Re: Need for launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 18, 2006 at 03:47:15PM +0100, Reinhard Tartler wrote: On 1/17/06, Wouter Verhelst [EMAIL PROTECTED] wrote: As it is, to me, Ubuntu is just a group of people, some of which might have names[1]. I find it hard to work with such a thing; while I would love to work more closely with Ubuntu, the lack of personality is what's holding me back---and I'm afraid that telling me contact me, I'll forward it isn't going to change that. If you want a fast answer to a quick question, we are at #ubuntu-motu in freenode. Usually there is someone with an archive of dapper-changes who can look quickly who touched the package last, or you could check changelogs.ubuntu.com which holds changelog and copyright files of the packages. Hi Reinhard, are the changelogs on changelogs.ubuntu.com only from stable releases or do they include testing/dapper? Also, I was checking packages.ubuntu.com - - dapper - base utils-bash-view Debian changelog and it was a dead link. If the entries on changelogs.ubuntu.com contain the info that the 'view Debian changelog' should contain, why not set up a programatic way to have the links made. The 'view Debian changelog' entries for stable (and presumable stable - 1) seem to work. Cheers, Kev - -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDz0VLv8UcC1qRZVMRAitEAJ9diMGJj7R3tarjGGN3YfFS+tBGaACfQhqQ qTlhC5yw7TJ0c8rDlhp++iw= =6/fj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
[Thomas Bushnell BSG] Since you don't do bin-NMU's, you could simply alter the version of every package to add an ubuntu tag, and then be done with it, right? That would work well and be very easy to implement. You are so hung up on this point, it's not even funny. Do you really think users who fail to notice an Origin tag from apt-cache, and believe they're above using reportbug, will notice an -ubuntuN suffix in the version number? I don't. I think you are arguing on abstract philosophical grounds rather than trying to solve a real problem. mdz is right when he says that we already discourage people from mixing packages from different distributions. People still do it on occasion, but at some point there's little that can be done to stop it - short of making the .deb formats purposely incompatible so you *can't* cross-pollinate your box even if you try. It seems to me that using a -ubuntu version suffix just to indicate this package is compiled for Ubuntu would accomplish approximately nothing. It's busy work, and I hope the Ubuntu team don't ever feel so badgered by this thread to actually waste their time doing it. A much larger problem, IMO, is the Ubuntu users who install Debian packages which break due to the Ubuntu environment (like '/usr/bin/env python' being 2.4) then complain to Debian and forget to mention that they're using Ubuntu. I don't think there's much that can be done about those users either. signature.asc Description: Digital signature
Re: Need for launchpad
On 1/19/06, Kevin Mark [EMAIL PROTECTED] wrote: you could check changelogs.ubuntu.com which holds changelog and copyright files of the packages. Hi Reinhard, are the changelogs on changelogs.ubuntu.com only from stable releases or do they include testing/dapper? Also, I was checking packages.ubuntu.com - - dapper - base utils-bash-view Debian changelog and it was a dead link. If the entries on changelogs.ubuntu.com contain the info that the 'view Debian changelog' should contain, why not set up a programatic way to have the links made. The 'view Debian changelog' entries for stable (and presumable stable - 1) seem to work. They should hold changelogs for the development release as well, since thats the place aptitude goes to fetch the changelog for a package. Dead links could result from changelogs being updated later than packages.ubuntu.com or the other way round, so I think this should be rather considered as bug. I CC'ed ubuntu-devel in the hope that someone can clarify on this point. -- regards, Reinhard
Re: The klik project and Debian
[EMAIL PROTECTED] wrote: There seems to be a fairly good amount of Debian Sarge packages available via http://klik.atekon.de/. However, most of them are having unmaintained recipes and therefore some of them do not work properly. I think it would be an easy task for Debian maintainers to check the working of the kliked packages and improve their recipes. I think we should make friends with the klik project and help them. Shouldn't this have been on debian-devel-announce? Running, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: [ad-hominem construct deleted]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jan 18, 2006 at 10:26:05AM +0100, Thijs Kinkhorst wrote: On Wed, 2006-01-18 at 10:01 +0100, Gerfried Fuchs wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-17 11:36]: Kennedy wasn't a citizen of Berlin, either, not literally. The world understood what he meant, though, when he said (somewhat awkwardly) that he was. Again my question: Do you seriously consider calling Linus and RMS Debian Developers? Shuttleworth is using a *figure of speech*. A figure of speech is something not to be taken literally. Figures of speech are used all the time and they make language more interesting. Mr Zimmerman's reference to Kennedy is an excellent example of such a metaphorical construct. When Kennedy said that, there will undoubtedly have been people who uttered Hey, he's not German! He's lying!. But luckily most people will have understood what he meant. Hi Thijs, I was unable to locate the quote, but it seems that the quote is/could be taken liteally. Why not modify the quote to state that it is metaphorical by using something like 'Every Debian developer is an Ubuntu developer in the same vein as the quote from JFK when he was in Berlin' or 'Every Debian developer is an Ubuntu developer in the sense that all of the Debian developers work is used as a basis for the work of Ubuntu developer' Cheers, Kev - -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDz00Iv8UcC1qRZVMRAjpGAJoCJkC2PoCIpXW8/7JiN0XDPy8lLgCfb6UR wb5Y/dqdkkqDZUUbujEZb/A= =mIW+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Thu, Jan 19, 2006 at 02:21:06AM -0600, Peter Samuelson wrote: [Thomas Bushnell BSG] Since you don't do bin-NMU's, you could simply alter the version of every package to add an ubuntu tag, and then be done with it, right? That would work well and be very easy to implement. You are so hung up on this point, it's not even funny. Do you really think users who fail to notice an Origin tag from apt-cache, and believe they're above using reportbug, will notice an -ubuntuN suffix in the version number? I don't. I think you are arguing on abstract philosophical grounds rather than trying to solve a real problem. I think being able to uniquely identify a binary package by its version number does have some value. I don't think it's anywhere near so important as to justify Thomas's strident objections. mdz is right when he says that we already discourage people from mixing packages from different distributions. People still do it on occasion, but at some point there's little that can be done to stop it - short of making the .deb formats purposely incompatible so you *can't* cross-pollinate your box even if you try. It seems to me that using a -ubuntu version suffix just to indicate this package is compiled for Ubuntu would accomplish approximately nothing. It's busy work, and I hope the Ubuntu team don't ever feel so badgered by this thread to actually waste their time doing it. It is the great danger of this thread that Matt et al. will feel sufficiently put upon that they *don't* take to heart the legitimate suggestions that could improve cooperation between Debian and Ubuntu (and distinguishing version numbers for binaries being by far the least of these). If you're not cooperating with me the way I want, I'll make you regret it doesn't benefit *anyone* involved. Indeed, it just makes it easier to conclude that Debian is no longer worth the effort of trying to give back to. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: For those who care about their packages in Ubuntu
Peter Samuelson [EMAIL PROTECTED] writes: Do you really think users who fail to notice an Origin tag from apt-cache, and believe they're above using reportbug, will notice an -ubuntuN suffix in the version number? Actually it seems fairly likely that they would -- version numbers are _far_ more visible than other package meta-data. I even know this from personal experience: a while ago I played around with mixing ubuntu and debian, and various ubuntu strings in the version numbers were highly noticeable. -Miles -- We have met the enemy, and he is us. -- Pogo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: Spare disk space isn't available to add amd64 to mirrors. Spare bandwith isn't available to add amd64 to mirrors. I see. Can we please have the numbers? Exactly how much disk space is needed? Perhaps we can simply go ahead and buy more disks for our machines. I recently posted a mail with mirror sizes for all arch on debian-devel so check lists.debian.org for it. The problem also isn't our machines but some mirror in low-diskspace-land. Mirrors that don't want to carry the additional arch shouldn't have to; this should be easy to arrange. Given the recent mail about the mirror split this seems to finaly get started. So far all primary mirrors HAD to carry all archs. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The klik project and Debian
Le Jeudi 19 Janvier 2006 08:48, Peter Samuelson a écrit : For those following along at home, it seems klik is some sort of gateway to install Debian packages on various non-Debian distributions. I imagine it's an ftp frontend to alien. Well.. In fact, it is a scripted version of apt that can install package in a temp directory. The aim of it is to allow normal user to install app without write acess to /usr etc.. One application for it is to test a beta release without the need to have it definitly installed. My own feeling about it is that the author is not very honnest with the debian packaging work. No where in his web page is written that in fact klik is a refactoring of actual debian packages. Instead, it is at least implcitly told that it's all the author's work... I feel it as being not honnest so I don't see why I should really care.. Do they solve any of these problems better than Debian does? Would Debian users derive any value from klik? How? Hum... It allows non permanent installation which can be seen as good thing, but, even if I'm not deeply aware of it, I can imagine that it needs to install libraries and other things, and has the risk of puting a real mess in your system... Furthermore, the instalation script is not documented, and I had to go through the source to know what it was doing.. If not, I fail to see why Debian should care. We've got enough to worry about just making packages suitable for Debian - why go out of our way to help people who refuse to use Debian? And to people who refuse to mention their use of debian's work... Romain -- There is a land far, far away Where there's no night, there's only day Look into the book of life and you will see That there's a land far, far away
Re: Debian derivatives and the Maintainer: field (again)
Wouter Verhelst [EMAIL PROTECTED] writes: On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. They obviously do. The version is bumped and a new changelog entry is added. Yes. And then the source used to build that binNMU is thrown away. It's a *binary* NMU, you don't see a sourceful upload with that. Which means the Maintainer field in the binary package could easily be changed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
It is the great danger of this thread that Matt et al. will feel sufficiently put upon that they *don't* take to heart the legitimate suggestions that could improve cooperation between Debian and Ubuntu (and distinguishing version numbers for binaries being by far the least of these). If you're not cooperating with me the way I want, I'll make you regret it doesn't benefit *anyone* involved. Indeed, it just makes it easier to conclude that Debian is no longer worth the effort of trying to give back to. Seconded. I am amazed by the involvment made by Matt and a few other Ubuntu people in this thread. And I actually fear they could give up and lose what I personnally consider as good will. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The klik project and Debian
Le Jeudi 19 Janvier 2006 09:57, Romain Beauxis a écrit : No where in his web page is written that in fact klik is a refactoring of actual debian packages. Ok I was wrong it is written in small at the end: Thanks to debian for the software compilation and packaging. Romain -- Satan is an evilous man, But him can't chocks it on I-man So when I check him my lassing hand And if him slip, I gaan with him hand
Re: The klik project and Debian
On Thursday 19 January 2006 09:57, Romain Beauxis wrote: My own feeling about it is that the author is not very honnest with the debian packaging work. From klik.atekon.de: Thanks to debian for the software compilation and packaging. Hum... It allows non permanent installation which can be seen as good thing, but, even if I'm not deeply aware of it, I can imagine that it needs to install libraries and other things, and has the risk of puting a real mess in your system... Furthermore, the instalation script is not documented, and I had to go through the source to know what it was doing.. IIRC it creates some kind of chroot. If not, I fail to see why Debian should care. We've got enough to worry about just making packages suitable for Debian - why go out of our way to help people who refuse to use Debian? And to people who refuse to mention their use of debian's work... See above Romain
Re: Bug#348728: ITP: php-net-imap -- PHP PEAR module implementing IMAP protocol
Le Mer 18 Janvier 2006 20:58, Steffen Joeris a écrit : You should be aware that per the current REJECT_FAQ [1] your package will be automatically rejected because it uses the PHP License. Several weeks ago I emailed the FTP Masters[2], requesting that they accept the PHP Licence for all PHP Group software, backed up by extensive debian-legal discussion. They were explicitely invited to either modify their rejection criteria, or continue the debian-legal debate, both of which they have failed to do. I am now re-extending that invitation. Charles 1. http://ftp-master.debian.org/REJECT-FAQ.html 2. http://lists.debian.org/debian-legal/2006/01/msg00066.html Hi Thanks for the information. I haven't noticed it before because I saw various packages in Debian using the PHP license. I told my sponsor to wait with the upload. I will ask him for upload when PHP license is DFSG compatible or tell him to drop it if the project disagree with the PHP license. Nevertheless i think the project should make a decision. Waiting for it now ... Greetings and thanks for info Steffen the project decision is clear IMHO : read the php license, you'll see it can only apply to the main and official PHP distribution. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVmPy4si1fc.pgp Description: PGP signature
Re: when and why did python(-minimal) become essential?
On Wed, Jan 18, 2006 at 11:36:13PM -0600, Joe Wreschnig wrote: On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote: Some reasons: * compatability with Ubuntu -- so that packages can be easily ported back and forth between us and them; I expect most of the work ubuntu might do on improving boot up will require python-minimal This would be nice. Right now it's accomplished through patches Ubuntu makes to dh_python and cdbs. They'd probably like to drop those. As a point of information, Ubuntu doesn't patch dh_python at present, and I don't see any Python-related changes in cdbs at the moment either. I don't know what's actually in (or more importantly not in) python2.4-minimal though. I'm eyeballing right now. Things that jump out at me: * No character encoding, translation, or locale handling. * A little oddly, loss of shutil. * No sockets. FWIW the relevant design docs from when this was done in Ubuntu are here: https://wiki.ubuntu.com/EssentialPython (requirements) https://wiki.ubuntu.com/PythonInEssential (details) The rationale for the set of included modules is in the latter, and was basically done by taking each module in perl-base and mapping it to its Python equivalent. The third seems like something software in base may want to do; I mention it specifically because perl-base include socket support. Socket support does seem to be there: $ dpkg -c /mirror/ubuntu/pool/main/p/python2.4/python2.4-minimal_2.4.2-1ubuntu2_i386.deb | grep socket -rw-r--r-- root/root 49608 2006-01-17 12:59:02 ./usr/lib/python2.4/lib-dynload/_socket.so -rw-r--r-- root/root 12876 2006-01-17 12:58:18 ./usr/lib/python2.4/socket.py Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
[Eric Dorland] This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? [Nathanael Nerode] IIRC, the copyright issues were carefully worked out and solved after several years, finally reaching the approval of debian-legal. At which point it went into the NEW queue, to be silently ignored forever by the ftpmasters with no explanation. This is becoming an increasingly frequently asked question. What about making a wiki page explaining the status with links to the debian-legal thread and other relevant info? This way we would point people there to read the answer, and hopefully the ftpmasters might find useful information there too when they find time to make a decision? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Md wrote:
This reminds me that there should be a list of modules which MUST NOT be
added to the initramfs because loading them too early is both useless
and as in this case actively harmful.
I'm testing this solution:
I added a blacklist file in /etc/mkinitramfs/, put blacklist
net-module lines in it and added a line to /usr/sbin/mkinitramfs to
append these blacklist lines to initramfs' blacklist:
grep -v # ${CONFDIR}/blacklist ${DESTDIR}/etc/modprobe.d/blacklist
udev now can rename the interfaces, because they haven't a name yet.
furthermore this (or something similar) could be useful if we need some
modules not to appear in the initramfs.
cheers
davide
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. furthermore this (or something similar) could be useful if we need some modules not to appear in the initramfs. If you do not want to load modules in the initramfs then do not put them there in the first place. -- ciao, Marco signature.asc Description: Digital signature
Re: Andrew Suffield
On Wed, 2006-01-18 at 20:44 +, Dallam Wych wrote: On Sun, Jan 15, 2006 at 05:09:03PM -0600, Joe Wreschnig wrote: On Sun, 2006-01-15 at 06:28 -0500, sean finney wrote: On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote: Do you think your constant bitching is funny? Do you think it achieves anything? There are other DDs who are also involved in intense debates and flamewars very often, but you're the only one where I constantly get the impression that you're just being childish, insulting and annoying for the sake of it. ...says someone who just publicly ostracized a fellow dd on a public mailing list. personal opinions of the matter aside, debian-devel is not the place for ridiculing other developers, no matter how justified you feel you may be. please post follow-ups to -private. I said this on -private, and I'll say it here -- why is it appropriate to be an ass on -private, but not on -devel? It's not appropriate anywhere. That goes for Adrian, and Andrew, and everyone. It also leads to situations like the present, where it looks like we're doing nothing to reprimand offensive behavior, because most conversation is happening on -private, while the original, offensive message is sitting on d-d-a. If you are upset by how Andrew acted, talk to him rationally, regardless of whether it's public or private. If you are *very* upset by how Andrew acted, there is an appropriate and agreed-to policy for expelling developers. Roger Leigh has mentioned his interest in seeing this through; contact him. -- Joe Wreschnig [EMAIL PROTECTED] I imagine that the ubuntu people, which include those on canonicals payroll that are posting to this list, are really finding this kind of discord within the Debian community quite comical and amusing. No more or less comical or amusing than I found it before Canonical was started. Which is to say, neither comical nor amusing. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: when and why did python(-minimal) become essential?
On Wed, Jan 18, 2006 at 09:56:59PM -0800, Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 12:12:07PM +1000, Anthony Towns wrote: * allowing us to easily use python (as well as C, C++ and perl) for programs in the base system * allowing us to provide python early on installs to make users happier Please note that it is against upstream's explicit wishes for -minimal to be installed for users as part of a package selection which does not also include the full python package. URL? I have trouble distinguishing that from Upstream says python-minimal must Depend: on python. In Ubuntu, we've split the package in order to make -minimal essential, but never install it alone (both are part of base). Then what's the benefit of having python(-minimal) be essential at all? We basically reviewed the available modules and picked out the ones that we thought would be useful in an Essential context, with a goal of having no external non-Essential dependencies. Cheers, aj signature.asc Description: Digital signature
Obsolete packages in Experimental
After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). If not, is there a way to remove packages from Experimental? Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Obsolete packages in Experimental
On Thu, Jan 19, 2006 at 12:35:45PM +0100, Jérôme Warnier wrote: After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). If not, is there a way to remove packages from Experimental? If the (source) packages have the same names as the packages in unstable they will get removed semi-automatically by the ftp-masters so just wait for it. If they have different names, I think a bug report against ftp.debian.org is needed. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Obsolete packages in Experimental
[Jérôme Warnier] After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). Hmmm, I thought experimental was garbage-collected automatically in this case. signature.asc Description: Digital signature
Re: udev naming problems for eth*
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. Maybe network interface renaming doesn't belong in udev, as they're really kernel assigned names. I think this point has been raised before, ( but I couldn't find any thread relating to it), but the right place to do that would be in the ifupdown package, that could have the right logic to do so. A (somewhat flawed) metaphor regarding this topic would be that IP address configuration doesn't belong in udev either. I've looked into the Suse sysconfig package, and it includes all the network configuration utils, such as ifup and dhcp handling, and they're coupled with the udev rules. As previously said those interactions are tricky, in order to guarantee that there are no race conditions. Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Some bug numbers talking about this: 182012 227283 Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: I've looked into the Suse sysconfig package, and it includes all the network configuration utils, such as ifup and dhcp handling, and they're coupled with the udev rules. As previously said those Look harder, because there is no reason to couple them. Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Wrong. OTOH it would be useful if ifupdown allowed reporting to udev the name of an interface given its MAC address. Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. -- ciao, Marco signature.asc Description: Digital signature
Re: Obsolete packages in Experimental
Le jeudi 19 janvier 2006 à 12:43 +0100, Frank Lichtenheld a écrit : On Thu, Jan 19, 2006 at 12:35:45PM +0100, Jérôme Warnier wrote: After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). If not, is there a way to remove packages from Experimental? If the (source) packages have the same names as the packages in unstable they will get removed semi-automatically by the ftp-masters so just wait for it. They have the same name. I guess it will be removed soon then. If they have different names, I think a bug report against ftp.debian.org is needed. Thanks
Re: udev naming problems for eth*
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Wrong. I think that ifupdown maintainers are the ones who can say that for sure, looking at the bugs I didn't get that impression. OTOH it would be useful if ifupdown allowed reporting to udev the name of an interface given its MAC address. Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. The point is to call them with the kernel generated name, and let them to rename the iface. The bad is that then ifupdown should look at sysfs or some other place to get again the interface info. Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wednesday 18 January 2006 21:51, Matt Zimmerman wrote: On Wed, Jan 18, 2006 at 09:41:58AM +0100, cobaco (aka Bart Cornelis) wrote: syncinc _to_ debian implies that changes are _pushed_ to Debian regularly, whereas in actuallity they're simply made available for pull by Debian (in most cases) I am pleased to report to all who were confused or offended by the ambiguities in these quotations that Mark has clarified them both in the wiki already. :-) Considere the following: - right now there are no Ubuntu changes to my package - if Ubuntu suddenly does change my package for whatever reason, there's absolutely no way I'll suddenly know to go check the patch page. The PTS already contains this information; if you want asynchronous notification, that should be easy to arrange within the PTS. right, that solves part of it. BUT this still doesn't help with the having multiple logical changes (most of which might not apply) in a single patch (an example of which was detailed earlier in this subthread) Problems I have with this: - I don't know of any upstream that accepts patches like the one discussed. Let along does so routinely. So why is Debian expected to be different in this regard? - After having looked over a new patch with the same/similar non-applicable changes a couple of times, and no (new) applicable changes people will, quite rightly IMHO, stop looking at the linked ubuntu patches, which is surely not what Ubuntu wants? (from comments I've seen in blogs and other places, this is definately a major source of frustration on the side of DD's). Providing 1 patch per logical change should be possible, assuming each logical change is made seperately. (Which should be the case most of the time I expect?) Has Ubuntu looked into this? If so what were the problems keeping this from happening? Is it completely impractical, is it being worked on, or ... ? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpk5tGMUro5T.pgp Description: PGP signature
Re: when and why did python(-minimal) become essential?
* Anthony Towns aj@azure.humbug.org.au [2006-01-19 19:21:07]: In Ubuntu, we've split the package in order to make -minimal essential, but never install it alone (both are part of base). Then what's the benefit of having python(-minimal) be essential at all? you are able to do init.d scripts, pre- and postinsts etc in python. That is a ease of development helper for ubuntu. how agressive does debian use it's perl in this regard? i think hardly at all. i would welcome to either kick both higher level scrip languages out (to shrink essential) and rewrite stuff like adduser in c or c++ or see if we cant really use perl (or perhaps even python-minimal) more for scripting in these places. it is an underutilized resource currently and would be a win in readability, structure and even speed. signature.asc Description: Digital signature
Re: udev naming problems for eth*
On Thu, Jan 19, 2006 at 12:54:32PM +0100, Marco d'Itri wrote: Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. When are those network hotplug handlers called? I've got udev loading the network drivers, then ifrename assigning fixed names, then whereami or ifupdown configuring the network. Where are the problems in this configuration? Is there a problem if the device was removed for example (pcmcia, usb etc)? Pre-udev I fixed this by adding modules to /etc/modules, which was processed before hotplug ran. Now udev runs earlier, making /etc/modules much less useful. :( thanks Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Hamish Moffatt [EMAIL PROTECTED] wrote: Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. When are those network hotplug handlers called? When udev receives the events from the kernel, like for any other event. I've got udev loading the network drivers, then ifrename assigning fixed names, then whereami or ifupdown configuring the network. Where are the problems in this configuration? Is there a problem if the device was That if you use ifrename to rename the device then the hotplug agents run by udev will not know about the new name. -- ciao, Marco signature.asc Description: Digital signature
Re: The klik project and Debian
Frank Küster [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: There seems to be a fairly good amount of Debian Sarge packages available via http://klik.atekon.de/. However, most of them are having unmaintained recipes and therefore some of them do not work properly. I think it would be an easy task for Debian maintainers to check the working of the kliked packages and improve their recipes. I think we should make friends with the klik project and help them. Shouldn't this have been on debian-devel-announce? No, the subject was wrong. It should have been For those who care about their packages in klik to be marked as real announcement. Marc -- Fachbegriffe der Informatik - Einfach erklärt 207: Gesundbooten Das Allheilmittel für jegliche Probleme, die auf, mit und um Windows auftauchen. (Holger Marzen) pgppCpnLcFLRS.pgp Description: PGP signature
Re: For those who care about their packages in Ubuntu
On Thu, 19 Jan 2006, Christian Perrier wrote: It is the great danger of this thread that Matt et al. will feel sufficiently put upon that they *don't* take to heart the legitimate suggestions that could improve cooperation between Debian and Ubuntu (and distinguishing version numbers for binaries being by far the least of these). If you're not cooperating with me the way I want, I'll make you regret it doesn't benefit *anyone* involved. Indeed, it just makes it easier to conclude that Debian is no longer worth the effort of trying to give back to. Seconded. Seconded too. I am amazed by the involvment made by Matt and a few other Ubuntu people in this thread. And I actually fear they could give up and lose what I personnally consider as good will. Mee too as well. The only solution that I know is to discuss the matter in a smaller group (like within Utnubu) and present the decision later to the larger group ... because people who join smaller group have a real common interest while people flaming here are only eager to impose their opinion on the project (since d-d is in theory the main discussion list of the developers). Cheers, PS: Yes it's about time that we limit the number of email that a single person can post on this list. Or impose a greater delay each time a new mail comes. Or whatever, but we need to try something to avoid problems like we had in the recent threads. -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Md wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. maybe I miss something, but for what I see we don't need udev not to load the modules: we just need they are not loaded *before* udev is ready to rename the interfaces. I can see only two ways to do that: 1) the modules are not loaded till udev starts the renaming process, and that, as I can see, only happens *after* /sbin/init starts 2) udev is ready to rename from within the initramfs T. Hood wrote: I just looked at the rename_netiface script in that package. The following comments in the script give an idea of how it handles the race problem. # look for a network interface name that is still not # used as persistent name. At first it tries the name the # interface currently has. If this name is already occupied, # then increase the number and try again. # To check if a name is occupied we have to look in # /etc/udev/rules.d/60-net_*.rules and in /tmp/used_interface_names*. # The latter serves as temporary registration file to avoid race # conditions. It will be removed when the script exits. # Simply try to rename directly, because it will work in most cases # Generate a temporary interface name # Rename it to the temporary name. # Then try several times to rename it to new name this approach can only work if the names are not assigned yet. I cannot see any way we can swap two interfaces' names after they're assigned, at least not in user space (exept if we use rmmod, of course) cheers davide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 01:14:17PM +0100, Andreas Schuldei wrote: * Anthony Towns aj@azure.humbug.org.au [2006-01-19 19:21:07]: In Ubuntu, we've split the package in order to make -minimal essential, but never install it alone (both are part of base). Then what's the benefit of having python(-minimal) be essential at all? you are able to do init.d scripts, Can be done using Depends. pre- Can be done using Pre-Depends. and postinsts Can be done using Depends. These really aren't reasons for making a package Essential, AFAICT. And the real hang-up with adding Essential packages isn't even size bloat, it's making sure it will still be possible to upgrade later. This is particularly a concern when the new essential package will be adding dependencies not needed by any other existing essential packages (e.g., in this case python-minimal Depends: python2.4-minimal). I guess you could want an Essential python in order to write debconf config scripts or postrm scripts in python. Is anyone doing 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. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: udev naming problems for eth*
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: maybe I miss something, but for what I see we don't need udev not to Indeed. udev can rename the modules without any need to mess with the initramfs or change anything else. Even if the driverss have already been loaded, network hotplug events will be synthesized at boot time. -- ciao, Marco signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 17 Jan 2006 16:03:05 -0800, Matt Zimmerman [EMAIL PROTECTED] wrote: Do you realize that Xandros, who maintains a Debian derivative which they box and sell for US$50-$129 per copy, leaves the Maintainer field unmodified, and as far as I'm aware, was doing so for a period of *years* before Ubuntu even existed? This never seemed to bother anyone, and personally, I don't think it's a big deal either. Xandros does not employ a significant number of people in important single-point-of-failure-positions in Debian, most notably not the people who are notoriously known for not doing the job they have volunteered for. Additionally, Xandros doesn't have nearly the user base that Ubuntu has, and they are not nearly as loud PR-wise as Ubuntu is. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: [ad-hominem construct deleted]
On Thu, Jan 19, 2006 at 03:25:45AM -0500, Kevin Mark wrote: I was unable to locate the quote, but it seems that the quote is/could be taken liteally. Why not modify the quote to state that it is metaphorical by using something like 'Every Debian developer is an Ubuntu developer in the same vein as the quote from JFK when he was in Berlin' or 'Every Debian developer is an Ubuntu developer in the sense that all of the Debian developers work is used as a basis for the work of Ubuntu developer' This already happened. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#348728: ITP: php-net-imap -- PHP PEAR module implementing IMAP protocol
2. http://lists.debian.org/debian-legal/2006/01/msg00066.html snip the project decision is clear IMHO : read the php license, you'll see it can only apply to the main and official PHP distribution. Please read the message to debian-legal that I originally referenced. It outlines recent changes to the PHP License which make it equally fit for PHP itself and for PHP Group software. While there are some lingering questions on debian-legal as to the freeness of the PHP License for anything (including PHP), it seems clear that the new license can be equally applied to PHP Group software as to PHP itself. Inasmuch as Debian currently accepts the PHP License for PHP, I am requesting that per the recent changes it also be accepted for PHP Group software (or outright rejected for everything). cheers, Charles -- When better Shaving brushes Are made We'll still shave Without their aid Burma-Shave http://burma-shave.org/jingles/1941/when_better signature.asc Description: Digital signature
Re: make-kpkg fails, Bug?
Adam Heath wrote: On Wed, 18 Jan 2006, Alejandro Bonilla Beeche wrote: What does /bin/sh point to? Could you please explain what is exactly what you need to check? ls -l /bin/sh In other words, what does /bin/sh point to? What shell is /bin/sh? bash? zsh(gods no)? posh? dash? Hi, OK, I use bash and yes: [EMAIL PROTECTED]:~$ ls -l /bin/sh lrwxrwxrwx 1 root root 4 2006-01-11 09:08 /bin/sh - bash Any ideas? If it's a bug please let me know which package so I can help by opening the bug. Thanks, .Alejandro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Derived distributions and the Maintainer: field
Nathanael Nerode writes: Then the *source* packages can legitimately use the same Maintainer: field. If they are also compiled with a toolchain unchanged from Debian, the binaries can legitimately have the same Maintainer: field as in Debian, because they are essentially the same package. If not, the binary packages should have different Maintainer: fields Personally, I have no objection to the Maintainer field remaining unchanged when the source package is unchanged. For instance, debugging bugs in your package generated by a toolchain you don't have is obnoxious, frustrating, and a waste of time... If building one of my packages with a well-chosen toolchain fails or produces a buggy binary there is probably something wrong with it that will eventually bite me and I'd like to know about it (in the form of a wishlist bug). Ubuntu should be sorting out whether such problems are present in Debian before sending them to the Debian maintainer. Ubuntu should certainly first try to make sure the problem is not theirs. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On Thu, Jan 19, 2006 at 11:08:42AM +0100, Petter Reinholdtsen wrote: [Eric Dorland] This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? [Nathanael Nerode] IIRC, the copyright issues were carefully worked out and solved after several years, finally reaching the approval of debian-legal. At which point it went into the NEW queue, to be silently ignored forever by the ftpmasters with no explanation. This is becoming an increasingly frequently asked question. What about making a wiki page explaining the status with links to the debian-legal thread and other relevant info? MJ Ray's already done such a summary; it's rather trivially inadequate, due to the information its summarising being equally inadequate. http://lists.debian.org/debian-devel/2005/12/msg00901.html This way we would point people there to read the answer, and hopefully the ftpmasters might find useful information there too when they find time to make a decision? Coming to a decision on inadequate information isn't particularly clever. Seriously, if you want something useful to happen about this, *thoroughly* investigate what's actually going on, with an open mind about the possibility of coming to the conclusion that, eg, it's just too much of a risk to include mplayer in Debian. Cheers, aj signature.asc Description: Digital signature
Backports
I was wondering if the developers thought Backports will ever become an official part of Debian, one where the bugs are tracked on the BTS etc... I really want to use backports, I'm just intimadated by: I provide these files without any warranty. Use them at your own risk. If one of these packages eats your cat or your rabbit, kills your neighbour, or burns your fridge, don't bother me. >From http://www.backports.org/warnings.html . Do you think we will ever see backports officially supported by Debian?
Re: For those who care about their packages in Ubuntu
On Wed, Jan 18, 2006 at 03:00:53PM -0800, Matt Zimmerman wrote:
On Wed, Jan 18, 2006 at 02:47:05PM -0800, Thomas Bushnell BSG wrote:
Ok, then I must have misunderstood something. So it is clear then
that Ubuntu does recompile every package.
To clarify explicitly:
- Ubuntu does not use any binary packages from Debian
- Most Ubuntu source packages are identical copies from Debian, while some
are modified for Ubuntu
- All Ubuntu binary packages are built for Ubuntu in Ubuntu chroots
When you recompile packages, change their version number just as
Debian does for binary-NMUs? That is, the first binary compile for
an arch gets the same version number as the original source, but all
future recompilations, which would include those done by Ubuntu or
anyone else, should get a modified version number.
I believe there are still packages which break when bin-NMU'd (e.g.,
Depends: = ${Source-Version}), and there are parts of our infrastructure
which do not support them (Ubuntu doesn't do bin-NMUs). If it were
essential to version the packages differently, I would say that the source
package versions should be changed as well. Bin-NMUs are more trouble than
they are worth.
The Source-Version problem will not affect Ubuntu because they rebuild
both binary: all and binary: any packages. The issue with Debian style
binNMU is that we only rebuild the binary: any packages that will have
a different source version than the binary: all packages.
You just need to bump the version before rebuilding the packages and
that's it. It is not different from rebuilding the packages after a
minor change.
Why is it now important to you that the version numbers be changed, though?
This is only an issue when mixing packages between different derivatives,
which already breaks in other subtle ways, so I'm not very much inclined to
try to un-break it in this particular way, given that it's non-trivial.
At least to avoid namespace conflict between Debian and Ubuntu .deb files.
Cheers,
Bill.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
A bit of experience after having updated some packages to use pbuilder-test testsuite engine.
Hi, * Let's modify pbuilder to run test-build tests and (if possible) also the generic tool and test-install tests. These belong, I think, better into pbuilder then piuparts, but it might be that piuparts should run them also. pbuilder hook is available for those who want to test this framework. I've been working with this, with a very simplistic set-up of running multiple shell scripts. There are things that you know beforehand (if you know the gory details of pbuilder as it is documented). 1. your source code is available in /tmp/buildd/package-version/, which you can probably match with the wildcard '/tmp/buildd/*/debian/../' 2. your testsuite resides in /tmp/buildd/*/debian/pbuilder-testsuite/*, which will be executed with run-parts. 3. previous version of your package will be installed by B92test-pkg by default, from your default apt sources, and if it fails, test won't progress. 4. within the chroot, B92test-pkg by default does the following: your previous version is installed from apt sources your previous version is removed your new package is installed with dpkg -i this sequence should be improved, and should probably allow failures Things that I really want to have after testing a few packages. 1. support for common operations, maybe a shell library is in order? For example, I usually want to compile/link/execute a test code to test a -dev package. That requires some amount of idiom in plain shell code, and I shouldn't have to copy-and-paste code all over the place. 2. support for providing source data. Most applications eat data and output data. I really want some way to provide data and to say what's the expected output. 3. support for X. Some of my packages are command-line console tools, but many are actually graphical apps. It would be a plus to have some kind of interactive/noninteractive X-based testing. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Thu, Jan 19, 2006 at 02:21:06AM -0600, Peter Samuelson wrote: Do you really think users who fail to notice an Origin tag from apt-cache, and believe they're above using reportbug, will notice an -ubuntuN suffix in the version number? I don't. I think you are arguing on abstract philosophical grounds rather than trying to solve a real problem. The .deb control file itself does not include the Origin tag, so this only work if you have Ubuntu in your source.list at the time you run apt-cache. (and actually apt-cache show available packages attribute rather than attribute of installed packages). This is not particularly accurate nor robust. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Thu, Jan 19, 2006 at 02:15:15PM +0100, Marc Haber wrote: On Tue, 17 Jan 2006 16:03:05 -0800, Matt Zimmerman [EMAIL PROTECTED] wrote: Do you realize that Xandros, who maintains a Debian derivative which they box and sell for US$50-$129 per copy, leaves the Maintainer field unmodified, and as far as I'm aware, was doing so for a period of *years* before Ubuntu even existed? This never seemed to bother anyone, and personally, I don't think it's a big deal either. Xandros does not employ a significant number of people in important single-point-of-failure-positions in Debian, most notably not the people who are notoriously known for not doing the job they have volunteered for. Apart from its questionable accuracy, this is a red herring and has nothing to do with how derivatives should treat the Maintainer field. Additionally, Xandros doesn't have nearly the user base that Ubuntu has, and they are not nearly as loud PR-wise as Ubuntu is. Likewise, I don't think that the popularity of a derivative is an important consideration on this point. What exactly do you consider loud PR? Ubuntu doesn't exactly mount campaigns; what messaging there is is by word of mouth. Other Debian derivatives buy ad space on Google keywords like Debian. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 01:14:17PM +0100, Andreas Schuldei wrote: you are able to do init.d scripts, pre- and postinsts etc in python. That is a ease of development helper for ubuntu. All of those can be done today using dependencies. .config scripts, for example, cannot. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Thu, Jan 19, 2006 at 03:08:32PM +0100, Bill Allombert wrote:
On Wed, Jan 18, 2006 at 03:00:53PM -0800, Matt Zimmerman wrote:
I believe there are still packages which break when bin-NMU'd (e.g.,
Depends: = ${Source-Version}), and there are parts of our infrastructure
which do not support them (Ubuntu doesn't do bin-NMUs). If it were
essential to version the packages differently, I would say that the source
package versions should be changed as well. Bin-NMUs are more trouble than
they are worth.
The Source-Version problem will not affect Ubuntu because they rebuild
both binary: all and binary: any packages. The issue with Debian style
binNMU is that we only rebuild the binary: any packages that will have
a different source version than the binary: all packages.
You just need to bump the version before rebuilding the packages and
that's it. It is not different from rebuilding the packages after a
minor change.
You're reiterating what I've said: binNMUs won't really work; updating the
source package version would be the more reasonable way to accomplish the
same goal (though there are definitely tradeoffs there as well, and I think
we have more important issues to tackle at this point).
Why is it now important to you that the version numbers be changed,
though? This is only an issue when mixing packages between different
derivatives, which already breaks in other subtle ways, so I'm not very
much inclined to try to un-break it in this particular way, given that
it's non-trivial.
At least to avoid namespace conflict between Debian and Ubuntu .deb files.
That seems like an abstract goal; what actual problem would be solved?
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 07:21:07PM +1000, Anthony Towns wrote: On Wed, Jan 18, 2006 at 09:56:59PM -0800, Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 12:12:07PM +1000, Anthony Towns wrote: * allowing us to easily use python (as well as C, C++ and perl) for programs in the base system * allowing us to provide python early on installs to make users happier Please note that it is against upstream's explicit wishes for -minimal to be installed for users as part of a package selection which does not also include the full python package. URL? I have trouble distinguishing that from Upstream says python-minimal must Depend: on python. I don't have a URL; this came out of a discussion in person with Anthony Baxter, though, who you could email for confirmation if you like. The Python community dislikes the idea of people being given a /usr/bin/python that doesn't include the standard library. This causes confusion for their users. In Ubuntu, we've split the package in order to make -minimal essential, but never install it alone (both are part of base). Then what's the benefit of having python(-minimal) be essential at all? So that the Python language, and select pieces of the standard library, can be used in contexts where only essential packages can be relied upon to be available. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backports
* Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backports
* Norbert Tretkowski [Thu, 19 Jan 2006 17:02:03 +0100]: * Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. Is this to be read as the person behind backports.org, I don't have in mind working to make them official, or I believe ftp.debian.org will never carry a 'backports' suite? Anthony Towns has hinted a couple times in the past that such may become a closer possibility after the mirror split (e.g. in [1]). [1] http://lists.debian.org/debian-devel-announce/2006/01/msg7.html Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conference is a gathering of important people who singly can do nothing but together can decide that nothing can be done. -- Fred Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, 19 Jan 2006 11:41:19 +0100, Frank Küster [EMAIL PROTECTED] said: Hi, the text of the amendment says at its very end: , Since this amendment would require modification of a foundation document, namely, the Social Contract, it requires a 3:1 majority to pass. ` But AFAICS it does not propose a textual change to the SC, just a change of its meaning, or interpretation or whatever. I am afraid I was responsible for that rider. I should apologize for not sending a clarification earlier, but I was inadvertently away from my keyboard since my laptop's graphics card died just as I was going off on a business trip I have a couple of questions about this: - Has this been done previously? If yes, where can I find a collection of all decisions that have thus changed the SC? Err, we have had two GR's that changed the SC -- the so called editorial changes GR, and the GR that deferred the changes for Sarge. But in each case we followed through and changed the text of the SC. - Shouldn't we add a sentence to the SC, something like In a couple of cases, the interpretation of this Social Contract or how it should be spelled out in technical details was controversial among the project, and votes have been taken. The results of these votes are at hyperlink ? As for the intention of the amendment, it seems to me that it relies heavily on the assumption that the excempted clauses are simply bugs of the license text and not the actual intention. Given how bad communication with the FSF was wrt to the GFDL, I doubt that we can sure about this... The fact that the license is buggy does not change the fact that works licensed under it would violate the DFSG. Given that, any resolution to allow these works to remain in Debian would require a rider to be added to the SC, something of the form: - Debian will remain 100% free + Debian will remain 100% free, apart from works licensed under the GFDL (the exact wording can be decided upon if the amendment passes). Since this requires a modification of a foundation document, the amendment requires a 3:1 majority. manoj -- signal(i, SIG_DFL); /* crunch, crunch, crunch */ Larry Wall in doarg.c From the perl source code Debian Project Secretarty [EMAIL PROTECTED] http://vote.debian.org/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpzsSjINPdGk.pgp Description: PGP signature
Re: Backports
* Adeodato Simó wrote: * Norbert Tretkowski [Thu, 19 Jan 2006 17:02:03 +0100]: * Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. Is this to be read as the person behind backports.org, I don't have in mind working to make them official, or I believe ftp.debian.org will never carry a 'backports' suite? The latter. Maybe it's possible to provide some 'official' backports in the future, which would be nice, but I don't think it's possible to make all packages from backports.org 'official'. We would need security support (which is currently done by upgrading the backport when a new version of the package hits unstable), and we have to take care of packages which depends on a backport (that's why there's no official firefox 1.5 backport[0] for Ubuntu). Norbert [0]: http://lists.ubuntu.com/archives/ubuntu-backports/2005-December/000550.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
* Debian Project Secretary [Thu, 19 Jan 2006 10:12:50 -0600]: The fact that the license is buggy does not change the fact that works licensed under it would violate the DFSG. Given that, any resolution to allow these works to remain in Debian would require a rider to be added to the SC, something of the form: - Debian will remain 100% free + Debian will remain 100% free, apart from works licensed under the GFDL (the exact wording can be decided upon if the amendment passes). Since this requires a modification of a foundation document, the amendment requires a 3:1 majority. I don't see why this _physical modification_ is necessary. I can admit that the secretary says this amendment overrules the social contract, since it talks about putting non-free things in main, so it requires a 3:1 majority; but if the amendment passes, and so the GR issues a statement that some GFDL documents will remain in main, I don't think explicit wording is needed _in_ the SC, at all. Or so. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Arguing with an engineer is like wrestling with a pig in mud: after a while, you realize the pig is enjoying it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backports
* Norbert Tretkowski [EMAIL PROTECTED] [2006-01-19 17:02:03]: * Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. i remember a conversation where you pointed out some principal problems (security support, manpower) but in general were in favour of the idea and prefered fixing those. what happend? signature.asc Description: Digital signature
Re: Obsolete packages in Experimental
On Thursday, January 19, 2006 11:35 AM, Jérôme Warnier [EMAIL PROTECTED] wrote: After the last update of OOo in Sid (aka Unstable), I wonder if it is generally considered acceptable to keep obsolete packages in experimental (currently, Sid has 2.0.1-2 and Experimental 2.0.1-1). Further to other answers, in this particular case you were about six and a half hours out of date ;-) = [Date: Wed, 18 Jan 2006 21:06:31 -0800] [ftpmaster: Ryan Murray] Removed the following packages from experimental: [...] openoffice.org |2.0.1-1 | source, i386, powerpc, sparc openoffice.org-base |2.0.1-1 | i386, powerpc, sparc [...] openoffice.org-writer |2.0.1-1 | i386, powerpc, sparc [...] --- Reason --- [rene] NVIU -- = (i.e. rene, the archive cruft remover flagged the experimental packages for removal as there was a newer version in unstable). Cheers, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backports
* Andreas Schuldei wrote: * Norbert Tretkowski [EMAIL PROTECTED] [2006-01-19 17:02:03]: * Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. i remember a conversation where you pointed out some principal problems (security support, manpower) but in general were in favour of the idea and prefered fixing those. what happend? Manpower is no longer a problem, thanks to Ganneff we're now using dak, which means every Debian developer can upload his packages (but I still need to manually add his gpg key to the backports.org keyring). A while back, I talked with Joey about the required infrastructure to provide security advisories, but until now I had no time to implement it. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The klik project and Debian
On Thu, 19 Jan 2006, Frank Küster wrote: [EMAIL PROTECTED] wrote: There seems to be a fairly good amount of Debian Sarge packages available via http://klik.atekon.de/. However, most of them are having unmaintained recipes and therefore some of them do not work properly. I think it would be an easy task for Debian maintainers to check the working of the kliked packages and improve their recipes. I think we should make friends with the klik project and help them. Shouldn't this have been on debian-devel-announce? Ha. You funny man. Me laugh.
Re: Backports
* Norbert Tretkowski [EMAIL PROTECTED] [2006-01-19 17:38:45]: * Andreas Schuldei wrote: * Norbert Tretkowski [EMAIL PROTECTED] [2006-01-19 17:02:03]: * Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. i remember a conversation where you pointed out some principal problems (security support, manpower) but in general were in favour of the idea and prefered fixing those. what happend? Manpower is no longer a problem, thanks to Ganneff we're now using dak, which means every Debian developer can upload his packages (but I still need to manually add his gpg key to the backports.org keyring). A while back, I talked with Joey about the required infrastructure to provide security advisories, but until now I had no time to implement it. Then why did you answer no above? Things look comparatively peachy to me. signature.asc Description: Digital signature
Re: Backports
Norbert Tretkowski [EMAIL PROTECTED] wrote: * Andreas Schuldei wrote: * Norbert Tretkowski [EMAIL PROTECTED] [2006-01-19 17:02:03]: * Joseph Smidt wrote: Do you think we will ever see backports officially supported by Debian? No. i remember a conversation where you pointed out some principal problems (security support, manpower) but in general were in favour of the idea and prefered fixing those. what happend? Manpower is no longer a problem, thanks to Ganneff we're now using dak, which means every Debian developer can upload his packages (but I still need to manually add his gpg key to the backports.org keyring). A while back, I talked with Joey about the required infrastructure to provide security advisories, but until now I had no time to implement it. The answer also depends on the understanding of officially supported. By definition, backports are not part of a release and can never get the same level of support as a stable release gets, like upgrade tests (we already don't support upgrades from n-2 to n, we'll never be able to promise an upgrade path for arbitrary combinations of stable+backports). Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Adeodato Simó [EMAIL PROTECTED] wrote: * Debian Project Secretary [Thu, 19 Jan 2006 10:12:50 -0600]: Since this requires a modification of a foundation document, the amendment requires a 3:1 majority. I don't see why this _physical modification_ is necessary. I can admit that the secretary says this amendment overrules the social contract, since it talks about putting non-free things in main, so it requires a 3:1 majority; but if the amendment passes, and so the GR issues a statement that some GFDL documents will remain in main, I don't think explicit wording is needed _in_ the SC, at all. I disagree - either the interpretation of the SC allows GFDL'ed documents without invariant (et al) sections, then we don't need a 3:1 majority, or it doesn't - then we have to change it if we want to keep our promises. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Amendment to GR on GFDL, and the changes to the Social Contract
* Debian Project Secretary [Thu, 19 Jan 2006 10:12:50 -0600]: On second thoughts... The fact that the license is buggy does not change the fact that works licensed under it would violate the DFSG. The amendment intentionally talks only about what Debian is going to do (allow invariant-less in main), which is what most people from outside are interested in hearing anyway, and does not talk about what needs overruling to achieve that. It seems, by my reading of the Constitution, that it's the task of the Secretary to determine who is being overruled and thus what majority is needed. And the Secretary's opinion is: (a) this amendment overrules the Social Contract by putting non-free bits in main, and thus needs 3:1 However, I'm pretty sure that more than one Developer thinks the proper interpretation would be: (b) this amendment overrules debian-legal's assessment that certain two clauses of the GFDL are non-free, and thus needs 1:1 How this gets handled, that I don't know, but I can imagine. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Guy: My dad made my mom have a cesarean when she had my little brother. He wanted to make sure he was born in the 1986 tax year so he could get another tax credit. -- http://www.overheardinnewyork.com/archives/002968.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Debian Project Secretary [EMAIL PROTECTED] wrote: The fact that the license is buggy does not change the fact that works licensed under it would violate the DFSG. Given that, any resolution to allow these works to remain in Debian would require a rider to be added to the SC, something of the form: - Debian will remain 100% free + Debian will remain 100% free, apart from works licensed under the GFDL (the exact wording can be decided upon if the amendment passes). Since this requires a modification of a foundation document, the amendment requires a 3:1 majority. I think the text should rather be fixed before the vote. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Backports
* Frank Küster [Thu, 19 Jan 2006 18:04:03 +0100]: The answer also depends on the understanding of officially supported. By definition, backports are not part of a release and can never get the same level of support as a stable release gets, like upgrade tests (we already don't support upgrades from n-2 to n, we'll never be able to promise an upgrade path for arbitrary combinations of stable+backports). Related to this: 18:01 dato nobse: well; IMHO a certain suite in ftp.debian.org needs the support that the project compromises to. e.g., Debian says stable is security-supported, unstable is not, and testing may lack packages at some point in time. nobody forces us to say the 'backports' suite is supported by the Security Team, though it'd be good to say at least security support 'backports' will happen by pulling the fixes from the testing or testing or unstable distributions -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Q: How do Debian developers play Russian rulette? A: Everone contributes a key revocation certificate and chooses a number from one to ten. Then everybody executes a random generator - if it's a match, then his revocation certificate is submitted to the keyservers. -- seen on [EMAIL PROTECTED]
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Hi, On Wed, Jan 18, 2006, Simon Richter wrote: I'm unconvinced that bumping the priority on the other terminal emulators is an adequate solution, hence I'm opening this general bug for discussion on how to reflect individual users' choices properly. We had a similar problem for GNOME recently, but not on the terminal emulator front, it was with web browsers. Rationale: you don't want to see konqueror launched as the default browser in GNOME but you want GNOME to be integrated with Debian. The www-browser and x-www-browser alternatives provide an useful mean for classing browsers system-wide with a priority. The sensible-browser script is an useful entry point to launch the most suitable browser from the current environment. sensible-browser will use the environment to guess what browser or alternative to launch (browsers in $BROWSER, x-www-browser, www-browser in xterm, www-browser). It is simple to extend this scheme with: - gnome-www-browser for browsers with GNOME support (epiphany-browser, galeon, firefox-gnome-support, ...) - check for $DISPLAY and eg. $GNOME_DESKTOP_SESSION_ID in sensible-browser to decide to launch gnome-www-browser or default to x-www-browser These changes were commited in galeon and epiphany's SVN, the changes to sensible-browser and to firefox remain to be done. Of course, this could be followed for KDE too. Simon, would this help with the problem you mentionned? Cheers, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Re: when and why did python(-minimal) become essential?
On Thu, 2006-01-19 at 09:31 +, Colin Watson wrote: On Wed, Jan 18, 2006 at 11:36:13PM -0600, Joe Wreschnig wrote: On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote: Some reasons: * compatability with Ubuntu -- so that packages can be easily ported back and forth between us and them; I expect most of the work ubuntu might do on improving boot up will require python-minimal This would be nice. Right now it's accomplished through patches Ubuntu makes to dh_python and cdbs. They'd probably like to drop those. As a point of information, Ubuntu doesn't patch dh_python at present, and I don't see any Python-related changes in cdbs at the moment either. Oh, hrm. So packages that need to use python-minimal manually handle their Python dependencies? That seems like a significant step backwards, in terms of handling transitions. $ dpkg -c /mirror/ubuntu/pool/main/p/python2.4/python2.4-minimal_2.4.2-1ubuntu2_i386.deb | grep socket -rw-r--r-- root/root 49608 2006-01-17 12:59:02 ./usr/lib/python2.4/lib-dynload/_socket.so -rw-r--r-- root/root 12876 2006-01-17 12:58:18 ./usr/lib/python2.4/socket.py D'oh. Apparently I'm blind. Thanks. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
statement from one of the klik project members [was: The klik project and Debian]
[EMAIL PROTECTED] There seems to be a fairly good amount of Debian Sarge packages available via http://klik.atekon.de/. You know, I almost didn't bother to visit the web site, since you're unwilling to even sign your name to your message, and you didn't say anything about what klik is or why we should care. I was bored, though. Peter, I'm sorry that someone I do not know has (stupidly) decided to anonymously kick off a klik discussion on this list. He/she may think he helps klik and/or Debian, but I'm afraid this is not the way to go about this. I say so as one member of the klik project team. (I'm not subscribed to the list, and I'll CC you because I don't know if my mail goes through. Thanks to SLH who came to #klik on Freenode to inform me about this thread.) For those following along at home, it seems klik is some sort of gateway to install Debian packages on various non-Debian distributions. I imagine it's an ftp frontend to alien. Not quite right. Essentially, klik is a web service that delivers recipes for klik applicationnane.cmg bundles to the klik clients. The klik clients execute the recipes (shell script) to download (possibly multiple) input packages (.debs, .tgzs, .rpms, .bz2s, .packages,...) and convert them into one single *.cmg file. The *.cmg is a complete compressed file system (cramfs or zisofs) similar to an ISO image, cantaining all the direct depencencies of the applicationname to run successfully. A klik *.cmg image file contains two types of components: a) all the required binaries, libraries and data files to run the contained application b) a wrapper script (call wrapper) that uses PATH, LD_LIBRARY_PATH and a few other simple settings to allow running the .cmg file as a more or less self-contained thingie. The *.cmg currently needs to be loop-mounted before exectution of the wrapper. That is done by an external helper script (part of the minimal klik client installation). For an overview about what klik is and what it isn't see this intro- ductionary article of mine: http://dot.kde.org/1126867980/ For some quick answers to FAQs see this link: http://klik.atekon.de/wiki/index.php/User's_FAQ The klik way of obtaining packages seems to have solved many other problems related to package management as well, so this is something Debian developers should study carefully. I disagree in that rather drastic and absolute-ish notion of this statement from the initial poster... First, klik is not a package management system at all. It doesn't strife to replace apt-get, dpkg, rpm, yum, apt4rpm, smart, autopackage or what-have-you. Second, klik is (IMHO) only in usable beta stage. (But I of course agree that klik has some very nice, very beneficial use cases -- use cases that benefit endusers as well as developers. See links given below.) Why is klik not a package manager? First, because klik does not interfere with any host's base system. It does not install into /usr. It does not mess up your native package manager. Second, because klik packaging does not (as a rule) involve to build from sources, does not involve compiling. It merely repackages what has been packaged by real men such as you.;-P And third, klik doesn't really install. It brings exactly 1 additional file (the *.cmg) onto the system. It works with user only privileges. It is a self-contained bundle encompassing all the direct depencies (however, it expects certain base system libraries and utilities to be present on the system). Do they solve any of these problems better than Debian does? You did not name these problems. What *I* personally use klik for is this: * using (for testing, bug-reporting, translations, etc) bleeding edge versions of software on my system (side by side with the system-installed stable versions) without endangering the stability of that base system in any way. * using different versions of the same software side by side without having to mess with the system package manager. * testdriving new versions of software before deciding for an upgrade of the system-installed package. klik bundles: - are easily relocateable (run them from $HOME, from an USB stick or even directly from CD). - are to a degree even transferable between different systems (well, we have to suffer from GCC and C++ ABI incompatibilities too). - implement an 1 file == 1 application paradigma, which makes it much more easy to handle by even grandma users. - do not pretend to be something completely new -- NeXT and Mac OS X had/have something very similar in the shape of AppDirs. The only new things brought by klik are a) compression of the AppDir into 1 single file system image, and b) offer klik bundles via a web service Would Debian users derive any value from klik? The same as I do (if they are interested in it). But klik also offers interesting use for *developers*. One of these you will probably
Re: binNMU version detection
[EMAIL PROTECTED] wrote: How did bin-NMU numbers work for the old numbering scheme on native packages? In a Complicated Way. Essentially, the debian revision and NMU revision were filled in with 0s (which were, accordingly, not supposed to be used in normal version numbers). What prohibited -3.0.1 numbers from occurring in such uploads before? It was just a matter of convention (codified in documentation), no? Yes. And that's my only real objection here: we've switched to something undocumented. I think for various reasons the distinction between binary-only upload version numbers and source upload version numbers ought to be codified in policy, not just in the developer's reference, but that's another matter. Furthermore (sigh) the developer's reference still advises the old numbering scheme for binNMUs, so we can expect to see it for manual binNMUs for a good while yet. So any routine will have to handle *both*. Let's patch that and solve that problem. (I'll try to do that within the next couple days, although I should probably be overruled by someone who knows a little bit more about it than I do.) If policy is patched to describe the new binNMU version number format and to tell people not to use that format for sourceful uploads; and the developer's reference is patched to match; that would satisfy, oh, *all* my complaints. :-) Later, Steve Langasek wrote: The primary aim of this change was to address the fact that there was no consistent numbering scheme that satisfies the constraint binNMU security NMU source NMU. The problems with this were due to security NMUs, weren't they? The old binNMU numbering scheme makes them consistently and reliably less than the source NMU numbering. So the binNMU numbering was changed so as to make it possible for the security team to name their uploads while guaranteeing that they would sort above binNMUs and below regular NMUs? Despite this, the current security team upload naming *doesn't work*. I've seen 5.8.4-8sarge3 in a recent upload of perl: $dpkg --compare-versions 5.8.4-8sarge3 gt 5.8.4-8+b1 || echo false false So this sorts below the binNMU. And I've seen 1.3.5-4.sarge.2 in a recent koffice upload: $dpkg --compare-versions 1.3.5-4.sarge.2 lt 1.3.5-4.1 || echo false false And this sorts above the source NMU. So this change has not yet addressed this problem. And contrary to Nathanael's protestations, this was discussed publically on debian-devel -- a year ago -- and this solution arrived at with the input of an ftpmaster and the then-current dpkg maintainer, among others. Ah. I must have missed that discussion. Pointer? I would appreciate knowing what was decided on for security uploads, since it's obviously not being used. Or did you decide to change the version numbering for regular NMUs instead? If so, that's certainly not being used. It just didn't get implemented until after wanna-build co. gained support for binNMUs, making them commonplace: The binNMU version changes could have been implemented long before that by changing the documentation and announcing to people that the new format should be used. They weren't. As a matter of fact, this clearly should have been done before implementing it in wanna-build. It wasn't. And the security upload version changes -- the original motivation for the whole thing -- clearly haven't been implemented at all. Even though this requires only one thing: getting the security team to agree to do it. It would work, except for native packages, if the security team switched to using +sarge? suffixes. (Well, as long as Debian never picked a code name starting with a.) For native packages, it would work as long as binNMUs and security uploads always added a 0 debian revision number before the +b? or +sarge? suffix. Worse, the security team could have made this change well before the binNMU changes, because it's better than the existing (and common) 5.8.4-8sarge3 naming. But they didn't. So, this still seems to me like a really half-assed way to have done things. Are there plans to straighten this out? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
aj@azure.humbug.org.au: MJ Ray's already done such a summary; it's rather trivially inadequate, due to the information its summarising being equally inadequate. http://lists.debian.org/debian-devel/2005/12/msg00901.html So the summary amounts to patents. Is that right? In other words, the previous (substantial) copyright issues *are* considered to be cleared up. Having it REJECTed with a needs to have algorithms covered by actively enforced patents identified and removed would be really helpful. Having a list of specific areas which are considered too dangerous (ffmpeg code, for instance) would be even better. Coming to a decision on inadequate information isn't particularly clever. Clever isn't the issue. I couldn't care less how clever the ftpmasters are. Too clever by half, perhaps, with the leave difficult packages in limbo policy. Coming to a decision on inadequate information is actually very helpful, when it's done in the form of This is the information we need before we can consider this package. I haven't seen that. Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. Seriously, if you want something useful to happen about this, *thoroughly* investigate what's actually going on, with an open mind about the possibility of coming to the conclusion that, eg, it's just too much of a risk to include mplayer in Debian. Hey, sure. Why is it too much of a risk? Can we get some background here? Originally it was too much of a risk because upstream was really bad about copyrights -- this was a FAQ. Like I said, some people spent literally years straightening that out. Hence the what the hell is wrong now? attitude. If it really is FFMPEG patent issues -- and I have no idea whether it is -- then I believe the packagers would be happy to just remove that code, because what some might call a crippled mplayer is still better than no mplayer. Incidentally, the current attitude of we won't include new packages with FFMPEG, but we will include FFMPEG is legally stupid. It doesn't get you anything if you do get sued; if anything, it helps prove that you knew you had a problem, and so were wilfully infringing. If this is really the issue, we should kick out the existing FFMPEG packages (and I'm happy to file the serious bugs, if that will get things started). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The klik project and Debian
Le Jeudi 19 Janvier 2006 08:48, Peter Samuelson a écrit?: For those following along at home, it seems klik is some sort of gateway to install Debian packages on various non-Debian distributions. I imagine it's an ftp frontend to alien. Well.. In fact, it is a scripted version of apt that can install package in a temp directory. scripted is right. apt (or Debian) is not exclusively used, only mostly. install I wouldnt call what klik does. It brings a single file to your system (hr yes, in previous versions, for debugging purposes it had leftovers in /tmp/klik/appname/), which is relocateable, can be run and used, but does not mess with your system's package manager's holy realm. The aim of it is to allow normal user to install app without write acess to /usr etc.. Not install the app. Use the app is more precise. Doesnt put anything into /usr etc. Just into the user's $HOME/Desktop/ (by default -- may be moved any time). One application for it is to test a beta release without the need to have it definitly installed. Right. My own feeling about it is that the author is not very honnest with the debian packaging work. Why?!? No where in his web page is written that in fact klik is a refactoring of actual debian packages. Read again. I'm sure you'll discover it. 1 minute ago I checked, and it was still there: Thanks to debian for the software compilation and packaging. On nearly every page. In the footer. I'm sure we are open for negotiation to make that note even more prominent, or re-word it. Please make a suggestion. (But please do also bear in mind that it shouldn't be too annoying and jumping into the face of frequent klik users). Instead, it is at least implcitly told that it's all the author's work... klik by Simon Peter. Thanks to all contributors on #klik. Thanks to debian for the software compilation and packaging. [] Thanks to all users who give feedback. THIS IS PURELY EXPERIMENTAL SOFTWARE. On nearly each page's footer... Are you sure you have looked onto the *real* klik page? http://klik.atekon.de/ ? I feel it as being not honnest so I don't see why I should really care.. Fortunately, you are wrong here. Do they solve any of these problems better than Debian does? ?Would Debian users derive any value from klik? ?How? Hum... It allows non permanent installation which can be seen as good thing, but, even if I'm not deeply aware of it, I can imagine that it needs to install libraries and other things, and has the risk of puting a real mess in your system... No. The beauty of klik is that it does not mess *at all* with your system! It doesnt install libraries. The only things a running klik-ified application will ever endanger by touching them are the dot files and directories in the user's home directory. These are generally not seens as being part of the system. (Of course, for the user they may be even more valuable than the system which can be easily rebuild...) If a klik bundle needs specific libraries, these will be embedded into the single compressed, self-contained file system image *.cmg file. Your system will not notice these additional libraries. If these libraries are buggy, your system's installed base stability will not suffer. If the klik app is failing well, then just that app doesnt run. Furthermore, the instalation script is not documented, and I had to go through the source to know what it was doing.. Please poke a bit more on the klik website. You may want to look at the FAQ first: http://klik.atekon.de/wiki/index.php/User's_FAQ If not, I fail to see why Debian should care. ?We've got enough to worry about just making packages suitable for Debian - why go out of our way to help people who refuse to use Debian? And to people who refuse to mention their use of debian's work. Heh... Cheers, Kurt [not subscribed]
Re: new mplayer 1.0pre7try2 package
Apologies to AJ and the ftpmasters. I found the *important* part of the thread, which I'd apparently missed during December, in which the ftpmasters... drumroll explain what would be needed for mplayer to go into Debian now, barring finding additional problems. Congrats Jeroen van Wolfellaar, ftpmaster extraordinare, not afraid to take on the difficult cases (he also managed the REJECT on rte IRRC). From http://lists.debian.org/debian-devel/2005/12/msg00888.html: (Jeroen) Basicly: Drop mpeg encoding from mplayer source package - definitely less problems getting through NEW. ... I suggest you upload stripping all the mpeg encoding stuff, pending answer to that difficult question. However, what you do, is your choice -- if you prefer to wait and are not planning to strip mpeg encoding support out of the source package, that's not something the ftp-master team will have any say on. ... I'm not aware of any fundamental reason why mplayer couldn't be in Debian. ... However, removing encoding stuff would bypass the main problem that we have with mplayer right now, and then the answer to this question can then be researched in parallel to an mplayer-with-only-mpeg-decoding being available from Debian. ... (A Menucc) 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) (Jeroen) I don't know of any at this moment, but I also cannot promise there won't be any more problems that need fixing found between now and the package being checked in the NEW queue. And to reiterate: If Debian wants to be legally safe w.r.t. mpeg encoder patents, removing some mpeg encoders and not others -- when the others have been pointed out -- is really a bad idea. They should all be removed until the issue is settled one way or another. I see no way that leaving some in while excluding others for patent reasons is going to help Debian; if anything it can only make Debian's legal situation worse, because it can be used as evidence that Debian knew about the problems but left the patent-covered code in Debian. Which gets you the extra penalties for wilful infringement. Is there an objection, or shall I file a serious bug against ffmpeg?
Re: when and why did python(-minimal) become essential?
Colin Watson wrote: FWIW the relevant design docs from when this was done in Ubuntu are here: https://wiki.ubuntu.com/EssentialPython (requirements) https://wiki.ubuntu.com/PythonInEssential (details) The rationale for the set of included modules is in the latter, and was basically done by taking each module in perl-base and mapping it to its Python equivalent. FWIW, that's a fairly strange way to do it, since modules are added/removed from perl-base as needed by the perl-using programs in the base system. For example, perl-base includes Data::Dumper because debconf (used to) use it, not because there's any other particular reason to include that module in base, and I've just asked that Data::Dumper be removed, so including its equivilant (pickle) in python-base on that rationalle is decidely strange. If we followed the same method for python-base, then we would a) instroduce python-base iff we had some package(s) written in python that we wanted in the base system (apt-listchanges comes to mind) b) include only the modules needed by the package(s). -- see shy jo signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 03:34:58PM -0500, Joey Hess wrote: If we followed the same method for python-base, then we would a) instroduce python-base iff we had some package(s) written in python that we wanted in the base system (apt-listchanges comes to mind) b) include only the modules needed by the package(s). Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Derivatives and the Version: field (Re: For those who care about their packages in Ubuntu)
On Wed, Jan 18, 2006 at 06:47:22PM -0800, Thomas Bushnell BSG wrote: In any case, I want to note what has just happened here. You received a clear, easily implemented, request about what would be a wonderful contribution, and which is (from the Debian perspective) entirely non-controversial. Your response was not to say yes, great! but rather to argue about whether these are things Debian should care about, and protest that they are not valuable and take too much work. What I saw was that a discussion with a practical point (treatment of the Maintainer field) was sidetracked because you started to focus on the Version field instead, and I asked you to justify your concern. Furthermore, regardless of whether you think it is easy, a global change of the Version field is not something that I can even consider making in the middle of our short release cycle, so it really isn't much of a priority at this time. The Maintainer field is something that I may be able to do something about, and I'm awaiting the results of Jeroen's poll on that. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backports
Em Qui, 2006-01-19 às 07:32 -0700, Joseph Smidt escreveu: I'm just intimadated by: I provide these files without any warranty. Use them at your own risk. If one of these packages eats your cat or your rabbit, kills your neighbour, or burns your fridge, don't bother me. Hmmm... Just thinking if you are using any GPL software at all... daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
* Matt Zimmerman [EMAIL PROTECTED] [2006-01-19 12:45]: Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. Why? Surely having a sub-set of python is better than nothing at all, no? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
On 10539 March 1977, Nathanael Nerode wrote: Congrats Jeroen van Wolfellaar, ftpmaster extraordinare, not afraid to take on the difficult cases (he also managed the REJECT on rte IRRC). Nope, he didnt reject rte. -- bye Joerg 16. What should you do if a security bug is discovered in one of your packages? 1) Notify [EMAIL PROTECTED] ASAP. 2) Notify upstream. 3) Try to create a patch. 4) Find out that Joey was faster. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-19 12:45]: Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. Why? Surely having a sub-set of python is better than nothing at all, no? One of the appealing things about the Python language is their batteries included philosophy: users can assume that the standard library is available, documentation and examples are written to the full API, etc. When it's broken into pieces, they get complaints and support requests from their user community when things don't work the way they should. It is already a source of frustration to them that we don't install python-dev with python. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Le Jeu 19 Janvier 2006 22:47, Matt Zimmerman a écrit : On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-19 12:45]: Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. Why? Surely having a sub-set of python is better than nothing at all, no? One of the appealing things about the Python language is their batteries included philosophy: users can assume that the standard library is available, documentation and examples are written to the full API, etc. When it's broken into pieces, they get complaints and support requests from their user community when things don't work the way they should. It is already a source of frustration to them that we don't install python-dev with python. IMHO, python-minimal has not to be a developpement environment that is viable as-is, but only what is needed to run the scripts that need it. That has to be stated clearly in the description of the package, so that nobody would assume anything about it. Honnestly, I would be really surprised that we can't find a consensus here, if it's needed one day (which currently isn't in Debian if I've followed that thread correctly enough). Ubuntu does not AFAICT the same size requirements as debian do for base, and I really think that python upstream can understand that the *full* python suite on a embeded device just does not makes sense. To me, this looks like a bad excuse. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcSotMgQyn8.pgp Description: PGP signature
Re: new mplayer 1.0pre7try2 package
On Jan 19, Nathanael Nerode [EMAIL PROTECTED] wrote: Is there an objection, or shall I file a serious bug against ffmpeg? Yes, I object to asking for removal of MPEG encoders because there is no good reason to do it. -- ciao, Marco signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
Le jeudi 19 janvier 2006 à 15:15 -0500, Nathanael Nerode a écrit : Is there an objection, or shall I file a serious bug against ffmpeg? The ffmpeg package doesn't include any faad, mp3, or other encoders for which patents are actively enforced. Therefore there is no reason to remove it from main. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thursday 19 January 2006 12:09, Adeodato Simó wrote: However, I'm pretty sure that more than one Developer thinks the proper interpretation would be: (b) this amendment overrules debian-legal's assessment that certain two clauses of the GFDL are non-free, and thus needs 1:1 Right. To declare that the amendment would constitute a modification of a foundation document is to presuppose the very issue that this amendment seeks to clarify, namely, whether or not the GFDL-minus-invariant-sections is indeed non-free. If the amendment passes, then GFDL-minus-invariant-sections docs would not be considered non-free, and so could be allowed in main without any special dispensation. The amendment is not intended to declare that we should suspend the DFSG for the sake of expediency; such a proposal would indeed require a 3:1 supermajority. Rather, it simply promulgates the interpretation that the GFDL, minus invariant sections, while not perfect, is still DFSG-free. No GR has declared the GFDL-minus-invariant-sections to be non-free. The GRs only decided to extend the DFSG to all of Debian, and then to postpone the application of this rule until after Sarge. The GFDL (with or without invariant sections) has been declared non-free with much controversy only by a very small set of developers, largely active on debian-legal, a body with no constitutional standing. While the Project finds it expedient to respect the general debian-legal consensus on most issues to avoid endless GRs on every subject, where there is a strong division of opinion within the developer body, or the decision will have important consequences, a GR to establish a license's status within the framework of the foundation documents seems wholly appropriate. The Project Secretary would be overstepping his or her authority to declare the interpretation of the license being proposed to be fundamentally in violation of the foundation documents _prior_ to any vote on the subject. He or she may hold a strong personal view on the matter, but cannot impose that view on the general shape of the vote. If the Secretary views the amendment as insufficiently clear as to what it is attempting to establish, then he or she can always request clarification. Cheers, Christopher Martin pgph1yVPpXsNM.pgp Description: PGP signature
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 01:47:18PM -0800, Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 09:23:30PM +, Martin Michlmayr wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-19 12:45]: Please don't do this; it implies that python-minimal would be part of base, but not full python, and this is something that python upstream explicitly objects to. Why? Surely having a sub-set of python is better than nothing at all, no? One of the appealing things about the Python language is their batteries included philosophy: users can assume that the standard library is available, documentation and examples are written to the full API, etc. When it's broken into pieces, they get complaints and support requests from their user community when things don't work the way they should. For what it's worth, we've caught hell from the ruby community for breaking the standard library in to its component parts and not installing it all by default. This problem has been largely abrogated as of late, but I'd rather not see us piss off the python community for making a similar mistake. That said, I don't really understand why it's Ok for Ubuntu to do this but not us. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: statement from one of the klik project members [was: The klik project and Debian]
On Thu, Jan 19, 2006 at 08:34:59PM +, Kurt Pfeifle wrote: And third, klik doesn't really install. It brings exactly 1 additional file (the *.cmg) onto the system. It works with user only privileges. Hang on. You loop-mount with user-only privileges? How? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote: That said, I don't really understand why it's Ok for Ubuntu to do this but not us. Ubuntu never installs python-minimal without python, even in base. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On 1/17/06, Wouter Verhelst [EMAIL PROTECTED] wrote: How about renaming Maintainer to Debian-Maintainer in Ubuntu's binary packages, and having a specific Ubuntu-Maintainer? This should probably happen in a way that all (or most) Debian-derived distro's agree on then. And one more problem: Ubuntu doesn't have the same maintainer concept as Debian has... -- JanC
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 03:18:48PM -0800, Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote: That said, I don't really understand why it's Ok for Ubuntu to do this but not us. Ubuntu never installs python-minimal without python, even in base. Ah, ok. Then why bother with the package at all then? Why not just make all of python Essential: yes? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Le jeudi 19 janvier 2006 à 18:05 -0500, Christopher Martin a écrit : Rather, it simply promulgates the interpretation that the GFDL, minus invariant sections, while not perfect, is still DFSG-free. But if this amendment passes, we would still have to modify the DFSG for the sake of consistency. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: when and why did python(-minimal) become essential?
On Thu, Jan 19, 2006 at 06:38:55PM -0500, David Nusinow wrote: On Thu, Jan 19, 2006 at 03:18:48PM -0800, Matt Zimmerman wrote: On Thu, Jan 19, 2006 at 05:58:20PM -0500, David Nusinow wrote: That said, I don't really understand why it's Ok for Ubuntu to do this but not us. Ubuntu never installs python-minimal without python, even in base. Ah, ok. Then why bother with the package at all then? Why not just make all of python Essential: yes? Because it has additional dependencies on packages which are not Essential: yes, and because -minimal is much smaller (if someone explicitly uninstalls it, along with the standard packages which depend on it), we can assume they are accepting the consequences). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thursday 19 January 2006 18:54, Josselin Mouette wrote: Le jeudi 19 janvier 2006 à 18:05 -0500, Christopher Martin a écrit : Rather, it simply promulgates the interpretation that the GFDL, minus invariant sections, while not perfect, is still DFSG-free. But if this amendment passes, we would still have to modify the DFSG for the sake of consistency. No, because as I wrote the whole point of the amendment is to make officially acceptable the interpretation of the license which views the license as flawed, but still DFSG-free. This amendment is in no way arguing for any sort of exception or modification or suspension of the DFSG. Therefore, no modification of the DFSG would be required after the passage of the amendment, since it would have been decided by the developers that there was no inconsistency. If you personally disagree with this, and believe that the GFDL, even without invariant sections, is inconsistent with the DFSG, then you may vote against the amendment. My above post was not intended to persuade the developers that they should vote for the amendment. Rather, it was attempting the clarify the proper status of the amendment, and therefore to correct the requirements for passage which the Secretary seems to have put upon it. Cheers, Christopher Martin pgpRlA4JW8SGG.pgp Description: PGP signature
Re: Re: statement from one of the klik project members [was: The klik project and Debian]
On Thu, Jan 19, 2006 at 08:34:59PM +, Kurt Pfeifle wrote: And third, klik doesn't really install. It brings exactly 1 additional file (the *.cmg) onto the system. It works with user only privileges. Hang on. You loop-mount with user-only privileges? How? The klik client installation needs root privileges once, to add 7 lines like this one to /etc/fstab: /tmp/app/1/image /tmp/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0 0 We know this is ugly (and a big limitation) -- but once Kernel 2.6.14 with FUSE will become more widespread, this will no longer be required. Cheers, Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, 19 Jan 2006 17:26:29 +0100, Adeodato Simó [EMAIL PROTECTED] said: * Debian Project Secretary [Thu, 19 Jan 2006 10:12:50 -0600]: The fact that the license is buggy does not change the fact that works licensed under it would violate the DFSG. Given that, any resolution to allow these works to remain in Debian would require a rider to be added to the SC, something of the form: - Debian will remain 100% free + Debian will remain 100% free, apart from works licensed under the GFDL (the exact wording can be decided upon if the amendment passes). Since this requires a modification of a foundation document, the amendment requires a 3:1 majority. I don't see why this _physical modification_ is necessary. I can admit that the secretary says this amendment overrules the social contract, since it talks about putting non-free things in main, so it requires a 3:1 majority; but if the amendment passes, and so the GR issues a statement that some GFDL documents will remain in main, I don't think explicit wording is needed _in_ the SC, at all. Umm, no. The social contract and the DFSG have stated the goals of the project, and have been given prominent status on the web site, and in other pronouncements. We hould not add codicils and riders that alter the meaning of the SC and not modify the SC document itself to record these modifications. manoj -- Try to divide your time evenly to keep others happy. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
* David Nusinow [EMAIL PROTECTED] [2006-01-19 17:58]: For what it's worth, we've caught hell from the ruby community for breaking the standard library in to its component parts and not installing it all by default. This problem has been largely abrogated as of late, but I'd rather not see us piss off the python community for making a similar mistake. I definitely agree we should listen to the Python community, especially with the lovely Martin v. Löwis doing so much good work for us. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Christopher Martin [EMAIL PROTECTED] writes: On Thursday 19 January 2006 12:09, Adeodato Simó wrote: However, I'm pretty sure that more than one Developer thinks the proper interpretation would be: (b) this amendment overrules debian-legal's assessment that certain two clauses of the GFDL are non-free, and thus needs 1:1 Right. To declare that the amendment would constitute a modification of a foundation document is to presuppose the very issue that this amendment seeks to clarify, namely, whether or not the GFDL-minus-invariant-sections is indeed non-free. If the amendment passes, then GFDL-minus-invariant-sections docs would not be considered non-free, and so could be allowed in main without any special dispensation. The amendment is not intended to declare that we should suspend the DFSG for the sake of expediency; such a proposal would indeed require a 3:1 supermajority. Rather, it simply promulgates the interpretation that the GFDL, minus invariant sections, while not perfect, is still DFSG-free. Ummm, so how exactly does declaring an interpretation of the DFSG as the one the project accepts constitute a modification? Are you telling me that when a judge interprets a law to make a ruling, that law has been changed in some way? -- Captain Logic is not steering this tugboat.
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, 19 Jan 2006, Christopher Martin wrote: No, because as I wrote the whole point of the amendment is to make officially acceptable the interpretation of the license which views the license as flawed, but still DFSG-free. This amendment is in no way arguing for any sort of exception or modification or suspension of the DFSG. The issue here devolves into a question of interpretation; if we can decide to interpret the Foundation Documents in any way we want simply by a majority vote, the requirement to have changes to them meet a 3:1 majority becomes rather pointless. Don Armstrong -- Filing a bug is probably not going to get it fixed any faster. -- Anthony Towns http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thursday 19 January 2006 20:39, Don Armstrong wrote: On Thu, 19 Jan 2006, Christopher Martin wrote: No, because as I wrote the whole point of the amendment is to make officially acceptable the interpretation of the license which views the license as flawed, but still DFSG-free. This amendment is in no way arguing for any sort of exception or modification or suspension of the DFSG. The issue here devolves into a question of interpretation; if we can decide to interpret the Foundation Documents in any way we want simply by a majority vote, the requirement to have changes to them meet a 3:1 majority becomes rather pointless. This is a real dilemma faced by all constitutions or similar charter documents. Unfortunately, all constitutions can be undermined by the reinterpretation of seemingly small details. But one person's undermining is another person's upholding. The important question here is one of legitimacy. Who exactly has the authority to determine these matters of interpretation? Specifically, who decides what is in accordance with the DFSG? The developers do, through GRs, if I understand correctly. Certainly nothing in my reading of the Constitution suggests that the Secretary has this power. The Secretary seems to be adopting the view that anyone who disagrees with his interpretation of the GFDL is not holding a legitimate opinion. Given the length of the GFDL debates, the acrimony, and the number of developers who remain on both sides, this seems far, far too strong a stance for a Project officer to adopt (even if Manoj holds that view personally). Hence my complaint. Cheers, Christopher Martin pgpcJG5oqDahE.pgp Description: PGP signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, 19 Jan 2006 21:11:11 -0500, Christopher Martin [EMAIL PROTECTED] said: The important question here is one of legitimacy. Who exactly has the authority to determine these matters of interpretation? Specifically, who decides what is in accordance with the DFSG? The developers do, through GRs, if I understand correctly. Certainly nothing in my reading of the Constitution suggests that the Secretary has this power. The secretary decides on the procedure of voting on a GR, and the final form the ballot may take. The secretary arrives at these decisions based on their best interpretation of the situation at hand. The Secretary seems to be adopting the view that anyone who disagrees with his interpretation of the GFDL is not holding a legitimate opinion. Given the length of the GFDL debates, the acrimony, and the number of developers who remain on both sides, this seems far, far too strong a stance for a Project officer to adopt (even if Manoj holds that view personally). Hence my complaint. Then hold a separate GR on whether or not the GFDL meets the DFSG -- aj's proposal, which states the GFDL licenced documents do not meet the DFSG is not subject to the 3:1 majority requirements. By moving to have GFDL licensed works included in main ahead of a determination of whether or not GFDL licensed works are free or not means that you have to accept the secretaries interpretation of reasonable arguments. Please note that I am not sure of the correctness of deciding by popular acclaim whether or not a licensed work meets the DFSG. But it is certainly one way of doing things. manoj -- Be careful when a loop exits to the same place from side and bottom. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages for sale
Thanks to those who saved me the time and hassle of filing some wnpp bugs. bricolage #348948 dbacl #348949 libcache-mmap-perl #348951 libmasonx-interp-withcallbacks-perl #348952 libparams-callbackrequest-perl #348953 libstring-crc32-perl #348954 scottfree #348950 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Christopher Martin [EMAIL PROTECTED] writes: On Thursday 19 January 2006 20:39, Don Armstrong wrote: On Thu, 19 Jan 2006, Christopher Martin wrote: No, because as I wrote the whole point of the amendment is to make officially acceptable the interpretation of the license which views the license as flawed, but still DFSG-free. This amendment is in no way arguing for any sort of exception or modification or suspension of the DFSG. The issue here devolves into a question of interpretation; if we can decide to interpret the Foundation Documents in any way we want simply by a majority vote, the requirement to have changes to them meet a 3:1 majority becomes rather pointless. This is a real dilemma faced by all constitutions or similar charter documents. Unfortunately, all constitutions can be undermined by the reinterpretation of seemingly small details. But one person's undermining is another person's upholding. The important question here is one of legitimacy. Who exactly has the authority to determine these matters of interpretation? Specifically, who decides what is in accordance with the DFSG? The developers do, through GRs, if I understand correctly. Certainly nothing in my reading of the Constitution suggests that the Secretary has this power. The Secretary seems to be adopting the view that anyone who disagrees with his interpretation of the GFDL is not holding a legitimate opinion. Given the length of the GFDL debates, the acrimony, and the number of developers who remain on both sides, this seems far, far too strong a stance for a Project officer to adopt (even if Manoj holds that view personally). Hence my complaint. I completely agree, and hereby question whether the secretary is capable of being impartial in this case given his personal interests[1] in this issue. [1] http://people.debian.org/~srivasta/Position_Statement.xhtml -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
