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

Johannes Schauer josch at debian.org
Mon Oct 7 13:49:27 BST 2019


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20191007/e10e5fb6/attachment.sig>


More information about the Reproducible-builds mailing list