Some toolchain vendors may have backported those options to older gcc
versions, and we have no way to know, so we have to check that the
user's selection is acceptable.
Extend the macro that currently checks for SSP in the toolchain, with
a new test that the actual SSP option is recognised and accepted.
Note that the SSP option is either totaly empty, or an already-quoted
string, so we can safely and easily assign it to a shell variable to
test and use it.
Note that we do not introduce BR2_TOOLCHAIN_HAS_SSP_STRONG, because:
- our internal toolchain infra only supports gcc >= 4.9, so it has
SSP strong;
- of the external pre-built toolchains, only the codesourcery-arm
one has a gcc-4.8 which lacks SSP strong, all the others have a
gcc >= 4.9;
- we'd still have to do the actual check for custom external
toolchains anyway.
So, we're not adding BR2_TOOLCHAIN_HAS_SSP_STRONG just for a single
case.
Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Following gdb 7.12.1 removal [1] the host gcc version needs to be updated
since gdb >= 8.x now requires a C++11 compiler (gcc >= 4.8).
While at it, move BR2_HOST_GCC_AT_LEAST_4_8 under BR2_PACKAGE_HOST_GDB since
it's not an architecture dependency. Add a comment when the host gcc is too
old to build host gdb.
[1] d36f2c7333
Fixes:
http://autobuild.buildroot.org/results/822/822a747a6717db57705d1ce198a61988aa1173b1
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Cc: Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We currently redirect the output of each helper function. This was nice
as long as we were generating single .mk and .in fragments.
But we are soon to need more .in fragments.
So, do the redirection inside the .in helpers.
We do not (currently) need to generate more than one .mk fragment, but
for consistency, do the redirection in the .mk helper too.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This rule was added back in 9429e7b698 (core: introduce an intermediate
rule before the configurators) when the kconfig-side br2-external file
was generated separately from the Makefile-side one.
Now that they are generated together very early in the Makefile, we no
longer need this intermediate rule. Drop it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
[Peter: also drop outdated reference in the manual]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When we introduced support for multiple br2-external trees, we
introduced two files, one on the Makefile side, needed very early,
and one on the kconfig side, needed later in the configuration
process. We naturally introduced a two-step generation, as it looked
like the simplest and most obvious way.
But now, we are on the verge of generating more files on the kconfig
side, and it does not make sense to add even more steps to generate
them.
And even better yet, we can generate both the Makefile-side and
kconfig-side files at the same time, in fact.
Make it so.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that all the br2-external generated files are named after the same
pattern, it gets easier to remove them all using a glob.
Furthermore, we're on the verge of introducing more such generated
files, so removing them at one fell swoop will be simpler too.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that the two (all of them!) br2-external related files are generated
in the same location, it makes sense they are named after the same
pattern.
When initial support for (then single) br2-external trees was added back
in a4239f7fd1 (core: introduce the BR2_EXTERNAL variable), it was not
clear-cut why that file was not named with a br2 prefix.
So rename it now.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, that file is generated rather late in the configuration
process, so BUILD_DIR is known (and exists) by then.
We're soon to generate that file much earlier, at a point where
BUILD_DIR is not yet known, so we have two options:
1- declare BUILD_DIR earlier;
2- generate the file in an already-known location.
We go with the second solution, as we're already generating a
br2-external related file in BASE_DIR, so we can as well generate all
br2-external files in the same place.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When adding the check-package test, the committer (Arnout) merged the
TestCheckPackageBasicUsage class into the TestCheckPackage class, but
failed to regenerate .gitlab-ci.yml. Do this now.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The error message issued when the creation of the log file fails lacks
an ending newline. Add a patch already submitted upstream[1] to fix it.
1. https://github.com/dubiousjim/dcron/pull/22
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
python3 nowadays appends the triplet to the config-<version>m directory:
echo target/usr/lib/python3.7/config-*
target/usr/lib/python3.7/config-3.7m-powerpc-linux-gnu
Likewise, there is no longer a pyconfig.h:
ls target/usr/lib/python3.7/config-3.7m-powerpc-linux-gnu
config.c config.c.in install-sh libpython3.7m.a Makefile
makesetup python-config.py python.o Setup Setup.local
So adjust the removal logic to match. Use a wildcard rather than
$GNU_TARGET_NAME as buildroot and python3's idea of the triplet doesn't
always match (E.G. for musl/uclibc).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fixes:
http://autobuild.buildroot.net/results/cb4/cb49c539501342e45cbe5ade82e588fcdf51f05b
GCC commit 6834b83784dcf0364eb820e8 (multiarch support for non-glibc linux
systems), which is part of GCC 8+, changed the multiarch logic to use
$arch-linux-musl / $arch-linux-uclibc rather than $arch-linux-gnu.
This then causes the python3 configure script to error out:
checking for the platform triplet based on compiler characteristics... powerpc-linux-gnu
configure: error: internal configure error for the platform triplet, please file a bug report
http://autobuild.buildroot.net/results/cb4/cb49c539501342e45cbe5ade82e588fcdf51f05b
As it requires that the --print-multiarch output (if not empty) matches the
deduced triplet (which always uses -linux-gnu).
It isn't quite clear why --print-multiarch returns something for a
non-multiarch toolchain on some architectures (E.G. PowerPC), but as a
workaround, add a patch to rewrite the --print-multiarch output to match
older GCC versions to keep the configure script happy.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We do not usually provide help for our internal scripts. Besides, such
help has a tendency to bitrot pretty quickly anyway.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit b14b02698 (core/br2-external: restore compatibility with old
distros) switched to using 'eval' to emulate associative arrays, for
those distros too old to have bash-4+.
In so doing, it forgot to declare the new local variables in the
respective helper functions.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vadim Kochan <vadim4j@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
xz help indicates only 1 thread is used unless we set threads:
-T, --threads=NUM use at most NUM threads; the default is 1; set to 0
to use as many threads as there are processor cores
Since this splits the file into blocks, the result will be not
bit-for-bit identical to single-threaded compression. Therefore, don't
enable this in BR2_REPRODUCIBLE builds.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
[Arnout: append the option instead of repeating the entire command]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
U-Boot supports a number of environment variables to pass specific
information. The following patches were submitted in the past to one
some specific Config.in option to pass some of these variables:
- http://patchwork.ozlabs.org/patch/881197/ proposed an option to
pass a custom EXT_DTB= variable
- http://patchwork.ozlabs.org/patch/1018245/ proposed an option to
pass a custom DEVICE_TREE= variable
Instead of adding one Config.in option for each of those variables,
let's provide a generic mechanism to pass arbitrary variables during
U-Boot build step.
Cc: Konstantin Porotchkin <kostap@marvell.com>
Cc: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some packages test for CMAKE_SYSTEM explicitly[1]
CMAKE_SYSTEM is comprised of CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_VERSION.
It defaults to CMAKE_SYSTEM_NAME if CMAKE_SYSTEM_VERSION is not set[2]
At the point CMAKE_SYSTEM_NAME is set to "Linux" CMAKE_SYSTEM is already
constructed. Setting it explicitly ensures that it is the correct value.
This is because we do set CMAKE_SYSTEM_NAME twice, in fact:
- first in toolchainfile.cmake, so that we tell cmake to use the
"Buildroot" platform,
- second, in the Buildroot.cmake platform definition itself, so that
we eventually behave like the Linux platform.
We also set CMAKE_SYSTEM_VERSION to 1, and so the real CMAKE_SYSTEM
value should be set to Linux-1 if we were to follow the documentation to
the letter.
However, for Linux, the version does not matter, and in some situations
may even be harmful (that was reported in one of the commits that
introduce Buildroot.cmake and toolchainfile.cmake).
[1] Fluidsynth 0cd44d00e1/CMakeLists.txt (L80)
[2] https://cmake.org/cmake/help/git-master/variable/CMAKE_SYSTEM.html#variable:CMAKE_SYSTEM
Signed-off-by: Frank Vanbever <frank.vanbever@mind.be>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Peter: update commit message with description from Yann]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bitcoin Core is an open source project which maintains and releases
Bitcoin client software called “Bitcoin Core”.
Signed-off-by: Fabio Urquiza <fabiorush@gmail.com>
[Thomas:
- Don't create a new blockchain applications sub-menu for now, put
this package in "Miscellaneous applications"
- Do not select BR2_INSTALL_LIBSTDCPP, use depends on instead, and
add the corresponding comment.
- Do not select BR2_TOOLCHAIN_BUILDROOT_USE_SSP. Instead pass
--disable-hardening, and let Buildroot pass the appropriate CFLAGS
when hardening features are enabled system-wide.
- Add missing BR2_TOOLCHAIN_HAS_ATOMIC dependency
- Add quirky !(BR2_arm || BR2_armeb) || BR2_USE_MMU because the
Cortex-M toolchains don't provide 8-byte __atomic intrinsics, but
we don't have a good way to express that today
- Add missing BR2_TOOLCHAIN_HAS_GCC_BUG_64735 due to the use of
std::future
- Use only one BITCOIN_CONF_OPTS assignment to pass all options]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add a simple init script that invokes sysctl early in the initialization
process to configure kernel parameters. This is already performed by
systemd (systemd-sysctl) but there is no sysvinit/busybox counterpart.
Files are read from directories in the following list in the given order
from top to bottom:
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a simple init script that invokes sysctl early in the initialization
process to configure kernel parameters. This is already performed by
systemd (systemd-sysctl) but there is no sysvinit/busybox counterpart.
Files are read from directories in the following list in the given order
from top to bottom:
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
A file may be used more than once, since there can be multiple symlinks
to it. No attempt is made to prevent this.
Signed-off-by: Carlos Santos <unixmania@gmail.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Some platform may generate specific boot image files instead of
the generic files tee.bin and tee-*_v2.bin when building OP-TEE OS
package.
This change introduces optee-os configuration directive
BR2_TARGET_OPTEE_OS_CORE_IMAGES that allows board configuration
to specify its expected boot image file names.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[Thomas: use the current hardcoded values as the default for the new
config option, to avoid breaking existing setups, and therefore use
$(wildcard ...) to support wildcards]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The domain search option is from RFC3397, not RFC3359 (which is about TLV
codepoints), so fix that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This is useful in networks with internal resources as it allows
to use much shorter names.
E.g. instead of "server.internal.company.com" it's possible
to use just "server" if DHCP server is configured with:
---------------------------->8-----------------------
option domain-search "internal.company.com";
---------------------------->8-----------------------
This improvement consists of 2 parts:
1. Enable handling of RFC3397 so DHCP client is ready for processing
corresponding data from DHCP server.
2. Some DHCP servers always send out search list if it is set in server's
configuration and some servers only provide search list if client
asks for that (sending list of options it expects to get).
And exactly for those stubborn DHCP servers we need to add "-O search"
to udhcp's command line via CONFIG_IFUPDOWN_UDHCPC_CMD_OPTIONS.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Ignacy Gawedzki <ignacy.gawedzki@green-communications.fr>
Cc: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch introduces a recently released significant update to ARC HS
family: ARC HS48.
One of the major ARC HS48 features is dual-issue pipeline which requires a
little bit modified instruction scheduling compared to single-issue cores
(HS38), thus new "-mcpu/--with-cpu=hs4x".
Also to address some peculiarities of early designs based on HS48 we
introduced yet another "-mcpu/--with-cpu=hs4x_rel31" which we're going to use
as well on some of our development boards.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
[Peter: fixup check-package warnings]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Check external.mk is ignored only when in the root path of a
br2-external.
Add a file called external.mk as a fixture to be used by the test case.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
[Arnout: wrap at 80 columns]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The external.mk file in a br2-external usually contains raw makefile
targets. This file is common code and not a package recipe so it should
not be tested against the code-style of a package .mk file.
When using this script to check files in a br2-external tree, usually
the user is responsible for not passing files that check-package do not
understand. But external.mk is special because it is part of the
br2-external structure, so it is likely someone expects it to be
checkable by an in-tree script.
Instead of adding another blob to the manual, just ignore this file.
Only do that when a br2-external is being tested (so with option -b
passed to the script) and also check that it is on the root path of the
br2-external to allow someone to have a package called external.
Reported on bug #11271.
Reported-by: Vitaliy Lotorev <lotorev@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Arnout: wrap at 80 columns]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Check the basic usage for check-package.
It can be called using either absolute path, relative path or from PATH.
Files to be checked can be passed with either absolute path or relative
path (also including files in the current directory).
Also check it ignores some special files when checking intree files,
i.e. package/pkg-generic.mk, while still generating warnings for out-of-tree
files when called with -b.
In order to allow the later, add an empty line to the Config.in in the
br2-external being tested so the script does generate a warning.
Catches bug #11271.
More tests can be added later, for example compatibility to Python 3.
Suggested-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
[Arnout: wrap at 80 columns where appropriate; merge into a single
class.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Currently run-tests must be called from the Buildroot top directory.
Derive the top directory from the script path, so run-tests can be called from
any path.
As a consequence the test infra will always test the repo it belongs to.
Suggested-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
One of the possible usages of check-package is to first cd to the
directory that contains the files to test (e.g. a package directory) and
then call the script passing the files in the current dir.
It already works when used for intree files, but for files in a
br2-external it throws an exception because some check functions (from
utils/checkpackagelib/lib_*.py) do need the name of the file being
processed and assume there will be a slash before the name.
Fix all check functions that assume that the full filename being checked
contains a slash. Do not use regexps to extract the filename, use
os.path functions instead.
Notice RemoveDefaultPackageSourceVariable and TypoInPackageVariable lead
to an exception in this case, but ApplyOrder instead generates a false
warning.
Fixes bug #11271.
Reported-by: Vitaliy Lotorev <lotorev@gmail.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Vitaliy Lotorev <lotorev@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This patch adds a new jack1 package alongside the existing jack2.
While jack1 and jack2 are two equivalent implementations of the same
protocol, they differ in a few details and both of them are being
actively used (jack2 is not considered to be a replacement of jack1).
It is not possible to enable both at the same time, so hide away jack1
when jack2 is enabled (to keep existing defconfig files working).
For more information, see:
https://github.com/jackaudio/jackaudio.github.com/wiki/Q_difference_jack1_jack2
Signed-off-by: Adam Heinrich <adam@adamh.cz>
[yann.morin.1998@free.fr:
- fix coding style
- use the release tarball, not a git clone
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
[Peter: add host-pkgconf dependency, reorder dependencies]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The custom external toolchain logic asks the user to specify which gcc
version is provided by the toolchain. The list of gcc versions given
by Buildroot is restricted depending on the selected CPU architecture
using the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz config options.
However, these config options generally indicate in which upstream gcc
version the support for the selected architecture was introduced. But
in practice, it is possible that an external toolchain uses some
non-upstream gcc code, providing support for a CPU architecture before
it was merged in upstream gcc.
A specific example is that there are pre-built external toolchains for
the C-SKY CPU architecture that are based on gcc 6.x, even if the
support for it was only added in upstream gcc 9.x.
Due to the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz options, only gcc >= 9.x
can be selected for C-SKY, preventing the use of such a custom
toolchain.
In addition, those dependencies are in fact not really needed:
Buildroot will check that the gcc version provided matches what the
user declared in the configuration. And if the gcc provided by the
toolchain does support that CPU architecture, then well, so be it,
there's no need to restrict the gcc version selected.
So we simply get rid of these dependencies on
BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz, and also don't use them anymore to
chose a default value for the gcc version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Acked-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
On Qt5 Latest package qt5webengine libnss that is affected by gcc bug
85862. However, that bug has now been worked around in libnss, so we
can remove the 'depends on !BR2_TOOLCHAIN_HAS_GCC_BUG_85862', as
libnss is now available even if the toolchain is affected by gcc bug
85862.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The recent addition of a RISC-V musl toolchain uncovered an issue in
Boost's endianness detection. Boost endianness detection only works
for C libraries that pretend to be glibc *or* if the architecture is
explicitly handled by Boost endian.h header. Neither were true for
RISC-V musl, so we slightly patch boost to fix this problem.
Fixes:
http://autobuild.buildroot.net/results/a40b600a7d0fdb6a8a1ded7883b4936f120811f5/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 0004-workaround-musl-bug.patch was added because musl's <sched.h>
was using memset(), but without including <string.h>. So including
just <sched.h> was causing a build failure.
However, this issue in musl has been fixed in upstream musl commit
48be5b6313d7b827acf555769e93b389fa9f6307 ("fix use of memset without
declaration in sched.h cpu set macros"). This commit was part of musl
1.1.17, which has been released a while ago. Both 2019.02.x, 2019.05.x
and master use a newer musl version.
So the workaround in Boost can be dropped.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
An ASCII-art game like Space Invaders using ncurses.
Signed-off-by: Thomas Huth <huth@tuxfamily.org>
Reviewed-by: Gilles Talis <gilles.talis@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Use the new builtin armv5 4.19 kernel to test atop.
The atop package cannot be tested using BASIC_TOOLCHAIN_CONFIG because
it needs kernel headers >= 3.14. So use an updated version of it,
copying the config fragment from
support/config-fragments/autobuild/br-arm-full.config
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Use the new builtin kernel 4.19 with VirtIORNG to provide entropy to
test syslog-ng.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
