X-CD-Roast is Roasting
Jan. 25th, 2007 03:13 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
swestrupIt took something like four hours of work, but I've finally gotten XCDRoast working on Webigail again. So now I can once more make backup DVDs.
XCDRoast, it turns out, relies on a command line program called cdrecord, maintained by someone else. It used to have a variant called cdrecord-ProDVD that could record DVDs. In order to use the free version, you needed to register for a free time-limited DVD key, which I did.
Eventually, of course, it ran out. Only, you can't get the keys any more, because the DVD writing feature is now just part of the newest version of cdrecord, now called cdrtools.
Fine, I would install the latest version, but currently RPM is broken on Webigail (something else I will need to spend many (more) hours fixing sometime). So, I had to download the source and compile it.
It needed a version of gdk-pixbuf installed. Now, I had that package installed, but it didn't have some of the required files for the compilation, so I downloaded its source, and compiled and installed it. That, at least, went off without a hitch. (although with RPM broken, I can't record the fact I've overwritten an installed RPM...)
Then I compiled the cdrtools, and installed them, only to discover they installed to /opt/schily/bin, not /usr/bin where the current versions are. (Of course, I ended up having to scan the whole file system to figure out where the damn files were installed to.) If there were any way to tell it to install elsewhere, it wasn't in the docs, and cdrtools doesn't use configure for its configurations either. Then again, the docs haven't really been updated since 2004. There have been many revisions of the code since then, but version numbers have only incremented from 2.01.01alpha1 to 2.01.01alpha23. Am I the only one who thinks that's insane?
Okay, so I write a script to find all files in /usr/bin that have counterparts in /opt/schily/bin, back them up, and create soft-links to the new versions. This, I imagine, is minimally disruptive.
Then I try to run xcdroast, and discover that this version isn't compatible with the latest cdrecord. I have to download the source for that too, and then patch it to deal with the latest latest updates that broke compatibility.
Even then, xcdroast would only run if I invoked it as root (because it seems kernel 2.6 broke user space writing of DVDs) and added a '-n' parameter to tell it not to check the version number of cdrecord because it can't parse version numbers like 2.01.01alpha23. (apparently the previous version had been patched to produce a different format of version number...)
And so, after all that, I managed to burn a DVD, although I did have to grovel around in /dev to find out what device name to use.
Is it any wonder that I keep saying Linux isn't ready for prime time yet?
XCDRoast, it turns out, relies on a command line program called cdrecord, maintained by someone else. It used to have a variant called cdrecord-ProDVD that could record DVDs. In order to use the free version, you needed to register for a free time-limited DVD key, which I did.
Eventually, of course, it ran out. Only, you can't get the keys any more, because the DVD writing feature is now just part of the newest version of cdrecord, now called cdrtools.
Fine, I would install the latest version, but currently RPM is broken on Webigail (something else I will need to spend many (more) hours fixing sometime). So, I had to download the source and compile it.
It needed a version of gdk-pixbuf installed. Now, I had that package installed, but it didn't have some of the required files for the compilation, so I downloaded its source, and compiled and installed it. That, at least, went off without a hitch. (although with RPM broken, I can't record the fact I've overwritten an installed RPM...)
Then I compiled the cdrtools, and installed them, only to discover they installed to /opt/schily/bin, not /usr/bin where the current versions are. (Of course, I ended up having to scan the whole file system to figure out where the damn files were installed to.) If there were any way to tell it to install elsewhere, it wasn't in the docs, and cdrtools doesn't use configure for its configurations either. Then again, the docs haven't really been updated since 2004. There have been many revisions of the code since then, but version numbers have only incremented from 2.01.01alpha1 to 2.01.01alpha23. Am I the only one who thinks that's insane?
Okay, so I write a script to find all files in /usr/bin that have counterparts in /opt/schily/bin, back them up, and create soft-links to the new versions. This, I imagine, is minimally disruptive.
Then I try to run xcdroast, and discover that this version isn't compatible with the latest cdrecord. I have to download the source for that too, and then patch it to deal with the latest latest updates that broke compatibility.
Even then, xcdroast would only run if I invoked it as root (because it seems kernel 2.6 broke user space writing of DVDs) and added a '-n' parameter to tell it not to check the version number of cdrecord because it can't parse version numbers like 2.01.01alpha23. (apparently the previous version had been patched to produce a different format of version number...)
And so, after all that, I managed to burn a DVD, although I did have to grovel around in /dev to find out what device name to use.
Is it any wonder that I keep saying Linux isn't ready for prime time yet?
