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