On Tue, 16 Apr 2013 20:26, Claudio Freire wrote:

On Tue, Apr 16, 2013 at 3:13 PM, Dimstar / Dominique Leuenberger 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

Stefan Seyfried 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

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

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.

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 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

Raymond Wooninck 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

Claudio Freire wrote:

On Tue, Apr 16, 2013 at 7:11 PM, Joerg Schilling 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

Claudio Freire 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