We need to backport a commit to fix a build failure cased by a spurious
wheel dependency.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This _partially_ reverts commit 2dbb0660fb.
Indeed, before 2dbb0660fb, the per-package ../host/ directory was
explicitly created right before it was populated. With 2dbb0660fb, it
is now created only at the beginning of the configure step.
However, some packages may have download or extract host dependencies,
and when we are trying to rsync them, the destination .../host/
directory does not yet exist at the download or extract steps, thus the
build fails. E.g., with wget which needs host-lzip if the system does
not have it yet:
rsync -a --link-dest=/home/ymorin/dev/buildroot/O/per-package/host-lzip/host/ /home/ymorin/dev/buildroot/O/per-package/host-lzip/host/ /home/ymorin/dev/buildroot/O/per-package/wget/host
rsync: mkdir "/home/ymorin/dev/buildroot/O/per-package/wget/host" failed: No such file or directory (2)
rsync error: error in file IO (code 11) at main.c(682) [Receiver=3.1.3]
make[1]: *** [package/pkg-generic.mk:170: /home/ymorin/dev/buildroot/O/build/wget-1.20.3/.stamp_extracted] Error 11
Kudos to Raphael for pin-pointing the culprit commit.
Fixes:
http://autobuild.buildroot.org/results/4c8/4c895c7ac0a635d38f5015b5df0393581ad7b508/
and a slew of similar failures
Notes:
An alternative solution would be to move the creation of the directories
from the configure step to the download step *and* to the rsync step,
but this is not so nice in the end... Let's just ensure they are created
where needed: at the configure step, and when populating them.
Reported-by: Raphael Jacob <r.jacob2002@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Add new NLS dependency as well as a patch to fix a build failure
without it
- Drop host-gettext (not needed since autoreconf was dropped with
8729c4ef88)
- Update indentation in hash file (two spaces)
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 0390777bfa (package/docker-engine: needs some kernel
options), docker-engine now automatically ensures the needed kernel options
are enabled, so drop the explicit options from the kernel config.
23:19:27 TestDockerCompose Starting
23:19:28 TestDockerCompose Building
00:14:41 TestDockerCompose Building done
00:15:30 TestDockerCompose Cleaning up
.
----------------------------------------------------------------------
Ran 1 test in 3362.784s
OK
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit 4f8229653 (package/docker-engine: needs more runtime
dependencies), docker-engine now automatically pulls in cgroupfs-mount, so
drop the explicit handling of it in TestDockerCompose.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a minor release which provides fixes for CVE-2020-9862,
CVE-2020-9893, CVE-2020-9894, CVE-2020-9895, CVE-2020-9915, and
CVE-2020-9925.
Full release notes can be found at:
https://webkitgtk.org/2020/07/28/webkitgtk2.28.4-released.html
A detailed security advisory can be found at:
https://webkitgtk.org/security/WSA-2020-0007.html
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is a minor release which provides fixes for CVE-2020-9862,
CVE-2020-9893, CVE-2020-9894, CVE-2020-9895, CVE-2020-9915, and
CVE-2020-9925.
Full release notes can be found at:
https://wpewebkit.org/release/wpewebkit-2.28.4.html
A detailed security advisory can be found at:
https://wpewebkit.org/security/WSA-2020-0007.html
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Removed patch which was applied upstream:
920cc74da0
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes an issue if host-dbus happens to be rebuilt after systemd, in
which case it autodetects systemd support but then ignored the prefix
when installing unit files. That means that is tries to write to the
host system's /usr/lib/ which fails.
There is no reason to build and install systemd support in the host
build, so disable it explicitly.
Signed-off-by: John Keeping <john@metanate.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
No functional change.
Rather than tracking both build targets and sub directory to run 'make
install' from, use a make loop for the staging/target install logic, similar
to how we are doing it to for the build step and directly use the Makefile
in the sub directory rather than the helper lib/lz4 targets in the top level
Makefile.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since the bit32 module is needed by all lua ABI 5.1 providers we can
select based on the lua ABI version instead of both lua 5.1 and luajit.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since solarus is compatible with lua interpreters that provide the
version 5.1 ABI we should depend on that instead of unconditionally
selecting luajit.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since collectd lua support is compatible with any luainterpreter
implementation we should depend on BR2_PACKAGE_HAS_LUAINTERPRETER
instead of unconditionally selecting BR2_PACKAGE_LUA.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr: use luainterpreter as dependency]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since sysdig is compatible with lua interpreters that provide the
version 5.1 ABI we should depend on that instead of unconditionally
selecting luajit.
Use luainterpreter as the dependency, now that either lua or luajit
can be used.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
- reorder dependencies in Config.in: package deps go after toolchain
deps
- keep the toolchain deps together in the comment
- switch to using luainterpreter as a build dependency
- split the now-long _DEPENDENCIES list
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Now that we have booleans to represent the Lua ABI version, and that
every Lua providers do select those, there is no longer any reason
for them to also handle the ABI version string anymore.
Move the defaults into the common luainterpreter.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: James Hilliard <james.hilliard1@gmail.com>
Cc: Francois Perrad <francois.perrad@gadz.org>
Since a number of packages depend on specific ABI version that are
provided by lua and luajit packages we should have a kconfig variable
that those packages can depend on.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The current version of prosody is compatible with Lua 5.3.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Luajit is a provider for luainterpreter. We can't select providers of
virtual packages; we can only depend on them.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
- a lua interpreter is needed, so don't drop the dependency
- make it a "depends on" rather than a "select"
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Luajit is a provider for luainterpreter. We can't select providers of
virtual packages; we can only depend on them.
Note also that it is not very clear whether the host and target variants
of EFL need to be built with the same lua interpreter. Today, this is
guaranteed as we inly use luajit in both cases. But there were issues
with lua 5.1 in the past, so stick to only using luajit.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
[yann.morin.1998@free.fr:
- depend on luajit, not "any" luainterpreter
- which keeps the host and target variants built with the same
interpreter
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Bump kernel to version 5.7.10 and U-Boot to 2020.07
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Tested-by: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bump kernel to version 5.7.10 and U-Boot to 2020.07
Signed-off-by: Pierre-Jean Texier <pjtexier@koncepto.io>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The logic doing the padding and concatenation of DDR firmware was
duplicated between the DDR4 and LPDDR4 cases. This commit refactors
this logic into a single function FIRMWARE_IMX_PREPARE_DDR_FW.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Stephane Viau <stephane.viau@oss.nxp.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
BR2_VERSION_FULL is currently defined as follows:
BR2_VERSION_FULL := $(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
This BR2_VERSION_FULL value then gets used as the "VERSION" variable
in the /etc/os-release file.
The logic of "setlocalversion" is that if it is exactly on a tag, it
returns nothing.
If it is on a tag + a number of commits, then it returns only
-XYZ-gABC where XYZ is the number of commits since the last tag, and
ABC the git commit hash (these are extracted from git describe).
This output then gets concatenated to BR2_VERSION which gives
something like 2020.05 or 2020.05-00123-g5bc6a.
The issue is that when you're on a tag specific to your project, which
is not a Buildroot YYYY.MM tag, then the output of setlocalversion is
empty, and all you get as VERSION in os-release is $(BR2_VERSION)
which is not really nice. Worse, if you have another non-official
Buildroot tag between the last official Buildroot tag/version and
where you are, you will get $(BR2_VERSION)-XYZ-gABC, but XYZ will not
correspond to the number of commits since BR2_VERSION, but since the
last tag that "git describe" as found, which is clearly incorrect.
Here is an example: you're on master, "make print-version" (which
displays BR2_VERSION_FULL) will show:
$ make print-version
2020.08-git-00758-gc351877a6e
So far so good. Now, you create a tag say 5 commits "before" master,
and show BR2_VERSION_FULL again:
$ git tag -a -m "dummy tag" dummy-tag HEAD~5
$ make print-version
2020.08-git-00005-gc351877a6e
This makes you believe you are 5 commits above 2020.08, which is
absolutely wrong.
So this commit simplifies the logic of setlocalversion to simply
return what "git describe" provides, and not prepend $(BR2_VERSION) in
the main Makefile. Since official Buildroot tags match official
Buildroot version names, you get the same output when you're on an
official Buildroot tag, or some commits above a Buildroot tag. An in
other cases, you get a sensible output. The logic is also adjusted for
the Mercurial case.
In the above situation, with this commit applied, we get:
$ make print-version
dummy-tag-6-g6258cdddeb
(6 commits instead of 5 as we have this very commit applied, but at
least it's 6 commits on top of the dummy-tag)
Finally, if you're not using a version control system, setlocalversion
was already returning nothing, so in this case, the Makefile simply
sets BR2_VERSION_FULL to BR2_VERSION to preserve this behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The defconfig check has been introduced by the previous
patch before the building each defconfig but those builds
are done every week or more.
Checking if a defconfig is valid can be done on every
push in the repository since it take few seconds.
This would allow to detect as soon as possible a problem
in a defconfig and eventually avoid breaking the build
while build testing all defconfig.
Introduce a new job template ".defconfig_check" in
gitlab-ci.yml.in and modify the generate-gitlab-ci-yml
to create a job for each defconfig to run the test.
Although, we could have used only one job to do all
tests, using one job per defconfig allow to identify
easily in gitlab which defconfig is falling.
Tested:
https://gitlab.com/kubu93/buildroot/pipelines/138331069https://gitlab.com/kubu93/buildroot/pipelines/171223758
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Use the script added by the previous patch to check
generated config files.
Tested on gitlab:
https://gitlab.com/kubu93/buildroot/pipelines/137597966
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
For the same reason as for 50b747f212,
we need to check if the generated configuration file (.config)
contains all symbols present in the defconfig file.
If not there is an issue with the defconfig.
This script will be used in .gitlab-ci.yml.
Inspired by is_toolchain_usable() function from genrandconfig:
https://git.busybox.net/buildroot/tree/utils/genrandconfig?h=2020.02#n164
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr:
- strip defconfig lines when reading them
- use a generator to read the defconfig lines
- no need to strip() again when building the missing list
- testing the list directly, not its len()
- simply sys.exit(1) in the error condition
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
BR2_TARGET_UBOOT_NEEDS_PYTHON3 is already selected for
this defconfig, BR2_TARGET_UBOOT_NEEDS_PYTHON and
BR2_TARGET_UBOOT_NEEDS_PYTHON3 can't be selected at the
same time.
Reported by check-dotconfig.py.
Fixes:
https://gitlab.com/kubu93/buildroot/-/jobs/657885314
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
BR2_TARGET_UBOOT_NEEDS_PYTHON3 is already selected for
this defconfig, BR2_TARGET_UBOOT_NEEDS_PYTHON and
BR2_TARGET_UBOOT_NEEDS_PYTHON3 can't be selected at the
same time.
Reported by check-dotconfig.py.
Fixes:
https://gitlab.com/kubu93/buildroot/-/jobs/657885313
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Move to an external RISC-V 64 bit musl toolchain to ease the load
on the autobuilders.
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a RISC-V 64-bit autobuild configuration for the internal
toolchain with uclibc.
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
We can enable uclibc for RISC-V 64 bit now that it has been
bumped from v1.0.32 to v1.0.34.
Uclibc has had basic support for RISC-V 64 bit since v1.0.31, but
shared library and TLS/NPTL support has only been available since
v1.0.33.
This update has been tested using qemu_riscv64_virt_defconfig and
the Buildroot host QEMU.
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
according to https://wiki.gentoo.org/wiki/Systemd#Kernel
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
[Peter: drop optional CGROUP_BPF / BPF_SYSCALL, unused POSIX_MQUEUE and
DEVTMPFS which is already taken care of by linux.mk]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
according to https://wiki.gentoo.org/wiki/Docker#Kernel /
docker-engine/contrib/check-config.sh.
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
[Peter: synchronize with contrib/check-config.sh, only enforce DM options if
device mapper driver is enabled]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 2acb27e298 ("package/lz4: make
program installation optional") make the installation of the lz4
programs optional. To preserve backward compatibility, this commit
added a "default y" to the BR2_PACKAGE_LZ4_PROGS.
While Buildroot definitely tries to preserve backward compatibility in
general, in this case, the backward compatibility would mean that
everbody would by default install those 220 KB of program, which are
most likely not needed for the majority of use cases. Installaing them
by default kind of breaks the Buildroot principle of minimalism.
In this specific case, it is believed that the principle of minimalism
wins over the principle of backward compatibility.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
According to the cegui requirements select explicitly the default
OpenGL renderer based on available dependencies.
Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
