[Buildroot] [autobuild.buildroot.net] Build results for 2017-08-14

[Buildroot] [autobuild.buildroot.net] Build results for 2017-08-14

[Thomas Petazzoni]

Hello,

Build statistics for 2017-08-14
================================

      successes : 193
       failures : 19 
       timeouts : 0  
          TOTAL : 212

Classification of failures by reason
====================================

                       unknown | 6 
                    norm-1.5r6 | 2 
                   faad2-2.8.1 | 1 
                flashrom-0.9.9 | 1 
gmrender-resurrect-33600ab6... | 1 
                     gpsd-3.16 | 1 
         libspatialindex-1.8.5 | 1 
        ltp-testsuite-20170516 | 1 
                   mp4v2-2.0.0 | 1 
                     mtd-2.0.0 | 1 
       python-smbus-cffi-0.5.1 | 1 
                      qt-4.8.7 | 1 
                    ruby-2.4.1 | 1 


Detail of failures
===================

      x86_64 |                    faad2-2.8.1 | NOK | http://autobuild.buildroot.net/results/6b159b766d791492bab4d897c33ce07845fb7119 |     
      x86_64 |                 flashrom-0.9.9 | NOK | http://autobuild.buildroot.net/results/e362848eb45f6b8100131361e6e5faa546f0bbd8 |     
         arm | gmrender-resurrect-33600ab6... | NOK | http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f |     
microblazeel |                      gpsd-3.16 | NOK | http://autobuild.buildroot.net/results/2387103a559da5a0fa77b8c5a17151284132d74c |     
microblazeel |          libspatialindex-1.8.5 | NOK | http://autobuild.buildroot.net/results/bbba2a2c97dbec21340c7fd07162a316a411cba4 |     
        mips |         ltp-testsuite-20170516 | NOK | http://autobuild.buildroot.net/results/9e1157776dfba79102225ac2d48e99644e1558b3 |     
         arm |                    mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/1a606e34f9c54f4c0b60c36eedeff05d947ee5a7 |     
         arm |                      mtd-2.0.0 | NOK | http://autobuild.buildroot.net/results/879c79e505f65387a46c4be263dc8783c8ca61bf | ORPH
         arm |                     norm-1.5r6 | NOK | http://autobuild.buildroot.net/results/d99b9e3da5851ac5279d8b7a6e7eeae4f6077c0c |     
         arm |                     norm-1.5r6 | NOK | http://autobuild.buildroot.net/results/958c853f89dba7d1d70665d2b2c1031c3abc9403 |     
      x86_64 |        python-smbus-cffi-0.5.1 | NOK | http://autobuild.buildroot.net/results/1cc523dccb1524f9f6fc8fe1af451beb62c38058 |     
     powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/2948ec94cc4f5f98f296fa487c481e971721cff8 | ORPH
      x86_64 |                     ruby-2.4.1 | NOK | http://autobuild.buildroot.net/results/8f0342b7b88df979a59fdab574b2489628d7ffa5 | ORPH
         arm |                        unknown | NOK | http://autobuild.buildroot.net/results/11119a8e3948bce27ad748bd9160a01b8f06f4f8 |     
      mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/7283cb4e1e6ae32ac14083ce1a00b0cd28fbb6a7 |     
         arm |                        unknown | NOK | http://autobuild.buildroot.net/results/4d35c523e36cce6d638fa10659e374ebaf6a7f00 |     
    mips64el |                        unknown | NOK | http://autobuild.buildroot.net/results/c5922b271252462601489f05a922d68140ef348f |     
      mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/5cdc5304654a277071d34d73c6c2c4a7808ac60d |     
      mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/ade9f0689b53cf461637f38b3640bfd89fe89ef0 |     

-- 
http://autobuild.buildroot.net

[Buildroot] Analysis of build results for 2017-08-14

[Thomas Petazzoni]

Hello,

On Tue, 15 Aug 2017 08:31:02 +0200 (CEST), Thomas Petazzoni wrote:

>       x86_64 |                    faad2-2.8.1 | NOK | http://autobuild.buildroot.net/results/6b159b766d791492bab4d897c33ce07845fb7119 |     

getopt.c:175:13: error: conflicting types for 'strncmp'
 extern int  strncmp(const char *s1, const char *s2, unsigned int n);

The code has some logic to detect if the GNU C library is being used,
and if not, defines its own functions. Except that the detection logic
doesn't work properly when musl is used.

>       x86_64 |                 flashrom-0.9.9 | NOK | http://autobuild.buildroot.net/results/e362848eb45f6b8100131361e6e5faa546f0bbd8 |     

/home/buildroot/autobuild/run/instance-0/output/host/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libc.a(strnlen.os): In function `__GI_strnlen':
strnlen.c:(.text+0x0): multiple definition of `strnlen'

Redefines strnlen() while it's already provided by the C library.

>          arm | gmrender-resurrect-33600ab6... | NOK | http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f |     

/home/buildroot/autobuild/run/instance-2/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgstreamer-1.0.a(libgstreamer_1.0_la-gstinfo.o): In function `generate_unwind_trace':
/home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2687: undefined reference to `_ULarm_init_local'
/home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2694: undefined reference to `_ULarm_step'
/home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2717: undefined reference to `_ULarm_get_proc_name'

No idea. It's happening in a static linking configuration. Not sure
what is supposed to provide those symbols.

> microblazeel |                      gpsd-3.16 | NOK | http://autobuild.buildroot.net/results/2387103a559da5a0fa77b8c5a17151284132d74c |     

Fixed by
https://git.buildroot.org/buildroot/commit/?id=e6d0177f5319457588080b7ed111da2c3b628cf8.

> microblazeel |          libspatialindex-1.8.5 | NOK | http://autobuild.buildroot.net/results/bbba2a2c97dbec21340c7fd07162a316a411cba4 |     

I've proposed a patch to fix this, see
https://patchwork.ozlabs.org/patch/801340/.

>         mips |         ltp-testsuite-20170516 | NOK | http://autobuild.buildroot.net/results/9e1157776dfba79102225ac2d48e99644e1558b3 |     

/home/test/autobuild/run/instance-2/output/build/ltp-testsuite-20170516/testcases/kernel/include/linux_syscall_numbers.h:10022:2: error: #endif without #if
 #endif

Bug in the tool that generates this file ?

>          arm |                    mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/1a606e34f9c54f4c0b60c36eedeff05d947ee5a7 |     

src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]

Quite easy to fix.

>          arm |                      mtd-2.0.0 | NOK | http://autobuild.buildroot.net/results/879c79e505f65387a46c4be263dc8783c8ca61bf | ORPH

Would be fixed by https://patchwork.ozlabs.org/patch/801414/. BTW, mtd
is a quite important package, but we have nobody listed for it in the
DEVELOPERS file. Would someone volunteer ?

>          arm |                     norm-1.5r6 | NOK | http://autobuild.buildroot.net/results/d99b9e3da5851ac5279d8b7a6e7eeae4f6077c0c |     
>          arm |                     norm-1.5r6 | NOK | http://autobuild.buildroot.net/results/958c853f89dba7d1d70665d2b2c1031c3abc9403 |     

Some C++ issue.

/home/buildroot/autobuild/run/instance-2/output/build/norm-1.5r6/protolib/include/protoTree.h: In member function 'ITEM_TYPE* ProtoSortedTreeTemplate<ITEM_TYPE>::Iterator::PeekPrevItem() const':
/home/buildroot/autobuild/run/instance-2/output/build/norm-1.5r6/protolib/include/protoTree.h:652:93: error: no matching function for call to 'ProtoSortedTreeTemplate<ITEM_TYPE>::Iterator::PeekPrevItem() const'

Gustavo is listed in the DEVELOPERS file for this package, but I don't
think he is going to be active in fixing this. Anyone else to look into
that ?

>       x86_64 |        python-smbus-cffi-0.5.1 | NOK | http://autobuild.buildroot.net/results/1cc523dccb1524f9f6fc8fe1af451beb62c38058 |     

That's the same PYTHON_PATH issue we had with python 2.x, now with
python 3.x. I have a patch fixing that, but it needs more testing.

>      powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/2948ec94cc4f5f98f296fa487c481e971721cff8 | ORPH

GCC ICE :

tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in validate_condition_mode, at config/rs6000/rs6000.c:17988

Weird, we're using a modern gcc version here, on a fairly well-known
architecture. Google doesn't know much about this ICE, so perhaps we
should report it upstream to gcc.


>       x86_64 |                     ruby-2.4.1 | NOK | http://autobuild.buildroot.net/results/8f0342b7b88df979a59fdab574b2489628d7ffa5 | ORPH

Not sure what's happening here:

linking shared-library libruby.so.2.4.1
libruby.so.2.4.1: final close failed: Invalid operation
collect2: error: ld returned 1 exit status

Anyone to look into this ?

>          arm |                        unknown | NOK | http://autobuild.buildroot.net/results/11119a8e3948bce27ad748bd9160a01b8f06f4f8 |     
>       mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/7283cb4e1e6ae32ac14083ce1a00b0cd28fbb6a7 |     
>          arm |                        unknown | NOK | http://autobuild.buildroot.net/results/4d35c523e36cce6d638fa10659e374ebaf6a7f00 |     
>     mips64el |                        unknown | NOK | http://autobuild.buildroot.net/results/c5922b271252462601489f05a922d68140ef348f |     
>       mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/5cdc5304654a277071d34d73c6c2c4a7808ac60d |     
>       mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/ade9f0689b53cf461637f38b3640bfd89fe89ef0 |     

All of these are qemu-user failures, due to the host kernel headers
being too old. This error is normally ignored by autobuild-run, but
Julien's autobuilder is running a too old version of autobuild-run. So
I've temporarily added some filtering on the server side to reject such
bogus failures.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Analysis of build results for 2017-08-14

[Matthew Weber]

Thomas,

On Tue, Aug 15, 2017 at 7:20 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 15 Aug 2017 08:31:02 +0200 (CEST), Thomas Petazzoni wrote:
>
>>       x86_64 |                    faad2-2.8.1 | NOK | http://autobuild.buildroot.net/results/6b159b766d791492bab4d897c33ce07845fb7119 |
>
> getopt.c:175:13: error: conflicting types for 'strncmp'
>  extern int  strncmp(const char *s1, const char *s2, unsigned int n);
>
> The code has some logic to detect if the GNU C library is being used,
> and if not, defines its own functions. Except that the detection logic
> doesn't work properly when musl is used.
>
>>       x86_64 |                 flashrom-0.9.9 | NOK | http://autobuild.buildroot.net/results/e362848eb45f6b8100131361e6e5faa546f0bbd8 |
>
> /home/buildroot/autobuild/run/instance-0/output/host/x86_64-buildroot-linux-uclibc/sysroot/usr/lib/libc.a(strnlen.os): In function `__GI_strnlen':
> strnlen.c:(.text+0x0): multiple definition of `strnlen'
>
> Redefines strnlen() while it's already provided by the C library.
>
>>          arm | gmrender-resurrect-33600ab6... | NOK | http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f |
>
> /home/buildroot/autobuild/run/instance-2/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgstreamer-1.0.a(libgstreamer_1.0_la-gstinfo.o): In function `generate_unwind_trace':
> /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2687: undefined reference to `_ULarm_init_local'
> /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2694: undefined reference to `_ULarm_step'
> /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2717: undefined reference to `_ULarm_get_proc_name'
>
> No idea. It's happening in a static linking configuration. Not sure
> what is supposed to provide those symbols.
>
>> microblazeel |                      gpsd-3.16 | NOK | http://autobuild.buildroot.net/results/2387103a559da5a0fa77b8c5a17151284132d74c |
>
> Fixed by
> https://git.buildroot.org/buildroot/commit/?id=e6d0177f5319457588080b7ed111da2c3b628cf8.
>
>> microblazeel |          libspatialindex-1.8.5 | NOK | http://autobuild.buildroot.net/results/bbba2a2c97dbec21340c7fd07162a316a411cba4 |
>
> I've proposed a patch to fix this, see
> https://patchwork.ozlabs.org/patch/801340/.
>
>>         mips |         ltp-testsuite-20170516 | NOK | http://autobuild.buildroot.net/results/9e1157776dfba79102225ac2d48e99644e1558b3 |
>
> /home/test/autobuild/run/instance-2/output/build/ltp-testsuite-20170516/testcases/kernel/include/linux_syscall_numbers.h:10022:2: error: #endif without #if
>  #endif
>
> Bug in the tool that generates this file ?
>
>>          arm |                    mp4v2-2.0.0 | NOK | http://autobuild.buildroot.net/results/1a606e34f9c54f4c0b60c36eedeff05d947ee5a7 |
>
> src/rtphint.cpp:342:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
>
> Quite easy to fix.
>
>>          arm |                      mtd-2.0.0 | NOK | http://autobuild.buildroot.net/results/879c79e505f65387a46c4be263dc8783c8ca61bf | ORPH
>
> Would be fixed by https://patchwork.ozlabs.org/patch/801414/. BTW, mtd
> is a quite important package, but we have nobody listed for it in the
> DEVELOPERS file. Would someone volunteer ?
>
>>          arm |                     norm-1.5r6 | NOK | http://autobuild.buildroot.net/results/d99b9e3da5851ac5279d8b7a6e7eeae4f6077c0c |
>>          arm |                     norm-1.5r6 | NOK | http://autobuild.buildroot.net/results/958c853f89dba7d1d70665d2b2c1031c3abc9403 |
>
> Some C++ issue.
>
> /home/buildroot/autobuild/run/instance-2/output/build/norm-1.5r6/protolib/include/protoTree.h: In member function 'ITEM_TYPE* ProtoSortedTreeTemplate<ITEM_TYPE>::Iterator::PeekPrevItem() const':
> /home/buildroot/autobuild/run/instance-2/output/build/norm-1.5r6/protolib/include/protoTree.h:652:93: error: no matching function for call to 'ProtoSortedTreeTemplate<ITEM_TYPE>::Iterator::PeekPrevItem() const'
>
> Gustavo is listed in the DEVELOPERS file for this package, but I don't
> think he is going to be active in fixing this. Anyone else to look into
> that ?
>
>>       x86_64 |        python-smbus-cffi-0.5.1 | NOK | http://autobuild.buildroot.net/results/1cc523dccb1524f9f6fc8fe1af451beb62c38058 |
>
> That's the same PYTHON_PATH issue we had with python 2.x, now with
> python 3.x. I have a patch fixing that, but it needs more testing.
>
>>      powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/2948ec94cc4f5f98f296fa487c481e971721cff8 | ORPH
>
> GCC ICE :
>
> tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in validate_condition_mode, at config/rs6000/rs6000.c:17988
>
> Weird, we're using a modern gcc version here, on a fairly well-known
> architecture. Google doesn't know much about this ICE, so perhaps we
> should report it upstream to gcc.
>
>
>>       x86_64 |                     ruby-2.4.1 | NOK | http://autobuild.buildroot.net/results/8f0342b7b88df979a59fdab574b2489628d7ffa5 | ORPH
>
> Not sure what's happening here:
>
> linking shared-library libruby.so.2.4.1
> libruby.so.2.4.1: final close failed: Invalid operation
> collect2: error: ld returned 1 exit status
>
> Anyone to look into this ?
>
>>          arm |                        unknown | NOK | http://autobuild.buildroot.net/results/11119a8e3948bce27ad748bd9160a01b8f06f4f8 |
>>       mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/7283cb4e1e6ae32ac14083ce1a00b0cd28fbb6a7 |
>>          arm |                        unknown | NOK | http://autobuild.buildroot.net/results/4d35c523e36cce6d638fa10659e374ebaf6a7f00 |
>>     mips64el |                        unknown | NOK | http://autobuild.buildroot.net/results/c5922b271252462601489f05a922d68140ef348f |
>>       mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/5cdc5304654a277071d34d73c6c2c4a7808ac60d |
>>       mipsel |                        unknown | NOK | http://autobuild.buildroot.net/results/ade9f0689b53cf461637f38b3640bfd89fe89ef0 |
>
> All of these are qemu-user failures, due to the host kernel headers
> being too old. This error is normally ignored by autobuild-run, but
> Julien's autobuilder is running a too old version of autobuild-run. So
> I've temporarily added some filtering on the server side to reject such
> bogus failures.
>

You're going to see some more unknown builds today (end log snippets
below).  I've updated my autobuilder and trying to figure out the
following new error.  At this point I disabled my result submissions
and doing further testing offline.

http://autobuild.buildroot.net/results/e19/e196ceb333f554748081e78858eafb2739e0e317//
 [7m>>>   Sanitizing RPATH in target tree [27m
/accts/mlweber1/instance-3/buildroot/support/scripts/fix-rpath target
make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
make: Entering directory `/accts/mlweber1/instance-3/buildroot'
package/coxpcall/coxpcall.mk:11: *** COXPCALL_SITE cannot be empty
when COXPCALL_SOURCE is not.  Stop.
make: Leaving directory `/accts/mlweber1/instance-3/buildroot'


http://autobuild.buildroot.net/results/d3f/d3fa24b5589cc75f040a8f7aedb442ffda9b6814//
 [7m>>>   Sanitizing RPATH in target tree [27m
/accts/mlweber1/instance-2/buildroot/support/scripts/fix-rpath target
make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
make: Entering directory `/accts/mlweber1/instance-2/buildroot'
package/lua-bit32/lua-bit32.mk:13: *** LUA_BIT32_SITE cannot be empty
when LUA_BIT32_SOURCE is not.  Stop.
make: Leaving directory `/accts/mlweber1/instance-2/buildroot'

Has anyone else seen errors like these?

The only modifications I have to the autobuilder script are to use a
local cache of archives for my BR2_PRIMARY_SITE.  ( we refresh it
daily out-of-band for internal firewall/proxy download failure
reasons)   As part of setting BR2_PRIMARY_SITE  we set
BR2_PRIMARY_SITE_ONLY=y.

Matt

[Buildroot] Analysis of build results for 2017-08-14

[Thomas Petazzoni]

Hello,

On Tue, 15 Aug 2017 07:58:43 -0500, Matthew Weber wrote:

> > All of these are qemu-user failures, due to the host kernel headers
> > being too old. This error is normally ignored by autobuild-run, but
> > Julien's autobuilder is running a too old version of autobuild-run. So
> > I've temporarily added some filtering on the server side to reject such
> > bogus failures.
> 
> You're going to see some more unknown builds today (end log snippets
> below).  I've updated my autobuilder and trying to figure out the
> following new error.  At this point I disabled my result submissions
> and doing further testing offline.
> 
> http://autobuild.buildroot.net/results/e19/e196ceb333f554748081e78858eafb2739e0e317//
>  [7m>>>   Sanitizing RPATH in target tree [27m  
> /accts/mlweber1/instance-3/buildroot/support/scripts/fix-rpath target
> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
> make: Entering directory `/accts/mlweber1/instance-3/buildroot'
> package/coxpcall/coxpcall.mk:11: *** COXPCALL_SITE cannot be empty
> when COXPCALL_SOURCE is not.  Stop.
> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
> 
> 
> http://autobuild.buildroot.net/results/d3f/d3fa24b5589cc75f040a8f7aedb442ffda9b6814//
>  [7m>>>   Sanitizing RPATH in target tree [27m  
> /accts/mlweber1/instance-2/buildroot/support/scripts/fix-rpath target
> make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
> make: Entering directory `/accts/mlweber1/instance-2/buildroot'
> package/lua-bit32/lua-bit32.mk:13: *** LUA_BIT32_SITE cannot be empty
> when LUA_BIT32_SOURCE is not.  Stop.
> make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
> 
> Has anyone else seen errors like these?
> 
> The only modifications I have to the autobuilder script are to use a
> local cache of archives for my BR2_PRIMARY_SITE.  ( we refresh it
> daily out-of-band for internal firewall/proxy download failure
> reasons)   As part of setting BR2_PRIMARY_SITE  we set
> BR2_PRIMARY_SITE_ONLY=y.

Having BR2_PRIMARY_SITE_ONLY=y is going to trigger some download
errors, when your mirror will not contain a tarball that is needed.
Please don't enable BR2_PRIMARY_SITE_ONLY=y if you contribute to the
public autobuild.b.o.

However, I indeed spotted this "unknown" error on coxpcall from your
machine, and wasn't able to reproduce it. Can you investigate what's
going on ?

In the mean time, I would ask you to stop using this BR2_PRIMARY_SITE +
BR2_PRIMARY_SITE_ONLY setup. We don't want to be flooded with "unknown"
errors at this time, especially now that we understand those will
happens for pretty much all luarocks packages in your scenario.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Analysis of build results for 2017-08-14

[Matthew Weber]

Thomas,

On Tue, Aug 15, 2017 at 8:59 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Tue, 15 Aug 2017 07:58:43 -0500, Matthew Weber wrote:
>
>> > All of these are qemu-user failures, due to the host kernel headers
>> > being too old. This error is normally ignored by autobuild-run, but
>> > Julien's autobuilder is running a too old version of autobuild-run. So
>> > I've temporarily added some filtering on the server side to reject such
>> > bogus failures.
>>
>> You're going to see some more unknown builds today (end log snippets
>> below).  I've updated my autobuilder and trying to figure out the
>> following new error.  At this point I disabled my result submissions
>> and doing further testing offline.
>>
>> http://autobuild.buildroot.net/results/e19/e196ceb333f554748081e78858eafb2739e0e317//
>>  [7m>>>   Sanitizing RPATH in target tree [27m
>> /accts/mlweber1/instance-3/buildroot/support/scripts/fix-rpath target
>> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
>> make: Entering directory `/accts/mlweber1/instance-3/buildroot'
>> package/coxpcall/coxpcall.mk:11: *** COXPCALL_SITE cannot be empty
>> when COXPCALL_SOURCE is not.  Stop.
>> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
>>
>>
>> http://autobuild.buildroot.net/results/d3f/d3fa24b5589cc75f040a8f7aedb442ffda9b6814//
>>  [7m>>>   Sanitizing RPATH in target tree [27m
>> /accts/mlweber1/instance-2/buildroot/support/scripts/fix-rpath target
>> make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
>> make: Entering directory `/accts/mlweber1/instance-2/buildroot'
>> package/lua-bit32/lua-bit32.mk:13: *** LUA_BIT32_SITE cannot be empty
>> when LUA_BIT32_SOURCE is not.  Stop.
>> make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
>>
>> Has anyone else seen errors like these?
>>
>> The only modifications I have to the autobuilder script are to use a
>> local cache of archives for my BR2_PRIMARY_SITE.  ( we refresh it
>> daily out-of-band for internal firewall/proxy download failure
>> reasons)   As part of setting BR2_PRIMARY_SITE  we set
>> BR2_PRIMARY_SITE_ONLY=y.
>
> Having BR2_PRIMARY_SITE_ONLY=y is going to trigger some download
> errors, when your mirror will not contain a tarball that is needed.
> Please don't enable BR2_PRIMARY_SITE_ONLY=y if you contribute to the
> public autobuild.b.o.
>
> However, I indeed spotted this "unknown" error on coxpcall from your
> machine, and wasn't able to reproduce it. Can you investigate what's
> going on ?

Sure

>
> In the mean time, I would ask you to stop using this BR2_PRIMARY_SITE +
> BR2_PRIMARY_SITE_ONLY setup. We don't want to be flooded with "unknown"
> errors at this time, especially now that we understand those will
> happens for pretty much all luarocks packages in your scenario.

Yeah, I'm just going to let it run offline for now.

Matt

[Buildroot] Analysis of build results for 2017-08-14

[Arnout Vandecappelle]

On 15-08-17 14:58, Matthew Weber wrote:
> You're going to see some more unknown builds today (end log snippets
> below).  I've updated my autobuilder and trying to figure out the
> following new error.  At this point I disabled my result submissions
> and doing further testing offline.
> 
> http://autobuild.buildroot.net/results/e19/e196ceb333f554748081e78858eafb2739e0e317//
>  [7m>>>   Sanitizing RPATH in target tree [27m
> /accts/mlweber1/instance-3/buildroot/support/scripts/fix-rpath target
> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
> make: Entering directory `/accts/mlweber1/instance-3/buildroot'
> package/coxpcall/coxpcall.mk:11: *** COXPCALL_SITE cannot be empty
> when COXPCALL_SOURCE is not.  Stop.
> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'

 Yes, it's a bug!

 if BR2_PRIMARY_SITE_ONLY=y, then BR2_LUAROCKS_MIRROR is not defined in
Config.in so any lua package has its _SITE set to none so you get this error...
There's a similar issue with the other mirrors, but those always have some path
appended to them (e.g. $(BR2_GNU_MIRROR)/libc) so the _SITE is never empty.

 I think it's best to put the empty _SITE check in an
ifneq ($(BR2_PRIMARY_SITE_ONLY),y)

 Regards,
 Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Analysis of build results for 2017-08-14

[Matthew Weber]

Arnout, Thomas

On Aug 16, 2017 3:23 PM, "Arnout Vandecappelle" <arnout@mind.be> wrote:



On 15-08-17 14:58, Matthew Weber wrote:
> You're going to see some more unknown builds today (end log snippets
> below).  I've updated my autobuilder and trying to figure out the
> following new error.  At this point I disabled my result submissions
> and doing further testing offline.
>
> http://autobuild.buildroot.net/results/e19/e196ceb333f554748081e78858eafb
2739e0e317//
>  [7m>>>   Sanitizing RPATH in target tree [27m
> /accts/mlweber1/instance-3/buildroot/support/scripts/fix-rpath target
> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
> make: Entering directory `/accts/mlweber1/instance-3/buildroot'
> package/coxpcall/coxpcall.mk:11: *** COXPCALL_SITE cannot be empty
> when COXPCALL_SOURCE is not.  Stop.
> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'

 Yes, it's a bug!

 if BR2_PRIMARY_SITE_ONLY=y, then BR2_LUAROCKS_MIRROR is not defined in
Config.in so any lua package has its _SITE set to none so you get this
error...
There's a similar issue with the other mirrors, but those always have some
path
appended to them (e.g. $(BR2_GNU_MIRROR)/libc) so the _SITE is never empty.

 I think it's best to put the empty _SITE check in an
ifneq ($(BR2_PRIMARY_SITE_ONLY),y)


I'll send a patch out tonight.


 Regards,
 Arnout
--
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170816/7e8a501c/attachment.html>

[Buildroot] Analysis of build results for 2017-08-14

[Matthew Weber]

All,

On Wed, Aug 16, 2017 at 6:58 PM, Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
> Arnout, Thomas
>
> On Aug 16, 2017 3:23 PM, "Arnout Vandecappelle" <arnout@mind.be> wrote:
>
>
>
> On 15-08-17 14:58, Matthew Weber wrote:
>> You're going to see some more unknown builds today (end log snippets
>> below).  I've updated my autobuilder and trying to figure out the
>> following new error.  At this point I disabled my result submissions
>> and doing further testing offline.
>>
>>
>> http://autobuild.buildroot.net/results/e19/e196ceb333f554748081e78858eafb2739e0e317//
>>  [7m>>>   Sanitizing RPATH in target tree [27m
>> /accts/mlweber1/instance-3/buildroot/support/scripts/fix-rpath target
>> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
>> make: Entering directory `/accts/mlweber1/instance-3/buildroot'
>> package/coxpcall/coxpcall.mk:11: *** COXPCALL_SITE cannot be empty
>> when COXPCALL_SOURCE is not.  Stop.
>> make: Leaving directory `/accts/mlweber1/instance-3/buildroot'
>
>  Yes, it's a bug!
>
>  if BR2_PRIMARY_SITE_ONLY=y, then BR2_LUAROCKS_MIRROR is not defined in
> Config.in so any lua package has its _SITE set to none so you get this
> error...
> There's a similar issue with the other mirrors, but those always have some
> path
> appended to them (e.g. $(BR2_GNU_MIRROR)/libc) so the _SITE is never empty.
>
>  I think it's best to put the empty _SITE check in an
> ifneq ($(BR2_PRIMARY_SITE_ONLY),y)
>
>

https://patchwork.ozlabs.org/patch/802290/

[Buildroot] Analysis of build results for 2017-08-14

[Thomas Petazzoni]

Hello,

On Wed, 16 Aug 2017 21:00:26 -0500, Matthew Weber wrote:

> >  I think it's best to put the empty _SITE check in an
> > ifneq ($(BR2_PRIMARY_SITE_ONLY),y)
> 
> https://patchwork.ozlabs.org/patch/802290/

I know this is what Arnout suggested, but I'm not sure it's my
preferred fix. Indeed, what about instead dropping the:

if !BR2_PRIMARY_SITE_ONLY
...
endif

condition in Config.in that encloses the definition of BR2_GNU_MIRROR,
BR2_LUAROCKS_MIRROR, etc. ?

Even though I agree such variables are not used when
BR2_PRIMARY_SITE_ONLY=y, I don't see why we hide them. Removing this
condition in Config.in avoids the need for adding another condition in
pkg-generic.mk, and it seems more logical to me.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Analysis of build results for 2017-08-14

[Arnout Vandecappelle]

On 17-08-17 09:09, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 16 Aug 2017 21:00:26 -0500, Matthew Weber wrote:
> 
>>>  I think it's best to put the empty _SITE check in an
>>> ifneq ($(BR2_PRIMARY_SITE_ONLY),y)
>>
>> https://patchwork.ozlabs.org/patch/802290/
> 
> I know this is what Arnout suggested, but I'm not sure it's my
> preferred fix. Indeed, what about instead dropping the:
> 
> if !BR2_PRIMARY_SITE_ONLY
> ...
> endif
> 
> condition in Config.in that encloses the definition of BR2_GNU_MIRROR,
> BR2_LUAROCKS_MIRROR, etc. ?
> 
> Even though I agree such variables are not used when
> BR2_PRIMARY_SITE_ONLY=y, I don't see why we hide them. Removing this
> condition in Config.in avoids the need for adding another condition in
> pkg-generic.mk, and it seems more logical to me.

 Works for me.

 Matthew, sorry for the bad suggestion :-)

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Analysis of build results for 2017-08-14

[Matthew Weber]

Thomas,

On Thu, Aug 17, 2017 at 2:09 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 16 Aug 2017 21:00:26 -0500, Matthew Weber wrote:
>
>> >  I think it's best to put the empty _SITE check in an
>> > ifneq ($(BR2_PRIMARY_SITE_ONLY),y)
>>
>> https://patchwork.ozlabs.org/patch/802290/
>
> I know this is what Arnout suggested, but I'm not sure it's my
> preferred fix. Indeed, what about instead dropping the:
>
> if !BR2_PRIMARY_SITE_ONLY
> ...
> endif
>
> condition in Config.in that encloses the definition of BR2_GNU_MIRROR,
> BR2_LUAROCKS_MIRROR, etc. ?
>
> Even though I agree such variables are not used when
> BR2_PRIMARY_SITE_ONLY=y, I don't see why we hide them. Removing this
> condition in Config.in avoids the need for adding another condition in
> pkg-generic.mk, and it seems more logical to me.
>

So still keep the condition around BR2_BACKUP_SITE, right?  (remove
from around the rest(LUA/CPAN/GNU/KERNEL))

Matt

[Buildroot] Analysis of build results for 2017-08-14

[Arnout Vandecappelle]

On 17-08-17 14:01, Matthew Weber wrote:
> Thomas,
> 
> On Thu, Aug 17, 2017 at 2:09 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Wed, 16 Aug 2017 21:00:26 -0500, Matthew Weber wrote:
>>
>>>>  I think it's best to put the empty _SITE check in an
>>>> ifneq ($(BR2_PRIMARY_SITE_ONLY),y)
>>>
>>> https://patchwork.ozlabs.org/patch/802290/
>>
>> I know this is what Arnout suggested, but I'm not sure it's my
>> preferred fix. Indeed, what about instead dropping the:
>>
>> if !BR2_PRIMARY_SITE_ONLY
>> ...
>> endif
>>
>> condition in Config.in that encloses the definition of BR2_GNU_MIRROR,
>> BR2_LUAROCKS_MIRROR, etc. ?
>>
>> Even though I agree such variables are not used when
>> BR2_PRIMARY_SITE_ONLY=y, I don't see why we hide them. Removing this
>> condition in Config.in avoids the need for adding another condition in
>> pkg-generic.mk, and it seems more logical to me.
>>
> 
> So still keep the condition around BR2_BACKUP_SITE, right?  (remove
> from around the rest(LUA/CPAN/GNU/KERNEL))

 Also remove it from backup site, I think. That way, you can toggle the
PRIMARY_ONLY condition without loosing the rest of your _SITE configurations. I
think that that's why Thomas calls it more logical. The purpose of PRIMARY_ONLY
is to be able to toggle it, cfr. the commit log that added it:

commit 5a83e0849964c5160b980bb57ce89e28684a7dbb
Author: Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>
Date:   Fri Jun 22 07:37:03 2012

    Package downloads: allow restricting to primary site only

    This patch adds a new config option BR2_PRIMARY_SITE_ONLY that, when set,
    restricts package downloads to the specified BR2_PRIMARY_SITE. If the package
    is not present on the primary site, the download fails.

    This is useful for project developers who want to ensure that the project can
    be built even if the upstream tarball locations disappear.

    [thomas.petazzoni at free-electrons.com:
     Extend config option help message with more details coming from the
     commit log. Added a dependency on the fact that a primary site has
     been defined. Without any primary site (the default configuration),
     this new option does not make any sense.]

    Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
    Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>



 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Analysis of build results for 2017-08-14

[Arnout Vandecappelle]

On 15-08-17 14:20, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 15 Aug 2017 08:31:02 +0200 (CEST), Thomas Petazzoni wrote:
> 

>>          arm | gmrender-resurrect-33600ab6... | NOK | http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f |     
> 
> /home/buildroot/autobuild/run/instance-2/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgstreamer-1.0.a(libgstreamer_1.0_la-gstinfo.o): In function `generate_unwind_trace':
> /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2687: undefined reference to `_ULarm_init_local'
> /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2694: undefined reference to `_ULarm_step'
> /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2717: undefined reference to `_ULarm_get_proc_name'
> 
> No idea. It's happening in a static linking configuration. Not sure
> what is supposed to provide those symbols.

 They are from libunwind.


> Gustavo is listed in the DEVELOPERS file for this package, but I don't
> think he is going to be active in fixing this. Anyone else to look into
> that ?

 Perhaps we should remove Gustavo from DEVELOPERS entirely?

>>      powerpc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/2948ec94cc4f5f98f296fa487c481e971721cff8 | ORPH
> 
> GCC ICE :
> 
> tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in validate_condition_mode, at config/rs6000/rs6000.c:17988
> 
> Weird, we're using a modern gcc version here, on a fairly well-known
> architecture. Google doesn't know much about this ICE, so perhaps we
> should report it upstream to gcc.
> 
> 
>>       x86_64 |                     ruby-2.4.1 | NOK | http://autobuild.buildroot.net/results/8f0342b7b88df979a59fdab574b2489628d7ffa5 | ORPH
> 
> Not sure what's happening here:
> 
> linking shared-library libruby.so.2.4.1
> libruby.so.2.4.1: final close failed: Invalid operation
> collect2: error: ld returned 1 exit status
> 
> Anyone to look into this ?

 Perhaps an instance of https://sourceware.org/bugzilla/show_bug.cgi?id=20006 ?
Not sure if that patch has been applied to the sourcery toolchain - it should
be, since the binutils 2.26 fix was committed in April 2016 and the toolchain is
from November, but it's hard to be sure.



 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Analysis of build results for 2017-08-14

[Thomas Petazzoni]

Hello,

On Wed, 16 Aug 2017 22:35:05 +0200, Arnout Vandecappelle wrote:

> >>          arm | gmrender-resurrect-33600ab6... | NOK | http://autobuild.buildroot.net/results/0a3a2485c187a000482c178f1e9c64dd716a858f |       
> > 
> > /home/buildroot/autobuild/run/instance-2/output/host/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgstreamer-1.0.a(libgstreamer_1.0_la-gstinfo.o): In function `generate_unwind_trace':
> > /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2687: undefined reference to `_ULarm_init_local'
> > /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2694: undefined reference to `_ULarm_step'
> > /home/buildroot/autobuild/run/instance-2/output/build/gstreamer1-1.12.2/gst/gstinfo.c:2717: undefined reference to `_ULarm_get_proc_name'
> > 
> > No idea. It's happening in a static linking configuration. Not sure
> > what is supposed to provide those symbols.  
> 
>  They are from libunwind.

OK, so we need to look at what's going on here.

> > Gustavo is listed in the DEVELOPERS file for this package, but I don't
> > think he is going to be active in fixing this. Anyone else to look into
> > that ?  
> 
>  Perhaps we should remove Gustavo from DEVELOPERS entirely?

Yes, perhaps we should do that. Not sure if it's too early to do that
or not.

> >>       x86_64 |                     ruby-2.4.1 | NOK | http://autobuild.buildroot.net/results/8f0342b7b88df979a59fdab574b2489628d7ffa5 | ORPH  
> > 
> > Not sure what's happening here:
> > 
> > linking shared-library libruby.so.2.4.1
> > libruby.so.2.4.1: final close failed: Invalid operation
> > collect2: error: ld returned 1 exit status
> > 
> > Anyone to look into this ?  
> 
>  Perhaps an instance of https://sourceware.org/bugzilla/show_bug.cgi?id=20006 ?
> Not sure if that patch has been applied to the sourcery toolchain - it should
> be, since the binutils 2.26 fix was committed in April 2016 and the toolchain is
> from November, but it's hard to be sure.

If you look at http://autobuild.buildroot.net/?reason=ruby-2.4.1, this
issue only appeared two times: in July 2017 and August 2017. This
Sourcery toolchain has been around for much longer, and was last bumped
in December 2016.

So if it was just the Sourcery toolchain being unable to build
ruby-2.4.1, I think we would have a lot more failures than that. So it
might be a toolchain issue, but that occurs under very specific
conditions.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Analysis of build results for 2017-08-14

[Arnout Vandecappelle]

On 16-08-17 22:53, Thomas Petazzoni wrote:
>>>>       x86_64 |                     ruby-2.4.1 | NOK | http://autobuild.buildroot.net/results/8f0342b7b88df979a59fdab574b2489628d7ffa5 | ORPH  
>>> Not sure what's happening here:
>>>
>>> linking shared-library libruby.so.2.4.1
>>> libruby.so.2.4.1: final close failed: Invalid operation
>>> collect2: error: ld returned 1 exit status
>>>
>>> Anyone to look into this ?  
>>  Perhaps an instance of https://sourceware.org/bugzilla/show_bug.cgi?id=20006 ?
>> Not sure if that patch has been applied to the sourcery toolchain - it should
>> be, since the binutils 2.26 fix was committed in April 2016 and the toolchain is
>> from November, but it's hard to be sure.
> If you look at http://autobuild.buildroot.net/?reason=ruby-2.4.1, this
> issue only appeared two times: in July 2017 and August 2017. This
> Sourcery toolchain has been around for much longer, and was last bumped
> in December 2016.

 As another point of reference: it didn't occur for ruby-2.4.0.

> So if it was just the Sourcery toolchain being unable to build
> ruby-2.4.1, I think we would have a lot more failures than that. So it
> might be a toolchain issue, but that occurs under very specific
> conditions.

 ruby has a bunch of optional dependencies, so yes indeed it only occurs for
some exotic combination of these dependencies.

 So I checked the source of the Sourcery toolchain and it does NOT have the
patch of bug 20006 applied, even though it was released in binutils 2.26.1, 4
months before the Sourcery release...

 So, we could try to find out which exact combination of packages triggers this
issue, but is that worth it for something that happens twice in five months...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Analysis of build results for 2017-08-14

[Thomas Petazzoni]

Hello,

On Thu, 17 Aug 2017 00:48:10 +0200, Arnout Vandecappelle wrote:

> > So if it was just the Sourcery toolchain being unable to build
> > ruby-2.4.1, I think we would have a lot more failures than that. So it
> > might be a toolchain issue, but that occurs under very specific
> > conditions.  
> 
>  ruby has a bunch of optional dependencies, so yes indeed it only occurs for
> some exotic combination of these dependencies.
> 
>  So I checked the source of the Sourcery toolchain and it does NOT have the
> patch of bug 20006 applied, even though it was released in binutils 2.26.1, 4
> months before the Sourcery release...
> 
>  So, we could try to find out which exact combination of packages triggers this
> issue, but is that worth it for something that happens twice in five months...

True, but it's annoying to have those sporadic failures once in a
while :-/

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com