[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Thomas Petazzoni]

Hello,

Build statistics for 2019-06-10
===============================

      branch |  OK | NOK | TIM | TOT |
   2019.02.x |  17 |   2 |   0 |  19 |
   2019.05.x |  23 |   2 |   0 |  25 |
      master | 188 |  21 |   1 | 210 |

Results for branch '2019.05.x'
==============================

Classification of failures by reason
------------------------------------

kvm-unit-tests-kvm-unit-tes... | 1 
             openjdk-jdk-12+33 | 1 


Detail of failures
------------------

      x86_64 | kvm-unit-tests-kvm-unit-tes... | NOK | http://autobuild.buildroot.net/results/77d159d935ffc351bfc6e18d2a637803ecd8d573 |     
   powerpc64 |              openjdk-jdk-12+33 | NOK | http://autobuild.buildroot.net/results/6afebe3ff4221cd6cfc67af02b20f1fe05a299a8 |     

Results for branch 'master'
===========================

Classification of failures by reason
------------------------------------

    host-mender-artifact-3.0.0 | 5 
libwebsock-3c1615eeadb0b582... | 3 
  vdr-plugin-vnsiserver-v1.8.0 | 2 
                   cups-2.2.10 | 1 
               host-efl-1.22.2 | 1 
           host-mfgtools-v0.02 | 1 
   host-xapp_mkfontscale-1.1.3 | 1 
                  libssh-0.8.7 | 1 
                 mesa3d-19.0.6 | 1 
                         mimic | 1 
                   mimic-1.1.0 | 1 
        network-manager-1.18.0 | 1 
                poppler-0.77.0 | 1 
           udpxy-1.0.23-9-prod | 1 
               wireshark-3.0.2 | 1 


Detail of failures
------------------

 powerpc64le |                    cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 |     
         arm |                host-efl-1.22.2 | NOK | http://autobuild.buildroot.net/results/b4744a79697777b0d40c6e070ac5c1c95076271d |     
        m68k |     host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/c82b10b6db02b2a87c45f41bd35bc0c5d5beddc6 |     
         arm |     host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/0fc486fc037c697b7605f330aafc6a64dd2bc675 |     
        i686 |     host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/1a62dba60f96275ea15471ee7f8588475b2ce5f9 |     
         arm |     host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/f9ba64ab4c8d7fa6cb301fab37ee4141ba442f61 |     
        m68k |     host-mender-artifact-3.0.0 | NOK | http://autobuild.buildroot.net/results/71853edaac4d9ed2a29b579e4abf62a68691dbfb |     
         arm |            host-mfgtools-v0.02 | NOK | http://autobuild.buildroot.net/results/42644ede89ad15b2ebcc307a9121d5b647629978 |     
         arm |    host-xapp_mkfontscale-1.1.3 | NOK | http://autobuild.buildroot.net/results/b5ec2d2d17e64ca7b85ebd7e4d0d880eaa661170 |     
      xtensa |                   libssh-0.8.7 | NOK | http://autobuild.buildroot.net/results/f03d4225b6c3a3ec8558f96a6a8c91c0318aa6bc |     
     aarch64 | libwebsock-3c1615eeadb0b582... | NOK | http://autobuild.buildroot.net/results/bfbb6d3e31033cc598f2288bce8f1447e79f09b0 |     
     aarch64 | libwebsock-3c1615eeadb0b582... | NOK | http://autobuild.buildroot.net/results/e2cbd9396caea7890996dd6b9e88e7236e46fd1a |     
     riscv32 | libwebsock-3c1615eeadb0b582... | NOK | http://autobuild.buildroot.net/results/3bc54e2fdce307007b68f5323594666b15343d62 |     
         sh4 |                  mesa3d-19.0.6 | NOK | http://autobuild.buildroot.net/results/1ea031c402f5416851e2a5467cee76f906a6be2a |     
        or1k |                          mimic | TIM | http://autobuild.buildroot.net/results/751953b121670bb51e3f16f63a9223311f119b6e |     
     powerpc |                    mimic-1.1.0 | NOK | http://autobuild.buildroot.net/results/0f0e7521f47cb92ea3ceab6af56a0618c4cf218a |     
       nios2 |         network-manager-1.18.0 | NOK | http://autobuild.buildroot.net/results/e47c7d855b452079a165ad4540b2e5ccd4162e19 | ORPH
     powerpc |                 poppler-0.77.0 | NOK | http://autobuild.buildroot.net/results/2c8695b75c3241359e739d88726430cbfe47a5bd |     
        i686 |            udpxy-1.0.23-9-prod | NOK | http://autobuild.buildroot.net/results/114adf08cd94473b59ff46819b27578466647e4a |     
     riscv32 |   vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/40268ca7d9ba32963de239923cd2ca18a0011b37 |     
         arm |   vdr-plugin-vnsiserver-v1.8.0 | NOK | http://autobuild.buildroot.net/results/de2e7db30aec888419c22dea08f4f769d9577afd |     
     powerpc |                wireshark-3.0.2 | NOK | http://autobuild.buildroot.net/results/1284723ae2886cfe05b8337d6cdd184ba1d7e5c7 | ORPH

Results for branch '2019.02.x'
==============================

Classification of failures by reason
------------------------------------

                   glm-0.9.8.4 | 2 


Detail of failures
------------------

        i686 |                    glm-0.9.8.4 | NOK | http://autobuild.buildroot.net/results/b01e79868cb2ec843adcf1f72662a23018eb1a0c | ORPH
        i686 |                    glm-0.9.8.4 | NOK | http://autobuild.buildroot.net/results/f02e8842bcae2fb69294def3fc29bd305cefe007 | ORPH


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Sam Bobroff]

On Tue, Jun 11, 2019 at 06:00:42AM -0000, Thomas Petazzoni wrote:
> Hello,

[snip]

> Detail of failures
> ------------------
> 
>  powerpc64le |                    cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 |     

[snip]

This failure building cups seems to be caused by an interaction between
buildroot and the cups package:

a) Buildroot setting the environment variable "GZIP" to "-n", and
b) the cups package internally using a Make variable "GZIP" for the path to
the gzip binary (i.e. "/bin/gzip").

So, when Make executes the rules for "install-data", the existance of
GZIP in Make's environment causes it to export it's value of GZIP into
the environment for the rules. Unfortunately for gzip, which is
expecting to see command line arguments in $GZIP, it now sees it's own
path as a command line option and the build fails with:

gzip: /bin/gzip.gz: Permission denied

I think the real fix should be in cups, because I *think* what all this
means is that it's always a bad idea to use a Make variable called
'GZIP' and they should rename it there. It fails the same way on the
master branch of cups so I've filed a bug report on their github issue
tracker.

However, it's easy to work around on the buildroot side with a hack in
the package file:
CUPS_MAKE_ENV = env -u GZIP
... but it does seem a bit cheeky to sneak a call to "env" in there. Is
there a better way to remove a variable from make's environment?

Should I post a patch for that fix, or a better one, for buildroot to
use before upstream fixes it? (Assuming they do.)

Cheers,
Sam.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190612/028e8b72/attachment.asc>

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Thomas Petazzoni]

Hello Sam,

First of all, thanks for the investigation. Adding Atharva, Arnout and
Yann in Cc, since the issue is due to BR2_REPRODUCIBLE=y.

On Wed, 12 Jun 2019 15:33:53 +1000
Sam Bobroff <sbobroff@linux.ibm.com> wrote:

> >  powerpc64le |                    cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 |       
> 
> [snip]
> 
> This failure building cups seems to be caused by an interaction between
> buildroot and the cups package:
> 
> a) Buildroot setting the environment variable "GZIP" to "-n", and
> b) the cups package internally using a Make variable "GZIP" for the path to
> the gzip binary (i.e. "/bin/gzip").
> 
> So, when Make executes the rules for "install-data", the existance of
> GZIP in Make's environment causes it to export it's value of GZIP into
> the environment for the rules. Unfortunately for gzip, which is
> expecting to see command line arguments in $GZIP, it now sees it's own
> path as a command line option and the build fails with:
> 
> gzip: /bin/gzip.gz: Permission denied
> 
> I think the real fix should be in cups, because I *think* what all this
> means is that it's always a bad idea to use a Make variable called
> 'GZIP' and they should rename it there. It fails the same way on the
> master branch of cups so I've filed a bug report on their github issue
> tracker.
> 
> However, it's easy to work around on the buildroot side with a hack in
> the package file:
> CUPS_MAKE_ENV = env -u GZIP
> ... but it does seem a bit cheeky to sneak a call to "env" in there. Is
> there a better way to remove a variable from make's environment?

Dropping the GZIP environment variable is maybe not going to work well
either: the reason why GZIP = -n is because of BR2_REPRODUCIBLE=y. The
-n option of gzip tells gzip to not store the file name and timestamp,
which is necessary for reproducible builds. Of course, it all depends
if the files that are being compressed by the cups build end up on the
target. If they don't, we can live without the -n option. However, if
they end up on the target, we really need to keep the -n option.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Sam Bobroff]

On Wed, Jun 12, 2019 at 08:49:27AM +0200, Thomas Petazzoni wrote:
> Hello Sam,
> 
> First of all, thanks for the investigation. Adding Atharva, Arnout and
> Yann in Cc, since the issue is due to BR2_REPRODUCIBLE=y.
> 
> On Wed, 12 Jun 2019 15:33:53 +1000
> Sam Bobroff <sbobroff@linux.ibm.com> wrote:
> 
> > >  powerpc64le |                    cups-2.2.10 | NOK | http://autobuild.buildroot.net/results/c4e0f6a3c79c9cb083a08f811b7d4838efef50f9 |       
> > 
> > [snip]
> > 
> > This failure building cups seems to be caused by an interaction between
> > buildroot and the cups package:
> > 
> > a) Buildroot setting the environment variable "GZIP" to "-n", and
> > b) the cups package internally using a Make variable "GZIP" for the path to
> > the gzip binary (i.e. "/bin/gzip").
> > 
> > So, when Make executes the rules for "install-data", the existance of
> > GZIP in Make's environment causes it to export it's value of GZIP into
> > the environment for the rules. Unfortunately for gzip, which is
> > expecting to see command line arguments in $GZIP, it now sees it's own
> > path as a command line option and the build fails with:
> > 
> > gzip: /bin/gzip.gz: Permission denied
> > 
> > I think the real fix should be in cups, because I *think* what all this
> > means is that it's always a bad idea to use a Make variable called
> > 'GZIP' and they should rename it there. It fails the same way on the
> > master branch of cups so I've filed a bug report on their github issue
> > tracker.
> > 
> > However, it's easy to work around on the buildroot side with a hack in
> > the package file:
> > CUPS_MAKE_ENV = env -u GZIP
> > ... but it does seem a bit cheeky to sneak a call to "env" in there. Is
> > there a better way to remove a variable from make's environment?
> 
> Dropping the GZIP environment variable is maybe not going to work well
> either: the reason why GZIP = -n is because of BR2_REPRODUCIBLE=y. The
> -n option of gzip tells gzip to not store the file name and timestamp,
> which is necessary for reproducible builds. Of course, it all depends
> if the files that are being compressed by the cups build end up on the
> target. If they don't, we can live without the -n option. However, if
> they end up on the target, we really need to keep the -n option.

Ah, right. So that hack is no good, and it suggests that no hack on
the buildroot side can work as long as GZIP is being overwritten by the
package's build system. I'll have a go hacking the build system in cups
to rename the GZIP variable but hopefully their upstream will fix it
soon :-)

At least some of the compressed files are part of some kind of test data,
so I'll see if they're the only ones and could perhaps be left out
entirely.

> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190612/22a470e2/attachment.asc>

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Thomas Petazzoni]

Hello,

On Wed, 12 Jun 2019 17:02:01 +1000
Sam Bobroff <sbobroff@linux.ibm.com> wrote:

> Ah, right. So that hack is no good, and it suggests that no hack on
> the buildroot side can work as long as GZIP is being overwritten by the
> package's build system. I'll have a go hacking the build system in cups
> to rename the GZIP variable but hopefully their upstream will fix it
> soon :-)
> 
> At least some of the compressed files are part of some kind of test data,
> so I'll see if they're the only ones and could perhaps be left out
> entirely.

Alternatively, Buildroot could use a gzip wrapper, installed in
$(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. The
gzip man page says that using the GZIP environment variable is
"obsolescent":

      The obsolescent environment variable GZIP can hold a set of default  options
       for  gzip.   These  options  are interpreted first and can be overwritten by
       explicit command line parameters.  As this can  cause  problems  when  using
       scripts,  this  feature  is  supported  only for options that are reasonably
       likely to not cause too much harm, and gzip warns if it is used.  This  fea?
       ture will be removed in a future release of gzip.

       You  can  use  an  alias  or script instead.  For example, if gzip is in the
       directory /usr/bin you can prepend $HOME/bin to your PATH and create an exe?
       cutable script $HOME/bin/gzip containing the following:

             #! /bin/sh
             export PATH=/usr/bin
             exec gzip -9 "$@"

Of course, if we go in this direction, we have to take care of what
happens if host-gzip is installed, as it would overwrite the wrapper.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Arnout Vandecappelle]

On 12/06/2019 09:06, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 12 Jun 2019 17:02:01 +1000
> Sam Bobroff <sbobroff@linux.ibm.com> wrote:
> 
>> Ah, right. So that hack is no good, and it suggests that no hack on
>> the buildroot side can work as long as GZIP is being overwritten by the
>> package's build system. I'll have a go hacking the build system in cups
>> to rename the GZIP variable but hopefully their upstream will fix it
>> soon :-)
>>
>> At least some of the compressed files are part of some kind of test data,
>> so I'll see if they're the only ones and could perhaps be left out
>> entirely.
> 
> Alternatively, Buildroot could use a gzip wrapper, installed in
> $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. 

 That sounds like the right thing to do. We only need to do install that wrapper
if BR2_REPRODUCIBLE=y.

 However, I'm afraid this will turn up packages that explicitly use /bin/gzip
without looking at $PATH... So those will have to be fixed again...

> The
> gzip man page says that using the GZIP environment variable is
> "obsolescent":
> 
>       The obsolescent environment variable GZIP can hold a set of default  options
>        for  gzip.   These  options  are interpreted first and can be overwritten by
>        explicit command line parameters.  As this can  cause  problems  when  using
>        scripts,  this  feature  is  supported  only for options that are reasonably
>        likely to not cause too much harm, and gzip warns if it is used.  This  fea?
>        ture will be removed in a future release of gzip.
> 
>        You  can  use  an  alias  or script instead.  For example, if gzip is in the
>        directory /usr/bin you can prepend $HOME/bin to your PATH and create an exe?
>        cutable script $HOME/bin/gzip containing the following:
> 
>              #! /bin/sh
>              export PATH=/usr/bin
>              exec gzip -9 "$@"
> 
> Of course, if we go in this direction, we have to take care of what
> happens if host-gzip is installed, as it would overwrite the wrapper.

 Didn't we say at some point that under BR2_REPRODUCIBLE, we should always build
all host packages? So the wrapper would be installed as part of host-gzip.

 Atharva, better put this on your list of things to do :-)


 Regards,
 Arnout

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Atharva Lele]

>  Didn't we say at some point that under BR2_REPRODUCIBLE, we should
always build
> all host packages?

What is the reason behind this? I looked for it but did not find much
valuable information.

> Atharva, better put this on your list of things to do :-)

Of course :)

Regards,
Atharva Lele


On Wed, Jun 12, 2019 at 1:56 PM Arnout Vandecappelle <arnout@mind.be> wrote:

>
>
> On 12/06/2019 09:06, Thomas Petazzoni wrote:
> > Hello,
> >
> > On Wed, 12 Jun 2019 17:02:01 +1000
> > Sam Bobroff <sbobroff@linux.ibm.com> wrote:
> >
> >> Ah, right. So that hack is no good, and it suggests that no hack on
> >> the buildroot side can work as long as GZIP is being overwritten by the
> >> package's build system. I'll have a go hacking the build system in cups
> >> to rename the GZIP variable but hopefully their upstream will fix it
> >> soon :-)
> >>
> >> At least some of the compressed files are part of some kind of test
> data,
> >> so I'll see if they're the only ones and could perhaps be left out
> >> entirely.
> >
> > Alternatively, Buildroot could use a gzip wrapper, installed in
> > $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y.
>
>  That sounds like the right thing to do. We only need to do install that
> wrapper
> if BR2_REPRODUCIBLE=y.
>
>  However, I'm afraid this will turn up packages that explicitly use
> /bin/gzip
> without looking at $PATH... So those will have to be fixed again...
>
> > The
> > gzip man page says that using the GZIP environment variable is
> > "obsolescent":
> >
> >       The obsolescent environment variable GZIP can hold a set of
> default  options
> >        for  gzip.   These  options  are interpreted first and can be
> overwritten by
> >        explicit command line parameters.  As this can  cause  problems
> when  using
> >        scripts,  this  feature  is  supported  only for options that are
> reasonably
> >        likely to not cause too much harm, and gzip warns if it is used.
> This  fea?
> >        ture will be removed in a future release of gzip.
> >
> >        You  can  use  an  alias  or script instead.  For example, if
> gzip is in the
> >        directory /usr/bin you can prepend $HOME/bin to your PATH and
> create an exe?
> >        cutable script $HOME/bin/gzip containing the following:
> >
> >              #! /bin/sh
> >              export PATH=/usr/bin
> >              exec gzip -9 "$@"
> >
> > Of course, if we go in this direction, we have to take care of what
> > happens if host-gzip is installed, as it would overwrite the wrapper.
>
>  Didn't we say at some point that under BR2_REPRODUCIBLE, we should always
> build
> all host packages? So the wrapper would be installed as part of host-gzip.
>
>  Atharva, better put this on your list of things to do :-)
>
>
>  Regards,
>  Arnout
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20190612/51e59f93/attachment.html>

[Buildroot] [autobuild.buildroot.net] Build results for 2019-06-10

[Yann E. MORIN]

Arnout, All,

On 2019-06-12 10:26 +0200, Arnout Vandecappelle spake thusly:
> On 12/06/2019 09:06, Thomas Petazzoni wrote:
> > On Wed, 12 Jun 2019 17:02:01 +1000
> > Sam Bobroff <sbobroff@linux.ibm.com> wrote:
> >> Ah, right. So that hack is no good, and it suggests that no hack on
> >> the buildroot side can work as long as GZIP is being overwritten by the
> >> package's build system. I'll have a go hacking the build system in cups
> >> to rename the GZIP variable but hopefully their upstream will fix it
> >> soon :-)
> > Alternatively, Buildroot could use a gzip wrapper, installed in
> > $(HOST_DIR)/bin to pass this -n option when BR2_REPRODUCIBLE=y. 
>  That sounds like the right thing to do. We only need to do install that wrapper
> if BR2_REPRODUCIBLE=y.

Yes, the wrapper thinggy is the best.

>  However, I'm afraid this will turn up packages that explicitly use /bin/gzip
> without looking at $PATH... So those will have to be fixed again...

Yup, but that's not like we are not used to these kind of stupidity,
aren't we? ;-)

> > The
> > gzip man page says that using the GZIP environment variable is
> > "obsolescent":
[--SNIP--]

That alone mandates the use of the wrapper.

> > Of course, if we go in this direction, we have to take care of what
> > happens if host-gzip is installed, as it would overwrite the wrapper.
>  Didn't we say at some point that under BR2_REPRODUCIBLE, we should always build
> all host packages? So the wrapper would be installed as part of host-gzip.

Hmm.. I usually advocate for maximising the number of host packages to
build, so as to indeed improve reproducibility.

But ultimately, I'd like we identify those host tools that indeed
generate non-reproducible output, and so we build our. Otherwise, rely
on the host provided tools.

And ultimately, I'd like that the reproducible option also applies to
the host packages too, so that we can produce reproducible toolchains
and SDKs as well. So, where do we draw the line? Surely, we're not going
to build our own host toolchain. so reproducibility of the host packages
will be limited to some extent, and only guaranteed on the system (i.e.
the machine and distribution) that actually did the build.

So, we'd have two levels of reproducibility: a high level for things
that go in target/ and staging/ (since we handle more tools), and a
lower level for things that go in host/ (since we can't handle all
tools).

Regards,
Yann E. MORIN.

>  Atharva, better put this on your list of things to do :-)
> 
> 
>  Regards,
>  Arnout
> 

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