Justin, many thx for your detailed answer. On 14.02.22 19:14, Justin Forbes wrote: > On Mon, Feb 14, 2022 at 5:15 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: >> >> On 12.02.22 06:21, Neal Gompa wrote: >>> On Fri, Feb 11, 2022 at 11:25 AM Justin Forbes <jforbes@xxxxxxxxxx> wrote: >>>> On Fri, Feb 11, 2022 at 8:07 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: >>>>> On 08.02.22 20:24, Donald Zickus wrote: >> My problem: with SRPMs it's easy to do this for thousands of packages in >> Fedora without known anything about the particular package: >> >> - verify the sources are pristine >> - update to a newer version >> - add or remove patches >> Kernel-ark broke all that from where I stand: >> >> - the sources included in kernel.spec don't match upstream and it's not >> obvious from reading the spec file how to verify them > > The source matches upstream in that they are a tarball made from > linus' branch (and nothing else). While we did previously download and > verify the signature of a tarball from kernel.org for actual releases, > the rc patches and such were generated from git before as well. As > kernel.org does use signatures for releases, you can verify those > signatures in our clone just the same. Using git log > --show-signature' will show you the signatures on commits if they > exist. How about adding a short comment to the spec file explaining this, otherwise it might look suspicions for people not familiar with kernel-ark/git. >> - if you want to manually update stable kernel.spec from say 5.16.5 to >> 5.16.6 you now have to modify the version number in iirc *four* >> different places; this like that would never pass a package review in >> Fedora. And even if you did that: then you still have to deal with the >> kabi stuff, which is not of interest for Fedora either iirc. > > This is somewhere that definitely needs improvement, but it has not > made it up on my priority list. More importantly, changing a release > should not change the sources required. Yeah. And yes, it's not urgent, but these small annoyances are likely among the reasons why I haven't come on good terms with kernel-ark yet. :-/ >> - building a near vanilla kernel that still applied patches needed to >> get things things building (like the gcc12 patches in rawhide recently) >> used to be pretty easy, now it's hard (as can be seen by the mailing >> list post about this a few days ago; I had trouble as well, but was able >> to deal with them myself) > > This is an issue we are working to address. Right now, if things are > building in rawhide, and not for you, the best bet is to look for > merge requests labeled "Include in releases" The hope is to get these > types of patches merged quickly now, though in the gcc12 case, there > was some discussion upstream and both of those patches have gone > through revisions, one as recently as yesterday. > https://gitlab.com/cki-project/kernel-ark/-/merge_requests?scope=all&state=opened&label_name[]=Include%20in%20Releases Many thx for working on this. >>> If we're going to have RHEL configs in kernel-ark (remember, "ark" is >>> really "rhel"), would other downstream configs be allowed? Can the >>> testing apparatus be extended to build and test them? How far can we >>> go here? > Every set of configs is another list of things that take time to > process, require care and feeding to maintain, and must be reviewed > and set. I don't see any value in adding too many additional > downstream configs. The mechanism already exists with > config-overrides to maintain separate configs in a branch, and it is > not particularly difficult to add another set of configs without > overrides. I am looking to drop configs (i686, armv7), not add more. BTW, what also would help a lot from my side to get on better terms for kernel-ark: some more (a lot more?) and better documentation for kernel-ark, as things like that (or the "include in releases" tag) are hard to find for outsiders. It afaics would also be helpful to have some more docs for Fedora users (in the Fedora wiki?) that need/want to do fiddle with the kernel somehow, for example adding or removing a patch to test something. >>>> While there is a defined workflow, there are improvements being made >>>> over time, and we are still looking at places the current process can >>>> be improved. This is why the thread was started. Is the mailing list >>>> interaction where it should be from an automation point of view? Are >>>> we sending too much? Not enough? >> >> Not sure. I for one missed that you added patches to make gcc12 builds >> work. Did I miss them in the noise (then some tags might help to >> distinguish RHEL and Fedora specific stuff -- or do we have those?) or >> are those patches not mentioned on the list when they get applied (I >> would like that, but maybe that's just me)? > > There should be no fedora specific patches, Sorry, you are of course right, poorly expressed myself here. > the GCC bits apply to > both. All gcc patches were delivered to this list at the time that > the MRs were opened. [...] Yeah, then I missed them, which brings us back to the "Are we sending too much? Not enough?" part, as I have a better answer to it now: The amount of mail itself is not a problem for me, but a lot of them afaics are irrelevant for users like me that mainly care about Fedora. Those mails thus create a noise in which I easily miss the things I'm interested in. Hence for me it would be helpful if RH/CentOS specific things like "Sync support status with RHEL9 and updates to new messaging", "configs: enable LOGITECH_FF for RHEL/CentOS too", or "Add Partner Supported taint flag" could be tagged for local filtering or get sent to a entirely different list. Anyway, thx again for your reply. Ciao, THorsten _______________________________________________ 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
