On Thu, Feb 05, 2015 at 02:38:04PM +0100, Holger Levsen wrote: > Hi Holger, > > nice to see reproducible builds moving forward :-)
Glad to hear interest in the project!
And thanks for taking care about reproducibility of your packages! :)
> Are there plans to check experimental, too?
There are.
What's missing is a patch to our infrastructure :)
We'll eventually do it, of course!
> Anyway, I had to try your toolchain on some of my packages (e.g.
> non-free stuff not that easily coverable) - I don't like these red
> things in my ddpo page
>
> * after fixing the timestamps in a kernel module source tarball, the
> file order has changed ... I didn't see a corresponding issue in the
> Wiki to make that deterministic (underlying filesystem is a tmpfs)
File order where?
BTW, underlying file system is not relevant here.
> Curious as I was, I wanted to do a bit more extreme testing, running the
> first pbuilder build with --twice, but that resulted in differing
> timestamps for the debian/ directory in the .debian.tar.xz tarball
> (possible explanation: the initial timestamp of the directory was before
> the changelog timestamp, so it didn't get updated during the first
> dpkg-source -b, but after the first build the directory timestamp was
> updated (since stuff has been created and deleted), so it got reset to
> the changelog stamp in the second dpkg-source -b)
> maybe setting the debian/ dir mtime to the changelog stamp always?
> (should capture most of the reproducible --twice issues)
not sure about this, but your explanation makes sense.
Anyway, we do the test with two different calls to pbuilder, where we set
differents env variables, use unshare and the like.
I don't think that pbuilder --twice (where the package is built twice from the
same unpacked source) is a valuable testbed.
> * in beignet I have an unreproducible .pch (precompiler header) file -
> any hints on what could be going on here? (although I'm more interested
> in testing the experimental respectively pending-in-git version)
Not from me, sorry.
> some remarks regarding rebuild.sh (I don't use it since it does not fit
> my pbuilder setup, just took some ideas from it)
>
> * you could use --buildresult b1/b2 and avoid copying the buildresult
> around manually
I think the same.
Holger, we are doing something similar in the jenkins script, but I don't get
why.
(+ I don't quite like the structure of reproducible_build.sh, but I know you ♥
patches, so ^^)
> * is it intentional to have --debbuildoptions -b enabled?
> the first "bug" I fixed was the doxygen timestamps in libvdpau-doc, i.e.
> an arch:all package ...
from dpkg-buildpackage(1):
-b Specifies a binary-only build, no source files are to be built and/or
distributed
Maybe you are confusing with -B, that builds arch-dep binary packages.
> * we should really patch pbuilder to add a --nocheck option :-)
? not checking what?
--
regards,
Mattia Rizzolo
GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
signature.asc
Description: Digital signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
