Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Kalle Kivimaa]

Turbo Fredriksson <[EMAIL PROTECTED]> writes:
> reject at SMTP etc (and claims that this makes Qmail wide open for
> spams is rubish - it's only if/when configured incorrectly that this
> becomes a problem)

How can you configure the QMail to send error messages only to
non-forged sender addresses? I don't see any way of differentiating
these, so the only way to do it is during the SMTP session.

> public domain (if the modifications is ok that is - then we're back to
> my original point - ARE we allowed to distribute modified versions!?).

Debian-legal is the right list to discuss this, in my opinion the new
license is DFSG-free.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Florian Weimer]

* Turbo Fredriksson:

> (and claims that this makes Qmail wide open for spams is rubish - it's
> only if/when configured incorrectly that this becomes a problem)

How can you configure DJB qmail so that it rejects mail for non-existing
local mailboxes at SMTP dialog time?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Andrew M.A. Cater]

On Sun, Dec 23, 2007 at 07:12:09PM +0200, Kalle Kivimaa wrote:
> Miros/law Baran <[EMAIL PROTECTED]> writes:
> > Ah, but it's been there, once. I remember that my first Debian
> > installation included in the default setup all the accounts used by
> > qmail (if not the qmail itself).
> 
> OK, that's possible, I can only remember back to about 2000, when
> there was only the source package. If it has been included as a
> binary, then it must have been removed as distributing a binary used
> to be illegal until the (recent?) license change.
> 

Smail?? [Debian mail agent pre-exim]. Don't think we've _ever_ 
distributed qmail, just as we stopped distributing Pine once the licence 
restrictions became clear for similar reasons. You are making me think 
back to 1996-1997 here :)

Andy



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Kalle Kivimaa]

[EMAIL PROTECTED] (Andrew M.A. Cater) writes:
> Smail?? [Debian mail agent pre-exim]. Don't think we've _ever_ 
> distributed qmail, just as we stopped distributing Pine once the licence 
> restrictions became clear for similar reasons. You are making me think 
> back to 1996-1997 here :)

qmail-src has been in the archive since 1997, so any binary must have
been there before that.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Julian Mehnle]

Kalle Kivimaa wrote:
> in my opinion the new [qmail] license is DFSG-free.

There ain't no new license.  DJB simply retracted his copyright.  As of 
now, anyone can copy the qmail 1.03 code, make modifications at will, 
claim copyright for those modifications, and distribute the whole under 
any license they wish (or none at all, contributing their modifications 
to the public domain as well).


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

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Steinar H. Gunderson]

On Mon, Dec 24, 2007 at 07:29:58AM +0100, Turbo Fredriksson wrote:
>> So, right, the argument we're left with is, it's quick and it doesn't
>> have many apparent security flaws.
> It have NO security flaws (especially not if patching it with the most
> obvious patches).

“No security flaws! And even fewer if you patch it!”

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Stefano Zacchiroli]

On Sun, Dec 23, 2007 at 08:16:07PM +0100, Leo costela Antunes wrote:
> >>> Sorry, but I disagree with this interpretation. For me a Debian native
> >>> package is a package which contains the official debian packaging stuff
> >>> in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
> >>> software has been used historically always as a Debian package, to me
> >>> that is a native Debian package.
> 
> I couldn't find any better and more direct references, but according to
> [0] and [1] your interpretation is wrong.

I was aware of [0] and I was (and still am) convinced that it is not so
clear about the topic. The "definition" of native packages there is
inside an "i.e." parenthesis which says: ``packages which have been
written especially for Debian''.  Well, gdome2-xslt has been written
especially for Debian, since its original target deployment were only
Debian machines (though it has the ordinary configure/make stuff and can
be deployed elsewhere by simply ignoring the debian/ dir).

I was not aware of [1], which is indeed more precise about the topic.
But personally I do not often read the maintainer guide and, assuming
that is the intended meaning of native debian package, then I want that
meaning to be integrated in the policy.

Besides, according to [2] (still in the policy), my interpretation is
not so wrong. Quoting from the "debian_revision" paragraph:

> This format represents the case where a piece of software was written
> specifically to be turned into a Debian package, and so there is only
> one "debianisation" of it and therefore no revision indication is
> required.

I consider gdome2-xslt as perfectly fitting in this category. Note how
this interpretation does not rule out other distribution, nor make any
assumption about whether the package is meaningful outside Debian or
not.


Wrapping up, I can't care less whether gdome2-xslt is Debian native or
not, and I would happy to convert it to a non-native Debian package.
Still, and before doing so, I want to have a clear and agreed upon
interpretation of what is a Debian native package, which is *reflected*
in our authoritative documents.

Cheers.

[0] http://www.debian.org/doc/debian-policy/ch-binary.html#s3.2.1
[1] http://www.debian.org/doc/maint-guide/ch-update.en.html#s-orig-tar
[2] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Stefano Zacchiroli]

On Sun, Dec 23, 2007 at 09:06:07PM +, brian m. carlson wrote:
> [N.B.  I am subscribed to -devel; please do not CC me if you are following 
> up there. ]

[ As you wish, but notice that I didn't have the chance of knowing that
upon my first Cc. I Cc-ed you as bug submitter. Dropping the Cc now. ]

> On Sun, Dec 23, 2007 at 07:35:12PM +0100, Stefano Zacchiroli wrote:
>> There are other examples of packages in the archive which are no way
>> Debian specific, but which are native as gdome2-xslt is; a fresh example
>> I have in mind is ikiwiki.
>
> If ikiwiki FTBFS on GCC 4.3, I will probably file a bug on it, too, when I 
> fix the FTBFS.  I don't think ikiwiki should be Debian-native either, but I 
> happened to file the bug on gdome2-xslt because I was working on it for 
> other reasons.

Is this relevant to our discussion? I was not complaining about your bug
report specificity on gdome2-xslt. I am just interested in a general,
rather than package-specific, outcome.

> It is my impression that this is the case already, but Policy is silent on 
> the issue; I checked before I filed the bug.  Perhaps if a consensus can be 
> reached a guideline should be placed in Policy so that people are not 
> further confused.

It is not so silent (see my other post), full ack on the request of a
clear guideline for this in the policy.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Stefano Zacchiroli]

On Sun, Dec 23, 2007 at 08:01:02PM +0100, Luk Claes wrote:
> I thought this consensus was already a fact and that some maintainers
> just disagree and nobody forced them to change yet...

Well, before forcing them to change we need a place where it is written
that the practice is front, don't we?
(Beside that, full ack on your reasons for not being a native package,
I'll probably fix gdome2-xslt notwithstanding this discussion outcome).

For fun I wrote the attached script which returns, when passed as
arguments one or more Sources file, the list of Debian native packages
(the test is only version based, so there are false negatives, as
gdome2-xslt itself). Only in main we have about 750 native packages.
There is no way of knowing a priori if they are "rightful" native or
not, but really a lot (40%?) of them seems not Debian specific at all

Cheers.

PS the script need python-debian to be installed

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time
#!/usr/bin/python

# grep the names of all Debian native packages out of Sources files
# Copyright (C) 2007 Stefano Zacchiroli <[EMAIL PROTECTED]>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.

import sys

from debian_bundle import deb822

for fname in sys.argv[1:]:
f = file(fname)
for stanza in deb822.Sources.iter_paragraphs(f):
pieces = stanza['version'].split('-')
if len(pieces) < 2:
print stanza['package']
f.close()



signature.asc
Description: Digital signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Toni Mueller]

Hi,

On Mon, 24.12.2007 at 07:29:58 +0100, Turbo Fredriksson <[EMAIL PROTECTED]> 
wrote:
> - all that send receipt on acceptance/delivery, reject at SMTP etc (and
> claims that this makes Qmail wide open for spams is rubish - it's only
> if/when configured incorrectly that this becomes a problem) shouldn't

this I can't agree with. Stock qmail (which I don't advocate) accepts
all mails sent to one of the domains it is configured to accept mails
for ("locals" etc), and decides to bounce mails it can't deliver later.
This causes significant backscatter for the typical

[EMAIL PROTECTED] -> [EMAIL PROTECTED]

junk mail that imho accounts for well over 50% of all spam. This can,
and is (was) used to send spam in the past, albeit in the form of
bounce messages, and when I was running stock qmail this way, I had
hundreds of undeliverable mails sitting in my queue because of that.
After I switched to qmail-ldap and turning RCPTCHECK on (a few years
ago), this wave was extinguished because I now don't accept mails that
are undeliverable.

> be done by an MTA (it isn't in the SMTP RFC that I know of).

What has this to do with RFCs? I didn't see any particular statement
demanding that mails to unknown recipients have to be accepted or
rejected.

> > featureless, and trivially replaced with things
> > that do respect the FHS are IMHO more important.

That's quite untrue, imho. It's not trivial to replace qmail, imho, and
while we are at it, I also consider the slashpackage a much better
"standard" than the FHS anyway (although qmail doesn't follow it,
either). And then qmail-ldap imho at least used to have a better
feature set and better documentation than Postfix (didn't check
recently), or otherwise I'd probably switched.


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Toni Mueller]

Hi Florian,

On Mon, 24.12.2007 at 09:41:22 +0100, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Turbo Fredriksson:
> > (and claims that this makes Qmail wide open for spams is rubish - it's
> > only if/when configured incorrectly that this becomes a problem)
> 
> How can you configure DJB qmail so that it rejects mail for non-existing
> local mailboxes at SMTP dialog time?

afaik, this is not possible with stock qmail (Turbo may know better),
but it can be done with netqmail (a DJB-approved version that was put
together by some of the high-profile users and developers on the qmail
list), and it's trivial to do using qmail-ldap.

For netqmail, which, most notably contains the QMAILQUEUE patch, you
can implement the recipient checking in the alternative queueing
program. I also, at some time in the past, did a patch to qmail that
checked against a flat file of email addresses, one per line, and with
qmail-ldap, which also contains that patch, you can configure a simple
switch (set RCPTCHECK="1" in your tcpserver's access control file) that
will cause qmail-ldap to reject all mail addresses it can't resolve
using either LDAP only (this is what I use), or LDAP + system accounts.


Best,
--Toni++


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Need information

[Jean-Christian BEDIER]

Hi,

I subscribe on this mailling list a few weeks ago because i wanted to know a
solution for publish my .deb on real debian mirror.

In fact i realized a little tools for backup throw a ftp server and i will
be really happy to add it in official debian packages.

Maybe someone can give me some information?

Re: Need information

[George Danchev]

On Monday 24 December 2007, Jean-Christian BEDIER wrote:
> Hi,

Hi Jean-Christian,

> I subscribe on this mailling list a few weeks ago because i wanted to know
> a solution for publish my .deb on real debian mirror.

You need to contact [EMAIL PROTECTED] instead and try to find a 
sponsor (official debian developer) to upload your package to the official 
debian archive. The best way to do that is described at mentors.debian.net 
(please read it carefully).

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[brian m. carlson]

On Mon, Dec 24, 2007 at 12:19:43PM +0100, Toni Mueller wrote:

On Mon, 24.12.2007 at 07:29:58 +0100, Turbo Fredriksson <[EMAIL PROTECTED]> 
wrote:

be done by an MTA (it isn't in the SMTP RFC that I know of).


What has this to do with RFCs? I didn't see any particular statement
demanding that mails to unknown recipients have to be accepted or
rejected.


What the RFC requires is that *if* you accept a mail and then find it 
undeliverable, you must send a non-delivery receipt (NDR).  Because of 
the huge problems with spam that you outlined, most MTAs reject unknown 
recipients at SMTP time to avoid sending backscatter, since it is 
trivial to forge SMTP and RFC2822 information.  Then they never have to 
send an NDR to anyone but their own users, preventing backscatter.


While I personally dislike qmail because of this problem, and because it 
is gratuitously incompatible with every other mail system, if this 
problem can be fixed, I see no reason why it should not be in the 
archive, assuming someone wants to maintain it.


--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
a typesetting engine: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#457695: ITP: kissdx -- kissdx is a PC-Link clone for KiSS media players

[Pjotr Kourzanov]

Package: wnpp
Severity: wishlist
Owner: Pjotr Kourzanov <[EMAIL PROTECTED]>

* Package name: kissdx
  Version : x.y.z
  Upstream Author : Name <[EMAIL PROTECTED]>
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : kissdx is a PC-Link clone for KiSS media players

 kissdx is a PC-Link clone for KiSS media players, based for the
most part on kissd (which it now replaces), with added features
for media playback, management, flexibility and more.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.23-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

New field in binary stanza

[David Paleino]

Hi *,
would it be possible to have a "License" field in the information of a package?
I mean, "apt-cache show foo" shows the fields defined in debian/control and
some others. Would it be possible to parse the license from debian/copyright
and add it to that info? Or, at least, give the chance to developers to use
something like XS-License: in the source stanza of debian/control?

I'm posting here before filing a bug to dpkg, because it seems "the right thing
to do".

Have a nice Christmas,
David

-- 
 . ''`.  Debian maintainer |  http://snipurl.com/qa_page
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: New field in binary stanza

[Neil Williams]

On Mon, 24 Dec 2007 16:51:13 +0100
David Paleino <[EMAIL PROTECTED]> wrote:

> Hi *,
> would it be possible to have a "License" field in the information of a 
> package?

Why? What is the benefit?

A machine-interpretable format for debian/copyright is already
available. Why clutter the dpkg and apt-cache with licence lines?

We already have main vs contrib vs non-free. Why subdivide main?

Some packages can have multiple (compatible) licences - the details of
what is licenced under which can only be properly determined by reading
debian/copyright. It's installed for every package so I don't see the
point.

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgpgDWfSMNkxq.pgp
Description: PGP signature

Re: Bug#457695: ITP: kissdx -- kissdx is a PC-Link clone for KiSS media players

[Guus Sliepen]

On Mon, Dec 24, 2007 at 04:38:13PM +0100, Pjotr Kourzanov wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Pjotr Kourzanov <[EMAIL PROTECTED]>
> 
> * Package name: kissdx
>   Version : x.y.z
>   Upstream Author : Name <[EMAIL PROTECTED]>
> * URL : http://www.example.org/
> * License : (GPL, LGPL, BSD, MIT/X, etc.)
>   Programming Lang: (C, C++, C#, Perl, Python, etc.)

Please fill in the real version, upstream author, url, license and
programming language.

>   Description : kissdx is a PC-Link clone for KiSS media players
> 
>  kissdx is a PC-Link clone for KiSS media players, based for the
> most part on kissd (which it now replaces), with added features
> for media playback, management, flexibility and more.

Please explain in the long description what a "PC-Link clone" does and
what a KiSS media player is (I had to google to find out it is some kind
of set top box to view movies, not a Kisekae Set System viewer).

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Bug#457353: gdome2-xslt: should not be a Debian-native package

[Matthew Johnson]

On Sun Dec 23 15:26, Roberto C. Sánchez wrote:
> On Sun, Dec 23, 2007 at 07:35:12PM +0100, Stefano Zacchiroli wrote:
> > 
> > Sorry, but I disagree with this interpretation. For me a Debian native
> > package is a package which contains the official debian packaging stuff
> > in the upstream tarball. Since I'm also upstream for gdome2-xslt and the
> > software has been used historically always as a Debian package, to me
> > that is a native Debian package.
> > 
> One of the packages in whose upstream maintenance I participate has a
> -doc package with a ~5MB .orig.tar.gz.  Are you suggesting that because
> I keep the debian/ directory in the same VCS as upstream development
> that I need to make a ~5MB upload everytime I make an upload to fix
> something trivial?

More to the point, when you fix something trivial under debian/ does
that cause a new upstream release to happen? There are lots of reasons
why you would want to make debian releases out of sync with upstream
releases (in both directions).

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: New field in binary stanza

[David Paleino]

Il giorno Mon, 24 Dec 2007 16:25:43 +
Neil Williams <[EMAIL PROTECTED]> ha scritto:

> On Mon, 24 Dec 2007 16:51:13 +0100
> David Paleino <[EMAIL PROTECTED]> wrote:
> 
> > Hi *,
> > would it be possible to have a "License" field in the information of a
> > package?
> 
> Why? What is the benefit?
>
> A machine-interpretable format for debian/copyright is already
> available. Why clutter the dpkg and apt-cache with licence lines?

debian/copyright is not available via the APT cache, thus cannot be available
to wrappers like python-apt and others.
 
> ...
>
> Some packages can have multiple (compatible) licences - the details of
> what is licenced under which can only be properly determined by reading
> debian/copyright. It's installed for every package so I don't see the
> point.

Again, it's not about _installed_ packages, but about fetching this information
from the APT cache (i.e. can't install packages on Alioth just to read
debian/copyright...), or any other place that won't require root privileges
(debian/copyright is online, but I believe that parsing it might be kind of a
nightmare, if one wants to give a "standardized" output).

I wondered whether one could add a "custom" XS-License field to his packages,
would that be ok? It doesn't really matter if they become "official" (like
Homepage and Vcs-* did), it's just for the matter of parsing the APT cache
(see [1] to understand what I'm trying to achieve).

Kindly,
David

[1] http://debian-med.alioth.debian.org/tasks/bio.php

-- 
 . ''`.  Debian maintainer |  http://snipurl.com/qa_page
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: New field in binary stanza

[Julien Cristau]

On Mon, Dec 24, 2007 at 16:51:13 +0100, David Paleino wrote:

> Hi *,
> would it be possible to have a "License" field in the information of a 
> package?
> I mean, "apt-cache show foo" shows the fields defined in debian/control and
> some others. Would it be possible to parse the license from debian/copyright
> and add it to that info? Or, at least, give the chance to developers to use
> something like XS-License: in the source stanza of debian/control?
> 
So the Packages file would be as big as the combination of all
debian/copyright files in the archive?

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New field in binary stanza

[David Paleino]

Il giorno Mon, 24 Dec 2007 18:03:39 +0100
Julien Cristau <[EMAIL PROTECTED]> ha scritto:

> On Mon, Dec 24, 2007 at 16:51:13 +0100, David Paleino wrote:
> 
> > Hi *,
> > would it be possible to have a "License" field in the information of a
> > package? I mean, "apt-cache show foo" shows the fields defined in
> > debian/control and some others. Would it be possible to parse the license
> > from debian/copyright and add it to that info? Or, at least, give the
> > chance to developers to use something like XS-License: in the source stanza
> > of debian/control?
> > 
> So the Packages file would be as big as the combination of all
> debian/copyright files in the archive?

No, wait. Probably you just misunderstood me. What I meant is something like:

License: GPL

or, if the case,

License: GPL, MIT, ...

If the license is free, but it's not a "standard" one, one could always write:

License: see debian/copyright.


I repeat, it's just for giving developers the chance to have a quick
look of what the license is. If it's possible to have "custom" fields,
I'll do that only on packages maintained by Debian-Med.

Have a nice Christmas,
David

-- 
 . ''`.  Debian maintainer |  http://snipurl.com/qa_page
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: New field in binary stanza

[Daniel Brumbaugh Keeney]

On Dec 24, 2007 11:07 AM, David Paleino <[EMAIL PROTECTED]> wrote:

> If the license is free, but it's not a "standard" one, one could always write:
>
> License: see debian/copyright.

> David


That seems unnecessary, being the effective default.


Daniel Brumbaugh Keeney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New field in binary stanza

[David Paleino]

Il giorno Mon, 24 Dec 2007 11:10:38 -0600
"Daniel Brumbaugh Keeney" <[EMAIL PROTECTED]> ha scritto:

> On Dec 24, 2007 11:07 AM, David Paleino <[EMAIL PROTECTED]> wrote:
> 
> > If the license is free, but it's not a "standard" one, one could always
> > write:
> >
> > License: see debian/copyright.
>
> That seems unnecessary, being the effective default.

Then one could just omit that field.

It seems like I'm asking an impossible thing to do -.-'

Kindly,
David

-- 
 . ''`.  Debian maintainer |  http://snipurl.com/qa_page
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: New field in binary stanza

[Neil Williams]

On Mon, 24 Dec 2007 17:36:06 +0100
David Paleino <[EMAIL PROTECTED]> wrote:

> > A machine-interpretable format for debian/copyright is already
> > available. Why clutter the dpkg and apt-cache with licence lines?
> 
> debian/copyright is not available via the APT cache, thus cannot be available
> to wrappers like python-apt and others.

So? Why is knowing the licence important before installation anyway?
It's in main, it's free software. It's not in main, a one-line addition
in the dpkg output is not going to tell you much about why.

>From a user perspective, there is no difference between any package in
main as far as a licence is concerned.

> > Some packages can have multiple (compatible) licences - the details of
> > what is licenced under which can only be properly determined by reading
> > debian/copyright. It's installed for every package so I don't see the
> > point.
> 
> Again, it's not about _installed_ packages, but about fetching this 
> information
> from the APT cache (i.e. can't install packages on Alioth just to read
> debian/copyright...), or any other place that won't require root privileges
> (debian/copyright is online, but I believe that parsing it might be kind of a
> nightmare, if one wants to give a "standardized" output).

I can't see any point in having such output available to the user.

If you want this data, write a dedicated wrapper - don't burden
everyone else with an extra 20,000 lines in Packages.gz - create a
local mirror if necessary.

> [1] http://debian-med.alioth.debian.org/tasks/bio.php

So for the sake of one webpage, every Debian user gets yet more bloat
in Packages.gz. Oh good. Sorry, I think that's a really really really
bad idea. Almost makes me think it's 1st April.

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgpUf83QGrCK6.pgp
Description: PGP signature

Re: New field in binary stanza

[Stefano Zacchiroli]

On Mon, Dec 24, 2007 at 04:51:13PM +0100, David Paleino wrote:
> would it be possible to have a "License" field in the information of a 
> package?

I understand your need, but in this case (as opposed to the others you
mention) I believe a new field is not the right solution. The reason is
that in the general case too many information would need to be encoded
in such a field; that's why a machine interpretable copyright format has
been proposed [1].

To avoid bloating the Sources (see other replies) the only possible way
in between would be to have such a field only for "simple cases" (e.g.
GPL-only packages). But I'm way in favour of no information over partial
information.


Maybe the related question is: once the debian/copyright format is
widespread enough, how can we make such an information available
archive-wide mechanically?

[1] http://wiki.debian.org/Proposals/CopyrightFormat

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: New field in binary stanza

[David Paleino]

Il giorno Mon, 24 Dec 2007 17:37:23 +
Neil Williams <[EMAIL PROTECTED]> ha scritto:

> On Mon, 24 Dec 2007 17:36:06 +0100
> David Paleino <[EMAIL PROTECTED]> wrote:
> 
> ...
> 
> From a user perspective, there is no difference between any package in
> main as far as a licence is concerned.

It's not for users, it's for developers.

> I can't see any point in having such output available to the user.

Again,

> If you want this data, write a dedicated wrapper - don't burden
> everyone else with an extra 20,000 lines in Packages.gz - create a
> local mirror if necessary.

I'll do, if necessary.

> > [1] http://debian-med.alioth.debian.org/tasks/bio.php
> 
> So for the sake of one webpage, every Debian user gets yet more bloat
> in Packages.gz. Oh good. Sorry, I think that's a really really really
> bad idea. Almost makes me think it's 1st April.

Please, calm down.

First of all, it's not just that webpage. Go to /tasks/, and you'll see that
there are others. But the most important thing is that this will probably be a
feature of cdd-dev; probably in future other CDDs (Debian-Edu, ...) will also
use that. From this point of view, Debian-Med is kind of a "prototype" for
cdd-dev.

I repeat, if it's needed, I'll write a parser for this. I just wanted to have
the chance not to write a huge script that does the job.

Kindly,
David

-- 
 . ''`.  Debian maintainer |  http://snipurl.com/qa_page
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: New field in binary stanza

[David Paleino]

Il giorno Mon, 24 Dec 2007 18:39:22 +0100
Stefano Zacchiroli <[EMAIL PROTECTED]> ha scritto:

> On Mon, Dec 24, 2007 at 04:51:13PM +0100, David Paleino wrote:
> > would it be possible to have a "License" field in the information of a
> > package?

First of all, thank you for the kind reply. It seemed like the Christmas spirit
has been blown away from this list.

> I understand your need, but in this case (as opposed to the others you
> mention) I believe a new field is not the right solution. The reason is
> that in the general case too many information would need to be encoded
> in such a field; that's why a machine interpretable copyright format has
> been proposed [1].

Well, my proposal was for an optional field: who wants it, uses it.

Anyway, I'm seeing that what I'm telling now has already been proposed for
debian/copyright. The problem is still there though: the chance to see some
information about the license of not installed packages not being connected to
the Internet.

> To avoid bloating the Sources (see other replies) the only possible way
> in between would be to have such a field only for "simple cases" (e.g.
> GPL-only packages). But I'm way in favour of no information over partial
> information.

Well, most of Debian packages have simple licenses (see: GPL, BSD, MIT). And,
again, the field would be totally optional.

> Maybe the related question is: once the debian/copyright format is
> widespread enough, how can we make such an information available
> archive-wide mechanically?

That might be an alternative. Is there any progress on the CopyrightFormat
proposal? I can't find anything on the wiki.

Thank you.

Buon Natale,
David

-- 
 . ''`.  Debian maintainer |  http://snipurl.com/qa_page
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Which spell checkers to include by default?

[Manoj Srivastava]

On Sat, 22 Dec 2007 23:49:05 +0100, Petter Reinholdtsen <[EMAIL PROTECTED]> 
said: 

> [Russ Allbery]
>> See previous thread about old Unix users and what we expect.  :)

> Well, some old unix users might expect it, but I've been using Unix
> and friends since I started with HP-UX 9 in 1992, and I do not expect
> word lists to be installed by default. :)

I have been doing so since '85, and I do expect to find the word
 lists. At this point we just have warring anecdotes; perhaps we should
 be looking for _data_ before we change standard?

> Lets move to the most advanced spell checker, hunspell, and drop
> ispell and friends as a package to install in the base system. :)

We could add hunspell, if it is indeed better.  I am not sure
 the case has been made for dropping ispell.

manoj
-- 
"Don't get married.  Find a woman you hate and buy her a house." anon
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which spell checkers to include by default?

[Manoj Srivastava]

On Sat, 22 Dec 2007 08:08:42 +0100, Petter Reinholdtsen <[EMAIL PROTECTED]> 
said: 

> [Anthony Towns]
>> Kind of reviving an old thread, but anyway: It also includes, but
>> afaics, probably doesn't need to (anymore):
>> 
>> ispell, dictionaries-common, iamerican, ibritish, wamerican

> [Agustin Martin]
>> #416572: ibritish: Should not have priority standard

> We now have aspell, myspell and hunspell as alternatives to ispell,
> and it can be argued that all of them are better than ispell at
> providing spell checking and recommendations for replacements.
> Because of this, I believe it would be a good idea to drop ispell from
> the list of standard packages, and the related packages too (i*, w*).

Are these packages a drop in replacement for ispell?  

> If we were to keep a spell checker as part of the default
> installation, I would suggest using hunspell as it is most advanced
> and I am told it support the most languages at the moment.  The next
> step would be to change all programs currently using ispell, aspell
> and myspell by default to use hunspell instead.  The only package I
> use that are still using ispell is emacs.  No idea how hard it would
> be to update, but it would be a good thing to support for example
> Hungarian and Nothern Sami spell checking in emacs. :)

I suggest we have a look at how many other packages are
 impacted, and what it would take to effect these changes, before the
 decision is taken to drop ispell.

manoj
-- 
Administration: An ingenious abstraction in politics, designed to
receive the kicks and cuffs due to the premier or president.-- Ambrose
Bierce
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Making contributing to Debian easier ; "gift" bug tag

[Lucas Nussbaum]

Hi,

I've been thinking about ways to make contributing to Debian easier. I
sometimes run into the situation where someone asks me "I'd like to
contribute to Debian, what could I do?", and I have problems directing
him to things where he could actually help.

So I worked on two things:

== "Help Debian!" web page ==
I think that we need a page that gives an overview of how a newcomer
could help. And a sexy one. Christian Perrier's slides from FOSS.in[0] are
a very good basis, but we need to work on converting this into something
suitable for a web page.

I started writing some stuff on http://wiki.debian.org/HelpDebian/Start
. Feel free to improve that, or to point me to pages I could use as a
basis. The plan is to move this to a separate, stable, web page, with
pics, etc. There's also a few notes on http://wiki.debian.org/HelpDebian .

[0] http://www.perrier.eu.org/debian/talks/foss-in-2007/contributing.pdf

== "gift" usertag ==
Some projects (Gnome, KDE) use a special tag to indicate bugs that
are suitable for new contributors (see [1]). Debian could use something
similar. I thought of using the "gift" tag for this, but don't hesitate
to propose something better. We can start with a usertag, and, if it
gets widely used, ask for a "normal" tag.

I wrote some documentation on
http://wiki.debian.org/qa.debian.org/GiftTag . Please review it, and
start adding the "gift" usertag (user: [EMAIL PROTECTED]) to
your bugs!

[1] http://live.gnome.org/GnomeLove

= Summary =
How can you help?
- Review/Improve the wiki pages
- Provide feedback
- Add the usertag to your bugs

Thank you, and merry christmas :-)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Which spell checkers to include by default?

[Manoj Srivastava]

On Sat, 22 Dec 2007 20:06:16 +0100, Petter Reinholdtsen <[EMAIL PROTECTED]> 
said: 

> [Brian M. Carlson]
>> Note that the w* packages provide word lists, which are important to
>> many programs.  One could argue that a standard Unix system should
>> have a word list; at least, every Unix system I have used provides
>> one.

> OK.  Which programs?  I was only aware of ispell.

Well, I am not a program, but I often use /usr/share/dict/words
 (I have not yet been able to train my fingers not to look for
 /usr/dict/words) directly, and also as test data for code snippets i
 write.

We should not change out aspects of the system that users have
 come to depend on, if it can be helped.

manoj
-- 
Exercise caution in your daily affairs.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Marco d'Itri]

On Dec 24, Turbo Fredriksson <[EMAIL PROTECTED]> wrote:

> Now, come on!! Get a fng reality check! Have you ever even USED
> Qmail?! And actually READ it's code!?
Yes to both.

http://www.starbsd.org/misc/why-not-qmail.png

I rest my case.

> I have Postfix crash more often on my home machine (~ 10 mails / 24h -
> using an smarthost) than Qmail do on my main mailservers (~ 10k mails / 24h).
Maybe the problem is not postfix or qmail, it's you.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Making contributing to Debian easier ; "gift" bug tag

[Jose Luis Rivas Contreras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lucas Nussbaum wrote:
> Hi,
> 
> I've been thinking about ways to make contributing to Debian easier. I
> sometimes run into the situation where someone asks me "I'd like to
> contribute to Debian, what could I do?", and I have problems directing
> him to things where he could actually help.
> 
> So I worked on two things:
> 
> == "Help Debian!" web page ==
> I think that we need a page that gives an overview of how a newcomer
> could help. And a sexy one. Christian Perrier's slides from FOSS.in[0] are
> a very good basis, but we need to work on converting this into something
> suitable for a web page.
> 
> I started writing some stuff on http://wiki.debian.org/HelpDebian/Start
> . Feel free to improve that, or to point me to pages I could use as a
> basis. The plan is to move this to a separate, stable, web page, with
> pics, etc. There's also a few notes on http://wiki.debian.org/HelpDebian .
> 

Well, in Spanish there's a similar initiative, anyone interested can
check http://wiki.debian.org/ComoContribuir that translated is "HowToHelp".

And the tag idea it's very nice.

Regards.
- --
Jose Luis Rivas. San Cristóbal, Venezuela. PGP: 0xCACAB118
http://ghostbar.ath.cx/{about,acerca} - http://debian.org.ve
`ghostbar' @ irc.debian.org/#debian-ve,#debian-devel-es
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHb/3UOKCtW8rKsRgRAlaGAJ9MgZzokn0Q/36ClsXiyT8dORCzhgCfasGq
ZsDLm+bkN0XUeQyZN80kzEE=
=QUyh
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New field in binary stanza

[Neil Williams]

On Mon, 24 Dec 2007 18:43:57 +0100
David Paleino <[EMAIL PROTECTED]> wrote:

> > From a user perspective, there is no difference between any package in
> > main as far as a licence is concerned.
> 
> It's not for users, it's for developers.

But you cannot separate the content of the Packages.gz file according
to whether the viewer is a user or developer. What goes into the
Packages file gets sent to everyone using main, whether they need the
licence data or not.

Now it might be nice to change that so that some users (all developers
are also users so that covers everyone) can have a minimal apt cache
download and Packages.gz file, some may want a maximal cache. However,
that isn't going to happen quickly and adding more fields is not the
way to seek it.

I'd support that because Emdebian could do with a smaller Packages.gz
file - maybe miniPackages.gz alongside Packages.gz. It's relatively easy
- a parser built into the repository tools to strip out certain fields
like Priority, Section, maybe even drop Maintainer and Homepage for
certain embedded devices that won't have a functional 'reportbug' on
the device itself. Then an option for apt (in /etc/apt/apt-conf.d/
IIRC) that uses this file for such devices.

There has been discussion on having translation status in Packages.gz
too - Emdebian has an alternative to that but it may be something that
could be added to max_Packages.gz etc. for those devices where space
and bandwidth are not an issue.

> > If you want this data, write a dedicated wrapper - don't burden
> > everyone else with an extra 20,000 lines in Packages.gz - create a
> > local mirror if necessary.
> 
> I'll do, if necessary.

I'd say it is necessary.

It would go a long way to restarting the whole issue of machine
interpreted copyright info and encouraging other developers to support
it. (I've converted some of my packages but without a visible benefit
of doing so, I'm not exactly rushing to convert the rest.)

> First of all, it's not just that webpage. Go to /tasks/, and you'll see that
> there are others. But the most important thing is that this will probably be a
> feature of cdd-dev; probably in future other CDDs (Debian-Edu, ...) will also
> use that. From this point of view, Debian-Med is kind of a "prototype" for
> cdd-dev.

I still can't see why the licence is relevant to such a website /
interface / task list. The package is in main - that's all you need to
know until you need to copy code from that package into your own.
Redistributing anything in main is explicitly allowed without any need
for any other information.

> I repeat, if it's needed, I'll write a parser for this. I just wanted to have
> the chance not to write a huge script that does the job.

Instead you want to add data to everyone's apt cache - that isn't a
good deal for everyone else. A parser is the sane solution.

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgpKCYwDAN5Fx.pgp
Description: PGP signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Russ Allbery]

Julian Mehnle <[EMAIL PROTECTED]> writes:
> Kalle Kivimaa wrote:

>> in my opinion the new [qmail] license is DFSG-free.
>
> There ain't no new license.  DJB simply retracted his copyright.  As of 
> now, anyone can copy the qmail 1.03 code, make modifications at will, 
> claim copyright for those modifications, and distribute the whole under 
> any license they wish (or none at all, contributing their modifications 
> to the public domain as well).

There's a thereotical open question as to whether you can do that in
Europe (I think that was the jurisdiction with additional moral rights for
authors), but I think we can take a statement that the source is public
domain as a license to do all of those things even in jurisdictions where
releasing copyrighted work into the public domain isn't strictly possible.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Russ Allbery]

Kalle Kivimaa <[EMAIL PROTECTED]> writes:
> Turbo Fredriksson <[EMAIL PROTECTED]> writes:

>> reject at SMTP etc (and claims that this makes Qmail wide open for
>> spams is rubish - it's only if/when configured incorrectly that this
>> becomes a problem)

qmail-smtpd in djb's stock distribution with no patches is not capable of
being configured to prevent reflected spam.  I'll take various people's
word that the patch sets fix this.

> How can you configure the QMail to send error messages only to
> non-forged sender addresses? I don't see any way of differentiating
> these, so the only way to do it is during the SMTP session.

You verify the sender address during the SMTP session and don't accept the
mail if it's not for a valid local address.  This requires keeping some
sort of database or other information that qmail-smtpd can query to use to
reject unknown addresses immediately.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New field in binary stanza

[Russ Allbery]

David Paleino <[EMAIL PROTECTED]> writes:

> would it be possible to have a "License" field in the information of a
> package?  I mean, "apt-cache show foo" shows the fields defined in
> debian/control and some others. Would it be possible to parse the
> license from debian/copyright and add it to that info? Or, at least,
> give the chance to developers to use something like XS-License: in the
> source stanza of debian/control?

You cannot reduce the licensing status of a package to a small number of
keywords in many cases.  It's really only possible for packages covered by
the "big licenses" like the GPL.  Even with relatively standardized
licenses like MIT or BSD, there are slight variations in wording between
different packages.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent

[Joey Hess]

Miros/law Baran wrote:
> Ah, but it's been there, once. I remember that my first Debian
> installation included in the default setup all the accounts used by
> qmail (if not the qmail itself).

That's becaused qmail needs/needed hardcoded uids, so we created them.
Later this changed to reserving the uid space without registering the
groups by default.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#457318: ITP: qmail -- a secure, reliable, ...

[Ron Johnson]

On Monday December 24 2007 12:34:07 Marco d'Itri wrote:
> On Dec 24, Turbo Fredriksson <[EMAIL PROTECTED]> wrote:
[snip]
>
> > I have Postfix crash more often on my home machine (~ 10
> > mails / 24h - using an smarthost) than Qmail do on my main
> > mailservers (~ 10k mails / 24h).
>
> Maybe the problem is not postfix or qmail, it's you.

Agreed.  For 3+ years I've been using Postfix (always keeping it 
relatively current with Sid) at home, in smarthost mode, and it's 
never crashed on me.

-- 
-
Ron Johnson, Jr.
Jefferson, LA  USA

"For me and windows it became a matter of easy to start with, and
becoming increasingly difficult to be productive as time went on,
and if something went wrong very difficult to fix, compared to
linux's large over head setting up and learning the system with
ease of use and the increase in productivity becoming larger the
longer I use the system."
Rohan Nicholls , The Netherlands


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

machine readable copyright file (was: New field in binary stanza)

[Nico Golde]

* Neil Williams <[EMAIL PROTECTED]> [2007-12-24 22:03]:
> On Mon, 24 Dec 2007 16:51:13 +0100
> David Paleino <[EMAIL PROTECTED]> wrote:
> 
> > would it be possible to have a "License" field in the information of a 
> > package?
> 
> Why? What is the benefit?
> 
> A machine-interpretable format for debian/copyright is already
> available.

Where?
Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpLoXOhQCFx6.pgp
Description: PGP signature

The policy process and user categories

[Manoj Srivastava]

Hi,

This is going to be a long email.  I am contemplating the
 holiday festivities, and am getting into the zen mode for making
 traditional egg nog.  Where I live, traditional egg nog means
 contemplating very old Kentucky straight bourbon whiskey, and single
 cask Jamaican white rum,  amongst other things.  Making good egg nog
 makes one inclined t wax long and lyrical.

You have been warned.

Oh, and please send responses to the debian-policy mailing list.

The genesis of this current development is in the discussion (if
 I may call it that) that emerged around the un-delegation and
 re-delegation of the policy team, which means circa October '06.

In the mail of:
  http://lists.debian.org/debian-vote/2006/10/msg00397.html
 I spell out some of the bits missing from the old policy change
 process; for example, soliciting and paying special heed to domain
 expert advice, leading and abridging discussion on policy changes, etc.

In
  http://lists.debian.org/debian-vote/2006/10/msg00402.html
 I talk about the goals of the policy change process, and the initial
 draft of what the new process would look like.

Last DebConf, I gave a talk titled: "The Policy and RC bug
 goulash", which can be found at
  
http://people.debian.org/~srivasta/talks/policy_change_process/policy_and_rc_bugs.pdf.
 The talk deals with two things: the policy rewrite, and the changes to
 the policy process itself.  I have already broached the re-write in
 another thread, here is my proposal to move to the new policy process,
 and to further open up the policy change process.

So, to recap, here are the goals for the policy change process:

GOALS
  * The change should be technically correct, and consistent with the
rest of the policy document. This means no legislating the value of
$\Pi$. This also means that the proposed solution be known to work;
iterative design processes do not belong in policy.
  * The change should not be too disruptive; if very many packages
become instantly buggy, then instead there should be a transition
plan.  Exceptions should be rare (only if the current state is
really untenable), and probably blessed by the TC.
  * The change has to be reviewed in depth, in the open, where any one
may contribute; a publicly accessible, archived, open mailing list.
  * Proposal should be addressed in a timely fashion.
  * Any domain experts should be consulted, since not every
policy mailing list subscriber is an expert on everything,
including policy maintainers.
  * The goal is rough consensus on the change, which should not be hard
if the matter is technical. Technical issues where there is no
agreement should be referred to the TC; non-technical issues should
be referred to the whole developer body, and perhaps general
resolutions lie down that path.
  * Package maintainers whose packages may be impacted should have
access to policy change proposals, even if they do not subscribe to
policy mailing lists (policy gazette?).


Here is the policy change process as a state machine:
SATE DIAGRAM
* State A: Issue raised.  Detect need, like gaps/flaws in
  current policy, or a new rule should be added. Any user or
  developer may start this step. There is a decision point here,
  not all issues are in scope of policy. [TAG: issue]
* State B:Discussion Discuss remedy. Alternate proposals. Discussion
  guided by delegates. There should be a clear time limit to this
  stage.[TAG: discussion]
* State C:Solicit advice [Optional] Solicit domain expert input
   [TAG: opinion]
* State D:Proposal.  A final proposal has emerged from the
  discussion, and there is a rough consensus on how to proceed to
  resolve the issue.  [TAG: proposal] 
* State E:Wording proposed Close to a working solution. Create
  policy language, rationale, test, and publish.  [TAG: wording]
* State F:Seconded The proposal is signed off on by N developers,
  N=3? (stages D and E may be reversed) Final discussions start;
  input from affected developers. [TAG: seconded]
* State G:Accepted Change accepted, will be in next upload.
  [TAG: accepted]
* State H:Reject Rejected proposals.  [TAG: rejected]
  These can be one of:
   H1:dubious   Not a policy matter  [TAG: dubious]
   H2:Ctte  Referred to TC   [TAG: ctte]
   H3:Devel Referred to developer body   [TAG: devel]
   H4:Delegate  Rejected by delegates[TAG: delegate]
(sent by default to TC)
   H4:Timeout   Timed out, no policy created.[TAG: obsolete]

 

Re: Making contributing to Debian easier ; "gift" bug tag

[Nico Golde]

Hi Lucas,
* Lucas Nussbaum <[EMAIL PROTECTED]> [2007-12-24 22:03]:
> I've been thinking about ways to make contributing to Debian easier. I
> sometimes run into the situation where someone asks me "I'd like to
> contribute to Debian, what could I do?", and I have problems directing
> him to things where he could actually help.

There is http://www.debian.org/intro/help but its really not 
that helpful I think.

[...] 
> == "gift" usertag ==
> Some projects (Gnome, KDE) use a special tag to indicate bugs that
> are suitable for new contributors (see [1]). Debian could use something
> similar. I thought of using the "gift" tag for this, but don't hesitate
> to propose something better. We can start with a usertag, and, if it
> gets widely used, ask for a "normal" tag.

I agree this would be a really cool thing but it can be 
really hard to judge what is suitable for new contributors 
and what not, some people understand things pretty fast 
others do not and thus you could lose the chance to get a fix for a bug 
because you rate it too low.

What do you think about using the RFH pseudo bug and add a 
usertag to it instead?

[...] 
> Thank you, and merry christmas :-)

Same to you and all other devs!
Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpGxRYqN7uEJ.pgp
Description: PGP signature

Re: machine readable copyright file (was: New field in binary stanza)

[Neil Williams]

On Mon, 24 Dec 2007 22:27:53 +0100
Nico Golde <[EMAIL PROTECTED]> wrote:

> * Neil Williams <[EMAIL PROTECTED]> [2007-12-24 22:03]:
> > A machine-interpretable format for debian/copyright is already
> > available.
> 
> Where?

http://wiki.debian.org/Proposals/CopyrightFormat

-- 

Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


pgplZthz2iLkQ.pgp
Description: PGP signature

Re: machine readable copyright file (was: New field in binary stanza)

[Nico Golde]

Hi Neil,
* Neil Williams <[EMAIL PROTECTED]> [2007-12-24 22:52]:
> On Mon, 24 Dec 2007 22:27:53 +0100
> Nico Golde <[EMAIL PROTECTED]> wrote:
> > * Neil Williams <[EMAIL PROTECTED]> [2007-12-24 22:03]:
> > > A machine-interpretable format for debian/copyright is already
> > > available.
> > 
> > Where?
> 
> http://wiki.debian.org/Proposals/CopyrightFormat

Thanks I thought there is actually one already in use :)
Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpNOxs4nIe59.pgp
Description: PGP signature