Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buildroot 2019.11 with GCC 9.2 build fails with "xgcc: No such file or directory" #108

Open
cirosantilli opened this issue Dec 16, 2019 · 3 comments

Comments

@cirosantilli
Copy link
Owner

cirosantilli commented Dec 16, 2019

At https://github.com/cirosantilli/linux-kernel-module-cheat/tree/buildroot-2019.11-1 which has buildroot 2019.11 and GCC 9.2:

  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -L/mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/host/lib -lisl -L/mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/host/lib -L/mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/host/lib -L/mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/host/lib -lmpc -lmpfr -lgmp -rdynamic -ldl  -L./../zlib -lz
/mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/build/host-gcc-final-custom/build/./gcc/xgcc -B/mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/build/host-gcc-final-custom/build/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../gcc/testsuite/selftests
/bin/bash: /mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/build/host-gcc-final-custom/build/./gcc/xgcc: No such file or directory
make[4]: *** [../../gcc/cp/Make-lang.in:178: s-selftest-c++] Error 127
make[4]: *** Waiting for unfinished jobs....
../../gcc/gcc.c: In function ‘long unsigned int get_random_number()’:
../../gcc/gcc.c:9639:12: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 9639 |       read (fd, &ret, sizeof (HOST_WIDE_INT));
      |       ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gcc.c: In function ‘void do_report_bug(const char**, int, char**, char**)’:
../../gcc/gcc.c:6999:9: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 6999 |   write (fd, "\n//", 3);
      |   ~~~~~~^~~~~~~~~~~~~~~
../../gcc/gcc.c:7002:13: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7002 |       write (fd, " ", 1);
      |       ~~~~~~^~~~~~~~~~~~
../../gcc/gcc.c:7003:13: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7003 |       write (fd, new_argv[i], strlen (new_argv[i]));
      |       ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gcc.c:7005:9: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
 7005 |   write (fd, "\n\n", 2);
      |   ~~~~~~^~~~~~~~~~~~~~~
rm gcov.pod gfdl.pod gpl.pod cpp.pod gcc.pod gcov-dump.pod gfortran.pod gcov-tool.pod fsf-funding.pod
make[3]: *** [Makefile:4322: all-gcc] Error 2
make[2]: *** [Makefile:955: all] Error 2
make[1]: *** [package/pkg-generic.mk:241: /mnt/sda3/linux-kernel-module-cheat-out/buildroot/build/default/x86_64/build/host-gcc-final-custom/.stamp_built] Error 2
make: *** [Makefile:84: _all] Error 2
Traceback (most recent call last):
  File "./build", line 656, in <module>
    Main().cli()
  File "/home/ciro/bak/git/linux-kernel-module-cheat/cli_function.py", line 267, in cli
    exit_status = self.cli_noexit(*args, **kwargs)
  File "/home/ciro/bak/git/linux-kernel-module-cheat/cli_function.py", line 258, in cli_noexit
    return self._do_main(vars(args))
  File "/home/ciro/bak/git/linux-kernel-module-cheat/cli_function.py", line 152, in _do_main
    return self.main(**self._get_args(kwargs))
  File "/home/ciro/bak/git/linux-kernel-module-cheat/common.py", line 1372, in main
    ret = self.timed_main()
  File "./build", line 653, in timed_main
    component.build(self.env['arch'])
  File "./build", line 57, in build
    self.build_callback()
  File "./build", line 447, in f
    lkmc.import_path.import_path_main(component_file)(**args)
  File "/home/ciro/bak/git/linux-kernel-module-cheat/common.py", line 685, in __call__
    return super().__call__(**kwargs)
  File "/home/ciro/bak/git/linux-kernel-module-cheat/cli_function.py", line 149, in __call__
    return self._do_main(kwargs)
  File "/home/ciro/bak/git/linux-kernel-module-cheat/cli_function.py", line 152, in _do_main
    return self.main(**self._get_args(kwargs))
  File "/home/ciro/bak/git/linux-kernel-module-cheat/common.py", line 1372, in main
    ret = self.timed_main()
  File "/home/ciro/bak/git/linux-kernel-module-cheat/common.py", line 1795, in timed_main
    return self.build()
  File "/home/ciro/bak/git/linux-kernel-module-cheat/build-buildroot", line 166, in build
    cwd=self.env['buildroot_source_dir'],
  File "/home/ciro/bak/git/linux-kernel-module-cheat/shell_helpers.py", line 432, in run_cmd
    raise e
Exception: Command exited with status: 2

Problem does not happen on clean Buildroot 2019.11 with make qemu_x86_64_defconfig then menuconfig to use GCC 9.2.

Problem also does not happen with above + modify binutils to 2.32... give up?

@cirosantilli cirosantilli changed the title Buildroot with GCC 9.2 build fails with "xgcc: No such file or directory" Buildroot 2019.11 with GCC 9.2 build fails with "xgcc: No such file or directory" Dec 31, 2019
@ghost
Copy link

ghost commented May 5, 2020

I'm also having this issue with buildroot 2020.02 (not from your repo). I could fix it by deleting the out/build/ directory and running make again. Had to do this evry time I build, so I used binutils 2.32, I assume some build variables are set wrong at first build, so when I started build again after deleting the dir, some variables other builds set aren't set anymore.

@fidomax
Copy link

fidomax commented May 6, 2020

Just apply this patch to gcc:

--- a/gcc/Makefile.in	2019-09-04 10:05:38.483715500 +0300
+++ b/gcc/Makefile.in	2019-04-25 17:32:16.000000000 +0300
@@ -1961,7 +1961,7 @@
 # require the selftests to be run by defining their selftest-<LANG> as
 # s-selftest-<LANG>.  Otherwise, they should define it as empty.
 
-SELFTEST_TARGETS = @selftest_languages@
+SELFTEST_TARGETS = 
 selftest: $(SELFTEST_TARGETS)
 
 # Recompile all the language-independent object files.

@ghost
Copy link

ghost commented May 7, 2020

Thank you!

buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue May 31, 2020
As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.

The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.

While debuging with "make -p" we can notice that s-selftest-c target
contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

  s-selftest-c: cc1

While the build is failing, the s-selftest-c dependencies recipe is
still running and reported as a bug by make.

  "Dependencies recipe running (THIS IS A BUG)."

A change [5] in gcc 9 seems to introduce the problem since we can't
reproduce this problem with gcc 8.

As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
including language makefile fragments.

With the fix applied, the s-seltest-c dependency contains
SELFTEST_DEPS value.

  s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
[3] cirosantilli/linux-kernel-module-cheat#108
[4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
[5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
buildroot-auto-update pushed a commit to buildroot/buildroot that referenced this issue Jun 2, 2020
As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.

The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.

While debuging with "make -p" we can notice that s-selftest-c target
contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

  s-selftest-c: cc1

While the build is failing, the s-selftest-c dependencies recipe is
still running and reported as a bug by make.

  "Dependencies recipe running (THIS IS A BUG)."

A change [5] in gcc 9 seems to introduce the problem since we can't
reproduce this problem with gcc 8.

As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
including language makefile fragments.

With the fix applied, the s-seltest-c dependency contains
SELFTEST_DEPS value.

  s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
[3] cirosantilli/linux-kernel-module-cheat#108
[4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
[5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 58ecbbc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
fschuett added a commit to fschuett/oss-linbo that referenced this issue Jul 3, 2020
Squashed commit of the following:

commit 5382d50c2b59002d13d29e0298452163318feb32
Merge: dd36674066 6306cf35c5
Author: Frank Schütte <fschuett@gymhim.de>
Date:   Fri Jul 3 08:12:15 2020 +0200

    Add 'buildroot/' from commit '95fdb33f71f8a2d6a6e86fa3c6eb2968b6440b88'

    git-subtree-dir: buildroot
    git-subtree-mainline: dd36674066bb6bde1b38ce14f5c81ddbd6b5bcb2
    git-subtree-split: 95fdb33f71f8a2d6a6e86fa3c6eb2968b6440b88

commit dd36674066bb6bde1b38ce14f5c81ddbd6b5bcb2
Author: Frank Schütte <fschuett@gymhim.de>
Date:   Fri Jul 3 08:10:50 2020 +0200

    remove old buildroot branch

commit 6306cf35c5936184c09fa1f5678c3381e330fe2b
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon Jun 1 23:11:33 2020 +0200

    Update for 2020.05

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit e0f5cc8f66c44088cc858ab97e460e7f4d06faf3
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon Jun 1 22:41:56 2020 +0200

    {linux, linux-headers}: bump 4.{4, 9, 14, 19}.x / 5.{4, 6}.x series

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 050abf7677a015bbb0b382d79b4a64aff02f7df6
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Mon Jun 1 11:54:32 2020 +0200

    package/wampcc fix build with musl 1.2.0

    Fixes:
     - http://autobuild.buildroot.org/results/da996e189220499b85efbdb541a891ac18db38c6

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 9740b9bcdd9167195498393098e89915ee564691
Author: Matt Weber <matthew.weber@rockwellcollins.com>
Date:   Mon Jun 1 07:30:36 2020 -0500

    DEVELOPERS: cleanup rockwellcollins.com maintainers

    Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 8f3d361f5ccbb43270f9e69bf6ac472698d3722e
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sun May 31 10:49:02 2020 +0200

    package/glib-networking: security bump to version 2.62.4

    - Fix CVE-2020-13645: In GNOME glib-networking through 2.64.2, the
      implementation of GTlsClientConnection skips hostname verification of
      the server's TLS certificate if the application fails to specify the
      expected server identity. This is in contrast to its intended
      documented behavior, to fail the certificate verification.
      Applications that fail to provide the server identity, including Balsa
      before 2.5.11 and 2.6.x before 2.6.1, accept a TLS certificate if the
      certificate is valid for any host.
    - Update indentation in hash file (two spaces)

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    [Peter: bump to 2.62.4 rather than 2.64.3]
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 3a9261ddd917007e19b56b4bfe48ccc0861dd716
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sun May 31 16:16:23 2020 +0200

    package/libusb-compat: set LIBUSB_1_0_SONAME

    LIBUSB_1_0_SONAME is detected since version 0.1.6 and
    https://github.com/libusb/libusb-compat-0.1/commit/b6f5a2fe12ca19d658d7180e106254b31cf1f8f5

    The detection mechanism is based on sed, here are the more relevant
    parts:

     shrext_regexp=`echo "$shrext_cmds" | sed 's/\./\\\\./'`
    [...]
     [AS_VAR_SET([ac_Lib_SONAME], [`ldd conftest$ac_exeext | grep 'lib[$2]'$shrext_regexp | sed 's/^@<:@ \t@:>@*lib[$2]'$shrext_regexp'/lib[$2]'$shrext_regexp'/;s/@<:@ \t@:>@.*$//'`])])

    However, this mechanism is broken with sed 4.7 and will return the
    following 'silent' error:

    checking for SONAME of libusb-1.0... sed: -e expression #1, char 40: Invalid back reference
    unknown

    Moreover, it also raises the following build failure on one of the
    autobuilder because an empty line is added to LIBUSB_1_0_SONAME:

    checking for SONAME of libusb-1.0... checking
    libusb-1.0.so.0
    checking for GNU extensions of errno.h... no
    configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline
    checking that generated files are newer than configure... done
    configure: creating ./config.status
    config.status: creating libusb.pc
    config.status: creating libusb-config
    config.status: creating Makefile
    config.status: creating libusb/Makefile
    config.status: creating examples/Makefile
    config.status: creating config.h
    config.status: executing depfiles commands
    config.status: executing libtool commands
    config.status: executing default commands
    configure: WARNING: unrecognized options: --disable-gtk-doc, --disable-gtk-doc-html, --disable-doc, --disable-docs, --disable-documentation, --with-xmlto, --with-fop, --enable-ipv6, --disable-nls
    configure: WARNING: cache variable au_cv_lib_soname_LIBUSB_1_0 contains a newline
    [7m>>> libusb-compat 0.1.7 Building[27m
    PATH="/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/bin:/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/host/sbin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1/usr/local/bin:/accts/mlweber1/bin:/accts/mlweber1/libexec/git-core:/accts/mlweber1/usr/bin:/accts/mlweber1
     /usr/local/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin"  /usr/bin/make -j8  -C /usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7/
    make[1]: Entering directory `/usr/lfs/hdd_v1/rc-buildroot-test/scripts/instance-0/output-1/build/libusb-compat-0.1.7'
    Makefile:284: *** missing separator.  Stop.

    We could patch patch m4/au_check_lib_soname.m4 to fix the mechanism
    however this is difficult without reproducing the autobuilder failure
    and upstream seems dead so just set LIBUSB_1_0_SONAME

    Fixes:
     - http://autobuild.buildroot.org/results/12d771d85d30594929cfe3e1c783fc70857e7f5f

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    [yann.morin.1998@free.fr: extract the actual SONAME from the library]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit d25a5724c02a79049b9cf17a24c5f5c0ff010b2a
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Wed May 13 19:48:09 2020 +0200

    package/linux-headers: add support for CIP kernel versions with same-as-kernel

    When the linux-headers are configured to use the same source as the
    kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured
    to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION
    or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the
    kernel sources are not already downloaded:

        $ cat defconfig
        BR2_LINUX_KERNEL=y
        BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y
        $ make defconfig BR2_DEFCONFIG=$pwd)/defconfig
        $ make linux-headers-source

        >>> linux-headers 4.19.118-cip25 Downloading
        --2020-05-13 19:28:44--  https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz
        Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176
        Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected.
        HTTP request sent, awaiting response... 404 Not Found
        2020-05-13 19:28:45 ERROR 404: Not Found.

        make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1
        make: *** [Makefile:23: _all] Error 2

    We fix that by adding yet another duplication of information out of
    the linux.mk, to use the CIP-specific git tree where to get the
    archives as snapshots.

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 40e0bf4c0c36970f8e94591fdb0a5a8910bf9859
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Tue May 12 22:33:53 2020 +0200

    linux: forcibly disable use of gcc plugins

    The soon-to-be-released linux 5.7 has changed the way it detects the
    ability of gcc to use plugins, when it dropped support for gcc 4.7 or
    older [0].

    To detect the ability to use gcc plugins, the kernel has to check
    whether the host gcc is capable enough to build them.

    When we call one of the configurator for the Linux kernel, we explicitly
    pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
    discrepancy between the ncurses headers and libraries as found by the
    Linux kconfig build [1] [2].

    But then, when we build the kernel, we pass another value to use [3]
    HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
    roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
    This is needed so that at build time, the kernel can build host tools
    that link with our openssl et al.

    So, the two HOSTCC we pass to the kernel may have different behaviours.
    For example, on a machine where gmp is missing in the system, it is
    available in $(O)/host/ when using an internal toolchain (and under a
    few other conditions).

    In that case, when configuring the kernel, it decides that the host
    compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
    are not met, and that option is not present in the linux' .config file
    (neither as "=y" nor as "is not set"). But then, when we build the
    kernel, the host compiler suddenly becomes capable of building the
    plugins, and the internal syncconfig run by the kernel will notice that
    the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
    shall decide on its value. And this blocks a build on an interactive
    console (abbreviated):

        * Restart config...
        * GCC plugins
        GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _

    But most problematic is the behaviour when run in a shell that is not
    interactiove (e.g. a CI job or such) (abbreviated):

        * Restart config...
        * GCC plugins
        GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
        Error in reading or end of file.
          Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
        Error in reading or end of file.
          Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
        Error in reading or end of file.
        * Memory initialization
        Initialize kernel stack variables at function entry
        > 1. no automatic initialization (weakest) (INIT_STACK_NONE)
          2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
          3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
          4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
        choice[1-4?]:
        Error in reading or end of file.
        Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
        Error in reading or end of file.
        Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
        Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n

    The most obvious and simple solution would be to unconditionally disable
    gcc plugins altogether, in the KCONFIG_FIXUP hook. But that can't work
    either, because after applying the fixups, we call olddefconfig (or the
    likes) with the incapable HOSTCC, so the disabled option would be removed
    anyway, and we'd be back to square one.

    So, in addition to the above, we also forcibly hack the same call just
    before actually building the kernel.

    Note that the two are needed: the one in the fixups is needed for those
    that have a system that already allows building gcc plugins, and the
    second is needed in the other case, where the system does not allow it
    but would work with our additional headers and libs in $(O)/host/. The
    two ensure there is a very similar experience in the two situations.

    Forcibly disabling the use of gcc plugins is not a regression on our
    side: it has never been possible to do so so far. We're now making sure
    that can't work by accident.

    Reported-by: Ganesh <ganesh45in@gmail.com>,
    Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Cc: Michael Walle <michael.walle@kontron.com>
    Cc: Peter Korsgaard <peter@korsgaard.com>
    Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Cc: Arnout Vandecappelle <arnout@mind.be>
    Tested-by: Heiko Thiery <heiko.thiery@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit f9548114d861289e7490594a704fff32f65559b3
Author: Romain Naour <romain.naour@gmail.com>
Date:   Sun May 24 17:58:18 2020 +0200

    package/qt5/qt5webengine: don't link with libstdc++.a on the host

    While cross-compiling, qt5webengine is building a host tool, 'gn', and
    by default wants to link it statically with libstdc++, when the tool is
    otherwise dynamically linked with other libraries:

        $ ldd 3rdparty/gn/out/Release/gn
            linux-vdso.so.1 (0x00007ffc1c999000)
            libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48a3c06000)
            libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48a3be4000)
            libc.so.6 => /lib64/libc.so.6 (0x00007f48a3a1b000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f48a3c53000)

    Not all ditributions have the static libraries installed by default; for
    example, on Fedora, libstdc++-static is not installed on a fresh system,
    leading to build issues:

      [185/185] LINK gn
      FAILED: gn
      /usr/bin/g++ -O3 -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-strip-all -Wl,--as-needed -static-libstdc++ -pthread -o gn -Wl,--start-group tools/gn/gn_main.o base.a gn_lib.a -Wl,--end-group -ldl
      /usr/bin/ld : unable to find -lstdc++
      [...]
      Project ERROR: GN build error!

    The root cause is the addition in [0] of a command line option to the
    build of gn, that requests static linking with libstdc++ by default.

    Explicitly pass that option now, to avoid static linking with libstdc++
    and get a fully dynamicallty linked executable:

        $ ldd 3rdparty/gn/out/Release/gn
            linux-vdso.so.1 (0x00007ffd3f160000)
            libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f68138e7000)
            libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f68138c5000)
            libc.so.6 => /lib64/libc.so.6 (0x00007f68136fc000)
            libm.so.6 => /lib64/libm.so.6 (0x00007f68135b6000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f6813b13000)
            libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f681359c000)

    [0] https://github.com/qt/qtwebengine-chromium/commit/cfab9198a9917f42cf08b1caf84ab9b71aac1911#diff-905c8f054808213577c0a92d1b704615

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: Gaël Portay <gael.portay@collabora.com>
    [yann.morin.1998@free.fr:
      - rewrite the commit log with extra details and explanations
    ]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 58ecbbc3ef18c43ae1c02a5c4bf30aa7ef2d8092
Author: Romain Naour <romain.naour@gmail.com>
Date:   Thu May 21 18:53:45 2020 +0200

    package/gcc/9.3.0: fix host-gcc-final when ccache is used

    As reported by several Buildroot users [1][2][3], the gcc build
    may fail while running selftests makefile target.

    The problem only occurs when ccache is used with gcc 9 and 10,
    probably due to a race condition.

    While debuging with "make -p" we can notice that s-selftest-c target
    contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

      s-selftest-c: cc1

    While the build is failing, the s-selftest-c dependencies recipe is
    still running and reported as a bug by make.

      "Dependencies recipe running (THIS IS A BUG)."

    A change [5] in gcc 9 seems to introduce the problem since we can't
    reproduce this problem with gcc 8.

    As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
    including language makefile fragments.

    With the fix applied, the s-seltest-c dependency contains
    SELFTEST_DEPS value.

      s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

    [1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
    [2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
    [3] https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108
    [4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
    [5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
    [6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
    Cc: Maxim Kochetkov <fido_max@inbox.ru>
    Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Cc: Yann E. MORIN <yann.morin.1998@free.fr>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 1a14a838eaa88ae683bf8c0cb0ae6cc7e1d10d49
Author: Heiko Thiery <heiko.thiery@gmail.com>
Date:   Wed May 27 09:11:13 2020 +0200

    package/sysrepo: fix SysV init script

    The current script (S51sysrepo-plugind) is not able to stop the daemon.

    Possible options to fix the problem:

    A) By adding the "-m -p $PIDFILE" option to start the pid file will be
       created but it will not contain the correct PID used by the daemon.
       This is obviously because the daemon forks.
    B) By not starting the daemon in background (sysrepo-plugind -d) and
       let do it by start-stop-daemon with "-b" option. But then the log
       messages of the daemon will not longer ends in the syslog but to stderr.
    C) Start the daemon without a pidfile and stop the daemon with the
       "-x" option.

    The only valid option is C to fix that.

    Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
    [yann.morin.1998@free.fr: introduce EXECUTABLE]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit ae417368f52518735dfce6c83d8e064298e6d0dd
Author: Carlos Santos <unixmania@gmail.com>
Date:   Fri May 29 17:32:04 2020 -0300

    DEVELOPERS: remove Carlos Santos

    Goodbye!

    Signed-off-by: Carlos Santos <unixmania@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 0caabc8cda933b32660867b270151451f77b6e14
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sat May 30 14:25:32 2020 +0200

    package/xen: security bump to version 4.13.1

    - Fix CVE-2020-11739: An issue was discovered in Xen through 4.13.x,
    allowing guest OS users to cause a denial of service or possibly gain
    privileges because of missing memory barriers in read-write unlock
    paths. The read-write unlock paths don't contain a memory barrier. On
    Arm, this means a processor is allowed to re-order the memory access
    with the preceding ones. In other words, the unlock may be seen by
    another processor before all the memory accesses within the "critical"
    section. As a consequence, it may be possible to have a writer executing
    a critical section at the same time as readers or another writer. In
    other words, many of the assumptions (e.g., a variable cannot be
    modified after a check) in the critical sections are not safe anymore.
    The read-write locks are used in hypercalls (such as grant-table ones),
    so a malicious guest could exploit the race. For instance, there is a
    small window where Xen can leak memory if XENMAPSPACE_grant_table is
    used concurrently. A malicious guest may be able to leak memory, or
    cause a hypervisor crash resulting in a Denial of Service (DoS).
    Information leak and privilege escalation cannot be excluded.

    - Fix CVE-2020-11740: An issue was discovered in xenoprof in Xen through
    4.13.x, allowing guest OS users (without active profiling) to obtain
    sensitive information about other guests. Unprivileged guests can
    request to map xenoprof buffers, even if profiling has not been enabled
    for those guests. These buffers were not scrubbed.

    - Fix CVE-2020-11741: An issue was discovered in xenoprof in Xen through
    4.13.x, allowing guest OS users (with active profiling) to obtain
    sensitive information about other guests, cause a denial of service, or
    possibly gain privileges. For guests for which "active" profiling was
    enabled by the administrator, the xenoprof code uses the standard Xen
    shared ring structure. Unfortunately, this code did not treat the guest
    as a potential adversary: it trusts the guest not to modify buffer size
    information or modify head / tail pointers in unexpected ways. This can
    crash the host (DoS). Privilege escalation cannot be ruled out.

    - Fix CVE-2020-11742: An issue was discovered in Xen through 4.13.x,
    allowing guest OS users to cause a denial of service because of bad
    continuation handling in GNTTABOP_copy. Grant table operations are
    expected to return 0 for success, and a negative number for errors. The
    fix for CVE-2017-12135 introduced a path through grant copy handling
    where success may be returned to the caller without any action taken. In
    particular, the status fields of individual operations are left
    uninitialised, and may result in errant behaviour in the caller of
    GNTTABOP_copy. A buggy or malicious guest can construct its grant table
    in such a way that, when a backend domain tries to copy a grant, it hits
    the incorrect exit path. This returns success to the caller without
    doing anything, which may cause crashes or other incorrect behaviour.

    - Fix CVE-2020-11743: An issue was discovered in Xen through 4.13.x,
    allowing guest OS users to cause a denial of service because of a bad
    error path in GNTTABOP_map_grant. Grant table operations are expected to
    return 0 for success, and a negative number for errors. Some misplaced
    brackets cause one error path to return 1 instead of a negative value.
    The grant table code in Linux treats this condition as success, and
    proceeds with incorrectly initialised state. A buggy or malicious guest
    can construct its grant table in such a way that, when a backend domain
    tries to map a grant, it hits the incorrect error path. This will crash
    a Linux based dom0 or backend domain.

    https://xenproject.org/downloads/xen-project-archives/xen-project-4-13-series/xen-project-4-13-1

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 9b91147545ab24c7fd23f9b052d95f0813f22d1c
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sat May 30 11:51:15 2020 +0200

    package/mp4v2: fix build with gcc <= 5

    Fixes:
     - http://autobuild.buildroot.org/results/14937c96a82fb3d10e5d83bd7b2905b846fb09f9

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    [yann.morin.1998@free.fr: expand the patch' commit log]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 36c0a0c65647bebe1050a2f9a7005fb44c24cf56
Author: Romain Naour <romain.naour@gmail.com>
Date:   Sat May 30 19:07:05 2020 +0200

    boot/arm-trusted-firmware: ignore licencing check for user defined official version

    The commit [1] "licensing info is only valid for v1.4" fixed the legal-info
    issues when a custom ATF tarball or a version from git is used.
    But we need to ignore licencing for a used defined official ATF version.

    Althougt the ATF version are licensed under BSD-3-Clause, the license
    file can be updated between version (for example between v1.4 and v2.0).

    Ignore the licencing check if the user provide a custom official version.

    [1] d1a61703f728340ec894c367398d2a3a394a3360

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: Yann E. MORIN <yann.morin.1998@free.fr>
    [yann.morin.1998@free.fr: use positive logic with the _LATEST option]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 3bfe849189881d4872b5949739f91b1ed01b6622
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Wed May 27 17:47:34 2020 +0200

    package/{fmc,fmlib}: change repository location

    Now that Freescale has been wholly swallowed into NXP, the public-facing
    git repositories that were hosting those two packages are no longer
    available.

    Fortunately, they had been mirrored on Code Aurora forge (a Linux
    Foundation project, so relatively stable and trustworthy), which has the
    tags we need, and that generates the exact same archives.

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
    Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit e118415151052365c5967687bce152a2c971ef7e
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Fri May 29 22:45:33 2020 +0200

    Update for 2020.05-rc3

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 0a860f21e1b8004ee937c20d54d29a5e66f96651
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Fri May 15 23:13:27 2020 +0200

    package/mp4v2: security bump to version 4.1.3

    - Switch site to an active fork
    - Send patch upstream
    - Update indentation in hash file (two spaces)
    - Fix the following CVEs:
      - CVE-2018-14054: A double free exists in the MP4StringProperty class
        in mp4property.cpp in MP4v2 2.0.0. A dangling pointer is freed again
        in the destructor once an exception is triggered.
        Fixed by
        https://github.com/TechSmith/mp4v2/commit/f09cceeee5bd7f783fd31f10e8b3c440ccf4c743
      - CVE-2018-14325: In MP4v2 2.0.0, there is an integer underflow (with
        resultant memory corruption) when parsing MP4Atom in mp4atom.cpp.
        Fixed by
        https://github.com/TechSmith/mp4v2/commit/e475013c6ef78093055a02b0d035eda0f9f01451
      - CVE-2018-14326: In MP4v2 2.0.0, there is an integer overflow (with
        resultant memory corruption) when resizing MP4Array for the ftyp
        atom in mp4array.h.
        Fixed by
        https://github.com/TechSmith/mp4v2/commit/70d823ccd8e2d7d0ed9e62fb7e8983d21e6acbeb
      - CVE-2018-14379: MP4Atom::factory in mp4atom.cpp in MP4v2 2.0.0
        incorrectly uses the MP4ItemAtom data type in a certain case where
        MP4DataAtom is required, which allows remote attackers to cause a
        denial of service (memory corruption) or possibly have unspecified
        other impact via a crafted MP4 file, because access to the data
        structure has different expectations about layout as a result of
        this type confusion.
        Fixed by
        https://github.com/TechSmith/mp4v2/commit/73f38b4296aeb38617fa3923018bb78671c3b833
      - CVE-2018-14403: MP4NameFirstMatches in mp4util.cpp in MP4v2 2.0.0
        mishandles substrings of atom names, leading to use of an
        inappropriate data type for associated atoms. The resulting type
        confusion can cause out-of-bounds memory access.
        Fixed by
        https://github.com/TechSmith/mp4v2/commit/51cb6b36f6c8edf9f195d5858eac9ba18b334a16

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit e1af92592ec591270ef7f86a56562d119f2a46e1
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sat May 2 21:54:38 2020 +0200

    package/matio: add upstream security fixes

    Fix the following CVEs:
     - CVE-2019-17533: Mat_VarReadNextInfo4 in mat4.c in MATIO 1.5.17 omits
       a certain '\0' character, leading to a heap-based buffer over-read in
       strdup_vprintf when uninitialized memory is accessed.
     - CVE-2019-20017: A stack-based buffer over-read was discovered in
       Mat_VarReadNextInfo5 in mat5.c in matio 1.5.17.
     - CVE-2019-20018: A stack-based buffer over-read was discovered in
       ReadNextCell in mat5.c in matio 1.5.17.
     - CVE-2019-20020: A stack-based buffer over-read was discovered in
       ReadNextStructField in mat5.c in matio 1.5.17.
     - CVE-2019-20052: A memory leak was discovered in Mat_VarCalloc in
       mat.c in matio 1.5.17 because SafeMulDims does not consider the
       rank==0 case.

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 75e82c42c6a4612c7385a32dcb82ca9cb5d866bd
Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Tue May 26 23:27:54 2020 +0200

    package/gnupg: fix build with gcc 10

    This commit backports an upstream patch made for gnupg2 into gnupg, in
    order to fix build failures with gcc 10 due to the use of
    -fno-common. Due to the code differences between upstream gnupg2 and
    the old gnupg 1.x, the backport is in fact more a rewrite than an
    actual backport.

    Fixes:

      http://autobuild.buildroot.net/results/496a18833505dc589f7ae58f2c7e5fe80fe9af79/

    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit a96277a93d36a1828de87b011022ae389a549cbd
Author: Romain Naour <romain.naour@gmail.com>
Date:   Tue May 26 23:04:43 2020 +0200

    package/qt5/qt5declarative: fix parallel install

    Installing qt5declarative examples on fast/fast/multicore machines sometimes
    failes with a variation of the following error messages:

     - Cannot touch [...]/chapter5-listproperties/app.qml: No such file or directory
     - Error copying [...]/chapter2-methods/app.qml: Destination file exists

    Fix it by using OTHER_FILES instead of a seperate qml files install target
    to fix the race between install_target, install_qml and install_sources.

    Fixes:

     - https://gitlab.com/buildroot.org/buildroot/-/jobs/565470221

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    [Reworked patch and commit log]
    Signed-off-by: Peter Seiderer <ps.report@gmx.net>
    Reviewed-by: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit fa96dfa6288652fedf650b1f6e39b4b1de0ef51b
Author: Heiko Thiery <heiko.thiery@gmail.com>
Date:   Mon May 18 08:43:21 2020 +0200

    package/efl: fix -fno-common build failure

    Added upstream patch for fixing build failure when using GCC10 as a host
    compiler (-fno-common is now default).

    Fixes:
    http://autobuild.buildroot.net/results/47f/47fcf9bceba029accdcf159236addea3cb03f12f/

    Cc: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
    Reviewed-by: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 73f4ad304f8a654dd3359e73f33ed463389218fa
Author: Heiko Thiery <heiko.thiery@gmail.com>
Date:   Sun May 17 23:34:26 2020 +0200

    package/erlang: fix -fno-common build failure

    Added upstream patch for fixing build failure when using GCC10 as a host
    compiler (-fno-common is now default).

    Cc: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit bec3cab8344072eed2b2ed1050f724e0325eb945
Author: Yegor Yefremov <yegorslists@googlemail.com>
Date:   Wed May 27 11:49:11 2020 +0200

    linux: fix COPYING file hash

    In version 5.6 a minor change was made to this file, stating tht "[a]ll
    contributions to the Linux Kernel are subject to this COPYING file",
    and hence the hash changed.

    We can update the hash, because the licensing information is only
    accounted for the "latest" version, so the hash change will not impact
    older kernel versions as the user would have to switch to a non-latest
    kernel.

    Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit f9666a9892c01510a0fa59dd4449e41253805809
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sat May 23 21:21:55 2020 +0200

    package/gerbera: fix static linking with libmagic

    This patch was wrongly removed when bumping the version to 1.4.0 in
    commit 6976f312fa84d4a9c4bbf99ed3b173085780dcd9

    Fixes:
     - http://autobuild.buildroot.org/results/7a53a59dd08c043f371bea967c3b450a7bddcde8

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 7d804aba66fbed7df6cf0caa845b6c52f7ff1f7e
Author: Fabio Estevam <festevam@gmail.com>
Date:   Tue May 26 18:01:19 2020 -0300

    board/freescale: increase the vfat size

    The default iamge size is 32MiB, which is quite low by today's standards.
    Besides, the AArch64 kernels are relatively big, which leaves not much
    room, if at all, for users to experiment on the default image.

    Increase the vfat size to a more reasonable 64MiB.

    Note that users who derive an in-tree defconfig for their own case will
    allways hit any arbitarary size we put here, so they will anyway have to
    also derive this template for their own use-cases.

    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 10454598a0c14054e4d52fafacdff5864db76cef
Author: Romain Naour <romain.naour@gmail.com>
Date:   Mon May 11 23:47:43 2020 +0200

    package/uboot-tools: tools/env/fw_env.h: remove env.h

    As reported by Nicolas Carrier on the Buildroot mailing list [1],
    there is a new build issue while building a program which interacts with
    the u-boot environment. This program uses the headers of the ubootenv
    library provided by uboot-tools.

    This is an upstream change from uboot [2] adding "#include <env.h>" to
    fw_env.h. Adding env.h require a board configuration to build.

    But only fw_env.h header is installed in the staging directory by
    uboot-tools package, but since it now include env.h the build is broken
    because env.h is missing from the staging directory.

    It's seems an upstream bug since env_set() is not used in fw_env tool.
    Nicolas removed env.h from fw_env tool and fixed it's build issue.

    This problem is present since uboot v2019.10, so the uboot version
    present in Buildroot 2020.02 is affected.

    It's probably not a problem for upstream uboot but it's a problem
    for uboot-tools package that build uboot tools without a board
    configuration for the target.

    [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280307.html
    [2] https://gitlab.denx.de/u-boot/u-boot/-/commit/9fb625ce05539fe6876a59ce1dcadb76b33c6f6e

    Reported-by: Nicolas Carrier <nicolas.carrier@orolia.com>
    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    [yann.morin.1998@free.fr: add URL to upstream commit]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit e7323e9d54ee9fc8a0c4af5f4198ac6024cc6b53
Author: Heiko Thiery <heiko.thiery@gmail.com>
Date:   Mon May 18 07:43:32 2020 +0200

    package/audit: fix -fno-common build failure

    Added upstream patch for fixing build failure when using GCC10 as a host
    compiler (-fno-common is now default).

    Fixes:
    http://autobuild.buildroot.net/results/c4b/c4bba80e9fc476247c7ba28850831c6a8edd559f/build-end.log

    Cc: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
    Reviewed-by: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit a26d6338fb47765de6e20fdead044ed6e69cc7ae
Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Mon May 18 07:22:02 2020 +0200

    package/leveldb: fix detection of the snappy library

    Pull a patch pending in an upstream pull request to fix the detection
    of the snappy library when we are in static linking configurations.

    Fixes:

      https://bugs.busybox.net/show_bug.cgi?id=12671

    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 39ef24f8bbe44d7850179f10fe0ab7e08e06059d
Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Mon May 18 07:22:01 2020 +0200

    package/leveldb: turn snappy into an optional dependency

    snappy is not a mandatory dependency to build leveldb. Back when it
    was introduced in Buildroot, as of version 1.18, the build logic
    already made snappy an optional dependency.

    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 00c1a8c34f7340c2db6eee82cd8d3f5e6ea62577
Author: James Hilliard <james.hilliard1@gmail.com>
Date:   Tue May 26 14:24:37 2020 -0600

    package/mesa3d: propagate missing libdrm-freedreno deps

    Libdrm freedreno depends on BR2_arm || BR2_aarch64 || BR2_aarch64_be
    as such we need to propagate those dependencies to mesa's gallium
    freedreno driver.

    Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit fa84c176c2148a60103e850204180f86aa5baa73
Author: James Hilliard <james.hilliard1@gmail.com>
Date:   Sun May 24 20:50:53 2020 -0600

    package/prosody: use correct bit32 package

    According to https://prosody.im/doc/depends#bitop the correct bitop
    package to use with prosody for Lua 5.1 is:
    https://luarocks.org/modules/siffiejoe/bit32

    As such replace BR2_PACKAGE_LUABITOP with BR2_PACKAGE_LUA_BIT32

    Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 1e6e67a82569093a9f2c59a3a94e874bba93fea6
Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Tue May 26 21:53:15 2020 +0200

    docs/website/sponsors.html: show 2020 sponsors

    So far in 2020, Logilin and Tap2Open made some financial donations to
    the Buildroot Association, so let's thank them on our sponsors page.

    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit b6aaed0cee95e61fc7714215199b6e344ba8c409
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Tue May 26 07:34:12 2020 +0200

    package/lrzip: fix hash

    Hash was not updated by commit 18079e20a712c4a7d539ead52b0a0c725ec7f7e2

    Fixes:
     - http://autobuild.buildroot.org/results/0f7179ed4706f05551af330d7f12b3efaeffd278

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 8a12ddaa295ee4919bf294900b96362ee8cb4f78
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon May 25 18:26:31 2020 +0200

    {linux, linux-headers}: bump 4.{4, 9, 14, 19}.x / 5.{4, 6}.x series

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 9ff7b6170561dde1ea01f94cf765abe73140029b
Author: Heiko Thiery <heiko.thiery@gmail.com>
Date:   Sun May 24 23:28:29 2020 +0200

    package/pkg-generic.mk: enable hash checks for svn tarbals

    With commit 89f5e989323ace815a32fced27eaefee2f4666de support for
    reproducible archives was added. Thus archives generated from svn do no
    longer needs to be added to BR_NO_CHECK_HASH_FOR.

    Cc: Yann E. MORIN <yann.morin.1998@free.fr>
    Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 18079e20a712c4a7d539ead52b0a0c725ec7f7e2
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sat May 23 10:36:23 2020 +0200

    package/lrzip: bump to 7f3bf46203bf45ea115d8bd9f310ea219be88af4

    This bump contains only one commit that fix a build failure with asm:
    https://github.com/ckolivas/lrzip/commit/844b8c057c8c7372ca41ad2efdbf849f45c24506

    Fixes:
     - http://autobuild.buildroot.org/results/800d8a97966ef75dbf20e85ec8a02766ba02cc76

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 58af9a70cc0f195116dedb3fd0e2ca5b4fec9e70
Author: Romain Naour <romain.naour@gmail.com>
Date:   Sat May 23 01:22:12 2020 +0200

    package/qemu: remove csky fork

    We have a qemu fork for csky cpus [1] but since qemu version
    bump to 4.2.0 [2] and libssh2/libssh change the csky build is
    broken.

    The csky fork is based on Qemu 3.0.0 but unlike autotools packages
    any unknown option is handled as error.

    Since we don't want to support all options from previous qemu
    release and the github repository has been removed [3] and the
    only remaining archive is located on http://sources.buildroot.net,
    remove the qemu csky fork as suggested by [4].

    [1] https://git.buildroot.net/buildroot/commit/?id=f816e5b276f1ef15840bec6667f1e8219717ab7d
    [2] https://git.buildroot.net/buildroot/commit/?id=0ea17054ce7dfc54efca5634133cef786445e7b1
    [3] https://github.com/c-sky/qemu
    [4] http://lists.busybox.net/pipermail/buildroot/2020-May/281885.html

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: Guo Ren <ren_guo@c-sky.com>
    Cc: Peter Korsgaard <peter@korsgaard.com>
    [Peter: move patches out of 4.2.0 subdir]
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 90dd7803914ec2d817e39b20bc88f09b0f04f54f
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Sun May 24 22:26:51 2020 +0200

    package/wiringpi: remove

    The author has completely ripped off the git tree, so the sources
    are no longer available, with that message:
        "Please look for alternatives for wiringPi"

    And indeed there is a better alternative, using the kernel GPIO
    subsystem and drivers.

    Note that queezelite looses that functionality now, but upstream
    squeezelite has done changes to do without wiringpi (hint for an
    upgrade?).

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Cc: Peter Seiderer <ps.report@gmx.net>
    Cc: Hiroshi Kawashima <kei-k@ca2.so-net.ne.jp>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 97551eb176cd75419e3520ea94f184e3220980cd
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Sun May 24 10:58:00 2020 +0200

    package/speexdsp+tremor: switch to new git repository

    The original git server on git.xiph.org died, and the Xiph project has
    now moved on to host their repositories on gitlab.comn instead.

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit fb57a54cf8d56fb9a32a3d632346c58eb58177b4
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Sun May 24 10:57:21 2020 +0200

    package: don't use BR2_KERNEL_MIRROR for git downloads

    The git repositories are not served on the kernel.org CDN:

        fatal: repository 'https://cdn.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/' not found

    Switch to explicitly use the git.kernel.org server.

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Cc: Matt Weber <matthew.weber@rockwellcollins.com>
    Cc: Cyril Bur <cyrilbur@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit c5e932613eaed02d983af1889d2280f493b1a20e
Author: Bernd Kuhls <bernd.kuhls@t-online.de>
Date:   Fri May 22 22:37:36 2020 +0200

    package/ffmpeg: bump version to 4.2.3

    Removed patch included in upstream release, reformatted hashes.

    Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 39bfd504102dce2166e9d9e1377744debde64b38
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Fri May 22 22:10:41 2020 +0200

    package/wireshark: security bump to version 3.2.4

    Fix CVE-2020-13164: In Wireshark 3.2.0 to 3.2.3, 3.0.0 to 3.0.10, and
    2.6.0 to 2.6.16, the NFS dissector could crash. This was addressed in
    epan/dissectors/packet-nfs.c by preventing excessive recursion, such as
    for a cycle in the directory graph on a filesystem.

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 2e0beffb74efd6a0a1bd4fd1e631b5a757d7c61b
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sat May 23 19:20:36 2020 +0200

    package/fio: fix build on sh4

    Fixes:
     - http://autobuild.buildroot.org/results/6dc82572ae1369aa5c9954b6e61777766c5aa3b4

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit de2b78143c4316c6a6a07d44d74298d307609dd2
Author: Joachim Nilsson <troglobit@gmail.com>
Date:   Sat May 23 16:05:03 2020 +0200

    docs/manual: new chapter on release engineering

    Describe release engineering and development phases of the project.

    Signed-off-by: Joachim Nilsson <troglobit@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 982728364141c4369003b1dbdc24e51428be6b39
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Sun May 24 22:39:25 2020 +0200

    package/ltrace: directly use s.b.o to fetch the archive

    During the migration from alioth to gitlab, the git repository for ltrace
    was not migrated. There is a repository on gitlab.com, owned by the debian
    maintainer, but that repository does not contain the sha1 we know of:
        https://gitlab.com/cespedes/ltrace

    s.b.o. is the only known location so far to host the archive, so switch
    to it.

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
    Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    Cc: Peter Korsgaard <peter@korsgaard.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 89a5d2162762490727c515692baa1257ba73179e
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Mon May 25 08:15:28 2020 +0200

    package/bind: security bump to version 9.11.19

    Fixes the following security issues:

    - (9.11.18) DNS rebinding protection was ineffective when BIND 9 is
      configured as a forwarding DNS server.  Found and responsibly reported by
      Tobias Klein.  [GL #1574]

    - (9.11.19) To prevent exhaustion of server resources by a maliciously
      configured domain, the number of recursive queries that can be triggered
      by a request before aborting recursion has been further limited.  Root and
      top-level domain servers are no longer exempt from the
      max-recursion-queries limit.  Fetches for missing name server address
      records are limited to 4 for any domain.  This issue was disclosed in
      CVE-2020-8616.  [GL #1388]

    - (9.11.19) Replaying a TSIG BADTIME response as a request could trigger an
      assertion failure.  This was disclosed in CVE-2020-8617.  [GL #1703]

    Also update the COPYRIGHT hash for a change of copyright year and adjust the
    spacing for the new agreements.

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 26c32d933eb4d841b7fbe9c1e0b61cef89665b15
Author: Jérémy Rosen <jeremy.rosen@smile.fr>
Date:   Fri May 22 18:59:29 2020 +0200

    packages/systemd: fix double getty on console

    When selecting "console" for the automatic getty, the buildroot logic
    would collide with systemd's internal console detection logic, resulting
    in two getty being started on the console.

    This commit fixes that by doing nothing when "console" is selected and
    letting systemd-getty-generator deal with starting the proper getty.

    Note that if something other than the console is selected
    * Things will work properly, even if the selected terminal is also the
      console
    * A getty will still be started on the console.
      This is what systemd has been doing on buildroot since the beginning. it
      could be disabled but I left it for backward compatibility

    Fixes: #12361
    Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 03fbb81b8bab7bad135b59267533be7688babe39
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Fri May 22 15:58:08 2020 +0200

    package/dovecot: security bump to version 2.3.10.1

    - Fix CVE-2020-10957: In Dovecot before 2.3.10.1, unauthenticated
      sending of malformed parameters to a NOOP command causes a NULL
      Pointer Dereference and crash in submission-login, submission, or
      lmtp.
    - Fix CVE-2020-10958: In Dovecot before 2.3.10.1, a crafted SMTP/LMTP
      message triggers an unauthenticated use-after-free bug in
      submission-login, submission, or lmtp, and can lead to a crash under
      circumstances involving many newlines after a command.
    - Fix CVE-2020-10967: In Dovecot before 2.3.10.1, remote
      unauthenticated attackers can crash the lmtp or submission process by
      sending mail with an empty localpart.
    - Drop first patch (already in version) and so autoreconf
    - Update indentation in hash file (two spaces)

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 6d7df70016d51c4813c77095705cf8a0e3e1c09e
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Fri May 22 15:58:07 2020 +0200

    package/dovecot: drop first patch

    First patch is not needed since version 2.3.0 and
    https://github.com/dovecot/core/commit/08259c1f206026ca9b9f4b4e97603943c6093def

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 796cc10fa0b7986cfe818df8743fe0ca1f87db98
Author: Stefan Ott <stefan@ott.net>
Date:   Fri May 22 03:40:26 2020 +0200

    package/unbound: bump version to 1.10.1 for security fixes

    Fixes the following security vulnerabilities:

    CVE-2020-12662: Unbound can be tricked into amplifying an incoming query
      into a large number of queries directed to a target.

    CVE-2020-12663: Malformed answers from upstream name servers can be used
      to make Unbound unresponsive.

    Signed-off-by: Stefan Ott <stefan@ott.net>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit 497e3dff7e13d0651b1e9db7b232b13da37f0108
Author: Peter Korsgaard <peter@korsgaard.com>
Date:   Fri May 22 11:53:24 2020 +0200

    Update for 2020.05-rc2

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit cb6eb5db792016751ab01b5dda04536ec65169c3
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Thu May 21 16:39:57 2020 +0200

    package/freerdp: security bump to version 2.1.1

    >From ChangeLog:
    - CVE: GHSL-2020-100 OOB Read in ntlm_read_ChallengeMessage
    - CVE: GHSL-2020-101 OOB Read in security_fips_decrypt due to
      uninitialized value
    - CVE: GHSL-2020-102 OOB Write in crypto_rsa_common
    - Enforce synchronous legacy RDP encryption count (#6156)
    - Fixed some leaks and crashes missed in 2.1.0
    - Removed dynamic channel listener limits
    - Lots of resource cleanup fixes (clang sanitizers)

    https://github.com/FreeRDP/FreeRDP/blob/2.1.1/ChangeLog

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

commit a00db9f80819982348e64834f76048c2c8381f40
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Thu May 21 16:43:40 2020 +0200

    DEVELOPERS: remove python-pycrypto

    Commit 7ef76ed32fcd447391e26d33a555ff5dab6dc48e forgot to remove
    python-pycrypto entry from DEVELOPERS

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit bcc02f5fe53be4021509c9361e69141491d458f3
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Mon May 18 18:15:25 2020 +0200

    package/libpam-tacplus: fix build when time_t is 64 bits

    Fixes:
     - http://autobuild.buildroot.org/results/874433d8cb30d21332f23024081a8b6d7b3254ae

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 19f726b9888f1bc4bb6284f2bcc417f5598c7723
Author: Heiko Thiery <heiko.thiery@gmail.com>
Date:   Tue May 19 08:53:21 2020 +0200

    package/vboot-utils: fix -fno-common build failure

    Added upstream patch for fixing build failure when using GCC10 as a host
    compiler (-fno-common is now default).

    Fixes:
    http://autobuild.buildroot.net/results/aca662d9fd7052f3b361b731cd266edb3b6c41b0
    http://autobuild.buildroot.net/results/6546b284cf306a2fde3c69d67daf9aacffa9e143
    http://autobuild.buildroot.net/results/db20bb3c11a1a9558a5d8021015c6915f99097c8

    Cc: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 7ef76ed32fcd447391e26d33a555ff5dab6dc48e
Author: Romain Naour <romain.naour@gmail.com>
Date:   Mon Apr 27 00:33:23 2020 +0200

    package/python-pycrypto: remove package

    This package doesn't work with Python 3.8 since the code contains
    time.clock() that was deprecated in Python 3.3 and removed in Python 3.8.

    Instead of applying non upstream patches from Fedora [1], python-pycrypto
    was replaced by python-pycryptodomex for crda and optee-os package.
    Now we can remove safely this package.

    [1] http://lists.busybox.net/pipermail/buildroot/2020-April/280683.html

    Fixes:
    https://gitlab.com/buildroot.org/buildroot/-/jobs/498144209

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: James Hilliard <james.hilliard1@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 82b74001752beaee4f87b1c58b8accea6bd53a9d
Author: Romain Naour <romain.naour@gmail.com>
Date:   Mon Apr 27 00:33:22 2020 +0200

    boot/optee-os: replace pycrypto by pycryptodomex

    >From [1] included in optee-os release 3.7.0:
    "PyCryptodome is a fork of PyCrypto, which is not maintained any more
    (the last release dates back to 2013 [2]). It exposes almost the same
    API, but there are a few incompatibilities [3]."

    pem_to_pub_c.py/sign.py scripts still use pycrypto that is replaced
    by pycryptodomex. Add a patch to use pycryptodomex but don't use
    upstream commit since it also switches from the algorithm
    TEE_ALG_RSASSA_PKCS1_V1_5_SHA256 to TEE_ALG_RSASSA_PKCS1_PSS_MGF1_SHA256
    when replacing pycrypto to pycryptodomex [4].

    [1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0
    [2] https://pypi.org/project/pycrypto/#history
    [3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html
    [4] https://github.com/OP-TEE/optee_os/commit/ababd72d2fd76cb2ded8e202b49db28d6545f6eb

    Fixes:
    https://gitlab.com/buildroot.org/buildroot/-/jobs/526035730

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: James Hilliard <james.hilliard1@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 8d05237b6018d5389e4381b38d874f447137f987
Author: Romain Naour <romain.naour@gmail.com>
Date:   Mon Apr 27 00:33:21 2020 +0200

    package/crda: replace pycrypto by pycryptodomex

    >From [1]:
    "PyCryptodome is a fork of PyCrypto, which is not maintained any more
    (the last release dates back to 2013 [2]). It exposes almost the same
    API, but there are a few incompatibilities [3]."

    [1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0
    [2] https://pypi.org/project/pycrypto/#history
    [3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html

    Update the patch 0001-crda-support-python-3-in-utils-key2pub.py.patch
    since it add pycrypto.

    >From [4]
    "CRDA is no longer needed as of kernel v4.15 since commit 007f6c5e6eb45
    ("cfg80211: support loading regulatory database as firmware file") added
    support to use the kernel's firmware request API which looks for the
    firmware on /lib/firmware. Because of this CRDA is legacy software for
    older kernels. It will continue to be maintained."

    [4] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/crda.git/tree/README?id=9856751feaf7b102547cea678a5da6c94252d83d#n8

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: James Hilliard <james.hilliard1@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 3db1e5fbcbde9f78f9cac99614fefc243545094e
Author: Romain Naour <romain.naour@gmail.com>
Date:   Mon Apr 27 00:33:20 2020 +0200

    package/python-pycryptodomex: add host variant

    Adding a host variant will allow to replace host-python-pycrypto by
    host-python-pycryptodomex for the crda and optee-os packages.

    From [1]:
    "PyCryptodome is a fork of PyCrypto, which is not maintained any more
    (the last release dates back to 2013 [2]). It exposes almost the same
    API, but there are a few incompatibilities [3]."

    [1] https://github.com/OP-TEE/optee_os/commit/90ad2450436fdd9fc0d28a3f92f3fbcfd89a38f0
    [2] https://pypi.org/project/pycrypto/#history
    [3] https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html

    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Cc: James Hilliard <james.hilliard1@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 6cff75415781deda1414fe22827400a7c334de6c
Author: Stephan Hoffmann <sho@relinux.de>
Date:   Mon May 18 11:36:02 2020 +0200

    DEVELOPERS: add Stephan Hoffmann for libhttpserver

    I added this package while working for Grandcentrix but
    am willing to maintain it further.

    Signed-off-by: Stephan Hoffmann <sho@relinux.de>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 64a2bfcf8f07d9d40e730ff9f483eb23a95233c1
Author: Stephan Hoffmann <sho@relinux.de>
Date:   Mon May 18 11:47:55 2020 +0200

    package/mtdev2tuio: remove package

    mtdev2tuio breaks the builds every now and then and is not
    maintained upstream. It does not seem to be useful any more.

    Signed-off-by: Stephan Hoffmann <sho@relinux.de>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit 285986ae5970d13090a27aba6b88743efd696158
Author: Ryan Coe <bluemrp9@gmail.com>
Date:   Mon May 18 07:00:49 2020 -0700

    package/mariadb: security bump to 10.3.23

    Add two spaces in hash file.

    Remove patch 0002 as it has been applied upstream.

    Release notes:
    https://mariadb.com/kb/en/library/mariadb-10323-release-notes/

    Changelog:
    https://mariadb.com/kb/en/library/mariadb-10323-changelog/

    Fixes the following security vulnerabilities:
    CVE-2020-2752 - Vulnerability in the MySQL Client product of Oracle MySQL
    (component: C API). Supported versions that are affected are 5.6.47 and
    prior, 5.7.27 and prior and 8.0.17 and prior. Difficult to exploit
    vulnerability allows low privileged attacker with network access via
    multiple protocols to compromise MySQL Client. Successful attacks of this
    vulnerability can result in unauthorized ability to cause a hang or
    frequently repeatable crash (complete DOS) of MySQL Client.

    CVE-2020-2812 - Vulnerability in the MySQL Server product of Oracle MySQL
    (component: Server: Stored Procedure). Supported versions that are affected
    are 5.6.47 and prior, 5.7.29 and prior and 8.0.19 and prior. Easily
    exploitable vulnerability allows high privileged attacker with network
    access via multiple protocols to compromise MySQL Server. Successful attacks
    of this vulnerability can result in unauthorized ability to cause a hang or
    frequently repeatable crash (complete DOS) of MySQL Server.

    CVE-2020-2814 - Vulnerability in the MySQL Server product of Oracle MySQL
    (component: InnoDB). Supported versions that are affected are 5.6.47 and
    prior, 5.7.28 and prior and 8.0.18 and prior. Easily exploitable
    vulnerability allows high privileged attacker with network access via
    multiple protocols to compromise MySQL Server. Successful attacks of this
    vulnerability can result in unauthorized ability to cause a hang or
    frequently repeatable crash (complete DOS) of MySQL Server.

    CVE-2020-2760 - Vulnerability in the MySQL Server product of Oracle MySQL
    (component: InnoDB). Supported versions that are affected are 5.7.29 and
    prior and 8.0.19 and prior. Easily exploitable vulnerability allows high
    privileged attacker with network access via multiple protocols to compromise
    MySQL Server. Successful attacks of this vulnerability can result in
    unauthorized ability to cause a hang or frequently repeatable crash
    (complete DOS) of MySQL Server as well as unauthorized update, insert or
    delete access to some of MySQL Server accessible data.

    Signed-off-by: Ryan Coe <bluemrp9@gmail.com>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>

commit ca0547ffeaea77b1b59ddcf77a2f3713167f8a7e
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Tue May 19 20:02:16 2020 +0200

    package/libexif: security bump to version 0.6.22

    - Switch site to github
    - Drop patches (already in version)
    - Fix the following CVEs:
      - CVE-2020-13114: Time consumption DoS when parsing canon array
        markers
      - CVE-2020-13113: Potential use of uninitialized memory
      - CVE-2020-13112: Various buffer overread fixes due to integer
        overflows in maker notes
      - CVE-2020-0093: read overflow
      - CVE-2020-12767: fixed division by zero

    https://github.com/libexif/libexif/releases/tag/libexif-0_6_22-release

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 78e78071128ccf2dba8cf76b00b1beb0c5f3e538
Author: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Date:   Mon May 18 08:26:47 2020 +0200

    package/bison: make installation relocatable

    Our current host-bison installation is not relocatable, so if you
    generate the SDK, and install it in a different location, bison will
    no longer work with failures such as:

    bison: /home/user/buildroot/output/host/share/bison/m4sugar/m4sugar.m4: cannot open: No such file or directory

    This particular issue is already resolved upstream by the addition of
    "relocatable" support, which we enable using --enable-relocatable.

    Once this issue is fixed, a second one pops up: the path to the m4
    program itself is also hardcoded. So we add a patch to fix that as
    well. The patch has been submitted upstream, which have requested for
    further refinements not applicable to the Buildroot context; in the
    meantime, we carry that patch.

    Fixes:

      https://bugs.busybox.net/show_bug.cgi?id=12656

    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
    [yann.morin.1998@free.fr: add reference to the upstream submission]
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 39ae8290aadf8c3b29388a9ebe0b32a7f6dd8e7e
Author: Yann E. MORIN <yann.morin.1998@free.fr>
Date:   Tue May 19 21:08:11 2020 +0200

    Revert "package/cracklib: add python3 support"

    This reverts commit f584595424137399dd06f73c6f04c759e04b879e.
    It in fact depends on a previous patch to python that was not applied
    [0], as upstream believes it is dangerous [1], and is still debating the
    proper solution [2].

    [0] https://patchwork.ozlabs.org/project/buildroot/patch/20200202205306.1785085-1-fontaine.fabrice@gmail.com/
    [1] https://bugs.python.org/issue39026#msg369309
    [2] https://bugs.python.org/issue39026

    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit f584595424137399dd06f73c6f04c759e04b879e
Author: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Date:   Sun Feb 2 21:53:06 2020 +0100

    package/cracklib: add python3 support

    python bindings supports python3 since version 2.8.19 and
    https://github.com/cracklib/cracklib/commit/219de98766b9f1e4c8c5b174de770158ffda3a93

    Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 42617caa720b96b66f00787b3d24b9bb18754e1e
Author: Stefan Sørensen <stefan@astylos.dk>
Date:   Tue May 19 15:35:23 2020 +0200

    package/p7zip: fix build with gcc 10

    Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
    Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

commit 9e9c242fb73fe19248c48ac28c083851d14f6813
Author: Stefan Sørensen <stefan.sorensen@spectralink.com>
Date:   Tue May 19 15:27:21 2020 +0200

    package/openldap: security bump to version 2.4.50

    Security fixes:
     CVE-2020-12243: Fixed slapd to limit depth of nested filters

    Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
    [yann.morin.1998@free.fr: two spaces in hash file]
    Signed…
celaxodon pushed a commit to celaxodon/buildroot that referenced this issue Oct 1, 2020
As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.

The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.

While debuging with "make -p" we can notice that s-selftest-c target
contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

  s-selftest-c: cc1

While the build is failing, the s-selftest-c dependencies recipe is
still running and reported as a bug by make.

  "Dependencies recipe running (THIS IS A BUG)."

A change [5] in gcc 9 seems to introduce the problem since we can't
reproduce this problem with gcc 8.

As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
including language makefile fragments.

With the fix applied, the s-seltest-c dependency contains
SELFTEST_DEPS value.

  s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
[3] cirosantilli/linux-kernel-module-cheat#108
[4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
[5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
lauromoura pushed a commit to lauromoura/buildroot that referenced this issue Jan 12, 2022
As reported by several Buildroot users [1][2][3], the gcc build
may fail while running selftests makefile target.

The problem only occurs when ccache is used with gcc 9 and 10,
probably due to a race condition.

While debuging with "make -p" we can notice that s-selftest-c target
contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].

  s-selftest-c: cc1

While the build is failing, the s-selftest-c dependencies recipe is
still running and reported as a bug by make.

  "Dependencies recipe running (THIS IS A BUG)."

A change [5] in gcc 9 seems to introduce the problem since we can't
reproduce this problem with gcc 8.

As suggested by Yann E. MORIN [6], move SELFTEST_DEPS before
including language makefile fragments.

With the fix applied, the s-seltest-c dependency contains
SELFTEST_DEPS value.

  s-selftest-c: cc1 xgcc specs stmp-int-hdrs ../../gcc/testsuite/selftests

[1] http://lists.busybox.net/pipermail/buildroot/2020-May/282171.html
[2] http://lists.busybox.net/pipermail/buildroot/2020-May/282766.html
[3] cirosantilli/linux-kernel-module-cheat#108
[4] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c/Make-lang.in;h=bfae6fd2549c4f728816cd355fa9739dcc08fcde;hb=033eb5671769a4c681a44aad08a454e667e08502#l120
[5] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=033eb5671769a4c681a44aad08a454e667e08502
[6] http://lists.busybox.net/pipermail/buildroot/2020-May/283213.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Ben Dakin-Norris <ben.dakin-norris@navtechradar.com>
Cc: Maxim Kochetkov <fido_max@inbox.ru>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 58ecbbc)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants