Bug#846365: debrepro: warn about faketime and allow alternative values

[Antonio Terceiro]

On Thu, Dec 01, 2016 at 11:39:00AM +0000, Ximin Luo wrote:
> Antonio Terceiro:
> > On Wed, Nov 30, 2016 at 07:11:00PM +0000, Ximin Luo wrote:
> >> Antonio Terceiro:
> >>> On Wed, Nov 30, 2016 at 05:52:04PM +0100, Ximin Luo wrote:
> >>>> Package: devscripts
> >>>> Version: 2.16.10
> >>>> Severity: normal
> >>>> Tags: patch
> >>>>
> >>>> Dear Maintainer,
> >>>>
> >>>> Running debrepro on glibc causes an infinite loop in the second build (13
> >>>> days+ build before I interrupted it). I didn't yet figure out the root cause
> >>>> of this in the glibc buildscripts, but faketime causing problems like this is
> >>>> a known issue with it, and people are not really expected to work around it.
> >>>>
> >>>> So debrepro should at least document this, and ideally make it possible to
> >>>> disable the time variation or do something else for it. For example, I could
> >>>> make the glibc build work by instead using:
> >>>>
> >>>>   vary 'fakeroot debian/rules binary' \
> >>>>     'faketime "@$SOURCE_DATE_EPOCH" fakeroot debian/rules binary'
> >>>
> >>> the current version is not calling debian/rules directly anymore, nor has
> >>> $SOURCE_DATE_EPOCH. it looks like this:
> >>>
> >>>   vary 'dpkg-buildpackage -b -us -uc' \
> >>>     'faketime +213days+7hours+13minutes dpkg-buildpackage -b -us -uc'
> >>>
> >>> can you please make sure you are running the latest version, and if so, let me
> >>> now if it still doesn't work for you?
> >>>
> >>
> >> Hi Antonio, the bug is about the +213days value, so based on what you
> >> described it would still exist in the new version. I will test it
> >> again to confirm, but this will take a few more days.
> >>
> >> The suggested fix is to use a value that is in the past instead of the
> >> future, but still after the latest entry in d/changelog. One doesn't
> >> have to set SOURCE_DATE_EPOCH, merely calling dpkg-parsechangelog
> >> would be fine.
> > 
> > Can you try this instead:
> > 
> > future=$(date -d '+213days+7hours+13minutes' +%s)
> > faketime "@$future" dpkg-buildpackage -b -us -uc
> > 
> 
> Hi Antonio, why do you think this would have a different effect?
> Everything that `man faketime` says indicates that all the 3 options
> that you described would behave identically. Nevertheless, I am
> testing it now, but I think you are wasting time here.
> 
> I told you already, faketime has known problems like this. It is
> perfectly expected that this +213 days value will cause something to
> break. That is why we don't just add it to dpkg-buildpackage and say
> "everything is reproducible" already. If for some magical reason it
> turns out it is not at fault here for glibc, it will still cause
> something *else* to break in the future. So an option to disable it is
> prudent.

I was just trying do understand the issue and not willingly wasting your
time. I assumed that somehow the issue could be on how the timestamp is
passed to faketime, since your original suggested fix did just that.

I guess I will add an option to skip any of the variations, as well as a
way to specify which timestamp to use for the second build. I can even
add options to override the values used for all other variations, let's see.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20161201/9875598f/attachment-0001.sig>