[Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348

Arnout Vandecappelle arnout at mind.be
Tue Nov 13 23:54:15 UTC 2018

On 13/11/2018 21:29, Yann E. MORIN wrote:
> Thomas, All,
> On 2018-11-13 21:02 +0100, Thomas Petazzoni spake thusly:
>> On Tue, 13 Nov 2018 18:20:57 +0100, Marcin Niestrój wrote:
> [--SNIP--]
>>> 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).
>> This is getting really horrible.
>> On my side, I have updated to Fedora 29, which ships tar 1.30, that we
>> consider as broken, and therefore now for everything single small build
>> that I do, I'm paying the price of building tar, which is super
>> annoying. This is especially annoying as tar 1.30 is only problematic
>> when *creating* tarballs of git-fetched packages, which clearly does
>> not happen at every build.
> Well, we only need host-tar and host-gzip when creating tarballs, not
> extracting them, correct? So, we could very well envision the fact that
> host-tar (and host-gzip) are only added to FOO_DOWNLOAD dependecies when
> FOO_SITE_METHOD == git (and they are needed, of course), no?

 Since we have the same problems sometimes with github tarballs, I think we need
a more fundamental solution. I would propose a new tarsha256 hash type, which
extracts the tarball to calculate the hash. In a simple version it's not so
complicated, something like

tar -xf - --to-command=$(TOPDIR)/support/scripts/tarsha256 | sort | sha256sum -

where tarsha256 contains:

{ echo $TAR_FILENAME; echo $TAR_MODE; echo $TAR_FILETYPE; cat - } | \
	sha256sum - | cut -f 1 -d ' '

As usually, entirely untested.


> (note: tar is ugly, because its configure step takes ~26s, while the
> build is only ~4s).
>> It would be truly horrible to also have to build our own gzip. Maybe we
>> need to somehow revisit our requirement that we need to have
>> reproducible tarballs for git-fetched packages ?
> I am ready to pay the price for reproducibility any time.
> Regards,
> Yann E. MORIN.

More information about the buildroot mailing list