After a fresh emerge an amd64, calling xcdroast as root fails with ** (xcdroast:13946): WARNING **: Failed to access cdrecord. Please check the permissions and ownership of /usr/bin/cdrecord # equery list xcdroast ... [I--] [ ~] app-cdr/xcdroast-0.98_alpha16 (0) # ll /usr/bin/cdrecord lrwxrwxrwx 1 root root 5 31. Jan 09:01 /usr/bin/cdrecord -> wodim # ll /usr/bin/wodim -rwxr-xr-x 1 root root 393K 31. Jan 09:01 /usr/bin/wodim # grep "cdr" /etc/group cdrom::19:haldaemon,... cdrw::80:haldaemon,... This report arises from http://bugs.gentoo.org/show_bug.cgi?id=243246#c12 ff.
src/xcdroast.h explicitly defines: /* this paths can be specified relative to lib-dir or absolute */ /* xcdroast will look for these first in $LIBDIR/ and if not found then in $PREFIX (e.g. /usr/bin/cdrecord instead of /usr/local/lib/xcdroast-0.98/bin/cdrecord) */ #define CDRECORD "bin/cdrecord" #define CDDA2WAV "bin/cdda2wav" #define READCD "bin/readcd" #define MKISOFS "bin/mkisofs"
Hi Manfred, all, the problem is that xcdroast dropped the cdrkit patches. I think there are two solutions to the problem: 1) xcdroast ebuild depends not on the virtual 'cdrtools', but the package app-cdr/cdrtools, because cdrkit is not a drop-in replacement for cdrtools. 2) the patches which added cdrkit (wodim and icedax) support to alpha15 should be updated and applied to alpha16 cdrecord is part of cdrtools package. xcdroast is based on cdrtools/cdrecord. cdrkit is a package forked from cdrtools because of licensing issues, and it installs the symlink you've shown from /usr/bin/cdrecord -> /usr/bin/wodim
Created attachment 185572 [details] Solution number 1. I've emailed Thomas asking whether he'd add the wodim/icedax support upstream. I have a feeling it's not going to meet with approval though.
(In reply to comment #3) Sorry, solution 1 :)
After unmerging cdrkit first, I can happily confirm that this -r1 ebuild is installing from my local overlay on my amd64, and the xcdroast application fires up. Thank you !! Andrew, I share your bias towards moving to cdrkit in the near future.
No worries Manfred, but actually I don't think moving over to cdrkit would be a good idea. cdrkit although having a GPL license is less well maintained, has less features, and doesn't have perfect compatibility with cdrtools, as the problem with xcdroast demonstrates. I think it's fair to give cdrkit a chance, which is why virtual/cdrtools was set up I guess. But it's not so fair to create extra work for maintainers because of the code required to emulate compatibility. If cdrtools works best and the licensing isn't an issue (bear in mind huge numbers of people are happy with the nvidia kernel module license!) then cdrtools wins.
(In reply to comment #6) I absulutely agree with your balancing of values. To complete my partial CONFIRMATION from above comment #5 : I have successfully burnt with -r1. Many thanks again! Kind regards Manfred
Please attach diffs when you did changes to an ebuild. That would be much more handy for our devs :)
Created attachment 185784 [details] The diff righto :)
yeah.. i'm not going to start backporting them, feel free to open a new bug if you want to do so i'd start with http://packages.debian.org/sid/xcdroast since that's where the cdrkit basically comes from changed the dep to app-cdr/cdrtools
