Debian Bug report logs - #774415
devscripts: please add the srebuild wrapper for reproducible builds

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <j.schauer@email.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Fri, 02 Jan 2015 12:59:28 +0100

[Message part 1 (text/plain, inline)]

Package: sbuild
Version: 0.65.1-1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: toolchain

Control: block -1 by 774359

Hi,

to verify a package build for reproducible builds [1], it is necessary
to carry it out in an environment with the right package versions. This
information is stored in .buildinfo files.

[1] https://wiki.debian.org/ReproducibleBuilds

I wrote a thin wrapper for sbuild which figures out the right timestamp
from snapshot.debian.org that contains the right package versions and
then installs those in sbuild using its hook functionality.

A more detailed explanation can be found in this email:

https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20141229/000613.html

The functionality depends on the resolution of bug #774359, thus adding
it as a blocker for this bug.

You can find the code implementing this functionality attached or in the
pu/reproducible branch in this repository:

http://anonscm.debian.org/cgit/reproducible/sbuild.git/

Thanks!

cheers, josch

[0001-Add-first-proof-of-concept-for-srebuild.patch (text/x-diff, attachment)]

[0002-srebuild-add-man-page-copyright-and-adapt-makefiles.patch (text/x-diff, attachment)]

Message #12 received at 774415-quiet@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@debian.org>

To: 774415-quiet@bugs.debian.org

Subject: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Thu, 19 Feb 2015 15:50:59 -0800

[Message part 1 (text/plain, inline)]

Control: block -1 by 774359

Somehow the block got missed in the bug submission; it doesn't look like
it was intentionally removed...

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #19 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Benjamin Drung <benjamin.drung@profitbricks.com>

To: Johannes Schauer <j.schauer@email.de>, 774415@bugs.debian.org

Subject: Re: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Mon, 13 Apr 2015 15:23:59 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Fri, 02 Jan 2015 12:59:28 +0100 Johannes Schauer <j.schauer@email.de> wrote:
> to verify a package build for reproducible builds [1], it is necessary
> to carry it out in an environment with the right package versions. This
> information is stored in .buildinfo files.
> 
> [1] https://wiki.debian.org/ReproducibleBuilds
> 
> I wrote a thin wrapper for sbuild which figures out the right timestamp
> from snapshot.debian.org that contains the right package versions and
> then installs those in sbuild using its hook functionality.
> 
> A more detailed explanation can be found in this email:
> 
> https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20141229/000613.html
> 
> The functionality depends on the resolution of bug #774359, thus adding
> it as a blocker for this bug.
> 
> You can find the code implementing this functionality attached or in the
> pu/reproducible branch in this repository:
> 
> http://anonscm.debian.org/cgit/reproducible/sbuild.git/

I briefly looked at the code and the man page of your script. I like the
idea to extent the sbuild package to support rebuilds. The
implementation of srebuild is very fine-tuned to one use case and will
break if you violate one of the constrains. I would prefer an
implementation that is more flexible and doesn't require soo many
conditions.

My idea would be to add an option to sbuild to provide a buildinfo file.
When this file is provided, sbuild will adjust the build dependencies to
depend on exactly the package versions that are in the buildinfo file
and tries to install these versions.

This way you just have to make sure that you have the package versions
somewhere available in your sources.list. Then you just need a thin
wrapper around sbuild that feeds additional snapshot.debian.org sources
entries into sbuild.

In case you keep old versions in your package repository (e.g. when you
use reprepro with multiple version management [bug #570623]), you could
simply use sbuild without any modifications.

-- 
Benjamin Drung
System Developer

ProfitBricks GmbH - The IaaS-Company
Greifswalder Str. 207
D - 10405 Berlin

Mail: benjamin.drung@profitbricks.com
Fax:  +49 30 577 008 598
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B.
Geschäftsführer: Andreas Gauger, Achim Weiss.

[signature.asc (application/pgp-signature, inline)]

Message #24 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Benjamin Drung <benjamin.drung@profitbricks.com>, 774415@bugs.debian.org

Subject: Re: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Tue, 14 Apr 2015 18:40:09 +0200

[Message part 1 (text/plain, inline)]

Hi,

Quoting Benjamin Drung (2015-04-13 15:23:59)
> I briefly looked at the code and the man page of your script. I like the idea
> to extent the sbuild package to support rebuilds. The implementation of
> srebuild is very fine-tuned to one use case and will break if you violate one
> of the constrains. I would prefer an implementation that is more flexible and
> doesn't require soo many conditions.

I understand.

> My idea would be to add an option to sbuild to provide a buildinfo file.
> When this file is provided, sbuild will adjust the build dependencies to
> depend on exactly the package versions that are in the buildinfo file and
> tries to install these versions.

This sounds like a very good idea.

> This way you just have to make sure that you have the package versions
> somewhere available in your sources.list. Then you just need a thin wrapper
> around sbuild that feeds additional snapshot.debian.org sources entries into
> sbuild.
> 
> In case you keep old versions in your package repository (e.g. when you
> use reprepro with multiple version management [bug #570623]), you could
> simply use sbuild without any modifications.

I agree with your plan but I don't have much time right now so nobody should be
stopped from implementing it before I get to it :)

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Benjamin Drung <benjamin.drung@profitbricks.com>

Cc: Johannes Schauer <j.schauer@email.de>, 774415@bugs.debian.org

Subject: Re: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Wed, 15 Apr 2015 13:14:23 +0200

[Message part 1 (text/plain, inline)]

Hi Benjamin,

On Montag, 13. April 2015, Benjamin Drung wrote:
> I briefly looked at the code and the man page of your script. I like the
> idea to extent the sbuild package to support rebuilds. The
> implementation of srebuild is very fine-tuned to one use case and will
> break if you violate one of the constrains. I would prefer an
> implementation that is more flexible and doesn't require soo many
> conditions.

makes sense.
 
> My idea would be to add an option to sbuild to provide a buildinfo file.
> When this file is provided, sbuild will adjust the build dependencies to
> depend on exactly the package versions that are in the buildinfo file
> and tries to install these versions.
> 
> This way you just have to make sure that you have the package versions
> somewhere available in your sources.list. 

This is not trivial in many cases, eg snapshot.d.o - or to phrase it 
differently: josch srebuild wrapper was doing exactly this. So if you'd 
generalize his script, this functionality should be preserved somehow.

> Then you just need a thin
> wrapper around sbuild that feeds additional snapshot.debian.org sources
> entries into sbuild.

oh, you just said that.

> In case you keep old versions in your package repository (e.g. when you
> use reprepro with multiple version management [bug #570623]), you could
> simply use sbuild without any modifications.

It would be great if sbuild could be used out-of-the-box to reproducibly 
rebuild packages from Debian and Ubuntu (and other distros) without any 
further modificication. Does ubuntu use sbuild btw?


cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 774415@bugs.debian.org (full text, mbox, reply):

From: HW42 <hw42@ipsumj.de>

To: 774415@bugs.debian.org

Subject: Re: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Sat, 06 Jun 2015 16:23:20 +0200

[Message part 1 (text/plain, inline)]

Hi,

I just noted that the current implementation of srebuild [0] calls
apt-get install with --force-yes which (as far as I remember) ignores
signature verification errors.

HW42

[0]:
https://anonscm.debian.org/cgit/reproducible/sbuild.git/tree/bin/srebuild-hook?h=pu/reproducible_builds#n110

[signature.asc (application/pgp-signature, attachment)]

Message #44 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Subject: srebuild wrapper needs hashes in buildinfo files to query snapshot.d.o

Date: Mon, 09 May 2016 21:07:40 +0200

[Message part 1 (text/plain, inline)]

Control: block -1 by 802241

The main disadvantage of the current srebuild implementation is, that it will
only make use of a single snapshot.d.o timestamp. This makes it impossible to
reproduce situations where packages are not built in a clean chroot, in a
partially updated chroot or in a chroot mixing different suites. To assemble a
chroot with the right package versions, sbuild could retrieve the exact right
debs from snapshot.d.o.

Snapshot.d.o provides the
/mr/package/<package>/<version>/binfiles/<binpkg>/<binversion> API to retrieve
hashes of .deb packages of the right architecture. With that hash, srebuild can
retrieve the right dependencies.

It would be simpler if the .buildinfo files would already contain the right
hashes such that less API queries would be necessary.

Thus, blocking this bug by #802241.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #51 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Subject: Re: srebuild wrapper needs hashes in buildinfo files to query snapshot.d.o

Date: Thu, 28 Jul 2016 06:59:41 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Mon, 09 May 2016 21:07:40 +0200 Johannes Schauer <josch@debian.org> wrote:
> The main disadvantage of the current srebuild implementation is, that it will
> only make use of a single snapshot.d.o timestamp. This makes it impossible to
> reproduce situations where packages are not built in a clean chroot, in a
> partially updated chroot or in a chroot mixing different suites. To assemble
> a chroot with the right package versions, sbuild could retrieve the exact
> right debs from snapshot.d.o.
> 
> Snapshot.d.o provides the
> /mr/package/<package>/<version>/binfiles/<binpkg>/<binversion> API to retrieve
> hashes of .deb packages of the right architecture. With that hash, srebuild can
> retrieve the right dependencies.

this API function requires the source package name and version which we don't
have from a buildinfo file. Luckily, there is also
/mr/binary/<binpkg>/<binversion>/binfiles

See: http://anonscm.debian.org/cgit/mirror/snapshot.debian.org.git/plain/API

> It would be simpler if the .buildinfo files would already contain the right
> hashes such that less API queries would be necessary.

This conclusion still holds.

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #56 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: From srebuild sbuild-wrapper to debrebuild

Date: Tue, 02 Aug 2016 22:49:00 +0200

[Message part 1 (text/plain, inline)]

Hi,

On Mon, 09 May 2016 21:07:40 +0200 Johannes Schauer <josch@debian.org> wrote:
> The main disadvantage of the current srebuild implementation is, that it will
> only make use of a single snapshot.d.o timestamp. This makes it impossible to
> reproduce situations where packages are not built in a clean chroot, in a
> partially updated chroot or in a chroot mixing different suites. To assemble
> a chroot with the right package versions, sbuild could retrieve the exact
> right debs from snapshot.d.o.

I was thinking about this issue again and thought that instead of creating a
wrapper for sbuild which then uses a chroot-setup hook to install the
dependencies, what I should instead do is to let sbuild itself accept
.buildinfo files and then do the right thing like:

 - use snapshot.d.o to retrieve the right timestamps needed to gather all
   packages
 - mangle the build dependencies such that the source package now depends on
   the exact right package versions and let the resolver figure out the rest
   (thanks Benjamin for that idea)
 - check whether the generated binaries produce the same checksum as given in
   the supplied buildinfo file

But then on IRC, HW42 suggested to approach this problem differently. Instead
of integrating the functionality of figuring out the right repositories to
reproduce the contents of a buildinfo file into sbuild, write a tool that can
drive any package builder (like pbuilder).

I now wrote such a script. It currently supports sbuild or manual installation
by showing the correct sources.list. For both it prints the correct command
line invocations. Advantages over the old sbuild hook-based script attached to
initial post are:

 - package versions can come from multiple snapshot timestamps
 - theoretically works for more package builders than just sbuild (pbuilder
   support is missing because I don't know enough about pbuilder)
 - uses Dpkg::Checksums to parse and verify the hash and size fields instead of
   doing it manually
 - uses apt to download and manage Packages files instead of doing it manually
 - allows to add additional repositories like reproducible.alioth.debian.org
   (which is hardcoded so far)
 - uses base-files and dpkg version to estimate a base Debian release
 - drastically reduce number snapshot.d.o API queries by only querying for
   missing packages

Limitations:

 - There is no nice command line interface with options and switches yet
 - You cannot yet supply additional initial archives
   (reproducible.alioth.debian.org is hardcoded)
 - It only considers Debian main
 - It only considers official Debian (and not ports)
 - It only considers Debian unstable from snapshot.d.o
 - You have to manually run sbuild/pbuilder with the displayed command and then
   manually verify if the .buildinfo file stayed the same

What is still needed:

 - a good name (I named it debrebuild for now because it is Debian centric and
   rebuilds a package that was built before to check if the checksums can be
   reproduced locally. This is the main difference to reprotest which does not
   require an existing build but checks for reproducibility by building the
   same software twice in different environments)
 - a nice home for the script to live
 - somebody maintaining the software and making it more user friendly by adding
   a nice command line interface and writing a README file and/or man page
 - maybe let the script execute the sbuild/pbuilder command it suggests to run
   as well. This would allow the script to check the output for plausibility.

Usage:

   debrebuild.pl package.buildinfo

Depends:

   apt-get install --no-install-recommends libdpkg-perl libwww-perl libdatetime-format-strptime-perl

Have fun!

cheers, josch

[debrebuild.pl (text/x-perl, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #61 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 10 Nov 2016 05:54:13 -0200

[Message part 1 (text/plain, inline)]

Hi all,

On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <josch@debian.org> wrote:
> I was thinking about this issue again and thought that instead of creating a
> wrapper for sbuild which then uses a chroot-setup hook to install the
> dependencies, what I should instead do is to let sbuild itself accept
> .buildinfo files and then do the right thing like:
> 
>  - use snapshot.d.o to retrieve the right timestamps needed to gather all
>    packages
>  - mangle the build dependencies such that the source package now depends on
>    the exact right package versions and let the resolver figure out the rest
>    (thanks Benjamin for that idea)
>  - check whether the generated binaries produce the same checksum as given in
>    the supplied buildinfo file
> 
> But then on IRC, HW42 suggested to approach this problem differently. Instead
> of integrating the functionality of figuring out the right repositories to
> reproduce the contents of a buildinfo file into sbuild, write a tool that can
> drive any package builder (like pbuilder).
> 
> I now wrote such a script.

now that libdpkg-perl comes with support for .buildinfo files, I improved the
script (new version attached) with the following changes:

 - don't use DateTime::Format::Strptime but Time::Piece instead (which is a
   perl core module)
 - don't use CTRL_INDEX_SRC but CTRL_FILE_BUILDINFO now that dpkg supports
   .buildinfo files
 - Dpkg::Compression::FileHandle as it is not needed
 - the .dsc file name is no longer part of the .buildinfo file, so assemble the
   .dsc file name from the package name and version using Dpkg::Source::Package
 - use the information from the Environment field
 - instead of splitting Installed-Build-Depends manually, use
   Dpkg::Deps::deps_parse
 - instead of using [trusted=yes], retrieve the gpg key of the reproducible
   builds repository and verify its fingerprint
 - set Binary::apt-get::Acquire::AllowInsecureRepositories to false so that
   apt-get fails to update repositories it cannot authenticate
 - use Dpkg::Vendor to retrieve the keyring filenames

Thanks to Guillem Jover for the code review!

cheers, josch

[debrebuild.pl (text/x-perl, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #66 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 10 Nov 2016 12:59:43 -0200

[Message part 1 (text/plain, inline)]

Hi,

On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <josch@debian.org> wrote:
> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <josch@debian.org> wrote:
> > But then on IRC, HW42 suggested to approach this problem differently.
> > Instead of integrating the functionality of figuring out the right
> > repositories to reproduce the contents of a buildinfo file into sbuild,
> > write a tool that can drive any package builder (like pbuilder).

there seems to be a conceptual problem with such an approach.

For binNMUs, the full changelog entry has to be passed to sbuild or pbuilder.
How does one best pass such a multi-line value via command line options? Would
the best way to pass the changelog entry via the .buildinfo file? And if
pbuilder and sbuild then already are parsing the .buildinfo file, would it not
be better for the debrebuild machinery to be implemented by either in the first
place?

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #71 received at 774415@bugs.debian.org (full text, mbox, reply):

From: HW42 <hw42@ipsumj.de>

To: 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 10 Nov 2016 15:23:00 +0000

[Message part 1 (text/plain, inline)]

Johannes Schauer:
> Hi,
> 
> On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <josch@debian.org> wrote:
>> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <josch@debian.org> wrote:
>>> But then on IRC, HW42 suggested to approach this problem differently.
>>> Instead of integrating the functionality of figuring out the right
>>> repositories to reproduce the contents of a buildinfo file into sbuild,
>>> write a tool that can drive any package builder (like pbuilder).
> 
> there seems to be a conceptual problem with such an approach.
> 
> For binNMUs, the full changelog entry has to be passed to sbuild or pbuilder.
> How does one best pass such a multi-line value via command line options?

What's your problem with passing multi-line value via command line
options?

> Would the best way to pass the changelog entry via the .buildinfo
> file?

Not sure about that. If you dislike passing the value via a command line
option, just use a plain file?

> And if pbuilder and sbuild then already are parsing the .buildinfo
> file, would it not be better for the debrebuild machinery to be
> implemented by either in the first place?

My point for an independent debrebuild was that

a) Every builder needs nearly the same functionaly for this.
b) It's security relevant since it parses semi-trusted (the .buildinfo)
   and untrusted (http response from snapshot.d.o) data.

So I still think that having this separate of the builder is useful. If
sbuild, pbuilder, etc. coordinate this, some kind of library might also be
an option.

[signature.asc (application/pgp-signature, attachment)]

Message #76 received at 774415@bugs.debian.org (full text, mbox, reply):

From: HW42 <hw42@ipsumj.de>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org

Subject: Re: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 17 Nov 2016 04:10:00 +0000

[Message part 1 (text/plain, inline)]

Johannes Schauer:
> Hi all,
> 
> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <josch@debian.org> wrote:
>> I was thinking about this issue again and thought that instead of creating a
>> wrapper for sbuild which then uses a chroot-setup hook to install the
>> dependencies, what I should instead do is to let sbuild itself accept
>> .buildinfo files and then do the right thing like:
>>
>>  - use snapshot.d.o to retrieve the right timestamps needed to gather all
>>    packages
>>  - mangle the build dependencies such that the source package now depends on
>>    the exact right package versions and let the resolver figure out the rest
>>    (thanks Benjamin for that idea)
>>  - check whether the generated binaries produce the same checksum as given in
>>    the supplied buildinfo file
>>
>> But then on IRC, HW42 suggested to approach this problem differently. Instead
>> of integrating the functionality of figuring out the right repositories to
>> reproduce the contents of a buildinfo file into sbuild, write a tool that can
>> drive any package builder (like pbuilder).
>>
>> I now wrote such a script.
> 
> now that libdpkg-perl comes with support for .buildinfo files, I improved the
> script (new version attached) with the following changes:
> 
>  - don't use DateTime::Format::Strptime but Time::Piece instead (which is a
>    perl core module)
>  - don't use CTRL_INDEX_SRC but CTRL_FILE_BUILDINFO now that dpkg supports
>    .buildinfo files
>  - Dpkg::Compression::FileHandle as it is not needed
>  - the .dsc file name is no longer part of the .buildinfo file, so assemble the
>    .dsc file name from the package name and version using Dpkg::Source::Package
>  - use the information from the Environment field
>  - instead of splitting Installed-Build-Depends manually, use
>    Dpkg::Deps::deps_parse
>  - instead of using [trusted=yes], retrieve the gpg key of the reproducible
>    builds repository and verify its fingerprint
>  - set Binary::apt-get::Acquire::AllowInsecureRepositories to false so that
>    apt-get fails to update repositories it cannot authenticate
>  - use Dpkg::Vendor to retrieve the keyring filenames
> 
> Thanks to Guillem Jover for the code review!

After discussing this in the irc meeting yesterday I propose that:

 - we keep it as a separate tool.
 - put it in a git repo under
   https://anonscm.debian.org/git/reproducible/
 - We have more than enough DDs who are willing to sponsor uploads, so
   having it in the Debian archive is no problem.
 - we mainly maintain this as a group. I will try to especially keep an
   eye on it.

Since you have done all the work so far the final decision is obviously
up to you.

If the above is fine with you I will prepare packaging it during the next
week (I also have a few improvements planed).

[signature.asc (application/pgp-signature, attachment)]

Message #81 received at 774415@bugs.debian.org (full text, mbox, reply):

From: HW42 <hw42@ipsumj.de>

To: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 17 Nov 2016 04:15:00 +0000

[Message part 1 (text/plain, inline)]

Johannes Schauer:
> Hi,
> 
> On Thu, 10 Nov 2016 05:54:13 -0200 Johannes Schauer <josch@debian.org> wrote:
>> On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer <josch@debian.org> wrote:
>>> But then on IRC, HW42 suggested to approach this problem differently.
>>> Instead of integrating the functionality of figuring out the right
>>> repositories to reproduce the contents of a buildinfo file into sbuild,
>>> write a tool that can drive any package builder (like pbuilder).
> 
> there seems to be a conceptual problem with such an approach.
> 
> For binNMUs, the full changelog entry has to be passed to sbuild or pbuilder.
> How does one best pass such a multi-line value via command line options? Would
> the best way to pass the changelog entry via the .buildinfo file? And if
> pbuilder and sbuild then already are parsing the .buildinfo file, would it not
> be better for the debrebuild machinery to be implemented by either in the first
> place?

Since this is somewhat relevant to the discussion in the other part of
this thread: I don't think this is a conceptual problem. Sure it could
be nicer if we don't had binNMUs, but I see no real problem in passing
it via cmd line option or via a plain file. I would anyway modify
debrebuild to be able to call sbuild/pbuiler/etc. directly and then you
are able to use a tempfile cleanly.

[signature.asc (application/pgp-signature, attachment)]

Message #86 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: HW42 <hw42@ipsumj.de>,

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org

Subject: Re: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 17 Nov 2016 08:24:27 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting HW42 (2016-11-17 05:10:00)
> After discussing this in the irc meeting yesterday I propose that:
> 
>  - we keep it as a separate tool.
>  - put it in a git repo under
>    https://anonscm.debian.org/git/reproducible/
>  - We have more than enough DDs who are willing to sponsor uploads, so
>    having it in the Debian archive is no problem.
>  - we mainly maintain this as a group. I will try to especially keep an
>    eye on it.
> 
> Since you have done all the work so far the final decision is obviously
> up to you.
> 
> If the above is fine with you I will prepare packaging it during the next
> week (I also have a few improvements planed).

please go ahead.

I'll make sure that sbuild adds a facility to receive a full binNMU changelog
entry from the user.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #91 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 15 Dec 2016 15:04:19 +0200

On Tue, Aug 02, 2016 at 10:49:00PM +0200, Johannes Schauer wrote:

> But then on IRC, HW42 suggested to approach this problem differently. Instead
> of integrating the functionality of figuring out the right repositories to
> reproduce the contents of a buildinfo file into sbuild, write a tool that can
> drive any package builder (like pbuilder).

Thanks for your work. I had a belated look and I'm willing to (help to)
maintain this stuff in the reproducible-builds team.

In general, I like the concept of sbuild/pbuilder accepting .buildinfo
files as input. This makes the user interface simple. My expectation
for this mode of operation would be for the builder to recreate the old
build as closely as possible.

Like you two, I'm also wondering about the interaction of the various
tools here.  The heavy weight lifted by this one is locating the package
versions specified in a .buildinfo file. It seems to me that this
functionality could also be a standalone helper tool that sbuild and
pbuilder could call to determine the necessary apt sources.list entries.

The other somewhat generic thing that the current script does / could
do is mangling the package build dependencies to correspond to the
exact versions in the .buildinfo file. This is a much easier and quite
mechanical task, but it might still be worth to make it into a filter
that takes one .dsc and outputs a modified one with strictly versioned
build dependencies?

With those, I'm thinking that 'sbuild foo.buildinfo' would fork out to
buildinfo-findrepos (or whatever) and possibly buildinfo-mangledsc,
and then read the environment variables, possible binNMU information
etc. from the .buildinfo file by itself.

I suppose there could still be a 'debrebuild' or 'buildinfo-rebuild'
tool that just calls a builder with a .buildinfo file and compares the
resulting binaries.

Thoughts?

I've pushed the current implementation (with a timestamp sorting fix) to

 https://anonscm.debian.org/cgit/reproducible/debrebuild.git/

but of course we can still generalize on that and change names etc.
as necessary.
-- 
Niko Tyni   ntyni@debian.org

Message #96 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Niko Tyni <ntyni@debian.org>, 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Thu, 15 Dec 2016 14:21:49 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Niko Tyni (2016-12-15 14:04:19)
> > But then on IRC, HW42 suggested to approach this problem differently.
> > Instead of integrating the functionality of figuring out the right
> > repositories to reproduce the contents of a buildinfo file into sbuild,
> > write a tool that can drive any package builder (like pbuilder).
> 
> Thanks for your work. I had a belated look and I'm willing to (help to)
> maintain this stuff in the reproducible-builds team.

thanks!

> In general, I like the concept of sbuild/pbuilder accepting .buildinfo files
> as input. This makes the user interface simple. My expectation for this mode
> of operation would be for the builder to recreate the old build as closely as
> possible.

I agree but would add that they should also have the ability to tell the user
if the checksums of the re-compiled packages do or do not match the information
in the supplied .buildinfo file.

> Like you two, I'm also wondering about the interaction of the various tools
> here.  The heavy weight lifted by this one is locating the package versions
> specified in a .buildinfo file. It seems to me that this functionality could
> also be a standalone helper tool that sbuild and pbuilder could call to
> determine the necessary apt sources.list entries.
> 
> The other somewhat generic thing that the current script does / could
> do is mangling the package build dependencies to correspond to the
> exact versions in the .buildinfo file. This is a much easier and quite
> mechanical task, but it might still be worth to make it into a filter
> that takes one .dsc and outputs a modified one with strictly versioned
> build dependencies?

Doing the latter is extremely trivial:

 - one call to Dpkg::Control->new() to parse the .buildinfo
 - one call to Dpkg::Deps::deps_parse() to parse Installed-Build-Depends
 - one loop over the result, printing it

The first step will even already be done in sbuild/pbuilder if they are the
ones accepting .builidinfo files. So this doesn't seem complicated enough to
warrant its own tool but I'm of course not stopping anybody from writing one.
:)

> With those, I'm thinking that 'sbuild foo.buildinfo' would fork out to
> buildinfo-findrepos (or whatever) and possibly buildinfo-mangledsc, and then
> read the environment variables, possible binNMU information etc. from the
> .buildinfo file by itself.
> 
> I suppose there could still be a 'debrebuild' or 'buildinfo-rebuild'
> tool that just calls a builder with a .buildinfo file and compares the
> resulting binaries.

If sbuild/pbuilder are parsing the .buildinfo themselves, then they can compare
the resulting binaries themselves as well. I think doing that would be expected
when providing a .buildinfo as input to either. Then no further wrapper would
be needed.

I don't care whether we have debrebuild as a wrapper to sbuild/pbuilder or
sbuild/pbuilder use a common tool to figure out the right lines for the
sources.list inside the chroot. I just want to have .buildinfo support for
sbuild in Stretch and if either solution is not in unstable soon, then my plan
is to just add .buildinfo support to sbuild myself so that it's still included
in the next Debian stable release.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #101 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Niko Tyni <ntyni@debian.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Sat, 17 Dec 2016 14:40:32 +0200

On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote:
> Quoting Niko Tyni (2016-12-15 14:04:19)

> > In general, I like the concept of sbuild/pbuilder accepting .buildinfo files
> > as input. This makes the user interface simple. My expectation for this mode
> > of operation would be for the builder to recreate the old build as closely as
> > possible.
> 
> I agree but would add that they should also have the ability to tell the user
> if the checksums of the re-compiled packages do or do not match the information
> in the supplied .buildinfo file.

I suppose; please just make sure such a failure is easily distinguishable
from a failing build.

> > The other somewhat generic thing that the current script does / could
> > do is mangling the package build dependencies to correspond to the
> > exact versions in the .buildinfo file. This is a much easier and quite
> > mechanical task, but it might still be worth to make it into a filter
> > that takes one .dsc and outputs a modified one with strictly versioned
> > build dependencies?

> Doing the latter is extremely trivial:

Right, I see.

> I don't care whether we have debrebuild as a wrapper to sbuild/pbuilder or
> sbuild/pbuilder use a common tool to figure out the right lines for the
> sources.list inside the chroot. I just want to have .buildinfo support for
> sbuild in Stretch and if either solution is not in unstable soon, then my plan
> is to just add .buildinfo support to sbuild myself so that it's still included
> in the next Debian stable release.

Having this just inside sbuild for stretch and refactoring it out later
if necessary works for me, but I'm not sure if HW42 and/or Mattia have
thoughts about the pbuilder side?

I note that we're only getting started on working with .buildinfo
files. It seems possible that we encounter enough common tasks that
something like a 'buildinfo-utils' package will be warranted, in which
case a 'buildinfo find-debs' command would fit in there.

(Another task for buildinfo-utils I can think of is diffing/intersecting
build environment information in two .buildinfo files to determine
different/common things about two builds, but this is getting off-topic
for this bug...)
-- 
Niko Tyni   ntyni@debian.org

Message #106 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Niko Tyni <ntyni@debian.org>,

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org, hw42@ipsumj.de, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Sat, 17 Dec 2016 14:30:40 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Niko Tyni (2016-12-17 13:40:32)
> On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote:
> > Quoting Niko Tyni (2016-12-15 14:04:19)
> > > In general, I like the concept of sbuild/pbuilder accepting .buildinfo files
> > > as input. This makes the user interface simple. My expectation for this mode
> > > of operation would be for the builder to recreate the old build as closely as
> > > possible.
> > 
> > I agree but would add that they should also have the ability to tell the user
> > if the checksums of the re-compiled packages do or do not match the information
> > in the supplied .buildinfo file.
> 
> I suppose; please just make sure such a failure is easily distinguishable
> from a failing build.

My plan would be to add it as a success/failure line next to the lintian or
autopkgtest status at the bottom of the build log.

> > I don't care whether we have debrebuild as a wrapper to sbuild/pbuilder or
> > sbuild/pbuilder use a common tool to figure out the right lines for the
> > sources.list inside the chroot. I just want to have .buildinfo support for
> > sbuild in Stretch and if either solution is not in unstable soon, then my
> > plan is to just add .buildinfo support to sbuild myself so that it's still
> > included in the next Debian stable release.
> 
> Having this just inside sbuild for stretch and refactoring it out later
> if necessary works for me, but I'm not sure if HW42 and/or Mattia have
> thoughts about the pbuilder side?

Putting them back in CC.

I am especially waiting for a response from HW42 who volunteered to "keep an
eye on it" but who didn't come back to my pings on IRC yet.

HW42: I need to know what your plan is for Stretch so that I can decide what to
include in the next sbuild release.

> I note that we're only getting started on working with .buildinfo files. It
> seems possible that we encounter enough common tasks that something like a
> 'buildinfo-utils' package will be warranted, in which case a 'buildinfo
> find-debs' command would fit in there.

I'm all in for breaking out common functionality into tools used by multiple
parties.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #111 received at 774415@bugs.debian.org (full text, mbox, reply):

From: HW42 <hw42@ipsumj.de>

To: Johannes Schauer <josch@debian.org>, Niko Tyni <ntyni@debian.org>

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Mon, 19 Dec 2016 06:37:00 +0000

[Message part 1 (text/plain, inline)]

Johannes Schauer:
> Hi,
> 
> Quoting Niko Tyni (2016-12-17 13:40:32)
>> On Thu, Dec 15, 2016 at 02:21:49PM +0100, Johannes Schauer wrote:
>>> Quoting Niko Tyni (2016-12-15 14:04:19)
>>>> In general, I like the concept of sbuild/pbuilder accepting .buildinfo files
>>>> as input. This makes the user interface simple. My expectation for this mode
>>>> of operation would be for the builder to recreate the old build as closely as
>>>> possible.
>>>
>>> I agree but would add that they should also have the ability to tell the user
>>> if the checksums of the re-compiled packages do or do not match the information
>>> in the supplied .buildinfo file.
>>
>> I suppose; please just make sure such a failure is easily distinguishable
>> from a failing build.
> 
> My plan would be to add it as a success/failure line next to the lintian or
> autopkgtest status at the bottom of the build log.
> 
>>> I don't care whether we have debrebuild as a wrapper to sbuild/pbuilder or
>>> sbuild/pbuilder use a common tool to figure out the right lines for the
>>> sources.list inside the chroot. I just want to have .buildinfo support for
>>> sbuild in Stretch and if either solution is not in unstable soon, then my
>>> plan is to just add .buildinfo support to sbuild myself so that it's still
>>> included in the next Debian stable release.
>>
>> Having this just inside sbuild for stretch and refactoring it out later
>> if necessary works for me, but I'm not sure if HW42 and/or Mattia have
>> thoughts about the pbuilder side?
> 
> Putting them back in CC.
> 
> I am especially waiting for a response from HW42 who volunteered to "keep an
> eye on it" but who didn't come back to my pings on IRC yet.
> 
> HW42: I need to know what your plan is for Stretch so that I can decide what to
> include in the next sbuild release.

Sorry about the late reply.

I didn't had any plans sofar for stretch. Given that a) the .buildinfo
format it self b) the services around .buildinfo c) the interface of
debrebuild (or buildinfo-utils, or whatever) is not really
clear/finished yet I would expect that one need anyway the backports
version. If you think otherwise we can of course push to get the current
version into stretch.

>> I note that we're only getting started on working with .buildinfo files. It
>> seems possible that we encounter enough common tasks that something like a
>> 'buildinfo-utils' package will be warranted, in which case a 'buildinfo
>> find-debs' command would fit in there.
> 
> I'm all in for breaking out common functionality into tools used by multiple
> parties.

So you (at least josch and ntyi) seem to prefer to have the user facing
part in sbuild/pbuilder and the common functionality in some kind of
library. How should the "library" interface look like for sbuild?

[signature.asc (application/pgp-signature, attachment)]

Message #116 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: HW42 <hw42@ipsumj.de>, "Niko Tyni" <ntyni@debian.org>

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Mon, 19 Dec 2016 10:02:58 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting HW42 (2016-12-19 07:37:00)
> So you (at least josch and ntyi) seem to prefer to have the user facing part
> in sbuild/pbuilder and the common functionality in some kind of library. How
> should the "library" interface look like for sbuild?

pbuilder is written in bash, so a plain-text interface via stdin/stdout would
be preferrable, I guess. The tool figuring out the right snapshot timestamps
could just write an apt sources.list in deb822 format on standard output. Even
if the builder doesn't use the apt resolver, the deb822 format is easy to parse
and thus any required information can be extracted from it.

I also came up with another question:

sbuild/pbuilder/debrebuild are given a .buildinfo file. But that file does not
necessarily include a reference to a .dsc. What shall be done in that case?

The current debrebuild script will auto-generate the filename of the .dsc from
the Source and Version fields of the .buildinfo file. Though the resulting .dsc
might accidentally come from a different build. Is this okay?

Other ways to solve this problem include:

 - only accept .buildinfo files that include the .dsc filename and checksum

    $ builder foo.buildinfo
    E: foo.buildinfo does not reference a source package

 - accept .changes files that reference both the .buildinfo and the .dsc

    $ builder foo.changes
    I: .changes file references a .buildinfo, will verify checksums at the end

 - make .buildinfo files a second-class citizen which are passed *in addition*
   to a .dsc

    $ builder foo.dsc --use-buildinfo=foo.buildinfo

 - accept .buildinfo files, autogenerate the .dsc filename but allow to
   override it via the command line

    $ builder foo.buildinfo --use-dsc=foo.dsc

Thoughts?

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #121 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Cc: HW42 <hw42@ipsumj.de>, Niko Tyni <ntyni@debian.org>, reproducible-builds@lists.alioth.debian.org, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Mon, 19 Dec 2016 09:35:53 +0000

[Message part 1 (text/plain, inline)]

On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote:
> Other ways to solve this problem include:
>  - only accept .buildinfo files that include the .dsc filename and checksum
>  - accept .changes files that reference both the .buildinfo and the .dsc

those two seem sensible to me.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #126 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Tue, 20 Dec 2016 13:49:27 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Johannes Schauer (2016-12-19 10:02:58)
> I also came up with another question:

and as I'm implementing this, here yet another:

Currently, a buildinfo file does not specify which artifacts were supposed to
be built (source,any,all). What should happen if the buildinfo file was for an
Arch:any build but when rebuilding the source package, also arch:all packages
show up? What should happen if the original build was including the source
package but now it does not?

Should the verification fail if the build produces artifacts that are not
listed in the buildinfo?

Should the verification fail if the build produces does not produce artifacts
that are listed in the buildinfo?

How should a rebuilder infer the value of the --build argument that it passes
to dpkg-buildpackage to reproduce the given buildinfo file?

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #131 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 01:11:57 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Johannes Schauer (2016-12-20 13:49:27)
> Currently, a buildinfo file does not specify which artifacts were supposed to
> be built (source,any,all).

as guillem points out to me on #debian-dpkg, the Architecture field lists
exactly that. It will contain "source" if the source package was built, "all"
for arch:all packages and a Debian architecture for arch:any builds.

> What should happen if the buildinfo file was for an Arch:any build but when
> rebuilding the source package, also arch:all packages show up? What should
> happen if the original build was including the source package but now it does
> not?
> 
> Should the verification fail if the build produces artifacts that are not
> listed in the buildinfo?
> 
> Should the verification fail if the build produces does not produce artifacts
> that are listed in the buildinfo?

I thus propose that a builder should use the Architecture field to figure out
what to build and fail if the produced artifacts are any different from the
ones in the buildinfo (being as strict about it as possible).

I implemented parsing of the Architecture field in the debrebuild.pl script and
let it pass the --build, --host, --arch-all, --arch-any and --source options to
sbuild.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #136 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org, pbuilder@packages.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 01:50:11 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Holger Levsen (2016-12-19 10:35:53)
> On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote:
> > Other ways to solve this problem include:
> >  - only accept .buildinfo files that include the .dsc filename and checksum
> >  - accept .changes files that reference both the .buildinfo and the .dsc
> 
> those two seem sensible to me.

I see why you think those make sense and I see how I could agree with you. But
thinking about this again, I think that the problem with implementing these two
options would be that they would sneak in an unexpected privacy breach.

If I add an option like --rebuild-and-verify=foo.buildinfo then the
documentation for that command line option can include a big fat warning that
using this option will try accessing snapshot.d.o to retrieve the right package
versions. Including this warning if the buildinfo is used implicitly (for
example if only a .changes file is passed) is not so easy.

Furthermore, .changes files will now nearly always include a reference to the
.buildinfo file. So if a .changes file were used, then another command line
argument would be needed to turn the buildinfo verification on or off
(depending on what the default is).

Lastly, accepting bare .buildinfo files requires them to reference the .dsc
which I find quite limiting. Builders should be able to verify .buildinfo files
that do not contain the source package.

Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option
to sbuild sounds like the most sane thing to do. It would even not require the
existing interface to change (the positional argument is a single source
package).

Any thoughts?

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #141 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 774415@bugs.debian.org

Subject: Re: Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 01:08:57 +0000

[Message part 1 (text/plain, inline)]

On Wed, Dec 21, 2016 at 01:50:11AM +0100, Johannes Schauer wrote:
> Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option
> to sbuild sounds like the most sane thing to do. It would even not require the
> existing interface to change (the positional argument is a single source
> package).
> 
> Any thoughts?

as long as there's a short version of --rebuild-and-verify=foo.buildinfo
such as (for example) -rb=foo.buildinfo fine with me… :)

(though I'm not sure I fully understand why not assume -rb if
foo.buildinfo is given - I do understand for foo.changes…)


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #146 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 774415@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 08:14:23 +0100

[Message part 1 (text/plain, inline)]

Quoting Holger Levsen (2016-12-21 02:08:57)
> On Wed, Dec 21, 2016 at 01:50:11AM +0100, Johannes Schauer wrote:
> > Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option
> > to sbuild sounds like the most sane thing to do. It would even not require the
> > existing interface to change (the positional argument is a single source
> > package).
> > 
> > Any thoughts?
> 
> as long as there's a short version of --rebuild-and-verify=foo.buildinfo
> such as (for example) -rb=foo.buildinfo fine with me… :)

the -r short option is still free.

> (though I'm not sure I fully understand why not assume -rb if foo.buildinfo
> is given - I do understand for foo.changes…)

 - Because I'm not so sure that the user is aware that passing a .buildinfo
   file will mean that sbuild is querying snapshot.d.n without asking the user
   for further consent.

 - Because then we would only allow .buildinfo files that include the source
   package hash as well which I find quite limiting - especially considering
   how the Debian autobuilders will exclusively generate .buildinfo files of
   that kind

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #151 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 09:32:07 +0000

[Message part 1 (text/plain, inline)]

On Wed, Dec 21, 2016 at 08:14:23AM +0100, Johannes Schauer wrote:
> > as long as there's a short version of --rebuild-and-verify=foo.buildinfo
> > such as (for example) -rb=foo.buildinfo fine with me… :)
> the -r short option is still free.
 
sounds good.

> > (though I'm not sure I fully understand why not assume -rb if foo.buildinfo
> > is given - I do understand for foo.changes…)
> 
>  - Because I'm not so sure that the user is aware that passing a .buildinfo
>    file will mean that sbuild is querying snapshot.d.n without asking the user
>    for further consent.

what's the problem with that? (especially compared to downloading
packages from ftp.*.debian.org, which is also done…)

>  - Because then we would only allow .buildinfo files that include the source
>    package hash as well which I find quite limiting - especially considering
>    how the Debian autobuilders will exclusively generate .buildinfo files of
>    that kind

why? If I call "sbuild foo.buildinfo" and that .buildinfo file has no
source hashes, then sbuild should fail. Easy. (?!?!)

You seem to imply that the Debian autobuilders will generate .buildinfo
files without source hashes - I think *that* is a problem - how can we
fix it?


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #156 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Holger Levsen <holger@layer-acht.org>,

Cc: 774415@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 10:52:54 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Holger Levsen (2016-12-21 10:32:07)
> On Wed, Dec 21, 2016 at 08:14:23AM +0100, Johannes Schauer wrote:
> > > (though I'm not sure I fully understand why not assume -rb if
> > > foo.buildinfo is given - I do understand for foo.changes…)
> > 
> >  - Because I'm not so sure that the user is aware that passing a .buildinfo
> >    file will mean that sbuild is querying snapshot.d.n without asking the user
> >    for further consent.
> 
> what's the problem with that? (especially compared to downloading
> packages from ftp.*.debian.org, which is also done…)

because somebody who *does* care about this and uses their own local mirror
will have their setup subverted by this feature without any warning.

> >  - Because then we would only allow .buildinfo files that include the
> >  source package hash as well which I find quite limiting - especially
> >  considering how the Debian autobuilders will exclusively generate
> >  .buildinfo files of that kind
> 
> why? If I call "sbuild foo.buildinfo" and that .buildinfo file has no
> source hashes, then sbuild should fail. Easy. (?!?!)

Why should it then fail in your opinion?

Sure, it's easy to implement but I wonder if this restrictions makes sense. Why
do you think it does?

> You seem to imply that the Debian autobuilders will generate .buildinfo files
> without source hashes - I think *that* is a problem - how can we fix it?

Autobuilders only generate the arch:all and arch:any binary packages from the
source package they are given. They do not regenerate the source package. Thus,
they will call dpkg-buildpackage with --build=any or --build=all which in turn
will create a .buildinfo that doesn't contain the source hash.

If one tries passing --buildinfo-option=--build=full to dpkg-buildpackage then
this will lead to a build failure if dpkg-buildpackage was not also called with
--build=full. This makes sense on the level of dpkg-buildpackage because it's
possible to build binary packages without having the source package. But on the
autobuilder level the source package always exists. It would thus probably have
to be sbuilds job to mangle the buildinfo file and insert the source package
hash in it. But if you do that then you get to disparities between people
generating their buildinfo with sbuild/pbuilder and people who just use
dpkg-buildpackage...

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #161 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: [buildd-tools-devel] Bug#774415: From srebuild sbuild-wrapper to debrebuild

Date: Wed, 21 Dec 2016 09:58:39 +0000

[Message part 1 (text/plain, inline)]

Hi,

On Wed, Dec 21, 2016 at 10:52:54AM +0100, Johannes Schauer wrote:
> because somebody who *does* care about this and uses their own local mirror
> will have their setup subverted by this feature without any warning.

well, I (the user) feed it with a .buildinfo files, which needs old
versions. So I basically *ask* for snapshot.d.o to be used.

I'd *expect* that snapshot.d.o is being used!

> > why? If I call "sbuild foo.buildinfo" and that .buildinfo file has no
> > source hashes, then sbuild should fail. Easy. (?!?!)
> 
> Why should it then fail in your opinion?
 
because for rebuilding purposes, .buildinfo files without source hashes
are broken. (And as .buildinfo files are made for rebuilding, I'd say
.buildinfo files without source hashes are always broken.)

> Sure, it's easy to implement but I wonder if this restrictions makes sense. Why
> do you think it does?

Because I dont expect there are .buildinfo files without source hashes.

> > You seem to imply that the Debian autobuilders will generate .buildinfo files
> > without source hashes - I think *that* is a problem - how can we fix it?
> 
> Autobuilders only generate the arch:all and arch:any binary packages from the
> source package they are given. They do not regenerate the source package. Thus,
> they will call dpkg-buildpackage with --build=any or --build=all which in turn
> will create a .buildinfo that doesn't contain the source hash.

SIGH.

This is a *major* problem, I think.

> If one tries passing --buildinfo-option=--build=full to dpkg-buildpackage then
> this will lead to a build failure if dpkg-buildpackage was not also called with
> --build=full. This makes sense on the level of dpkg-buildpackage because it's
> possible to build binary packages without having the source package. But on the
> autobuilder level the source package always exists. It would thus probably have
> to be sbuilds job to mangle the buildinfo file and insert the source package
> hash in it. But if you do that then you get to disparities between people
> generating their buildinfo with sbuild/pbuilder and people who just use
> dpkg-buildpackage...

makes sense and sucks. Need to think more about this.


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #164 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org

Cc: reproducible-builds@lists.alioth.debian.org

Subject: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Tue, 01 Aug 2017 19:27:36 +0200

[Message part 1 (text/plain, inline)]

Hi,

this bug has been listed in the "NMU campaign" email on d-devel. But I wonder
how it ended up there. There are still open problems that are not answered, the
fix for this is still blocked by another bug (#802241) which is not on the NMU
list, and the code I wrote to fix the problem (debrebuild) is still waiting for
a maintainer.

So how did sbuild end up on the NMU list? I do not see what you want to NMU.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #167 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org, reproducible-builds@lists.alioth.debian.org

Subject: Re: sbuild: please add the srebuild sbuild wrapper to reproduce builds

Date: Tue, 1 Aug 2017 20:35:26 +0200

[Message part 1 (text/plain, inline)]

On Tue, Aug 01, 2017 at 07:27:36PM +0200, Johannes Schauer wrote:
> this bug has been listed in the "NMU campaign" email on d-devel.  But I wonder
> how it ended up there.

That's just an UDD query…  But I wonder whether this bug should be
tagged as "infrastructure" (which would have avoid it being listed)...

> fix for this is still blocked by another bug (#802241) which is not on the NMU
> list,

umh… that's weird, that one definitly should be in the list (even if
clearly we don't want to NMU dpkg!)

udd=> select * from bugs_usertags where id=802241;
                    email                    |    tag    |   id   
---------------------------------------------+-----------+--------
 reproducible-builds@lists.alioth.debian.org | toolchain | 802241
(1 row)

guess there is a bug in my SQL query (on top of the bug_list file
attached to the d-d mail)

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]

Message #174 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org, 802241@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Subject: Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

Date: Sat, 9 Jun 2018 20:12:33 +0000

[Message part 1 (text/plain, inline)]

Hi josch,

adding #774415 to to: and reply-to:…

On Fri, Jun 08, 2018 at 07:54:20PM +0200, Johannes Schauer wrote:
> > as I'm not an sbuild user (yet) myself, I was hesistant to try this
> > myself, so I'm confused now: does it work as it is now? (or does it need
> > changes to snapshot.d.o?)
> 
> yes, it does work as it is now.
> 
> Just supply the script with a buildinfo file to see it in action.
> 
> It does not require superuser privileges.
> 
> The script will query snapshot.debian.org to retrieve the right snapshot
> timestamp that contains all the package versions specified in the buildinfo
> file.
> 
> At the end of execution the script will print how to either reproduce the
> buildinfo manually via dpkg-buildpackage or how to run sbuild such that it does
> it for you.
> 
> People who know how to use pbuilder could easily add a section that outputs how
> to run pbuilder to do the same.
> 
> Naturally, instead of just printing how to use sbuild or pbuilder, the script
> could also be made actually run either.
> 
> The main two limitations of the script are:
> 
>  1. it will fail if there is not a single snapshot that contains all the right
>     package versions
> 
>  2. it will instruct sbuild/pbuilder to use the last stable release as the base
>     which might not allow upgrading to the right package versions
> 
> Both issues can be fixed by manually downloading exactly the required binary
> package set and creating a completely new chroot with exactly the required
> packages. But I didn't get around to doing that yet.

thank you very much for this nice summary!

As it sounds, I now believe this script would better live in
src:devscripts and as such I would like to reassign #774415 to
devscripts - or do you see any issue with that?


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #179 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org, 802241@bugs.debian.org, Holger Levsen <holger@layer-acht.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Cc: 774415@bugs.debian.org, 802241@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Subject: Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

Date: Sat, 09 Jun 2018 22:33:16 +0200

[Message part 1 (text/plain, inline)]

Quoting Holger Levsen (2018-06-09 22:12:33)
> As it sounds, I now believe this script would better live in src:devscripts
> and as such I would like to reassign #774415 to devscripts - or do you see
> any issue with that?

I see no issues with that from my side.

[signature.asc (application/pgp-signature, inline)]

Message #184 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Subject: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Sat, 9 Jun 2018 20:39:07 +0000

[Message part 1 (text/plain, inline)]

control: reassign -1 devscripts
control: retitle -1 devscripts: please add the srebuild wrapper for reproducible builds
thanks

On Sat, Jun 09, 2018 at 10:33:16PM +0200, Johannes Schauer wrote:
> Quoting Holger Levsen (2018-06-09 22:12:33)
> > As it sounds, I now believe this script would better live in src:devscripts
> > and as such I would like to reassign #774415 to devscripts - or do you see
> > any issue with that?
> I see no issues with that from my side.

ok :) 

thanks!


-- 
cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #195 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Johannes Schauer <j.schauer@email.de>

Cc: 774415@bugs.debian.org

Subject: Re: srebuild in devscripts

Date: Sat, 10 Nov 2018 23:03:19 +0100

Le 10/11/2018 à 22:55, Xavier a écrit :
> Hello,
> 
> I started to adapt srebuild.pl for devscripts:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/srebuild.pl
> 
> No big changes, just this:
>  - manpage in POD
>  - srebuild-hook embedded
>  - parameters
> 
> I have a little problem: srebuild search a "Build-Environment" field
> which seems to not exist anymore on https://buildinfo.debian.net files.
> Could you take a look ?

Just to replace it by "Installed-Build-Depends" ?

> Cheers,
> Xavier
> 

Message #200 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Johannes Schauer <j.schauer@email.de>

Cc: 774415@bugs.debian.org

Subject: srebuild in devscripts

Date: Sat, 10 Nov 2018 22:55:42 +0100

Hello,

I started to adapt srebuild.pl for devscripts:
https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/srebuild.pl

No big changes, just this:
 - manpage in POD
 - srebuild-hook embedded
 - parameters

I have a little problem: srebuild search a "Build-Environment" field
which seems to not exist anymore on https://buildinfo.debian.net files.
Could you take a look ?

Cheers,
Xavier

Message #205 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Xavier <yadd@debian.org>, 774415@bugs.debian.org

Cc: Johannes Schauer <j.schauer@email.de>

Subject: Re: Bug#774415: srebuild in devscripts

Date: Sun, 11 Nov 2018 13:26:36 +0000

[Message part 1 (text/plain, inline)]

On Sat, Nov 10, 2018 at 10:55:42PM +0100, Xavier wrote:
> I started to adapt srebuild.pl for devscripts:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/srebuild.pl
> 
> No big changes, just this:
>  - manpage in POD
>  - srebuild-hook embedded
>  - parameters

cool

> I have a little problem: srebuild search a "Build-Environment" field
> which seems to not exist anymore on https://buildinfo.debian.net files.
> Could you take a look ?

look at the very bottom of
https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/mpgrafic_0.3.15-1_amd64.buildinfo

it says:

Environment:
 DEB_BUILD_OPTIONS="buildinfo=+all reproducible=+all parallel=15"
 LANG="C"
 LC_ALL="C"
 SOURCE_DATE_EPOCH="1503091995"


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Message #210 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Xavier <yadd@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: srebuild in devscripts

Date: Sun, 11 Nov 2018 20:09:35 +0100

[Message part 1 (text/plain, inline)]

Hi Xavier,

thanks for working on this!

Quoting Xavier (2018-11-10 22:55:42)
> I started to adapt srebuild.pl for devscripts:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/srebuild.pl
> 
> No big changes, just this:
>  - manpage in POD
>  - srebuild-hook embedded
>  - parameters
> 
> I have a little problem: srebuild search a "Build-Environment" field
> which seems to not exist anymore on https://buildinfo.debian.net files.
> Could you take a look ?

the script that you used as a base for your work seems to have been written by
me in 2014. There is a much more recent version which (according to its git
history) is only one year old here:

https://salsa.debian.org/reproducible-builds/attic/debrebuild/blob/master/debrebuild.pl

It also doesn't have the problem with the (now) non-existing
"Build-Environment" field.

Please have a look whether you can use some of the things from debrebuild for
the version of srebuild that you are now maintaining in devscripts.

One advantage of debrebuild is, that it attempts to be builder agnostic.
Currently it can only be used for bare dpkg-buildpackage and sbuild but support
for pbuilder can be added by somebody who is familiar with the right command
line arguments.

Also for working with sbuild chroots of arbitrary snapshot timestamps, please
notice that sbuild features the "unshare" backend which allows unprivileged
users to create chroot tarballs if Linux user namespaces are enabled.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #215 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: srebuild in devscripts

Date: Sun, 11 Nov 2018 22:43:34 +0100

Le 11/11/2018 à 20:09, Johannes Schauer a écrit :
> Hi Xavier,
> 
> thanks for working on this!
> 
> Quoting Xavier (2018-11-10 22:55:42)
>> I started to adapt srebuild.pl for devscripts:
>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/srebuild.pl
>>
>> No big changes, just this:
>>  - manpage in POD
>>  - srebuild-hook embedded
>>  - parameters
>>
>> I have a little problem: srebuild search a "Build-Environment" field
>> which seems to not exist anymore on https://buildinfo.debian.net files.
>> Could you take a look ?
> 
> the script that you used as a base for your work seems to have been written by
> me in 2014. There is a much more recent version which (according to its git
> history) is only one year old here:
> 
> https://salsa.debian.org/reproducible-builds/attic/debrebuild/blob/master/debrebuild.pl
> 
> It also doesn't have the problem with the (now) non-existing
> "Build-Environment" field.
> 
> Please have a look whether you can use some of the things from debrebuild for
> the version of srebuild that you are now maintaining in devscripts.
> 
> One advantage of debrebuild is, that it attempts to be builder agnostic.
> Currently it can only be used for bare dpkg-buildpackage and sbuild but support
> for pbuilder can be added by somebody who is familiar with the right command
> line arguments.
> 
> Also for working with sbuild chroots of arbitrary snapshot timestamps, please
> notice that sbuild features the "unshare" backend which allows unprivileged
> users to create chroot tarballs if Linux user namespaces are enabled.
> 
> Thanks!
> 
> cheers, josch

Sadly http://reproducible.alioth.debian.org/debian/ doesn't exists
anymore and I can't find any Debian repository in
https://tests.reproducible-builds.org/debian
So now, I've some "cannot find base-files/9.9+deb9u5/amd64 in dumpavail"
Do you know any alternative to replace
http://reproducible.alioth.debian.org/debian/ ?

Message #220 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Xavier <yadd@debian.org>, 774415@bugs.debian.org

Cc: Johannes Schauer <josch@debian.org>

Subject: Re: Bug#774415: srebuild in devscripts

Date: Mon, 12 Nov 2018 10:08:51 +0000

[Message part 1 (text/plain, inline)]

On Sun, Nov 11, 2018 at 10:43:34PM +0100, Xavier wrote:
> Sadly http://reproducible.alioth.debian.org/debian/ doesn't exists
> anymore and I can't find any Debian repository in
> https://tests.reproducible-builds.org/debian

look at https://tests.reproducible-builds.org/debian/index_repositories.html
there you will find the repo lines you are looking for.


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Message #225 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Johannes Schauer <josch@debian.org>

Cc: Holger Levsen <holger@layer-acht.org>, 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Mon, 12 Nov 2018 21:43:14 +0100

Le 12/11/2018 à 11:08, Holger Levsen a écrit :
> On Sun, Nov 11, 2018 at 10:43:34PM +0100, Xavier wrote:
>> Sadly http://reproducible.alioth.debian.org/debian/ doesn't exists
>> anymore and I can't find any Debian repository in
>> https://tests.reproducible-builds.org/debian
> 
> look at https://tests.reproducible-builds.org/debian/index_repositories.html
> there you will find the repo lines you are looking for.

Thanks, seems to work now but needs to be tested more:
https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/debrebuild.pl

No changes for now, just update of repo and gpg key

Message #230 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Xavier <yadd@debian.org>

Cc: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Wed, 14 Nov 2018 17:25:24 +0000

[Message part 1 (text/plain, inline)]

On Mon, Nov 12, 2018 at 09:43:14PM +0100, Xavier wrote:
> Le 12/11/2018 à 11:08, Holger Levsen a écrit :
> > On Sun, Nov 11, 2018 at 10:43:34PM +0100, Xavier wrote:
> >> Sadly http://reproducible.alioth.debian.org/debian/ doesn't exists
> >> anymore and I can't find any Debian repository in
> >> https://tests.reproducible-builds.org/debian
> > 
> > look at https://tests.reproducible-builds.org/debian/index_repositories.html
> > there you will find the repo lines you are looking for.
> 
> Thanks, seems to work now but needs to be tested more:
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/debrebuild.pl

I just gave it a try:

$ git clone https://salsa.debian.org/yadd/devscripts
[...]
$ cd devscripts/
$ git checkout devscripts-srebuild 
$ wget https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/munin_2.0.42-5_amd64.buildinfo
[...]
$ perl scripts/debrebuild.pl munin_2.0.42-5_amd64.buildinfo 
debrebuild.pl: error: cannot fstat file ./munin-async_2.0.42-5_all.deb: No such file or directory

why does it need existing .debs in the current directory?

:)


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Message #235 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Holger Levsen <holger@layer-acht.org>

Cc: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Wed, 14 Nov 2018 19:30:44 +0100

Le 14/11/2018 à 18:25, Holger Levsen a écrit :
> On Mon, Nov 12, 2018 at 09:43:14PM +0100, Xavier wrote:
>> Le 12/11/2018 à 11:08, Holger Levsen a écrit :
>>> On Sun, Nov 11, 2018 at 10:43:34PM +0100, Xavier wrote:
>>>> Sadly http://reproducible.alioth.debian.org/debian/ doesn't exists
>>>> anymore and I can't find any Debian repository in
>>>> https://tests.reproducible-builds.org/debian
>>>
>>> look at https://tests.reproducible-builds.org/debian/index_repositories.html
>>> there you will find the repo lines you are looking for.
>>
>> Thanks, seems to work now but needs to be tested more:
>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-srebuild/scripts/debrebuild.pl
> 
> I just gave it a try:
> 
> $ git clone https://salsa.debian.org/yadd/devscripts
> [...]
> $ cd devscripts/
> $ git checkout devscripts-srebuild 
> $ wget https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/munin_2.0.42-5_amd64.buildinfo
> [...]
> $ perl scripts/debrebuild.pl munin_2.0.42-5_amd64.buildinfo 
> debrebuild.pl: error: cannot fstat file ./munin-async_2.0.42-5_all.deb: No such file or directory
> 
> why does it need existing .debs in the current directory?
> 
> :)

debrebuild seems to want to compare with old .deb (size ?)

Message #240 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: Xavier <yadd@debian.org>

Cc: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Wed, 14 Nov 2018 18:38:17 +0000

[Message part 1 (text/plain, inline)]

On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
> debrebuild seems to want to compare with old .deb (size ?)

it should not. it should compare with the hashes in the .buildinfo file.


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Message #245 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Holger Levsen <holger@layer-acht.org>

Cc: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Wed, 14 Nov 2018 19:39:49 +0100

Le 14/11/2018 à 19:38, Holger Levsen a écrit :
> On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
>> debrebuild seems to want to compare with old .deb (size ?)
> 
> it should not. it should compare with the hashes in the .buildinfo file.

I didn't modify script for now (except url update). I'm going to modify
it now.

Thanks

Message #250 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Xavier <yadd@debian.org>

To: Holger Levsen <holger@layer-acht.org>

Cc: Johannes Schauer <josch@debian.org>, 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Wed, 14 Nov 2018 20:04:02 +0100

Le 14/11/2018 à 19:39, Xavier a écrit :
> Le 14/11/2018 à 19:38, Holger Levsen a écrit :
>> On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
>>> debrebuild seems to want to compare with old .deb (size ?)
>>
>> it should not. it should compare with the hashes in the .buildinfo file.
> 
> I didn't modify script for now (except url update). I'm going to modify
> it now.
> 
> Thanks

Fixed, it works now but I don't understand the interest of this tool: it
gives just a command line to build...

It's really different than srebuild

Message #255 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Holger Levsen <holger@layer-acht.org>, Xavier <yadd@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Thu, 15 Nov 2018 09:13:41 +0100

[Message part 1 (text/plain, inline)]

Quoting Xavier (2018-11-14 20:04:02)
> Fixed, it works now but I don't understand the interest of this tool: it
> gives just a command line to build...
> 
> It's really different than srebuild

You are free to change a line that says:

print "sbuild --option1 --option2 --option3"

into a line that says:

exec "sbuild --option1 --option2 --option3"

If that is what you want the script to do. The reason the script in its current
form doesn't do that is because the script is supposed to work with multiple
builders. Some builders (dpkg-buildpackage and pbuilder) need sudo and since
the script is just a proof-of-concept I didn't want to write a script that does
anything with sudo and then potentially messes up the user's system as a
result. Thus, in its current state, the script only prints the commends that
the user is supposed to execute if they know what they are doing.

But if you feel confident, that you can run the whole script as root without
anything going wrong, feel free to change these "print" lines into "exec" lines
as I said before.

[signature.asc (application/pgp-signature, inline)]

Message #260 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Holger Levsen <holger@layer-acht.org>, Xavier <yadd@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Thu, 15 Nov 2018 09:22:08 +0100

[Message part 1 (text/plain, inline)]

Quoting Holger Levsen (2018-11-14 19:38:17)
> On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
> > debrebuild seems to want to compare with old .deb (size ?)
> 
> it should not. it should compare with the hashes in the .buildinfo file.

What the script is doing there in lines 183-187 is to make sure that the files
you already have match the hashes in the .buildinfo file. This is done, because
the mode of operation of the debrebuild script is to expect a .buildinfo file
together with build artifacts to exist (either downloaded from the archive or
as a result from a previous run of dpkg-buildpackage, pbuilder or sbuild) and
then you run debrebuild to check whether the files you got can be reproduced or
not. You now just removed these checks which makes the script quite useless. If
you don't want the check, then you also have to let the script do the first
build.

[signature.asc (application/pgp-signature, inline)]

Message #265 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Holger Levsen <holger@layer-acht.org>, Xavier <yadd@debian.org>

Cc: 774415@bugs.debian.org

Subject: Re: Bug#774415: srebuild in devscripts

Date: Thu, 15 Nov 2018 15:55:06 +0100

[Message part 1 (text/plain, inline)]

Quoting Johannes Schauer (2018-11-15 09:22:08)
> Quoting Holger Levsen (2018-11-14 19:38:17)
> > On Wed, Nov 14, 2018 at 07:30:44PM +0100, Xavier wrote:
> > > debrebuild seems to want to compare with old .deb (size ?)
> > 
> > it should not. it should compare with the hashes in the .buildinfo file.
> 
> What the script is doing there in lines 183-187 is to make sure that the
> files you already have match the hashes in the .buildinfo file. This is done,
> because the mode of operation of the debrebuild script is to expect a
> .buildinfo file together with build artifacts to exist (either downloaded
> from the archive or as a result from a previous run of dpkg-buildpackage,
> pbuilder or sbuild) and then you run debrebuild to check whether the files
> you got can be reproduced or not. You now just removed these checks which
> makes the script quite useless. If you don't want the check, then you also
> have to let the script do the first build.

Another thing that I fear might not have been obvious for others, so mentioning
it just in case: We already have the software called reprotest which just
builds a given source package twice and check if its reproducible. Debrebuild
is *not* supposed to be reprotest. So the *input* to debrebuild is an already
built source package together its buildinfo and then the package is built
again. Indeed it is not strictly necessary for the old build artifacts to exist
when one just wants a binary result (either reproducible/FTBR). But in
practice, if the package FTBR, then one wants to have access to the old
existing packages so that one can use it as input to diffoscope for inspection.

[signature.asc (application/pgp-signature, inline)]

Message #270 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 774415@bugs.debian.org, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Cc: Johannes Schauer <josch@debian.org>, Xavier <yadd@debian.org>, Santiago Torres Arias <santiago@nyu.edu>, kpcyrd <git@rxv.cc>, Steven Chamberlain <steven@pyro.eu.org>

Subject: re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Sun, 6 Oct 2019 19:02:38 +0000

[Message part 1 (text/plain, inline)]

hi,

so I thought I'd be bold and add the srebuild wrapper to src:devscripts
in git this weekend...

So I re-read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415
rather completly and noticed, that

- the branch devscripts-srebuild from https://salsa.debian.org/yadd/devscripts
  for a long time used the 2014 srebuild script from josch and was only
  'recently' based on the 2016 debrebuild script from josch.
  (The last 4 commits on this branch have all this history and thus are
  easy to grasp.)

- the NYU rebuilders OTOH use a by now quite modified version of the
  2014 srebuild script (with support for in-toto etc), see
  https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/blob/master/builder/srebuild

- the authoritive source/git repo for josch script(s) is the #774415 bug
  report? Or yadd's repo? ;)

- the 2016 debrebuild script doesn't do a rebuild by itself but produces
  a command which is to be run with sudo, so we need another wrapper
  here.

- there is also https://salsa.debian.org/reproducible-builds/attic/reprobuild/blob/master/repro-build.pl
  from Steven Chamberlain...

- for the sake of presenting a complete picture of this discussion I
  want to state that I also thought about packaging $name (srebuild,
  debrebuild, repro-build, whatever) as a seperate package, not part of
  devscripts. I've decided, at least for now, to first try to make it
  usable as part of the devscripts packages. Maybe however we want more
  configurability (like the in-toto support or other stuff which was
  added to NYU's srebuild fork) and this wont work in the long term.

- I think I'd like "something working most or even half the time"
  installable in Debian unstable by the end of the month. This is long
  overdue. (tm)
  (Only halfworking would be fine (for a start) for me cause there are
  quite some special cases, like binNMUs or support for unclean build
  envs or whatever.)

- I think I want(ed) to package the debrebuild script, as this is josch's
  reimplementation of the same problem. And I thought NYU had some
  patches on top of this and I was thinking to sort out this fork later
  (eg by making some of their features optional), but now I've seen that
  they forked the old srebuild script and I'm unsure what to do.

Comments, suggestions or any other feedback much welcome!


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Message #273 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: 774415@bugs.debian.org, Holger Levsen <holger@layer-acht.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>

Cc: Xavier <yadd@debian.org>, Santiago Torres Arias <santiago@nyu.edu>, kpcyrd <git@rxv.cc>, Steven Chamberlain <steven@pyro.eu.org>

Subject: re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Mon, 07 Oct 2019 14:49:27 +0200

[Message part 1 (text/plain, inline)]

Hi all,

Quoting Holger Levsen (2019-10-06 21:02:38)
> so I thought I'd be bold and add the srebuild wrapper to src:devscripts in
> git this weekend...

thanks for looking into this! :)

> So I re-read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415
> rather completly and noticed, that
> 
> - the branch devscripts-srebuild from https://salsa.debian.org/yadd/devscripts
>   for a long time used the 2014 srebuild script from josch and was only
>   'recently' based on the 2016 debrebuild script from josch.
>   (The last 4 commits on this branch have all this history and thus are
>   easy to grasp.)

Indeed. Why is checksum verification disabled in the last commit?

> - the NYU rebuilders OTOH use a by now quite modified version of the
>   2014 srebuild script (with support for in-toto etc), see
>   https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/blob/master/builder/srebuild

The original srebuild script suffered from many conceptional problems. I'd just
rebase their changes onto the new codebase. For a list of flaws in the original
script see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415#56

> - the authoritive source/git repo for josch script(s) is the #774415 bug
>   report? Or yadd's repo? ;)

My latest script is what you already saw in #774415.

> - the 2016 debrebuild script doesn't do a rebuild by itself but produces
>   a command which is to be run with sudo, so we need another wrapper
>   here.

Not necessarily. See:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415#255

> - there is also https://salsa.debian.org/reproducible-builds/attic/reprobuild/blob/master/repro-build.pl
>   from Steven Chamberlain...

Steven, which advantages does that script have over debrebuild.pl?

> - for the sake of presenting a complete picture of this discussion I want to
> state that I also thought about packaging $name (srebuild, debrebuild,
> repro-build, whatever) as a seperate package, not part of devscripts. I've
> decided, at least for now, to first try to make it usable as part of the
> devscripts packages. Maybe however we want more configurability (like the
> in-toto support or other stuff which was added to NYU's srebuild fork) and
> this wont work in the long term.

Is it not possible to have both and still have the script in devscripts?

> - I think I'd like "something working most or even half the time" installable
> in Debian unstable by the end of the month. This is long overdue. (tm) (Only
> halfworking would be fine (for a start) for me cause there are quite some
> special cases, like binNMUs or support for unclean build envs or whatever.)

Since the information about both is captured in the .buildinfo file,
debrebuild.pl should be able to handle those. Do you have a counter example?

> - I think I want(ed) to package the debrebuild script, as this is josch's
> reimplementation of the same problem. And I thought NYU had some patches on
> top of this and I was thinking to sort out this fork later (eg by making some
> of their features optional), but now I've seen that they forked the old
> srebuild script and I'm unsure what to do.
> 
> Comments, suggestions or any other feedback much welcome!

The srebuild script suffers from many problems (see above). I would advice
against using it in favour of debrebuild. If you want something that works
"most or even half the time" then I think that debrebuild is what you want.
Feel free to ask me if you have any questions about the script.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #276 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer <josch@debian.org>

To: Santiago Torres Arias <santiago@nyu.edu>

Cc: 774415@bugs.debian.org, Holger Levsen <holger@layer-acht.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, Xavier <yadd@debian.org>, kpcyrd <git@rxv.cc>, Steven Chamberlain <steven@pyro.eu.org>

Subject: Re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Mon, 07 Oct 2019 17:10:18 +0200

[Message part 1 (text/plain, inline)]

Hi,

Quoting Santiago Torres Arias (2019-10-07 16:58:58)
> On Mon, Oct 07, 2019 at 02:49:27PM +0200, Johannes Schauer wrote:
> > The srebuild script suffers from many problems (see above). I would advice
> > against using it in favour of debrebuild. If you want something that works
> > "most or even half the time" then I think that debrebuild is what you want.
> > Feel free to ask me if you have any questions about the script.
> On the rebuilder side, would this work as a drop-in replacement? how
> does it handle fetching dependencies from the debian archive and such?

it uses snapshot.debian.org to find the snapshot with the right packages and
then crafts either an sbuild command line that does the right thing or outputs
manual apt-get command that will install what is necessary. Pbuilder support
could be added but I do not understand enough pbuilder to know how to do that.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #281 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Santiago Torres Arias <santiago@nyu.edu>

To: Johannes Schauer <josch@debian.org>

Cc: 774415@bugs.debian.org, Holger Levsen <holger@layer-acht.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, Xavier <yadd@debian.org>, kpcyrd <git@rxv.cc>, Steven Chamberlain <steven@pyro.eu.org>

Subject: Re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Mon, 7 Oct 2019 10:58:58 -0400

[Message part 1 (text/plain, inline)]

Hello Everyone,
On Mon, Oct 07, 2019 at 02:49:27PM +0200, Johannes Schauer wrote:
> Copious snipping performed here
 
> The srebuild script suffers from many problems (see above). I would advice
> against using it in favour of debrebuild. If you want something that works
> "most or even half the time" then I think that debrebuild is what you want.
> Feel free to ask me if you have any questions about the script.
> 
On the rebuilder side, would this work as a drop-in replacement? how
does it handle fetching dependencies from the debian archive and such?

Cheers!
-Santiago

[signature.asc (application/pgp-signature, inline)]

Message #286 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Matt Bearup <mbearup@microsoft.com>

To: Santiago Torres Arias <santiago@nyu.edu>

Cc: Steven Chamberlain <steven@pyro.eu.org>, kpcyrd <git@rxv.cc>, Holger Levsen <holger@layer-acht.org>, "774415@bugs.debian.org" <774415@bugs.debian.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, Xavier <yadd@debian.org>

Subject: RE: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Mon, 7 Oct 2019 18:03:08 +0000

I have to second the issues with srebuild. We invested a lot of time to utilize this tool in our rebuilds but faced consistent build failures.
The best explanation I could find was that the snapshots referred to in the .buildinfo files had expired. That's not conclusive (the output wasn't clear on the cause of failure) nor is expired repo metadata the fault of srebuild per se. But the issue was nonetheless a blocker.
PBuilder is the most consistent build tool we've seen thus far, will have to investigate debrebuild as well.

Matt Bearup
Software Developer – CEH, CISSP, GCUX
Microsoft Azure  Compute Linux

-----Original Message-----
From: Reproducible-builds <reproducible-builds-bounces+jose.miguel=microsoft.com@alioth-lists.debian.net> On Behalf Of Johannes Schauer
Sent: Monday, October 7, 2019 8:10 AM
To: Santiago Torres Arias <santiago@nyu.edu>
Cc: Steven Chamberlain <steven@pyro.eu.org>; kpcyrd <git@rxv.cc>; Holger Levsen <holger@layer-acht.org>; 774415@bugs.debian.org; Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>; Xavier <yadd@debian.org>
Subject: Re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Hi,

Quoting Santiago Torres Arias (2019-10-07 16:58:58)
> On Mon, Oct 07, 2019 at 02:49:27PM +0200, Johannes Schauer wrote:
> > The srebuild script suffers from many problems (see above). I would 
> > advice against using it in favour of debrebuild. If you want 
> > something that works "most or even half the time" then I think that debrebuild is what you want.
> > Feel free to ask me if you have any questions about the script.
> On the rebuilder side, would this work as a drop-in replacement? how 
> does it handle fetching dependencies from the debian archive and such?

it uses snapshot.debian.org to find the snapshot with the right packages and then crafts either an sbuild command line that does the right thing or outputs manual apt-get command that will install what is necessary. Pbuilder support could be added but I do not understand enough pbuilder to know how to do that.

Thanks!

cheers, josch

Message #291 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Santiago Torres Arias <santiago@nyu.edu>

To: Matt Bearup <mbearup@microsoft.com>

Cc: Steven Chamberlain <steven@pyro.eu.org>, kpcyrd <git@rxv.cc>, Holger Levsen <holger@layer-acht.org>, "774415@bugs.debian.org" <774415@bugs.debian.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, Xavier <yadd@debian.org>

Subject: Re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Mon, 7 Oct 2019 14:49:19 -0400

[Message part 1 (text/plain, inline)]

Curious, was the srebuild the one as featured in the
debian-rebuilder-setup[1] repository or the upstream one?

I don't think we've faced much build issues on our side...

Cheers!
-Santiago

[1] https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup

On Mon, Oct 07, 2019 at 06:03:08PM +0000, Matt Bearup wrote:
> I have to second the issues with srebuild. We invested a lot of time to utilize this tool in our rebuilds but faced consistent build failures.
> The best explanation I could find was that the snapshots referred to in the .buildinfo files had expired. That's not conclusive (the output wasn't clear on the cause of failure) nor is expired repo metadata the fault of srebuild per se. But the issue was nonetheless a blocker.
> PBuilder is the most consistent build tool we've seen thus far, will have to investigate debrebuild as well.
> 
> Matt Bearup
> Software Developer – CEH, CISSP, GCUX
> Microsoft Azure  Compute Linux

[signature.asc (application/pgp-signature, inline)]

Message #296 received at 774415-quiet@bugs.debian.org (full text, mbox, reply):

From: "Spravce dane" <Jiri.Bartozka@alpskavyhlidka.cz>

To: <774415-quiet@bugs.debian.org>

Subject: Zmeny v zakone o danich z prijmu.

Date: Fri, 22 Nov 2019 13:30:42 +0200

[Message part 1 (text/plain, inline)]

Uprava od 12. 11. 2019

Danovy rad zasadne meni lhutu, ve ktere je mozne vymerit dan.

Nova uprava ovlivni termin k podani:

priznani k dani z prijmu
vyuctovani dane z prijmu vybirane srazkou
vyuctovani dane z prijmu ze zavisle cinnosti

Pokud drive podnikatel podal danove priznani se zpozdenim:

Nejnizsi pokuta podle § 250 danoveho radu pritom cini 800 Kc a nejvyssi 500 000 Kc.

Informace k novele zakona o danich z prijmu v priloze.


"Disclaimer: This e-mail contains privileged information or information belonging to Maharashtra State Power Generation Co. Ltd. and is intended solely for the addressee/s. Access to this email by anyone else is unauthorized. Any copying (whole or partial) or further distribution beyond the original recipient is not intended, and may be unlawful. The recipient acknowledges that Maharashtra State Power Generation Co. Ltd. is unable to exercise control or ensure or guarantee the integrity of the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and are not binding on Maharashtra State Power Generation Co. Ltd. E-mails are susceptible to alteration and their integrity cannot be guaranteed. Maharashtra State Power Generation Co. Ltd. does not accept any liability for any damages caused on account of this e-mail.If you have received this email in error, ! please contact the sender and delete the material from your computer."

[Dodatec c.3.doc (application/msword, attachment)]

Message #301 received at 774415@bugs.debian.org (full text, mbox, reply):

From: Matt Bearup <mbearup@microsoft.com>

To: Santiago Torres Arias <santiago@nyu.edu>

Cc: Steven Chamberlain <steven@pyro.eu.org>, kpcyrd <git@rxv.cc>, Holger Levsen <holger@layer-acht.org>, "774415@bugs.debian.org" <774415@bugs.debian.org>, Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>, Xavier <yadd@debian.org>

Subject: RE: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Date: Wed, 11 Dec 2019 01:29:44 +0000

Following up from the conference last week - yes we're using srebuild from debian-rebuilder-setup.

Thanks,

Matt Bearup
Software Developer – CEH, CISSP, GCUX
Microsoft Azure  Compute Linux

-----Original Message-----
From: Santiago Torres Arias <santiago@nyu.edu> 
Sent: Monday, October 7, 2019 11:49 AM
To: Matt Bearup <mbearup@microsoft.com>
Cc: Steven Chamberlain <steven@pyro.eu.org>; kpcyrd <git@rxv.cc>; Holger Levsen <holger@layer-acht.org>; 774415@bugs.debian.org; Reproducible Builds discussion list <reproducible-builds@lists.alioth.debian.org>; Xavier <yadd@debian.org>
Subject: Re: #774415: devscripts: please add the srebuild wrapper for reproducible builds

Curious, was the srebuild the one as featured in the debian-rebuilder-setup[1] repository or the upstream one?

I don't think we've faced much build issues on our side...

Cheers!
-Santiago

[1] https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup

On Mon, Oct 07, 2019 at 06:03:08PM +0000, Matt Bearup wrote:
> I have to second the issues with srebuild. We invested a lot of time to utilize this tool in our rebuilds but faced consistent build failures.
> The best explanation I could find was that the snapshots referred to in the .buildinfo files had expired. That's not conclusive (the output wasn't clear on the cause of failure) nor is expired repo metadata the fault of srebuild per se. But the issue was nonetheless a blocker.
> PBuilder is the most consistent build tool we've seen thus far, will have to investigate debrebuild as well.
> 
> Matt Bearup
> Software Developer – CEH, CISSP, GCUX
> Microsoft Azure  Compute Linux

Message #306 received at 774415-submit@bugs.debian.org (full text, mbox, reply):

From: "Tomas Petricek" <thais@ellonew.com>

To: <774415-submit@bugs.debian.org>

Subject: Fwd:fwd: Doplatek na ucet c.1 (01270-51332)

Date: Fri, 27 Dec 2019 11:47:28 +0200

[Message part 1 (text/plain, inline)]

Dobre odpoledne

Dle domluvy Vam posilam info ohledne doplatku.
vysi 8657.894 ,- Kc, kterou  prosim uhradte na nize uvedeny bankovni ucet
do 29.12.2019.

Informace o fakturaci prilohy.

S pozdravem,
Tomas Petricek
advokat/attorney at law
Opatovicka 1653/4, Praha 1

[faktura-23.12.2019_c.1 (01270-51334).doc (application/msword, attachment)]

Message #311 received at 774415-quiet@bugs.debian.org (full text, mbox, reply):

From: Petra Stoklasová <alexander@mongolia-altai-adventure.com>

To: <774415-quiet@bugs.debian.org>

Subject: Neuhrazené pohledávky. Dôvodová správa.

Date: Fri, 3 Jan 2020 10:55:43 +0200

[Message part 1 (text/plain, inline)]

Vážení,

Do dnešního dne jste nesplnili Vaši zákonnou povinnost a nevrátili mi zaplacenou finanční částku, kterou jste byli povinni mi vrátit.

Současně vás tímto upozorňujeme, že pokud k úhradě uvedené částky na základě této písemné výzvy dobrovolně nedojde, případně se ani neozvete, a to obratem, za účelem návrhu akceptovatelného řešení této situace, jsme připraveni se domáhat uvedeného nároku právní cestou, především pak podáním žaloby k místně příslušnému soudu prostřednictvím zvolené advokátní kanceláře.
 
 Dôvodová správa v příloze (zahrnuje fakturu a smlouvu).
 
 S pozdravem,
 Petra Stoklasová
 advokát/attorney at law
 Opatovická 1677/5, Praha 1

[Dôvodová správa č.1 (2137-0046).doc (application/msword, attachment)]

Message #314 received at 774415-submitter@bugs.debian.org (full text, mbox, reply):

From: Mattia Rizzolo <mattia@debian.org>

To: 774415-submitter@bugs.debian.org

Subject: Bug#774415 marked as pending in devscripts

Date: Thu, 30 Jan 2020 20:55:42 +0000

Control: tag -1 pending

Hello,

Bug #774415 in devscripts reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/devscripts/commit/bb5f21821e962baf8426533e7d2e558f1d2633b6

------------------------------------------------------------------------
Merge the `debrebuild` script from Johannes Schauer

Thanks also to yadd for the initial integration.

Closes: #774415
Signed-off-by: Mattia Rizzolo <mattia@debian.org>
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/774415

Message #321 received at 774415-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 774415-close@bugs.debian.org

Subject: Bug#774415: fixed in devscripts 2.20.1

Date: Fri, 31 Jan 2020 12:04:20 +0000

Source: devscripts
Source-Version: 2.20.1

We believe that the bug you reported is fixed in the latest version of
devscripts, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 774415@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mattia Rizzolo <mattia@debian.org> (supplier of updated devscripts package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Fri, 31 Jan 2020 12:10:18 +0100
Source: devscripts
Architecture: source
Version: 2.20.1
Distribution: unstable
Urgency: medium
Maintainer: Devscripts Maintainers <devscripts@packages.debian.org>
Changed-By: Mattia Rizzolo <mattia@debian.org>
Closes: 774415 933642 939538 941329 945267
Changes:
 devscripts (2.20.1) unstable; urgency=medium
 .
   [ Xavier Guimard ]
   * d/bug-script: fix return value if a file is empty.  MR: !148
   * Update French translation
 .
   [ Mattia Rizzolo ]
   * test/uscan:
     + Fixup and improve the httpserver cleanup functions to prevent
       stray process to persist at the end of the build.  Closes: #933642
     + Go back to use a real temporary file instead of a named pipe in
       chronic_sh.  This should also fix the Hurd FTBFS.
   * d/control:
     + Use an alternative dependency to pylint | pylint3, to supprt backports.
     + Bump Standards-Version to 4.5.0, no changes needed.
   * Make the Python code compliant with pylint-2.4.4.  Closes: #945267
   * grep-excuses:
     + Document the --autopkgtests option also in the --help.  Closes: #941329
   * debrebuild:
     + Add a new script that accepts a .buildinfo file as input and provides
       instructions on how to drive APT (and sbuild) to perform a rebuild.
       This script is still considered WIP, and its interface will likely
       change in the future.
       Thanks to Johannes Schauer for authoring the script.  Closes: #774415
 .
   [ Andrius Merkys ]
   * uscan:
     + Add support for direct access to Subversion repositories using a new
       mode=svn.  Closes: #939538; MR: !160
 .
   [ Hans Jerry Illikainen ]
   * reproducible-check:
     + Consider 'FTBR' as unreproducible.  MR: !169
 .
   [ Timo Furrer ]
   * mk-build-deps:  MR: !168
     + Document the DEB_BUILD_PROFILES environment variable.
     + Introduce a -P / --build-profiles option.
 .
   [ Ximin Luo ]
   * mk-origtargz:
     + Restore old behaviour that skips mk-origtargz when --no-symlink is given.
 .
   [ Nicolas Boulenguez ]
   * Improve reporting in case of --no-conf misuse for several tools.  MR: !163
Checksums-Sha1:
 648e2032c32db486bf8693d37642fc2717eca2e6 3171 devscripts_2.20.1.dsc
 18a359d77ac205b2a34dbcd37cd7a0639e7d3344 854932 devscripts_2.20.1.tar.xz
 9918fde7937c3257746e610678318bc75820f776 12515 devscripts_2.20.1_amd64.buildinfo
Checksums-Sha256:
 8535623ecbe2558e62ac11b4c9f7315ec0e05de7815ffe7e0a05c34cc66b3429 3171 devscripts_2.20.1.dsc
 22459e6ee23e0def9453202814069c6096ede53fbd72abfa2c5d4998d3a5917b 854932 devscripts_2.20.1.tar.xz
 724c31f476845941b13b4240c82a6394ea8ad426b82af58dce54570408052009 12515 devscripts_2.20.1_amd64.buildinfo
Files:
 3466cc2fb6e2418dd3d05690c3e0998c 3171 devel optional devscripts_2.20.1.dsc
 4eef195b60b3b8837734240a5f511971 854932 devel optional devscripts_2.20.1.tar.xz
 f5628f37b16fa7e32190b43d34745665 12515 devel optional devscripts_2.20.1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEi3hoeGwz5cZMTQpICBa54Yx2K60FAl40EQEACgkQCBa54Yx2
K63vlQ/+KTmcDLAJRNRupBhAhnbqfjPfeNiHjuUSMw6YJqiapIkYbSkls3pgmDw3
ewuD6+ONY5debP9EnuCRbfJxCdIBrBlPTq9KeijAPkLm5TZBHkBulTsT+Yv/Lbbx
ALcE19K5bHdJLIuWnzdanw72tVcopAjULE4aeIk99TLScscLlg0Mw+Pjm5gh9oSQ
mWgmhM9I0Q/UUgB+OWr7ecN0F1QZtU2AvKdD2zotzL/m95CSU9lF3oKk43IHhoCW
GzC+F88QB7a6SRaAYU0h7CYwiEEDhgV6fl26/ZWFJYfKX16f6StmaXcnEkSSiLT/
a3ntQ0O0QQPXxFuG1+zE9Jn7Q7Uc3YzLCmklKqnpCwT72NyaJHpUWh9yAabN/mhJ
att9FTS1x6xJjaeidyUkvTBEv4c251yHi4St42gbjTBEOpwOchpGA1oTPPvd/7iw
57GZvOnRIt0z1yvC5xa3Xdc2/v6aHzV9+/thIG+0DIVrmZeYa/lzD/Y1htYnDYEM
cOgoRFY8lYrcACTLnT0wFztTMQ9wVhMIg4aW4Di7t09upV+eCq4+/1jVpuC/dceR
CyhoueotiaFxgaVRmqUQ5dTnk8hAmWh36UMIlBKst1bs1gdZUfUT+aSPSMECpYDO
1r4awfOetaJY7JoP26IbCOIUYE39JsKBKuvS+er6fbDH0yDup/I=
=x/29
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.