[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Thomas Petazzoni]

Hello,

Build statistics for 2016-09-02
================================

      successes : 174
       failures : 36 
       timeouts : 0  
          TOTAL : 210

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

                     lxc-2.0.3 | 4 
            micropython-v1.8.3 | 3 
             util-linux-2.28.1 | 3 
               binutils-2.25.1 | 2 
                libxslt-1.1.29 | 2 
                    cups-2.1.4 | 1 
                  dbus-1.10.10 | 1 
           dmraid-1.0.0.rc16-3 | 1 
         docker-engine-v1.12.0 | 1 
               domoticz-3.4834 | 1 
                   erlang-18.3 | 1 
                  fio-fio-2.13 | 1 
                 jack2-v1.9.10 | 1 
kvmtool-372f583d359a5bdcbbe... | 1 
                    lftp-4.7.3 | 1 
              libarchive-3.2.1 | 1 
                  libcdio-0.93 | 1 
                  libffi-3.2.1 | 1 
                libldns-1.6.17 | 1 
                    mosh-1.2.5 | 1 
                    mpv-0.19.0 | 1 
                  openjpeg-2.1 | 1 
                      qt-4.8.7 | 1 
                    ruby-2.3.1 | 1 
                socat-2.0.0-b9 | 1 
         systemd-bootchart-230 | 1 
               trousers-0.3.13 | 1 


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

         arm |                binutils-2.25.1 | NOK | http://autobuild.buildroot.net/results/e1e2acaef571627a6dd173010450c8b7d90116ee
         arm |                binutils-2.25.1 | NOK | http://autobuild.buildroot.net/results/d733d2fa34c9b1e70453c6445254a4f0c7c040a3
        i586 |                     cups-2.1.4 | NOK | http://autobuild.buildroot.net/results/28adc429b7e60b2eb4956504d109d17ccb5643d9
       nios2 |                   dbus-1.10.10 | NOK | http://autobuild.buildroot.net/results/332f31ce9c5e9a6e405867c3cc5b1f260ae7fdcb
         arc |            dmraid-1.0.0.rc16-3 | NOK | http://autobuild.buildroot.net/results/1f0a1de0bca0c18843c363c626c4e708d65a1cd1
     aarch64 |          docker-engine-v1.12.0 | NOK | http://autobuild.buildroot.net/results/5f2b62a67920052e303f74f1830202ca61c0f569
         arm |                domoticz-3.4834 | NOK | http://autobuild.buildroot.net/results/62ec0d348153dff0efd4c1975a9198c17f01f1fa
         arm |                    erlang-18.3 | NOK | http://autobuild.buildroot.net/results/d86348207b3b2a9fcf68453be337b17a860d73ae
         arm |                   fio-fio-2.13 | NOK | http://autobuild.buildroot.net/results/bab10f2c9a5104458138dff8cbd01d03e8681d9d
      xtensa |                  jack2-v1.9.10 | NOK | http://autobuild.buildroot.net/results/d4518dd467555ce209ea914e0861859a5e1a3be2
         arm | kvmtool-372f583d359a5bdcbbe... | NOK | http://autobuild.buildroot.net/results/9fca6356c07874e01e53f85f2f1d7ef56cd3d2f3
         arc |                     lftp-4.7.3 | NOK | http://autobuild.buildroot.net/results/8128e8b4d2808bd64d3806b9ec8a11e1ae63e36c
         arm |               libarchive-3.2.1 | NOK | http://autobuild.buildroot.net/results/a7f12c8b48c7036360f22e4e4a0c142f442c85c3
         arc |                   libcdio-0.93 | NOK | http://autobuild.buildroot.net/results/61cf744cd2829e2b025197f2304fb20c64cf3b2b
         arm |                   libffi-3.2.1 | NOK | http://autobuild.buildroot.net/results/c9476154e2e63ee50ca72639b04a51e81ef61a87
    mips64el |                 libldns-1.6.17 | NOK | http://autobuild.buildroot.net/results/b2476f5aace2d1ee7aef72de8d50ae6f4f6709a3
        bfin |                 libxslt-1.1.29 | NOK | http://autobuild.buildroot.net/results/3bbfcb072077438e3cd0535a757976f1e441a9e8
        bfin |                 libxslt-1.1.29 | NOK | http://autobuild.buildroot.net/results/580e248c13fa60f6e8c747aeb1767b456b6f4dee
         arm |                      lxc-2.0.3 | NOK | http://autobuild.buildroot.net/results/b1cbca6d0396863654b1d09ccc3163c5f6124ab8
         arm |                      lxc-2.0.3 | NOK | http://autobuild.buildroot.net/results/fcf2834ad74b95548d25dad2274704ea401f9665
      x86_64 |                      lxc-2.0.3 | NOK | http://autobuild.buildroot.net/results/048be2fc702c9dba9ca4439ff687d71b30c10551
        i686 |                      lxc-2.0.3 | NOK | http://autobuild.buildroot.net/results/939246c9a4f433dfd0dc414988f5957441b8e9b4
    mips64el |             micropython-v1.8.3 | NOK | http://autobuild.buildroot.net/results/061c66987e9c33a6641c8183f5e0badae516fc1d
         sh4 |             micropython-v1.8.3 | NOK | http://autobuild.buildroot.net/results/62e5b5c6d9dca0f41fb4e7d462ebfbb02f8d29da
        sh4a |             micropython-v1.8.3 | NOK | http://autobuild.buildroot.net/results/a6437a49659a7b2983269e758dba9fa5a29240d7
        i586 |                     mosh-1.2.5 | NOK | http://autobuild.buildroot.net/results/a148ce0c3db85630d915ea23de6206b830c86403
        m68k |                     mpv-0.19.0 | NOK | http://autobuild.buildroot.net/results/98bb9b57faedb9cb33505d230489e2ae62bc2d2a
      xtensa |                   openjpeg-2.1 | NOK | http://autobuild.buildroot.net/results/c73c7985e5768adb6a4ffe6c4debb8bf1d570c44
         arc |                       qt-4.8.7 | NOK | http://autobuild.buildroot.net/results/d8694878c87a5e5658bfb3e03b4beee65469ca13
        i586 |                     ruby-2.3.1 | NOK | http://autobuild.buildroot.net/results/013a5e09a38a881725491c464467610c01079ef9
         arm |                 socat-2.0.0-b9 | NOK | http://autobuild.buildroot.net/results/b9d9dc20049229aac3f4e9ef8cddb73233ed700f
     aarch64 |          systemd-bootchart-230 | NOK | http://autobuild.buildroot.net/results/ba0b23d7f4402efab29ccff9d0d9a5c730aa36b8
         arc |                trousers-0.3.13 | NOK | http://autobuild.buildroot.net/results/45ff44ca54bd561933733190e5fd59fb02818544
    mips64el |              util-linux-2.28.1 | NOK | http://autobuild.buildroot.net/results/e45931629ee3f5dc45de6940a2c0983435f77e00
         sh4 |              util-linux-2.28.1 | NOK | http://autobuild.buildroot.net/results/b3649dedd048515844675cd48b84bab74eb897f8
      x86_64 |              util-linux-2.28.1 | NOK | http://autobuild.buildroot.net/results/26b3a4de1fb8b366727299ff5de7d59b3e521c23

-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Jérôme Pouiller]

On Saturday 03 September 2016 08:30:33 Thomas Petazzoni wrote:
[...]
> mips64el |              util-linux-2.28.1 | NOK |
> http://autobuild.buildroot.net/results/e45931629ee3f5dc45de6940a2c0983435f77e00 
>      sh4 |              util-linux-2.28.1 | NOK |
> http://autobuild.buildroot.net/results/b3649dedd048515844675cd48b84bab74eb897f8 
>   x86_64 |              util-linux-2.28.1 | NOK |
> http://autobuild.buildroot.net/results/26b3a4de1fb8b366727299ff5de7d59b3e521c23

wget do not accept certificate from cdn.kernel.org. It seems to be
related to :
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409938

wget >= 1.13-1 is necessary to fix problem. I see three solutions:
  1. Revert de76cb7da734dde2204a7ea9ff60e24cbe857ddb ("Use CDN
     kernel.org mirror")
  2. Use http instead if https
  3. Check wget version in dependencies.sh

Any opinion?

BR,

-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Carlos Santos]

> From: "J?r?me Pouiller" <jezz@sysmic.org>
> To: buildroot at busybox.net
> Cc: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>, "Alexey Brodkin" <Alexey.Brodkin@synopsys.com>
> Sent: Saturday, September 3, 2016 1:03:13 PM
> Subject: Re: [Buildroot] [autobuild.buildroot.net] Build results for	2016-09-02

> On Saturday 03 September 2016 08:30:33 Thomas Petazzoni wrote:
> [...]
>> mips64el |              util-linux-2.28.1 | NOK |
>> http://autobuild.buildroot.net/results/e45931629ee3f5dc45de6940a2c0983435f77e00
>>      sh4 |              util-linux-2.28.1 | NOK |
>> http://autobuild.buildroot.net/results/b3649dedd048515844675cd48b84bab74eb897f8
>>   x86_64 |              util-linux-2.28.1 | NOK |
>> http://autobuild.buildroot.net/results/26b3a4de1fb8b366727299ff5de7d59b3e521c23
> 
> wget do not accept certificate from cdn.kernel.org. It seems to be
> related to :
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409938
> 
> wget >= 1.13-1 is necessary to fix problem. I see three solutions:
>  1. Revert de76cb7da734dde2204a7ea9ff60e24cbe857ddb ("Use CDN
>     kernel.org mirror")

This can slow down the downloading of many source files.

>  2. Use http instead if https

I suspect that this would require passing "--no-hsts" to wget (did not test with an old version to confirm).

>  3. Check wget version in dependencies.sh

What would be the approach, in thes case, compiling wget as a host tool?

> Any opinion?

I'd vote for option 3, since wget 1.13.1 is already five years old. I'd ask the developer to migrate to a more up-to-date OS installation rather than spending a lot of effort to circumvent the problem in Buildroot.

Carlos Santos (Casantos)
DATACOM, P&D

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Thomas Petazzoni]

Hello,

On Sat, 03 Sep 2016 18:03:13 +0200, J?r?me Pouiller wrote:

> wget >= 1.13-1 is necessary to fix problem. I see three solutions:
>   1. Revert de76cb7da734dde2204a7ea9ff60e24cbe857ddb ("Use CDN
>      kernel.org mirror")
>   2. Use http instead if https
>   3. Check wget version in dependencies.sh

4. The problem is already solved, because the util-linux-2.28.1.tar.xz
   tarball is now on http://sources.buildroot.net/, and Buildroot
   automatically falls back to this address. Therefore, the build
   failure will no longer occur.

However, we could discuss whether it really makes sense to use https://
as the main download location when all downloads anyway fall back to
downloading from sources.buildroot.net over http://.

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

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Jérôme Pouiller]

On Saturday 03 September 2016 20:36:13 Thomas Petazzoni wrote:
> Hello,
> 
> On Sat, 03 Sep 2016 18:03:13 +0200, J?r?me Pouiller wrote:
> > wget >= 1.13-1 is necessary to fix problem. I see three solutions:
> >   1. Revert de76cb7da734dde2204a7ea9ff60e24cbe857ddb ("Use CDN
> >   
> >      kernel.org mirror")
> >   
> >   2. Use http instead if https
> >   3. Check wget version in dependencies.sh
> 
> 4. The problem is already solved, because the util-linux-2.28.1.tar.xz
> tarball is now on http://sources.buildroot.net/, and Buildroot
> automatically falls back to this address. Therefore, the build
> failure will no longer occur.

It means this error will occurs each time a package using KERNEL_MIRROR 
will be upgraded? Do autobuilder owners could update their wget version?


> However, we could discuss whether it really makes sense to use
> https:// as the main download location when all downloads anyway fall
> back to downloading from sources.buildroot.net over http://.

sources.buildroot.net should provide an https access?

BR,

-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Thomas Petazzoni]

Hello,

On Sat, 03 Sep 2016 20:59:08 +0200, J?r?me Pouiller wrote:

> > 4. The problem is already solved, because the util-linux-2.28.1.tar.xz
> > tarball is now on http://sources.buildroot.net/, and Buildroot
> > automatically falls back to this address. Therefore, the build
> > failure will no longer occur.  
> 
> It means this error will occurs each time a package using KERNEL_MIRROR 
> will be upgraded?

Sadly, yes.

> Do autobuilder owners could update their wget version?

Could be a solution. My autobuilder is intentionally running a very old
system so that we catch such issues. Upgrading wget would solve this
problem, but Buildroot users that must use old systems (which is
sometimes the case in corporate environments) would still face the same
issue. So keeping an old system for testing on our side is also a way
of making sure that we face the same problems as those users, and can
anticipate/fix them when possible.

> > However, we could discuss whether it really makes sense to use
> > https:// as the main download location when all downloads anyway fall
> > back to downloading from sources.buildroot.net over http://.  
> 
> sources.buildroot.net should provide an https access?

I am not a security expert, I am not sure if this is really useful. I
don't think there's anything secret in those communications, and the
integrity of the downloaded tarballs is verified using hashes.

Maybe the solution to the whole problem is to use http:// when
available over https:// ? Though admittedly more and more sites tend to
redirect http to https and force people to use secure connections
(which is a good thing).

I'm open to suggestions from others on this.

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

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Peter Korsgaard]

>>>>> "J?r?me" == J?r?me Pouiller <jezz@sysmic.org> writes:

 >> However, we could discuss whether it really makes sense to use
 >> https:// as the main download location when all downloads anyway fall
 >> back to downloading from sources.buildroot.net over http://.

 > sources.buildroot.net should provide an https access?

How would that fix issues with older wget versions having problems with
TLS/SNI?

-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Peter Korsgaard]

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

Hi,

 >> > However, we could discuss whether it really makes sense to use
 >> > https:// as the main download location when all downloads anyway fall
 >> > back to downloading from sources.buildroot.net over http://.  
 >> 
 >> sources.buildroot.net should provide an https access?

 > I am not a security expert, I am not sure if this is really useful. I
 > don't think there's anything secret in those communications, and the
 > integrity of the downloaded tarballs is verified using hashes.

 > Maybe the solution to the whole problem is to use http:// when
 > available over https:// ? Though admittedly more and more sites tend to
 > redirect http to https and force people to use secure connections
 > (which is a good thing).

 > I'm open to suggestions from others on this.

Well, the problems we typically run into are:

- Websites using TLS with SNI (to not 'waste' an IP address per site),
  which isn't supported by old wget versions

- Websites signed with new certificates not known by older distributions

- Misconfigured websites or website using self signed certificates

The reason we have preferred https was to ensure data integrity
(E.G. make sure we get the correct tarball), not for privacy. With the
download hashes this doesn't really matter much, as corruption will be
discovered by the hashes.

I think our options are:

- Do nothing. The issue is not so big, and presumably will get smaller
  over time as older distributions get updated.

- Change HTTPS URLs to HTTP where possible. Notice that these days a
  number of websites use HSTS headers to enforce HTTPS. I'm not sure
  when HSTS support got added to wget though (not clear from changelog)

- Pass --no-check-certificate in BR2_WGET to disable the check, working
  around the issues.

What do you say?

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Jérôme Pouiller]

On Monday 05 September 2016 10:05:30 Peter Korsgaard wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-
electrons.com> writes:
> Hi,
> 
>  >> > However, we could discuss whether it really makes sense to use
>  >> > https:// as the main download location when all downloads anyway
>  >> > fall
>  >> > back to downloading from sources.buildroot.net over http://.
[...]
> - Do nothing. The issue is not so big, and presumably will get smaller
> over time as older distributions get updated.
> 
> - Change HTTPS URLs to HTTP where possible. Notice that these days a
>   number of websites use HSTS headers to enforce HTTPS. I'm not sure
>   when HSTS support got added to wget though (not clear from
> changelog)
> 
> - Pass --no-check-certificate in BR2_WGET to disable the check,
> working around the issues.
> 
> What do you say?

wget exit with error code '5' if it detect an SSL verification failure. 
Buildroot may detect it and display a message explaining how to work 
around the problem (something like "Try with BR2_WGET='wget --no-check-
certificate'").


-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Yann E. MORIN]

Peter, All,

On 2016-09-05 10:05 +0200, Peter Korsgaard spake thusly:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>  >> > However, we could discuss whether it really makes sense to use
>  >> > https:// as the main download location when all downloads anyway fall
>  >> > back to downloading from sources.buildroot.net over http://.  
>  >> 
>  >> sources.buildroot.net should provide an https access?
> 
>  > I am not a security expert, I am not sure if this is really useful. I
>  > don't think there's anything secret in those communications, and the
>  > integrity of the downloaded tarballs is verified using hashes.
> 
>  > Maybe the solution to the whole problem is to use http:// when
>  > available over https:// ? Though admittedly more and more sites tend to
>  > redirect http to https and force people to use secure connections
>  > (which is a good thing).
> 
>  > I'm open to suggestions from others on this.
> 
> Well, the problems we typically run into are:
> 
> - Websites using TLS with SNI (to not 'waste' an IP address per site),
>   which isn't supported by old wget versions
> 
> - Websites signed with new certificates not known by older distributions
> 
> - Misconfigured websites or website using self signed certificates
> 
> The reason we have preferred https was to ensure data integrity
> (E.G. make sure we get the correct tarball), not for privacy.

Not sure. If you download the tarball for the tor package, you are
most probably flagged as an interesting target by Eve (or any other
three-letter agency ;-] ).

> With the
> download hashes this doesn't really matter much, as corruption will be
> discovered by the hashes.

Hashes are not only about integrity. They are about authenticity as
well: be sure that upstream did not update the archive with another
re-release.

> I think our options are:
> 
> - Do nothing. The issue is not so big, and presumably will get smaller
>   over time as older distributions get updated.

That means we basically don't care about such old distributions anymore,
and that we should upgrade our autobuilders (or at least locally install
a wget that does accepts newer https stuff). That's fine with me.

> - Change HTTPS URLs to HTTP where possible. Notice that these days a
>   number of websites use HSTS headers to enforce HTTPS. I'm not sure
>   when HSTS support got added to wget though (not clear from changelog)

I would favour we stick to https where upstream provides it.

> - Pass --no-check-certificate in BR2_WGET to disable the check, working
>   around the issues.

Maybe a note in the manual and (as J?r?me suggested) catch such a failure
in our wget wrapper? (but I wouldn't like we do the latter).

But I would argue against the suggestion to use --no-check-certificate,
and rather suggest to install a newer wget.

My suggestion would be we do (both):
  - add the note in the manual,
  - update the affected autobuilders (or at least install a newer wget).

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Peter Korsgaard]

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 >> The reason we have preferred https was to ensure data integrity
 >> (E.G. make sure we get the correct tarball), not for privacy.

 > Not sure. If you download the tarball for the tor package, you are
 > most probably flagged as an interesting target by Eve (or any other
 > three-letter agency ;-] ).

If you are really worried about that, then you shouldn't download from
dist.torproject.org at all (https or not):

host -t a dist.torproject.org
dist.torproject.org has address 138.201.14.197
dist.torproject.org has address 78.47.38.226
dist.torproject.org has address 82.195.75.101
dist.torproject.org has address 154.35.132.70
dist.torproject.org has address 38.229.72.16

Which all have .torproject.org reverse DNS.

 >> With the
 >> download hashes this doesn't really matter much, as corruption will be
 >> discovered by the hashes.

 > Hashes are not only about integrity. They are about authenticity as
 > well: be sure that upstream did not update the archive with another
 > re-release.

I see that as integrity, just a question about where the modification
happens - But ok.

 >> I think our options are:
 >> 
 >> - Do nothing. The issue is not so big, and presumably will get smaller
 >> over time as older distributions get updated.

 > That means we basically don't care about such old distributions anymore,
 > and that we should upgrade our autobuilders (or at least locally install
 > a wget that does accepts newer https stuff). That's fine with me.

Why? "Real users" either use something more stable than git head
(E.G. our sources.b.o mirror will normally download a copy of the
tarball within 1-2h of the commit getting pushed) or they know enough to
pass --no-check-certificate in BR2_WGET (or update wget).


 >> - Change HTTPS URLs to HTTP where possible. Notice that these days a
 >> number of websites use HSTS headers to enforce HTTPS. I'm not sure
 >> when HSTS support got added to wget though (not clear from changelog)

 > I would favour we stick to https where upstream provides it.

Any specific reason?


 >> - Pass --no-check-certificate in BR2_WGET to disable the check, working
 >> around the issues.

 > Maybe a note in the manual and (as J?r?me suggested) catch such a failure
 > in our wget wrapper? (but I wouldn't like we do the latter).

This gets somewhat complicated by the fact that we normally
automatically fall back to sources.b.o if upstream cannot be used, so
the error message should only be shown if it was a fatal error.

 > But I would argue against the suggestion to use --no-check-certificate,
 > and rather suggest to install a newer wget.

 > My suggestion would be we do (both):
 >   - add the note in the manual,
 >   - update the affected autobuilders (or at least install a newer wget).

I don't think we really need to update the autobuilders. I don't find it
a big problem that we have a few autobuilder failures the first 1-2h
after pushing a version bump. The error message is quite obvious and it
ensures we won't forget the issue.

But sure, we can add a note in the manual.

-- 
Venlig hilsen,
Peter Korsgaard 

[Buildroot] [autobuild.buildroot.net] Build results for 2016-09-02

[Jérôme Pouiller]

On Saturday 03 September 2016 23:23:02 Thomas Petazzoni wrote:
> Hello,
> 
> On Sat, 03 Sep 2016 20:59:08 +0200, J?r?me Pouiller wrote:
> > > 4. The problem is already solved, because the
> > > util-linux-2.28.1.tar.xz tarball is now on
> > > http://sources.buildroot.net/, and Buildroot automatically falls
> > > back to this address. Therefore, the build failure will no longer
> > > occur.
> > 
> > It means this error will occurs each time a package using
> > KERNEL_MIRROR will be upgraded?
> 
> Sadly, yes.
> 
> > Do autobuilder owners could update their wget version?
> 
> Could be a solution. My autobuilder is intentionally running a very
> old system so that we catch such issues. Upgrading wget would solve
> this problem, but Buildroot users that must use old systems (which is
> sometimes the case in corporate environments) would still face the
> same issue. So keeping an old system for testing on our side is also
> a way of making sure that we face the same problems as those users,
> and can anticipate/fix them when possible.

I didn't check autobuilder code, but it should be possible to detect 
this case (old wget + SSL problem + 404 while checking mirror). We may 
associate this failure with a special package name? So developers know 
it should normally be ignored.


-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr