Observations:
Not having it obvious in the kernel name that it was a kernel from the nodebug repo caused a minor amount of confusion.
A normal rawhide kernel and a nodebug repo kernel both ended up with the name 3.7.0-0.rc5.git1.3.fc19.
A normal rawhide nodebug kernel is still being built once per rc.
There seems to be a lot of variability in the lag of when a nodebug version of any particular rawhide kernel.
Suggestions:
Instead of bumping the release number for nodebug kernels and the string ".nodebug" to the end of the release. For example: 3.7.0-0.rc5.git1.3.fc19.nodebug
Always build debug kernels for rawhide.
Automate building of nodebug kernels so that once a rawhide kernel has successfully completed building in koji, the same kernel gets rebuilt as a nodebug kernel. Check on the order of hourly.
On Fri, Nov 16, 2012 at 10:29:41AM -0600, Bruno Wolff III wrote:
Observations:
Not having it obvious in the kernel name that it was a kernel from the nodebug repo caused a minor amount of confusion.
A normal rawhide kernel and a nodebug repo kernel both ended up with the name 3.7.0-0.rc5.git1.3.fc19.
A normal rawhide nodebug kernel is still being built once per rc.
Yes to all of the above.
There seems to be a lot of variability in the lag of when a nodebug version of any particular rawhide kernel.
It's done on the side.
Suggestions:
Instead of bumping the release number for nodebug kernels and the string ".nodebug" to the end of the release. For example: 3.7.0-0.rc5.git1.3.fc19.nodebug
Possible. Would have to take into consideration upgrade paths and such.
Always build debug kernels for rawhide.
I'd rather not. The nodebug repo is a side thing that not everyone wants to add. Having one non-debug kernel per RC in real rawhide does have value.
Automate building of nodebug kernels so that once a rawhide kernel has successfully completed building in koji, the same kernel gets rebuilt as a nodebug kernel. Check on the order of hourly.
Not really sure how feasible that is at the moment. It would have to trigger off of koji build completion. Maybe once that is hooked up to fedmsg.
Though since they're all being built on a private machine that isn't sitting idle, I don't think that's likely going to happen soon in any case.
josh
On Fri, 2012-11-16 at 10:29 -0600, Bruno Wolff III wrote:
Observations:
Not having it obvious in the kernel name that it was a kernel from the nodebug repo caused a minor amount of confusion.
A normal rawhide kernel and a nodebug repo kernel both ended up with the name 3.7.0-0.rc5.git1.3.fc19.
A normal rawhide nodebug kernel is still being built once per rc.
There seems to be a lot of variability in the lag of when a nodebug version of any particular rawhide kernel.
Suggestions:
Instead of bumping the release number for nodebug kernels and the string ".nodebug" to the end of the release. For example: 3.7.0-0.rc5.git1.3.fc19.nodebug
Always build debug kernels for rawhide.
Automate building of nodebug kernels so that once a rawhide kernel has successfully completed building in koji, the same kernel gets rebuilt as a nodebug kernel. Check on the order of hourly.
It is actually started much quicker than that. The bigger issue is koji. Because they are done as scratch builds, they get a low priority and can take *much* longer to build than a regular kernel. For instance, this mornings kernel build was started within minutes of the git commit. Possibly even before the actual rawhide build was started. At this point, the rawhide build has been done for a while, and the nodebug build is still going. Had I waited until the koji build finished to start the nodebug build, you would just be waiting an extra hour or so for your nodebug kernel. I might suggest adding an exclude kernel* to your rawhide kernel repo if you want to insure that you are getting the nodebug kernels always. Every kernel is built there, even the first rc kernels which are nodebug in rawhide anyway.
Justin
On Fri, 2012-11-16 at 10:53 -0600, Justin M. Forbes wrote:
It is actually started much quicker than that. The bigger issue is koji. Because they are done as scratch builds, they get a low priority and can take *much* longer to build than a regular kernel. For instance, this mornings kernel build was started within minutes of the git commit. Possibly even before the actual rawhide build was started. At this point, the rawhide build has been done for a while, and the nodebug build is still going. Had I waited until the koji build finished to start the nodebug build, you would just be waiting an extra hour or so for your nodebug kernel.
An added data point here: rawhide kernel-3.7.0-0.rc5.git2.1.fc19: 53 minute koji build nodebug kernel-3.7.0-0.rc5.git2.2.fc19: 4h 8 minute koji build
The nodebug build was started less than 15 minutes after the rawhide build was started, it just takes a lot longer to complete.
Justin
On Fri, 16 Nov 2012 12:16:42 -0600 "Justin M. Forbes" jforbes@redhat.com wrote:
On Fri, 2012-11-16 at 10:53 -0600, Justin M. Forbes wrote:
It is actually started much quicker than that. The bigger issue is koji. Because they are done as scratch builds, they get a low priority and can take *much* longer to build than a regular kernel. For instance, this mornings kernel build was started within minutes of the git commit. Possibly even before the actual rawhide build was started. At this point, the rawhide build has been done for a while, and the nodebug build is still going. Had I waited until the koji build finished to start the nodebug build, you would just be waiting an extra hour or so for your nodebug kernel.
An added data point here: rawhide kernel-3.7.0-0.rc5.git2.1.fc19: 53 minute koji build nodebug kernel-3.7.0-0.rc5.git2.2.fc19: 4h 8 minute koji build
The nodebug build was started less than 15 minutes after the rawhide build was started, it just takes a lot longer to complete.
Additional, and likely main reason why this is:
Official kernel builds go to a pair of kernel builder boxes which only build kernel, grub2, shim for secure boot. Since nothing else builds on them, they are mostly idle and ready and have lots of capacity.
Scratch kernel builds go into the normal koji pool and get a random builder and are at lower priority than any official build, so they get pushed to the end of the queue.
Once we have coprs up, it might be faster to build them there...
kevin
On Fri, Nov 16, 2012 at 11:24:27 -0700, Kevin Fenzi kevin@scrye.com wrote:
Scratch kernel builds go into the normal koji pool and get a random builder and are at lower priority than any official build, so they get pushed to the end of the queue.
Does that mean the dodebug kernels won't work with secure boot by default? (This doesn't directly affect me, but might be something to get noted on the nodebug kernel wiki page if it's true.)
On Fri, Nov 16, 2012 at 02:10:05PM -0600, Bruno Wolff III wrote:
On Fri, Nov 16, 2012 at 11:24:27 -0700, Kevin Fenzi kevin@scrye.com wrote:
Scratch kernel builds go into the normal koji pool and get a random builder and are at lower priority than any official build, so they get pushed to the end of the queue.
Does that mean the dodebug kernels won't work with secure boot by default?
Yes, that is what it means.
josh
On Fri, Nov 16, 2012 at 15:14:02 -0500, Josh Boyer jwboyer@redhat.com wrote:
On Fri, Nov 16, 2012 at 02:10:05PM -0600, Bruno Wolff III wrote:
On Fri, Nov 16, 2012 at 11:24:27 -0700, Kevin Fenzi kevin@scrye.com wrote:
Scratch kernel builds go into the normal koji pool and get a random builder and are at lower priority than any official build, so they get pushed to the end of the queue.
Does that mean the dodebug kernels won't work with secure boot by default?
Yes, that is what it means.
josh
Any objections to me making a note on the wiki page about that?
On Fri, Nov 16, 2012 at 02:21:08PM -0600, Bruno Wolff III wrote:
On Fri, Nov 16, 2012 at 15:14:02 -0500, Josh Boyer jwboyer@redhat.com wrote:
On Fri, Nov 16, 2012 at 02:10:05PM -0600, Bruno Wolff III wrote:
On Fri, Nov 16, 2012 at 11:24:27 -0700, Kevin Fenzi kevin@scrye.com wrote:
Scratch kernel builds go into the normal koji pool and get a random builder and are at lower priority than any official build, so they get pushed to the end of the queue.
Does that mean the dodebug kernels won't work with secure boot by default?
Yes, that is what it means.
josh
Any objections to me making a note on the wiki page about that?
No, no objections at all! Thanks.
josh
On Fri, Nov 16, 2012 at 15:25:36 -0500, Josh Boyer jwboyer@redhat.com wrote:
No, no objections at all! Thanks.
I added a caveats section and added an entry stating: Will not "just work" with secure boot. (Because these kernels are built as scratch builds in koji, they don't get to run on the signing builders, so they don't get signed, so the shim will not run them without human interaction.)
kernel@lists.fedoraproject.org
-
Bruno Wolff III -
Josh Boyer -
Justin Forbes -
Kevin Fenzi