Re: setting umask globally
also sprach Steve Greenland [EMAIL PROTECTED] [2005.06.17.0208 +0200]: And unless they know about the completely non-standard /etc/umask.conf, they'll still edit multiple files. True enough... unless files like /etc/profile include some magic code for umask (rather than the umask call itself), and a one-line comment telling people to go to /etc/umask.conf. I think the PAM way is the better way. An alternative would be to refer to libpam-umask from such a comment. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! 'the answer to the great question...' 'of life, the universe and everything...' said deep thought. 'is...' said deep thought, and paused. 'is...' 'forty-two,' said deep thought, with infinite majesty and calm. -- hitchhiker's guide to the galaxy signature.asc Description: Digital signature
Re: Upcoming removal of orphaned packages
On Thu, Jun 16, 2005 at 06:18:06PM +0100, Martin Michlmayr wrote: iceme -- A graphical menu editor for IceWM [#227054] * Orphaned 520 days ago * Package orphaned 360 days ago. icepref -- Yet another configuration tool for IceWM [#227077] * Orphaned 520 days ago * Package orphaned 360 days ago. I use both of these and would like to adopt them. I will upload next week (via Anibal). -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpNfAq6XxJaG.pgp Description: PGP signature
Re: setting umask globally
Filing a bug against login... (shadow maintainer hat on) bugger...:-) I was reading this thread and just told to self: dude, this will end up in a BR against shadow/login:-) So, to summarize, the rationale here is: don't set umask in the default login.defs and leave this to shells and/or pam_umask. Right? I have to keep some kind of explanation for the default login.defs file, this is why I prefer asking immediately...:-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
day. Many of the false positives were from the same people, who could have removed their CBL listing easily. (If they didn't fix the Hmmm, IIRC I was among these ones and the reasons was the CBL listing all dynamic and non dynamic addresses from Free, one of the 2-3 major ISPs for DSL in France. And, IIRC, again, I just gave up, routed my mail to you through my ISP mail server and went to another tasks because I consider I have other things to do than just hunting down why my address is listed in this or that blacklist. No real angryness here...I have been able to circumvent the problem but, well, no real happyness as well...:-) About greylisting: that's a nice feature of course. But just try some day to send the mails you wrote during a long airline flight from a WiFi hotspot in an airport and do it through a server implementing greylisting: you'll just find out that no mail can be sent unless you stay connected for a quite long time. User-configurable greylisting thus seems mandatory if we want to have it. Same for any BL system on debian.org systems, probably, if this can be made (other people are mail wizards, you included, BlarsI am definitely not..:-))). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: setting umask globally
also sprach Christian Perrier [EMAIL PROTECTED] [2005.06.17.0658 +0200]: So, to summarize, the rationale here is: don't set umask in the default login.defs and leave this to shells and/or pam_umask. Right? Yes. I have to keep some kind of explanation for the default login.defs file, this is why I prefer asking immediately...:-) See the bug report... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! why didn't noah swat those two mosquitoes? signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
On Fri, 2005-06-17 at 07:41 +0200, Florian Weimer wrote: * Wouter Verhelst: What's painful about it? I wouldn't be surprised if it already increases load on lists.debian.org significantly. Not nearly as much as people who teergrub us. We can _really_ feel them. Cheers, Pasc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Fri, 2005-06-17 at 10:45 +0900, Miles Bader wrote: Wouter Verhelst [EMAIL PROTECTED] writes: What's painful about it? It stops a lot of viruses and spam, with no false positives. What's the problem? No false positives seems a bit optimistic. One problem I've encountered in the past is big mail providers (like yahoo) who will send retries from _different_ servers, which sometimes don't even have a DNS entry (maybge it's just DNS propagation delay, I don't know). How do greylisting services determine that a message is being resent (and so should be accepted this time)? If it's by hostname or host address, this would sometimes fail with systems like the above. I've had pretty good luck by matching by /24. The mail servers will usually be within that range. This has worked for the mail I host in terms of receiving from yahoo, ebay, hotmail, etc, etc Realistically, it's not a solution to spam, but it does at least cut down on what you get a fair bit. Pasc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Reduce the amount of spam for @debian.org (Was: Greylisting for @debian.org email, please)
[Santiago Vila] For example, we could use greylisting. Or we could reject messages that are known to come directly from trojanized windows machines acting as open proxies. Or even better, we could do both things. Or a completely different option. Here at the university the postmasters implemented a system to delay delivery based on blacklist entries. The delaying is done during the first connect, and does not require the MTA in the other end to reconnect, like greylisting. The idea is simple: - Keep/use a list of good and not soo good blacklists for MTA hosts. - If the other side is listed in one of this blacklists, act as a _very_ slow SMTP server. The initial hello reply is delayed 1-2 minutes in this case, and if the client try to send anything in this period, the connection is dropped. The SMTP protocol specifies that the client should not send anything before receiving the intro line from the other end, so this is safe to do. - This reduced the amount of spam with more than 90 percent, I've been told. The current spam software do not seem to have time to wait for a reply, or give up the delivery after a few seconds without any reply. In either case, all standard-compliant MTAs are able to get their mails through, even if they are listed in a blacklist. - MTAs not listed in a blacklist is passed throught without any delays. Could this be an idea for Debian as well? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Le Ven 17 Juin 2005 01:42, Wouter Verhelst a crit : On Thu, Jun 16, 2005 at 03:09:47PM +0200, Pierre Habouzit wrote: Le Jeu 16 Juin 2005 14:33, Santiago Vila a crit : Now that we have released sarge, I would like to ask debian-admin and the Project Leader to consider seriously doing something to reduce the level of spam we have to receive, store, and filter in our @debian.org addresses. For example, we could use greylisting. Or we could reject messages that are known to come directly from trojanized windows machines acting as open proxies. Or even better, we could do both things. I fully disagree, greylisting is really painful, What's painful about it? the delay it creates. For a ML it's often OK, and it may be benefic (since it will delay flames too, and also diminish their length and annoyance) but for our @debian.org addresses ... that sucks, I often rely on the fact that delivery is immediate on those. It stops a lot of viruses and spam, with no false positives. What's the problem? it can have false positive or at least be inefficient. e.g. : the alumni site of my school uses SRS rewriting since it does only mail forwarding (no real mailboxes) and that without that it would send to many bad mail wrt SPF. SRS changes the MAIL FROM for one user every 3 or 4 hours. so every 3 or 4 hours he comes stuck in greylisting server again and again. For such domains, greylisting sucks. though, I think greylisting is a quite good last barrier defense. I have recently written a policy [1] daemon for postfix (that has been accepted recently) that works like that : it looks RBL's, and checks SPF against mails. if any of those tests is suspicious, it answer 'DUNNO' (and also let the mail go through the next postfix filtering rule). if NONE of them was suspicious (no rbl hit, and clean SPF) then it answer 'OK' to postfix, and also validate the mail. My following filtering rule (and in fact last one) is a greylisting daemon. with this scheme, I don't greylist by default, and with the right RBLs and SPF settings, I have quite good results, combining a not to large growth of the greylist DB, and not too many delays, and no false positives. This is not an ad for my tool (it's called whitelister and just entered debian tonight ;p) but I think in such a scheme, greylisting is ok and also really effective. and after that, you can have your AVcheck and AS check, and you have a very robust, light, scalable queue. Don't forget also that MX of the planet that have a very big traffic list domains that are greylisted, and force mails delivered to such domains to wait 1h (if not more) in queue after any retry, in order to be really sure to retry *after* the greylist timeout. I'm sure of it, because I know admins of such MX's, and greylisting pulls the charge on their shoulder ... All the reasons I detail here are the one that make me think full, default, complete greylisting on a domain is *not* a good idea. [1] http://www.postfix.org/SMTPD_POLICY_README.html -- O Pierre Habouzit O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9lHG4Z1Eyr.pgp Description: PGP signature
Re: Reduce the amount of spam for @debian.org (Was: Greylisting for @debian.org email, please)
gmail.com used to do that to lists.debian.org. We deliver ~300,000 emails to gmail a day. It resulted in some deliveries timing out before they were even attempted; I'll let you imagine the rest. Cheers, Pasc On Fri, 2005-06-17 at 08:35 +0200, Petter Reinholdtsen wrote: [Santiago Vila] For example, we could use greylisting. Or we could reject messages that are known to come directly from trojanized windows machines acting as open proxies. Or even better, we could do both things. Or a completely different option. Here at the university the postmasters implemented a system to delay delivery based on blacklist entries. The delaying is done during the first connect, and does not require the MTA in the other end to reconnect, like greylisting. The idea is simple: - Keep/use a list of good and not soo good blacklists for MTA hosts. - If the other side is listed in one of this blacklists, act as a _very_ slow SMTP server. The initial hello reply is delayed 1-2 minutes in this case, and if the client try to send anything in this period, the connection is dropped. The SMTP protocol specifies that the client should not send anything before receiving the intro line from the other end, so this is safe to do. - This reduced the amount of spam with more than 90 percent, I've been told. The current spam software do not seem to have time to wait for a reply, or give up the delivery after a few seconds without any reply. In either case, all standard-compliant MTAs are able to get their mails through, even if they are listed in a blacklist. - MTAs not listed in a blacklist is passed throught without any delays. Could this be an idea for Debian as well? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote: On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote: So, maybe it's time to revisit the weaknesses of the shlibs system, particularly as they apply to glibc. Scott James Remnant had done some poking in this area about a year ago, which involved tracking when individual symbols were added to a package -- apparently, many packages would actually be happy with glibc 2.1 or so (at least on i386), but we have no way to track this... I was just thinking the same with this thread ... The principal problem with the shlibsyms stuff was that in order to track when symbols are added to a package, you need the list of the set of symbols that were in the last version -- and as the source packages are put together before the binary, the source package wouldn't contain the updated set of symbols. Once we begin to deploy icheck, we will have all this information. Haven't yet figured out how to do anything with it. It is not sufficient to track when symbols are added to a package. You must also check when their meaning changes. I have not yet been able to find a way to do this on a per-symbol basis, only a per-library one (I can find examples that break all the 'obvious' approaches). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian concordance
On Fri, Jun 17, 2005 at 08:07:34AM +0100, Andrew Suffield wrote: On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote: On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote: So, maybe it's time to revisit the weaknesses of the shlibs system, particularly as they apply to glibc. Scott James Remnant had done some poking in this area about a year ago, which involved tracking when individual symbols were added to a package -- apparently, many packages would actually be happy with glibc 2.1 or so (at least on i386), but we have no way to track this... I was just thinking the same with this thread ... The principal problem with the shlibsyms stuff was that in order to track when symbols are added to a package, you need the list of the set of symbols that were in the last version -- and as the source packages are put together before the binary, the source package wouldn't contain the updated set of symbols. Once we begin to deploy icheck, we will have all this information. Haven't yet figured out how to do anything with it. It is not sufficient to track when symbols are added to a package. You must also check when their meaning changes. I have not yet been able to find a way to do this on a per-symbol basis, only a per-library one (I can find examples that break all the 'obvious' approaches). However, breaking the meaning of any symbol is supposed to mean that we punt by changing the soname, no? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Work-needing packages report for Jun 17, 2005
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 208 (new: 24) Total number of packages offered up for adoption: 100 (new: 13) Total number of packages requested help for: 10 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: august (#312839), orphaned 6 days ago Description: Tcl/Tk HTML editor. cgiemail (#314434), orphaned today Description: CGI Form-to-Mail converter dbench (#312868), orphaned 6 days ago Description: The dbench (disk) and tbench (TCP) benchmarks gfontview (#312833), orphaned 6 days ago Description: A font viewer for Type 1 and TrueType fonts iprint (#312869), orphaned 6 days ago Description: Trivial command-line integer print utility lft (#312840), orphaned 6 days ago Description: display the route packets take to a network host/socket libapache-authnetldap-perl (#312834), orphaned 6 days ago Description: LDAP authentication for Apache+mod_perl libapache-authznetldap-perl (#312835), orphaned 6 days ago Description: LDAP access control for Apache+mod_perl libtest-cmd-perl (#313466), orphaned 3 days ago Description: perl module to providers testing framework phpgroupware-napster (#312859), orphaned 6 days ago Description: The phpGroupWare Napster interface module tkpaint (#312841), orphaned 6 days ago Description: Versatile bitmap/pixmap editing tool toolame (#313441), orphaned 3 days ago wmx10 (#313442), orphaned 3 days ago zope-cmf (#312861), orphaned 6 days ago Description: Zope CMF Topic Reverse Depends: zope-cmfworkflow zope-ttwtype zope-cmfcalendar zope-cmfphoto zope-cmftopic zope-cmfforum zope-cmfquickinstallertool zope-cmfldap zope-speedpack zope-cmf zope-cmfpgforum zope-cmfformcontroller zope-cmfdefault zope-cmfsin zope-cmfactionicons zope-cmfldap (#312854), orphaned 6 days ago Description: Zope CMF LDAP membership management tools zope-cmfworkflow (#312856), orphaned 6 days ago Description: Zope CMF workflow module zope-emarket (#312858), orphaned 6 days ago Description: Simple e-commerce system for Zope zope-ldap (#312860), orphaned 6 days ago Description: A driver for connecting Zope with Ldap system zope-ldapuserfolder (#312855), orphaned 6 days ago Description: The Zope LDAP user folder Reverse Depends: zope-cmfldap zope-parsedxml (#312857), orphaned 6 days ago Description: ParsedXML Zope Product zope-xmlmethods (#312863), orphaned 6 days ago Description: XMLMethods Zope Product zope-znavigator (#312862), orphaned 6 days ago Description: Zope product for creating navigation bars zope-zpatterns (#312864), orphaned 6 days ago Description: Database Independence and Framework Integration for Zope Reverse Depends: zope-emarket zope-loginmanager zopectl (#312865), orphaned 6 days ago Description: Zope instances controlling utility Reverse Depends: zope 184 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: eterm-themes (#313183), offered 4 days ago Description: Themes for Eterm, the Enlightened Terminal Emulator leakbug (#313633), offered 2 days ago Description: GNUpdate leakbug tracer library Reverse Depends: libleakbug-dev liberror-perl (#313634), offered 2 days ago Description: Perl module for error/exception handling in an OO-ish way Reverse Depends: libcache-cache-perl courier-filter-perl libstring-koremutake-perl libpsp-parser-perl libcorba-orbit-perl libpsp-perl libgnome-gnorba-perl libtest-unit-perl libnet-irc-ruby (#314192), offered 2 days ago Description: a Ruby library for IRC (Internet Relay Chat) libparse-yapp-perl (#313635), offered 2 days ago Description: Perl module for creating fully reentrant LALR parser OO Perl modules Reverse Depends: gnuift-perl pica libxml-xql-perl libtime-piece-perl (#313636), offered 2 days ago Description: Perl module for object oriented time objects Reverse Depends: libplucene-perl pydb (#312850), offered 6 days ago Description: An enhanced Python command-line debugger python-extclass (#312872), offered 6 days ago Description: Improves integration between Python and C++ classes Reverse Depends: qmtest python-extclass zorp python-pcgi (#312875), offered 6 days ago Description: Persistent CGI for Python python-reportlab (#312876), offered 6 days ago Description: ReportLab library
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Hi Eric, Le jeudi 16 juin 2005 14:45 -0400, Eric Dorland a crit : I'm not trying to say it's non-free. It is free. What I'm trying to determine is if we should use the marks within Debian. If it's free, the project as a whole has already decided to be able to include it. For the rest, it's up to the maintainer to decide what is reasonable in his point of view. Apparently, you couldn't make up your mind and so you asked for other opinions. And you had plenty : Indeed, the most vocal (and rational) contributors seem to be saying these demands are reasonable. I'm still not convinced. Either you have no opinion and you should be following the majority because that's was the point of your request, or you have one and you should just follow you own decision. It looks like you have your opinion and you based your opinion with respect to point #8 of the DFSG. We explained you that your reasoning was ill-advised because DFSG stands for DF Software G and not DF Trademark G. What can I say more ? If you decide using firefox is not reasonable, please rename the package and do whatever work you like with the renamed package. But let someone else (which has no problem with the MoFo trademark license) maintain a package named firefox ! Sometime the project as a whole has the last word on something because it is related to our basic texts. Sometimes the project as a whole has nothing to say and it's up to the maintainer to take the decision. And this case it's clearly your decision. Let me try another example. If, say, the Apache Foundation came to us and said, Sure the code is free, but that's our trademark you're using. It will cost you $5000 a year to use that trademark in Debian. Now we could easily afford this as a project, would we do it? I don't think we would do it, even though we could because a strict interpretation of the DFSG says trademarks don't matter. Clearly we would never accept such a deal. We're all open minded but we're not dumb. :-) The point I'm trying to make is that clearly not all trademark terms are reasonable. Their certainly are situations where we would find using the trademark unacceptable, even if the DFSG apparently says we can. Sure ! In the example you take with $5000 fees each year, the project would never accept to pay that on its own fund. But if we have a rich maintainer (or a sponsor) willing to pay that for us I'm pretty convinced we'd accept nevertheless because it's unrelated to the fact that it's free software. Is this Mozilla situation acceptable? I think it is, So end of discussion (but I think you mistyped ... :-)) I think the spirit of DFSG #8 is that Debian should not have rights that the user doesn't have in terms of the software we distribute. Yes, these are not copyrights rights, but they are still rights. And we don't agree on that. And it looks like several other people don't agree with you on that point. But this point of the discussion won't be resolved without a rewrite of the DFSG with the added clarification. In the mean time, assume your opinion and do whatever you feel is needed. But don't impose your interpretation to the whole project when clearly there's no consensus. Cheers, -- Raphal Hertzog Premier livre franais sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Fri, Jun 17, 2005 at 12:15:25AM -0700, Steve Langasek wrote: On Fri, Jun 17, 2005 at 08:07:34AM +0100, Andrew Suffield wrote: On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote: On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote: So, maybe it's time to revisit the weaknesses of the shlibs system, particularly as they apply to glibc. Scott James Remnant had done some poking in this area about a year ago, which involved tracking when individual symbols were added to a package -- apparently, many packages would actually be happy with glibc 2.1 or so (at least on i386), but we have no way to track this... I was just thinking the same with this thread ... The principal problem with the shlibsyms stuff was that in order to track when symbols are added to a package, you need the list of the set of symbols that were in the last version -- and as the source packages are put together before the binary, the source package wouldn't contain the updated set of symbols. Once we begin to deploy icheck, we will have all this information. Haven't yet figured out how to do anything with it. It is not sufficient to track when symbols are added to a package. You must also check when their meaning changes. I have not yet been able to find a way to do this on a per-symbol basis, only a per-library one (I can find examples that break all the 'obvious' approaches). However, breaking the meaning of any symbol is supposed to mean that we punt by changing the soname, no? The notable exception would be glibc, which is the really interesting case here. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
We explained you that your reasoning was ill-advised because DFSG stands for DF Software G and not DF Trademark G. What can I say more ? I think you'd best come up with a better line of argument. The S in DFSG does not stand for copyright, it stands for software. Software usually contains copyrighted code, and sometimes it also contains trademarked names or images. You can argue that the DFSG does not apply to trademark restrictions, but I hope you have a better reason than S stands for Copyright. signature.asc Description: Digital signature
Re: Questions on how to handle this: [EMAIL PROTECTED]: httperf_0.8-3_i386.changes REJECTED]
Roberto C. Sanchez [EMAIL PROTECTED], wrote, on Friday, June 17, 2005 6:37 AM: Below I have included the text rejecting my httperf package. I am taking over as maintainer and uploaded a new version that also closed a couple of bugs and moved it from non-US to main. If linking with libssl is not permissible, should the version that is currently in Sarge be slated for removal when 3.1r1 comes out? There is no httperf package in sarge, as there is no non-US archive for sarge, so the question is academic. As http://packages.debian.org/httperf shows, the package currently only exists in oldstable/non-US. Regards, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
17.06.2005 pisze Peter Samuelson ([EMAIL PROTECTED]): I think you'd best come up with a better line of argument. The S in DFSG does not stand for copyright, it stands for software. Software usually contains copyrighted code, and sometimes it also contains trademarked names or images. You can argue that the DFSG does not apply to trademark restrictions, but I hope you have a better reason than S stands for Copyright. You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Any system that depends on reliability is unreliable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#314590: ITP: zopex3 -- open source web application server (X3 branch)
Package: wnpp Severity: wishlist Owner: Debian Zope team [EMAIL PROTECTED] * Package name: zope2.8 Version : 2.8.0 Upstream Author : Zope Community * URL : http://www.zope.org/ * License : ZPL 2.0 Description : open source web application server (2.8 branch) Zope enables teams to collaborate in the creation and management of ynamic web-based business applications such as intra-nets and portals. Zope makes it easy to build features such as site search, news, personalisation, and e-commerce into your web applications. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) signature.asc Description: Digital signature
Bug#314589: ITP: zope2.8 -- open source web application server (2.8 branch)
Package: wnpp Severity: wishlist Owner: Debian Zope team [EMAIL PROTECTED] * Package name: zope2.8 Version : 2.8.0 Upstream Author : Zope Community * URL : http://www.zope.org/ * License : ZPL 2.0 Description : open source web application server (2.8 branch) Zope enables teams to collaborate in the creation and management of ynamic web-based business applications such as intra-nets and portals. Zope makes it easy to build features such as site search, news, personalisation, and e-commerce into your web applications. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
On Jun 17, Miles Bader [EMAIL PROTECTED] wrote: Spamhaus's rather irresponsible behavior in the past[*] hasn't left a happy impression; have they cleaned up their act lately? Looks like you are confusing it with some other DNSBL. -- ciao, Marco signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
[EMAIL PROTECTED] (Marco d'Itri) writes: Spamhaus's rather irresponsible behavior in the past[*] hasn't left a happy impression; have they cleaned up their act lately? Looks like you are confusing it with some other DNSBL. Hmmm, looking thought old email I think you're right -- it was spamcop that behaved badly in the past (there are multiple incidents I'm thinking of though; they all involved spam-mumble-something, but I can't swear they were all the same people). My apologies to spamhaus. -Miles -- Suburbia: where they tear out the trees and then name streets after them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#314590: ITP: zopex3 -- open source web application server (X3 branch)
On Fri, 17 Jun 2005 at 11:58 +0200, Fabio Tranchitella wrote: Package: wnpp Severity: wishlist Owner: Debian Zope team [EMAIL PROTECTED] * Package name: zope2.8 Version : 2.8.0 Description : open source web application server (2.8 branch) Damn, I meant zopex3 and 3.0.0 ... -- Fabio Tranchitella [EMAIL PROTECTED].''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Re: Bug#314590: ITP: zopex3 -- open source web application server (X3 branch)
On Fri, 17 Jun 2005, Fabio Tranchitella wrote: On Fri, 17 Jun 2005 at 11:58 +0200, Fabio Tranchitella wrote: Package: wnpp Severity: wishlist Owner: Debian Zope team [EMAIL PROTECTED] * Package name: zope2.8 Version : 2.8.0 Description : open source web application server (2.8 branch) Damn, I meant zopex3 and 3.0.0 ... We guessed it. ;-) BTW, is there any plan to separate ZODB from the packaging. There is an ITP for ZODB (#158552) which in principle would make sense to me, but it seems nobody cares about it. Kind regards and thanks for your Zope efforts Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
On Friday 17 June 2005 07:04, Roberto C. Sanchez wrote: On Thu, Jun 16, 2005 at 06:18:06PM +0100, Martin Michlmayr wrote: iceme -- A graphical menu editor for IceWM [#227054] * Orphaned 520 days ago * Package orphaned 360 days ago. icepref -- Yet another configuration tool for IceWM [#227077] * Orphaned 520 days ago * Package orphaned 360 days ago. I use both of these and would like to adopt them. I will upload next week (via Anibal). These two also use pygtk 1.2 which is rather outdated. There seems to be a new upstream version that uses pygtk 2.0, but I'm not sure if it is functionally equivalent. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Thu, Jun 16, 2005 at 01:51:04PM +1000, Russell Coker wrote: regarding prelink On Thursday 16 June 2005 08:18, Steve Langasek [EMAIL PROTECTED] wrote: One of the points of the md5sum verification is to ensure that the binaries haven't been tampered with. If one can tamper with the binaries by modifying some file in /var/cache instead, doesn't that just reintroduce the same problem? There are two basic reasons why people want md5sums of their binaries: to know when their filesystem is eating files, and as an extra layer of security to tell them their binaries have been modified by an intruder. In the first instance, removing the cache and regenerating it would be sufficient to eliminate any corrupted files; in the second instance, removing the cache and regenerating it would be sufficient to eliminate any trojaned files (though, what a strange attack vector that would be :). I think that the idea would be: Prelink changes certain fixed parts of the binary, most of the file is never changed. The parts that are changed would have their original values stored so that a checking tool can do a md5 or sha sum of the main part of the file plus the original values for the parts that prelink changes. In which case, /var/cache is absolutely the wrong place to store those original values, since they can't be regenerated based on information on the rest of the system. I figured people were going the other way around with this, and suggesting that prelink store its *output* in /var/cache, with support in the dynamic loader for merging it in at the correct moment. But if someone can change the cache of data written by prelink then why couldn't they also change the program that does the md5 checks to make it always return a good result? They can, but I've never seen a rootkit with that level of sophistication; and if there was one, there's still the option of booting from read-only media to check (which is the only safe way to audit your system anyway). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Upcoming removal of orphaned packages
On Thu, 16 Jun 2005, Sven Mueller wrote: [2001/03/03 10:05] Markus Schoder has contributed finddupes.cpp, GPL'ed source code for a C++ based version ... It's only compilable in its current state with g++-2.95 (regarding compilers in Debian stable). There is a single error when compiling with g++-3.4 which I am unable to fix (as I don't know the STL at all). Thanks for investigating this. It would be great if somebody could fix this issue which is probably not much effort for a C++ programmer. If it would compile nicely I would take the package (or would leave it for somebody who cares for it inside Debian). Apart from that, it works quite fine. Good news. Thanks, the time is on your side as I also would like to have a command line based tool. Yes, plaaasse. So if we have so many people who want it, we will find a maintainer for the package. If it is necessary to keep it inside Debian I would just volunteer to take it over like it is - but the final goal would be to replace the perl script with the C++ version. Any clue? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
In article [EMAIL PROTECTED] you write: Hmmm, IIRC I was among these ones and the reasons was the CBL listing all dynamic and non dynamic addresses from Free, one of the 2-3 major ISPs for DSL in France. I think you are confusing CBL with another DNSbl. CBL only lists addresses that spam thier spamtraps, and removes listings automaticly after several days. They attempt not to list mail servers. To be removed immediatly, just fill out their web form with the IP address to be removed. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
On Friday 17 June 2005 13:40, Andreas Tille wrote:
It's only compilable in its current state with g++-2.95 (regarding
compilers in Debian stable). There is a single error when compiling with
g++-3.4 which I am unable to fix (as I don't know the STL at all).
Thanks for investigating this. It would be great if somebody could fix
this issue which is probably not much effort for a C++ programmer. If
it would compile nicely I would take the package (or would leave it for
somebody who cares for it inside Debian).
I haven't tested this change but it does compile.
--- finddupes.cpp.orig 2005-06-17 13:57:57.0 +0100
+++ finddupes.cpp 2005-06-17 13:57:36.0 +0100
@@ -96,12 +96,13 @@
vectorFingerprint a;
while(cin.getline(buf, buf_size))
{
+Fingerprint fp;
char *p = strchr(buf, ':');
if(!p)
continue;
-a.push_back();
-a.back().name = string(buf, p - buf);
-hex_convert8(a.back().u, p + 1);
+fp.name = string(buf, p - buf);
+hex_convert8(fp.u, p + 1);
+a.push_back(fp);
}
size_t n = a.size();
Re: Upcoming removal of orphaned packages
On Thu, Jun 16, 2005 at 06:18:06PM +0100, Martin Michlmayr wrote: There are currently over 200 orphaned packages, many of which have been on WNPP for quite a long time and some with RC bugs. I intend to request the removal of a number of packages in three weeks unless a package has been adopted by someone by then. some of these packages are useful and interesting, and I feel they should not be removed from unstable at least. perhaps they could be moved to a different section which is not necessarily stabilized for release. I used rtf2latex myself only 5 minutes ago before reading this message in which you propose to remove it! and I think boust is cool. peace, Sam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 11:54:40AM +0200, Miros/law Baran wrote: 17.06.2005 pisze Peter Samuelson ([EMAIL PROTECTED]): I think you'd best come up with a better line of argument. The S in DFSG does not stand for copyright, it stands for software. Software usually contains copyrighted code, and sometimes it also contains trademarked names or images. You can argue that the DFSG does not apply to trademark restrictions, but I hope you have a better reason than S stands for Copyright. You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. That would be the part where the trademark holder tells you that you can't distribute modified versions. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Upcoming removal of orphaned packages
Joey Hess [EMAIL PROTECTED] scrisse: Martin Michlmayr wrote: gkdial -- PPP dial-up configuration and dialing tool [#287992] * Orphaned 164 days ago * 1 RC bugs. Does any graphical ppp frontend exist that can be used instead of this? Under gnome you can find gpppkill and gpppon, but they can't manage provider setting. However you can find the modem-light applet for the gnome panel. Gkdial is a great tool, but ATM is really buggy :( Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno : :' : The Universal O.S.| luca.br(AT)uno.it `. `'` | GPG Key ID: 0x3BFB9FB3 `- http://www.debian.org | Proud Debian GNU/Linux User -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
I've only been skimming this thread, so I fear this may have been said. What about: 1) rebrand mozilla-firefox 2) create a permanent transition package with the firefox name that depends on it 3) use alternatives to provide /usr/bin/firefox The description of the transition package should briefly explain what is happening, that the transition package merely depends on a rebranded/forked version of the Mozilla Firefox web browser. This way, you are using the TM term to refer to the correct product but substituting a rebrand seemlessly (without the kind of confusion that would run you afoul of TM law). Someone on debian-legal would have to consider whether having a binary named firefox is enough to create an issue. If it is, then I am happy to retract the suggestion. Don -- Don Bindner [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
On Friday 17 June 2005 12:10, Sam Watkins wrote: some of these packages are useful and interesting, and I feel they should not be removed from unstable at least. perhaps they could be moved to a different section which is not necessarily stabilized for release. http://archive.debian.org/debian-archive/ I used rtf2latex myself only 5 minutes ago before reading this message in which you propose to remove it! and I think boust is cool. Would you consider maintaining them? Or persuading someone you know to maintain them? Without a maintainer they may become unbuildable, contain security flaws or break installation of other unrelated software. Someone has to fix these issues and if the QA team are the only ones caring for the package they have the right to ask for the packages removal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
I use both of these and would like to adopt them. I will upload next week (via Anibal). I think they are no longer maintained upstream. Take a look at http://www.icewm.org/FAQ/IceWM-FAQ-11.html#tools4icewm for more modern and supported alternatives. Greetings Ben -- Please do not sent any email to the [EMAIL PROTECTED] - all email not originating from the mailing list will be deleted automatically. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On 17-Jun-05, 01:41 (CDT), Pierre Habouzit [EMAIL PROTECTED] wrote: the delay it creates. [...] but for our @debian.org addresses ... that sucks, I often rely on the fact that delivery is immediate on those. Then you don't understand how the internet and SMTP works. There is absolutely no guarantee the mail will be delivered immediately, and no reasonable expectation of such. As a practical matter, the only time the delay is significant is when trying to carry on an e-mail conversation, which by very definition is not going to be delayed after the first exchange. SRS changes the MAIL FROM for one user every 3 or 4 hours. so every 3 or 4 hours he comes stuck in greylisting server again and again. For such domains, greylisting sucks. Yet another reason SRS is broken. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding 'offensive' material
On 15/06/2005 Thijs Kinkhorst wrote: Unfortunately people that are easily offended will always exist, even by simple human body parts displayed in a very abstract manner (more abstract than the pictures in any sexual education book). So we have to do something about it, because it's a given. I was thinking that maybe debtags would provide a solution. You can invent a tag contains remote references to natural reproduction and anyone can use that to filter out unwanted packages. the problem is, that most of these sexual pictures or whatsoever are created and even provided because they're offending. maybe not to offend somebody directly, but rather because offending material is that popular. the problem that it presumes somebody who feels offended is simply ignored. bye jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ada in Debian, past, present and future. Request for Advocate.
Ludovic Brenta [EMAIL PROTECTED] writes: In July 2003, I adopted the package gnat and several other Ada packages. In November 2003, Matthias Klose sponsored my first few packages into Debian unstable. After I adopted all the orphaned packages I could, I created several new packages from sratch. Now, all my packages have been released as part of sarge. [...] I am now looking for an advocate; if you are interested, please visit: Please don't do something like this - your advocate should have worked with you and know something about you and your plans. Writing an advocation mail isn't that time-consuming, Matthias really should be able to do it himself. Asking random developers to do it abuses the whole advocation process. Marc -- BOFH #173: Recursive traversal of loopback mount points pgptYJwnDsr95.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
On Thu, Jun 16, 2005 at 08:46:33PM -0700, Blars Blarson wrote: I recomed using spamhaus SBL-XBL, or at least CBL (which is included in SBL-XBL). I dont: http://www.paulgraham.com/spamhausblacklist.html -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 If a man cannot choose, he ceases to be a man. --Minister (A clockwork orange) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Le Ven 17 Juin 2005 14:13, Steve Greenland a crit : On 17-Jun-05, 01:41 (CDT), Pierre Habouzit [EMAIL PROTECTED] wrote: the delay it creates. [...] but for our @debian.org addresses ... that sucks, I often rely on the fact that delivery is immediate on those. Then you don't understand how the internet and SMTP works. There is absolutely no guarantee the mail will be delivered immediately, and no reasonable expectation of such. As a practical matter, the only time the delay is significant is when trying to carry on an e-mail conversation, which by very definition is not going to be delayed after the first exchange. I perfectly understand what SMTP is, and I perfectly *don't* understand why having a 30 minutes delay or even a 2 or 3 hours delay in some conditions is tolerable. SRS changes the MAIL FROM for one user every 3 or 4 hours. so every 3 or 4 hours he comes stuck in greylisting server again and again. For such domains, greylisting sucks. Yet another reason SRS is broken. I don't know any better solution in order to be SPF compliant when you have a redirection service. please tell me, I'll use it. but any method will require : * sender rewriting * time dependant hash in order to avoid open relay and will create such a problem. For the record, I don't like SRS, but I don't know anything else that would work with SPF. -- O Pierre Habouzit O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpuMU3utzmOW.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
* Pierre Habouzit ([EMAIL PROTECTED]) [050617 17:08]: Le Ven 17 Juin 2005 14:13, Steve Greenland a crit : On 17-Jun-05, 01:41 (CDT), Pierre Habouzit [EMAIL PROTECTED] wrote: the delay it creates. [...] but for our @debian.org addresses ... that sucks, I often rely on the fact that delivery is immediate on those. Then you don't understand how the internet and SMTP works. There is absolutely no guarantee the mail will be delivered immediately, and no reasonable expectation of such. As a practical matter, the only time the delay is significant is when trying to carry on an e-mail conversation, which by very definition is not going to be delayed after the first exchange. I perfectly understand what SMTP is, and I perfectly *don't* understand why having a 30 minutes delay or even a 2 or 3 hours delay in some conditions is tolerable. Come one. We're speaking on additional 5 minutes on the first connection. Greylist works quite well for me, and I really hope that we manage to deploy anti-spam-tools on Debian. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Fri, 17 Jun 2005, Andreas Barth wrote: Come one. We're speaking on additional 5 minutes on the first connection. Greylist works quite well for me, and I really hope that we manage to deploy anti-spam-tools on Debian. AOLMe too./AOL See also some interesting tips here for Sendmail: http://www.acme.com/mail_filtering/sendmail_config_frameset.html Including the 'greet_pause' feature. Probably similar features for Exim ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Fri, 2005-06-17 at 09:32 +0100, Andrew Suffield wrote: On Fri, Jun 17, 2005 at 12:15:25AM -0700, Steve Langasek wrote: On Fri, Jun 17, 2005 at 08:07:34AM +0100, Andrew Suffield wrote: On Fri, Jun 17, 2005 at 04:26:36AM +0100, Scott James Remnant wrote: On Thu, 2005-06-16 at 17:20 -0700, Steve Langasek wrote: So, maybe it's time to revisit the weaknesses of the shlibs system, particularly as they apply to glibc. Scott James Remnant had done some poking in this area about a year ago, which involved tracking when individual symbols were added to a package -- apparently, many packages would actually be happy with glibc 2.1 or so (at least on i386), but we have no way to track this... I was just thinking the same with this thread ... The principal problem with the shlibsyms stuff was that in order to track when symbols are added to a package, you need the list of the set of symbols that were in the last version -- and as the source packages are put together before the binary, the source package wouldn't contain the updated set of symbols. Once we begin to deploy icheck, we will have all this information. Haven't yet figured out how to do anything with it. It is not sufficient to track when symbols are added to a package. You must also check when their meaning changes. I have not yet been able to find a way to do this on a per-symbol basis, only a per-library one (I can find examples that break all the 'obvious' approaches). However, breaking the meaning of any symbol is supposed to mean that we punt by changing the soname, no? The notable exception would be glibc, which is the really interesting case here. Who are historically pretty well behaved about changing symbol versions if they change the API. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Greylisting for @debian.org email, please
I perfectly understand what SMTP is, and I perfectly *don't* understand why having a 30 minutes delay or even a 2 or 3 hours delay in some conditions is tolerable. Come one. We're speaking on additional 5 minutes on the first connection. Greylist works quite well for me, and I really hope that we manage to deploy anti-spam-tools on Debian. you didn't read one of my first posts : when the mail you receive comes from a big big big MX, and that they see a greylisted domain, since the time is sometimes 5 minutes, somtimes 10 and sometimes 20, they choose to deliberately let those mail in the queue for 30 to 60 minutes. if there is 2 or 3 such MX that relay the mail before it arrives to its final destination, it can induce 2 to 3 hours delays (I already saw it) and it's painful. And don't tell me that those MX admins are idiots. If you have an MX farm that deal with Megs of mails per day, you can't afford useless requeuinf of mails. Greylisting should *not* be a default rule for incoming mail, it has to many nasty side effects. btw, I don't know how to help to deploy antispam tools for debian, but I can help if any help is welcomed/wanted/... -- O Pierre Habouzit O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpPR3tDl6dxw.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
* Pierre Habouzit ([EMAIL PROTECTED]) [050617 17:34]: I perfectly understand what SMTP is, and I perfectly *don't* understand why having a 30 minutes delay or even a 2 or 3 hours delay in some conditions is tolerable. Come one. We're speaking on additional 5 minutes on the first connection. Greylist works quite well for me, and I really hope that we manage to deploy anti-spam-tools on Debian. you didn't read one of my first posts : when the mail you receive comes from a big big big MX, and that they see a greylisted domain, since the time is sometimes 5 minutes, somtimes 10 and sometimes 20, they choose to deliberately let those mail in the queue for 30 to 60 minutes. if there is 2 or 3 such MX that relay the mail before it arrives to its final destination, it can induce 2 to 3 hours delays (I already saw it) and it's painful. First of all, E-Mail is no real time medium. It was never intended so. Also, skillfull mail admins should whitelist known good hosts. For example, I never greylist any debian.org-host for obvious reasons. :) Greylisting should *not* be a default rule for incoming mail, it has to many nasty side effects. Well, actually the amount of spam is the more nasty side effect, especially for those of us who are on good spammed mail accounts. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Fri, 17 Jun 2005, Jesus Climent wrote: On Thu, Jun 16, 2005 at 08:46:33PM -0700, Blars Blarson wrote: I recomed using spamhaus SBL-XBL, or at least CBL (which is included in SBL-XBL). I dont: http://www.paulgraham.com/spamhausblacklist.html Selected paragraph from the article: This case illustrates an important failing of blacklists. Unlike filters, they're run by humans. And humans are all too likely to abuse the kind of power that blacklists embody. Perhaps someone will start another blacklist that tries to avoid such abuses. But how long before that one becomes corrupt too? This is pure FUD against DNSBLs (which is their proper name). The truth is that some DNSBLs are run by humans, but not all of them are. The CBL, in particular, is completely automated, it tries very hard to not list real mail servers, and you can remove yourself trivially. In fact, most of the effectiveness of SBL-XBL really comes from the CBL, as shown by the widely known statistics: http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html We could use just the CBL, and we would already reduce spam by a half without a lot of controversy. I will be more than happy to apply my other filters (razor, pyzor, bogofilter) to the *remaining* email, but at least I would know that we are doing *something* about it at the SMTP level, which is where we can really avoid spam to reach our inboxes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITA: linux-wlan-ng initial version of 0.2.1-pre26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have made the linux-wlan-ng package for 0.2.1 [0] The modules for 2.6.8 and 2.6.11 is my next step. Can you take a look over it? I'm not sure if it is correct. [0] http://linuxmaniac.homeip.net/debian/ - -- Victor Seva Lopez [EMAIL PROTECTED] http://www.torreviejawireless.org http://linuxmaniac.homeip.net jabber: [EMAIL PROTECTED] PGP Key ID: 0xDD12F253 Orgulloso usuario de Debian Socio numero 78 de ANURI -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCsvS0S/DSSd0S8lMRAh11AKCCNHcWZyPzktE1eBlXXij6tSSyKgCff8LL 6nWffhDCwfLvF95ht4Es2BQ= =HNow -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Le vendredi 17 juin 2005 14:09 +0100, Andrew Suffield a crit : You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. That would be the part where the trademark holder tells you that you can't distribute modified versions. The Mozilla Foundation explicitely gave us that right (or at least they are ready to give us this right because they trust us). Of course the right is revocable ... but that doesn't matter. When they decide to stop granting us this right, then we'll have to rename the package. Right now, it's not needed. Cheers, -- Raphal Hertzog Premier livre franais sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding 'offensive' material
On Fri, Jun 17, 2005 at 04:25:43PM +0200, Jonas Meurer wrote: On 15/06/2005 Thijs Kinkhorst wrote: Unfortunately people that are easily offended will always exist, even by simple human body parts displayed in a very abstract manner (more abstract than the pictures in any sexual education book). So we have to do something about it, because it's a given. I was thinking that maybe debtags would provide a solution. You can invent a tag contains remote references to natural reproduction and anyone can use that to filter out unwanted packages. the problem is, that most of these sexual pictures or whatsoever are created and even provided because they're offending. maybe not to offend somebody directly, but rather because offending material is that popular. That's simply another way to say that the group of people who are offended is a minority. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
On Fri, Jun 17, 2005 at 05:53:25PM +0200, Santiago Vila wrote: In fact, most of the effectiveness of SBL-XBL really comes from the CBL, as shown by the widely known statistics: http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html Statistics which list only hits, and not false positives or false negatives, pretty much speak for themselves (and the people who cite them) as to their relevance. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 06:08:36PM +0200, Rapha?l Hertzog wrote: Le vendredi 17 juin 2005 14:09 +0100, Andrew Suffield a crit : You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. That would be the part where the trademark holder tells you that you can't distribute modified versions. The Mozilla Foundation explicitely gave us that right (or at least they are ready to give us this right because they trust us). After they first told us that we couldn't distribute modified versions, that was one of several outcomes of debian-legal's investigation into this matter, yes. There were several others, too. Oddly enough, I *do* know what happened. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Upcoming removal of orphaned packages
Luca writes: Under gnome you can find gpppkill and gpppon, but they can't manage provider setting. Gpppon doesn't need to manage settings. It uses the same settings as pon/poff, which can be managed with pppconfig. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Donald J Bindner writes: 2) create a permanent transition package with the firefox name that depends on it 3) use alternatives to provide /usr/bin/firefox Thereby attaching the name Firefox to something which is not pristine Mozilla code. This is exactly what it is being claimed we may not do without explicit permission[1]. [1] I doubt that trademark law reaches that far, but I am not a lawyer. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding 'offensive' material
On 17/06/2005 Andrew Suffield wrote: On Fri, Jun 17, 2005 at 04:25:43PM +0200, Jonas Meurer wrote: On 15/06/2005 Thijs Kinkhorst wrote: Unfortunately people that are easily offended will always exist, even by simple human body parts displayed in a very abstract manner (more abstract than the pictures in any sexual education book). So we have to do something about it, because it's a given. I was thinking that maybe debtags would provide a solution. You can invent a tag contains remote references to natural reproduction and anyone can use that to filter out unwanted packages. the problem is, that most of these sexual pictures or whatsoever are created and even provided because they're offending. maybe not to offend somebody directly, but rather because offending material is that popular. That's simply another way to say that the group of people who are offended is a minority. even if the group where the material is popular is a minority itself? most minorities are a majority in particular communities. white men for example are a minority on earth, but a majority in the open source world. bye jonas signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Friday 17 June 2005 17:08, Raphal Hertzog wrote: The Mozilla Foundation explicitely gave us that right (or at least they are ready to give us this right because they trust us). Of course the right is revocable ... but that doesn't matter. When they decide to stop granting us this right, then we'll have to rename the package. Right now, it's not needed. aol/ The ironic thing is, even if we do rename, who is going to do the trademark search to prove that the new name we choose is not someone else's trademark who we do NOT have permission to use?
Re: Greylisting for @debian.org email, please
On Fri, 17 Jun 2005 17:18:37 +0200, Andreas Barth [EMAIL PROTECTED] wrote: Come one. We're speaking on additional 5 minutes on the first connection. Greylist works quite well for me, and I really hope that we manage to deploy anti-spam-tools on Debian. Just for the record: The default MTA in sarge is configured to run the queue every 30 minutes, and this default is not going to change because of greylisting. So, your 5 minutes quickly become up to 30 for the majority of our users. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Greylisting for @debian.org email, please
On Fri, 17 Jun 2005, Andrew Suffield wrote: On Fri, Jun 17, 2005 at 05:53:25PM +0200, Santiago Vila wrote: In fact, most of the effectiveness of SBL-XBL really comes from the CBL, as shown by the widely known statistics: http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html Statistics which list only hits, and not false positives or false negatives, pretty much speak for themselves (and the people who cite them) as to their relevance. This is from the statistics for 4 June 2005 from the URL above: 13219 sbl-xbl.spamhaus.org (union of all results) 10757 cbl.abuseat.org Even if those are absolute numbers, and do not include false positives, they allow us to say things like most of the spam caught by SBL-XBL comes from the fact that it includes the CBL. which is what I meant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Andrew Suffield ([EMAIL PROTECTED]) wrote: On Fri, Jun 17, 2005 at 06:08:36PM +0200, Rapha?l Hertzog wrote: Le vendredi 17 juin 2005 14:09 +0100, Andrew Suffield a crit : You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. That would be the part where the trademark holder tells you that you can't distribute modified versions. The Mozilla Foundation explicitely gave us that right (or at least they are ready to give us this right because they trust us). After they first told us that we couldn't distribute modified versions, that was one of several outcomes of debian-legal's investigation into this matter, yes. There were several others, too. Sorry Andrew, which investigation are you referring to? Which other outcomes? You've got some context there I'm not getting. Oddly enough, I *do* know what happened. -- 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
* Raphal Hertzog ([EMAIL PROTECTED]) wrote: Hi Eric, Le jeudi 16 juin 2005 14:45 -0400, Eric Dorland a crit : I'm not trying to say it's non-free. It is free. What I'm trying to determine is if we should use the marks within Debian. If it's free, the project as a whole has already decided to be able to include it. For the rest, it's up to the maintainer to decide what is reasonable in his point of view. Apparently, you couldn't make up your mind and so you asked for other opinions. And you had plenty : Indeed, the most vocal (and rational) contributors seem to be saying these demands are reasonable. I'm still not convinced. Either you have no opinion and you should be following the majority because that's was the point of your request, or you have one and you should just follow you own decision. So either I should do what I want or subjugate my will to the project? Clearly I have my own opinions, but I don't work in a vacuum. I wanted to know what the rest of the project thought to balance my decision against, that was the whole point of the thread. It's not so black-and-white. It looks like you have your opinion and you based your opinion with respect to point #8 of the DFSG. We explained you that your reasoning was ill-advised because DFSG stands for DF Software G and not DF Trademark G. What can I say more ? If you decide using firefox is not reasonable, please rename the package and do whatever work you like with the renamed package. But let someone else (which has no problem with the MoFo trademark license) maintain a package named firefox ! Sometime the project as a whole has the last word on something because it is related to our basic texts. Sometimes the project as a whole has nothing to say and it's up to the maintainer to take the decision. And this case it's clearly your decision. I think you're really stretching here and claiming your interpretations are shared by most of the project. Let me try another example. If, say, the Apache Foundation came to us and said, Sure the code is free, but that's our trademark you're using. It will cost you $5000 a year to use that trademark in Debian. Now we could easily afford this as a project, would we do it? I don't think we would do it, even though we could because a strict interpretation of the DFSG says trademarks don't matter. Clearly we would never accept such a deal. We're all open minded but we're not dumb. :-) The point I'm trying to make is that clearly not all trademark terms are reasonable. Their certainly are situations where we would find using the trademark unacceptable, even if the DFSG apparently says we can. Sure ! In the example you take with $5000 fees each year, the project would never accept to pay that on its own fund. But if we have a rich maintainer (or a sponsor) willing to pay that for us I'm pretty convinced we'd accept nevertheless because it's unrelated to the fact that it's free software. So you're saying Debian as a project is too cheap to pay for it itself, but if some rich benefactor did it would be alright? I don't what to say, that seems extremely contradictory. Is this Mozilla situation acceptable? I think it is, So end of discussion (but I think you mistyped ... :-)) I have really got to proofread more... I think the spirit of DFSG #8 is that Debian should not have rights that the user doesn't have in terms of the software we distribute. Yes, these are not copyrights rights, but they are still rights. And we don't agree on that. And it looks like several other people don't agree with you on that point. But this point of the discussion won't be resolved without a rewrite of the DFSG with the added clarification. In the mean time, assume your opinion and do whatever you feel is needed. But don't impose your interpretation to the whole project when clearly there's no consensus. Enjoy your rewrite of the DFSG. If it's anything like the views expressed in this mail, I'll want none of 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: Debian concordance
On 6/16/05, Michael K. Edwards [EMAIL PROTECTED] wrote: On 6/16/05, Ian Murdock [EMAIL PROTECTED] wrote: glibc. Shipping X.org and GNOME 2.10 adds value, since sarge doesn't ship them. Shipping glibc 2.6.5 vs. glibc 2.6.2 just adds incompatibilities. Speaking as someone with no Ubuntu affiliation (and IANADD either), I think that statement is based on a somewhat shallow analysis of how glibc is handled. [...] I don't doubt there were changes, even some worthwhile changes, between the version of libc in sarge and the versions in hoary/breezy. My question is: Are the changes worth breaking compatibility? It's a cost/benefit thing. And if they're important enough, why aren't they going into Debian directly? I understand why Ubuntu was moving ahead of Debian before, since Debian was so far behind. But now that sarge is out, don't you think it would be worthwhile to give Debian a chance to fix its release cycle problems and, better yet, to try to help fix them, rather than simply saying Debian is too slow/unpredictable for us? Again, as I've said before, it's *sarge* the rest of the world thinks of as Debian, not sid. So, we're getting out patches into sid or we're tracking sid or whatever doesn't really help anything. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ A nerd is someone who uses a telephone to talk to other people about telephones. --Douglas Adams
Re: Debian concordance
On Fri, Jun 17, 2005 at 01:55:57PM -0500, Ian Murdock wrote: snip I don't doubt there were changes, even some worthwhile changes, between the version of libc in sarge and the versions in hoary/breezy. My question is: Are the changes worth breaking compatibility? It's a cost/benefit thing. And if they're important enough, why aren't they going into Debian directly? I understand why Ubuntu was moving ahead of Debian before, since Debian was so far behind. But now that sarge is out, don't you think it would be worthwhile to give Debian a chance to fix its release cycle problems and, better yet, to try to help fix them, rather than simply saying Debian is too slow/unpredictable for us? Pardon me, but wouldn't hoary and sarge be (roughly) compatible, and breezy with etch (hoping on a slightly faster release cycle). Wouter van Heyst -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 08:18:29AM -0500, Donald J Bindner wrote: 1) rebrand mozilla-firefox 2) create a permanent transition package with the firefox name that depends on it 3) use alternatives to provide /usr/bin/firefox The description of the transition package should briefly explain what is happening, that the transition package merely depends on a rebranded/forked version of the Mozilla Firefox web browser. This way, you are using the TM term to refer to the correct product but substituting a rebrand seemlessly (without the kind of confusion that would run you afoul of TM law). I think it's a good compromise. I'd like to suggest: 4) make the program's branding depend on argv[0]. That way the behaviour of the firefox command and package don't change at all, but the name firefox is encapslated in a package which can be dropped completely (no debian permission anymore) or moved to non-free (the firefox maintainers decide the DFSG applies to trademarks.) Users will eventually notice the situation (read firefox's description or README.Debian.) Derived distribution which have modified iceweasel but haven't got the permission to call their own firefox yet just need to abstain distributing the firefox package. -- Jeremie Koenig [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
* Andreas Barth: First of all, E-Mail is no real time medium. It was never intended so. My users complain if it's not (soft) real-time, and rightly so For most users, it's more real-time than a fax transmission because both parties need not walk to the fax machine. Today, even an MX hop which performs virus scanning adds a latency of well under a second (if configured properly). Anyway, today a lot of spam is already sent through webmail providers with poor registration procedures and no spam controls, and these services definitely have queues. Greylisting would affect them. It helps with the current generation of zombie software, but there are solutions of comparable effectiveness which do not introduce artificial delays. In a few months, zombie software will have been extended to use virtual queues, so greylisting will be mostly ineffective. It may make sense to switch on greylisting for mail servers in address space with automatically generated reverse lookup, though. Sort of a compromise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
* Santiago Vila: The CBL, in particular, is completely automated, it tries very hard to not list real mail servers, and you can remove yourself trivially. In fact, most of the effectiveness of SBL-XBL really comes from the CBL, as shown by the widely known statistics: Hmm, so greylist when in CBL might be a sensible strategy. 8-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 11:07:33PM +0200, Jeremie Koenig wrote: On Fri, Jun 17, 2005 at 08:18:29AM -0500, Donald J Bindner wrote: 1) rebrand mozilla-firefox 2) create a permanent transition package with the firefox name that depends on it 3) use alternatives to provide /usr/bin/firefox The description of the transition package should briefly explain what is happening, that the transition package merely depends on a rebranded/forked version of the Mozilla Firefox web browser. This way, you are using the TM term to refer to the correct product but substituting a rebrand seemlessly (without the kind of confusion that would run you afoul of TM law). I think it's a good compromise. I'd like to suggest: 4) make the program's branding depend on argv[0]. Do trademarks only apply to binaries, or to source also? A running firefox will prominently display the trademarked bits in question, but hey, the source being open for viewing is important here. Wouter van Heyst -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On 6/17/05, Ian Murdock [EMAIL PROTECTED] wrote: On 6/16/05, Michael K. Edwards [EMAIL PROTECTED] wrote: Speaking as someone with no Ubuntu affiliation (and IANADD either), I think that statement is based on a somewhat shallow analysis of how glibc is handled. [...] I don't doubt there were changes, even some worthwhile changes, between the version of libc in sarge and the versions in hoary/breezy. My question is: Are the changes worth breaking compatibility? It's a cost/benefit thing. And if they're important enough, why aren't they going into Debian directly? Well, if anyone broke compatibility in the sarge/hoary timeframe, it wasn't Ubuntu. The sched_[gs]et_affinity change in sarge is the only one that broke an ABI and bumped shlib_dep_ver. The Ubuntu folks quite consciously refrained from rolling out 2.3.[45] in hoary; demanding that they merge 2.3.2.ds1-22 and nothing else into breezy, and therefore further postpone upstream's improved ppc64 support and compatibility with other toolchain updates, seems like a lot to ask. I understand why Ubuntu was moving ahead of Debian before, since Debian was so far behind. But now that sarge is out, don't you think it would be worthwhile to give Debian a chance to fix its release cycle problems and, better yet, to try to help fix them, rather than simply saying Debian is too slow/unpredictable for us? I really don't think they're saying that. Goto-san and the rest of the Debian glibc team are appropriately cautious about moving 2.3.5 from experimental to unstable at the same time that many other things are in flux. But if Ubuntu is going to move the toolchain forward in breezy at all, they just can't wait. If anything, this will help smooth the transition in Debian and speed up the etch cycle accordingly. There's no particular reason why etch can't ship in six or nine months, with better application compatibility between etch and breezy than there is now between sarge and hoary. Again, as I've said before, it's *sarge* the rest of the world thinks of as Debian, not sid. So, we're getting out patches into sid or we're tracking sid or whatever doesn't really help anything. I basically agree with you there; what would help, in my view, is a sort of Debian/Ubuntu mini-LSB, ideally with a white box testing framework that helps validate that a .deb is installable and likely to function properly on some combination of sarge, hoary, breezy, and etch. If, that is, ISV support is of interest, and you don't want to go the LCC multi-distro golden binaries route. Cheers, - Michael
Re: Debian concordance
* Daniel Stone: Breezy (like current sid) is built against 2.3.5. Current sid on which platform? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Fri, Jun 17, 2005 at 03:58:35AM +1000, Daniel Stone wrote: Hoary (like sarge) is built against 2.3.2. Breezy (like current sid) is built against 2.3.5. No, 2.3.5 is still in experimental. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Jun 17, Ian Murdock [EMAIL PROTECTED] wrote: I don't doubt there were changes, even some worthwhile changes, between the version of libc in sarge and the versions in hoary/breezy. My question is: Are the changes worth breaking compatibility? It's a cost/benefit thing. And if they're important enough, why aren't they going into Debian directly? You may want to ask the Debian glibc team. Or understand that different distributions may have different goals and priorities. I understand why Ubuntu was moving ahead of Debian before, since Debian was so far behind. But now that sarge is out, don't you think it would be worthwhile to give Debian a chance to fix its release cycle problems and, better yet, to try to help fix them, rather than simply saying Debian is too slow/unpredictable for us? Considering the track record of past debian releases, I'd say no. Again, as I've said before, it's *sarge* the rest of the world thinks of as Debian, not sid. So, we're getting out patches into Not since sarge has been about 1-2 years late. -- ciao, Marco signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
On 17-Jun-05, 13:11 (CDT), Marc Haber [EMAIL PROTECTED] wrote: On Fri, 17 Jun 2005 17:18:37 +0200, Andreas Barth [EMAIL PROTECTED] wrote: Come one. We're speaking on additional 5 minutes on the first connection. Greylist works quite well for me, and I really hope that we manage to deploy anti-spam-tools on Debian. Just for the record: The default MTA in sarge is configured to run the queue every 30 minutes, and this default is not going to change because of greylisting. So, your 5 minutes quickly become up to 30 for the majority of our users. So what? It's *e-mail*. If you need realtime, pick up a phone, or use one of any of the innumerable chat systems. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 11:10:34PM +0200, Wouter van Heyst wrote: 4) make the program's branding depend on argv[0]. Do trademarks only apply to binaries, or to source also? A running firefox will prominently display the trademarked bits in question, but hey, the source being open for viewing is important here. The source wouldn't need to include the trademarks under this setting. The firefox package would include these, as the name of the symlink, and maybe as a directory which would be accessed only when the program is invoked as firefox. -- Jeremie Koenig [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ada in Debian, past, present and future. Request for Advocate.
Marc 'HE' Brockschmidt writes: Ludovic Brenta [EMAIL PROTECTED] writes: In July 2003, I adopted the package gnat and several other Ada packages. In November 2003, Matthias Klose sponsored my first few packages into Debian unstable. After I adopted all the orphaned packages I could, I created several new packages from sratch. Now, all my packages have been released as part of sarge. [...] I am now looking for an advocate; if you are interested, please visit: Please don't do something like this - your advocate should have worked with you and know something about you and your plans. Writing an advocation mail isn't that time-consuming, Matthias really should be able to do it himself. Asking random developers to do it abuses the whole advocation process. yes, that was not the question. I had Fabio asked to outline his planned work related to the Ada packages, support for new architectures, etc. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding 'offensive' material
On Fri, Jun 17, 2005 at 07:19:21PM +0200, Jonas Meurer wrote: On 17/06/2005 Andrew Suffield wrote: On Fri, Jun 17, 2005 at 04:25:43PM +0200, Jonas Meurer wrote: On 15/06/2005 Thijs Kinkhorst wrote: Unfortunately people that are easily offended will always exist, even by simple human body parts displayed in a very abstract manner (more abstract than the pictures in any sexual education book). So we have to do something about it, because it's a given. I was thinking that maybe debtags would provide a solution. You can invent a tag contains remote references to natural reproduction and anyone can use that to filter out unwanted packages. the problem is, that most of these sexual pictures or whatsoever are created and even provided because they're offending. maybe not to offend somebody directly, but rather because offending material is that popular. That's simply another way to say that the group of people who are offended is a minority. even if the group where the material is popular is a minority itself? I think you'll find that porn is the majority industry on the internet. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Mozilla Foundation Trademarks
John Hasler wrote: Alexander Sack writes: In general the part of the MoFo brand we are talking about is the product name (e.g. firefox, thunderbird, sunbird). From what I can recall now, it is used in the help menu, the about box, the package-name and the window title bar. I'm not convinced that any of these constitute trademark infringement. Then I'm slightly confused as to your concept of trademark infringement. If I label the car I've built as a Ford (even if it uses a lot of Ford parts), it infringes Ford's trademark. I haven't heard anyone else disputing that to ship a web browser called Firefox, Debian needs an arrangement with the owner of the trademark Firefox as applied to web browsers. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Eric Dorland wrote: * Simon Huggins ([EMAIL PROTECTED]) wrote: I was under the impression that downstreams could call the packages firefox as they had been blessed with official Debian penguin pee as long as they didn't then change them and it was only when they were modified that they potentially had to go to the Mozilla Foundation for a license. That is correct, but (correct me if I'm wrong Gerv), but change would include such things as recompiling it. As I was saying earlier in the thread, what we'd probably do is say that they could make changes within the terms of the trademark policy - possibly the Community Edition rules, which allow for recompilation and limited change. We can certainly discuss the extent of such rights; what we can't agree to is giving them unlimited rights, or even rights as extensive as Debian's or Red Hat's or another trusted distributor's without them proving themselves worthy of such trust. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Eric Dorland wrote: But I don't think it's good for our users for Debian to have rights that the user don't have. Debian already has rights that their users don't have, the most prominent among them being to label a Linux distribution as Debian (or official Debian, or whatever it is you guys use). :-) They do have concerns about the trustability of CAcert certs. I'm mostly convinced they're no worse than other CA's. What we have a problem with (in the context of including the cert in Firefox) is the fact that CAcert haven't been audited, so the risk of including them is unquantifiable. Please see the CAcert list for recent discussions on this topic. Eric Dorland wrote in another thread: Will the add the SPI root CA to their root CA list? It's pretty Debian specific, so I doubt it. There are two ways we could go about this. The first is for the MoFo to have a list of CAs who meet the CA policy[0] in all other ways except that they are too specific to go into the general Firefox build. These could then be included by any distributor at will. The difficulty with that is that currently we don't have time to evaluate the requests of all the CAs requesting general distribution, let alone ones we aren't going to include ourselves. The second is for Debian to show us their policy on how they decide whether a CA is trustworthy, and we say yes, taking everything into account, that policy is OK with us and then we let you guys get on with it. But to attempt this, I need to see the policy :-) Gerv [0] http://www.hecker.org/mozilla/ca-certificate-policy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 03:10:07PM -0400, Eric Dorland wrote: * Andrew Suffield ([EMAIL PROTECTED]) wrote: On Fri, Jun 17, 2005 at 06:08:36PM +0200, Rapha?l Hertzog wrote: Le vendredi 17 juin 2005 14:09 +0100, Andrew Suffield a crit : You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. That would be the part where the trademark holder tells you that you can't distribute modified versions. The Mozilla Foundation explicitely gave us that right (or at least they are ready to give us this right because they trust us). After they first told us that we couldn't distribute modified versions, that was one of several outcomes of debian-legal's investigation into this matter, yes. There were several others, too. Sorry Andrew, which investigation are you referring to? Which other outcomes? You've got some context there I'm not getting. There have been multiple threads on debian-legal over the past couple of years on this issue, exploring it exhaustively (I don't believe *this* thread contains anything new or significant). The important ones are probably these: http://lists.debian.org/debian-legal/2004/03/msg6.html http://lists.debian.org/debian-legal/2005/01/msg00023.html But I'm just fishing from memory, I expect I missed some. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Upcoming removal of orphaned packages
Rich Walker wrote on 16/06/2005 23:23: Sven Mueller [EMAIL PROTECTED] writes: Martin Michlmayr wrote on 16/06/2005 19:18: findimagedupes -- Finds visually similar or duplicate images [#218699] * Orphaned 590 days ago * Package orphaned 360 days ago. Though I probably can't adopt it (due to lack of time), it would be a pity to loose this since there is no comparable commandline tool fdupes? Doesn't do partial matching, but is otherwise excellent. That's (almost?) the point: findimagedupes (or the c++-implementation finddupes.cpp) is intended for the location of duplicate images, with a given fuzziness (not too far apart in size, very similar content). There are a lot of tools which find exact duplicates of files, but those matching images are really rare. cu, sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Fri, Jun 17, 2005 at 01:55:57PM -0500, Ian Murdock wrote: I don't doubt there were changes, even some worthwhile changes, between the version of libc in sarge and the versions in hoary/breezy. My question is: Are the changes worth breaking compatibility? It's a cost/benefit thing. And if they're important enough, why aren't they going into Debian directly? I understand why Ubuntu was moving ahead of Debian before, since Debian was so far behind. But now that sarge is out, don't you think it would be worthwhile to give Debian a chance to fix its release cycle problems and, better yet, to try to help fix them, rather than simply saying Debian is too slow/unpredictable for us? Let's slow down for a minute. No one has said Debian is too slow/unpredictable for us, no one is denying Debian a chance to address the issues with its release cycle, and Hoary did not break glibc ABI compatibility with Sarge. I think the following timeline might help to clarify the situation: 2004-12-27 glibc 2.3.2.ds1-20 uploaded to sid (http://lists.debian.org/debian-devel-changes/2004/12/msg01481.html) 2005-04-08 Ubuntu 5.04 (Hoary Hedgehog) released, with glibc based on (and compatible with) sid's (and sarge's) 2.3.2.ds1-20 (http://www.ubuntulinux.org/504Released) 2005-04-16 glibc 2.3.2.ds1-21 uploaded to sid (http://lists.debian.org/debian-devel-changes/2005/04/msg01457.html) 2005-04-18 glibc 2.3.5 uploaded to experimental (http://lists.debian.org/debian-devel-changes/2005/04/msg01579.html) 2005-04-28 glibc 2.3.2.ds1-21 accepted into sarge (http://release.debian.org/sarge-hints/vorlon) 2005-05-17 glibc 2.3.5 uploaded to breezy (http://lists.ubuntu.com/archives/breezy-changes/2005-May/004798.html) 2005-06-06 Debian 3.1 (Sarge) released, with glibc 2.3.2.ds1-22 (http://lists.debian.org/debian-announce/debian-announce-2005/msg3.html) 2005-06-?? glibc 2.3.5 expected to enter sid sometime this month As I've said to you privately already, I do not feel that demanding binary compatibility between Debian and Ubuntu is the best way to address your concerns. You seem to disagree strongly, as is of course your right, but I think that some of the comments that you've made in support of this cause have been misleading. The fact is that Hoary *was* binary compatible (in both directions) with both sarge and sid when it was released. Later, the Debian glibc maintainers and release managers considered changing the ABI in order to fix a bug. In the course of a lengthy discussion[0], including expression of concerns about inter-distribution compatibility, they weighed the options and decided to go ahead with it. I fully support their decision, and I do not consider the resulting incompatibility to be a significant obstacle to the continuing growth and success of either Debian or Ubuntu. Presumably, neither did they. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=297769 Again, you may disagree with me on this point, but there is no justification for claiming that Ubuntu created this situation, regardless of your opinion about it. Again, as I've said before, it's *sarge* the rest of the world thinks of as Debian, not sid. So, we're getting out patches into sid or we're tracking sid or whatever doesn't really help anything. I don't know what you mean by this. Are you trying to say that: - Patches received from Ubuntu should have been pushed into sarge more aggressively? - Ubuntu should base its development branch on sarge rather than sid? Neither of these interpretations make sense to me. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla Foundation Trademarks
On 6/17/05, Gervase Markham [EMAIL PROTECTED] wrote: John Hasler wrote: Alexander Sack writes: In general the part of the MoFo brand we are talking about is the product name (e.g. firefox, thunderbird, sunbird). From what I can recall now, it is used in the help menu, the about box, the package-name and the window title bar. I'm not convinced that any of these constitute trademark infringement. Then I'm slightly confused as to your concept of trademark infringement. If I label the car I've built as a Ford (even if it uses a lot of Ford parts), it infringes Ford's trademark. I haven't heard anyone else disputing that to ship a web browser called Firefox, Debian needs an arrangement with the owner of the trademark Firefox as applied to web browsers. Debian doesn't need such an arrangement, as I argued in a previous thread six months ago; there's the Coty v. Prestonettes standard and all that. But IMHO it would be advisable for both sides if such an arrangement were reached. I prefer the not-quite-a-trademark-license arrangement discussed in the thread ending at http://lists.debian.org/debian-legal/2005/01/msg00795.html . But then, I tend to take the square deal / keep people's options open when that won't result in a tragedy of the commons approach to freedom rather than the natural right approach. So I'm pro-GPL-as-construed-under-the-actual-law, pro-trademark-when-used-to-discourage-misrepresentation, and pro-real-world-legal-system generally. This may put me in a minority among debian-legal regulars. :-) Cheers, - Michael (IANAL, IANADD)
Re: Question regarding 'offensive' material
On 6/17/05, Andrew Suffield [EMAIL PROTECTED] wrote: I think you'll find that porn is the majority industry on the internet. The Internet is, to zeroth order, useful only for the same four things that interactive TV is well suited for: video games, gambling, pornography, and pornographic gambling video games. Its first-order uses are cracker joyriding, make-money fast schemes, and hot chat leading to occasional sexual assignations (oddly parallel to the zeroth-order uses), plus ripping off copyrighted media and movement of large military science data sets. Usages that you wouldn't be ashamed to admit to your mother are second-order effects at best. These proportions are essentially unchanged since the opening of the Internet to general US undergraduate populations in the mid-80's. Ask anyone who's worked at an ISP or in a university IT department. This does not, of course, mean that I approve of any software on my systems downloading random _anything_ from the internet without my very explicit approval. It astonishes me that anyone opposes the instant removal of something so fundamentally stupid to include in the Debian operating system. Cheers, - Michael
Re: Questions on how to handle this: [EMAIL PROTECTED]: httperf_0.8-3_i386.changes REJECTED]
On Fri, Jun 17, 2005 at 10:12:01AM +0100, Adam D. Barratt wrote: Roberto C. Sanchez [EMAIL PROTECTED], wrote, on Friday, June 17, 2005 6:37 AM: Below I have included the text rejecting my httperf package. I am taking over as maintainer and uploaded a new version that also closed a couple of bugs and moved it from non-US to main. If linking with libssl is not permissible, should the version that is currently in Sarge be slated for removal when 3.1r1 comes out? There is no httperf package in sarge, as there is no non-US archive for sarge, so the question is academic. As http://packages.debian.org/httperf shows, the package currently only exists in oldstable/non-US. Quite right. I should really stay on top of these things :-) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpFkztbGFah6.pgp Description: PGP signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Thu, 16 Jun 2005, Eric Dorland wrote: Well I don't think DFSG #4 says the rename has to be easy, it just has to be possible. Yes. However, the last sentence in DFSG #4 only talks about renaming, not being forced to change content. Don Armstrong -- Build a fire for a man, an he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Jules Bean http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
On Fri, Jun 17, 2005 at 12:57:13PM +0100, Will Newton wrote: On Friday 17 June 2005 07:04, Roberto C. Sanchez wrote: On Thu, Jun 16, 2005 at 06:18:06PM +0100, Martin Michlmayr wrote: iceme -- A graphical menu editor for IceWM [#227054] * Orphaned 520 days ago * Package orphaned 360 days ago. icepref -- Yet another configuration tool for IceWM [#227077] * Orphaned 520 days ago * Package orphaned 360 days ago. I use both of these and would like to adopt them. I will upload next week (via Anibal). These two also use pygtk 1.2 which is rather outdated. There seems to be a new upstream version that uses pygtk 2.0, but I'm not sure if it is functionally equivalent. OK. I will look into it. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpYQntRJ8KO8.pgp Description: PGP signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Don Armstrong ([EMAIL PROTECTED]) wrote: On Thu, 16 Jun 2005, Eric Dorland wrote: Well I don't think DFSG #4 says the rename has to be easy, it just has to be possible. Yes. However, the last sentence in DFSG #4 only talks about renaming, not being forced to change content. Ummm, huh? If I legally change my name, I also have to change the name on my driver's license. If I change the name of my program, I also change all references to that name in program (if for no other reason, consistency). Is that really so unexpected? The DFSG didn't tell you to breathe either, I hope you can still figure out that you should do 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: Mozilla Foundation Trademarks
Gerv writes: If I label the car I've built as a Ford (even if it uses a lot of Ford parts), it infringes Ford's trademark. Not until you try to sell it. Ford Motor Company does not own the word 'Ford'. They merely have the exclusive right to sell automobiles (and related parts and services) using that mark. -- John Hasler [EMAIL PROTECTED] Elmwood, WI USA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla Foundation Trademarks
Michael writes: Debian doesn't need such an arrangement, as I argued in a previous thread six months ago; there's the Coty v. Prestonettes standard and all that. But IMHO it would be advisable for both sides if such an arrangement were reached. Exactly. If Debian doesn't need such an arrangement, neither do our users. And if our users don't need such an arrangement, our accepting it does not put us in a privileged position with respect to them: they have the legal right to do everything that we want to do with or without permission. So let's accept the arrangement and move on. There is no DFSG problem here even if we do accept the notion that the DFSG applies to trademarks. -- John Hasler (IANAL, IAADD) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, 17 Jun 2005, Eric Dorland wrote: * Don Armstrong ([EMAIL PROTECTED]) wrote: the last sentence in DFSG #4 only talks about renaming, not being forced to change content. If I change the name of my program, I also change all references to that name in program (if for no other reason, consistency). You should change them when it makes sense to you. However, being forced to do so by the trademark license when it doesn't make sense to you is another thing entirely.[1] Imagine suddenly having to go and rip out every single reference to the name of a program, some of which could be intricately tied into the codebase; or a library that required you to rename all symbols bearing the name of the library, and thus change any symbols that the library exported. Don Armstrong 1: Many things that the DFSG allows are relatively insane; I'm sure we all have examples of code that should be outlawed (some of the code I've written definetly qualifies.) However, when the license restricts these types of modifications, the freedom of the license begins to come into question. -- This space for rent http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
On Fri, Jun 17, 2005 at 07:47:43PM -0700, Don Armstrong wrote: On Fri, 17 Jun 2005, Eric Dorland wrote: * Don Armstrong ([EMAIL PROTECTED]) wrote: the last sentence in DFSG #4 only talks about renaming, not being forced to change content. If I change the name of my program, I also change all references to that name in program (if for no other reason, consistency). You should change them when it makes sense to you. However, being forced to do so by the trademark license when it doesn't make sense to you is another thing entirely.[1] Imagine suddenly having to go and rip out every single reference to the name of a program, some of which could be intricately tied into the codebase; or a library that required you to rename all symbols bearing the name of the library, and thus change any symbols that the library exported. ... which isn't covered by trademark law anyway, so could only be enforced by an over-reaching copyright license, which is non-free. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* Andrew Suffield ([EMAIL PROTECTED]) wrote: On Fri, Jun 17, 2005 at 03:10:07PM -0400, Eric Dorland wrote: * Andrew Suffield ([EMAIL PROTECTED]) wrote: On Fri, Jun 17, 2005 at 06:08:36PM +0200, Rapha?l Hertzog wrote: Le vendredi 17 juin 2005 14:09 +0100, Andrew Suffield a crit : You could also, as a courtesy to other readers, lay before us the stunningly obvious proof that a free software that elects to use trademarks automagically transmutates into non-free state. That would be the part where the trademark holder tells you that you can't distribute modified versions. The Mozilla Foundation explicitely gave us that right (or at least they are ready to give us this right because they trust us). After they first told us that we couldn't distribute modified versions, that was one of several outcomes of debian-legal's investigation into this matter, yes. There were several others, too. Sorry Andrew, which investigation are you referring to? Which other outcomes? You've got some context there I'm not getting. There have been multiple threads on debian-legal over the past couple of years on this issue, exploring it exhaustively (I don't believe *this* thread contains anything new or significant). The important ones are probably these: http://lists.debian.org/debian-legal/2004/03/msg6.html http://lists.debian.org/debian-legal/2005/01/msg00023.html But I'm just fishing from memory, I expect I missed some. You are correct. But I hope this time we can make some sort of decision as to what action, if any, we need to take. -- 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: Eric Dorland wrote: * Simon Huggins ([EMAIL PROTECTED]) wrote: I was under the impression that downstreams could call the packages firefox as they had been blessed with official Debian penguin pee as long as they didn't then change them and it was only when they were modified that they potentially had to go to the Mozilla Foundation for a license. That is correct, but (correct me if I'm wrong Gerv), but change would include such things as recompiling it. As I was saying earlier in the thread, what we'd probably do is say that they could make changes within the terms of the trademark policy - possibly the Community Edition rules, which allow for recompilation and limited change. We can certainly discuss the extent of such rights; what we can't agree to is giving them unlimited rights, or even rights as extensive as Debian's or Red Hat's or another trusted distributor's without them proving themselves worthy of such trust. Ok, that's interesting. It's somewhat more permissive than I had assumed. I'm not sure it really changes anything from our perspective though. -- 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 Foundation Trademarks
* John Hasler ([EMAIL PROTECTED]) wrote: Michael writes: Debian doesn't need such an arrangement, as I argued in a previous thread six months ago; there's the Coty v. Prestonettes standard and all that. But IMHO it would be advisable for both sides if such an arrangement were reached. Exactly. If Debian doesn't need such an arrangement, neither do our users. And if our users don't need such an arrangement, our accepting it does not put us in a privileged position with respect to them: they have the legal right to do everything that we want to do with or without permission. So let's accept the arrangement and move on. There is no DFSG problem here even if we do accept the notion that the DFSG applies to trademarks. If we don't need the arragement, why exactly would we accept it 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
Accepted raster3d 2.7c-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Jun 2005 19:53:59 -0300 Source: raster3d Binary: raster3d raster3d-doc Architecture: source i386 all Version: 2.7c-5 Distribution: unstable Urgency: low Maintainer: Nelson A. de Oliveira [EMAIL PROTECTED] Changed-By: Nelson A. de Oliveira [EMAIL PROTECTED] Description: raster3d - tools for generating images of proteins or other molecules raster3d-doc - documents and example files for Raster3D Closes: 314239 Changes: raster3d (2.7c-5) unstable; urgency=low . * Fix FTBFS (amd64/gcc-4.0): -malign-double makes no sense in the 64bit mode (Closes: #314239). Thanks to Andreas Jochens for pointing this. Files: e78c67d0b99c6d5781078b107f8bedb9 689 non-free/science optional raster3d_2.7c-5.dsc cfdc42696d5b31b9df18f1d82f3832b4 10359 non-free/science optional raster3d_2.7c-5.diff.gz b80566bda256c853c4fa8d4a743f5bdc 1546748 non-free/science optional raster3d-doc_2.7c-5_all.deb 84ddbc0d846f738d443290042fc5347f 188704 non-free/science optional raster3d_2.7c-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCsnFnYDBbMcCf01oRAvyKAKC0XNWpaxo0rdJosTRS3kSn/mNbTQCdER7P mPQ15ekpbfwWwL4D61DdEoo= =E8Uu -END PGP SIGNATURE- Accepted: raster3d-doc_2.7c-5_all.deb to pool/non-free/r/raster3d/raster3d-doc_2.7c-5_all.deb raster3d_2.7c-5.diff.gz to pool/non-free/r/raster3d/raster3d_2.7c-5.diff.gz raster3d_2.7c-5.dsc to pool/non-free/r/raster3d/raster3d_2.7c-5.dsc raster3d_2.7c-5_i386.deb to pool/non-free/r/raster3d/raster3d_2.7c-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmms-singit 0.1.28-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Jun 2005 10:25:11 +0200 Source: xmms-singit Binary: xmms-singit Architecture: source i386 Version: 0.1.28-2 Distribution: unstable Urgency: low Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: xmms-singit - Display and edit lyrics with XMMS Closes: 297884 313861 Changes: xmms-singit (0.1.28-2) unstable; urgency=low . * New maintainer address, many thanks to Andreas Barth for previous sponsoring * debian/control: Standards-Version: 3.6.2, no changes required * debian/watch: now points to prdownloads.sf.net * Allow building on amd64 with gcc-4.0, thanks to Andreas Jochens for the patch (upstream doesn't like it, but here we go for now) (Closes: #297884) * Some German PO file corrections, thanks to Jens Seidel for the initial patch (Closes: #313861) Files: d342ba81614c82d2fe23bfff9a44ae55 737 sound optional xmms-singit_0.1.28-2.dsc 49811a68114a1a0788ae6c8774c79362 6457 sound optional xmms-singit_0.1.28-2.diff.gz 09bfb43c35d7e979ed1f1972cbbabdae 331076 sound optional xmms-singit_0.1.28-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCso0xs3U+TVFLPnwRAp7+AJ4v4dNNCXSzORwUipVgVezbNi2+lwCghuvC WCaS9BXwTiHggw2WbScJcA0= =NDsS -END PGP SIGNATURE- Accepted: xmms-singit_0.1.28-2.diff.gz to pool/main/x/xmms-singit/xmms-singit_0.1.28-2.diff.gz xmms-singit_0.1.28-2.dsc to pool/main/x/xmms-singit/xmms-singit_0.1.28-2.dsc xmms-singit_0.1.28-2_i386.deb to pool/main/x/xmms-singit/xmms-singit_0.1.28-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted heartbeat 1.2.3-10 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Jun 2005 18:17:03 +0900 Source: heartbeat Binary: libstonith-dev ldirectord libstonith0 heartbeat libpils-dev libpils0 stonith heartbeat-dev Architecture: source i386 all Version: 1.2.3-10 Distribution: unstable Urgency: low Maintainer: Simon Horman [EMAIL PROTECTED] Changed-By: Simon Horman [EMAIL PROTECTED] Description: heartbeat - Subsystem for High-Availability Linux heartbeat-dev - Subsystem for High-Availability Linux - development files ldirectord - Monitors virtual services provided by LVS libpils-dev - Plugin and Interface Loading System - development files libpils0 - Plugin and Interface Loading System libstonith-dev - Interface for remotely powering down a node in the cluster libstonith0 - Interface for remotely powering down a node in the cluster stonith- Interface for remotely powering down a node in the cluster Closes: 310600 Changes: heartbeat (1.2.3-10) unstable; urgency=low . * Make signal handling less aggressive to avoid exiting in FTP and LDAP chacks. (closes: #310600) Files: ec480ec7fedf0ac8a65bfefbacc30ef5 871 admin optional heartbeat_1.2.3-10.dsc 1bd59ea532ef9ff10a386928ebab13ad 263918 admin optional heartbeat_1.2.3-10.diff.gz 0340b341f4603fccb70ec4a75a3feead 44988 admin optional ldirectord_1.2.3-10_all.deb d9ef9698c31ff73723eb9303cde870c7 30170 admin optional stonith_1.2.3-10_i386.deb 14537e52f547e7f0ee7da4dce97cd71d 79042 libs optional libstonith0_1.2.3-10_i386.deb bfcd2858592b5d8ca0c26d3f0bec2233 29320 libdevel optional libstonith-dev_1.2.3-10_i386.deb 370757e3c501619c8e2220d017f76640 47862 libs optional libpils0_1.2.3-10_i386.deb 334a180850eccf5d2ab15d8f0361351f 58656 devel optional libpils-dev_1.2.3-10_i386.deb b8d5300779190bc8c67876ce283486fe 498452 admin optional heartbeat_1.2.3-10_i386.deb fd0d56db406bf89f9ca29c7a1dddc913 117294 devel optional heartbeat-dev_1.2.3-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCspb8du+M6Iexz7URAjmmAJ9xY+GqDz5tly2DLDNnngbdbgKiUACgg5dE 37mCARa/yMRu0WqTr1Gaq4U= =z30v -END PGP SIGNATURE- Accepted: heartbeat-dev_1.2.3-10_i386.deb to pool/main/h/heartbeat/heartbeat-dev_1.2.3-10_i386.deb heartbeat_1.2.3-10.diff.gz to pool/main/h/heartbeat/heartbeat_1.2.3-10.diff.gz heartbeat_1.2.3-10.dsc to pool/main/h/heartbeat/heartbeat_1.2.3-10.dsc heartbeat_1.2.3-10_i386.deb to pool/main/h/heartbeat/heartbeat_1.2.3-10_i386.deb ldirectord_1.2.3-10_all.deb to pool/main/h/heartbeat/ldirectord_1.2.3-10_all.deb libpils-dev_1.2.3-10_i386.deb to pool/main/h/heartbeat/libpils-dev_1.2.3-10_i386.deb libpils0_1.2.3-10_i386.deb to pool/main/h/heartbeat/libpils0_1.2.3-10_i386.deb libstonith-dev_1.2.3-10_i386.deb to pool/main/h/heartbeat/libstonith-dev_1.2.3-10_i386.deb libstonith0_1.2.3-10_i386.deb to pool/main/h/heartbeat/libstonith0_1.2.3-10_i386.deb stonith_1.2.3-10_i386.deb to pool/main/h/heartbeat/stonith_1.2.3-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xcruise 0.30-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Jun 2005 10:57:04 +0200 Source: xcruise Binary: xcruise Architecture: source i386 Version: 0.30-5 Distribution: unstable Urgency: low Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: xcruise- Fly about a 3D-formed file system Closes: 306722 Changes: xcruise (0.30-5) unstable; urgency=low . * New maintainer address, many thanks to Kenshi Muto for previous sponsoring * debian/control: Standards-Version: 3.6.2, no changes required * debian/rules: split out linking into debian/links * debian/watch: now pointing to prdownloads.sf.net * Various wording fixes, many thanks to A Costa for the intial pointer (Closes: #306722) Files: 37d056b4383deea835e3e3a6ef2483d1 592 games optional xcruise_0.30-5.dsc 31c8a867e98f9648fcf1588a8c0da6db 4422 games optional xcruise_0.30-5.diff.gz 0bbe9936eb508fb984050d4ed2bc411a 30350 games optional xcruise_0.30-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCspS2s3U+TVFLPnwRArZkAJ9t8+bbmc4GO4qWRS0wxAUs/OkysQCeM1oX m/NqPSQ45//rOTW3eKv92WU= =JSX9 -END PGP SIGNATURE- Accepted: xcruise_0.30-5.diff.gz to pool/main/x/xcruise/xcruise_0.30-5.diff.gz xcruise_0.30-5.dsc to pool/main/x/xcruise/xcruise_0.30-5.dsc xcruise_0.30-5_i386.deb to pool/main/x/xcruise/xcruise_0.30-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mrxvt 0.4.1-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 13 Jun 2005 22:02:03 +0100 Source: mrxvt Binary: mrxvt mrxvt-common mrxvt-mini mrxvt-cjk Architecture: source i386 all Version: 0.4.1-3 Distribution: unstable Urgency: low Maintainer: Qingning Huo [EMAIL PROTECTED] Changed-By: Qingning Huo [EMAIL PROTECTED] Description: mrxvt - lightweight multi-tabbed X terminal emulator mrxvt-cjk - lightweight multi-tabbed X terminal emulator mrxvt-common - lightweight multi-tabbed X terminal emulator mrxvt-mini - lightweight multi-tabbed X terminal emulator Closes: 312710 Changes: mrxvt (0.4.1-3) unstable; urgency=low . * Fix portability problem on ia64 (Closes: #312710). - Add CPPFLAGS=-D_GNU_SOURC for strndup(). - Use uintptr_t to define u_intp_t. Files: 15008c8b45ffe68135a72caafdb0d2a4 744 x11 optional mrxvt_0.4.1-3.dsc 58c7be3e8bf1a7c6473a0e9e89070c7d 7742 x11 optional mrxvt_0.4.1-3.diff.gz e1f76994047c8c6d5c3e84231e2c392b 118442 x11 optional mrxvt-common_0.4.1-3_all.deb 8659ef26df9859e595f4a7d95e7f02a4 123204 x11 optional mrxvt_0.4.1-3_i386.deb 01a9368d188160d27b74c494f8ea98d1 68128 x11 optional mrxvt-mini_0.4.1-3_i386.deb ef274cec1b2622854f6b6707f6af32f1 75454 x11 optional mrxvt-cjk_0.4.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCsqc/hQui3hP+/EARArqyAJ9O8B21NoCH4hvlsxY7PdG6/CW5LwCg3TCY 38eN46/LOUM1rfwgu3dCZr4= =yTfd -END PGP SIGNATURE- Accepted: mrxvt-cjk_0.4.1-3_i386.deb to pool/main/m/mrxvt/mrxvt-cjk_0.4.1-3_i386.deb mrxvt-common_0.4.1-3_all.deb to pool/main/m/mrxvt/mrxvt-common_0.4.1-3_all.deb mrxvt-mini_0.4.1-3_i386.deb to pool/main/m/mrxvt/mrxvt-mini_0.4.1-3_i386.deb mrxvt_0.4.1-3.diff.gz to pool/main/m/mrxvt/mrxvt_0.4.1-3.diff.gz mrxvt_0.4.1-3.dsc to pool/main/m/mrxvt/mrxvt_0.4.1-3.dsc mrxvt_0.4.1-3_i386.deb to pool/main/m/mrxvt/mrxvt_0.4.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fribidi 0.10.5-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Jun 2005 11:03:25 +0100 Source: fribidi Binary: libfribidi0-udeb libfribidi0 libfribidi-dev Architecture: source i386 Version: 0.10.5-2 Distribution: unstable Urgency: low Maintainer: Baruch Even [EMAIL PROTECTED] Changed-By: Baruch Even [EMAIL PROTECTED] Description: libfribidi-dev - Development files for FreeBidi library libfribidi0 - Free Implementation of the Unicode BiDi algorithm libfribidi0-udeb - Free Implementation of the Unicode BiDi algorithm (udeb) Closes: 314379 Changes: fribidi (0.10.5-2) unstable; urgency=low . * Compile with -Os -fomit-frame-pointer to reduce size of udeb (Closes: #314379) Files: 1b5014d91a60724b56c71e0c67014496 613 libs optional fribidi_0.10.5-2.dsc df5a2cbc4a3283ef9c1dbd3ad97f4eeb 76481 libs optional fribidi_0.10.5-2.diff.gz c5bfe9e31c4e6d7be0166affa6b39b43 40446 libs optional libfribidi0_0.10.5-2_i386.deb 126f57c7df37c97ed1bedbedfc27c8fb 42198 libdevel optional libfribidi-dev_0.10.5-2_i386.deb 1547a60b4f17ff1d11bf93b167268c31 16334 debian-installer extra libfribidi0-udeb_0.10.5-2_i386.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCsrAYHCar6qtHRZgRAvSGAJ47jz3K5qxcCU2zcQfkFI1wqsQvlACeJTgC LKTOTkUXJsb0DxAH1Abr7d4= =rrt4 -END PGP SIGNATURE- Accepted: fribidi_0.10.5-2.diff.gz to pool/main/f/fribidi/fribidi_0.10.5-2.diff.gz fribidi_0.10.5-2.dsc to pool/main/f/fribidi/fribidi_0.10.5-2.dsc libfribidi-dev_0.10.5-2_i386.deb to pool/main/f/fribidi/libfribidi-dev_0.10.5-2_i386.deb libfribidi0-udeb_0.10.5-2_i386.udeb to pool/main/f/fribidi/libfribidi0-udeb_0.10.5-2_i386.udeb libfribidi0_0.10.5-2_i386.deb to pool/main/f/fribidi/libfribidi0_0.10.5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted i8kutils 1.27 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Jun 2005 11:26:26 +0200 Source: i8kutils Binary: i8kutils i8kutils-smm Architecture: source i386 Version: 1.27 Distribution: unstable Urgency: low Maintainer: Massimo Dal Zotto [EMAIL PROTECTED] Changed-By: Massimo Dal Zotto [EMAIL PROTECTED] Description: i8kutils - utilities for Dell Inspiron and Latitude laptops Closes: 314270 Changes: i8kutils (1.27) unstable; urgency=low . * In debian/control added kfreebsd-i386 to Architecture: field. Closes: #314270. . * In i8kmon disabled the auto option by default. Users must enable it manually in the config file. . * In i8kmon added MAKE_LINTIAN_HAPPY hack. . * Added the private i8kutils-smm package. This package is used by me only for testing purposes and must not be distributed with debian or any other distribution. Files: 5743d41db4c0e32b1e7f51adcb120b81 520 utils optional i8kutils_1.27.dsc 8f3d3cbf7197fc209b0b64bf0a9732e3 44250 utils optional i8kutils_1.27.tar.gz 6b6c1ff084a5c9f02add99243acc9f6a 31418 utils optional i8kutils_1.27_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCsrp+FH8a6i22VZYRAlUWAJwKTlmp7tFP7ypnvR8I1rVSzQxnywCgxQzL Tq+g3sjOwi9srT4+Y8FZsik= =J+2L -END PGP SIGNATURE- Accepted: i8kutils_1.27.dsc to pool/main/i/i8kutils/i8kutils_1.27.dsc i8kutils_1.27.tar.gz to pool/main/i/i8kutils/i8kutils_1.27.tar.gz i8kutils_1.27_i386.deb to pool/main/i/i8kutils/i8kutils_1.27_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted screem 0.14.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Jun 2005 18:41:52 +0100 Source: screem Binary: screem Architecture: source i386 Version: 0.14.1-1 Distribution: unstable Urgency: low Maintainer: Rob Bradford [EMAIL PROTECTED] Changed-By: Rob Bradford [EMAIL PROTECTED] Description: screem - A GNOME website development environment Changes: screem (0.14.1-1) unstable; urgency=low . * New upstream release Files: fc13216dd21f4c8e17fd4691c5fa2697 828 gnome optional screem_0.14.1-1.dsc b23bf53698df79477f83f3d66b6eab0d 3947396 gnome optional screem_0.14.1.orig.tar.gz 76a7962967f3e20e53fa4463a4b4badf 34898 gnome optional screem_0.14.1-1.diff.gz 01b9a98a532b8f60f7d900f23dcd705c 2296876 web optional screem_0.14.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCse89Cw8pKd+B7oMRAmGgAKCT7BFYRr1CioWfeoZK5pkGSEM0aQCgvxj1 czvd4bkFh9Wsrr8dSQPNhjg= =6LUs -END PGP SIGNATURE- Accepted: screem_0.14.1-1.diff.gz to pool/main/s/screem/screem_0.14.1-1.diff.gz screem_0.14.1-1.dsc to pool/main/s/screem/screem_0.14.1-1.dsc screem_0.14.1-1_i386.deb to pool/main/s/screem/screem_0.14.1-1_i386.deb screem_0.14.1.orig.tar.gz to pool/main/s/screem/screem_0.14.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
