Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Kuhls <bernd.kuhls@t-online.de>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] Update github hashes
Date: Wed, 20 Sep 2017 20:29:21 +0200	[thread overview]
Message-ID: <1loa9exfa8.ln2@ID-313208.user.individual.net> (raw)
In-Reply-To: CANQCQpa9S7chHUTg1GBNz9Qi=r-tMeQnQO2sYpNdZ7oQ+9MP9w@mail.gmail.com

Am Wed, 20 Sep 2017 13:03:32 -0500 schrieb Matthew Weber:

> All,
> 
> On Wed, Sep 20, 2017 at 12:52 PM, Peter Korsgaard
> <peter@korsgaard.com> wrote:
>>>>>>> "Bernd" == Bernd Kuhls
>>>>>>> <bernd.kuhls@t-online.de> writes:
>>
>>  > It seems github now sometimes provides slightly changed tarballs
>>  > which produce a different sha256 hash than before. Fix the hashes of
>>  > the affected packages to avoid downloading from
>>  > sources.buildroot.net.
>>
>>  > Signed-off-by: Bernd Kuhls
>>  > <bernd.kuhls@t-online.de>
>>
>> :/
>>
>> I'm not sure updating the hashes is the correct thing to do.
>> Sources.b.o runs 'make source' from the 2017.02.x and master branches
>> to keep it uptodate, and E.G. freerdp hasn't been updated since
>> 2017.02, so it will break hard for 2017.02.x users if we change it.
>>
>> Falling back to s.b.o is not such a bad thing, so I think we can wait
>> with fixing up the hashes until the packages get bumped.
>>
>> In the mean time I will try to figure out who to contact at github to
>> ask about the change.
>>
>>
> I'd second it would be better to wait.  The iperf hash issue earlier
> this summer created a mess until that was bumped.

Hi,

I do not see a perfect solution for this problem, the fallback to s.b.o. 
will not circumvent download failures because it does not provide source 
tarballs for all packages:

$ LC_ALL=C wget sources.buildroot.org/kodi-17.4-Krypton.tar.gz
--2017-09-20 20:23:27--  http://sources.buildroot.org/kodi-17.4-
Krypton.tar.gz
Resolving sources.buildroot.org (sources.buildroot.org)... 176.9.16.109
Connecting to sources.buildroot.org (sources.buildroot.org)|
176.9.16.109|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-09-20 20:23:27 ERROR 404: Not Found.

Not committing this patch means that downloading the kodi package will 
always fail. Otoh I recognize the mess for the lts versions...

Additionally not all users are using
BR2_BACKUP_SITE="http://sources.buildroot.net"
in their setup, I normally deactivate this option to save bandwidth and 
to be informed when upstream did changes to its website.

Regards, Bernd

  reply	other threads:[~2017-09-20 18:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-20 11:28 [Buildroot] [PATCH 1/1] Update github hashes Bernd Kuhls
2017-09-20 17:35 ` Yann E. MORIN
2017-09-20 17:52 ` Peter Korsgaard
2017-09-20 18:03   ` Matthew Weber
2017-09-20 18:29     ` Bernd Kuhls [this message]
2017-09-21  7:23       ` Peter Korsgaard
2017-09-21  9:17         ` Bernd Kuhls
2017-09-21  9:32           ` Peter Korsgaard
2017-09-21 20:35   ` Arnout Vandecappelle
2017-09-21 21:23     ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1loa9exfa8.ln2@ID-313208.user.individual.net \
    --to=bernd.kuhls@t-online.de \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox