From: David Ward on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/issues/39#note_547939066 Sorry if I am misunderstanding something. I was saying that for `kernel-5.12.0-0.rc6.20210408git454859c5.186` we should make the date (`20210408`) correspond to the upstream commit (`454859c5`). If we use the date that the Makefile is run, that is not reproducible behavior. It affects the filenames of source tarballs (which have to be generated), along with the package NVR itself. You mentioned using the date to distinguish changes in dist-git that are independent of the upstream source. My comment was that we should being use `<N>` for that, not the snapshot date. A major reason is that the date might not even be in the NVR to begin with (which is expected). For example: - kernel-5.11.0-155 - kernel-5.11.0-156 - kernel-5.11.0-157 - kernel-5.11.0-158 can only be distinguished by `<N>`. Similarly, I am suggesting we should be using `<N>` to distinguish these tags (from the last cycle), where dist-git changed but the upstream sources did not: - kernel-5.11.0-0.rc5.20210130git0e9bcda5.139 - kernel-5.11.0-0.rc5.20210131git0e9bcda5.140 If I rebuild from those tags on my local system today, and make no modifications, it would generate packages named - kernel-5.11.0-0.rc5.20210408git0e9bcda5.139 - kernel-5.11.0-0.rc5.20210408git0e9bcda5.140 which does not reproduce the earlier behavior. (If I make any local changes, I should set the BUILDID or somehow tag the package differently.) Is that reasonable? Am I overlooking something? _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure