On Sat, Mar 11, 2017 at 03:33:05AM +0100, Guillem Jover wrote:
> I forgot to mention two curretly pending issues, not listed previously:
>
> * An error in dpkg-genbuildinfo caused by arch-qualified dependencies
> on a virtual package.
> * Broken dependency recursor in dpkg-genbuildinfo
I
On Sun, Feb 19, 2017 at 06:52:16PM +0100, Guillem Jover wrote:
> Hi!
>
> On Sat, 2016-11-12 at 19:04:53 +0100, Guillem Jover wrote:
> > As I've mentioned elsewhere, I've noticed several things with the
> > current .buildinfo format, even after the cleanup pre-merge, that
> > I'd like to fix or
On Sun 2017-02-19 16:34:45 -0500, Guillem Jover wrote:
> On Sun, 2017-02-19 at 11:39:28 -0800, Vagrant Cascadian wrote:
>> On 2017-02-19, Guillem Jover wrote:
>> >> * .buildinfo files are not generated when creating source-only uploads
>> >
>> > Fixed. Now always generated.
>>
>> On a related
On Sun, 2017-02-19 at 11:39:28 -0800, Vagrant Cascadian wrote:
> On 2017-02-19, Guillem Jover wrote:
> >> * .buildinfo files are not generated when creating source-only uploads
> >
> > Fixed. Now always generated.
>
> On a related note, is it currently possible to create a .buildinfo with
> both
On 2017-02-19, Guillem Jover wrote:
>> * .buildinfo files are not generated when creating source-only uploads
>
> Fixed. Now always generated.
On a related note, is it currently possible to create a .buildinfo with
both the source and binary, but a corresponding .changes with only the
source?
Hi!
On Sat, 2016-11-12 at 19:04:53 +0100, Guillem Jover wrote:
> As I've mentioned elsewhere, I've noticed several things with the
> current .buildinfo format, even after the cleanup pre-merge, that
> I'd like to fix or change so that we can hopefully reach Format 1.0.
Ok, let's see what's the
Hi!
On Sun, 2016-11-13 at 14:21:45 +0100, Johannes Schauer wrote:
> Also see:
>
> https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Semantics
>
> I've heard many upstream developers who were initially very much against
> purging the timestamp when the build was done from their build
On Mon, Nov 14, 2016 at 05:44:22AM +0900, Daniel Kahn Gillmor wrote:
> >> Multiple builds of the same source package will set SOURCE_DATE_EPOCH to
> >> the same value but will result in a different Build-Date.
> It is definitely not what most of us initially expected, but it is
> actually what we
Hi,
Quoting Daniel Kahn Gillmor (2016-11-13 21:44:22)
> It is definitely not what most of us initially expected, but it is
> actually what we want.
>
> i look at it this way:
>
> * Ideally, the generated binary packages are reproducible *even when
>the build environment changes*. For
On Sun 2016-11-13 22:33:29 +0900, Chris Lamb wrote:
>> Multiple builds of the same source package will set SOURCE_DATE_EPOCH to
>> the same value but will result in a different Build-Date.
>
> … but that would mean that a reproducible build will result in .buildinfo
> files with different
Chris Lamb:
> Hey Johannes,
>
>> Multiple builds of the same source package will set SOURCE_DATE_EPOCH to
>> the same value but will result in a different Build-Date.
>
> … but that would mean that a reproducible build will result in .buildinfo
> files with different contents (varying on
Hey Johannes,
> Multiple builds of the same source package will set SOURCE_DATE_EPOCH to
> the same value but will result in a different Build-Date.
… but that would mean that a reproducible build will result in .buildinfo
files with different contents (varying on Build-Date).
That seems, at
Hi,
Quoting Chris Lamb (2016-11-13 12:25:07)
> > move the build date inside the .buildinfofile in a Build-Date field or
> > similar
> Hrm. Are we sure about this? My gut tells me that the external definition of
> the build should not include the Build-Date. (At the very least, this is just
> a
Dear Guillem,
First, thanks for all your great work on this.
> * .buildinfo filename
I personally find the current filenames pretty ugly and would prefer them
to match the .changes file. :) Note that they will also differ in raw
content once signed too (!)
> move
Hi!
As I've mentioned elsewhere, I've noticed several things with the
current .buildinfo format, even after the cleanup pre-merge, that
I'd like to fix or change so that we can hopefully reach Format 1.0.
Some of the issues, that bother me:
* .buildinfo files are not currently signed
I just
15 matches
Mail list logo
