On Sun, 2020-05-17 at 13:12 +0200, Matthias Klose wrote:
> Any idea which package this should be filed for?
I think this is going to require a bunch of different changes in
various places including dpkg-dev, debhelper, reprepro, dak, launchpad
and any other apt repos that have an incoming system
On 5/17/20 12:58 AM, Chris Lamb wrote:
> Hi Paul,
>
>> There is already the BYHAND (and automatic BYHAND) mechanisms for files
>> that get installed outside of pool/ in the Debian apt repository. Each
>> one needs support from dak too though.
> [..]
>> It strikes me that these files are most simil
On Sat, 2020-05-16 at 22:58 +, Chris Lamb wrote:
> My gut feeling is that this is the avenue we want to explore. Having a
> separate mechanism to capture this build-specific metadata would be an
> elegant solution and, as you imply, having the logs would have QA
> advantages as well as permit
Hi Paul,
> There is already the BYHAND (and automatic BYHAND) mechanisms for files
> that get installed outside of pool/ in the Debian apt repository. Each
> one needs support from dak too though.
[..]
> It strikes me that these files are most similar to .buildinfo or the
> build logs in that they
On Mon, 24 Feb 2020 14:09:23 -0800 Vagrant Cascadian wrote:
> Exploring avenues to put files like this into some separate artifact for
> things that are not reproducible might be one avenue
There is already the BYHAND (and automatic BYHAND) mechanisms for files
that get installed outside of pool/
On 2/24/20 11:09 PM, Vagrant Cascadian wrote:
> On 2020-02-22, Matthias Klose wrote:
>>> I'm not sure what the rationale for including these test logs in the
>>> package is, but from a reproducible builds perspective, ideally these
>>> would simply not be included at all.
>>
>> that's not an option
Vagrant Cascadian wrote:
> > Or you could add a override database for files which are expected to differ.
>
> This is considerably more complicated than running a checksum on the
> resulting .deb files and is another opportunity for bugs to lead to
> incorrect reproducibility results...
I would
On 2020-02-22, Matthias Klose wrote:
>> I'm not sure what the rationale for including these test logs in the
>> package is, but from a reproducible builds perspective, ideally these
>> would simply not be included at all.
>
> that's not an option. this is all useful information for debugging purpo
> I'm not sure what the rationale for including these test logs in the
> package is, but from a reproducible builds perspective, ideally these
> would simply not be included at all.
that's not an option. this is all useful information for debugging purposes,
and you'll find that in the GCC packag
Package: binutils-dev
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain randomness buildpath hostname timestamps username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
The log files included in /usr/share/doc/binutils/tests/ include many
v
10 matches
Mail list logo
