Re: source-only builds and .buildinfo

[Guillem Jover]

Hi!

[ Just a very quick reply, will go over the other mails during the week. ]

On Wed, 2017-05-24 at 13:58:00 +, Ximin Luo wrote:
> Also the man page for dpkg-buildpackage is out-of-date:
> 
>6. Unless a source-only build has been requested, it runs the
> buildinfo hook and calls dpkg-genbuildinfo to generate a .buildinfo
> file.  Several dpkg-buildpackage options are forwarded to dpkg-genbuildinfo.
> 
> and also later:
> 
>   The current hook-name supported are:
>   init preclean source build binary changes postclean check
>   sign done
> 
> missing out "buildinfo", and indeed if I run "dpkg-buildpackage
> --hook-buildinfo=true" the buildinfo file still gets generated.

Yes, as I mentioned on
 this is
something I've noticed now several times, but forgot to fix. I did so
the other day and have queued it for a future 1.18.25 release.

Thanks,
Guillem

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#863284: unblock: quadrapassel/1:3.22.0-1.1

[Chris Lamb]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Release Team,

Please consider unblocking quadrapassel 1:3.22.0-1.1:

  quadrapassel (1:3.22.0-1.1) unstable; urgency=medium

 * Non-maintainer upload.
 * Fix segfault when unpausing a paused game that has finished.
   (Closes: #863106)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for quadrapassel-3.22.0 quadrapassel-3.22.0

 changelog|8 
+
 patches/0001_fix-segfault-when-unpausing-a-paused-finished-game.diff |   16 
++
 patches/series   |1 
 3 files changed, 25 insertions(+)

diff -Nru quadrapassel-3.22.0/debian/changelog 
quadrapassel-3.22.0/debian/changelog
--- quadrapassel-3.22.0/debian/changelog2016-09-21 22:13:51.0 
+0100
+++ quadrapassel-3.22.0/debian/changelog2017-05-23 19:48:01.0 
+0100
@@ -1,3 +1,11 @@
+quadrapassel (1:3.22.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix segfault when unpausing a paused game that has finished.
+(Closes: #863106)
+
+ -- Chris Lamb   Tue, 23 May 2017 19:48:01 +0100
+
 quadrapassel (1:3.22.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
quadrapassel-3.22.0/debian/patches/0001_fix-segfault-when-unpausing-a-paused-finished-game.diff
 
quadrapassel-3.22.0/debian/patches/0001_fix-segfault-when-unpausing-a-paused-finished-game.diff
--- 
quadrapassel-3.22.0/debian/patches/0001_fix-segfault-when-unpausing-a-paused-finished-game.diff
 1970-01-01 01:00:00.0 +0100
+++ 
quadrapassel-3.22.0/debian/patches/0001_fix-segfault-when-unpausing-a-paused-finished-game.diff
 2017-05-23 19:48:01.0 +0100
@@ -0,0 +1,16 @@
+Description: Fix segfault when unpausing a paused game that has finished
+Author: Chris Lamb 
+Debian-Bug: #863106
+Last-Update: 2017-05-23
+
+--- quadrapassel-3.22.0.orig/src/game.vala
 quadrapassel-3.22.0/src/game.vala
+@@ -261,6 +261,8 @@ public class Game : Object
+ set
+ {
+ _paused = value;
++if (game_over)
++return;
+ if (has_started)
+ setup_drop_timer ();
+ pause_changed ();
diff -Nru quadrapassel-3.22.0/debian/patches/series 
quadrapassel-3.22.0/debian/patches/series
--- quadrapassel-3.22.0/debian/patches/series   1970-01-01 01:00:00.0 
+0100
+++ quadrapassel-3.22.0/debian/patches/series   2017-05-23 19:48:01.0 
+0100
@@ -0,0 +1 @@
+0001_fix-segfault-when-unpausing-a-paused-finished-game.diff
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: source-only builds and .buildinfo

[Ian Jackson]

Hi, Ximin.  Thanks for your attention.

Ximin Luo writes ("Re: source-only builds and .buildinfo"):
> Also the man page for dpkg-buildpackage is out-of-date:

I think maybe you should file a bug about these ?

> >> So I think for `dgit push-source', there should be no .buildinfo ?
> >> At least, unless dgit ran the clean target.
...
> >> Alternatively dgit could strip out the .buildinfo, depending on
> >> whether it ran rules clean.
> > 
> > What do you think ?
> >
> > (The background here is that `dgit push-source' wants to verify for
> > itself that the .changes file it is uploading is really source-only.
> > Because of the possible presence of extraneous (eg BY-HAND) build
> > artefacts in .changes, Guillem suggested comparing the .changes to the
> > .dsc.  But of course the .changes contains not only the .dsc and the
> > files named in it, but also the .buildinfo.)
> 
> There are a few other options for you:
> 
> - Add a --no-buildinfo flag to dpkg-genchanges, then call dpkg-buildpackage 
> --changes-option=--no-buildinfo

dgit would have to work around the lack of the flag anyway.

> - Ignore the buildinfo entry in the .changes file.
> - Verify that the buildinfo file contains only ".dsc" entries and that they 
> match up with the ones in the changes file.

I did an experimental dpkg-buildpackage -S and I got a .buildinfo
containing the following fields:

  Format
  Source
  Binary
  Architecture
  Version
  Checksums-Md5
  Checksums-Sha1
  Checksums-Sha256
  Build-Origin
  Build-Architecture
  Build-Date
  Installed-Build-Depends
  Environment

Because of the weirdness with `debian/rules clean', it is logically
possible for things like the build depends and the environment to
affect the generated source package.

But, I'm not sure what this buildinfo means in the context of
reproducible builds.  Is it an assertion that if the b-deps etc. are
as specified, this source package will reproduce itself (ie, will be a
fixed point) ?

That doesn't seem very useful.  Sane build machinery which consumes
Debian sources will transport (and, if necessary, modify) those
sources without invoking them to regenerate themselves, so will not
mind source packges which are not a fixed point under
dpkg-buildpackage -S.  (By this definition of `sane' many of our
normal tools are not; but I think any tool that is trying to do build
reproduction must be sane by this definition because otherwise it will
be constantly tripping over buggy packages.)

And of course only pretty bad packages are not a fixed point with any
reasonable combination of the build-deps.  In practice bugs where the
package is simply broken will far outweigh situationns where rules
clean works properly only with certain versions of the depndencies.
Nothing normally actually verifies the fixed-point-ness.  So if the
.buildinfo is such an assertion, it will be a lie in any situation
where the information in it might be useful.

Finally in the context of dgit, the information seems even less likely
to be useful.  Much of the time the person generating the source
package will have avoided the use of rules clean at all.  In such a
situation the build-deps were not involved in generating the source
package.  And dgit does check that the .dsc being uploaded corresponds
to the source the maintainer intended; so with dgit a situation cannot
arise where what is Uploaded = S(Intended) != Intended (where S is the
transformation "unpack, run dpkg-buildpackage -S, grab out the
resulting source package").  With dgit, if S(Intended) != Intended,
either dgit will upload Intended, oblivious to the bug because it
never runs rules clean; or it will run rules clean, discover the
discrepancy, and bomb out.

> I'm actually not sure what your main problem is.

Well, we tripped over this anomaly while trying to decide what dgit
push-source should do.

dgit push-source definitely needs to verify that the .changes file it
is uploading is a source-only upload.  That is a safety catch against
unintended binaryful uploads (for example caused due to some
miscommunication in the stacks of build machinery, or the user
manually specifying the wrong .changes file).  That means dgit
push-source needs to account for every file in the .changes.

The obvious algorithm is to check that every file in the .changes is
either the .dsc itself, or named in the .dsc.  But we discover that
there's a .buildinfo there too.  So we need to decide what to do about
it.

Ignoring the .buildinfo seems like an easy workaround but 1. I don't
understand the implications 2. this seems like it's leaving a bug (the
.buildinfo generation) unfixed and unreported 3. the .buildinfo
contains information which ought not to be disseminated (and
published!) unless necessary (or at least, useful).

Particularly (3) means I'm leaning towards arranging for the
.buildinfo to be stripped out (or not generated).  But then I am
dismantling Chesterton's fence.

Is there a downside to having dgit make source-only uploads which do
not

Re: source-only builds and .buildinfo

[Ximin Luo]

Ian Jackson:
> [..]
> 
>   
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F
>  
> 
> As I wrote to Guillem, quoting the FAQ:
> 
>>   By default dpkg-buildpackage does active tasks such as cleaning via
>>   debian/rules, and makes sure that the dependencies from Build-Depends
>>   are satisfied as these are needed by the clean target. In addition the
>>   clean target can perform any kind of action that will affect the
>>   source package, which is also part of the build, and should be by
>>   default also reproducible
>>
>> I think what you mean here is that one might have a source package
>> which is not a fixed point under `debian/rules clean' for all
>> reasonable combinations of the build-deps.  I think this is a buggy
>> package but in practice it seems that many packages are buggy in this
>> way.
>>
>> Indeed IMO it is a defect of our overall design that it the concept of
>> a `non-reproducible source package' even exists.  Sources are the
>> input to builds, not an output, so the question of reproducing them
>> does not arise.  That our system as a whole can sometimes mutate the
>> source package all by itself is a bug.
>>

I actually would like to see this fixed, then we can put source and binary 
hashes in /var/lib/dpkg/status for every binary package, then we can add these 
to .buildinfo files, which is more secure than adding the version number (as we 
do now).

I agree this is a separate issue, but I have some concrete suggestions that I 
could go into in another thread, if anyone is interested.

Also the man page for dpkg-buildpackage is out-of-date:

   6. Unless a source-only build has been requested, it runs the buildinfo 
hook and calls dpkg-genbuildinfo to generate a .buildinfo file.  Several 
dpkg-buildpackage options are forwarded to dpkg-genbuildinfo.

and also later:

  The current hook-name supported are:
  init preclean source build binary changes postclean check sign 
done

missing out "buildinfo", and indeed if I run "dpkg-buildpackage 
--hook-buildinfo=true" the buildinfo file still gets generated.

>> However, these are not considerations for dgit in this context, since
>> what dgit uploads is always guaranteed to be equal to the input.
>> Often the user will have dgit use `git clean' rather than rules clean;
>> and even if they don't, dgit will check that the results were the
>> same.
>>
>> That is, even with the .buildinfo, someone who gets the .dsc cannot
>> know whether the rules clean target is correct (or to put it another
>> way, under what conditions the source tree is a fixed point under
>> rules clean), because dgit has not necessarily run rules clean at all.
>> I'm sure there are other vcsish tools which have the same property.
>>
>> (Also, and I hesitate to make this argument because of course I
>> support reproducible builds, but: if the .buildinfo is not useful,
>> then it's an unwarranted privacy violation.)
>>
>> So I think for `dgit push-source', there should be no .buildinfo ?
>> At least, unless dgit ran the clean target.
>>
>> This suggests to me that dgit push-source should use dpkg-source
>> rather than dpkg-buildpackage, as you note in later in the FAQ entry:
>>
>>   If the intention is to just produce a source package instead of an
>>   actual build to upload, then using dpkg-source is always the better
>>   option.
>>
>> This wording is a bit unclear.  It conflates `build' and `for upload'.
>> I think regarding `dgit push-source' as a build is perverse.
>>
>> dgit would have to run dpkg-genchanges.
>>
>> Alternatively dgit could strip out the .buildinfo, depending on
>> whether it ran rules clean.
> 
> What do you think ?
>
> (The background here is that `dgit push-source' wants to verify for
> itself that the .changes file it is uploading is really source-only.
> Because of the possible presence of extraneous (eg BY-HAND) build
> artefacts in .changes, Guillem suggested comparing the .changes to the
> .dsc.  But of course the .changes contains not only the .dsc and the
> files named in it, but also the .buildinfo.)
> 

There are a few other options for you:

- Add a --no-buildinfo flag to dpkg-genchanges, then call dpkg-buildpackage 
--changes-option=--no-buildinfo
- Ignore the buildinfo entry in the .changes file.
- Verify that the buildinfo file contains only ".dsc" entries and that they 
match up with the ones in the changes file.

I'm actually not sure what your main problem is. Does dgit by default checkout 
a previously-build .dsc from git? And you are worried that if 
"dpkg-buildpackage -S" is run, causing "debian/rules clean" to be run, that the 
second-built .dsc would differ from the one that is checked in?

If this is the case, you have this problem regardless of whether the .changes 
file contains a .buildinfo file or not, these are two separate issues.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pu

Re: source-only builds and .buildinfo

[Ian Jackson]

Sean Whitton writes ("Re: source-only builds and .buildinfo"):
> On Wed, May 24, 2017 at 11:59:55AM +0100, Ian Jackson wrote:
> > [Ian:]
> > > Alternatively dgit could strip out the .buildinfo, depending on
> > > whether it ran rules clean.
> 
> While a plain `dgit push-source` will prepare a fresh .dsc and .changes,
> we also want it to work with -C, which allows the user to supply an
> existing .dsc and .changes.  So even if we use dpkg-source and
> dpkg-genchanges directly, we still need a validation function that says
> whether a .changes is source-only.

Ah, yes.

> Alternatively we could have dgit not accept -C with push-source.  This
> would be to think of push-source as a command to /do/ a source-only
> upload, rather than a variant on `dgit push` that /ensures/ a
> source-only upload.  This is probably fine.

(For others reading: -C is the dgit option to specify an existing
changes file.  Normally `dgit push-source' would generate one.)

I think that would be suboptimal, though.  If you say -C you should
get the .buildinfo that's in the .changes, I guess.  So that means
that dgit needs a validator, and it needs to accept .buildinfo at
least in this case.

I still think `dgit push-source' (without -C) probably shouldn't
include a buildinfo in the upload unless it ran (or caused
dpkg-buildpackage to run) `debian/rules clean'.

Ian.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: source-only builds and .buildinfo

[Sean Whitton]

On Wed, May 24, 2017 at 11:59:55AM +0100, Ian Jackson wrote:
> > So I think for `dgit push-source', there should be no .buildinfo ?
> > At least, unless dgit ran the clean target.
> > 
> > This suggests to me that dgit push-source should use dpkg-source
> > rather than dpkg-buildpackage, as you note in later in the FAQ entry:
> > 
> >   If the intention is to just produce a source package instead of an
> >   actual build to upload, then using dpkg-source is always the better
> >   option.
> > 
> > This wording is a bit unclear.  It conflates `build' and `for upload'.
> > I think regarding `dgit push-source' as a build is perverse.
> > 
> > dgit would have to run dpkg-genchanges.
> > 
> > Alternatively dgit could strip out the .buildinfo, depending on
> > whether it ran rules clean.

While a plain `dgit push-source` will prepare a fresh .dsc and .changes,
we also want it to work with -C, which allows the user to supply an
existing .dsc and .changes.  So even if we use dpkg-source and
dpkg-genchanges directly, we still need a validation function that says
whether a .changes is source-only.

Alternatively we could have dgit not accept -C with push-source.  This
would be to think of push-source as a command to /do/ a source-only
upload, rather than a variant on `dgit push` that /ensures/ a
source-only upload.  This is probably fine.

-- 
Sean Whitton


signature.asc
Description: PGP signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

source-only builds and .buildinfo

[Ian Jackson]

(Resending with the right CC for reproducible-builds@lists.a.d.o)

Hi.  I'm widening the scope of this thread because I think the
reproducible builds folks might have an opinion.  (Holger said on IRC
that they'd welcome a CC.)  So, I'm going to recap.


dpkg-buildpackage -S (which is the conventional way to build a
source-only upload) generates a .buildinfo file, which ends up
appearing in the .changes.  (I don't know what dak does with it.)

Sean tripped over this in the context of developing a new dgit
operation mode `dgit push-source'.  I found the generation of a
.buildinfo questionable so we asked debian-dpkg.  Guillem pointed me
to this FAQ entry:

  
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F
 

As I wrote to Guillem, quoting the FAQ:

>   By default dpkg-buildpackage does active tasks such as cleaning via
>   debian/rules, and makes sure that the dependencies from Build-Depends
>   are satisfied as these are needed by the clean target. In addition the
>   clean target can perform any kind of action that will affect the
>   source package, which is also part of the build, and should be by
>   default also reproducible
> 
> I think what you mean here is that one might have a source package
> which is not a fixed point under `debian/rules clean' for all
> reasonable combinations of the build-deps.  I think this is a buggy
> package but in practice it seems that many packages are buggy in this
> way.
> 
> Indeed IMO it is a defect of our overall design that it the concept of
> a `non-reproducible source package' even exists.  Sources are the
> input to builds, not an output, so the question of reproducing them
> does not arise.  That our system as a whole can sometimes mutate the
> source package all by itself is a bug.
> 
> However, these are not considerations for dgit in this context, since
> what dgit uploads is always guaranteed to be equal to the input.
> Often the user will have dgit use `git clean' rather than rules clean;
> and even if they don't, dgit will check that the results were the
> same.
> 
> That is, even with the .buildinfo, someone who gets the .dsc cannot
> know whether the rules clean target is correct (or to put it another
> way, under what conditions the source tree is a fixed point under
> rules clean), because dgit has not necessarily run rules clean at all.
> I'm sure there are other vcsish tools which have the same property.
> 
> (Also, and I hesitate to make this argument because of course I
> support reproducible builds, but: if the .buildinfo is not useful,
> then it's an unwarranted privacy violation.)
> 
> So I think for `dgit push-source', there should be no .buildinfo ?
> At least, unless dgit ran the clean target.
> 
> This suggests to me that dgit push-source should use dpkg-source
> rather than dpkg-buildpackage, as you note in later in the FAQ entry:
> 
>   If the intention is to just produce a source package instead of an
>   actual build to upload, then using dpkg-source is always the better
>   option.
> 
> This wording is a bit unclear.  It conflates `build' and `for upload'.
> I think regarding `dgit push-source' as a build is perverse.
> 
> dgit would have to run dpkg-genchanges.
> 
> Alternatively dgit could strip out the .buildinfo, depending on
> whether it ran rules clean.

What do you think ?

(The background here is that `dgit push-source' wants to verify for
itself that the .changes file it is uploading is really source-only.
Because of the possible presence of extraneous (eg BY-HAND) build
artefacts in .changes, Guillem suggested comparing the .changes to the
.dsc.  But of course the .changes contains not only the .dsc and the
files named in it, but also the .buildinfo.)

Thanks,
Ian.

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#843811: downgrading severity

[Holger Levsen]

control: severity -1 normal
thanks

Hi,

downgrading the severity because not being able to strip determinism from
a few files present in very few packages doesn't have a major impact on the
usability of this package. (It's actually closer to wishlist…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Processed: downgrading severity

[Debian Bug Tracking System]

Processing control commands:

> severity -1 normal
Bug #843811 [strip-nondeterminism] strip-nondeterminism: does not strip 
nondeterminism from /SYM64/ ar entries
Severity set to 'normal' from 'important'

-- 
843811: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843811
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds