Jérémy Bobbio wrote:
> Hans-Christoph Steiner:
>> I've been using faketime in my work on reproducible builds on Android (both
>> "native" C code and Java), and it has been working well.  It seems to me that
>> the current approach in Debian does not use faketime.
>> Since so much of the little issues are due to timestamps, it could make a lot
>> of sense if faketime was a default part of the process.  For the make+C 
>> builds
>> I've done, faketime just froze the clock entirely and that worked.  For
>> ant+java builds, it would hang forever with a frozen clock.  So I set 
>> faketime
>> to run the clock at 5% speed, and that seems to work well.
> Before getting into any technical details, let's start by the social
> problem. We are talking about Debian (and derivatives!). There is no
> canonical way a Debian package is built. Most developers will, for
> example, use `fakeroot`, but it's optional and `sudo` is also supported.
> To reproduce builds using libfaketime, you need both the original build
> and the later builds to use libfaketime. Requiring that every Debian
> developers uses libfaketime when building a package is a change that
> would be very hard, if not impossible, to achieve.
> For the most important technical problem: libfaketime cannot make the
> build process entirely deterministic. According to my tests, parallel
> execution, variations in file order, and randomness can all participate
> in making the faked times different from one build to the next.
> While experimenting in my little corner, I also saw several build
> systems just fail, or fail to be reproducible with libfaketime. That's
> what actually led me to remove the time fixing feature of the
> `test-reproducibility` script entirely:
> https://anonscm.debian.org/cgit/reproducible/misc.git/commit/?id=f4146ee73d
> I really would love to have it back, but it simply could not be made to
> work reliably under my fingers.
> There's a consensus that libfaketime is not the good approach for
> reproducible builds since the initial BoF during DebConf13. Patching
> timestamps is a harder path, but we know there's not going to be a
> hidden cliff in the middle of the journey.

Thanks for the explanation, that's a bummer that it was so problematic, but I
suppose not surprising.  Would it make sense to have something like a "dh
--use-faketime" flag so that maintainers could opt-in to use it where it might
be helpful like when upstream refuses to remove build stamps, etc?  The idea
there would be that dh would handle setting up faketime before the upstream
build system was called.  In that case, a flag to dh would be a lot less work
to maintain then a set of patches.


PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

Reproducible-builds mailing list

Reply via email to