10:29 a.m.
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.
10:41 a.m.
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
10:53 a.m.
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
12:16 p.m.
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
12:24 p.m.
On Fri, 16 Nov 2012 12:16:42 -0600
"Justin M. Forbes" <jforbes(a)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
2:10 p.m.
On Fri, Nov 16, 2012 at 11:24:27 -0700,
Kevin Fenzi <kevin(a)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.)
2:14 p.m.
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(a)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
2:21 p.m.
On Fri, Nov 16, 2012 at 15:14:02 -0500,
Josh Boyer <jwboyer(a)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(a)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?
2:25 p.m.
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(a)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(a)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
2:35 p.m.
On Fri, Nov 16, 2012 at 15:25:36 -0500,
Josh Boyer <jwboyer(a)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.)
4178
days inactive
4178
days old
kernel@lists.fedoraproject.org
9 comments
4 participants
participants (4)
-
Bruno Wolff III -
Josh Boyer -
Justin Forbes -
Kevin Fenzi