This adds the host dependency host-qt6base as host-qt6tools requires the
Qt cmake modules to be installed.
Fixes:
$ make qt6tools
(...)
CMake Error at CMakeLists.txt:21 (find_package):
Could not find a package configuration file provided by "Qt6" (requested
version 6.7.2) with any of the following names:
Qt6Config.cmake
qt6-config.cmake
Add the installation prefix of "Qt6" to CMAKE_PREFIX_PATH or set "Qt6_DIR"
to a directory containing one of the above files. If "Qt6" provides a
separate development package or SDK, be sure it has been installed.
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The download and homepage URL for this project have been
updated. The old site no longer works.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Provide correct grouping for preprocessor conditions to avoid building
ld.so with undefined macroses which are in use. This is a fix for
package/uclibc/0002-Fix-compilation-with-4.x-kernel-headers.patch.
Signed-off-by: Dmitry Chestnykh <dm.chestnykh@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some buildsystems (or their use of it by packages) will cause flags in
LDFLAGS to be re-orderded, or even dropped, causing some
incomprehensible mayhem... For example, gpsd [0] has this in its
SConscript [1](typoes not mines, for once):
591 # scons uses gcc, or clang, to link. Thus LDFLAGS does not serve its
592 # traditional function of providing arguments to ln. LDFLAGS set in the
593 # environment before running scons get moved into CCFLAGS by scons.
594 # LDFLAGS set while running scons get ignored.
[--SNIP--]
611 for i in ["ARFLAGS",
612 "CCFLAGS",
613 "CFLAGS",
614 "CPPFLAGS",
615 "CXXFLAGS",
616 "LDFLAGS",
617 "LINKFLAGS",
618 "SHLINKFLAGS",
619 ]:
620 if i in os.environ:
621 # MergeFlags() puts the options where scons wants them, not
622 # where you asked them to go.
623 env.MergeFlags(Split(os.getenv(i)))
So, when LDFLAGS (our TARGET_LDFLAGS) contains "-z text" (without the
quotes), that gets turned into a command line like (line-splitted for
readability):
[...]/buildroot/output/host/bin/aarch64_be-buildroot-linux-musl-gcc \
-o gpsd-3.25/drivers/driver_rtcm2.os \
-c \
--sysroot=[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot \
-O3 -g0 \
-z \
-fPIC -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \
gpsd-3.25/drivers/driver_rtcm2.c
Notice how there is a lone "-z" without any following keyword.
This then causes a build failure that looks totally unrelated [2]:
In file included from gpsd-3.25/drivers/../include/gpsd.h:36,
from gpsd-3.25/drivers/driver_rtcm2.c:65:
gpsd-3.25/drivers/../include/os_compat.h:40:8: error: redefinition of ‘struct timespec’
40 | struct timespec {
| ^~~~~~~~
In file included from [...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/sys/select.h:16,
from gpsd-3.25/drivers/../include/gpsd.h:31:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/bits/alltypes.h:237:8: note: originally defined here
237 | struct timespec { time_t tv_sec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER==4321); long tv_nsec; int :8*(sizeof(time_t)-sizeof(long))*(__BYTE_ORDER!=4321); };
| ^~~~~~~~
gpsd-3.25/drivers/../include/os_compat.h:48:5: error: conflicting types for ‘clock_gettime’; have ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
48 | int clock_gettime(clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
In file included from gpsd-3.25/drivers/../include/gpsd.h:33:
[...]/buildroot/output/host/aarch64_be-buildroot-linux-musl/sysroot/usr/include/time.h:104:5: note: previous declaration of ‘clock_gettime’ with type ‘int(clockid_t, struct timespec *)’ {aka ‘int(int, struct timespec *)’}
104 | int clock_gettime (clockid_t, struct timespec *);
| ^~~~~~~~~~~~~
scons: *** [gpsd-3.25/drivers/driver_rtcm2.os] Error 1
scons: building terminated because of errors.
make[1]: *** [package/pkg-generic.mk:289: [...]/buildroot/output/build/gpsd-3.25/.stamp_built] Error 2
make: *** [Makefile:83: _all] Error 2
Although undocumented, neither in gcc not ld (clang unchecked by lack of
a clang toolchain here, and by lack of clang knowledge), -z accepts the
keyword to be snatch-glued onto it, like -zkeyword, rather than be
spearated with a space. So, use that to pass -ztext.
Fixes:
http://autobuild.buildroot.org/results/c03/c039989947b960ac6af17c87090366abc26dcb6d/http://autobuild.buildroot.net/results/bc35d3e7b0e8c59c776652070650af3c749250ee/
[0] Our other scons-based package, mongodb, does not build for another
reason that probably hides the same issue as seen with gpsd.
[1] As explained in gpsd's SConscript (se above), Scons does play tricks
with variables:
https://scons.org/doc/production/HTML/scons-man.html#f-MergeFlagshttps://scons.org/doc/production/HTML/scons-man.html#f-ParseFlags
Quoting:
Flag values are translated according to the prefix found, and added
to the following construction variables:
[...]
-Wl, LINKFLAGS
[...]
- CCFLAGS
[...]
Any other strings not associated with options are assumed to be the
names of libraries and added to the $LIBS construction variable.
So in our case, it finds that -z is an unknown option that matches the
'-' prefix, so it is added to CFLAGS, while 'text' is a string on its
own, so added to LIBS, and thus it would try to link with -ltext
(supposedly, because we do not even go that far). Funnily enough, we can
se that "-Wl," is a known option prefix, that is added to LINKFLAGS (to
properly be used with gcc or clang, not ld).
As a consequence, gpsd's buildsystem does drop -ztext from the link
flags, and only passes it to the compile flags, which brings us back to
before we banned textrels in a1a2f498d7 (package/Makefile.in: ban
textrels on musl toolchains). Fixing gpsd is a task for another,
separate patch...
[2] I spent quite some time to look at recent, time-related changes in
Buildroot, especially due to the infamous time64_t issues... Alas, that
was not related, and only a git-bisect pinpointed the actual issue. Poor
polar bears...
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: J. Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: J. Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Migrate the zynqmp_zcu106_defconfig to rev1.0 ddr memory, since all new boards
will be using the rev1.0 ddr memory.
This patch also adds documentation in the board/zynqmp/readme.txt explaining
the issue related to the change in ddr memory. Should users not see anything
printing from the board during boot, the most likely issue is that the board
has the original ddr memory and the u-boot device tree needs to be configured
accordingly to revA.
Original DDR Memory:
BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="DEVICE_TREE=zynqmp-zcu106-revA"
More information regarding this issue can be found here:
https://support.xilinx.com/s/article/71961?language=en_US
Signed-off-by: Neal Frager <neal.frager@amd.com>
Reviewed-by: Brandon Maier <brandon.maier@collins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As of commit e35f29177495131f0f598fc7ae1ffd74d89edf15, the dynamic-layouts
example has been removed from the flutter-packages repository, which fixes
https://github.com/flutter/flutter/issues/148979.
The exact reasoning is as follows:
```
The dynamic_layouts package is unpublished, and its core feature set has not
been updated in years.
Though it's not high-traffic, all packages in that repo require maintenance
for Flutter versions, gradle bumps, and project migrations.
```
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add `"download_fuchsia_deps": False` to the dot-gclient file as this is
for linux, not fuchsia, so the dependencies are not necessary.
Also, change various paths in flutter-engine.mk to ensure that the package
builds correctly.
Remove patch
0005-skip-configuration-dependency-if-unit-tests-are-disa.patch which
is upstream.
Tested with tests.package.test_flutter.TestFlutter.test_run
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As of https://github.com/flutter/engine/pull/51943, by default, flutter now
uses and provides the AOT snapshot frontend server instead of the
frontend_server.dart.snapshot.
The depfile produced by dart has been renamed from kernel_snapshot.d to
kernel_snapshot_program.d.
Flutter programs must compile with the dartaotruntime binary instead of the
dart binary, or else errors occure stating that the dartaotruntime must be
used.
Signed-off-by: Adam Duskett <adam.duskett@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit adds license information, and license file hashes for LTS
versions, by using per-version directories.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is a new lts-v2.10.x branch. Add it to the selection
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
bump the lts-v2.8.x branch to v2.8.20. Our patch still applies.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
ARM_TRUSTED_FIRMWARE_SITE is currently pointing to the deprecated
ARM-software github read-only mirror[0] which is no longer publishing
new tags. They do have a newer github mirror under the TrustedFirmware-A
organization[1] which continues to receive tag updates we could use
however because of the way github generates tarballs changing the SITE
to point to TrustedFormware-A changes the pre-calculated hash values
for every version for everyone.
Without much way around changing all hash values if we want these latest
tags, lets drop the github mirrors and move to the official git
source[2] so we can download real tarballs which shouldn't change even
if the ARM_TRUSTED_FIRMWARE_SITE moves again and hopefully preventing
this from ever happening again.
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/
[1] https://github.com/TrustedFirmware-A/trusted-firmware-a
[0] https://github.com/ARM-software/arm-trusted-firmware
Signed-off-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit 7f0af11cee (support/testing/tests/package/test_flutter.py: new
runtime test) added a simple test that just checked that the systemd
unit launching the application, was active.
It is perfectly possible, from a systemd perspective, that the unit is
active, while the application actually crashes.
Instead, what we need to check, is that the application does actually
render "something"; we don't really care what, as long as we know it is
actually rendering, thus the graphical stack is working and the
aplication stack is running.
Extend the flutter runtime test to also check that the framebuffer is
modified by the application when it is running, similarly to what we do
in the weston test.
We drop the activation of the unit and start it manually, as we want to
check the state of the CRC before, while, and after the application
runs.
We also need to disable the blinking cursor on the console, or we would
not be able to detect whether a change in CRC is due to the application
starting rendering, or to the cursor blinking. We tell the kernel to
disable the cursor with the appropriate kernel command line parameter.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Adam Duskett <aduskett@gmail.com>
Reviewed-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In 4edb0e3456 (support/testing/tests/package/test_weston.py: new
runtime test), the weston test was introduced, and thus was the first
that needed to test that rendering was happening.
Now we also have a test for a flutter application, and we'll want to
have it test the rendering too.
Move the corresponding code to a helper that can be reused by other
tests, rather than duplicate (or reinvent) it.
Switch weston to using that new helper.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Julien Olivain <ju.o@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Django 5.0.7 fixes the following CVEs:
* CVE-2024-38875: Potential denial-of-service vulnerability in django.utils.html.urlize()
* CVE-2024-39329: Username enumeration through timing difference for users with unusable passwords
* CVE-2024-39330: Potential directory-traversal via Storage.save()
* CVE-2024-39614: Potential denial-of-service vulnerability in get_supported_language_variant()
Django 5.0.8 fixes the following CVEs:
* CVE-2024-41989: Memory exhaustion in django.utils.numberformat.floatformat()
* CVE-2024-41990: Potential denial-of-service vulnerability in django.utils.html.urlize()
* CVE-2024-41991: Potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget
* CVE-2024-42005: Potential SQL injection in QuerySet.values() and values_list()
Further release Notes: https://docs.djangoproject.com/en/5.0/releases/
Signed-off-by: Marcus Hoffmann <buildroot@bubu1.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
