On Fri, Aug 18, 2006 at 01:24:06PM -0500, Steve Greenland wrote:
> No sign of what it actually did, no sign of whether the answer was
> yes or no. Yes, there is some stuff in there. But not always enough.
> Sometimes it spits out what the compile command was, and the code used,
> and sometimes it
On 17-Aug-06, 23:33 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> [Steve Greenland]
> > By "autoconf related problems" I mean things like it suddenly
> > deciding it's running a cross compiler, or that stdlib.h is
> > missing. A lot of this kind of stuff could be improved by simply
> > SH
I demand that Russ Allbery may or may not have written...
> Steve Greenland <[EMAIL PROTECTED]> writes:
>> And, for example, all of a sudden (autoconf 2.5, I think) every/many
>> (newly generated or regenerated) configure script starting checking for
>> C++ compilers, Fortran compilers, etc. etc.
On Friday 18 August 2006 06:56, Matthew R. Dempsky wrote:
> On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
> > So are some widespread programming languages. If you blindly follow bad
> > examples and bad styles you can dynamite yourself happily without even
> > noticing, but that d
[Steve Greenland]
> By "autoconf related problems" I mean things like it suddenly
> deciding it's running a cross compiler, or that stdlib.h is
> missing. A lot of this kind of stuff could be improved by simply
> SHOWING ME THE FSCKING ERROR MESSAGES, rather than just checking the
> return code an
On Thu, Aug 17, 2006 at 08:48:24PM +0300, George Danchev wrote:
> So are some widespread programming languages. If you blindly follow bad
> examples and bad styles you can dynamite yourself happily without even
> noticing, but that does not make them disused or abandoned (on the contrary
> some
[Wouter Verhelst]
> It has nothing to do with "being afraid to", but everything with "not
> needing to".
There's lots of things we don't _need_ to do but we do anyway, as a
matter of quality of implementation. I believe that building a package
from source is something we should do as well, if on
On Thursday 17 August 2006 19:02, Steve Greenland wrote:
> On 16-Aug-06, 20:49 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
> > As for useless autoconf tests - have you looked at how autoconf is
> > used? You pick the tests you think you need. It's not like the system
> > forces you to use a
Steve Greenland <[EMAIL PROTECTED]> writes:
> And, for example, all of a sudden (autoconf 2.5, I think) every/many
> (newly generated or regenerated) configure script starting checking for
> C++ compilers, Fortran compilers, etc. etc. etc. even for pure C
> projects.
This is a libtool bug.
--
R
On 17-Aug-06, 09:06 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On the other hand, sw with custom build systems were always a pain:
> usually they had no idea how to build a shared lib on AIX,
Neither does libtool. But I can usually easily change the Makefile to
fix that problem; libtool is
On 16-Aug-06, 20:49 (CDT), Peter Samuelson <[EMAIL PROTECTED]> wrote:
>
> As for useless autoconf tests - have you looked at how autoconf is
> used? You pick the tests you think you need. It's not like the system
> forces you to use a certain range of obsolete baseline tests. A huge
> number o
Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote:
>> Yeah, wanting to use functionality when it's available is always a
>> dreadful idea. Far better to reimplement it locally in order to ensure
>> that we have more copies of it to
On 16-Aug-06, 20:23 (CDT), Miles Bader <[EMAIL PROTECTED]> wrote:
> The main problem with your argument is that you seem to be looking at
> poorly written programs that use autoconf, and jumping to the conclusion
> that autoconf is the reason for the poor programming -- it's not. Bad
> programmer
On 16-Aug-06, 19:23 (CDT), Matthew Garrett <[EMAIL PROTECTED]> wrote:
> Yeah, wanting to use functionality when it's available is always a
> dreadful idea. Far better to reimplement it locally in order to ensure
> that we have more copies of it to fix should there ever be any sort of
> security
On Wed, Aug 16, 2006 at 07:11:19PM -0500, Steve Greenland wrote:
> So you chose to use a function not reliably available. Sounds like bad
> planning to me.
More than a year ago the plan was that we'll support Debian Sarge only.
Then a couple of weeks ago our project partner said they'll be using
On Tue, Aug 15, 2006 at 02:42:09AM -0500, Peter Samuelson wrote:
> [Michael Poole]
> > On top of the default automake behavior being horribly broken, does
> > that make usual revision control practices horribly broken?
>
> It really bothers me to hear people claim as a best practice that you
> sho
Steve Greenland <[EMAIL PROTECTED]> writes:
> On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
>> On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
>>
>> > And guess what? System tests are actually more reliable, especially
>> > when the user tells you what the s
[Steve Greenland]
> My experience is that the ones whose build instructions say "edit the
> makefile to pick your platform and compiler" compile and work, and
> when they don't, they're easy to fix. The ones that use autoconf tend
> to blow up on non-Linux[1], in ways that are hard to debug and da
Steve Greenland <[EMAIL PROTECTED]> writes:
> You figure out where the incompatability points are, and you write
> functions to mask them. Of course the functions themselves have
> #ifdefs (or some other way of controlling compilation), but you get it
> *out* of your main code base.
Gee sounds lik
Steve Greenland <[EMAIL PROTECTED]> wrote:
> On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
>> This will never work. Real life example from a couple of weeks ago: I
>> wrote a program that was running happily on Sarge, then somebody wanted
>> to build it on RHEL and failed beca
On 16-Aug-06, 04:00 (CDT), Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
>
> > And guess what? System tests are actually more reliable, especially
> > when the user tells you what the system is. You can simply flip to
> > compiling foo_
On Tue, Aug 15, 2006 at 02:26:29PM -0500, Steve Greenland wrote:
> And guess what? System tests are actually more reliable, especially
> when the user tells you what the system is. You can simply flip to
> compiling foo_linux.c or foo_solaris.c and go on your way.
This will never work. Real life
eople's* .iso files, since I use DVDs instead lately.
> But I noticed that growisofs *does* use mkisofs as a backend.
>
> We definitely need a functional mkisofs in Debian.
>
> mkisofs is certainly part of cdrtools. But not of cdrecord.
>
> Nothing in mkisofs has weird con
Steve Greenland <[EMAIL PROTECTED]> writes:
> And guess what? System tests are actually more reliable, especially
> when the user tells you what the system is. You can simply flip to
> compiling foo_linux.c or foo_solaris.c and go on your way.
If you only port to 2 or 3 different very well-defined
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell:
>
>>> As a countermeasure, the FSF tries to extend copyright to interfaces,
>>> so that you do create a derivative work merely by programming to a
>>> specific interface of a library written by someone else, without
>>> copying their
On Tue, Aug 15, 2006 at 02:11:21PM -0500, Steve Greenland wrote:
> No, you don't #ifdef all the users, you write multiple versions of a a
> generic function that hides the differences, and compile the appropriate
> one. Read the reference I gave.
> Sure, you *could* do this with autoconf driving
On 14-Aug-06, 23:35 (CDT), Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> Steve Greenland wrote:
> Um, this is the exact opposite of the philosophy promoted by Autoconf since
> at least version 2.0. "Feature tests, not system tests". I can't speak to
> other autotools.
Doesn't matter ("feature t
On 14-Aug-06, 17:32 (CDT), Hendrik Sattler <[EMAIL PROTECTED]> wrote:
> Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
> > The *real* problem with the whole autotools disaster is that it promotes
> > a braindead idea of how to achieve portability: a #ifdef branch for
> > every different s
* Steve Greenland <[EMAIL PROTECTED]> [060814 23:30]:
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase.
On Mon, Aug 14, 2006 at 09:40:41PM -0400, Michael Poole wrote:
> Wouter Verhelst writes:
>
> >> In my experience, this is greatly exacerbated and perhaps even
> >> primarily due to older versions of autotools encouraging or requiring
> >> behavior that later versions of autotools declare to be bro
llity, the k3b maintainers did already give up with
> > Debian versions of cdrtools and use self-compiled unmodified
> > originalsources.
>
> This is of course a lie.or why don't you like to prove it?
You are of course lying...
> Neither upstream or debian packaging k
ely.
But I noticed that growisofs *does* use mkisofs as a backend.
We definitely need a functional mkisofs in Debian.
mkisofs is certainly part of cdrtools. But not of cdrecord.
Nothing in mkisofs has weird conditions on the GPL, unlike other parts
of cdrtools (libscg, cdrecord.c), so it shou
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Nathanael Nerode:
>
>> In reality, as "user A", I switched to using cdrdao for making serious audio
>> CDs and CD-RWs, and for burning disks from .iso files: this uses
>> Schilling's scsilib, but not the rest of cdrecord.
>
> What about mkisofs?
So f
* Nathanael Nerode:
> In reality, as "user A", I switched to using cdrdao for making serious audio
> CDs and CD-RWs, and for burning disks from .iso files: this uses
> Schilling's scsilib, but not the rest of cdrecord.
What about mkisofs?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a su
[Michael Poole]
> On top of the default automake behavior being horribly broken, does
> that make usual revision control practices horribly broken?
It really bothers me to hear people claim as a best practice that you
should never recompile configure.ac or Makefile.am except under
controlled cond
Adam Borowski <[EMAIL PROTECTED]> writes:
> Autotools do require you to do things the way they want, indeed. And
> every single autotool uses a different obscure language. Some
> consistency would be good -- but, I challenge you: write something
> that works better. There's a lot of deficiencies
Steve Greenland wrote:
> On 14-Aug-06, 15:59 (CDT), Michael Poole <[EMAIL PROTECTED]> wrote:
>> Wouter Verhelst writes:
>> > In the case of autotools, the fact is that usually it's configure.ac or
>> > Makefile.am being horribly broken, rather than the autotools.
Oh yeah. Most people don't know
Hendrik Sattler wrote:
> You mean the difference between manpages-posix-dev (in non-free) and
> manpages-dev (in main)? The first is not proposed by Debian (I still don't
> get why anone would want to change a standards document as not changing it
> is the whole purpose of its existence.)
In order
Eduard Bloch wrote:
> Then let's see what a user of your software would do, in a
> not-so-uncommon use case:
>
> User A wants to burn a CD-ROM. She gets cdrtools,
In reality, as "user A", I switched to using cdrdao for making serious audio
CDs and CD-RWs, and for bu
Wouter Verhelst writes:
>> In my experience, this is greatly exacerbated and perhaps even
>> primarily due to older versions of autotools encouraging or requiring
>> behavior that later versions of autotools declare to be broken.
> [...]
>> The situation is not helped when these mutually incompati
On Mon, Aug 14, 2006 at 03:53:40PM -0700, Russ Allbery wrote:
> Steve Greenland <[EMAIL PROTECTED]> writes:
> > The *real* problem with the whole autotools disaster is that it promotes
> > a braindead idea of how to achieve portability: a #ifdef branch for
> > every different system (or library ve
Steve Greenland <[EMAIL PROTECTED]> writes:
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase. Real por
On Mon, Aug 14, 2006 at 04:59:24PM -0400, Michael Poole wrote:
> Wouter Verhelst writes:
>
> > On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> >> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> >> > At 1155391794 past the epoch, Bernd Schubert wrote:
> >> >
eallity, the k3b maintainers did already give up with
> > Debian versions of cdrtools and use self-compiled unmodified
> > originalsources.
>
> This is of course a lie.or why don't you like to prove it?
I'm not trying to pick on you, Riku, but please, let's sto
Am Montag 14 August 2006 23:10 schrieb Bernd Schubert:
> Wouter Verhelst wrote:
> > If used properly, autotools usually do their job; and pretty well, too.
>
> Just have a look here http://lwn.net/Articles/188693
KDE never used the autotools properly (I'd rather call it hacking into it),
probably
Am Montag 14 August 2006 23:27 schrieb Steve Greenland:
> On 14-Aug-06, 15:59 (CDT), Michael Poole <[EMAIL PROTECTED]> wrote:
> > Wouter Verhelst writes:
> > > In the case of autotools, the fact is that usually it's configure.ac or
> > > Makefile.am being horribly broken, rather than the autotools.
Steve Greenland <[EMAIL PROTECTED]> writes:
> The *real* problem with the whole autotools disaster is that it promotes
> a braindead idea of how to achieve portability: a #ifdef branch for
> every different system (or library version, or whatever), strewn
> throughout the entire codebase. Real por
Wouter Verhelst wrote:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
>> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
>> > At 1155391794 past the epoch, Bernd Schubert wrote:
>> > > Btw, why always the autotools while there's this nice
>> > > cmake?
>> >
>
On 14-Aug-06, 15:59 (CDT), Michael Poole <[EMAIL PROTECTED]> wrote:
> Wouter Verhelst writes:
> > In the case of autotools, the fact is that usually it's configure.ac or
> > Makefile.am being horribly broken, rather than the autotools.
>
> In my experience, this is greatly exacerbated and perhaps
On Mon, Aug 14, 2006 at 09:52:01PM +0200, Wouter Verhelst wrote:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> > On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> > > At 1155391794 past the epoch, Bernd Schubert wrote:
> > > > Btw, why always the autotools
Wouter Verhelst writes:
> On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
>> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
>> > At 1155391794 past the epoch, Bernd Schubert wrote:
>> > > Btw, why always the autotools while there's this nice
>> > > cmake?
>> >
On Mon, Aug 14, 2006 at 10:58:13AM -0500, Steve Greenland wrote:
> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> > At 1155391794 past the epoch, Bernd Schubert wrote:
> > > Btw, why always the autotools while there's this nice
> > > cmake?
> >
> > I've never used cmake myse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Greenland wrote:
> On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
>> At 1155391794 past the epoch, Bernd Schubert wrote:
>>> Btw, why always the autotools while there's this nice
>>> cmake?
>> I've never used cmake myself, so
On Mon, Aug 14, 2006 at 04:09:33PM +0200, Joerg Schilling wrote:
> This is of course a lie.or why don't you like to prove it:
> http://cdrecord.berlios.de/old/private/problems.html
> Come back to reallity, the k3b maintainers did already give up with
> Debian versions of
Hello,
On Sat, 12.08.2006 at 20:40:37 +0200, Florian Weimer <[EMAIL PROTECTED]> wrote:
> As a countermeasure, the FSF tries to extend copyright to interfaces,
> so that you do create a derivative work merely by programming to a
> specific interface of a library written by someone else, without
>
On 12-Aug-06, 09:09 (CDT), Jon Dowland <[EMAIL PROTECTED]> wrote:
> At 1155391794 past the epoch, Bernd Schubert wrote:
> > Btw, why always the autotools while there's this nice
> > cmake?
>
> I've never used cmake myself, so I can't speak for how nice
> it is, but autotools (for all its problem
On Fri, Aug 11, 2006 at 10:57:45PM +0200, Joerg Schilling wrote:
> Joerg Jaspert <[EMAIL PROTECTED]> wrote:
> > You should look at the video I pointed you at. You just accused me of
> > being a liar. If i would have your low level I would now do the same you
>
> I did look at this video: it verifi
many Debian users that
> > > did write bug reports against the Debian version of cdrtools did already
> > > switch to a self compiled original source in order to get a working
> > > cdrecord.
> > >
> > > Why don't you read my reply?
> >
> &
> - With Linux 2.6.x, it is impossible to run cdrecord without
> root privs.
>
> Do not believe single persons who claim otherwise as Linux-2.6.x
> filters away random SCSI commands when cdrecord does not have
> root-privs and as cdrecord heavily depends
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > Do you really believe that you are able to deflect from the main problem:
> >
> > The original sources do not have such bugs and many Debian users that
> > did write bug reports against the Debian version of cdrt
strictly use kernel 2.4.x, ide-scsi emulation and
> install your programs as suid-root.
You again prove that you are uninformed.
If you did really work as Debian cdrtools maintainer, you would have read the
bug repor
Hubert Chan <[EMAIL PROTECTED]> wrote:
> The GPL (section 3) does restrict distributions of binaries ("object
> code or executable form", to use the words of the GPL, to be more
> accurate, since the GPL only uses the term "binary" once, and only to
> refer to a completely different issue) and sta
On 8/14/06, Florian Weimer <[EMAIL PROTECTED]> wrote:
And to some extent, the FSF must claim that it's not possible to
escape the GPL with a second implementation (so that programs linking
to readline must still be GPLed, even though you could use libedit as
a mostly-transparent replacement, for
* Thomas Bushnell:
>> As a countermeasure, the FSF tries to extend copyright to interfaces,
>> so that you do create a derivative work merely by programming to a
>> specific interface of a library written by someone else, without
>> copying their code. I'm not sure if this is such a bright idea.
On Sun, Aug 13, 2006 at 12:28:15PM +0200, Joerg Schilling wrote:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > Joerg Schilling <[EMAIL PROTECTED]> writes:
> > > Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > >> Why do you ins
Joerg Schilling <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Joerg Schilling <[EMAIL PROTECTED]> writes:
>>
>> > Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> >
>> >> Why do you insi
And don't tell me I am lying, our BTS is full of them.
> I did never claim that cdrecord is free of bugs, but it works out of the box
> on Linux while the version Debian publishes does not because Debian introduced
> bugs into cdrtools that are not present in the original.
Then let
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Joerg Schilling <[EMAIL PROTECTED]> writes:
>
> > Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> >
> >> Why do you insist on programming bugs into cdrtools that linux
> >> distributi
On Sat, Aug 12, 2006 at 09:48:55PM +0200, Goswin von Brederlow wrote:
> Joerg Schilling <[EMAIL PROTECTED]> writes:
> Please try to read, understand and answere the question asked in a
> mail. Hint: The question wasn't about cdrtools patches.
Please try to take off-topic th
Joerg Schilling <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>
>> Why do you insist on programming bugs into cdrtools that linux
>> distributions have to fix by patching?
>
> You should inform yourself about reality
Are
do so in such a way that the legal problems no longer
apply. He is not saying that there are no legal issues.
> - Eben Moglen tells you that what I do in cdrtools is OK:
> "They" the FSF and Moglen have only be in fear that people
> could interpret the GPL in a
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Why do you insist on programming bugs into cdrtools that linux
> distributions have to fix by patching?
You should inform yourself about reality
The original sources do not have such bugs and many Debian users that
did write
e tell me: This module is a Perl library. If I modify
>> it to become PDF::API2::Debian, how will our users' code be portable?
>
> You are a funny person.
>
> You like to talk avout portabilitiy but the patches that Debian aplies to
> cdrtools are only from two categ
nti ?
>
> Why do Linux distributions insist in applying patches that introduce bugs
> into cdrtools?
>
> Jörg
Why do you insist on programming bugs into cdrtools that linux
distributions have to fix by patching?
Why do you to typos? Why do you stumble sometimes or trip over
somethi
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Daniel Schepler:
>
>> And since dynamic linking is done at the time the program is run,
>> this would appear to me to be what applies. In particular, it
>> appears to me that you could satisfy the GPL and still dynamically
>> link against a non-free
PDF::API2::Debian, how will our users' code be portable?
You are a funny person.
You like to talk avout portabilitiy but the patches that Debian aplies to
cdrtools are only from two categories:
- Patches that introduce bugs that cannot be found in the original
software
-
* Daniel Schepler:
> And since dynamic linking is done at the time the program is run, this would
> appear to me to be what applies. In particular, it appears to me that you
> could satisfy the GPL and still dynamically link against a non-free library,
> and distribute both, by invoking the "m
oduce bugs
into cdrtools?
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
--
To UNS
Alle Saturday 12 August 2006 16:09, Jon Dowland ha scritto:
> At 1155391794 past the epoch, Bernd Schubert wrote:
> > Btw, why always the autotools while there's this nice
> > cmake?
>
> I've never used cmake myself, so I can't speak for how nice
> it is, but autotools (for all its problems) is ver
At 1155391794 past the epoch, Bernd Schubert wrote:
> Btw, why always the autotools while there's this nice
> cmake?
I've never used cmake myself, so I can't speak for how nice
it is, but autotools (for all its problems) is very
widespread.
> The cmake build system might even get accepted by Joe
> The fork-team can look at http://www.arklinux.org/projects/dvdrtools, a
> 100% free fork of cdrtools.
> The SVN is inactive from 6 month, but the autotool-ization is already
> done and it can write on DVDs, and probably is better than starting
> another fork.
Btw, why always the
On Thu, Aug 10, 2006 at 11:25:11PM +0200, Joerg Schilling wrote:
> 1)Throw out Eduard Bloch.
rotflmao.
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PRO
Daniel Schepler <[EMAIL PROTECTED]> writes:
> According to the GPL, section 0:
>
> The act of running the Program is not restricted...
>
> And since dynamic linking is done at the time the program is run, this would
> appear to me to be what applies. In particular, it appears to me that you
>
On Friday 11 August 2006 18:10 pm, Goswin von Brederlow wrote:
> I believe that the totaly interchangable option of specifying
> "-static" or not should not change the free-ness of the source or
> resulting binary. So if you link static and you agree that it is a
> violation that way then you shoul
On Fri, 11 Aug 2006 23:25:52 +0200, Joerg Schilling <[EMAIL PROTECTED]> said:
> Hubert Chan <[EMAIL PROTECTED]> wrote:
>> No, but the combined work (A+B) (i.e. a binary produced by linking
>> module A with module B) is a "work based on" A, and hence (A+B) must
>> be distributable under the terms o
Hi,
On Fri, Aug 11, 2006 at 07:04:51PM -0400, Edward Allcutt wrote:
> On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote:
Your discussion is off-topic for debian-devel, please kindly take it
elsewhere.
Thanks,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "un
On Fri, 2006-08-11 at 23:55 +0200, Joerg Schilling wrote:
> Linking a GPLd program against a non-GPLd library does not make the library a
> derived work of the GPLd program.
but it does mean you may distribute the resulting binary only if you make the
library
source available under the GPL, and i
You did write:
...
>I have a general question about how the GPL is construed to cover the case of
>dynamic linking. According to the GPL, section 0:
...
I am sory to see that you did remove me from the Cc: list
you are the first person at Debian who starts to think the right
way...
If you
Joerg Jaspert <[EMAIL PROTECTED]> writes:
> reassign 377109 ftp.debian.org
> retitle 377109 RM: cdrtools -- RoM: non-free, license problems
> thanks
>
> Hi guys,
>
> ok well, as JS stays with an interpretation of CDDL and GPL that the
> whole world does not follow (a
Daniel Schepler <[EMAIL PROTECTED]> writes:
> Let's put aside for the moment that the FAQ is not meant to be a legal
> document as opposed to the GPL itself, and that the FAQ is not saying B would
> be a derived work of A, but rather that the combination would be...
>
> I have a general question
Hubert Chan <[EMAIL PROTECTED]> wrote:
> No, but the combined work (A+B) (i.e. a binary produced by linking
> module A with module B) is a "work based on" A, and hence (A+B) must be
> distributable under the terms of the GPL.
>
> Distributing the sources of A with the sources of B may be fine, bu
Jorg Schilling wrote:
[...]
> Sorry, but I do not believe people that put things into a GPL FAQ that
> are obviously wrong. Let me give a single example to avoid wasting too
> much time:
> The FSF GPL FAQ e.g. incorrectly claims:
> Linking ABC statically or dynamically with other modules
Alle Friday 11 August 2006 22:51, Joerg Jaspert ha scritto:
> reassign 377109 ftp.debian.org
> retitle 377109 RM: cdrtools -- RoM: non-free, license problems
> thanks
>
> Hi guys,
>
> ok well, as JS stays with an interpretation of CDDL and GPL that the
> whole world does n
On Friday 11 August 2006 14:48 pm, Joerg Schilling wrote:
> The FSF GPL FAQ e.g. incorrectly claims:
>
> Linking ABC statically or dynamically with other modules is making a
> combined work based on ABC. Thus, the terms and conditions of the GNU
> General Public License cover th
Joerg Jaspert <[EMAIL PROTECTED]> wrote:
> > Eduard Bloch has absolutely no clue and on the other side implicitely
> > claims
> > in his arrogant habbit that he knows more about cdrtools than I do. This
> > makes
> > it impussoble to cooperate
in case you carefully
listen to Simon Phipps:
- Sun did not make the CDDL incompatible by intention to the GPL
- The only thing that prevents Linux to use the DTrace code in
Linux is the different threading model
- Eben Moglen tells you that what I do in cdrtools is OK:
&
reassign 377109 ftp.debian.org
retitle 377109 RM: cdrtools -- RoM: non-free, license problems
thanks
Hi guys,
ok well, as JS stays with an interpretation of CDDL and GPL that the
whole world does not follow (all wrong, of course :) ), lets go and fix
this. The sane way is to remove cdrtools from
e and on the other side implicitely claims
> in his arrogant habbit that he knows more about cdrtools than I do. This
> makes
> it impussoble to cooperate with him.
You know that this is "Rufschädigung übelster Art"?
> Claiming that Sun did make the CDDL incompatible with the
e other side implicitely claims
in his arrogant habbit that he knows more about cdrtools than I do. This makes
it impussoble to cooperate with him.
> > 2) Update to a recent cdrtools source, do not hide interesting
> > new features from Debian users and (this may be even
On 10743 March 1977, Joerg Jaspert wrote:
> [1]
> http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/theora-small/2006-05-14/tower/OpenSolaris_Java_and_Debian-Simon_Phipps__Alvaro_Lopez_Ortega.ogg
> [2]
> http://debian-meetings.debian.net/pub/debian-meetings/2006/debconf6/mpeg1
1 - 100 of 214 matches
Mail list logo
