Re: cdbs borked by new version of make
* Ken Bloom ([EMAIL PROTECTED]) wrote: I just noticed bug #342892 (Incompatible with make 3.80+3.81.b3-1) on cdbs, and thought I should bring it to more people's attention that the new version of make has broken CDBS, and may potentially break your package. Everyone who has CDBS packages should try rebuilding them, and if you can patch the brokenness, submit the patch to bug 342892. Phew. Thanks for dropping this note. The package I was working on suddenly stopped building yesterday and I'd thought I'd lost my mind. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: /run vs. /lib/run
* Josselin Mouette ([EMAIL PROTECTED]) wrote: Le lundi 19 décembre 2005 à 20:12 +0100, Thomas Hood a écrit : Any other defenders of /lib/run? Of /run? Please go ahead with /run. This has to the right place as no other proposed location makes sense. I agree, it's no fun creating new top-level directories, but moving it under /lib doesn't really make sense. It more surprising and less consistent to have it under /lib. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: switching to vim-tiny for standard vi?
* Joey Hess ([EMAIL PROTECTED]) wrote: As you can see below and in the BTS, vim's maintainer has managed to create a vim-tiny package that is vim without some of the extras such as syntax highlighting. It's now only marginally larger than nvi, which is the standard vi included in the base system (amazingly, it's smaller than nano, the other editor in the base system). Stefano suggested that vim-tiny could replace nvi and become part of base, and I think it's a good idea. There are obviously users who will prefer nvi to vim (and others who prefer some other vi), but I get the impression there are rather more who prefer vim, it's probably the most commonly used vi in linux these days. One argument I can think of for keeping nvi in base is that it is the closest to bug-compatible with the original vi. However, I don't think that will prevent hardcore vi users from easily using vim-tiny if it's in base. Another good reason for doing this is that for basically every Linux user I've encountered, vi == vim. When I tell non-Debian users that Debian ships with something called nvi instead of vim by default, they shake their heads and disbelief and next words out of their mouths either make fun of Debian, or make fun of me (*snif*). Now we don't necessarily have to pander to these people, but this change is the sort of thing that will help the change perception of Debian for people who think we're a bunch of crazies. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Need for launchpad
* Frans Jessop ([EMAIL PROTECTED]) wrote: Ubuntu's launchpad is amazing. Do you think it would be helpful if all DD's worked through it on their projects? Wouldn't that keep things more organized and efficient? Or perhaps Debian could build its own version of launchpad which is better. Again, I think it would do a good job keeping everything organized an efficient. Cheers, Frans AFAIK Launchpad is not free software, so it's not going to happen. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Bug#348069: ITP: firefox-bidiui -- Enable Firefox user interface BiDi options by default
* Lior Kaplan ([EMAIL PROTECTED]) wrote: Package: wnpp Severity: wishlist Owner: Lior Kaplan [EMAIL PROTECTED] * Package name: firefox-bidiui Version : 0.1 Upstream Author : Lior Kaplan [EMAIL PROTECTED] * URL : http://svn.debian.org/wsvn/debian-hebrew/pkg/firefox-bidiui/trunk/ * License : GPL Description : Enable Firefox user interface BiDi options by default This package will turn on the Firefox BiDi options by default. It is useful for systems with Hebrew users but with non-Hebrew default locale. . BiDi options are based on the user's locale. This package sets Firefox bidi.browser.ui option to true. This seems a crazy thing to have an entire package for. Let's see if we can come up with a better solution. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Does it sometimes happen that people send mails before NMU ?
* Mike Hommey ([EMAIL PROTECTED]) wrote: There have been 2 NMUs on libxml2 in a week and I never got a message beforehand. Now I wonder if that practice has disappeared somehow. I admit I've not spent enough time for libxml2 recently, but still, I wouldn't have been bothered by some poking beforehand. Moreover, I'm not exactly sure the second NMU has indeed removed all problematic content but the bug is closed, so the NMUer may be happy. Ah, by the way, the bug was not even a problem for package propagation to testing, so that doesn't make the propagation an argument for a quick upload. No thanks Mike To quote Andreas Barth: However, we need to start *now* to give the RC-bug count some more attention. This means also that we're going to start again an everlasting BSP: For RC-bugs, you can upload 0-days NMUs for RC-bugs open for more than one week. However, you are still required to notify the maintainer via BTS before uploading. And of course, you need to take care of anything you broke by your NMU. So if they didn't notify you through the BTS and/or the bugs were open for less than a week, then let the chastisement commence! -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: new mplayer 1.0pre7try2 package
* A Mennucc ([EMAIL PROTECTED]) wrote: hi everybody a new version of mplayer 1.0pre7try2 is available ; add either for the etch version, the line deb http://tonelli.sns.it/pub/mplayer/etch ./ or for the sarge version, the line deb http://tonelli.sns.it/pub/mplayer/sarge ./ to /etc/apt/source.list . This has probably been covered ad nauseum, but where do we stand in respect to getting mplayer in Debian? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
* J?r?me Marant ([EMAIL PROTECTED]) wrote: Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Thu, 09 Feb 2006, Jérôme Marant wrote: Quoting Marco d'Itri [EMAIL PROTECTED]: Well, maybe the people who mislabeled the everything is software vote as an editorial change and deceived many other developers should have tought about this. The only people it made happy are extremists. See #207932. This is a A 3:1 majority win in 2004-04 makes your claim rather tenuous, unless you are arguing that such a large part of Debian is composed of extremists, only. That was a 3:1 majority out of 200 voters, considering that Debian counts almost 1000 developers and considering that many pros are convinced they have been deceived. If only 200 out of 1000 care enough to vote, then those are the people who get to make the decisions. We can't force developers to vote, so we can't be paralyzed into inaction by saying we can't do something because not enough people sent in a vote. Extremists are a minority but a very lound minority as usual which makes them often win. Dictorship of Minorities shall be opposed. If I minority are the only ones that vote, they get to set the direction of the project. No sense bitching about that, just get more people to vote. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: buildd disk space and debug symbols
* Martin Michlmayr ([EMAIL PROTECTED]) wrote: * Mike Hommey [EMAIL PROTECTED] [2006-03-21 13:08]: FWIW, Thiemo's patch has been in debian's firefox for a while (well, at least that of bugzilla #258429), and is also aaplied to xulrunner. I can confirm that firefox in Debian works. However, what can we do to finally get this patch into upstream? It seem the discussion never went anywhere, and for all I know Mozilla has this bizarre system I don't understand where you have to find people yourself to look at the patches you submit. Given that you know the Mozilla development process, can you request review again or do whatever is necessary to get this in. I can confirm that the patch in our firefox works - at least firefox starts and loads the Debian homepage. I'll play some more with it later. If I recall correctly, only the submitter of the bug and people properly blessed can turn on the ask for review flag. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: buildd disk space and debug symbols
* Martin Michlmayr ([EMAIL PROTECTED]) wrote: * Eric Dorland [EMAIL PROTECTED] [2006-03-21 10:34]: get this in. I can confirm that the patch in our firefox works - at least firefox starts and loads the Debian homepage. I'll play some more with it later. If I recall correctly, only the submitter of the bug and people properly blessed can turn on the ask for review flag. https://bugzilla.mozilla.org/show_bug.cgi?id=258429 has been submitted by glandium so hopefully he can do the necessary magic. Whoops, good point. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Bug#188463: ITP: libxcb -- lightweight, low-latency replacement for Xlib
Package: wnpp Version: unavailable; reported 2003-04-09 Severity: wishlist * Package name: libxcb Version : CVS Upstream Authors: Bart Massey [EMAIL PROTECTED], Jamey Sharp [EMAIL PROTECTED] * URL : http://xcb.cs.pdx.edu/ * License : MIT/X Description : lightweight, low-latency replacement for Xlib An X C Binding. A lightweight binding that speaks the X protocol directly, meant as a replacement for Xlib. It is meant to address some issues with Xlib, by being smaller, providing lower latency and being better able to handle multithreaded programs. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux apocalypse 2.4.20 #1 Fri Dec 20 18:08:05 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US
Bug#190656: ITP: freedroidrpg -- a clone of the classic game Paradroid on the Commodore 64
Package: wnpp Version: unavailable; reported 2003-04-24 Severity: wishlist * Package name: freedroidrpg Version : 0.94 Upstream Authors: Johannes Prix [EMAIL PROTECTED] Reinhard Prix [EMAIL PROTECTED] * URL : http://freedroid.sourceforge.net/ * License : GPL Description : a clone of the classic game Paradroid on the Commodore 64 A game inpired by Andrew Braybrook's classic Paradroid on the good old Commodore C64 and Blizzards' Classics Diablo I/II. In this game, you control a robot, depicted by a small white ball with a few numbers within an interstellar spaceship consisting of several decks connected by elevators. The aim of the game is to destroy all enemy robots, depicted by small black balls with a few numbers, by either shooting them or seizing control over them by creating connections in a short subgame of electric circuits. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux apocalypse 2.4.20 #1 Fri Dec 20 18:08:05 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US
Firebird 0.6
Hi Everyone, From the amount of mail I've gotten I guess people will be interested. I've uploaded mozilla-firebird_0.6-1 to my personal apt repository at http://people.debian.org/~eric/debian/. Just add: deb http://people.debian.org/~eric/debian/$(ARCH) ./ to your /etc/apt/sources.list and apt-get install mozilla-firebird. Note that This package does NOT Conflict/Provide/Replace my older phoenix package since they were unofficial, and this package doesn't actually conflict with the phoenix package (because of the name change). I'll probably upload this to unstable after a few more tweaks, if there's no objections. PS Many people have sent bug reports over the last few months and I tried to fix as many as I could remember, but I didn't actually look through my mail archive. So if I said I would fix your issue and I didn't, please drop me another note. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgpXWyccMqgB6.pgp Description: PGP signature
Re: Firebird 0.6
* Grzegorz B. Prokopski ([EMAIL PROTECTED]) wrote: W li?cie z wto, 20-05-2003, godz. 05:52, Eric Dorland pisze: Hi Everyone, From the amount of mail I've gotten I guess people will be interested. I've uploaded mozilla-firebird_0.6-1 to my personal apt repository at http://people.debian.org/~eric/debian/. Just add: To avoid confustion and to promote right common practise please *always* include the proper name of this project which is Mozilla Firebird AFAIK. And in the Subject too if that's not too much work. Thanks Grzegorz B. Prokopski PS: I am debian firebird packages maintainer. Ugh, Lets not start this flamewar here. I called it Firebird for the same reason as people say Linux instead of GNU/Linux and Bob instead of Robert: it's shorter and I'm lazy. I don't think anyone was confused by it particularly, especially since I refer to the full package name later on in the mail. So unless you have a better reason then PCness, I'll use either as the mood strikes me :) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK--
Re: Firebird 0.6
* Brian Nelson ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] writes: Hi Everyone, From the amount of mail I've gotten I guess people will be interested. I've uploaded mozilla-firebird_0.6-1 to my personal apt repository at http://people.debian.org/~eric/debian/. Just add: deb http://people.debian.org/~eric/debian/$(ARCH) ./ to your /etc/apt/sources.list and apt-get install mozilla-firebird. Note that This package does NOT Conflict/Provide/Replace my older phoenix package since they were unofficial, and this package doesn't actually conflict with the phoenix package (because of the name change). I'll probably upload this to unstable after a few more tweaks, if there's no objections. Hi Eric, Have you considered building the mozilla-firebird package from the mozilla or (more likely) the mozilla-snapshot source package? Given that the firebird build system requires just a small modification to the mozilla build system, I think it's possible to build both mozilla-browser and mozilla-firebird from the same source. Doing so would reduce the large amount of duplicated files that are contained in both mozilla and firebird. I intended to look into this last weekend, but cvs.mozilla.org and cvs-mirror.m.o were unreachable for me for the entire weekend. I did consider this, but since mozilla and firebird are not developed in parallel, they are released at different times, with different snapshots of the source tree. So if I tried to build it out of the mozilla source tree it would end up being either too old or too new or broken. It might be possible to build it out of the mozilla-snapshot packages, but only really -snapshot packages, not real releases. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK--
Re: Firebird 0.6
Could you be more specific? If there's a permission problem I'd like to fix it :) * Andreas Happe ([EMAIL PROTECTED]) wrote: In article [EMAIL PROTECTED], Nikolai Prokoschenko wrote: I've installed a bunch of extensions while using root and now Mozilla Firebird hangs when starting it as user. Does anybody else experience this? Any hints on diagnosing? been there, done that. there were some files in /usr/lib/mozilla-firebird/chrome which were not world readable. look for suspicious strace output. Andreas -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgpXJpRJ4dyuP.pgp Description: PGP signature
Bug#203712: ITP: irqbalance -- Balances irq's for SMP systems
Package: wnpp Version: unavailable; reported 2003-07-31 Severity: wishlist * Package name: irqbalance Version : 0.6 Upstream Author : Arjan van de Ven [EMAIL PROTECTED] * URL : http://people.redhat.com/arjanv/irqbalance/ * License : OSL 1.1 Description : Balances irq's for SMP systems Daemon to balance irq's across multiple CPUs on systems with the 2.4 or 2.6 kernel. Only useful on SMP systems. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux nightcrawler 2.4.21 #1 SMP Sun Jul 27 01:13:50 EDT 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US
Re: Automake dependency tracking
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: Hi, Recent versions of automake add an option --disable-dependency-tracking to the generated configure script. If you don't use that option, the generated Makefile will wrap all calls to the compiler in a call to 'depcomp', which will generate a Makefile snippet in a .deps directory to better track dependencies. This would include dependencies in the to be built package, but also dependencies outside that package, e.g., system headers. While I can understand the value of this for an upstream developer, I would wonder whether this is of any value for Debian packages. Debian packages typically do not profit from this kind of optimization; after all, a call to 'dpkg-buildpackage' will start off by running a 'make clean', which means that all source files are (unconditionally) rebuilt anyway. Well that's true if invoked from dpkg-buildpackage, it's not necessarily true in general. A developer working on a package might not do a complete clean rebuild, so it could have adverse effects. But if we could detect dpkg-buildpackage was the runner, then disabling dependency tracking would provide a little speed boost. Is there any other reason why we would still need to use automake's dependency tracking anyway? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: PROPOSAL: debian-mozilla@lists.debian.org (was: Transitioning to Mozilla Firefox 1.0PR)
* Johannes Rohr ([EMAIL PROTECTED]) wrote: [Cc and reply-to debian-devel] Am 2004.10.08 06:49 schrieb(en) Mike Hommey: On Fri, Oct 08, 2004 at 12:24:07AM +0200, Aurelien Jarno wrote: I remarked that mozilla-firefox is built on hppa using gcc-3.2 (I [...] Dear all, due to the ever increasing number of mozilla-based packages I wonder if it would be a good thing to have a separate debian-mozilla mailing list. Personally I have big difficulties understanding the hacked way how mozilla extensions etc are being repackaged for Debian and I would be very happy if there was a place to discuss such matters. Looking forward to any comments opinions, I'm very much in favor of such a list, but it would be best if Takuo and other leading mozilla packagers wanted such a thing as well. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Transitioning to Mozilla Firefox 1.0PR
* Johannes Rohr ([EMAIL PROTECTED]) wrote: [Cc'ing to debian-devel. Maybe others want to comment on this. Firefox 1.0x is currently kept out of Sid/Sarge because most translations are not yet available. Therefore Sarge is likely to be released with Firefox 0.9.3] Hi, the latest news from my upstream is, that they are not going to release a locale package for firefox 0.10 at all. They say they are going to release Firefox 10 RC1 instead which is due 18 October. Now, I understand that many other locale packagers have similar probs. What does this mean? What is less unfortunate? Releasing Debian with a totally unsupported development release of firefox or dump the not-yet-updated locale packages instead? Personally I'd rather have mozilla-firefox-locale-de removed from Sarge in order to get Firefox 1.0 in! The localization can still be installed through firefox' extension manager anyway. I'm basically in agreement with Johannes here. I think we're better served getting a latter firefox in than earlier, translations be damned :) I'm basically going to upload 0.10.1-1.0PR1 to unstable unless someone come up with compelling reasons not to. If I can't get it into sarge then I will certainly make a 0.9.3 release to address it's issues. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: SourceForge.net PR-Web Upgrade Notice.
* Luke Kenneth Casson Leighton ([EMAIL PROTECTED]) wrote: i'm forwarding this to debian devel for people's attention because it would appear that debian has lost a quite large opportunity - by not having selinux available. Nothing in that message implied the lack of SELinux was why sf went to Fedora, what makes you think so? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Transitioning to Mozilla Firefox 1.0PR
* Johannes Rohr ([EMAIL PROTECTED]) wrote: Hello everyone, I see that five firefox locale packages are still not updated and keep firefox out of testing: mozilla-firefox-locale-eu (0.9+0.7-1) mozilla-firefox-locale-ko (0.9.1) (btw: this looks like a native package which it should not be) mozilla-firefox-locale-nb (0.9.2-4) mozilla-firefox-locale-sv (0.9.3-1) mozilla-firefox-locale-tr (0.9.1-1) None of these packages has testing candidates. Four out of five fall behind even the firefox version that is is Sarge at present (0.9.3). Three of those packages can be easily brought up-to-date within five minutes: Please download the latest langpack from ftp.mozilla.org and rebuild your package. Here are the URLs: http://207.200.85.49/pub/mozilla.org/firefox/nightly/latest-0.11-l10n/firefox-1.0.ko-KR.langpack.xpi http://207.200.85.49/pub/mozilla.org/firefox/nightly/latest-0.11-l10n/firefox-1.0.nb-NO.langpack.xpi http://207.200.85.49/pub/mozilla.org/firefox/nightly/latest-0.11-l10n/firefox-1.0.sv-SE.langpack.xpi (Those are labelled nightlies, anyway they are for firefox 1.0) Also, please check the contents of the installed-chrome list e.g. debian/50xx-locale and sync it with the actual contents of the jar files, as there have been some changes recently, at least in the de locale package. The other two (eu and tr) should be removed from testing unless there is an updated langpack available elsewhere. Eric: Should we upload with priority=high to be ready for Sarge ASAP? Will you upload 1.0? I will upload a version 1.0, probably tonight, worst case later in the week. Mike Hommey is doing some excellent work on it right now, but there will be some tweaks to the extension manager that may require locale and extensions packagers to make a few changes (don't worry, if anything you should have to remove things). Stay tuned. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: mozilla-firefox-locale package with all language translations
* Mike Hommey ([EMAIL PROTECTED]) wrote: On Fri, Nov 12, 2004 at 10:52:35AM +0100, Nikolai Prokoschenko wrote: On Thu, Nov 11, 2004 at 03:50:51PM +0900, Mike Hommey wrote: Anyways, I'd suggest to make a multi-binary package so that it produces several mozilla-firefox-locale-* packages. A stupid question from my side: do we have any code in the mozilla-* wrappers to automatically select the right language according to the current locale? There is one in firefox. I'm not sure mozilla supports the -UIlocale and -contentLocale we can use on firefox to do the trick... Yes it does, that's where I stole the idea/code from :) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: GtkMozEmbed with Firefox not Mozilla
* William Ballard ([EMAIL PROTECTED]) wrote: gtkmozembed.h is packaged in mozilla-dev mozilla-dev depends on mozilla-browser Apparently it is possible to use FireFox instead and RPM for firefox-gtkmozembed exit: http://lists.freshrpms.net/pipermail/freshrpms-list/2004-October/011326.html Will Debian package such? And what would the advantage be over using mozilla? The gecko engine is the same, in fact mozilla tends to have a newer gecko engine than firefox. I mean this could be done, but if it doesn't actually confer any advantages why bother? And I can't think of any. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: GtkMozEmbed with Firefox not Mozilla
* William Ballard ([EMAIL PROTECTED]) wrote: On Sun, Jan 02, 2005 at 09:55:42PM -0500, Eric Dorland wrote: And what would the advantage be over using mozilla? The gecko engine is the same, in fact mozilla tends to have a newer gecko engine than firefox. I mean this could be done, but if it doesn't actually confer any advantages why bother? And I can't think of any. Why should I install an email client and web page editor, the bloat that is Mozilla, just to get GtkMozEmbed? Err, the email client and webpage editor are separate packages, so you don't need them if you're worried about bloat. If you're really worried about bloat, you should ask the mozilla maintainers to separate out the needed libraries in a separate package for you. Why is the exact same reasons as wanting Firefox not Mozilla in the first place. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: GtkMozEmbed with Firefox not Mozilla
* William Ballard ([EMAIL PROTECTED]) wrote: On Mon, Jan 03, 2005 at 08:44:05AM +0100, Norbert Tretkowski wrote: mozilla-dev depends on mozilla-browser, but not mozilla. mozilla-browser is 30 megabytes and duplicates the vast majority of firefox So every program that uses MozEmbed needs two versions, one compiled against mozilla and one compiled against firefox? Come on, that's silly. The solution is to ask the mozilla maintainer (Takuo KITAME [EMAIL PROTECTED]) to separate out the libraries you need from the rest of the package. as my link suggest apparently there exists an rpm for gtkmozembed-firefox so somebody else at least is doing it -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: GtkMozEmbed with Firefox not Mozilla
* William Ballard ([EMAIL PROTECTED]) wrote: On Mon, Jan 03, 2005 at 12:08:03PM -0500, Eric Dorland wrote: * William Ballard ([EMAIL PROTECTED]) wrote: On Mon, Jan 03, 2005 at 08:44:05AM +0100, Norbert Tretkowski wrote: mozilla-dev depends on mozilla-browser, but not mozilla. mozilla-browser is 30 megabytes and duplicates the vast majority of firefox So every program that uses MozEmbed needs two versions, one compiled against mozilla and one compiled against firefox? No. That's why you have virtual packages. Just like every program that depends on a java2-runtime doesn't have multiple versions. I think that a very large part of mozilla is probably just the libraries and you'd still have a great deal of duplication. The mozilla or firefox binary is probably only a very thin wrapper around the libraries; that's what iexplore.exe is. Unfortunately they're not just libraries. They're mostly just dynamic code blobs. They don't have sonames or published APIs. Firefox now tends to fork from the mainline mozilla tree, so the code can be quite different, or at least different enough to make having firefox load the mozilla components quite impossible. So yes there is duplication. Yes, it is unfortunate. Go tell mozilla fellas to make their stuff more modular. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: scripts to download porn in Debian?
* Sam Watkins ([EMAIL PROTECTED]) wrote: [snip] 2. Should Debian publish highly offensive content which is DFSG free? I say no. There are limits to what is acceptable in Debian. The anarchist FAQ is acceptable. The bible is acceptable. A package of hardcore pictures is obviously not acceptable, [snip] It is not at all obvious in fact. The bible and the anarchist FAQ have probably caused more direct damage to the world. Please don't project your morality on the project. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Bug#294990: ITP: bontmia -- backup over network to multiple incremental archives
Out of curiosity, how does this program is different from dirvish? * Reto Schuettel ([EMAIL PROTECTED]) wrote: Package: wnpp Severity: wishlist Owner: Reto Schuettel [EMAIL PROTECTED] * Package name: bontmia Version : 0.14 Upstream Author : John Enok Vollestad [EMAIL PROTECTED] * URL : http://folk.uio.no/johnen/bontmia/ * License : GPL Description : backup over network to multiple incremental archives bontmia creates incremental snapshots of a list of given directories over the network by using rsync over ssh and hard links. Every snapshot looks for the user like a complete copy of all the files, but as a result of using hard links every unchanged copy of a file is stored only once on the hard disk. The user can specify how old backups should be stored/kept. For example it's possible to keep the daily snapshots of the last 14 days, but also keep one snapshot per month of the last 12 months. The used network bandwidth can also be limited to avoid affecting production systems. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: dh_movefiles, tar vs. mv
* Frank Küster ([EMAIL PROTECTED]) wrote: Hi, dh_movefiles internally uses tar to move file contents. I'm not sure why it doesn't use mv, is it because mv moves the file block-by-block and thus starts removing parts of the file before it is completely written, and hence is less save? Anyway: If I am only going to move complete subdirectories from the temp tree to the package trees, is it in this case safe to use mv? It's much faster, and it would safe space (because dh_movefiles only removes the originals after the complete tarball has been extracted). Uhh, who cares? dh_movefiles has been superseded by dh_install. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: dh_movefiles, tar vs. mv
* Frank Küster ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] schrieb: * Frank Küster ([EMAIL PROTECTED]) wrote: Hi, dh_movefiles internally uses tar to move file contents. I'm not sure why it doesn't use mv, is it because mv moves the file block-by-block and thus starts removing parts of the file before it is completely written, and hence is less save? Anyway: If I am only going to move complete subdirectories from the temp tree to the package trees, is it in this case safe to use mv? It's much faster, and it would safe space (because dh_movefiles only removes the originals after the complete tarball has been extracted). Uhh, who cares? dh_movefiles has been superseded by dh_install. Well, fine. But the question remains: dh_install uses cp, not mv. What is the problem with using mv? And would it be safe to use mv if I only move complete directories? Well one reason is sometimes (in multipackage builds) you want to have the same file in 2 different packages. Also, the less side-effects during build time the better for debugging. Eg since dh_install is idempotent I can run my install target multiple times it will work. That won't work with dh_movefiles. OTOH if you have a massively big package, dh_install would be painful, especially on some of the buildds. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Key management using a USB key
An arguably more secure approach would be to use a cryptographic smart card in a usb key form factor with OpenSC. Unfortunately integration with ssh and gpg is lacking at this point, but I hope to be able to do something about that post-sarge (ssh has support but doesn't compile it in, and gnupg support will come with gnupg 2.0). * David H?rdeman ([EMAIL PROTECTED]) wrote: Hi all, first of all, this might be slightly off-topic for the debian-devel list, but I've got the impression that it's already been solved by some DD's and might prove interesting to others (including non-DD's such as me). I've been meaning for some time to get a USB key to manage private keys (such as gpg, ssh, etc), but it's not until recently that I tried to sit down and sketch on how to implement it (filesystem layout, functionality, which parts are encrypted and accessed at which points in time etc). It turns out that it was not as obious as I thought. Things which I've considered so far: o In order to minimize the exposure of the key, it might be wise to mount the drive, load the keys (ssh,gpg) into the memory of the appropriate agents and then unmount the drive. On the other hand, does this actually provide any extra security as opposed to having the key mounted for the entire session? o Password entry, it's a hassle to enter 10 different passwords, what would be the best way to reduce the number of password entries? dm-crypt to mount an encrypted file on the USB key and then have the gpg and ssh keys unencrypted within? The login to X/console etc could then maybe be performed using libpam-usb [1] so that only the password for the dm-crypt filesystem is needed? o Especially on laptops, it might be interesting to also encrypt all of /home and/or other parts of the harddrive to make the data unusuable without the USB key. But how to integrate this with the other requirements? o Revocation certificates for the gpg keys, are there arguments for/against storing them on the usb key? o Automagic setup. Hopefully, some scripts in conjunction with udev/hotplug/pmount/whatever could make everything just work (tm) when the key is inserted. o USB key removal, how should it be handled if the key is physically removed during a session? Maybe kill the agents and run xscreensaver until the key is reinserted... o Permissions, how are these handled when the key moves between systems where my userid might differ? o Other issues? It would be very interesting to hear how others manage this... Kind regards, David [1] http://bugs.debian.org/234134 -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Proposed change to debian release system
* Andrew Pollock ([EMAIL PROTECTED]) wrote: On Sat, Dec 13, 2003 at 03:20:27PM +, Scott Minns wrote: Hiya all, First of all let me introduce myself, my name is Scott Minns, i'm a debian user, not a developer. That most likely makes you question why i'm using thins mailing list at all, let alone having the gall to propose altering a well established testing and release system. Here is my proposal and I would like to hear your thoughts on it, In addition to the present releases- stable, testing and unstable. We add a release called current. [snip] What you propose is probably technically difficult to actually achieve, due to dependencies, and would, as has already been pointed out, effectively mean there are two stable distributions running around. I've been musing over a proposal for a while, which your email makes me want to raise now... I'd like to propose some changes to the stable release policy (ps it would be nice if the policy is linked from http://www.debian.org/releases/stable/). I'd like for certain packages to be classed as perishable, i.e. they become more or less useless with age. How packages should be classsed as such, I'm not 100% sure on yet (-devel+maintainer+SRM consenus, perhaps?), but to provide some examples: * spamassassin * snort could be considered perishable because their effectiveness is reduced over time. Such classed packages should be allowed to be updated in stable, I feel. Of course, it could be argued that any package is perishable, and thus this whole thing becomes a moot point... We always have to be careful with things like that, since stable is *stable*... it should not really change, except to address critical issues. Not that I disagree with your proposal. I think that some value in updating these packages, and for packages such as spamassassin and snort the case could be made that updating them would be security updates, particularly in the case of snort. Also those two packages really contain rule sets that could be packaged separately and updated, while leaving the core code unchanged. That would probably be the least surprising thing, and the least likely to cause bugs, but would still be a lot of work and testing. Another package I think would be on the list might be gaim. If msn or yahoo changes their protocol then it becomes rather broken. This one would be very difficult to handle in most cases... new version could introduce new bugs, and backports could be really tough. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Common Position on RubyGems, stupid? what about /usr/local/ ?
* Antony Lesuisse ([EMAIL PROTECTED]) wrote: Reading http://pkg-ruby-extras.alioth.debian.org/rubygems.html was disappointing. I might be completely wrong but i would like to know what you think about this idea. I noticed that the ruby1.8 install supports the directory: /usr/local/lib/site_ruby/1.8 So what about packaging a version of rubygems with its files in: /usr/lib/ruby/1.8/rubygems.rb /usr/lib/ruby/1.8/rubygems/* /usr/bin/gem ... BUT this version would be configured to install and consume downloaded gems into: /usr/local/lib/site_ruby/1.8/gems The package is compliant (at installation only it only add an empty dir in /usr/local). Indeed, this is the right approach. Only dpkg should be installing things into /usr/lib. Admin takes full reponsabilty about rubygem. On purge rubygem only remove its files in /usr/lib. I consider rubygem as package similar to wget. I don't expect dpkg -P wget to remove files i have downloaded when i typed: wget -O /usr/local/somefile http://some/url What do you think about that ? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Missing firefox source and unofficial debian-amd64 breakage
* Jeroen van Wolffelaar ([EMAIL PROTECTED]) wrote: On Sun, Apr 23, 2006 at 09:57:32PM +0200, Mike Hommey wrote: On Sun, Apr 23, 2006 at 09:49:29PM +0200, Mike Hommey [EMAIL PROTECTED] wrote: On Sun, Apr 23, 2006 at 02:46:47PM +0200, Goswin von Brederlow [EMAIL PROTECTED] wrote: Hi, as some might have noticed the Debian archive is missing /debian/pool/main/f/firefox/firefox_1.5.dfsg+1.5.0.2.orig.tar.gz The missing file has a sideeffect for the debian-amd64 archive because the sync-script detects an inconsistency and stops. Since it goes alphabeticaly and package after firefox won't be updated to the latest version anymore. From my irc backlog this looks like a DAK screwup and not the maintainers fault and is probably being investigated already. But that doesn't help the rest of the world in the short run. AFAIK, the breakage is due to the fact that 1.5.dfsg+1.5.0.2-1 is sitting in the NEW queue. I guess Eric didn't make a sourceful upload for 1.5.dfsg+1.5.0.2-2, thus the missing orig.tar.gz file. Better than that. Eric DID a sourceful upload which got rejected because the .orig.tar.gz was in the NEW queue. Then he uploaded without the source and that's what got into the archive. Now, 1.5.dfsg+1.5.0.2-1 has been rejected, without any reason given. There should have been a reason in the reject mail, and even if not, the footer asks to reply if you don't understand. Anyway, the reason was that currently 1.5.dfsg+1.5.0.2-2 is in unstable, and 1.5.dfsg+1.5.0.2-1 is smaller, so cannot be anything else than rejected. You can of course re-upload to NEW with a higher version number. Anyway, the .orig.tar.gz is now restored and should be on your local mirror around nowish. Thanks very much Jeroen. Should I file a bug somewhere about this? Clearly I hit a corner case that dak doesn't handle quite right. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Bug#364609: O: Gnus -- A versatile News and mailing list reader for Emacsen.
* Jorgen Schaefer ([EMAIL PROTECTED]) wrote: Manoj Srivastava [EMAIL PROTECTED] writes: After seven and a half years of maintaining Gnus, I am having to give away the package, on what I consider is a matter of principle. My upload removing non-DFSG bits was rejected, on the grounds that the upload renamed the source package name (the binary package name remains Gnus). I find myself unable to comply with calling the source package Gnus, even though we remove all documentation from the package, and pretending it is just a newer upstream version, since that implies to people looking at the list of sources that this is perhaps unreleased upstream source package -- even though upstream is vehemently opposed to this course of action. I'm with Manoj here - it's not useful to our users for us to fake a new upstream version. I'm very confused as to why changing the source package name is such a huge problem. Maybe someone could clarify? Faking an upstream version number which doesn't exist, and which is not the package that is in Debian, can't be the right solution. Since changing the source package name seems to be inappropriate, what would be a useful approach to this problem? I hope this problem can be solved so that a) our users can rely on us not to fake version numbers, and b) Manoj can continue to package Gnus. There is a fairly long tradition of stripping non-free things out of the upstream tarball and adding a dfsg to the version. While the documentation removal is probably some of the most intrusive DFSG-izing to date, I don't see why the dfsg in the version number is somehow worse than in the source package name. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: O: Gnus -- A versatile News and mailing list reader for Emacsen.
* Manoj Srivastava ([EMAIL PROTECTED]) wrote: On 24 Apr 2006, Thomas Bushnell said: Manoj Srivastava [EMAIL PROTECTED] writes: In this case, there have been deeply felt and vehement protests for Debian removing a critical subset of the software shipped with make/gnus, with people appealing to keep the code together with the docs even if it meant removing the package to non-free. Upstream is strongly opposed to removing the non-free documentation; to imply this is upstreams project (with a perhaps unreleased version) seems deceptive to my eyes. It's free software. They don't get to make those demands. No. But there are user expectations, and when you talk about source package for Gnus, the assumption is that the orig,tar.gz comes from the FSF, and the debian changes are in the diff.gz. There are debian specific changes to Gnus, and they do love in diff.gz -- apart from the documentation that we are ripping out, and the build system changes to reflect that. There's no reason for the build system changes not to live in the diff.gz. Other than making the orig.tar.gz broken on its own. Not acknowledging it in the package name, but pretending it is just a new upstream version, bothers me. The version is not the only documentation. The dfsg tag in version names means not this is the upstream dfsg version, it means this is the Debian-modified version, where the only modifications made were those we did to make the package meet the DFSG. Sorry, that string in the upstream version does not convey that to me at all. It makes me think that larsi released a second version compatible of the DFSG. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: gnome 2 gnucash into unstable
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: I have just uploaded gnucash 1.9.6, the first beta release of the new gnome 2 gnucash. Since this is now in beta, I judged it opportune to upload it to unstable. The final 2.0 release is expected in a short number of weeks. Many thanks to the fabulous upstream gnucash team! I'm as excited about the new version as anyone, but considering the data gnucash operates on, maybe it would be better to wait until the final is released? Is there any particular thing I should do to have the series in the experimental distribution deleted? Ideally, they should go away as -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: [Debconf-discuss] Re: Please revoke your signatures from Martin Kraff's keys
* Stephen Frost ([EMAIL PROTECTED]) wrote: * Manoj Srivastava ([EMAIL PROTECTED]) wrote: On 25 May 2006, Stephen Frost verbalised: * Manoj Srivastava ([EMAIL PROTECTED]) wrote: Explanation? What we have here is an act of bad faith, in the guise of demonstrating a weakness. In my experience, one act of bad faith often leads to others. pffft. This is taking it to an extreme. He wasn't trying to fake who he was, it just wasn't an ID issued by a generally recognized government (or perhaps not a government at all, but whatever). If you think an ID from a place that issue you any ID when you pay for it is valid, I probably will not trust a key signed by you, and I would also suggest other people do not. I wasn't making any claim as to the general validity of IDs which are purchased and I'm rather annoyed that you attempted to extrapolate it out to such. What I said is that he wasn't trying to fake who he was, as the information (according to his blog anyway, which he might be lieing on but I tend to doubt it) on the ID was, in fact, accurate. Indeed, to the best of my recollection the name and picture on both his Transnational ID and his official German Identification Card matched (well they weren't the same picture, but they were both pictures of him). Now of course you don't have to take my word for that, but if it's any reassurance at all, he wasn't trying to fake who he was or obtain signatures under false pretenses. He was just conducting an experiment to see how much people really *check* the ID they're looking at. It's a good lesson, and I'd rather Martin demonstrate it rather someone with actual malicious intent. As to bad faith, since most pot smokers do not become crystal meth addicts and most jay walkers do not become serial killers, I'm not concerned that Martin will begin rooting the project's boxes. If you're upset about this because you had planned to sign it and now feel 'duped' then I suggest you get past that emotional hurdle and come back to reality. No one 'crack'ed anything here (that we know of anyway) and while not signing his key because of this is reasonable, or even revoking a signature which had been based on this ID, the constant inflammatory claims of Martin being a 'cracker' and how this could lead to other 'cracks' is extreme, insulting, and childish. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Real Life hits: need to give up packages for adoption
* () wrote: Hi, My inability to find enough time to focus on package maintainance has been *way* too persistent. I therefore need to give up my packages for adoption, for the time being. I am sorry (and not happy with myself) that I've been procrastinating about this for too long. This decision has not been easy. However, I need to focus more on (a) work that actually feeds my kids, and (b) time that is *not* spent hacking. Before filing Orphan bugs, I'd like to ask whether anybody wants to tackle these packages. The Easy Pickings stuff would be ideal start-up work for new maintainers / mentorship; some of the others do need some work. * gnupg2 (some clean-up work) I'd like to take this, as it ties into some of my work packaging OpenSC quite nicely. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
proposed mozilla-firefox security update, needs testing!
At http://people.debian.org/~eric/mozilla-firefox you'll find mozilla-firefox 1.0.4-2sarge8. It contains backports of the security fixes present in 1.5.0.4. All these fixes are the work of Alexander Sack, who's been working tirelessly the last couple of weeks to get things ported. It is still missing some of the fixes from mfsa2006-32, as these have proved difficult to backport I believe. Please test these packages! There was quite a lot of code change in some of these patches, and the more users we have to test the sooner we can resolve any problems before this is an official security release. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: dxpc in sid and ready for backports, FYI
* Jay Berkenbilt ([EMAIL PROTECTED]) wrote: For the small handful of people use dxpc (differential X protocol compressor, a useful tool for running X over slow network connections even including dialup), you should be aware that I have just uploaded 3.9.0-1 to sid. Version 3.9.0 is not runtime compatible with older versions of because of non-compatible changes to the protocol. I have a version ready to upload to backports.org which I will upload as soon as 3.9.0 hits testing. In the mean time, if you use dxpc, please be aware that the next upload will break compatibility with dxpc running on older systems. That information is a very good candidate for a NEWS.Debian file. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: proposed mozilla-firefox security update, needs testing!
* Martin Spoehrle ([EMAIL PROTECTED]) wrote: On Mon, Jun 19, 2006 at 05:34:55PM -0400, Eric Dorland wrote: Please test these packages! There was quite a lot of code change in some of these patches, and the more users we have to test the sooner we can resolve any problems before this is an official security release. bookmarks.html files created by firefox 1.0.4-2sarge7 can not correctly be read by firefox 1.0.4-2sarge8 - all bookmarks subfolders appear to be empty. Can anyone confirm this? Could you send me a copy of your bookmarks.html file privately? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Reclaiming automake
¶the [EMAIL PROTECTED] airsnort peacock Chris Lawrence [EMAIL PROTECTED] gnome-lokkit Marcelo E. Magallon [EMAIL PROTECTED] gtkgl2 gtkglarea lib3ds Camm Maguire [EMAIL PROTECTED] codebreaker maxima perspic Cyril Martin [EMAIL PROTECTED] eagle-usb Martin Maurer [EMAIL PROTECTED] fireflier Remco van de Meent [EMAIL PROTECTED] scli A Mennucc1 [EMAIL PROTECTED] snmpkit Stephen M Moraco [EMAIL PROTECTED] gpsim Gopal Narayanan [EMAIL PROTECTED] yacas Pedro Zorzenon Neto [EMAIL PROTECTED] avrprog Søren Boll Overgaard [EMAIL PROTECTED] pan tcltls Jonathan Oxer [EMAIL PROTECTED] lcdproc Barak A. Pearlmutter [EMAIL PROTECTED] xgraph VÃctor Pérez Pereira [EMAIL PROTECTED] gfslicer squidguard Zed Pobre [EMAIL PROTECTED] cppopt libmodplug modplugxmms Filip Van Raemdonck [EMAIL PROTECTED] clanlib Klaus Reimer [EMAIL PROTECTED] sqlxx strutilsxx Roberto C. Sanchez [EMAIL PROTECTED] toshutils Amaya Rodrigo Sastre [EMAIL PROTECTED] fkiss Riccardo Setti [EMAIL PROTECTED] libgalago Thomas Smith [EMAIL PROTECTED] fuzz Christian T. Steigies [EMAIL PROTECTED] luola Paul J Stevens [EMAIL PROTECTED] dbmail Al Stone [EMAIL PROTECTED] llvm Norbert Tretkowski [EMAIL PROTECTED] lcd4linux Riku Voipio [EMAIL PROTECTED] wbxml2 James R. Van Zandt [EMAIL PROTECTED] autoproject -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* Artur R. Czechowski ([EMAIL PROTECTED]) wrote: Hi Eric, On Sun, Jun 25, 2006 at 07:11:14PM -0400, Eric Dorland wrote: automake1.4: This is the old school package, that's been completely unsupported for a number of years (since 2002). It certainly not used with any new software and any software still using it should be migrated away from it. It is also the only package that provides automake, cause there are still 73 packages by my reckoning that build depend on automake and expect that be automake 1.4. Have you considered packages depending on automake1.4? apt-cache rdepends automake1.4 | grep ^ | dd-list --stdin says: For the purpose of this transition these are fine. But yes, it would better if these packages could depend on something newer. Hakan Ardo [EMAIL PROTECTED] toolchain-source For some reason this depends on both automake1.4 and automake1.7. Weird. Debian PHP Maintainers [EMAIL PROTECTED] php4 php5 php4 is fairly old, but I'm surprised php5 still uses automake 1.4. Is this really the case? Gustavo Noronha Silva [EMAIL PROTECTED] glade Glade apparently still generates 1.4 Makefile.am files. Probably easy to fix, if anyone is working on glade anymore. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: proposed mozilla-firefox security update, needs testing!
* Alexander Sack ([EMAIL PROTECTED]) wrote: On Tue, Jun 20, 2006 at 06:25:36PM -0400, Eric Dorland wrote: * Martin Spoehrle ([EMAIL PROTECTED]) wrote: On Mon, Jun 19, 2006 at 05:34:55PM -0400, Eric Dorland wrote: Please test these packages! There was quite a lot of code change in some of these patches, and the more users we have to test the sooner we can resolve any problems before this is an official security release. bookmarks.html files created by firefox 1.0.4-2sarge7 can not correctly be read by firefox 1.0.4-2sarge8 - all bookmarks subfolders appear to be empty. Can anyone confirm this? Could you send me a copy of your bookmarks.html file privately? Eric, was this reproducible? Unfortunately it was very reproducible :( I'm not sure how to proceed. Is anyone else using these patches that might be able to help figure out where the problem lies? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* Scott James Remnant ([EMAIL PROTECTED]) wrote: On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: Scott James Remnant dropped me an email recently, interested in improving the automake situation in Ubuntu and Debian[0]. [0] Their plan, which mirrors mine, is documented here: https://wiki.ubuntu.com/AutomakeTransition If you could have another read through of that spec, now it's post-draft, and make sure we're still both planning the same thing that'd be great. I don't see any reason for Ubuntu to go a different direction to Debian here. In particular I had a momentary thought about what packages should actually depend/build-depend on now -- could you check that. The automaken | automake$VER is probably not wise. A new version of automake may not be fully backwards compatible. If it were, we wouldn't have these problems. Better to depend on a known version that works, or better still don't build depend on it at all and ship the generated files in the diff.gz. Now before I can implement this master plan, I need to fix all the packages that still build depend on automake[1]. To proceed with this I'd like to file wishlist bugs (with patches) against these packages one week from today. One week after that, with the Release Team's blessing, I'd like to start NMUing as much of these packages as I can. Once that is complete, I'd like to make the transition and raise the severity of any of bugs that remain. We should probably work together to cut the time down to make these patches. I'm going to get started on Saturday, and I'll be on IRC (#debian-devel) so if you (or anyone) want to join in the fun, we can coordinate there. I've just filed #376047 too, so any bugs filed should be made to block that one. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* Scott James Remnant ([EMAIL PROTECTED]) wrote: On Thu, 2006-06-29 at 19:37 -0400, Eric Dorland wrote: * Scott James Remnant ([EMAIL PROTECTED]) wrote: On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: Scott James Remnant dropped me an email recently, interested in improving the automake situation in Ubuntu and Debian[0]. [0] Their plan, which mirrors mine, is documented here: https://wiki.ubuntu.com/AutomakeTransition If you could have another read through of that spec, now it's post-draft, and make sure we're still both planning the same thing that'd be great. I don't see any reason for Ubuntu to go a different direction to Debian here. In particular I had a momentary thought about what packages should actually depend/build-depend on now -- could you check that. The automaken | automake$VER is probably not wise. A new version of automake may not be fully backwards compatible. If it were, we wouldn't have these problems. Better to depend on a known version that works, or better still don't build depend on it at all and ship the generated files in the diff.gz. I'd personally tend to err on the assume it is, unless it isn't -- would you suggest all packages be changed to not B-D on automaken then? In my opinion this would be best practice. Some maintainers don't agree. I'm going to get started on Saturday, and I'll be on IRC (#debian-devel) so if you (or anyone) want to join in the fun, we can coordinate there. I've just filed #376047 too, so any bugs filed should be made to block that one. The disadvantage of doing this for a living, rather than for fun, is that weekends tend to be out :) I'll pick up on Monday :p You've lost your love of free software Scott :P No worries, hopefully on Monday you'll wake up to see a lot of progress. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Reclaiming automake
* James Westby ([EMAIL PROTECTED]) wrote: On (29/06/06 19:37), Eric Dorland wrote: * Scott James Remnant ([EMAIL PROTECTED]) wrote: On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: Scott James Remnant dropped me an email recently, interested in improving the automake situation in Ubuntu and Debian[0]. [0] Their plan, which mirrors mine, is documented here: https://wiki.ubuntu.com/AutomakeTransition It would be good if you could make a page or two on the Debian wiki. One with the details about what must happen and what must be checked, perhaps with lists of packages that can be claimed and then marked appropriately. It would also be good to have a page that bug reports that are filed can reference, so that the maintainers have a clear about what is supposed to happen. Sure, I'll take a look at doing this before I start anything. Are the instructions at the bottom of the referenced Ubuntu page exact enough for you? They go farther than is necessary, but if that can be done it would be great. Now before I can implement this master plan, I need to fix all the packages that still build depend on automake[1]. To proceed with this I'd like to file wishlist bugs (with patches) against these packages one week from today. One week after that, with the Release Team's blessing, I'd like to start NMUing as much of these packages as I can. Once that is complete, I'd like to make the transition and raise the severity of any of bugs that remain. We should probably work together to cut the time down to make these patches. I'm going to get started on Saturday, and I'll be on IRC (#debian-devel) so if you (or anyone) want to join in the fun, we can coordinate there. I've just filed #376047 too, so any bugs filed should be made to block that one. I will help out where possible. I will hopefully email you later with information on the packages that were referenced as [1] (snipped) that might help you out as well. Great, thanks! -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: cdrtools
* Matthew Garrett ([EMAIL PROTECTED]) wrote: (For what it's worth, I have no great objection to the CDDL. Most of the aspects of it that people claim to be unhappy with are also in the MPL, and we still ship Mozilla quite happily. Yes, I know that most of Mozilla is also available under the GPL. I don't really see why that's relevant...) Just to point out that as of Firefox/Thunderbird 2 the entire codebase is triple licensed under the MPL, GPL and LGPL and any objection to the MPL as far as Mozilla is concerned is fairly academic at this point. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: cdrtools
* Matthew Garrett ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] wrote: Just to point out that as of Firefox/Thunderbird 2 the entire codebase is triple licensed under the MPL, GPL and LGPL and any objection to the MPL as far as Mozilla is concerned is fairly academic at this point. Seriously? That's absolutely great. Is there any sort of announcement of this anywhere? Seriously: http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html. I'm hoping to have Firefox 2.0 part of etch, but with the aggressive release schedule it may not happen. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: cdrtools
* Mike Hommey ([EMAIL PROTECTED]) wrote: On Wed, Jul 12, 2006 at 12:47:32AM -0400, Eric Dorland [EMAIL PROTECTED] wrote: * Matthew Garrett ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] wrote: Just to point out that as of Firefox/Thunderbird 2 the entire codebase is triple licensed under the MPL, GPL and LGPL and any objection to the MPL as far as Mozilla is concerned is fairly academic at this point. Seriously? That's absolutely great. Is there any sort of announcement of this anywhere? Seriously: http://weblogs.mozillazine.org/gerv/archives/2006/03/relicensing_complete.html. Actually, only the trunk has the relicensing complete, and the trunk is Firefox 3. Firefox 2 will still be in the same state as previous releases, but we know most of its code is available in upstream cvs in a really triple licensed form. Really? Gerv's post is incorrect? I'm hoping to have Firefox 2.0 part of etch, but with the aggressive release schedule it may not happen. I'm hoping to have Firefox 2.0beta1 uploadable to experimental somewhat soon. Firefox 2.0 final itself is supposed to be released in august (but more likley in september) I was thinking about doing that myself :) It might not be impossible to have it in etch (and would be preferable, since upstream will stop support of Firefox 2 6 months after release of Firefox 3, which is itself due Q1 2007). Oh I certainly don't think it's impossible, but the timing is tight. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: cdrtools
* Mike Hommey ([EMAIL PROTECTED]) wrote: On Wed, Jul 12, 2006 at 10:10:29AM +0200, Mike Hommey [EMAIL PROTECTED] wrote: Last time I checked (and it was after Gerv's post), the relicensing changes were still not applied to the MOZILLA_1_8_BRANCH. Things seem to have changed, but that needs some checking. I took some random files to check and found out files that are not tri-licensed in the trunk, so... *sigh* After a slightly closer look, it seems most of the code is actually tri-licensed, even in the Firefox 2 branch. Strangely enough, while the vast majority of the code is under MPL/GPL/LGPL, some of it is under NPL/GPL/LGPL. That doesn't change much for us, but it's still strange. Still a lot of files don't have a license text at all, including examples and test source code. Well I'm glad it's mostly resolved. It's odd that there are still things licensed under the NPL. http://www.mozilla.org/MPL/ says it's not even used in any mozilla code anymore. Some examples and test files are licensed under Mozilla-sample-code. Uh, is that actually a license? The most problematic files are in xpcom/reflect/xptcall/src/md/unix. This directory contains assembler code for xpcom on several platforms. While a lot of these files are not of any use for us (irix, vms...) some are indeed used: xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and xptcinvoke_asm_sparc_linux.s are NPL only ; xptcinvoke_asm_mips.s is MPL. Even if we don't use the irix, vms, etc files, if they're problematic license-wise, we'd need to strip them out or get the license fixed. I'm going to contact Gerv about that. Fantastic. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: cdrtools
* Mike Hommey ([EMAIL PROTECTED]) wrote: On Wed, Jul 12, 2006 at 03:58:13PM -0400, Eric Dorland [EMAIL PROTECTED] wrote: Some examples and test files are licensed under Mozilla-sample-code. Uh, is that actually a license? Yes it is: BEGIN LICENSE BLOCK Version: Mozilla-sample-code 1.0 Copyright (c) 2002 Netscape Communications Corporation and other contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this Mozilla sample software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Contributor(s): END LICENSE BLOCK That's just the MIT license renamed it would appear. If you want a full licensing status on the mozilla code base, take a look to http://packages.debian.org/changelogs/pool/main/x/xulrunner/current/copyright which I actually need to update, I saw that some files changed to tri-license between 1.8.0.1 and 1.8.0.4... Wow, I should really update the copyright file in firefox. The most problematic files are in xpcom/reflect/xptcall/src/md/unix. This directory contains assembler code for xpcom on several platforms. While a lot of these files are not of any use for us (irix, vms...) some are indeed used: xptcinvoke_asm_ppc_linux.s, xptcstubs_asm_ppc_linux.s and xptcinvoke_asm_sparc_linux.s are NPL only ; xptcinvoke_asm_mips.s is MPL. Even if we don't use the irix, vms, etc files, if they're problematic license-wise, we'd need to strip them out or get the license fixed. The point was that in the worst case scenario, we can't remove the files I listed without removing support for these architectures. The others can be removed without harm. Indeed. Another thing that is a bit annoying is that the LICENSE file in the upstream tarball is the MPL license text. It'd be better for everyone if they'd make it clear that everything in the tarball, except external libraries such as expat, libpng, etc. are tri-licensed. Should we file a bug? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Bug#379343: ITP: jrpg -- kanji learning game
Package: wnpp Severity: wishlist Owner: Eric Dorland [EMAIL PROTECTED] * Package name: jrpg Version : 20060524-2151 Upstream Author : Tomasz Wegrzanowski [EMAIL PROTECTED] * URL : http://www.example.org/ * License : mostly GPL, but will go in non-free because of non-free graphics Programming Lang: Python Description : kanji learning game JRPG is a kanji learning game styled after the classic SNES RPG games (like Final Fantasy 6, or Legend of Zelda: Link to the Past). The game tries to help you learn how to read and understand kanji in context, and in doing that it also helps you improve your Japanese vocabulary. You can also use it to refresh your kana. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#379343: ITP: jrpg -- kanji learning game
* Matthew R. Dempsky ([EMAIL PROTECTED]) wrote: On Sat, Jul 22, 2006 at 06:01:57PM -0400, Eric Dorland wrote: * URL : http://www.example.org/ Does this package not have an actual web site? Sorry, http://www.zabor.org/jrpg/ -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Centralized darcs
* John Goerzen ([EMAIL PROTECTED]) wrote: On Tue, Aug 01, 2006 at 06:12:34PM -0300, Otavio Salvador wrote: diff also doesn't preserve permissions, so some are using debian/rules anyway. Indeed but that can make thing broke due the wrong permission of upstream files, iff you use darcs to maintain those fixes mixed with changes for packaging. It's true that it *can* happen, but it rarely *does* happen, and when it does, there are easy workarounds. I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Amen to that. (although I use svn) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Bug#381745: ITP: ceferino -- action game similar to Super Pang
* Miriam Ruiz ([EMAIL PROTECTED]) wrote: Package: wnpp Severity: wishlist Owner: Miriam Ruiz [EMAIL PROTECTED] * Package name: ceferino Version : 0.97.5 Upstream Author : Hugo Ruscitti [EMAIL PROTECTED] * URL : http://www.losersjuegos.com.ar/juegos/ceferino/ceferino.php * License : GPL Programming Lang: C++ Description : action game similar to Super Pang A game similar to 'Super Pang'. You are attacked by little green balls which are bouncing around and which you have to kill with your knife. Your knife however is limited to being thrown upwards, thus you have to get under the balls to kill them. Even worse, if you 'kill' a large ball, it doesn't just vanish, but breaks apart into two smaller balls. Levels consist of little platforms connected by ladders, so you can go up and down or find cover if needed. Is this one better or worse than pangzero? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: release update: freeze, RC Bug count, python, toolchain
* sorting out docs-in-main vs. the DFSG We have seen some promising development here, and only a few packages need to be updated for this. Sadly, the remaining packages include glibc, automake and emacs21. Please try to help out for those. Sorry I've been dawdling with automake. I have a patch to remove the documentation cleanly, I'll try to get it all sorted out over the weekend. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: MPEG in general Was: Is anyone packaging `lame' ?
* Florian Weimer ([EMAIL PROTECTED]) wrote: * Frederik Dannemare: I'll dare to take the other route and ask: what is now holding back software such as mplayer/mencoder, transcode and mjpegtools from entering Debian? Same as ever, sufficiently influential people oppose it. Well they must have some sort of argumentation for why they oppose it. I know that at one point the mplayer code had some dubious licensing issues, but is this still the case? As for the others, can anyone point out where people have made objections to these packages? And with the recent upload of ffmpeg make these objections moot? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Bug#291495: ITP: blktool -- Program that does stuff with block devices
Package: wnpp Severity: wishlist * Package name: blktool Version : 4 Upstream Author : Jeff Garzik [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/gkernel/ * License : GPL Description : Program that does stuff with block devices blktool is used for querying and/or changing settings of a block device. It is like hdparm but a more general tool, as it works on SCSI, IDE and SATA devices. This code is still experimental and you should use it at your own risk as it could cause damage to your hardware. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#128487: ITP: ferite -- Ferite programming language
Package: wnpp Version: N/A; reported 2002-01-09 Severity: wishlist * Package name: ferite Version : 0.99.4 Upstream Author : Chris Ross (boris) [EMAIL PROTECTED] * URL : http://www.ferite.org/ * License : BSD Description : Ferite programming language Ferite is a language that incorporates the design philosophies of other languages, but without many of their drawbacks. It has strong similiarities to perl, python, C, Java and pascal, while being both lightweight, modular, and embeddable. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux apocalypse 2.4.16 #1 Fri Nov 30 14:38:38 EST 2001 i686 Locale: LANG=en_US, LC_CTYPE=
Re: ITP: ferite, a lightweight scripting language and engine
Ummm, i uploaded ferite late last week, sorry. * Adam C Powell IV ([EMAIL PROTECTED]) wrote: Package: wnpp Version: N/A Severity: wishlist Greetings, I am ITPing this lightweight extensible scripting language and engine, used by E17 and applicable to many other projects. From the website: ferite is a scripting language and engine all in one managable chunk. It is designed to be easily extended in terms of API, and to be used within other applications making them more configurable and useful to the end user. It has a syntax similar to a number of other languages but remains clean and its own language. For now I just have shlib and -dev packages, in the future -dev may be split into -modules, -scripts, -bin, etc. License: BSD. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgpzOSr5HUMBv.pgp Description: PGP signature
Bug#140985: ITP: rbot -- IRC bot written in ruby
Package: wnpp Version: N/A; reported 2002-04-02 Severity: wishlist * Package name: rbot Version : 0.5 Upstream Author : Tom Gilbert [EMAIL PROTECTED] * URL : http://www.linuxbrit.co.uk/rbot/ * License : BSD Description : IRC bot written in ruby This is a irc bot that supports plugins and powerful feautures out of the box. The license is BSD-style: Copyright (C) 2002 Tom Gilbert. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the Software), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies of the Software and its documentation and acknowledgment shall be given in the documentation and software packages that this Software was used. THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux apocalypse 2.4.18 #1 Fri Mar 29 02:45:45 EST 2002 i686 Locale: LANG=en_US, LC_CTYPE=en_US -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Periodic cleanup of old automake versions (aka, removal of automake1.6)
Hello, We now have 5 versions of automake in the archive. These are necessary because new versions of automake tend to break backwards compatibility. We don't however need to keep all these versions around forever. So I'd like to get automake1.6 removed from the archive. The packages below have strict build-dependencies on automake1.6. It tends to be a bad idea to build-depend on the auto* tools (if for the only reason I'll be bugging you about it periodically), but if you want to continue, please transition to using automake1.7 or later (automake1.9 being the best). For most of you that should just work with no changes, if you have problems let me know. In a couple of weeks anyone who hasn't done this will get a wishlist bug filed against their package. A couple of weeks after that I will ask for the removal of automake1.6 and those bugs will be upgraded to severity serious. PS I would love if we could get rid of automake1.4. That's a bit unrealistic at this point, but if everyone can gently encourage their upstreams (and themselves) to start using later versions of automake, maybe it will be possible one day. amarok, Adeodato Simo [EMAIL PROTECTED] amaya, Steve Dunham [EMAIL PROTECTED] boson-base, Mickael Marchand [EMAIL PROTECTED] droidbattles, Kari Pahula [EMAIL PROTECTED] epplets, Stephen Frost [EMAIL PROTECTED] facturalux, Juan Manuel Garcia Molina [EMAIL PROTECTED] fam, Chuan-kai Lin [EMAIL PROTECTED] freqtweak, Enrique Robledo Arnuncio [EMAIL PROTECTED] gsmlib, automake1.6 isdnutils, Paul Slootman [EMAIL PROTECTED] k3d, David Martinez Moreno [EMAIL PROTECTED] kcdlabel, Stephen Gran [EMAIL PROTECTED] kde-i18n, Noel Kothe [EMAIL PROTECTED] ksimus-boolean, Aurelien Jarno [EMAIL PROTECTED] ksimus-datarecorder, Aurelien Jarno [EMAIL PROTECTED] ksimus-floatingpoint, Aurelien Jarno [EMAIL PROTECTED] ksociograma, Juan Manuel Garcia Molina [EMAIL PROTECTED] lesstif1-1, Sam Hocevar (Debian packages) [EMAIL PROTECTED] libiodbc2, Christian Hammers [EMAIL PROTECTED] libnss-ldap, Stephen Frost [EMAIL PROTECTED] libosip, Anand Kumria [EMAIL PROTECTED] libosip2, ARAKI Yasuhiro [EMAIL PROTECTED] libtheora, Christopher L Cheney [EMAIL PROTECTED] libwmf, Matej Vela [EMAIL PROTECTED] lineak-defaultplugin, Aurelien Jarno [EMAIL PROTECTED] lineak-kdeplugins, Aurelien Jarno [EMAIL PROTECTED] lineak-xosdplugin, Aurelien Jarno [EMAIL PROTECTED] multisync, Mikael Sennerholm [EMAIL PROTECTED] rsplib, Anibal Monsalve Salazar [EMAIL PROTECTED] snort, Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] splint, Samuele Giovanni Tonon [EMAIL PROTECTED] sppc, Mikael Hedin [EMAIL PROTECTED] sweep, Anand Kumria [EMAIL PROTECTED] swscanner, Andres Seco Hernandez [EMAIL PROTECTED] tapiir, Enrique Robledo Arnuncio [EMAIL PROTECTED] wmfsm, Arthur Korn [EMAIL PROTECTED] xbsql, Rafal Lewczuk [EMAIL PROTECTED] -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Firefox:I get redirected to microsoft website when entering http//kernel.org or http//debian.org
* Steve Langasek ([EMAIL PROTECTED]) wrote: On Mon, Aug 08, 2005 at 11:24:18AM +0300, Török Edvin wrote: First of all excuse me for cc-ing this to debian-devel, but I think this is an issue to be debated on debian-devel (besides being a bug report) Why? Did the maintainer ask for input? I did not, he filed the bug a couple of days ago and I haven't been able to respond yet. Try entering the following URLs in the location bar: http//kernel.org http//debian.org http//www.getthunderbird.org Result: the user gets redirected to the microsoft website due to the I'm feeling lucky google search Solution: disable the default I'm feeling lucky search, or pop up a window asking if he wants to do the search and getting redirected (about:config, keyword.enabled-false, or change keyword.URL) This issue occurs each time a user forgots the : from http, and types http// instead of http://, firefox performs a google search on http and microsoft is the first, and thus we get redirected there. This should not be default behaviour. I don't see anything particularly wrong with it. People who don't understand what URIs are will, IME, generally just type the domain name without specifying a protocol. People who understand what URIs are should bloody well be able to figure out that they did something wrong and try again. The fact that a number of these searches wind up at microsoft.com, though, when doing a direct google search on the entered string does not, suggests there is room for improvement in the auto-searching feature... -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: bogus lintian warning
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote: The lintian warning source-contains-CVS-dir is bogus. I agree that upstream should not put CVS in their tarballs. But sometimes they do. When they do, it is a violation of Debian standards to remove it from the orig.tar.gz file. So there is no question of doing that. If you want to maintain a package using cvs-buildpackage, you *have* to remove those files from the orig.tar.gz. If you remove the CVS files from your unpacked build directory, that's well and good, but dpkg-source refuses to honor this, printing helpful messages like dpkg-source: warning: ignoring deletion of directory stylesheet/CVS Of course dpkg-source ignores these because the packaging manual says that the .diff.gz can't specify deletions. (Never mind that patch is perfectly capable of handling deletions.) So, it's a bogus warning. It should be removed from lintian. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Why do we still have this on the distribution?
* Martin Schulze ([EMAIL PROTECTED]) wrote: Don Armstrong wrote: This raises a valid point; maybe the maintainer can comment on this? Since we already receive no security updates to php3 from upstream, is it feasible security-wise to keep it in the distribution for some years to come? I think the opinion of the stable release manager and security team should rank higher than the maintainer also. If the RM and or security team feel that a package is likely to be the cause of too much grief for them to support security fixes for, they should explain that fact to the maintainer(s) (if at all possible) and let the maintainer(s) determine if they will take on the burden of supporting the package in stable as well. If the maintainer doesn't want that burden,[1] the maintainer should file a severity serious bug against the package to keep it from being released in stable. FWIW: This would mean to remove all of Mozilla and friends, since they don't receive any security support upstream, and neither the maintainer or the security team are in a position to backport all fixes and correcte all stuff in the older versions. (upstream does only support the most recent version, which will be different about one month after the sarge release). I'm willing to try for firefox, but I'll admit that in some cases it may be impossible/too much work. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: [repost] Policy for Scheme implementations supporting SRFI 22, also virtual packages
* Jorgen Schaefer ([EMAIL PROTECTED]) wrote: Note: This is a repost of the mail at http://lists.debian.org/debian-devel/2005/04/msg01000.html - no replies were received at that time. I have now created a bug report against debian-policy (#310113) requesting the creation of the virtual packages mentioned in the policy. I will wait a few days before doing any more steps in this regard. Been a while since I've done anything Schemey, but this looks like a good proposal. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Peter Samuelson ([EMAIL PROTECTED]) wrote: [Roberto C. Sanchez] W: toshutils; Package Build-Depends on automake* or autoconf. This package Build-Depends on automake* or autoconf. This is almost never a good idea, as the package should run autoconf or automake on the source tree before the source package is built. There's lots of debate about this one. If your package uses horrible macros and kludges to make everything work, you may wish to play it cautious and manually run the same version of autoconf upstream uses. If it doesn't, in my view it's the responsibility of the autoconf maintainer to ensure that what he packages doesn't break arbitrary documented features. The big problem was autoconf 2.13 - 2.5x, but it's easy enough to make sure you run the correct one of those. automake1.x seems reasonable to depend on, since the maintainer has provided multiple versioned packages, so you can reasonably expect the API not to change within a single package. I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. W: toshutils; The file config.guess contains a timestamp line that is less than 2002. The autoconf file shown above contains a timestamp variable that has a year that is less than 2002. This means you need to update your autoconf files, as the current files will make it hard for your package to auto-build. W: toshutils; The file config.sub contains a timestamp line that is less than 2002. Build-depend on autotools-dev, and copy /usr/share/misc/config.guess and config.sub into place at build time. ln -fs also works. It's a very light build dep, so there's not much point in patching the right files into the source diff.gz. (However, note that if you don't want to bloat your diff.gz you may wish to mv the old files out of the way, and mv them back in your 'clean' target.) W: toshutils; The command xmessage -timeout 10 `fan -f` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan -n` listed in a menu file does not exist. W: toshutils; The command xmessage -timeout 10 `fan` listed in a menu file does not exist. Those seem pretty legitimate, although there's an argument to be made that menu should provide a syntax for this type of status display, so individual apps don't have to do it by hand. (Some window managers and desktop environments might have alternative facilities to xmessage, better integrated into their own weltanschauung.) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Eric Dorland ([EMAIL PROTECTED]) wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. My English teachers would kill me. That should read: I think a build-dependency on automake and autoconf is almost always a bad idea... -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Roberto C. Sanchez ([EMAIL PROTECTED]) wrote: On Sun, May 29, 2005 at 06:49:22PM -0400, Eric Dorland wrote: * Eric Dorland ([EMAIL PROTECTED]) wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. My English teachers would kill me. That should read: I think a build-dependency on automake and autoconf is almost always a bad idea... No problem. Based on the SubIDs in your GPG key, I consider myself fortunate you did not also answer in French :-) (Sorry, I really couldn't resist). Sadly, English is my first language. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Roberto C. Sanchez ([EMAIL PROTECTED]) wrote: On Sun, May 29, 2005 at 06:40:26PM -0400, Eric Dorland wrote: I don't think a dependency on automake and autoconf are almost always bad ideas. It makes the build more unpredictable, which is generally a bad thing. You should just run automake and/or autoconf on the unpacked source and ship it in the .diff.gz. An extra 2K won't hurt. I tried that once to see the difference. It went from ~4K to ~61K. Is that OK? In effect, the only thing changed in configure.in is the GTK macro to look for GTK 2 instead of 1.2. I have not had any weirdness buidling on my sarge box or in clean Sarge and Sid chroots. That seems somewhat unusual. Which package was this? But really, why quibble over 57K? Is that really a problem we should be worrying about? I've seen it a few times over the years, and they're usually pretty wacky. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Tollef Fog Heen ([EMAIL PROTECTED]) wrote: * Eric Dorland [Substituting your fixed sentence in the text below] | I think a build-dependency on automake and autoconf is almost always | a bad idea. It makes the build more unpredictable, which is | generally a bad thing. You should just run automake and/or autoconf | on the unpacked source and ship it in the .diff.gz. An extra 2K | won't hurt. You can argue this for a lot of files. An example is texinfo files which get their headers updated with information in the language of the build locale. Or why should docs be built as part of the build process at all? Or X fonts? Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. Well I don't disagree. But either we test every auto* using package this way, or we don't. The auto* tools are designed specifically so that they are not build dependencies. So making it a build dependency seems like a kludge. Now if we wanted to make it a general policy to test whether auto* regeneration works then I have less problem with that, but it would be a lot more work, for very little benefit that I can see. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Robert Collins ([EMAIL PROTECTED]) wrote: On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote: * Tollef Fog Heen ([EMAIL PROTECTED]) wrote: Because we want to test for buildability. We want to make it possible to change any part of the program and barring real errors, it should still build. That upstream writes crap configure.in/.ac and Makefile.ams is not an excuse, it's just a bug which should be fixed. Well I don't disagree. But either we test every auto* using package this way, or we don't. The auto* tools are designed specifically so that they are not build dependencies. So making it a build dependency seems like a kludge. Now if we wanted to make it a general policy to test whether auto* regeneration works then I have less problem with that, but it would be a lot more work, for very little benefit that I can see. The auto* tools are only /not/ a build dependency when one does not change the code. They are explicitly a build dependency for developers. Yes, they are necessary tools for developers. But nearly ever project I've ever seen ships the files generated from the auto* tools. We and the buildds do *not count* as end users - we are patching the code in most cases. But most packages aren't patching configure.in's and Makefile.am's. And the buildd is not patching the code, the maintainer is. So either you don't patch the package, or you be willing to require the relevant auto* be installed. Or you put the patch in the .diff.gz. I think that's the best option. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: On Mon, May 30, 2005 at 10:30:56AM -0400, Eric Dorland wrote: * Robert Collins ([EMAIL PROTECTED]) wrote: So either you don't patch the package, or you be willing to require the relevant auto* be installed. Or you put the patch in the .diff.gz. I think that's the best option. Uh, it's not as if adding the patch to the .diff.gz doesn't have its own set of problems... see /usr/share/doc/autotools-dev/README.Debian.gz, search for 'timestamp skew' I did forget that aspect, but of course liberal touch'ing can get you around those problems. Also automake's use of missing tends to make things just work even with timestamp skew (http://sources.redhat.com/automake/automake.html#maintainer_002dmode). Maintainer-mode is also a good solution. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Linda warnings
* Philipp Kern ([EMAIL PROTECTED]) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dorland wrote: Yes, they are necessary tools for developers. But nearly ever project I've ever seen ships the files generated from the auto* tools. However I feel the use of a build-dependency is a legitimate one if the package is built directly from the upstream's tagged SCM sources and thus contains no Autotools output. Why? Just run auto* on the unpacked tarball and ship them in the .diff.gz? What makes it more legitimate in that case? That the upstream developers didn't run the autotools? They would have, if it were a proper release. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: hijacking libhtml-mason-perl
* Charles Fry ([EMAIL PROTECTED]) wrote: Hi, I am an active user of the libhtml-mason-perl package, and am quite interested in seeing it continue to progress in Debian. Unfortunately, as outlined in my [1]message to debian-qa in January, the package appears to have been abandoned, and all attempts to contact the package maintainer have failed. 1. http://lists.debian.org/debian-qa/2005/01/msg00079.html I am not yet a Debian Developer, but I am interested in pursuing the path of becoming one. I have actively provided feedback of numerous Debian packages in the form of bug reports (including half of the outstanding libhtml-mason-perl bug reports), and I have already packaged the new upstream release of libhtml-mason-perl. I discussed the matter with Joshua Kwan, who recommended that I send this email, asking whether or not it would be acceptable for me to hijack the abandoned libhtml-mason-perl package. Any feedback/advise would be appreciated. I'm pretty interested in this package as well, and I'm willing to sponsor you. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Ongoing Firefox (and Thunderbird) Trademark problems
Hi, Now that sarge has been released it's time to revisit this problem. Most of the problems revolve around this document: http://www.mozilla.org/foundation/trademarks/policy.html From my reading of this, I'm not permitted to do such necessary things such as security patches, and retain the name Firefox. This has been brought up with Gervase Markham (who seems to be the Mozilla point of contact on these issues) before on debian-legal: http://lists.debian.org/debian-legal/2005/01/msg6.html http://lists.debian.org/debian-legal/2005/01/msg00023.html http://lists.debian.org/debian-legal/2005/01/msg00503.html Now, the Mozilla Foundation is willing to give us permission to use the marks, but only to Debian specifically. To me, this feels like a violation (at least in spirit) of DFSG #8. It's now nearly six months since the debian-legal threads, sarge is out the door, so it's time to do something about this. As I see it, we have the following options: 1. Completely ignore their Trademark Policy document and let MoFo come to us if they're not happy with our use of the marks. 2. Rename Firefox and strip all trademarks out. 3. Accept MoFo's offer of Debian-specific trademark usage. 4. Try to negotiate some other arrangement with MoFo. I don't believe we can really do #1 in good conscience. I don't believe #3 is acceptable under the DFSG. It's been 6 months with no real progress towards a resolution that I can see, so #4 seems to be stalled, but again I invite Gervase to restart discussions. That lives #2 as an unappealing solution, but perhaps the only way to go. So for hopefully the last time I'd like to get people's opinion on this before I take any action. Am I being too pedantic? I'd also love to hear how Ubuntu is handling this (not to fan the flames, just to get a different perspective). -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Julien BLACHE ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] wrote: Now, the Mozilla Foundation is willing to give us permission to use the marks, but only to Debian specifically. To me, this feels like a violation (at least in spirit) of DFSG #8. It's now nearly six months I'd say that it is a clear violation of the DFSG, not only in spirit. So for hopefully the last time I'd like to get people's opinion on this before I take any action. Am I being too pedantic? I'd also love to hear how Ubuntu is handling this (not to fan the flames, just to get a different perspective). The Debian Way (tm) would be to drop mozilla, firefox and thunderbird from Debian -- there's no reason what works with the FSF can't work with the MoFo. Don't be so militant. Firefox is clearly a popular and useful program. There's no reason to be so extreme. By the way, what is the status wrt OpenOffice.org, which has the same kind of issue ? I'm not sure, I don't think the issues are entirely the same. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Matthew Garrett ([EMAIL PROTECTED]) wrote: Julien BLACHE [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: What is DFSG 4 if not a grudging acceptance of this sort of behaviour as free? (This is a compromise. The Debian Project encourages all authors to not restrict any files, source or binary, from being modified.) Says it all. Right. We don't like it, but we think it's free. Requiring a name change because we apply a security patch or fix a bug crosses the border. It's not like if we were forking their codebase. We have permission to apply security patches and fix bugs without changing the name. We (as in Debian) may have the permission, but that permission does not flow downstream. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Gervase Markham ([EMAIL PROTECTED]) wrote: Thijs Kinkhorst wrote: However, in #4, an explicit exception is made for program names and version numbers. They are not considered fundamental enough to software to require them to be as absolutely free as source code. So if we accept this exception for software coming in, why can't we accept this same exception for software derived from our distribution? This is basically our position. I include below, for reference, an email I sent to Eric 24 hours ago in response to his request to settle this issue. It outlines a rough shape of an agreement which I hope we can reach. Gerv, I'm not sure what happened, but I never saw this email. It might be beneficial though to have an agreement with MoFo that allows for downstreams of Debian to also use the name, as long as they only modify the package in ways similar to Debian. If you have a downstream that just copies, or copies-and-fixes-bugs, this would surely be just as acceptable to MoFo, right? [snip] Previous email to Eric: Original Message Subject: Re: Firefox Trademark Issues Date: Sun, 12 Jun 2005 18:15:27 +0100 From: Gervase Markham [EMAIL PROTECTED] Organization: mozilla.org To: Eric Dorland [EMAIL PROTECTED] References: [EMAIL PROTECTED] Eric Dorland wrote: Sarge is released, so the time is ripe to figure out what I'm going to do. This issue has been dragging out like 6 months now, so lets hash it out. OK. One thing I remember being a concern last time was the level of difficulty of rebranding Firefox. You may have noticed that the Firefox 1.1 preview release has been rebranded as Deer Park. The work went on in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=294399 There were a few false starts, but I think it's clear that fundamentally, rebranding Firefox is not a complicated or lengthy operation. That's very good news. No matter how things work out, having an escape plan is the right thing to do. Thanks. Having said that, is it possible to come to an agreement along the following lines? - The Mozilla Foundation gives Debian permission to use the Firefox logo and brand name. Using the logo is not possible, as it is not licensed under a free license. - That permission is revocable, but not for shipped or frozen versions of Debian. - It's the Foundation's responsibility to make sure the Debian version meets our requirements; if we have issues, we sort them out with the maintainer in the first instance. - The requirements in question (or, probably, a set of principles or something like that) would be the result of a discussion between the Foundation and the maintainer. - The permission to ship copies of Debian's version extends to everyone. - The permission to ship modified versions of Debian's version does not extend to everyone; if they make changes, they have to rebrand or ask permission. This is analogous to the clause which is found in some BSD licences, stating that modified packages of software are required to have a different name. As noted above, this is not a difficult exercise. Can we make this fly? This agreement is not evil, but internally we have to work out whether we can make this sort of agreement under the DFSG. If you came back with something non-Debian specific and still gave us the ability to do the things we need to, then there probably wouldn't be any debate. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Florian Weimer ([EMAIL PROTECTED]) wrote: * Eric Dorland: 1. Completely ignore their Trademark Policy document and let MoFo come to us if they're not happy with our use of the marks. This is the policy we have adopted with PHP, Apache and similarly-licensed software. It's basically the only choice when we want to continue to distribute software such as phpGroupWare or Apache::Request. That's true, but in Mozilla's case they have a document that is very specific about what can and can't be done. PHP and Apache don't have such documents as far as I can see, so it's easier to take a passive approach. In the Firefox case, the trademark situation is extremely murky because in many countries, the Mozilla Foundation doesn't even own that trademark WRT to computer programs (examples: Germany, United Kingdom). Looks like someone didn't do his or her homework before choosing the name. 8-( -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Peter Samuelson ([EMAIL PROTECTED]) wrote: [Jonas Meurer] i second the idea that debian should provide sources to the community which are entirely free. sources which contain the Mozilla trademarks and ignore their license are not entirely free. Nobody is ignoring the Mozilla trademark license. The issue is that Debian is being offered non-transferrable rights to the trademark. And whether not having DFSG-free rights to the *brand* makes the *product* non-free. FWIW, I agree with the proposed extension to DFSG#4: [in terms of distributing software,] Debian will not accept or exercise rights which cannot be granted to Debian's users. Proposed extension? Is this actually been on the table before? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Anthony Towns (aj@azure.humbug.org.au) wrote: Eric Dorland wrote: Now, the Mozilla Foundation is willing to give us permission to use the marks, but only to Debian specifically. To me, this feels like a violation (at least in spirit) of DFSG #8. Our priorities are our users and free software Does having the package actually be called firefox or thunderbird make life easier and better for users? I think so. Does the opposite make it worse? I think so. Certainly retaining the name makes life easier. But the easier thing and the right thing are often in conflict. I've clearly been very reluctant to take the renaming step, because I know it will cause a lot of acrimony. But just because it's a painful step doesn't necessarily make it the wrong one. Does calling it firefox or thunderbird hurt free software? It doesn't hurt us -- we're already doing it, it doesn't hurt upstream -- they're happy for us to do it, it doesn't hurt our users as above. Does it hurt Debian derivatives? Depends on the permission -- it seems hard to give Debian permission but not give random people permission to redistribute Debian's deb, which is all most distributors do. The reason we're already doing it was for expediency during the sarge release. We shouldn't use that as justification for continuing to do so. I think keeping the name does hurt Debian. Keeping the name means we cut a Debian specific deal. That doesn't sit well with me. I don't want to get special treatment just because we're popular. Does changing the name hurt free software? It hurts us, by taking away time from other things, it hurts upstream by decreasing their name recognition and providing a bunch of FAQs of the form what's wrong with firefox that Debian doesn't distribute it?. Depending on how much time it takes us to do it right, it might hurt our derivatives even more, by introducing new RC bugs and destabilising the release, and providing a base system that users are less happy with (Why doesn't it come with firefox?). YMMV, of course. Cheers, aj -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Adrian von Bidder ([EMAIL PROTECTED]) wrote: On Tuesday 14 June 2005 18.21, Eric Dorland wrote: * Matthew Garrett ([EMAIL PROTECTED]) wrote: Julien BLACHE [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] wrote: What is DFSG 4 if not a grudging acceptance of this sort of behaviour as free? (This is a compromise. The Debian Project encourages all authors to not restrict any files, source or binary, from being modified.) Says it all. Right. We don't like it, but we think it's free. Requiring a name change because we apply a security patch or fix a bug crosses the border. It's not like if we were forking their codebase. We have permission to apply security patches and fix bugs without changing the name. We (as in Debian) may have the permission, but that permission does not flow downstream. So? As I understand DSFG 8, this covers only the case that the firefox package distributed by Debian *as is* must still be usable legally when used outside Debian. Come on, that can't possibly be the intention. I could craft a license that says you have all the rights of the BSD license, as long as your code is exactly the same as it is in Debian. That would be insane. The first sentence goes The rights attached to the program must not depend on the program's being part of a Debian system.. Clearly if we accepted the MoFo proposal, the program would have more rights within Debian than without, and wouldn't be compatible with DFSG #8. Yes, it's not nice, it's crap, but it's still entirely possible within the (pseudo-)legal framewark Debian gives itself. cheers -- vbi -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Julien BLACHE ([EMAIL PROTECTED]) wrote: Eric Dorland [EMAIL PROTECTED] wrote: The Debian Way (tm) would be to drop mozilla, firefox and thunderbird from Debian -- there's no reason what works with the FSF can't work with the MoFo. Don't be so militant. Firefox is clearly a popular and useful program. There's no reason to be so extreme. Eh ? So why are we removing *all* the GFDLed docs, then ? When did this Project stop being militant ? There's a much more rational solution in renaming Firefox to get around the trademark restrictions. I'm not about to swat files with nuclear weapons. By the way, what is the status wrt OpenOffice.org, which has the same kind of issue ? I'm not sure, I don't think the issues are entirely the same. Yes, IIRC, it was a bit more relaxed. We did not ship Qt and KDE until they fixed their license; we're removing all the GFDL docs; we're removing every firmware we can find in the distro. Let's remove anything that falls under the Mozilla trademark policy, or we're clearly creating a double-standard. JB. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Arthur de Jong ([EMAIL PROTECTED]) wrote: On Tue, 2005-06-14 at 19:30 +0100, Matthew Garrett wrote: Manoj Srivastava [EMAIL PROTECTED] wrote: While this argument was indeed tempting, I think we also need to look at how free the resulting package is: Can a derivbative take any package in main, modify it, and further redistribute it? If yes, then the package can remain in main, and is free; if not, then the package is not free. Our users have permission to modify it and further redistribute it *as long as they change the name*. That's a limitation we're willing to accept for ourselves - why should it not be free enough for our users? Let's say we call it mozilla-firefox (assuming we are allowed to in the first place) and downstream (making some modifications) is not allowed to call it mozilla-firefox. If we call it debian-firefox then downstream is still not allowed (under the same conditions) to call it mozilla-firefox. The difference is not that huge to me. (but naming the package just firefox seems to me like a good idea in the first place) The difference is we have perhaps compromised our principles to keep calling it Firefox. BTW, don't be fooled into thinking we'll be able to call it debian-firefox. If we have to rename it will not be able to include the string firefox anywhere in that name. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Adrian von Bidder ([EMAIL PROTECTED]) wrote: On Tuesday 14 June 2005 16.20, Humberto Massa Guimarães wrote: * Towns :: Does calling it firefox or thunderbird hurt free software? At first, no. But it *does* hurt our users. Why? Because they are confident that getting something from the Debian mirror, modifying it and re-distributing under the same terms is allowed. And they can be burned after some time. And they *will* blame it on Debian. DFSG 4 again: it is grudgingly allowed that people are required to rename what they get from Debian. People seem to be using DFSG 4 as a justification for keeping the name, but I believe that is flawed. DFSG 4 allows for a license to say if you meet conditions X, you can use our name, otherwise you can't. So the TeX guys have a test suite and specifications that you have to pass to call the software TeX. What if the license said You can call the program TeX if it's part of Debian. Would we still call it TeX? Clearly that's a violation of DFSG #8. Should we allow it? I don't think #4 should be used to bypass another one of the guidelines. Now in the Mozilla case we're not talking about software licenses, we're talking about trademarks, which makes things murkier. But the principles should still apply. We're being offered a Debian specific deal. I don't think #8 allows us to do that, even if it is permissible under #4. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Julien BLACHE ([EMAIL PROTECTED]) wrote: Humberto Massa Guimarães [EMAIL PROTECTED] wrote: If we drop their products, we issue a PR explaining why we dropped them. Just like we're about to do with the GFDL'ed docs. And *then* Debian will be left without a mozilla-compatible web browser, not without Mozilla itself. There's still Galeon and a couple of others, based on Gecko. Should be enough. Julien, I'm not going to remove Firefox from the distro over this issue. Let it go, it's not going to happen. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Cesar Martinez Izquierdo ([EMAIL PROTECTED]) wrote: El Martes 14 Junio 2005 18:54, Humberto Massa Guimarães escribió: Firefox is free software, and DFSG-compliant: The license may require derived works to carry a different name or version number from the original software. (Even if it is a compromise). But is non-rebranded Firefox *really* distributable by us under GPL#6, no further restrictions? It seems to me that if our users can't customize and compile and distribute Firefox under the terms of the GPL, we are passing along another restriction over those in the GPL. Yes, they can customize and compile and distribute Firefox, but they need to pay attention to the trademark issues, as well as patent issues and any other law that may apply in their country. I think everything is clear enough. And I think it is quite reasonable that an upstream author asks for a name change for a modified version. Even for security fixes. There is lots of modified versions of programs out there and the upstreams authors are always suffering bug reports that doesn't concern the original version. So, in this paragraph you are basically stating that we *should* rename firefox to save them from such burden. No, I think we should NOT rename Firefox to save our *direct* users from such burden. A lot of people would get greatly confused with a different name for Firefox, even if you don't think so. *Indirect* users such as derived distributions should check the licenses and other trademark or patent issues before start distributing anything. It's their task to check it. We can help them if we create Debian packages which are easy to rename, but we shouldn't confuse the rest of the users just to make this task easier to derived distributions. We're losing sight of the key issue here. We *cannot* use their trademark under their current trademark policy. They are offering us a deal that is Debian specific to allow use to use the marks. Can we accept such a deal as a project? Does the DFSG allow us to? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Humberto Massa Guimarães ([EMAIL PROTECTED]) wrote: We're losing sight of the key issue here. We *cannot* use their trademark under their current trademark policy. They are offering us a deal that is Debian specific to allow use to use the marks. Can we accept such a deal as a project? Does the DFSG allow us to? Well said. IMHO, no. DFSG #8 -- witch is part of the SC, IIRC -- forbids us to have rights that our users don't have. This is indeed my feeling as well. But I'm willing to be convinced that my interpretation is incorrect. BTW, any Ubuntu developers care to comment? I'm interested in second opinions and how you guys are handling this situation? Did you accept an arrangement with MoFo? -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Jose Carlos Garcia Sogo ([EMAIL PROTECTED]) wrote: El mar, 14-06-2005 a las 15:35 -0400, Eric Dorland escribió: We're losing sight of the key issue here. We *cannot* use their trademark under their current trademark policy. They are offering us a deal that is Debian specific to allow use to use the marks. Can we accept such a deal as a project? Does the DFSG allow us to? Yes and yes. Thanks for your argument, I'm fully convinced. :-P -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Jose Carlos Garcia Sogo ([EMAIL PROTECTED]) wrote: El mar, 14-06-2005 a las 16:45 -0300, Humberto Massa Guimarães escribió: Let's say we call it mozilla-firefox (assuming we are allowed to in the first place) and downstream (making some modifications) is not allowed to call it mozilla-firefox. If we call it debian-firefox then downstream is still not allowed (under the same conditions) to call it mozilla-firefox. The difference is not You seem to be wrong about the Mozilla Foundation's trademark policy. They say no one (ok, they excepted Debian especially, but *I*, personally, do not think this flies because of DFSG#8) can use the words Mozilla or Firefox (or Thunderbird etc) in their browser. So, if we rename the browser, we must call it (for instance) IceWeasel, and yes, any person downstream from us can call it anything but Firefox or Mozilla or Mozilla Firefox. BTW, we should remove any gecko based browser too. After all they depend in MOZILLA-browser. Not only firefox is going to be blamed here. AFAIK, Mozilla is not trademarked. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Jose Carlos Garcia Sogo ([EMAIL PROTECTED]) wrote: El mar, 14-06-2005 a las 15:12 -0400, Eric Dorland escribió: [...] Let's say we call it mozilla-firefox (assuming we are allowed to in the first place) and downstream (making some modifications) is not allowed to call it mozilla-firefox. If we call it debian-firefox then downstream is still not allowed (under the same conditions) to call it mozilla-firefox. The difference is not that huge to me. (but naming the package just firefox seems to me like a good idea in the first place) The difference is we have perhaps compromised our principles to keep calling it Firefox. BTW, don't be fooled into thinking we'll be able to call it debian-firefox. If we have to rename it will not be able to include the string firefox anywhere in that name. Then rename it to firebitch and make a campaing on WSJ to let people know about the new software? How is then people going to get the software? I cannot install anything that I don't know how to it is named. I even cannot search for it... or are we going to call it the browser before known as firefox? I never claimed the renaming would not be confusing and painful. Sometimes we have to do painful things because they're the right thing to do. I think everyone realizes a rename would suck the big one. That's why I'm approaching it cautiously and looking for alternatives. But complaining how much a rename would stink is not constructive. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Marco d'Itri ([EMAIL PROTECTED]) wrote: On Jun 15, Eric Dorland [EMAIL PROTECTED] wrote: I never claimed the renaming would not be confusing and painful. Sometimes we have to do painful things because they're the right thing to do. I think everyone realizes a rename would suck the big one. That's why I'm approaching it cautiously and looking for alternatives. But complaining how much a rename would stink is not constructive. It's an important part in evaluating the balance between the priorities of our users and free software... And where do we strike that balance in this case? I think gaining more freedom for our users is the best thing in the long run. Sure, there will be shorter term pain, but we need to take the long view. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: On Tue, Jun 14, 2005 at 03:05:20PM -0400, Eric Dorland wrote: * Adrian von Bidder ([EMAIL PROTECTED]) wrote: As I understand DSFG 8, this covers only the case that the firefox package distributed by Debian *as is* must still be usable legally when used outside Debian. Come on, that can't possibly be the intention. I could craft a license that says you have all the rights of the BSD license, as long as your code is exactly the same as it is in Debian. That would be insane. Yes, but it's not relevant to the case at hand. Why is it irrelevant? In the firefox case, people say You have all the rights of the license; and as long as it's in Debian or it's not modified, you may call it firefox. Exactly. How is that permissible under DFSG #8. Your example isn't even close to that. The first sentence goes The rights attached to the program must not depend on the program's being part of a Debian system.. Clearly if we accepted the MoFo proposal, the program would have more rights within Debian than without, and wouldn't be compatible with DFSG #8. First, a program doesn't have any right. People do. Yes, my phrasing was slightly off. It should say... the program would have more rights attached to it within Debian than without. I think the meaning was still clear. Second, this trademark business has nothing to do with the program's license. Trademarks licenses and software licenses are two entirely distinct beasts, and you shouldn't even attempt to mix them. I don't recall saying or implying they were the same thing. The DFSG talks about software licenses. It does not talk about patents (which is a problem), and it does not talk about trademarks either (which I don't think is a problem, but I don't know whether other people feel the same way). A trademark license simply /is not an issue/ with regards to Free Software; whether you're allowed to use a trademark or not has no impact on whether or not you're allowed to modify, study, or redistribute the software. As such, it cannot make the license non-free. Just because the DFSG was developed only within the context of software licenses, it doesn't mean their principles don't apply to other things. Let's construct an analogy using patents. Company X releases foowhizbang under a BSD license. But contained within foowhizbang is their patented algorithm, which they're actively enforcing against anyone who distributes their own complied binaries. Except they've granted the Debian project an exception. Would we distribute this software? Even though we're not discussing a software license, I think the principles behind the DFSG would mean we would not distribute this software. I hope the parallels I'm drawing are clear. Now, I haven't claimed Firefox's trademark makes it non-free. My question is whether I can use the trademark in Debian. If I look at the Mozilla Trademark Policy, I cannot. Now MoFo has agreed to extend us permission to use the mark. I don't think we should accept that permission. We shouldn't be making deals purely in our own self interest. That's what DFSG #8 is all about. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Marco d'Itri ([EMAIL PROTECTED]) wrote: On Jun 15, Eric Dorland [EMAIL PROTECTED] wrote: It's an important part in evaluating the balance between the priorities of our users and free software... And where do we strike that balance in this case? I think gaining more freedom for our users is the best thing in the long run. Sure, there will be shorter term pain, but we need to take the long view. I'm here to build the best free OS, not to collect the most liberal trademarks. If a trademark license allows us to ship the software the way we want and there are no practical problems in removing trademark references if it were ever needed then I think it's obvious that we would do a disservice to our users by removing from Debian such a widely know trademark without a good reason. Well the whole issue is I don't believe we're allowed to ship the software the way we want. We would be compromising our principles by doing so. There are good reasons for a trademark license to be restrictive and I believe that the MF made a good case about their one, so I do not think that it's important for users to have the permission to use it however they want. The code is still free no matter how it is branded so this is not an issue of software freedom, at best this is a marketing issue. I never asked them to give users permission to use it however they want. But their current permissions are too restrictive. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Wouter Verhelst ([EMAIL PROTECTED]) wrote: On Wed, Jun 15, 2005 at 02:10:06AM -0400, Eric Dorland wrote: * Wouter Verhelst ([EMAIL PROTECTED]) wrote: On Tue, Jun 14, 2005 at 03:05:20PM -0400, Eric Dorland wrote: Come on, that can't possibly be the intention. I could craft a license that says you have all the rights of the BSD license, as long as your code is exactly the same as it is in Debian. That would be insane. Yes, but it's not relevant to the case at hand. Why is it irrelevant? Because your example is about code, while the other example is about a name. Not allowing people to use modified code is clearly non-free; not allowing people to use the same name is not. I never said it was non-free. The question is still whether we can accept the use of the name or not. In the firefox case, people say You have all the rights of the license; and as long as it's in Debian or it's not modified, you may call it firefox. Exactly. How is that permissible under DFSG #8. The DFSG does not apply to trademark licenses, only to software (copyright) licenses. So where are the guidelines for trademarks? Oh wait they're aren't any. That doesn't mean that anything goes with respect to trademarks. [...] The DFSG talks about software licenses. It does not talk about patents (which is a problem), and it does not talk about trademarks either (which I don't think is a problem, but I don't know whether other people feel the same way). A trademark license simply /is not an issue/ with regards to Free Software; whether you're allowed to use a trademark or not has no impact on whether or not you're allowed to modify, study, or redistribute the software. As such, it cannot make the license non-free. Just because the DFSG was developed only within the context of software licenses, it doesn't mean their principles don't apply to other things. Where possible, sure. But principles doesn't mean the rules should be exactly the same. Please stop putting words in my mouth. I never said that the rules should necessarily be the same. But I am of the opinion that the spirit of DFSG #8 should apply. Let's construct an analogy using patents. Company X releases foowhizbang under a BSD license. But contained within foowhizbang is their patented algorithm, which they're actively enforcing against anyone who distributes their own complied binaries. Except they've granted the Debian project an exception. Would we distribute this software? Even though we're not discussing a software license, I think the principles behind the DFSG would mean we would not distribute this software. I hope the parallels I'm drawing are clear. We will not distribute anything that is encumbered with an actively enforced patent, period. Whether we have an exception or not isn't even relevant. That's not true. If the patent was actively enforced, but a blanket exception was given to OSS implementations, we would distribute it. We will distribute things that have a copyright licence which is actively enforced. All of the GNU stuff, for example. Come on, we distribute things with actively enforced copyrights that have DFSG licenses, not just anything. The two are, again, completely different beasts. The same is true for trademark licenses, and I don't see why a requirement to rename it unless given permission (which, as it happens, Debian has gotten) is wrong. If we accept it, we've made a Debian-specific deal to distribute that software. Is that acceptable? I don't believe it is. Now, I haven't claimed Firefox's trademark makes it non-free. My question is whether I can use the trademark in Debian. If I look at the Mozilla Trademark Policy, I cannot. Now MoFo has agreed to extend us permission to use the mark. I don't think we should accept that permission. We shouldn't be making deals purely in our own self interest. We're not doing that. Yes, we are. We're making a deal to distribute software with a certain name that only benefits Debian. DFSG#8 _cannot_ be applied to trademarks. Due to the nature of trademark law, the Mozilla Foundation _cannot_ give a blanket permission to call firefox anything deriving even a slight bit of code from the Debian packages; if they did that, they would lose their trademark. It's as simple as that. Sure it can. Mozilla could have a trademark policy that says If your build of Firefox meets conditions X, Y, Z, you can use our trademark. Anyone is free to meet those conditions. Other projects do this with their trademarks. But the mozilla DFSG#8 applies to copyright law, where such a rule does make sense and is possible. It does not apply to trademark law, which is completely different. -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Christian Perrier ([EMAIL PROTECTED]) wrote: We drop their products from Debian, they lose market share. We drop Really? Do you actually believe that debian users would switch to Konqueror just because we stopped distributing Firefox in Debian? What about Galeon and the others Gecko-based browsers ? Non issue. Nearly all organizations care about internal standards. If the organization policy for web browsers is Firefox, every environment for which Firefox is not part of is out of the organization standard. This is how IT is handled in professionnal environments, like it or not. In short, as ONERA's policy will soon be that Firefox is the company's standard, I may be forced to drop off Debian as the official recommendation *I* am responsible for Linux systems if Debian drops Firefox out because of some license/trademark/whatever_you_call_it issues. Please relax. The discussion is not whether we drop Firefox from the distro. This will not happen, Firefox will still be here for as long as it's free software and useful. The *only* issue is whether we can use the name Firefox or not. No matter what is decided, the software is going to be in Debian. And, no, we won't switch to Galeon. Not unless there is a Windows port (yes, I live in the real world, where MS-Windows exists and will exist for a long time). So, please, people who enjoy swimming in the nasty pool of licenses and legal stuff, don't make me just ban Debian of my own company. Or make me maintain unofficial firefox packages which will of course be of lower quality than those from the firefox package maintainers in Debian. (for most people around who are unaware of it and for more clarity, ONERA is the French Aerospace research center, where I'm responsible for desktop systems architectures) This is probably my first and last comment about this issue. I *hate* legal discussions, licenses nitpicking and haircutting. I understand that some people enjoy this and I even understand we need some people to do so. But I feel there are enough *real* issues and we probably should not begin to invent new ones..:-) I know this mail will sound a bit rude but some parts of this thread really made me nervous. (taking pills now..:-))) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
