Reset of limits with su / new session
Hi all, while wondering about missing ulimits for an interactive session scheduled by SGE (SUN GridEngine) to a node in a cluster running on Debian (which is working fine with other Linux distributions), I also found, that each user can increase his limits again by a simple su to his own account: $ ulimit -t 55 $ ulimit -aH ... cpu time (seconds, -t) 55 ... $ su - reuti Password: $ ulimit -aH ... cpu time (seconds, -t) unlimited ... Digging around I finally found this: --- pam-0.76.orig/debian/patches-applied/ 027_pam_limits_better_init_allow_explicit_root +++ pam-0.76/debian/patches-applied/ 027_pam_limits_better_init_allow_explicit_root @@ -0,0 +1,100 @@ +Allow explicit limits for root. +Also, remove limits on su. +Index: Linux-PAM/modules/pam_limits/pam_limits.c Seems, that I can get the desired behavior by changing this back. But more interesting is the question: why was this patch applied to pam_ulimits.c in Debian? What is the advantage of allowing a user to circumvent any imposed limits? Cheers - Reuti -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making more packages binary NMU safe
On Mon, Jan 16, 2006 at 11:05:55PM -0600, Ken Bloom wrote: Here is the corresponding patch for that possibility. I hope the dpkg maintainers will pick up one of these patches quickly. You should submit them to the proper channels, then, i.e. either [EMAIL PROTECTED] or a bug report. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emphasize teams, not packages
[..] Future A: There are now 10,000 DD's and over 100,000 packages, most nobody uses, they are just there because they were needed by people who wanted to become DD's. Now that they are, those unused packages are ignored. A major upload occures and now there are 30,000 bugs on the BTS. Over 10,000 remain for months on these packages nobody cares about. The media speculates Debian will never again be stable, look at the bugs!!! Those who want to be DD's scramble for even more pointless packages, even more future bugs that will But why would you want to become a DD if you are not willing to maintain a package. Debian is just about maintaining packages. I agree there are other ways to contribute to Debian, but not much which do not involve being responsible for a package. I'm not a DD, and would like to become one to vote in some cases and to help more effectively in some (rare) cases. I already have a package which I maintain in the archive (and), mostly because I needed it, and it was being orphaned (well, to tell the truth, it was not maintained for a long time despite several important bugs), so I contacted the maintainer and took it over. But this is not my main contribution to Debian, I propose patches and close bugs for many packages I personally use or need for customers, and this is not recognized currently as sufficient for becoming a DD... and I'm not the only one. be ignored. People that do wan to fix some bugs won't know how and will apply for help from those who know nothing about their package and could care less. The bugs remain. This DD goes MIA in frustration. [..] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Regarding site linking and affiliation
Dear webmaster, I would like to introduce myself, T Damarla and my company, Louis Technologies (www.louistechnologies.net ). My company is a Software Development based in New Jersey. We recently launched a Web site named www.eazyrentals.com, which, as you'll see, provides rental information on nine major fields, along five different countries and access to our extensive product line. I would like to speak with you about establishing a potential linking relationship between our two organizations. Please take a few moments, at your convenience, to review my site, and I will look forward for your positive response to discuss this opportunity. If you have any questions in the meantime, feel free to e-mail me at [EMAIL PROTECTED] Best regards, T Damarla, Louis Technologies. -- 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
CC:ing -project because this is a project wide call for discussion. Am Montag, den 16.01.2006, 18:36 -0500 schrieb Joey Hess: Please consider ALL code written/maintained by me that is present in Ubuntu and is not bit-identical to code/binaries in Debian to be not suitable for release with my name on it. What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html There have been no responses which would indicate what we should do. There are clearly some Maintainers in Debian, who want their name in the maintainer field and some who don't want that. You are now making a request to not release binary packages with your name on it. I assume this does not include source packages as well, just binary packages. This is a call for discussion: What does debian actually want? Do we really need to include a white or black list (and what exactly?) in apt-get, apt-cache and co to disable/mangling the Maintainer field of packages just imported from Debian? Or can we live with an less intrusive approach? I'd prefer a solution which can be implemented in a reasonable time frame, and which ends this annoyingly heated discussion once and for all. -- Reinhard Tartler [EMAIL PROTECTED] signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: making more packages binary NMU safe
On Mon, 16 Jan 2006, Steve Langasek wrote: horrible, horrible kludge! No, the correct solution is to introduce two new variables and deprecate the old one, instead of further re-defining Source-Version in ways that have even less to do with the source version. Agreed. And why is this on -devel instead of on -dpkg, anyway? No idea. But while at it, why don't we provide Upstream-Version as well? (that's the version string minus any -[^-]*$ (extended regexp notation). That will give us a full suite of substitution vars for this stuff, and debian/rules scripts will not need to provide their own implementations of them. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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 Tue, 17 Jan 2006, Reinhard Tartler wrote: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html That's probably because different maintainers will have different opinions on this matter. packages just imported from Debian? Or can we live with an less intrusive approach? IMHO a if, and only if we modify it, we upload it with our name in changelog and uploaders field rule would be quite a good compromise. But that's my personal opinion, of course. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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 Tue, Jan 17, 2006 at 11:07:40AM +0100, Reinhard Tartler wrote: CC:ing -project because this is a project wide call for discussion. (-project is for discussion about the project, not for project wide stuff; dunno if this fits that) What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html http://lists.debian.org/debian-devel/2006/01/msg00966.html There have been no responses which would indicate what we should do. Actually, there've been lots, some of them are just contradictory. There are clearly some Maintainers in Debian, who want their name in the maintainer field and some who don't want that. FWIW, I haven't seen the ones who do want their name in the maintainer field. This is a call for discussion: What does debian actually want? Do we really need to include a white or black list (and what exactly?) Personally, I'd suggest: * for unmodified debs (including ones that have been rebuilt, possibly with different versions of libraries), keep the Maintainer: field the same * for debs in main that are modified, set the maintainer: field to the appropriate point of contact, and add a note to the copyright file as to the source you pulled from * for debs in universe that are modified, set the maintainer: field to the MOTU list or similar point of contact, and add a note to the copyright file * for maintainers who want to keep their name in the maintainer field, even when modified by Ubuntu, invite them to join Ubuntu in the usual manner * for changes that are likely to be useful in Debian or generally, submit the change upstream, by filing a bug with a minimal patch included to bugs.debian.org, or by the appropriate mechanism further upstream. That seems like it makes things fairly simple for you guys (no changes in the normal case, tweaking debian/control and debian/copyright when changes are needed), provides appropriate credit to debian maintainers, and provides a fairly simple and effective way of getting changes incorporated back in. I'd prefer a solution which can be implemented in a reasonable time frame, and which ends this annoyingly heated discussion once and for all. It's rare that heated discussions are ever done with once and for all IME. Though the emacs/vi wars are cooler now than they were a decade ago. Cheers, aj signature.asc Description: Digital signature
Re: [ad-hominem construct deleted]
On Tue, 17 Jan 2006, Robert Collins wrote: And yet most upstreams can get pretty much arbitrary code into Debian, just by committing it?. How many DD's read the -entire- diff on major version upgrades from upstream. And not just read, audit. Not all, but it might be quite a few more than what you seem to expect given the ammount of stressing you place on -entire- diff. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- 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
* Reinhard Tartler [Tue, 17 Jan 2006 11:07:40 +0100]: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2005/05/msg00260.html Yah, zero luck: http://lists.debian.org/debian-devel/2005/05/msg00077.html http://lists.debian.org/debian-devel/2005/05/msg00080.html -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org And don't get me wrong - I don't mind getting proven wrong. I change my opinions the way some people change underwear. And I think that's ok. -- Linus Torvalds -- 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
Am Dienstag 17 Januar 2006 11:07 schrieb Reinhard Tartler: Am Montag, den 16.01.2006, 18:36 -0500 schrieb Joey Hess: Please consider ALL code written/maintained by me that is present in Ubuntu and is not bit-identical to code/binaries in Debian to be not suitable for release with my name on it. What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html There have been no responses which would indicate what we should do. There are clearly some Maintainers in Debian, who want their name in the maintainer field and some who don't want that. You are now making a request to not release binary packages with your name on it. I assume this does not include source packages as well, just binary packages. This is a call for discussion: What does debian actually want? Do we really need to include a white or black list (and what exactly?) in apt-get, apt-cache and co to disable/mangling the Maintainer field of packages just imported from Debian? Or can we live with an less intrusive approach? I'd prefer a solution which can be implemented in a reasonable time frame, and which ends this annoyingly heated discussion once and for all. How about placing the Ubuntu-Maintainer as the official maintainer to whom bug reports etc would then be sent from Ubuntu users. As a reference to the original packaging work something like Debian-Maintainer field could be added. Whoever uploads a Debian package to Ubuntu should as the maintainer of the Debian package if they want to act as the official Ubuntun maintainer, too. I do not expect too many to say no if there is little overhead. Any investigation of bug reports that would require the installation of Ubuntu are not feasible for Debian maintainers. At the same time I would be disappointed if the BTS of Debian would not be shared between the distributions. Sigh. If the Ubuntu and the Debian developer are not the same person then they should work together at least, hey, they share some considerable interests. If both were DD, then both could be uploaders. People working at the core of Debian like Joey will have the one or other problem, but the normalo DD (ironic remarkor the normal member of the nm queue/ironic remark) I expect to experience very little issues since there is far too much and too diverse work out there and comparatively little reason to fight over it. Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348508: ITP: autodir -- Creates home, group directories for LDAP/NIS/SQL/local Unix accounts transparently
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine [EMAIL PROTECTED] * Package name: autodir Version : 0.99.0 Upstream Author : Venkata Ramana Enaganti [EMAIL PROTECTED] * URL : http://www.intraperson.com/autodir/ * License : Creative Commons Attribution License 2.0 Description : Creates home, group directories for LDAP/NIS/SQL/local Unix accounts transparently For license: http://creativecommons.org/licenses/by/2.0/legalcode (non-free) A modular and threaded tool to create and/or mounting and managing automagically and transparently user/group home directories, on demand. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- 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 Tue, 17 Jan 2006, Anthony Towns wrote: On Mon, Jan 16, 2006 at 09:45:29PM -0500, Eric Cooper wrote: I saw today that the python-minimal package in unstable is tagged as Essential (and currently pulls in python2.3). According to policy, this is supposed to happen only after discussion on debian-devel and consensus is reached, but I couldn't find that discussion in the list archives. I've changed the override to Priority: standard; I can't say I'm remotely impressed by how this has been handled. Could this be stopped, please? I don't know much about the Debian base management, but if I recall correctly, Python used to be kept away specifically to stop the base bloat. A quick comparison of fresh unconfigured i386 chroots: 94420 woody 146140 sarge 160264 etch 185444 sid a +25MB increase, even though etch is nearly in sync. With standard/important packages, you simply don't install them; removing required/essential ones is not trivial. Extra bloat doesn't noticeably hurt Ubuntu because Ubuntu doesn't try to support memory sticks, old hardware, embedded things or farms of tiny virtual machines; Debian does. No one cares about wasting some memory and disk space on a modern desktop. Also, I can't think of any important packages that need Python. Let's check a few of my systems: * firewall/squid/WWW/samba/mail/DNS server (Sarge, headless) apt-listchanges, reportbug * Postgres/MySQL (Sarge, headless) apt-listchanges * firewall/squid/DNS cache (Sarge, headless) apt-listchanges * router (Sarge, headless) - * desktop (Sid) apt-listchanges, reportbug, btdownloadcurses (IIRC, it's off) So, it's not a matter of scripts that exist but a matter of possible future stuff. And since the DDs who work on base all have good sets of skills at least in Perl ans Bash, keeping Python at standard or less won't really hurt anything. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- 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 Tue, Jan 17, 2006 at 09:45:13PM +1000, Anthony Towns aj@azure.humbug.org.au wrote: * for changes that are likely to be useful in Debian or generally, submit the change upstream, by filing a bug with a minimal patch included to bugs.debian.org, or by the appropriate mechanism further upstream. s/or/and/. There's no reason that should prevent the ubuntu maintainer to forward his patch to upstream AND debian. Mike -- 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 Tue, Jan 17, 2006 at 01:28:07PM +0100, Adam Borowski wrote: On Tue, 17 Jan 2006, Anthony Towns wrote: I've changed the override to Priority: standard; I can't say I'm remotely impressed by how this has been handled. Could this be stopped, please? I am not sure why you are replying to Anthony, if you read his mail, you see that he *has* stopped this. I guess this was a honest mistake from Matthias, he accidently uploaded a package not stripped of the Ubuntu-specific Essential: yes tags. This is unfortunate, but no reason for the world to end. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Size matters. Debian binary package stats
Am 2005-12-28 22:33:10, schrieb Benjamin Seidenberg: Seriously? Where? I live in the states, and we pay approx. $50/month (600 USD/year) for residential DSL (I think, parents pay the bill). That's a 1.5m down/512k up pipe, with horrible reliability (alltel sucks). Where can I get the fiber optic for $10/year? I was talking about a E3, STM-1/4 or something similar. Here in Strasbourg we have ADSL with 8MBit downstream and 0.5 to 1 MBit upstream for 30-55 Euros. Generaly these ADSL lines are ADSL2+ with 16 MBit, but 8 MBit are reserved for TV and Telephone. I use an 1 MBit SDSL (incl. 8 IP fix and free Reverse DNS Service) from http://www.nerim.net/ for 253 Euros. Speed is with warantie. and service 24/7 Benjamin Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) -- 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 Tue, Jan 17, 2006 at 01:28:07PM +0100, Adam Borowski wrote: A quick comparison of fresh unconfigured i386 chroots: 94420 woody 146140 sarge That's a bit more than I would've expected; though the sarge chroots are notably be more functional than woody ones. 160264 etch I get 131140 on powerpc, after running apt-get clean. You can lose another 14M by clearing out /var/lib/apt/lists. /usr/share/locale also takes up a fair chunk. Removing all that, I get 91656 total. 185444 sid a +25MB increase, even though etch is nearly in sync. Well, except for python... That only looks like it should account for ~17MB though, so there might be more to it. Note that you can remove base packages fairly happily (or avoid installing them in the first place, with some care); it's only required/essential packages that are really difficult to avoid. Note that python2.4-minimal should only be an extra 2.5M, compared to an extra 12.4MB for python2.4 (or 10.5MB for python2.3, which is what python-minimal currently equates to). Cheers, aj signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
On Tue, 17 Jan 2006, Michael Banck wrote: On Tue, Jan 17, 2006 at 01:28:07PM +0100, Adam Borowski wrote: On Tue, 17 Jan 2006, Anthony Towns wrote: I've changed the override to Priority: standard; I can't say I'm remotely impressed by how this has been handled. Could this be stopped, please? I am not sure why you are replying to Anthony, if you read his mail, you see that he *has* stopped this. Hey, since when replying to someone implies that you disagree with him? It can as well be a case of AOL -- and I provided some arguments to help his case in what appeared to be a start of a possible flamewar. I guess this was a honest mistake from Matthias, he accidently uploaded a package not stripped of the Ubuntu-specific Essential: yes tags. I was just whining about: Obviously, python2.4-minimal is what Ubuntu includes in its essential set; so presumably the idea is to move Debian to a similar arrangement. no reason for the world to end. You're underestimating the grave consequences of losing 25MB off every memory stick and virtual machine. The increased costs of hardware will topple our economy, and the extra power drawn by the equipment will accelerate the global warming to a point where Earth will turn into bad-sf style land of lava and inferno within our lifetime. And you'll struggle to survive with the knowledge that I warned you. -- /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Estella
Hello, beauty, Bolden See you Bolden Bolden Bolden Bolden Bolden Bolden Bolden Bolden Bolden Bolden -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical's business model
Manoj Srivastava writes (Re: Canonical's business model): What would I *like* to see? Well, that they treat me like I treat my upstreams; I triage bug reports, I keep feature specific patches separate, I submit these feature requests to upstream BTS, or upstream author, depending on their preference. I triage, confirm, and pass along bug reports to upstream BTS, with any additional data that can serve to shine a light on the actual problem. Quite so. This is what I personally try to do (whether I'm working on Ubuntu or on some local mutation of a Debian package). In other words, I would like to see people downstream treat me like I treat my upstream. Exactly. I know that not all Ubuntu developers do this and I think that's a shame. (This is one of many problems exacerbated by the lack of good process documentation in Ubuntu.) Not only is that bad for Debian, and so unneighbourly, it's only a short-term gain in effort anyway - doing a good job of feeding patches upstream is the most effective way of reducing one's own maintenance effort. Ian. (wearing Ubuntu hat just at the moment) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Anthony Towns writes: On Mon, Jan 16, 2006 at 09:45:29PM -0500, Eric Cooper wrote: I saw today that the python-minimal package in unstable is tagged as Essential (and currently pulls in python2.3). According to policy, this is supposed to happen only after discussion on debian-devel and consensus is reached, but I couldn't find that discussion in the list archives. Joerg approved it at 09:50:15 2006/01/15, after Doko uploaded a new python-defaults package (-4). I've no idea why he accepted it as Priority:required and Essential:yes, and given that python-minimal isn't any different to regular python (though presumably will be if we ever switch to python2.4), I can't see why it was uploaded at this point. The -5 upload removed the Essential:yes tag, and lowered the priority to standard (apparently due to apt automatically installing Essential:yes packages and thus screwing up people who've pinned stable or testing, see #348354, and #348319), but since the override was already set at required, that's what the Priority: field still shows. yes, that was a merge error on my side, fixed in -5. Maybe Doko's been paying attention to all the folks saying Ubuntu should contribute back more? no need to spoil the lists with foul language Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Thomas Bushnell BSG writes (Re: Need for launchpad): Actually, upstream maintainers have no voice before the technical committee, which exists to resolve disputes between Debian developers, not between Debian developers and outsiders. This is not true. Constitution s6 defines the powers of the TC and there is no restriction that the TC can consider only the complaints of Developers. 6.3(6) says that the TC basically only acts when prompted but does not say that the prompt has to come from a DD. 6.1(4) has an example suggesting that a bug submitter can be upheld. An upstream maintainer could file a bug in the Debian BTS and dealt with in the normal way, if they felt strongly enough. Of course, the TC only overrules the Debian maintainer (whether in favour of upstream or in any other way) if the TC agrees with a 3:1 majority to do so. Ian. (wearing TC chair hat) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Survey on Debian contributors
Dear Debian contributors, The Hypermedia lab at the University of Tampere, Finland is doing a survey on free/open source software (FOSS) communities. We ask Debian contributors, including developers, bug fixers, documentation writers, testers, packagers and coordinators to participate in the survey. Please take a few minutes to answer the survey at http://hiisi.fi/survey/debian We hope the survey will increase our understanding of the structure of FOSS communities and company participation in FOSS. The research is part of the project Managing Open Source Software as an Integrated Part of Business (http://coss.fi/ossi/). Results of the survey will be available publically later this year. You may contact me with any questions or comments. Thanks, -- Researcher Niklas Vainio Hypermedia Laboratory University of Tampere, Finland Weblog: http://hiisi.fi/blog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to determine complete reverse dependencies?
I wrote a script on the train this morning to determine the complete reverse dependencies for a specified set of packages, for both RPM and DEB. http://www.pixelbeat.org/scripts/whatrequires It works as expected on my fedora core 3 laptop. However when trying it on my ubuntu breezy desktop, I noticed some missing dependencies. For e.g. imagemagick isn't reported to depend on libc6 ? $ whatrequires libc6 | grep imagemagick $ ldd /usr/bin/convert | grep libc libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7a1b000) So I'm wondering is this a bug in the imagemagick package dependencies, or am I doing something stupid? I'm sorry if this is the wrong list or an obvious question. But my excuse is that I've only been using debian for a couple of weeks. thanks, Pádraig. -- 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 Tue, Jan 17, 2006 at 02:31:47PM +0100, Adam Borowski wrote: You're underestimating the grave consequences of losing 25MB off every memory stick and virtual machine. python-minimal is about two megabytes installed, with no non-Essential dependencies. (strictly an observation of fact; I'm not expressing an opinion either way about the change) -- - 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 Tue, Jan 17, 2006 at 09:45:13PM +1000, Anthony Towns wrote: On Tue, Jan 17, 2006 at 11:07:40AM +0100, Reinhard Tartler wrote: There have been no responses which would indicate what we should do. Actually, there've been lots, some of them are just contradictory. There was a lot of discussion, much of which took place without a clear understanding of the technical issues involved. I attempted to summarize those and present the questions in a clear and unequivocally answerable fashion, and I did not in fact receive a single answer. Now, eight months later, some of the same discussions are being rehashed without considering the issues and questions that I put forth in that summary message. Personally, I'd suggest: * for unmodified debs (including ones that have been rebuilt, possibly with different versions of libraries), keep the Maintainer: field the same Joey Hess and others in this thread have said that this is not acceptable to them. What I need from Debian is either a clear consensus resulting from discussion among developers, or an official decision from a position of authority. Otherwise, we'd just be chasing our tail trying to please individuals with conflicting opinions. * for debs in main that are modified, set the maintainer: field to the appropriate point of contact, and add a note to the copyright file as to the source you pulled from * for debs in universe that are modified, set the maintainer: field to the MOTU list or similar point of contact, and add a note to the copyright file These two are equivalent, so we don't need to treat main and universe separately. * for maintainers who want to keep their name in the maintainer field, even when modified by Ubuntu, invite them to join Ubuntu in the usual manner I don't see how this would help. If we were to institute a policy (or more likely, an automated process) to change the maintainer field, inviting the maintainer to become an Ubuntu developer wouldn't have any obvious effect on the process. What did you have in mind here? * for changes that are likely to be useful in Debian or generally, submit the change upstream, by filing a bug with a minimal patch included to bugs.debian.org, or by the appropriate mechanism further upstream. Let's not conflate these entirely separate issues. I'd prefer a solution which can be implemented in a reasonable time frame, and which ends this annoyingly heated discussion once and for all. It's rare that heated discussions are ever done with once and for all IME. Though the emacs/vi wars are cooler now than they were a decade ago. There will always be differing personal preferences, but in spite of these, there are times when an organization needs to take an official position on behalf of its members, even if they don't all agree, so that other organizations can respond to it with confidence. If a consensus can't be reached informally, that's what I think we will need. -- - 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 Tue, 2006-01-17 at 09:32 -0800, Matt Zimmerman wrote: On Tue, Jan 17, 2006 at 02:31:47PM +0100, Adam Borowski wrote: You're underestimating the grave consequences of losing 25MB off every memory stick and virtual machine. python-minimal is about two megabytes installed, with no non-Essential dependencies. (strictly an observation of fact; I'm not expressing an opinion either way about the change) The python-minimal I see depends on all of python2.3. In Ubuntu perhaps it's 2MB, but in Debian right now it's almost all of Python. -- Joe Wreschnig [EMAIL PROTECTED] -- 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 Tue, Jan 17, 2006 at 09:58:28AM -0200, Henrique de Moraes Holschuh wrote: On Tue, 17 Jan 2006, Reinhard Tartler wrote: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html That's probably because different maintainers will have different opinions on this matter. I cannot recall any time when differing opinions have resulted in silence on a Debian mailing list. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Mon, Jan 16, 2006 at 04:04:09PM -0800, Matt Zimmerman wrote: The ratio of Debian developers to upstream developers is *much* closer to 1:1 than the ratio of Ubuntu developers to Debian developers, Obviously; but still, I'd appreciate it if people responsible downstream for my packages would have a name, rather than being 'some random Ubuntu person'. It'd probably be great if Ubuntu would set up (or, if it already exists, advertise) some way to have a canonical way (no pun intended) to contact the Ubuntu maintainer (or, if no such person exists, the responsible Ubuntu team) for a given package. Something like the @packages.debian.org alias would be wonderful, but something else would work, too. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
* Matt Zimmerman [EMAIL PROTECTED] [2006-01-16 15:39]: On Sun, Jan 15, 2006 at 02:59:58AM +0100, Gerfried Fuchs wrote: It's not about succeeding. It's about false statements all the time, like Every Debian developer is also an Ubuntu developer. If I were I would know. And they are recompiling all my packages, so you can't even say that they are using my packages directly. Is the meaning of this statement truly unclear to you, or is this purely a rhetorical point? Under the assumption that you read it differently than I do, I'll attempt to explain. Do we call RMS a Debian developer? Do we call Linus a Debian Developer? Does anyone seriously consider that? Pardon, but that's ridiculous. I don't have upload permission at all, can't do anything about my packages, there are changed packages with still my name as maintainer that I never got any information about -- and you still have the guts to call me a Ubuntu developer? Sorry for laughing into your face for that... It's also about false statements like We sync our packages to Debian regularly, because that simply doesn't happen for quite a lot of us, otherwise all these heated discussions wouldn't happen. Given that you saw this on a wiki page, a disclaimer about wiki contents should be implicit. It's still as cite from Mark on there, and I don't think that the cite is wrong. Or do you rather consider your fellow developers putting false statements intenionally there? However, regardless of whether it's an accurate quote, it's quite clear to me from context that your interpretation doesn't match the text. My interpretation of regularly and sync and _especially_ the We most hopefully doesn't vary very much with that of most people. The full quote is We sync our packages to Debian regularly, because that introduces the latest work, the latest upstream code, and the newest packaging efforts from a huge and competent open source community. Without Debian, Ubuntu would not be possible. It should be obvious from the remainder of the sentence that it is talking about propagation of changes *from* Debian *to* Ubuntu. Then I guess the to should be changed into a from, just to get the direction where the sync really happens and what you are willing to really do straight with the reality. It was inappropriate for this user to raise this issue with you, rather than with Ubuntu, but that's been discussed elsewhere in this thread already. So? There is the Maintainer field that still has my name and my email address in it as being responsible for that very package -- where I can't do anything against it. That's simply wrong. What I find interesting about your statement is that you seem to imply that the situation would have been better if you had been notified that your package was a part of Ubuntu. Then I would had been able to a.) check if someone might add changes, b.) to check if my address and name is in the changed package, and c.) inform the person at hand that I don't think that the changes make much sense and if there are changes needed for ubuntu that they should at least have the courtsey to leave me out of the Mainainer field, becasue again: _I_ can't do anything for the package in ubuntu. I have no upload rights there. Yes, the situation would had been _immensly_ been better. It would had shown at least that Ubuntu cares for its upstream. This would be technically simple to implement, but I'm not convinced that it's possible to do it in a socially acceptable way. Emailing every Debian maintainer to notify them that their package is present in Ubuntu sounds like spam to me, and posting Ubuntu-related announcements to Debian mailing lists has been deemed inappropriate by many in Debian as well. From first I knew only that there is this Ubuntu which goes for one CD with gnome and xorg on it. I thought fine, I don't have a package in that range, so why should it bother me too much, so I didn't check. Do you really think that everyone in Debian is aware that there exist a thing like multiverse or whatever which seems to include every single package that is in Debian? I wasn't, for a very long time. An announce along that lines instead of a press release so you can add d-d-a to your announce lists would hadn't stirred up so much bad blood, don't you think so? The creation of Ubuntu was *very* widely publicized, as was the fact that it was based on Debian, and this fact has been mentioned countless times since, both in the press and on Debian mailing lists. But it wasn't really mentioned that it includes every single package that is out there Again, beside that, it would had been a courtsey to change the Maintainer field, or send patches back. Applying patches and leaving the Maintainer field to a DD is just terribly impolite, because the Maintainer isn't the maintainer anymore and can't do anything about it, and additionally doesn't get informed at all about the changes! I ask you,
Re: How to determine complete reverse dependencies?
Pádraig Brady [EMAIL PROTECTED] wrote: [...] However when trying it on my ubuntu breezy desktop, I noticed some missing dependencies. For e.g. imagemagick isn't reported to depend on libc6 ? $ whatrequires libc6 | grep imagemagick $ ldd /usr/bin/convert | grep libc libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7a1b000) Please note that ldd is the wrong tool, as it will also list indirect linking (foo links directly against libbar which in turn links against libblah). objdump -p /usr/bin/convert | grep NEEDED works better. So I'm wondering is this a bug in the imagemagick package dependencies, or am I doing something stupid? [...] It is a bug, which has already been fixed in Debian unstable with this upload: --- Date: Sat, 17 Sep 2005 01:00:09 +0200 imagemagick (6:6.2.4.5-0.1) unstable; urgency=low [...] * debian/control: Use shlibs information to generate Depends line for imagemagick binary package. --- cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- 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 Tue, Jan 17, 2006 at 09:25:40AM -0800, Matt Zimmerman wrote: [snip] There will always be differing personal preferences, but in spite of these, there are times when an organization needs to take an official position on behalf of its members, even if they don't all agree, so that other organizations can respond to it with confidence. If a consensus can't be reached informally, that's what I think we will need. Why would Debian need to take an official position on behalf of its members? Yes, I can see that it would be in Ubuntu's best interest for Debian to do so, but since it's obvious from this discussion that different Debian developers have different opinions on this issue, it's clearly not in Debian's best interest. Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- 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 Tue, Jan 17, 2006 at 11:07:40AM +0100, Reinhard Tartler wrote: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: [...] This is a call for discussion: What does debian actually want? Do we really need to include a white or black list (and what exactly?) in apt-get, apt-cache and co to disable/mangling the Maintainer field of packages just imported from Debian? Or can we live with an less intrusive approach? How about renaming Maintainer to Debian-Maintainer in Ubuntu's binary packages, and having a specific Ubuntu-Maintainer? As Ubuntu recompiles all Debian packages anyway, this would only require a (fairly minor) patch to dpkg-gencontrol. This would make it crystal clear that Debian's packages in Ubuntu are maintained by Ubuntu people, while you're not dropping the credit for the Debian maintainer who's put in a lot of work; and for packages that have not seen any Ubuntu-specific patches, you could leave out the Ubuntu-Maintainer field (while still renaming the Maintainer field to Debian-Maintainer). -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- 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 Mon, 16 Jan 2006, Joey Hess wrote: Please consider ALL code written/maintained by me that is present in Ubuntu and is not bit-identical to code/binaries in Debian to be not suitable for release with my name on it. Then how would d-i+debconf have gotten some of the enhancments that you yourself have blogged about? -- 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
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: * for unmodified debs (including ones that have been rebuilt, possibly with different versions of libraries), keep the Maintainer: field the same Joey Hess and others in this thread have said that this is not acceptable to them. What I need from Debian is either a clear consensus resulting from discussion among developers, or an official decision from a position of authority. Otherwise, we'd just be chasing our tail trying to please individuals with conflicting opinions. Maybe I missed something, but has someone actually said they'd be unhappy if the Maintainer: field was an appropriate Ubuntu person? Some might be alright with leaving Maintainer alone if the package hasn't been changed, some might be alright with leaving it the same even if the package has been changed and some might always want it changed, I don't expect you'll get a concensus on that. I'd be suprised if someone was actually unhappy with the Maintainer field changing though. Of course, don't submit a patch back to Debian which includes changing the Maintainer field. * for maintainers who want to keep their name in the maintainer field, even when modified by Ubuntu, invite them to join Ubuntu in the usual manner I don't see how this would help. If we were to institute a policy (or more likely, an automated process) to change the maintainer field, inviting the maintainer to become an Ubuntu developer wouldn't have any obvious effect on the process. What did you have in mind here? It's similar to my comment above- set the maintainer to an appropriate Ubuntu person, which would naturally be the Ubuntu package maintainer, who might also be the Debian package maintainer. Really, though, this isn't a Debian concern or problem- if the Ubuntu developers are complaining about an automated Maintainer-changing script then that's an issue Ubuntu needs to deal with and figure a way around, or just ignore. It's certainly not an excuse to leave the Maintainer field alone. Thanks, Stephen signature.asc Description: Digital signature
Re: Survey on Debian contributors
Hi, Am Dienstag, den 17.01.2006, 18:20 +0200 schrieb Niklas Vainio: Please take a few minutes to answer the survey at http://hiisi.fi/survey/debian Some suggestions: Surveys from a university should have a place on the university's webserver -- they look official. Question 11 (income): Is this before of after taxes? If you are free to choose, I suggest after taxes -- gross salaries are very difficult to compare. Thomas -- 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 Tue, 17 Jan 2006, Anthony Towns wrote: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html http://lists.debian.org/debian-devel/2006/01/msg00966.html Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Tue, Jan 17, 2006 at 06:52:10PM +0100, Wouter Verhelst wrote: On Mon, Jan 16, 2006 at 04:04:09PM -0800, Matt Zimmerman wrote: The ratio of Debian developers to upstream developers is *much* closer to 1:1 than the ratio of Ubuntu developers to Debian developers, Obviously; but still, I'd appreciate it if people responsible downstream for my packages would have a name, rather than being 'some random Ubuntu person'. It'd probably be great if Ubuntu would set up (or, if it already exists, advertise) some way to have a canonical way (no pun intended) to contact the Ubuntu maintainer (or, if no such person exists, the responsible Ubuntu team) for a given package. Something like the @packages.debian.org alias would be wonderful, but something else would work, too. Unfortunately, something like @packages.debian.org doesn't map very well to how our development team is organized. Of course, [EMAIL PROTECTED] will reach the right people, but it also has too much traffic to be very reliable for this sort of thing. As I've said before, I'm happy to act as a point of contact personally, and pass on any communications from Debian developers to the appropriate team or individual within Ubuntu, wherever there is a doubt about who to contact. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 12:46:52PM -0600, Adam Heath wrote: On Tue, 17 Jan 2006, Anthony Towns wrote: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html http://lists.debian.org/debian-devel/2006/01/msg00966.html Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). I would very much appreciate if folks would review http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the points that I raise there. I put some effort into collating the issues which came up the last time and presenting them. It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: I would very much appreciate if folks would review http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the points that I raise there. I put some effort into collating the issues which came up the last time and presenting them. It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. You're already rebuilding the package, which I expect entails possible Depends: line changes and other things which would pretty clearly 'normally' entail different Debian package revision numbers; changing the Maintainer field at the same time is just not that hard, *especially* when you're rebuilding the package. You're implying that this is alot of work and it's just not. It's also not 'forking' in any real sense of the word. You don't even have to change the version number if you don't want to. When done in Debian, it's also not even a new source package (in general anyway) as the thing which has the Maintainer field is actually the patch. As I've pointed out before, this also just plain isn't Debian's problem. You keep asking for Debian to tell you what 'should' be in the Maintainer field but then you're ignoring the answer because you think it's hard. It's pretty clear what 'Debian' thinks *should* be in the field, or at least what most people would agree with; sorry that it's not the simple answer you want but you asked. Thanks, Stephen signature.asc Description: Digital signature
Re: For those who care about their packages in Ubuntu
Joey Hess wrote: FYI, I refuse to allow the fact that my code happens to be present in a currently perceived as high profile distribution to hold my time hostage. I've never done it before with other high profile distributions (Corel's mangling of alien comes to mind), and I won't start now. The correct action in these circumstances is a sufficiently evolved killfile. Please consider ALL code written/maintained by me that is present in Ubuntu and is not bit-identical to code/binaries in Debian to be not suitable for release with my name on it. FWIW, the with my name on it was the least significant bit of the above message although it seems to be the only bit anyone paid attention to. I have killfiles; I cannot stop people from releasing software with my name on it; it's not a big deal. But don't expect me to do your QA or maintenance for you if you do so. The parent message was an attempt to get Debian developers to take on that responsibility for software outside Debian, and this Debian developer will not do that. -- see shy jo signature.asc Description: Digital signature
Re: For those who care about lesbians
Andrew Suffield wrote on 15/01/2006 05:20: [I know the below quote has been directly linked to the 2005/08 incident of which I know no details - not being a DD yet myself - but I assume you would hold the same opinion with respect to your recent d-d-a post] I fail to see how expressing a simple opinion like that, which is not even an uncommon one, *on a private mailing list*, could possibly be 'detrimental to the project'. That is pure slander. Well, your post to d-d-a is potentially somewhat detrimental to the project. Had you simply made a post like the following, probably nobody would have cared. I even wouldn't have cared if you had made your d-d-a post to d-d instead. Now here is what would probably been OK: - cut here - Subject: To all who care about the quality of d-d-a This list is about the Debian project and important news to and from it's developers. Please refrain from posting off-topic stuff on this list. Needing to make it a moderated list would be a shame. - cut here - Irony and sarcasm on big public mailinglists is always a problem, especially if there are some corporate staff people also reading the list and - at least partially - judging the whole project by the contents of that list. Apart from your posts intention (which I wholeheartedly agree with), I can't agree with the form you took. However, even though I agree with your intention (of keeping d-d-a as close to its topic as possible), I don't really see anything too bad about Raphael Herzog's post. Sure, he talks about Ubuntu a lot, but his whole point is how Debian and Ubuntu could cooperate more closely, giving Debian Developers information about where they can find stuff on Ubuntu's side. Hell, his post asking both sides for cooperation is on topic on d.d.a as on (whatever the equivalent for ubuntu would be) IMHO. regards, Sven signature.asc Description: OpenPGP digital signature
Re: [ad-hominem construct deleted]
On Tue, Jan 17, 2006 at 06:46:26PM +0100, Gerfried Fuchs wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-16 15:39]: Is the meaning of this statement truly unclear to you, or is this purely a rhetorical point? Under the assumption that you read it differently than I do, I'll attempt to explain. Do we call RMS a Debian developer? Do we call Linus a Debian Developer? Does anyone seriously consider that? 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. Pardon, but that's ridiculous. I don't have upload permission at all, can't do anything about my packages, there are changed packages with still my name as maintainer that I never got any information about -- and you still have the guts to call me a Ubuntu developer? Sorry for laughing into your face for that... It isn't productive to take this kind of jeering tone. Given that you saw this on a wiki page, a disclaimer about wiki contents should be implicit. It's still as cite from Mark on there, and I don't think that the cite is wrong. Or do you rather consider your fellow developers putting false statements intenionally there? I'm saying that you should pause and consider that you're looking at a world-writable resource before treating its contents as a position statement on behalf of the project, and that malicious intent is far from the only (or even the most common) reason for errors. It could very well be that Mark or someone else originally wrote from Debian and the quote was transcribed incorrectly. In any case, as I said, I think the meaning of the sentence as a whole is sufficiently unambiguous, though for the sake of clarity I will ask Mark to look and correct it if appropriate. It was inappropriate for this user to raise this issue with you, rather than with Ubuntu, but that's been discussed elsewhere in this thread already. So? There is the Maintainer field that still has my name and my email address in it as being responsible for that very package -- where I can't do anything against it. That's simply wrong. This had been commonplace for Debian derivatives for years before Ubuntu existed, and when the issue was raised regarding Ubuntu, I asked for input from the Debian community as to what to do. The issue is not at all obvious, and in fact it's quite similar to the attribution of upstream authors of packages which are modified in Debian, which is even older. What I find interesting about your statement is that you seem to imply that the situation would have been better if you had been notified that your package was a part of Ubuntu. [...] Yes, the situation would had been _immensly_ been better. It would had shown at least that Ubuntu cares for its upstream. Ubuntu has been in communication with Debian, primarily on this and other Debian mailing lists, about what we are doing since before the project even had a name. We've been very vocal about our development process, which essentially amounts to a branch of the Debian archive. I don't think that a credible claim could be made that Debian was not notified that Ubuntu includes packages from Debian. This is what it means to be a derivative. This would be technically simple to implement, but I'm not convinced that it's possible to do it in a socially acceptable way. Emailing every Debian maintainer to notify them that their package is present in Ubuntu sounds like spam to me, and posting Ubuntu-related announcements to Debian mailing lists has been deemed inappropriate by many in Debian as well. From first I knew only that there is this Ubuntu which goes for one CD with gnome and xorg on it. I thought fine, I don't have a package in that range, so why should it bother me too much, so I didn't check. Do you really think that everyone in Debian is aware that there exist a thing like multiverse or whatever which seems to include every single package that is in Debian? I wasn't, for a very long time. Debian, too, distributes software via networked mirrors which is not included on the official CDs. There is nothing surprising or devious in this. An announce along that lines instead of a press release so you can add d-d-a to your announce lists would hadn't stirred up so much bad blood I haven't a clue what you're talking about here. What press release, and how does d-d-a enter into it? The creation of Ubuntu was *very* widely publicized, as was the fact that it was based on Debian, and this fact has been mentioned countless times since, both in the press and on Debian mailing lists. But it wasn't really mentioned that it includes every single package that is out there Ubuntu is, and always has been, a branch of sid. This has been pointed out, among other places, on debian-devel and on the front page of LWN. Not a subset or a miniature distribution, but a derivative of the complete Debian
Re: For those who care about their packages in Ubuntu
On Tue, Jan 17, 2006 at 07:01:42PM +0100, David Weinehall wrote: On Tue, Jan 17, 2006 at 09:25:40AM -0800, Matt Zimmerman wrote: [snip] There will always be differing personal preferences, but in spite of these, there are times when an organization needs to take an official position on behalf of its members, even if they don't all agree, so that other organizations can respond to it with confidence. If a consensus can't be reached informally, that's what I think we will need. Why would Debian need to take an official position on behalf of its members? Yes, I can see that it would be in Ubuntu's best interest for Debian to do so, but since it's obvious from this discussion that different Debian developers have different opinions on this issue, it's clearly not in Debian's best interest. In my opinion, it's much more practical and reasonable for there to be an agreement on consistent treatment of all packages, than for each Debian derivative to try to please individual maintainers with differing tastes on this subject. -- - 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
Matt Zimmerman [EMAIL PROTECTED] writes: In my opinion, it's much more practical and reasonable for there to be an agreement on consistent treatment of all packages, than for each Debian derivative to try to please individual maintainers with differing tastes on this subject. Your strategy seems to be to do something which pisses off almost everyone who has been near it, with your excuse being that there is not absolute unanimity on the alternative. Notice that there is no agreement that what you are doing now is right, and to boot, it's contrary to the Debian policy manual too. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Yes. Being a downstream modifier imposes costs. Debian meets those costs, how about you? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On Tue, Jan 17, 2006 at 10:34:57AM -0800, Matt Zimmerman wrote: On Tue, Jan 17, 2006 at 06:52:10PM +0100, Wouter Verhelst wrote: It'd probably be great if Ubuntu would set up (or, if it already exists, advertise) some way to have a canonical way (no pun intended) to contact the Ubuntu maintainer (or, if no such person exists, the responsible Ubuntu team) for a given package. Something like the @packages.debian.org alias would be wonderful, but something else would work, too. Unfortunately, something like @packages.debian.org doesn't map very well to how our development team is organized. Of course, [EMAIL PROTECTED] will reach the right people, but it also has too much traffic to be very reliable for this sort of thing. As I've said before, I'm happy to act as a point of contact personally, and pass on any communications from Debian developers to the appropriate team or individual within Ubuntu, wherever there is a doubt about who to contact. That's always an extra step, and while I'm sure you'll do your best to do this as good as possible, there's always going to be the problem that it won't work when you're too busy with other things. I don't know the details of how Ubuntu works, but I understand that while it's basically a free-for-all regarding package uploads, there's still some informal feeling that most packages have a one or few people who're responsible for them, and do most (if not all) of their uploads. If an @packages.debian.org doesn't really fit, do you think something like the Latest News section on packages.qa.debian.org (aka the PTS) would work? That way, a Debian Developer could easily see which Ubuntu developer or MOTU does the most work on one's packages (or did the last upload), in case it would be necessary. And for the case that most of such uploads are either automated or done by a different person every time, you could add a 'generic' contact address to that page. This would make it a *lot* easier for me to find out who to talk to when I think my package has been abused, or when something important for my package, something that could use some coordination, is coming up. 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. [1] yes, I'm exaggerating here, but I'm just trying to convey an emotion; I hope you understand what I mean. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: I would very much appreciate if folks would review http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the points that I raise there. I put some effort into collating the issues which came up the last time and presenting them. In my point of view, maintainer field just need to be change when Ubuntu does a non-trivial change on it. Otherwise, at least to me, is OK to leave the maintainer field unchanged. Directly imported source (that will be just recompiled by Ubuntu) doesn't need to be change since it's the same source code that runs on Debian. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- 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 Tue, Jan 17, 2006 at 11:07:40AM +0100, Reinhard Tartler wrote: CC:ing -project because this is a project wide call for discussion. Am Montag, den 16.01.2006, 18:36 -0500 schrieb Joey Hess: Please consider ALL code written/maintained by me that is present in Ubuntu and is not bit-identical to code/binaries in Debian to be not suitable for release with my name on it. What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: Well, there some points where I have voiced my opinion to some Ubuntu developers rather than here. I did not know debian-devel was the correct place to send that. 1) No changes rebuild-only upload should still be versionned so that we do not end up with two .deb with the same version but different contents. Rebuilding a package with a newer toolchain can cause different dependencies and bugs. 2) I find a bit odd to be called the maintainer of a package I did not test and that I cannot change anyway. 3) The name of the Ubuntu developers which have tested the package before uploading it is not mentionned in the case of a no-changes upload. I am refraining from assuming there were none. 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 Tue, 17 Jan 2006, Matt Zimmerman wrote: Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). I would very much appreciate if folks would review http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the points that I raise there. I put some effort into collating the issues which came up the last time and presenting them. It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Modify the incoming processor, so that the Packages and Sources files get the correct info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 17 Jan 2006, Matt Zimmerman wrote: Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). I would very much appreciate if folks would review http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the points that I raise there. I put some effort into collating the issues which came up the last time and presenting them. It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Actually, ignore my last mail. I actually considered that you(ubuntu) would respond thusly. But, it doesn't fly. We don't allow J. Random Upstream to upload unchanged source into Debian. We add meta-data, and set the Maintainer field appropriately. This is so that Debian becomes the contact for the software, when it exists in Debian. Debian derivaties need to do the same. There really is no other way. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 17 Jan 2006, Otavio Salvador wrote: In my point of view, maintainer field just need to be change when Ubuntu does a non-trivial change on it. Otherwise, at least to me, is OK to leave the maintainer field unchanged. Directly imported source (that will be just recompiled by Ubuntu) doesn't need to be change since it's the same source code that runs on Debian. But linked against other libraries. The binary is downloaded from another location(or installed from a different cd set). The program used to do the download may be different. While the above list may not be all inclusive, it's enough to warrant changing the Maintainer field to something ubuntu specific. Debian doesn't set the upstream author in the Maintainer field, when the changes only amount to adding a debian directory to the upstream source. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Apology for MIA, Retiring, RFA: x-symbol, xmix, oneko
* Steve Dunham [EMAIL PROTECTED] wrote: I'd like to offer these three packages for adoption: x-symbol, xmix, and oneko. x-symbol is probably the most used of these and needs someone who knows emacsen and a little TeX. I would also love to see a recent version of x-symbol in Debian. However, upstream seems to be dead, too. The last version was released in 2003 and is a beta. :-( Regards, Marcus -- Zapp Brannigan: You win again, gravity! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 12:37:47PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Yes. Being a downstream modifier imposes costs. Debian meets those costs, how about you? We really don't need a stand-in for Andrew Suffield while he's away. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Development standards for unstable
* Thomas Viehmann: I think that not shipping unmaintained and unsupported packages is a benefit. Packages need a maintainer to enter, I think they should need one to stay. A real problem is that willingness to maintain a package in unstable is not as good a predictor as you might think for the future situation in stable. I'm talking about mainly about security bugs, of course. I'm not really sure how to address this (I plan to implement my proposed opt-in approach in March or April, although it's far from a complete solution). A strict policy-based approach which rejects packages with no support perspective (based on past experience) would certainly result in a very painful transition. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Canonical's business model
Le dimanche 15 janvier 2006 à 19:55 +0200, Martin-Éric Racine a écrit : I personally appreciate the excellent work done by Ubuntu. Just looking at major GNOME improvements that directly resulted from Ubuntu efforts (by Debian Developers such as Sébastien Bacher) clearly shows how Ubuntu helps the free desktop evolve by leaps and bounds. I would like to know which GNOME improvements you are talking about. To my knowledge, there are much more improvements going from Debian to Ubuntu than the other way around. -- .''`. 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: For those who care about their packages in Ubuntu
On Tue, Jan 17, 2006 at 12:37:15PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: In my opinion, it's much more practical and reasonable for there to be an agreement on consistent treatment of all packages, than for each Debian derivative to try to please individual maintainers with differing tastes on this subject. Your strategy seems to be to do something which pisses off almost everyone who has been near it, with your excuse being that there is not absolute unanimity on the alternative. That simply isn't true, and taken at face value, it's insulting, because you attribute malicious intent. What I am doing is asking the Debian community for opinions on the appropriate thing for Debian derivatives to do. In response, you've been unnecessarily hostile, argumentative and accusatory. There's simply no cause for it. The most productive thing you could do in this situation would be to read my mail from last May and (politely and thoughtfully) answer the questions therein. Don't you realize how much easier it would be to ignore these issues entirely, rather than endure these harangues just for the sake of trying to collect information? Why do you think I would bother if I just wanted to piss you off? Notice that there is no agreement that what you are doing now is right, and to boot, it's contrary to the Debian policy manual too. Nonsense. What we are doing now amounts basically to inaction, is consistent with how Debian derivatives have worked in the past, and has no relevance whatsoever to the Debian policy manual. Please read the previous threads on this subject. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 03:07:25PM -0500, Stephen Frost wrote: You're already rebuilding the package, which I expect entails possible Depends: line changes and other things which would pretty clearly 'normally' entail different Debian package revision numbers; changing the Maintainer field at the same time is just not that hard, *especially* when you're rebuilding the package. You're implying that this is alot of work and it's just not. It's also not 'forking' in any real sense of the word. You don't even have to change the version number if you don't want to. When done in Debian, it's also not even a new source package (in general anyway) as the thing which has the Maintainer field is actually the patch. You quite obviously haven't read http://lists.debian.org/debian-devel/2005/05/msg00260.html yet, where I wrote (among other important things), it would be fairly straightforward for Ubuntu to override the Maintainer field in binary packages. I explained exactly what is and isn't difficult and for whom. If you're going to attack me, please do it on the basis of what I've actually said. Honestly, I expected better from you, give that you've acted like a human being toward me on IRC on several occasions in the past. -- - 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?
Joe Wreschnig writes: On Tue, 2006-01-17 at 09:32 -0800, Matt Zimmerman wrote: On Tue, Jan 17, 2006 at 02:31:47PM +0100, Adam Borowski wrote: You're underestimating the grave consequences of losing 25MB off every memory stick and virtual machine. python-minimal is about two megabytes installed, with no non-Essential dependencies. (strictly an observation of fact; I'm not expressing an opinion either way about the change) The python-minimal I see depends on all of python2.3. In Ubuntu perhaps it's 2MB, but in Debian right now it's almost all of Python. correct, the change was made to introduce the package name, so that the package doesn't stick in the NEW queue, when we actually do the change. two other packages were introduced, so it only needs to be approved one time by the FTP masters. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 03:50:09PM -0600, Adam Heath wrote: On Tue, 17 Jan 2006, Matt Zimmerman wrote: Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). I would very much appreciate if folks would review http://lists.debian.org/debian-devel/2005/05/msg00260.html and consider the points that I raise there. I put some effort into collating the issues which came up the last time and presenting them. It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Modify the incoming processor, so that the Packages and Sources files get the correct info. The .dsc and .diff.gz would still have the original values, and the copyright file can't be modified this way. -- - 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
Le mardi 17 janvier 2006 à 12:46 -0600, Adam Heath a écrit : On Tue, 17 Jan 2006, Anthony Towns wrote: What I find very dissapointing is that mdz asked on debian-devel twice for a decision from debian how ubuntu should handle the maintainer Field without any luck: http://lists.debian.org/debian-devel/2006/01/msg00678.html http://lists.debian.org/debian-devel/2005/05/msg00260.html http://lists.debian.org/debian-devel/2006/01/msg00966.html Debian developers set the Maintainer field to themselves(or a team), when they upload to Debian. The upstream author is only mentioned in the copyright file. Ubuntu should do something similiar. Set the Maintainer field to someone from their group, and mention debian in the copyright(or other appropriate place). Even better, they could stop crediting themselves for changes initiated by Debian developers. http://lists.ubuntu.com/archives/ubuntu-news/2005-December/33.html -- .''`. 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: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman: It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Such a change could be implemented in the toolchain. IIRC, you rebuild everything anyway, so this wouldn't be such a terrible thing to do. FWIW, I think your implied assumption that all Debian derivatives should be treated the same is flawed. Ubuntu is just not like any other derivative, it's a significant operation on its own. Its commercial backer is apparently able to pay quite a few Debian developers, several of them among the core team. There is a significant user base, and so on. Like it or not, Ubuntu is a bit special. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#348103: ITP: kde-icons-gorilla -- gorilla icons for kde
Le samedi 14 janvier 2006 à 21:26 +0100, Sune Vuorela a écrit : * Package name: kde-icons-gorilla Version : 1.4 Upstream Author : Patrick Yavitz pyavitz (at) gmail.com * URL : http://kde-look.org/content/show.php?content=6927 * License : GPL Description : Yellowish gorilla icons for kde Gorilla icon set for kde. Brings monkey spirit to your desktop These icons are already in gnome-themes-extras. Isn't there a way to avoid having the same files in two packages? -- .''`. 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: [ad-hominem construct deleted]
On Mon, Jan 16, 2006 at 06:39:37PM -0600, John Hasler wrote: Matt Zimmerman writes: Is the meaning of this statement truly unclear to you... Every Debian developer is also an Ubuntu developer implies to me that I can make uploads to Ubuntu. I can't (not that I'm asking for that privilege). I don't doubt that it was meant as an expression of gratitude and camaraderie, but it does not come across that way. Perhaps Every Debian developer is, in a sense, also an Ubuntu developer might get the point across more clearly. On behalf of those of you who insist on this interpretation, I've already suggested that the wording might be improved, even though I personally think that it's fine as-is. Emailing every Debian maintainer to notify them that their package is present in Ubuntu sounds like spam to me... It doesn't to me. I am pleased when downstream distributions notify me that they are using my packages. Have you ever received such a notification? There are hundreds of distributions based on Debian, and more appearing all the time. Distributions based on Ubuntu are using your packages as well. How much unsolicited mail is too much? -- - 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
Matt Zimmerman [EMAIL PROTECTED] writes: On Tue, Jan 17, 2006 at 12:37:15PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: In my opinion, it's much more practical and reasonable for there to be an agreement on consistent treatment of all packages, than for each Debian derivative to try to please individual maintainers with differing tastes on this subject. Your strategy seems to be to do something which pisses off almost everyone who has been near it, with your excuse being that there is not absolute unanimity on the alternative. That simply isn't true, and taken at face value, it's insulting, because you attribute malicious intent. Um, I have said nothing about your intent. I think you are desperate to do whatever minimizes your costs. What I am doing is asking the Debian community for opinions on the appropriate thing for Debian derivatives to do. Right, because you are now interested in scalability. If you were *really* interested in scalability, then you wouldn't adopt the wonderful hey, all the patches are on our website, come and get 'em! approach. You have not ever shown a serious interest in what Debian would like. Which is *fine*, you don't need to. But then, geez, stop pretending you are a great cooperator with Debian. In response, you've been unnecessarily hostile, argumentative and accusatory. There's simply no cause for it. The most productive thing you could do in this situation would be to read my mail from last May and (politely and thoughtfully) answer the questions therein. Do what has *already been suggested*. You need to be using different version numbers *anyway* if you are recompiling the packages. So given that you are doing that (right?!) it is no trouble to adjust the fields. Don't you realize how much easier it would be to ignore these issues entirely, rather than endure these harangues just for the sake of trying to collect information? Why do you think I would bother if I just wanted to piss you off? I didn't say you want to piss anyone off. What I said was that what you are doing is having that effect. I think it's a reaction you wish didn't happen, but not so much that you are willing to change Ubuntu's practices. Notice that there is no agreement that what you are doing now is right, and to boot, it's contrary to the Debian policy manual too. Nonsense. What we are doing now amounts basically to inaction, is consistent with how Debian derivatives have worked in the past, and has no relevance whatsoever to the Debian policy manual. Please read the previous threads on this subject. No, you are distributing packages with incorrect Maintainer fields. That's not inaction, it's a specific action. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: You quite obviously haven't read http://lists.debian.org/debian-devel/2005/05/msg00260.html yet, where I wrote (among other important things), it would be fairly straightforward for Ubuntu to override the Maintainer field in binary packages. I explained exactly what is and isn't difficult and for whom. Notice that what you say, in response to what has been asked over and over, is my opinion is that changing the Maintainer field on otherwise-unmodified source packages is too costly for derivatives in general. But you say nothing about why. You already have suitable automated tools. Since you are rebuilding the package, you *must* change the version number *anyway*. It is not correct to recompile, and leave the version number alone. If you were not recompiling, then no modification would be necessary. Moreover, what about category (2), packages which are modified? Since you are making a new source package *anyway*, why is it so expensive? In response to your questions, as if they haven't been answered: If a binary package is built by a third party from unmodified Debian sources, should its Maintainer field be kept the same as the source package, or set to the name and address of the third party? If the third party has their own bug-tracking system, then the Maintainer field should probably be changed. The original Debian Maintainer should still be acknowledged. Should Debian-derived distributions change the Maintainer field in source packages which are modified relative to Debian? If so, should this be done in all cases, or only if the modifications are non-trivial? In absolutely every case, the Maintainer field should be changed if you have altered the source in any respect. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, Jan 18, 2006 at 12:34:33AM +0100, Florian Weimer wrote: * Matt Zimmerman: It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Such a change could be implemented in the toolchain. IIRC, you rebuild everything anyway, so this wouldn't be such a terrible thing to do. We don't rebuild every source package, which is what the proposal was about (modifying source packages). I outlined the options and their costs as I saw them here: http://lists.debian.org/debian-devel/2005/05/msg00260.html FWIW, I think your implied assumption that all Debian derivatives should be treated the same is flawed. Ubuntu is just not like any other derivative, it's a significant operation on its own. Its commercial backer is apparently able to pay quite a few Debian developers, several of them among the core team. There is a significant user base, and so on. Like it or not, Ubuntu is a bit special. I can't accept this; if there is no principle here which should be applied consistently, then it's entirely unfair to attack Ubuntu. Certainly, there are things about Ubuntu which are unique, but none of them change the issues at hand. 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. Seriously, it's entirely unreasonable to single out Ubuntu on this issue. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348607: ITP: gtkedit -- Notepad clone based on GTK+
Package: wnpp Severity: wishlist * Package name: gtkedit Version : 0.1/b1 Upstream Author : Daniel Guerrero [EMAIL PROTECTED] * URL or Web page : http://gtkedit1.sourceforge.net * License : MIT Description : Notepad clone based on GTK+ GTKEdit is a lightweight Notepad clone designed for low performance systems It is currently in Ubuntu REVU http://revu.tauware.de/details.py?upid=1523 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 11:44:48AM -0800, Matt Zimmerman wrote: It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Ubuntu is different in that they rebuild all packages, not just the one they changes. 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 Tue, Jan 17, 2006 at 06:19:32PM -0600, Bill Allombert wrote: On Tue, Jan 17, 2006 at 11:44:48AM -0800, Matt Zimmerman wrote: It is important, in particular, to account for the fact that Ubuntu is not the only Debian derivative, and that proposals like yours would amount to Debian derivatives being obliged to fork *every source package in Debian* for the sake of changing a few lines of text. Ubuntu is different in that they rebuild all packages, not just the one they changes. The matter at hand above was source packages, not binary packages. Besides which, do you honestly know which packages other Debian derivatives rebuild? As a rule, they are far less communicative about their practices than Ubuntu. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: Besides which, do you honestly know which packages other Debian derivatives rebuild? As a rule, they are far less communicative about their practices than Ubuntu. How does the behavior of other Debian derivatives matter? As a rule, those other derivatives do not cooperate with Debian. If Ubuntu wants to be like them, fine, but don't say you cooperate with Debian if that's what you want to do. Thomas -- 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 Tue, Jan 17, 2006 at 04:05:35PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: That simply isn't true, and taken at face value, it's insulting, because you attribute malicious intent. Um, I have said nothing about your intent. I think you are desperate to do whatever minimizes your costs. If that were true, you wouldn't be having this conversation with me. It is costing me an unreasonable amount of time to deal with this trivial issue, and I've spent a disproportionate amount of it going in circles with you. I'm quickly losing interest in discussing this with you at all, to be honest. You have not ever shown a serious interest in what Debian would like. This is, again, insulting, and nonsensical in the face of the repeated dialogues I have initiated and participated in with Debian developers regarding Ubuntu practices. Debian deserves better than to be represented by this kind of behavior. -- - 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
Matt Zimmerman [EMAIL PROTECTED] writes: If that were true, you wouldn't be having this conversation with me. It is costing me an unreasonable amount of time to deal with this trivial issue, and I've spent a disproportionate amount of it going in circles with you. I'm quickly losing interest in discussing this with you at all, to be honest. Then, um, don't. Doesn't affect me either way. You have not ever shown a serious interest in what Debian would like. This is, again, insulting, and nonsensical in the face of the repeated dialogues I have initiated and participated in with Debian developers regarding Ubuntu practices. Can you describe the cases in which you have altered your practices in response to the views of Debian developers? I refer not to technical decisions or particular patches, but rather, things on the level of policy and overall structure. As far as I can tell, you have not done any such. This makes it seem unlikely that you really are willing to entertain such changes. Perhaps, though, I have missed. You have attempted to convince Debian that what you are doing is already cooperation, but that is not the same thing as a serious interest in what Debian would like. Instead, you have tried to convince us that what you are providing is what we should like. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
I wrote: I am pleased when downstream distributions notify me that they are using my packages. mdz writes: Have you ever received such a notification? Yes. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 04:09:50PM -0800, Thomas Bushnell BSG wrote: Notice that what you say, in response to what has been asked over and over, is my opinion is that changing the Maintainer field on otherwise-unmodified source packages is too costly for derivatives in general. But you say nothing about why. You already have suitable automated tools. I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. Since you are rebuilding the package, you *must* change the version number *anyway*. It is not correct to recompile, and leave the version number alone. 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. Moreover, what about category (2), packages which are modified? Since you are making a new source package *anyway*, why is it so expensive? If you re-read your own quote above, you'll see that I was talking about otherwise-unmodified source packages, not source packages which were modified anyway, and if you re-read http://lists.debian.org/debian-devel/2005/05/msg00260.html, you'll see that my second question simply asked whether this would be appropriate. In response to your questions, as if they haven't been answered: So far I've received two clear responses in this thread. I do like jvw's idea of setting up a poll, and that will be a much more effective way to collect opinions on this. I've sent him my proposed options for the poll. I do expect, however, for this decision to be taken with regard to all Debian derivatives, and not to single out Ubuntu with a different set of criteria. -- - 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 Tue, Jan 17, 2006 at 04:58:40PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: If that were true, you wouldn't be having this conversation with me. It is costing me an unreasonable amount of time to deal with this trivial issue, and I've spent a disproportionate amount of it going in circles with you. I'm quickly losing interest in discussing this with you at all, to be honest. Then, um, don't. Doesn't affect me either way. Done. -- - 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 Tue, Jan 17, 2006 at 09:25:40AM -0800, Matt Zimmerman wrote: Personally, I'd suggest: * for unmodified debs (including ones that have been rebuilt, possibly with different versions of libraries), keep the Maintainer: field the same Joey Hess and others in this thread have said that this is not acceptable to them. What I need from Debian is either a clear consensus resulting from discussion among developers, Well, you're not going to get one when you're too busy telling us everything we suggest is wrong. All I can imagine you doing is encouraging people to even more firmly want nothing to do with Ubuntu. or an official decision from a position of authority. Otherwise, we'd just be chasing our tail trying to please individuals with conflicting opinions. If you're trying to do the right and best thing, we've got something to talk about. But asking for official decisions from a position of authority looks more like a way of finding someone else for people to blame. Cheers, aj signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. It's really a very short perl script, or a simple modification in C to the dpkg-building tools. Indeed, if you said, hey, we would like to do this, but need someone to write the tool for us you might well find volunteers. Since you are rebuilding the package, you *must* change the version number *anyway*. It is not correct to recompile, and leave the version number alone. 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. Actually, binary-only NMUs, after the first compilation, *do* get new version numbers. I do expect, however, for this decision to be taken with regard to all Debian derivatives, and not to single out Ubuntu with a different set of criteria. No other Debian derivative, as far as I'm aware, says that it cooperates fully with Debian. Thomas -- 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 Tue, Jan 17, 2006 at 04:58:40PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: If that were true, you wouldn't be having this conversation with me. It is costing me an unreasonable amount of time to deal with this trivial issue, and I've spent a disproportionate amount of it going in circles with you. I'm quickly losing interest in discussing this with you at all, to be honest. Then, um, don't. Doesn't affect me either way. Thomas, if you don't care about a topic please don't waste all of our time while you browbeat your opposition (and in this case, fellow Debian developer) in to the ground. Some of us who do care might want to see something positive come out of this long and painful thread. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, 2006-01-17 at 17:29, Thomas Bushnell BSG 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. Actually, binary-only NMUs, after the first compilation, *do* get new version numbers. In Debian yes. Ubuntu recompiles the Debian source, in a different environment and with different dependencies, then uploads with exactly the same version as Debian. Having two different package files with the exactly the same name and different content and dependencies drove me crazy for a while until we made our migration scripts smarter. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making more packages binary NMU safe
Steve Langasek wrote:
On Mon, Jan 16, 2006 at 10:53:04PM -0600, Adam M. wrote:
Ken Bloom wrote:
I noticed that glabels is broken on i386 because it's not binary NMU
safe, and someone did a binary NMU.
After poking around a bit, I found
http://lists.debian.org/debian-dpkg/2005/11/msg0.html, which
discussed a possible solution to this problem. Since then, we have
changed the version number format for binary NMUs, so I wanted to submit
a patch (based on the one mentioned previously) to allow the creation
more binNMU safe packages.
Instead of doing blind substitutions like it is done currently, it is
possible to separate Arch:all from Arch:any|other|whatever in the
substitution script such that,
Source-Version = bin NMU version for binaries that are build
Source-Version = 'original' version for Arch:all binaries
Which would mean the value of the ${Source-Version} substitution would have
to change based on which *package name* preceded it in the control file --
horrible, horrible kludge! No, the correct solution is to introduce two new
variables and deprecate the old one, instead of further re-defining
Source-Version in ways that have even less to do with the source version.
And why is this on -devel instead of on -dpkg, anyway?
Because I didn't know where to send it so it wouldn't get lost. But now
that Michael Banck told me where to send it, I'll send it to
[EMAIL PROTECTED]
--Ken
--
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel size (was: Re: when and why did python(-minimal) become essential?)
Adam Borowski [EMAIL PROTECTED] writes: Extra bloat doesn't noticeably hurt Ubuntu because Ubuntu doesn't try to support memory sticks, old hardware, embedded things or farms of tiny virtual machines; Debian does. No one cares about wasting some memory and disk space on a modern desktop. Speaking of which, I recently tried to install a standard debian kernel on my home machine (I normally build my own kernels), and was ultimately defeated because that machine has a fairly small root partition, and the linux-image package required _45 MB_ of disk space! Does the installed kernel reay need 45 MB...? Granted, it's been a while, but I used to use standard debian kernels on this machine in the 2.4 days, and don't remember any bloat problems quite this bad. [The exact package was linux-image-2.6.15-1-686 2.6.15-2] -Miles -- The car has become... an article of dress without which we feel uncertain, unclad, and incomplete. [Marshall McLuhan, Understanding Media, 1964] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Mike Bird [EMAIL PROTECTED] writes: On Tue, 2006-01-17 at 17:29, Thomas Bushnell BSG 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. Actually, binary-only NMUs, after the first compilation, *do* get new version numbers. In Debian yes. Ubuntu recompiles the Debian source, in a different environment and with different dependencies, then uploads with exactly the same version as Debian. Right. I was contradicting Matt's statement that This isn't even the case within Debian. -- 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
David Nusinow [EMAIL PROTECTED] writes: On Tue, Jan 17, 2006 at 04:58:40PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: If that were true, you wouldn't be having this conversation with me. It is costing me an unreasonable amount of time to deal with this trivial issue, and I've spent a disproportionate amount of it going in circles with you. I'm quickly losing interest in discussing this with you at all, to be honest. Then, um, don't. Doesn't affect me either way. Thomas, if you don't care about a topic please don't waste all of our time while you browbeat your opposition (and in this case, fellow Debian developer) in to the ground. Some of us who do care might want to see something positive come out of this long and painful thread. I do care about the topic. I do not care about Matt's ego. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 04:38:29PM -0800, Matt Zimmerman wrote: On Tue, Jan 17, 2006 at 04:09:50PM -0800, Thomas Bushnell BSG wrote: Notice that what you say, in response to what has been asked over and over, is my opinion is that changing the Maintainer field on otherwise-unmodified source packages is too costly for derivatives in general. But you say nothing about why. You already have suitable automated tools. I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. Huh? Of course you do -- it's called make. Since you are rebuilding the package, you *must* change the version number *anyway*. It is not correct to recompile, and leave the version number alone. 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. However if a binNMU screws up a maintainer's package, the maintainer can easily fix it, and doing so is just part of contributing to Debian. The same thing applies when an autobuild on another architecture happens. That's not the case if an Ubuntu rebuild screws things up. Cheers, aj signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: No other Debian derivative, as far as I'm aware, says that it cooperates fully with Debian. Other than, say, the DCC Alliance? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
John Hasler [EMAIL PROTECTED] wrote: mdz writes: Have you ever received such a notification? Yes. I haven't. I'm going to cry now :-((( -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matthew Garrett [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] wrote: No other Debian derivative, as far as I'm aware, says that it cooperates fully with Debian. Other than, say, the DCC Alliance? I wasn't aware of them until just now. :) Interestingly, the DCC Alliance says that it wants to become part of Debian. Do you have information on their plans with respect to the issues discussed in this thread? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] writes: Other than, say, the DCC Alliance? I wasn't aware of them until just now. :) Wow! Interestingly, the DCC Alliance says that it wants to become part of Debian. Do you have information on their plans with respect to the issues discussed in this thread? The DCCA distribution is a mixture of packages from Sarge plus some backports. In all cases, the Maintainer: field appears to be the same as in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are supposed to be using these packages in an unmodified form, as I understand it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 18 Jan 2006, Matthew Garrett wrote: Patch clauses only prohibit code reuse if your build system is insufficiently complicated. And you are willing to contain an entire copy of the codebase from which you are extracting. [Unless the patch clause is per-file...] Oh, sure. But bandwidth and disk space are relatively cheap commodities compared to what they used to be. If the Linux source tree contained an entire copy of the BSD kernel source, I doubt anyone would really bat an eyelid. It's certainly an inconvenience, but I don't think it really prevents anything of any great interest. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matthew Garrett [EMAIL PROTECTED] writes: Interestingly, the DCC Alliance says that it wants to become part of Debian. Do you have information on their plans with respect to the issues discussed in this thread? The DCCA distribution is a mixture of packages from Sarge plus some backports. In all cases, the Maintainer: field appears to be the same as in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are supposed to be using these packages in an unmodified form, as I understand it. Have they modified these packages? What do they do about version numbering of recompilations? (Do they recompile?) Do they modify the packages at all? It seems like they aren't doing the things which annoy me in the case of Ubuntu, but it's possible I don't understand enough. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 07:23:41PM -0800, Thomas Bushnell BSG wrote: Matthew Garrett [EMAIL PROTECTED] writes: The DCCA distribution is a mixture of packages from Sarge plus some backports. In all cases, the Maintainer: field appears to be the same as in Debian. Several derived distributions (gnuLinEx, Knoppix, Mepis, Linspire, Progency, Sun-Wah, UserLinux (ha ha ha) and Xandros) are supposed to be using these packages in an unmodified form, as I understand it. Have they modified these packages? Some of them, yes. Mostly the backports. What do they do about version numbering of recompilations? (Do they recompile?) They have to recompile the backports, at least. I haven't checked the MD5s of the binaries, but that's easy enough to do. Do they modify the packages at all? As stated, in some cases yes. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matthew Garrett [EMAIL PROTECTED] writes: Have they modified these packages? Some of them, yes. Mostly the backports. What happens to the maintainer field in these cases? Certainly, if they are modifying the packages, I would think the same there here applies as in the case of Ubuntu: they should reset the Maintainer field to point to themselves, and continue to give credit to the Debian developer in a suitable fashion. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 07:32:20PM -0800, Thomas Bushnell BSG wrote: Matthew Garrett [EMAIL PROTECTED] writes: Have they modified these packages? Some of them, yes. Mostly the backports. What happens to the maintainer field in these cases? I haven't seen any that have been changed. Certainly, if they are modifying the packages, I would think the same there here applies as in the case of Ubuntu: they should reset the Maintainer field to point to themselves, and continue to give credit to the Debian developer in a suitable fashion. The founder of Debian seems to disagree, but still. The DCCA situation suggests that we need to define exactly what we want and make it clear to all derived distributions that this is what we expect. This isn't something that only affects Ubuntu - we're talking about a large number of fairly major distributions. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348625: ITP: puppet -- centralised configuration management for networks
Package: wnpp Severity: wishlist Owner: Jamie Wilkinson [EMAIL PROTECTED] * Package name: puppet Version : 0.11.1 Upstream Author : Luke Kanies [EMAIL PROTECTED] * URL : http://reductivelabs.com/projects/puppet/ * License : GPL Description : centralised configuration management for networks Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. Puppet's simple declarative specification language provides powerful classing abilities for drawing out the similarities between hosts while allowing them to be as specific as necessary, and it handles dependency and prerequisite relationships between objects clearly and explicitly. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ironies abound (was Re: GPL v3 draft)
Glenn Maynard [EMAIL PROTECTED] wrote: On Wed, Jan 18, 2006 at 03:21:14AM +, Matthew Garrett wrote: I'm not going to defend patch clauses. I think they're massively horrible things, and the world would be a better place without them. But deciding that they're not free any more would involve altering our standards of freedom, and I don't see any way that we can reasonably do that. It's disappointing, then, that Debian is so fixed in stone that it's incapable of correcting its mistakes. Declaring patch clauses non-free isn't correcting a mistake. It's stating that the entire community's definition of freedom is wrong. Patch clauses have been acceptable for longer than Debian has existed. The degree of freedom they provide has, if anything, increased with improvements in technology. -- Matthew Garrett | [EMAIL PROTECTED] -- 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 Tuesday 17 January 2006 16:54, Matt Zimmerman wrote: You have not ever shown a serious interest in what Debian would like. This is, again, insulting, and nonsensical in the face of the repeated dialogues I have initiated and participated in with Debian developers regarding Ubuntu practices. Debian deserves better than to be represented by this kind of behavior. What BSG writes is the feeling I'm getting from you as well. This is not Planet Ubuntu, Debian doesn't exist purely to source Ubuntu. I'm personally tired of the attitude from Ubuntu users and developers alike that this is Planet Ubuntu. -- Paul Johnson Email and IM (XMPP Google Talk): [EMAIL PROTECTED] Got Jabber? http://ursine.ca/Ursine:Jabber pgpFMwVfN7DAX.pgp Description: PGP signature
Re: Ironies abound (was Re: GPL v3 draft)
I do apologise. These should plainly have been on -legal. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 04:54:36PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Besides which, do you honestly know which packages other Debian derivatives rebuild? As a rule, they are far less communicative about their practices than Ubuntu. How does the behavior of other Debian derivatives matter? As a rule, those other derivatives do not cooperate with Debian. If Ubuntu wants to be like them, fine, but don't say you cooperate with Debian if that's what you want to do. To be fair, co-operation and attribution are really separate issues. We do need to be consistent about each. Any complaint we have about co-operation with Ubuntu should not mean we have special requirements with regard to attribution. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
unsubscribe Send instant messages to your online friends http://in.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
