This week in rawhide (The april edition)
A few jucy tidbits this week for rawhide.
First, there was a bug in the grubby package that landed on friday in rawhide. If you installed a kernel after that, you likely had it not boot correctly. If you installed a new kernel (3.14.0 came out monday) with grubby-8.31-1.fc21 installed you will need to edit your /etc/grub2.cfg or /etc/grub2-efi.cfg or remove the kernel(s) with the broken entries, upgrade grubby and reinstall them.
Next there was some discussion about getting rawhide signed in the latest releng meeting. There’s still no concrete proposal, but we agreed on things we don’t want: no passphrases stored on disk, no signing code on the koji hub itself. We are considering some listener that could take a passphrase on startup (only in memory) and listen on fedmsg for builds to sign. That way the hub is completely unaware of it, and we could easily expand it to signing scratch builds with a scratch key, etc. There was also a lot of discussion around if we wanted a dedicated rawhide key or not or if we use normal keys and resign at the branch point. Lots more discussion to happen on this before we get to a concrete proposal, but its moving along.
I filed a few tickets on mash (mash is the thing that composes the trees of packages):
One has already been fixed and the patch upstreamed: Right now rawhide keeps at least one drpm for every binary package for every arch. This amounts to about 120,000 files in drpm directories. In addition to causing some mirrors problems due to filesystem limitations of files in one dir, the vast majority of them are useless. Most rawhide users update pretty often, and those that don’t really shouldn’t expect drpms for everything. So, we now will have the ability to keep only the last 7 days of them. This should vastly cut down on those files and also really help compose time. I am looking forward to this landing.
The next is around multiple packages. Mash currently has the ability to either gather up the ‘latest’ package in a tag, or all packages in a tag. We use the ‘latest’ config since all packages in a tag would be way way too large. I’d like there to be a middle ground, possibly keeping 2 versions of a package (the ‘latest’ and the one before it, and possibly only for a limited time (say again a week). This way users could downgrade easily if they noticed a problem in the window, but we wouldn’t need to double the size of rawhide. This is bug https://bugzilla.redhat.com/show_bug.cgi?id=1082830
The final one is around mashes blacklists and whitelists. Right now mash has a number of different multilib methods (basically 32bit support for 64bit trees). In those there’s some packages that are whitelisted (always get added) and some blacklisted (always removed), but this is hard coded into a file in mash, meaning that you have to do a new release or patch locally to get changes in. This should be config options so you can dynamically adjust them on the fly. This is bug https://bugzilla.redhat.com/show_bug.cgi?id=1082832
If anyone wants to work on those, patches welcome. 🙂