This week, the temp has been up to 72F. But this morning...

I am a happy smithj :)

I've been using mercurial for awhile now, for conary (hg.rpath.com), but in doing so I've only really used basic functionality. I've really liked that the distributed model allows me to work when not connected to a network, as is necessary for systems such as CVS. Anyway, an issue came up where it would be desirable to use source control to work on a third party project, namely fedora/redhat initscripts, which are in a CVS repo. I went to the mercurial website to see if there were conversion tools, and noticed a project (done by the guys who write darcs, yet another source control system) to push and pull from one system to another. I set up a simple config file (mostly machine generated) and pulled the entire archive from anon cvs into an hg repo. I then set up a cron job to pull from fedora hourly and dump into that repo and now I can merge from fedora to mine whenever necessary. To put it mildly, this is better than the mass o patches I was otherwise faced with. Mercurial makes this unbelievably easy, and if you haven't checked out mercurial and tailor, you should do so now :-).

Since our alpha release a few weeks ago, we've been very busy getting rpl:devel full of new features. In addition to simple things like gnome-2.16.1, we've bumped glibc to 2.5 to enable the much faster GNU_HASH, updated the toolchain to use that hash and stack smashing protection, one of the coolest things about gcc-4.1.

Other changes include linker optimizations (-O1), and inclusion of Position Independent Executables in many programs. Xorg-x11-7.1 comming soon :)

I have recently been working on ways to clean up the recipes in conary.rpath.com@rpl:devel. I have noticed a large amount of code duplication and forcing recipe writers to know things about how packages are built internally that they should not be required to know. Thus, I've been working to remove these hurdles to creating good packages with conary. Two recent changes include adding an RPMPackageRecipe superclass and enabling conary to automatically detect patchlevels.

RPMPackageRecipe is a superclass defined in the rpmpackage recipe in conary.rpath.com@rpl:devel. It allows individuals to easily pull *source* and patches from Fedora or RHEL RPMs. This enables removing the srpm= lines in curent rpm-based recipes. It also enables unpacking the tarball and applying designated patches with one simple command... r.unpack(). Since AutoPackageRecipe already uses r.unpack() (which is normally defined in the recipe), its possible to use both at once to create an elegant and maintainable recipe, as shown below:

loadSuperClass('rpmpackage')
class Hesiod(RPMPackageRecipe, AutoPackageRecipe):
    name = 'hesiod'
    version = '3.1.0'
    rpmRelease = '4'
    rpmPatches = [ 'hesiod-3.0.2-env.patch', ]

Thats it! The entire recipe is contained in those 6 lines. The previous version was 17 lines... quite an improvement in my view. If you have more questions as to what some of the options mean, or even what options there are, "cvc co rpmpackage=conary.rpath.com@rpl:devel" and have a look; the code is pretty simple.

If you want to use the superclass for your own recipes, add a line before your class defination saying:
loadSuperClass('rpmpackage=conary.rpath.com@rpl:devel')
Also, you will need to actually inherit from RPMPackageRecipe in your class. See above or any of the rpl:devel changes I've recently been making for examples.

A common problem with this method, though, is that the patch command for the superclass assumed the patchlevel was 1, and failed otherwise. Some Fedora patches ship with patchlevel 0, causing us a problem and making the superclass less than useful. A good example of this is grub in rpl:devel. To fix this problem, I took an idea from Gentoo Portage's econf and modified conary such that it would try to patch with patch level 1 and then try 0,2,3 (in that order) until the patch applied. If the patch did not, then instead of giving an interactive prompt like patch normally likes to do, conary now exits with an error. If, for some reason, you still need to specify the level manually, this is still supported. Note that this is in conary tip and should arrive as part of 1.0.19. These two changes cut the grub recipe from 110 lines to 44.

So kenvandine has gotten me hooked on gnome, but not the GNOME you're probably imagining. Its GNOME with fluxbox as the WM. GNOME support will be optional, but will be hacked so that it defaults to flux and everything Just Works. I will also make something byDefaultFalse so that it works on one CD, but I don't know what yet.

Input is appreciated :-)