Hi, Jeffrey Walton wrote: > This problem comes up several times a year on the mailing list. Can > you find a place to memorialize it, like <https://wiki.debian.org/>?
I am not aware that wodim is often topic here. Currently nothing else comes to me than "don't use wodim if you don't have to". And that would be inappropriate because my software is a competitor of wodim and genisoimage. But i can demonstrate that cdrskin can handle the situation in Trixie. Without the link from /dev/scd0 to /dev/sr0 i get: $ cdrskin --devices ... 0 dev='/dev/sr0' rwrw-- : 'QEMU ' 'QEMU DVD-ROM' ... $ cdrskin drive_scsi_dev_family=sg --devices ... 0 dev='/dev/sg2' rwrw-- : 'QEMU ' 'QEMU DVD-ROM' ... $ cdrskin drive_scsi_dev_family=scd --devices ... cdrskin: NOTE : No usable drive detected. cdrskin: HINT : Run this program as superuser with option --devices cdrskin: HINT : Allow rw-access to the dev='...' file of the burner. cdrskin: HINT : Busy drives are invisible. (Busy = open O_EXCL) cdrskin: Overview of accessible drives (0 found) : ... $ If the /dev/scd0 link exists, then: $ cdrskin drive_scsi_dev_family=scd --devices ... 0 dev='/dev/scd0' rwrw-- : 'QEMU ' 'QEMU DVD-ROM' ... $ (Maybe cdrskin and xorriso should also point to the fact that /dev/scd is outdated.) Max Nikulin wrote: > Do you know precise range of affected kernel versions? > return ( 0==uname( &buf ) && sscanf(buf.release, "%d.%d", &gen, &tmp)>1 && tmp>=6); > The major kernel version is ignored here. Return value of sscanf is the > number of matched and assigned values. Indeed. The author's compulsion to write a one-liner confused me. So any minor versions < 6 causes the search for /dev/sg* devices, which will normally find the available optical drives, whereas other minor versions will search for /dev/sdc* and find nothing. > You found it several years ago: > "Re: wodim --devices and -scanbus bugs 495184, 655878, 833346" > - <https://bugs.debian.org/495184#112> > - <https://bugs.debian.org/655878#10> > - <https://bugs.debian.org/833346#35> Just 8.5 years. I need to take memory strengthening pills or move my brain into AI. > My conclusion that there is severe problem with package development and > maintenance. There seems to be no public code repository either. > That is why I earlier asked if xorriso may be a replacement. Rather cdrskin, which can do audio, CD-TEXT, and CDRWIN CUE files. xorriso restricts itself to single-track data sessions. The CD use cases knwon to me which demand wodim or cdrecord are: - Mixed mode recording of audio plus data. - Non-audio, non-mode-1 sector formats. Options -raw, -raw96r, -raw96p, -raw16, -mode2, -xa, -xa1, -xa2, -xamix. Needed e.g. to produce weirdly copy protected CDs or to fulfill Microsoft's demand for XA mode in multi-session ISOs with Joliet extension. (Nothing bad was ever reported after not obeying that demand.) > Can k3b be configured to use "ssh wodim.local wodim ..." instead of just > "wodim" (or a shell script wrapper)? Can't tell for current versions. Some distros seem to have tried to put in cdrskin for cdrecord or wodim: https://discuss.kde.org/t/k3b-unable-to-find-cdrskin/34742 I myself explored this way successfully about 18 years ago: https://scdbackup.sourceforge.net/k3b_on_cdrskin.html It has to be expected that the complete user interface of K3B was overthrown several times since then. Have a nice day :) Thomas
