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