Launchpad has imported 68 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=507108.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-06-20T21:54:38+00:00 Maciej wrote: I'd like to ask, why on every Fedora system I install I have to manually install cdrecord/mkisofs (since wodim rarely works correctly, often failing to finalize images, etc). According to the spec file for cdrtools, the cause was some licensing issues. According to the original author: http://cdrecord.berlios.de/private/linux-dist.html Fedora should be free to include cdrtools as an rpm. What's the problem? Could the decision to drop cdrtools be re-examined? At least make it an optional package? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/3 ------------------------------------------------------------------------ On 2009-07-22T11:01:25+00:00 Nikola wrote: Our lawyers have other view to this problem. If this issue will be solver I'd glad make a new package and maintained it. See: https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.htm Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/4 ------------------------------------------------------------------------ On 2009-07-22T22:10:45+00:00 Maciej wrote: https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.htm is a 404 from where I'm browsing the web... Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/5 ------------------------------------------------------------------------ On 2009-07-22T22:13:18+00:00 Maciej wrote: https://www.redhat.com/archives/fedora-legal- list/2009-July/msg00000.html is probably the URL you meant. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/6 ------------------------------------------------------------------------ On 2009-07-23T07:17:29+00:00 Nikola wrote: (In reply to comment #3) > https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.html is > probably the URL you meant. Yes that's it. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/7 ------------------------------------------------------------------------ On 2009-07-31T13:41:48+00:00 Jörg wrote: The redhat/fedora URL you mention above contains FUD :-( The person who wrote the mail (somebody who calls himself "tom") confirms that he is no lawyer and from reading his mail it it obvious that he is even missing basic legal skills. The cdrkit "fork" is in conflict with the copyright law and cannot be distributed legally. The initiators of the fork have been informed in detail about the copyright problems but they are not interested in making the fork legal. Why is Readhat distributing software that cannot be legally distributed? Why does readhat consider unmaintained software? The fork did _never_ _ever_ in it's full lifetime deliver any even halfway bug free release. There are more than 100 well documented bugs in the fork, many of them have been created by the initiators of the fork. There is no viable project activity anymore since May 6th 2007. The original software however is if course legal and this has even be verified by several lawyers. see: http://cdrecord.berlios.de/private/linux-dist.html for more information (updated). Note that the original software is well maintained and that reported bugs are usually fixed within a few hours. This is why the original software did deliver more than 50 releases that had no known bugs at time of release during the lifetime of the "fork". Redhat should decide whether Redhat is interested in distributing legal software that is to the benefits of it's users or whether redhat like to continue to distribute illegal software that does not even work correctly. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/8 ------------------------------------------------------------------------ On 2010-04-27T15:07:22+00:00 Bug wrote: This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/11 ------------------------------------------------------------------------ On 2010-04-28T09:37:47+00:00 Jörg wrote: The current problem with Readhat is not fixed by making a specific Redhat release outdated. It is a general problem that RedHat ships the fork "cdrkit" that cannot be legally distributed but refuses to ship the legal original software. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/12 ------------------------------------------------------------------------ On 2010-06-01T10:11:27+00:00 Michael wrote: I just want to add that I am *forced* to build the original cdrecord on Fedora to get a reasonable experience. Out of the box, writing discs is horribly slow, often fails or even worse: it seems to succeed but the resulting medium is not really usable. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/17 ------------------------------------------------------------------------ On 2010-06-01T10:38:33+00:00 Jörg wrote: As you are not alone and as there are people on other platforms that created own binary packets, it would be a nice idea to also create redhat packages for cdrtools. Let me give some background information: cdrtools-3.0-final will be out within this week SuSE includes packages for the original software since September 2009 after a private person created these packages for a longer time. Since a while there are binary packages for Ubuntu created by private people. RedHat seems to be the only remaining white spot that misses recent software. Are you able to help with creating a binary package for RadHat? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/18 ------------------------------------------------------------------------ On 2010-06-01T12:34:12+00:00 Susi wrote: (In reply to comment #5) > The cdrkit "fork" is in conflict with the copyright law > and cannot be distributed legally. The initiators > of the fork have been informed in detail about the copyright > problems but they are not interested in making the fork legal. You don't seem to get the concept of free software. When you released cdrtools under the GPL, at that moment you gave permission to take the code and fork it as according to the license. Those versions are still under the GPL. You just not might not be able to call the fork "cdrecord"; that's why it's called cdrkit. (In reply to comment #9) > As you are not alone and as there are people on other platforms > that created own binary packets, it would be a nice idea to also > create redhat packages for cdrtools. So do so. > SuSE includes packages for the original software since > September 2009 after a private person created these packages > for a longer time. A *private* person. It's not a part of SuSe. > Since a while there are binary packages for Ubuntu created by > private people. Again, *private* people, not Ubuntu. > RedHat seems to be the only remaining white spot that misses > recent software. No, you've just shown yourself that other distributions such as SuSE and Ubuntu do not include the CDDA-licensed cdrtools, either. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/19 ------------------------------------------------------------------------ On 2010-06-01T15:15:44+00:00 Jörg wrote: (In reply to comment #10) > (In reply to comment #5) > > The cdrkit "fork" is in conflict with the copyright law > > and cannot be distributed legally. The initiators > > of the fork have been informed in detail about the copyright > > problems but they are not interested in making the fork legal. > > You don't seem to get the concept of free software. When you released cdrtools > under the GPL, at that moment you gave permission to take the code and fork it > as according to the license. Those versions are still under the GPL. You just > not might not be able to call the fork "cdrecord"; that's why it's called > cdrkit. You don't get the concept of Open Source Software and you don't get the concept of a legal system and the concept of a legal pyramid. The Copyright law rules everything that is not mentioned in a license and in addition it even forbids some things to be ruled in a license in in a way that is in conflict with the law. > (In reply to comment #9) [Some missunderstood comments removed] I cannot comment things that you did completely missunderstand. > > RedHat seems to be the only remaining white spot that misses > > recent software. > > No, you've just shown yourself that other distributions such as SuSE and > Ubuntu > do not include the CDDA-licensed cdrtools, either. Cdrtools is "collective work" that is _fully_ compliant with OSS. The CDDL is a _fully_ accepted OSS license. No license mix exist in the cdrtools: every single project (work) is completely under a single license. Even the GPL is an acepted OSS License and thus _needs_ to meet the rules in http://www.opensource.org/docs/definition.php so the GPL _cannot_ forbid to ship different projects under different licenses in the same tar ball. And last: Suse included cdrtools in the official list of packets. I have no idea why RedHat is not following the rules of the OpenSource Initiative that is the only neutral and unbiased entity in OSS rules. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/20 ------------------------------------------------------------------------ On 2010-06-21T06:44:23+00:00 Whistler wrote: http://cid-29bdd7826332657e.office.live.com/browse.aspx/.Public /cdrtools-fedora?uc=4 fedora 13 x64 packages of cdrtools 3.0 adapted from opensuse srpm. Note that I just chmod u+s'ed cdrecord binary so there might be security issues. I don't care about it though as I doubt it would be accepted into fedora. Still wondering why someone keeps interpreting the license crap differently from rest of the world even after several years which caused all of the issue though :( Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/25 ------------------------------------------------------------------------ On 2010-06-22T09:53:44+00:00 Jörg wrote: Hi Whistler, could you please send your "spec file" or whatever is needed to build a redhat rpm? A friend is currently trying to use suse's build service to build for all Linux target platforms (including redhat), but he seems to have problems. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/26 ------------------------------------------------------------------------ On 2010-06-23T02:49:30+00:00 Whistler wrote: Created attachment 426139 spec file the spec file is included in the srpm. I've attached it separately Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/27 ------------------------------------------------------------------------ On 2010-06-23T02:57:26+00:00 Whistler wrote: anyways I do hope the GPL'ed stuff in cdrtools (specially mkisofs) can be relicensed to CDDL as well though, which would fix everything. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/28 ------------------------------------------------------------------------ On 2010-06-23T07:29:29+00:00 Roman wrote: Just run rpmlint; rpmlint cdrtools.spec cdrtools.spec:5: W: non-standard-group Productivity/Multimedia/CD/Record cdrtools.spec:32: W: non-standard-group Development/Libraries/Other cdrtools.spec:47: W: non-standard-group Productivity/Multimedia/CD/Record cdrtools.spec:65: W: non-standard-group Productivity/Multimedia/CD/Grabbers cdrtools.spec:79: W: non-standard-group Hardware/Other cdrtools.spec:90: W: non-standard-group Productivity/Multimedia/CD/Record cdrtools.spec:104: W: rpm-buildroot-usage %build smake INS_BASE=/usr INS_RBASE=/ DESTDIR=$RPM_BUILD_ROOT MANDIR=man cdrtools.spec:111: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/lib*.a cdrtools.spec:114: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/profiled cdrtools.spec:170: E: hardcoded-library-path in /usr/lib/siconv cdrtools.spec:171: E: hardcoded-library-path in /usr/lib/siconv/* cdrtools.spec:89: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 89) cdrtools.spec: W: invalid-url Source0: cdrtools-3.00.tar.bz2 0 packages and 1 specfiles checked; 4 errors, 9 warnings. I guess after few changes specfile could be good. Nevertheless, regard the license problems, this one is not usable in fedora. No offence, just the statement due to fedora legal... Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/29 ------------------------------------------------------------------------ On 2010-06-23T08:59:05+00:00 Jörg wrote: Unfortunately, Redhat legal does not follow usual rules for legality. The real problem seems to be that Redhat does not like the CDDL but does not tell this is the public (I have private statements from Redhat employees that verify this statement). Cdrkit is in conflict with the Copyright law and cannot be legally distributed. Redhat distributes cdrkit ignoring legal background. Cdrtools however is completely legal and completely following the rules for all used licenses (including of course the rules of the GPL). If Redhat employs real lawyers, Redhat is expected to know that any interpretation of the GPL that is not ignoring the high-order legal rules from: 1) http://www.opensource.org/docs/definition.php otherwise the GPL would not be an accepted free license 2) The US Copyright law 3) The European Copyright law of course permits the "collective works" used in cdrtools. See: http://www.osscc.net/en/gpl.html http://www.osscc.net/en/licenses.html http://www.rosenlaw.com/Rosen_Ch06.pdf http://www.rosenlaw.com/oslbook.htm http://www.osscc.net/pdf/QualipsoA1D113.pdf Note that the FSF is _very_ eager to define the GPL as a US-license and not a contract, therefore the GPL is not permitted to redefine the definition for a "derived work", see http://www.copyright.gov/title17/92chap1.html#106 and the legal essay from Tomas Gordon mentioned above. In Europe, the general conditions of business apply to the GPL and make sure that for all doubtful cases in the GPL the interpretation that is better for the licensee has to be applied. It is a commonly accepted truth that linking two independend works (like a GPLd program and a CDDLd library) just creates a collective work permitted by the GPL. A derived work is only if there was a modification of a significant threshold of originality. As you see, there are _many_ lawyers that in a legally correct way explain why there is _no_ problem in cdrtools. >From Redhat legal and from the FSF, there is only FUD but not a single legally useful statement. Do you really like us to follow people who just spread FUD? I understand that you (Roman) get payed from Redhat, so I do not expect any useful statement from you in the public, but I hope that you are still able to understand in private that your employer is an actor in an anti-OSS campaign. Note that _all_ works in cdrtools (except mkisofs) are pure CDDL and that the work mkisofs just links against libraries that are much older than mkisofs and used not only by mkisofs but by many other programs. So there is doubtlessly a permitted collective work. Do we really need to warn people about Redhat's aparent anti OSS goals or is there a chance that Redhat will act seriously in future? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/30 ------------------------------------------------------------------------ On 2010-11-04T11:03:44+00:00 Bug wrote: This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/31 ------------------------------------------------------------------------ On 2010-11-04T11:15:42+00:00 Michael wrote: Still no proper fix for this in F14. Someone should bump up the version. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/32 ------------------------------------------------------------------------ On 2010-11-04T12:46:00+00:00 Jörg wrote: This is a problem that exists independent of the fedora release. It will exist as long as Redhat continues to distribute the buggy fork. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/33 ------------------------------------------------------------------------ On 2010-11-26T14:00:36+00:00 Simone wrote: Hello, I have exactly the same problems, since its first inception cdrkit/wodim never worked for me, especially with dvds. Time has passed and now with mmc drives everywhere the compatibility has improved a bit but nevertheless most of the problems I had are still there. So here are the packages I use in my Fedora / RHEL installations. The spec file is inside the specs directory. http://www.kosgroup.com/simosimo/ http://www.kosgroup.com/simosimo/specs/ http://www.kosgroup.com/simosimo/RPM-GPG-KEY-slaanesh A few things about the packages: 1- The Epoch goes to 10 to be newer than cdrkit "obsoletes" statements and to be newer than the old epoch 9 of cdrtools that's declared in cdrkit spec file; this avoids yum loops. 2- It provides "genisoimage", "icedax" and "wodim" for the package that require them (such as Anaconda and others). No symlinks to binaries are defined. 3- It does not use the alternative system cdrkit uses, in this case I found it useless. 4- There are no patches to modify behaviour or code, binary runs as root (btw, I personally don't use it as suid and never had a single problem). 5- There's a default configuration in the /etc/default/cdrecord file that points to /dev/cdrom as default, this is for obvious compatibility reasons with Fedora defaults. My package goes into the updates of a lot of computers and works as cdrkit replacement without configuration. 6- There's a conversion of utf8 in C and man files prior to building to correctly show "ö" instead of a "?". 7- If you check the spec with rpmlint there are a few errors but you can check inside the spec files why those "errors" are there. 8- It has been built with mock on both platforms, I've cut the changelog. I'll be happy to mantain a yum repository for the latest Fedora and RHEL (x86_64 and i386) if someone gives me some little space (ftp://ftp.berlios.de/pub/cdrecord/ maybe?) Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/34 ------------------------------------------------------------------------ On 2010-11-26T14:48:59+00:00 Jörg wrote: Thank you for your work! Please note that it seems that k3b recently started to call mkisofs with -sort sortfile by default and that this will trigger a bug in mkisofs in case at least one of the files is > 4 GB. I published a new version with a fix for this problem last wednesday: ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-3.01a01.tar.bz2 BTW: future versions of cdrtools will include support for NLS and implement a workaround for the problem that UTF-8 is not able to display 8 bit UNICODE characters like ö correctly. I'll fetch your packages in the evening and probably copy them to berlios. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/35 ------------------------------------------------------------------------ On 2010-11-29T15:55:40+00:00 Roman wrote: Created attachment 463520 Fix some rpmlint errors and warnings I have played a bit with rpmlint and fix some errors and warnings. But, it needs a fix for rpmlint; see bug #657593. There is still few errors which should be fixed - rpmlint run: --- $ rpmlint cdrtools-devel-3.00-2.fc13.x86_64.rpm cdrecord-3.00-2.fc13.x86_64.rpm mkisofs-3.00-2.fc13.x86_64.rpm cdda2wav-3.00-2.fc13.x86_64.rpm btcflash-3.00-2.fc13.x86_64.rpm cdrtools-debuginfo-3.00-2.fc13.x86_64.rpm cdrtools-devel.x86_64: E: description-line-too-long C Cdrtools is a set of command line programs that allows to record CD/DVD/BluRay media. cdrecord.x86_64: E: description-line-too-long C A program to create hybrid ISO9660/JOLIET/HFS file systems with optional Rock Ridge attributes. cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/rscsi ['/usr/lib', '/opt/schily/lib'] cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/readcd ['/usr/lib', '/opt/schily/lib'] cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/cdrecord ['/usr/lib', '/opt/schily/lib'] cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/scgskeleton ['/usr/lib', '/opt/schily/lib'] cdrecord.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/scgcheck ['/usr/lib', '/opt/schily/lib'] cdrecord.x86_64: E: non-readable /usr/sbin/rscsi 0711L cdrecord.x86_64: E: non-standard-executable-perm /usr/sbin/rscsi 0711L cdrecord.x86_64: E: non-readable /usr/bin/readcd 0711L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/readcd 0711L cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L mkisofs.x86_64: E: description-line-too-long C A program to create hybrid ISO9660/JOLIET/HFS file systems with optional Rock Ridge attributes. mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isovfy ['/usr/lib', '/opt/schily/lib'] mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isodebug ['/usr/lib', '/opt/schily/lib'] mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/mkisofs ['/usr/lib', '/opt/schily/lib'] mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/devdump ['/usr/lib', '/opt/schily/lib'] mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isodump ['/usr/lib', '/opt/schily/lib'] mkisofs.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/isoinfo ['/usr/lib', '/opt/schily/lib'] mkisofs.x86_64: W: only-non-binary-in-usr-lib cdda2wav.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/cdda2wav ['/usr/lib', '/opt/schily/lib'] cdda2wav.x86_64: E: non-readable /usr/bin/cdda2wav 0711L cdda2wav.x86_64: E: non-standard-executable-perm /usr/bin/cdda2wav 0711L btcflash.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/btcflash ['/usr/lib', '/opt/schily/lib'] 6 packages and 0 specfiles checked; 24 errors, 1 warnings. --- rpaths should be removed. Any hints how to do it (and not using chrpath)? I'm not sure about permissions. Is it safe to move /usr/lib files to /usr/share in mkisofs package? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/36 ------------------------------------------------------------------------ On 2010-11-29T17:27:55+00:00 Simone wrote: Hello, thanks for feedback. Didn't know I could run rpmplint on rpms, just thought it was meant for spec files. Here are the fixed packages (only for Fedora 14 atm): http://www.kosgroup.com/simosimo/ http://www.kosgroup.com/simosimo/RPM-GPG-KEY-slaanesh 1. A rebuilt rpmlint with the fix you specified. 2. Rebuilt cdrtools rpms with most of the aforementioned warnings fixed: [slaanesh@buko repo]$ rpmlint *3.00* cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L cdrtools.src:96: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/profiled cdrtools.src:102: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/lib*.a cdrtools.src:150: E: hardcoded-library-path in /usr/lib/siconv/* mkisofs.x86_64: W: only-non-binary-in-usr-lib 7 packages and 0 specfiles checked; 5 errors, 1 warnings. A note on warnings: - cdrecord.x86_64: I personally don't run cdrecord as root and never had a single problem, can we remove this or use File Capabilities? - cdrtools.src: These are only used during the build phase, how are they marked as errors? - mkisofs.x86_64: I don't know if I can move everything somewhere else; I'l look into it. File Capabilities: https://fedoraproject.org/wiki/Features/RemoveSETUID Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/37 ------------------------------------------------------------------------ On 2010-11-29T17:43:35+00:00 Simone wrote: Added rpmlint and cdrtools packages for rhel5 at the same url. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/38 ------------------------------------------------------------------------ On 2010-11-29T17:45:57+00:00 Jörg wrote: All files that get 0711 need to be installed 04711 as they require root privileges in order to be able to do certain tasks correctly. Many applications _need_ RPATH as RPATH is the official method to let applications find their libraries in case they are not in /usr/lib. If you install all needed libs into /usr/lib, you may remove RPATH. A typical command line for this case would be: smake INS_BASE=/usr INS_RBASE=/ DESTDIR=/home/you/schilyutils/ STRIPFLAGS=-s install CCOM=gcc RUNPATH= The needed files for mkisofs are looked for in $INS_BASE/lib/siconv/ if you install the files in a different path, mkisofs will not find them and as a result not work correctly at least for all calls that create Apple extensions. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/39 ------------------------------------------------------------------------ On 2010-11-29T17:55:52+00:00 Simone wrote: Thanks for the info, since we're using packages and libraries are strictly controlled it seems RUNPATH is not needed. I made a simple sed -i -e 's@-R$(INS_BASE)/lib -R/opt/schily/lib@@g' DEFAULTS/* DEFAULTS_ENG/* in the spec file but sure passing the empty variable is much more cleaner. I'll upload a correct package as soon as possible. Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/40 ------------------------------------------------------------------------ On 2010-11-29T18:22:02+00:00 Simone wrote: Here it is again, everything updated: http://www.kosgroup.com/simosimo/ [slaanesh@buko repo.el5]$ rpmlint *3.00* cdda2wav.x86_64: E: setuid-binary /usr/bin/cdda2wav root 04755L cdda2wav.x86_64: E: non-standard-executable-perm /usr/bin/cdda2wav 04755L cdrecord.x86_64: E: setuid-binary /usr/sbin/rscsi root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/sbin/rscsi 04755L cdrecord.x86_64: E: setuid-binary /usr/bin/readcd root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/readcd 04755L cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L cdrtools.src:96: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/profiled cdrtools.src:102: E: hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/lib*.a cdrtools.src:146: E: hardcoded-library-path in /usr/lib/siconv/* mkisofs.x86_64: W: only-non-binary-in-usr-lib 6 packages and 0 specfiles checked; 11 errors, 1 warnings. Is there a way to set the option at compile time to make mkisofs look for lib/siconv files somewhere else? Fedora sets some permission on cd/dvd burners for the user that is logged into the first graphical console, I think that these permissions are enough to remove the setuid bit at least for commands that just require r/w access to the device. Is it correct? [slaanesh@buko ~]$ ls -al /dev/sr* /dev/cd* /dev/dvd* lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/cdrom -> sr0 lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/cdrw -> sr0 lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/dvd -> sr0 lrwxrwxrwx. 1 root root 3 Nov 29 08:37 /dev/dvdrw -> sr0 brw-rw----+ 1 root cdrom 11, 0 Nov 29 08:37 /dev/sr0 [slaanesh@buko ~]$ getfacl /dev/sr0 getfacl: Removing leading '/' from absolute path names # file: dev/sr0 # owner: root # group: cdrom user::rw- user:slaanesh:rw- group::rw- mask::rw- other::--- Thanks, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/41 ------------------------------------------------------------------------ On 2010-11-29T19:30:47+00:00 Jörg wrote: Cdrtools use an open development process. During the design of a new feature it is always possible to influence the implementation by making better proposals. This allows the best idea to win. The design of libsiconv happened in May 2007 and proposing to use $DEST_DIR/lib/share/siconv before the end of Summer 2007 did most likely have a 100% chance to get accepted. Now the implementation exists since 3.5 years and it seems to be too late to modify a path that exists since a long time on various platforms. Since June 2010, there is cdrtools-3.00-final and this creates a need to maintain binary compatibility. Regarding the need for suid root: The permission of the files mentioned above has little influence on the behavior of cdrtools. There are other reasons that require root privileges. There have been some people that in the past tried to remove related error messages in the code. The result of such changes has been unspecific late abortions that make it impossible to debug the related problem. In theory, Linux could be enhanced to permit a root-less installation of cdrtools. This root-less feature is possible on Solaris since at least year 2004 and since then, I am trying to get in contact with Linux distributions to add the needed features. Once a notable Linux distribution will add the needed userland support for fine-grained privileges as a non-deselectale part of the base system, I see nothing that prevents to create a root-less cdrtools installation for Linux as well. For now, there is no way to avoid suid-root for cdrtools on Linux. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/42 ------------------------------------------------------------------------ On 2010-11-30T10:27:15+00:00 Jörg wrote: Regarding file capabilties... This may be a way to avoid suid root. The URL you mentioned however does not point to the needed information: So far, I am only aware of a Linux distro from Turkey that supports them. What is the state in Redhat? Is it a base feature that cannot be removed from the system? Are the support-commands always present? If the feature is not in libc, is the related library always present? Is is easy to set up a VirtualBox with an installation that allows to check the features on whether they support everything that is needed? If the basic constraints are met, it may be something that could be added next year..... Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/43 ------------------------------------------------------------------------ On 2010-11-30T10:43:00+00:00 Roman wrote: (In reply to comment #30) > Regarding file capabilties... > > This may be a way to avoid suid root. The URL you mentioned however does not > point to the needed information: > > So far, I am only aware of a Linux distro from Turkey that supports them. What > is the state in Redhat? Is it a base feature that cannot be removed from the > system? Just nit picking - Not Redhat, but Fedora. And I don't know. > > Are the support-commands always present? Which commands? When? > > If the feature is not in libc, is the related library always present? You can specify needed library in spec file (for building). For runtime, rpm and yum solves dependencies, libraries are autorequired and installed with package. > > Is is easy to set up a VirtualBox with an installation that allows to check > the > features on whether they support everything that is needed? I don't know. > > If the basic constraints are met, it may be something that could be added next > year..... Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/44 ------------------------------------------------------------------------ On 2010-11-30T12:23:44+00:00 Jörg wrote: I checked the content of the RPMs on Solaris and it seems to be OK. I do not have a RedHat system running here. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/45 ------------------------------------------------------------------------ On 2010-11-30T20:46:09+00:00 Simone wrote: Hello, I'mm currently in a job transfer and cannot look at it, I'll check how difficult is to add support for libcap-ng to cdrtools. The policycoreutils_setuid.patch is pretty neat, I'll check the capabilities along with the pfexec settings that can be done on Solaris for cdrtools and see if there's a match. http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch According to the %caps line in the patch this seems pretty easy to do, I'll check it on Thursday back home. Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/46 ------------------------------------------------------------------------ On 2010-11-30T20:59:07+00:00 Jörg wrote: A few years ago, I checked the Linux caps and it seems that except for the needed SCSI settings that seem to be unclear for me on Linux, there is a 1:1 match with the other privileges used with pfexec on Solaris. In any case, cdrecord, cdda2wav and readcd all need to actively maintain the capabilities at runtime as they need to give up "file_dac_read" after opening the SCSI devices. For this reason, there is a need for similar support code as already present for Solaris. If this would not be done, cdrecord could burn any local file (regardless of the calling user) which is not intended. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/47 ------------------------------------------------------------------------ On 2010-12-07T09:34:26+00:00 Jörg wrote: BTW: Could you please pack cdrtools-3.01a01? It fixes a bug that has been recently unveiled by k3b. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/49 ------------------------------------------------------------------------ On 2010-12-10T09:03:51+00:00 Simone wrote: Hello, I've been on holiday, here are the rpms. http://www.kosgroup.com/simosimo/ I made a %global define at the beginning of the spec file, by setting the alpha version and bumping the version the Source URL and other pointers gets updated. I can also supply 32 bit builds built with mock if someone needs them. btw, I'm no programmer but I tried anyway to add libcap-ng to cdrecord. Of course this comes without success, I was able to link cdrecord to libcap-ng.so.0 but didn't get the capabilities, probably there's the need for some other patch. If someone wants to add support I'll be happy to test it on RHEL and Fedora. According to the documents it should just be a matter of adding something like tis: #ifdef HAVE_LIBCAP_NG #include <cap-ng.h> #endif #ifdef HAVE_LIBCAP_NG capng_clear(CAPNG_SELECT_BOTH); capng_updatev(CAP_IPC_LOCK, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SYS_ADMIN, CAP_SYS_NICE, -1); capng_apply(CAPNG_SELECT_BOTH); #endif libcap-ng is not included yet in RedHat Enterprise Linux, just Fedora. RHEL 5+ has just libcap. I can make a conditional build for rhel 5/6 and Fedora in the same rpm if someone provides the patches. Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/50 ------------------------------------------------------------------------ On 2010-12-10T09:27:14+00:00 Simone wrote: Hello, just re-uploaded the packages for a typo. I just noticed that setting an empty RUNPATH doesn't seem to work anymore for cdda2wav, here's the output of rpmlint: cdda2wav.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/cdda2wav ['/usr/lib', '/opt/schily/lib'] cdda2wav.x86_64: E: setuid-binary /usr/bin/cdda2wav root 04755L cdda2wav.x86_64: E: non-standard-executable-perm /usr/bin/cdda2wav 04755L cdrecord.x86_64: E: setuid-binary /usr/sbin/rscsi root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/sbin/rscsi 04755L cdrecord.x86_64: E: setuid-binary /usr/bin/readcd root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/readcd 04755L cdrecord.x86_64: E: setuid-binary /usr/bin/cdrecord root 04755L cdrecord.x86_64: E: non-standard-executable-perm /usr/bin/cdrecord 04755L mkisofs.x86_64: W: only-non-binary-in-usr-lib mkisofs.x86_64: W: manual-page-warning /usr/share/man/man8/isoinfo.8.gz 33: a special character is not allowed in a name 6 packages and 0 specfiles checked; 9 errors, 2 warnings. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/51 ------------------------------------------------------------------------ On 2010-12-10T09:38:55+00:00 Jörg wrote: Setting an empty RUNPATH works perfectly for me. What make program do you use? If you have the standard ELF utilities installed, you can call: dump -Lv cdda2wav to get a list that includes the RUNPATH if present. BTW: there seems to be something wrong in the check program as it gives a strange complaint about isoinfo.8 Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/52 ------------------------------------------------------------------------ On 2010-12-10T15:40:06+00:00 Simone wrote: Sorry no elfutils here, the machines I currently use are in production. Running mock avoids me installing anything that relates to development but have all dependencies and checks controlled in a chroot environment. I made a few test, with 3.00 setting an empty RUNPATH doesn't set rpaths, in 3.01a01 an empty RUNPATH generates the above situation. Putting again the following in the spec file solves the problem: sed -i -e 's@-R$(INS_BASE)/lib -R/opt/schily/lib@@g' DEFAULTS/* DEFAULTS_ENG/* I've updated the packages again with that and the isoinfo.8 encode. http://www.kosgroup.com/simosimo/ Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/53 ------------------------------------------------------------------------ On 2010-12-10T17:36:50+00:00 Jörg wrote: I did just run a test on Linux and I cannot reproduce your problem. Calling: smake RUNPATH= definitely does not use any -R option for the final link commands. Could you explain what's about isoinfo.8? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/54 ------------------------------------------------------------------------ On 2011-01-10T13:23:19+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/55 ------------------------------------------------------------------------ On 2011-06-07T23:42:45+00:00 Matt wrote: Simone, it seems your link gives a 404 now. Any plans to re-post your packages, or repackage for Fedora 15? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/57 ------------------------------------------------------------------------ On 2011-06-08T07:46:54+00:00 Simone wrote: Hello, I've put again 3.01a05 signed packages for fc15/el5 at the same link: http://www.kosgroup.com/simosimo/ Unfortunately in a month I will not be able to access that site anymore, so if someone could offer some space I'd be happy to mantain packages for el5/6 and fc14/15. Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/58 ------------------------------------------------------------------------ On 2011-06-08T13:01:06+00:00 Jörg wrote: you of course could start a project at berlios.de I still don't understand why RedHat distributes 6 year old software that misses 50% of the features of a recent version? Cdrkit in addition is of dubious legality while the original software hat positive legal reviews from several lawywers. Is RedHat really interested in actively supporting anti-OSS campaigns? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/59 ------------------------------------------------------------------------ On 2011-06-08T20:25:16+00:00 Matt wrote: Simone, thanks for the updated package. Maybe you can package these for rpmfusion? They take packages with a variety of licences, so if the issue for fedora is just the license then shouldn't this be fine? Jörg, thanks for all the work on cdrtools. I'm genuinely curious in the following, not trying to troll. Now that Sun has been swallowed up by Oracle, which I think we can all agree really is anti-OSS in that they have effectively killed a number of open source projects since buying Sun, why not switch your code back to GPL? Wouldn't that at least be a good test of the veracity of Red Hat/Fedora/Debian claims that they truly believe the CDDL is an incompatible license? I know this isn't a place for a long discussion, so I'm just going to bow out now. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/60 ------------------------------------------------------------------------ On 2011-06-08T22:02:36+00:00 Jörg wrote: The change towards the CDDL was not related to Sun but was a reaction on an anti-OSS anti-GPL act from Debian. At a time when cdrecord was 100% GPL (in Summer 2005), Debian started to claim that there was a license change in cdrecord although absolutely nothing was changed in cdrecord. Debian claimed there was a GPL violation as a result of a non-existent and just alleged license change. At that time, people could have given help to me..... Nobody helped. In special, the FSF did not help against this anti-OSS anti-GPL act from Debian. As a reaction on the attacks from Debian and as a restult on the missing help from others, I decided to change the license so Debian could no longer claim that there was a GPL license violation as there was no GPL anymore in cdrecord. After the license change on May 15 2006, cdrecord was 100% CDDL. Debian continued to claim a GPL violation in cdrecord. So it is obvious that Debian is not interested in any kind of relation to reality. As a result, the FSF did loss one of the top 10 GPL OSS projects in the world. Why do they now weep bitter tears on the lost project? As the reason for the license change still exists, why do you believe that another license change would help? The current situation is a result from the attacks from Debian and a result from the missing help from the FSF and from the OSS community. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/61 ------------------------------------------------------------------------ On 2011-06-09T05:50:41+00:00 Michael wrote: Jörg, I have been following this since the beginning. I still do not understand every single bit of the story but I can say that people have been doing strange and also stupid things. Even worse, people have tried to discredit you personally for whatever reasons. In the end, the situation is bad for everyone, especially users, most of which don't even care about the license and just want their CD recording software to work. But companies like Red Hat have to care about licenses. Not being a lawyer, I cannot judge the legal aspect myself. Personally, I don't really have a problem with the CDDL, but I have to give credit to Red Hat who have been around for a long time and have made a lot of correct decisions (even if this particular one may not be the correct one...) So, would another license change help? I can't tell. But I know the best thing for users would be to get cdrecord 3.x shipped by default in Fedora, Red Hat, etc. This should be the goal and I would advice all parties involved to get over the problems of the past. Red Hat legal should have another look and propose whatever license they think would meet their needs... I am sure that whatever license that would be, it would be fine for cdrecord to use (provided a license change is possible). Anyway, a first step would be to declare willingness to change license. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/62 ------------------------------------------------------------------------ On 2011-06-09T20:54:23+00:00 Jörg wrote: It is obvious that RedHat does not care about legality. Cdrkit is of questionable legality - RedHat is informed but RedHat does not care and ships cdrkit. During the past 10 Years, GNU VCDimager was illegal and based on a Copyright violation (this was recently confirmed by Suse lawyers). The FSF and RedHat have both been informed - nobody cared about the legality. With the help from Suse, we have been able to fix this two months ago. On the other side, the Sun legal department made a legal review with the original cdrtools and confirmed that there is no problem. Early this year, Orcale made a second legal review with a different background with Oracle lawyers and confirmed that there is no problem. RedHat legal is unfortunately just trolling and denying a fact based discussion. Those who checked legality distribute the original software and do not distribute cdrkit. Why does RedHat behave different? If there really was any legal argument against cdrtools, it would be easy to publish the argument and to have a fact based discussion with various other lawyers. The fact that Redhat does not give any argument against cdrtools confirms that RedHat legal has no legal argument against cdrtools. Ask RedHat for the real reasons for their decision, it cannot be based on a legal fact. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/63 ------------------------------------------------------------------------ On 2011-10-26T08:49:07+00:00 Simone wrote: Hello, I'm still building rpms with the latest versions of cdrtools for el5, el6 and fc15. Sorry to ask here, but how can I push the rpms on repos.fedorapeople.org? I already have an account @fedorapeople.org but the instructions say I have to apply to a group before having the rights to upload. Apart from cdrtools I have other rpmlint/mock built packages that I would like to host somewhere. Thanks, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/81 ------------------------------------------------------------------------ On 2011-10-26T10:40:33+00:00 Honza wrote: (In reply to comment #49) > Sorry to ask here, but how can I push the rpms on repos.fedorapeople.org? I > already have an account @fedorapeople.org but the instructions say I have to > apply to a group before having the rights to upload. > > Apart from cdrtools I have other rpmlint/mock built packages that I would like > to host somewhere. Unfortunately, I can't give you an answer, I've no experiences with that. Generally, you can ask on fedora list, but please mind that "Do not distribute anything on fedorapeople.org that Fedora itself cannot distribute for legal reasons. Nothing on the ForbiddenItems list or otherwise non distributable by Fedora." [1], so cdrtools shouldn't be included in repos.fedorapeople.org, AFAIK. [1] http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Allowable_content Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/82 ------------------------------------------------------------------------ On 2011-10-26T11:52:49+00:00 Simone wrote: Well, according to: http://fedoraproject.org/wiki/Licensing#Good_Licenses my understanding is that CDDL programs are fine for distributing inside Fedora and that licenses identified as "good" could be in the main repositories as well. CDDL is also a valid license value when checking packages with rpmlint. It's funny because this debate about the license of cdrtools shouldn't even exist, but I'm not there to start a flame. Do you know which list among the many provided of the Fedora Project is the right one? Thanks, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/83 ------------------------------------------------------------------------ On 2011-10-26T12:23:22+00:00 Honza wrote: (In reply to comment #51) > my understanding is that CDDL programs are fine for distributing inside Fedora > and that licenses identified as "good" could be in the main repositories as > well. CDDL is also a valid license value when checking packages with rpmlint. You're right that CDDL itself isn't problem, but combination of CDDL and GPL code seems to be (see http://www.redhat.com/archives/fedora-legal- list/2009-July/msg00000.html). > Do you know which list among the many provided of the Fedora Project is the > right one? I'd go for the devel list. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/84 ------------------------------------------------------------------------ On 2011-10-26T14:26:08+00:00 Jörg wrote: There is no combination of CDDL and GPL in cdrtools. Cdrtools is a set of more than 25 separate projects (or "works" when using the wording of lawyers). Each of the different projects is completely under a single license only. 4 projects are still under GPL, 2 projects are under the BSD license, the rest is CDDL. A detailed decription is available in the file COPYING, but it seems that the linux distributors that support the attacks from Debian did never read that file... BTW: The whole dispute was initiated by by some unfriendly people from Debian and was nothing but a red herring to distract from the real problem: the Debian packetizer changed and the new packetizer that was unwilling to collaborate. And in case you don't know, the license change was a reaction on the attacks against the project. If people did like to have everything stay unter GPL, these people would need to have supported me in 2005, but this did not happen. Anyway, Linux distributions are made from many projects under many different licenses and nobody reported a problem resulting from that aggregation. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/85 ------------------------------------------------------------------------ On 2011-10-27T06:34:20+00:00 Honza wrote: Jörg, thanks for explanation how you understand that. But we just have to follow our lawyers' status. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/86 ------------------------------------------------------------------------ On 2011-10-27T09:20:17+00:00 Jörg wrote: I am not sure what you like to tell me with this text.... There is not is single lawyer that could find any legal problem in the cdrtools package, so what problem do you have? Please note that the mail you quoted in your previous post is from a person who is not willing to expose himself with the problems. The quoted mail contains nothing than a bunch of unlrelated blabla. (*) If one of your lawyer did really see a problem, why does he keep it secret? Why did companies like Sun that really asked laywers made a decission against cdrkit and pro cdrtools? What redhat is doing with cdrtools is called pointless bashing, as there was never a single legal argument from redhat against cdrtools. Do you really like to continue this way? RedHat lost it's credability with the way it deals with cdrtools. It would be nice to see this changed and it would be nice if we could start a fact based discussion. Are you ready for a fact based discussion? *) redhat e.g. closed many still valid bug reports against cdrkit; arguing with the number of bugs in the redhat buglist is childish. In special if you watch related discussions in the net where more and more people inform others that they needed to go to cdrtools in order to be able to work again. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/87 ------------------------------------------------------------------------ On 2011-10-27T09:38:58+00:00 Simone wrote: I've seen that there's a06 available, but I'm not able to build it. I just swapped the version in the spec file and tried to rebuild but it seems to get stuck in a loop: EBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/btcflash' DEBUG: ==> MAKING SYMLINKS in . DEBUG: ==> MAKING DIRECTORY "OBJ/x86_64-linux-cc" DEBUG: ==> MAKING SYMLINKS in . DEBUG: ==> MAKING SYMLINKS in . DEBUG: ==> MAKING SYMLINKS in . DEBUG: ln: failed to create symbolic link `./cd_misc.c': File exists DEBUG: ln: failed to create symbolic link `./cd_misc.c': File existsln: DEBUG: failed to create symbolic link `./io.c': File exists DEBUG: ln: failed to create symbolic link `./io.c': File exists DEBUG: cp: `../cdrecord/cd_misc.c' and `./cd_misc.c' are the same file DEBUG: cp: `../readcd/io.c' and `./io.c' are the same file DEBUG: ln: failed to create symbolic link `./misc.c': File exists DEBUG: ln: failed to create symbolic link `./misc.c': File exists DEBUG: cp: `../cdrecord/misc.c' and `./misc.c' are the same file DEBUG: ln: ln: failed to create symbolic link `./scsi_cdr.c': File exists DEBUG: failed to create symbolic link `./scsi_cdr.c' ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/misc.d" DEBUG: : File exists DEBUG: ln: failed to create symbolic link `./scsi_scan.c': File exists DEBUG: ln: failed to create symbolic link `./scsi_scan.c': File exists DEBUG: cp: `../cdrecord/scsi_cdr.c' and `./scsi_cdr.c' are the same file DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/skel.d" DEBUG: cp: `../cdrecord/scsi_scan.c' and `./scsi_scan.c' are the same file DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/btcflash' DEBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/btcflash' DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/scsi_scan.d" DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/scsi_cdr.d" DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/cd_misc.d" DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/io.d" DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/btcflash' DEBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/btcflash' DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/skel.o" DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/io.o" DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/cd_misc.o" DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/scsi_cdr.o" DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/scsi_scan.o" DEBUG: ==> COMPILING "OBJ/x86_64-linux-cc/misc.o" DEBUG: ==> LINKING "OBJ/x86_64-linux-cc/btcflash" DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/btcflash' DEBUG: ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav" DEBUG: make[1]: Entering directory `/builddir/build/BUILD/cdrtools-3.01/cdda2wav' DEBUG: ../RULES/local.cnf:43: OBJ/x86_64-linux-cc/Inull: No such file or directory DEBUG: ../RULES/local.cnf:44: OBJ/x86_64-linux-cc/local.cnf: No such file or directory DEBUG: ==> MAKING DIRECTORY "OBJ/x86_64-linux-cc" DEBUG: ==> MAKING SYMLINKS in . DEBUG: ==> MAKING SYMLINKS in . DEBUG: ==> MAKING SYMLINKS in . DEBUG: ==> MAKING SYMLINKS in . DEBUG: ln: failed to create symbolic link `xxzzy.345': File exists DEBUG: ln: ln: failed to create symbolic link `xxzzy.345'failed to create symbolic link `./cd_misc.c': File exists: File exists DEBUG: ln: failed to create symbolic link `./scsi_cdr.c': File exists DEBUG: ln: failed to create symbolic link `./cd_misc.c': File exists DEBUG: ln: failed to create symbolic link `./scsi_scan.c': File exists DEBUG: ln: failed to create symbolic link `./scsi_cdr.c': File existscp: `../autoconf/acgeneral.m4' and `./acgeneral.m4' are the same file DEBUG: ln: failed to create symbolic link `./scsi_scan.c'cp: `../autoconf/aclocal.m4' and `./aclocal.m4' are the same file: File exists DEBUG: ln: failed to create symbolic link `./acgeneral.m4': File exists DEBUG: cp: `../autoconf/acoldnames.m4' and `./acoldnames.m4' are the same file DEBUG: ln: failed to create symbolic link `./aclocal.m4': File exists DEBUG: cp: `../autoconf/acgeneral.m4' and `./acgeneral.m4' are the same file DEBUG: cp: `../autoconf/acspecific.m4' and `./acspecific.m4' are the same file DEBUG: ln: failed to create symbolic link `./acoldnames.m4': File exists DEBUG: cp: `../autoconf/aclocal.m4' and `./aclocal.m4' are the same file DEBUG: cp: `../autoconf/autoconf.m4' and `./autoconf.m4' are the same file DEBUG: ln: failed to create symbolic link `./acspecific.m4': File exists DEBUG: cp: `../autoconf/acoldnames.m4' and `./acoldnames.m4' are the same fileln: failed to create symbolic link `./autoconf.m4': File exists DEBUG: ln: failed to create symbolic link `./autoconf': File exists DEBUG: ==> MAKING DIRECTORY "OBJ/x86_64-linux-cc/Inull" DEBUG: ln: failed to create symbolic link `./autoheader.m4': File exists DEBUG: ln: failed to create symbolic link `./config.guess': File exists DEBUG: ln: failed to create symbolic link `./config.sub': File exists DEBUG: cp: `../autoconf/acspecific.m4' and `./acspecific.m4' are the same file DEBUG: ln: failed to create symbolic link `./install-sh': File exists DEBUG: cp: `../autoconf/autoconf' and `./autoconf' are the same file DEBUG: cp: `../autoconf/autoconf.m4' and `./autoconf.m4' are the same file DEBUG: cp: `../autoconf/autoheader.m4' and `./autoheader.m4' are the same file DEBUG: cp: `../autoconf/autoconf' and `./autoconf' are the same file DEBUG: cp: `../autoconf/config.guess' and `./config.guess' are the same file DEBUG: cp: `../autoconf/autoheader.m4' and `./autoheader.m4' are the same file DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/parse.d" DEBUG: cp: `../autoconf/config.guess' and `./config.guess' are the same file DEBUG: cp: `../autoconf/config.sub' and `./config.sub' are the same file DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/base64.d" DEBUG: cp: `../autoconf/config.sub' and `./config.sub' are the same file DEBUG: cp: `../conf/install-sh' and `./install-sh' are the same file DEBUG: cp: `../conf/install-sh' and `./install-sh' are the same file DEBUG: make[1]: *** [install-sh] Error 1 DEBUG: make[1]: *** Waiting for unfinished jobs.... DEBUG: ==> MAKING DEPENDENCIES "OBJ/x86_64-linux-cc/ioctl.d" DEBUG: config.h:34:21: fatal error: lconfig.h: No such file or directoryconfig.h:34:21: fatal error: lconfig.h: No such file or directory DEBUG: compilation terminated. DEBUG: compilation terminated. DEBUG: make[1]: Leaving directory `/builddir/build/BUILD/cdrtools-3.01/cdda2wav' DEBUG: make: *** [all] Error 1 Thanks, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/88 ------------------------------------------------------------------------ On 2011-10-27T10:40:18+00:00 Jörg wrote: I have no idea where the "DEBUG:" messages are from, but it looks like you are using a buggy "make" program, or you did modify the source tree in an inapropriate way? gmake has several well known bugs that even have been accepted by it's maintainer in 1998 already, but these bugs are still not fixed. It was always a problem to support make programs like gmake that do not behave as documented, but if you ignore the incorrect warnings from gmake and if you are OK with the fact that gmake may not stop it's work when an error is encountered, you still should be able to use gmake if you are on Linux (there are many other OS where gmake compiles fine but does not work at all). I recommend to use "smake" as smake is known for not having problems and as smake works on more platforms than gmake. The easiest way to start is to download the complete set of "schily" sources from: ftp://ftp.berlios.de/pub/schily/ If you call "gmake" on that source tree, it will first build a bootstrap "smake" (using shell scripts) and then use that bootstrap smake to compile the rest. If your problems stay with the official compile method, we need to have a closer look at what you are doing. cdrtools-3.01a06 as well as schily-2011-08-29 are known to compile without problems on a sane Linux installation. Hint: if you like to remove possible official compile results, call "./.clean". Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/89 ------------------------------------------------------------------------ On 2011-10-27T11:03:08+00:00 Honza wrote: (In reply to comment #55) > RedHat lost it's credability with the way it deals with cdrtools. It would be > nice to see this changed and it would be nice if we could start a fact based > discussion. Are you ready for a fact based discussion? I believe you that a fact based discussion can solve the problem. Nevertheless, I'm not the right person who to discuss with and this is not the right place to discuss, since bugzilla is a bug tracking tool. If you really need to start a new discussion, fedora legal list seems to be a better place to begin. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/90 ------------------------------------------------------------------------ On 2011-10-27T11:14:42+00:00 Giandomenico wrote: I have successfully rebuild a f14 x86_64 packages using simosimo's f15 ones (cdrtools-3.01-a05.1.fc15.src.rpm) and update tarballs from schilly site (3.01-a06...) Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/91 ------------------------------------------------------------------------ On 2011-10-27T11:18:35+00:00 Jörg wrote: Honza: That list is run by an unfriendly person who is unwilling to a fact based discussion and who blocked me from that list. As the person in question did not yet send any legally valid claim, it may be better to get a direct contact with a redhat lawyer. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/92 ------------------------------------------------------------------------ On 2011-10-27T11:20:17+00:00 Jörg wrote: Giandomenico: do these rpms contain the build scripts, so I could see where problems may be caused? Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/93 ------------------------------------------------------------------------ On 2011-10-27T11:28:35+00:00 Simone wrote: Thanks, it worked. I changed the spec file from: export CFLAGS="$RPM_OPT_FLAGS" make GMAKE_NOWARN=true INS_BASE=/usr INS_RBASE=/ MANDIR=man %{?_smp_mflags} \ COPTX=-g LDOPTX=-g RUNPATH= to: ./.clean export CFLAGS="$RPM_OPT_FLAGS" make GMAKE_NOWARN=true INS_BASE=/usr INS_RBASE=/ MANDIR=man %{?_smp_mflags} \ COPTX=-g LDOPTX=-g RUNPATH= and that indeed fixed the problem, I built succesfully a06. It seems there's some leftover into the original tarball. I tested RHEL6 i386/x86_64 and Fedora 15/16 i386/x86_64, in RHEL6 I don't get the problem, it seems to be related to Fedora 15+. The "DEBUG" prefix can be ignored, is just the verbose output of mock, the Fedora/Redhat tool that is used to create a clean & complete chroot environment for building packages. The address space at kosgroup.com/* will be deleted soon, I no longer work for that company. Giandomenico; are you able to host the packages? I have new spec files with added fixes from new versions of rpmlint. Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/94 ------------------------------------------------------------------------ On 2011-10-27T11:50:18+00:00 Jörg wrote: There is no leftover in the original tarball, it seems that you added some files that do not belong there. If you like, you can also host the data on berlios. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/95 ------------------------------------------------------------------------ On 2011-10-27T12:05:16+00:00 Simone wrote: I've not added anything, I just changed the %define from "a05" to "a06" at the top of the spec file. To force cdrecord, readcd and mkisofs higher priority in Brasero in respect to other plugins run the following as your user: dconf write /apps/brasero/plugins/cdrecord/priority 1 dconf write /apps/brasero/plugins/mkisofs/priority 1 dconf write /apps/brasero/plugins/readcd/priority 1 I guess that at least in my case the reason for failed dvd writing is libburnia. dvd+rw-tools by command line works fine as cdrecord with all the {DL-}DVDs I throw to it and wodim/genisoimage are replaced by my packages so the culprit is probably there. I'll check if I still get errors with Brasero. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/96 ------------------------------------------------------------------------ On 2011-10-27T12:15:20+00:00 Jörg wrote: The tarball does not contain incorrect or superfluous files and it compiles out of the box on Linux. If you did have problems with compiling, some of your actions must have created the files in question. BTW: some of the bug-reports I received let me asume that gmake under some conditions ignores existing rules. Ignoring rules may cause problems later on. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/97 ------------------------------------------------------------------------ On 2011-10-27T15:56:08+00:00 Simone wrote: Well, the "./.clean" has nothing to do with the fix, I incurred in the error of a06 again while building for other archs. The solution for fixing the build on my systems was removing "%{?_smp_mflags}", the multiple jobs to make. Regards, --Simone Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/98 ------------------------------------------------------------------------ On 2011-11-26T18:45:41+00:00 Rahul wrote: Mail referred to https://www.redhat.com/archives/fedora-legal-list/2009-July/msg00000.html is the Fedora legal position on cdrkit. If you have any further considerations, bring it to the legal mailing list. Bugzilla isn't the right place for such discussions. Reply at: https://bugs.launchpad.net/ubuntu/+source/cdrtools/+bug/213215/comments/99 ** Changed in: cdrtools (Fedora) Status: Unknown => Invalid ** Changed in: cdrtools (Fedora) Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/213215 Title: Please include original cdrecord (cdrtools) package in Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/linuxmint/+bug/213215/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
