Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
Regards, Jeremy
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
This looks like it will completely remove the need for https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
Is that correct? (Please let it be correct.)
josh
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
Regards, Jeremy
kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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
On Wed, 2020-03-11 at 12:58 -0400, Josh Boyer wrote:
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
This looks like it will completely remove the need for https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
Is that correct? (Please let it be correct.)
Eventually, yes. To start with we're just going to do Rawhide this way, but assuming things go well handling stable releases the same way should be straight-forward.
josh
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
Regards, Jeremy
kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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
On Wed, Mar 11, 2020 at 1:21 PM Jeremy Cline jeremy@jcline.org wrote:
On Wed, 2020-03-11 at 12:58 -0400, Josh Boyer wrote:
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
This looks like it will completely remove the need for https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
Is that correct? (Please let it be correct.)
Eventually, yes. To start with we're just going to do Rawhide this way, but assuming things go well handling stable releases the same way should be straight-forward.
Great. Please let me know when I can stop generating that tree.
josh
On Wed, Mar 11, 2020 at 1:26 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, Mar 11, 2020 at 1:21 PM Jeremy Cline jeremy@jcline.org wrote:
On Wed, 2020-03-11 at 12:58 -0400, Josh Boyer wrote:
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
This looks like it will completely remove the need for https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
Is that correct? (Please let it be correct.)
Eventually, yes. To start with we're just going to do Rawhide this way, but assuming things go well handling stable releases the same way should be straight-forward.
Great. Please let me know when I can stop generating that tree.
So, that tree is now officially stopped for the rawhide branch. The changes in the NVR broke the script that explodes and rebuilds it, and I'm not going to invest any time to fix it. I'll keep it running for the stable branches until those are converted too.
josh
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
I don't think that's actually acceptable under Fedora guidelines, as that violates the canonicity rule on the sources and spec[1].
Have you already worked out how to deal with that yet?
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance...
-- 真実はいつも一つ！/ Always, there's only one truth!
Hi Neal,
On Thu, 2020-03-12 at 06:21 -0400, Neal Gompa wrote:
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
I don't think that's actually acceptable under Fedora guidelines, as that violates the canonicity rule on the sources and spec[1].
Have you already worked out how to deal with that yet?
Yes, I'll add something to the import script that checks to see if the prior commit is not from the import script. If it notices someone else committing to the dist-git it'll stop and require a maintainer handle it manually.
- Jeremy
On Thu, Mar 12, 2020 at 5:22 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Mar 11, 2020 at 12:41 PM Jeremy Cline jeremy@jcline.org wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
I don't think that's actually acceptable under Fedora guidelines, as that violates the canonicity rule on the sources and spec[1].
Have you already worked out how to deal with that yet?
While in theory, this could be an issue, in practice it is very much not.
The kernel doesn't get hit with most of those automated bumps and scripted changes due to the fact that we build pretty much daily to begin with. And we pay pretty close attention to everything committed, so someone commiting to the dist-git would get a reply and a pointer to the current workflow before their changes were overwritten.
Justin
----- Original Message -----
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist-git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
How do we ensure that this repo on gitlab.com is as trustworthy as the tarballs extracted from upstream kernel.org repos?
On Thu, 2020-03-12 at 10:11 -0400, Bastien Nocera wrote:
----- Original Message -----
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
How do we ensure that this repo on gitlab.com is as trustworthy as the tarballs extracted from upstream kernel.org repos?
The git tags are still signed by Linus. Does that cover your concerns?
- Jeremy
----- Original Message ----- <snip>
The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
Cheers
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
Thanks, Laura
----- Original Message -----
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
I also am personally not a fan of the "source-git" approach for various reasons (including that it makes it *much* more difficult to identify downstream vs upstream changes, more easily leading to forks), but the kernel team actively contributes to upstream and our current policy makes it incredibly difficult to have non-upstream changes in the kernel, so I'm less worried there.
On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
Fedora's "trusted infrastructure" can't scale to what CKI is doing. One could argue about what trusted infrastructure means in general, because in my opinion there is no such thing, but it would be entirely irresponsible to overwhelm already limited capacity with something that is done at the scale CKI runs. Figuring out how to get comfortable with using cloud resources for workloads where that make sense is critical to our long term success.
(FWIW, I'm trying really hard not to read your comment as a slam on the kernel team here. I also find it an interesting example of cognitive dissonance that CKI running in AWS somehow triggers this comment, when all of Fedora is dependent on the mirror network to serve the actual binaries to users and *that* is far more risky than doing build testing in the cloud that doesn't even impact end-users.)
josh
I also am personally not a fan of the "source-git" approach for various reasons (including that it makes it *much* more difficult to identify downstream vs upstream changes, more easily leading to forks), but the kernel team actively contributes to upstream and our current policy makes it incredibly difficult to have non-upstream changes in the kernel, so I'm less worried there.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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
On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
Fedora's "trusted infrastructure" can't scale to what CKI is doing. One could argue about what trusted infrastructure means in general, because in my opinion there is no such thing, but it would be entirely irresponsible to overwhelm already limited capacity with something that is done at the scale CKI runs. Figuring out how to get comfortable with using cloud resources for workloads where that make sense is critical to our long term success.
(FWIW, I'm trying really hard not to read your comment as a slam on the kernel team here. I also find it an interesting example of cognitive dissonance that CKI running in AWS somehow triggers this comment, when all of Fedora is dependent on the mirror network to serve the actual binaries to users and *that* is far more risky than doing build testing in the cloud that doesn't even impact end-users.)
I am not slamming the kernel maintainers. They're doing excellent work, and many of the efforts as part of the CKI project are to be lauded. I am also not saying cloud resources in themselves are a problem, but it's not like you're running on a git server hosted in Fedora's AWS/Azure/GCP account.
My principal concern has always been that projects under the Fedora banner (or something like it) should be under infrastructure that the Fedora Project controls.
Honestly, I don't care if it's RHOSP, Fedora's AWS/Azure/GCP, or a server in a Red Hat office or datacenter. What I care about is that when push comes to shove, we're not screwed by an external force in an unexpected fashion in a way where we have no recovery plan.
Personally, I think it's cool to see that the Red Hat kernel might eventually be derived from the Fedora kernel as a consequence of this effort!
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Mar 13, 2020 at 9:42 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Mar 13, 2020 at 7:08 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
Fedora's "trusted infrastructure" can't scale to what CKI is doing. One could argue about what trusted infrastructure means in general, because in my opinion there is no such thing, but it would be entirely irresponsible to overwhelm already limited capacity with something that is done at the scale CKI runs. Figuring out how to get comfortable with using cloud resources for workloads where that make sense is critical to our long term success.
(FWIW, I'm trying really hard not to read your comment as a slam on the kernel team here. I also find it an interesting example of cognitive dissonance that CKI running in AWS somehow triggers this comment, when all of Fedora is dependent on the mirror network to serve the actual binaries to users and *that* is far more risky than doing build testing in the cloud that doesn't even impact end-users.)
I am not slamming the kernel maintainers. They're doing excellent work, and many of the efforts as part of the CKI project are to be lauded. I am also not saying cloud resources in themselves are a problem, but it's not like you're running on a git server hosted in Fedora's AWS/Azure/GCP account.
My principal concern has always been that projects under the Fedora banner (or something like it) should be under infrastructure that the Fedora Project controls.
Ah. I see, well that makes sense, yes.
Honestly, I don't care if it's RHOSP, Fedora's AWS/Azure/GCP, or a server in a Red Hat office or datacenter. What I care about is that when push comes to shove, we're not screwed by an external force in an unexpected fashion in a way where we have no recovery plan.
CKI didn't evolve as a Fedora specific thing. It certainly benefits Fedora, and I think we should welcome such activities without being worried entirely about control. The tipping point in my mind is whether we *depend* on something for Fedora's success. Those kinds of projects should probably be folded into Fedora control. CKI is massively valuable, but if it disappeared tomorrow Fedora would still continue on.
Personally, I think it's cool to see that the Red Hat kernel might eventually be derived from the Fedora kernel as a consequence of this effort!
I agree 100%.
josh
On Fri, Mar 13, 2020 at 10:00 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Fri, Mar 13, 2020 at 9:49 AM Neal Gompa ngompa13@gmail.com wrote:
I am not slamming the kernel maintainers. They're doing excellent work, and many of the efforts as part of the CKI project are to be lauded. I am also not saying cloud resources in themselves are a problem, but it's not like you're running on a git server hosted in Fedora's AWS/Azure/GCP account.
My principal concern has always been that projects under the Fedora banner (or something like it) should be under infrastructure that the Fedora Project controls.
Ah. I see, well that makes sense, yes.
Honestly, I don't care if it's RHOSP, Fedora's AWS/Azure/GCP, or a server in a Red Hat office or datacenter. What I care about is that when push comes to shove, we're not screwed by an external force in an unexpected fashion in a way where we have no recovery plan.
CKI didn't evolve as a Fedora specific thing. It certainly benefits Fedora, and I think we should welcome such activities without being worried entirely about control. The tipping point in my mind is whether we *depend* on something for Fedora's success. Those kinds of projects should probably be folded into Fedora control. CKI is massively valuable, but if it disappeared tomorrow Fedora would still continue on.
I think that will depend on how much we will grow to rely on the CKI stuff to make "good" kernels. Ideally, it'll become critical to doing so, and thus it will make sense to fold it under the Fedora banner.
The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
Fedora's "trusted infrastructure" can't scale to what CKI is doing. One could argue about what trusted infrastructure means in general, because in my opinion there is no such thing, but it would be entirely irresponsible to overwhelm already limited capacity with something that is done at the scale CKI runs. Figuring out how to get comfortable with using cloud resources for workloads where that make sense is critical to our long term success.
And git repos should be verifiable to the upstream so I believe this should be no worse than any other git ecosystem.
(FWIW, I'm trying really hard not to read your comment as a slam on the kernel team here. I also find it an interesting example of cognitive dissonance that CKI running in AWS somehow triggers this comment, when all of Fedora is dependent on the mirror network to serve the actual binaries to users and *that* is far more risky than doing build testing in the cloud that doesn't even impact end-users.)
Package/repo signing mitigates that, but that can also be done in the git side of things too.
On Fri, Mar 13, 2020 at 9:51 AM Peter Robinson pbrobinson@gmail.com wrote:
> The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
Fedora's "trusted infrastructure" can't scale to what CKI is doing. One could argue about what trusted infrastructure means in general, because in my opinion there is no such thing, but it would be entirely irresponsible to overwhelm already limited capacity with something that is done at the scale CKI runs. Figuring out how to get comfortable with using cloud resources for workloads where that make sense is critical to our long term success.
And git repos should be verifiable to the upstream so I believe this should be no worse than any other git ecosystem.
(FWIW, I'm trying really hard not to read your comment as a slam on the kernel team here. I also find it an interesting example of cognitive dissonance that CKI running in AWS somehow triggers this comment, when all of Fedora is dependent on the mirror network to serve the actual binaries to users and *that* is far more risky than doing build testing in the cloud that doesn't even impact end-users.)
Package/repo signing mitigates that, but that can also be done in the git side of things too.
Provenance isn't what I was phrasing as risky. We depend on the mirror network to scale, which is entirely outside of our control and if they decide it's no longer worth distributing Fedora binaries we'd be screwed. It's the exact concern Neal has :)
josh
On Fri, Mar 13, 2020 at 9:56 AM Josh Boyer jwboyer@fedoraproject.org wrote:
Provenance isn't what I was phrasing as risky. We depend on the mirror network to scale, which is entirely outside of our control and if they decide it's no longer worth distributing Fedora binaries we'd be screwed. It's the exact concern Neal has :)
Well, as a mirror admin, I don't plan on stopping anytime soon. :)
That said, we still control the master endpoint, and there *are* some fallback scenarios, just way more expensive and difficult to deal with. I hope we don't have to go there, I enjoy the generosity of our mirror network and I'm glad to contribute to the project myself in this manner, too.
On Fri, 2020-03-13 at 07:07 -0400, Neal Gompa wrote:
On Fri, Mar 13, 2020 at 7:02 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
On 3/12/20 10:57 AM, Bastien Nocera wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your > concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I think this boils down to how much do you trust the kernel maintainers. Keep in mind that the existing model requires the kernel maintainers to manually pull down a tree and extract the tarball and then upload. You can probably trust them to not do anything malicious but mistakes can happen (source: I screwed up many times). It's good to be concerned about provenance as a threat model but I consider maintainers screwing up manual tasks to be a bigger threat model to Fedora kernel security so anything that moves towards automation is a benefit in my eyes.
For me, it's about how much we trust gitlab.com _in addition_ to trusting kernel.org and fedoraproject.org. I wouldn't be concerned at all if the new "in-between" tree was at either of those 2 locations.
For what it's worth, while I agree, I doubt the kernel maintainers will care about that. They clearly haven't cared given that the CKI project does not run on what most in the project generally considers "trusted infrastructure".
I'm not sure what your issue with CKI is, but that's beside the point.
What exactly about the tarball coming from kernel.org makes you trust it? That's not a rhetorical question, I'm genuinely curious. Is it the x509 certificate they were issued? Is it that the tarballs are GPG- signed?
I also am personally not a fan of the "source-git" approach for various reasons (including that it makes it *much* more difficult to identify downstream vs upstream changes, more easily leading to forks), but the kernel team actively contributes to upstream and our current policy makes it incredibly difficult to have non-upstream changes in the kernel, so I'm less worried there.
Currently we make a clone of Linus's tree and do a diff between master and the latest tag and then plop that into the lookaside cache. No individual commits, nothing. You know what happens if I'm working on a patch in that repository? Into the patch it goes, and good luck finding it among thousands of other changes.
In the source tree, every commit is still broken out, figuring out what patches Fedora carries is a simple git command. It's *way* simpler to discover what patches are included in a build and why.
Kind regards, Jeremy
On Thu, Mar 12, 2020 at 9:58 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I don't really see how this is relevant in regards to kernel.org.
dist-git still uses the lookaside for tarballs, which are downloaded from kernel.org, signature verified, and uploaded independent of anything gitlab is doing. Development work happens on top of a tree at gitlab, which is how our fedora specific patches, config options, and spec file are maintained, but none of this is on kernel.org anyway. The tree used as a basis does use the kernel.org tree, but this is not much different from cloning a tree anywhere else and doing development on top of it.
Justin
----- Original Message -----
On Thu, Mar 12, 2020 at 9:58 AM Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
<snip> > The git tags are still signed by Linus. Does that cover your concerns?
Not really, no. I think that multiplying the intermediaries between kernel.org and the Fedora repos by adding gitlab.com in the middle might not be the best of ideas.
If the Fedora security team is fine with it, I'm fine with it, and even if I understand the practical concerns (pagure not being up to par to deal with repos that size, and without a mail gateway support), I find it slightly concerning.
I don't really see how this is relevant in regards to kernel.org.
dist-git still uses the lookaside for tarballs, which are downloaded from kernel.org, signature verified, and uploaded independent of anything gitlab is doing. Development work happens on top of a tree at gitlab, which is how our fedora specific patches, config options, and spec file are maintained, but none of this is on kernel.org anyway. The tree used as a basis does use the kernel.org tree, but this is not much different from cloning a tree anywhere else and doing development on top of it.
Presumably the important distinction is that if you were just "doing development somewhere else", the diff/patches would then be reviewed before being merged.
Here, they're going to be reviewed as they're being merged into the gitlab.com repo, and the sync to the fedoraproject.org repo isn't going to be reviewed because it's likely not going to be human-readable.
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
Just a note folks, the plan is to do this starting next week after the close of the v5.7 merge window.
Regards, Jeremy
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
Hi folks,
This should come as no surprise to those who have been following the kernel list and/or saw Laura's Flock talk last summer, but there are some changes to the way the Fedora kernel is maintained coming in the next couple of weeks.
For those folks who aren't committing directly to the kernel dist- git, this change won't really impact you, although contributing might be easier.
We're planning to switch from maintaining the kernel directly in the dist-git to using a kernel source tree along with a set of scripts to turn the source tree into something that can be automatically checked into the dist-git. This means anything committed directly to the dist- git repository will get overwritten on the next update.
The git repository is currently hosted at https://gitlab.com/cki-project/kernel-ark/. Documentation (still very rough) for common tasks is at https://gitlab.com/cki-project/kernel-ark/-/wikis/home. There are a few outstanding merge requests to get the tree fully synced up with the current state of the dist-git repository, so if you decide to jump in and try things out, be aware things might not work.
As part of this, we're going to start bridging merge requests to this list as emailed patch series for those who prefer email, and turn any emailed patches to the list into merge requests, so the list is going to get quite a bit more traffic.
Just a note folks, the plan is to do this starting next week after the close of the v5.7 merge window.
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
Please send any kernel changes as merge requests to the GitLab repository or as emails to this list. If you are one of the folks who has commit access to the dist-git and adds something there directly, I'll pull it into the source tree for you, but I *will* whine at you and I'm a world class whiner.
Regards, Jeremy
On Tue, Apr 14, 2020 at 6:37 PM Jeremy Cline jeremy@jcline.org wrote:
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
Please send any kernel changes as merge requests to the GitLab repository or as emails to this list. If you are one of the folks who has commit access to the dist-git and adds something there directly, I'll pull it into the source tree for you, but I *will* whine at you and I'm a world class whiner.
My apologies if I missed a discussion on this earlier, but what is the process for building the source tarball for the kernel-headers package? The old process does not seem to apply to the new build process ...
On Tue, 2020-04-14 at 21:13 -0400, Paul Moore wrote:
On Tue, Apr 14, 2020 at 6:37 PM Jeremy Cline jeremy@jcline.org wrote:
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
Please send any kernel changes as merge requests to the GitLab repository or as emails to this list. If you are one of the folks who has commit access to the dist-git and adds something there directly, I'll pull it into the source tree for you, but I *will* whine at you and I'm a world class whiner.
My apologies if I missed a discussion on this earlier, but what is the process for building the source tarball for the kernel-headers package? The old process does not seem to apply to the new build process ...
The script did indeed get nuked (although obviously it's in the history forever). I haven't made a particular plan for this yet, but the script could either move into the kernel-headers package or the source tree. I'm inclined to move it into the source tree so the kernel-headers (and kernel-tools) packages can be generated from it as well.
- Jeremy
On Tue, Apr 14, 2020 at 9:35 PM Jeremy Cline jeremy@jcline.org wrote:
On Tue, 2020-04-14 at 21:13 -0400, Paul Moore wrote:
On Tue, Apr 14, 2020 at 6:37 PM Jeremy Cline jeremy@jcline.org wrote:
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
Please send any kernel changes as merge requests to the GitLab repository or as emails to this list. If you are one of the folks who has commit access to the dist-git and adds something there directly, I'll pull it into the source tree for you, but I *will* whine at you and I'm a world class whiner.
My apologies if I missed a discussion on this earlier, but what is the process for building the source tarball for the kernel-headers package? The old process does not seem to apply to the new build process ...
The script did indeed get nuked (although obviously it's in the history forever). I haven't made a particular plan for this yet, but the script could either move into the kernel-headers package or the source tree. I'm inclined to move it into the source tree so the kernel-headers (and kernel-tools) packages can be generated from it as well.
This would be helpful for me too so that I can build those things from a custom kernel build easily. The three separate source package thing isn't very easy to deal with when making custom packages...
On Tue, Apr 14, 2020 at 9:37 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Apr 14, 2020 at 9:35 PM Jeremy Cline jeremy@jcline.org wrote:
On Tue, 2020-04-14 at 21:13 -0400, Paul Moore wrote:
On Tue, Apr 14, 2020 at 6:37 PM Jeremy Cline jeremy@jcline.org wrote:
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
Please send any kernel changes as merge requests to the GitLab repository or as emails to this list. If you are one of the folks who has commit access to the dist-git and adds something there directly, I'll pull it into the source tree for you, but I *will* whine at you and I'm a world class whiner.
My apologies if I missed a discussion on this earlier, but what is the process for building the source tarball for the kernel-headers package? The old process does not seem to apply to the new build process ...
The script did indeed get nuked (although obviously it's in the history forever). I haven't made a particular plan for this yet, but the script could either move into the kernel-headers package or the source tree. I'm inclined to move it into the source tree so the kernel-headers (and kernel-tools) packages can be generated from it as well.
This would be helpful for me too so that I can build those things from a custom kernel build easily. The three separate source package thing isn't very easy to deal with when making custom packages...
It was a bit of a mess, but it was reasonably stable and just a matter of scripting to automate it. Honestly, I'm not sure I care too much about the process details, I just want a recipe that I can follow to generate a patched kernel-headers package.
I just noticed an oddity/bug with the current kernel package ... if you run `fedpkg srpm` *after* running `fedpkg prep` the `fedpkg srpm` command fails with several lines similar to the following:
error: Bad file: /pjob.data/scratch/kernel/filter-modules.sh.fedora: No such file or directory
On Tue, Apr 14, 2020 at 9:52 PM Paul Moore paul@paul-moore.com wrote:
I just noticed an oddity/bug with the current kernel package ... if you run `fedpkg srpm` *after* running `fedpkg prep` the `fedpkg srpm` command fails with several lines similar to the following:
error: Bad file: /pjob.data/scratch/kernel/filter-modules.sh.fedora: No such file or directory
There is another change in the kernel's specfile relating to where the %buildid is inserted into the version string. Previously the kernel NVR would look like this:
kernel-5.6.0-0.rc7.git1.1.BUILDID.fc33.src.rpm
... but now it looks like this:
kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33.BUILDID.src.rpm
Any chance you can change the specfile so that the %buildid comes before %dist as it did in the past?
Am 15.04.20 um 04:24 schrieb Paul Moore:
On Tue, Apr 14, 2020 at 9:52 PM Paul Moore paul@paul-moore.com wrote:
There is another change in the kernel's specfile relating to where the %buildid is inserted into the version string. Previously the kernel NVR would look like this:
kernel-5.6.0-0.rc7.git1.1.BUILDID.fc33.src.rpm
... but now it looks like this:
kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33.BUILDID.src.rpm
Any chance you can change the specfile so that the %buildid comes before %dist as it did in the past?
And how about making it a bit shorter? Until now I added ".vanilla.knurd.1" for my vanilla builds (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ), but doing that now exceeds the 64 char limit now and thus results in build error. No big deal, I can remove the ".knurd", but I liked the old way more, as that made it more obvious *what* kind of kernel this is and *who* built it.
And is the "2020" really that important when we have 5.7-rc1 already? How about changing "20200414git" to "0414g" and get something like this (saves 7 chars):
kernel-5.7.0-0.rc1.0414g8632e9b5645b.1.fc33.BUILDID.src.rpm
Anyway, I don't care to much, just a suggestion, no need for a big bike shedding debate.
Cu, knurd
On Wed, 2020-04-15 at 11:15 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 04:24 schrieb Paul Moore:
On Tue, Apr 14, 2020 at 9:52 PM Paul Moore paul@paul-moore.com wrote:
There is another change in the kernel's specfile relating to where the %buildid is inserted into the version string. Previously the kernel NVR would look like this:
kernel-5.6.0-0.rc7.git1.1.BUILDID.fc33.src.rpm
... but now it looks like this:
kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33.BUILDID.src.rpm
Any chance you can change the specfile so that the %buildid comes before %dist as it did in the past?
Should be straight-forward, I'll take care of that today.
And how about making it a bit shorter? Until now I added ".vanilla.knurd.1" for my vanilla builds (https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories ), but doing that now exceeds the 64 char limit now and thus results in build error. No big deal, I can remove the ".knurd", but I liked the old way more, as that made it more obvious *what* kind of kernel this is and *who* built it.
And is the "2020" really that important when we have 5.7-rc1 already? How about changing "20200414git" to "0414g" and get something like this (saves 7 chars):
kernel-5.7.0-0.rc1.0414g8632e9b5645b.1.fc33.BUILDID.src.rpm
Anyway, I don't care to much, just a suggestion, no need for a big bike shedding debate.
So the current format follows the snapshot guidelines[0], but it *is* very long. While it's nice to follow the guidelines, the package hasn't been compliant before this so I suppose it's not terrible to bend the rules.
I'm okay with this adjustment if folks are okay with treating the guidelines like... guidelines.
[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snaps...
- Jeremy
On Wed, Apr 15, 2020 at 9:53 AM Jeremy Cline jeremy@jcline.org wrote:
On Wed, 2020-04-15 at 11:15 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 04:24 schrieb Paul Moore:
On Tue, Apr 14, 2020 at 9:52 PM Paul Moore paul@paul-moore.com wrote:
There is another change in the kernel's specfile relating to where the %buildid is inserted into the version string. Previously the kernel NVR would look like this:
kernel-5.6.0-0.rc7.git1.1.BUILDID.fc33.src.rpm
... but now it looks like this:
kernel-5.7.0-0.rc1.20200414git8632e9b5645b.1.fc33.BUILDID.src.rpm
Any chance you can change the specfile so that the %buildid comes before %dist as it did in the past?
Should be straight-forward, I'll take care of that today.
FWIW, this is the patch I've been using since last night; limited testing of course, but it seems to work thus far.
diff --git kernel.spec kernel.spec index 2aa6271ff..bdfbf766e 100644 --- kernel.spec +++ kernel.spec @@ -74,7 +74,7 @@ Summary: The Linux kernel # allow pkg_release to have configurable %%{?dist} tag %define specrelease 0.rc1.20200414git8632e9b5645b.1%{?dist}
-%define pkg_release %{specrelease}%{?buildid} +%define pkg_release %{pkgrelease}%{?buildid}%{?dist}
# What parts do we want to build? We must build at least one kernel. # These are the kernels that are built IF the architecture allows it.
Am 15.04.20 um 00:37 schrieb Jeremy Cline:
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
Just a note folks, the plan is to do this starting next week after the close of the v5.7 merge window.
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
``` The files MUST then be checked into the Fedora Package revision control system […]. Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection […]. ``` There are other rules in the patch section that afaics are violated. Were those violation discussed and blessed by the Fedora Packaging Committee or FESCo?
I for one would dislike such an exception, because I sometimes look at kernel source packages from other dists and it is always annoying when I can't easily see individual patches. It also makes it way harder for users to remove one certain patch that Fedora applied for testing or other reasons.
So you you maybe change the scheme so individual patch files land in the src.rpm?
Cu, knurd
P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always applied.
On Wed, Apr 15, 2020 at 5:32 AM Thorsten Leemhuis fedora@leemhuis.info wrote:
Am 15.04.20 um 00:37 schrieb Jeremy Cline:
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
Just a note folks, the plan is to do this starting next week after the close of the v5.7 merge window.
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
The files MUST then be checked into the Fedora Package revision control system […]. Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection […].There are other rules in the patch section that afaics are violated. Were those violation discussed and blessed by the Fedora Packaging Committee or FESCo?
I don't think the split out patches "rule" is being violated here. They changed the source tarball to one generated from the git tree and they don't have any patches at the dist-git level at all. Several other packages in Fedora already do this, such as anaconda.
I for one would dislike such an exception, because I sometimes look at kernel source packages from other dists and it is always annoying when I can't easily see individual patches. It also makes it way harder for users to remove one certain patch that Fedora applied for testing or other reasons.
So you you maybe change the scheme so individual patch files land in the src.rpm?
Is there a reason you can't do that in the source git tree instead?
P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always applied.
I'm not sure --with-vanilla will exist at all with the changes here.
josh
Le mer. 15 avr. 2020 à 13:34, Josh Boyer jwboyer@fedoraproject.org a écrit :
On Wed, Apr 15, 2020 at 5:32 AM Thorsten Leemhuis fedora@leemhuis.info wrote:
...
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
The files MUST then be checked into the Fedora Package revision control system […]. Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection […].There are other rules in the patch section that afaics are violated. Were those violation discussed and blessed by the Fedora Packaging Committee or FESCo?
I don't think the split out patches "rule" is being violated here. They changed the source tarball to one generated from the git tree and they don't have any patches at the dist-git level at all. Several other packages in Fedora already do this, such as anaconda.
So it means should one single line patch should be changed, you need to re-upload a 100M tarball to the fedora lookaside cache? I understand the benefit to have an upstream source tree as a primary origin for kernel patch development. But what is the reason behind this process in particular ?
It would have been easier to only generate a full fedora diff against the original upstream tree (using a commit-id that can also be generated with gitlab with A PR). Like how I expect it's done with the patch-5.7.0-redhat.patch.
Then keep using the original upstream tarballs. (linux-M.tar.xz and patch-M-m.xz) I'm sure that in some cases, (minor patch update) there is even not have to change the fedora diff.
On Thu, 2020-04-16 at 13:10 +0200, Nicolas Chauvet wrote:
Le mer. 15 avr. 2020 à 13:34, Josh Boyer jwboyer@fedoraproject.org a écrit :
On Wed, Apr 15, 2020 at 5:32 AM Thorsten Leemhuis < fedora@leemhuis.info> wrote:
...
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
The files MUST then be checked into the Fedora Package revision control system […]. Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection […].There are other rules in the patch section that afaics are violated. Were those violation discussed and blessed by the Fedora Packaging Committee or FESCo?
I don't think the split out patches "rule" is being violated here. They changed the source tarball to one generated from the git tree and they don't have any patches at the dist-git level at all. Several other packages in Fedora already do this, such as anaconda.
So it means should one single line patch should be changed, you need to re-upload a 100M tarball to the fedora lookaside cache? I understand the benefit to have an upstream source tree as a primary origin for kernel patch development. But what is the reason behind this process in particular ?
It would have been easier to only generate a full fedora diff against the original upstream tree (using a commit-id that can also be generated with gitlab with A PR). Like how I expect it's done with the patch-5.7.0-redhat.patch.
Then keep using the original upstream tarballs. (linux-M.tar.xz and patch-M-m.xz) I'm sure that in some cases, (minor patch update) there is even not have to change the fedora diff.
Yes, it's a bit inefficient. I brought this up on the infrastructure list ([RFC] Optionally using git repositories instead of the lookaside cache), but people didn't seem concerned about the storage requirement.
I am not particularly inspired to develop a bunch of scripts to work around the fact that we're not using git to store source code. If someone else wants to fix up the kernel build scripts I'm fine with that, although it seems to me that it's fixing the problem in the wrong place.
- Jeremy
On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 00:37 schrieb Jeremy Cline:
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
Just a note folks, the plan is to do this starting next week after the close of the v5.7 merge window.
Okay, this is now done. You may notice a number of stale options made their way back into the config files, it's on my to-do list to clean this up assuming there aren't any larger fires this week.
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
The files MUST then be checked into the Fedora Package revision control system […]. Storing the files in this way allows people to use standard tools to visualize the changes between revisions of the files and track additions and removals without a layer of indirection […].There are other rules in the patch section that afaics are violated. Were those violation discussed and blessed by the Fedora Packaging Committee or FESCo?
I for one would dislike such an exception, because I sometimes look at kernel source packages from other dists and it is always annoying when I can't easily see individual patches. It also makes it way harder for users to remove one certain patch that Fedora applied for testing or other reasons.
So you you maybe change the scheme so individual patch files land in the src.rpm?
I'll look into how simple it is to change. It's easy to see in the source tree, though, just look at the "ark-patches" branch.
Cu, knurd
P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always applied.
I'll see about that as well. Note that if you want a vanilla SRPM it's easy from the source tree:
$ git checkout master $ git merge internal $ sed -i 's/=13/=11/g' redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER $ make rh-srpm
However, if you want to continue building from the dist-git, the patch is ignored if it's empty so doing
$ truncate -s 0 patch-*-redhat.patch
will also give you a vanilla build.
- Jeremy
Am 15.04.20 um 15:41 schrieb Jeremy Cline:
On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 00:37 schrieb Jeremy Cline:
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches […] So you you maybe change the scheme so individual patch files land in the src.rpm?
I'll look into how simple it is to change.
Thx. Until then or in general: If you have a minute it IMHO would be really nice to have a comment in the spec file that…
It's easy to see in the source tree, though, just look at the "ark-patches" branch.
…wound explain this with a link to the git repo. Then maintainers from other distros or interested people that look in dist-git or the src.rpm known where to look for patches.
And BTW: I wouldn't call that "easy". Simply browsing to https://src.fedoraproject.org/rpms/kernel/tree/f32 and looking for files that end with .patch is way easier, even if you know your way around with git. And if you want to take a closer look you don't have to clone only a small git repo instead of a really big fat one…
P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always applied.
I'll see about that as well.
Great, thx.
Note that if you want a vanilla SRPM it's easy from the source tree:
$ git checkout master $ git merge internal $ sed -i 's/=13/=11/g' redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDER $ make rh-srpm
What kind of sorcery is that? ;-) Well, I guess I'll understand if I dig deeper into the kernel-ark documentation...
This BTW might be the biggest problem with the whole new approach: It's not really obvious and a bit hard to understand. Yes, there are is lots of documentation in kernel-ark project, but if you are used to RPM or DEB packages and just want to peek into the Fedora kernel SRPM (say you have a kernel problem you want to track down and fix) then you might quickly feel lost, as there seems to be a lot of magic you have to learn for an otherwise small task. I know that this magic is supposed to make the kernel maintainers life easier, but it makes things a lot harder for other people that thus might give up instead of helping you. That's IMHO one of the reasons why the Fedora Packaging Committee put the rules in place I mentioned. Maybe a few more comments in the spec file or a document with a quickstart for this use case could help a lot.
However, if you want to continue building from the dist-git, the patch is ignored if it's empty so doing
$ truncate -s 0 patch-*-redhat.patch
will also give you a vanilla build.
Ahh, good to know.
Thx for replying and looking into this,
CU, knurd
On Thu, 2020-04-16 at 08:34 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 15:41 schrieb Jeremy Cline:
On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 00:37 schrieb Jeremy Cline:
On Tue, 2020-04-07 at 15:33 +0000, Jeremy Cline wrote:
On Wed, 2020-03-11 at 16:40 +0000, Jeremy Cline wrote:
There is one thing I really dislike about the scheme (one it didn't notice when I took a brief look at it weeks ago; sorry): There are no individual patches anymore in dist-git/the srpm and that afaics violates the packaging guidelines. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches […] So you you maybe change the scheme so individual patch files land in the src.rpm?
I'll look into how simple it is to change.
Thx. Until then or in general: If you have a minute it IMHO would be really nice to have a comment in the spec file that…
It's easy to see in the source tree, though, just look at the "ark-patches" branch.
…wound explain this with a link to the git repo. Then maintainers from other distros or interested people that look in dist-git or the src.rpm known where to look for patches.
And BTW: I wouldn't call that "easy". Simply browsing to https://src.fedoraproject.org/rpms/kernel/tree/f32 and looking for files that end with .patch is way easier, even if you know your way around with git. And if you want to take a closer look you don't have to clone only a small git repo instead of a really big fat one…
P.S.: The "--with-vanilla" build option afaics doesn't work anymore, as patch-%{rpmversion}-redhat.patch and linux-kernel-test.patch are always applied.
I'll see about that as well.
Great, thx.
Note that if you want a vanilla SRPM it's easy from the source tree:
$ git checkout master $ git merge internal $ sed -i 's/=13/=11/g' redhat/configs/fedora/generic/arm/aarch64/CONFIG_FORCE_MAX_ZONEORDE R $ make rh-srpm
What kind of sorcery is that? ;-) Well, I guess I'll understand if I dig deeper into the kernel-ark documentation...
The short story is internal is the (poorly named) branch that contains the config and build scripts. Fedora ships a patch that changes CONFIG_FORCE_MAX_ZONEORDER default so it's invalid if you prep the kernel without it. It might be best to not check configurations for completeness and validity by default.
This BTW might be the biggest problem with the whole new approach: It's not really obvious and a bit hard to understand. Yes, there are is lots of documentation in kernel-ark project, but if you are used to RPM or DEB packages and just want to peek into the Fedora kernel SRPM (say you have a kernel problem you want to track down and fix) then you might quickly feel lost, as there seems to be a lot of magic you have to learn for an otherwise small task. I know that this magic is supposed to make the kernel maintainers life easier, but it makes things a lot harder for other people that thus might give up instead of helping you. That's IMHO one of the reasons why the Fedora Packaging Committee put the rules in place I mentioned. Maybe a few more comments in the spec file or a document with a quickstart for this use case could help a lot.
I've proposed a readme[0] and something to break the patches out for those who prefer dist-git[1].
There's also a fix for the buildid reordering[2] and the moving of files around that breaks multiple preps[3].
I'm happy to make improvements and make this as easy as possible. It's not perfect to start out and I apologize to anyone who's been inconvenienced by that changes.
[0] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/303 [1] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/315 [2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/296 [3] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/300
However, if you want to continue building from the dist-git, the patch is ignored if it's empty so doing
$ truncate -s 0 patch-*-redhat.patch
will also give you a vanilla build.
Ahh, good to know.
Thx for replying and looking into this,
Given this are do you still want a --with-vanilla option?
- Jeremy
Am 17.04.20 um 01:29 schrieb Jeremy Cline:
On Thu, 2020-04-16 at 08:34 +0200, Thorsten Leemhuis wrote:
Am 15.04.20 um 15:41 schrieb Jeremy Cline:
On Wed, 2020-04-15 at 11:31 +0200, Thorsten Leemhuis wrote:
[…] I've proposed a readme[0]
Ahh, good. Nitpicking: maybe a comment or two at the appropriate places in the spec file (especially near "Source0") pointing towards that readme would be good afauics, as that's where a lot of people will look and might get puzzled otherwise.
and something to break the patches out for those who prefer dist-git[1].
Great, thx.
However, if you want to continue building from the dist-git, the patch is ignored if it's empty so doing $ truncate -s 0 patch-*-redhat.patch will also give you a vanilla build.
Ahh, good to know. Thx for replying and looking into this,
Given this are do you still want a --with-vanilla option?
Ohh, seems you got me wrong here a little bit. I don't care much about it, I only noticed it's still there and afaics broken. So decide yourself.
I think it was good to have it in the past, but not so much now kernel.spec became even harder to understand for people that want to use it as base for a customized package. At least if I was not familiar with how things work I would simply not use something as base that has a 100m file "Source0: linux-20200416git9786cab67457.tar.xz" in it, as it's not that easy to check if that is pristine. That's why I would have strongly preferred if you had continued to use the regular tarballs and patch-x.y.z.xz files as a base, but well, I can see that would have made things more complicated.
CU, knurd
kernel@lists.fedoraproject.org
-
Bastien Nocera -
Jeremy Cline -
Josh Boyer -
Justin Forbes -
Laura Abbott -
Neal Gompa -
Nicolas Chauvet -
Paul Moore -
Peter Robinson -
Thorsten Leemhuis