cdrkit: Debian's fork of cdrtools
| From: | Joerg Jaspert <joerg-AT-ganneff.de> | |
| To: | debian-devel-announce-AT-lists.debian.org | |
| Subject: | cdrkit (fork of cdrtools) uploaded to Debian, please test | |
| Date: | Mon, 04 Sep 2006 00:16:41 +0200 |
Hi we, the Debian maintainers of cdrtools, the cdrecord/mkisofs/cdda2wav program suite, just uploaded cdrkit into the Debian archive. It will hit your unstable box with the next run of dinstall, please help us and test it. This is a fork of the well-known cdrtools suite provided by Jörg Schilling. It will replace his cdrtools package in Debian (cdrtools will be removed a day later). The tarball for this release can be found on http://debburn.alioth.debian.org/ or on your friendly debian mirror after the next archive run. Now we need your help to be sure we release a working version with etch. If you are a user: - test it, with whatever you have to burn. Report anything broken which is not the fault of your hardware :) If you are a maintainer of a program depending on cdrecord/mkisofs/cdda2wav: - change the dependency from cdrecord to wodim and change your program to call wodim, not cdrecord - test your program if it continues to work with the changes. In theory it should, but we all know Master Murphy just too well. Now, for the background on why we took the decision to fork cdrtools: Forking cdrtools as cdrkit -------------------------- So, why the fork? CD/DVD burning is a complicated business that needs a lot of knowledge, so forking such a big collection isn't a step to be taken lightly. It requires a lot of development effort that could be put to better use elsewhere. In the past, we, the Debian maintainers of cdrtools, had a good and mutually cooperative relationship with Jörg Schilling. He even commented on Debian bug reports, which is one of the best things an upstream maintainer can do. Naturally, there were occasionally disagreements, but this is normal. Unfortunately Sun then developed the CDDL[1] and Jörg Schilling released parts of recent versions of cdrtools under this license. The CDDL is incompatible with the GPL. The FSF itself says that this is the case as do people who helped draft the CDDL. One current and one former Sun employee visited the annual Debian conference in Mexico in 2006. Danese Cooper clearly stated there that the CDDL was intentionally modelled on the MPL in order to make it GPL- incompatible. For everyone who wants to hear this first-hand, we have video from that talk available at [2]. You can read the FSF position about the CDDL at [3]. The thread behind [4] contains statements on the issue made by Debian people; for more context also see the other mails in that thread. In short - the CDDL has extra restrictions, which the GPL does not allow. Jörg has a different opinion about this and has repeatedly stated that the CDDL is not incompatible, interpreting a facial expression in the above-mentioned video, calling us liars and generally appearing unwilling to consider our concerns (he never replied to the parts where we explained why it is incompatible). As he has basically ignored what we have said, we have no choice but to fork. While the CDDL *may* be a free license, we never questioned if it is free or not, as it is not our place to decide this as the Debian cdrtools maintainers. However, having been approved by OSI doesn't mean it's ok for any usage, as Jörg unfortunately seems to assume. There are several OSI-approved licenses that are GPL-incompatible and CDDL is one of them. That is and always was our point. For our fork we used the last GPL-licensed version of the program code and killed the incompatibly licensed build system. It is now replaced by a cmake system, and the whole source we distribute should be free of other incompatibilities, as to the best of our current knowledge. Anyone who wants to help with this fork, particularly developers of other distributions, is welcome to join our efforts. You can contact us on IRC, server irc.oftc.net, channel #debburn, or via mail at debburn-devel@lists.alioth.debian.org. Our svn repository is http://svn.debian.org/wsvn/debburn. [1] http://www.opensource.org/licenses/cddl1.php [2] http://meetings-archive.debian.net/pub/debian-meetings/20... [3] http://www.gnu.org/licenses/license-list.html [4] http://lists.debian.org/debian-devel/2006/08/msg00552.html -- bye Joerg <helix> doogie: you have an interesting definition for 'interact with people' that means 'make them want to jump off cliffs'
Posted Sep 4, 2006 18:01 UTC (Mon)
by moxfyre (guest, #13847)
[Link] (3 responses)
I hope that this will result in a CD-burning package that is more responsive to the needs of Linux distros, and without all the chest-thumping egotistical BS that has surrounded cdrtools.
Posted Sep 4, 2006 18:27 UTC (Mon)
by richo123 (guest, #24309)
[Link] (2 responses)
Posted Sep 4, 2006 20:03 UTC (Mon)
by erich (guest, #7127)
[Link] (1 responses)
Instead of forking cdrecord, we could just fork the users!
Posted Sep 14, 2006 18:25 UTC (Thu)
by dvdeug (guest, #10998)
[Link]
Posted Sep 4, 2006 20:35 UTC (Mon)
by aleXXX (subscriber, #2742)
[Link] (8 responses)
Posted Sep 4, 2006 23:02 UTC (Mon)
by moxfyre (guest, #13847)
[Link] (1 responses)
How steep is the learning curve on cmake? Can I learn the basics in an hour or two?
Posted Sep 5, 2006 1:38 UTC (Tue)
by lovelace (guest, #278)
[Link]
Posted Sep 5, 2006 2:14 UTC (Tue)
by ringerc (subscriber, #3071)
[Link]
Posted Sep 5, 2006 6:32 UTC (Tue)
by asamardzic (guest, #27161)
[Link]
Posted May 24, 2009 4:59 UTC (Sun)
by solardiz (guest, #35993)
[Link] (2 responses)
We find cdrkit's use of cmake unreasonable. cdrkit is relatively small (e.g., compared to cmake!) and it does not require "portability" to native development environments on non-Unix platforms (where the use of cmake could be an advantage). cdrkit is simply bloated by its use of cmake. :-(
Posted May 29, 2009 20:16 UTC (Fri)
by aleXXX (subscriber, #2742)
[Link] (1 responses)
On basically all desktop distros this is the case now, and more and more
If you want to avoid the build time, you can also use the binary cmake
Alex
Posted Jun 2, 2009 12:58 UTC (Tue)
by nix (subscriber, #2304)
[Link]
I suspect what's annoying people is that the syntax for cmake is quite
Posted Aug 18, 2009 8:55 UTC (Tue)
by schily (guest, #60311)
[Link]
Cmake is no make program but just another cryptic way of doing
Cmake is just an autoconf replacement - not a new program
Cmake creates extremely cryptic makefiles, that are hard to debug.
Cmake does not create a multi platform build environment,
I see no advantage before the Schily makefile system.
>When I once built cdrtools myself, I also wondered why for every tool
I wonder why some people wrote programs like "gmake" although smake
BTW: I recommend to use the official and well maintained cdrtools
Posted Sep 4, 2006 23:32 UTC (Mon)
by finster (guest, #32338)
[Link]
Posted Sep 5, 2006 5:13 UTC (Tue)
by eru (subscriber, #2753)
[Link] (2 responses)
Posted Sep 5, 2006 7:47 UTC (Tue)
by Zomb (guest, #23391)
[Link]
So it was finally the better compromise.
And then there are good and active alternatives which are going to replace cdrtools in the (mid-term) future: libburn/libisofs based apps, libcdio seems quite usefull as well and there is http://littlesvr.ca/isomaster/ which also looks promising.
Posted Sep 7, 2006 10:46 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
Posted Sep 5, 2006 19:45 UTC (Tue)
by kenmoffat (subscriber, #4807)
[Link] (2 responses)
These systems are using linux-libc-headers-2.6.12.0 with glibc-2.3.6, or the CLFS linux-headers with glibc-2.4. Meanwhile, dvdrtools 'just works', even on multilib ppc64.
Posted Sep 5, 2006 20:56 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Sep 6, 2006 1:22 UTC (Wed)
by Zomb (guest, #23391)
[Link]
Posted Sep 8, 2006 4:04 UTC (Fri)
by kevinbsmith (guest, #4778)
[Link] (2 responses)
Posted Sep 11, 2006 7:35 UTC (Mon)
by xoddam (subscriber, #2322)
[Link]
It could be Word of Deliverance
Insititutional Ministries, Inc. Or, just maybe, it's Write Optical Disc IMage (a guess...)
Posted Sep 12, 2006 19:30 UTC (Tue)
by jimparis (guest, #38647)
[Link]
Q: What does "wodim" stand for?
Kudos to Debian!cdrkit: Debian's fork of cdrtools
Could not agree more! I have had a lot of problems with cd burning in Ubuntu and one was never sure because of Schilling's inpenetrable thicket where exactly the problem lay. His rants against linux scsi support used to really get on my nerves: Basic position was: use a proper unix like Sun or regress to a 2.4 kernel. Thanks (NOT) for the constructive input Herr Schilling! Time for a cleanout! cdrkit: Debian's fork of cdrtools
Why would you change the software? Change the user!cdrkit: Debian's fork of cdrtools
Users have a natural tendency to fork. Unfortunately, there seems to be some trouble getting the necessary pair of developers with the right attributes together to create and support the fork, and it take a lot of time and a lot of money to get a successful fork that doesn't depend on the initial pair of developers.cdrkit: Debian's fork of cdrtools
And another CMake convert :-) cdrkit: Debian's fork of cdrtools
It seems CMake (http://www.cmake.org) is really starting to get
momentum.
When I once built cdrtools myself, I also wondered why for every tool
there was a special Schilling edition, like "smake" and others...
Alex
I've never bothered to learn autotools fully since it's so complicated, and I can mostly just edit existing files to get what I want.cdrkit: Debian's fork of cdrtools
Can I learn the basics in an hour or two?
cdrkit: Debian's fork of cdrtools
Yes, absolutely. There was an article in Linux Magazine recently (disclaimer, free registration apparently required, and I'm the author of the article) about how to use CMake as well one here at LWN too. It's very simple to get started using it.
And rightly so - it's great. I work on a project that presently supports CMake and autohell in parallel (we're dropping autohell as soon as current CMake unstable gets a stable release) and the relative ease of maintainance is significant. Whenever we want to change anything significant or add any feature to the build system it goes from significant to amazing - CMake rocks.CMake
After completing porting several small- and medium-scale projects from auto-tools to cmake, I can only confirm that (in my experience) cmake rocks indeed. Simple and consistent language made it possible for me to easily write feature testing macros, I was never able to figure out how to properly accomplish this with autoconf. The only slight problem is lack of complete documentation, I guess for projects with complicated setups one would have to order "Mastering CMake" book to get most from the tool. But this seems like fair game to me (mine copy of book is on its way), and on the other side cmake developers (and users too) are *very* responsive on cmake mailing list, so for lots of questions one could get the clarification this way.cdrkit: Debian's fork of cdrtools
We wanted to introduce cdrkit into Openwall GNU/*/Linux (Owl), a small
distro for servers, and we finally did, but we found the build-time dependency on cmake very unfortunate. So we got rid of that dependency in our package, but this cost us time. For more info, see my posting to the Distributions list and our cdrkit package files, including README-cmakeless.
cdrkit without cmake
cdrkit without cmake
which should already be existing on the system.
On most systems this is now already the case.
other programs are converting to cmake. So maybe cdrkit is the first
program you are encountering now which uses cmake for your distro, but
there will be more in the future.
release which you can download here:
http://www.cmake.org/cmake/resources/software.html
It works on all Linux distributions (at least we don't know of any where
it doesn't).
This still adds size, but you can save the build time for cmake.
cdrkit without cmake
different from configure scripts, and it takes a good bit of manual
reading to figure out how to get a list of per-package compilation options
et al (cmake --help doesn't work for that as far as I can tell: you can
get lists of *all* properties or commands, but not only of those added byt
the thing you're trying to build. I have to resort to reading the
cmakefiles, which is not ideal!)
cdrkit: Debian's fork of cdrtools
>It seems CMake (http://www.cmake.org) is really starting to get
>momentum.
things the outdated way. When it was written first, the Schily makefile
system did already exist for 8 years.
like David Korn's "nmake". Cmake is no make program but a makefile
generator - you still need a working make program in order
to compile.....
so it is the same fetch - unpack - configure - compile - install - throw away idea as vanilla autoconf.
>there was a special Schilling edition, like "smake" and others...
existed for years already...smake is highly portable (more portable
than gmake) and smake is definitely needed for some of the supported
platforms where gmake is too buggy.
instead of the questionable fork that is unmaintained since more
than two years and that is based on an extremely outdated cdrtools
source.
Yes! I look forward to testing cdrkit! Lets see if we can all chip in and assist the devs on this fork.cdrkit: Debian's fork of cdrtools
I'm wondering why another fork. There was already dvdrtools.
Why not dvdrtools?
Because dvdrtools took off from an older version and has not received many updates/fixes since then but got some significant modifications to port it away from "Schilling-style". Previous Debian package already had dozens of fixes and extensions (many shared with other distros, after all), it would have been the hell porting them to dvdrtools and keeping the quality. Especially in the expected time period, Debian Stable has to be released by the end of the year.Why not dvdrtools?
Furthermore, dvdrtools forked from a version of cdrecord that was available under the GPL with the additional restriction that you may not alter or remove the FUD about Linux printed when cdrecord starts up. Debian currently have dvdrtools in non-free... I would have thought that this additional restriction makes the entire lot non-distributable, however.Why not dvdrtools?
Can we report non-debian bugs, and if so, where ? My systems run variants of LFS and they don't have sys/capability.h. I've got linux/capability.h, but that only contains CAP_SYS_RAWIO, not CAP_EFFECTIVE nor CAP_SET, so I can't compile cdrecord.c.cdrkit: Debian's fork of cdrtools - for non-debian
You need libcap.cdrkit: Debian's fork of cdrtools - for non-debian
Please send a note to the mailing list, maybe with the contents of your header file and the exact error messages. libcap support is a new feature, I am not sure dvdrtools support it whatsoever.cdrkit: Debian's fork of cdrtools - for non-debian
This is good news. But what's a wodim? It appears to be the command line burning portion of cdrkit, but it would have been nice to have that explained. It would be fun to know the meaning behind the word, too. If it's an acronym, it would be easier to remember.wodim?
wodim?
Frequently Asked Questions about cdrkitwodim?
=======================================
A: It is not a forest troll and not a winner of the inpronounceability
contest. It was simply the next alternative to wom (Writes Optical Media)
which was unfortunately already used by other software products.