Re: Build system clocks?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 7, 2023 at 11:11 PM Elliott Sales de Andrade
<quantum.analyst@xxxxxxxxx> wrote:
>
> On Sun, May 7, 2023 at 4:59 PM Chris Adams <linux@xxxxxxxxxxx> wrote:
>>
>> Once upon a time, Kevin Kofler <kevin.kofler@xxxxxxxxx> said:
>> > Chris Adams wrote:
>> > > I updated the source of a package of mine last night.  The upstream is
>> > > on Github, and I use the %forgemeta macro for an easy spec file.  When I
>> > > tried to run "fedpkg build" though, it failed - the build system
>> > > rejected the build because it was expecting an SRPM with a release
>> > > string including 20230507, but instead got one with 20230506.
>> >
>> > Could it be that you built the package over midnight UTC, so the SRPM was
>> > still built with 20230506, but when the build happened, it was already
>> > 20230507?
>>
>> It wasn't that, I tried it several times.  Also, the forge macro is
>> using the timestamp of the source file, not the wall clock (so the
>> system clock being wrong wouldn't have caused it either).
>>
>
> It uses the timestamp of the source file, but are those timestamps the same? When you download from the forge, the timestamp on the file will be the time that you downloaded it. When you upload to the lookaside cache, the timestamp will be for when it was put there, but your local file has not changed. When fedpkg or koji download from the lookaside cache, it will copy the timestamp from it for reproducibility.
>
> However, if the file already exists, fedpkg won't touch it. I suspect if you delete the tarball and have fedpkg download it again, everything will appear consistent again.

Yeah, the way the forge macros determine "snapshot date" is a bit
broken / produces inconsistent results.
It uses the source file *modification time* ("mtime"), which might or
might not be consistent in all environments ... it's also an attempt
to get the "date the snapshot was taken" (not the "date the specified
commit was committed") which always seemed a bit misguided to me, but
what do I know :)

Anyway, those are the reasons why - back in the days when I did more
Go packaging - I added a way to override the date with a fixed value
to make the "Release" tag reproducible when using the %forge macros.

(Side note: The %forge macros don't even follow the new Versioning
guidelines for snapshots - i.e. using caret and tilde - which puts the
snapshot info into the "Version" tag instead of the "Release" tag ...
but I'm not sure if anybody is still around who could fix that.)

Fabio
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux