On Sun, 27 Nov 2016, Chris Lamb wrote:
> Henrique de Moraes Holschuh wrote:
> > Please test the attached patch. Does it pass all the reproducibility
> > testing?
>
> Not quite; I needed to make the following change to your patch:
>
> - CHANGELOG_TS :=$(shell date +%s
> + CHANGELOG_TS :=$(shell
Henrique de Moraes Holschuh wrote:
> Please test the attached patch. Does it pass all the reproducibility
> testing?
Not quite; I needed to make the following change to your patch:
- CHANGELOG_TS :=$(shell date +%s
+ CHANGELOG_TS :=$(shell date --utc +%s
.. then it was reproducible. :)
FYI
On Sat, Nov 26, 2016 at 10:55:57AM +0100, Chris Lamb wrote:
> I fear I may have confused the issue here; the source package
> "amd64-microcode"
> is perfectly reproducible, so debating over whether it should be built from a
> contrib/non-free/autobuilt point of view is — at the very least — not
>
[Re-adding myself to CC]
Holger Levsen wrote:
> […]
I fear I may have confused the issue here; the source package "amd64-microcode"
is perfectly reproducible, so debating over whether it should be built from a
contrib/non-free/autobuilt point of view is — at the very least — not "on-topic"
for t
On Fri, Nov 25, 2016 at 02:56:24PM -0200, Henrique de Moraes Holschuh wrote:
> > to explain: we only test main, as using and or even building packages
> > from contrib or non-free might be problematic.
> Well, FWIW, intel-microcode and amd64-microcode have been manually
> checked to be safe to auto
On Fri, 25 Nov 2016, Holger Levsen wrote:
> On Thu, Nov 24, 2016 at 11:20:19PM +0100, Chris Lamb wrote:
> > > Please test the attached patch. Does it pass all the reproducibility
> > > testing?
> > This is not actually tested in Debian's Reproducible Builds testing
> > framework — I discovered it
On Thu, Nov 24, 2016 at 11:20:19PM +0100, Chris Lamb wrote:
> > Please test the attached patch. Does it pass all the reproducibility
> > testing?
> This is not actually tested in Debian's Reproducible Builds testing
> framework — I discovered it when working directly on Tails.
to explain: we only
Henrique de Moraes Holschuh wrote:
> Please test the attached patch. Does it pass all the reproducibility
> testing?
This is not actually tested in Debian's Reproducible Builds testing
framework — I discovered it when working directly on Tails. I thus
can't give you an answer straight away.
I w
Chris,
Please test the attached patch. Does it pass all the reproducibility
testing?
--
Henrique Holschuh
diff --git a/debian/initramfs.hook b/debian/initramfs.hook
index d250719..c65d7d4 100755
--- a/debian/initramfs.hook
+++ b/debian/initramfs.hook
@@ -73,6 +73,9 @@ fi
verbose "installin
Hi Henrique,
> Because the early initramfs is going to be (re?)generated at package
> *install* / upgrade time. So, it is not only at package build time...
Yep that's fine; I am attempting to make a reproducible live system and
it will be exported during the live build system. :)
> Also, if the
On Mon, Nov 21, 2016, at 09:18, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] on behalf of the
> Tails operating system [1], I noticed that amd64-microcode generates
> a prepended initramfs image that is not reproducible.
So far so good, but...
> Patch attached.
It dep
Source: amd64-microcode
Version: 3.20160316.2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps fileordering toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0] on behalf of
12 matches
Mail list logo
