[Buildroot] [autobuild.buildroot.net] Build results for 2014-04-19

[Buildroot] [autobuild.buildroot.net] Build results for 2014-04-19

[Thomas Petazzoni]

Build statistics for 2014-04-19
===============================

        success : 54 
       failures : 17 
       timeouts : 1  
          TOTAL : 72 

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

           host-nodejs-0.10.12 | 2 
                rtorrent-0.9.3 | 1 
                    php-5.5.11 | 1 
                  opencv-2.4.2 | 1 
                  zeromq-4.0.4 | 1 
                  cppcms-1.0.4 | 1 
                  nftables-0.2 | 1 
                   libgc-7.4.0 | 1 
        gst1-plugins-bad-1.2.3 | 1 
jack2-37976441044d69b91d61d... | 1 
libstrophe-d408eaf2bbfe5ff5... | 1 
                 libpfm4-4.3.0 | 1 
  CXX      DerivedSources/W... | 1 
ne10-88c18f02199947b2c8b577... | 1 
             lttng-tools-2.4.0 | 1 
                 cairo-1.12.10 | 1 
                 python3-3.4.0 | 1 

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

    x86_64 |   CXX      DerivedSources/W... | TIM | http://autobuild.buildroot.net/results/a3a8607751156fb47dc5c145fcd46825a93078dc/
      bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/5c181b1fb8f0e9e39f864523e84dd8766f5a67b8/
   powerpc |                   cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/b093b0edc9b7ac1f113349c09ed3c04967726d31/
       arm |         gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/0aab79be8043bf88a227af2ca27b4447aa2f8901/
      i686 |            host-nodejs-0.10.12 | NOK | http://autobuild.buildroot.net/results/114df8d99e802b69a39804e0608b022419d912b4/
       arm |            host-nodejs-0.10.12 | NOK | http://autobuild.buildroot.net/results/505091df8b1b48c77ee2d6c67ef337df16ca67b7/
       arm | jack2-37976441044d69b91d61d... | NOK | http://autobuild.buildroot.net/results/29cf31a7d20a85e3b33a6d30ac59b49688c54c3d/
    x86_64 |                    libgc-7.4.0 | NOK | http://autobuild.buildroot.net/results/1ec3535a3b476122292dc9582416eb54d7d784c8/
       arc |                  libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/a545e499241b9b67848eb9abc989180a32317f0f/
      bfin | libstrophe-d408eaf2bbfe5ff5... | NOK | http://autobuild.buildroot.net/results/f48a0f34094505402ee0618189de178ace062ce2/
       arm |              lttng-tools-2.4.0 | NOK | http://autobuild.buildroot.net/results/082078c70b6923b8d98d27e2475d001e1e5a2487/
       arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/a8a20b53f748ecfe38f3a3d6f4c6c7199edf287f/
    mipsel |                   nftables-0.2 | NOK | http://autobuild.buildroot.net/results/1525d7a3e1d1fcf35858962251c0b69a5e1b64db/
       arm |                   opencv-2.4.2 | NOK | http://autobuild.buildroot.net/results/a5360b73266af53ce92e48b0285987e674baa9ab/
       arm |                     php-5.5.11 | NOK | http://autobuild.buildroot.net/results/5a7fd0de2747e876a182117d7f7d8f16b20cadea/
     avr32 |                  python3-3.4.0 | NOK | http://autobuild.buildroot.net/results/7a65e381cc04bf8f74fd63a6dcda502f3c26aeef/
     nios2 |                 rtorrent-0.9.3 | NOK | http://autobuild.buildroot.net/results/f7d61452aec2edaf7207a01d0fd7c9c4fbe031e0/
      bfin |                   zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/4d8222f02b5f88622bef9ad57ebd6e419c9d2cba/


-- 
http://autobuild.buildroot.net

[Buildroot] Analysis of build results for 2014-04-19

[Thomas Petazzoni]

Hello,

The usual analysis of build failures.

On Sun, 20 Apr 2014 08:30:09 +0200 (CEST), Thomas Petazzoni wrote:

>     x86_64 |   CXX      DerivedSources/W... | TIM | http://autobuild.buildroot.net/results/a3a8607751156fb47dc5c145fcd46825a93078dc/

Once again, timeout while building webkit.

>       bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/5c181b1fb8f0e9e39f864523e84dd8766f5a67b8/

fork() being used by one part of Cairo. We probably shouldn't mark
Cairo entirely dependent on MMU, but identify the part of Cairo that
uses fork().

make[6]: Entering directory `/home/test/test/1/output/build/cairo-1.12.10/boilerplate'
  CC     cairo-boilerplate-getopt.lo
  CC     any2ppm-any2ppm.o
cairo-boilerplate-getopt.c: In function 'increment_index':
cairo-boilerplate-getopt.c:62: warning: cannot optimize possibly infinite loops
any2ppm.c: In function 'daemonize':
any2ppm.c:722: error: implicit declaration of function 'fork'
make[5]: *** [any2ppm-any2ppm.o] Error 1
make[5]: *** Waiting for unfinished jobs....

>    powerpc |                   cppcms-1.0.4 | NOK | http://autobuild.buildroot.net/results/b093b0edc9b7ac1f113349c09ed3c04967726d31/

/home/test/test/3/output/build/cppcms-1.0.4/booster/lib/locale/src/encoding/codepage.cpp:42:35: error: 'converter_between' was not declared in this scope
/home/test/test/3/output/build/cppcms-1.0.4/booster/lib/locale/src/encoding/codepage.cpp:42:52: error: template argument 1 is invalid
/home/test/test/3/output/build/cppcms-1.0.4/booster/lib/locale/src/encoding/codepage.cpp:42:57: error: invalid type in declaration before ';' token

These functions can be provided by three implementations inside cppcms:

 * One that needs iconv
 * One that needs icu
 * One which is called wconv, which I assume is related to wide-char
   but I'm not sure at all, and I haven't found any confirmation of
   this.

Nicolas, you are the person who added cppcms in Buildroot. Could you
have a look at this problem?

>        arm |         gst1-plugins-bad-1.2.3 | NOK | http://autobuild.buildroot.net/results/0aab79be8043bf88a227af2ca27b4447aa2f8901/

Samuel?

  CXX      libgstopencv_la-motioncells_wrapper.lo
gstdisparity.cpp:124:39: fatal error: opencv2/contrib/contrib.hpp: No such file or directory
 #include <opencv2/contrib/contrib.hpp>

>       i686 |            host-nodejs-0.10.12 | NOK | http://autobuild.buildroot.net/results/114df8d99e802b69a39804e0608b022419d912b4/
>        arm |            host-nodejs-0.10.12 | NOK | http://autobuild.buildroot.net/results/505091df8b1b48c77ee2d6c67ef337df16ca67b7/

Still the same problem. Need to reproduce.

>        arm | jack2-37976441044d69b91d61d... | NOK | http://autobuild.buildroot.net/results/29cf31a7d20a85e3b33a6d30ac59b49688c54c3d/

Python problem:

  File "/scratch/peko/build/jack2-37976441044d69b91d61d8f6278949a39cf1b7b7/example-clients/wscript", line 126
    if bld.env['IS_WINDOWS']:

>     x86_64 |                    libgc-7.4.0 | NOK | http://autobuild.buildroot.net/results/1ec3535a3b476122292dc9582416eb54d7d784c8/

mach_dep.c:205:23: fatal error: fenv.h: No such file or directory

We don't build uClibc with fenv support. We could fix this problem by
passing NO_GETCONTEXT when building libgc on uClibc.

>        arc |                  libpfm4-4.3.0 | NOK | http://autobuild.buildroot.net/results/a545e499241b9b67848eb9abc989180a32317f0f/

cc1: all warnings being treated as errors

>       bfin | libstrophe-d408eaf2bbfe5ff5... | NOK | http://autobuild.buildroot.net/results/f48a0f34094505402ee0618189de178ace062ce2/

checking for libxml/parser.h... no
configure: error: couldn't find libxml2
make: *** [/home/test/test/3/output/build/libstrophe-d408eaf2bbfe5ff5c56eab01463c278f9891c08e/.stamp_configured] Error 1

>        arm |              lttng-tools-2.4.0 | NOK | http://autobuild.buildroot.net/results/082078c70b6923b8d98d27e2475d001e1e5a2487/

  CC       consumer-stream.lo
consumer-timer.c: In function 'consumer_timer_thread':
consumer-timer.c:518:1: internal compiler error: in gen_movsi, at config/arm/arm.md:5452
Please submit a full bug report,
with preprocessed source if appropriate.

Nobody ever answered me on how to handle gcc bugs affecting custom
external toolchains...

>        arm | ne10-88c18f02199947b2c8b577... | NOK | http://autobuild.buildroot.net/results/a8a20b53f748ecfe38f3a3d6f4c6c7199edf287f/

Lots of errors... there isn't enough backlog to see the beginning of
them. Need to reproduce.

>     mipsel |                   nftables-0.2 | NOK | http://autobuild.buildroot.net/results/1525d7a3e1d1fcf35858962251c0b69a5e1b64db/

There is a fix proposed by Baruch.

>        arm |                   opencv-2.4.2 | NOK | http://autobuild.buildroot.net/results/a5360b73266af53ce92e48b0285987e674baa9ab/

Gaah, another compiler failure.

/home/test/test/1/output/build/opencv-2.4.2/modules/imgproc/src/smooth.cpp:525:1: internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5468
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [modules/imgproc/CMakeFiles/opencv_imgproc.dir/src/smooth.cpp.o] Error 1

>        arm |                     php-5.5.11 | NOK | http://autobuild.buildroot.net/results/5a7fd0de2747e876a182117d7f7d8f16b20cadea/

checking for init_snmp in -lnetsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for more information.
make: *** [/home/test/test/3/output/build/php-5.5.11/.stamp_configured] Error 1

Gustavo, Luca?

>      avr32 |                  python3-3.4.0 | NOK | http://autobuild.buildroot.net/results/7a65e381cc04bf8f74fd63a6dcda502f3c26aeef/

Still on my plate to fix.

>      nios2 |                 rtorrent-0.9.3 | NOK | http://autobuild.buildroot.net/results/f7d61452aec2edaf7207a01d0fd7c9c4fbe031e0/

The infamous fallocate64 problem. Ezequiel?

>       bfin |                   zeromq-4.0.4 | NOK | http://autobuild.buildroot.net/results/4d8222f02b5f88622bef9ad57ebd6e419c9d2cba/

fork() used in zeromq test cases:

  CXX    test_fork.o
test_fork.cpp: In function 'int main()':
test_fork.cpp:38: error: 'fork' was not declared in this scope

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

[Buildroot] Analysis of build results for 2014-04-19

[Mike Zick]

On Sun, 20 Apr 2014 10:48:12 +0200
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

>   CC       consumer-stream.lo
> consumer-timer.c: In function 'consumer_timer_thread':
> consumer-timer.c:518:1: internal compiler error: in gen_movsi, at
> config/arm/arm.md:5452 Please submit a full bug report,
> with preprocessed source if appropriate.
> 

I seem to remember that message usually having a (missing here)
line with the bug report URL.
It is (or was) one of the build time options.

> Nobody ever answered me on how to handle gcc bugs affecting custom
> external toolchains...
> 

Directions should be in doc/<version>/README.bugs of the documentation -
Which probably was not shipped and/or installed with the compiler.  ;)

In general, the bug report goes to the builder of the binary,
not to gcc.gnu.org

In the case of a gcc binary built by Buildroot, that would be
Buildroot.org.
Ah, but it is already here.  ;)

Duh...

For the auto-builder, I guess all you can do is exclude the 
vendor/arch/gcc-version that exhibits an ICE.

Mike

[Buildroot] Analysis of build results for 2014-04-19

[Luca Ceresoli]

Hi Thomas,

Thomas Petazzoni wrote:
...
>>         arm |                     php-5.5.11 | NOK | http://autobuild.buildroot.net/results/5a7fd0de2747e876a182117d7f7d8f16b20cadea/
>
> checking for init_snmp in -lnetsnmp... no
> configure: error: SNMP sanity check failed. Please check config.log for more information.
> make: *** [/home/test/test/3/output/build/php-5.5.11/.stamp_configured] Error 1
>
> Gustavo, Luca?
>

My bad, it built perfectly here! Tried uninstalling net-snmp from my
host, as well as installing it with -dev packages. It always built fine.

FWIW, my build machine is a 64-bit Ubuntu 13.10.

Can you share the output/build/php-5.5.11/config.log file from your
build server please?

-- 
Luca

[Buildroot] php / snmp / iconv problem

[Thomas Petazzoni]

Dear Luca Ceresoli,

On Mon, 21 Apr 2014 19:35:50 +0200, Luca Ceresoli wrote:

> My bad, it built perfectly here! Tried uninstalling net-snmp from my
> host, as well as installing it with -dev packages. It always built fine.
> 
> FWIW, my build machine is a 64-bit Ubuntu 13.10.
> 
> Can you share the output/build/php-5.5.11/config.log file from your
> build server please?

Sure. So, as expected, the error is:

===============================================
checking OpenSSL dir for SNMP... no
checking for init_snmp in -lnetsnmp... no
configure: error: SNMP sanity check failed. Please check config.log for more information.
make: *** [/home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/build/php-5.5.11/.stamp_configured] Error 1
===============================================

In config.log, we see that:

===============================================
configure:83770: checking for init_snmp in -lnetsnmp
configure:83795: /home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/host/usr/bin/arm-none-linux-gnueabi-gcc -o conftest -I/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os  -fvisibility=hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/lib  -L/home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib conftest.c -lnetsnmp  -lgmp -lz -lpcre -lcrypto -lssl -lcrypto -lm  -lxml2 -lz -lm -ldl -
lxml2 -lz -lm -ldl -lnetsnmp -lcrypto -lm >&5
/home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/lib" is unsafe for cross-compilation
/lib/libgcc_s.so.1: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
===============================================

So the problem is due to /lib being present in the -L flags. This is
most likely due to:

ifeq ($(BR2_PACKAGE_PHP_EXT_ICONV),y)
ifeq ($(BR2_PACKAGE_LIBICONV),y)
        PHP_CONF_OPT += --with-iconv=$(STAGING_DIR)/usr
        PHP_DEPENDENCIES += libiconv
else
        PHP_CONF_OPT += --with-iconv
endif
endif

We are in a case where BR2_PACKAGE_PHP_EXT_ICONV=y but
BR2_PACKAGE_LIBICONV is not enabled (glibc toolchain). So the iconv
test of PHP starts looking in /lib for iconv. I think we already
discussed this problem with Gustavo. See "[PATCH] php: fix wrong -L and
-I paths added by iconv tests" in the mailing list archive.

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

[Buildroot] php / snmp / iconv problem

[Gustavo Zacarias]

On 04/22/2014 05:25 PM, Thomas Petazzoni wrote:
> Sure. So, as expected, the error is:
> 
> ===============================================
> checking OpenSSL dir for SNMP... no
> checking for init_snmp in -lnetsnmp... no
> configure: error: SNMP sanity check failed. Please check config.log for more information.
> make: *** [/home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/build/php-5.5.11/.stamp_configured] Error 1
> ===============================================
> 
> In config.log, we see that:
> 
> ===============================================
> configure:83770: checking for init_snmp in -lnetsnmp
> configure:83795: /home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/host/usr/bin/arm-none-linux-gnueabi-gcc -o conftest -I/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os  -fvisibility=hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/lib  -L/home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/host/usr/arm-buildroot-linux-gnueabi/sysroot/usr/lib conftest.c -lnetsnmp  -lgmp -lz -lpcre -lcrypto -lssl -lcrypto -lm  -lxml2 -lz -lm -ldl -
> lxml2 -lz -lm -ldl -lnetsnmp -lcrypto -lm >&5
> /home/test/outputs/5a7fd0de2747e876a182117d7f7d8f16b20cadea/output/host/opt/ext-toolchain/bin/../lib/gcc/arm-none-linux-gnueabi/4.7.3/../../../../arm-none-linux-gnueabi/bin/ld: warning: library search path "/lib" is unsafe for cross-compilation
> /lib/libgcc_s.so.1: file not recognized: File format not recognized
> collect2: error: ld returned 1 exit status
> ===============================================
> 
> So the problem is due to /lib being present in the -L flags. This is
> most likely due to:
> 
> ifeq ($(BR2_PACKAGE_PHP_EXT_ICONV),y)
> ifeq ($(BR2_PACKAGE_LIBICONV),y)
>         PHP_CONF_OPT += --with-iconv=$(STAGING_DIR)/usr
>         PHP_DEPENDENCIES += libiconv
> else
>         PHP_CONF_OPT += --with-iconv
> endif
> endif
> 
> We are in a case where BR2_PACKAGE_PHP_EXT_ICONV=y but
> BR2_PACKAGE_LIBICONV is not enabled (glibc toolchain). So the iconv
> test of PHP starts looking in /lib for iconv. I think we already
> discussed this problem with Gustavo. See "[PATCH] php: fix wrong -L and
> -I paths added by iconv tests" in the mailing list archive.

Hi.
Ok, hopefully i've finally solved this php 'nuisance'.
Ugly patch sent in need of heavy testing, it should solve many (all?) of
the php autobuild failures related to iconv.
I really don't want to see this b****** again, fingers crossed, i'm not
a fan of modifying configure directly but there seem to be no other
choice at the moment.
Also php upstream should really take a hard look at hardcoding paths and
using test instead of AC_TRY_LINK to check for headers, that's very dirty.
Regards.

[Buildroot] Analysis of build results for 2014-04-19

[Arnout Vandecappelle]

On 20/04/14 10:48, Thomas Petazzoni wrote:
> On Sun, 20 Apr 2014 08:30:09 +0200 (CEST), Thomas Petazzoni wrote:
> 
>> >     x86_64 |   CXX      DerivedSources/W... | TIM | http://autobuild.buildroot.net/results/a3a8607751156fb47dc5c145fcd46825a93078dc/
> Once again, timeout while building webkit.
> 

 I think there should be two changes to the autobuilders.

- Reduce the % yes. With the growing number of packages, the number of
selected packages is also becoming unrealistically large.

- If webkit is selected, increase the timeout with an hour. I don't know
how easy that is, though.

 It would of course be even better if the autobuilder would calculate the
timeout based on historical information from build-time.log, but I guess
that's a bit too ambitious :-)

 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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Analysis of build results for 2014-04-19

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 22 Apr 2014 18:41:34 +0200, Arnout Vandecappelle wrote:

>  I think there should be two changes to the autobuilders.
> 
> - Reduce the % yes. With the growing number of packages, the number of
> selected packages is also becoming unrealistically large.

True. Currently the KCONFIG_PROBABILITY is chosen between 1% and 35%.
Should I reduce that to 30% ? 25% ?

> - If webkit is selected, increase the timeout with an hour. I don't know
> how easy that is, though.

Not easy with the current horrible script, because the timeout is
chosen in a shell script that runs the Python script that actually
generates the configuration and runs the build.

So let's say that I'll reduce the KCONFIG_PROBABILITY on one side, and
increase the timeout for all builds by an hour on the other side. How
does that look?

>  It would of course be even better if the autobuilder would calculate the
> timeout based on historical information from build-time.log, but I guess
> that's a bit too ambitious :-)

Hmmm, sounds fun! But I'd prefer to keep the autobuilder logic smaller
in size than Buildroot itself, if possible :-)

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

[Buildroot] Analysis of build results for 2014-04-19

[Arnout Vandecappelle]

On 22/04/14 22:19, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Tue, 22 Apr 2014 18:41:34 +0200, Arnout Vandecappelle wrote:
> 
>>  I think there should be two changes to the autobuilders.
>>
>> - Reduce the % yes. With the growing number of packages, the number of
>> selected packages is also becoming unrealistically large.
> 
> True. Currently the KCONFIG_PROBABILITY is chosen between 1% and 35%.
> Should I reduce that to 30% ? 25% ?

 25% still means 300 packages, and I think that that doesn't even include
their dependencies. Isn't that exaggerated? I think that any defconfig
with more than 50 packages is not very realistic anymore...

 Also, the interesting failures (with missing dependencies) are more
likely to fall out when less packages are selected, right?

 So my suggestion is to reduce the probability to 15% (still 180 packages
in the defconfig...).

>> - If webkit is selected, increase the timeout with an hour. I don't know
>> how easy that is, though.
> 
> Not easy with the current horrible script, because the timeout is
> chosen in a shell script that runs the Python script that actually
> generates the configuration and runs the build.
> 
> So let's say that I'll reduce the KCONFIG_PROBABILITY on one side, and
> increase the timeout for all builds by an hour on the other side. How
> does that look?

 The timeout is already 4 hours, isn't it? That's already quite long IMHO.


 Regards,
 Arnout

> 
>>  It would of course be even better if the autobuilder would calculate the
>> timeout based on historical information from build-time.log, but I guess
>> that's a bit too ambitious :-)
> 
> Hmmm, sounds fun! But I'd prefer to keep the autobuilder logic smaller
> in size than Buildroot itself, if possible :-)
> 
> Thomas
> 


-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Analysis of build results for 2014-04-19

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 23 Apr 2014 00:14:26 +0200, Arnout Vandecappelle wrote:

> > True. Currently the KCONFIG_PROBABILITY is chosen between 1% and 35%.
> > Should I reduce that to 30% ? 25% ?
> 
>  25% still means 300 packages, and I think that that doesn't even include
> their dependencies. Isn't that exaggerated? I think that any defconfig
> with more than 50 packages is not very realistic anymore...
> 
>  Also, the interesting failures (with missing dependencies) are more
> likely to fall out when less packages are selected, right?
> 
>  So my suggestion is to reduce the probability to 15% (still 180 packages
> in the defconfig...).

Not really, because your calculations make the assumption that there is
one BR2_PACKAGE_<foo> option per package. But that's not true: certain
packages have several, sometimes dozens of BR2_PACKAGE_<foo> options
(think Qt4, Qt5, Python, etc.). And the percentage of randomization is
done per BR2_PACKAGE_<foo> options, not per package.

A quick analysis shows a total of 2832 BR2_PACKAGE_<foo> options
defined in Buildroot for around 1200 packages, so in average we have a
little more than 2 Config.in options per package.

Also, by having a much smaller percentage, I'm wondering if we have a
lot less chances to trigger cases that require a fairly significant
combination of options to be produced.

I've anyway reduced the percentage from 1% to 30% (where it was 1% to
35%). I'm obviously open to more discussion on the matter, reducing to
30% was just an initial measure.

> > So let's say that I'll reduce the KCONFIG_PROBABILITY on one side, and
> > increase the timeout for all builds by an hour on the other side. How
> > does that look?
> 
>  The timeout is already 4 hours, isn't it? That's already quite long IMHO.

Yes, that's quite large, but I've anyway increased it to 6 hours. The
goal of the time out was *only* to make sure builds entering some quite
of infinite loop terminate at some point (we used to have a PowerPC
toolchain whose 'ld' was buggy, and was entering an infinite loop when
building a certain package).

Thanks,

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

[Buildroot] Analysis of build results for 2014-04-19

[Arnout Vandecappelle]

On 23/04/14 09:22, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Wed, 23 Apr 2014 00:14:26 +0200, Arnout Vandecappelle wrote:
> 
>>> True. Currently the KCONFIG_PROBABILITY is chosen between 1% and 35%.
>>> Should I reduce that to 30% ? 25% ?
>>
>>  25% still means 300 packages, and I think that that doesn't even include
>> their dependencies. Isn't that exaggerated? I think that any defconfig
>> with more than 50 packages is not very realistic anymore...
>>
>>  Also, the interesting failures (with missing dependencies) are more
>> likely to fall out when less packages are selected, right?
>>
>>  So my suggestion is to reduce the probability to 15% (still 180 packages
>> in the defconfig...).
> 
> Not really, because your calculations make the assumption that there is
> one BR2_PACKAGE_<foo> option per package. But that's not true: certain
> packages have several, sometimes dozens of BR2_PACKAGE_<foo> options
> (think Qt4, Qt5, Python, etc.). And the percentage of randomization is
> done per BR2_PACKAGE_<foo> options, not per package.
> 
> A quick analysis shows a total of 2832 BR2_PACKAGE_<foo> options
> defined in Buildroot for around 1200 packages, so in average we have a
> little more than 2 Config.in options per package.

 Ah correct, so my proposed 15% indeed becomes 30%.

> 
> Also, by having a much smaller percentage, I'm wondering if we have a
> lot less chances to trigger cases that require a fairly significant
> combination of options to be produced.

 Do we actually have examples of such a situation, that a combination of
packages leads to an error? It's more likely to lead to runtime errors I
expect.

> 
> I've anyway reduced the percentage from 1% to 30% (where it was 1% to
> 35%). I'm obviously open to more discussion on the matter, reducing to
> 30% was just an initial measure.
> 
>>> So let's say that I'll reduce the KCONFIG_PROBABILITY on one side, and
>>> increase the timeout for all builds by an hour on the other side. How
>>> does that look?
>>
>>  The timeout is already 4 hours, isn't it? That's already quite long IMHO.
> 
> Yes, that's quite large, but I've anyway increased it to 6 hours. The
> goal of the time out was *only* to make sure builds entering some quite
> of infinite loop terminate at some point (we used to have a PowerPC
> toolchain whose 'ld' was buggy, and was entering an infinite loop when
> building a certain package).

 True, if there is currently no situation that the timeout is "real",
then it doesn't hurt to increase the timeout. And if a real timeout does
start occuring, we can decrease the timeout again until it is solved.


 Regards,
 Arnout

> 
> Thanks,
> 
> Thomas
> 


-- 
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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Analysis of build results for 2014-04-19

[Jeremy Rosen]

> 
> > 
> > Also, by having a much smaller percentage, I'm wondering if we have
> > a
> > lot less chances to trigger cases that require a fairly significant
> > combination of options to be produced.
> 
>  Do we actually have examples of such a situation, that a combination
>  of
> packages leads to an error? It's more likely to lead to runtime
> errors I
> expect.
> 


on a side note, if the autobuilder has selected a high number of packages
so far, there are probably many "low number of packages" type of bug
that it could find. it might be interesting to temporarly set it to a
low number of packages...

[Buildroot] Analysis of build results for 2014-04-19

[Arnout Vandecappelle]

On 23/04/14 10:56, Jeremy Rosen wrote:
> 
>>
>>>
>>> Also, by having a much smaller percentage, I'm wondering if we have
>>> a
>>> lot less chances to trigger cases that require a fairly significant
>>> combination of options to be produced.
>>
>>  Do we actually have examples of such a situation, that a combination
>>  of
>> packages leads to an error? It's more likely to lead to runtime
>> errors I
>> expect.
>>
> 
> 
> on a side note, if the autobuilder has selected a high number of packages
> so far, there are probably many "low number of packages" type of bug
> that it could find. it might be interesting to temporarly set it to a
> low number of packages...

 No, the number of packages is randomly selected between 1% and 30/35%.
So about 1 out of 6 builds has less than 5%, i.e. 30 packages. With such
a small percentage, it's extremely likely that the selected packages are
completely unrelated.

 However, this makes me realize that with the lower percentages, most
likely all the sub-options of a package will be set to no. With 30%,
there's a decent chance that at least some sub-options are selected, and
at least there is some chance that all of them are selected (though for a
package with 4 suboptions the chance that all are selected is already
less than 1%). Yet another reason not to reduce the percentage any further.

 It would probably be a lot better if the configurations would not use
randconfig, but rather a more customised was of selecting a random
configuration. But as usual, that's a lot of work...

 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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Analysis of build results for 2014-04-19

[Thomas Petazzoni]

Dear Jeremy Rosen,

On Wed, 23 Apr 2014 10:56:02 +0200 (CEST), Jeremy Rosen wrote:

> on a side note, if the autobuilder has selected a high number of packages
> so far, there are probably many "low number of packages" type of bug
> that it could find. it might be interesting to temporarly set it to a
> low number of packages...

As I said, the randomization is randomized. The percentage used for
KCONFIG_PROBABILITY is itself randomized between 1% and 30%. So some
builds will have 1% of BR2_PACKAGE_<foo> options enabled, some will
have 30% of options defined.

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

[Buildroot] Analysis of build results for 2014-04-19

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 23 Apr 2014 10:51:16 +0200, Arnout Vandecappelle wrote:

> > Also, by having a much smaller percentage, I'm wondering if we have a
> > lot less chances to trigger cases that require a fairly significant
> > combination of options to be produced.
> 
>  Do we actually have examples of such a situation, that a combination of
> packages leads to an error? It's more likely to lead to runtime errors I
> expect.

I believe so. For example, the cairo build problem due to GLchar would
only occur if both the sunxi-mali OpenGL implementation was selected
*and* cairo was enabled.

We also have lots of optional dependencies all over the place in many
packages. Those optional dependencies are only triggered is the
dependency is enabled.


> > Yes, that's quite large, but I've anyway increased it to 6 hours. The
> > goal of the time out was *only* to make sure builds entering some quite
> > of infinite loop terminate at some point (we used to have a PowerPC
> > toolchain whose 'ld' was buggy, and was entering an infinite loop when
> > building a certain package).
> 
>  True, if there is currently no situation that the timeout is "real",
> then it doesn't hurt to increase the timeout. And if a real timeout does
> start occuring, we can decrease the timeout again until it is solved.

Indeed. Right now, all the timeouts we see seem to be spurious
timeouts, only caused by the fact that the build is really taking
longer than the timeout, not because there was some infinite loop or
other issue that would have caused the build to actually never
terminate.

A better thing would be to monitor build-time.log while the build is
running, and only abort if the build duration of the *current* package
is higher than a certain limit. This way, instead of having a per-build
timeout, we would have a per-package timeout (which I believe, would be
related to the webkit build time).

Best regards,

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