[Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[Athaariq Ardhiansyah]

Temporary fix for buildroot-specific bug. Ideally, we should install linux-headers first then glibc. Is this actually possible on Buildroot? If yes, then we can also fix bug #15021 simultaneously if linux-headers being installed first as possible.

Signed-off-by: Athaariq Ardhiansyah <buildroot@athaariq.my.id>
---
 .../0002-fsconfig_command-workaround.patch      | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 package/glibc/0002-fsconfig_command-workaround.patch

diff --git a/package/glibc/0002-fsconfig_command-workaround.patch b/package/glibc/0002-fsconfig_command-workaround.patch
new file mode 100644
index 0000000000..27dd25b244
--- /dev/null
+++ b/package/glibc/0002-fsconfig_command-workaround.patch
@@ -0,0 +1,17 @@
+diff --git a/sysdeps/unix/sysv/linux/sys/mount.h b/sysdeps/unix/sysv/linux/sys/mount.h
+index 19841d0738..43a681d097 100644
+--- a/sysdeps/unix/sysv/linux/sys/mount.h
++++ b/sysdeps/unix/sysv/linux/sys/mount.h
+@@ -27,11 +27,7 @@
+ #include <stddef.h>
+ #include <sys/ioctl.h>
+ 
+-#ifdef __has_include
+-# if __has_include ("linux/mount.h")
+-#  include "linux/mount.h"
+-# endif
+-#endif
++#include "linux/mount.h"
+ 
+ 
+ #define BLOCK_SIZE_BITS	10
-- 
2.37.3

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[Yann E. MORIN]

Athaariq, All,

On 2022-10-01 02:05 +0000, Athaariq Ardhiansyah spake thusly:
> Temporary fix for buildroot-specific bug.

How is this a buildroot-specific bug? Can you elaborate on that part? If
it is really a buildroot-related bug, then we want to understand it, and
fix it, not work around it.

> Ideally, we should install linux-headers first then glibc. Is this actually possible on Buildroot?

This is exactly what we are doing already, and for as long as Buildroot
has supported building a glibc-ased toolchain, as the kernel headers are
required to build glibc; see package/glibc/glibc.mk@28:

   26 # Before glibc is configured, we must have the first stage
   27 # cross-compiler and the kernel headers
   28 GLIBC_DEPENDENCIES = host-gcc-initial linux-headers host-bison host-gawk \

> If yes, then we can also fix bug #15021 simultaneously if linux-headers being installed first as possible.

This part does not apply (or makes sense), as linux headers *are*
installed before glibc is even configured.

This issue is really weird, because the glibc commit we are using is
supposed to contain the related fixes:

    $ git los --oneline 2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d3
    2628500f5d m68k: Enforce 4-byte alignment on internal locks (BZ #29537)
    [...]
    3bd3c612e9 Linux: Fix enum fsconfig_command detection in <sys/mount.h>
    bb1e8b0ca9 linux: Fix sys/mount.h usage with kernel headers
    d48813227b linux: Use compile_c_snippet to check linux/mount.h availability

(There are two new commits on the release/2.36/master branch, but they
seem unrelated to the issue:
    76e05613ee (origin/release/2.36/master) stdlib: Fix __getrandom_nocancel type and arc4random usage (BZ #29638)
    227c903587 get_nscd_addresses: Fix subscript typos [BZ #29605]
)

To be noted, and as Thomas noticed, OpenEmbeded is also using a glibc
2.36 commit, and even one older than ours, but they do not seem to have
issues.

So, we'd like to understand why this is causing an issue for us. Hence,
if you could elaborate on the firt part of your message, above, that
would be extermely useful!

Regards,
Yann E. MORIN.

> Signed-off-by: Athaariq Ardhiansyah <buildroot@athaariq.my.id>
> ---
>  .../0002-fsconfig_command-workaround.patch      | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 package/glibc/0002-fsconfig_command-workaround.patch
> 
> diff --git a/package/glibc/0002-fsconfig_command-workaround.patch b/package/glibc/0002-fsconfig_command-workaround.patch
> new file mode 100644
> index 0000000000..27dd25b244
> --- /dev/null
> +++ b/package/glibc/0002-fsconfig_command-workaround.patch
> @@ -0,0 +1,17 @@
> +diff --git a/sysdeps/unix/sysv/linux/sys/mount.h b/sysdeps/unix/sysv/linux/sys/mount.h
> +index 19841d0738..43a681d097 100644
> +--- a/sysdeps/unix/sysv/linux/sys/mount.h
> ++++ b/sysdeps/unix/sysv/linux/sys/mount.h
> +@@ -27,11 +27,7 @@
> + #include <stddef.h>
> + #include <sys/ioctl.h>
> + 
> +-#ifdef __has_include
> +-# if __has_include ("linux/mount.h")
> +-#  include "linux/mount.h"
> +-# endif
> +-#endif
> ++#include "linux/mount.h"
> + 
> + 
> + #define BLOCK_SIZE_BITS	10
> -- 
> 2.37.3
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[buildroot]

Hello Mr. Morrin,

> This issue is really weird, because the glibc commit we are using is
> supposed to contain the related fixes

Pardon me for being so weird. What I'm trying to fix is this error:

```
/builds/buildroot.org/buildroot/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/include/linux/mount.h:92:6: 
error: multiple definition of ‘enum fsconfig_command’
    92 | enum fsconfig_command {
       |      ^~~~~~~~~~~~~~~~
In file included from 
../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:62:
/builds/buildroot.org/buildroot/output/build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:249:6: 
note: previous definition here
   249 | enum fsconfig_command
       |      ^~~~~~~~~~~~~~~~
```

I did spent entire morning last two days ago and I figured out that no 
matter how do I detect linux/mount.h presence in "sys/mount.h", **enum 
fsconfig_command** still in clash between linux-headers and glibc. 
However, the problem only exist in glibc v2.36 whereas no effect when I 
changed linux version. Thus, linux-headers seems to be declared after 
glibc.

> How is this a buildroot-specific bug? Can you elaborate on that part? 
> If
> it is really a buildroot-related bug, then we want to understand it, 
> and
> fix it, not work around it.

Because it successfully compiled in Gentoo but failed when compile 
Buildroot for Raspberry Pi 4 and Raspberry Pi 3, with default 
configuration. The reason why I asked "Is this possible on Buildroot?" 
is to give you two options:
1. If possible, let's make sure linux-headers installed before glibc
2. If not, let's workaround for a while until there's a revelation from 
upstream

> This is exactly what we are doing already, and for as long as Buildroot
> has supported building a glibc-ased toolchain, as the kernel headers 
> are
> required to build glibc; see package/glibc/glibc.mk@28:

Well that's interesting. Wonder why that enum redeclaration error exist 
and my last patch actually works.

> To be noted, and as Thomas noticed, OpenEmbeded is also using a glibc
> 2.36 commit, and even one older than ours, but they do not seem to have
> issues.

Honestly, I only tested it on my Raspberry Pi 4 and my friend's 
Raspberry Pi 3 with latest origin/master and default configuration. 
Yesterday, I realized that all raspberry boards are symlinked into one 
directory after checked autobuild. Perhaps, board specific issue? If 
correct, I'm going to patch the custom kernel instead, plus bump it.

I also noticed Raspberry Pi boards are marked ORPH at autobuild. Is that 
means orphan? If yes, I would gladly contribute as board maintainer. 
Thank you for your cooperation.

Regards,
Athaariq Ardhiansyah

NB: My nickname is Eric
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[Yann E. MORIN]

Athaariq, Al,

On 2022-10-02 03:33 +0000, buildroot@athaariq.my.id spake thusly:
> >This issue is really weird, because the glibc commit we are using is
> >supposed to contain the related fixes
> Pardon me for being so weird.

You are not being weird, no worries.

> What I'm trying to fix is this error:
> error: multiple definition of ‘enum fsconfig_command’

Yes, we are aware of that issue.

> I did spent entire morning last two days ago and I figured out that no
> matter how do I detect linux/mount.h presence in "sys/mount.h", **enum
> fsconfig_command** still in clash between linux-headers and glibc. However,
> the problem only exist in glibc v2.36 whereas no effect when I changed linux
> version. Thus, linux-headers seems to be declared after glibc.

When you change the linux headers version in Buildroot, you need to
restart from a clean state, i.e. run "make clean" before resuming the
build, see the full explanations in the manual:
    https://buildroot.org/downloads/manual/manual.html#full-rebuild

> >How is this a buildroot-specific bug? Can you elaborate on that part? If
> >it is really a buildroot-related bug, then we want to understand it, and
> >fix it, not work around it.
> 
> Because it successfully compiled in Gentoo but failed when compile Buildroot
> for Raspberry Pi 4 and Raspberry Pi 3, with default configuration. The
> reason why I asked "Is this possible on Buildroot?" is to give you two
> options:
> 1. If possible, let's make sure linux-headers installed before glibc
> 2. If not, let's workaround for a while until there's a revelation from
> upstream
> 
> >This is exactly what we are doing already, and for as long as Buildroot
> >has supported building a glibc-ased toolchain, as the kernel headers are
> >required to build glibc; see package/glibc/glibc.mk@28:
> 
> Well that's interesting. Wonder why that enum redeclaration error exist and
> my last patch actually works.

Yes, we really need to understand why it is broken in the first place,
to evaluate whether your patch is correct, or whether we should change
the way we do things in Buildroot. Hint: I think we do something in
Buildroot that is wrong (or has become wrong as time passed), but we
could not pinpoint it yet...

> >To be noted, and as Thomas noticed, OpenEmbeded is also using a glibc
> >2.36 commit, and even one older than ours, but they do not seem to have
> >issues.
> 
> Honestly, I only tested it on my Raspberry Pi 4 and my friend's Raspberry Pi
> 3 with latest origin/master and default configuration. Yesterday, I realized
> that all raspberry boards are symlinked into one directory after checked
> autobuild. Perhaps, board specific issue? If correct, I'm going to patch the
> custom kernel instead, plus bump it.

It is not specific to the raspberrypi, we have tons of builds failing on
various architectures:
    http://autobuild.buildroot.net/?reason=glibc-2.36-%

> I also noticed Raspberry Pi boards are marked ORPH at autobuild. Is that
> means orphan? If yes, I would gladly contribute as board maintainer. Thank
> you for your cooperation.

Weird, as we already have two persons registered for the rpi series:

    $ ./utils/get-developers -f configs/raspberrypi* board/raspberrypi/
    Julien Grossholtz <julien.grossholtz@openest.io>
    Martin Bark <martin@barkynet.com>

But if you want to be added to that list, do not hesitate to send a
patch against the DEVELOPERS file to add yourself.

> NB: My nickname is Eric

Erics are everywhere! :-)

Is that what you want to be adressed by, or should we go with Athaariq?

Regards,
Yann E. MORIN.

> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[Peter Seiderer]

Hello *,

On Sun, 2 Oct 2022 09:40:28 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

[...]  
> 
> Yes, we really need to understand why it is broken in the first place,
> to evaluate whether your patch is correct, or whether we should change
> the way we do things in Buildroot. Hint: I think we do something in
> Buildroot that is wrong (or has become wrong as time passed), but we
> could not pinpoint it yet...
> 
> > >To be noted, and as Thomas noticed, OpenEmbeded is also using a glibc
> > >2.36 commit, and even one older than ours, but they do not seem to have
> > >issues.  
> > 

With buildroot raspberrypi4_64_defconfig:

  In file included from .../host/aarch64-buildroot-linux-gnu/sysroot/usr/include/linux/fs.h:19,
                   from ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:75:
  .../host/aarch64-buildroot-linux-gnu/sysroot/usr/include/linux/mount.h:92:6: error: multiple definition of ‘enum fsconfig_command’
     92 | enum fsconfig_command {
        |      ^~~~~~~~~~~~~~~~
  In file included from ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:62:
.../build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:249:6: note: previous definition here
    249 | enum fsconfig_command
        |      ^~~~~~~~~~~~~~~~


Note the 'include-fixed' path, so diff the original vs. the fixed:

	$ diff -u .../sysroot/usr/include/sys/mount.h /home/seiderer/Work/Buildroot/build_rpi4_64_glibc_001/build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h | cat
--- .../sysroot/usr/include/sys/mount.h	2022-10-03 16:17:15.934642586 +0200
+++ .../build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h	2022-10-03 16:20:35.862882930 +0200
@@ -1,3 +1,12 @@
+/*  DO NOT EDIT THIS FILE.
+
+    It has been auto-edited by fixincludes from:
+
+	".../sysroot/usr/include/sys/mount.h"
+
+    This had to be done to correct non-standard usages in the
+    original, manufacturer supplied header file.  */
+
 /* Header file for mounting/unmount Linux filesystems.
    Copyright (C) 1996-2022 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
@@ -28,7 +37,7 @@
 #include <sys/ioctl.h>
 
 #ifdef __has_include
-# if __has_include ("linux/mount.h")
+# if __has_include ("__linux__/mount.h")
 #  include "linux/mount.h"
 # endif
 #endif

After changing back the line

	# if __has_include ("__linux__/mount.h")

to

	# if __has_include ("linux/mount.h")

the build succeeds...

Seems gcc fixincl does not handle the '# if __has_include' pattern the right way...

Same for all other '__has_include' usages:

	$ grep -R __has_include build/host-gcc-final-11.3.0/build/gcc/include-fixed/
build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/unistd_ext.h:#ifdef __has_include
build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/unistd_ext.h:# if __has_include ("__linux__/close_range.h")
build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/statx.h:   __has_include argument (GCC PR 80005).  */
build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/statx.h:#ifdef __has_include
build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/statx.h:# if __has_include ("__linux__/stat.h")
build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:#ifdef __has_include
build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:# if __has_include ("__linux__/mount.h")
build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/rseq.h:#ifdef __has_include
build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/rseq.h:# if __has_include ("__linux__/rseq.h")


Regards,
Peter

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[Peter Seiderer]

Hello *,

On Tue, 4 Oct 2022 08:59:22 +0200, Peter Seiderer <ps.report@gmx.net> wrote:

> Hello *,
> 
> On Sun, 2 Oct 2022 09:40:28 +0200, "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> 
> [...]  
> > 
> > Yes, we really need to understand why it is broken in the first place,
> > to evaluate whether your patch is correct, or whether we should change
> > the way we do things in Buildroot. Hint: I think we do something in
> > Buildroot that is wrong (or has become wrong as time passed), but we
> > could not pinpoint it yet...
> >   
> > > >To be noted, and as Thomas noticed, OpenEmbeded is also using a glibc
> > > >2.36 commit, and even one older than ours, but they do not seem to have
> > > >issues.    
> > >   
> 
> With buildroot raspberrypi4_64_defconfig:
> 
>   In file included from .../host/aarch64-buildroot-linux-gnu/sysroot/usr/include/linux/fs.h:19,
>                    from ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:75:
>   .../host/aarch64-buildroot-linux-gnu/sysroot/usr/include/linux/mount.h:92:6: error: multiple definition of ‘enum fsconfig_command’
>      92 | enum fsconfig_command {
>         |      ^~~~~~~~~~~~~~~~
>   In file included from ../../../../libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:62:
> .../build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:249:6: note: previous definition here
>     249 | enum fsconfig_command
>         |      ^~~~~~~~~~~~~~~~
> 
> 
> Note the 'include-fixed' path, so diff the original vs. the fixed:
> 
> 	$ diff -u .../sysroot/usr/include/sys/mount.h /home/seiderer/Work/Buildroot/build_rpi4_64_glibc_001/build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h | cat
> --- .../sysroot/usr/include/sys/mount.h	2022-10-03 16:17:15.934642586 +0200
> +++ .../build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h	2022-10-03 16:20:35.862882930 +0200
> @@ -1,3 +1,12 @@
> +/*  DO NOT EDIT THIS FILE.
> +
> +    It has been auto-edited by fixincludes from:
> +
> +	".../sysroot/usr/include/sys/mount.h"
> +
> +    This had to be done to correct non-standard usages in the
> +    original, manufacturer supplied header file.  */
> +
>  /* Header file for mounting/unmount Linux filesystems.
>     Copyright (C) 1996-2022 Free Software Foundation, Inc.
>     This file is part of the GNU C Library.
> @@ -28,7 +37,7 @@
>  #include <sys/ioctl.h>
>  
>  #ifdef __has_include
> -# if __has_include ("linux/mount.h")
> +# if __has_include ("__linux__/mount.h")
>  #  include "linux/mount.h"
>  # endif
>  #endif
> 
> After changing back the line
> 
> 	# if __has_include ("__linux__/mount.h")
> 
> to
> 
> 	# if __has_include ("linux/mount.h")
> 
> the build succeeds...
> 
> Seems gcc fixincl does not handle the '# if __has_include' pattern the right way...
> 
> Same for all other '__has_include' usages:
> 
> 	$ grep -R __has_include build/host-gcc-final-11.3.0/build/gcc/include-fixed/
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/unistd_ext.h:#ifdef __has_include
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/unistd_ext.h:# if __has_include ("__linux__/close_range.h")
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/statx.h:   __has_include argument (GCC PR 80005).  */
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/statx.h:#ifdef __has_include
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/bits/statx.h:# if __has_include ("__linux__/stat.h")
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:#ifdef __has_include
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/mount.h:# if __has_include ("__linux__/mount.h")
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/rseq.h:#ifdef __has_include
> build/host-gcc-final-11.3.0/build/gcc/include-fixed/sys/rseq.h:# if __has_include ("__linux__/rseq.h")

And the corresponding gcc bug entry ([1]) and master branch patch ([2], [3])...

Regards,
Peter

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085
[2] https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6bf383c37e6131a8e247e8a0997d55d65c830b6d
[3] https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=6bf383c37e6131a8e247e8a0997d55d65c830b6d


> 
> 
> Regards,
> Peter
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/1] package/glibc: fix fsconfig_command redeclaration bug

[buildroot]

Hello Mr. Morin,

Sorry for late reply, I'm quite hectic last two days.

> You are not being weird, no worries.

Glad to know that :)

> Yes, we really need to understand why it is broken in the first place,
> to evaluate whether your patch is correct, or whether we should change
> the way we do things in Buildroot. Hint: I think we do something in
> Buildroot that is wrong (or has become wrong as time passed), but we
> could not pinpoint it yet...

Is there any other lines of code which manage sequence of installation?

> It is not specific to the raspberrypi, we have tons of builds failing 
> on
> various architectures:
>     http://url9588.athaariq.my.id/ls/click?upn=EfMvhF2HbzWlWvoxH9jeaTgpDdcbplGK5RDVND-2B6ZFK9hCQC2WiAEjIrhodLYz5eO-2BJO20BJqwrc4lATo1NRwg-3D-3DAfCw_beVnn4Jp-2FUb-2BbeVAiSjItHJusThyvkQasPabgmUJ334L25BZoBu4-2BDqB8GH-2F13lOIyetiMWNseqo8XOa2P3TgbwwX0LwZSnBEz551VXh7QULfJDj-2BMmFJXrbyG2bmzhV8tnlx3rXaFEqxj2D6HbUpMuG0fiGFL-2FTlxTNHZ4TVNFV5tYud8vJWgB1-2FYJ3uq8XZRKx59Sy9Ok2eRA5ZSeQGA-3D-3D

This is got more interesting, upstream also experienced this issue but 
successfully fixed. Reference: 
http://url9588.athaariq.my.id/ls/click?upn=HR0k-2FCRlAlnEsA1lGB1G4hmlzVyQPcieteZMXKJ8qcLkRdBj-2FX6cy8YNfcDO-2FLRPt1izGFD3NiimghABa-2BBrOA-3D-3DEonc_beVnn4Jp-2FUb-2BbeVAiSjItHJusThyvkQasPabgmUJ334L25BZoBu4-2BDqB8GH-2F13lOIyetiMWNseqo8XOa2P3TgUGGjpBpy7evZzxTQ-2FI8tVgqm-2FzsG5O1eQ19JFczEMINKm4yv0dmYFsigmPLPNlJAgpyI1rghWLAeFqItil1jhw2qQX4KoB2KCIMJQZAnSQj8i0z-2B7O3BI83-2B0Mx0bP1eQ-3D-3D

> But if you want to be added to that list, do not hesitate to send a
> patch against the DEVELOPERS file to add yourself.

I'm going to do that after bumped Raspberry Pi kernel and also fixed 
this issue. Because this issue causes buildroot fail to build. So I 
can't test it with *trully* default configuration.

For your information, I'm also attempting to add support for Orange Pi 
Zero 2 board as Buildroot got more popular here. Especially for smart 
bike development at campus.

> Erics are everywhere! :-)
> 
> Is that what you want to be adressed by, or should we go with Athaariq?

Haha Erics are everywhere even at my campus! What about Thor, is that 
also a common name?

Regards,
Athaariq "Thor" Ardhiansyah
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot