From: "Marcin Niestrój" <m.niestroj@grinn-global.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348
Date: Tue, 13 Nov 2018 18:20:57 +0100 [thread overview]
Message-ID: <87bm6svqpy.fsf@grinn-global.com> (raw)
In-Reply-To: <20181109210610.GB2445@scaer>
Hi All,
Yann E. MORIN <yann.morin.1998@free.fr> writes:
> Marcin, Thomas, All,
>
> On 2018-11-09 21:57 +0100, Thomas Petazzoni spake thusly:
>> On Thu, 8 Nov 2018 16:33:22 +0100, Marcin Niestroj wrote:
>>
>> > -sha256 b279ca4d086887c2efab13e28a7ca36e409410d3df38a62d7c7b5799ee3de916 linux-firmware-44d4fca9922a252a0bd81f6307bcc072a78da54a.tar.gz
>> > +sha256 3e4fcbac18990a14d52159fefdc70081a56c5244adba28b14242e159a748e755 linux-firmware-1baa34868b2c0a004dc595b20678145e3fff83e7.tar.gz
>>
>> I am sorry, but this hash is still not good for me, I get:
>>
>> 5c636765fd1ac638176893feccfd4a4854f59fc3d01b38f3ccdbb89bd5bb6ef1
>>
>> I.e:
>>
>> ERROR: linux-firmware-1baa34868b2c0a004dc595b20678145e3fff83e7.tar.gz has wrong sha256 hash:
>> ERROR: expected: 3e4fcbac18990a14d52159fefdc70081a56c5244adba28b14242e159a748e755
>> ERROR: got : 5c636765fd1ac638176893feccfd4a4854f59fc3d01b38f3ccdbb89bd5bb6ef1
>>
>> And this morning, Yann E. Morin reported having the same hash as me:
>>
>> 08:07 < y_morin> kos_tom: I also have a different hash here.
>> 08:10 < y_morin> kos_tom: FTR, I got: 5c636765fd1ac638176893feccfd4a4854f59fc3d01b38f3ccdbb89bd5bb6ef1
>
> Right.
Thank you both for testing.
>
>> My system tar is 1.29, which is considered as a "good" version by
>> support/dependencies/check-host-tar.sh. I have nonetheless forced
>> building host-tar, and I still get the same hash.
>
> Recently, another user reported hash issues as well, and it turned out
> that they had changed gzip to be really pigz (a parallel gzip). Can you
> check if that is not your case too?
I have investigated the issue on my side. It turns out that gzip is
really the issue here.
I have two PCs with Arch Linux. PC_1 is the one I have prepared
linux-firmware. Here gzip package info on that machine:
[mniestroj at gm ~]$ LANG=C yaourt -Si gzip
Repository : core
Name : gzip
Version : 1.9-1
Description : GNU compression utility
Architecture : x86_64
URL : https://www.gnu.org/software/gzip/
Licenses : GPL3
Groups : base base-devel
Provides : None
Depends On : glibc bash less
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 77.78 KiB
Installed Size : 150.00 KiB
Packager : S
Build Date : Mon Jan 22 00:52:54 2018
Validated By : MD5 Sum SHA-256 Sum Signature
PC_2 is also Arch Linux, but with slightly more up-to-date
packages. gzip package info looks like this:
[macius at zm ~]$ LANG=C yaourt -Si gzip
Repository : core
Name : gzip
Version : 1.9-2
Description : GNU compression utility
Architecture : x86_64
URL : https://www.gnu.org/software/gzip/
Licenses : GPL3
Groups : base base-devel
Provides : None
Depends On : glibc bash less
Optional Deps : None
Conflicts With : None
Replaces : None
Download Size : 78.14 KiB
Installed Size : 185.00 KiB
Packager : Allan McRae <allan@archlinux.org>
Build Date : Sat Nov 3 23:10:39 2018
Validated By : MD5 Sum SHA-256 Sum Signature
You can find differences in package here:
https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/gzip
I have also checked output of gzip command on another PC with pigz
configured as gzip drop-in replacement. It outputs even different file,
with different sha256 hash.
I think the overall conclusion is that a host-gzip package is needed,
just like host-tar. In the meantime I will send v3 of this patch with
proper hash (the same as you calculated above).
>
> Regards,
> Yann E. MORIN.
>
>> I have uploaded the tarball at
>> https://bootlin.com/~thomas/pub/linux-firmware-1baa34868b2c0a004dc595b20678145e3fff83e7.tar.gz.
>> Could you upload the tarball that was generated on your side so that we
>> can compare them, and see where the problem lies ?
Thank for sharing. After gunzipping your version and mine I ended with
the same *.tar files. So the difference was clearly because of gzip.
Regards,
Marcin
>>
>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
next prev parent reply other threads:[~2018-11-13 17:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-08 15:33 [Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348 Marcin Niestroj
2018-11-09 20:57 ` Thomas Petazzoni
2018-11-09 21:06 ` Yann E. MORIN
2018-11-13 17:20 ` Marcin Niestrój [this message]
2018-11-13 17:32 ` Marcin Niestrój
2018-11-13 20:02 ` Thomas Petazzoni
2018-11-13 20:29 ` Yann E. MORIN
2018-11-13 20:57 ` Thomas Petazzoni
2018-11-13 23:54 ` Arnout Vandecappelle
2018-11-15 19:05 ` Yann E. MORIN
2018-11-16 8:35 ` Thomas Petazzoni
2018-11-20 18:50 ` Yann E. MORIN
2018-11-20 23:47 ` Arnout Vandecappelle
2018-11-21 7:13 ` Peter Korsgaard
2018-11-13 21:34 ` Marcin Niestrój
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=87bm6svqpy.fsf@grinn-global.com \
--to=m.niestroj@grinn-global.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.