On Sat, Apr 18, 2020 at 02:35:24PM +0200, Thorsten Leemhuis wrote: > Just a quick clarification: > > Am 17.04.20 um 22:06 schrieb Thorsten Leemhuis: > > Am 17.04.20 um 20:55 schrieb Don Zickus: > > >> Is there any other large concern with the new workflow? > > > > The more I think about this the more I dislike that we are not using > > official, pristine tarballs anymore. This "Source0 is a tarball > > generated from a git tree maintained outside of the Fedora infra and > > patched with buildscripts" IMHO violates the intention of the SourceURL > > part of the Fedora Packaging Guidelines that was put in place for good > > reasons (by both red hat and community contributors): > > https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ > > > > This can be fixed afaics, as it was already discussed in this mail and > > the answer to it: > > https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx/thread/I2JXHKX3P4EIRXGRU7JRY33EBQRCLRI4/#IBRZXHKW72PNN7USTJJHPCQQZJAVOEMD > > > > Yes, it will be some work, but I think it would be wise to do that "to > > cleanly separate upstream source from vendor modifications" (that's a > > quote from the guidelines). > > Note: What I wrote might sound like I want to stick to tarballs forever. > That is not the case, I only would prefer something where all vendor > modifications are clearly separated from the sources upstream released > (which was the case for the kernel.spec until a few days ago). IOW: I'm > totally fine if RPM and/or Dist-Git learn to understand source URLs that > download sources from a signed tag somehow (say: "Source0: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/snapshot/linux-5.7-rc1.tar.gz" > – which is a bad example, as that is a tarball again, but you get the idea). Hi knurd, Thanks for the feedback! I believe we would like to work out a solution for this. But as Jeremy and Laura (in your reference thread) pointed out, there are multiple ways to solve this. It comes down to what is a reasonable and comfortable approach for the community. Signed tags could work, but they are only applied to releases, not the -rcX updates. So there is limitation to that. Looking through the Fedora Doc you posted, they seem to provide examples of using a git commit for reference (despite kernel.org using tarballs). In essence that is what we are doing, using more of the upstream commit and generating our own tarball from that commit. Obviously, the problem comes down to trust. Just trying to figure out the most reasonable way to prove we didn't make any mistakes when generating the tarball using the tools we have available. Thoughts? Cheers, Don _______________________________________________ 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