I've added links on my Linux page and my Links page to Torrentocracy. This is a project I am working on which combines RSS + Bit Torrent + Your TV. In a nutshell, it enables a cool new way for you to get the media (audo/video) which you watch on your TV.

When it dawned on me that when I move to California in September, I won't be able to take my Time Warner DVR with me, I decided to cut the commercial teather and build my own dvr. Using the afore-linked HOWTO to setup MythTV I was probably able to save myself a ton of heartache, but the process has not been entirely smooth. In fact, until I saw this message on the users list yesterday, there was a good 10 day period where I couldn't figure out why my system magically stopped showing tv video (I'm an apt noob and got burned by an automatic bad upgrade ... guess i'm in-apt ... sorry, bad joke).

Anyway, in back-revving to the working version of ivtv, I realized it is a perfect candidate to be dkms-ified. One Sunday afternoon later, and here you go (or directly at ivtv-0.1.9-25dkms.noarch.rpm). This DKMS-enabled ivtv RPM contains both the utility portions of the ivtv package pre-compiled as well as the ivtv driver source which DKMS then builds for whatever kernel you're running (which means it replaces both the old ivtv RPM and the the ivtv-kmdl RPM).

From what I've seen with mythtv, the previous convention was to use "kmdl" to mark kernel driver RPMs, but why limit yourself to pre-compiled binaries for only one kernel at a time, when you can utilize DKMS to do all the dirty work for you? Moreover, you can satisify the hard-core types that only want to build from source on their own box while satisfying us lazies who just rely on an RPM. Plus, now, as you boot into new kernels, DKMS will automatically build and install the ivtv package for you (assuming you have your kernel sources installed). If people think this is a worthwhile thing, let me know and I'll perhaps go repackage the other kmdl rpms for myth.

Oh yes, and speaking of feedback, does anybody know:

- How I can convince X that my TV is not as wide as it thinks? I'm using a Hauppauge 350 card, and while the tv output fits the screen perfectly, all the background myth menus get the left hand sides cut off. Also, for some reason, they mythconfigure pays no attention to my X and Y offsets which I would think would be useful in attenuating this problem.

- Why audio is coming out of the RCA audio jacks on the 350 and not the headphone jack? I direct the audio into the MIC of my soundcard, but when I then output that through my stereo, it's rather crackly.

- Why when I try to bring the menu up during live tv playback, it hangs my entire system?

As you can tell, it's all a work in progress. But hopefully dkms will make this process easier for everyone.

The March edition of Dell's Power Solutions magazine includes a paper I co-authored with Matt Domsch on Simplifying Linux Management with Dynamic Kernel Module Support. It's more current than the Linux Journal article and is also focused more towards using dkms from the systems administration perspective.

Yesterday, I stumbled across blogs.redhat.com. It looks like they got off the ground towards the beginning of March and are currently chronicling their "state of Linux" world marketing tour. I'd be skeptical of dark-side marketers too, but I did see this: "I'm the manager of the Marketing Communications department at Red Hat. I'm one of the people fighting to keep Red Hat from becoming too Corporate and Capitalized." We shall see. Apparently, they're making a documentary.

Today marks the arrival of http://linux.dell.com. I've been working on getting site setup inside Dell for some time now. It serves as Dell's "customer-supported" resource aggregator. More specifically, my hosting of the devlabel and dkms projects will move there.

Devlabel - http://linux.dell.com/devlabel
DKMS - http://linux.dell.com/dkms

Be sure to check out the "What's New" section for a blog of Dell Linux Updates:

http://linux.dell.com/blog

Devlabel 0.45.01 is now available (tarball or RPM):

* Added a check in scsi_unique_id written by Dan Clark to determine if Page80/Page83 indentifier data are supported before checking for the identifier. This was suggested in Red Hat Bugzilla #112585 to help with older devices which might not support these fields.

Devlabel 0.44.01 is now available (tarball or RPM):

* The ignore_list is now kept in /etc/sysconfig/devlabel.d and not /var/lib/devlabel. Though /var/lib is generically a more appropriate place for application state information to live, it was necessary to have these files located on the root partition. This is to make sure that these files are available during boot after the root partition has been mounted but before any other partition has been mounted (such as /var).

Devlabel 0.43.18 is now available (tarball or RPM):

* Changed the check for root user until after it ensures that /usr/bin is in the system PATH to ensure that usage of the program /usr/bin/id works correctly.

DKMS 1.00 is now available (tarball or RPM):

* Bumped the version to 1.00. That's all.

I just stumbled over some good documentation on the usage of devlabel in Red Hat's Enterprise Linux 3 System Administrators Guide. I've gotten some emails of people looking for this specific type of thing, so hopefully this will fill that need.

Interestingly, at work on Friday, a co-worker and I discovered that when you plugged a usb key into his old desktop system with a funky cd-rom drive, devlabel's algorithm to find the device's uuid was causing the cdrom to eject the cdrom drive every 30 seconds. Our conjecture was that scanning for the devices uuid was, for some internal design reason of the cdrom, causing a bus reset which led to the eject action. Happily with the latest devlabel which implements an internal ignore list to avoid such bad devices, the problem went away. Unfortunately, the older devlabel is on the RHEL 3 gold cds.

DKMS version 0.99.01 is now available (tarball or RPM):

* Bumped the version to 0.99 to convey impending 1.00 release status. The intention is to iron out any remaining issues and move out of beta phase in the coming weeks.

* Added MODULES_CONF_OBSOLETE_ONLY[#] directive array available in dkms.conf. This array, when set to "yes", informs DKMS to only modify /etc/modules.conf if it finds an obsolete reference within it as specified in the MODULES_CONF_OBSOLETES[#] array.

* Changed DKMS so it will now only bother to remove /etc/modules.conf entries during an uninstall if REMAKE_INITRD is set, or if you are uninstalling your module from the last kernel that it is installed on.

* Fixed mktarball so that the file that it creates cannot have a filename >255 chars

* Updated the man page

DKMS 0.46.04 is now available (tarball or RPM):

* DKMS mktarball --binaries-only now includes a copy of the dkms.conf within the tarball such that ldtarball can load a binaries only tarball if you specify --force. This is still a bad idea, however, since if you load a binaries-only tarball into your DKMS tree without the module source already added to your tree, you won't be able to build the module using DKMS.

* dkms_autoinstaller now installs to /etc/init.d instead of /etc/rc.d/init.d for cross-distro happiness.

DKMS 0.45.01 is now available (tarball or RPM):

* Changed the logic behind when modules.conf gets edited during a remove. Previously, after a remove would complete, DKMS would automatically re-add references into modules.conf for that module regardless of whether the module which was just removed was active on that kernel or not. Now, DKMS only adds the references back into modules.conf if that module was active for that kernel and, if and only if, there is at least one other kernel which still has that module installed on it.

* Added hugemem kernel prep support for RH hugemem kernels.

DKMS 0.44.05 is now available (tarball or RPM):

* Changed $MODULES_CONF_ALIAS_TYPE to an array that is a part of the $BUILT_MODULE_NAME[#] / $DEST_MODULE_NAME[#] array family. This allows you to specify different alias types for different modules within a single DKMS package. $MODULES_CONF_OBSOLETES[#] (explained below) is also part of this directive array family.

* Added DKMS directive array $MODULES_CONF_OBSOLETES[#]. This directive should be used to specify the modules that your newer module makes obsolete. During install, DKMS will look for entries for these modules in /etc/modules.conf if the corresponding $MODULES_CONF_ALIAS_TYPE[#] entry is set and will remove these. As you uninstall modules, DKMS will first try to put an original module back into the kernel. If it does this, it will leave the reference to the non-obsolete module in modules.conf. If no original_module exists in the kernel, but an obsolete module does, DKMS will put the obsolete module reference back into modules.conf and remake the initrd. If neither exist, it will just remove the non-obsolete reference and replace it with nothing.

* As well, the $MODULES_CONF_OBSOLETES directive can be used to specify multiple modules which are made obsolete. This should be done by setting the variable to a comma-delimited list (eg. ="megaraid,megaraid_2002"). During uninstall, if no original module is found, DKMS attempts to instead use an obsolete module giving priority to the leftmost entry in the variable.

* Updated the man page to better explain how DKMS handles modules.conf changes.

DKMS 0.42.03 is now available (tarball or RPM):

* Added --binaries-only option usable during mktarball. This will create a DKMS tarball which does not contain source. This helps in keeping down the size of the tarball if you know that the target system already has the source installed. DKMS will only load a binaries-only tarball with ldtarball, if the target system already has source for that module/module-version added to the tree. If it does not, DKMS will not load the binaries-only tarball and will exit out.

DKMS 0.41.15 is now available (tarball or RPM):

* During install of a module, if depmod or mkinitrd fail, it automatically backs out of the install and goes back to the built state

* During uninstall of a module, if mkinitrd fails, it warns loudly.

DKMS 0.41.11 is now available (tarball or RPM):

* Moved dkms from /sbin/dkms to /usr/sbin/dkms

* Thanks to the work of Matt Domsch, there is now a Red Hat kernel preparation routine which removes the time consuming make dep stage for module builds on Red Hat kernels. In order to utilize this improved process, you kernel sources must be in a pristine state as delivered by the Red Hat kernel-source RPM (they've never had make dep or make mrproper run on them). So, if you've previously used DKMS for a kernel, you'll either have to reinstall your kernel source, or stick with the "General" preparation routine as before.

* Added /usr/sbin/dkms_mkkerneldoth to enable the quicker Red Hat prep routine

* Fixed a bug in dkms_autoinstaller which was causing it not to run correctly

* Fixed a bug during uninstall where original_modules were not actually getting reinstalled even though it told you they were

* Fixed DKMS to unset all arrays before using them.

* Changed expected driver disk file "module-info" to "modinfo" in order to support legacy Red Hat driver disk formats

* Fixed mkdriverdisk such that it actually copies the rhdd-6.1 file into the driver disk image

* Kernel makefiles are no longer edited during kernel preparation. Instead KERNELRELEASE=$kernel_version is passed to make commands.

* Removed the unnecessary depmod during uninstall of a module

Devlabel 0.43.16 is available (tarball or RPM):

* Created a device ignore list in /var/lib/devlabel/ignore_list such that devlabel can keep track of devices it shouldn't query for IDs since it knows they won't return IDs and likely will only spew errors to the screen instead. The ignore_list is cleared every time devlabel is restarted or after /proc/partitions has changed since the last time devlabel has run.

* The previous version (0.42.05) had a bug in it due to the way it used sfdisk -V to determine if a device should be ignored or not. This bug will make devlabel unable to use any device that has trivial problems in its partitioning scheme (eg. paritition does not end on a cylinder boundary). This has been fixed in this version.

* Added mktemp as a required package.

DKMS 0.40.11 is available (tarball or RPM):

* `dkms add` no longer copies dkms.conf and any post script into the /var/dkms tree. To avoid duplication, it now just uses these directly from the source_tree in /usr/src/<module>-<module_version>/. This change to the tree architecture caused me to bump the dkms_dbversion from 1.00 to 1.01.

* Got rid of the options --postadd, --postremove, --postinstall and --postbuild. Replaced these with equivalent directives in dkms.conf POST_ADD=, POST_REMOVE=, POST_INSTALL= and POST_BUILD=. This was to go along with the above change. All script path names should be given relative to the root directory of your module's source.

* Added the flag --rpm_safe_upgrade. This flag should be used in all dkms-enabled RPM modules during the ADD and REMOVE. Thus, in your spec file, all adds should be: dkms add -m <module> -v <version> --rpm_safe_upgrade. All removes in RPM spec files should now be: dkms remove -m <module> -v <version> --all --rpm_safe_upgrade. Using this rpm_safe_upgrade flag makes sure that in all RPM upgrade scenarios (rpm -Uvh), dkms behaves appropriately. See the man page for more details.

* Added a sample dkms.conf to /usr/share/doc (called sample.conf)

DMKS 0.39.17 is available (tarball or RPM):

* Modified mktarball format to remove dependency on $source_tree and $dkms_tree. This means that regardless of these values between systems, you can now count on the tarball to properly load on another system with ldtarball. Note that because of this, any tarball made with mktarball before this version will not load properly anymore.

* Modified ldtarball to handle the new mktarball format. As well, ldtarball can now be used on any tar archive which contains a dkms.conf within it. It first checks to see if the tarball is made by mktarball. If not, it then finds the dkms.conf within the archive and then adds that archive to the dkms tree. This is very handy and can serve as an unpack routine as discussed in this thread.

* Ldtarball now uses the --archive option instead of the --config option. --archive is new and was created to alleviate any confusion over options.

* Added --kernelsourcedir option as well as $kernel_source_dir DKMS variable to allow specification of an alternate kernel source directory if it is not found as expected in /lib/modules/$kernelver/build

* Driver disk files for Red Hat driver disks are now looked for within the ./redhat_driver_disk directory within your sources

* Added $tmp_location variable available in /etc/dkms_framework.conf to specify an alternate location for your systems /tmp directory. The default is /tmp.

* Added diff checking in status command. Now, when a module is in the installed state, dkms checks to make sure that the module in the /lib/modules tree matches the one saved within the DKMS tree. This will help alleviate confusion if other packages start overwriting things that DKMS has put into place.

* Changed the build-arch of the RPM to noarch as my beautiful shell scripts are arch independent.

* Other miscellaneous changes which are available within the SRPM spec file changelog.

Here's a good Dell Linux read with the above title. You can find it here.

Also, there's an interview with a Dell exec about Dell's Linux strategy for the Sky Radio Network (the one for the airlines). Hear it here.

DKMS 0.38.03 is available (tarball or RPM):

* Fixed mkdriverdisk to correctly create kernel/driver tree within the driver disk modules.cgz

* Added support in mkdriverdisk to put modules for more than one kernel within the disk image. With Red Hat installs, this will allow the RH installer to place these extra modules directly into the various kernels it installs on your system (smp, etc).

* Moved driver_disk directory location to underneath the $module_version directory. This is more fitting since driver disks can now contain modules from various kernels.

* Fixed a temp_dir_name typo in ldtarball.

Over on domsch.com, Matt has uploaded a DKMS enabled megaraid2 RPM which we put together today.

You can download it here.

DKMS 0.37.10 is available (tarball or RPM):

* Don't allow installs of modules onto kernels which don't exist

* Suppressed stderr on the output of some commands

* Fixed brain dead bug for REMAKE_INITRD

* During uninstall, don't remake initrd if it was never installed

* Fixed ldtarball to first unload into a unique temp directory and then clean up after itself.

DKMS 0.37.04 is now available (tarball or RPM):

* Changed PATCH directives to an array based system. All patch filenames should be given in the PATCH[#] array. If the patch should only be applied when building for certain kernels, then a corresponding regular expression should now be placed in the PATCH_MATCH[#] array which matches against those kernels. This new array system is not only cleaner, but allows matching against regular expressions (ala egrep) whereas the old system was limited to substring matches. If no corresponding entry is found in PATCH_MATCH, then the patch will automatically be applied.

* Changed MAKE directives to an array based system. The default make command should now be specified in MAKE[0]. All other MAKE directives should fill out this array and will only be used if their corresponding regular expression in the MAKE_MATCH[#] array matches against the kernel being built for.

* Changed the MODULES_CONF directive to an array based system.

* Fixed known-filename exploit issues in invoke_command (thanks to Oron Peled: oron () mail ! artcom ! co ! il ).

* Changed autoinstaller bootup priority from 08 to 04.

DKMS version 0.36.05 is now availabel (tarball or RPM):

* In dkms.conf, when specifying the name of your module, you should no longer append the .o or .ko to the end. Instead, based on what kernel you are building a module for, DKMS will figure out the suffix (if <2.5 then .o, otherwise .ko) and will work appropriately. The example below shows this change from the old format to the new.

* Removed the DKMS directives LOCATION and MODULE_NAME. Replaced them with the arrays BUILT_MODULE_NAME[#], BUILT_MODULE_LOCATION[#], DEST_MODULE_NAME[#] and DEST_MODULE_LOCATION[#]. This allows much more flexibility in finding and renaming modules and placing them in various locations of your /lib/modules tree. Whereas, before you would specify something like:

MODULE_NAME="qla2200.o:qla2200_6x.o qla2300.o:qla2300_6x.o"
LOCATION="/kernel/drivers/addon/qla2200"

you would now specify it as:

BUILT_MODULE_NAME[0]="qla2200"
DEST_MODULE_NAME[0]="qla2200_6x"
DEST_MODULE_LOCATION[0]="/kernel/drivers/addon/qla2200"

BUILT_MODULE_NAME[1]="qla2300"
DEST_MODULE_NAME[1]="qla2300_6x"
DEST_MODULE_LOCATION[1]="/kernel/drivers/addon/qla2200"

This above example doesn't show usage of BUILT_MODULE_LOCATION which is optional. This is used if your built modules are spread out within your source tree, and you need dkms to find them. It should be given relative to the root directory of your module source (eg. relative to the directory which holds your dkms.conf file).

If you do not intend to rename the modules after they have been built, then DEST_MODULE_NAME is optional. As stated above, with DEST_MODULE_LOCATION, you can now install each module to different locations in your /lib/modules tree.

Devlabel 0.42.05 is available (tarball or RPM):

* Added a work-around for devices with bad partition tables. For example, on USB floppy devices containing floppy disks marked as bootable, linux currently errantly reports that the device has 4 partitions even though it does not. Devlabel was probing these bad partitions for UUIDs and this was causing kernel I/O errors. The work-around tells devlabel to ignore partitions which come from devices with messed up partition tables.

There's actually a little bit of irony surrounding this, as I had been tasked to root cause I/O errors in Red Hat's latest beta, only to find out it was my own software which was exacerbating this problem. Of course, if the kernel reported partitions correctly, this would never have reared its face. Still humorous though.

Looks like Dell has a couple new commercials which make reference to Linux. I believe this might be a first, so be sure to keep your eyes open during prime time and football games. Here's a link to the commercials. The ones of interest are "Cold Call" and "Let's Do Lunch".

DKMS version 0.35.01 is now available (tarball or RPM):

* Added PACKAGE_VERSION and PACKAGE_NAME as directives available in dkms.conf. These are strict requirements and DKMS will not function without these present (because these are strict requirements, I also revved the example QLogic DKMS driver which you may need to now download).

This feature was added at the request of Cyril Bortolato who is the creator of gmodconfig. Gmodconfig is a GUI which is intended as a simplified module management system for inexperienced (and experienced) Linux users. It uses dkms as a back-end to install modules and you can read more about it from its kernel-traffic nod.

As well, you can read the thread on the dkms-devel mailing list which spurred these additions.

DKMS 0.34.10 is now available (tarball or RPM):

* Added the dkms_autoinstaller service (/etc/rc.d/init.d/dkms_autoinstaller). Its purpose is to automatically install modules during bootup onto kernels which do not already have that module installed for it. It only does the install, though, if AUTOINSTALL="yes" is set in that module's dkms.conf. If multiple versions of the same module exist in DKMS, the autoinstaller does not install that module and warns appropriately.

* Added the AUTOINSTALL="yes" option available in dkms.conf. See above.

* Added the --no-prepare-kernel and --no-clean-kernel cli options. These were needed to create the autoinstaller service but might be applicable in other areas. --no-prepare-kernel skips any kernel preparation before building a module whereas --no-clean-kernel does not clean the kernel after building a module.

My article on DKMS is now web-accessible to the public. You can read it here.

Here's the errata advisory for the 2.4.20-20.9 errata kernel now available from Red Hat to fix "obsure" bugs. Much respect goes to Robert Hentosh and Matt Domsch of Dell whom I both work with for diagnosing and fixing these race conditions. They don't mention this errata should likely also help fix large memory support for RH9.

I have a 4 page piece about DKMS in this month's Linux Journal. The article can be found here online, but requires a paid subscription to Linux Journal. Go pick a copy up at your local bookstore.

DKMS version 0.33.02 is now available (tarball or RPM):

* Add /var/dkms/dkms_dbversion to track the versioning of the underlying database structure used in DKMS. This is currently set at 1.00.

* Fixed bugs in match which was causing it to fail when matching against multiple modules.

* Added Fred Treasure to the author's list for his SuSE/UL work.

I've resisted commenting on the SCO controversy until now. In anycase, IBM has finally come out and responded pointing out SCO's own distribution of their alleged code. I'm glad someone finally came out and said this. The whole thing is pure Linux FUD.

A couple guys at work just got back from the Ottawa Linux Symposium where apparently there was little discussion on SCO and its implications. That sort of complacency is interesting and probably warranted, but somehow I think at LinuxWorld next week this won't be the case. What else to expect at a marketing driven event? We'll have to see.

Anyway, come visit me in the Dell booth.

Been away from the blog lately mostly moving into my new place and getting it setup. Well, now with everything in order and me blogging via my new 802.11a setup, its only appropriate to include some links on the impending desktop linux explosion.

Walmart sells SuSE desktops

and

Munich makes Microsoft squirm

The latter story isn't really news, but its an interesting in-depth account. Now if only it was actually easy to setup my home wifi we'd be well on our way.

Matt Domsch and I are holding a BOF session about DKMS at the upcoming LinuxWorld. Get more details here.

DKMS version 0.32.04 is now available (tarball or RPM)

* Added support for 2.5 kernels. Specifically, if it detects that you are building for >2.4, it uses a generic make command (make -C $kernel_source_dir SUBDIRS=$build_dir modules) which makes use of advances in the 2.5 kernel series. Also, it doesn't do a make dep (though for SuSE, it still does a make CONFIG_MODVERSIONS=1 dep since I didn't know whether to take this out or not...advice?).

* Added SuSE initrd support. Now, if it detects the SuSE type mk_initrd command, it modifies /etc/sysconfig/kernel if REMAKE_INITRD is set and then calls mkinitrd which should remake all initrds which it knows about. Only during the final removal of a module are the changes removed from /etc/sysconfig/kernel. Because of this methodology, mkinitrd will often return exit status 9 since it attempts to remake all initrds and some kernels don't have the module you just added.

* Changed the kernel preparation stuff so that it does UnitedLinux prep stuff if it finds /boot/vmlinuz.version.h, but otherwise will do RedHat/generic prep routines.

Looks like the slashdot-effect traffic is finally starting to cool down. As a follow-up, given this comment the Axim uptime and usability has dramatically increased. Basically, if you go into Settings > Light & Power > Suspend after, and set it to "never", the panics mostly go away. Looks like they weren't kidding when they said suspend was broken.

Also, a slight rant from something I've learned from this heavy traffic experience. If you run a professional site dedicated to a certain field with a professional looking interface, then you should probably be smarter than to steal bandwidth from others (especially smaller non-commercial websites). In this case, a couple sites (mobi-mania.com and mypdacafe.com) both put my axim pic on their front page-- meaning that for every hit their site got, I too got one for 40K. The term "netiquette" sounds somewhat antiquated by now, but come on guys. Host your own images if you're gonna put them on the forefront of your site. Many thanks to http://www.pocketpcthoughts.com for their courteousness.

Here's the slashdot posting about Linux running on the Axim. Well timed since my monthly bandwidth allotment starts fresh tomorrow.

*** This use of the Dell Axim is not supported by Dell ***

Thanks to the great work of Martin Demin over at handhelds.org, it is now possible to run Linux on the Axim. It currently only supports load from RAM (not ROM) which means you boot it from Windows, but it's a start. Specifically, if you follow these instructions made available by Steve Johnson it's pretty easy. Though, beware that it currently kernel panics after about 15 minutes, and when you do the hard reset, it boots back into Windows at factory default settings (meaning, you lose any files you might have stored on it).

Touchscreen, sound, lcd, serial port, buttons and charging all currently function. Much work still remains on things like the power button, screen rotation support, battery indicator, and loading it into the actual flash ROM, but this really is a great start. Check out the picture below...running a 2.4.19 based kernel on the Familiar Linux distribution.

I've included all this information on my linux page so that these links are readily available outside of this blog entry.

Devlabel version 0.41.01 is now available (tarball or RPM).

* Fixed up scsi_unique_id to better handle identifier types. Specifically, as per the SCSI spec, it now checks page83 identifiers for their association value. If this value is non-zero, the ID is not considered stable and so scsi_unique_id no longer returns it. Thanks to Tom Coughlan (coughlan () redhat ! com) for pointing this out.

* Fixed devlabel to handle multiple identifiers of the same page and type. In this case it just concatenates the ids to form one large identifier.

Zach Brown picked up my post to the linux-kernel mailing list regarding the addition of SuSE support to DKMS. Here's the kernel-traffic write-up.

Devlabel version 0.40.03 is now available (tarball or RPM).

* Changed reverseremap so that if a device returns a bad UUID or no longer exists, it comments out that entry in /etc/sysconfig/devlabel.

* Added a %pre and %post in the RPM which detects if you are using an old version of devlabel which has the old formatting for UUIDs. If it detects this, it calls a devlabel restart before the upgrade (to make sure the values in column 2 are up to date) and after the upgrade it calls a reverseremap (to fix the UUIDs).

Red Hat has accepted devlabel-0.38.07 and it is currently being served up in their RawHide section. Look for the updated version in their next distro. Until then, you can get the RPM right here.