Re: Sponsorship requirements and copyright files
On Thu, Mar 19, 2009 at 10:19 PM, Mike O'Connor s...@debian.org wrote: 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 agree. The thing that I like about creating packages with the wiki.d.o specification is that it forces you to actually examine the copyrights of all the parts of a new package, instead of just use a lazy link to /usr/share/common-licenses/foo. This is especially important for packages that have many different hidden scripts or architecture-independent libraries that might have different licenses. With the kind of copyright file generated by dh_make, it seems like new maintainers often ignore the risk of a package with a tainted, unredistributable license problem. In shorter words: I think something should be done about the copyright file to encourage developers to actually perform an audit of the license status of files in their packages before they upload. The current copyright template doesn't really encourage this; I like the machine-parseable system because it makes it easy to organize such an audit. Daniel -- Daniel Moerner dmoer...@gmail.com -- 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
On 2009-03-20, Mike O'Connor s...@debian.org wrote: 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. It is a very trivial, but very time consuming task to document the copyright holders. $ find . -name '*.cpp' | wc --lines 923 $ find . -name '*.h' | wc --lines 1001 find all the well formed copyright holder headers: $ grep -rhi Copyright * | grep @| sed 's/\*//g;s/#//g;s,/,,g;s/ //g;s/^ //' | sort -u | wc --lines 444 and then there is all the not well formed ones who needs to be manually found, and ordered into a copyright file of any format. And this is just looking at one of my source packages. Trying to take another example, a bit bigger, but one who until now get special treatment by ftp team copyright file wise: linux-2.6-2.6.28$ find . -name '*.h' | wc --lines 9654 $ find . -name '*.c' | wc --lines 10807 $ grep -rhi Copyright * | grep @| sed 's/\*//g;s/#//g;s,/,,g;s/ //g;s/^ //' | sort -u | wc --lines 3066 not any time at all ... /Sune -- 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
On Fri, Mar 20 2009, Mike O'Connor wrote: On Fri, Mar 20, 2009 at 12:58:14AM +0100, Josselin Mouette 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. 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?) So, I just reproduce that copyright notice in the binary package, which is all that one is required to do. I might also add other obvious contributor names, if the appear in other files in the package, but this is mostly the first time I package stuff. I might miss names added or new files in a new version, though I try. 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. manoj -- He who takes nothing in the world that has not been given him, long or short, big or small, attractive or that is what I call a brahmin. 409 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 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
On Thu, Mar 19, 2009 at 11:02:48PM -0700, Daniel Moerner wrote: On Thu, Mar 19, 2009 at 10:19 PM, Mike O'Connor s...@debian.org wrote: 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 agree. The thing that I like about creating packages with the wiki.d.o specification is that it forces you to actually examine the copyrights of all the parts of a new package, instead of just use a lazy link to /usr/share/common-licenses/foo. This is especially important for packages that have many different hidden scripts or architecture-independent libraries that might have different licenses. With the kind of copyright file generated by dh_make, it seems like new maintainers often ignore the risk of a package with a tainted, unredistributable license problem. In shorter words: I think something should be done about the copyright file to encourage developers to actually perform an audit of the license status of files in their packages before they upload. The current copyright template doesn't really encourage this; I like the machine-parseable system because it makes it easy to organize such an audit. Try doing that on iceweasel or xulrunner. Hint: there are about 3 files and a real lot of copyright holders. It's already a PITA with webkit, which is about 3000 files and quite a lot of copyright holders (the copyright file, which I'm pretty sure is not accurate is 809 lines and growing at each new release). On top of listing copyright holders, I must say listing the individual files for each license in the copyright file is also a major PITA. While wildcards can be used, a huge mix of license like webkit is makes it really painful to update. OTOH, I really don't care what files are under what licence. I *do* know that there is a mix of BSD-2, BSD-3 and LGPL code, plus some extra libraries embedded, and that any addition to webkit is licensed under BSD or LGPL because upstream does enforce that (except, obviously, embedded libraries, but we already have to check if any is added to avoid duplication and build against the system one whenever possible) 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
Sune Vuorela nos...@vuorela.dk writes: On 2009-03-20, Mike O'Connor s...@debian.org wrote: 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. It is a very trivial, but very time consuming task to document the copyright holders. $ find . -name '*.cpp' | wc --lines 923 $ find . -name '*.h' | wc --lines 1001 find all the well formed copyright holder headers: $ grep -rhi Copyright * | grep @| sed 's/\*//g;s/#//g;s,/,,g;s/ //g;s/^ //' | sort -u | wc --lines 444 and then there is all the not well formed ones who needs to be manually found, and ordered into a copyright file of any format. And this is just looking at one of my source packages. All of what you've demonstrated is part of what Mike covered with “one has to go through all of the source files anyway”, is it not? The point I got from his message is that, having *already* accepted the burden of going through all the files, one can then record the copyright status while doing that. Unless you are not actually looking at the code you upload, which would worry me for other reasons as well. Are you proposing some third option? -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__) development | Ben Finney -- 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
On Fri, Mar 20, 2009 at 01:28:09AM -0500, Manoj Srivastava wrote: On Fri, Mar 20 2009, Mike O'Connor wrote: 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. 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?) Yes, Manoj, thanks for the clarification. I didn't intend to imply that I believed that this statement in the license is a requirement to hunt down all contributors. I agree that it rather clearly indicates ABOVE copyright statements. I meant to point out to Joss, who was seeming to imply that copyright notices shouldn't be required at all in debian/copyright, that there are clear cases when they are required. stew signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
On 2009-03-20, Ben Finney ben+deb...@benfinney.id.au wrote: All of what you've demonstrated is part of what Mike covered with ???one has to go through all of the source files anyway???, is it not? The point I got from his message is that, having *already* accepted the burden of going through all the files, one can then record the copyright status while doing that. So far, comaintainers of gnome, kde, webkit, xulrunner and firefox are saying that this is a major extra burden. The kernel team seems to have a full waiver for listing copyright holders. So please listen to the packagers of big packages what is a burden and what is not. Trying to look over Ben Finney's packages, the most complex package is gracie, where Ben is upstream. It is a python package consisting of 1000 lines of sourcecode + 3000 lines of test code. (according to sloccount). Except a single file in the test code, everything is by Ben. Trying to look over some of Mike O'Connor's packages, kxstitch and rosegarden, Kxstitch with one upstream author and bunches of autogenerated files. (the sources are available and the generated tools are GPL, so no real problem, but just not 'good style'). The copyright file does mention this one author. Rosegarden is having many copyright holders, only 3 is mentioned in the copyright file. Most files have a copyright header stating Copyright is Rosegarden development team, so all in all not that complex from a copyright file point of view. Still, there is many copyright holders missing from debian/copyright. If anyone wants to actually try working with copyright files for one of those bigger packages, Mike O'Connor helpfulyl just opened #520485 to track one of them. Patches are welcome. /Sune -- 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
pe, 2009-03-20 kello 04:00 +0100, Romain Beauxis kirjoitti: Was there any intent of writting such a tool at some point ? Most of the specifications also deduce from an actual implementation, which also helps people who don't want to follow the multiple revisions to check and convert their files.. I always have been waiting from some sort of validation tools from the people that want to push for this before considering converting my files... I'm writing a Python library that will make it easy to write tools to use copyright files. Once Steve gets DEP-5 going, I'll share my ideas for the library. -- 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
On Sun, Mar 15, 2009 at 11:07:29PM +0100, Marco d'Itri wrote: On Mar 15, Bernd Zeimetz be...@bzed.de wrote: Being able to rename an interface without messing with udev is a feature, not a bug. Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. It is still possible to install and run Lenny without the use of udev, and many people do so. 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? -- Lo-lan-do 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
On Fri, Mar 20, 2009 at 09:09:53AM +, Roger Leigh rle...@codelibre.net wrote: Mike Hommey wrote: On Thu, Mar 19, 2009 at 11:02:48PM -0700, Daniel Moerner wrote: On Thu, Mar 19, 2009 at 10:19 PM, Mike O'Connor s...@debian.org wrote: 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 agree. The thing that I like about creating packages with the wiki.d.o specification is that it forces you to actually examine the copyrights of all the parts of a new package, instead of just use a lazy link to /usr/share/common-licenses/foo. This is especially important for packages that have many different hidden scripts or architecture-independent libraries that might have different licenses. With the kind of copyright file generated by dh_make, it seems like new maintainers often ignore the risk of a package with a tainted, unredistributable license problem. In shorter words: I think something should be done about the copyright file to encourage developers to actually perform an audit of the license status of files in their packages before they upload. The current copyright template doesn't really encourage this; I like the machine-parseable system because it makes it easy to organize such an audit. Try doing that on iceweasel or xulrunner. Hint: there are about 3 files and a real lot of copyright holders. It's already a PITA with webkit, which is about 3000 files and quite a lot of copyright holders (the copyright file, which I'm pretty sure is not accurate is 809 lines and growing at each new release). On top of listing copyright holders, I must say listing the individual files for each license in the copyright file is also a major PITA. Given that copyrights are usually in a standard format, such as Copyright (\([cC]\)|©) Year[-Year] Name Email It shouldn't be too hard to write a tool to scan the whole source tree and spit out a completely generated summary of copyright holders. If this could be added to an existing tool, such as licensecheck, this would save everyone from reimplementing it in their package (I was considering doing this). Licensecheck already checks that, though you have to give it an option for that, but it fails to catch anything that doesn't match such pattern, and I can tell you there are a lot... I invite you to take a look at a few .cpp files from xulrunner or iceweasel, you'll see you won't get much with your pattern, and that you can't reliably get these holders with a pattern. 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
Sune Vuorela nos...@vuorela.dk writes: On 2009-03-20, Ben Finney ben+deb...@benfinney.id.au wrote: All of what you've demonstrated is part of what Mike covered with ???one has to go through all of the source files anyway???, is it not? The point I got from his message is that, having *already* accepted the burden of going through all the files, one can then record the copyright status while doing that. So far, comaintainers of gnome, kde, webkit, xulrunner and firefox are saying that this is a major extra burden. What is “this” that you refer to, though? Going through the files that one is proposing to distribute? Or recording their copyright status as one goes? That's a key distinction that I'm not seeing addressed in your objection. -- \ “I met my girlfriend in Macy's; she was buying clothes, and I | `\ was putting Slinkies on the escalators.” —Steven Wright | _o__) | Ben Finney -- 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
On Tue, Mar 17, 2009 at 09:05:53AM +0100, Bjørn Mork wrote: Ben Hutchings b...@decadent.org.uk writes: You can do this with ethtool now, and more cleanly: link-speed 100 link-duplex full Yes, I know. But that means that existing working configurations have to be modified. Which should not be an argument to hold back progress. Every release upgrade contains with it such cases, and they are all handled, either through documentation in /usr/share/doc/relevant package, or through meta packages, or through the release notes. This is no different. -- Lo-lan-do 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
[Transferred to -devel as suggested. Please follow-up there]. Le Thu, Mar 19, 2009 at 04:40:33PM +, Sune Vuorela a écrit : http://wiki.debian.org/Proposals/CopyrightFormat It is a too complex, overengineered solution to a very minor issue. It is not easy readables for humans It is ugly Too time consuming to write and check No real gain. Hi Sune, Ugliness was already reported earlier by Christoph Berg, and I think that the only reason why his points have not been integrated in the wiki page is because his comments came after a consensus emerged that the page was overloaded and that we would first change the discussion medium before resuming discussions and modifications. I am quite confident that readability can be much improved. See for instance the copyrignt file of the perl packages created with recent versions of dh-make-perl, like the following one: http://ftp-master.debian.org/new/libfile-find-object-perl_0.2.0-1.html#binary-libfile-find-object-perl-copyright In my opinion, it is already quite nice and readable compared to dh-make's template, that starts by dealing about debianization before going to the most important: the main license of the package. Nevertheless, we could probably slim the machine-readable version down to something like: Name: File-Find-Object Maintainer: Olivier Thauvin shlo...@iglu.org.il Source: http://search.cpan.org/dist/File-Find-Object/ Copyright: © 2009, Olivier Thauvin shlo...@iglu.org.il License: Artistic or GPL-1+ License: Artistic This program is free software; you can redistribute it and/or modify it under the terms of the Artistic License, which comes with Perl. On Debian GNU/Linux systems, the complete text of the Artistic License can be found in `/usr/share/common-licenses/Artistic' License: GPL-1+ This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version. On Debian GNU/Linux systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL' Files: debian/* Copyright: 2009, Alejandro Garrido Mota garridom...@gmail.com License: Artistic or GPL-1+ Format-Specification: Machine-readable copyright declaration version 1 Do not hesitate to make suggestions, there is no doubt the proposal can be impoved ! Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: net-tools future
On Fri, Mar 20, 2009 at 09:57:13AM +0100, Wouter Verhelst wrote: On Sun, Mar 15, 2009 at 11:07:29PM +0100, Marco d'Itri wrote: Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. It is still possible to install and run Lenny without the use of udev, and many people do so. 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? I wouldn't call small systems a 'toy'. udev is desired, nearly required for big systems, right. It's bloat and trouble for embedded or limited ones. I don't do embedded personally so I have no idea how udev fares there, but I can tell you that vservers and udev don't go well together. Udev expects a real system where there's none and then gets confused -- vserver is hardly more than a glorified chroot, nearly identical to BSD jails. You want every container to be small and simple. A vserver is a valid Debian system, and certainly not a waste of archive space. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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
Le vendredi 20 mars 2009 à 08:28 +, Sune Vuorela a écrit : If anyone wants to actually try working with copyright files for one of those bigger packages, Mike O'Connor helpfulyl just opened #520485 to track one of them. Patches are welcome. How thoughtful of his. Hint: you can open such a bug on each and every GNOME package that hasn’t gone through NEW in the 2.24 cycle. -- .''`. 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
Mike Hommey wrote: On Thu, Mar 19, 2009 at 11:02:48PM -0700, Daniel Moerner wrote: On Thu, Mar 19, 2009 at 10:19 PM, Mike O'Connor s...@debian.org wrote: 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 agree. The thing that I like about creating packages with the wiki.d.o specification is that it forces you to actually examine the copyrights of all the parts of a new package, instead of just use a lazy link to /usr/share/common-licenses/foo. This is especially important for packages that have many different hidden scripts or architecture-independent libraries that might have different licenses. With the kind of copyright file generated by dh_make, it seems like new maintainers often ignore the risk of a package with a tainted, unredistributable license problem. In shorter words: I think something should be done about the copyright file to encourage developers to actually perform an audit of the license status of files in their packages before they upload. The current copyright template doesn't really encourage this; I like the machine-parseable system because it makes it easy to organize such an audit. Try doing that on iceweasel or xulrunner. Hint: there are about 3 files and a real lot of copyright holders. It's already a PITA with webkit, which is about 3000 files and quite a lot of copyright holders (the copyright file, which I'm pretty sure is not accurate is 809 lines and growing at each new release). On top of listing copyright holders, I must say listing the individual files for each license in the copyright file is also a major PITA. Given that copyrights are usually in a standard format, such as Copyright (\([cC]\)|©) Year[-Year] Name Email It shouldn't be too hard to write a tool to scan the whole source tree and spit out a completely generated summary of copyright holders. If this could be added to an existing tool, such as licensecheck, this would save everyone from reimplementing it in their package (I was considering doing this). Of course, this does depend on the files being completely up-to-date, otherwise this is useless. As an upstream, I would say that while I do make an effort to keep these up to date, not every contributor does an so information will be missing. This is ultimately all stored in the git commits, so trawling though the repo might be needed to actually make an accurate header in each file. Regards, Roger -- 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
On Mar 20, Wouter Verhelst wou...@debian.org 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. 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. -- ciao, Marco signature.asc Description: Digital signature
Re: net-tools future
Twas brillig at 10:50:23 20.03.2009 UTC+01 when kilob...@angband.pl did gyre and gimble: AB It's bloat and trouble for embedded or limited ones. mdev from busybox kicks in there. -- pgpoBcZgEVOcl.pgp Description: PGP signature
svn-buildpackage's future
Hi all, I had some talks with Eduard Bloch (the author of svn-buildpackage) and Eddy Petrisor (as a contributor listed in its uploaders field) and it seems that both of them lost their interest in svn-bp and/or are too busy to take care of current development. Some time ago I started fixing some of the bugs but then discovered that some of those need bigger improvement in svn-bp's code. Thinking about all that I started redesigning svn-bp (actually I started redesigning the code but in the end it's become more) and after writing some code I want to stop here and wait for comments, suggestions and criticism first (before doing too much in the wrong direction). === Why the changes? === svn-buildpackage (with its scripts svn-inject and svn-upgrade) is a collection of logically structured system calls which invoke other binaries via shell (mainly svn commands of course). That lead to inconvinient issues, e.g. having to authenticate for every single svn call. Another problem came up with packages with many files. For some shell commands all files were listed as arguments, this leading to a shell failure because of too many lines. So, to get rid of these shell commands I wanted to use SVN::Client and other perl libraries. I tried to implement it in current code but that was too hard to do. :) Then there were layout problems (layout meaning the repository layout in this case). At the moment svn-bp knows two different layouts but there were requests for new ones. Implementing more layouts seems pretty hard because layout specific code is to be found everywhere in the scripts. Another reason for rewriting at least some of the code is Format: 3.0 (quilt). Some parts of svn-bp rely on a diff.gz; those need to be able to deal with debian.tar.comp as well which is not as easy as I thought in the first place. === So, what's the new idea? (implementation) === I started writing a class SvnBp::Repository which wraps some SVN::Client functions and implements the layout types (those are actually in subclasses SvnBp::Repository::Layout[1-3]). Having this structure it's easier to add new layouts. And the big win (IMO) is the interface to the repository which is of course layout independent (you can always give 'branches/lenny' as arguments and the object knows the exact URL for the selected layout). Another class I started writing is SvnBp::Dpack which is a wrapper for everything related to the package. It's supposed to know commands like get_upstream, get_full_source, build and so on. (Yes, the idea is to have short and readable svn-* scripts in the end.) This all wouldn't automatically mean any changes for our users, but... === What about more ideas? === Well, there is another one: removing svn-inject and svn-upgrade and moving that functionality to svn-buildpackage which now knows 'operation modes'. svn-inject would then be 'svn-buildpackage inject' (and of course there will be symlinks from svn-(inject|upgrade) to svn-buildpackage which then starts the correct mode automagically). The idea is to make svn-buildpackage more like a layer over svn with package building functionality :). That means that I intend to implement more subversion typical commands in svn-buildpackage, e.g. switch or checkout. Since svn-bp then knows about the layout it's possible to do svn-buildpackage checkout branches/lenny svn+ssh://alioth.d.o/whatever/package or similar (not yet implemented :)). I think that it's still possible to leave the command line options unchanged which is convinient for already written scripts around svn-bp. About the config file of svn-bp I'm not sure yet. I'm thinking about changing it completely to have a file with groups (maybe even group names as regexps) which would be nice for people who work in group maintenance and alone. But that's still just an idea. === Where to find what? === A summary (or whatever it is) can be found in the wiki at: http://wiki.debian.org/svn-buildpackage/improvements The code (without a debian dir and any documentation) is in the svn-bp subversion repository (in collab-maint) as branch/0.7: svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/svn-buildpackage/branches/0.7 === Why am I telling you that? === 1. Like probably almost everyone else in this project I need help to get ready faster (the code is *far* from usable!). 2. As I already said I don't want to implement everything and then see you disagreeing completely with me. So, this is your chance to tell me that everything was wrong and I'm a stupid moron who should go home -- or you send patches, whatever you like better. Also, you can now send in wishes for 0.7; I'll try to consider all of them. If you want to help me (which I very much appreciate) please contact me off list; almost everything is possible! And now, go, rip me up! :-) Hauke signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
Le Friday 20 March 2009 10:58:53 Josselin Mouette, vous avez écrit : Le vendredi 20 mars 2009 à 08:28 +, Sune Vuorela a écrit : If anyone wants to actually try working with copyright files for one of those bigger packages, Mike O'Connor helpfulyl just opened #520485 to track one of them. Patches are welcome. How thoughtful of his. Hint: you can open such a bug on each and every GNOME package that hasn’t gone through NEW in the 2.24 cycle. There was at some point a discussion about a collaborative copyright proofread. I think this would be a great improvement in our workflow. What was the conclusion of this proposal ? Romain -- 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
On Fri March 20 2009 02:53:19 Marco d'Itri wrote: On Mar 20, Wouter Verhelst wou...@debian.org 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. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? --Mike Bird -- 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
On Fri, Mar 20, 2009 at 07:46:11AM +0100, Mike Hommey wrote: In shorter words: I think something should be done about the copyright file to encourage developers to actually perform an audit of the license status of files in their packages before they upload. The current copyright template doesn't really encourage this; I like the machine-parseable system because it makes it easy to organize such an audit. Try doing that on iceweasel or xulrunner. Hint: there are about 3 files and a real lot of copyright holders. It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. On top of listing copyright holders, I must say listing the individual files for each license in the copyright file is also a major PITA. While wildcards can be used, a huge mix of license like webkit is makes it really painful to update. OTOH, I really don't care what files are under what licence. I *do* know that there is a mix of BSD-2, BSD-3 and LGPL code, plus some extra libraries embedded, and that any addition to webkit is licensed under BSD or LGPL because upstream does enforce that (except, obviously, embedded libraries, but we already have to check if any is added to avoid duplication and build against the system one whenever possible) You might not care, but the package users might do. -- 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
On Mar 20, Adam Borowski kilob...@angband.pl wrote: udev is desired, nearly required for big systems, right. It's bloat and It's not. trouble for embedded or limited ones. I don't do embedded personally so I have no idea how udev fares there, but I can tell you that vservers and udev don't go well together. Udev expects a real system where there's none and then gets confused -- vserver is hardly more than a glorified chroot, nearly identical to BSD jails. You want every container to be small and simple. This is why you install udev in the host system and bind-mount its /dev to the /dev of each context. vserver and openvz are not relevant for the purpose of this discussion. On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote: popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? And surely lurkers agree with you in personal emails... -- ciao, Marco signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
Hi, On Freitag, 20. März 2009, Sune Vuorela wrote: The kernel team seems to have a full waiver for listing copyright holders. AFAIK linux-kbuild-2.6.28 was rejected from NEW for this very reason. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 08:28:34AM +, Sune Vuorela wrote: On 2009-03-20, Ben Finney ben+deb...@benfinney.id.au wrote: All of what you've demonstrated is part of what Mike covered with ???one has to go through all of the source files anyway???, is it not? The point I got from his message is that, having *already* accepted the burden of going through all the files, one can then record the copyright status while doing that. So far, comaintainers of gnome, kde, webkit, xulrunner and firefox are saying that this is a major extra burden. The kernel team seems to have a full waiver for listing copyright holders. So please listen to the packagers of big packages what is a burden and what is not. No one is saying it isn't a chore. As a maintainer, it is your duty to make sure that everything you upload is DFSG free, which means checking every single file. As you have to do this anyway, it makes sense to record that information in debian/copyright. If you maintain a very large package, then you should *expect* this to take a long time. If that's too much effort for your, get a co-maintainer or a different package. -- 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
Le vendredi 20 mars 2009 à 12:14 +0100, Marco d'Itri a écrit : This is why you install udev in the host system and bind-mount its /dev to the /dev of each context. Erm… no, you don’t. -- .''`. 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: Bug#520471: ITP: configure-trackpoint -- configuration program for Thinkpad TrackPoint mouse
On Thu, Mar 19, 2009 at 10:56:39PM -0400, Joe Nahmias wrote: Package: wnpp Severity: wishlist Owner: Joe Nahmias je...@debian.org * Package name: configure-trackpoint Version : 0.7 Upstream Author : Cheuksan Edward Wang wang02139_AT_gmail.com * URL : http://tpctl.sourceforge.net/configure-trackpoint.html * License : GPL Programming Lang: C Description : configuration program for Thinkpad TrackPoint mouse configure-trackpoint is a small GNOME utility that allows the user customize various parameters related to the trackpoint found on many IBM/Lenovo Thinkpads. Shouldn't that rather be implemented as a preferences capplet? From the screenshots, it looks like a stand-alone application. Michael -- 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
On Thu, Mar 19, 2009 at 09:41:36PM -0700, Russ Allbery wrote: Ben Finney ben+deb...@benfinney.id.au writes: The point is that, since we can predict the need for this information, we have the choice of assuming the information is there when we distribute and never looking for it until the need arises in the face of such a threat, or looking for it in advance of distribution and hence in advance of exposure to that threat. I think it's clear that the latter option is preferable. Er, I'm certainly not going to pay any attention who the copyright holders are for various files in something I'm packaging. I care about the license; why should I care in the slightest whether the listed copyright holder is one name or some other name? Of course, this isn't just about the legal issues. Including the copyright statement is a form of attribution, and is good manners. I also see that the copyright file is primarily useful to end users who may want a convenient way of browsing the copyright and licence information. 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
Le vendredi 20 mars 2009 à 11:16 +, Noah Slater a écrit : As a maintainer, it is your duty to make sure that everything you upload is DFSG free, which means checking every single file. As you have to do this anyway, it makes sense to record that information in debian/copyright. If you maintain a very large package, then you should *expect* this to take a long time. If that's too much effort for your, get a co-maintainer or a different package. Fine. Do you have co-maintainers on sale? -- .''`. 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
Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit : If that's too much effort for your, get a co-maintainer or a different package. Fine. Do you have co-maintainers on sale? It is not about co-maintaining, but about co-reviewing which is a totally different task. 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
Le vendredi 20 mars 2009 à 13:02 +0100, Romain Beauxis a écrit : Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit : Fine. Do you have co-maintainers on sale? It is not about co-maintaining, but about co-reviewing which is a totally different task. Do you really think we can find an unlimited amount of volunteers willing to continuously read thousands of files to find the list of copyright holders? -- .''`. 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: User and groups justification (was Re: group nvram)
On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote: On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it wrote: I would prefer any new information to be added there instead, since the files above are available offline as well. Does not forbid to add to wiki in order to ease writing :) I agree we should sync the offline file. If you do so please bear in mind that doc/* in the base-passwd package is licensed GPL-2 and Debian wiki pages have no automatic explicit copyright exceptions (i.e. default to all rights reserved). See http://wiki.debian.org/Maintainers for an example of how to specify an explicit license for a new page (and the linked http://wiki.debian.org/DebianWiki/LicencingTerms for context and history) -- Jon Dowland -- 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
m...@linux.it (Marco d'Itri) writes: On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote: popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? And surely lurkers agree with you in personal emails... Marco, it was you that cited absence of evidence (the low popcon score) as evidence of absence. You don't get to accuse Adam of doing the same, especially since he's not doing it. -- \ “Any intelligent fool can make things bigger and more complex… | `\It takes a touch of genius – and a lot of courage – to move in | _o__)the opposite direction.” —Albert Einstein | Ben Finney -- 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
Le Friday 20 March 2009 13:07:44 Josselin Mouette, vous avez écrit : It is not about co-maintaining, but about co-reviewing which is a totally different task. Do you really think we can find an unlimited amount of volunteers willing to continuously read thousands of files to find the list of copyright holders? I mean that asking for co-mainenance is a different thing than asking for a review of the copyright stuff. If you ask me for co-maintaining one of your package, I might surely say no because I don't want to be involved in the long term, but on the contrary reviewing copyright stuff can be a one shot. Besides, there is no technical requirement to do this, not even to understand the build system or what the software is about.. This idea of a public reviewing page for NEWly uploaded packages really looked appealing to me. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Mass bugfiling in preparation for multiarch
Goswin von Brederlow goswin-...@web.de (17/03/2009): Aurelien Jarno aurel...@aurel32.net writes: I am interested in seeing the dpkg patch. The most current work should be on the multiarch alioth project. If you do work on something please add it there. http://alioth.debian.org/tracker/index.php?func=detailaid=310911group_id=30462atid=411196 It is not as complete as it once was but against the most recent source and with some previous mistakes corrected. I guess (at least in dpkg's case), having a git branch somewhere might help WRT possible inclusion, rather than a patch in an obscure ticket system? :) Mraw, KiBi. signature.asc Description: Digital signature
Re: net-tools future
On Fri, Mar 20, 2009 at 12:14:53PM +0100, Marco d'Itri wrote:
On Mar 20, Adam Borowski kilob...@angband.pl wrote:
trouble for embedded or limited ones. I don't do embedded personally so I
have no idea how udev fares there, but I can tell you that vservers and udev
don't go well together. Udev expects a real system where there's none and
then gets confused -- vserver is hardly more than a glorified chroot, nearly
identical to BSD jails. You want every container to be small and simple.
This is why you install udev in the host system and bind-mount its /dev
to the /dev of each context.
Definitely wrong.
Only a tiny sliver of devices are accessible from inside a context, and
making others accessible would be bad. Even root can't create forbidden
devices from inside...
vserver and openvz are not relevant for the purpose of this discussion.
They have their specific needs, and the last time I checked, udev couldn't
fulfill them. You need just /dev/{null,zero,full,random,urandom,tty,ptmx}
and the links to /proc/. More may be needed, but that depends on the
context's capabilities rather than on modules being present. A vserver may
have /dev/kqemu, /dev/fuse, /dev/net/tun, ...
On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote:
popcon shows that the number is trivial. Definitely not many.
Perhaps sysadmins that go to the effort of removing udev from
some systems are less likely to install popcon on those systems?
And surely lurkers agree with you in personal emails...
If you insist on popcon being installed on such systems, I may arrange a
bunch. I'm not sure if Debian would be well-served by a slew popcon
submissions of: (minimal+bind), (minimal+apache+mod_perl), (minimal+...),
though.
Rawr?!?
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
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
On Fri, Mar 20, 2009 at 01:07:44PM +0100, Josselin Mouette wrote: Le vendredi 20 mars 2009 à 13:02 +0100, Romain Beauxis a écrit : Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit : Fine. Do you have co-maintainers on sale? It is not about co-maintaining, but about co-reviewing which is a totally different task. Do you really think we can find an unlimited amount of volunteers willing to continuously read thousands of files to find the list of copyright holders? Nobody said anything about needing an unlimited amount of collaborators. However, it is required that we check every single file we upload to the Debian archives, so this task has to be done in some form or another. If you feel like your current packages are too much effort, maybe you should look for collaborators on them to ease the ask. If we cannot do this simple thing, maybe we shouldn't be distributing software. -- 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
On Mar 20, Adam Borowski kilob...@angband.pl wrote:
They have their specific needs, and the last time I checked, udev couldn't
fulfill them. You need just /dev/{null,zero,full,random,urandom,tty,ptmx}
and the links to /proc/. More may be needed, but that depends on the
You keep missing the point. udev matters in the host system, not in each
context. You will also not install in the contexts SANE or alsa-base or
kvm or Gnome.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 12:20:14PM +, Noah Slater nsla...@tumbolia.org wrote: On Fri, Mar 20, 2009 at 01:07:44PM +0100, Josselin Mouette wrote: Le vendredi 20 mars 2009 à 13:02 +0100, Romain Beauxis a écrit : Le Friday 20 March 2009 12:55:05 Josselin Mouette, vous avez écrit : Fine. Do you have co-maintainers on sale? It is not about co-maintaining, but about co-reviewing which is a totally different task. Do you really think we can find an unlimited amount of volunteers willing to continuously read thousands of files to find the list of copyright holders? Nobody said anything about needing an unlimited amount of collaborators. However, it is required that we check every single file we upload to the Debian archives, so this task has to be done in some form or another. If you feel like your current packages are too much effort, maybe you should look for collaborators on them to ease the ask. Do you know how many calls for help have been thrown on the BTS, debian-devel and other places for mozilla, kde, openoffice and other big packages ? We, big-packages maintainers, are still waiting for collaborators... Sometimes, I wonder if the only way for that to happen wouldn't be to stop updating the package at all. (and apparently, it, sadly, kind of worked with iceape, though I still have to contact the volunteer) 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
On Fri, Mar 20, 2009 at 01:24:01PM +0100, Romain Beauxis to...@rastageeks.org wrote: Le Friday 20 March 2009 13:07:44 Josselin Mouette, vous avez écrit : It is not about co-maintaining, but about co-reviewing which is a totally different task. Do you really think we can find an unlimited amount of volunteers willing to continuously read thousands of files to find the list of copyright holders? I mean that asking for co-mainenance is a different thing than asking for a review of the copyright stuff. If you ask me for co-maintaining one of your package, I might surely say no because I don't want to be involved in the long term, but on the contrary reviewing copyright stuff can be a one shot. Besides, there is no technical requirement to do this, not even to understand the build system or what the software is about.. This idea of a public reviewing page for NEWly uploaded packages really looked appealing to me. On the other hand, when you look at projets such as Mozilla or Webkit, there are people already doing that upstream, or ensuring things are done properly at commit time. Why should we duplicate that effort, especially considering how much work it represents for teams that are already undermanned. Mike -- 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
On Fri, Mar 20, 2009 at 01:03:32PM +0100, Marco d'Itri wrote:
On Mar 20, Adam Borowski kilob...@angband.pl wrote:
They have their specific needs, and the last time I checked, udev couldn't
fulfill them. You need just /dev/{null,zero,full,random,urandom,tty,ptmx}
and the links to /proc/. More may be needed, but that depends on the
You keep missing the point. udev matters in the host system, not in each
context.
Do you mean the original point of this thread, about ifrename (which indeed
can't be used inside vserver or openvz, can be in xen)? Or do you mean
other uses of udev?
You will also not install in the contexts SANE
Probably.
or alsa-base
Right.
or kvm
That's pretty useful. I used to run qemu from a vserver.
or Gnome.
I have Gnome installed on a sid vserver, used it no farther than a couple of
days ago to test something.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
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
Le Friday 20 March 2009 14:18:22 Mike Hommey, vous avez écrit : This idea of a public reviewing page for NEWly uploaded packages really looked appealing to me. On the other hand, when you look at projets such as Mozilla or Webkit, there are people already doing that upstream, or ensuring things are done properly at commit time. Why should we duplicate that effort, especially considering how much work it represents for teams that are already undermanned. I don't mean duplicate work. To me, the essence of copyright reviewing remains in the level of trust that you put in the guys that did the job. If you think your upstream is doing this seriously, then it could be fine. But, more generaly, when dealing with trust, the only suitable way to pretend that you are seriously adressing an issue is to have a process which is openly reviewable. You do not pretend that each interested collaborator is going review it any time, but you publicaly challenge anyone to check your work. At least that is how I understand we will not hide our issues. Why shouldn't this work also for copyright reviewing in debian packages ? If you think of it, when people commit a patch to a project, it is acked by some guys and then considered as reviewed. That is also how it works in my work (research) when we publish papers. Why couldn't it exists a public page for reviewing copyright, for which interested developpers could send a signed ACK claiming they have reviewed the copyright file and that it is ok for them (or not...), including the ftpmasters themselves. This could of course be mitigated by some degree of trust, like considering that ftpmasters are more reliable in checking details for a particular uncommon license. But for the vast majority of packages, this would be sufficent to decide on the acceptation or not of a NEW package. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: User and groups justification (was Re: group nvram)
On Fri, Mar 20, 2009 at 1:13 PM, Jon Dowland jon+debian-de...@alcopop.org wrote: On Thu, Mar 19, 2009 at 12:34:44AM +0100, Bastien ROUCARIES wrote: On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello l...@pca.it wrote: I would prefer any new information to be added there instead, since the files above are available offline as well. Does not forbid to add to wiki in order to ease writing :) I agree we should sync the offline file. If you do so please bear in mind that doc/* in the base-passwd package is licensed GPL-2 and Debian wiki pages have no automatic explicit copyright exceptions (i.e. default to all rights reserved). See http://wiki.debian.org/Maintainers for an example of how to specify an explicit license for a new page (and the linked http://wiki.debian.org/DebianWiki/LicencingTerms for context and history) Done. Thank you Bastien -- 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
On Mar 20, Adam Borowski kilob...@angband.pl wrote: You keep missing the point. udev matters in the host system, not in each context. Do you mean the original point of this thread, about ifrename (which indeed can't be used inside vserver or openvz, can be in xen)? Or do you mean other uses of udev? About udev in general. I have Gnome installed on a sid vserver, used it no farther than a couple of days ago to test something. Then you had to have udev installed, because it's a dependency of gnome-volume-manager. -- ciao, Marco signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 11:11:20AM +, Noah Slater nsla...@tumbolia.org wrote: On Fri, Mar 20, 2009 at 07:46:11AM +0100, Mike Hommey wrote: In shorter words: I think something should be done about the copyright file to encourage developers to actually perform an audit of the license status of files in their packages before they upload. The current copyright template doesn't really encourage this; I like the machine-parseable system because it makes it easy to organize such an audit. Try doing that on iceweasel or xulrunner. Hint: there are about 3 files and a real lot of copyright holders. It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. If you don't stop writing crap like this, I really think I *will* stop maintaining these packages. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFC: Better formatting for long descriptions
Hi, 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. This leaves a lot of freedom to simulate for instance itemize lists. I'd like to give some examples for package names starting with 'a' and stopped with the first package names of 'b'. If you are bored by these examples continue reading below the -- line. 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) Package: acidlab ... o Alert management by providing constructs to logically group alerts to create incidents (alert groups), deleting the handled alerts or false positives, exporting to email for collaboration, or archiving of alerts to transfer them between alert databases. . o Chart and statistic generation based on time, sensor, signature, protocol, IP address, TCP/UDP ports . ACID has the ability to analyze a wide variety of events which are post-processed into its database. Tools exist for the following formats: . o using Snort (www.snort.org) - Snort alerts - tcpdump binary logs o using logsnorter (www.snort.org/downloads/logsnorter-0.2.tar.gz) - Cisco PIX - ipchains -- atempt to emulate a two level itemize list == The upper part has only one space which is most probably not intended. Package: addresses-goodies-for-gnustep adgnumailconverter A tool that will merge your GNUMail address book into the Addresses database. adserver A stand-alone Addresses network server. adtool A command-line tool for address database manipulation. -- atempt to simulate a description list Package: airport-utils For the original Apple AirPort and the Lucent RG-1000 base stations only: - airport-config: base station configurator - airport-linkmon: wireless link monitor, gives information on the wireless link quality between the base station and the associated hosts . For the Apple AirPort Extreme base stations only: - airport2-config: base station configurator - airport2-portinspector: port maps monitor - airport2-ipinspector: WAN interface monitoring utility . For all: - airport-modem: modem control utility, displays modem state, starts/stops modem connections, displays the approximate connection time (Extreme only) - airport-hostmon: wireless hosts monitor, lists wireless hosts connected to the base station (see airport2-portinspector for the Snow) -- sometimes two sometimes three spaces, broken indentation for continued lines Package: alsa-utils o amixer: command line mixer o alsamixer: curses mixer -- third type of marker (we had '*' and '-') Package: altermime * Insert disclaimers * Insert arbitrary X-headers four spaces Package: amanda-client Features: ^^ useless verbose * will back up multiple machines in parallel to a holding disk, blasting finished dumps one by one to tape as fast as we can write files to tape. For example, a ~2 Gb 8mm tape on a ~240K/s interface to a host with a large holding disk can be filled by Amanda in under 4 hours. * built on top of standard backup software: Unix dump/restore, and later GNU Tar and others. ^^^ three spaces Package: amaya - eXtensible HyperText Markup Language (XHTML) - Scalable Vector Graphics (SVG) - Math Markup Language (MathML) - Cascading Style Sheets (CSS) a lot of spaces Package: amrita * The template for amrita is a pure html/xhtml document without special tags like ?...? or % .. % * The template can be written by designers using almost any html editor. ^^^ continued line with 3 spaces instead of four as it would look nicer Package: amsynth * two analogue-style audio oscillators, featuring: o sine wave o saw/triangle wave with adjustable shape o square/pulse wave with adjustable pulsewidth o noise generation o random wave (noise with sample hold) o oscillator sync o of course, detune and range control * mixer section with ring modulation -- another atempt to simulate two level itemizing Package: aoetools * aoecfg - manipulate AoE configuration strings * aoe-discover - trigger discovery of ATA over Ethernet devices * aoe-flush - flush the down devices out of the aoe driver -- a description list simulated as itemize + formating Package: aolserver4-doc (1) The AOLserver Administrator's Guide covers the setup options and security issues relating to running the server. (2) The AOLserver Tcl Developer's Guide covers the Tcl API which can be used to add features to your web pages (similar in some respects to PHP or Microsoft's ASP) ^^
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote: It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. If you don't stop writing crap like this, I really think I *will* stop maintaining these packages. I don't see what your problem is. If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. The focus here should be on producing quality software, with a rigorous and open process, so that people can be confident that what we're shipping is totally free software. Cutting corners to save a bit of time, simply because a package is large, does not seem to fit well with this goal. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. 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
Please Improve Debian for Multimedia Production
Hi, Since a while I'm pretty active in using Debian/Linux for Multimedia production, especially focusing on music production (check www.linuxmusicians.com for instance). Debian is a great system to use for this. Unfortunately there are nice music production applications which are not in Debian yet or are pretty outdated (also those in unstable). It would be nice if we could improve Debian for multimedia production and package more multimedia packages and keep them up to date. For instance, I posted some apps which are not in Debian right now as wishes (RFP): http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com (There is work on progress on Frescobaldi, Rumor (my first Debian package ;) ) and Gtklick.) Of course we have the Debian Multimedia Team, which takes care of a lot of multimedia packages for Debian. So if you like to help in this progress, the best thing you could do imo is joining the Debian Multimedia Team: http://wiki.debian.org/DebianMultimedia http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers Thanks in advance, \r ps: I'm not an official member of the Debian Multimedia Team myself. I'm just a musician which uses Debian now, but I think I'm gonna join the team myself. I recently build my first Debian package :), so I'm almost ready to join ;) -- 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
also sprach Andreas Tille til...@rki.de [2009.03.20.1445 +0100]: 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. This leaves a lot of freedom to simulate for instance itemize lists. I'd like to give some examples for package names starting with 'a' and stopped with the first package names of 'b'. If you are bored by these examples continue reading below the -- line. What we really should do, instead of clinging to the NIH-behaviour, reinventing the wheel, and polishing it over and over again is ditch the pseudo-RFC822 format we have and use Yaml instead. http://www.yaml.org/start.html http://yaml.org/spec/1.2/ -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems den stil verbessern, das heißt den gedanken verbessern. - friedrich nietzsche digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 02:02:31PM +, Noah Slater nsla...@tumbolia.org wrote: On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote: It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. If you don't stop writing crap like this, I really think I *will* stop maintaining these packages. I don't see what your problem is. If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. The focus here should be on producing quality software, with a rigorous and open process, so that people can be confident that what we're shipping is totally free software. Cutting corners to save a bit of time, simply because a package is large, does not seem to fit well with this goal. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. No, look at the text I quoted : you suggested to maintain a different package. Now, as I said earlier in this thread, there have been several calls for help on those big packages that *are* a problem to do the scan you would like to see on all packages, yet, nobody joined teams as a result. Following your advice, we should stop maintaining openoffice, iceweasel, xulrunner, kde, and who knows what other packages because nobody cares enough to scan tens of thousands of source files for copyright holders. That does sound like a plan. 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
Le vendredi 20 mars 2009 à 14:02 +, Noah Slater a écrit : If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. The focus here should be on producing quality software, with a rigorous and open process, so that people can be confident that what we're shipping is totally free software. Cutting corners to save a bit of time, simply because a package is large, does not seem to fit well with this goal. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. What is your problem? Do you want to see whether Mike can become violent if you press him hard enough, or is it another kind of experiment? -- .''`. 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: Please Improve Debian for Multimedia Production
On Fri, 20 Mar 2009, Grammostola Rosea wrote: For instance, I posted some apps which are not in Debian right now as wishes (RFP): http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=rosea.grammost...@gmail.com (There is work on progress on Frescobaldi, Rumor (my first Debian package ;) ) and Gtklick.) Of course we have the Debian Multimedia Team, which takes care of a lot of multimedia packages for Debian. So if you like to help in this progress, the best thing you could do imo is joining the Debian Multimedia Team: http://wiki.debian.org/DebianMultimedia http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers 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]. ps: I'm not an official member of the Debian Multimedia Team myself. I'm just a musician which uses Debian now, but I think I'm gonna join the team myself. I recently build my first Debian package :), so I'm almost ready to join ;) Good luck for joining Andreas. [1] http://lists.debian.org/debian-devel-announce/2009/03/msg00013.html [2] 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: RFC: Better formatting for long descriptions
On Fri, 20 Mar 2009, martin f krafft wrote: What we really should do, instead of clinging to the NIH-behaviour, reinventing the wheel, and polishing it over and over again is ditch the pseudo-RFC822 format we have and use Yaml instead. http://www.yaml.org/start.html http://yaml.org/spec/1.2/ And most probably somebody else will revive the switch to XML suggestion. I know the pros and cons for different formats but I want a solution *now* and that's the reason why I wrote: 2. Does not break any existing tool 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
On Fri, Mar 20, 2009 at 02:37:44PM +0100, Marco d'Itri wrote: On Mar 20, Adam Borowski kilob...@angband.pl wrote: You keep missing the point. udev matters in the host system, not in each context. Do you mean the original point of this thread, about ifrename (which indeed can't be used inside vserver or openvz, can be in xen)? Or do you mean other uses of udev? About udev in general. udev is needed to allow for complex and/or hotplugged hardware. Small systems have either little, static hardware, or no hardware at all. I have Gnome installed on a sid vserver, used it no farther than a couple of days ago to test something. Then you had to have udev installed, because it's a dependency of gnome-volume-manager. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==-= pn udev none (no description available) Indeed, that's how I learned that udev breaks vservers. That's in a good part my fault, I installed the whole bulk of Gnome without trimming things utterly useless on a headless box. gnome-volume-manager has no place there. But, let's return to the original claim which I disagree with: Every relevant Linux distribution requires udev, and so do many important features of Debian systems. Anything not compatible with udev is a toy which wastes space in the archive. Welcome to 2008. I can agree that there's no need to support _hardware-related_ things which are incompatible with udev. Yet, pieces of Debian which do not need to talk to hardware directly (ie, 95% of the archive) should not require udev. I also say that systems without udev installed are legitimate. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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
On Fri, 20 Mar 2009, Noah Slater wrote: On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote: It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. If you don't stop writing crap like this, I really think I *will* stop maintaining these packages. I don't see what your problem is. You are requesting work from other volunteers and it's bad taste to do so. If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. Those checks have not always been part of the requirements. And I'm not convinced they are always needed. We should document the various licenses used in the source package, we should maybe also document the default license for new code added upstream but I don't see the point of collecting a list of copyright holders and keeping it up-to-date. We should be able to trust by default upstream authors on the license claim, maintainers should be encouraged to audit their packages when possible but we should not blame them for not having it done. After all we have ftpmasters who are doing it anyway. Of course, if you know you have a bad upstream you might want to be more careful than one that is very strict in its patch integration policy. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 03:13:29PM +0100, Mike Hommey wrote: No, look at the text I quoted : you suggested to maintain a different package. Yes, out of several emails I sent to the list, you selected a single sentence. I apologise if you got the wrong message from what I had written, it was not meant as a personal attack. On the other hand, saying that maintaining packages can be time consuming seems like such an obvious thing, I wonder why people are bringing it up - unless they mean to suggest that we should cut corners when rigorously checking free software made available for distribution. Now, as I said earlier in this thread, there have been several calls for help on those big packages that *are* a problem to do the scan you would like to see on all packages, yet, nobody joined teams as a result. I appreciate the difficulties you might be experiencing here. The distinction I was trying to draw is that this matter is totally unrelated to the copyright documentation we keep in the packages. Considering that it is already our mandate to check every single file, this is already a problem for you. Sure, you have a lot to deal with, and finding collaborators is hard, but using this as a flimsy reason to disregard the copyright proposal seems absurd. Following your advice, we should stop maintaining openoffice, iceweasel, xulrunner, kde, and who knows what other packages because nobody cares enough to scan tens of thousands of source files for copyright holders. You selectively chose one thing I had written, please don't do that. 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
On Fri, Mar 20, 2009 at 03:14:36PM +0100, Josselin Mouette wrote: Le vendredi 20 mars 2009 à 14:02 +, Noah Slater a écrit : If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. The focus here should be on producing quality software, with a rigorous and open process, so that people can be confident that what we're shipping is totally free software. Cutting corners to save a bit of time, simply because a package is large, does not seem to fit well with this goal. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. What is your problem? Do you want to see whether Mike can become violent if you press him hard enough, or is it another kind of experiment? Why do you find it necessary to be so aggressive with me? I fail to see which part of my argument you think is inflammatory or ridiculous: * It is already your responsibility as a Debian package maintainer to thoroughly check each and every file for copyright and licensing issues. * If you maintain a large package, this must already be a burden for you. * Documenting this process in a text file does not seem like much extra work. * Complaining that you would have to check every single file implies that you don't already check every single file, which you should be doing. * Therefor, complaining that this is hard work and collaborators are hard to come by, seems like a completely orthogonal issue to the copyright proposal. This doesn't mean that I am doubting how much work the bigger packages are, or that it isn't hard finding collaborators. I have a lot of respect for the people who offer there time to get this job done. On the other hand, this rationally has nothing to do with the copyright proposal, presuming that everyone is already following policy. 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
Mike Hommey m...@glandium.org writes: On Fri, Mar 20, 2009 at 12:20:14PM +, Noah Slater nsla...@tumbolia.org wrote: However, it is required that we check every single file we upload to the Debian archives, so this task has to be done in some form or another. If you feel like your current packages are too much effort, maybe you should look for collaborators on them to ease the ask. Do you know how many calls for help have been thrown on the BTS, debian-devel and other places for mozilla, kde, openoffice and other big packages ? We, big-packages maintainers, are still waiting for collaborators... Noah Slater nsla...@tumbolia.org writes: I don't see what your problem is. It seems that the problem is that “look for collaborators” is what they're already doing, without apparent impact on the problem at hand (the workload involved in copyright auuditing of the package), so presenting it as a novel course of action isn't helpful. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. That doesn't appear to be in dispute at all. Yet, by Mike's account, these packages continue to lack sufficient collaborators. -- \ “All progress has resulted from people who took unpopular | `\ positions.” —Adlai Stevenson | _o__) | Ben Finney -- 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
Twas brillig at 15:30:11 20.03.2009 UTC+01 when kilob...@angband.pl did gyre and gimble: AB udev is needed to allow for complex and/or hotplugged hardware. AB Small systems have either little, static hardware, Small systems nowadays have a lot of hotplugged hardware: various USB devices, from mass storage to printers, SD and other storage cards. AB or no hardware at all. :) -- pgpFyhR31wSQ4.pgp Description: PGP signature
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 03:35:22PM +0100, Raphael Hertzog wrote: On Fri, 20 Mar 2009, Noah Slater wrote: On Fri, Mar 20, 2009 at 02:41:31PM +0100, Mike Hommey wrote: It behoves us as distributors to check, no matter how hard it is. If you think that sounds like too much work, maintain a different package. If you don't stop writing crap like this, I really think I *will* stop maintaining these packages. I don't see what your problem is. You are requesting work from other volunteers and it's bad taste to do so. I accept your point, but I think that this is a bad framing. People have been complaining about the copyright proposal costing too much time. Aside from pointing out that this is presumably time you were already spending checking each file, a good solution is collaborative maintenance. Not sure what else you expect someone to respond with apart from throwing their hands up and conceding that we should adopt policy to conform with peoples wish to avoid additional work. -- 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
On Fri, Mar 20, 2009 at 02:35:34PM +, Noah Slater nsla...@tumbolia.org wrote: On Fri, Mar 20, 2009 at 03:13:29PM +0100, Mike Hommey wrote: No, look at the text I quoted : you suggested to maintain a different package. Yes, out of several emails I sent to the list, you selected a single sentence. That you actually felt stroing enough to type twice, which pissed me off. See 20090320111658.gd7...@tumbolia.org if you don't remember suggesting to maintain a different package. 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
On Sat, Mar 21, 2009 at 01:46:51AM +1100, Ben Finney wrote: I don't see what your problem is. It seems that the problem is that “look for collaborators” is what they're already doing, without apparent impact on the problem at hand (the workload involved in copyright auuditing of the package), so presenting it as a novel course of action isn't helpful. Well, that is great then. Obviously, I was not aware of this. My argument still stands though. This has nothing to do with the new copyright proposal. All this proposal does is cement what is already policy, and what packagers should already be doing. If the community thinks that policy is at fault, this should be discussed as a separate matter. As it stands, I see that people are effectively arguing that the copyright proposal should be abandoned because it is enforcing an aspect of policy that people don't wish to follow. All I am doing is suggesting that either we throw out this argument, or fix the policy. -- 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
On Fri, Mar 20, 2009 at 02:40:18PM +, Noah Slater nsla...@tumbolia.org wrote: On Fri, Mar 20, 2009 at 03:14:36PM +0100, Josselin Mouette wrote: Le vendredi 20 mars 2009 à 14:02 +, Noah Slater a écrit : If we were suggesting some totally arbitrary and time consuming task, then I could understand your concerns. However, you should be checking each file as a part of your packaging, all that is being requested is that you document this for the FTP masters and our users. The focus here should be on producing quality software, with a rigorous and open process, so that people can be confident that what we're shipping is totally free software. Cutting corners to save a bit of time, simply because a package is large, does not seem to fit well with this goal. Hence my suggestion that if a package you are maintaining seems like too much work, perhaps it would make sense to collaboratively maintain it. What is your problem? Do you want to see whether Mike can become violent if you press him hard enough, or is it another kind of experiment? Why do you find it necessary to be so aggressive with me? I fail to see which part of my argument you think is inflammatory or ridiculous: * It is already your responsibility as a Debian package maintainer to thoroughly check each and every file for copyright and licensing issues. * If you maintain a large package, this must already be a burden for you. * Documenting this process in a text file does not seem like much extra work. * Complaining that you would have to check every single file implies that you don't already check every single file, which you should be doing. If all the above were true, no package of xulrunner, iceweasel, openoffice, kde and others would have *EVER* entered the archive, since there has *NEVER* been such work done on these packages, and until this funky new copyright showed up, that did bother *NOONE*, including the ftpmasters. * Therefor, complaining that this is hard work and collaborators are hard to come by, seems like a completely orthogonal issue to the copyright proposal. If you want those copyright files to be thourough, I invite you to download one of the packages above's source, and start checking those tens of thousands of files. See you in three months to see where you are at it, and throw you some more new upstream releases. This doesn't mean that I am doubting how much work the bigger packages are, or that it isn't hard finding collaborators. I have a lot of respect for the people who offer there time to get this job done. On the other hand, this rationally has nothing to do with the copyright proposal, presuming that everyone is already following policy. It has all to do with it, since you are suggesting that the copyright proposal is sane even for big packages, changes nothing to the current status quo, which, as I said above is far from being true, and that $SOMEPEOPLE should do their homework or move to other packages. 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
On Fri, Mar 20, 2009 at 02:59:35PM +, Noah Slater nsla...@tumbolia.org wrote: On Sat, Mar 21, 2009 at 01:46:51AM +1100, Ben Finney wrote: I don't see what your problem is. It seems that the problem is that “look for collaborators” is what they're already doing, without apparent impact on the problem at hand (the workload involved in copyright auuditing of the package), so presenting it as a novel course of action isn't helpful. Well, that is great then. Obviously, I was not aware of this. My argument still stands though. This has nothing to do with the new copyright proposal. All this proposal does is cement what is already policy, and what packagers should already be doing. If the community thinks that policy is at fault, this should be discussed as a separate matter. As it stands, I see that people are effectively arguing that the copyright proposal should be abandoned because it is enforcing an aspect of policy that people don't wish to follow. All I am doing is suggesting that either we throw out this argument, or fix the policy. Point me to the paragraph in the policy that says that the copyright file must list all copyright holders and licensing info for all individual files in the source package. Let me help you: there is no such paragraph. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: Please Improve Debian for Multimedia Production
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: http://qa.debian.org/developer.php?login=pkg-multimedia-maintainers%40lists.alioth.debian.org Have a nice weekend, Fabian -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: svn-buildpackage's future
Hi again, Obey Arthur Liu suggested to have this svn-bp re-engineering as a Google Summer of Code project. I'm not sure if it's big enough to employ a student for such a long time. I'd like to see comments on this, too. Hauke signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
On Fri, Mar 20 2009, Noah Slater wrote: No one is saying it isn't a chore. As a maintainer, it is your duty to make sure that everything you upload is DFSG free, which means checking every single file. As you have to do this anyway, it makes sense to record that information in debian/copyright. If you maintain a very large package, then you should *expect* this to take a long time. I don't care for copyright notices, really. I care for license statements; and I take the upstream on trust that the license attached to the work is valid (since it is hard to determine every copyright holder -- people who have contributed more than, say, 10 lines of code, unless we trust the upstream to mention them). Even otherwise, I would find recording the names in the copyright notices a partial rendering, irrelevant in a copyright challenge, and too much work for what it is worth. If that's too much effort for your, get a co-maintainer or a different package. Frankly, for such lack of collegiality, one could arguably suggest you seek another project, neh? However, to keep this civil, I will just say: Patches welcome, as long as they come with a verification toll as well. In the meanwhile, I'll record Licenses and file to which they apply, and copyright holders will be opportunistically captured. manoj -- [Babe] Ruth made a big mistake when he gave up pitching. Tris Speaker, 1921 Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 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
On Fri, Mar 20, 2009 at 03:55:30PM +0100, Mike Hommey wrote: That you actually felt stroing enough to type twice, which pissed me off. See 20090320111658.gd7...@tumbolia.org if you don't remember suggesting to maintain a different package. Well, there are only three solutions, and I have suggested them all. If you find the current work a burden, you could maintain a different package, try to find collaborators, or lobby to get policy changed. I wasn't suggesting any were preferable, or that you hadn't tried. I really don't care either way. My goal was to draw the focus away from the copyright proposal, which is only codifying existing policy. 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
On Fri, Mar 20, 2009 at 04:01:56PM +0100, Mike Hommey wrote: * Complaining that you would have to check every single file implies that you don't already check every single file, which you should be doing. If all the above were true, no package of xulrunner, iceweasel, openoffice, kde and others would have *EVER* entered the archive, since there has *NEVER* been such work done on these packages, and until this funky new copyright showed up, that did bother *NOONE*, including the ftpmasters. [...] If you want those copyright files to be thourough, I invite you to download one of the packages above's source, and start checking those tens of thousands of files. See you in three months to see where you are at it, and throw you some more new upstream releases. This doesn't mean that I am doubting how much work the bigger packages are, or that it isn't hard finding collaborators. I have a lot of respect for the people who offer there time to get this job done. On the other hand, this rationally has nothing to do with the copyright proposal, presuming that everyone is already following policy. It has all to do with it, since you are suggesting that the copyright proposal is sane even for big packages, changes nothing to the current status quo, which, as I said above is far from being true, and that $SOMEPEOPLE should do their homework or move to other packages. Actually, the copyright proposal is just a text format, not a policy document. If you're telling me that the FTP masters would be happy with blanket license statements for a package, what is stopping you from using the existing format to say something along the lines of: Files: * Copyright: Copyright 2008, Damien Katz dam...@apache.org Copyright 2008, Jan Lehnardt j...@apache.org Copyright 2008, Christopher Lenz cml...@apache.org Copyright 2008, Noah Slater nsla...@apache.org License: Apache-2.0 On Debian systems the full text of the Apache License (Version 2) can be found in the `/usr/share/common-licenses/Apache-2.0' file. Note, this is an actual snipped from the couchdb package. 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
On Fri, Mar 20, 2009 at 04:12:37PM +0100, Mike Hommey wrote: Point me to the paragraph in the policy that says that the copyright file must list all copyright holders and licensing info for all individual files in the source package. Let me help you: there is no such paragraph. So what on earth has this to do with the copyright proposal? If you wish to make blanket statements using the copyright proposal, what is stopping you? All we wanted to do is develop a format so that copyright information was both machine and human readable. If the FTP masters are happy with your current work, there should be no reason why you can't express what you are already doing with the new copyright proposal. 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: Re: Please Improve Debian for Multimedia Production
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 Overly simplifying, you get something like this: http://debian-med.alioth.debian.org/tasks/imaging.html instead of: http://qa.debian.org/developer.php?login=pkg-multimedia-maintainers%40lists.alioth.debian.org ;-) Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- 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
On Fri, Mar 20, 2009 at 11:13:45PM +1100, Ben Finney wrote: m...@linux.it (Marco d'Itri) writes: On Mar 20, Mike Bird mgb-deb...@yosemite.net wrote: popcon shows that the number is trivial. Definitely not many. Perhaps sysadmins that go to the effort of removing udev from some systems are less likely to install popcon on those systems? And surely lurkers agree with you in personal emails... Marco, it was you that cited absence of evidence (the low popcon score) as evidence of absence. You don't get to accuse Adam of doing the same, especially since he's not doing it. I think he gets to accuse Mike Bird of anything he wants to. I accuse Mike Bird of being a dolomite. -- 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: Bits from the Debian Pure Blends Team
On Fri, 20 Mar 2009 14:40:24 +0100 (CET) Andreas Tille til...@rki.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as you might have noticed the effort formerly known as Custom Debian Distributions was renamed to Debian Pure Blends (see [1] for the reasons). This process is now regarded as finished. The Alioth project was moved to http://alioth.debian.org/projects/debian-blends This link reports 'Invalid Project' -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org signature.asc Description: PGP signature
Re: RFC: Better formatting for long descriptions
On Fri, Mar 20, 2009 at 02:45:09PM +0100, Andreas Tille wrote: 1. Itemize lists: (li) 2. Enumerate lists: (ol) -- 3. Description lists: (dl) This suggestion is far from complete and should be enhanced. Well, not sure this should be over-engineered; I guess itemize lists already cover most of the cases (most enumerations could probably be changed to itemizations I guess). So a +1 from me. Michael -- 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
On Fri, Mar 20, 2009 at 12:20:39PM -0400, Daniel Dickinson wrote: On Fri, 20 Mar 2009 14:40:24 +0100 (CET) Andreas Tille til...@rki.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as you might have noticed the effort formerly known as Custom Debian Distributions was renamed to Debian Pure Blends (see [1] for the reasons). This process is now regarded as finished. The Alioth project was moved to http://alioth.debian.org/projects/debian-blends This link reports 'Invalid Project' The correct one is http://alioth.debian.org/projects/blends Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: svn-buildpackage's future
On Fri, Mar 20, 2009 at 04:54:30PM +0100, Jan Hauke Rahm wrote: Obey Arthur Liu suggested to have this svn-bp re-engineering as a Google Summer of Code project. I'm not sure if it's big enough to employ a student for such a long time. I think it's a worthy goal in the spirit of GSoC. Whether or not it is too small I cannot judge, but my first reaction would be that it's fine. Maybe wait what students propose exactly and then review whether that's feasable or not. Michael -- 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
On Fri, Mar 20, 2009 at 03:18:33PM +, Noah Slater wrote: On Fri, Mar 20, 2009 at 04:12:37PM +0100, Mike Hommey wrote: Point me to the paragraph in the policy that says that the copyright file must list all copyright holders and licensing info for all individual files in the source package. Let me help you: there is no such paragraph. So what on earth has this to do with the copyright proposal? I guess people think the new copyright proposal mandates mentioning the copyright holders etc. in a much more verbose way than Policy does so far. So people consider it a regression with respect to their routine. disclaimer: I have not reviewed the new copyright proposal. Michael -- 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
Quoting Daniel Dickinson (csh...@brucetelecom.com): On Fri, 20 Mar 2009 14:40:24 +0100 (CET) Andreas Tille til...@rki.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as you might have noticed the effort formerly known as Custom Debian Distributions was renamed to Debian Pure Blends (see [1] for the reasons). This process is now regarded as finished. The Alioth project was moved to http://alioth.debian.org/projects/debian-blends This link reports 'Invalid Project' Correct link appears to be: http://alioth.debian.org/projects/blends/ -- Cheers, Crypto lets someone say Hi! I absolutely definitely have Rick Moena name somewhat like the name of a large familiar r...@linuxmafia.com organization, and I'd like to steal your data! and lots McQ! (4x80) of users will say OK, fine, whatever.-- John Levine signature.asc Description: Digital signature
Re: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 05:45:11PM +0100, Michael Banck wrote: I guess people think the new copyright proposal mandates mentioning the copyright holders etc. in a much more verbose way than Policy does so far. So people consider it a regression with respect to their routine. Great, so it seems we have made progress! If the consensus is that broad-brush copyright information is suitable for Debian, we should make it clear in the copyright proposal that people are free to make that judgement call. I apologise if I came across as too aggressive, I was only disheartened by what seemed to be a conflation of separate issues. I see the copyright proposal as a format, not policy, document. If people want to formalise the granularity of our copyright information, then so be it, but let's do that as a separate effort. 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
On Fri, Mar 20, 2009 at 02:35:34PM +, Noah Slater wrote: The distinction I was trying to draw is that this matter is totally unrelated to the copyright documentation we keep in the packages. Considering that it is already our mandate to check every single file, No, it isn't. On Fri, Mar 20, 2009 at 11:16:58AM +, Noah Slater wrote: As a maintainer, it is your duty to make sure that everything you upload is DFSG free, which means checking every single file. No, it doesn't. If I have a good upstream and am confident that the work has been correctly licensed, there's no reason for me to go through the software file-by-file just to double-check this. -- 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: Sponsorship requirements and copyright files
On Fri, Mar 20, 2009 at 09:56:39AM -0700, Steve Langasek wrote: No, it doesn't. If I have a good upstream and am confident that the work has been correctly licensed, there's no reason for me to go through the software file-by-file just to double-check this. As I have been corrected, so apologies are in order. However, there have been times when I have realised after some time that the copyright information in the upstream is woefully incomplete or inaccurate. I had similarly doing blanked declarations in debian/copyright which turned out to be wrong because I had not checked. When I found this, I sent the issue upstream: http://tinyurl.com/ctargs And I was fortunate that they did a massive overhaul and a re-release. 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
Le vendredi 20 mars 2009 à 10:39 -0500, Manoj Srivastava a écrit : I don't care for copyright notices, really. I care for license statements; and I take the upstream on trust that the license attached to the work is valid (since it is hard to determine every copyright holder -- people who have contributed more than, say, 10 lines of code, unless we trust the upstream to mention them). That is clearly the reasonable line to follow. However it has not been the line of FTP masters for at least a few months now. -- .''`. 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
[OT] net-tools future
On Fri March 20 2009 09:29:26 Steve Langasek wrote: On Fri, Mar 20, 2009 at 11:13:45PM +1100, Ben Finney wrote: Marco, it was you that cited absence of evidence (the low popcon score) as evidence of absence. You don't get to accuse Adam of doing the same, especially since he's not doing it. I think he gets to accuse Mike Bird of anything he wants to. I accuse Mike Bird of being a dolomite. Et tu Stevie? --Mike CaMg(CO3)2 Bird -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Revising Policy 12.5 (Copyright information)
Josselin Mouette j...@debian.org writes: Le vendredi 20 mars 2009 à 10:39 -0500, Manoj Srivastava a écrit : I don't care for copyright notices, really. I care for license statements; and I take the upstream on trust that the license attached to the work is valid (since it is hard to determine every copyright holder -- people who have contributed more than, say, 10 lines of code, unless we trust the upstream to mention them). That is clearly the reasonable line to follow. However it has not been the line of FTP masters for at least a few months now. Policy doesn't provide much guidance here. Currently, you could read Policy as saying that you have to reproduce all of the copyright notices from the source (or read it several other ways; it's not very specific). The requirements in the current REJECT FAQ are not in Policy and should be if that's what we're enforcing. Maybe the best resolution to this is to have a broader discussion that leads to a rewording of Policy 12.5 that makes the requirements explicit, with ftp-master buy-in on what the requirements are? Then we can all be on the same page and everyone will know what the requirements really are, whereas right now there's a lot of grey area. (For example, up until I started experimenting with the new copyright file format, I never documented the license or copyright information for any of the Autotools-generated files, and I never heard a peep of concern about that.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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)
Russ Allbery r...@debian.org writes: started experimenting with the new copyright file format, I never documented the license or copyright information for any of the Autotools-generated files, and I never heard a peep of concern about that.) Currently the ftpmasters don't require those copyrights to be listed in the debian/copyright. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- 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)
Romain Beauxis to...@rastageeks.org writes: Le Friday 20 March 2009 19:12:02 Russ Allbery, vous avez écrit : Maybe the best resolution to this is to have a broader discussion that leads to a rewording of Policy 12.5 that makes the requirements explicit, with ftp-master buy-in on what the requirements are? on the same page and everyone will know what the requirements really are, whereas right now there's a lot of grey area. But do you think this is possible ? Sure. Resolving this sort of thing is the point of the Policy process, after all, and we have a clear authority that does the enforcement (ftp-master), so it seems likely that we can reach a clear policy that we can document. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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)
Kalle Kivimaa kil...@debian.org writes: Russ Allbery r...@debian.org writes: started experimenting with the new copyright file format, I never documented the license or copyright information for any of the Autotools-generated files, and I never heard a peep of concern about that.) Currently the ftpmasters don't require those copyrights to be listed in the debian/copyright. I had a suspicion, but this is exactly the sort of thing that I'd like to have written down somewhere. (For example, I went and documented them since I wasn't sure whether it was a good thing to do or not, and I figured that while I was using the new copyright format, I should give it a fair shake and try using it literally as written, and there's nothing in it saying to skip those files.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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)
Le Friday 20 March 2009 19:38:34 Russ Allbery, vous avez écrit : But do you think this is possible ? Sure. Resolving this sort of thing is the point of the Policy process, after all, and we have a clear authority that does the enforcement (ftp-master), so it seems likely that we can reach a clear policy that we can document. Sorry, but there was also an argument below in my message. The point is that there are possibly a lot of corner cases, such as the autotools case, for which we can't really decide and list every single issue or produce a general rational. 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. Romain -- 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)
Le Friday 20 March 2009 19:12:02 Russ Allbery, vous avez écrit : Maybe the best resolution to this is to have a broader discussion that leads to a rewording of Policy 12.5 that makes the requirements explicit, with ftp-master buy-in on what the requirements are? on the same page and everyone will know what the requirements really are, whereas right now there's a lot of grey area. But do you think this is possible ? (For example, up until I started experimenting with the new copyright file format, I never documented the license or copyright information for any of the Autotools-generated files, and I never heard a peep of concern about that.) That's one of the grey corners. So far, my understanding is that they are not listed because they are only in the source tarball, and also autogenerated. The usual understanding seems that the licenses of these build scripts are documented in the corresponding auto* package and that should be sufficient. As for myself, I don't think we can reach a strict consensus through the policy, but more likely have some sort of case law that is publicaly discussed and settled. Much like the reject FAQ, but where we discuss the motivations all together. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Gratituous dependences among packages
At the encouragement of Luk Claes, I would like to raise this subject in the general mailing list. It has been my impression that when using aptitude and requesting to install/upgrade desktops (KDE, maybe also Gnome), several other packages, which don't interest me, are installed as well. They cause a bloat to the installation and longer upgrade times in the future. I agree with Luk that it is reasonable to recommend the installation of games, texlive-* and other goodies with packages like KDE and Gnome. My problem is that the desktop packages REQUIRE the cruft. Example: kde depends on kdegraphics (will be broken without this dependence) kdegraphics depends upon kdvi (will be broken without this dependence) kdvi depends upon some texlive-* packages So satisfying those dependences would pull in lots of texlive stuff, even if one has no need for TeX related files. My wish is that modularization of Debian packages be improved. It means that it'll be possible to uninstall all games in a PC and continue to have functioning KDE. Likewise - TeX. --- Omer On Fri, 2009-03-20 at 16:56 +0100, Luk Claes wrote: Omer Zak wrote: Some examples which I have for extraneous dependencies between packages: 1. KDE seems to be indirectly dependent upon all kinds of computer games. Well I guess it's quite natural for a desktop environment to include these games. Though feel free to discuss this on debian-devel. 2. There is a KDE package, which depends upon texlive-*, but an earlier version did not depend upon it. In a PC with Lenny Debian, I had to pin that package because of a problem I had with a texlive-* package. Are you sure it depends on it? It probably Recommends it and recommended package get installed by default. In future packages, I'd like to see all those extraneous dependences being turned off. Games should be installed only if people explicitly ask them. And texlive-* stuff should be installed only if a KDE user needs the relevant feature/s. I think you should discuss the texlive recommends with the package maintainer that Recommends them. While you might be right that it should be easy to install a desktop environment without games and other gratitous dependencies or recommends, I think the default of installing them is not bad. Though please discuss all this in the open on the debian-devel mailing list as there is not much we Release Managers can do about them. -- You haven't made an impact on the world before you caused a Debian release to be named after Snufkin. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- 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)
Romain Beauxis wrote: Le Friday 20 March 2009 19:38:34 Russ Allbery, vous avez écrit : But do you think this is possible ? Sure. Resolving this sort of thing is the point of the Policy process, after all, and we have a clear authority that does the enforcement (ftp-master), so it seems likely that we can reach a clear policy that we can document. Sorry, but there was also an argument below in my message. The point is that there are possibly a lot of corner cases, such as the autotools case, for which we can't really decide and list every single issue or produce a general rational. 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). signature.asc Description: OpenPGP digital signature
Re: Sponsorship requirements and copyright files
Le Friday 20 March 2009 15:54:14 Noah Slater, vous avez écrit : Not sure what else you expect someone to respond with apart from throwing their hands up and conceding that we should adopt policy to conform with peoples wish to avoid additional work. You know, if you get some agressive answers to your messages, it is because you are throwing a moral judgement on the people that do not follow your views. I strongly agree with them, I feel upset by this judgement. I do not consider myself as better than any other packager and I did mistakes when going through copyright and license check. And thank the ftpmaster for spotting some of them. You shouldn't insinuate such claims but try to understand why they think it is not reasonable. And it is not reasonable since all of this is about trust. If there were no trust between us, we wouldn't upload packages to a common pool nor release an OS. If there were no trust between us and our users, they would download and check themselves each and every package's sources for copyright and license compliance. What those people are telling you is that they proceed the same way with their upstream, and assume it is a serious statement from them when they claim for license and copyright. So, really, nothing about wanting to avoid additional work... Or else, you checked youself for source availability and license compliance of each and every free software you installed in your machine... Did you ? Romain -- 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
On Fri, 20 Mar 2009 14:45:09 +0100 (CET) Andreas Tille til...@rki.de 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. :-( This leaves a lot of freedom to simulate for instance itemize lists. I'd like to give some examples for package names starting with 'a' and stopped with the first package names of 'b'. If you are bored by these examples continue reading below the -- line. - I think we should try to implement some more strict formating rules to our long descriptions. Maybe starting with a way to provide extra long descriptions by some means *other* than Packages.gz - which in turn means maintainers deciding which bits of the long description *really* need to be visible before download and which can wait until the user has decided to download the package. 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? The rationale behind this is that with some better standard formating some tools which display descriptions on web pages might be enhanced to use li, ol and dl 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. 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? This suggestion is far from complete and should be enhanced. I think the entire suggestion should be redirected away from the Packages.gz file. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpv9i4UdL58G.pgp Description: PGP signature
Re: Revising Policy 12.5 (Copyright information)
Romain Beauxis to...@rastageeks.org writes: Sorry, but there was also an argument below in my message. The point is that there are possibly a lot of corner cases, such as the autotools case, for which we can't really decide and list every single issue or produce a general rational. 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. Oh, yes, I agree. However, I think Policy should say what to do about Autotools at least, since that's a very common case. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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
On Fri, 2009-03-20 at 19:03 +, Neil Williams wrote: On Fri, 20 Mar 2009 14:45:09 +0100 (CET) Andreas Tille til...@rki.de 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. :-( Yeah, I'm sure being consistent about whether we use 2 or 3 spaces for indented lists in descriptions is going to make that file a lot harder to compress. Cheers, Julien -- 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
Neil Williams wrote: On Fri, 20 Mar 2009 14:45:09 +0100 (CET) Andreas Tille til...@rki.de 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. :-( AFAICS he's not talking about lengthen the descriptions at all, but to standardize the way lists are formatted in long descriptions. That is, formalize whether we should be using 2 or 3 spaces, dashes or plus signs for items in the lists... Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Splitting of the gnome-python* source packages - MBF
Hi Joss, Josselin Mouette wrote: 1. GNOME-PYTHON I propose to file wishlist bugs on the packages that can move to using python-gconf. 2. GNOME-PYTHON-DESKTOP I propose to file important bugs on all packages depending on python-gnome2-desktop, making them RC once the package is removed (not until at least a few months, though). 3. GNOME-PYTHON-EXTRAS Bugs have already been filed for egg.trayicon, gtkhtml2 and gtkmozembed. I propose to complete them with gtkspell bugs and to make them important. They would become serious before the squeeze release. All sound good to me. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: RFC: Better formatting for long descriptions
On Fri, 20 Mar 2009 20:08:43 +0100 Julien Cristau jcris...@debian.org wrote: On Fri, 2009-03-20 at 19:03 +, Neil Williams wrote: On Fri, 20 Mar 2009 14:45:09 +0100 (CET) Andreas Tille til...@rki.de 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. :-( Yeah, I'm sure being consistent about whether we use 2 or 3 spaces for indented lists in descriptions is going to make that file a lot harder to compress. 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. If there is going to be discussion on standardising on some form of indentation, it's worth considering whether there isn't a better way of providing the data itself to achieve other benefits. Indents would need changes in all affected packages - it might be easier to provide a different means that also reduces the size of the Packages.gz file at the same time so that packages only need to be changed once. 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. Better can be construed to mean more - I merely want maintainers to consider whether better actually means less. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpvZrNsif0sW.pgp Description: PGP signature
Re: net-tools future
Martín Ferrari wrote: Hi, Hi In our call to move away from net-tools, I want to first start with identifying the packages that still use it: * ifconfig, route: the most difficult ones, both can be replaced by calls to ip, maybe except for some obscure options. * netstat : sstat provides almost the same information, just some formatting changes and parsing the command line Below a list of packages/maintainers that use ifconfig/route/netstat: Note that I divided them according the use of one or more of the tools (with what appear to be false positives at the end): ifconfig + route + netstat -- Simon Horman ho...@debian.org heartbeat pacemaker (U) Anibal Monsalve Salazar ani...@debian.org pacemaker ifconfig + route Achim Bohnet a...@mpe.mpg.de knemo (U) Bruno Barrera C. br...@debian.org portsentry Kanru Chen kos...@debian.org.tw tspc Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org knemo Thomas Goirand tho...@goirand.fr dtc Alberto Gonzalez Iniesta a...@inittab.org openvpn Mark Purcell m...@debian.org knemo (U) Petter Reinholdtsen p...@debian.org ifupdown (U) Al Stone a...@debian.org laptop-net Anthony Towns a...@debian.org ifupdown ifconfig + netstat -- Micah Anderson mi...@debian.org rkhunter (U) Daniel Baumann dan...@debian.org gnunet Christoph Berg m...@debian.org irssi-scripts Fathi Boudra f...@debian.org kvpnc (U) Marc 'HE' Brockschmidt h...@debian.org firehol (U) Kanru Chen kos...@debian.org.tw tspc Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org kvpnc Debian QA Group packa...@qa.debian.org ion3-scripts Matthew Palmer mpal...@debian.org facter (U) Javier Fernandez-Sanguino Pen~a j...@debian.org ifupdown-extra tiger Mark Purcell m...@debian.org kvpnc (U) Julien Valroff jul...@kirya.net rkhunter Jamie Wilkinson j...@debian.org facter facter (U) Alexander Wirt formo...@debian.org firehol netstat --- Joost van Baal joos...@debian.org systraq (U) Adam Conrad adcon...@0c3.net apache2 (U) Debian Apache Maintainers debian-apa...@lists.debian.org apache2 Mike Forbes m...@nothing.net.nz chkrootkit (U) Laurent Fousse laur...@komite.net systraq Turbo Fredriksson tu...@debian.org roxen4 Stefan Fritsch s...@debian.org apache2 (U) Wilmer van der Gaast wil...@gaast.net bitlbee Tollef Fog Heen tfh...@debian.org apache2 (U) Giuseppe Iuculano giuse...@iuculano.it chkrootkit Thom May t...@debian.org apache2 (U) Kari Pahula k...@debian.org tntnet Peter Samuelson pe...@p12n.org apache2 (U) Jelmer Vernooij jel...@samba.org bitlbee (U) ifconfig Debian Apache Maintainers debian-apa...@lists.debian.org apr Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libnet-arp-perl Stefan Fritsch s...@debian.org apr (U) Bdale Garbee bd...@gag.com bind9 (U) Tollef Fog Heen tfh...@debian.org apr (U) LaMont Jones lam...@debian.org bind9 Bastian Kleineidam cal...@debian.org fiaif Noèl Köthe n...@debian.org hammerhead Jonny Lamb jo...@debian.org synce-hal Andrew Lee and...@linux.org.tw lxnm Andrew McMillan deb...@mcmillan.net.nz whereami Ryan Niebur ryanrya...@gmail.com apr (U) Martin Peylo deb...@izac.de tipcutils Andrew Pollock apoll...@debian.org argus Peter Samuelson pe...@p12n.org apr (U) Guus Sliepen g...@debian.org ifenslave-2.6 Niko Tyni nt...@debian.org libnet-arp-perl (U) Gunnar Wolf gw...@debian.org libnet-arp-perl (U) false positive? --- Mirco Bauer mee...@debian.org xsp (U) Daniel Baumann dan...@debian.org gnunet-gtk gnunet-qt Marc 'HE' Brockschmidt h...@debian.org gnome-nettool (U) Kanru Chen kos...@debian.org.tw tspc Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gnome-nettool Debian Mono Group pkg-mono-gr...@lists.alioth.debian.org xsp Debian OLPC debian-olpc-de...@lists.alioth.debian.org sugar Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libnet-sip-perl Sebastian Dröge sl...@debian.org gnome-nettool (U) Martín Ferrari tin...@debian.org libnet-sip-perl (U) gregor herrmann gre...@debian.org libnet-sip-perl (U) Damyan Ivanov d...@debian.org libnet-sip-perl (U) Rene Mayorga rmayo...@debian.org libnet-sip-perl (U) Loic Minier l...@dooz.org gnome-nettool (U) Dylan R. E. Moonfire deb...@mfgames.com xsp (U) Josselin Mouette j...@debian.org gnome-nettool (U) Jose Luis Rivas ghostba...@gmail.com libnet-sip-perl (U) Jo Shields direct...@apebox.org xsp (U) Jonas Smedegaard d...@jones.dk sugar (U) Cheers Luk -- 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)
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 ? Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
