[opensuse-factory] RFC: Drop cdrdao
Hi all, the various gnome*mm packages (last refreshed in ~ 2009) become more and more obsolete and painful to maintain; pretty much every new version of glib, gtk, other library keeps on breaking them. Looking at candidates to drop, I currently come across: libgnomecanvasmm libgnomeuimm libgnomeuimm depends as only package in Factory on libgnomecanvasmm, so dropping them together is a good start. There is one more package in Factory depending on libgnomeuimm: cdrdao (actually, the gui part gcdmaster. Frankly, looking at screenshots of this tool, I doubt anybody is seriously still using this. Hence the proposal: - Drop cdrdao As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm. Options? Comments? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 16, 2013 at 3:13 PM, Dimstar / Dominique Leuenberger <dimstar@opensuse.org> wrote:
Frankly, looking at screenshots of this tool, I doubt anybody is seriously still using this.
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
I think, under some circumstances, k3b uses it. Not sure when it's able to use wodim instead, I've seen it use one or the other and I haven't figured out the pattern. So, removing the UI of cdrdao does look like a better choice. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 16 Apr 2013 20:26, Claudio Freire <klaussfreire@...> wrote:
On Tue, Apr 16, 2013 at 3:13 PM, Dimstar / Dominique Leuenberger <dimstar@opensuse.org> wrote:
Frankly, looking at screenshots of this tool, I doubt anybody is seriously still using this.
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
I think, under some circumstances, k3b uses it.
Not sure when it's able to use wodim instead, I've seen it use one or the other and I haven't figured out the pattern.
So, removing the UI of cdrdao does look like a better choice.
on OSS 12.3 if k3b is installed, both cdrdao and cdrkit-cdrtools-compat are pulled in as Require, see list [list] /usr/bin/cdrdao /usr/bin/cdrecord /usr/bin/mkisofs /usr/bin/readcd config(k3b) = 2.0.2-26.1.2 dvd+rw-tools ... [/list] Give a shout to the kde-list if you want that changed AFAIK cdrdao is just the cli, no gui. If you want to eliminate some gui's and lib for them, that's fine Wrong construct:
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
gcdmaster needs libgnomeuimm and cdrdao but cdrdao does need neither. see "rpm -q --requires cdrdao" So dropping libgnomeuimm (and thus gcdmaster) is a matter for the gnome team to decide. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Die, 2013-04-16 at 22:13 +0200, Yamaban wrote:
on OSS 12.3 if k3b is installed, both cdrdao and cdrkit-cdrtools-compat are pulled in as Require, see list
[list] /usr/bin/cdrdao /usr/bin/cdrecord /usr/bin/mkisofs /usr/bin/readcd config(k3b) = 2.0.2-26.1.2 dvd+rw-tools ... [/list]
oh.. obs nicely ignore those when querying.. thanks!
Wrong construct:
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
gcdmaster needs libgnomeuimm and cdrdao
except that gcdmaster is built from the cdrdao sources :) it's not an independent package maintained by the gnome team.. promise ! ( I would know otherwise). Byt, as already stated earlier: an SR against cdrdao is pending to kill the GUI, but maintain cdrdao functionality. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 16.04.2013 20:13, schrieb Dimstar / Dominique Leuenberger:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Options? Comments?
I did not even know there is gcdmaster, but I use cdrdao quite often to rip and write CDs. Of course if I am the only one, it can also live in home:seife and we can drop it from Factory :-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 16.04.2013 21:48, schrieb Stefan Seyfried:
Am 16.04.2013 20:13, schrieb Dimstar / Dominique Leuenberger:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Options? Comments?
I did not even know there is gcdmaster, but I use cdrdao quite often to rip and write CDs.
Of course if I am the only one, it can also live in home:seife and we can drop it from Factory :-)
You are not the only one. The only one I know or ever used from above is cdrdao. Not saying there is nothing else which could do the work. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 16.04.2013 20:13, schrieb Dimstar / Dominique Leuenberger:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Options? Comments?
I did not even know there is gcdmaster, but I use cdrdao quite often to rip and write CDs.
cdrdao is unmaintained since aprox. 5 years. .....and the audio extract quality from cdrdao is worse than the one from cdda2wav. Why do you use cdrdao? Is there simething I miss or do you just not know enough about cdda2wav? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 17.04.2013 00:08, schrieb Joerg Schilling:
Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 16.04.2013 20:13, schrieb Dimstar / Dominique Leuenberger:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Options? Comments?
I did not even know there is gcdmaster, but I use cdrdao quite often to rip and write CDs.
cdrdao is unmaintained since aprox. 5 years.
.....and the audio extract quality from cdrdao is worse than the one from cdda2wav. Why do you use cdrdao? Is there simething I miss or do you just not know enough about cdda2wav?
I'm not Stefan but in my case I do not use cdrdao often but when I do I used it to backup (S)VCDs. cdda2wav is only for Audio CDs AFAICS. I never looked for cdrdao alternatives to do that but I'm open for suggestions. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2013-04-17 09:33, Wolfgang Rosenauer wrote:
cdrdao is unmaintained since aprox. 5 years.
.....and the audio extract quality from cdrdao is worse than the one from cdda2wav. Why do you use cdrdao? Is there simething I miss or do you just not know enough about cdda2wav?
I'm not Stefan but in my case I do not use cdrdao often but when I do I used it to backup (S)VCDs. cdda2wav is only for Audio CDs AFAICS. I never looked for cdrdao alternatives to do that but I'm open for suggestions.
You can create images with readcd(1) and then load them using cdemu, the latter of which is in openSUSE already. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> wrote:
I never looked for cdrdao alternatives to do that but I'm open for suggestions.
You can create images with readcd(1) and then load them using cdemu, the latter of which is in openSUSE already.
Correct, cdrtools is a set of specialized commands. - cdrecord writes CDs, DVDs, BluRay - cdda2wav reads audio CDs - readcd reads Cds, DVDs, BluRay and includes support to support sub-channels (all meta data) for CDs. Implementing best Audio CD extract features would e.g. have been hard to implement inside cdrecord as cdrecord was optimized for writing and thus uses different data structures. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
cdrdao is unmaintained since aprox. 5 years.
.....and the audio extract quality from cdrdao is worse than the one from cdda2wav. Why do you use cdrdao? Is there simething I miss or do you just not know enough about cdda2wav?
I'm not Stefan but in my case I do not use cdrdao often but when I do I used it to backup (S)VCDs. cdda2wav is only for Audio CDs AFAICS. I never looked for cdrdao alternatives to do that but I'm open for suggestions.
This is intersting: Have you been able to copy (s)vcd's using cdrdao? If yes, when did you do it first? I tried it once after this feature was announced for cdrdao and it did not work, so I was forced to implement the needed features in cdrtools that time... in Summer 2001. cdda2wav definitely can do more features and better than cdrdao, it e.g. by default checks for hidden tracks, and it of course includes a working portable cdparanoia module. cdda2wav -vall -cddb=1 No target specified, trying to find one... Using dev=1,0,0. Type: ROM, Vendor 'TEAC ' Model 'DV-W5000E ' Revision '1.0H' MMC+CDDA 274432 bytes buffer memory requested, transfer size 57344 bytes, 4 buffers, 24 sectors #Cdda2wav version 3.01a13_sunos5_5.11_i86pc_i386, real time sched., soundcard, libparanoia support 17482 sectors of audio data before track #0, audible data at sector 112. Hidden audio track with 17482 sectors found. AUDIOtrack pre-emphasis copy-permitted tracktype channels 0- 0 no no audio 2 AUDIOtrack pre-emphasis copy-permitted tracktype channels 1-17 no no audio 2 Table of Contents: total tracks:17, (total time 58:32.25) 0.( 3:53.07), 1.( 3:42.18), 2.( 2:43.25), 3.( 3:35.60), 4.( 1:47.67), 5.( 3:26.35), 6.( 3:52.33), 7.( 3:00.25), 8.( 2:35.67), 9.( 3:52.33), 10.( 3:46.00), 11.( 2:44.30), 12.( 3:12.17), 13.( 4:17.70), 14.( 3:54.35), 15.( 5:00.35), 16.( 3:07.60) 17.( 3:52.15), Table of Contents: starting sectors 0.( 0), 1.( 17482), 2.( 34150), 3.( 46400), 4.( 62585), 5.( 70677), 6.( 86162), 7.( 103595), 8.( 117120), 9.( 128812), 10.( 146245), 11.( 163195), 12.( 175525), 13.( 189942), 14.( 209287), 15.( 226872), 16.( 249407), 17.( 263492), lead-out( 280907) CDINDEX discid: TmdzNJXgs95gE8MsG.UDMS1ivw4- CDDB discid: 0xf10db811 CDDBP titles: resolved CD-Text: not detected CD-Extra: not detected Album title: '13' [from Die Ärzte] Track 0: '' Track 1: 'Punk ist ...' Track 2: 'Ein Lied für Dich' Track 3: 'Goldenes Handwerk' Track 4: 'Meine Freunde' Track 5: 'Party Stinkt' Track 6: '1/2 Lovesong' Track 7: 'Ignorama' Track 8: 'Nie wieder Krieg, nie mehr Las Vegas!' Track 9: 'Rebell' Track 10: 'Der Graf' Track 11: 'Grau' Track 12: 'Angeber' Track 13: 'Männer sind Schweine' Track 14: 'Liebe und Schmerz' Track 15: 'Nie Gesagt' Track 16: 'Der Infant' Track 17: 'Grotesksong' No media catalog number present. T: 1 ISRC: DE-D57-98-02870 T: 2 ISRC: DE-D57-98-02880 T: 3 ISRC: DE-D57-98-02890 T: 4 ISRC: DE-D57-98-02900 T: 5 ISRC: DE-D57-98-02910 T: 6 ISRC: DE-D57-98-02920 T: 7 ISRC: DE-D57-98-02930 T: 8 ISRC: DE-D57-98-02940 T: 9 ISRC: DE-D57-98-02950 T: 10 ISRC: DE-D57-98-02960 T: 11 ISRC: DE-D57-98-02970 T: 12 ISRC: DE-D57-98-02980 T: 13 ISRC: DE-D57-98-02990 T: 14 ISRC: DE-D57-98-03000 T: 15 ISRC: DE-D57-98-03010 T: 16 ISRC: DE-D57-98-03020 T: 17 ISRC: DE-D57-98-03030 index scan: 1... Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 16 April 2013 20:13:39 Dimstar / Dominique Leuenberger wrote:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Dropping cdrdao might be a No-No :-) As Claudio already indicated k3b has current a hard requirement for cdrdao, however this is without the gui frontend. So let's keep cdrdao and drop the gui part Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Die, 2013-04-16 at 22:02 +0200, Raymond Wooninck wrote:
On Tuesday 16 April 2013 20:13:39 Dimstar / Dominique Leuenberger wrote:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Dropping cdrdao might be a No-No :-) As Claudio already indicated k3b has current a hard requirement for cdrdao, however this is without the gui frontend. So let's keep cdrdao and drop the gui part
Then you should probably fix k3b to actually Require cdrdao :) https://build.opensuse.org/package/binary?arch=x86_64&filename=cdrdao-1.2.3-8.1.x86_64.rpm&package=cdrdao&project=openSUSE%3AFactory&repository=standard => gcdmaster and brasero are so far the only ones requiring it :) anyway: I submitted a request to Base:System getting rid of gcdmaster.. this looks really like the best approach. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 16 April 2013 21:08, Dimstar / Dominique Leuenberger <dimstar@opensuse.org> wrote:
On Die, 2013-04-16 at 22:02 +0200, Raymond Wooninck wrote:
On Tuesday 16 April 2013 20:13:39 Dimstar / Dominique Leuenberger wrote:
Hence the proposal: - Drop cdrdao
As an alternative, we should as a minimum at least get rid of gcdmaster and the dependency of cdrdao on libgnomeuimm.
Dropping cdrdao might be a No-No :-) As Claudio already indicated k3b has current a hard requirement for cdrdao, however this is without the gui frontend. So let's keep cdrdao and drop the gui part
Then you should probably fix k3b to actually Require cdrdao :)
It requires /usr/bin/cdrdao. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Raymond Wooninck <tittiatcoke@gmail.com> wrote:
Dropping cdrdao might be a No-No :-) As Claudio already indicated k3b has current a hard requirement for cdrdao, however this is without the gui frontend. So let's keep cdrdao and drop the gui part
Sure? k3b happily uses cdrtools if present. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 16, 2013 at 7:11 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
Dropping cdrdao might be a No-No :-) As Claudio already indicated k3b has current a hard requirement for cdrdao, however this is without the gui frontend. So let's keep cdrdao and drop the gui part
Sure?
k3b happily uses cdrtools if present.
Yeah, that's wodim. But I've seen k3b use cdrdao at times, not sure why. Maybe something cdrdao supports that wodim doesn't, but DAO is not that something since wodim supports it just fine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire <klaussfreire@gmail.com> wrote:
On Tue, Apr 16, 2013 at 7:11 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
Dropping cdrdao might be a No-No :-) As Claudio already indicated k3b has current a hard requirement for cdrdao, however this is without the gui frontend. So let's keep cdrdao and drop the gui part
Sure?
k3b happily uses cdrtools if present.
Yeah, that's wodim.
You seem to missunderstand things: k3b tries to avoid this fake whenever possible. k3b authors know that "wodim" and friends is unmaintained crap and full of bugs. If the original software is available, k3b of course uses cdrecord and friends.
But I've seen k3b use cdrdao at times, not sure why.
Maybe something cdrdao supports that wodim doesn't, but DAO is not that something since wodim supports it just fine.
wodim is a "fork" from a cdrtools version from September 2004. The only "development activity" that could be seen was to introduce new Debian specific bugs. Since May 5th 2007, it is fully unmaintained. So the current situation is: - cdrdao is unmaintained since October 2009 (the last new functionality has been added in Summer 2004). - "cdrkit" (wodim) is unmaintained since it's beginning and it is based on archeoligical versions of the original software. You thus should not be surprized that it misses more than 50% of the features of current software. This is why I don't like to compare cdrdao with "wodim".... or do you like to use a version of the Linux kernel from 2004 when you know that development did not stop? I currently know of no feature from cdrdao that is not also in cdrtools. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Apr 17, 2013 at 5:42 AM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
k3b happily uses cdrtools if present.
Yeah, that's wodim.
You seem to missunderstand things: k3b tries to avoid this fake whenever possible. k3b authors know that "wodim" and friends is unmaintained crap and full of bugs. If the original software is available, k3b of course uses cdrecord and friends.
But I've seen k3b use cdrdao at times, not sure why.
Maybe something cdrdao supports that wodim doesn't, but DAO is not that something since wodim supports it just fine.
wodim is a "fork" from a cdrtools version from September 2004. The only "development activity" that could be seen was to introduce new Debian specific bugs. Since May 5th 2007, it is fully unmaintained.
I guess the situation is more dire than I thought, then, if *both* are unmantained. Then again, both worked fine for me since they stopped being maintained. Perhaps they're "mature" instead. Anyway, I'll try to catch k3b using one or the other then, from what you say, that shouldn't happen on a single system right? I must have seen one system use cdrdao while another uses wodim. That's more likely. Regardless, k3b currently has cdrdao as hard requirement so it can't be dropped. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Claudio Freire <klaussfreire@gmail.com> wrote:
wodim is a "fork" from a cdrtools version from September 2004. The only "development activity" that could be seen was to introduce new Debian specific bugs. Since May 5th 2007, it is fully unmaintained.
I guess the situation is more dire than I thought, then, if *both* are unmantained.
Then again, both worked fine for me since they stopped being maintained. Perhaps they're "mature" instead.
While cdrdao (as long as you don't like more features than it currently supports) could be called "mature", wodim is no more than crap. There are more than 100 well documented bugs and there was never any attempt to fix them.
Anyway, I'll try to catch k3b using one or the other then, from what you say, that shouldn't happen on a single system right? I must have seen one system use cdrdao while another uses wodim. That's more likely. Regardless, k3b currently has cdrdao as hard requirement so it can't be dropped.
You may drop cdrdao without getting into trouble if you install cdrtools instead, but you cannot if you only have wodim. wodim is ancient software that misses most of the features. Also if you like to create bug-free ISO-9660/RR/Joliet/UDF filesystem images, you better use the original "mkisofs" instead of the broken "genisoimage" that is part of "cdrkit" (wodim). Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Claudio Freire -
Cristian Morales Vega -
Dimstar / Dominique Leuenberger -
Jan Engelhardt -
Joerg Schilling -
Raymond Wooninck -
Stefan Seyfried -
Wolfgang Rosenauer -
Yamaban