* [Buildroot] [autobuild.buildroot.net] Build results for 2017-08-14
@ 2017-08-15 6:31 Thomas Petazzoni
2017-08-15 12:20 ` [Buildroot] Analysis of build " Thomas Petazzoni
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2017-08-15 6:31 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-15 6:31 [Buildroot] [autobuild.buildroot.net] Build results for 2017-08-14 Thomas Petazzoni
@ 2017-08-15 12:20 ` Thomas Petazzoni
2017-08-15 12:58 ` Matthew Weber
2017-08-16 20:35 ` Arnout Vandecappelle
0 siblings, 2 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2017-08-15 12:20 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-15 12:20 ` [Buildroot] Analysis of build " Thomas Petazzoni
@ 2017-08-15 12:58 ` Matthew Weber
2017-08-15 13:59 ` Thomas Petazzoni
2017-08-16 20:22 ` Arnout Vandecappelle
2017-08-16 20:35 ` Arnout Vandecappelle
1 sibling, 2 replies; 16+ messages in thread
From: Matthew Weber @ 2017-08-15 12:58 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-15 12:58 ` Matthew Weber
@ 2017-08-15 13:59 ` Thomas Petazzoni
2017-08-15 14:15 ` Matthew Weber
2017-08-16 20:22 ` Arnout Vandecappelle
1 sibling, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2017-08-15 13:59 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-15 13:59 ` Thomas Petazzoni
@ 2017-08-15 14:15 ` Matthew Weber
0 siblings, 0 replies; 16+ messages in thread
From: Matthew Weber @ 2017-08-15 14:15 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-15 12:58 ` Matthew Weber
2017-08-15 13:59 ` Thomas Petazzoni
@ 2017-08-16 20:22 ` Arnout Vandecappelle
2017-08-16 23:58 ` Matthew Weber
1 sibling, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle @ 2017-08-16 20:22 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-15 12:20 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-08-15 12:58 ` Matthew Weber
@ 2017-08-16 20:35 ` Arnout Vandecappelle
2017-08-16 20:53 ` Thomas Petazzoni
1 sibling, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle @ 2017-08-16 20:35 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-16 20:35 ` Arnout Vandecappelle
@ 2017-08-16 20:53 ` Thomas Petazzoni
2017-08-16 22:48 ` Arnout Vandecappelle
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Petazzoni @ 2017-08-16 20:53 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-16 20:53 ` Thomas Petazzoni
@ 2017-08-16 22:48 ` Arnout Vandecappelle
2017-08-17 7:47 ` Thomas Petazzoni
0 siblings, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle @ 2017-08-16 22:48 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-16 20:22 ` Arnout Vandecappelle
@ 2017-08-16 23:58 ` Matthew Weber
2017-08-17 2:00 ` Matthew Weber
0 siblings, 1 reply; 16+ messages in thread
From: Matthew Weber @ 2017-08-16 23:58 UTC (permalink / raw)
To: buildroot
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>
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-16 23:58 ` Matthew Weber
@ 2017-08-17 2:00 ` Matthew Weber
2017-08-17 7:09 ` Thomas Petazzoni
0 siblings, 1 reply; 16+ messages in thread
From: Matthew Weber @ 2017-08-17 2:00 UTC (permalink / raw)
To: buildroot
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/
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-17 2:00 ` Matthew Weber
@ 2017-08-17 7:09 ` Thomas Petazzoni
2017-08-17 7:36 ` Arnout Vandecappelle
2017-08-17 12:01 ` Matthew Weber
0 siblings, 2 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2017-08-17 7:09 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-17 7:09 ` Thomas Petazzoni
@ 2017-08-17 7:36 ` Arnout Vandecappelle
2017-08-17 12:01 ` Matthew Weber
1 sibling, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle @ 2017-08-17 7:36 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-16 22:48 ` Arnout Vandecappelle
@ 2017-08-17 7:47 ` Thomas Petazzoni
0 siblings, 0 replies; 16+ messages in thread
From: Thomas Petazzoni @ 2017-08-17 7:47 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-17 7:09 ` Thomas Petazzoni
2017-08-17 7:36 ` Arnout Vandecappelle
@ 2017-08-17 12:01 ` Matthew Weber
2017-08-17 12:15 ` Arnout Vandecappelle
1 sibling, 1 reply; 16+ messages in thread
From: Matthew Weber @ 2017-08-17 12:01 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] Analysis of build results for 2017-08-14
2017-08-17 12:01 ` Matthew Weber
@ 2017-08-17 12:15 ` Arnout Vandecappelle
0 siblings, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle @ 2017-08-17 12:15 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-08-17 12:15 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-08-15 6:31 [Buildroot] [autobuild.buildroot.net] Build results for 2017-08-14 Thomas Petazzoni
2017-08-15 12:20 ` [Buildroot] Analysis of build " Thomas Petazzoni
2017-08-15 12:58 ` Matthew Weber
2017-08-15 13:59 ` Thomas Petazzoni
2017-08-15 14:15 ` Matthew Weber
2017-08-16 20:22 ` Arnout Vandecappelle
2017-08-16 23:58 ` Matthew Weber
2017-08-17 2:00 ` Matthew Weber
2017-08-17 7:09 ` Thomas Petazzoni
2017-08-17 7:36 ` Arnout Vandecappelle
2017-08-17 12:01 ` Matthew Weber
2017-08-17 12:15 ` Arnout Vandecappelle
2017-08-16 20:35 ` Arnout Vandecappelle
2017-08-16 20:53 ` Thomas Petazzoni
2017-08-16 22:48 ` Arnout Vandecappelle
2017-08-17 7:47 ` Thomas Petazzoni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox