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

[Ximin Luo]

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.
> 

Thank you! The behaviour specifically for glibc_2.24-5 is like this:

make[2]: Warning: File 'o-iterator.mk' has modification time 18411205 s in the future
running CONFIG_SHELL=/bin/bash /bin/bash /tmp/debrepro.afKzxbwOYw/build/source/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --enable-add-ons=libidn, --without-selinux --enable-stackguard-randomization --enable-obsolete-rpc --with-pkgversio
n=Debian GLIBC 2.24-5.1 --with-bugurl=http://www.debian.org/Bugs/ --with-headers=/tmp/debrepro.afKzxbwOYw/build/source/debian/include --enable-kernel=2.6.32 --with-selinux --enable-multi-arch --enable-lock-elision build_alias=x86_64-linux-gnu host_alias=x86_64-linux-
gnu CC=x86_64-linux-gnu-gcc-6 CPPFLAGS=-isystem /tmp/debrepro.afKzxbwOYw/build/source/debian/include CXX=: --no-create --no-recursion

[... runs some tests ...]

make[2]: Warning: File 'o-iterator.mk' has modification time 18411180 s in the future
running CONFIG_SHELL=/bin/bash /bin/bash /tmp/debrepro.afKzxbwOYw/build/source/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --enable-add-ons=libidn, --without-selinux --enable-stackguard-randomization --enable-obsolete-rpc --with-pkgversio
n=Debian GLIBC 2.24-5.1 --with-bugurl=http://www.debian.org/Bugs/ --with-headers=/tmp/debrepro.afKzxbwOYw/build/source/debian/include --enable-kernel=2.6.32 --with-selinux --enable-multi-arch --enable-lock-elision build_alias=x86_64-linux-gnu host_alias=x86_64-linux-
gnu CC=x86_64-linux-gnu-gcc-6 CPPFLAGS=-isystem /tmp/debrepro.afKzxbwOYw/build/source/debian/include CXX=: --no-create --no-recursion

[... runs the same tests again ...]

[... etc ...]

It would probably be theoretically possible to reduce this to a minimal test case, but based on previous things I was told about make, I'm not sure if it's worth the effort. You might also try increasing the timestamps of all the source files in the second build by the same amount, but again I'm not sure it's worth the effort.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git