It's been a little while since my last rawhide post. Things have been busy. Fedora 23 has branched off rawhide heading for it's Alpha release hopefully next week. A number of people have hit a common issue with rawhide recently and I thought I would talk some about that. Namely, it's getting a rawhide release installed, ie, the install path. Once you have an install, things are usually not that bad. DNF hides broken deps from you, you get the updates you can apply and things roll right along. However, the upgrade path is a really hard one which we should fix. First of all, in order to produce a rawhide compose at all, the following have to work:

1. The rawhide comps xml file from https://git.fedorahosted.org/cgit/comps.git has to be valid and usable. If this breaks, the compose fails and nothing is produced.
2. The chroot that rawhide compose runs it needs to have no broken deps and is installable. This is what you get when you do a mock --init
3. The chroot has to be able to install: "koji yum createrepo make intltool findutils mash yum-utils rsync repoview hardlink"
4. mash (in the chroot) has to run and complete ok.

Once that happens the compose will finish (even if parts of it are broken after that). In order to produce a boot.iso for the day:

1. mock has to be able to --init a chroot
2. All of: "pungi nfs-utils setarch" have to be installable and have no broken deps.
3. lorax has to be able to run and produce images (This requires no broken deps from anything in the set of things on the boot.iso).

So, as you can tell things can (and do) break down in various places. Recently there was a rpm build that changed soname. This meant that a few of the tools in step 2 of the base case above had broken deps, so result was no rawhide compose at all for those days. Then there was a broken dep in grub2, which meant the boot.iso couldn't be created. Then, finally today there was a broken dep in tigervnc which meant no boot.iso. So, there's two obvious approaches to try and make all these parts better, we could take one or both of them. :) We could gate builds entering rawhide and run some kind of dep check on them. I have a plan for how we could do the gating part pretty simply today, but dependency checking is pretty hard. It might be we could leverage taskotron for this, but not sure. And/or, we could just try and fail faster/quicker. Identify the packages in all the above sets we need to be working and anytime any of them change we try and build a new iso or test compose. If it fails we ring loud alarm bells. We could then even untag the offending build if it cannot be fixed quickly. Right now failures are not very visible, and they really should be so that everyone in the community can work to make sure they get fixed. I'm running a workshop at flock next week on friday afternoon (yeah, I know, but still). I do hope interested parties will be there and we can try and make rawhide installable for everyone all the time. :) http://flock2015.sched.org/event/6c9cb5cd93903549d911c58e5cc71533