Source: cookiecutter
Version: 1.4.0-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], I noticed
that cookiecutter could not
Source: echoping
Version: 6.0.2-9
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], I noticed
that echoping could not be built
Source: nagios-nrpe
Version: 2.15-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps randomness
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], I noticed
that nagios-nrpe
Hi,
i wrote:
> > As it is now, it is the clearest no-brainer:
> > Export SOURCE_DATE_EPOCH and forget about any other time issues which
> > you don't create yourself by own xorriso arguments.
Chris Lamb wrote:
> I'm sorry but I don't quite follow and I don't want to read what I want
> to read.
On Fri, Aug 19, 2016 at 05:54:57PM +0100, Chris Lamb wrote:
> Some extra background — we usually remove archived bugs from notes. I
> believe there is a script for this..
Just ran it.
I usually run it every so often, when I remember :)
--
regards,
Mattia Rizzolo
GPG
> So either the bug is here again, or it was not the real reason for the
> FTBFS
It's unclear to me as AIUI "pep8" is being renamed to pycodestyle, so it
could be that "neutron/hacking/checks.py" is at fault for importing pep8.
I'd just file a bug and see what the maintainer thinks, it's not
Greetings.
In notes, Bug#816735 appears in a lot of places as a reason for FTBFS
bugs like this:
ImportError: No module named pep8
The bug is now closed and archived, but many of the packages having this
bug in notes happen to FTBFS again. Example:
> > *iff* SOURCE_DATE_EPOCH is set:
> >
> > - mtimes are taken from stat(2). [The FS creator is responsible for
> > ensuring they are reproducible, possibly by some "clamping" call
> > to `find -newermt | xargs touch …`.]
> >
> > - atime is copied from mtime [as FS creator "can't" set that].
Hi,
Chris Lamb wrote:
> May I propose the following behaviour *iff* SOURCE_DATE_EPOCH
> is set:
>
> - mtimes are taken from stat(2). [The FS creator is responsible for
> ensuring they are reproducible, possibly by some "clamping" call
> to `find -newermt | xargs touch …`.]
>
> - atime is
Chris Lamb:
> Holger wrote:
>
>> I think regarding Debian releases, I'd recommend that we aim for
>> partially reproducible packages given known build paths
>
> I agree. We should, regrettably, define a fixed build path for stretch
> at this point in the release cycle.
I want to note that this
Hi Thomas,
> - Verify that SOURCE_DATE_EPOCH works as promised and expected.
> (Promised is to set the defaults of three xorriso settings.
>Expected is that these defaults suffice for reliable reproducibility.)
My current schedule is to test this and report back in the next 4 or 5
days.
On Fri, Aug 19, 2016 at 01:10:53PM +0100, Chris Lamb wrote:
> Only from me asking:
> | So, just to be 100% clear, simply varying DEB_BUILD_OPTIONS="parallel=X"
> | would not have discovered this gedit bug?
> Where — in context — varying meant 17 vs. 18 instead of 1 vs. 18.
it wasn't clear to
Hi,
i am pondering when to release xorriso-1.4.6 et.al.
1.4.5 passed my rebuild-ISO regression tests by reporting no differences
of file content or boot equipment as far as xorriso can replay the latter.
Normally i would wait a few weeks whether my daily backups or some
courageous user find any
> > This entire email chain was prompted by such a case.
>
> what makes you think so? this wasn't and isn't clear for me, neither
> from the mails nor from https://bugzilla.gnome.org/show_bug.cgi?id=770100
Only from me asking:
| So, just to be 100% clear, simply varying
Hi Ceridwen,
> For most of the variations I've done so far, I've been either
> depending on external utilities or had POSIX-compliant ways to execute
> them. The rest of the variations pose more problems.
[…]
I'm afraid I didn't get around to replying to this at the time and I'm
sure you have
On Fri, Aug 19, 2016 at 12:32:13PM +0100, Chris Lamb wrote:
> > yes, I cannot imagine there's something which is reproducible if build
> > in parallel but not if not.
> This entire email chain was prompted by such a case.
what makes you think so? this wasn't and isn't clear for me, neither
from
Holger wrote:
> I think regarding Debian releases, I'd recommend that we aim for
> partially reproducible packages given known build paths
I agree. We should, regrettably, define a fixed build path for stretch
at this point in the release cycle.
I do not believe we would have enough resources
> > Right, so make all the pkg-gnome packages build reproducibly without
> > paralellism enabled (which you should do anyway) and then simply
> > build with parallel enabled.
>
> yes, I cannot imagine there's something which is reproducible if build
> in parallel but not if not.
This entire
Hi,
On Fri, Aug 19, 2016 at 12:58:24AM +0100, Chris Lamb wrote:
> > I understand that building with parallel disabled takes much longer
> > for many packages so I don't know if this is just a lack of resources
> It's more that we have two builds and I think (?) we would prefer to do
> different
19 matches
Mail list logo
