[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Thomas Petazzoni]

Hello,

Build statistics for 2017-05-11
================================

      successes : 244
       failures : 21 
       timeouts : 0  
          TOTAL : 265

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

                 opencv3-3.2.0 | 3 
                  libcdio-0.94 | 2 
                 mplayer-1.3.0 | 2 
                  ntp-4.2.8p10 | 2 
                    radvd-2.12 | 2 
             bluez_utils-4.101 | 1 
        ltp-testsuite-20170116 | 1 
                   mimic-1.1.0 | 1 
openblas-f04af36ad0e85b64f1... | 1 
                poppler-0.54.0 | 1 
                protobuf-3.2.0 | 1 
               skalibs-2.4.0.2 | 1 
                 sudo-1.8.19p2 | 1 
uclibc-ng-test-c9b9876cefc1... | 1 
               upmpdcli-1.2.12 | 1 


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

         arm |              bluez_utils-4.101 | NOK | http://autobuild.buildroot.net/results/07e2f952ec974ab765acdf9209d2026504d495cc |     
         arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/6c305d720062c651dd856ed0bc5d30ab5fb31285 |     
         arc |                   libcdio-0.94 | NOK | http://autobuild.buildroot.net/results/ebc83038f86b49bce818bf43b4479ca5df86b2dd |     
    mips64el |         ltp-testsuite-20170116 | NOK | http://autobuild.buildroot.net/results/b448569c1f899f08f704e556208b1db2be04f46e |     
      mipsel |                    mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/a814dc78a9fc7bc80d0b82083817ddfe9cdb3c29 |     
        i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/525048619d7d4438092ccb2f5d5da8c1e8929f1e |     
        i686 |                  mplayer-1.3.0 | NOK | http://autobuild.buildroot.net/results/b4dfa228118c20737e47323650194e9202567381 |     
     aarch64 |                   ntp-4.2.8p10 | NOK | http://autobuild.buildroot.net/results/1e5d70b1a48bdda4e2708ab584b61a966cbef62a | ORPH
        mips |                   ntp-4.2.8p10 | NOK | http://autobuild.buildroot.net/results/c2a945855172970736a8ffea9c564f029a023344 | ORPH
       sparc | openblas-f04af36ad0e85b64f1... | NOK | http://autobuild.buildroot.net/results/6699b89f96ed7095a14bfa18248444534eb81083 |     
    mips64el |                  opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/421ba36bae19ead1bbe366cc7eac429b45a29990 |     
         arm |                  opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/6b89c74c72694f61a5e86e5f8c26263d9e0afe47 |     
      x86_64 |                  opencv3-3.2.0 | NOK | http://autobuild.buildroot.net/results/32d6ac30ca5621b45f7090abb5fb76d9f577c066 |     
         arm |                 poppler-0.54.0 | NOK | http://autobuild.buildroot.net/results/1cc931a2d9658beebf2b82f10013c04cc3823bdc |     
       sparc |                 protobuf-3.2.0 | NOK | http://autobuild.buildroot.net/results/1a328ea6e202898d5e39c904f713da3667b25806 | ORPH
      xtensa |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/7b9d92c859aa5ba11d6a1b10b482f887d8201eb1 | ORPH
microblazeel |                     radvd-2.12 | NOK | http://autobuild.buildroot.net/results/949a75d96299394e4ac957746fa23a4b52f31b43 | ORPH
       sparc |                skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |     
         arm |                  sudo-1.8.19p2 | NOK | http://autobuild.buildroot.net/results/ebbb4c3138b5023a0c8bd938db1932a25ba5b6fb | ORPH
       nios2 | uclibc-ng-test-c9b9876cefc1... | NOK | http://autobuild.buildroot.net/results/8a0eaea2d3b2fb76bd68fab22623e118e00173cb |     
         arm |                upmpdcli-1.2.12 | NOK | http://autobuild.buildroot.net/results/251c6ea384f638a8ab6831394b62373baef6f63a |     

-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Eric Le Bihan]

Hi!

On 17-05-12 08:29:50, Thomas Petazzoni wrote:

>        sparc |                skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |

This one is puzzling. The configure steps ends with the following error:

```
Checking whether system has auto-close after fd-passing...
  ... test crashed, aborting.
  make: ***
  [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured]
  Error 111
  make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
```

The configure script tries to cross-compile and execute a program
(tryancilautoclose). The cross-compilation succeeds and of course the
execution fails, as it means running a program compiled for the
SPARC architecture on a x86 machine. Normally, the shell which executes
the program should return the code 126, as mentioned in the list of Bash
exit codes with special meaning [1].

Here the exit code is 111. When looking at tryancilautoclose.c, we can
see that 111 may be returned.

So this error means that either the shell managed to execute the
cross-compiled program or the shell does not follow the convention [1].

Which are the architecture of the build machine and the shell used?

[1] http://tldp.org/LDP/abs/html/exitcodes.html

--
ELB

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Thomas Petazzoni]

Hello,

On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote:

> On 17-05-12 08:29:50, Thomas Petazzoni wrote:
> 
> >        sparc |                skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |  
> 
> This one is puzzling. The configure steps ends with the following error:
> 
> ```
> Checking whether system has auto-close after fd-passing...
>   ... test crashed, aborting.
>   make: ***
>   [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured]
>   Error 111
>   make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
> ```
> 
> The configure script tries to cross-compile and execute a program
> (tryancilautoclose). The cross-compilation succeeds and of course the
> execution fails, as it means running a program compiled for the
> SPARC architecture on a x86 machine. Normally, the shell which executes
> the program should return the code 126, as mentioned in the list of Bash
> exit codes with special meaning [1].
> 
> Here the exit code is 111. When looking at tryancilautoclose.c, we can
> see that 111 may be returned.
> 
> So this error means that either the shell managed to execute the
> cross-compiled program or the shell does not follow the convention [1].
> 
> Which are the architecture of the build machine and the shell used?

Thanks for investigating this issue. This build failure occurred on
Matt Weber's autobuilder instance, so I've added him in Cc. His
instance has already triggered some weird issues recently due to an
unusual setup. Hopefully Matt will be able to shed some light on what's
going on, possibly reproduce by hand the issue and investigate.

Thanks!

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

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Matthew Weber]

Thomas/Eric,

On Sun, May 14, 2017 at 2:19 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote:
>
>> On 17-05-12 08:29:50, Thomas Petazzoni wrote:
>>
>> >        sparc |                skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |
>>
>> This one is puzzling. The configure steps ends with the following error:
>>
>> ```
>> Checking whether system has auto-close after fd-passing...
>>   ... test crashed, aborting.
>>   make: ***
>>   [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured]
>>   Error 111
>>   make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
>> ```
>>
>> The configure script tries to cross-compile and execute a program
>> (tryancilautoclose). The cross-compilation succeeds and of course the
>> execution fails, as it means running a program compiled for the
>> SPARC architecture on a x86 machine. Normally, the shell which executes
>> the program should return the code 126, as mentioned in the list of Bash
>> exit codes with special meaning [1].
>>
>> Here the exit code is 111. When looking at tryancilautoclose.c, we can
>> see that 111 may be returned.
>>
>> So this error means that either the shell managed to execute the
>> cross-compiled program or the shell does not follow the convention [1].
>>
>> Which are the architecture of the build machine and the shell used?
>
> Thanks for investigating this issue. This build failure occurred on
> Matt Weber's autobuilder instance, so I've added him in Cc. His
> instance has already triggered some weird issues recently due to an
> unusual setup. Hopefully Matt will be able to shed some light on what's
> going on, possibly reproduce by hand the issue and investigate.
>

Here's the machine info
# uname -a
Linux largo 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
# ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Nov 18  2014 /bin/sh -> bash
# bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

I'll kick off a manual recreation now and see how it ends up.

Matt

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Matthew Weber]

Eric,

On Sun, May 14, 2017 at 8:09 PM, Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
> Thomas/Eric,
>
> On Sun, May 14, 2017 at 2:19 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote:
>>
>>> On 17-05-12 08:29:50, Thomas Petazzoni wrote:
>>>
>>> >        sparc |                skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |
>>>
>>> This one is puzzling. The configure steps ends with the following error:
>>>
>>> ```
>>> Checking whether system has auto-close after fd-passing...
>>>   ... test crashed, aborting.
>>>   make: ***
>>>   [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured]
>>>   Error 111
>>>   make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
>>> ```
>>>
>>> The configure script tries to cross-compile and execute a program
>>> (tryancilautoclose). The cross-compilation succeeds and of course the
>>> execution fails, as it means running a program compiled for the
>>> SPARC architecture on a x86 machine. Normally, the shell which executes
>>> the program should return the code 126, as mentioned in the list of Bash
>>> exit codes with special meaning [1].
>>>
>>> Here the exit code is 111. When looking at tryancilautoclose.c, we can
>>> see that 111 may be returned.
>>>
>>> So this error means that either the shell managed to execute the
>>> cross-compiled program or the shell does not follow the convention [1].
>>>
>>> Which are the architecture of the build machine and the shell used?
>>
>> Thanks for investigating this issue. This build failure occurred on
>> Matt Weber's autobuilder instance, so I've added him in Cc. His
>> instance has already triggered some weird issues recently due to an
>> unusual setup. Hopefully Matt will be able to shed some light on what's
>> going on, possibly reproduce by hand the issue and investigate.
>>
>
> Here's the machine info
> # uname -a
> Linux largo 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC
> 2014 x86_64 x86_64 x86_64 GNU/Linux
> # ls -l /bin/sh
> lrwxrwxrwx 1 root root 4 Nov 18  2014 /bin/sh -> bash
> # bash --version
> GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>
> I'll kick off a manual recreation now and see how it ends up.
>

Well this is interesting and I'll have to dig around some more but
here's what I've found after doing a build.  It looks like I have
SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine.  I
can execute the test app since it's statically linked.

# ./tryancilautoclose
Unsupported ancillary data: 65535/1
# echo $?
111
# file tryancilautoclose
tryancilautoclose: ELF 32-bit MSB  executable, SPARC version 1 (SYSV),
statically linked, with unknown capability 0x41000000 = 0xf676e75,
with unknown capability 0x10000 = 0x70403, not stripped

Matt

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Matthew Weber]

All,

On Sun, May 14, 2017 at 9:53 PM, Matthew Weber
<matthew.weber@rockwellcollins.com> wrote:
> Eric,
>
> On Sun, May 14, 2017 at 8:09 PM, Matthew Weber
> <matthew.weber@rockwellcollins.com> wrote:
>> Thomas/Eric,
>>
>> On Sun, May 14, 2017 at 2:19 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Hello,
>>>
>>> On Sun, 14 May 2017 19:45:06 +0200, Eric Le Bihan wrote:
>>>
>>>> On 17-05-12 08:29:50, Thomas Petazzoni wrote:
>>>>
>>>> >        sparc |                skalibs-2.4.0.2 | NOK | http://autobuild.buildroot.net/results/85062b5f9dbe74d7d1c6edfeda085268ecaef4c2 |
>>>>
>>>> This one is puzzling. The configure steps ends with the following error:
>>>>
>>>> ```
>>>> Checking whether system has auto-close after fd-passing...
>>>>   ... test crashed, aborting.
>>>>   make: ***
>>>>   [/accts/mlweber1/instance-2/output/build/skalibs-2.4.0.2/.stamp_configured]
>>>>   Error 111
>>>>   make: Leaving directory `/accts/mlweber1/instance-2/buildroot'
>>>> ```
>>>>
>>>> The configure script tries to cross-compile and execute a program
>>>> (tryancilautoclose). The cross-compilation succeeds and of course the
>>>> execution fails, as it means running a program compiled for the
>>>> SPARC architecture on a x86 machine. Normally, the shell which executes
>>>> the program should return the code 126, as mentioned in the list of Bash
>>>> exit codes with special meaning [1].
>>>>
>>>> Here the exit code is 111. When looking at tryancilautoclose.c, we can
>>>> see that 111 may be returned.
>>>>
>>>> So this error means that either the shell managed to execute the
>>>> cross-compiled program or the shell does not follow the convention [1].
>>>>
>>>> Which are the architecture of the build machine and the shell used?
>>>
>>> Thanks for investigating this issue. This build failure occurred on
>>> Matt Weber's autobuilder instance, so I've added him in Cc. His
>>> instance has already triggered some weird issues recently due to an
>>> unusual setup. Hopefully Matt will be able to shed some light on what's
>>> going on, possibly reproduce by hand the issue and investigate.
>>>
>>
>> Here's the machine info
>> # uname -a
>> Linux largo 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC
>> 2014 x86_64 x86_64 x86_64 GNU/Linux
>> # ls -l /bin/sh
>> lrwxrwxrwx 1 root root 4 Nov 18  2014 /bin/sh -> bash
>> # bash --version
>> GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>>
>> I'll kick off a manual recreation now and see how it ends up.
>>
>
> Well this is interesting and I'll have to dig around some more but
> here's what I've found after doing a build.  It looks like I have
> SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine.  I
> can execute the test app since it's statically linked.
>
> # ./tryancilautoclose
> Unsupported ancillary data: 65535/1
> # echo $?
> 111
> # file tryancilautoclose
> tryancilautoclose: ELF 32-bit MSB  executable, SPARC version 1 (SYSV),
> statically linked, with unknown capability 0x41000000 = 0xf676e75,
> with unknown capability 0x10000 = 0x70403, not stripped
>

Ok, didn't realize the qemu-user-static will automatically hook-up
support for executing the arch it supports seamlessly.  When I straced
I noticed the call into qemu-sparc-static.  Since removing that
package, I now observe what would be expected.

# ./tryancilautoclose
bash: ./tryancilautoclose: cannot execute binary file: Exec format error
# echo $?
 11126

Sorry about that one Eric, it's fixed now on that machine and shouldn't reoccur.

Thomas, should there be a check or warning added as part of
buildroot's package/host checking which would catch a case where
qemu-user-static is installed and may adversely affect the build?

Matt

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Thomas Petazzoni]

Hello,

On Sun, 14 May 2017 22:03:27 -0500, Matthew Weber wrote:

> > Well this is interesting and I'll have to dig around some more but
> > here's what I've found after doing a build.  It looks like I have
> > SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine.  I
> > can execute the test app since it's statically linked.
> >
> > # ./tryancilautoclose
> > Unsupported ancillary data: 65535/1
> > # echo $?
> > 111
> > # file tryancilautoclose
> > tryancilautoclose: ELF 32-bit MSB  executable, SPARC version 1 (SYSV),
> > statically linked, with unknown capability 0x41000000 = 0xf676e75,
> > with unknown capability 0x10000 = 0x70403, not stripped
> 
> Ok, didn't realize the qemu-user-static will automatically hook-up
> support for executing the arch it supports seamlessly.  When I straced
> I noticed the call into qemu-sparc-static.  Since removing that
> package, I now observe what would be expected.

Wow, ok. Thanks a lot for investigating this issue.

> # ./tryancilautoclose
> bash: ./tryancilautoclose: cannot execute binary file: Exec format error
> # echo $?
>  11126
> 
> Sorry about that one Eric, it's fixed now on that machine and shouldn't reoccur.
> 
> Thomas, should there be a check or warning added as part of
> buildroot's package/host checking which would catch a case where
> qemu-user-static is installed and may adversely affect the build?

Yes, we should definitely do something about that. Ideally, Buildroot
should do something to prevent binfmt_misc from kicking off the
execution of foreign binaries. I have no idea if this is possible. If
not, at the very least, we should warn/error out, but I really hate
when a build system/tool asks me to change my system-wide configuration
to operate correctly.

Best regards,

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

[Buildroot] [autobuild.buildroot.net] Build results for 2017-05-11

[Matthew Weber]

Thomas,

On Mon, May 15, 2017 at 2:23 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Sun, 14 May 2017 22:03:27 -0500, Matthew Weber wrote:
>
>> > Well this is interesting and I'll have to dig around some more but
>> > here's what I've found after doing a build.  It looks like I have
>> > SPARC ELF ABI compatibility on my x86_64 Ubuntu 14.04.1 machine.  I
>> > can execute the test app since it's statically linked.
>> >
>> > # ./tryancilautoclose
>> > Unsupported ancillary data: 65535/1
>> > # echo $?
>> > 111
>> > # file tryancilautoclose
>> > tryancilautoclose: ELF 32-bit MSB  executable, SPARC version 1 (SYSV),
>> > statically linked, with unknown capability 0x41000000 = 0xf676e75,
>> > with unknown capability 0x10000 = 0x70403, not stripped
>>
>> Ok, didn't realize the qemu-user-static will automatically hook-up
>> support for executing the arch it supports seamlessly.  When I straced
>> I noticed the call into qemu-sparc-static.  Since removing that
>> package, I now observe what would be expected.
>
> Wow, ok. Thanks a lot for investigating this issue.
>
>> # ./tryancilautoclose
>> bash: ./tryancilautoclose: cannot execute binary file: Exec format error
>> # echo $?
>>  11126
>>
>> Sorry about that one Eric, it's fixed now on that machine and shouldn't reoccur.
>>
>> Thomas, should there be a check or warning added as part of
>> buildroot's package/host checking which would catch a case where
>> qemu-user-static is installed and may adversely affect the build?
>
> Yes, we should definitely do something about that. Ideally, Buildroot
> should do something to prevent binfmt_misc from kicking off the
> execution of foreign binaries. I have no idea if this is possible. If
> not, at the very least, we should warn/error out, but I really hate
> when a build system/tool asks me to change my system-wide configuration
> to operate correctly.
>

I looked at this a bit more, I think we could check for
/proc/sys/fs/binfmt_misc being mounted and then see if any qemu-*
files exist.  Beyond that I'm unsure of the action to take.
I think for autobuilder machines they should error out from the
autobuilder script as you'd want binfmts disabled (sudo update-binfmts
--disable) before that runs.  However for the normal shared use
server/build machine it does seem like an issue to enforce having that
disabled as a pre-req to doing a buildroot build. Maybe a check
initially at the beginning of make to warn the user.....

Matt