Re: Pristine source from upstream VCS repository

[Cyril Brulebois]

Ben Finney  (04/03/2009):
>   * Invoke the appropriate VCS tool to export the specified revision
> from the VCS repository URL to a temporary directory.
> 
>   * Pack the temporary directory to an appropriately-named tarball in
> the current directory.

AFAICT, that doesn't ensure reproducibility. See pristine-* for hints
about things that can change between one environment and another.

Mraw,
KiBi.


signature.asc
Description: Digital signature

ITP: a routing failover daemon

[Russell Coker]

I have written a little Perl program that can ping two routers and configure 
the routing table to route data to whichever router works.

Among other things it can be configured to run a script when a router becomes 
available which can be used for a VPN.

If there is already a good program in Debian to do this then I may refrain 
from adding another (ideally I wouldn't need to maintain my code any more).

My program will be released under the GPL.

I don't know what to name it, suggestions would be appreciated.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Pristine source from upstream VCS repository

[Ben Finney]

Ben Finney  writes:

> For an example of this approach, see the ‘docutils-manpage-writer’
> package.

The package is actually named ‘docutils-writer-manpage’.

-- 
 \“The errors of great men are venerable because they are more |
  `\ fruitful than the truths of little men.” —Friedrich Nietzsche |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Pristine source from upstream VCS repository

[Ben Finney]

Howdy all,

A Debian source package is constructed from a “pristine source”
tree, plus Debian-specific changes. The pristine source is usually the
tarball distributed by the upstream developer of the work.

The ‘uscan’ tool, as configured by the ‘debian/watch’ file in the
source package, allows assurance that every Debian user can get the
same pristine source, for as long as it's available from the same
upstream location — but only if it's available as a tarball.

Increasingly, some upstream developers are not making tarball releases
of their source, and Debian's “pristine source” is an exported
revision from an upstream version control system. The ‘uscan’ tool
currently has no way to accomodate these packages.


Debian's policy §4.9 discusses a ‘debian/rules’ target named
‘get-orig-source’:

 `get-orig-source' (optional)
  This target fetches the most recent version of the original
  source package from a canonical archive site (via FTP or
  WWW, for example), does any necessary rearrangement to turn
  it into the original source tar file format described below,
  and leaves it in the current directory.

I have had some success with the following approach:

* Name the Debian package's release version such that the upstream
  version ends with the upstream VCS revision number, e.g.
  ‘foo-1.2.3~bzr.r987-1’ (the upstream version number is thus
  ‘1.2.3~bzr.r987’).

* Write a ‘debian/get-orig-source’ program that will:

  * Parse the changelog to get the package name and upstream version.

  * Parse the upstream version string to get the specified VCS
revision number.

  * Specify the upstream VCS repository URL.

  * Invoke the appropriate VCS tool to export the specified revision
from the VCS repository URL to a temporary directory.

  * Pack the temporary directory to an appropriately-named tarball in
the current directory.

* In ‘debian/rules’, define ‘get-orig-source’ as a ‘.PHONY’ target,
  and make its action run the program ‘debian/get-orig-source’.

* Write a ‘debian/watch’ that explains in comments that the upstream
  source is fetched via ‘debian/rules get-orig-source’ as per policy.

For an example of this approach, see the ‘docutils-manpage-writer’
package. (The program ‘get-orig-source’ is licensed under GPLv2+,
share and enjoy.)


This gives satisfactory results, but it does require non-trivial
fiddling with each package's rules and programs to do the right thing.
I can't help thinking that it's only a stop-gap waiting for a true
solution.

I imagine a true solution would be to tell the Debian packaging tools
more directly that the source is to be fetched, not as a tarball, but
as a specified revision from a specified public VCS repository.

Is anyone working on something like this capability?

-- 
 \ “It is hard to believe that a man is telling the truth when you |
  `\  know that you would lie if you were in his place.” —Henry L. |
_o__)  Mencken |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Stefano Zacchiroli]

On Tue, Mar 03, 2009 at 06:39:08PM -0800, Steve Langasek wrote:
> If the facility is later implemented as a C executable (or whatever)
> instead of a shell lib, the shell lib would still have to be shipped in dpkg
> so that maintainer scripts don't fail ungracefully when trying to source it.
> That makes it hard to ever get rid of that interface once deployed.

Fair enough, this is a good argument against the shell lib
approach. It works pretty well with the conffile case, especially now
that Guillem announced it will work on it directly within dpkg.

Still, shell lib vs C implementation shows the unavoidable trade off
between being easier to deploy (shell lib) and becoming part of dpkg
itself (C implementation). *If* the goal is building a place where to
start factorizing tons of maintainer script snippets that we are
accumulating then shell lib looks, at least to me, more appropriate
and more readily available.

> > In principle, that package can be dpkg itself (as it was suggested by
> > Joey). Note how we regularly write down in release notes to first
> > upgrade dpkg and then go ahead with the rest of the upgrade. That
> > would trivially solve the usual pre-dependency potential issues.
> 
> No, the way to get dpkg upgraded first is by declaring the
> Pre-Dependency on dpkg.  Then, if there *is* a pre-dependency loop,
> it's detectable and should be resolved...

Don't blame me for the release notes :-), I'm culpable of not having
contributed a single line to them.

But I do agree with you, and that's actually even better. It will just
mean that if packages are fine with the current stable version of the
maintainer script helper package, fine, otherwise they will just add a
Pre-Dependency as usual. As long as the helper package maintainers are
sane-minded, we will never have pre-dep loops.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#518103: ITP: libapp-nopaste-perl -- easy access to any pastebin

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libapp-nopaste-perl
  Version : 0.04
  Upstream Author : Shawn M Moore, C<<  >>
* URL : http://search.cpan.org/dist/App-Nopaste/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : easy access to any pastebin
 Pastebins (also known as nopaste sites) let you post text, usually
 code, for public viewing. They're used a lot in IRC channels to show
 code that would normally be too long to give directly in the channel
 (hence the name nopaste).
 .
 Each pastebin is slightly different. When one pastebin goes down (I'm
 looking at you, http://paste.husk.org), then you have to find a new
 one. And if you usually use a script to publish text, then it's too
 much hassle.
 .
 This module aims to smooth out the differences between pastebins, and
 provides redundancy: if one site doesn't work, it just tries a
 different one.

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: -dbg packages; are they actually useful?

[Paul Wise]

On Wed, Mar 4, 2009 at 2:17 PM, Steve Langasek  wrote:

>> If the -dbg files were more like these sizes:
>
...
>
>> I doubt there's be too much concern
>
> Remaining concerns:
>
> - each of these dbg packages requires manual modification to the source
>  package (incl. adding the package to debian/control)
> - each has to go through the NEW queue
> - each takes up space afterwards in the Packages file
>
> Much better if these can be generated centrally as part of the builds.

Agreed.

To be more useful, this would require that the ftpmaster team allow
source-only uploads or at least always rebuild binary packages
provided by maintainers on the buildds (where the build process can be
more easily controlled).

ftpmasters, what is your current position on source-only uploads or
throwing away maintainer-built debs?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Steve Langasek]

On Tue, Mar 03, 2009 at 10:25:06PM -0500, Theodore Tso wrote:

> > I'm looking at my local mirror (slowly) update at the moment, and I've
> > got to wondering: are the large -dbg packages actually really useful
> > to anybody? I can't imagine that more than a handful of users ever
> > install (to pick an example) the amarok-dbg packages, but we have
> > multiple copies of a 70MB-plus .deb taking up mirror space and
> > bandwidth. I can understand this for library packages, maybe, but for
> > applications?

> There are people working on ways of compressing the debuginfo
> information, and I've been told they might have results within a
> couple of months.  Part of the problem is that depending on how the
> package is built, the -dbg packages can be huge, so it makes the
> cost/benefit ratio somewhat painful.

> If the -dbg files were more like these sizes:

> 224 e2fslibs-dbg_1.41.3-1_i386.deb 52 libss2-dbg_1.41.3-1_i386.deb
> 452 e2fsprogs-dbg_1.41.3-1_i386.deb48 libuuid1-dbg_1.41.3-1_i386.deb
>  76 libblkid1-dbg_1.41.3-1_i386.deb48 uuid-runtime-dbg_1.41.3-1_i386.deb
>  44 libcomerr2-dbg_1.41.3-1_i386.deb

> I doubt there's be too much concern

Remaining concerns:

- each of these dbg packages requires manual modification to the source
  package (incl. adding the package to debian/control)
- each has to go through the NEW queue
- each takes up space afterwards in the Packages file

Much better if these can be generated centrally as part of the builds.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#518099: ITP: libgtk2-mozembed-perl -- Perl interface to the Mozilla embedding widget

[Ryan Niebur]

Package: wnpp
Owner: Ryan Niebur 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: libgtk2-mozembed-perl
  Version : 0.08
  Upstream Author : the gtk2-perl team
* URL : http://gtk2-perl.sourceforge.net/
* License : LGPL-2.1+
  Programming Lang: Perl
  Description : Perl interface to the Mozilla embedding widget
 This module allows a Perl developer to use the Mozilla embedding widget.

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[Tyler MacDonald]

First, I'm a perl programmer so TMTOWTDI is pretty ingrained into my culture.

I use mydns -- yi.org is based off of it, and I also use it as an easy way
to set up dynamic virtual hosts for automated builds on another project, in
conjunction with libapache2-mod-macro and mod_proxy on the frontend, and m4
to dynamically rewrite the port numbers of daemons in cdebootstrap-based
chroot environments on the backend (the way this project is set up, whenever
there is a new checkin into a subversion branch, we end up with a pristine
debian environment running the software...)

All these technologies are "redundant" -- why do we still have both
"debootstrap" and "cdebootstrap" anyway? -- why do we still have squid if
there's a mod_proxy? Why do we have libapache2-mod-macro if mod_perl or m4
can do all of that? Why do we even have PowerDNS *or* MyDNS now that
BIND-DLZ is part of the mainline?

Personally, I'm abandoning MyDNS in the mid-term as well, but if somebody
wants to keep packaging it up for debian, please don't discourage them.

Thanks,
Tyler


Russell Coker  wrote:
> Having different programs to perform a task will decrease the portion of the 
> user-base that runs a given program and if a bug is found it will give some 
> degree of herd immunity.  But the down-side is that more programs means more 
> potential security flaws and spreading the time of people who want to fix 
> security problems (including the security team) across more targets.
> 
> The range of software that is available also adds to the work that I have to 
> do in writing SE Linux policy. I am not complaining, merely noting a fact 
> about the development work.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> 

-- 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[Russell Coker]

On Wednesday 04 March 2009 03:45:19 Giacomo A. Catenazzi wrote:
> It is a network daemon, so you should also considering security:
> different implementations *could* help security,
> so redundancy not always is wast of time.

Having different programs to perform a task will decrease the portion of the 
user-base that runs a given program and if a bug is found it will give some 
degree of herd immunity.  But the down-side is that more programs means more 
potential security flaws and spreading the time of people who want to fix 
security problems (including the security team) across more targets.

The range of software that is available also adds to the work that I have to 
do in writing SE Linux policy. I am not complaining, merely noting a fact 
about the development work.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[William Pitcock]

On Mon, 2009-03-02 at 22:59 +0100, Guus Sliepen wrote:
> On Mon, Mar 02, 2009 at 09:10:21PM +, Ben Hutchings wrote:
> 
> > > On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote:
> > > > 
> > > > What does this have over PowerDNS?
> > > 
> > > Probably nothing, else that I am using it and packaging it for my own 
> > > and thought that it would be a good idea to contribute to Debian, is 
> > > redundancy a problem ?
> > 
> > Even if you're a perfectly responsible maintainer, a new package still
> > requires some work by ftpmaster, the release team, possibly the security 
> > team,
> > and so on.  It also increases the number of options a user has to choose
> > between.  If the package is redundant, this is a waste of their time.
> 
> If it is really redundant then it is also a waste of upstream's time. William,
> since you're trying to package it, could you compare it in detail to PowerDNS,
> and if there is really little difference, try to see if both upstreams can 
> work
> together and merge their efforts? That would help everyone in the end.
> 

It's not me who is trying to package it, but Sylvain Rochet.

William


signature.asc
Description: This is a digitally signed message part

web link has invited you to open a Google mail account

[web link]

I've been using Gmail and thought you might like to try it out. Here's
an invitation to create an account.

---

web link has invited you to open a free Gmail account.

To accept this invitation and register for your account, visit
http://mail.google.com/mail/a-ada53f76aa-0291c74b72-97fe9c3779

Once you create your account, web link will be notified with
your new email address so you can stay in touch with Gmail!

If you haven't already heard about Gmail, it's a new search-based webmail
service that offers:

- Over 2,700 megabytes (two gigabytes) of free storage
- Built-in Google search that instantly finds any message you want
- Automatic arrangement of messages and related replies into
  "conversations"
- Powerful spam protection using innovative Google technology
- No large, annoying ads--just small text ads and related pages that are
  relevant to the content of your messages

To learn more about Gmail before registering, visit:
http://mail.google.com/mail/help/benefits.html

And, to see how easy it can be to switch to a new email service, check
out our new switch guide: http://mail.google.com/mail/help/switch/

We're still working every day to improve Gmail, so we might ask for your
comments and suggestions periodically.  We hope you'll like Gmail.  We
do.  And, it's only going to get better.

Thanks,

The Gmail Team

(If clicking the URLs in this message does not work, copy and paste them
into the address bar of your browser).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: OSS-only applications

[Cyril Brulebois]

Paul Wise  (04/03/2009):
> Is ALSA supported by kFreeBSD or hurd or other unofficial ports?

Last time I checked, GNU/kFreeBSD provided with OSS, not with ALSA
(which is, as its name suggests, Linux-specific).

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: OSS-only applications

[Paul Wise]

On Wed, Mar 4, 2009 at 4:27 AM, Samuel Thibault
 wrote:

> Quite a few packages support only OSS, not ALSA.  Nowadays there's quite
> little probability that your sound board only has an OSS driver, and so
> there is quite little probability that quite a few packages work out the
> box.

Is ALSA supported by kFreeBSD or hurd or other unofficial ports?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Theodore Tso]

On Tue, Mar 03, 2009 at 10:12:22PM +, Steve McIntyre wrote:
> 
> I'm looking at my local mirror (slowly) update at the moment, and I've
> got to wondering: are the large -dbg packages actually really useful
> to anybody? I can't imagine that more than a handful of users ever
> install (to pick an example) the amarok-dbg packages, but we have
> multiple copies of a 70MB-plus .deb taking up mirror space and
> bandwidth. I can understand this for library packages, maybe, but for
> applications?

There are people working on ways of compressing the debuginfo
information, and I've been told they might have results within a
couple of months.  Part of the problem is that depending on how the
package is built, the -dbg packages can be huge, so it makes the
cost/benefit ratio somewhat painful.

If the -dbg files were more like these sizes:

224 e2fslibs-dbg_1.41.3-1_i386.deb 52 libss2-dbg_1.41.3-1_i386.deb
452 e2fsprogs-dbg_1.41.3-1_i386.deb48 libuuid1-dbg_1.41.3-1_i386.deb
 76 libblkid1-dbg_1.41.3-1_i386.deb48 uuid-runtime-dbg_1.41.3-1_i386.deb
 44 libcomerr2-dbg_1.41.3-1_i386.deb

I doubt there's be too much concern

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Steve Langasek]

On Tue, Mar 03, 2009 at 04:55:00PM +0100, Stefano Zacchiroli wrote:
> On Tue, Mar 03, 2009 at 04:17:00PM +0200, Guillem Jover wrote:
> > Introducing either a shell library or a non-integrated dpkg-conffile
> > has a too high cost IMO. It will prompt maintainers to switch to it
> > (when the annoying part is the initial introduction of the support,
> > being there already on packages currently needing it), which they
> > might then need to do again once we get a proper solution, and will
> > mean having to carry a deprecated interface for a long time, or not
> > be able to change the existing one. I'd rather work during this
> > release cycle on improving the general conffile support.

> Hi Guillem, thanks for the improvement proposal, I guess we are all
> eager to beta test it :)

> Nevertheless, I don't get your argument against the essential package
> containing the shell snippet library. To me, it looks very much like
> debhelper. We are used to release of it with new features adding the
> proper versioned dependency to ensure we have the right debhelper.

If the facility is later implemented as a C executable (or whatever)
instead of a shell lib, the shell lib would still have to be shipped in dpkg
so that maintainer scripts don't fail ungracefully when trying to source it.
That makes it hard to ever get rid of that interface once deployed.

> In principle, that package can be dpkg itself (as it was suggested by
> Joey). Note how we regularly write down in release notes to first
> upgrade dpkg and then go ahead with the rest of the upgrade. That
> would trivially solve the usual pre-dependency potential issues.

No, the way to get dpkg upgraded first is by declaring the Pre-Dependency on
dpkg.  Then, if there *is* a pre-dependency loop, it's detectable and should
be resolved...


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Steve Langasek]

On Tue, Mar 03, 2009 at 03:11:12PM -0800, Don Armstrong wrote:
> On Tue, 03 Mar 2009, Steve McIntyre wrote:
> > I've got to wondering: are the large -dbg packages actually really
> > useful to anybody?

> > Thoughts?

> I think they are useful, but probably not for the vast majority of
> users. [I've used them on a few dozen occasions.]

There are 785 packages matching '*-dbg' in unstable on i386.  327 of them
are for applications (well, !libraries).  Does it really make sense to ship
all of these in the archive if, out of the whole set, they're useful to
people on "a few dozen occasions"?

According to popcon[1], 433 of these packages have an install count of 10 or
less; 616 have an install count of 30 or less.[2]  For orphaned packages,
these are the kinds of numbers where the QA team starts talking about
removals.  Granted, the numbers on -dbg packages are going to be lower
because they're often installed just for debugging and then removed again,
but I think we should seriously look at whether all these one-off debug
builds are really justified, and whether they really belong as part of the
main archive (and on all our mirrors).

> What I really wish for is the ability to have a relatively centralized
> location where the symbols from every single package ended up that was
> separate from the normal mirrors.

Yes, absolutely.  Doing this right, though, requires integration with the
buildd network, so that the debugging symbols can be extracted as part of
the official build instead of being lossily reconstructed after the fact.

> The above, coupled with a coredump submission site which would accept
> coredumps and automatically generate backtraces for them (or a script
> that downloaded the -dbg packages, unpacked them and backtraced the
> coredump) would be a great help in debugging some of the relatively
> rare segfaults. [We could probably even hook up a coredump handler to
> such a script.]

> There was some talk that Ubuntu was going to implement such a thing at
> the Prague UDS, but I've no clue if it ever came to fruition.

'apport' in Ubuntu does exactly this (and has been in use since well before
the Prague UDS); it hasn't really been worth evaluating for inclusion in
Debian without first resolving the problem of lack of systematic debugging
symbols.  If there's a will to get that done in Debian now, I will
definitely be happy to ditch the samba-dbg package for one.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] Well, popcon also thinks there are 887 such packages, rather than 785; I
guess there are some of these no longer in unstable.
[2] Unfortunately, thanks to bug-buddy Recommending gnome-dbg, we also have
almost 40 GNOME -dbg packages with greater popcon stats than libc6-dbg!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Daniel Burrows]

  I doubt most users will install them on their own, but I've found
them to be moderately useful in tracking down crashes.  It's easier
to convince people to install a -dbg package than to convince them to
recompile the program from source.

  Daniel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Axel Beckert]

Hi,

On Tue, Mar 03, 2009 at 10:12:22PM +, Steve McIntyre wrote:
> I'm looking at my local mirror (slowly) update at the moment, and I've
> got to wondering: are the large -dbg packages actually really useful
> to anybody? I can't imagine that more than a handful of users ever
> install (to pick an example) the amarok-dbg packages, but we have
> multiple copies of a 70MB-plus .deb taking up mirror space and
> bandwidth. I can understand this for library packages, maybe, but for
> applications?

I was glad to have them available for e.g. tracking down some nasty
xulrunner bugs on non-x86 -- and I guess xulrunner only counts half as
library. Same for liferea, webkit (a library, okay: :) and some webkit
browsers (midori comes to my mind).

Just an idea coming to my mind: What if they are available from their
own APT repository which doesn't need to be mirrored everywhere?
Somehow in a similar way as the CD images are distributed separately.

Ok, the CD images are no APT repository and splitting off the -dbg
packages to a separate repository would mean that what is built from
one source package would have to be split up (probably after upload)
and put into different APT repositories.

Regards, Axel
-- 
Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Sune Vuorela]

On 2009-03-03, Steve McIntyre  wrote:
> Hey folks,
>
> I'm looking at my local mirror (slowly) update at the moment, and I've
> got to wondering: are the large -dbg packages actually really useful
> to anybody? I can't imagine that more than a handful of users ever
> install (to pick an example) the amarok-dbg packages, but we have
> multiple copies of a 70MB-plus .deb taking up mirror space and
> bandwidth. I can understand this for library packages, maybe, but for
> applications?

Yes. They are very useful - without those, crash reports are mostly
useless.

/Sune
 - thru his KDE maintainer glasses


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Ansgar Burchardt]

Hi,

Don Armstrong  writes:

> What I really wish for is the ability to have a relatively centralized
> location where the symbols from every single package ended up that was
> separate from the normal mirrors.
>
> The above, coupled with a coredump submission site which would accept
> coredumps and automatically generate backtraces for them (or a script
> that downloaded the -dbg packages, unpacked them and backtraced the
> coredump) would be a great help in debugging some of the relatively
> rare segfaults. [We could probably even hook up a coredump handler to
> such a script.]
>
> There was some talk that Ubuntu was going to implement such a thing at
> the Prague UDS, but I've no clue if it ever came to fruition.

Ubuntu has both of the above: automatic generation of debug symbol
packages at build time [1] and a backtracing service integrated in the
bug tracker [2].

Regards,
Ansgar

[1] 
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-September/000195.html
Packages with debug symbols can be downloaded from
http://ddebs.ubuntu.com
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023440.html

-- 
PGP: 1024D/595FAD19  739E 2D09 0969 BEA9 9797  B055 DDB0 2FF7 595F AD19


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Bastien ROUCARIES]

On Wed, Mar 4, 2009 at 12:11 AM, Don Armstrong  wrote:
> On Tue, 03 Mar 2009, Steve McIntyre wrote:
>> I've got to wondering: are the large -dbg packages actually really
>> useful to anybody?
>>
>> Thoughts?

See  #508585 and http://debug.debian.net/

It will be really nice to have this stuff generalized for squeeze.

> I think they are useful, but probably not for the vast majority of
> users. [I've used them on a few dozen occasions.]
> What I really wish for is the ability to have a relatively centralized
> location where the symbols from every single package ended up that was
> separate from the normal mirrors.

See http://debug.debian.net/

> The above, coupled with a coredump submission site which would accept
> coredumps and automatically generate backtraces for them (or a script
> that downloaded the -dbg packages, unpacked them and backtraced the
> coredump) would be a great help in debugging some of the relatively
> rare segfaults. [We could probably even hook up a coredump handler to
> such a script.]

Like unbuntu system. it is really really helpful.

> There was some talk that Ubuntu was going to implement such a thing at
> the Prague UDS, but I've no clue if it ever came to fruition.

It is implemented in ubuntu, and lauchpad receive automatic report.

> Don Armstron
>
> --

Bastien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Up for adoption: Xiph.org and OpenEXR packages

[Cyril Brulebois]

Adeodato Simó  (04/03/2009):
> (pkg-multimedia-maintainers and pkg-phototools-devel Bcc'ed).

The latter Cc'd this time.

> 2. OpenEXR packages
> ===
> 
>   * openexr
>   * ilmbase
> 
> These two library packages I RFA'ed quite some time ago (#494877 and
> #494878), but the person who expressed initial interest won't have time
> any time soon, and has indicated it's okay to search for somebody else.

Indeed. I also totally forgot about them, which explains why I didn't
adopt them in the meanwhile.

> I have no idea if these would be appropriate for the pkg-phototools
> group, but I guess it's worth a try. I'm also CC'ing the maintainer of
> openexr-tools, Pino Toscano, in case he has particular interest in
> OpenEXR packages.

(Guess what, I belong to that group. :p)

> I'll file RFA bugs in a week if this thread doesn't succeed, and fix
> RC bugs during that period. If they are many, at some point I will
> have to orphan them.

Unless someone beats me to it, I think I should have more time in a few
weeks (beginning of April might be OK), so openexr & ilmbase could be
added to pkg-phototools in the end.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: -dbg packages; are they actually useful?

[Don Armstrong]

On Tue, 03 Mar 2009, Steve McIntyre wrote:
> I've got to wondering: are the large -dbg packages actually really
> useful to anybody?
> 
> Thoughts?

I think they are useful, but probably not for the vast majority of
users. [I've used them on a few dozen occasions.]

What I really wish for is the ability to have a relatively centralized
location where the symbols from every single package ended up that was
separate from the normal mirrors.

The above, coupled with a coredump submission site which would accept
coredumps and automatically generate backtraces for them (or a script
that downloaded the -dbg packages, unpacked them and backtraced the
coredump) would be a great help in debugging some of the relatively
rare segfaults. [We could probably even hook up a coredump handler to
such a script.]

There was some talk that Ubuntu was going to implement such a thing at
the Prague UDS, but I've no clue if it ever came to fruition.


Don Armstrong

-- 
Science is a way of trying not to fool yourself. The first principle
is that you must not fool yourself, and you are the easiest person to
fool.
 -- Richard Feynman "What is and What Should be the Role of Scientific
Culture in Modern Society"; 1964

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: -dbg packages; are they actually useful?

[Russ Allbery]

Steve McIntyre  writes:

> I'm looking at my local mirror (slowly) update at the moment, and I've
> got to wondering: are the large -dbg packages actually really useful to
> anybody? I can't imagine that more than a handful of users ever install
> (to pick an example) the amarok-dbg packages, but we have multiple
> copies of a 70MB-plus .deb taking up mirror space and bandwidth. I can
> understand this for library packages, maybe, but for applications?

They've been vital for me several times with library packages and I've
occasionally cursed libraries that didn't have them.  I find them much
less interesting for applications (and indeed dropped them from one
application package that I took over after it was orphaned).

There are some exceptions, though; for example, I ship debug symbols for
the OpenAFS fileserver since it's often hard to figure out what's going on
without a backtrace and upstream is very active and very good about
analyzing those backtraces.  I similarly think it's important to provide
debugging symbols for slapd.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Up for adoption: Xiph.org and OpenEXR packages

[Adeodato Simó]

Hello,

(pkg-multimedia-maintainers and pkg-phototools-devel Bcc'ed).

I have several packages (all libraries except one) I can no longer take
proper care of, and I'd appreciate if somebody/group who knows how to
maintain a library would step up and take them.

They come in two groups:

1. Xiph.org packages


  * libao
  * libogg
  * libspiff
  * libtheora
  * libvorbis
  * uriparser
  * vorbis-tools

I initiated some time ago a pkg-xiph project on Alioth to take care of
all these packages. For some time I've been unable to work on them, and
the person who has been doing all of the work since then has recently
stepped down as well.

Maybe pkg-multimedia would like/could take care of them? Or anybody else
wants to adopt the pkg-xiph project? (I'm CC'ing Peter Samuelson, who
expressed interest at some point.)

2. OpenEXR packages
===

  * openexr
  * ilmbase

These two library packages I RFA'ed quite some time ago (#494877 and
#494878), but the person who expressed initial interest won't have time
any time soon, and has indicated it's okay to search for somebody else.

I have no idea if these would be appropriate for the pkg-phototools
group, but I guess it's worth a try. I'm also CC'ing the maintainer of
openexr-tools, Pino Toscano, in case he has particular interest in
OpenEXR packages.

I'll file RFA bugs in a week if this thread doesn't succeed, and fix RC
bugs during that period. If they are many, at some point I will have to 
orphan them.

Many thanks in advance,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- F. Nietzsche


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

-dbg packages; are they actually useful?

[Steve McIntyre]

Hey folks,

I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick an example) the amarok-dbg packages, but we have
multiple copies of a 70MB-plus .deb taking up mirror space and
bandwidth. I can understand this for library packages, maybe, but for
applications?

Thoughts?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Russ Allbery]

Michelle Konzack  writes:
> Am 2009-03-02 10:34:38, schrieb Bernd Schubert:

>> Maybe you should start to test Debian-Testing from time to time and
>> report bugs if something doesn't work for you? Just complaining *after*
>> a release isn't really helpful.

> How many Enterprises do you know, running testing on there production
> machines?

You don't run testing on your production machines.  You run it on your
test/dev systems.  At Stanford, we started running lenny on selected
test/dev systems back in November of 2008 to understand the issues that
we'd run into with the upgrade.  (FWIW, the only thing we ran into was
qLogic's lack of support for current kernels for its HBA drivers, which
isn't a Debian issue.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Michelle Konzack]

Am 2009-03-02 10:34:38, schrieb Bernd Schubert:
> Maybe you should start to test Debian-Testing from time to time and report 
> bugs if something doesn't work for you? Just complaining *after* a release 
> isn't really helpful.

How many Enterprises do you know, running testing on there production
machines?

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Stefano Zacchiroli]

On Tue, Mar 03, 2009 at 05:26:11PM +0100, Josselin Mouette wrote:
> At 16:10, someone wrote in another thread:
> > I believe that you're using circular arguments with no relevance to the
> > actual case in hand. 
> 
> At 16:59, Joerg Schilling wrote :
> > Before you again and again try to present your speudo arguments that go in 
> > circles, carefully read the GPL..
> 
> I think we could call it the Schilling pattern. Given how it is
> predictable, it looks like we have enough data to determine the
> argumentation he will use by advance.

In fact, I'm starting to wonder whether he will pass the Turing test.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#518059: ITP: cfengine3 -- tool for configuring and maintaining network machines

[Antonio Radici]

Package: wnpp
Severity: wishlist
Owner: Antonio Radici 


* Package name: cfengine3
  Version : 3.0.1b3
  Upstream Author : Mark Burgess 
* URL : http://www.cfengine.org/
* License : GPL
  Programming Lang: C
  Description : tool for configuring and maintaining network machines

Cfengine is a suite of programs for integrated autonomic management of either
individual or networked computers
.
Cfengine 3 is both a more powerful and much simplified version of cfengine, 
which has been designed to interoperate with cfengine 2 rather than be 
backwards 
compatible with it
.
With cfengine 3 you can install, configure and maintain computers using powerful
hands-free tools.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#518057: ITP: libvariable-magic-perl -- module to associate user-defined magic to variables from Perl

[Antonio Radici]

Package: wnpp
Severity: wishlist
Owner: Antonio Radici 


* Package name: libvariable-magic-perl
  Version : 0.32
  Upstream Author : Vincent Pit 
* URL : http://search.cpan.org/dist/Variable-Magic
* License : GPL-1+ | Artistic
  Programming Lang: Perl
  Description : module to associate user-defined magic to variables

Variable::Magic is Perl way of enhancing objects. This mechanism lets the user 
add extra data to any variable and hook syntaxical operations (such as access,
assignment or destruction) that can be applied to it
.
With this module, you can add your own magic to any variable without having 
to write a single line of XS.

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#518052: ITP: booh -- image classifier and web album generator

[Lucas Nussbaum]

Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum 

* Package name: booh
  Version : 0.9.1
  Upstream Author : Guillaume Cottenceau
* URL : http://booh.org/
* License : GPLv2
  Programming Lang: Ruby
  Description : image classifier and web album generator

Booh is an image classifier and a static web album generator. It takes
one or several series of photos and videos, and automatically build
static web pages to browse through them. The image classifier has all
the features that one would expect from such software: automatic
rotation, preloading of images, video support, etc.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Wouter Verhelst]

On Tue, Mar 03, 2009 at 08:58:34PM +0100, Joerg Schilling wrote:
> Bill Unruh  wrote:
> 
> > > Attacks from Debian against the cdrtools project caused the license to be
> > > changed. Debian now needs to live with this change.
> >
> > Unfortunately it is not Debian who have to live with it, but the
> > users around the world. Debian is not being particularly harmed, but
> > the users are. They are being forced to use programs which are not
> > keeping up with modern hardware etc. I understand that there is a
> > lot of ill will between Schilling and Debian, but the only ones
> > getting hurt in the crossfire are innocent civilians. And they have
> > no idea why they are being hurt. This thread started with such a cry
> > of pain.
> 
> As I mentioned before, the attacks have been initated by Eduard Bloch
> who is no longer active in Debian. It would be a nice gesture if
> Debian would through him out. As he is currently already in a
> suspended status, this would be something that is not hard to do by
> Debian but it would show a sign of will.

There is not a chance in hell that Eduard is going to be thrown out.
However, I'm very close to requesting that the list admins ban you from
our mailinglists.

In Debian, we make the rules, not you. If you license your software the
way you have, we will not distribute it, and that is non-negotiable. We
can legally fork software that has been released under the GPL; and you
cannot retroactively change a license on a piece of software that you
have released under the GPL. You can make people use a different name if
you please, and you can require that your name is not used publically on
the fork; but once you have put the code out there under the terms of
the GPL, people can use it, modify it, and redistribute it under those
terms. This is exactly the right that the cdrkit people have exercised,
and there is nothing you can do about that.

Now, it occurs to me that you have three options:

- relicense your software so that it is acceptable to Debian. It does
  not matter in this context whether you think Debian is right or not;
  we will do as we please, not as you do. If *you* want cdrecord in
  Debian, then *you* should make that possible, not us.
- not care about the whole thing and shut up.
- go fuck yourself.

Debian does not care enough about cdrecord to put up with you; we have
plenty of other software that works for most people. I guess it could be
nice to the subset of our users who, like Michelle, have a rather high
bunch of somewhat exotic hardware, but most of our users are not in that
case, and while they are one of their main priorities, there is a
priority of life that says 'nobody should have to deal with arrogant
self-observed morons'.

I'll casually mention that you'll also note that there is no law, in any
jurisdiction anywhere in the world, that says 'Debian must distribute
cdrecord'.

Kind regards,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Bill Unruh  wrote:

> > Attacks from Debian against the cdrtools project caused the license to be
> > changed. Debian now needs to live with this change.
>
> Unfortunately it is not Debian who have to live with it, but the users around
> the world. Debian is not being particularly harmed, but the users are. They
> are being forced to use programs which are not keeping up with modern hardware
> etc. I understand that there is a lot of ill will between Schilling and
> Debian, but the only ones getting hurt in the crossfire are innocent
> civilians. And they have no idea why they are being hurt. This thread started
> with such a cry of pain.

As I mentioned before, the attacks have been initated by Eduard Bloch who is no 
longer active in Debian. It would be a nice gesture if Debian would through him 
out. As he is currently already in a suspended status, this would be something 
that is not hard to do by Debian but it would show a sign of will.

> > Wrong again, instead I explaind already you why this is not the case.
> > The act of compiling does not create a derived work.
>
> I think that legally this is unclear. I believe no US court has ever ruled on
> the issue, and that is the defining character. Without that we have legal
> theories of what "derived work" means in software.

I discussed this with Eben Moglen and he did not mention a different 
intpretation in the US law system.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Bill Unruh  wrote:

> On Tue, 3 Mar 2009, Joerg Schilling wrote:
>
> ...
> >
> > As a hint: "the work mkisofs" is the plain files that can be found in the
> > sub-directory "mkisofs" in the cdrtools source tree. Other sub-directories 
> > in
> > this source tree colletion contain _other_ independent works.
> >
> >
> > You have to decide whether the GPL is a completely unusable license or 
> > whether
> > there is no problem with mkisofs.
>
> I am afraid that we will not solve the problems of the shortcomings of GPL
> here. The question is whether or not we can solve the problems of the
> different reading of the GPL for the purposes of this one program, mkisofs.

Well despite the claims from some people that try to prevent a solution, 
there in fact is only a very minor disagreement. This disagreement is based on 
the attempt from some people to interpret some meaning into the "system 
exception" that is not in the GPL text.


> I understand that in the legal theory you have about the programs there is no
> problem, while under the theory espoused by Debian and many other
> distributions there is a problem. Lets not try to solve everything here, but
> only the one thing-- mkisofs. As I have said, the users would thank you.


Do you see a chance that people would re-read the GPL and try not to put 
meaning into the GPL that is not in the text?

Last night, I send a quote from Eben Moglen that confirms that the "system 
exception" has no meaning besides giving the permission to omit things from 
"the complete source".

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: OSS-only applications

[Samuel Thibault]

Julien Cristau, le Tue 03 Mar 2009 20:36:23 +0100, a écrit :
> On Tue, Mar  3, 2009 at 20:27:54 +0100, Samuel Thibault wrote:
> > Are there plans on this issue?  Drop packages?  Always load snd_pcm_oss?
> > 
> Make those packages depend on oss-compat?

Ah, didn't know that one.  Very few packages depend on it, I guess bug
mass-filling could be useful?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#518045: RFP: pywikipediabot -- Python wikipedia robot framework

[Thomas Viehmann]

Severity: wishlist
Package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org

Hi,

it might be neat to have pywikipediabot in Debian.

Package:  pywikipediabot
URL:  http://pywikipediabot.sourceforge.net/
  see also
  http://meta.wikimedia.org/wiki/Interwiki_bot/Getting_started
Authors:  Various
License:  MIT (mostly)
Language: Python

Tools for maintenance of MediaWiki installations. This also contains
parsers for wikipedia (et al) content.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Bill Unruh]

On Tue, 3 Mar 2009, Joerg Schilling wrote:


Bill Unruh  wrote:


There is absolutely no problem with distributing mkisofs binaries that are
linked against CDDLd libs that are a "different work".


Well, no, there is a problem. Whether that problem is due to a misreading of
the law, differing laws (Under US, the concept of derivative work is a very
important and strong concept. Publishers have been successfully sued for using 
less than
.3% of another work in their work. It is a vague and broad concept, and at
present in a situation like this all we have are legal theories, since courts
have not ruled. Note that part of the SCO suit against IBM is precisely based
on this concept of derivative work, and a broad interpretation thereof. Maybe
that case will clarify the situation, but I doubt it.


The US courts seem to have strange ideas about the Copyright... I know of a case
where a US Lawyer did steal one of the major font collections of the world and
modified only 5% of the mesh-points from be Bezier splines that define the 
fonts.
For almost all people, the resulting fonts look identical to the original fonts.
A US judge did see no Copyright violation in this case.


Yes, what is copyrightable and what not is a complete minefield. And the
concept of derivative work is even more of one. 
Unfortunately one has to live and work within the confines of the legal system

we actually have, not the one that might make sense.







From your comments, it appears that German copyright law does not contain that
concept. Unfortunately all Linux distributions are world wide and have to
worry about the law in many jurisdictions, especially the USA.


There are some basic concepts in the Berne convention that apply to all
countries that singed the Berne contract.


Unfortunately concepts like derivative work apparently are not part of the
convention and anyway, each country interprets the convention as they please.
It is a convention, it is not law.





Anyway, since the people in the Linux distributions clearly are worried about
the legal situation for whatever reason, and since the dual licensing of
libscg or the parts of libscg actually used by mkisofs would make them happy,
and since the benefit to users of having your software available on the
distributions would be great, I would ask you consider doing something like
that.


I know that my theory applies to the European Copyright law and Eben Moglen did
confirm that the relevent parts also apply to the US law system. Isn't this
sufficient?


The answer would appear to be "no", it is not sufficient. Thus, for the sake
of the users, not for the sake of the Debian people, but of the users, it
would be really great if the that licensing issue with libscg and mkisofs
could be brought to a place where it would satisfy the major theories of
copyright law in dispute. That could either be through cross licensing or even
extracting those parts of libscg which are actually used by mkisofs ( and it
seems to be very little), including them in the source for mkisofs and making
them GPL or LGPL. I realise that this is both a pain and an impostion, and it
makes things messier with respect to the code. On the other hand, the current
situation makes things much messier with respect to the users.





J�rg




--
William G. Unruh   |  Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy  | Advanced Research  | Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 |  and Gravity   |  www.theory.physics.ubc.ca/

Re: OSS-only applications

[Julien Cristau]

On Tue, Mar  3, 2009 at 20:27:54 +0100, Samuel Thibault wrote:

> Are there plans on this issue?  Drop packages?  Always load snd_pcm_oss?
> 
Make those packages depend on oss-compat?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: OSS-only applications

[Samuel Thibault]

Samuel Thibault, le Tue 03 Mar 2009 20:27:54 +0100, a écrit :
> Quite a few packages support only OSS, not ALSA.
> [...]
> 
> Are there plans on this issue?  Drop packages?  Always load snd_pcm_oss?

Put another way: how severe should bugs like

#517853 [G|M|  ] [saytime] saytime: depends on the OSS layer

be?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Wouter Verhelst]

On Tue, Mar 03, 2009 at 03:41:40PM +0100, Joerg Schilling wrote:
> Wouter Verhelst  wrote:
> 
> > On Tue, Mar 03, 2009 at 01:09:29PM +0100, Joerg Schilling wrote:
> > > You are uninformed: libc on Linux is under LGPL and the LGPL is as
> > > "incompatible" to GPL as the CDDL is "incomparible" to the GPL.
> >
> > Er?
> 
> Well, it seems that you are uninfored

Yes, I am uninformed in en_JS, that much is true.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

OSS-only applications

[Samuel Thibault]

Hello,

Quite a few packages support only OSS, not ALSA.  Nowadays there's quite
little probability that your sound board only has an OSS driver, and so
there is quite little probability that quite a few packages work out the
box.

Of course, there are solutions: fix the apps, load snd_pcm_oss, or
use alsa-oss.  The first one is just wishes, I'm usually just doing
the second one (the third one is not really convenient), but it's not
necessarily so obvious for a beginner that he could do it to fix his "no
/dev/dsp" error message.

Are there plans on this issue?  Drop packages?  Always load snd_pcm_oss?

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Bill Unruh  wrote:

> > There is absolutely no problem with distributing mkisofs binaries that are
> > linked against CDDLd libs that are a "different work".
>
> Well, no, there is a problem. Whether that problem is due to a misreading of
> the law, differing laws (Under US, the concept of derivative work is a very
> important and strong concept. Publishers have been successfully sued for 
> using less than
> .3% of another work in their work. It is a vague and broad concept, and at
> present in a situation like this all we have are legal theories, since courts
> have not ruled. Note that part of the SCO suit against IBM is precisely based
> on this concept of derivative work, and a broad interpretation thereof. Maybe
> that case will clarify the situation, but I doubt it.

The US courts seem to have strange ideas about the Copyright... I know of a case
where a US Lawyer did steal one of the major font collections of the world and
modified only 5% of the mesh-points from be Bezier splines that define the 
fonts. 
For almost all people, the resulting fonts look identical to the original fonts.
A US judge did see no Copyright violation in this case.


> From your comments, it appears that German copyright law does not contain that
> concept. Unfortunately all Linux distributions are world wide and have to
> worry about the law in many jurisdictions, especially the USA.

There are some basic concepts in the Berne convention that apply to all 
countries that singed the Berne contract.

> Anyway, since the people in the Linux distributions clearly are worried about
> the legal situation for whatever reason, and since the dual licensing of
> libscg or the parts of libscg actually used by mkisofs would make them happy,
> and since the benefit to users of having your software available on the
> distributions would be great, I would ask you consider doing something like
> that.

I know that my theory applies to the European Copyright law and Eben Moglen did
confirm that the relevent parts also apply to the US law system. Isn't this 
sufficient?

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Darren Salt  wrote:

> "End of discussion", as far as I'm concerned. I'm saying no more.

OK, wonderful to see that you no longer write non-fact based claims Once 
you are willing to have a fact based discussion I am willing to continue.

For anyone who likes to know what to read before, it is:


-   The Copyright law   
http://www.gesetze-im-internet.de/urhg/index.html

-   The GPL http://www.opensource.org/licenses/gpl-2.0.php


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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Bill Unruh]

On Tue, 3 Mar 2009, Joerg Schilling wrote:




Particularly in the case of cdrecord, I don't believe there is enough of
a case that we absolutely must have it that we should take a risk on the
licensing. If, on the other hand, you want your software in Debian, you
need to take into account our point of view. After all, surely you agree
that there is no problem with dual-licensing libscg? So what does it
cost you? If you are not interested in having it in Debian then I'm
unclear why you are posting to our mailing lists...


Attacks from Debian against the cdrtools project caused the license to be
changed. Debian now needs to live with this change.


Unfortunately it is not Debian who have to live with it, but the users around
the world. Debian is not being particularly harmed, but the users are. They
are being forced to use programs which are not keeping up with modern hardware
etc. I understand that there is a lot of ill will between Schilling and
Debian, but the only ones getting hurt in the crossfire are innocent
civilians. And they have no idea why they are being hurt. This thread started
with such a cry of pain.





Wrong again, instead I explaind already you why this is not the case.
The act of compiling does not create a derived work.


I think that legally this is unclear. I believe no US court has ever ruled on
the issue, and that is the defining character. Without that we have legal
theories of what "derived work" means in software.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Bill Unruh]

On Tue, 3 Mar 2009, Joerg Schilling wrote:

...


As a hint: "the work mkisofs" is the plain files that can be found in the
sub-directory "mkisofs" in the cdrtools source tree. Other sub-directories in
this source tree colletion contain _other_ independent works.


You have to decide whether the GPL is a completely unusable license or whether
there is no problem with mkisofs.


I am afraid that we will not solve the problems of the shortcomings of GPL
here. The question is whether or not we can solve the problems of the
different reading of the GPL for the purposes of this one program, mkisofs.

I understand that in the legal theory you have about the programs there is no
problem, while under the theory espoused by Debian and many other
distributions there is a problem. Lets not try to solve everything here, but
only the one thing-- mkisofs. As I have said, the users would thank you.





J�rg




--
William G. Unruh   |  Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy  | Advanced Research  | Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 |  and Gravity   |  www.theory.physics.ubc.ca/

Re: xcdroast does no longer work with wodim: Who to blame?

[Bill Unruh]

On Tue, 3 Mar 2009, Joerg Schilling wrote:


Bill Unruh  wrote:


I believe that you mean the above to apply to mkisofs, not to cdrtools, which
is a bunch of different program. The programs which are purely CDDL I assume
you have no problem with distributing (despite your discomfort with CDDL).
  Since it appears that mkisofs is the
only GPL licensed program within cdrtools, the linking of mkisofs with libscg 
is what you find
problematic.


As the FSF is interested to see GPLd programs on OpenSolaris (*), the FSF did
confirm that there is no problem with linking a GPLd program like e.g. GNU tar
with the CDDLd libraries fron OpenSolaris and to publish the resulting binaries.



*) and as a different interpretation of the GPL would make the GPL be in
violation with the Copyright law


There is absolutely no problem with distributing mkisofs binaries that are
linked against CDDLd libs that are a "different work".


Well, no, there is a problem. Whether that problem is due to a misreading of
the law, differing laws (Under US, the concept of derivative work is a very
important and strong concept. Publishers have been successfully sued for using 
less than
.3% of another work in their work. It is a vague and broad concept, and at
present in a situation like this all we have are legal theories, since courts
have not ruled. Note that part of the SCO suit against IBM is precisely based
on this concept of derivative work, and a broad interpretation thereof. Maybe
that case will clarify the situation, but I doubt it.

From your comments, it appears that German copyright law does not contain that
concept. Unfortunately all Linux distributions are world wide and have to
worry about the law in many jurisdictions, especially the USA.


Anyway, since the people in the Linux distributions clearly are worried about
the legal situation for whatever reason, and since the dual licensing of
libscg or the parts of libscg actually used by mkisofs would make them happy,
and since the benefit to users of having your software available on the
distributions would be great, I would ask you consider doing something like
that.




J�rg




--
William G. Unruh   |  Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy  | Advanced Research  | Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 |  and Gravity   |  www.theory.physics.ubc.ca/

Re: [Foo2zjs-maintainer] Bug#517957: foo2zjs: Some user data (firmware) goes in /usr ; should be /usr/local or /etc

[Luca Capello]

block 517957 by 449497
thanks

Hi Daniel!

I cc:ed the d-devel mailing list to get a wider opinion.  Please keep at
least the BTS cc:ed.

On Tue, 03 Mar 2009 08:37:33 +0100, Daniel Dickinson wrote:
> Firmware is looked for under /usr/share/foo2zjs/firmware, but firmware
> is added on and therefore user data and really belongs in /etc or
> /usr/local

I would say that the proper location is /lib/firmware, but AFAIK the
latter is only for firmwares loaded by kernel drivers.  Am I correct?
If so, which folder should be used?

I do not like /etc or /usr/local because depending on the outcome of bug
#449497 [1], some firmwares could even be legally distributable, in
which case even the current location would be fine.  However, if there
is a "proper" one, I would prefer to use it ASAP.

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/449497


pgpgLJzTLXudn.pgp
Description: PGP signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Darren Salt]

I demand that Joerg Schilling may or may not have written...

[snip]
> I am definitely not writing self contradicting statements, you are.

Keep telling yourself that; I don't think that anybody else believes you.

> Your problem seems to be that you repeat untrue claims from other people
> without reading the GPL before.

http://groups.google.co.uk/group/uk.comp.os.linux/msg/e1f32622f567ef1d

"End of discussion", as far as I'm concerned. I'm saying no more.

[snip]
-- 
| Darren Salt| linux or ds at  | Absolutely *NOT*| Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | representing Debian | Army
| + Lobby friends, family, business, government.WE'RE KILLING THE PLANET.

Haste maketh waste.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Darren Salt  wrote:

> [Mail-Followup-To set again. I note that the last one was ignored...]
>
> I demand that Joerg Schilling may or may not have written...
>
> > Darren Salt  wrote:
> >>> In order to create a derived work, you need to add own code of a
> >>> sufficient creation level. The simple act of compiling does of course
> >>> not create a derived work.
> >> By that argument, it seems to me that if I compile (and link) cdrtools,
> >> it's not a derived work; but if you compile (and link) cdrtools, it's a
> >> derived work. (You've definitely added your own code, whereas I haven't
> >> added anything.)
>
> > You seem to be extremely confused. Try to first write as many internal
> > draft version before you come back with something that does not contradict
> > within a single sentence.
>
> Nice. I point out a problem in what you said, and get accusations of
> confusion and self-contradiction in return. I have this suspicion that you're
> using two definitions of "derived work" and are picking whichever best suits
> your argument.

As long as you are not prepared to understand and to discuss the license issues
I see no way to advance.

I am definitely not writing self contradicting statements, you are.

Your problem seems to be that you repeat untrue claims from other people 
without reading the GPL before. If we like toi discuss "license issues" it of 
course makes no sense if you are not able to discuss at eye level. So please 
first read the GPL as many times as needed to understand the basic concepts in 
it.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Michael Banck]

On Tue, Mar 03, 2009 at 04:51:26PM +, Darren Salt wrote:
> Chances are that I'll not be the last either. I think that he's a lost cause
> wrt getting that licensing sorted out, but you know, million-to-one...

million-to-one is the debian-devel S/N ratio you're aiming for?


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Darren Salt]

I demand that Michael Banck may or may not have written...

> On Tue, Mar 03, 2009 at 03:33:57PM +, Darren Salt wrote:
>> Strange, then, that Eben Moglen's opinion, quoted in this very thread,
>> should refer explicitly to the C library and otherwise only to *system*
>> libraries.

> You're not the first to point this out. 

Chances are that I'll not be the last either. I think that he's a lost cause
wrt getting that licensing sorted out, but you know, million-to-one...

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Burn less waste. Use less packaging. Waste less. USE FEWER RESOURCES.

This tagline is deadlier than a three-second egg.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Marco d'Itri]

On Mar 03, Roger Leigh  wrote:

> You could easily adapt these expressions and logic (if needed,
> they are very general) for use by modprobe.
I did this in 2004. Upstream was not interested.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[William Pitcock]

On Mon, 2009-03-02 at 16:42 +0100, Sylvain Rochet wrote:
> Hi,
> 
> On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote:
> > 
> > What does this have over PowerDNS?
> 
> Probably nothing, else that I am using it and packaging it for my own 
> and thought that it would be a good idea to contribute to Debian, is 
> redundancy a problem ?

No, I was just wondering if it had anything over PowerDNS because
PowerDNS has some design concepts that I do not necessarily agree with.

Specifically, the behaviour of PowerDNS's listen-address and listen-ipv6
being separate seems like an unpleasant design that I have found
annoying. listen-address and listen-ipv6 break in unpleasant ways if one
is global scope, and the other is not -- this results in the server
failing to start. I should probably file a bug on that, but I am not
sure if it is a bug or an intentional thing yet.

William



signature.asc
Description: This is a digitally signed message part

Re: xcdroast does no longer work with wodim: Who to blame?

[Darren Salt]

[Mail-Followup-To set again. I note that the last one was ignored...]

I demand that Joerg Schilling may or may not have written...

> Darren Salt  wrote:
>>> In order to create a derived work, you need to add own code of a
>>> sufficient creation level. The simple act of compiling does of course
>>> not create a derived work.
>> By that argument, it seems to me that if I compile (and link) cdrtools,
>> it's not a derived work; but if you compile (and link) cdrtools, it's a
>> derived work. (You've definitely added your own code, whereas I haven't
>> added anything.)

> You seem to be extremely confused. Try to first write as many internal
> draft version before you come back with something that does not contradict
> within a single sentence.

Nice. I point out a problem in what you said, and get accusations of
confusion and self-contradiction in return. I have this suspicion that you're
using two definitions of "derived work" and are picking whichever best suits
your argument.

>>> In addition: if ever, mkisofs could be a derived work if libschily but
>>> not vice vcersa.
>> Now there I don't see any real disagreement (except that I would say not
>> that it may be but that it is).

> You would need to understand the concept of an aimed relationship to allow
> a further discussion.

Hmm, yes, libschily no doubt itself uses the C library, which makes it a
derived work (but then the CDDL presumably has a system library exception).
Best leave it at that, I think :-)

> The GPL is an assymmetrical license and while you are not allowed to let
> non-GPL code call GPL code, the other direction is not affected by the GPL.

I see your troll and I raise you the three-clause BSD licence (by way of
example). And licence incompatibility strikes down your second assertion.

(Hmm. I see another way out: a clean-room reimplementation of libschily,
released under the (L)GPL. No doubt you'll call *that* illegal too...)

Now. Are you prepared to sort out this licensing issue? If not, you should
just accept the existence and availability of cdrkit because there's nothing
that you can do about it. Insist all that you like... oh, wait, you *want*
the attention, don't you... in that case, I'll shut up now :-]

-- 
| Darren Salt| linux or ds at  | Speaking personally, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | representing myself  | Army
| + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING.

There's got to be more to life than compile-and-go.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage

[Giacomo A. Catenazzi]

Ben Hutchings wrote:

On Mon, Mar 02, 2009 at 04:42:19PM +0100, Sylvain Rochet wrote:

Hi,

On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote:

What does this have over PowerDNS?
Probably nothing, else that I am using it and packaging it for my own 
and thought that it would be a good idea to contribute to Debian, is 
redundancy a problem ?


Even if you're a perfectly responsible maintainer, a new package still
requires some work by ftpmaster, the release team, possibly the security team,
and so on.  It also increases the number of options a user has to choose
between.  If the package is redundant, this is a waste of their time.


It is a network daemon, so you should also considering security:
different implementations *could* help security,
so redundancy not always is wast of time.

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Andrea Bolognani]

On Tue, 03 Mar 2009 16:31:30 +0100
joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote:

> Darren Salt  wrote:
> 
> > > In order to create a derived work, you need to add own code of a 
> > > sufficient
> > > creation level. The simple act of compiling does of course not create a
> > > derived work.
> >
> > By that argument, it seems to me that if I compile (and link) cdrtools, it's
> >  ^
> > not a derived work; but if you compile (and link) cdrtools, it's a derived
> >^^^
> > work. (You've definitely added your own code, whereas I haven't added
> > anything.)
> 
> You seem to be extremely confused. Try to first write as many internal draft 
> version before you come back with something that does not contradict within 
> a single sentence.
 
There is no contradiction in that sentence; please read it more carefully.

-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


pgpl3lKU9eegc.pgp
Description: PGP signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Josselin Mouette]

At 16:10, someone wrote in another thread:
> I believe that you're using circular arguments with no relevance to the
> actual case in hand. 

At 16:59, Joerg Schilling wrote :
> Before you again and again try to present your speudo arguments that go in 
> circles, carefully read the GPL..

I think we could call it the Schilling pattern. Given how it is
predictable, it looks like we have enough data to determine the
argumentation he will use by advance.

I wonder if that’s enough to make him fail to pass the Turing test.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: the files in /etc/modprobe.d/

[Raphael Hertzog]

On Tue, 03 Mar 2009, Guillem Jover wrote:
> On Tue, 2009-03-03 at 09:02:18 +0100, Raphael Hertzog wrote:
> > It's already there:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514316
> > 
> > I would happily include such a file, though it probably needs some thought
> > on the API before we commit to support it for eternity. Feel free to help
> > and make a proposal/patch.
> 
> Joey Hess already sent a proposal for a dpkg-conffile last year[0],
> [0] 
> based on the wiki shell snippets. The problem I see with that is that
> it's not properly integrated with the dpkg internals. And I'd expect
> the interface to change once it is actually a proper C binary. The
> current copy-and-paste solution and the scripts even if suboptimal and
> cumbersome, work, but are a hack, a fine one though.

I agree with that but I don't see how it also applies to a shell library.
Once you have a proper C binary, the shell library can simply be modified
to wrap around the C binary.

We just have to make sure that the input parameters of the shell functions
contain everything we might need in the future. And also that the set of
places where we require people to call those functions allow us to
implement most ideas/request concerning conffile handling that we already
know.

And even if conffile renaming is integrated into dpkg itself so that
nothing is needed in maintainer scripts, it's easy to change those
functions back to be no-ops emitting some warnings (if we can't transition
progressively).

> Introducing either a shell library or a non-integrated dpkg-conffile
> has a too high cost IMO. It will prompt maintainers to switch to it
> (when the annoying part is the initial introduction of the support,
> being there already on packages currently needing it), which they might
> then need to do again once we get a proper solution, and will mean
> having to carry a deprecated interface for a long time, or not be able
> to change the existing one. I'd rather work during this release cycle
> on improving the general conffile support.

I don't think introducing a shell library would forbid you to improve
the general conffile support.

That said, we can certainly wait a bit more, until Squeeze plans wrt conffile
handling have been elaborated.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Life - Un salto nella tua filiera

[Gruppo Life-City Srl | Bellaria]

To view the message, please use an HTML compatible email viewer!

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Darren Salt  wrote:

> I demand that Joerg Schilling may or may not have written...
>
> [snip]
> > As the FSF is interested to see GPLd programs on OpenSolaris (*), the FSF
> > did confirm that there is no problem with linking a GPLd program like e.g.
> > GNU tar with the CDDLd libraries fron OpenSolaris and to publish the
> > resulting binaries.
>
> Strange, then, that Eben Moglen's opinion, quoted in this very thread, should
> refer explicitly to the C library and otherwise only to *system* libraries.

You seem to lack the ability to abstract from minor details.


> libschily isn't widely enough used to even be considered as possibly being a
> system library... or do you have evidence to the contrary? Schillix, for
> example? :-)

Before you again and again try to present your speudo arguments that go in 
circles, carefully read the GPL..

There is _absolutely_ no rule in the GPL that allows to treat license 
compatibility for system libraries in a different way than for other libraries.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Michael Banck]

On Tue, Mar 03, 2009 at 03:33:57PM +, Darren Salt wrote:
> Strange, then, that Eben Moglen's opinion, quoted in this very thread, should
> refer explicitly to the C library and otherwise only to *system* libraries.

You're not the first to point this out.  It's unclear why you reiterate
this point unless you want to keep the thread alive?


Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Stefano Zacchiroli]

On Tue, Mar 03, 2009 at 04:17:00PM +0200, Guillem Jover wrote:
> Introducing either a shell library or a non-integrated dpkg-conffile
> has a too high cost IMO. It will prompt maintainers to switch to it
> (when the annoying part is the initial introduction of the support,
> being there already on packages currently needing it), which they
> might then need to do again once we get a proper solution, and will
> mean having to carry a deprecated interface for a long time, or not
> be able to change the existing one. I'd rather work during this
> release cycle on improving the general conffile support.

Hi Guillem, thanks for the improvement proposal, I guess we are all
eager to beta test it :)

Nevertheless, I don't get your argument against the essential package
containing the shell snippet library. To me, it looks very much like
debhelper. We are used to release of it with new features adding the
proper versioned dependency to ensure we have the right debhelper.

Sure we have potentially to deal with pre-dependencies, is that the
problem you were thinking at? While in general pre-dependencies are
bad because they can induce loops, in this specific case they will
always be towards the package containing the shell library which, in a
sense, will be a leaf of the pre-dependency graph.

In principle, that package can be dpkg itself (as it was suggested by
Joey). Note how we regularly write down in release notes to first
upgrade dpkg and then go ahead with the rest of the upgrade. That
would trivially solve the usual pre-dependency potential issues.

We do have evidence that there exist several de facto patterns in
maintainer scripts which are just copy & pasted around. That is
bad(TM), having a place where to factorize them IMO is a must.

/me just trying to understand whether I'm missing something of the
global picture
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Darren Salt  wrote:

> > In order to create a derived work, you need to add own code of a sufficient
> > creation level. The simple act of compiling does of course not create a
> > derived work.
>
> By that argument, it seems to me that if I compile (and link) cdrtools, it's
> not a derived work; but if you compile (and link) cdrtools, it's a derived
> work. (You've definitely added your own code, whereas I haven't added
> anything.)

You seem to be extremely confused. Try to first write as many internal draft 
version before you come back with something that does not contradict within 
a single sentence.


> > In addition: if ever, mkisofs could be a derived work if libschily but not
> > vice vcersa.
>
> Now there I don't see any real disagreement (except that I would say not that
> it may be but that it is).

You would need to understand the concept of an aimed relationship to allow a 
further discussion. The GPL is an assymmetrical license and while you are not 
allowed to let non-GPL code call GPL code, the other direction is not affected 
by the GPL.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Darren Salt]

I demand that Joerg Schilling may or may not have written...

[snip]
> As the FSF is interested to see GPLd programs on OpenSolaris (*), the FSF
> did confirm that there is no problem with linking a GPLd program like e.g.
> GNU tar with the CDDLd libraries fron OpenSolaris and to publish the
> resulting binaries.

Strange, then, that Eben Moglen's opinion, quoted in this very thread, should
refer explicitly to the C library and otherwise only to *system* libraries.

libschily isn't widely enough used to even be considered as possibly being a
system library... or do you have evidence to the contrary? Schillix, for
example? :-)

[snip]
-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING.

"cdrkit is not the pure blessèd cdrtools. EXTERMINATE! EXTERMINATE! 
EXTERMINATE!"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Darren Salt]

[M-F-T set. Do *not* Cc to me.]

I demand that Joerg Schilling may or may not have written...

> Matthew Johnson  wrote:
>> On Tue Mar 03 11:07, Joerg Schilling wrote:
>>> The rules of the GPL end at "work" limit and neither libc nor libschily
>>> or libscg are part of the "work" mkisofs. For this reason, there is no
>>> problem with the fact that mkisofs links against libschily and libscg.
>> The FSF certainly believes (and I think it is supported by at least US
>> copyright law) that the complete work of mkisofs linked against libschily
>> and libscg (i.e. the binary form, rather than the source) is a single
>> work which is a derivative work of all three individual (source) works.
>> Therefore, it must be distributed under terms which are compatible with
>> the licences of all three.

> Repeating false claims does not make them correct.

I echo mjj's response: repeating that claims are false does not make them
false.

> In order to create a derived work, you need to add own code of a sufficient
> creation level. The simple act of compiling does of course not create a
> derived work.

By that argument, it seems to me that if I compile (and link) cdrtools, it's
not a derived work; but if you compile (and link) cdrtools, it's a derived
work. (You've definitely added your own code, whereas I haven't added
anything.)

> In addition: if ever, mkisofs could be a derived work if libschily but not
> vice vcersa.

Now there I don't see any real disagreement (except that I would say not that
it may be but that it is).

> Do you really like to tell us that compiling:

> main()
> {
>   printf("hello world\n");
> }
> 
> makes libc a derived work of the program "hello world"?

I'd be very surprised if he does mean (not like) to tell "us" that.

You're not by any chance trying to set up a static-linking strawman...? But
even there, I'd still say that program Z from source X and library Y is a
derived work of both X and Y and that in no way does that make Y a derived
work of X or Z.

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   Let's keep the pound sterling

Zipping through or taking the time to read?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Brett Parker]

On 03 Mar 15:41, Joerg Schilling wrote:
> Wouter Verhelst  wrote:
> 
> > On Tue, Mar 03, 2009 at 01:09:29PM +0100, Joerg Schilling wrote:
> > > You are uninformed: libc on Linux is under LGPL and the LGPL is as
> > > "incompatible" to GPL as the CDDL is "incomparible" to the GPL.
> >
> > Er?
> 
> Well, it seems that you are uninfored
> 
> If you like to tell me that mkisofs cannot link against libschily because it 
> is
> CDDL, mkisofs could not link against GNU libc either because it is LGPL.

Err, GPL code can link with LGPL code - the LGPL *removes* restrictions
from the GPL, and thus is a compatible licence, as has already been
explained to you.

Also, libc is (fairly much) a system library, and would therefore get
through on that exemption anyways.

> If you believe that GNU libc and mkisofs both together create a derived work, 
> you would need to use the option from the LGPL to tranform the code into GPL.
> 
> .then you would never be able to have X on a Linux platform again as the 
> conversion from LGPL to GPL is irreversible and valid for the master copy of 
> a Distributor.

I believe that you're using circular arguments with no relevance to the
actual case in hand. libschily is *not* a system library and so does not
come through with that exemption, and the CDDL and GPL are incompatible
licences.

Ho hum,
-- 
Brett Parker


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Wouter Verhelst  wrote:

> On Tue, Mar 03, 2009 at 01:09:29PM +0100, Joerg Schilling wrote:
> > You are uninformed: libc on Linux is under LGPL and the LGPL is as
> > "incompatible" to GPL as the CDDL is "incomparible" to the GPL.
>
> Er?

Well, it seems that you are uninfored

If you like to tell me that mkisofs cannot link against libschily because it is
CDDL, mkisofs could not link against GNU libc either because it is LGPL.

If you believe that GNU libc and mkisofs both together create a derived work, 
you would need to use the option from the LGPL to tranform the code into GPL.

.then you would never be able to have X on a Linux platform again as the 
conversion from LGPL to GPL is irreversible and valid for the master copy of 
a Distributor.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Wouter Verhelst]

On Tue, Mar 03, 2009 at 02:57:23PM +0100, Joerg Schilling wrote:
> Matthew Johnson  wrote:
> 
> > On Tue Mar 03 14:14, Joerg Schilling wrote:
> > > Attacks from Debian against the cdrtools project caused the license to be 
> > > changed. Debian now needs to live with this change.
> >
> > We do live with this change. We don't have cdrtools in the archive, this
> > is how we live with such changes.
> 
> Debian is not allowed to publish the fork as the fork is in violation with
> GPL and Copyright.

If you really believe that to be the case, you have a simple option: sue
those working on and distributing the fork. I fail to see how boring
half the world with your narrow viewpoints will help get you anywhere.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Wouter Verhelst]

On Tue, Mar 03, 2009 at 02:14:41PM +0100, Joerg Schilling wrote:
> Attacks from Debian against the cdrtools project caused the license to be 
> changed. Debian now needs to live with this change.

We have. We forked cdrtools, as is perfectly okay with most open source
projects.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Wouter Verhelst]

On Tue, Mar 03, 2009 at 01:09:29PM +0100, Joerg Schilling wrote:
> You are uninformed: libc on Linux is under LGPL and the LGPL is as
> "incompatible" to GPL as the CDDL is "incomparible" to the GPL.

Er?

-
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
[...]

7. Additional Terms.

"Additional permissions" are terms that supplement the terms of this
license by making exceptions from one or more of its conditions.
[...]
-

... is what the GPLv3 says. And the LGPLv3:

-
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007

[...]

This version of the GNU Lesser General Public License incorporates the
terms and conditions of the GNU General Public License, supplemented by
the additional permissions listed below
[...]
-

Or, in other words: the LGPLv3 *is* the GPLv3, using the "Additional
Terms" clause from §7 of the GPLv3. Exactly which part of that is
incompatible with itself?

Oh, and in case you are going to argue that LGPLv2 is incompatible with
GPLv2:

-
GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991
[...]
  3. You may opt to apply the terms of the orderinary GNU General Public
License instead of this license to a given copy of the Library.  To do
so, you must alter all the notices that refer to this License, so that
they refer to the ordinary GNU General Public License, version 2,
instead of to this License.
[...]
-

Not that I expect you to agree to my interpretation; I'm sure you'll
find that this clause is invalid in whatever dialect of English you're
speaking, and so that it's illegal, invalid, silly, or all of the above.

Don't bother to reply, I won't read it.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Roger Leigh]

On Tue, Mar 03, 2009 at 03:09:52AM +0100, Marco d'Itri wrote:
> On Mar 03, Steve Langasek  wrote:
> 
> > On Tue, Mar 03, 2009 at 01:43:53AM +0100, Marco d'Itri wrote:
> > > The upstream maintainers decided that in the future the files in
> > > /etc/modprobe.d/ will be processed only if they have a .conf suffix.
> > What is the point of this change, except to force an annoying transition on
> > people?
> Being sure to ignore backups, packaging systems files, etc.
> It's not that I like this much, but I'd rather not carry forever a patch
> to restore the old behaviour.

run-parts uses a set of simple regular expressions to ignore both backup 
files and dpkg conffile leftovers.  This is the relevent code from the 
schroot run-parts class:

  bool match = false;

  static regex lanana_namespace("^[a-z0-9]+$");
  static regex lsb_namespace("^_?([a-z0-9_.]+-)+[a-z0-9]+$");
  static regex debian_cron_namespace("^[a-z0-9][a-z0-9-]*$");
  static regex debian_dpkg_conffile_cruft("dpkg-(old|dist|new|tmp)$");

  if ((regex_search(name, lanana_namespace) ||
   regex_search(name, lsb_namespace) ||
   regex_search(name, debian_cron_namespace)) &&
  !regex_search(name, debian_dpkg_conffile_cruft))
match = true;

You could easily adapt these expressions and logic (if needed,
they are very general) for use by modprobe.


Regards,
Roger


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Guillem Jover]

On Tue, 2009-03-03 at 09:02:18 +0100, Raphael Hertzog wrote:
> On Mon, 02 Mar 2009, Steve Langasek wrote:
> > On Mon, Mar 02, 2009 at 10:02:11PM -0500, Joey Hess wrote:
> > > 
> > > Insert the typical winge here about dpkg conffile renaming code
> > > being deployed via cut-n-paste from a wiki page instead of any
> > > of our better technologies, such as a utility, with a man page,
> > > in a single package.
> > > 
> > 
> > It would of course have to be in an Essential: yes package, since conffile
> > renaming has to be handled in the package preinst and we wouldn't want
> > conffile handling to involve lots of extra Pre-Depends.  dpkg itself is the
> > most likely package to carry this - wishlist bug on dpkg warranted?
> 
> It's already there:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514316
> 
> I would happily include such a file, though it probably needs some thought
> on the API before we commit to support it for eternity. Feel free to help
> and make a proposal/patch.

Joey Hess already sent a proposal for a dpkg-conffile last year[0],
based on the wiki shell snippets. The problem I see with that is that
it's not properly integrated with the dpkg internals. And I'd expect
the interface to change once it is actually a proper C binary. The
current copy-and-paste solution and the scripts even if suboptimal and
cumbersome, work, but are a hack, a fine one though.

Introducing either a shell library or a non-integrated dpkg-conffile
has a too high cost IMO. It will prompt maintainers to switch to it
(when the annoying part is the initial introduction of the support,
being there already on packages currently needing it), which they might
then need to do again once we get a proper solution, and will mean
having to carry a deprecated interface for a long time, or not be able
to change the existing one. I'd rather work during this release cycle
on improving the general conffile support.

regards,
guillem

[0] 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Matthew Johnson  wrote:

> On Tue Mar 03 14:14, Joerg Schilling wrote:
> > Attacks from Debian against the cdrtools project caused the license to be 
> > changed. Debian now needs to live with this change.
>
> We do live with this change. We don't have cdrtools in the archive, this
> is how we live with such changes.

Debian is not allowed to publish the fork as the fork is in violation with GPL 
and Copyright.

If you like to have legal software you need to use the original.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Wouter Verhelst]

On Tue, Mar 03, 2009 at 12:58:20AM -0800, Bill Unruh wrote:
> OK, good. So if Jorg were to dual license libscg, this would be
> sufficient for Debian to believe that they are able to distribute it?
> This is far weaker than the demand that all of the software be dual
> licensed or GPLed. Whether or not he would be willing to dual license
> libscg I have no idea.

I have no idea either, but I'm willing to venture a guess you won't be
able to convince him.

Jörg is a troll, nothing more, nothing less.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

A plan to provide some patch to improve package configuration upgrades (was: Proposal to improve package configuration upgrades)

[Dominique Dumont]

Stefano Zacchiroli  writes:
> ... now it is only the two of us which needs to stop talking and start
> proposing patches as needed :-)

ok. Here's the plan:

- Identify a "candidate" package to add (as a patch) an upgrade
  feature based on Config::Model. 
- Then, I'll patch this source package to use Config::Model during
  upgrade and test it at home
- Then, I'll send the patch for review and comments

Now, I need some help to identify the package I'll will work on.

This package should have a configuration not too complex and its
configuration definition should not move too fast. So this excludes
exim, sendmail and xorg.

So, do you have a configuration peeve package that fit the criteria
above and bothered you during upgrades ?

Does anyone want to participate actively to improve upgrade with
Config::Model ? (yes, this is a call for help :-) )

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Matthew Johnson]

On Tue Mar 03 14:14, Joerg Schilling wrote:
> Attacks from Debian against the cdrtools project caused the license to be 
> changed. Debian now needs to live with this change.

We do live with this change. We don't have cdrtools in the archive, this
is how we live with such changes.

I've told you what I'll do to help this situation. Whether or not you
agree with it, not doing that will not get cdrtools in Debian. If you
don't want to do this then we really aren't interested in your software
and I don't see why you are posting on our mailing lists!

I have nothing else to say on the subject. My offer still stands.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Bug#517999: ITP: gremind -- Simple reminder program for GNOME

[Sebastian Krause]

Package: wnpp
Severity: wishlist
Owner: Sebastian Krause 

* Package name: gremind
  Version : 0.1.2
  Upstream Author : Sergio Perticone 
* URL : http://perticone.homelinux.net/~sergio/c++/gremind/
* License : GPL, LGPL
  Programming Lang: C++
  Description : Simple reminder program for GNOME

gremind allows you to remind yourself of events and appointments
and notifies you a single or periodic times.

It stays in the system tray and provides a graphical interface to
add and manage your events. Every time an event happens, it outputs
a notification in the system tray and optionally plays a sound.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Matthew Johnson  wrote:

> On Tue Mar 03 13:38, Joerg Schilling wrote:
>  
> > Repeating false claims does not make them correct.
>
> Repeating that correct claims are false does not make them false.
>
> There is enough weight on the side that I have described that I believe
> it is in Debian's interest to follow them. After all, if we are wrong
> this way round we just miss out on some software. If we are wrong the
> other way round we might get sued.

Wrong

> Particularly in the case of cdrecord, I don't believe there is enough of
> a case that we absolutely must have it that we should take a risk on the
> licensing. If, on the other hand, you want your software in Debian, you
> need to take into account our point of view. After all, surely you agree
> that there is no problem with dual-licensing libscg? So what does it
> cost you? If you are not interested in having it in Debian then I'm
> unclear why you are posting to our mailing lists...

Attacks from Debian against the cdrtools project caused the license to be 
changed. Debian now needs to live with this change.


> > Do you really like to tell us that compiling:
> > 
> > main()
> > {
> > printf("hello world\n");
> > }
> > 
> > makes libc a derived work of the program "hello world"?
>
> No, I am saying that the resulting binary of libc linked with hello
> world is a derivative work of both libc and hello world. You seem to
> have overlooked that in my previous post. There are three works here:


Wrong again, instead I explaind already you why this is not the case.
The act of compiling does not create a derived work.



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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Matthew Johnson]

On Tue Mar 03 13:38, Joerg Schilling wrote:
 
> Repeating false claims does not make them correct.

Repeating that correct claims are false does not make them false.

There is enough weight on the side that I have described that I believe
it is in Debian's interest to follow them. After all, if we are wrong
this way round we just miss out on some software. If we are wrong the
other way round we might get sued.

Particularly in the case of cdrecord, I don't believe there is enough of
a case that we absolutely must have it that we should take a risk on the
licensing. If, on the other hand, you want your software in Debian, you
need to take into account our point of view. After all, surely you agree
that there is no problem with dual-licensing libscg? So what does it
cost you? If you are not interested in having it in Debian then I'm
unclear why you are posting to our mailing lists...

> Do you really like to tell us that compiling:
> 
> main()
> {
>   printf("hello world\n");
> }
> 
> makes libc a derived work of the program "hello world"?

No, I am saying that the resulting binary of libc linked with hello
world is a derivative work of both libc and hello world. You seem to
have overlooked that in my previous post. There are three works here:

- the source of libc (licence A)
- the source of hello world (licence B)
- the resulting binary containing both libc and hello world (licence A+B)

This is obviously the case with static linking, the FSF hold that
dynamic linking is equivalent.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Matthew Johnson  wrote:

> On Tue Mar 03 11:07, Joerg Schilling wrote:
>
> > The rules of the GPL end at "work" limit and neither libc nor
> > libschily or libscg are part of the "work" mkisofs. For this reason,
> > there is no problem with the fact that mkisofs links against libschily
> > and libscg.
>
> The FSF certainly believes (and I think it is supported by at least US
> copyright law) that the complete work of mkisofs linked against
> libschily and libscg (i.e. the binary form, rather than the source) is a
> single work which is a derivative work of all three individual (source)
> works. Therefore, it must be distributed under terms which are
> compatible with the licences of all three. 

Repeating false claims does not make them correct.

In order to create a derived work, you need to add own code of a sufficient 
creation level. The simple act of compiling does of course not create a derived 
work.

In addition: if ever, mkisofs could be a derived work if libschily but not vice 
vcersa.


Do you really like to tell us that compiling:

main()
{
printf("hello world\n");
}

makes libc a derived work of the program "hello world"?

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Harald Braumann  writes:

>> Agreed. But VCS solution is a 80% success/20% silent
>> failure. Config::Model is a 80% success/20% abort. The latter should
>> be easier to deal with for average user.
>
> But you don't need to silently merge (and thus silently fail in some
> cases). You can still ask the user about confirmation.

Agreed. Some user will think before confirming, others will not.

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Josselin Mouette]

Le mardi 03 mars 2009 à 13:09 +0100, Joerg Schilling a écrit :
> You are uninformed: libc on Linux is under LGPL and the LGPL is as 
> "incompatible" 
> to GPL as the CDDL is "incomparible" to the GPL.

In what realm?

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Goswin von Brederlow  wrote:

> joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) writes:
>
> > As said, license compatibility needs to be discussed separately. If you 
> > like 
> > to allow to publish binaries from GPLd programs for _any_ OS that does not 
> > come with a GPLd "libc", you need to allow (*) to link _any_ GPLd program 
> > against _any_ library that is not part of "the work" of the GPLd program. 
> > The
> > rules of the GPL end at "work" limit and neither libc nor libschily or 
> > libscg 
> > are part of the "work" mkisofs. For this reason, there is no problem with 
> > the 
> > fact that mkisofs links against libschily and libscg.
>
> No we don't. We can just keep releasing Debian GNU/Linux which has a
> GPLed "libc". It is not our problem nor our concern if Schilli OS
> does not. Debian is legally only concerned with "Debian OS" and not
> "_any_ OS".

You are uninformed: libc on Linux is under LGPL and the LGPL is as 
"incompatible" 
to GPL as the CDDL is "incomparible" to the GPL.

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Matthew Johnson]

On Tue Mar 03 11:07, Joerg Schilling wrote:

> The rules of the GPL end at "work" limit and neither libc nor
> libschily or libscg are part of the "work" mkisofs. For this reason,
> there is no problem with the fact that mkisofs links against libschily
> and libscg.

The FSF certainly believes (and I think it is supported by at least US
copyright law) that the complete work of mkisofs linked against
libschily and libscg (i.e. the binary form, rather than the source) is a
single work which is a derivative work of all three individual (source)
works. Therefore, it must be distributed under terms which are
compatible with the licences of all three. 

You may disagree with this stance, however, it is a view which Debian
holds. Maybe that's just us being too cautious, but we are by nature
cautious and that isn't going to change. We do a lot of work and
distribution in the US.

You may also think that it _is_ possible to distribute under terms which
satisfy both the CDDL and GPL. There is certainly enough doubt about
this that again, we are being conservative in our interpretations.

Finally, to address your other point that the above view would make the
whole of Debian undistributable: this is where both the system libraries
clause comes in (which libscg doesn't meet) and also the fact that libc
is LGPL and the kernel is GPLv2+exception come in.

Anyway, Debian is not obliged to distribute your software. We have
deliberately conservative interpretations of copyright law and licences
which is unlikely to change. If you want us to distribute it you'll have
to do so under a licence we're happy with. This wouldn't be the first
time we've disagreed with people about the freeness of a licence...

Matt.
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Goswin von Brederlow]

joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) writes:

> As said, license compatibility needs to be discussed separately. If you like 
> to allow to publish binaries from GPLd programs for _any_ OS that does not 
> come with a GPLd "libc", you need to allow (*) to link _any_ GPLd program 
> against _any_ library that is not part of "the work" of the GPLd program. The
> rules of the GPL end at "work" limit and neither libc nor libschily or libscg 
> are part of the "work" mkisofs. For this reason, there is no problem with the 
> fact that mkisofs links against libschily and libscg.

No we don't. We can just keep releasing Debian GNU/Linux which has a
GPLed "libc". It is not our problem nor our concern if Schilli OS
does not. Debian is legally only concerned with "Debian OS" and not
"_any_ OS".

> *) Any definition of "the work" that would include libraries that have been 
>developed independently from the GPLd work would be in violation with the 
>Copyright law anyway.
>
> As a hint: "the work mkisofs" is the plain files that can be found in the 
> sub-directory "mkisofs" in the cdrtools source tree. Other sub-directories in 
> this source tree colletion contain _other_ independent works.
>
>
> You have to decide whether the GPL is a completely unusable license or whether
> there is no problem with mkisofs.

The GPL is a completely unusable license, as defined by your terms. It
is painfully strickt and viral to a fault. That's why we so love it.

>
> Jörg

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Matthew Johnson]

On Tue Mar 03 00:58, Bill Unruh wrote:
> I understand this as well. That is a however a different issue than the legal
> one. It at least opens the possibility, both for Debian and for the many other
> Linux distributions. And relieving the Debian maintainers
> from having to try to keep up to date with new and old hardware, which 
> Schilling has
> proven himself to be willing to do, is an attraction which may help make up 
> for
> other detractions.  It  has been said that Debian is used to working with 
> ornery writers.
>

OK, I've been convinced by this thread that it might be useful to have
cdrecord in Debian. So, here is a suggestion of compromise. I am willing
to sponsor a package of cdrecord into Debian, _providing_ the following
conditions are met:

   - someone who uses it (such as yourself or Michelle) volunteers to be
 the maintainer and work with Jorg
   - the packaging meets my (fairly high) standards
   - Jorg licenses his software in a fashion which is acceptable to
 Debian (which will certainly require resolving the GPL/CDDL
 conflict in mkisofs. I'm not the person who can give an
 authoritative answer on this though, it will require ftp-master
 being happy with the licence).
   - the package, maintainer and Jorg work alongside wodim. This means:
  - it conflicts: with wodim if required
  - Jorg ceases complaining about wodim and its maintainers in any
way, stops telling wodim users they should be using cdrecord,
stops posting to debian or other mailing lists or BTSs claiming
that it's buggy, violates copyright law or similar and stops
threatening anyone with the possibility of legal action who is
involved with it. Basically 'play nice'.
  - Don't complain if frontends are migrated to wodim instead of
cdrecord (of course, if wodim continues to ship a compatibility
symlink, they could use whichever is installed).
   - Jorg doesn't complain about our packaging practices. Yes we will
 patch your software if it needs it. Please do not complain about
 things filed in _our_ BTS telling people to use the upstream
 version (for example).
   - We are not going to do anything about the previous situation to
 salve Jorg's pride, we won't expel Eduard or recant anything that
 was said before. I still think Jorg was wrong, but I do think it's
 potentially useful to have cdrecord in Debian.
   - (this list is not exhaustive)

I don't have the time to package it myself (and I'm happy with wodim, so
don't need to use it), however, I'm prepared to sponsor a package if
Jorg plays nice (and I will, of course, try to do the same in return),
but if not I'll just have it removed again.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Goswin von Brederlow]

Russ Allbery  writes:

> Russell Coker  writes:
>
>> If libschilly met the criteria for being a System Library then it
>> probably have been packaged for use by other programs.  If you want to
>> make a case for including libschilly as a System Library then please
>> provide a list of some of the other programs which depend on it.
>
> It's also worth bearing in mind that, in the past, Debian has decided to
> not assume *any* library shipped with Debian is a System Library since the
> concept isn't particularly meaningful for a distribution maker that
> doesn't divide its software into the system and add-ons.  It's a somewhat
> ill-defined and murky area of the GPL and I think Debian is best served by
> steering entirely clear of it with the exception of not worrying about the
> fact that the kernel is under the GPL.

The linux kernel luckily has a specific excemption:

linux-source-2.6.26/COPYING:

   NOTE! This copyright does *not* cover user programs that use kernel
 services by normal system calls - this is merely considered normal use
 of the kernel, and does *not* fall under the heading of "derived work".

So the ball stops at the libc. That the libc calls syscalls does not
make anything a "derived work" of the kernel and the viral nature of
the GPL is halted there.

Debian can work completly without the system library special case.

> If Debian can't consider OpenSSL to be a System Library, and that was the
> decision that we were advised to make in the past, I can't imagine any
> circumstances that would allow libschilly to qualify.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Hendrik Sattler]

Joerg Schilling schrieb:
> As a hint: "the work mkisofs" is the plain files that can be found in the 
> sub-directory "mkisofs" in the cdrtools source tree. Other sub-directories in 
> this source tree colletion contain _other_ independent works.


So you like to enhance a program with a GPL license by implementing the
extra stuff in a non-GPL library and using that library in the program.
Nice GPL work-around :-(

If that works and is legal, the whole GPL is non-sense.

BTW: just making something compile separately is not independent work.


It's personal optinion as I am no lawyer but it's my understanding of
the GPL. And no, I will not discuss that opinion.

HS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Bill Unruh  wrote:

> I believe that you mean the above to apply to mkisofs, not to cdrtools, which
> is a bunch of different program. The programs which are purely CDDL I assume
> you have no problem with distributing (despite your discomfort with CDDL).
>   Since it appears that mkisofs is the
> only GPL licensed program within cdrtools, the linking of mkisofs with libscg 
> is what you find
> problematic.

As the FSF is interested to see GPLd programs on OpenSolaris (*), the FSF did 
confirm that there is no problem with linking a GPLd program like e.g. GNU tar
with the CDDLd libraries fron OpenSolaris and to publish the resulting binaries.



*) and as a different interpretation of the GPL would make the GPL be in 
violation with the Copyright law


There is absolutely no problem with distributing mkisofs binaries that are 
linked against CDDLd libs that are a "different work".

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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Marco d'Itri]

On Mar 03, Steve Langasek  wrote:

> Is there a chance upstream would accept a patch to implement this as a
> blacklist instead of a whitelist?
This is how it used to work (and still does).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Reinhard Tartler]

Bill Unruh  writes:

> OK, good. So if Jorg were to dual license libscg, this would be
> sufficient for Debian to believe that they are able to distribute it?
> This is far weaker than the demand that all of the software be dual
> licensed or GPLed.  Whether or not he would be willing to dual license
> libscg I have no idea.

The outcome of the SFLC investigation was that Joerg was asked to
include an explicit statement in libscg that linking it in mkisofs is
allowed. The ubuntu technical board has asked him to do so but Joerg
refused because he does not see a necessity to do so. Moreover, he
claimed that big "harm" would be done to unrelated projects because of
that, without further clarifying what he is actually referencing here.

However, he was also told that as soon as he reconsiders this position,
the technical board would continue to investigate the integration of
cdrtools in ubuntu, as there are no further known concerns about the
cdrtools licensing.

> And the use mkisofs makes of libscg seems to be pretty small. I
> understand that he feels that there is no problem with distribution as
> it now stands, but perhaps he would be willing to dual license that
> small part simply in order to make his progam more available to users
> of Linux, who would really benefit.

yes, that would be ideal, but Joerg refuses to make this step.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

Don Armstrong  wrote:

> On Tue, 03 Mar 2009, Joerg Schilling wrote:
> > The "OS exception" in the GPL just allows you to omit things like
> > libc from "the complete source". The The "OS exception" in the GPL
> > does not allow you to treat license compatibility between GPL code
> > and "system libraries" different from license compatibility between
> > GPL code and any other library that was created as a separate work.
>
> Those of us who have been dealing with licensing issues for quite some
> time are very familiar with the "major components of the operating
> system" exception to GPL v2 ?3 and the "System Libraries" exception of
> GPL v3 ?1.

"Those of us", are you kidding?

You just verify again that you did not deal with license issues before,
you definitely have not been part of the discussion around 1987 when 
_we_ did find the solution for problems with early GPL versions. The soulution 
for these problems was to introduce the "system library exception" because
e.g. libc from SunOS in 1987 could not be distributed as part of a "complete 
source". The "system library exception" is just to avoid making the GPL 
violate the license rules from SunOS in the 1980s or other OS platform 
from that time.


If you like to take part if this discussion, you would first need to carefully 
read the GPL and to read what I wrote.

Your current reply is not related to what I wrote and for this reason, we 
cannot base any further discussion on your statements.

Let me repeat:

The "system library exception" has one single goal: It allows to reduce the
amount of code that needs to be published as "complete source" as required by 
GPL section 3.

The "system library exception" definitely does not deal with license 
compatibility. License compatibility is a completely independend issue.


As said, license compatibility needs to be discussed separately. If you like 
to allow to publish binaries from GPLd programs for _any_ OS that does not 
come with a GPLd "libc", you need to allow (*) to link _any_ GPLd program 
against _any_ library that is not part of "the work" of the GPLd program. The
rules of the GPL end at "work" limit and neither libc nor libschily or libscg 
are part of the "work" mkisofs. For this reason, there is no problem with the 
fact that mkisofs links against libschily and libscg.

*) Any definition of "the work" that would include libraries that have been 
   developed independently from the GPLd work would be in violation with the 
   Copyright law anyway.

As a hint: "the work mkisofs" is the plain files that can be found in the 
sub-directory "mkisofs" in the cdrtools source tree. Other sub-directories in 
this source tree colletion contain _other_ independent works.


You have to decide whether the GPL is a completely unusable license or whether
there is no problem with mkisofs.


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 debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Michael Banck]

On Tue, Mar 03, 2009 at 08:12:16AM +1100, Russell Coker wrote:
> On Tue, 3 Mar 2009, Russ Allbery  wrote:
> > If Red Hat wants to pay someone to put up with it, that's their call; it's
> > a lot easier to be polite in the face of an unending stream of personal
> > abuse if you're getting a paycheck for doing it.
> 
> If Red Hat was to do this, then it would not be the only case of Red Hat 
> having a package that Debian users desire.  From time to time I find a 
> situation where a CentOS kernel works better than a Debian kernel, while I 
> agree that it's ideal to try and get the problem in Debian fixed I also have 
> a need to get machines working and sometimes can't invest the necessary 
> amount of time.
> 
> There is the "alien" program to convert an RPM to a .deb.  Is there a way of 
> also automatically tracking the upstream (Fedora or CentOS) version of the 
> package and downloading a new version (with signature checks) when it becomes 
> available?

Russell, what does that have to do with wodim and/or xcdroast?  Next
time you want to start a completely new discussion, please start a
completely new discussion and don't enlarge the already large thread
about xcdroast and wodim.


thanks,

Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Michael Banck]

On Mon, Mar 02, 2009 at 06:52:05PM -0800, Bill Unruh wrote:
> I do not think we are there yet. The claim is that cdrecord cannot be
> distributed as any part of Debian because of legal issues. I am trying to find
> out what the issues are, and narrow them down to their essense. 

Maybe do so in a different forum, it is unclear at this point what your
endeavour has to do with Debian development in general.  


thanks,

Michael


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Benjamin M. A'Lee]

On Mon, Mar 02, 2009 at 05:08:33PM -0800, Bill Unruh wrote:
> On Mon, 2 Mar 2009, James Vega wrote:
>
>> On Mon, Mar 02, 2009 at 02:41:54PM -0800, Bill Unruh wrote:
>>> Thus, is it correct that the issue centers around mkisofs, a program which 
>>> is
>>> under the GPL2 license and is linked with libscg, a CDDL licensed library? 
>>> Is
>>> this where the dispute lies?
>>>
>>> If so, exactly what is the nature of the legal (as opposed to personal)
>>>  disagreement? Schilling has made clear that he does not believe there to
>>> be any legal
>>> impediment to the distribution of the software. Debian has made clear that
>>> they believe that there is such an impediment. What, in as few words as
>>> possible, is the impediment?
>>
>> Read the CDDL section under the FSF's list of GPL incompatible licenses.
>
> I have. It says nothing except give the opinion that the two are incompatible
> ( as are GPL2 and GPL3). In particular it does not address the issue of
> exactly why, in the case of cdrtools, the linking of mkisofs and libscg makes
> the result undistributable.
> Ie, it is not very helpful in helping to resolve this dispute.
>
>>
>> http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses
>>

As was explained elsewhere in this thread (though I don't blame people
for missing it), the GPL mandates that additional restrictions may not
be applied to the code, and the CDDL contains restrictions (related to
patents) that the GPL does not. It's therefore not possible to
distribute something covered by both the GPL and the CDDL without
violating copyright law (unless one is the copyright holder).

Jörg Schilling, as I understand it, does not believe that the above
situation actually occurs, and that the CDDL-licenced and GPL-licenced
parts are entirely separate. Debian disagrees.

-- 
Benjamin M. A'Lee || mail: b...@subvert.org.uk
web: http://subvert.org.uk/~bma/ || gpg: 0xBB6D2FA0


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: xcdroast does no longer work with wodim: Who to blame?

[Bill Unruh]

On Tue, 3 Mar 2009, Matthew Johnson wrote:


On Mon Mar 02 22:36, Bill Unruh wrote:

Are you claiming that he does/did not have the right to release the major
portion of the code under CDDL? (ie those portions that he did release in that
way?) Ie, that he did not have the permission of those other copyright holders
to thus release the code?


Merely stating, I believe, that he would _need_ all of those other
copyright holders to relicesce their sections of the work in the same
manner each time he wants to change the licence and so saying that he is
the sole copyright holder is a slight simplification. Speaking as a dbus


I  agree that it is a simplification, nor has he made the claim that he owns
all the copyrights. He has claimed the right to license under the CDDL and
 I think it is best to assume that he has that permission, unless proven 
otherwise.


contributor, which recently tried to relicense, it's really quite hard
to get hold of everyone in order to do this (we failed). This is why the
FSF insist you grant them the copyright on any patches you submit.


The problem is fairly clear; the combination of GPLed and CDDLed code
is not distributable. Whether Joerg will agree with that statement of
the problem is unlikely, but that's not really our problem anymore.


This is again far too broad a statement. Debian does distribute a
combination of GPL and many other code licenses which are not GPL-- if
they apply to separate and different programs. I am trying to narrow
down the problem.  So again, is the issue the linking of mkisofs with
libscg?


The problem is with the linking. Debian is allowed to ship non-linked
CDDL (or other) software on the same media as GPL software (the 'mere
aggregation' clause) and link GPL fundamental system libraries such as
libc to non-GPL software (the 'system libraries' clause), but it is not
allowed to link anything against GPL software unless the resulting work
as a whole can be distributed under the terms of the GPL.

This means that works licensed under the BSD, MIT, expat etc licences
can be linked against GPL works because they can be distributed under
the terms of the GPL without violating their own terms of distribution.
You cannot distribute a CDDL work under the terms of the GPL without
violating its licence.

As you say, most of cdrecord is pure CDDL and there is no issue with
that at all (assuming the above agreement of all copyright holders. As
you say, we generally have to trust upstreams about this). The issue is
specifically with the combination of a GPL-only mkisofs with a CDDL-only
libscg. If Jorg were to dual-license either of them (again, see
relicensing) then we could distribute the result under the terms of
whichever licence they shared (and it doesn't really matter which).



OK, good. So if Jorg were to dual license libscg, this would be sufficient for
Debian to believe that they are able to distribute it? This is far weaker than
the demand that all of the software be dual licensed or GPLed. Whether or not
he would be willing to dual license libscg I have no idea. And the use mkisofs
makes of libscg seems to be pretty small. I understand that he feels that
there is no problem with distribution as it now stands, but perhaps he would
be willing to dual license that small part simply in order to make his progam 
more
available to users of Linux, who would really benefit.



However, I'll repeat the clause that this would merely make it possible
for us to distribute. It still requires a maintainer who will work with
Jorg, who has been hostile in the past about things like patching his
software and working with the Linux kernel rather than insisting
everything be done like solaris. Debian routinely patches software it
ships for many reasons and this is unlikely to change with cdrecord.


I understand this as well. That is a however a different issue than the legal
one. It at least opens the possibility, both for Debian and for the many other
Linux distributions. And relieving the Debian maintainers
from having to try to keep up to date with new and old hardware, which 
Schilling has
proven himself to be willing to do, is an attraction which may help make up for
other detractions.  It  has been said that Debian is used to working with 
ornery writers.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: the files in /etc/modprobe.d/

[Ferdi Thommes]

after upgrading module-init-tools in unstable just now the boot process shows 
a lot of warnings like:

modprobe: WARNING: All config files need .conf: /etc/modprobe.d/aliases, it 
will be ignored in a future release.

there is blocks of those lines, one for each file in /modprobe.d, 
those blocks are repeated 6 times during boot.

regards



-- 
Ferdi Thommes
2.Vorsitzender
sidux e.V.
_


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org