[Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13

[Buildroot] [autobuild.buildroot.net] Build results for 2014-02-13

[Thomas Petazzoni]

Build statistics for 2014-02-13
===============================

        success : 94 
       failures : 31 
       timeouts : 3  
          TOTAL : 128

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

                  thrift-0.9.1 | 3 
                       unknown | 3 
           imagemagick-6.8.8-4 | 2 
mmc-utils-11f2ceabc4ad3f0dd... | 2 
                 cairo-1.12.10 | 2 
                 pixman-0.30.0 | 2 
      libnetfilter_queue-1.0.2 | 1 
  toolchain-external-undefined | 1 
                     popt-1.16 | 1 
                  samba-3.6.22 | 1 
               w_scan-20130331 | 1 
                 qt5base-5.2.0 | 1 
                      udev-182 | 1 
                  tstools-1_11 | 1 
                    crda-1.1.3 | 1 
                 libxml2-2.9.1 | 1 
tvheadend-c7d0335eb10d02b78... | 1 
                  python-2.7.3 | 1 
                 dropwatch-1.4 | 1 
        ltp-testsuite-20130904 | 1 
                     vlc-2.1.2 | 1 
              e2fsprogs-1.42.9 | 1 
                       kmod-16 | 1 
             host-libeet-1.7.7 | 1 
           host-libxslt-1.1.28 | 1 
              gst1-libav-1.2.2 | 1 

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

      bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/899395ce00ba54f19fd1f8ebaf1ea7a15e3d98dc/
      bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/0fcb07e9efbef5881c986199e2c1358d7fd9cffa/
     nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
microblaze |                  dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/916eec6a8853c49eab5b7806edcc0add06b8168f/
     nios2 |               e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
    x86_64 |               gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/
   powerpc |              host-libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/e3581e4a17e2c577458f5481b391f548b7fcdf69/
      i686 |            host-libxslt-1.1.28 | NOK | http://autobuild.buildroot.net/results/784b3989fab4007d6d077fba9a9078cf337ce002/
      i686 |            imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/
       arc |            imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d8eaf4d0/
    xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
     nios2 |       libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/
       arc |                  libxml2-2.9.1 | NOK | http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964ba70ac4b/
  mips64el |         ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f6aa04e2b904b1aae3b68b2ffbb1b8edb6f4929a/
   powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/79e24d5ada564e664f32041cc71a1aeac0d9d5cd/
   powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/b23f295008a834bbb37b6ea5c99842409b652bc9/
microblaze |                  pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/3becd76e2a7c3cf843d43ea9f1713fd536888cd7/
microblaze |                  pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/2b1feb18dc415c69aae6de9d558e527faae7b246/
      bfin |                      popt-1.16 | NOK | http://autobuild.buildroot.net/results/8d3ee14585f54c6946b449854df9f06ea7746e8e/
   powerpc |                   python-2.7.3 | NOK | http://autobuild.buildroot.net/results/64ed5890d4d03399eb549cba4aa3e65afd3b005f/
    xtensa |                  qt5base-5.2.0 | NOK | http://autobuild.buildroot.net/results/70b77e7a5b292e3fcbcf8cab4651c48220f2bd17/
     nios2 |                   samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/bc674e494c24155800583dde5dfda0709709becb/
    x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/eb6317433b89d3ad2a70b39a186ee223bc3f4a41/
    x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/d439787cb8b3ee3e001dfd24e93351201a1387ce/
    x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/c397677e2332c9a39950ea840333fc05d04c2e68/
   powerpc |   toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/a659d7ede91bb13904c360fe8c8f316b7011918b/
   powerpc |                   tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/
       arm | tvheadend-c7d0335eb10d02b78... | NOK | http://autobuild.buildroot.net/results/4df8cd85e0287910567df81c0394b2914570e98a/
      bfin |                       udev-182 | NOK | http://autobuild.buildroot.net/results/386be48be71ede6e06ea5547e37a1b6448f5fba2/
      sh4a |                        unknown | TIM | http://autobuild.buildroot.net/results/52bc9c4c2dfc0bd37f7170b98a2201ed853bad74/
      sh4a |                        unknown | TIM | http://autobuild.buildroot.net/results/899155257298dbc85c1681f900ddd042ead98412/
      sh4a |                        unknown | TIM | http://autobuild.buildroot.net/results/b908769c1291da8f758a44b04d36dbc415400b39/
    x86_64 |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/
   powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/6e7c691099a8f3eef4fc84860ceb1a94f25873eb/


-- 
http://autobuild.buildroot.net

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Hello,

Aaron, Ezequiel, Spenser, Anton, Baruch and Gustavo, there are
questions for you below. Please read on ! :-)

On Fri, 14 Feb 2014 08:30:08 +0100 (CET), Thomas Petazzoni wrote:

>       bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/899395ce00ba54f19fd1f8ebaf1ea7a15e3d98dc/
>       bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/0fcb07e9efbef5881c986199e2c1358d7fd9cffa/

cairo-test-runner.c: In function 'is_running_under_debugger':
cairo-test-runner.c:168: error: implicit declaration of function 'getppid'
cairo-test-runner.c:168: warning: nested extern declaration of 'getppid'
cairo-test-runner.c:169: error: implicit declaration of function 'readlink'
cairo-test-runner.c:169: warning: nested extern declaration of 'readlink'

This problem has been here for a while. Aaron, as the Blackfin person,
can you have a look into this and sent a patch to fix the problem? Thanks!

>      nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/

No idea what this error means. Ezequiel ?

/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line

> microblaze |                  dropwatch-1.4 | NOK | http://autobuild.buildroot.net/results/916eec6a8853c49eab5b7806edcc0add06b8168f/

Spenser, can you have a look at this one?

/home/test/test/2/output/host/usr/bin/microblaze-buildroot-linux-gnu-gcc -g -o dropwatch main.o lookup.o lookup_bfd.o lookup_kas.o -lbfd -liberty -lreadline -lnl-3 -lnl-genl-3 -lpthread -lncurses -lm
/home/test/test/2/output/host/usr/lib/gcc/microblaze-buildroot-linux-gnu/4.9.0/../../../../microblaze-buildroot-linux-gnu/bin/ld: cannot find -liberty

>      nios2 |               e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/

Another missing syscall on NIOS II ? Ezequiel ?

../lib/libext2fs.so: undefined reference to `fallocate64'
collect2: error: ld returned 1 exit status

>     x86_64 |               gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/

Weird:

/home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC

But the build is not a static library build.

>    powerpc |              host-libeet-1.7.7 | NOK | http://autobuild.buildroot.net/results/e3581e4a17e2c577458f5481b391f548b7fcdf69/

Spurious failure, the build machine was too heavily loaded.

>       i686 |            host-libxslt-1.1.28 | NOK | http://autobuild.buildroot.net/results/784b3989fab4007d6d077fba9a9078cf337ce002/

  CCLD   testThreads
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_code at XZ_5.0'
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_auto_decoder at XZ_5.0'
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_end at XZ_5.0'
/home/peko/scratch/host/usr/lib/libxml2.so: undefined reference to `lzma_properties_decode at XZ_5.0'
collect2: error: ld returned 1 exit status

I find it rather weird that this doesn't happen more often...

>       i686 |            imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/

Not enough backlog to see what the error is, unfortunately.

>        arc |            imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d8eaf4d0/

Internal compiler error. Anton, would you mind checking if your recent
bump of the ARC toolchain components solves this compiler problem?

>     xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/

Binutils internal error. Baruch ?

>      nios2 |       libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/

Issue with kernel headers ?

/home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: nested redefinition of 'enum nfnetlink_groups'
/home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: redeclaration of 'enum nfnetlink_groups'

>        arc |                  libxml2-2.9.1 | NOK | http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964ba70ac4b/

Another internal compiler error. Anton, same thing, is that fixed by your recent bump?

>   mips64el |         ltp-testsuite-20130904 | NOK | http://autobuild.buildroot.net/results/f6aa04e2b904b1aae3b68b2ffbb1b8edb6f4929a/

This one is fixed by
http://git.buildroot.net/buildroot/commit/?h=next&id=898e54bd783280ee1ffb6aeeb523c9fb8c31641a,
but unfortunately Peter only merged it in the next branch, so we still
have the build problem on master.

>    powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/79e24d5ada564e664f32041cc71a1aeac0d9d5cd/
>    powerpc | mmc-utils-11f2ceabc4ad3f0dd... | NOK | http://autobuild.buildroot.net/results/b23f295008a834bbb37b6ea5c99842409b652bc9/

Too old kernel headers;

> microblaze |                  pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/3becd76e2a7c3cf843d43ea9f1713fd536888cd7/
> microblaze |                  pixman-0.30.0 | NOK | http://autobuild.buildroot.net/results/2b1feb18dc415c69aae6de9d558e527faae7b246/

utils.c:779:21: error: 'FE_DIVBYZERO' undeclared (first use in this function)
     feenableexcept (FE_DIVBYZERO);

Spenser ? :-)

>       bfin |                      popt-1.16 | NOK | http://autobuild.buildroot.net/results/8d3ee14585f54c6946b449854df9f06ea7746e8e/

Maybe the blackfin uClibc lacks _glob_pattern_p ? Aaron ?

./.libs/libpopt.so: undefined reference to `_glob_pattern_p'

>    powerpc |                   python-2.7.3 | NOK | http://autobuild.buildroot.net/results/64ed5890d4d03399eb549cba4aa3e65afd3b005f/

./Modules/posixmodule.c: In function '_pystat_fromstructstat':
./Modules/posixmodule.c:1356:22: error: 'struct stat' has no member named 'st_birthtime'

Weird: it wants to use st_birthtime, even though this field doesn't
exist under Linux, and Python has a configure test that checks whether
it exists or not, and the code is properly conditionally compiled.

>     xtensa |                  qt5base-5.2.0 | NOK | http://autobuild.buildroot.net/results/70b77e7a5b292e3fcbcf8cab4651c48220f2bd17/

Needs NPTL. Fixed by my series about NPTL support.

>      nios2 |                   samba-3.6.22 | NOK | http://autobuild.buildroot.net/results/bc674e494c24155800583dde5dfda0709709becb/

Wooo, lots of errors. Relocation truncated to fit (maybe the binary is
too large), and missing fallocate64.

>     x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/eb6317433b89d3ad2a70b39a186ee223bc3f4a41/
>     x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/d439787cb8b3ee3e001dfd24e93351201a1387ce/
>     x86_64 |                   thrift-0.9.1 | NOK | http://autobuild.buildroot.net/results/c397677e2332c9a39950ea840333fc05d04c2e68/

uint64_t type problem. Gustavo, can you have a look?

>    powerpc |   toolchain-external-undefined | NOK | http://autobuild.buildroot.net/results/a659d7ede91bb13904c360fe8c8f316b7011918b/

Something for me to look at, it seems.

>    powerpc |                   tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/

Weird messages:

Assembler messages:
Fatal error: can't create obj/esfilter.o: No such file or directory

Parallel build issue?

>        arm | tvheadend-c7d0335eb10d02b78... | NOK | http://autobuild.buildroot.net/results/4df8cd85e0287910567df81c0394b2914570e98a/

src/input/mpegts/dvb_support.c:415:25: error: 'SYS_TURBO' undeclared here (not in a function)
   { "TURBO",            SYS_TURBO }

Too old kernel headers.

>       bfin |                       udev-182 | NOK | http://autobuild.buildroot.net/results/386be48be71ede6e06ea5547e37a1b6448f5fba2/

udev needs fork().

>       sh4a |                        unknown | TIM | http://autobuild.buildroot.net/results/52bc9c4c2dfc0bd37f7170b98a2201ed853bad74/
>       sh4a |                        unknown | TIM | http://autobuild.buildroot.net/results/899155257298dbc85c1681f900ddd042ead98412/
>       sh4a |                        unknown | TIM | http://autobuild.buildroot.net/results/b908769c1291da8f758a44b04d36dbc415400b39/

Those ones should be fixed now, they were caused by issues in the
autobuilder script.

>     x86_64 |                      vlc-2.1.2 | NOK | http://autobuild.buildroot.net/results/a53ea017ec92150c7d37c0da0ca9a8dac75f460e/

/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: ./.libs/libvlc_srtp.a(libvlc_srtp_la-srtp.o): relocation R_X86_64_PC32 against undefined symbol `gcry_md_reset@@GCRYPT_1.2' can not be used when making a shared object; recompile with -fPIC
/home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Bad value

>    powerpc |                w_scan-20130331 | NOK | http://autobuild.buildroot.net/results/6e7c691099a8f3eef4fc84860ceb1a94f25873eb/

Too old kernel headers.

Best regards,

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

[Buildroot] Analysis of build failures

[Anton Kolesov]

Hi Thomas,

> 
> >        arc |            imagemagick-6.8.8-4 | NOK |
> http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d
> 8eaf4d0/
> 
> Internal compiler error. Anton, would you mind checking if your recent
> bump of the ARC toolchain components solves this compiler problem?

No, that hasn't fixed yet. I've opened bug report for this error, but no ETA. Should I disable affected packages for ARC until solution will be ready?

> >        arc |                  libxml2-2.9.1 | NOK |
> http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964
> ba70ac4b/
> 
> Another internal compiler error. Anton, same thing, is that fixed by your
> recent bump?

Yes, it passes for me with the "next" branch.

Anton

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Anton Kolesov,

On Fri, 14 Feb 2014 10:23:00 +0000, Anton Kolesov wrote:

> > >        arc |            imagemagick-6.8.8-4 | NOK |
> > http://autobuild.buildroot.net/results/97ec0c366c24bd03fe4c26851e8729a4d
> > 8eaf4d0/
> > 
> > Internal compiler error. Anton, would you mind checking if your recent
> > bump of the ARC toolchain components solves this compiler problem?
> 
> No, that hasn't fixed yet. I've opened bug report for this error, but no ETA. Should I disable affected packages for ARC until solution will be ready?

Yes, please.

> > >        arc |                  libxml2-2.9.1 | NOK |
> > http://autobuild.buildroot.net/results/4abdea83c6915aa02b6dc55c9a9dd964
> > ba70ac4b/
> > 
> > Another internal compiler error. Anton, same thing, is that fixed by your
> > recent bump?
> 
> Yes, it passes for me with the "next" branch.

Argh. So libxml2 doesn't build at all on master. This is pretty
annoying, because this package has a fairly large number of reverse
dependencies, so marking all of them "depends on !BR2_arc" to avoid
build problems occurring on master is going to be annoying.

I was discussing this morning with better whether he should have merged
your ARC toolchain components bump to master instead of next. He merged
in next to be on the safe side, but the consequence is that we have a
good number of packages that don't build for ARC in master, causing
autobuilder failures, that we know are solved in next.

Oh well, I guess it's just a matter of waiting for the release at the
end of the month, and get next merged into master.

Best regards,

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

[Buildroot] Analysis of build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> Yes, it passes for me with the "next" branch.

 > Argh. So libxml2 doesn't build at all on master. This is pretty
 > annoying, because this package has a fairly large number of reverse
 > dependencies, so marking all of them "depends on !BR2_arc" to avoid
 > build problems occurring on master is going to be annoying.

 > I was discussing this morning with better whether he should have merged

s/better/Peter/ ;)

 > your ARC toolchain components bump to master instead of next. He merged
 > in next to be on the safe side, but the consequence is that we have a
 > good number of packages that don't build for ARC in master, causing
 > autobuilder failures, that we know are solved in next.

 > Oh well, I guess it's just a matter of waiting for the release at the
 > end of the month, and get next merged into master.

As I said on IRC, if we think arc will be in a better state with those
bumps cherry picked to master instead, then that's fine for me as well.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Fri, 14 Feb 2014 15:42:16 +0100, Peter Korsgaard wrote:

>  > Argh. So libxml2 doesn't build at all on master. This is pretty
>  > annoying, because this package has a fairly large number of reverse
>  > dependencies, so marking all of them "depends on !BR2_arc" to avoid
>  > build problems occurring on master is going to be annoying.
> 
>  > I was discussing this morning with better whether he should have merged
> 
> s/better/Peter/ ;)

Oops, sorry!

Fortunately I have this automatic thing "Dear <foo>", which gets your
name right whenever I reply to you :-)

>  > your ARC toolchain components bump to master instead of next. He merged
>  > in next to be on the safe side, but the consequence is that we have a
>  > good number of packages that don't build for ARC in master, causing
>  > autobuilder failures, that we know are solved in next.
> 
>  > Oh well, I guess it's just a matter of waiting for the release at the
>  > end of the month, and get next merged into master.
> 
> As I said on IRC, if we think arc will be in a better state with those
> bumps cherry picked to master instead, then that's fine for me as well.

Anton, what is your confidence with this bump of the toolchain
components? Should we merge it for 2014.02 ?

Best regards,

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

[Buildroot] Analysis of build failures

[Anton Kolesov]

Hi Thomas and Peter,

> >
> > As I said on IRC, if we think arc will be in a better state with those
> > bumps cherry picked to master instead, then that's fine for me as well.
> 
> Anton, what is your confidence with this bump of the toolchain
> components? Should we merge it for 2014.02 ?
> 

I would say that I would prefer to keep current state, because currently master points to our released versions, which are pretty much of a known entity for us, even if with some known failures. Latest commits haven?t been completely tested, so while they fix some bugs, they might introduce some new undiscovered troubles as well, so I don't feel safe about pointing to them in the buildroot release.

Since it is a problem of our tools, I can volunteer to prepare patches that disable reverse dependencies of libxml for ARC in master, though you still will have to apply them :) 

I will ask our team opinion on this as well. And let me know if you are ok if I we just disable failing packages in master.

Anton

[Buildroot] Analysis of build failures

[Thomas Petazzoni]

Dear Anton Kolesov,

On Fri, 14 Feb 2014 17:05:24 +0000, Anton Kolesov wrote:

> I would say that I would prefer to keep current state, because currently master points to our released versions, which are pretty much of a known entity for us, even if with some known failures. Latest commits haven?t been completely tested, so while they fix some bugs, they might introduce some new undiscovered troubles as well, so I don't feel safe about pointing to them in the buildroot release.

Ok, no problem!

> Since it is a problem of our tools, I can volunteer to prepare patches that disable reverse dependencies of libxml for ARC in master, though you still will have to apply them :) 
> 
> I will ask our team opinion on this as well. And let me know if you are ok if I we just disable failing packages in master.

I believe it's ok to disable failing packages in master, except when
they have too many reverse dependencies and that we know the problem
will be fixed soon. For such cases, I can simply add an exception to
the autobuilder script.

Thanks!

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

[Buildroot] Analysis of build failures

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/

 > No idea what this error means. Ezequiel ?

 > /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
 > /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line

If I remember correctly, _gp is a magic linker symbol on mips/nios. When
we discussed it last time I brought up this link:

https://lists.debian.org/debian-mips/2013/06/msg00041.html


 >> x86_64 |               gst1-libav-1.2.2 | NOK | http://autobuild.buildroot.net/results/2d83f38b4a6cb2a1a47c78306da7773270ce698e/

 > Weird:

 > /home/test/test/1/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: ../../gst-libs/ext/libav/libavcodec/libavcodec.a(lpc.o): relocation R_X86_64_PC32 against symbol `ff_pd_1' can not be used when making a shared object; recompile with -fPIC

 > But the build is not a static library build.

But it uses a static (embedded) copy of libav, perhaps that one isn't
built with -fPIC?


 >> powerpc |                   tstools-1_11 | NOK | http://autobuild.buildroot.net/results/b92b707ec32bf6f9a0c5834fd68d81d76d1a6365/

 > Weird messages:

 > Assembler messages:
 > Fatal error: can't create obj/esfilter.o: No such file or directory

 > Parallel build issue?

Sounds like it.


-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build failures

[Ezequiel García]

On 14 February 2014 06:12, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>>      nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
>
> No idea what this error means. Ezequiel ?
>
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line
>

As Peter said, some issue with the compiler. This is too much for me :-)
Adding nios2 support in the internal toolchain is on my (increasingly
long) TODO list.

>>      nios2 |               e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
>
> Another missing syscall on NIOS II ? Ezequiel ?
>
> ../lib/libext2fs.so: undefined reference to `fallocate64'
> collect2: error: ld returned 1 exit status
>

Ah, yes. We have lots of packages failing with this issue. I think
it's some issue
with the toolchain. fallocate64 is not a system call (only fallocate
exists, AFAICS),
so this should be some libc issue.

Anybody knows better? Who implements fallocate64? What can we do to fix this
in Buildroot (using an external toolchain)?

>>      nios2 |       libnetfilter_queue-1.0.2 | NOK | http://autobuild.buildroot.net/results/3d77c91847a099b2498030505b91f3f84c81df18/
>
> Issue with kernel headers ?
>
> /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: nested redefinition of 'enum nfnetlink_groups'
> /home/test/test/1/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/include/libnfnetlink/linux_nfnetlink.h:6:6: error: redeclaration of 'enum nfnetlink_groups'
>

The kernel headers exported by CodeSourcery toolchain seem to be copied
using some braindead cp-like copy, instead of using "make headers_install".
The latter does some modification to the headers. The dhcp package also fails
because of this.

Let's put this on top of my nios2 TODO list. Can we apply the header
sanitize in Buildroot,
when we install the Sourcery toolchain?
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar

[Buildroot] Analysis of build failures

[Frank Bergmann]

Hello,

On 14.02.2014 14:15, Ezequiel Garc?a wrote:
> On 14 February 2014 06:12, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>>       nios2 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/780c3388e408ae6479e824711b1c02fdbd34bef4/
>>
>> No idea what this error means. Ezequiel ?
>>
>> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/crt1.o: undefined reference to symbol '_gp'
>> /home/test/test/2/output/host/opt/ext-toolchain/bin/../lib/gcc/nios2-linux-gnu/4.7.3/../../../../nios2-linux-gnu/bin/ld: note: '_gp' is defined in DSO /home/test/test/2/output/host/usr/nios2-buildroot-linux-gnu/sysroot/usr/lib/libgpg-error.so.0 so try adding it to the linker command line
>>
>
> As Peter said, some issue with the compiler. This is too much for me :-)

What about the hint the linker gives in the line after the error ?
Link the binary with the additional LDFLAG '-lgpg-error' build the 
binary (but I have not run-time tested the result). This is also the 
advise from libgcrypt:

   $> libgcrypt-config --libs
   -lgcrypt -ldl -lgpg-error

I guess this is an unlucky accident: libgpg-error exports a 
symbol/function named '_gp' that could lead one to think it's about the 
global pointer from the nios2.

> Adding nios2 support in the internal toolchain is on my (increasingly
> long) TODO list.

That's fine. Is there a public repository for early testing ?

With regards,
Frank Bergmann.

[Buildroot] Analysis of build failures

[Frank Bergmann]

Hello,

On 14.02.2014 14:15, Ezequiel Garc?a wrote:
>>>       nios2 |               e2fsprogs-1.42.9 | NOK | http://autobuild.buildroot.net/results/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
>>
>> Another missing syscall on NIOS II ? Ezequiel ?
>>
>> ../lib/libext2fs.so: undefined reference to `fallocate64'
>> collect2: error: ld returned 1 exit status
>>
>
> Ah, yes. We have lots of packages failing with this issue. I think
> it's some issue
> with the toolchain. fallocate64 is not a system call (only fallocate
> exists, AFAICS),
> so this should be some libc issue.
>
> Anybody knows better? Who implements fallocate64? What can we do to fix this
> in Buildroot (using an external toolchain)?

No, sorry. But after dig a little bit:
e2fsprogs using

   _FILE_OFFSET_BITS=64

while compiling the source. In this case the fallocate system call will 
be silently replaced by fallocate64 (see: 
https://lists.debian.org/debian-glibc/2010/02/msg00088.html). But 
fallocate64 is unfortunately not available on nios2 toolchain at the moment.

The only solution that works appears to be completely disable the 
fallocate system call(s) by providing

   ac_cv_func_fallocate=no

to the configure script. The effect in e2fsprogs will be that 
unix_discard() in ext2fs/unix_io.c will return with the "UNIMPLEMENTED" 
return code. I'm not sure for the moment if the whole packages or only a 
couple of functions gets unusable with this.

With regards,
Frank Bergmann.

[Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2

[Frank Bergmann]

Nios2 is currently missing the fallocate64 system call. Because of
compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate
call is replaced by fallocate64 by the glibc. Therefor fallocate is
entirely disbaled while configuring the package.

e4defrag have to be disabled because it declares the fallocate64 but
the library have its own defined.

It fixes an autobuilder issue:
http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/

Signed-off-by: Frank Bergmann <frank@frajasalo.de>
---
  package/e2fsprogs/Config.in    | 2 +-
  package/e2fsprogs/e2fsprogs.mk | 3 ++-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in
index 7775e94..1e87aef 100644
--- a/package/e2fsprogs/Config.in
+++ b/package/e2fsprogs/Config.in
@@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO

  config BR2_PACKAGE_E2FSPROGS_E4DEFRAG
         bool "e4defrag"
-       depends on !BR2_avr32 # fallocate not implemented
+       depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented

  config BR2_PACKAGE_E2FSPROGS_FILEFRAG
         bool "filefrag"
diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk
index 2eb59f5..310f549 100644
--- a/package/e2fsprogs/e2fsprogs.mk
+++ b/package/e2fsprogs/e2fsprogs.mk
@@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \
         --disable-libuuid \
         --enable-fsck \
         --disable-e2initrd-helper \
-       --disable-testio-debug
+       --disable-testio-debug \
+       $(if $(BR2_nios2),ac_cv_func_fallocate=no,)

  E2FSPROGS_DEPENDENCIES = host-pkgconf util-linux

-- 
1.8.3.1

[Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2

[Thomas Petazzoni]

Dear Frank Bergmann,

Please send your patches with "git send-email". Thunderbird has badly
replaces the tabs by spaces.

On Sat, 15 Feb 2014 19:52:01 +0100, Frank Bergmann wrote:
> Nios2 is currently missing the fallocate64 system call. Because of
> compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate
> call is replaced by fallocate64 by the glibc. Therefor fallocate is
> entirely disbaled while configuring the package.

Therefor -> Therefore
disbaled -> disabled

> 
> e4defrag have to be disabled because it declares the fallocate64 but
> the library have its own defined.

Not sure I understand this part.

> 
> It fixes an autobuilder issue:
> http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
> 
> Signed-off-by: Frank Bergmann <frank@frajasalo.de>
> ---
>   package/e2fsprogs/Config.in    | 2 +-
>   package/e2fsprogs/e2fsprogs.mk | 3 ++-
>   2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in
> index 7775e94..1e87aef 100644
> --- a/package/e2fsprogs/Config.in
> +++ b/package/e2fsprogs/Config.in
> @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO
> 
>   config BR2_PACKAGE_E2FSPROGS_E4DEFRAG
>          bool "e4defrag"
> -       depends on !BR2_avr32 # fallocate not implemented
> +       depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented
> 
>   config BR2_PACKAGE_E2FSPROGS_FILEFRAG
>          bool "filefrag"
> diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk
> index 2eb59f5..310f549 100644
> --- a/package/e2fsprogs/e2fsprogs.mk
> +++ b/package/e2fsprogs/e2fsprogs.mk
> @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \
>          --disable-libuuid \
>          --enable-fsck \
>          --disable-e2initrd-helper \
> -       --disable-testio-debug
> +       --disable-testio-debug \
> +       $(if $(BR2_nios2),ac_cv_func_fallocate=no,)

Such variables are normally passed in <pkg>_CONF_ENV. Also, in
Config.in, the fallocate problem seems to also apply for AVR32, while
you only pass ac_cv_func_fallocate=no for NIOS II here. Could you
explain why?

Thanks,

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

[Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2

[Frank Bergmann]

Hello,

On 18.02.2014 22:19, Thomas Petazzoni wrote:
> Dear Frank Bergmann,
>
> Please send your patches with "git send-email". Thunderbird has badly
> replaces the tabs by spaces.

Sorry for that, next time using the right tool !

> On Sat, 15 Feb 2014 19:52:01 +0100, Frank Bergmann wrote:
>> Nios2 is currently missing the fallocate64 system call. Because of
>> compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate
>> call is replaced by fallocate64 by the glibc. Therefor fallocate is
>> entirely disbaled while configuring the package.
>
> Therefor -> Therefore
> disbaled -> disabled
>
>>
>> e4defrag have to be disabled because it declares the fallocate64 but
>> the library have its own defined.
>
> Not sure I understand this part.

Sorry for not being clear but the toolchain is a little bit messy:
In the toolchain headers fallocate64 is defined but it is not implemented in the library.
e4defrag declares its own fallocate64 function that throw an error because of the previous
declaration in the header.

>
>>
>> It fixes an autobuilder issue:
>> http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/
>>
>> Signed-off-by: Frank Bergmann <frank@frajasalo.de>
>> ---
>>    package/e2fsprogs/Config.in    | 2 +-
>>    package/e2fsprogs/e2fsprogs.mk | 3 ++-
>>    2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in
>> index 7775e94..1e87aef 100644
>> --- a/package/e2fsprogs/Config.in
>> +++ b/package/e2fsprogs/Config.in
>> @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO
>>
>>    config BR2_PACKAGE_E2FSPROGS_E4DEFRAG
>>           bool "e4defrag"
>> -       depends on !BR2_avr32 # fallocate not implemented
>> +       depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented
>>
>>    config BR2_PACKAGE_E2FSPROGS_FILEFRAG
>>           bool "filefrag"
>> diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk
>> index 2eb59f5..310f549 100644
>> --- a/package/e2fsprogs/e2fsprogs.mk
>> +++ b/package/e2fsprogs/e2fsprogs.mk
>> @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \
>>           --disable-libuuid \
>>           --enable-fsck \
>>           --disable-e2initrd-helper \
>> -       --disable-testio-debug
>> +       --disable-testio-debug \
>> +       $(if $(BR2_nios2),ac_cv_func_fallocate=no,)
>
> Such variables are normally passed in <pkg>_CONF_ENV. Also, in
> Config.in, the fallocate problem seems to also apply for AVR32, while
> you only pass ac_cv_func_fallocate=no for NIOS II here. Could you
> explain why?

As written in the patch description fallocate is replaced by fallocate64 if using
_FILE_OFFSET_BITS=64 . fallocate64 is not available in nios2 toolchain library. So
if in that case we want to avoid fallocate64 then we have to avoid fallocate.

Not sure for the moment why it's working for AVR32 but fallocate is referenced in
lib/ext2fs/unix_io.c which builds libext2fs.so and therefore it's independent of
e4defrag. Only avoiding e4defrag does not work for nios2.

I missed that ac_cv_func_fallocate is normally passed in E2FSPROGS_CONF_ENV.

Regards,
Frank.

[Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2

[Frank Bergmann]

Hello,

On 19.02.2014 00:13, Frank Bergmann wrote:
> On 18.02.2014 22:19, Thomas Petazzoni wrote:
>>> diff --git a/package/e2fsprogs/Config.in b/package/e2fsprogs/Config.in
>>> index 7775e94..1e87aef 100644
>>> --- a/package/e2fsprogs/Config.in
>>> +++ b/package/e2fsprogs/Config.in
>>> @@ -49,7 +49,7 @@ config BR2_PACKAGE_E2FSPROGS_E2UNDO
>>>
>>>    config BR2_PACKAGE_E2FSPROGS_E4DEFRAG
>>>           bool "e4defrag"
>>> -       depends on !BR2_avr32 # fallocate not implemented
>>> +       depends on !BR2_avr32 && !BR2_nios2 # fallocate not implemented
>>>
>>>    config BR2_PACKAGE_E2FSPROGS_FILEFRAG
>>>           bool "filefrag"
>>> diff --git a/package/e2fsprogs/e2fsprogs.mk b/package/e2fsprogs/e2fsprogs.mk
>>> index 2eb59f5..310f549 100644
>>> --- a/package/e2fsprogs/e2fsprogs.mk
>>> +++ b/package/e2fsprogs/e2fsprogs.mk
>>> @@ -23,7 +23,8 @@ E2FSPROGS_CONF_OPT = \
>>>           --disable-libuuid \
>>>           --enable-fsck \
>>>           --disable-e2initrd-helper \
>>> -       --disable-testio-debug
>>> +       --disable-testio-debug \
>>> +       $(if $(BR2_nios2),ac_cv_func_fallocate=no,)
>>
>> Such variables are normally passed in <pkg>_CONF_ENV. Also, in
>> Config.in, the fallocate problem seems to also apply for AVR32, while
>> you only pass ac_cv_func_fallocate=no for NIOS II here. Could you
>> explain why?
>
> As written in the patch description fallocate is replaced by fallocate64 if using
> _FILE_OFFSET_BITS=64 . fallocate64 is not available in nios2 toolchain library. So
> if in that case we want to avoid fallocate64 then we have to avoid fallocate.
>
> Not sure for the moment why it's working for AVR32 but fallocate is referenced in
> lib/ext2fs/unix_io.c which builds libext2fs.so and therefore it's independent of
> e4defrag. Only avoiding e4defrag does not work for nios2.

On AVR32 there is neither fallocate nor fallocate64 available. e4defrag has to be
disabled on this architecture because it uses the fallocate system call which is
also not available.

Frank.

[Buildroot] [PATCH 1/1] e2fsprogs: fix missing fallocate64() on nios2

[Peter Korsgaard]

>>>>> "Frank" == Frank Bergmann <frank@frajasalo.de> writes:

 > Nios2 is currently missing the fallocate64 system call. Because of
 > compiling the e2fsprogs package with _FILE_OFFSET_BITS=64 the fallocate
 > call is replaced by fallocate64 by the glibc. Therefor fallocate is
 > entirely disbaled while configuring the package.

 > e4defrag have to be disabled because it declares the fallocate64 but
 > the library have its own defined.

 > It fixes an autobuilder issue:
 > http://autobuild.buildroot.org/results/70a/70a47bd7392560cbc1c64769c8357c0b4c91ca3b/

 > Signed-off-by: Frank Bergmann <frank@frajasalo.de>

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build failures

[Baruch Siach]

Hi Thomas,

On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote:
> >     xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
> 
> Binutils internal error. Baruch ?

Xtensa Toolchain issues are out of scope for me at the moment I'm afraid. 
Sorry.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

[Buildroot] Xtensa support ?

[Thomas Petazzoni]

Baruch,

On Sat, 15 Feb 2014 23:31:24 +0200, Baruch Siach wrote:

> On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote:
> > >     xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
> > 
> > Binutils internal error. Baruch ?
> 
> Xtensa Toolchain issues are out of scope for me at the moment I'm afraid. 
> Sorry.

Argh, too bad. You have been very active in recent times in improving
the Xtensa support, and this was really nice.

The daily Xtensa autobuilder failures are sent to chris at zankel.net, but
Chris doesn't seem to be very active in fixing the issues. Chris, are
you still interested in Buildroot Xtensa support?

Are there other Xtensa users on the list? If so, please speak up, we
need you to continue improving the Xtensa Buildroot support.

Thanks,

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

[Buildroot] Xtensa support ?

[Chris Zankel]

+CC: Max

Hi Thomas,

Unfortunately, I have been really busy with another project and won't 
have much time to look into it for another week or so. Max has been 
working on Xtensa a lot, so maybe he can step in?

If the autobuilder supports multiple recipients, it would be great if 
you could still keep me in that list, though.

Thanks,
-Chris

On 2/18/14, 1:22 PM, Thomas Petazzoni wrote:
> Baruch,
>
> On Sat, 15 Feb 2014 23:31:24 +0200, Baruch Siach wrote:
>
>> On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote:
>>>>      xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
>>> Binutils internal error. Baruch ?
>> Xtensa Toolchain issues are out of scope for me at the moment I'm afraid.
>> Sorry.
> Argh, too bad. You have been very active in recent times in improving
> the Xtensa support, and this was really nice.
>
> The daily Xtensa autobuilder failures are sent to chris at zankel.net, but
> Chris doesn't seem to be very active in fixing the issues. Chris, are
> you still interested in Buildroot Xtensa support?
>
> Are there other Xtensa users on the list? If so, please speak up, we
> need you to continue improving the Xtensa Buildroot support.
>
> Thanks,
>
> Thomas

[Buildroot] Xtensa support ?

[Thomas Petazzoni]

Dear Chris Zankel,

On Tue, 18 Feb 2014 16:24:20 -0800, Chris Zankel wrote:

> Unfortunately, I have been really busy with another project and won't 
> have much time to look into it for another week or so.

I am not really worried about the immediate future (i.e the coming
week), but more in the mid to long term future.

> Max has been working on Xtensa a lot, so maybe he can step in?

We'll be definitely happy to receive contributions from Max. Max, do
you want to receive a daily e-mail that lists the Xtensa build issues
(no mail is sent when there are no Xtensa build issues during the day).

> If the autobuilder supports multiple recipients, it would be great if 
> you could still keep me in that list, though.

I can send the e-mail to as many recipients as I want, so I'll
definitely keep you in the list.

Thanks!

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

[Buildroot] Xtensa support ?

[Thomas Petazzoni]

Dear Max Filippov,

On Wed, 19 Feb 2014 14:46:28 +0400, Max Filippov wrote:

> On Wed, Feb 19, 2014 at 12:04 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> >> Unfortunately, I have been really busy with another project and won't
> >> have much time to look into it for another week or so.
> >
> > I am not really worried about the immediate future (i.e the coming
> > week), but more in the mid to long term future.
> >
> >> Max has been working on Xtensa a lot, so maybe he can step in?
> 
> I think I can. I've been always using somewhat old buildroot version,
> so need some time to get familiar with its current state.

Great!

> > We'll be definitely happy to receive contributions from Max. Max, do
> > you want to receive a daily e-mail that lists the Xtensa build issues
> > (no mail is sent when there are no Xtensa build issues during the day).
> 
> Yes, please.

Done, you will receive the daily e-mail with Xtensa build failures
starting tomorrow morning.

Thanks for your participation!

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

[Buildroot] Xtensa support ?

[Jonathan Ben Avraham]

On Tue, 18 Feb 2014, Thomas Petazzoni wrote:

> Date: Tue, 18 Feb 2014 22:22:15 +0100
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> To: Baruch Siach <baruch@tkos.co.il>
> Cc: buildroot at uclibc.org
> Subject: [Buildroot] Xtensa support ?
> 
> Baruch,
>
> On Sat, 15 Feb 2014 23:31:24 +0200, Baruch Siach wrote:
>
>> On Fri, Feb 14, 2014 at 10:12:41AM +0100, Thomas Petazzoni wrote:
>>>>     xtensa |                        kmod-16 | NOK | http://autobuild.buildroot.net/results/ba205bcbb6898bee78f610883f3837930eda262c/
>>>
>>> Binutils internal error. Baruch ?
>>
>> Xtensa Toolchain issues are out of scope for me at the moment I'm afraid.
>> Sorry.
>
> Argh, too bad. You have been very active in recent times in improving
> the Xtensa support, and this was really nice.
>
> The daily Xtensa autobuilder failures are sent to chris at zankel.net, but
> Chris doesn't seem to be very active in fixing the issues. Chris, are
> you still interested in Buildroot Xtensa support?
>
> Are there other Xtensa users on the list? If so, please speak up, we
> need you to continue improving the Xtensa Buildroot support.
>
> Thanks,
>
> Thomas

Hi Thomas,
There is a chance that I can take over the Xtensa Buildroot support from
Baruch. There is a budget issue and a ramp-up issue that I need to resolve
first, but I believe that it's doable. I will let you know later in the
day.
Regards,

  - yba


-- 
  9590 8E58 D30D 1660 C349  673D B205 4FC4 B8F5 B7F9  ~. .~  Tk Open Systems
=}------------- Jonathan Ben-Avraham -------------ooO--U--Ooo------------{=
mailto:yba at tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm

[Buildroot] Xtensa support ?

[Thomas Petazzoni]

Dear Jonathan Ben Avraham,

On Wed, 19 Feb 2014 07:26:14 +0200 (IST), Jonathan Ben Avraham wrote:

> There is a chance that I can take over the Xtensa Buildroot support from
> Baruch. There is a budget issue and a ramp-up issue that I need to resolve
> first, but I believe that it's doable. I will let you know later in the
> day.

Cool. Let me know when you have the answer. Also, let me know if you
want to receive daily e-mails about Xtensa autobuilder failures.

Thanks!

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

[Buildroot] Xtensa support ?

[Jonathan Ben Avraham]

On Wed, 19 Feb 2014, Thomas Petazzoni wrote:

> Date: Wed, 19 Feb 2014 09:05:32 +0100
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> To: Jonathan Ben Avraham <yba@tkos.co.il>
> Cc: Baruch Siach <baruch@tkos.co.il>, buildroot at uclibc.org
> Subject: Re: [Buildroot] Xtensa support ?
> 
> Dear Jonathan Ben Avraham,
>
> On Wed, 19 Feb 2014 07:26:14 +0200 (IST), Jonathan Ben Avraham wrote:
>
>> There is a chance that I can take over the Xtensa Buildroot support from
>> Baruch. There is a budget issue and a ramp-up issue that I need to resolve
>> first, but I believe that it's doable. I will let you know later in the
>> day.
>
> Cool. Let me know when you have the answer. Also, let me know if you
> want to receive daily e-mails about Xtensa autobuilder failures.

Hi Thomas,
Yes, please keep Baruch and I on the Xtensa autobuilder list. If Baruch 
gives me his blessing for this effort then I intend to be in for the 
long-term.

  - yba (Jonathan)


> Thanks!
>
> Thomas
>

-- 
  9590 8E58 D30D 1660 C349  673D B205 4FC4 B8F5 B7F9  ~. .~  Tk Open Systems
=}------------- Jonathan Ben-Avraham -------------ooO--U--Ooo------------{=
mailto:yba at tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm

[Buildroot] Xtensa support ?

[Thomas Petazzoni]

Dear Jonathan Ben Avraham,

On Wed, 19 Feb 2014 10:16:04 +0200 (IST), Jonathan Ben Avraham wrote:

> > Cool. Let me know when you have the answer. Also, let me know if you
> > want to receive daily e-mails about Xtensa autobuilder failures.
> 
> Yes, please keep Baruch and I on the Xtensa autobuilder list.

Until now, Baruch was not receiving the daily Xtensa e-mails, only
Chris Zankel. Should I add both Baruch and you?

> If Baruch gives me his blessing for this effort then I intend to be in for the 
> long-term.

That would be great. We really need some contributors to maintain all
these fairly specific architectures, so your help is definitely welcome
here.

Thanks,

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

[Buildroot] Analysis of build failures

[Romain Naour]

Hi Thomas, All,
>>        i686 |            imagemagick-6.8.8-4 | NOK | http://autobuild.buildroot.net/results/a9d35975c7699515350eb307712cd69b6d48e418/
> Not enough backlog to see what the error is, unfortunately.
>
>
It is impossible to disable documentation in Imagemagick because all 
options like  --disable-gtk-doc, --disable-doc, --disable-docs and 
--disable-documentation are not handled by configure script.

It will be easier to understand what happens when the build fails if we 
remove hard coded documentation from Makefiles.

I just sent a patch for this.

Best regards,
Romain Naour