Re: cdrkit 1.1.10 fails to locate libcap
Norbert Preining wrote: > OpenSuSE 11.2 distributes cdrkit. OpenSuSE 11.2 distributes cdrtools. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
On Mo, 04 Jan 2010, Joerg Schilling wrote:
> Let us look at the bigger distributions:
>
> Solaris
> *BSD
> Gentoo
> Slackware
> SuSE
> Arch Linux
> and many others distribute the original software.
OpenSuSE 11.2 distributes cdrkit.
>
> RedHat seems to be a hostile distribution as there are extremely hostile
So then we have the biggest three Debian/Ubuntu, RH, SuSE without
schily/cdrecord.
> mails from RedHat - maybe we need to sue RedHat to let them learn that
> they cannot distribute software that is in conflict with GPL and Copyright
> law.
Enjoy!
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
`How do you feel?' he asked him.
bits of me keep
passing out.'
`We're safe,' he said.
`Oh good,' said Arthur.
in one of the
spaceships of the Vogon Constructor Fleet.'
this is obviously some strange usage of
the word "safe" that I wasn't previously aware of.'
--- Arthur after his first ever teleport ride.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Mark Rosenstand wrote: > > Given the fact that there have been many new features added to cdrtools > > since > > the time some people created the "fork", > > I don't use a distribution, but the fact is that when the big distros > adopt something, it is likely to get used by a lot of people, including > e.g. CD burning GUI front-end application developers. Let us look at the bigger distributions: Solaris *BSD Gentoo Slackware SuSE Arch Linux and many others distribute the original software. RedHat seems to be a hostile distribution as there are extremely hostile mails from RedHat - maybe we need to sue RedHat to let them learn that they cannot distribute software that is in conflict with GPL and Copyright law. On March 6th 2009 at CeBIT in the Sun booth, Debian made a binding commitment to distribute the original cdrtools as soon as possible and there is already a binary packet waiting at Debian since more than half a year. Let us see whether a binding commitment from Debian is something substancial Ubuntu is just a Debian downstream In case you don't know, authors of frontends for cdrtools know about the > 100 bugs in the fork and thus prefer to use the original software. > > Well, cdrtools uses a standard leading edge build system. The fact that is > > has extreme similarities to the build system created by David Korn that > > is written on top of a new make utility "nmake" but uses the same ideas > > of just having a list of source files in the leaf makefiles verifies that > > it uses the right basic ideas. In contrary to other build systems, it > > grants out of the box compilation on 30+ platforms. It may be that you > > are not flexible enough to lean new software and that you just not notice > > that > > many of the OSS packages that use different build systems just do not > > compile > > even on major platforms like Solaris without manually changing significant > > parts. > > No doubt autotools and even cmake have their weaknesses too, but they > are much more widely used (at least in the projects I'm interested in), > so I can invest time in learning them. It is interesting that you even mention cmake which creates worse results than you get from using the so called "autotools". > Another fact is that cdrtools on Linux cannot even be built in parallel > on the world's most widely used make(1) implementation, GNU make. All software that uses the Schily Makefilesystem of course can be made in parallel. Just try e.g. "dmake" from Sun it is even available for free for Linux x86. There may be a problem with GNU make. GNU make is full of bugs that are not fixed. I did e.g. file a bug report for a coneptional bug to the GNU make maintainers in 1998 and they accepted the bug and told me that it will take a bit longer to get fixed. Now 12 years have passed and nothing was fixed. The bug I am talking about here, creates warning messages for include files that make people believe that there is a bug in the schily makefilesystem although the bug is in GNU make. GNU make does not yet seem to be ready for being used as a parallel make tool. Note that GNU make is still to dumb to separate the output of commands run in parallel. This makes it impossible to see the relation between the error messages and the source files the messages are created for. I have also been told by other people that GNU make ignores some dependencies if in parallel mode and thus may fail. Given the fact that GNU make before version 3.81 even ignores dependencies in non-parallel mode (and thus cannot be used for cdrtools), it seems that there is just another hidden bug that was not fixed correctly. GNU make claims to be portable to many platforms but if you try to verify this claim, you will find that GNU make compiles on all these platforms but on many platforms, there is no resulting usable GNU make binary. GNU make e.g. does not work correclty on all platforms that use as line separator or that use the backslash as path name separator. This is a result of the incorrectly implemented parser for Makefiles in GNU make. GNU make does not work for me in a useful way on OpenVMS, MS-WIN, BeOS, Haiku, OS/2. This is why I use "smake" as the reference make implementation as smake is working correctly on all known platforms and as smake is cleanly written and thus may easily be fixed in case there is a problem. BTW: in case you don't know, smake is even ~ 5 years older than GNU make. The next thing I am going to implement in smake is support for parallel makes and you can be sure that it will work correctly ;-) > We are getting very much off-topic, so excuse me for not replying > further at least on this mailing list. I don't beleive that we are off topic as what you believe seems to be a common missunderstanding for many people and thus it makes sense to correct you in public. > Again, I do not use any other software that uses your build system, so > also packaging smake would be a wa
Re: cdrkit 1.1.10 fails to locate libcap
On Sun, 2010-01-03 at 15:04 +0100, Joerg Schilling wrote: > Mark Rosenstand wrote: > > > > Cdrkit is undistributable as it is in conflict with the GPL and the > > > Copyright > > > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for > > > cdrkit? > > > > The 1.1.10 source package on ftp.debian.org is dated just over a month > > ago, but yeah, it's unfortunate that it hasn't hit the upstream download > > area yet. Latest stable release of cdrtools seems to be from 2004 > > though. > > The fact that somebody creates new "versions" does not proof that there is > some kind of maintenance. During the last 2.5+ years, there was much less > changes in the fork than in a very lazy week of development on cdrtools. > > There are still more than 100 well known bugs in the fork that do not get > fixed. > Given the fact that most of these bugs could be fixed in much less than one > hour > each, it is obvious that the people behind cdrkit do not care about users > > Cdrkit users are on a dead end, there are no bug fixes and there is no > development. > > > > > I recommend you to use the original software from > > > ftp://ftp.berlios.de/pub/cdrecord/alpha/ > > > > I've been using cdrecord for years before cdrkit appeared, but with > > cdrkit being what most Linux distros package these days, I just go with > > the flow, as it means less work/headscratching for me in the long run. > > Well, you are a user and you could ask your Linux distributor why he > distributes unmaintained software with legal problems instead of well > maintained original software with no legal problems. > > Given the fact that there have been many new features added to cdrtools since > the time some people created the "fork", I don't use a distribution, but the fact is that when the big distros adopt something, it is likely to get used by a lot of people, including e.g. CD burning GUI front-end application developers. > > I'm maintaining all packages myself, so the totally non-standard build > > system in cdrtools is a big minus, especially since pretty much all the > > default paths, permissions, and even ownership are different from what's > > casual on Linux systems today. When you have over 1400 source packages > > to maintain, automation is key. (Sorry, I don't use any of your other > > software, so I can't justify the time it will take to automate it.) > > Well, cdrtools uses a standard leading edge build system. The fact that is > has extreme similarities to the build system created by David Korn that > is written on top of a new make utility "nmake" but uses the same ideas > of just having a list of source files in the leaf makefiles verifies that > it uses the right basic ideas. In contrary to other build systems, it > grants out of the box compilation on 30+ platforms. It may be that you > are not flexible enough to lean new software and that you just not notice that > many of the OSS packages that use different build systems just do not compile > even on major platforms like Solaris without manually changing significant > parts. No doubt autotools and even cmake have their weaknesses too, but they are much more widely used (at least in the projects I'm interested in), so I can invest time in learning them. Another fact is that cdrtools on Linux cannot even be built in parallel on the world's most widely used make(1) implementation, GNU make. Linux has a huge user base, this is usually the reason most things tend to usually just work there. Personally I prefer the BSD's - in particular NetBSD - to Linux because of its beautiful and elegant design, but I use Linux out of convenience. We are getting very much off-topic, so excuse me for not replying further at least on this mailing list. > And BTW: if you like automation, you should already know the advantages of > the schily makefilesystem as you just need to call "smake". The other packages > you may be talking about, force you to call "configure" manually and usually > do > not even compile unless you find out some magic parameters you need to add > to the "configure" call in order to get a usefull autoconf result. > > It may be that you are a victim of the Stickholm syndrom and like what > punishes > you ;-) Again, I do not use any other software that uses your build system, so also packaging smake would be a waste of time for me. > > > There are no known problems with the original software and the original > > > software > > > includes many new features that are missing from the illegal fork. > > > > This is a valid point and if GPL'ed software fails, I will likely give > > it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing > > and then the CDDL issues, but at least the former seems no longer an > > issue, and e.g. BluRay writing is indeed a nice feature. > > There never was such an issue. There have been some hostile people who spread > incorrect claims on my software in order to harm. > > Just in
Re: cdrkit 1.1.10 fails to locate libcap
On So, 03 Jan 2010, Joerg Schilling wrote:
> Please stop your hostile trolling, this is a mailing list to discuss
> CD/DVD/BD
> writing and you did never write anything that was helpful for this topic.
And the original question was about a CD burning program.
Could you please be more specific what was "hostile trolling" here
but the fact that I want this list to be open to everyone and every
CD/DVD/BD writing software?
> Note that your mails are called "Verleundung" unless you _prove_ your claims
"Verleumdung" (not "Verleundung")
Furthermore, it is *you* who are stating that something is against the law.
AFAIR in all the European law systems (both Latin based on the continent
and Anglosaxian based in the UK) it is still the job of the one
accusing someone to be against the law to provide proofs.
> with facts. So stop mailing or finally prove that the Debian fork is _not_
> in conflict with the GPL and not in conflict with the Copyright law.
As I said, it is *your* job to enforce that if you are so sure about it.
The German courts are open to your suitcases. I will happily follow
them and wish you good luck (not really).
But as long as you do *NOT* have sufficient proof, and putting something
on *your* websites is not "sufficient proof", in any reasonable
law system, whatever you say in this respect can be considered "Verleumdung".
> > If you continue like that I will request to list master to ban you from
> > this and other lists hosted here.
>
> I hope that I don't need to ask to ban you, as you are a person that is only
> known for frequent trolling. So take care and unless you have something
> substanceful stop posting to this list.
Good luck, would be the first time (well in fact not, but that has different
reasons) that a DD is banned from a Debian hosted mailing list.
So please, go ahead, PLEASE PLEASE PLEASE I will enjoy the fun of it!
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
ZAPHOD Hey, this rock...
FORDMarble...
ZAPHOD Marble...
FORDIce-covered marble...
ZAPHOD Right... it's as slippery as... as... What's the slipperiest
thing you can think of?
FORDAt the moment? This marble.
ZAPHOD Right. This marble is as slippery as this marble.
--- Zaphod and Ford trying to get a grip on things in
--- Brontitall, Fit the Tenth.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Mark Rosenstand wrote: > > Cdrkit is undistributable as it is in conflict with the GPL and the > > Copyright > > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for > > cdrkit? > > The 1.1.10 source package on ftp.debian.org is dated just over a month > ago, but yeah, it's unfortunate that it hasn't hit the upstream download > area yet. Latest stable release of cdrtools seems to be from 2004 > though. The fact that somebody creates new "versions" does not proof that there is some kind of maintenance. During the last 2.5+ years, there was much less changes in the fork than in a very lazy week of development on cdrtools. There are still more than 100 well known bugs in the fork that do not get fixed. Given the fact that most of these bugs could be fixed in much less than one hour each, it is obvious that the people behind cdrkit do not care about users Cdrkit users are on a dead end, there are no bug fixes and there is no development. > > I recommend you to use the original software from > > ftp://ftp.berlios.de/pub/cdrecord/alpha/ > > I've been using cdrecord for years before cdrkit appeared, but with > cdrkit being what most Linux distros package these days, I just go with > the flow, as it means less work/headscratching for me in the long run. Well, you are a user and you could ask your Linux distributor why he distributes unmaintained software with legal problems instead of well maintained original software with no legal problems. Given the fact that there have been many new features added to cdrtools since the time some people created the "fork", > I'm maintaining all packages myself, so the totally non-standard build > system in cdrtools is a big minus, especially since pretty much all the > default paths, permissions, and even ownership are different from what's > casual on Linux systems today. When you have over 1400 source packages > to maintain, automation is key. (Sorry, I don't use any of your other > software, so I can't justify the time it will take to automate it.) Well, cdrtools uses a standard leading edge build system. The fact that is has extreme similarities to the build system created by David Korn that is written on top of a new make utility "nmake" but uses the same ideas of just having a list of source files in the leaf makefiles verifies that it uses the right basic ideas. In contrary to other build systems, it grants out of the box compilation on 30+ platforms. It may be that you are not flexible enough to lean new software and that you just not notice that many of the OSS packages that use different build systems just do not compile even on major platforms like Solaris without manually changing significant parts. And BTW: if you like automation, you should already know the advantages of the schily makefilesystem as you just need to call "smake". The other packages you may be talking about, force you to call "configure" manually and usually do not even compile unless you find out some magic parameters you need to add to the "configure" call in order to get a usefull autoconf result. It may be that you are a victim of the Stickholm syndrom and like what punishes you ;-) > > There are no known problems with the original software and the original > > software > > includes many new features that are missing from the illegal fork. > > This is a valid point and if GPL'ed software fails, I will likely give > it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing > and then the CDDL issues, but at least the former seems no longer an > issue, and e.g. BluRay writing is indeed a nice feature. There never was such an issue. There have been some hostile people who spread incorrect claims on my software in order to harm. Just in case you don't know: I was the fisrt person who tried to sue companies for violating the GPL and while doing this, I learned that most of the GPL claims cannot be enforced in court. The CDDL is a license that is more liberal and just includes those claims that are enforcable in court. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Norbert Preining wrote: > On Sa, 02 Jan 2010, Joerg Schilling wrote: > > Cdrkit is undistributable as it is in conflict with the GPL and the > > Copyright > > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for > > cdrkit? > > 1. This is a mailing list for CD/DVD writing, not for your personal >enjoyment. There are other cd burning programs, and it is valid to ask > here. Please stop your hostile trolling, this is a mailing list to discuss CD/DVD/BD writing and you did never write anything that was helpful for this topic. > 2. Please provide proofs that it is undistributable, or start a suit >case if you are sure that it is in conflict with Copyright law. The proof for my statements is on my website, there os no need to repeat my statements at nauseum. The fact that you ingnore facts is irrelevant and just proves that your only interest is trolling. Note that your mails are called "Verleundung" unless you _prove_ your claims with facts. So stop mailing or finally prove that the Debian fork is _not_ in conflict with the GPL and not in conflict with the Copyright law. > If you continue like that I will request to list master to ban you from > this and other lists hosted here. I hope that I don't need to ask to ban you, as you are a person that is only known for frequent trolling. So take care and unless you have something substanceful stop posting to this list. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Hi Joerg, On Sat, 2010-01-02 at 23:55 +0100, Joerg Schilling wrote: > Mark Rosenstand wrote: > > > Hi, > > > > I just found the 1.1.10 update on ftp.debian.org by accident as I'm > > tracking cdrkit.org/releases/ - would be nice if releases were made > > available through the upstream site as well (or the old releases removed > > and a message telling to use ftp.debian.org) > > Cdrkit is undistributable as it is in conflict with the GPL and the Copyright > law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit? The 1.1.10 source package on ftp.debian.org is dated just over a month ago, but yeah, it's unfortunate that it hasn't hit the upstream download area yet. Latest stable release of cdrtools seems to be from 2004 though. > I recommend you to use the original software from > ftp://ftp.berlios.de/pub/cdrecord/alpha/ I've been using cdrecord for years before cdrkit appeared, but with cdrkit being what most Linux distros package these days, I just go with the flow, as it means less work/headscratching for me in the long run. I'm maintaining all packages myself, so the totally non-standard build system in cdrtools is a big minus, especially since pretty much all the default paths, permissions, and even ownership are different from what's casual on Linux systems today. When you have over 1400 source packages to maintain, automation is key. (Sorry, I don't use any of your other software, so I can't justify the time it will take to automate it.) > There are no known problems with the original software and the original > software > includes many new features that are missing from the illegal fork. This is a valid point and if GPL'ed software fails, I will likely give it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing and then the CDDL issues, but at least the former seems no longer an issue, and e.g. BluRay writing is indeed a nice feature. Cheers, Mark -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
On Sa, 02 Jan 2010, Joerg Schilling wrote:
> Cdrkit is undistributable as it is in conflict with the GPL and the Copyright
> law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit?
1. This is a mailing list for CD/DVD writing, not for your personal
enjoyment. There are other cd burning programs, and it is valid to ask here.
2. Please provide proofs that it is undistributable, or start a suit
case if you are sure that it is in conflict with Copyright law.
If you continue like that I will request to list master to ban you from
this and other lists hosted here.
Thanks.
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, JapanTU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
GLENTIES (pl.n.)
Series of small steps by which someone who has made a serious tactical
error in a conversion or argument moves from complete disagreement to
wholehearted agreement.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Mark Rosenstand wrote: > Hi, > > I just found the 1.1.10 update on ftp.debian.org by accident as I'm > tracking cdrkit.org/releases/ - would be nice if releases were made > available through the upstream site as well (or the old releases removed > and a message telling to use ftp.debian.org) Cdrkit is undistributable as it is in conflict with the GPL and the Copyright law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit? I recommend you to use the original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ There are no known problems with the original software and the original software includes many new features that are missing from the illegal fork. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
On Sat, 2010-01-02 at 20:31 +0100, Mark Rosenstand wrote: > Hi, > > I just found the 1.1.10 update on ftp.debian.org by accident as I'm > tracking cdrkit.org/releases/ - would be nice if releases were made > available through the upstream site as well (or the old releases removed > and a message telling to use ftp.debian.org) > > Anyway, it fails to locate my libcap 2.18: > > -- Looking for include files HAVE_SYS_CAPABILITY_H > -- Looking for include files HAVE_SYS_CAPABILITY_H - not found. > CMake Error at wodim/CMakeLists.txt:18 (MESSAGE): > Error: found a Linux system but no libcap header. Install libcap-dev. > > /usr/include/sys/capability.h is there and readable, and I've got other > libcap-using applications building and working fine. I'm pretty clueless > with cmake so if I should provide additional information, let me know. Disregard that. It was because of the recent linux/types.h changes in the kernel headers, my libcap package was broken. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
cdrkit 1.1.10 fails to locate libcap
Hi, I just found the 1.1.10 update on ftp.debian.org by accident as I'm tracking cdrkit.org/releases/ - would be nice if releases were made available through the upstream site as well (or the old releases removed and a message telling to use ftp.debian.org) Anyway, it fails to locate my libcap 2.18: -- Looking for include files HAVE_SYS_CAPABILITY_H -- Looking for include files HAVE_SYS_CAPABILITY_H - not found. CMake Error at wodim/CMakeLists.txt:18 (MESSAGE): Error: found a Linux system but no libcap header. Install libcap-dev. /usr/include/sys/capability.h is there and readable, and I've got other libcap-using applications building and working fine. I'm pretty clueless with cmake so if I should provide additional information, let me know. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
