[Buildroot] [autobuild.buildroot.net] Build results for 2015-08-18

[Buildroot] [autobuild.buildroot.net] Build results for 2015-08-18

[Thomas Petazzoni]

Build statistics for 2015-08-18
===============================

        success : 180
       failures : 38 
       timeouts : 0  
          TOTAL : 218

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

               libpthsem-2.0.8 | 7 
                busybox-1.23.2 | 4 
                  weston-1.8.0 | 3 
                  boost-1.58.0 | 3 
                   bdwgc-7.4.2 | 2 
             libselinux-2.1.13 | 2 
                 qt5base-5.5.0 | 2 
                 mesa3d-10.6.3 | 2 
             alsa-utils-1.0.29 | 1 
               linux-pam-1.1.8 | 1 
                harfbuzz-1.0.1 | 1 
                   dhrystone-2 | 1 
                   msmtp-1.6.1 | 1 
             webkitgtk24-2.4.9 | 1 
               protobuf-v2.5.0 | 1 
                  ltris-1.0.19 | 1 
                    faifa-v0.1 | 1 
                  mono-4.0.2.5 | 1 
                minidlna-1.1.4 | 1 
                   tinc-1.0.24 | 1 
    xserver_xorg-server-1.17.2 | 1 

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

         arc |              alsa-utils-1.0.29 | NOK | http://autobuild.buildroot.net/results/605249fe36cf0698e2211a6707ebe0aaa1d73332/
       sparc |                    bdwgc-7.4.2 | NOK | http://autobuild.buildroot.net/results/b66e107c3f1cea60a64fbfebd042839187838c8f/
       sparc |                    bdwgc-7.4.2 | NOK | http://autobuild.buildroot.net/results/fa94a7b7b3add55944dfa82915e172c3637893a5/
         arc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/b20f4fb82c3bcb3633f1e8230a9051b6bb699dd6/
         arc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/22b710346d2cd78b7b51cdccd18d670bb6ac5d24/
         arc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/b946c39ac4543249330caeb6c528f273f886137a/
       sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98fd1c9a3f92d2354fe3bd9c233916f720e26234/
       sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/7ce7267bdc4da3bd0069cec49b8286316d220cd9/
       sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/3ebe4454210fb257af08a0ca9cd13844d6985d58/
       sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/cf90773bcca2b0401135779a293af33dc9cf658b/
         arm |                    dhrystone-2 | NOK | http://autobuild.buildroot.net/results/004704ff6415be66f4cceb1a1d12e527f9eb1fd0/
      x86_64 |                     faifa-v0.1 | NOK | http://autobuild.buildroot.net/results/9eeb9d1497d94dfbda710e8bcdf781bc6d4b8724/
      x86_64 |                 harfbuzz-1.0.1 | NOK | http://autobuild.buildroot.net/results/ad4f31237e8e127ee40f6914c6b48879e17856e9/
         arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/90fe673b4aab2c2231b419dbe8307d747680f583/
         arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/0c72434c9f0cab6b1afbe7592273a909211b30a1/
     powerpc |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/389b0dac8bb62ae72fd43396f5cd05de39472fa8/
         arc |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/edd545f529bdb075baa96cba76864146594acee5/
         arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/d2799afb5042b08d556953d89ba2b75815f5022a/
     aarch64 |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/e0a6e39e58a76c15e621e713a1fba1ce6e2cfbb0/
         arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/3a11a92b731977acdd7ce98d1e4464b40f8e9aaa/
         arc |              libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/417e81ada0977aca0c5bb7b1f2fe1c238e829d49/
         arc |              libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/eb7a0d940d0bce0a09f357a2d6b0bb359d69367b/
         arm |                linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/e337d69420ad00b2cc4017d639a31803926f2353/
         arm |                   ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/c5e65c8d5a8f2042e5f9f0fd186d44ac5b9ed60d/
      xtensa |                  mesa3d-10.6.3 | NOK | http://autobuild.buildroot.net/results/737c2a94e025d813da45be6375dc0ef9af4f0b05/
     powerpc |                  mesa3d-10.6.3 | NOK | http://autobuild.buildroot.net/results/62b525fffa6ab9a211ec96940517decad0e54f9f/
         arm |                 minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/c9ffbf16c255d4d993c8564b53610bb9a6b90a79/
         arm |                   mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/5d99bdf77f1942fa403081267c362aa1f8fd0dab/
         sh4 |                    msmtp-1.6.1 | NOK | http://autobuild.buildroot.net/results/95a75c3696807ff6256ebda12b037c4db9e6efc2/
         arm |                protobuf-v2.5.0 | NOK | http://autobuild.buildroot.net/results/89856178211d9d077fabd9affe4007ee616f9899/
        mips |                  qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/966f2e4bd4237e082922b27b141e7277ffd8a76f/
        mips |                  qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/305e5c31a6bd37fe5ee20821ba4e693d9bc495f3/
         arm |                    tinc-1.0.24 | NOK | http://autobuild.buildroot.net/results/32da2e5ac384383c1e40eb17bf87970d912b235e/
         arm |              webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/eb8804abced7297b5edb5073f7a29d8b37dc6c6a/
         arm |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/ef685a41a56e81dc93a40f23f8cd55860f44e055/
         arm |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/d842a17476e52f064d678a6a1a9ac5f7b6f2446e/
         arc |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/c42d72498e05364a718748caef74bba6c423d7d1/
     powerpc |     xserver_xorg-server-1.17.2 | NOK | http://autobuild.buildroot.net/results/0900f6d340b92c6fd1d391a9e2424d0b421c3cba/


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2015-08-18

[Vicente Olivert Riera]

Dear Thomas Petazzoni,

On 08/19/2015 07:30 AM, Thomas Petazzoni wrote:
> Build statistics for 2015-08-18

>         mips |                  qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/966f2e4bd4237e082922b27b141e7277ffd8a76f/
>         mips |                  qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/305e5c31a6bd37fe5ee20821ba4e693d9bc495f3/

Fixed by http://patchwork.ozlabs.org/patch/507916/

Regards,

Vincent.

[Buildroot] Analysis of build results for 2015-08-18

[Thomas Petazzoni]

Hello,

On Wed, 19 Aug 2015 08:30:13 +0200 (CEST), Thomas Petazzoni wrote:

>          arc |              alsa-utils-1.0.29 | NOK | http://autobuild.buildroot.net/results/605249fe36cf0698e2211a6707ebe0aaa1d73332/

Static linking issue:

  undefined reference to `_snd_module_rawmidi_virt'

Peter, maybe you could have a look?

>        sparc |                    bdwgc-7.4.2 | NOK | http://autobuild.buildroot.net/results/b66e107c3f1cea60a64fbfebd042839187838c8f/
>        sparc |                    bdwgc-7.4.2 | NOK | http://autobuild.buildroot.net/results/fa94a7b7b3add55944dfa82915e172c3637893a5/

Invalid use of libatomic_ops. I thought I sent a patch for this. I'll
have a look.

>          arc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/b20f4fb82c3bcb3633f1e8230a9051b6bb699dd6/
>          arc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/22b710346d2cd78b7b51cdccd18d670bb6ac5d24/
>          arc |                   boost-1.58.0 | NOK | http://autobuild.buildroot.net/results/b946c39ac4543249330caeb6c528f273f886137a/

Would be fixed by:

   http://patchwork.ozlabs.org/patch/508792/

>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98fd1c9a3f92d2354fe3bd9c233916f720e26234/
>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/7ce7267bdc4da3bd0069cec49b8286316d220cd9/
>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/3ebe4454210fb257af08a0ca9cd13844d6985d58/
>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/cf90773bcca2b0401135779a293af33dc9cf658b/

Peter, what do you suggest we do about these issues for the release?
Long-term, libtirpc will be changed to not use atomic builtins. But
what do we do now? Mark libtirpc as not available on SPARCv8, and
propagate the reverse dependency?

>          arm |                    dhrystone-2 | NOK | http://autobuild.buildroot.net/results/004704ff6415be66f4cceb1a1d12e527f9eb1fd0/

musl build problem

error: 'HZ' undeclared

Someone to have a look?

>       x86_64 |                     faifa-v0.1 | NOK | http://autobuild.buildroot.net/results/9eeb9d1497d94dfbda710e8bcdf781bc6d4b8724/

musl build problem

error: #error Define BYTE_ORDER to be equal to either LITTLE_ENDIAN or BIG_ENDIAN

Someone to have a look?

>       x86_64 |                 harfbuzz-1.0.1 | NOK | http://autobuild.buildroot.net/results/ad4f31237e8e127ee40f6914c6b48879e17856e9/

checking for CAIRO... no
configure: error: cairo support requested but not found
make: *** [/home/test/autobuild/instance-2/output/build/harfbuzz-1.0.1/.stamp_configured] Error 1

Romain, you already looked at harfbuzz in the past. Can you look into this one?

>          arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/90fe673b4aab2c2231b419dbe8307d747680f583/
>          arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/0c72434c9f0cab6b1afbe7592273a909211b30a1/
>      powerpc |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/389b0dac8bb62ae72fd43396f5cd05de39472fa8/
>          arc |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/edd545f529bdb075baa96cba76864146594acee5/
>          arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/d2799afb5042b08d556953d89ba2b75815f5022a/
>      aarch64 |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/e0a6e39e58a76c15e621e713a1fba1ce6e2cfbb0/
>          arm |                libpthsem-2.0.8 | NOK | http://autobuild.buildroot.net/results/3a11a92b731977acdd7ce98d1e4464b40f8e9aaa/

Fixed by
http://git.buildroot.net/buildroot/commit/?id=97e9db4332aeb58c5b83536426906df942573d4d.

>          arc |              libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/417e81ada0977aca0c5bb7b1f2fe1c238e829d49/
>          arc |              libselinux-2.1.13 | NOK | http://autobuild.buildroot.net/results/eb7a0d940d0bce0a09f357a2d6b0bb359d69367b/

Would be fixed (worked around) by
http://patchwork.ozlabs.org/patch/508793/.

>          arm |                linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/e337d69420ad00b2cc4017d639a31803926f2353/

musl build issue.

>          arm |                   ltris-1.0.19 | NOK | http://autobuild.buildroot.net/results/c5e65c8d5a8f2042e5f9f0fd186d44ac5b9ed60d/

gcc5 problem, maybe?

>       xtensa |                  mesa3d-10.6.3 | NOK | http://autobuild.buildroot.net/results/737c2a94e025d813da45be6375dc0ef9af4f0b05/

The DRM/DRI story:

checking for LIBUDEV... no
configure: error: gbm requires --enable-dri
package/pkg-generic.mk:146: recipe for target '/home/buildroot/build/instance-0/output/build/mesa3d-10.6.3/.stamp_configured' failed

>      powerpc |                  mesa3d-10.6.3 | NOK | http://autobuild.buildroot.net/results/62b525fffa6ab9a211ec96940517decad0e54f9f/

Same.

>          arm |                 minidlna-1.1.4 | NOK | http://autobuild.buildroot.net/results/c9ffbf16c255d4d993c8564b53610bb9a6b90a79/

Static linking problem. A patch has been proposed, but I'm really not
happy with adding more and more hardcoded -l<foo> in minidlna.mk.

checking for id3_file_open in -lid3tag... no
configure: error: Could not find libid3tag


>          arm |                   mono-4.0.2.5 | NOK | http://autobuild.buildroot.net/results/5d99bdf77f1942fa403081267c362aa1f8fd0dab/

gc_dlopen.c:63:19: fatal error: dlfcn.h: No such file or directory

We could probably pass -DGC_NO_DLOPEN to try to fix this, but I don't
think it makes sense to build Mono in a statically linked environment.
I'll send a patch to disable that.

>          sh4 |                    msmtp-1.6.1 | NOK | http://autobuild.buildroot.net/results/95a75c3696807ff6256ebda12b037c4db9e6efc2/

Static linking problem.

>          arm |                protobuf-v2.5.0 | NOK | http://autobuild.buildroot.net/results/89856178211d9d077fabd9affe4007ee616f9899/

Already fixed by 9fa58ed79b83d61f250cba65a85df096c2a6f447.

>         mips |                  qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/966f2e4bd4237e082922b27b141e7277ffd8a76f/
>         mips |                  qt5base-5.5.0 | NOK | http://autobuild.buildroot.net/results/305e5c31a6bd37fe5ee20821ba4e693d9bc495f3/

Vicente has proposed a patch to fix this. However, it involves some
fairly ugly workaround for the external toolchain to work :-/

>          arm |                    tinc-1.0.24 | NOK | http://autobuild.buildroot.net/results/32da2e5ac384383c1e40eb17bf87970d912b235e/

checking for dlopen in -ldl... no
configure: error: OpenSSL depends on libdl.

>          arm |              webkitgtk24-2.4.9 | NOK | http://autobuild.buildroot.net/results/eb8804abced7297b5edb5073f7a29d8b37dc6c6a/

Traceback (most recent call last):
  File "./Source/JavaScriptCore/inspector/scripts/cssmin.py", line 44, in <module>
    sys.stdout.write(cssminify(sys.stdin.read()))
  File "/home/test/autobuild/instance-2/output/host/usr/lib/python3.4/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 642: ordinal not in range(128)
make[1]: *** [DerivedSources/WebCore/XMLViewerCSS.h] Error 1

Gustavo, can you have a look?

>          arm |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/ef685a41a56e81dc93a40f23f8cd55860f44e055/
>          arm |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/d842a17476e52f064d678a6a1a9ac5f7b6f2446e/
>          arc |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/c42d72498e05364a718748caef74bba6c423d7d1/

  CC       shared/libshared_la-os-compatibility.lo
src/compositor-rdp.c: In function 'rdp_peer_init':
src/compositor-rdp.c:1109:10: error: 'rdpSettings' has no member named 'SurfaceFrameMarkerEnabled'
  settings->SurfaceFrameMarkerEnabled = TRUE;

Yann, can you have a look?

>      powerpc |     xserver_xorg-server-1.17.2 | NOK | http://autobuild.buildroot.net/results/0900f6d340b92c6fd1d391a9e2424d0b421c3cba/

The DRM/DRI mess.

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

[Buildroot] Analysis of build results for 2015-08-18

[Brendan Heading]

Thomas, Yann,

>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/98fd1c9a3f92d2354fe3bd9c233916f720e26234/
>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/7ce7267bdc4da3bd0069cec49b8286316d220cd9/
>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/3ebe4454210fb257af08a0ca9cd13844d6985d58/
>>        sparc |                 busybox-1.23.2 | NOK | http://autobuild.buildroot.net/results/cf90773bcca2b0401135779a293af33dc9cf658b/
>
> Peter, what do you suggest we do about these issues for the release?
> Long-term, libtirpc will be changed to not use atomic builtins. But
> what do we do now? Mark libtirpc as not available on SPARCv8, and
> propagate the reverse dependency?

Can I suggest that you just leave it broken ? I suspect it's been
broken for a little while. The problem in libtirpc was a commit in
2011, which would have first been seen in stable release 0.2.3 in
2013. We jumped from 0.2.2 to 0.2.4 on 26 Jun 2014 (f2ac23454) so each
release since then will have had this problem. A simple workaround in
the short term is simply to turn off libtirpc on SPARC manually.

I've been talking to the devs about this. After some discussion
they've pretty much come to the view that the commit which added the
use of the atomic builtins to the library was a bad idea to start
with, as it exposed extra, needless functionality to the caller that
is not part of the TI-RPC API. So the plan at the moment is to remove
it entirely, which will fix our build bug here. This should fix a
number of other packages that fail on SPARC due to dependence on
libtirpc.

It will take another week or so to sort this out as we're waiting for
the person who committed the change in the first place (in 2011) to
return from vacation so he can comment on it. The fix should be ready
by the end of the month assuming no objections are raised.

>>          arm |                linux-pam-1.1.8 | NOK | http://autobuild.buildroot.net/results/e337d69420ad00b2cc4017d639a31803926f2353/
>
> musl build issue.

I have fixed most of this, nearly ready to submit a patch set once
I've tidied it all up. There are several further problems that also
have to be fixed. An additional headache is that the changes clash
with some of the existing patches.

Also, I've had to implement some functions that are missing from musl
entirely (by borrowing BSD implementations and conditionally
compiling). I know that Yann has been disabling musl support with
other packages that require this kind of change, so I'd be interested
to hear what the view is. linux-pam is a reasonably major component
and part of the justification for musl is to do with security ..

I will try to send an RFC patch tomorrow, it might take an iteration
or two to get it right. This might be a case where it is appropriate
to disable libpam + musl in the coming release.

regards

Brendan

[Buildroot] Analysis of build results for 2015-08-18

[Peter Korsgaard]

>>>>> "Brendan" == Brendan Heading <brendanheading@gmail.com> writes:

Hi,

 >> Peter, what do you suggest we do about these issues for the release?
 >> Long-term, libtirpc will be changed to not use atomic builtins. But
 >> what do we do now? Mark libtirpc as not available on SPARCv8, and
 >> propagate the reverse dependency?

 > Can I suggest that you just leave it broken ? I suspect it's been
 > broken for a little while. The problem in libtirpc was a commit in
 > 2011, which would have first been seen in stable release 0.2.3 in
 > 2013. We jumped from 0.2.2 to 0.2.4 on 26 Jun 2014 (f2ac23454) so each
 > release since then will have had this problem. A simple workaround in
 > the short term is simply to turn off libtirpc on SPARC manually.

Yes, that's fine by me.

 > It will take another week or so to sort this out as we're waiting for
 > the person who committed the change in the first place (in 2011) to
 > return from vacation so he can comment on it. The fix should be ready
 > by the end of the month assuming no objections are raised.

Ok, let us know how it goes.

 >>> arm | linux-pam-1.1.8 | NOK |
 >>> http://autobuild.buildroot.net/results/e337d69420ad00b2cc4017d639a31803926f2353/
 >> 
 >> musl build issue.

 > I have fixed most of this, nearly ready to submit a patch set once
 > I've tidied it all up. There are several further problems that also
 > have to be fixed. An additional headache is that the changes clash
 > with some of the existing patches.

 > Also, I've had to implement some functions that are missing from musl
 > entirely (by borrowing BSD implementations and conditionally
 > compiling). I know that Yann has been disabling musl support with
 > other packages that require this kind of change, so I'd be interested
 > to hear what the view is. linux-pam is a reasonably major component
 > and part of the justification for musl is to do with security ..

 > I will try to send an RFC patch tomorrow, it might take an iteration
 > or two to get it right. This might be a case where it is appropriate
 > to disable libpam + musl in the coming release.

For 2015.08 I would prefer to just disable it for musl. In general, we
want to carry as few / small patches as possible - So if we can work
with upstream to get these included that would be very good.

-- 
Bye, Peter Korsgaard

[Buildroot] Analysis of build results for 2015-08-18

[Brendan Heading]

[libpam]

>  > I will try to send an RFC patch tomorrow, it might take an iteration
>  > or two to get it right. This might be a case where it is appropriate
>  > to disable libpam + musl in the coming release.
>
> For 2015.08 I would prefer to just disable it for musl. In general, we
> want to carry as few / small patches as possible - So if we can work
> with upstream to get these included that would be very good.

Okay, will I send a patch to disable with musl for the short term ?

In the longer term - this could get complicated. There are 9 patches
in buildroot already against linux-pam and none have the
upstream-status marked :(. Also, we are two releases (= two years)
behind the upstream. I think I'll need to review all of the buildroot
patches to see if they've made it up there, and look at doing a
version bump to the latest.

Brendan

[Buildroot] Analysis of build results for 2015-08-18

[Thomas Petazzoni]

Dear Brendan Heading,

On Wed, 19 Aug 2015 22:56:44 +0100, Brendan Heading wrote:

> > Peter, what do you suggest we do about these issues for the release?
> > Long-term, libtirpc will be changed to not use atomic builtins. But
> > what do we do now? Mark libtirpc as not available on SPARCv8, and
> > propagate the reverse dependency?
> 
> Can I suggest that you just leave it broken ?

Leaving things broken in the autobuilders is annoying. For two reasons:

 1/ Due to this Busybox failure on SPARC, many SPARC builds abort at
    this point, and we don't see other SPARC failures.

 2/ It leaves some "noise" in the build results, and due to this it's
    hard to distinguish the build failures that should be investigated
    from the ones that are already analyzed.

> I suspect it's been
> broken for a little while. The problem in libtirpc was a commit in
> 2011, which would have first been seen in stable release 0.2.3 in
> 2013. We jumped from 0.2.2 to 0.2.4 on 26 Jun 2014 (f2ac23454) so each
> release since then will have had this problem. A simple workaround in
> the short term is simply to turn off libtirpc on SPARC manually.

Testing SPARC in the autobuilders is fairly recent, that's why we're
only tackling this problem now.

> It will take another week or so to sort this out as we're waiting for
> the person who committed the change in the first place (in 2011) to
> return from vacation so he can comment on it. The fix should be ready
> by the end of the month assuming no objections are raised.

I doubt we can get this merged for 2015.08, though. It will probably be
2015.11 material.

In any case, thanks a lot for working on this libtirpc topic, it has
been around for a while, so it's good to have someone looking into this!

Best regards,

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

[Buildroot] Analysis of build results for 2015-08-18

[Brendan Heading]

> Leaving things broken in the autobuilders is annoying. For two reasons:
>
>  1/ Due to this Busybox failure on SPARC, many SPARC builds abort at
>     this point, and we don't see other SPARC failures.
>
>  2/ It leaves some "noise" in the build results, and due to this it's
>     hard to distinguish the build failures that should be investigated
>     from the ones that are already analyzed.

Understood. Would you like me to put together a "disable libtirpc on
SPARC" patch then ?

We can make it temporary, like the one I submitted for libpam.

> I doubt we can get this merged for 2015.08, though. It will probably be
> 2015.11 material.
>
> In any case, thanks a lot for working on this libtirpc topic, it has
> been around for a while, so it's good to have someone looking into this!

Not at all, it's fun. Kind of like pulling teeth. ;) And it's been
great to learn the ropes in terms of submitting things to open source
projects too.

regards

Brendan

[Buildroot] Analysis of build results for 2015-08-18

[Thomas Petazzoni]

Dear Brendan Heading,

On Fri, 21 Aug 2015 12:38:33 +0100, Brendan Heading wrote:
> > Leaving things broken in the autobuilders is annoying. For two reasons:
> >
> >  1/ Due to this Busybox failure on SPARC, many SPARC builds abort at
> >     this point, and we don't see other SPARC failures.
> >
> >  2/ It leaves some "noise" in the build results, and due to this it's
> >     hard to distinguish the build failures that should be investigated
> >     from the ones that are already analyzed.
> 
> Understood. Would you like me to put together a "disable libtirpc on
> SPARC" patch then ?

I think we'll just ship 2015.08 with the SPARCv8 breakage on libtirpc.
I must admit I'm not sure what to do with SPARCv8. Should we simply
deprecate it, and if someone complain, ask that someone to help
maintaining the platform?

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

[Buildroot] Analysis of build results for 2015-08-18

[Yann E. MORIN]

Thomas, All,

On 2015-08-19 22:41 +0200, Thomas Petazzoni spake thusly:
> On Wed, 19 Aug 2015 08:30:13 +0200 (CEST), Thomas Petazzoni wrote:
[--SNIP--]
> >          arm |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/ef685a41a56e81dc93a40f23f8cd55860f44e055/
> >          arm |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/d842a17476e52f064d678a6a1a9ac5f7b6f2446e/
> >          arc |                   weston-1.8.0 | NOK | http://autobuild.buildroot.net/results/c42d72498e05364a718748caef74bba6c423d7d1/
> 
>   CC       shared/libshared_la-os-compatibility.lo
> src/compositor-rdp.c: In function 'rdp_peer_init':
> src/compositor-rdp.c:1109:10: error: 'rdpSettings' has no member named 'SurfaceFrameMarkerEnabled'
>   settings->SurfaceFrameMarkerEnabled = TRUE;

That's because we're using FreeRDP from the stable-1.1 branch, while
weston expect someything from the master branch.

For master, I'll mark the weston RDP compositor broken. For next, I'll
see if we can bump FreeRDP.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'