On Tue, 2019-01-22 at 10:53 +0100, Philipp Kern wrote:
> On 1/22/2019 7:08 AM, Cyril Brulebois wrote:
> > > Alternatively, we could make pigz a strict build requirement but
> > > that sounds a little antisocial.
> > Right.
> In what way do you consider this antisocial and what's speaking
> against
Hi Cyril,
> I think I'd prefer closing this very bug report whenever what's in
> git gets uploaded
That would definitely work for me. Indeed, it would probably help
separate discussions/issues correctly as any followups are likely =
to be much more specific.
> half the build time is spent
Philipp,
> > > Alternatively, we could make pigz a strict build requirement but
> > > that sounds a little antisocial.
> >
> > Right.
>
> In what way do you consider this antisocial and what's speaking against
> doing that?
I was using this word in a somewhat romantic sense; fewer
dependencies
On 1/22/2019 7:08 AM, Cyril Brulebois wrote:
>> Alternatively, we could make pigz a strict build requirement but
>> that sounds a little antisocial.
> Right.
In what way do you consider this antisocial and what's speaking against
doing that? If it's about CPU time, then maybe it should obey the
Hi Chris,
Chris Lamb (2019-01-21):
> > That's looking good but I'm seeing new warnings because of gzip's
> > being unhappy about the GZIP environment variable.
>
> Interesting. However when you say "new" warnings I don't believe my
> patch set actually added/changed this; indeed, it has not
Dear Cyril,
Thank you for your review and timely merge.
> That's looking good but I'm seeing new warnings because of gzip's being
> unhappy about the GZIP environment variable.
Interesting. However when you say "new" warnings I don't believe my
patch set actually added/changed this; indeed, it
Control: tag -1 pending
Cyril Brulebois (2019-01-19):
> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg? (In which case build/config/arm.cfg might need an
> update as well.)
Cyril Brulebois (2019-01-19):
> Back to d-i results: I'm seeing small differences in the generated
> -images tarball, that I'll try to investigate. I'll probably push the
> series anyway, as these patches are helping anyway. :)
Here are the differences I'm seeing by building multiple times in
Hi Chris,
Chris Lamb (2019-01-19):
> > * 0c19a29645a6a3136f3a51da5d5cf1cfcec5fdfb mentions file system
> >ordering only, but that's just the sort part
>
> I've split this commit and it is much clearer now.
Perfect, thanks.
> > * 71391967763708055a65ed68999db8f4ea6fc6e6 sets “deb1”
[Keeping Kibi in CC as requested off-list, dropping mtools@p.d.o]
Dear Kibi,
First, thank you so much for your review. I believe I have resolve
all of your issues on the corresponding merge request, as well as
rebasing it against the current master:
Hello Chris,
First off: Thanks a lot for your work, and for your patience.
Chris Lamb (2019-01-12):
> I would dearly love to have reproducible installer images for buster
> and indeed this would be a good thing to provide and offer, let alone
> announce in the release notes, etc.
>
> Now that
Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that debian-installer's images were not reproducible.
>
> I have created merge request #3 [1] on salsa with a patch series
> to address this.
>
> [0] https://reproducible-builds.org/
> [1]
Control: block 900918 by 900409 900410
This requires fixes to mtools, marked as blocking bugs.
live well,
vagrant
signature.asc
Description: PGP signature
Package: debian-installer
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed
that debian-installer's images were not
14 matches
Mail list logo
