WODIM refused to blank CD-RW media

[daf]

What happened: WODIM refused to blank CD-RW media UNTIL i did so with official cdrtools from Schily.
What I expected to happen: I expected WODIM to blank and write my CD-RW's. Silly me.
How to repeat: Not sure. Since once using the offical cdrtools package, my problem seems to have vanished. To be honest though, I had some major issues trying to burn a CD-R the other day, and made a rather impressive selection of coasters. THANKS, WODIM.

The long story:

I've been reading up on the debate between Schily and the Debian dev team -- I have to admit I was biased from the start, thinking that Schily was just pompous twit. My most sincere apologies to Mr Schily. WODIM, installed in Intrepid, refused to blank CD-RW media, alternately claiming that the device was in use and that it was unable to open the scsi bus. The device WASN'T in use (DEFINITELY NOT mounted, or anything else running against it). Rebooting (hey, it fixes Windows ;p ) didn't help -- the problem persisted. Note that I also tried cdrskin, which is supposed to be a thin wrapper aroung libburn, with the same results -- the device was permanently "locked". Note that this particular machine has been upgraded (not reloaded) at least 3 times (7.10-8.04-8.10), that I can remember. Perhaps more. And it's only been in 8.10 where this has become an issue.

I downloaded Schily's 2.01.01a55 version of cdrecord, compile and installed. K3b (yes, I use GNOME, but there is no burning GUI that I have ever used (*nix or win32) which can compete with k3b, except perhaps older versions of Nero (<6), before the dev team hired a pack of turd-throwing, crack-smoking chimps to redesign what WAS a clear, usable interface) picked it up without configuration (huzzah!), and I could once again blank and write CD-RW media WITHOUT ISSUE. Oddly enough, after having dispelled the bad juju, wodim decided to co-operate, and will now blank and write CD-RW media. Not good enough for me -- I'm leaving my Schily tools as the default in k3b.

Ubuntu already breaks the "total freedom" concept of Debian by providing items such as the NVIDIA/ATI binary blobs and official Firefox artwork (to name just the most commonly-known culprits). I have no problem with this as it means that the average Joe user can get a working Linux machine without having to rise to the status of 1337 h4x0r; this is good for Linux and the user in general. My question then, is why are we still subscribing to the broken wodim? I'm all for the Free alternative, but I rather subscribe to Linus' approach: "free" or not, the BEST solution always wins. And it's not like Schily's cdrtools isn't actually free -- it's just not GPL, but I have other licenses which live side-by-side on my system (MPL, GPL, BSD, to name just a few). I just don't get how this made it past QA (and I have a very high opinion of Ubuntu QA). For a non-tech user out there, this would have been a show-stopper. A "switch back to that crappy Other OS" moment.

Requested info:
output from 'lsb_release -rd'
Description: Ubuntu 8.10
Release: 8.10

[Florian Diesch (diesch)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we can't fix it because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.

If you ever can reproduce this bug we'd be grateful if you would call wodim with the options '-dd -V ' and attach the complete output here.

This is not the right place to discuss the wodim vs. cdrecord issue. It has discussed a lot in various places in the past; if you still feel the need for discussion you can reach the developers in the ubuntu-devel-discuss mailing list https://lists.ubuntu.com/mailman/listinfo/Ubuntu-devel-discuss

To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ .

[daf (davydm)]

Thank you for pointing me at an old article about how to report bugs. Fortunately for me, I am a software developer myself, and I have an understanding of what is required to report a bug (and, sometimes, to my delight, how to fix one too). Unfortunately for this bug report, I did provide all of the information that I was privy to, with the knowledge I had available to me.

I also bothered to read the Ubuntu Launchpad guidelines for reporting a bug, hence the "Requested Info" section (which I thought was a bit sparse, but hey, that's what was requested). Perhaps the Launchpad needs a feature added: "how to get extra information pertaining to this specific package which will help the developers to resolve your issue". Obviously, this would be different for different packages. Once again, despite your attempt at diplomacy, I don't appreciate a glossed-over RTFM.

Thanks also for pointing me at the Ubuntu Code of Conduct, so that I may remain more diplomatic in the face of adversity, though tuly the only true disrespect was shown for the Nero development team, which is neither here nor there in the scheme of this bug report. The rest is true: wodim has provided endless issues for countless users, and provided myself with a most impressive (but ultimately useless) stack of shiny coasters in the past, and shown the ubiquitous desire to not function at all until the path was paved by schily tools.

I can, however, glean the one item of actual value from your response: what information would assist you in resolving this bug (running wodim -dd -V). I certainly do understand the benefit of having more information reported for the resolution of a bug. It would be super-cool if that kind of requirement could have been presented to me at the time of the bug report -- I might have actually provided it.

Should the problem recur, I will be most delighted to attach more information. It might also be in the interests of the wodim development team to examine Mr Schilling's work -- the problem in wodim might become glaringly obvious. I have a feeling that the schily cdrecord prods the drive in some way that wodim doesn't. Since wodim is just a fork from a prior version, surely one could diff the two trees to find out what cleverness Mr Schiling is up to (though he has alluded to permission issues in online postings)? I know it's a tedious job, but the dividends might be worth it.

If the above comments are too inflammatory, please just ignore them. I have done my best to edit out some of my more biting comments, in the interests of actually trying to achieve a constructive end-goal.

[Thomas Schmitt (scdbackup)]

I'm developer of cdrskin and quite late with this comment, i fear.
But for the records:

Without seeing the original error message of cdrskin, i can only
guess that the problem is some O_EXCL usage of the drive
(by some automat).
One can keep cdrskin from respecting such Linux specific locks
by its option --drive_not_exclusive .

For finding the culprit of the suspected open(O_EXCL), one
should try a command like:

  lsof | fgrep /dev/sr0

--------------------------------------------------------------------------------

To those who take care for the support here:

Be invited to notify me about any report where cdrskin, xorriso
or the underlying libraries are mentioned with problems.
E.g. via: <email address hidden>

[Schily (schilling-fokus)]

Why should someone use cdrskin as long as there is a maintained
working version of the original cdrtools?

BTW: There are many problems with wodim:

- it is based on a very old version of cdrtools (~ 4 years)

- it's maintainers added plenty of bugs because these people do not grok
  enough from SCSI passthrough coding and confused well designed features
  with so called "bugs". While "fixing" these so called "bugs", they introduced
  many of the well known problems.

- It's maintainers do not understand the problems in the hald implementation.
  This is the actual problem from the current bug report

- the named fork is in conflict with Copyright and GPL and cannot be legally
  distributed.

The original version of cdrtools however does not have any of the named
problems. It is well maintained and did add a lot of new and very interesting
features during the past years.

Note that there was an agreement with Debian on March 6th 2009 with the
help from Simon Phipps (Sun). Debian will include the original cdrtools again
very soon.

[daf (davydm)]

All I can say is "Huzzah".

Actually, I can say more. Something along the lines of "about time too".

Thomas: Sorry I couldn't provide more information. Please excuse the acidity of my original posts. The first was out of sheer frustration and the second was in response to a backhanded RTFM, which was not at all called for.

I've upgraded to Jaunty recently. Brasero seems to be behaving at the moment, obviously using wodim (according to the package depends at least; though I *thought* that brasero levered off of libburn?). I hope that the re-inclusion of cdrtools will provide much-needed stability and functionality to other projects (eg libburn), or will just simply replace them where possible (eg wodim -- no need to flog a dead horse when you have a new one on hand).

CDRTools coming back to Debian and derivatives is a win for the users.

[Launchpad Janitor (janitor)]

[Expired for cdrkit (Ubuntu) because there has been no activity for 60 days.]

[Schily (schilling-fokus)]

daf: Unfortunately Debian did break their promise after trying to delay a definitve action for a long long time.

Fortunately, there are other users that are unhappy with the problems in cdrkit and created a Ubuntu binary package.