On Sat, 21 Mar 2009, Christian Perrier wrote:
Please note that debian-l10n-english suggests using the enumeration
style you mention for a2ps, when we're reviewing package
descriptions...
BTW, once you answered in this thread: Shouldn't we make the suggested
enhancements part of the Smith-Proje
On Sun, 22 Mar 2009, Michael Bramer wrote:
if we like to remove the long description from the package file, we must
change apt in some way and use some other rules for select the right
description (a new 'Description-md5sum' or the Version-Nr)
I'd call the Version-Nr. a sinsible choice. ;-)
Noah Slater writes:
> I don't understand the disconnect here.
>
> A license check must, by definition, involve each file in the package.
>
> As re-quoted from the quote you previously quoted:
>
> "I don't see why it should be considered that much extra effort
> documenting the process."
Give
Noah Slater writes:
> On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote:
>> NEW rejections are even stronger than an RC bug. Apart from questions
>> of whether that's useful documentation for users, I have a hard time
>> seeing either of your reasons stated above as being RC-level bug
On Sun, Mar 22, 2009 at 04:31:58AM +0100, Josselin Mouette wrote:
> Le dimanche 22 mars 2009 à 02:58 +, Noah Slater a écrit :
> > Again, while the documentation of individual licenses may not be policy, it
> > is
> > certainly policy for each package to be thoroughly checked for licensing
> >
On Sat, Mar 21, 2009 at 08:09:56PM -0700, Russ Allbery wrote:
> > The legal details of copyright assignment are not important here. If the
> > package lists the copyright as belonging to the FSF, then it belongs to
> > the FSF. If it does not, then it does not.
>
> I don't mean to be excessively bl
On Sat, Mar 21, 2009 at 08:07:23PM -0700, Russ Allbery wrote:
> NEW rejections are even stronger than an RC bug. Apart from questions of
> whether that's useful documentation for users, I have a hard time seeing
> either of your reasons stated above as being RC-level bugs.
You don't think that po
Le dimanche 22 mars 2009 à 02:58 +, Noah Slater a écrit :
> Again, while the documentation of individual licenses may not be policy, it is
> certainly policy for each package to be thoroughly checked for licensing
> issues.
> As this necessarily involves looking at each file, I don't see why i
Noah Slater writes:
> On Sat, Mar 21, 2009 at 11:09:36PM +0100, Florian Weimer wrote:
>> This still doesn't tell us if the assignment is effective.
>> (To clarify, I haven't seen the FSF records, but I've spoken to several
>> GNU contributors in potential work-for-hire scenarios and have been
>>
Noah Slater writes:
> On Sat, Mar 21, 2009 at 12:15:00PM -0700, Russ Allbery wrote:
>> Is the reason that you feel most licenses require preservation of the
>> copyright notice and it's easier to enforce it uniformly for all
>> copyright files? Is there some other larger reason why is this
>> im
On Sat, Mar 21, 2009 at 11:09:36PM +0100, Florian Weimer wrote:
> * Tim Retout:
>
> > If you do want to check who has assigned copyright to what, ask a GNU
> > maintainer who has access to the records on fencepost.gnu.org.
>
> This still doesn't tell us if the assignment is effective.
>
> (To clari
On Sat, Mar 21, 2009 at 04:24:55PM +0100, Josselin Mouette wrote:
> When you spend more time on administrative stuff that no one will ever
> care about than on actual packaging stuff, something is very wrong. As I
> have already explained, I won’t spend any more time doing that. If you
> feel like
On Sat, Mar 21, 2009 at 12:15:00PM -0700, Russ Allbery wrote:
> Is the reason that you feel most licenses require preservation of the
> copyright notice and it's easier to enforce it uniformly for all copyright
> files? Is there some other larger reason why is this important for the
> project? (P
On Sat, Mar 21, 2009 at 09:42:35AM -0500, Manoj Srivastava wrote:
> Why do they have to? I know, the ftp team made it up. But there
> is no reason in policy or in copyright law for such copying to
> occur. But it would be nice to know why it is needed.
I can think of a few desirable reas
On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote:
> Honestly, if you cant deal with listing the Authors/(C) holders - dont
> maintain a package. It is not much work to list them. (It might be a lot
> of work using the "new" format, but noone *requires* this format, especially
> not ftp
On Sat, 21, Mar, 2009 at 03:47:57PM +0100, Joerg Jaspert spoke thus..
> - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ ] Choice 1: Enhance seconders to 2Q [3:1]
> [ ] Choice 2: Enhance seconders to Q [3:1]
> [ ] Choice 3: Further Discussion
> - - - -=-=-=-=-=
Joerg Jaspert writes:
> We require, and have seen nothing to convince us otherwise, that Debian
> maintainers need to do the basic work of listing each copyright holder in
> debian/copyright, as seen in the source files and AUTHORS list or
> equivalent (if any).
Is this requirement being applied
Neil Williams wrote:
On Fri, 20 Mar 2009 19:15:00 -0400
Filipus Klutiero wrote:
[...]
> > What about a way of having a really long, detailed, nicely formatted
> > description on packages.debian.org but a much shorter, more basic
> > version in the Packages.gz file?
> >
> The extended descri
On Mar 21, Wouter Verhelst wrote:
> While 1.6% is indeed a rather small amount, I wouldn't call 1340 people
> 'trivial'.
I do, since I expect that most of these are using sarge or worse.
> That would be a good argument if you were to explain how, exactly, it
> would make other packages more comp
Paul Wise schrieb:
On Sat, Mar 21, 2009 at 4:58 PM, Neil Williams wrote:
It's another instance of duplication - why retain the long description
in the Packages file while a translated version also exists from DDTP?
Probably better for the description to be removed from the Packages
file comp
On Sun, Mar 22, 2009 at 12:13:37AM +0100, Petter Reinholdtsen wrote:
> I know some package maintainers handle this by ignoring the existence
> of file-rc and just removing symlinks directly in /etc/rcX.d/. As
> long as file-rc exist and is supposed in Debian, I believe it is a bad
> idea. :(
It s
[Jan Wagner]
> while thinking about how to solve #508189, where I need to change
> the position of the initscript in bootorder, I thought it would not
> sufficient to change only the call of dh_installinit in the rules
> file.
This is the kind of issues the dependency based boot sequencing is
men
Quoting Andreas Tille (til...@rki.de):
> Package: a2ps
> - various encodings (all the Latins and others),
> - various fonts (automatic font down loading),
> - various medias,
> ^^ (two spaces)
>
> Package: acerhk-source
>* controlling LEDs (Mail, Wireless)
>* enable/disable wireless
On Sat, Mar 21, 2009 at 10:53:55PM +0100, Florian Weimer wrote:
> * Bernd Zeimetz:
> > Being able to rename an interface without messing with udev is a
> > feature, not a bug.
>
> I think you can't rename most interfaces after the boot process
> anyway. Or has the kernel been changed and can rena
On Fri, Mar 20, 2009 at 10:53:19AM +0100, Marco d'Itri wrote:
> On Mar 20, Wouter Verhelst wrote:
>
> > It is still possible to install and run Lenny without the use of udev,
> > and many people do so.
> popcon shows that the number is trivial. Definitely not "many".
popcon tells me that there a
* Tim Retout:
> If you do want to check who has assigned copyright to what, ask a GNU
> maintainer who has access to the records on fencepost.gnu.org.
This still doesn't tell us if the assignment is effective.
(To clarify, I haven't seen the FSF records, but I've spoken to
several GNU contributo
On Sat, 2009-03-21 at 20:58 +0100, Florian Weimer wrote:
> And take a typical GNU project: You don't know who has effectively
> assigned copyright to the FSF, so you can't reasonably claim that the
> FSF is the sole copyright holder--and listing authors from the
> changelog is equally wrong.
When
On Sat, Mar 21, 2009 at 03:04:32PM +0100, Joerg Jaspert wrote:
> Even the GPL tells you to. § 4. Conveying Verbatim Copies (which is then
> mentioned in the source/binary paragraphs):
> --88---
> You may convey verbatim copies of the Progr
On Fri, 20 Mar 2009, Filipus Klutiero wrote:
> 2. Does not break any existing tool
I tend to agree with Martin. Do you have a particular reason making this
change urge?
Just to give the suggestion a small chance. I'm not against a "better"
format but I have read enough suggestions tha
* Bernd Zeimetz:
>> Kill it ASAP, it's not compatible with udev.
>
> Being able to rename an interface without messing with udev is a
> feature, not a bug.
I think you can't rename most interfaces after the boot process
anyway. Or has the kernel been changed and can rename interfaces
which are i
On Fri, 20 Mar 2009, Neil Williams wrote:
My comment for this RFC is, therefore, that better formatting for long
descriptions should include a review of whether the long description
deserves to be that long in the first place, whether the long
description merely duplicates data already available
On Fri, 20 Mar 2009, Neil Williams wrote:
Packages.gz is already 26Mb - I'd like to find ways to shorten the
package descriptions, not lengthen it. :-(
Please read again. Chances are good that packages files might
become shorter.
The rationale behind this is that with some
better standard f
On Sat, 21 Mar 2009, Grammostola Rosea wrote:
Speaking for the pkg-multimedia-maintainers, i.e. the actual Debian
Multimedia Team, we don't see ourself as a Debian Blend. We are just a
bunch of maintainers maintaining a bunch of packages *in* Debian:
Right, and that is what blends are about -
On Fri, 20 Mar 2009, Daniel Dickinson wrote:
http://alioth.debian.org/projects/debian-blends
This link reports 'Invalid Project'
Sorry - it's
http://alioth.debian.org/projects/blends
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.or
On Sat, Mar 21, 2009 at 02:57:34PM +0100, Thomas Viehmann wrote:
> Allow me to disagree. While in common language "original" can be used in
> the sense of "initial" as your interpretation seems to suggest, this is
> clearly and consistently not the case in the context of copyright. In
> fact, "orig
* Joerg Jaspert:
> Honestly, if you cant deal with listing the Authors/(C) holders - dont
> maintain a package. It is not much work to list them.
It is, if upstream doesn't provide such a list. And it is my firm
belief that if upstream fails to maintain an accurate copyright record
and releases
Jonas Meurer writes:
> On 21/03/2009 Mike Hommey wrote:
>> On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote:
>>> Honestly, if you cant deal with listing the Authors/(C) holders - dont
>>> maintain a package. It is not much work to list them. (It might be a
>>> lot of work using the "
On 21/03/2009 Mike Hommey wrote:
> On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote:
> >
> > >> No. It is not up to the Debian maintainer to decide that some
> > >> contributor has written enough of the code to also be mentioned in the
> > >> (C) lines in a particular file. But as soo
Romain Beauxis wrote:
> Le Friday 20 March 2009 19:55:29 Emilio Pozuelo Monfort, vous avez écrit :
>>> Since the vast majority of the packages fall into a regular copyright and
>>> licensing, this would also mean overload the policy with stuff that is
>>> only relevant in a very small number of cas
Joerg Jaspert writes:
> We require, and have seen nothing to convince us otherwise, that Debian
> maintainers need to do the basic work of listing each copyright holder
> in debian/copyright, as seen in the source files and AUTHORS list or
> equivalent (if any).
So, the question being raised on
Hi,
On Samstag, 21. März 2009, Manoj Srivastava wrote:
> Err, isn't munin a hugely complex beasty, that has to be
> configured for the network, and usually lives on a signle machine and
> polls others? and does alerting and graphing and is a pain to
> configure?
actually you just do
On Samstag, 21. März 2009, Sandro Tosi wrote:
> Sadly, we are all losing here.
yes. *sigh*
> /me still has to understand what's the point in shooting on
> ourselves... we are losing!
I think it's following binary logic to the end. Which we got trained by using
computers but what is very wrong
Hi Patrik and all,
> In <20090321105249.ga6...@albino.fimpnet>
> Patrik Fimml wrote:
> the abiword package, maintained by mhatta and joshk, could
> definitely use some more care. The version that is in Debian was
> released back in Nov 2006 [1], and it currently includes a grave bug
>
On Sun, Mar 22, 2009 at 02:27:51AM +0900, Masayuki Hatta wrote:
> > Patrik Fimml wrote:
>
> > the abiword package, maintained by mhatta and joshk, could
> > definitely use some more care. The version that is in Debian was
> > released back in Nov 2006 [1], and it currently includes a grave bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 21, 2009 at 18:42, Mike Hommey wrote:
> On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote:
>>
>> >> No. It is not up to the Debian maintainer to decide that some
>> >> contributor has written enough of the code to also be menti
On Sat, Mar 21, 2009 at 03:58:34PM +0100, Joerg Jaspert wrote:
>
> >> No. It is not up to the Debian maintainer to decide that some
> >> contributor has written enough of the code to also be mentioned in the
> >> (C) lines in a particular file. But as soon as upstream lists them
> >> either in a f
Le Saturday 21 March 2009 15:42:35 Manoj Srivastava, vous avez écrit :
> Now, it might be perfectly fine for the ftp team to impose such
> restrictions on packages, and create their own policy; but please at
> least say so, and do not hide being hand waving of either copyright law
> requ
Le samedi 21 mars 2009 à 15:58 +0100, Joerg Jaspert a écrit :
> Honestly, if you cant deal with listing the Authors/(C) holders - dont
> maintain a package. It is not much work to list them.
Bullshit. The last time FTP masters REJECTed a package because of that,
I spent more than an hour to get t
Manoj Srivastava wrote:
> On Sat, Mar 21 2009, Holger Levsen wrote:
>
>
>>> netstat
>>> ---
>> munin
>
> Err, isn't munin a hugely complex beasty, that has to be
> configured for the network, and usually lives on a signle machine and
> polls others? and does alerting and graphing a
On Sat, Mar 21, 2009 at 04:25:36PM +0200, Lars Wirzenius wrote:
> la, 2009-03-21 kello 15:04 +0100, Joerg Jaspert kirjoitti:
> > We require, and have seen nothing to convince us otherwise, that
> > Debian
> > maintainers need to do the basic work of listing each copyright holder in
> > debian/copyr
Michael Hanke wrote:
Hi,
On Fri, Mar 20, 2009 at 04:29:35PM +0100, Fabian Greffrath wrote:
As an additional hint the multimedia team might consider using the Debian Pure
Blends framework which enables them to show quite simply what is just there and
what they are working on (for instance see
On Sat, Mar 21 2009, Holger Levsen wrote:
>> netstat
>> ---
>
> munin
Err, isn't munin a hugely complex beasty, that has to be
configured for the network, and usually lives on a signle machine and
polls others? and does alerting and graphing and is a pain to
configure? On the ot
>> No. It is not up to the Debian maintainer to decide that some
>> contributor has written enough of the code to also be mentioned in the
>> (C) lines in a particular file. But as soon as upstream lists them
>> either in a file header or the AUTHORS file the Debian maintainer has to
>> copy that
On Sat, Mar 21 2009, Joerg Jaspert wrote:
The real problem here is that FTP masters require the list of copyright
holders to be up-to-date each time the package goes through NEW.
Whatever justification exists for this requirement, I???m starting to find
it unacceptable. If a pa
Hi,
I have felt for some time that the low requirement for seconds on General
Resolutions is something that should be fixed. Currently it needs 5
supporters to get any idea laid before every Debian Developer to vote
on. While this small number was a good thing at the time Debian was
smaller, I thi
On Sat, Mar 21 2009, Thomas Viehmann wrote:
> Hi Manoj,
>
> Manoj Srivastava wrote:
>> o) It should name the original authors -- which, in my view, is
>> distinct from every subsequent contributor. This can bea matter of
>> subjective interpretation, though.
>
> Allow me to disagree. W
On Sat, Mar 21 2009, Noah Slater wrote:
> I only maintain a small number of packages, but even then, I have
> regularly found files contained within those packages which were
> included for various reasons by upstream under a different license. In
> the case of planet-venus, I remove a not insign
On Sat, Mar 21 2009, Thomas Viehmann wrote:
> Hi Manoj,
>
> Manoj Srivastava wrote:
>> o) It should name the original authors -- which, in my view, is
>> distinct from every subsequent contributor. This can bea matter of
>> subjective interpretation, though.
>
> Allow me to disagree. W
Le samedi 21 mars 2009 à 15:04 +0100, Joerg Jaspert a écrit :
> No. It is not up to the Debian maintainer to decide that some
> contributor has written enough of the code to also be mentioned in the
> (C) lines in a particular file. But as soon as upstream lists them
> either in a file header or th
la, 2009-03-21 kello 15:04 +0100, Joerg Jaspert kirjoitti:
> We require, and have seen nothing to convince us otherwise, that
> Debian
> maintainers need to do the basic work of listing each copyright holder in
> debian/copyright, as seen in the source files and AUTHORS list or
> equivalent (if any
Hi Jonas,
On Samstag, 21. März 2009, Jonas Smedegaard wrote:
> >plugin. We dont want to suggest asterisk just because there is a plugin
> >to monitor it :)
>
> Why not?
>
> The purpose of "Suggests:" is exactly to declare non-important
> relationship. From Policy 7.2:
True, but IMO it's the other
>>> The real problem here is that FTP masters require the list of copyright
>>> holders to be up-to-date each time the package goes through NEW.
>>> Whatever justification exists for this requirement, I???m starting to find
>>> it unacceptable. If a package has to go through NEW, it takes about
>>
Hi Manoj,
Manoj Srivastava wrote:
> o) It should name the original authors -- which, in my view, is
> distinct from every subsequent contributor. This can bea matter of
> subjective interpretation, though.
Allow me to disagree. While in common language "original" can be used in
the se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Mar 21, 2009 at 02:10:40PM +0100, Holger Levsen wrote:
>munin uses netstat only in the netstat plugin. I've now added a
>suggests (in svn) on the assumption that netstat is a rather common
>plugin. We dont want to suggest asterisk just becaus
Holger Levsen wrote:
> Hi Luk,
Hi Holger
> On Samstag, 21. März 2009, Luk Claes wrote:
Below a list of packages/maintainers that use ifconfig/route/netstat:
>>> How did you create that list? You seem to be missing a few..
>> By looking at dependency relations with the net-tools package. I gu
Hi Luk,
On Samstag, 21. März 2009, Luk Claes wrote:
>>> Below a list of packages/maintainers that use ifconfig/route/netstat:
> > How did you create that list? You seem to be missing a few..
> By looking at dependency relations with the net-tools package. I guess
> some packages use net-tools if a
On Sun, Mar 15, 2009 at 02:30:18PM -0300, Martín Ferrari wrote:
>
> About the wrapper scripts:
> * ipconfig, route: the most difficult ones, both can be replaced by
> calls to "ip", maybe except for some obscure options.
Suggestion about the wrapper scripts. It would be nice if they had a
mode
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Package name: kplayer
Version: 0.7
Upstream Author: kiriuja
URL: http://kplayer.sourceforge.net
License: GPL version 3
Description: multimedia player
kplayer is a frontend for mplayer w
On Fri, Mar 20, 2009 at 11:33:32PM -0500, Manoj Srivastava wrote:
> Now, some of the objections you have heard is because of the
> hard line you have been taking in this discussion about looking for
> and adding copyright holders is not, as far as I can see, reflected in
> current polic
> Holger Levsen wrote:
> > Hi Luk,
> >
> > On Freitag, 20. März 2009, Luk Claes wrote:
> >> Below a list of packages/maintainers that use ifconfig/route/netstat:
> >
> > How did you create that list? You seem to be missing a few..
>
> By looking at dependency relations with the net-tools package
Holger Levsen wrote:
> Hi Luk,
>
> On Freitag, 20. März 2009, Luk Claes wrote:
>> Below a list of packages/maintainers that use ifconfig/route/netstat:
>
> How did you create that list? You seem to be missing a few..
By looking at dependency relations with the net-tools package. I guess
some pac
Hi,
the abiword package, maintained by mhatta and joshk, could definitely
use some more care. The version that is in Debian was released back in
Nov 2006 [1], and it currently includes a grave bug that makes the
package nearly unusable on amd64 [2].
[1] http://www.abisource.com/downloads/abiword/
Hi Luk,
On Freitag, 20. März 2009, Luk Claes wrote:
> Below a list of packages/maintainers that use ifconfig/route/netstat:
How did you create that list? You seem to be missing a few..
> ifconfig + route
>
sitesummary
> netstat
> ---
munin
> ifconfig
>
fai
deb
On Sat, Mar 21, 2009 at 4:58 PM, Neil Williams wrote:
> It's another instance of duplication - why retain the long description
> in the Packages file while a translated version also exists from DDTP?
> Probably better for the description to be removed from the Packages
> file completely and the D
On Sat, 21 Mar 2009 12:28:36 +0900
Paul Wise wrote:
> On Sat, Mar 21, 2009 at 8:15 AM, Filipus Klutiero wrote:
>
> > The extended description needs to be available to APT, not only via
> > packages.d.o.
>
> I agree with Neil William's comment in the other thread about removing
> long descripti
On Fri, 20 Mar 2009 23:32:51 +0100
Michael Banck wrote:
> On Fri, Mar 20, 2009 at 07:20:43PM +, Neil Williams wrote:
> > I'd like to get the longest descriptions out of Packages.gz completely,
> > so encouraging their retention it not ideal. It's not about whether 2
> > or 3 spaces should be
On Fri, 20 Mar 2009 19:15:00 -0400
Filipus Klutiero wrote:
> > On Fri, 20 Mar 2009 14:45:09 +0100 (CET)
> > Andreas Tille wrote:
> >
> > > I tried to find a clear advise how to reasonable format lists inside long
> > > descriptions of packages. The only thing I know is that lines with two
> > >
77 matches
Mail list logo
