Re: RFC: Better formatting for long descriptions

[Andreas Tille]

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-Project?

Kind regards

  Andreas.

--
http://fam-tille.de


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

Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Andreas Tille]

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. ;-)

Kind regards

  Andreas.
--
http://fam-tille.de


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

Re: Sponsorship requirements and copyright files

[Russ Allbery]

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."

Given that many people have already said that it is, perhaps this is the
point where you should just accept that they're not lying to you and
instead you're suffering from a failure of imagination?

I know from personal experience (having done this as an experiment for
several packages of mine, including some fairly large ones) that it is
indeed quite a bit of extra effort.  This is for several reasons,
including the simple fact that I read a lot faster than I type.

-- 
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: Sponsorship requirements and copyright files

[Russ Allbery]

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 bugs.

> You don't think that possible DFSG problems are RC bugs? :/

You gave two reasons:

 * [...] it serves as documentation that the package has been thoroughly
   checked for licensing issues.

 * It also provides a nice summary for our users.

Could you explain to me how the lack of those two things is a possible
DFSG problem?  I assume that this is based on the first, but that seems
like quite a stretch to me.  The same assurance, for what good there is in
it, could be drived from a statement in debian/copyright saying "I checked
every file in this package for DFSG licensing problems."

Also, no, I definitely do not think that a possible DFSG problem is an RC
bug.  I think that an *actual* DFSG problem is an RC bug.  A possible DFSG
problem is only a possible RC bug.  Surely this is obvious?

-- 
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: Sponsorship requirements and copyright files

[Noah Slater]

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 
> > issues.
> > As this necessarily involves looking at each file, I don't see why it 
> > should be
> > considered that much extra effort documenting the process.
> >
> > Ensuring DFSG compatibility is hardly administrative fluff.
>
> Please read what people write, otherwise it’s getting pretty insulting.
>
> No one here is questioning the importance and the usefulness of the
> licensing check.

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."

Best,

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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 blunt, but I'm afraid that this simply
> isn't legally true.

For our purposes it is more than sufficient.

If a package lists a person as the copyright holder, we should accept it.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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 possible DFSG problems are RC bugs? :/

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Josselin Mouette]

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 it should 
> be
> considered that much extra effort documenting the process.
> 
> Ensuring DFSG compatibility is hardly administrative fluff.

Please read what people write, otherwise it’s getting pretty insulting.

No one here is questioning the importance and the usefulness of the
licensing check.

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


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

Re: Sponsorship requirements and copyright files

[Russ Allbery]

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
>> told how the assignment process had been handled within their
>> organizations.)

> It is largely unimportant.

> 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 blunt, but I'm afraid that this simply
isn't legally true.

> This is coming from a GNU maintainer who has been through the process.

They apparently gave you incorrect information then.

-- 
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: Sponsorship requirements and copyright files

[Russ Allbery]

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
>> important for the project?  (Please note that I'm not assuming that you
>> have no reason.  I just don't understand, from the discussion so far,
>> what it is.  We can't really have a meaningful discussion until we're
>> all on the same page)
>
> Like I have said a few times previously, it serves as documentation that
> the package has been thoroughly checked for licensing issues. Because
> such a check must involve looking at the headers of each file, and any
> AUTHORS or similar file, there appears to be no reason why this should
> not be written down.
>
> It also provides a nice summary for our users.

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.

Also, I *truly* don't want to shut you down here, but I would specifically
like to know why ftpmaster wants this information.  We're discussing a
policy set by ftpmaster for specific reasons.  In that context, the views
of people who are not on the ftpmaster team or who weren't involved in
setting that policy, while important, don't help us understand what the
reasons were for the original policy.

-- 
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: Sponsorship requirements and copyright files

[Noah Slater]

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 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 told how the assignment process had been handled within their
> organizations.)

It is largely unimportant.

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. This is coming from a GNU maintainer who has been
through the process.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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 REJECTing packages because of that, fine. We’ll surely find
> some NMs to disgust by doing administrative trivia, and in the meantime
> packages will be found on a repository on alioth.

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 it should be
considered that much extra effort documenting the process.

Ensuring DFSG compatibility is hardly administrative fluff.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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?  (Please note that I'm not assuming that you have no reason.  I
> just don't understand, from the discussion so far, what it is.  We can't
> really have a meaningful discussion until we're all on the same page)

Like I have said a few times previously, it serves as documentation that the
package has been thoroughly checked for licensing issues. Because such a check
must involve looking at the headers of each file, and any AUTHORS or similar
file, there appears to be no reason why this should not be written down.

It also provides a nice summary for our users.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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 reasons:

  * To show the FTP masters that they have thoroughly checked the licensing.

  * To provide concise information for our users.

> > 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).
>
> Why do you think this work is needed? You must have had some
>  rationale, since you made up this policy.

Again, to document that they have, in fact, done what they are supposed to.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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 ftpmaster. It has *no* gain for us at all, we couldnt care less if
> you use it or not).

I resent the implication in this remark. The copyright proposal is not complex,
not verbose, and does not require any extra information from developers. The
only thing it does is to mandate a machine readable format, in a similar vein as
debian/control, for whatever information you might have already been using.

This has clear advantages for being able to post-process, check, search, and
navigate copyright information using whatever tools the community decides would
be profitable.

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: Proposal: Enhance requirements for General resolutions

[Mark Hymers]

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
> - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> 
> As this will change the constitution it will need a 3:1 to win. (see
> Constitution 4.1.2)
> 
> Of course, this being a proposal to enhance the required seconds, I
> would love if many people do second this, even if we might be past the
> currently needed limit already. The more the better. :)
> 
> PROPOSAL START
> 
> General Resolutions are an important framework within the Debian
> Project. Yet, in a project the size of Debian, the current requirements
> to initiate one are too small.
> 
> Therefore the Debian project resolves that
>  a) The constitution gets changed to not require K developers to sponsor
> a resolution, but floor(2Q). [see §4.2(1)]
>  b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
> as well as resolutions against a shortening of discussion/voting
> period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
> developers to sponsor the resolution.
>  c) the definition of K gets erased from the constitution. [§4.2(7)]
> 
> (Numbers in brackets are references to sections in the constitution).
> 
> PROPOSAL END

Seconded.

Mark

-- 
Mark Hymers 

"Irish police are being handicapped in a search for a stolen van, because
 they cannot issue a description. It's a special branch vehicle, and they
 don't want the public to know what it looks like."
 The Guardian


signature.asc
Description: Digital signature

Re: Sponsorship requirements and copyright files

[Ben Pfaff]

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 uniformly?  I don't see any
such attempt in linux-image-2.6.28-1-686, to pick one example at
random, even though the Linux kernel comes with a very long list
of subsystem maintainers who are presumably authors or copyright
holders.
-- 
Ben Pfaff 
http://benpfaff.org


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

Re: Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Filipus Klutiero]

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 description needs to be available to APT


Only for use by apt-search, the rest of apt doesn't care about it. apt
understands debtags, why duplicate that information? (Frontends can be
adapted or just rely on apt-cache search underneath.)
  
I don't understand what you mean. Where would apt-cache get the extended 
description from? Again, debtags is not mature enough yet to shrink 
descriptions.
>, not only via 
> packages.d.o. I seem to remember that Mandrake Linux (or some other 
> RPM-based distribution) used two Packages-like files, a fat one about 5 
> times our Packages and a slim one about a fifth of Debian's Packages. I 
> remember finding the slim index cool, but now that there's 
> Packages.diff, I think that developing Mandrake-like Packages files and 
> seeing the results in, perhaps, 2 years, would not benefit much to the 
> kind of hardware Debian will run on by then.


Debian is not exclusively for power-hungry servers and mega-powerful
workstations, Debian also runs on very small hardware and not
necessarily old stuff either. It is a mistake to think that Debian
should require more and more powerful hardware for the basic system.
  
Actually, I was only saying that I thought such a reduction of the 
hardware requirements would not help much.

Yes, there is software in Debian that needs a powerful machine, there
is also a LOT of software in Debian specifically designed for low
resource machines where the benefits of a <1Mb Packages.gz file are
appreciable.
I agree, after reading Paul's comment, that if we get a Translations-en 
file via DDTP, removing the extended description from Packages would be 
less work, and thus more interesting.


I tested the gain with
awk '$0 !~ /^(Description| )/'
and the result loses close to half of its compressed size.
-rw-r--r-- 1 chealer chealer  4224356 mar 21 20:12 nodesc.tar.gz
-rw-r--r-- 1 chealer chealer  7350583 mar 21 15:56 
debian.savoirfairelinux.net_debian_dists_testing_main_binary-i386_Packages.tar.gz



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

Re: net-tools future

[Marco d'Itri]

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 complex.
> Can you give an example, please?
The second-last alsa-base release is a good example.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Michael Bramer]

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 completely and the DDTP one contains the translated version and
English ones for those with missing or outdated translations. That way,
apt spends less time parsing the (smaller) Packages file when doing
ordinary stuff like package installation and only needs to look at the
DDTP information when specifically called as 'apt-cache search'.


One issue is that many people will have disabled downloading
translations so they'll need to change their configuration from none
to en:

APT::Acquire::Translation "none";

Since en will now be a "Translation", perhaps a different config item
is more appropriate:

APT::Acquire::Description "en";


This will not work:

apt use a md5sum from the sort and lang description (from the packages 
file) to find the right 'translation'. If you remove the long 
description from the packages file, apt can't do this task...


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)


Gruss
Grisu


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

Re: Transition of initscripts to new order / sequence number

[Steve Langasek]

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 seems to me that it would be a lot less effort to fix this by removing
file-rc in Debian, which has only a handful (137) of popcon reports.  Even
if we take into consideration that popcon isn't a good source of absolute
numbers, this comes out to .2% of popcon reports that we're spending this
effort on, and for what benefit?

-- 
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: Transition of initscripts to new order / sequence number

[Petter Reinholdtsen]

[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
ment to solve.  It generate the boot ordering based on dependencies
specified in each init.d script.  See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> for
more info on this effort.

> If an user changed the symlinks, I guess I will break his
> changes. How should we handle this? Is there any best practise
> and/or policy how we should deal with it? I think it's not usefull
> just to override the changes by the local sysadmin.

At the moment, the only option that work with both sysv-rc and file-rc
is to remove all symlinks and reinstall them.  This is not a very good
option, but given the limitation of the update-rc.d API, it is the
only one that work.

Kel Modderman has been working on extending the update-rc.d API to
allow for more fine grained adjustment of init.d symlinks, and I hope
it will be available for the next stable release.  Until then, no good
and portable option exist.  Please see the posts linked from
http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2008-September/thread.html>
for more information about the proposed API.

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. :(

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: RFC: Better formatting for long descriptions

[Christian Perrier]

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 hardware
> ^^^ (three spaces)


.../...

Please note that debian-l10n-english suggests using the enumeration
style you mention for a2ps, when we're reviewing package
descriptions...

Of course, that triggers rewrites but these are generally coupled with
much more very good improvement suggestions (the team features an
artist of the English language and that's not /mewhich is obvious
for everybody).




signature.asc
Description: Digital signature

Re: net-tools future

[Wouter Verhelst]

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 rename interfaces
> which are in use?

How on earth does 'network interface is in use' correlate to 'the system
is booting'?

ip link set  down
ip addr flush dev 


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


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

Re: net-tools future

[Wouter Verhelst]

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 are 82953 people who have udev installed, and
that this is 98.41% of the total amount of people who do popcon
submission.

82953*100/98.41 = 84293

This means that of those who have popcon running, there are 1340 people
who do not use udev.

While 1.6% is indeed a rather small amount, I wouldn't call 1340 people
'trivial'.

Moreover, while popcon is useful to order packages so that we can decide
which package goes on which CD, I would be _very_ wary of using it to
justify throwing software out of the archive. To be representative,
statistical data has to be drawn from a *random* subgroup of people.
This does not happen with popcon; as such, it is not entirely reliable.

> > Whether you agree that this is useful or a 'toy'
> > setup is beside the point; fact is that it happens, and if people want
> > to work on this so that it remains being supported, why not?
> Because it makes other packages more complex.

That would be a good argument if you were to explain how, exactly, it
would make other packages more complex.

Can you give an example, please?

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


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

Re: Sponsorship requirements and copyright files

[Florian Weimer]

* 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 contributors in potential work-for-hire scenarios and have
been told how the assignment process had been handled within their
organizations.)


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

Re: Sponsorship requirements and copyright files

[Tim Retout]

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 copyright is assigned to the FSF, the upstream maintainer generally
changes the copyright statements in the headers of the files:
http://www.gnu.org/prep/maintain/maintain.html#Copyright-Notices

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.

Regards,

-- 
Tim Retout 


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

Re: Sponsorship requirements and copyright files

[Steve Langasek]

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 Program's source code as you
> receive it, in any medium, provided that you conspicuously and
> appropriately publish on each copy an appropriate copyright notice;
> keep intact all notices stating that this License and any
> non-permissive terms added in accord with section 7 apply to the code;
> keep intact all notices of the absence of any warranty; and give all
> recipients a copy of this License along with the Program.
> --88---

This language is specific to v3 of the GPL.  Works licensed under GPLv2
don't have such a provision; the copyright notice is only required with the
source distribution, not the binary distribution.

So s/Event the GPL tells you to/Only the GPLv3 tells you to/.

The GPLv3 certainly makes an interesting case, because §6 says "You may
convey a covered work in object code form under the terms of sections 4 and
5".  It's not at all clear to me what it means to "convey a work in object
code form" under terms that specifically say "You may convey verbatim copies
of the Program's source code" and "You may convey a work based on the
Program, or the modifications to produce it from the Program, in the form of
source code".

I think that's a bug that was overlooked in the GPLv3 drafting process.  It
would probably be worth asking the FSF for a clarification of intent here,
as well as to get legal advice ourselves, because I actually don't see that
the reading you're giving it, "distribute binaries following the same
requirements outlined in §4", is more naturally correct than "distribute
binaries as allowed by §4".  Or, for that matter, more naturally correct
than "distribute binaries only if they're source".

Also, FWIW, §4 says "appropriate copyright notice", but doesn't define what
this means.  Given that there appears to be some disagreement on what this
means, I think Debian should get legal advice about what the standard needs
to be instead of the ftp team going out on a limb by making their own rules.

> 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 information into debian/copyright.

So it's not up to the Debian maintainer, but it is up to the ftp team?
Why?

-- 
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: RFC: Better formatting for long descriptions

[Andreas Tille]

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 that ended in nothing.  BTW,
getting the descriptions in some standard shape might make an automatic
transition to a "better" format easier.

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: net-tools future

[Florian Weimer]

* 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 in use?


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

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

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 via debtags and
whether the long description should be trimmed for the package in
question *as well as* standardising the formatting of what remains.


I agree that some descriptions are definitely to long.  I wonder who
should really read some descriptions to the end.  Bad examples can be
viewn here:

   http://debian-med.alioth.debian.org/tasks/typesetting.html

Kind regards

   Andreas.

--
http://fam-tille.de


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

Re: RFC: Better formatting for long descriptions

[Andreas Tille]

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 formating some tools which display descriptions on web
pages might be enhanced to use ,  and  tags which finally
makes a better reading.


Oh no, please don't let Packages.gz get to 40Mb or 50Mb or more. There
has to be a limit somewhere.


You should definitely read again - in how far removing / adding some spaces
and use defined characters instead of random ones should have such an
effect?

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Please Improve Debian for Multimedia Production

[Andreas Tille]

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 -- maintaining packages *in*
Debian.


I really hope that people will get the right impression what Blends
are and start reading before they make wrong assumptions.

My aim as the thread starter was to ask for developers and/or package 
maintainers for multimedia in Debian. Because there are a lot nice packages 
which are not in Debian now or are pretty outdated. I know the Debian 
Multimedia Team exist, but I think they can use some help here...


Yes, definitely.  And to get some help you need to be visible and give
your project some better structure.  If you want to learn about the
reason for maintaining a Blend instead of beeing a bunch of maintainers
just read the doc [1] (BTW, this helps to avoid wrong asumptions that
packages are not *in* Debian).

Kind regards

Andreas.

[1] http://blends.alioth.debian.org/blends/
--
http://fam-tille.de


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

Re: Bits from the Debian Pure Blends Team

[Andreas Tille]

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

Re: Sponsorship requirements and copyright files

[Steve Langasek]

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, "original author" is a something of a technical term in this
> domain. A definition capturing the common meaning of this term can be
> found e.g. in the CC licenses. In CC 3.0 it starts with
>   "Original Author" means, in the case of a literary or artistic work,
>   the individual, individuals, entity or entities who created the Work
>   ...

The fact that the CC licenses define the term is a pretty clear[1] indicator
that the term does *not* have a universally recognized definition under
copyright law.

> Debian sees increased enforcement of properly documenting copyright
> status because the people who recently joined the FTP team were
> instructed to check for this and pointed to the publicly available
> reject faq and the two announcements on debian-devel-announce that
> explicitly state that copyright notices must be listed and have not been
> met with opposition when they were posted five and again three years ago.

When the Reject FAQ was posted, its author was the ftp assistant tasked with
NEW processing, not an ftpmaster.  There was a clear line of appeal to the
ftpmasters in case of disputes, and I assumed at the time that the Reject
FAQ was documentation of existing practice, not unilateral codification of
new requirements.  I certainly didn't analyze it at the time it was posted
to look for unintended side effects in the event someone started using it as
Scripture to justify blocking DDs' packages from the archive.

Over the past 13 months, there has been 100% turnover of the ftp team with
the exception of that single ftp assistant who is now the senior ftpmaster.
All of a sudden, a FAQ that some of us considered advisory has become a
strictly enforced law, with no route of appeal short of GR or TC.  The
publication of that FAQ was *not* precedent for the kinds of rejects that
are going on now; this is something entirely new, untempered by the
institutional continuity that existed before.

> Properly documenting the copyright license well includes listing the
> licensor and the basis of the license, i.e. including the copyright
> notice.

I agree that this is the proper thing to do.  It is not, however,
appropriate to enforce creating a debian/copyright that documents every
single copyright holder as a condition of NEW processing, if this is not
already a requirement of the license.

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

[1] though not definitive; lawyers, unlike compilers, like shadowing
variables...


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

Re: Sponsorship requirements and copyright files

[Florian Weimer]

* 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 the software und a free software license, we have got
implicit permission to redistribute it without proper attribution to
individual contributors, no matter what the license says.  The same
argument applies to keeping track of changes (which is the most widely
violated GPL requirement, I guess).

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.

If the information is copied into the copyright file manually (I don't
think you're supposed to auto-generated debian/copyright anyway), it
will bit-rot pretty quickly.  Even now, we miss fundamental licensing
changes--for instance, the transition from GPL+BSD to BSD for pcre3.

I think an accurate copyright record is necessary to exercise free
software freedoms, but many upstreams disagree, and we have to cope
with that discrepancy somehow.  Package removal is certainly not the
answer (we shouldn't remove Iceweasel or the kernel).


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

Re: Sponsorship requirements and copyright files

[Russ Allbery]

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 "new" format, but noone *requires* this format,
>>> especially not ftpmaster. It has *no* gain for us at all, we couldnt
>>> care less if you use it or not).

>> You win.

>> I hereby orphan xulrunner and iceape. As for iceweasel and webkit,
>> there is a comaintainer on both, so that's up to them.

> I cannot believe that. Despite deeply appreciating your decision, it
> makes me very sad to see another complex and important package losing
> its competent and valuable maintainer.

> Joerg, please don't you see the consequences of your harsh discussion
> style? I've quite the feeling that with getting more and more important
> within debian you get more and more authoritarian as well.  sorry for
> these straight words. it's not that i wouldn't appreciate your valuable
> work for debian, but please refrain from exploiting the power you got.

Personally, I'm rather annoyed at both of them.  There are people in the
project who are willing to invest time and energy into finding mutually
agreeable solutions and talking through problems, but if people explode as
soon as the discussion gets heated and make drastic decisions before
anyone even has a chance to mediate, what's the point?

The problem doesn't have to be solved yesterday.  We're early in the
squeeze development cycle, nothing is currently happening that can't wait
a little bit, and there's time to talk through it and let initial
positions moderate and people calm down.  Can we PLEASE not escalate every
heated discussion immediately?  If you're really upset about something,
take a few days away from it and think about it for a while.  Write the
heated message, file it somewhere, and decide whether you still want to
send it tomorrow.

For that matter, you're certainly welcome to mail me directly and either
let off steam or ask that a point be represented in public that you're too
steamed to make.  I expect there are others who would volunteer to do the
same.

-- 
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: Sponsorship requirements and copyright files

[Jonas Meurer]

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 soon as upstream lists them
> > >> either in a file header or the AUTHORS file the Debian maintainer has to
> > >> copy that information into debian/copyright.
> > > This is an absolute waste of time.
> > 
> > As your mail is.
> > 
> > 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 ftpmaster. It has *no* gain for us at all, we couldnt care less if
> > you use it or not).
> 
> You win.
> 
> I hereby orphan xulrunner and iceape. As for iceweasel and webkit, there
> is a comaintainer on both, so that's up to them.

I cannot believe that. Despite deeply appreciating your decision, it
makes me very sad to see another complex and important package losing
its competent and valuable maintainer.

Joerg, please don't you see the consequences of your harsh discussion
style? I've quite the feeling that with getting more and more important
within debian you get more and more authoritarian as well.
sorry for these straight words. it's not that i wouldn't appreciate your
valuable work for debian, but please refrain from exploiting the power
you got.

I really start to ask myself whether we do have a social problem with
the debian developers community. people who're important for the project
often tend to authoritarian discussion style. i don't know what and
whether at all they compensate anything with this behaviour, but at
least they don't realize how they hurt the complete project with doing
so.

greetings,
 jonas


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

Re: Revising Policy 12.5 (Copyright information)

[Emilio Pozuelo Monfort]

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 cases in proportion.
>> If copyright holder listing isn't needed at all, there's no special-casing
>> needed for autofoo stuff (wrt copyright listing, not wrt licenses though).
> 
> But this is also problematic for license ! 
> 
> Even in the case in which we accept my above rational, it is still possible 
> that the configure.ac contains custom macros with a bad license...
> 
> Hence, if we were to decide on a general basis, it would be either to check 
> for all configure.ac or for no one.. Do you think one of these possibilities 
> is reasonable ?

I dunno, but that is not the point. The point is about not requiring copyright
holders, which wouldn't need special casing.

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Sponsorship requirements and copyright files

[Russ Allbery]

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 this thread is why?  What purpose does
this work serve?

The argument against doing it is that it takes increased time over just
verifying the licenses of every file and requires ongoing maintenance that
could be spent on tasks more directly related to improving the software.

If the argument in favor is just that Policy says something along those
lines, well, as discussed in this thread, I want to revise that Policy
section anyway.

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?  (Please note that I'm not assuming that you have no reason.  I
just don't understand, from the discussion so far, what it is.  We can't
really have a meaningful discussion until we're all on the same page)

-- 
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: net-tools future

[Holger Levsen]

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 "sudo apt-get install munin munin-node" and point your 
webbrowser to http://127.0.0.1/munin/ and are done for a single host. for 
multiple hosts its editing one file on the node to allow the server to access 
it, and tell the server to do so (by editing another simple file).

Configuring extra plugins is a bit more work, though many services munin can 
monitor are autoconfigured. (And configuring a plugin involves creating a 
link to activate the plugin and then putting some configuration in 
into /etc/munin/plugin-conf.d/ - usually stuff like the disk to monitor by 
the smart plugin or the credentials to access databases or such.)

Really not a big deal.

> Am I missing something, since munin is seen as a replacement for
>  netstat?

You missed what Luk pointed out, but I felt like clarifying the above as 
well :-)


regards,
Holger


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

Re: Sponsorship requirements and copyright files

[Holger Levsen]

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 in social interactions.


regards,
Holger


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

Re: abiword package lacks maintenance

[Masayuki Hatta]

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
> that makes the package nearly unusable on amd64 [2].

> [1] http://www.abisource.com/downloads/abiword/
> [2] http://bugs.debian.org/514525

Well, the current Debian version is 2.6.4 (in stable and unstable),
released in 13-Jul-2008.  Seems Ubuntu Hardy somehow has 2.4.6, which
was released in Nov. 2006 and is definitely a really old version.  I
guess you confused that with Debian.

Anyway, this is merely a nitpicking -- the latest release is 2.6.8 and
the Debian package is not up-to-date anyway.

> According to db.debian.org, both maintainers seem to be on vacation.
> I have been trying to contact them more than a month ago, without
> reply.  Could a DD check whether they are planning to return
> sometime soon?

I was on vacation and am back to Debian only recently, but now
realized I have only sporadic free time now, and in the foreseeable
future.  I appreciate your help very much.

Seems I missed your previous mail; sorry about that.

> As already mentioned, the package is not very up-to-date, which is
> why I'd offer to take it over. As maintainer of the eboard package,
> I already have some experience in packaging and with the BTS.

I'm planning to form a maintenance team for abiword, move debian/ to
Alioth and use SVN or Git extensively.  How do you think?

Best regards,
MH

--
Masayuki Hatta 


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

Re: abiword package lacks maintenance

[Patrik Fimml]

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 bug
> > that makes the package nearly unusable on amd64 [2].
> 
> > [1] http://www.abisource.com/downloads/abiword/
> > [2] http://bugs.debian.org/514525
> 
> Well, the current Debian version is 2.6.4 (in stable and unstable),
> released in 13-Jul-2008.  Seems Ubuntu Hardy somehow has 2.4.6, which
> was released in Nov. 2006 and is definitely a really old version.  I
> guess you confused that with Debian.

Sorry for the wrong accusation. Indeed 2.6.4 and 2.4.6 (and nothing
inbetween) appearing everywhere on the QA page confused me. Sorry!

> > As already mentioned, the package is not very up-to-date, which is
> > why I'd offer to take it over. As maintainer of the eboard package,
> > I already have some experience in packaging and with the BTS.
> 
> I'm planning to form a maintenance team for abiword, move debian/ to
> Alioth and use SVN or Git extensively.  How do you think?

Sounds good to me, I'm hereby offering co-maintainership. Josselin Mouette
pointed out the possibility of using the Debian-GNOME infrastructure [1]
(SVN) earlier—the mail didn't reach the list apparently. Personally,
though, I prefer Git by far.

[1] http://pkg-gnome.alioth.debian.org/

Before migrating to a VCS, one might consider splitting the source
package. It seems a bit awkward to have four separate source tarballs in
one source package, which then builds four separate binary packages
again. Do you agree?

Kind regards,
Patrik


signature.asc
Description: Digital signature

Re: Sponsorship requirements and copyright files

[Sandro Tosi]

-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 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 information into debian/copyright.
>> > This is an absolute waste of time.
>>
>> As your mail is.
>>
>> 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 ftpmaster. It has *no* gain for us at all, we couldnt care less if
>> you use it or not).
>
> You win.
>
> I hereby orphan xulrunner and iceape. As for iceweasel and webkit, there
> is a comaintainer on both, so that's up to them.

Sadly, we are all losing here.

You're a fscking great maintainer, as I was able to experiment with
our interaction on some bugs, and it's a loss for the WHOLE Debian
you're demotivated to maintain those important packages.

Hope in some days/weeks, when the situation will cool a bit, you might
reconsider your decision.

Cheers,
Sandro

/me still has to understand what's the point in shooting on
ourselves... we are losing! every time a maintainer (being a DD or
not) reaches his limit of patience for the sake of nothing.

- --
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.4)

iEYEARECAAYFAknFK8YACgkQAukwV0RN2VD08wCdHNbguc2DdBEPp3RWRomtSOYz
Wf0AnRfRskMVq2cwe4TWDL0PdLJr3z04
=2hwQ
-END PGP SIGNATURE-


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

Re: Sponsorship requirements and copyright files

[Mike Hommey]

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 file header or the AUTHORS file the Debian maintainer has to
> >> copy that information into debian/copyright.
> > This is an absolute waste of time.
> 
> As your mail is.
> 
> 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 ftpmaster. It has *no* gain for us at all, we couldnt care less if
> you use it or not).

You win.

I hereby orphan xulrunner and iceape. As for iceweasel and webkit, there
is a comaintainer on both, so that's up to them.

Mike


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

Re: Sponsorship requirements and copyright files

[Romain Beauxis]

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
>  requiring it (it does not) or Debian policy saying so (which it does
>  not either).

If it is not required by a law such policy should be decided by the 
developpers as a whole and not only ftpmasters through the policy indeed.

Even though, it is questionable when the legal requirements are only for a 
specific legislation.


Romain


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

Re: Sponsorship requirements and copyright files

[Josselin Mouette]

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 the list right, for a package that took
only a few minutes to update. I can hardly imagine how fun it must be
for a big package.

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 REJECTing packages because of that, fine. We’ll surely find
some NMs to disgust by doing administrative trivia, and in the meantime
packages will be found on a repository on alioth.

Furthermore, I noticed a few times some wrong *license* statements that
passed through NEW and that I fixed later. I just wish you spent less
time nitpicking on copyright holders if you don’t have the time to check
things that actually matter.

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


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

Re: net-tools future

[Luk Claes]

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 and is a pain to
>  configure?  On the  other hand, netstat -r, netstat -i, netstat -al
>  just work?
> 
> Am I missing something, since munin is seen as a replacement for
>  netstat?

This lists are not replacements for tools from net-tools, but lists of
packages using tools from net-tools.

Cheers

Luk


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

Re: Sponsorship requirements and copyright files

[Roger Leigh]

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/copyright, as seen in the source files and AUTHORS list or
> > equivalent (if any).
> 
> It would, of course, help, if at least most upstreams would adopt some
> systematic way of marking such. Could we push the machine-readable
> debian/copyright file upstream? :)

I think a standardised machine-readable copyright and licence header
for every source file would be desirable.  I do this for all my code.
Most upstreams do use a semi-standard list of copyright holders
followed by licence boilerplate, so it would hopefully only be a case
of fixing up files where a formatting screwup breaks the format.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: Please Improve Debian for Multimedia Production

[Grammostola Rosea]

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 just issued bits [1]).  So if you
are interested in those tasks and bugs pages or in multimedia related 
metapackages
just ask me in case there might be some technical questions about Blends.
You can read more here [2].
  
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 -- maintaining packages *in*
Debian. You just get some additional magic that helps you to make your
work a bit more visible and guides users like the starter of this
thread, as well as potential contributers
My aim as the thread starter was to ask for developers and/or package 
maintainers for multimedia in Debian. Because there are a lot nice 
packages which are not in Debian now or are pretty outdated. I know the 
Debian Multimedia Team exist, but I think they can use some help here...


Regards,

\r


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

Re: net-tools future

[Manoj Srivastava]

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  other hand, netstat -r, netstat -i, netstat -al
 just work?

Am I missing something, since munin is seen as a replacement for
 netstat?

manoj
-- 
I've noticed several design suggestions in your code.
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: Sponsorship requirements and copyright files

[Joerg Jaspert]

>> 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 information into debian/copyright.
> This is an absolute waste of time.

As your mail is.

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 ftpmaster. It has *no* gain for us at all, we couldnt care less if
you use it or not).

-- 
bye, Joerg
 man
 the AMD64 camp is not helped by the list of people supporting it
 when nerode is on your side, you know you're doing something wrong


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

Re: Sponsorship requirements and copyright files

[Manoj Srivastava]

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 package has to go through NEW, it takes about
 twice as much time to update this list than to do the actual packaging
 work.
 Why is this list needed? 
>>> Often the license requires it.  For instance the BSD license says,
>>> "Redistributions in binary form must reproduce the above copyright".
>
> 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 Program's source code as you
> receive it, in any medium, provided that you conspicuously and
> appropriately publish on each copy an appropriate copyright notice;
> keep intact all notices stating that this License and any
> non-permissive terms added in accord with section 7 apply to the code;
> keep intact all notices of the absence of any warranty; and give all
> recipients a copy of this License along with the Program.
> --88---

In each copy of the source code we have the license notices
 already, without it ever being in debian/copyright.

The verbatim copy of the programs source code have the copyright
 notice, so we meet that. Breinging that into this discussion is a red
 herring, and derails discussion on what is required in  debian/copyright;
 nothing in the GPL ever requires a debian/copyright file at all.

Trust me. Lots of people in the world distribute programs, and
 they often do not have debian/copyright files.  Copyright law is not
 just valid if you are a Debian derivative.

>>> To me, it seems like since one has to go through all of the source files
>>> anyway, creating a list of copyright holders while you are doing it is a
>>> trivial task.  I don't see why making this list takes any time at all
>>> really.  Unless you are not actually looking at the code you upload,
>>> which would worry me for other reasons as well.
>> I think it means what is says. The *ABOVE* copyright notice must
>>  be reproduced. That does not mean you have to hunt down every person
>>  with a Signed-Off-By header in the log, or every person who made an
>>  more than 10 line (non-trivial) patch submission to the project (and
>>  yes, most of these people also hold copyright -- how are you gonna find
>>  out all such names?)
>
> 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 information into debian/copyright.

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.

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
 requiring it (it does not) or Debian policy saying so (which it does
 not either).


>> Frankly, at this point, I am not seeing a need to track down or
>>  verify the completeness of my list of copyright holders, since it is
>>  almost impossible to do so, or very time consuming, and I see limited
>>  returns for time invested.
>
> We do not require people to wade through $VCS commit logs or mailinglist
> threads to find out who wrote each single line of code.
>
> 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).

Why do you think this work is needed? You must have had some
 rationale, since you made up this policy.

manoj
-- 
Hempstone's Question: If you have to travel on the Titanic, why not go
first class?
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

Proposal: Enhance requirements for General resolutions

[Joerg Jaspert]

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 think it is no longer the case. We currently have over 1000
Developers, and even if not everyone is active all the time, there
should be a little higher barrier before all of them have to deal with
something, effectively taking away time from their usual Debian work.

While one could go and define another arbitary number, like 10 or 15 or
whatever, I propose to move this to something that is dependent on the
actual number of Developers, as defined by the secretary, and to
increase its value from the current 5 to something higher. My personal
goal is 2Q there, which would mean 30 supporters. If you can't find 30
supporters, out of 1000 Developers, your idea is most probably not worth
taking up time of everyone else.

Various IRC discussions and the discussion on debian-project in December
told me that others feel similar. So here is a proposal.

As the discussion in December also told us, we should vote on different
options than just one, so I will also send in an amendment. My personal
goal would be to end up with a vote having options similar to the ones
pasted below as an example, but if someone feels like having a "Keep it
like it is, no discusssion" is needed, I would accept such an amendment
too. (Not that I think its neccessary, for me FD means that, but still).

- - - -=-=-=-=-=- 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
- - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

As this will change the constitution it will need a 3:1 to win. (see
Constitution 4.1.2)

Of course, this being a proposal to enhance the required seconds, I
would love if many people do second this, even if we might be past the
currently needed limit already. The more the better. :)

PROPOSAL START

General Resolutions are an important framework within the Debian
Project. Yet, in a project the size of Debian, the current requirements
to initiate one are too small.

Therefore the Debian project resolves that
 a) The constitution gets changed to not require K developers to sponsor
a resolution, but floor(2Q). [see §4.2(1)]
 b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)],
as well as resolutions against a shortening of discussion/voting
period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q)
developers to sponsor the resolution.
 c) the definition of K gets erased from the constitution. [§4.2(7)]

(Numbers in brackets are references to sections in the constitution).

PROPOSAL END

Practical changes: Taking the definitions of the latest GR we had,

 Current Developer Count = 1018
 Q ( sqrt(#devel) / 2 ) = 15.9530561335438
 K min(5, Q )   = 5
 Quorum  (3 x Q )   = 47.8591684006314

this will mean that future GRs would need 30 other people to support
your idea. While that does seem a lot (6times more than now),
considering that a GR affects more than 1000 official Developers and
uncounted amounts of other people doing work for Debian, I think its not
too much. Especially as point b only requires 15 people, 3 times the
amount than now, in case there is a disagreement with the DPL, TC or
a Delegate.

-- 
bye, Joerg
* libpng2 no libpng3 no why ? because no yes no yes no yes bullshit no yes
  no yes no yes stop ? no when someday beep beep beep beep (Closes: #157011)
 -- Christian Marillat   Thu, 29 Aug 2002 16:41:58 +0200


pgpskl3NEMDEh.pgp
Description: PGP signature

Re: Sponsorship requirements and copyright files

[Manoj Srivastava]

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. 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, "original author" is a something of a technical term in this
> domain. A definition capturing the common meaning of this term can be
> found e.g. in the CC licenses. In CC 3.0 it starts with
>   "Original Author" means, in the case of a literary or artistic work,
>   the individual, individuals, entity or entities who created the Work
>   ...
> The works Debian distributes are more often than not the result of a
> collaborative effort. As such, anyone with a (original, i.e. creative)
> contribution to the work is an original author, and not just whoever
> started a project.

Had Debian policy been written by copyright lawyers, you might
 have had a point. The  wording in policy was vetted by us non-lawyers;
 and, in fact, was last modified in a commit made by me, on
 2005-06-16.  I certainly did not mean the original in the sense you say
 it means in copyright law.

Putting busy work into a publicly available and documented
 policy makes it no less busy work, and a partial list of copyright
 owners (since the list of copyright owners is largter thatn the ones in
 the copyright notices on files) serves little  purpose, apart from hand
 wavy ones that applaud us for putting in extra, albeit mostly useless,
 effort.

manoj
-- 
An exception TESTS a rule; it NEVER proves it.  -- Edmund C. Berkeley
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: Sponsorship requirements and copyright files

[Manoj Srivastava]

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 insignificant number of these
> for the DFSG. Clearly, some amount of checking each file is a good
> thing, so why not be explicit about what is required of a developer
> for this?

I do a license check, yes. But that does not mean I record the
 author names, no. So, making sure that you cover all licenses the
 package comes with is required, but there is no reason to create a
 partial list of copyright holders --- until there is need to.

manoj
-- 
"Loyalty to petrified opinion never broke a chain or freed a human
soul." Mark Twain
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: Sponsorship requirements and copyright files

[Manoj Srivastava]

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. 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, "original author" is a something of a technical term in this
> domain. A definition capturing the common meaning of this term can be
> found e.g. in the CC licenses. In CC 3.0 it starts with
>   "Original Author" means, in the case of a literary or artistic work,
>   the individual, individuals, entity or entities who created the Work
>   ...
> The works Debian distributes are more often than not the result of a
> collaborative effort. As such, anyone with a (original, i.e. creative)
> contribution to the work is an original author, and not just whoever
> started a project.

Had Debian policy been written by copyright lawyers, you might
 have had a point. The  wording in policy was vetted by us non-lawyers;
 and, in fact, was last modified in a commit made by me, on
 2005-06-16.  I certainly did not mean the original in the sense you say
 it means in copyright law.

Putting busy work into a publicly available and documented
 policy makes it no less busy work, and a partial list of copyright
 owners (since the list of copyright owners is largter thatn the ones in
 the copyright notices on files) serves little  purpose, apart from hand
 wavy ones that applaud us for putting in extra, albeit mostly useless,
 effort.

manoj
-- 
An exception TESTS a rule; it NEVER proves it.  -- Edmund C. Berkeley
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: Sponsorship requirements and copyright files

[Josselin Mouette]

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 the AUTHORS file the Debian maintainer has to
> copy that information into debian/copyright.

This is an absolute waste of time.

Lots of time.

Valuable time.

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


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

Re: Sponsorship requirements and copyright files

[Lars Wirzenius]

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).

It would, of course, help, if at least most upstreams would adopt some
systematic way of marking such. Could we push the machine-readable
debian/copyright file upstream? :)


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

munin-plugin enhances.. (Re: net-tools future

[Holger Levsen]

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 way round: asterisk should suggest munin-node, to 
monitor it's performance. munin-node could probably make use of the enhances: 
field, which has been proposed sometime. (I dont remember its exact status.)

Else munin-node would "suggest" a lot of software, which IMO doesnt fit.

> Please cc me on responses: I am not subscribed to -devel

done.


regards,
Holger


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

Re: Sponsorship requirements and copyright files

[Joerg Jaspert]

>>> 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
>>> twice as much time to update this list than to do the actual packaging
>>> work.
>>> Why is this list needed? 
>> Often the license requires it.  For instance the BSD license says,
>> "Redistributions in binary form must reproduce the above copyright".

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 Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
--88---

>> To me, it seems like since one has to go through all of the source files
>> anyway, creating a list of copyright holders while you are doing it is a
>> trivial task.  I don't see why making this list takes any time at all
>> really.  Unless you are not actually looking at the code you upload,
>> which would worry me for other reasons as well.
> I think it means what is says. The *ABOVE* copyright notice must
>  be reproduced. That does not mean you have to hunt down every person
>  with a Signed-Off-By header in the log, or every person who made an
>  more than 10 line (non-trivial) patch submission to the project (and
>  yes, most of these people also hold copyright -- how are you gonna find
>  out all such names?)

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 information into debian/copyright.

> Frankly, at this point, I am not seeing a need to track down or
>  verify the completeness of my list of copyright holders, since it is
>  almost impossible to do so, or very time consuming, and I see limited
>  returns for time invested.

We do not require people to wade through $VCS commit logs or mailinglist
threads to find out who wrote each single line of code.

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).

-- 
bye, Joerg
>  I. What would you do if a package has no sane default configuration?
> (There is *no* default configuration that works on most systems!)
   The best thing to do would be to add such a default configuration.
[... ARGS ...]


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

Re: Sponsorship requirements and copyright files

[Thomas Viehmann]

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 sense of "initial" as your interpretation seems to suggest, this is
clearly and consistently not the case in the context of copyright. In
fact, "original author" is a something of a technical term in this
domain. A definition capturing the common meaning of this term can be
found e.g. in the CC licenses. In CC 3.0 it starts with
  "Original Author" means, in the case of a literary or artistic work,
  the individual, individuals, entity or entities who created the Work
  ...
The works Debian distributes are more often than not the result of a
collaborative effort. As such, anyone with a (original, i.e. creative)
contribution to the work is an original author, and not just whoever
started a project.

Debian sees increased enforcement of properly documenting copyright
status because the people who recently joined the FTP team were
instructed to check for this and pointed to the publicly available
reject faq and the two announcements on debian-devel-announce that
explicitly state that copyright notices must be listed and have not been
met with opposition when they were posted five and again three years ago.

Properly documenting the copyright license well includes listing the
licensor and the basis of the license, i.e. including the copyright
notice. If Debian absolutely wants to decide it does not care about who
grants the copyright license, then it has to do so. It might not,
however, be quite necessary to pretend that the ftp team who try to
diligently do the job that has been entrusted to them, including
(manually, mostly, not that much less tedious as compiling them)
double-check that the stuff put on Debian mirrors is prima facie legally
distributable is getting fun out of making up reject reasons.

I do not envy anyone to have to wade through things to collect these
notices and looking at hundreds of license boilerplates but having found
stuff like "proprietary property of IBM" in openjdk (probably vetted by
people paid to know what they are doing) or KDE themes with an PNGs from
a KDE icon collection and the express clarification that GPL requires
distributing SVG source with any pixel formats, I can assure you that if
Debian is interested in credibly attempting to ensure that the stuff put
on mirrors is legal to distribute someone has to look at every file in
the tarballs.

Kind regards

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


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

Re: net-tools future

[Jonas Smedegaard]

-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 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:

> This is used to declare that one package may be more useful with one 
> or more others.  Using this field tells the packaging system and the 
> user that the listed packages are related to this one and can perhaps 
> enhance its usefulness, but that installing this one without them is 
> perfectly reasonable.



Kind regards,

  - Jonas

P.S.

Please cc me on responses: I am not subscribed to -devel

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknE7asACgkQn7DbMsAkQLjc2wCfXHR73zu54jsTcaEQVJcAI6qe
oa8An358Gj3WDQd4c15f8B/e7ZscveJn
=ax17
-END PGP SIGNATURE-


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

Re: net-tools future

[Luk Claes]

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 guess
>> some packages use net-tools if available and otherwise fallback to
>> something else?
> 
> Sadly I think thats wishful thinking at least in the case of the four 
> packages 
> I mentioned. 
> 
> 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 because there is a plugin to monitor it :)
> 
> debian-edu-config might be covered through one of its depends (but it doesnt 
> seem so, not even lsb depends net-tools, so I just added a depends in svn).
> 
> sitesummary misses it, so I fixed it in svn.
> 
> fai uses it in three binary packages: fai-server, fai-client and fai-doc. 
> I'll 
> follow up on this on the fai-list.

Note that we want packages to stop using net-tools, so you might want to
fix that as well :-)

Cheers

Luk


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

Re: net-tools future

[Holger Levsen]

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 available and otherwise fallback to
> something else?

Sadly I think thats wishful thinking at least in the case of the four packages 
I mentioned. 

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 because there is a plugin to monitor it :)

debian-edu-config might be covered through one of its depends (but it doesnt 
seem so, not even lsb depends net-tools, so I just added a depends in svn).

sitesummary misses it, so I fixed it in svn.

fai uses it in three binary packages: fai-server, fai-client and fai-doc. I'll 
follow up on this on the fai-list.


regards,
Holger

(maintainer role-addresses bcc:ed.)


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

Re: net-tools future

[Theodore Tso]

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 enabled by an environment variable or a command-line option which
printed the equivalent "ip" commands which they issued, so people can
learn the new "ip" interface if they are so interested.

Also, I'd recommend making the scripts carefully cover 100% of the
ifconfig, route, and netstat commands, since these commands have a
very long history, and are extremely well known by many sysadmins, and
used in many, *many* shell scripts.

- Ted


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

Bug#520620: ITP: kplayer -- media player

[David Palacio]

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 written with KDE libraries. As mplayer, it 
supports a wide range of multimedia formats.

A previous ITP was closed because kplayers license was incompatible with Qt. 
Now that Qt 4.5.0 is in the archive, that is not longer the case.

Kplayer packaging can be found at:
http://github.com/dpalacio/debian-pkg/tree/master



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

Re: Sponsorship requirements and copyright files

[Noah Slater]

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 policy.
>
> And telling people they are doing a bad job and need to either
>  shape up or change policy does not actually seem to be corroborated by
>  policy, unless I am missing chunks.

Yeah, I apologise for this. This had been my understanding. Sorry.

> BTW, to your list of solutions, I can add another one:
>  + realize this is busy work with little value in the common case, and
>prefer to spend time otherwise improving the package.

On the other hand, I think this needs to be clarified.

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 insignificant number of these for the DFSG. Clearly, some amount of
checking each file is a good thing, so why not be explicit about what is
required of a developer for this?

Best,

-- 
Noah Slater, http://tumbolia.org/nslater


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

Re: net-tools future

[Michael Tautschnig]

> 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 packages use net-tools if available and otherwise fallback to
> something else?
> 

In that case, Holger actually listed packages that lack proper Depends: ... :-)

Best,
Michael



pgpcH5Dh7YK49.pgp
Description: PGP signature

Re: net-tools future

[Luk Claes]

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 packages use net-tools if available and otherwise fallback to
something else?

Cheers

Luk


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

abiword package lacks maintenance

[Patrik Fimml]

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/
[2] http://bugs.debian.org/514525

Abiword is a word processor for GNOME, with a simpler interface and less
functionality than e.g. OpenOffice.org Writer.

According to db.debian.org, both maintainers seem to be on vacation.  I
have been trying to contact them more than a month ago, without reply.
Could a DD check whether they are planning to return sometime soon?

As already mentioned, the package is not very up-to-date, which is why
I'd offer to take it over. As maintainer of the eboard package, I
already have some experience in packaging and with the BTS.

Please CC me in replies, as I'm not subscribed to the list (though
reading it on-line).

Kind regards,
Patrik Fimml


signature.asc
Description: Digital signature

Re: net-tools future

[Holger Levsen]

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 
debian-edu-config


regards,
Holger


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

Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Paul Wise]

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 DDTP one contains the translated version and
> English ones for those with missing or outdated translations. That way,
> apt spends less time parsing the (smaller) Packages file when doing
> ordinary stuff like package installation and only needs to look at the
> DDTP information when specifically called as 'apt-cache search'.

One issue is that many people will have disabled downloading
translations so they'll need to change their configuration from none
to en:

APT::Acquire::Translation "none";

Since en will now be a "Translation", perhaps a different config item
is more appropriate:

APT::Acquire::Description "en";

-- 
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: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Neil Williams]

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 descriptions from the Packages files. I think the obvious place
> to put them is in dists/unstable/main/i18n/Translations-en (or C) like
> the descriptions from DDTP.

Now that's a good idea - thanks Paul. That way, the long descriptions
can be moved aside without needing changes by lots of maintainers and
other formatting changes like the original thread can proceed
independently.

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 DDTP one contains the translated version and
English ones for those with missing or outdated translations. That way,
apt spends less time parsing the (smaller) Packages file when doing
ordinary stuff like package installation and only needs to look at the
DDTP information when specifically called as 'apt-cache search'.

CC:'ing debian-i18n to see if there are problems with this approach.

-- 


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



pgprAi03SA6jw.pgp
Description: PGP signature

Re: RFC: Better formatting for long descriptions

[Neil Williams]

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 used, it's about whether such detailed content
> > deserves to be in Packages.gz in the first place.
> 
> Then I wonder why you hijacked this thread and did not rather start a
> new one?

If large numbers of package descriptions are to change collectively,
it's best to make that one change with two aims rather than two separate
changes. Less work for everyone involved.

Just looking for a bit of consideration for those situations where the
Packages file is already too large.

-- 


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



pgptoOhBoY8aZ.pgp
Description: PGP signature

Re: Extended descriptions size (was Re: RFC: Better formatting for long descriptions)

[Neil Williams]

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
> > > leading spaces is considered verbose. 
> >
> > Packages.gz is already 26Mb - I'd like to find ways to shorten the
> > package descriptions, not lengthen it. :-(
> >   
> Current squeeze main Packages.gz is 7 MB: 
> http://ftp.ca.debian.org/debian/dists/squeeze/main/binary-i386/

Bah, my fault - 26Mb uncompressed. I was looking at /var/lib/apt/lists/
Sorry.

> > Can the long description be trimmed to only such data necessary to
> > identify the package compared to similar packages? We have debtags for
> > lots of other facets of a package description, maybe it is time that
> > the long description itself is trimmed so that it does not repeat any
> > information already encoded as debtags?

> debtags is not yet at a stage where this should be done (for one thing, 
> Synaptic, for "example", does not support debtags). Even if it would be 
> possible, I doubt this would help much.

Any reduction, replicated across 13,000 packages (or even just the
ones from that 13,000 that have verbose long descriptions currently), is
only going to help reduce the size of the file.

> > 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 description needs to be available to APT

Only for use by apt-search, the rest of apt doesn't care about it. apt
understands debtags, why duplicate that information? (Frontends can be
adapted or just rely on apt-cache search underneath.)

>, not only via 
> packages.d.o. I seem to remember that Mandrake Linux (or some other 
> RPM-based distribution) used two Packages-like files, a fat one about 5 
> times our Packages and a slim one about a fifth of Debian's Packages. I 
> remember finding the slim index cool, but now that there's 
> Packages.diff, I think that developing Mandrake-like Packages files and 
> seeing the results in, perhaps, 2 years, would not benefit much to the 
> kind of hardware Debian will run on by then.

Debian is not exclusively for power-hungry servers and mega-powerful
workstations, Debian also runs on very small hardware and not
necessarily old stuff either. It is a mistake to think that Debian
should require more and more powerful hardware for the basic system.

Yes, there is software in Debian that needs a powerful machine, there
is also a LOT of software in Debian specifically designed for low
resource machines where the benefits of a <1Mb Packages.gz file are
appreciable.

-- 


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



pgp3lHY1fDFBt.pgp
Description: PGP signature