Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).

[Charles Plessy]

Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
> 
> > The dh_make template for debian/copyright induces many developers to put 
> > their
> > packaging work under the GPL, and I have already seen packages whose 
> > license is
> > otherwise BSD-ish with such patches. If the maintainer suddenly goes MIA and
> > the patch is non-trivial, then in theory if we want to respect what is 
> > written,
> > we are stuck with a GPL'ed patch. Therefore, we have an optional License 
> > field
> > to make things crystal clear if necessary.
> 
> Sounds like dh_make needs a bug report about the default packagaging
> license, could you file one?

Dear all,

we just had a case in the Debian Med packaging team where the upstream author
of software licensed under terms similar to the BSD license got upset to see
the Debian packaging licenced under the GPL, and posted a reminder that GPLed
contributions to his software will not be accepted.

This reminded me of this thread and I filled the bug #540740.

(Note that it is not only about patches, but all the other possible
contributions: documentation, artwork,…)

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


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

Re: Automatic Debug Packages

[Manoj Srivastava]

On Sun, Aug 09 2009, Steve Langasek wrote:

> On Sat, Aug 08, 2009 at 08:33:09PM -0500, Manoj Srivastava wrote:
>> > Manoj Srivastava wrote:
>> >> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> >>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> >>> which is short since the format is basically that of .debs). Do we
>> >>> really need this to be documented in policy?
>
>> >> Not if that is all that is. So ddebs are just  -dbg packages
>> >>  renamed to foo_version_arch.ddeb (you do not need ddeb in the name
>> >>  since they are called .ddebs.)
>
>> > dpkg doesn't know about filenames AFAICS. So you can't coinstall
>> > foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
>> > -ddeb suffix. 
>
>> If we are going to enshrine ddebs into policy, we might as well
>>  teach dpkg about ddebs.
>
> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg to understand
> them as a prerequisite for implementing a general purpose, public
> archive for auto-stripped debugging symbols packages.  There really is

Since this is on -policy, I am commenting on when it gains
 enough gravitas to be enshrined in policy. Getting things in policy is
 also not a pre-requisite for implementing a general purpose, public
 archive for auto-stripped debugging symbols packages.


I do have a question: Why is the fact that these are
 automatically created relevant?


> no reason for dpkg to treat these packages specially - a simple
> namespace convention imposed by Policy (i.e., reserving package names
> ending in "-ddeb" for use by this archive, which is what has been
> proposed) is sufficient, and requires no changes to dpkg, which is as
> it should be.

Why should it be a leading change in policy? Can't we try out
 the experiment, make any changes needed, and then come with  the policy
 change? If we do not need maintainers to change anything, ans we do not
 need dpkg to change anything, why is there a hurry to get this into
 policy before it has been implemented and tested?

> I think the .ddeb extension is a red herring.  There ought not be
> anything new to teach dpkg, here; the only thing of relevance is that
> there not be namespace clashes between the ddebs and the debs in the
> main archive, and the filename is not relevant to that at all.

So why not just have foo-ddeb.*.deb? This is the kind of thing I
 want to see discussed, and alternatives tried for, before we
 hard code stuff into policy.


>> So why are we creating a whole new class of packages which dpkg
>>  does not know about,
>
> dpkg "knows" about them the same way it "knows" about debs, AFAICS.

Why, then, the .ddeb suffix? Why are these not just .debs, with
 a specific naming schema?

>> and which are substantially the same as the current -dbg packages? Is it
>> to just reduce debian/control file bloat?  Or to create debug packages
>> whether or not the maintainer cooperates?
>
> To optionally create debug packages without requiring work by individual
> package maintainers.

Why should automatically created debug packages be treated
 differently than hand crafted ones? Why shouldn't _all_ debug packages
 follow the same naming policy? Is there a reason for this (confusing)
 distinction?

manoj
-- 
"All we are given is possibilities -- to make ourselves one thing or
another." Ortega y Gasset
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Russ Allbery]

Steve Langasek  writes:

> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg to understand
> them as a prerequisite for implementing a general purpose, public
> archive for auto-stripped debugging symbols packages.  There really is
> no reason for dpkg to treat these packages specially - a simple
> namespace convention imposed by Policy (i.e., reserving package names
> ending in "-ddeb" for use by this archive, which is what has been
> proposed) is sufficient, and requires no changes to dpkg, which is as it
> should be.

Or even just -dbg, since aren't the existing debug packages basically
.ddebs, modulo bugs?

> I think the .ddeb extension is a red herring.  There ought not be
> anything new to teach dpkg, here; the only thing of relevance is that
> there not be namespace clashes between the ddebs and the debs in the
> main archive, and the filename is not relevant to that at all.

Yes.

-- 
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: Automatic Debug Packages

[Steve Langasek]

On Sat, Aug 08, 2009 at 08:33:09PM -0500, Manoj Srivastava wrote:
> > Manoj Srivastava wrote:
> >> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
> >>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
> >>> which is short since the format is basically that of .debs). Do we
> >>> really need this to be documented in policy?

> >> Not if that is all that is. So ddebs are just  -dbg packages
> >>  renamed to foo_version_arch.ddeb (you do not need ddeb in the name
> >>  since they are called .ddebs.)

> > dpkg doesn't know about filenames AFAICS. So you can't coinstall
> > foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
> > -ddeb suffix. 

> If we are going to enshrine ddebs into policy, we might as well
>  teach dpkg about ddebs.

I don't have a strong opinion on whether ddebs should be documented in
policy, but I certainly don't agree with requiring dpkg to understand them
as a prerequisite for implementing a general purpose, public archive for
auto-stripped debugging symbols packages.  There really is no reason for
dpkg to treat these packages specially - a simple namespace convention
imposed by Policy (i.e., reserving package names ending in "-ddeb" for use
by this archive, which is what has been proposed) is sufficient, and
requires no changes to dpkg, which is as it should be.

I think the .ddeb extension is a red herring.  There ought not be anything
new to teach dpkg, here; the only thing of relevance is that there not be
namespace clashes between the ddebs and the debs in the main archive, and
the filename is not relevant to that at all.

> So why are we creating a whole new class of packages which dpkg
>  does not know about,

dpkg "knows" about them the same way it "knows" about debs, AFAICS.

> and which are substantially the same as the current -dbg packages? Is it
> to just reduce debian/control file bloat?  Or to create debug packages
> whether or not the maintainer cooperates?

To optionally create debug packages without requiring work by individual
package maintainers.

-- 
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: Bug#540365: ITP: turnin-ng -- Assignment submitter and manager

[Ryan Kavanagh]

(Sorry, resending, I forgot to CC the bug and the list)

On Sun, Aug 09, 2009 at 05:23:43PM +0200, Guillem Jover wrote:
> Hi!
> I hope the packages uploaded won't have a «project» binary in the
> PATH?

Hi Guillem,
At the moment yes, Turnin-NG provides /usr/bin/project since that's what the
original turnin / project app provided. However, I can either:
 1) Rename the project script to something else upstream.
 2) Rename it in the Debian package and add a note to README.Debian.

I'm not sure which I prefer. #1 has the advantage of being consistent across all
distributions. #2 makes it so that if someone else wants to move away from SPARC
and use Turnin-NG as a direct replacement for their old binaries, they can.

What do you think?

Cheers,
Ryan

--
|_)|_/  Ryan Kavanagh |  Gnupg key
| \| \  http://blog.ryanak.ca/|  E95EDDC9


signature.asc
Description: Digital signature

Re: Non-unified patches and dpkg source format ‘3.0 (quilt)’.

[Pierre Habouzit]

On Fri, Aug 07, 2009 at 04:12:35PM +0200, Frank Küster wrote:
> Pierre Habouzit  wrote:
> 
> > On Fri, Aug 07, 2009 at 10:45:14AM +0900, Charles Plessy wrote:
> >> Le Thu, Aug 06, 2009 at 09:26:02AM -0700, Russ Allbery a écrit :
> >> > 
> >> > (filterdiff comes with patchutils.)  Given that, this seems like a 
> >> > tempest
> >> > in a teapot to me.  Just convert the diff into whatever format the tool
> >> > that you're using expects or the reviewer wants to read.
> >> 
> >> Hi Russ and everybody,
> >> 
> >> I already explained that I prefered that the patch stays in the original 
> >> format
> >
> > Then you'll need to write your "own" patch system that calls patch(1) to
> > apply the patches, à la cdbs-simple-patchsys.
> 
> Why should he need to do that?  If you'd had written "submit patches to
> dpkg", I could get a meaning out of it, but here?  He doesn't want to
> diverge from upstream.

Oh boy, are you even reading... That's a workaround to wait for dpkg to
be fixed. If you're willing to fix dpkg, please go ahead, but Charles
first try is clearly _not_ a proper fix, hence for now no such patch
exists.
-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Bug#540701: ITP: wbarconf -- graphical configuration utility for wbar

[Krzysztof Burghardt]

Package: wnpp
Severity: wishlist
Owner: Krzysztof Burghardt 

* Package name: wbarconf
  Version : 0.7.2
  Upstream Author : Mika Hynnä 
* URL : http://www.ihku.biz/wbarconf/
* License : GPLv3
  Programming Lang: Python
  Description : graphical configuration utility for wbar

wbar configuration gui written with Python and GTK+.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



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

Re: Automatic Debug Packages

[Paul Wise]

On Wed, Jul 29, 2009 at 8:18 PM, Emilio Pozuelo
Monfort wrote:

> I proposed [1] a GSoC project this spring which was accepted, and I'm thus
> working on getting automatic debug packages into Debian.

BTW, it would be nice if debug.debian.net were to continue to exist,
but contain binaries and their debugging symbols built with noopt
instead of -O2.

-- 
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: piuparts-MBF: overwriting other packages files

[Holger Levsen]

Hi,

On Samstag, 8. August 2009, Manoj Srivastava wrote:
> So am I correct in my assumption that only file conflicts with
>  packages installed on the once-clean chroot would be detected by the
>  test? Or am I missing something?

Yes. for the rest there is edos.debian.net :)

> > Yes, the results of that are available at
> > http://edos.debian.net/missing-conflicts/ ;-)
> Oh, cool, all of these are already reported as bug. Thanks for
>  the work, whoever is to blame.

Ralf Treinen :-)


regards,
Holger


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

Re: Automatic Debug Packages

[Holger Levsen]

Hi,

On Sonntag, 9. August 2009, Manoj Srivastava wrote:
> The link to the wiki page was missing
>  http://wiki.debian.org/AutomaticDebugPackages

this link was also missing in #508585.


regards,
Holger


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