From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] support/dependencies: add a check for a suitable gzip
Date: Fri, 16 Nov 2018 20:38:25 +0100 [thread overview]
Message-ID: <20181116193825.GU10271@scaer> (raw)
In-Reply-To: <20181116163252.25ff7342@windsurf>
Thomas, All,
On 2018-11-16 16:32 +0100, Thomas Petazzoni spake thusly:
> On Fri, 16 Nov 2018 16:27:19 +0100, Yann E. MORIN wrote:
> > Recently, some hash mismatch have been reported, both by users as well
> > as autobuilder failures, about tarballs generated from git repositories.
> >
> > This turned out to be caused by users having the 'gzip' command somehow
> > aliased to 'pigz' (which stand for: parallel implementation of gzip,
> > which takes advantage of multi-processor system to parallelise the
> > compression).
> >
> > Unfortunately, the output of pigz-compressed archives differ from that
> > of gzip (even though they *are* valid gzip-compressed streams).
> >
> > Add a dependency check that ensures that gzip is not pigz. If that is
> > the case, bail out and refuse to build.
> >
> > This is a stop-gap measure in preparation of the release. A complete
> > solution would accept pigz as a decompressor (because that is totally
> > OK), and ensure that we do build a host-gzip package should that be
> > needed. This is a much bigger endeavour, so this simple solution is
> > deemed enough for the release (after all, use of pigz is just atypical
> > enough that it should not pose such a problem for users to reverti to
> > using plain gzip).
>
> Is it really that more complicated to add and use host-gzip ?
We need to add an actual host-gzip package, then ensure it is used when
needed (e.g. in _DOWNLOAD_DEPENDENCIES of git/svn/cvs based packages).
Definitiely not overly complex as I stated, no, but I was mostly looking
through the release-incoming prism, with a goal to do the strict minimum
to fail in a sane way, and was seeing the host-gzip as too far reaching
for the release.
But I can do that if you prefer.
> (This is a real question, not one asked with some irony.)
;-)
Even then, I can stomach a bit of irony. Even if I am very often
incapable of noticing it. :-]
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. |
'------------------------------^-------^------------------^--------------------'
prev parent reply other threads:[~2018-11-16 19:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 15:27 [Buildroot] [PATCH] support/dependencies: add a check for a suitable gzip Yann E. MORIN
2018-11-16 15:32 ` Thomas Petazzoni
2018-11-16 19:38 ` Yann E. MORIN [this message]
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=20181116193825.GU10271@scaer \
--to=yann.morin.1998@free.fr \
--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.