Re: Fedora kernel workflow feedback
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@lists.fedoraproject.org/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@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora kernel workflow feedback
On Fri, Apr 17, 2020 at 10:06:02PM +0200, Thorsten Leemhuis wrote: > Hi Don! > > Am 17.04.20 um 20:55 schrieb Don Zickus: > > > > I know as Jeremy and Justin have rolled out changes recently there have been > > > concerns over technical and non-technical issues. While they are happy to > > > make various tweaks to the workflow that might have broken during the > > > conversion, I am asking for some of the bigger concerns, folks reach out to > > > me. > > FWIW from the perspective of someone that deals with kernel.spec in his > spare time occasionally I think the conversation worked mostly well. Thx > for that. A bit of fine tuning might be needed here and there, but well, > that's often the case in situations like this :-D > > > I am sure there are pieces we overlooked in our attempt to change the > > workflow and over the next few months we will try to address what makes > > sense. I just ask folks to redirect their concerns to me and work with us > > to get them resolved. > > > > The two concerns I am aware that need addressing are: > > * broken out patches > > Which is already in the works (thx again Jeremy!) > > > * handle drive-by users who know dist-git by not the source git tree > > A few additional comments in the spec file and the readme that Jeremy > proposed will take care of most of it afaics. And one more thing, see > next part of this reply. > > > 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/ > It sounds like maybe there's confusion about what the new tarball contains. The tarballs that are generated and checked into dist-git contain no Fedora modifications and are directly from a commit or tag Linus's git tree generated with git-archive[0]. The only thing that changed is before we took the latest tagged release, then applied an rc patch from upstream if available, then the snapshot from that week's development as a patch generated on the maintainer's machine, then applied Fedora-specific patches. Now we just git-archive Linus's master branch for the day. We can download the tarball (created by git-archive on a signed tag) from kernel.org instead of running git-archive on a signed tag ourselves if that will really help people sleep at night, but we'll still be slapping unsigned snapshots on top of that so it's not clear to me that we'll be gaining much. [0] https://gitlab.com/cki-project/kernel-ark/-/blob/internal/redhat/scripts/create-tarball.sh - Jeremy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
