coke
pomade http://whywaitlonger.com/cams2.php?SEVY Cedric
Re: Greylisting for @debian.org email, please
Hi, Frans Pop wrote: Try mine: 195.240.184.66 And yes, it is static and not dynamic but unlikely to change rarely. Not listed either. I started using my own mailserver because the one from my provider was down a lot for a while or not delivering within something like 8 hours (they seem to be better ATM). Using my own server I would at least _know_ what was happening to my mails. Yes, that is a valid reason, although being able to check manually sort of implies that you don't have a lot of traffic. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
On 6/19/05, Florian Weimer [EMAIL PROTECTED] wrote: * Marc Haber: On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer [EMAIL PROTECTED] wrote: That could save a grand total of about a second. It will save time in case of error when the bootup process stalls for timeouts like DNS and NTP. You should set the clock using NTP *before* starting any daemons. Most daemons don't use monotonic clocks (I'm not even sure if Linux supports them at the required level), and some of them fail in strange ways if the system clock warps. Doesn't Linux or NTP support gradually changing the clock exactly to avoid such warps?
Re: And now for something completely different... etch!
On Friday 17 June 2005 22:06, Steve Langasek [EMAIL PROTECTED] wrote: 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; There have been root-kits that hide files and show the original versions to programs that do checks. This is not really difficult to do with a kernel module. 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). True. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Sunday 19 June 2005 08:22, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: If you don't want to accept mail from users, for whatever reason, you don't have to. But Debian requires that uploads have a valid email address: and that means one that accepts all legitimate mail from all users, and it isn't up to you to try and offload work to them. I guess that this doesn't have to be an @debian.org address. I've been considering removing my @debian.org address, the only things that go to it are debian-private (which I can hopefully get directed to another address) and spam. And don't trot out any lies about no false positives. Say, instead, I'm making you do work so that I don't have to. That's an amusing way to look at it. Make everyone who receives mail through Debian servers (both list servers and their personal @debian.org address) do extra work because you don't want to remove yourself from the CBL (which you can only get listed on if you send mail to a spam-trap address). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
* Olaf van der Spek: You should set the clock using NTP *before* starting any daemons. Most daemons don't use monotonic clocks (I'm not even sure if Linux supports them at the required level), and some of them fail in strange ways if the system clock warps. Doesn't Linux or NTP support gradually changing the clock exactly to avoid such warps? Gradually skewing the clock doesn't exactly work that well if the offset exceeds a few minutes. You don't want to run with a wrong clock for hours or even days. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Sunday 19 June 2005 08:24, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: An email address with such blocking on it is therefore not suitable for the Maintainer: field of a Debian package. What anti-spam measures do you consider acceptable for a Debian maintenance address? Keep in mind that most @debian.org email gets directed to another mail server that has some anti-spam measures in place. It seems to me that your personal requirements for lack of spam protection on Debian developers would exclude most DDs. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Saturday 18 June 2005 01:07, Pierre Habouzit [EMAIL PROTECTED] wrote: 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. Why is it tolerable to receive 200 spams in a day? On a bad day I will receive over 100 spams even though I use most of the anti-spam measures that some people in this discussion don't like. The more spam that people receive the less care they will take when deleting the spam without reading it. This leads to legitimate messages being deleted by mistake. Bad luck for you if your question about my package appears in between a few spams in my inbox and I accidentally delete it with the spam. The Debian servers send out a significant number of bounces for spam. Some DDs have their mail server do in-line content filtering and reject mail with a SMTP 55x code which is sent to them from the Debian server because it was addressed to their @debian.org address. This leads to spam bounces and delay messages from the Debian servers going to innocent people. This means that when a non-spam message bounces because a Debian server can't send it on it will probably be ignored. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Sun, Jun 19, 2005 at 05:19:08PM +0100, Scott James Remnant wrote: A definitive example would be the (eventually abandoned) attempt by Ximian to provide debs for Helix GNOME. Didn't that have more to do with it being experimental, rather flakey, and conflicting badly with the gnome stuff in Debian? The main problem they had was that they created the debs for potato, and they were perfectly installable on that. But Debian changed things hugely in unstable, so they weren't installable there -- and then introduced testing, making three incompatible systems. It was impossible to create a single set of debs that would work on all three (stable, testing, unstable) distributions of Debian at the same time. I thought the big problem was that the Helix GNOME packages were packaged without any coordination with Debian, and no effort was made on the part of those packagers (and therefore, not by anyone else either) to ensure the official Debian packages for woody included a smooth upgrade path? There are some fundamental technical problems with the way Debian does things, and the way our software works, that makes deriving from Debian or providing third-party debs very hard or impossible. Unfortunately Debian has a habit of blaming the derivative or third party for working around these problems :-( Let's use a popular example... I make a package that requires /usr/bin/bzgrep. In Debian, I would have to read the debian/changelog for bzip2 and discover that this wasn't introduced until 1.0.1-3, and thus Depends: bzip2 (= 1.0.1-3) But in a Debian-derivative with a different release schedule (perhaps a system used in Schools and sync'd on the start of a school year), that might have been backported and added in 0.9.5d-3school1 Depends: bzip2 (= 0.9.5d-3school1) There's no way to express both of these relationships in the same binary (as 1.0.1-2 would satisfy the relationship for the Debian-derivative). Sure there is -- Provides: bzgrep But that requires coordination between the maintainers of the two packages. And while file-based dependencies could address this particular class of issue (and I think there's far from universal agreement that it's a good idea), there are certainly other issues where packaging system changes can't possibly be a substitute. It's also certainly not realistic to expect Debian maintainers to track down whatever arbitrary changes any Debian derivative is making to their packages: there are far too many Debian derivatives to go around. So yes, when Debian derivatives make changes without communicating with Debian about them, I do blame the derivatives for the resulting incompatibilities. Similar problems exist for shared libraries, I might need a symbol added in a particular revision in one derivative and a different one in another. And do you have any real-world examples of this happening? Patching upstream libraries in this fashion is strongly discouraged within Debian. Even glibc, which seems to have started this discussion, hasn't suffered from such a problem between Debian and Ubuntu. I don't disagree with, and in fact, I utterly support the idea that Debian should be an excellent base for derivative distributions and third-party packages. I just don't think sarge is there, in fact, I think sarge is about as far from that ideal as you can get. We need social and technical changes to make Debian suitable as a standard base, I think we should do it and I think we _can_ do it. But first Debian needs to stop blaming derivatives and third parties for breaking compatibility, and instead ask what we did wrong that required them to break compatibility in order to reach their goals. I think that's a very unrealistic position to take. If the derivatives care about breaking compatibility, why aren't they here *telling* us when we've done something wrong? And if upwards compatibility isn't a priority for them, why assume that this is any fault of Debian's? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
On Saturday 18 June 2005 01:33, Pierre Habouzit [EMAIL PROTECTED] wrote: 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. Do you have any evidence to support yout claim that big mail servers are configured to handle gray-listing servers differently from other mail servers? My experience from working at big ISPs is that queues can take 60 minutes to process because they have many tens of thousands of messages. A queue with more than 50,000 messages will take quite a while to process even if you have a 100baseT full-duplex connection to the Internet. 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. In what situation will you have three such mail servers? 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. My experience is that when you have a mail server farm dealing with gigs of mail a day you don't bother about special queuing etc. Any change from the default config of a mail server is a change that has to be preserved across upgrades (including emergency upgrades for security reasons), it has to be tested, and if it goes wrong it might do bad things to hundreds of thousands of messages. btw, I don't know how to help to deploy antispam tools for debian, but I can help if any help is welcomed/wanted/... You could help by listing the anti-spam measures that you consider to be acceptable. Rejecting every suggestion for an improvement is not helpful. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Thursday 16 June 2005 23:48, Kalle Kivimaa [EMAIL PROTECTED] wrote: I do _not_ want to have my debian.org mail forwarding go through a greylisting service. I've had to deal with one too many user complaints due to greylisting. If it is a configurable service, then fine, other people may have different experiences, but if greylisting becomes a mandatory feature, I guess I have to start using non-greylisted (ie. non-Debian) addresses in my Debian correspondence. Why would it be such a problem if you use a non-Debian email address for Debian correspondence? As far as I recall I have never used my Debian email address in the From: field of an email or in a Debian package maintainer field. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Le Lun 20 Juin 2005 09:58, Russell Coker a écrit : On Saturday 18 June 2005 01:33, Pierre Habouzit [EMAIL PROTECTED] wrote: 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. Do you have any evidence to support yout claim that big mail servers are configured to handle gray-listing servers differently from other mail servers? I do. I know personnaly some admins of big MX (not necessarily ISPs, french schools/universities in my case) that have a special rule for domain that they know practicing greylisting, and that *force* the delay to be of 30 to 60 minutes. and they increase that time if their queue is big My experience from working at big ISPs is that queues can take 60 minutes to process because they have many tens of thousands of messages. A queue with more than 50,000 messages will take quite a while to process even if you have a 100baseT full-duplex connection to the Internet. well, greylisiting is done before any DATA is sent, and won't charge your connection that much. so the BW problem seems quite irrelevant. the latency will play a big role though. 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. In what situation will you have three such mail servers? redirections : my debian account redirects to an adress I have from my alumni that is a redirection address garanteed for life that redirects to my real account. I do that because my alumni provides me really good AV and AS services, and all my ingoing mail comes through it. So maybe 3 is a bit exagerated, but I think 2 is pretty common. btw, I don't know how to help to deploy antispam tools for debian, but I can help if any help is welcomed/wanted/... You could help by listing the anti-spam measures that you consider to be acceptable. Rejecting every suggestion for an improvement is not helpful. I already did. I don't find blacklists, or greylists alone be of any good : too many false positives ofr r(h)bls, and too many delays for greylisting. IMHO, rbls, SPF and others techniques that induce false positives have to be used upside down : use the rbls, SPF, ... to clean mail. that means, that a mail that is 100% correct wrt dnsRBLs, SPF records, ... can come in. any other mail, then, can go through evil treatments like greylisting. It's a way to select mails that are suspicious, and let them be delayed. With that, it's quite easy to avoid greylisting if you are a real ISP/MX/... : you only have to try to be removed from RBLs, or fix your domain wrt SPF if you use it and use it badly. I've written a little postfix POLICY daemon that does what I explained here. it's called whitelister, and it's in the repo. Though, it has not been (AFAIK) used in a big queue, but I plan to. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpEWnV2IYoTa.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Lun 20 Juin 2005 09:51, Russell Coker a écrit : On Saturday 18 June 2005 01:07, Pierre Habouzit [EMAIL PROTECTED] wrote: 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. Why is it tolerable to receive 200 spams in a day? On a bad day I will receive over 100 spams even though I use most of the anti-spam measures that some people in this discussion don't like. The more spam that people receive the less care they will take when deleting the spam without reading it. This leads to legitimate messages being deleted by mistake. Bad luck for you if your question about my package appears in between a few spams in my inbox and I accidentally delete it with the spam. The Debian servers send out a significant number of bounces for spam. Some DDs have their mail server do in-line content filtering and reject mail with a SMTP 55x code which is sent to them from the Debian server because it was addressed to their @debian.org address. This leads to spam bounces and delay messages from the Debian servers going to innocent people. This means that when a non-spam message bounces because a Debian server can't send it on it will probably be ignored. I know that, but it does not (IMHO) justify the use of greylising for everybody by default. I prefer to receive spam (and I do a lot through my @debian.org address, despite the fact that it's quite recent) that is filtered by my personnal bogofilter quite well (even if not 100% accurate) than to have some QOS alteration. moreover, I believe there is better ways to use greylising, like I already explained in the thread 2 or 3 times already. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYJ2gJBqwuQ.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Le Lun 20 Juin 2005 10:02, Russell Coker a écrit : On Thursday 16 June 2005 23:48, Kalle Kivimaa [EMAIL PROTECTED] wrote: I do _not_ want to have my debian.org mail forwarding go through a greylisting service. I've had to deal with one too many user complaints due to greylisting. If it is a configurable service, then fine, other people may have different experiences, but if greylisting becomes a mandatory feature, I guess I have to start using non-greylisted (ie. non-Debian) addresses in my Debian correspondence. Why would it be such a problem if you use a non-Debian email address for Debian correspondence? As far as I recall I have never used my Debian email address in the From: field of an email or in a Debian package maintainer field. from my new debian maintainer account mail : We strongly suggest that you use your [EMAIL PROTECTED] address for the maintainer field in your packages, because that one will be valid as long as you are a Debian developer, even if you change jobs, leave university or change Internet Service providers. I personnally use my @debian.org address in order to filter all my Debian related mail, including if not real time, at least quite fast discussion. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgplWFv6K51L6.pgp Description: PGP signature
Re: Greylisting for @debian.org email, please
Russell Coker [EMAIL PROTECTED] writes: Why would it be such a problem if you use a non-Debian email address for Debian correspondence? As far as I recall I have never used my Debian email address in the From: field of an email or in a Debian package maintainer field. Like I said, it wouldn't be a problem if I changed to one of my alternative addresses. I just wanted to point out that a non-configurable spam filtering system on Debian addresses probably would cause some people to switch from Debian addresses to non-Debian ones. If the Project wants to promote using Debian addresses for Debian related correspondence, then that should be taken into account when deciding what spam filtering system to use. If not, then of course it is a non-issue. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Monday 20 June 2005 18:09, Kalle Kivimaa [EMAIL PROTECTED] wrote: Russell Coker [EMAIL PROTECTED] writes: Why would it be such a problem if you use a non-Debian email address for Debian correspondence? As far as I recall I have never used my Debian email address in the From: field of an email or in a Debian package maintainer field. Like I said, it wouldn't be a problem if I changed to one of my alternative addresses. I just wanted to point out that a non-configurable spam filtering system on Debian addresses probably would cause some people to switch from Debian addresses to non-Debian ones. As a total lack of anti-spam measures will cause some other people to switch from Debian addresses. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
Florian == Florian Weimer [EMAIL PROTECTED] writes: Florian You should set the clock using NTP *before* starting any Florian daemons. ...which of course is a problem if the daemons are required to setup the network connection to the NTP server... e.g. network tunnels and DNS servers both might need to be started first before the NTP server can be contacted. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Mon, Jun 20, 2005 at 05:58:11PM +1000, Russell Coker wrote: Do you have any evidence to support yout claim that big mail servers are configured to handle gray-listing servers differently from other mail servers? Not quite the same thing as Pierre was describing but some mail server software have an option which allows mails where delivery needs to be retried to be directed to a separate machine. This can be useful if some sites that get a lot of mail are being very slow to respond (for example, timing out due to being down or heavily loaded) but it can cause noticable delays for mail that does wind up getting retried due to delivery slots being congested. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Monday 20 June 2005 18:17, Pierre Habouzit [EMAIL PROTECTED] wrote: Do you have any evidence to support yout claim that big mail servers are configured to handle gray-listing servers differently from other mail servers? I do. I know personnaly some admins of big MX (not necessarily ISPs, french schools/universities in my case) that have a special rule for domain that they know practicing greylisting, and that *force* the delay to be of 30 to 60 minutes. and they increase that time if their queue is big Do you consider universities to have big mail servers? AFAIK universities tend to have less than 100,000 accounts with 30,000 being a fairly typical number. Medium sized at most. My experience from working at big ISPs is that queues can take 60 minutes to process because they have many tens of thousands of messages. A queue with more than 50,000 messages will take quite a while to process even if you have a 100baseT full-duplex connection to the Internet. well, greylisiting is done before any DATA is sent, and won't charge your connection that much. so the BW problem seems quite irrelevant. the latency will play a big role though. My point is that if you have 50,000 full sized messages in the queue it will take quite some time to go through the queue and be ready for a second pass. 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. In what situation will you have three such mail servers? redirections : my debian account redirects to an adress I have from my alumni that is a redirection address garanteed for life that redirects to my real account. I do that because my alumni provides me really good AV and AS services, and all my ingoing mail comes through it. So maybe 3 is a bit exagerated, but I think 2 is pretty common. Two such mail servers would only be common if mail was commonly sent to @debian.org addresses from big mail servers, and if redirecting Debian mail to similar big mail servers was also common. I doubt this. Also you were making claims about two or three multiples of the graylist delay. In your case at least that is false as you apparently don't plan to run such graylisting on your own machine. But redirection to a redirection service should be considered a bad idea. When mail doesn't arrive then it's another step in tracking down the problem, and it's another step that can possibly bounce spam to innocent third parties. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Monday 20 June 2005 18:20, Pierre Habouzit [EMAIL PROTECTED] wrote: I know that, but it does not (IMHO) justify the use of greylising for everybody by default. I prefer to receive spam (and I do a lot through my @debian.org address, despite the fact that it's quite recent) that is filtered by my personnal bogofilter quite well (even if not 100% accurate) than to have some QOS alteration. Bogofilter is something that we can't recommend to all users. Most people are not smart enough to use such filtering systems. When I talk to people about anti-spam measures most people who report using Bayesian systems tell me that they train the filter with all mail listed as spam!!! This indicates a total lack of understanding of how the Bayesian systems work. If it accidentally classifies a legit message as spam the last thing you want is to train the filter on that legit message and have it learn to stop other legit mail! Gray-listing is something that's difficult to screw up. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315051: ITP: newpki-lib -- PKI based on the OpenSSL low-level API (core library)
Package: wnpp Severity: wishlist Owner: Pierre Chifflier [EMAIL PROTECTED] * Package name: newpki-lib Version : 2.0.0beta4 Upstream Author : Frederic Giudicelli [EMAIL PROTECTED] * URL : http://www.newpki.org/ * License : GPL Description : PKI based on the OpenSSL low-level API (core library) Public Key Infrastructure (PKI) are designed to manage certificates on a long term. All the data are handled through a MySQL database, which provides a convenient frontend to OpenSSL, and options such as seeking a certificate with a search engine. . The actual version is able to handle multiple Certificate Authorities in one server, to publish a certificate request from a Certificate Signing Request, to certify a request, to revoke a certificate and to manage one or more Certificate Revocation Lists. It also able to search for the waiting requests or certificates, to respond to OCSP requests and to seek in and publish to LDAP Directory. . This package provides the core shared library. . Homepage: http://www.newpki.org/ Additional note concerning the license: the needed exemption for OpenSSL is present. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11ac7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: proficiency-level tag for debian packages
I think it's a great idea, but the criteria should be picked more conceptually, i.e. with respect to the level of learning curve. E.g. we could differentiate: GUI or interactive console users command line with necessary manual lookup for options highly customizable software (like emacs and most of server services) advanced with knowledge of debian-way doing things expert -- debian developer There's already some differentiation done somewhere in installer (where one selects the level/number of messages/question to be asked), reportbug utility. marius -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On 6/18/05, Michael K. Edwards [EMAIL PROTECTED] wrote: In any case, Ubuntu packages aren't Debian packages any more than Mandrake packages are Red Hat packages. If Ubuntu sees itself to Debian as Mandrake was to Red Hat, then that certainly explains a lot. If you want binary compatibility, you need to build a system whose engineering outcome is binary compatibility That's precisely what I'm proposing we should do here! There will never be a better time. -- 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 6/18/05, Matt Zimmerman [EMAIL PROTECTED] wrote: For open source software as a rule, the most important interface level is the source code. [...] [...] The cost of guaranteeing ABI compatibility is high, and the benefit to free software is marginal. It is a problem for proprietary software vendors to be concerned with, and we should leave it to them. We have more important work to do, and we're doing it in source code form. I don't know if you release this, but this is exactly what Red Hat says too. RHEL is free, because we provide the source code. Binaries aren't important to free software. Well, they're pretty damned important to Red Hat, to the tune of about $200 million per year (and growing at an impressive rate too). No wonder they don't want anyone else to think they're important. Surely you can see that there is quite a lot more to what we do than GNOME and X.org, both technologically and organizationally, and our release process is part of it. Sure, I've never disputed that. I'd argue, though, that your release process *was* part of it. Now that sarge is out, we have an opportunity to fix the problem at its source, rather than continuing to provide a workaround. Why not take advantage of that? If Ubuntu had somehow been constructed atop Woody, rather than unstable, consider how much more difficult it would have been for Ubuntu patches to be used in unstable. This would have been like forward-porting patches from Linux 2.2 to Linux 2.6. You're being dramatic again. I'm not suggesting Ubuntu should track a Debian stable that's released whenever it's ready. I'm saying Ubuntu should base on stable if and only if Debian can fix the release management problems. If, 12 or 18 months from today, Debian seems no closer to fixing these problems, Debian will deserve what it gets, and I'll be Ubuntu's biggest chearleader. In the meantime, let's give Debian a chance. That's all I'm saying. -- 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 6/18/05, Steve Langasek [EMAIL PROTECTED] wrote: Is Progeny interested in working with other Debian (+Ubuntu) folks to solve the fundamental limitations of the shlibs system that cause sarge and hoary to be incompatible due to a single-symbol difference, and that will cause similar breakage in the other direction with sarge and breezy? Am I willing to put my money where my mouth is? Absolutely. In fact, this could fit pretty well with some work Jeff Licquia is already doing to help Debian achieve LSB 2.0/3.0 compliance without breaking sarge compatibility: http://www.licquia.org/archives/2005/06/16/a-new-approach-to-the-lsb-part-2/ It doesn't really matter to me *how* we fix the compatibility problem, so long as we fix it. In fact, if we can find a way to fix it that makes it easier for the derivatives, so much the better--don't forget, I'm in that business too. ... going it alone, like when Matthias Klose ran his plans for the gcc 4 transition past the Debian release team before implementing it in Ubuntu, and is now proceeding to implement the same transition in Debian? Mea culpa. -- 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: Greylisting for @debian.org email, please
Pierre Habouzit [EMAIL PROTECTED] writes: I do. I know personnaly some admins of big MX (not necessarily ISPs, french schools/universities in my case) that have a special rule for domain that they know practicing greylisting, and that *force* the delay to be of 30 to 60 minutes. and they increase that time if their queue is big A novel, but not particularly clever use of greylisting. Those delays seem excessively big. From experience, there only needs to be one 4xx message, and a short delay. 5 minutes is common, a few seconds is sufficient. Todays spambots do not try again after the first 4xx. However, this _will_ change, if enough sites start to greylist. Spammers adapt. IMHO, rbls, SPF and others techniques that induce false positives have to be used upside down : use the rbls, SPF, ... to clean mail. that means, that a mail that is 100% correct wrt dnsRBLs, SPF records, ... can come in. any other mail, then, can go through evil treatments like greylisting. It's a way to select mails that are suspicious, and let them be delayed. With that, it's quite easy to avoid greylisting if you are a real ISP/MX/... : you only have to try to be removed from RBLs, or fix your domain wrt SPF if you use it and use it badly. I've written a little postfix POLICY daemon that does what I explained here. It's called whitelister, and it's in the repo. Though, it has not been (AFAIK) used in a big queue, but I plan to. These are sound ideas, and a piece of code is worth more than a thousand arguments. I'll give it a try. :D -- Stig Sandbeck Mathisen Linpro -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Sat, Jun 18, 2005 at 02:30:50PM -0700, Thomas Bushnell BSG wrote: Olaf van der Spek [EMAIL PROTECTED] writes: Is realtime a requirement for bug reporting? Since delays could be weeks from graylisting--or worse--yes. Uh, no. If properly configured, graylisting will not produce such delays. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
* Stig Sandbeck Mathisen [Mon, Jun 20, 2005 at 01:07:22PM +0200]: Pierre Habouzit [EMAIL PROTECTED] writes: I've written a little postfix POLICY daemon that does what I explained here. It's called whitelister, and it's in the repo. Though, it has not been (AFAIK) used in a big queue, but I plan to. These are sound ideas, and a piece of code is worth more than a thousand arguments. I'll give it a try. :D And if you're using exim4 together with greylistd you just need to add a dnslists line to the greylistd acl statement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Jun 20, Russell Coker [EMAIL PROTECTED] wrote: I guess that this doesn't have to be an @debian.org address. I've been considering removing my @debian.org address, the only things that go to it are debian-private (which I can hopefully get directed to another address) and spam. I requested this myself too in the past, since I never published the @debian.org address and never will, but the DSA were apparently not interested enough to implement a way to disable an address. Anyway, the major problem now are the @packages.debian.org addresses, I have ~20 of them and most days they account for 1/3 to 1/2 of all the spam I receive (and almost all of it could be blocked with the CBL). -- ciao, Marco signature.asc Description: Digital signature
graphic installation to debian
hi, i suggest a raphical insallation to debian, one is soon coming ro gentoo. Markus
Re: graphic installation to debian
Le lundi 20 juin 2005 à 14:59 +0300, Markus Åkerman a écrit : i suggest a raphical insallation to debian, one is soon coming ro gentoo. I'm eager to see your patches for bringing this. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Debian concordance
* Scott James Remnant | A definitive example would be the (eventually abandoned) attempt by | Ximian to provide debs for Helix GNOME. At the same time, I've never had a problem Opera debs provided by Opera Software. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Minutes of Debian Installer IRC meeting of 20050618
On Mon, Jun 20, 2005 at 01:37:55AM +0200, Marco d'Itri wrote: On Jun 19, Christian Perrier [EMAIL PROTECTED] wrote: It becomes obvious that maintaining the 2.4 compatibility may become harder and harder. This is however a key point if we want to keep the etch installer able to install sarge. Why? sarge as is supports 2.6 kernels up to 2.6.11. The sarge installer doesn't quite - 2.6.9 kernels and above need newer rootskel and base-config if you want the framebuffer to work properly on i386/amd64 systems. I'm sure there are other issues I don't know about. My first instinct for sarge d-i maintenance is to provide builds against newer 2.6.8 kernels supplied by the kernel team, with additional targetted fixes for known d-i bugs. This would all go in via proposed-updates, and debian-installer would build initrds from stable + stable-security + proposed-updates. It would not surprise me if people wanted 2.6.11 for improved SATA support; before committing to that, though, we'd need to know whether the stable RM would be willing to accept 2.6.11 kernel .debs into a point release of sarge. My strong inclination would be to provide this as an option (perhaps with special images in a different area of cdimage.debian.org), not as the default. As Marco notes, 2.6.12 would require a udev upgrade, and 2.6.13 requires the conversion of the installer and initrd-tools away from devfs (both of which are in progress for etch, but not yet finished), so support for new kernels in sarge starts to look increasingly unlikely after 2.6.11. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
On Mon, Jun 20, 2005 at 02:59:07PM +0300, Markus Åkerman wrote: i suggest a raphical insallation to debian, one is soon coming ro gentoo. The appropriate forum for discussing this is [EMAIL PROTECTED] Quite a bit of discussion about exactly how to implement this has already taken place there, along with a good deal of code. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming removal of orphaned packages
On Fri, 17 Jun 2005, Will Newton wrote: 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. The diff leads to smooth compilation of the C++ code but I have to admit that I have no idea what this code really does. On the other hand the perl code was acceptable fast for the job I was doing with it and it did it to my complete satisfaction. So perhaps I go for an upload of the original program and add a hint to the README.Debian for the C++ version. If there is nobody hwo would be really keen on taking this over himself, I'll go for an upload in the next couple of days. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On 6/19/05, Scott James Remnant [EMAIL PROTECTED] wrote: On Sun, 2005-06-19 at 11:42 -0400, Joey Hess wrote: Scott James Remnant wrote: Walking up to a man on the street, if anything, you'll find Debian has a far worse reputation than RPM and RedHat-derived distributions. The general feeling is that third-party RPMs will almost always install on any system, while third-party .debs are practically useless. That's strange, this is not the impression I've gotten from ten years of reading the debian-user mailing list, participating in Linux and Debian user groups, or hearing people discuss services such as backports.org and apt-get.org, or from using them myself. Try hanging out outside of the immediate Debian community; I spend a fair amount of time loitering around the GNOME and Freedesktop.org communities, for example. You see a wildly different picture there. I spend a fair amount of time with executives in technology companies, big and small. What they tell me is that they very badly want to support Debian but aren't quite sure how to do it. The demand is clearly there. The main problem, as they see it, is that they're not quite sure what Debian is. They'd like it to be Debian stable, but that hasn't been realistic up to now because Debian stable has been too old, and it's been impossible to know when the next one will be out. In that environment, the Ubuntu approach is reasonable. I guess the difference between your point of view and mine is that you seem to take it as a given that it has to be this way while I don't. It was impossible to create a single set of debs that would work on all three (stable, testing, unstable) distributions of Debian at the same time. That may be partially true (and it's not quite that dramatic--I've been mixing and matching for years without major problems). However, as I've said several times in this thread, to the vast majority of the world, Debian is Debian stable. Historically, people have used testing because of the lack of a predictable release cycle around stable, and Debian developers are the primary users of unstable. Also, as Joey has pointed out, all three of these distros are under a single umbrella, Debian, so transitions can be and are carefully coordinated. Fix the release problem, and lots of day-to-day users will stop using testing; the remainder will continue to use testing because they, well, want to help test it. Furthermore, for the most part, as has already been pointed out, packages built against stable tend to work on unstable just fine, particularly if there isn't a three year gap between releases. The other situations are bugs. As the comment that started this thread stated, packages built against glibc 2.3.2 run fine against glibc 2.3.5 but not vice versa, and this is mostly true when the upstreams are careful about compatibility. -- 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: Mozilla Foundation Trademarks
Eric Dorland writes: We may be their friends, but that shouldn't give us special privileges. If what we are doing does not actually infringe their trademark we would not be getting any special privileges. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Åkerman [EMAIL PROTECTED] wrote: hi, i suggest a raphical insallation to debian, one is soon coming ro gentoo. But *why*? I see little to no advantage over what we've currently got, fine for a desktop install, but what on earth do you want something firing up X for a simple server setup? Or even using framebuffer? How about we stick with something 'simple' that 'just works'? I'd rather have consistently easy installs than something that gets in the damned way and wants more dependencies than you can shake a large stick at. Thanks, - -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtsSxEh8oWxevnjQRApk2AJ4jukkQJ6+dtKe/6MAtY+xvPkbdHACfR70Z wME8ICaj7MIg8PimMH98hFw= =Rpmr -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
Matthew Garrett wrote: Lack of choice of venue imposes a burden on the licensor in case of litigation - I see no reason why one is obviously free and the other non-free. No, lack of choice of venue generally imposes a burden on the plaintiff, who may be either the licensor or the licensee. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Humberto Massa Guimarães wrote: Well said. IMHO, no. DFSG #8 -- witch is part of the SC, IIRC -- forbids us to have rights that our users don't have. No, it doesn't. It says: The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system. Very clearly, DFSG 8 states that you can not have a different set of rights in regard to FireFox when it is distributed as part of Debian vs. when it is not distributed as part of Debian. That's all. It does /not/ prohibit Debian the organization from having rights that other people don't. It is unreasonable to read it that way, because Debian will *always* have additional rights in some works, for example those which it is author or copyright holder of.
Re: graphic installation to debian
On Mon, Jun 20, 2005 at 02:59:07PM +0300, Markus Åkerman wrote: hi, i suggest a raphical insallation to debian, one is soon coming ro gentoo. This is being worked on, and might happen with etch. Note, however, that it's never a good idea to just go and suggest something to an open source project; actually doing the work is far more likely to achieve something. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
On Mon, Jun 20, 2005 at 02:59:07PM +0300, Markus Åkerman wrote: i suggest a raphical insallation to debian, one is soon coming ro gentoo. What does gentoo show you while it compiles your base system all weekend? WebCollage porn perhaps.. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On 18-Jun-05, 17:24 (CDT), Thomas Bushnell BSG [EMAIL PROTECTED] wrote: An email address with such blocking on it is therefore not suitable for the Maintainer: field of a Debian package. Any spam filtering system is going to have *some* false positives. Are you claiming that if I do *any* spam filtering on the address listed in my packages, it is not suitable? Regards, 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: graphic installation to debian
On Mon, Jun 20, 2005 at 02:29:21PM +0100, Brett Parker wrote: Markus Åkerman [EMAIL PROTECTED] wrote: i suggest a raphical insallation to debian, one is soon coming ro gentoo. But *why*? I see little to no advantage over what we've currently got, fine for a desktop install, but what on earth do you want something firing up X for a simple server setup? A graphical version of d-i will be optional. Or even using framebuffer? Note that the current installer already uses a framebuffer, in order to provide decent rendering of text in languages that aren't just ASCII. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
On Mon, 20 Jun 2005, Brett Parker wrote: But *why*? Indian languages have conjunct, variable-length characters so it is impossible to display them properly on the console. So some kind of graphical solution is our only choice if we want to support about 1.7 billion people. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
Quoting Wouter Verhelst ([EMAIL PROTECTED]): On Mon, Jun 20, 2005 at 02:59:07PM +0300, Markus Åkerman wrote: hi, i suggest a raphical insallation to debian, one is soon coming ro gentoo. This is being worked on, and might happen with etch. Note, however, that it's never a good idea to just go and suggest something to an open source project; actually doing the work is far more likely to achieve something. And explaining why one thinks that a graphical installer adds value also helps..:-). Fortunately, it actually *adds* value (I have a few examples coming to my mind, the rendering of several non Latin languages being one of them : RTL support for Hebrew/Arabic is based on (nice) hacks and all languages from India cannot seriously be rendered with a non graphical environment) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Watson [EMAIL PROTECTED] wrote: On Mon, Jun 20, 2005 at 02:29:21PM +0100, Brett Parker wrote: Markus Åkerman [EMAIL PROTECTED] wrote: i suggest a raphical insallation to debian, one is soon coming ro gentoo. But *why*? I see little to no advantage over what we've currently got, fine for a desktop install, but what on earth do you want something firing up X for a simple server setup? A graphical version of d-i will be optional. Ah, that's alright then :) Or even using framebuffer? Note that the current installer already uses a framebuffer, in order to provide decent rendering of text in languages that aren't just ASCII. I did really know that, but we're not really using all the features that the framebuffer really has to offer, are we? It's still ncurses based and just works (tm). Thanks, - -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCttFiEh8oWxevnjQRAp2kAJ46ITnkTfPril6ZkVsORihxFT2HegCfVtOs zsAJR8ItFbU7XOLliurKyz8= =oWbQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jaldhar H. Vyas [EMAIL PROTECTED] wrote: On Mon, 20 Jun 2005, Brett Parker wrote: But *why*? Indian languages have conjunct, variable-length characters so it is impossible to display them properly on the console. So some kind of graphical solution is our only choice if we want to support about 1.7 billion people. Ahhh, thanks, didn't realise that. I thought that there were console fonts available that covered it. Thanks, - -- Brett Parker web: http://www.sommitrealweird.co.uk/ email: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCttGREh8oWxevnjQRAkWiAJ9SlePpoj5dHLdu0oxS/Xn18VMAFwCdE3rK a3iAEIiGyAUIpLK3EVwubgo= =OCo/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
On Mon, 20 Jun 2005, Brett Parker wrote: Ahhh, thanks, didn't realise that. I thought that there were console fonts available that covered it. The one such effort I've seen required a huge and hackish kernel patch and still looked like crap. GTK and Qt on the other hand have a few minor display problems but are steadily improving and are quite usable. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
I perfer a installer where have gcc onboard, so you can compile the modules where not included. Booting afterwards the compiled kernel in a uml system and install from this debian. That is a smoth thing with today have only gentoo. Ryven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315098: ITP: newpki-client -- PKI based on the OpenSSL low-level API (client package)
Package: wnpp Severity: wishlist Owner: Pierre Chifflier [EMAIL PROTECTED] * Package name: newpki-client Version : 2.0.0beta4 Upstream Author : Frederic Giudicelli [EMAIL PROTECTED] * URL : http://www.newpki.org/ * License : GPL Description : PKI based on the OpenSSL low-level API (client package) Public Key Infrastructure (PKI) are designed to manage certificates on a long term. All the data are handled through a MySQL database, which provides a convenient frontend to OpenSSL, and options such as seeking a certificate with a search engine. . The actual version is able to handle multiple Certificate Authorities in one server, to publish a certificate request from a Certificate Signing Request, to certify a request, to revoke a certificate and to manage one or more Certificate Revocation Lists. It also able to search for the waiting requests or certificates, to respond to OCSP requests and to seek in and publish to LDAP Directory. . This package provides a graphical client for NewPKI, written in C++ with using the wxWidgets (http://www.wxwidgets.org) cross-platform framework to allow it to run on multiple platforms. . Homepage: http://www.newpki.org/ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11ac7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
** Anthony DeRobertis :: Humberto Massa Guimarães wrote: Well said. IMHO, no. DFSG #8 -- witch is part of the SC, IIRC -- forbids us to have rights that our users don't have. No, it doesn't. It says: The rights attached to the program must not depend on the program's being part of a Debian system. If the program is extracted from Debian and used or distributed without Debian but otherwise within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the Debian system. This is exactly what I was talking about: if you consider their trademark policy (for everybody else) combined with their license for Debian to use their trademark, you do have rights attached to the program (the presence of MF's trademarks, most visibly in the caption of the main window and in the names of both the package and the main executable AFAIK (*)) that depend on the program's being part of Debian. And that's it. The only copies of Firefox that do not infringe on this particular DFSG clause are those which are absolutely clean of MF's trademarks. Very clearly, DFSG 8 states that you can not have a different set of rights in regard to FireFox when it is distributed as part of Debian vs. when it is not distributed as part of Debian. That's all. And this is my problem with the inclusion of MF's trademark usage in our package: the right to include such trademark *is* attached to the program (after all, it's the original name of the program (**)); it's a right that *must* *not* *depend* on the program's being part of a Debian system. One *must* be capable of extracting the program from Debian and use it, or distribute it, without debian, but otherwise within the terms of the program's license -- which obviously (at least IMHO) includes the license to the trademarks originally included in the program. It does /not/ prohibit Debian the organization from having rights that other people don't. It is unreasonable to read it that way, because Debian will *always* have additional rights in some works, for example those which it is author or copyright holder of. You are 100% right. But this is irrelevant, because you ignored the context of my phrase. The relevant (contextualized) meaning of my phrase above is: premise 1 = DFSG #8 classifies as non-free software that has *any* rights attached to it that depends on the software be distributed in Debian. premise 2 = Mozilla Foundation Firefox trademark, which is present to be displayed in the usage of the firefox browser as it comes originally, has a restrictive license that either (a) forbids it to be used by Debian or (b) allows it to be used by Debian and Debian only, according to our acceptance or not of their offer of exclusive trademark licensing. conclusion = non-rebranded Firefox is not Free Software as per the DFSG. This is a fairly simple conclusion, and no historically the DFSG was made thinking about copyrights only argument contradicts what is precisely stated there. Even taking the DFSG #4 concession, what is being asked from the MF is not a rename of the program (in which case the version in Debian could be called firefox-debianized or somesuch), but a complete purge of the trademark from the visible part of the program (including menu items, etc), which goes IMHO clearly beyond the DFSG #4 exception. (*) I don't even know if US trademark law allows them to go that far; I could NOT find in Brazilian trademark law any references to anything as deep as that. Basically, the only references that I found in BR case law were to *advertising* and *misrepresenting* something as being from the wrong origin. Anyway, the situation that we have here is: we are modifying Civics and putting different accessories and tuning the engine. We are not obliged to sell our Civics under any other name (maybe in the interest of full disclosure we should state to the next buyer that the car is modified and tuned, IRT the original Civics, and our Consumer Defense Act even makes us give some warranty on the services we made on the vehicle). The Civic is a Civic and any non-forking, non-backdooring, derivative of Firefox is still Firefox, without any trademark being violated IMHO. IANAL, TINLA, and I am not quite familiarized with the Brazilian Industrial Property Act (which regulates trademarks and patents, and gives some instructions about trade/industrial secrets), as opposed to Brazilian copyright statutes and case law, which I am quite familiar with, having worked in some cases while I was a paralegal in a DA's office, criminally prosecuting alledged copyright infringers. (**) as opposed to other trademarks that also cannot be used in the program. An example: I cannot take a modified firefox and call it The Coca-Cola Browser, as I cannot take modified k3b and re-brand it The Coca-Cola CD Burner. Does this fact make those programs non-free? NO. Because the
Re: Greylisting for @debian.org email, please
On Mon, 20 Jun 2005, Steve Greenland wrote: On 18-Jun-05, 17:24 (CDT), Thomas Bushnell BSG [EMAIL PROTECTED] wrote: An email address with such blocking on it is therefore not suitable for the Maintainer: field of a Debian package. Any spam filtering system is going to have *some* false positives. Indeed. Are you claiming that if I do *any* spam filtering on the address listed in my packages, it is not suitable? I wonder the same. Apparently, receiving tons of spam is not our only duty as package maintainers, it seems we are also forced to *read* it to be good maintainers... Thomas: If you send me a message which is spammy in nature (for whatever definition my bayesian filter has of spammy) and it's stored in my spam folder, it is very likely that I will not read it, and you will never know that the message landed in my spam folder. At least using a good DNSBL like the CBL would clearly tell the sender (if it's a human) that the message will not be read, since the message is rejected at SMTP stage. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Russell Coker [EMAIL PROTECTED] writes: You could help by listing the anti-spam measures that you consider to be acceptable. Rejecting every suggestion for an improvement is not helpful. I am ok with anti-spam measures which enable a well-behaving false positive sender to know they have run afoul, and in which the maintainers of the mechanism promise to try and adjust the system so that the false-positive in question doesn't recur, taking responsibility for false positives. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
On Sun, Jun 19, 2005 at 04:15:08AM +0300, Lars Wirzenius wrote: Frank Lichtenheld and others have brought up the idea of automatically testing installation, upgrading, and removal of packages. It struck me that it should be pretty simple to implement at least basic versions of this. The result: http://liw.iki.fi/liw/download/piuparts-0.4.tar.gz I have attached the manual page. The current version is quite simplistic. It may well be too simplistic to work for more than in simple cases, but it's a start. I'd be very curious to hear about suggestions for improvements. how about an optional debian/package.piuparts file that would contain the syntax to make runtime tests? this would allow to check that executables can be run, and possibly that their result is consistent. it could even be used to detect memory leaks. a few (badly written) examples: debian/bc.piuparts -- expr `echo 3^3 | bc -l` = 27 echo $? debian/evince.piuparts -- /usr/bin/evince echo $? kill %? debian/supercollider.piuparts: -- /usr/bin/sclang /dev/null echo $? JACK_START_SERVER=1 /usr/bin/scsynth echo $? kill %? bye, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Wouter Verhelst [EMAIL PROTECTED] writes: On Sat, Jun 18, 2005 at 02:30:50PM -0700, Thomas Bushnell BSG wrote: Olaf van der Spek [EMAIL PROTECTED] writes: Is realtime a requirement for bug reporting? Since delays could be weeks from graylisting--or worse--yes. Uh, no. If properly configured, graylisting will not produce such delays. If I have an email farm of dozens of servers, so that each time the message is sent, it comes from a different server, graylisting can take an extremely long time. Since you do not have a complete list of every mail server that does this, you cannot avoid the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Steve Greenland [EMAIL PROTECTED] writes: On 18-Jun-05, 17:24 (CDT), Thomas Bushnell BSG [EMAIL PROTECTED] wrote: An email address with such blocking on it is therefore not suitable for the Maintainer: field of a Debian package. Any spam filtering system is going to have *some* false positives. Are you claiming that if I do *any* spam filtering on the address listed in my packages, it is not suitable? I'm saying you must make sure you can get bug reports from users. For example, if you occasionally filter a message, but in such a way that the user can tell that they have been filtered, and in such a way that it isn't going to be every message from them which gets filtered, then the user can send a second message saying, hey, my email got filtered! which you will receive. If you then spend the time to figure out *why* their email got filtered, and fix it so that they can send the original message and others like it, then I'm fine with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla Foundation Trademarks
* John Hasler ([EMAIL PROTECTED]) wrote: Eric Dorland writes: We may be their friends, but that shouldn't give us special privileges. If what we are doing does not actually infringe their trademark we would not be getting any special privileges. What we are doing already is against their trademark policy. We're being offered an agreement specific to Debian to bypass that. I would call that special privileges. -- 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: Orphaning packages
On Sat, Jun 18, 2005 at 11:08:28PM +0200, Ivo Timmermans wrote: Hi, I'm orphaning these packages: alsaplayer (bug #314841) i will be interested in maintaining this one. i will propose comaintainance on the bts entry. cheers, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
Christian Perrier wrote: Quoting Wouter Verhelst ([EMAIL PROTECTED]): Note, however, that it's never a good idea to just go and suggest something to an open source project; actually doing the work is far more likely to achieve something. And explaining why one thinks that a graphical installer adds value also helps..:-). A GUI can have better usability. E.g. some beginners don't know, how to mark an item in a list for selection in the current installer. O.k., 'use spacebar to select' would avoid confusion. But with GUIs and mouse it would be more intuitive for desktop users. IMHO both is necessary: - improve usability and docs of the non-GUI version - have a GUI version At least I assume to have it choosable, as I (and other purists too) prefer non-GUI on servers and old hardware. Helmut Wollmersdorfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315104: ITP: schroot -- Execute commands in a chroot environment
Package: wnpp Severity: wishlist Owner: Roger Leigh [EMAIL PROTECTED] * Package name: schroot Version : 0.1.0 Upstream Author : Roger Leigh [EMAIL PROTECTED] * URL : http://people.debian.org/~rleigh/schroot/ * License : GPL Description : Execute commands in a chroot environment schroot allows users to execute commands or interactive shells in different chroots. Any number of named chroots may be created, and access permissions given to each, including root access for normal users, on a per-group basis. Additionally, schroot can switch to a different user in the chroot, using PAM for authentication and authorisation. All operations are logged for security. . schroot shares most of its options with dchroot, but offers vastly more functionality. The above URL is temporary. It should shortly be moved from a local Arch repository to buildd-tools CVS on Alioth. sbuild will use it in the future to allow a true-chroot mode for apt-get/dpkg. Regards, Roger -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
Humberto Massa Guimarães writes: (*) I don't even know if US trademark law allows them to go that far... The notion that we would be infringing their trademark by failing to remove strings that they put in is ludicrous. It's equivalent to Ford demanding that I remove all the Ford logos before selling my truck. Basically, the only references that I found in BR case law were to *advertising* and *misrepresenting* something as being from the wrong origin. Same in the US. -- John Hasler (IANAL) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla Foundation Trademarks
I wrote: If what we are doing does not actually infringe their trademark we would not be getting any special privileges. Eric Dorland writes: What we are doing already is against their trademark policy. We're being offered an agreement specific to Debian to bypass that. I would call that special privileges. If their policy is not legally enforceable our users have all the rights we have whether we accept the agreement of not. -- John Hasler (IANAL) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: setting umask globally
On Fri, 2005-06-17 at 00:33 +0200, Santiago Vila wrote: On Fri, 17 Jun 2005, martin f krafft wrote: If one is faced with the task to set the umask globally for all users and shells, this turns out to be a job of redundancy: every shell uses its own file in /etc, and you end up making changes to 5 files or more (depending on the number of installed shells). What's worse: change the umask and you'll possibly forget one shell or the other, which may cause delays in your user's work, or even break things (yeah, you should not rely on umask; yeah, don't tell me...) [ snipped gigantic hack ] So the plan is: 1. gather comments. 2. file a bug against base-files to have the files included. 3. once base-files hits unstable, mass-file bugs against all compatible shells and ask them to use it. 4. rejoice. So, let's start at (1)... This is Unix, and we are system integrators. Our job is to make things simpler, not more complex. I wonder why people always consider base-files as the package of choice to implement all sorts of ugly global hacks. There is already an umask setting in /etc/login.defs. If it makes people happy, I will happily drop the umask setting from /etc/profile, so that people do not have to decide between login.defs and profile when trying to set an umask globally. Then we could make policy (or just convince the shell maintainers) that shells should not set umask in their default global initialization scripts, so that they do not override the one in /etc/login.defs. pam umask should be used ... though this was adde to debian without much integration. The setting in /etc/login.defs should be move to the end of this file (settings obsolete by pam) and all /etc/pam.d files upgraded. Do libpam-umask ought to be base ? And the setting removed from all shell/cron/X who knows specific configuration file. Thanks again Tollef for the great libpam-umask . I cannot wait for when some fellow manages to make a libpam-path (which deal with a separate path for root and users, maybe for su, ssh , cron too) ... it is time to get rid of /etc/login.defs and hacks to work around it (especially su, ssh and X login managers ). Tese kind of small extensions does more for us administrators to get a get a real life, children , etc than big g4c, yast ... :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: setting umask globally
also sprach Alban Browaeys [EMAIL PROTECTED] [2005.06.20.1911 +0200]: pam umask should be used ... though this was adde to debian without much integration. The setting in /etc/login.defs should be move to the end of this file (settings obsolete by pam) and all /etc/pam.d files upgraded. Do libpam-umask ought to be base ? The discussion is here: http://bugs.debian.org/314539 -- 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! consciousness: that annoying time between naps. signature.asc Description: Digital signature
Re: graphic installation to debian
Quoting Helmut Wollmersdorfer ([EMAIL PROTECTED]): A GUI can have better usability. E.g. some beginners don't know, how to mark an item in a list for selection in the current installer. O.k., Right. This has been reported quite often (actually more in tasksel than the installer itself, though, because tasksel is the only place you have a multiselect template in a default install) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: setting umask globally
Quoting martin f krafft ([EMAIL PROTECTED]): Do libpam-umask ought to be base ? The discussion is here: http://bugs.debian.org/314539 And enforcing the use of libpam-umask is actually the direction we're taking.. First step probably : comment UMASK in login.defs in answer to #314539. Then probably discuss with the PAM maintainers and try having libpam-umask used by default (with sane defaults of course). Tollef is OK to improve it in areas it needs to be improved (user-level configuration and so on...).) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
Quoting Otavio Salvador ([EMAIL PROTECTED]): Maybe we should change debconf to display a message when we hve multiselect templates explain how the user should do to mark an iten and how to continue. This has been discussed, yep. Just like a possible Help button, but we're quite stuck with the various interfaces (text, dialog, gnome...) used by debonf. Someprobably do not easily allow this, particularly dialog, based on newt, which is the default ATM in the second stage. But, of course, improvements will be welcome..:) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On Mon, Jun 20, 2005 at 05:44:33AM -0500, Ian Murdock wrote: I don't know if you release this, but this is exactly what Red Hat says too. RHEL is free, because we provide the source code. Binaries aren't important to free software. Well, they're pretty damned important to Red Hat, to the tune of about $200 million per year (and growing at an impressive rate too). No wonder they don't want anyone else to think they're important. As I explained when Joey made this same interpretation, I obviously don't believe that binaries are unimportant. Binaries are the most important transport format for getting software into the hands of users. However, they aren't a very useful tool for software development collaboration, and work to make binaries more universal does not promote the development of open source software. Sure, I've never disputed that. I'd argue, though, that your release process *was* part of it. Now that sarge is out, we have an opportunity to fix the problem at its source, rather than continuing to provide a workaround. Why not take advantage of that? Debian and Ubuntu already are taking advantage of the space created by the Sarge release, by coordinating major transitions, and feeding more Ubuntu features and packages into Debian. But if what you're suggesting is that the Sarge release means that Ubuntu should stop making its own releases based on unstable, that doesn't make sense for our developers or our users. You seem to believe that Ubuntu's approach to releasing was a one-time workaround for a delayed Sarge release, but that has never been the case. Ubuntu 5.10 will be released in October of this year, based on the breezy development tree, regardless of any pending discussions about Debian's release strategy. You're being dramatic again. I'm not suggesting Ubuntu should track a Debian stable that's released whenever it's ready. I'm saying Ubuntu should base on stable if and only if Debian can fix the release management problems. If, 12 or 18 months from today, Debian seems no closer to fixing these problems, Debian will deserve what it gets, and I'll be Ubuntu's biggest chearleader. In this case, your suggestion is entirely hypothetical, and we'll discuss this when there's something concrete to discuss. The world could be a very different place in 12 or 18 months, and we aren't going to plan the next 2-3 Ubuntu releases based on an oversimplified proposal to improve Debian's release cycle. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphic installation to debian
Christian Perrier [EMAIL PROTECTED] writes: Quoting Helmut Wollmersdorfer ([EMAIL PROTECTED]): A GUI can have better usability. E.g. some beginners don't know, how to mark an item in a list for selection in the current installer. O.k., Right. This has been reported quite often (actually more in tasksel than the installer itself, though, because tasksel is the only place you have a multiselect template in a default install) Maybe we should change debconf to display a message when we hve multiselect templates explain how the user should do to mark an iten and how to continue. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian concordance
On 6/20/05, Ian Murdock [EMAIL PROTECTED] wrote: On 6/18/05, Michael K. Edwards [EMAIL PROTECTED] wrote: In any case, Ubuntu packages aren't Debian packages any more than Mandrake packages are Red Hat packages. If Ubuntu sees itself to Debian as Mandrake was to Red Hat, then that certainly explains a lot. Well, I haven't used Mandrake in a while, and if there's bad blood there that I don't know about then it's probably a bad analogy. (And remember, I have no affiliation with Ubuntu either.) All I'm saying is that, unlike a CDD or a Debian-pony-with-one-extra-trick (Knoppix, etc.), Ubuntu is a full distro which tracks Debian at the source code level rather than using Debian binary packages. This has consequences for ISVs not unlike those of the early Mandrake releases, when Mandrake tracked Red Hat's code and releases but optimized for Pentium and wrote an alternate installer. If you wanted your third-party application to run on both, you couldn't just sort of pretend you were part of the Red Hat release cycle; you needed to concoct a build environment whose products were distro-agnostic. Choice is good; but choice doesn't always make things easier. If you want binary compatibility, you need to build a system whose engineering outcome is binary compatibility That's precisely what I'm proposing we should do here! There will never be a better time. Building that system doesn't mean cajoling Ubuntu into holding breezy back. It means (as I see it) constructing an apt repository and a debootstrap recipe for Debian Standard Base 05.03 and 05.09 -- build environments for sarge+hoary+breezy+etch-compatible binary debs and breezy+etch-compatible debs respectively. Presumably packages built in 05.03 won't be able to use ABI fixes, etc. introduced at the last minute in sarge and/or hoary, and anything that we can already tell won't run on breezy or etch should also be excluded. If that leaves a build environment that won't build much other than C programs with few library dependencies, maybe we should think about formalizing more backwards compatibility mechanisms in breezy/etch. If, that is, we care about ISVs and other poor sods who don't want their application upgrade cycle dictated by their O/S upgrade cycle (and vice versa). Cheers, - Michael
Re: relocation error(s) with various binaries
On Thu, 2005-06-16 at 12:27 -0400, Chris Gorman wrote: Have you reinstalled with : apt-get install --reinstall package ? else does : # rm ld.so.cache # ldconfig helps ? You could also try : ldconfig -vv to see if errors shows up. Cheers Alban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Mon, Jun 20, 2005 at 08:48:05AM -0700, Thomas Bushnell BSG wrote: Wouter Verhelst [EMAIL PROTECTED] writes: On Sat, Jun 18, 2005 at 02:30:50PM -0700, Thomas Bushnell BSG wrote: Since delays could be weeks from graylisting--or worse--yes. Uh, no. If properly configured, graylisting will not produce such delays. If I have an email farm of dozens of servers, so that each time the message is sent, it comes from a different server, graylisting can take an extremely long time. Since you do not have a complete list of every mail server that does this, you cannot avoid the problem. The number of email domain that needs such a setup is rather small (probably only the hotmails, and AOLs of this world), so you could make an educated guess. That being said, even if you couldn't do that, there still are ways to avoid the problem: e.g., do graylisting based on the /24 of the sending host, rather than on the /32, and make the delay only valid for five minutes rather than an entire hour. This might still make the delay be quite some time, but it shouldn't take /weeks/, at any rate. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
I demand that Florian Weimer may or may not have written... * Olaf van der Spek: You should set the clock using NTP *before* starting any daemons. Most daemons don't use monotonic clocks (I'm not even sure if Linux supports them at the required level), and some of them fail in strange ways if the system clock warps. Doesn't Linux or NTP support gradually changing the clock exactly to avoid such warps? Gradually skewing the clock doesn't exactly work that well if the offset exceeds a few minutes. You don't want to run with a wrong clock for hours or even days. Maybe ntp, ntpdate etc. should recommend adjtimex? -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | Let's keep the pound sterling You will be travelling and coming into a fortune. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
Wouter Verhelst [EMAIL PROTECTED] writes: That being said, even if you couldn't do that, there still are ways to avoid the problem: e.g., do graylisting based on the /24 of the sending host, rather than on the /32, and make the delay only valid for five minutes rather than an entire hour. This might still make the delay be quite some time, but it shouldn't take /weeks/, at any rate. This assumes that my email hosting is all on one subnet, doesn't it. Whoops, that might not be right. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
red hot hussy doxy feels good swallowing all his little tadpoles.
Buenos noches! Damn does Alice have a fine white body or what? This bitch came in with that tight ass and she knew she was gonna get it torn up good and hard! That large prick barely fit in her tight anal crevice! Jasmine little white bitch has grown up with a rich daddy! =)) http://www.geocities.com/jenny_227morales_511/?s=srtm=gfibjW-gfOfY.YbRQR,gfibjW,VSd He is a modest little man who has a good deal to be modest about.Love is everything. It is the key to life, and its influences are those that move the world. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
Hi, I think this can not quite do it, since the chroot will need to be a woody chroot but get at least partially upgraded in each test to allow installation of the sarge and sid packages. It looks like piuparts is otherwise close to the tool I need. Create a lvm logical volume of a clean chroot. Make a snapshot of it, mount proc, do the test, kill (and probably report) any residual processes, umopunt proc, kill snapshot. Using lvm is the fastest way to do this. Alternatives are to copy or untar a clean chroot for every test. But that needs more time. I've not yet come around to testing it; lvm2 is supposed to be very much improved with read/write snapshots. (compared to lvm1 which only had read-only snapshots. Correct me if I'm wrong) How is your experience ? Is it stable enough? regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
On Tue, 21 Jun 2005, Junichi Uekawa wrote: Hi, I think this can not quite do it, since the chroot will need to be a woody chroot but get at least partially upgraded in each test to allow installation of the sarge and sid packages. It looks like piuparts is otherwise close to the tool I need. Create a lvm logical volume of a clean chroot. Make a snapshot of it, mount proc, do the test, kill (and probably report) any residual processes, umopunt proc, kill snapshot. Using lvm is the fastest way to do this. Alternatives are to copy or untar a clean chroot for every test. But that needs more time. Additionally use xen/uml to run the chroot; no pollution of host at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
Junichi Uekawa [EMAIL PROTECTED] writes: Hi, I think this can not quite do it, since the chroot will need to be a woody chroot but get at least partially upgraded in each test to allow installation of the sarge and sid packages. It looks like piuparts is otherwise close to the tool I need. Create a lvm logical volume of a clean chroot. Make a snapshot of it, mount proc, do the test, kill (and probably report) any residual processes, umopunt proc, kill snapshot. Using lvm is the fastest way to do this. Alternatives are to copy or untar a clean chroot for every test. But that needs more time. I've not yet come around to testing it; lvm2 is supposed to be very much improved with read/write snapshots. (compared to lvm1 which only had read-only snapshots. Correct me if I'm wrong) How is your experience ? Is it stable enough? Works fine for me. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Mon, Jun 20, 2005 at 02:03:34PM -0700, Thomas Bushnell BSG wrote: Wouter Verhelst [EMAIL PROTECTED] writes: That being said, even if you couldn't do that, there still are ways to avoid the problem: e.g., do graylisting based on the /24 of the sending host, rather than on the /32, and make the delay only valid for five minutes rather than an entire hour. This might still make the delay be quite some time, but it shouldn't take /weeks/, at any rate. This assumes that my email hosting is all on one subnet, doesn't it. No. Whoops, that might not be right. It most likely isn't. However, if you have dozens and dozens of mailservers and set them up so that the mail would come from one mailserver on the first try and another one on the next try, then I think it's safe to assume your dozens and dozens of mailservers are set up in the same data center -- or, at least, grouped over a rather small number of data centers (at least as compared to the number of mailservers you're running), because you don't want to be continuously bouncing your mail from Tokio to London to New York and back again. If you do, I wouldn't want to be paying your bandwidth. As such, I suspect that even if mail won't originate from the same /24 all the time, chances are pretty high they will for a rather large portion of the attempts. And in the rare (or not) occasion that they don't, I still suggested using a 5 minute timeout rather than a 1h one, which will alleviate the problem even more. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for @debian.org email, please
On Mon, Jun 20, 2005 at 05:58:11PM +1000, Russell Coker wrote: Rejecting every suggestion for an improvement is not helpful. Yes, it is, if every suggestion for improvement is a poor one. Lack of good ideas does not justify bad ones; not having any good ideas does not invalidate or in any way reduce the value of pointing out the bad ones. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
Darren Salt wrote: I demand that Florian Weimer may or may not have written... Gradually skewing the clock doesn't exactly work that well if the offset exceeds a few minutes. You don't want to run with a wrong clock for hours or even days. Maybe ntp, ntpdate etc. should recommend adjtimex? If, then only ntpdate + adjtimex is a good combination. ntp has its own sophisticated logic if skewing, but does not correct offsets 500 sec (AFAIK). Having your BIOS clock at local time (e.g. UTC+1), then installing Linux with configuration system clock = UTC, will remain a falseticker. Even offsets of some minutes need a long time to be corrected by ntp. Chrony can correct hours very fast. Helmut Wollmersdorfer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Greylisting for at debian.org email, please
Pierre Habouzit madcoder at debian.org writes: 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 at 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, and I really hope this would never be used as a default rule for email filtering. I'd prefer to see some tools like dspam/bogofilter/... used instead of the heavy and not efficient enought SA. I've found that a combination of: * RBLs that dont suck - dsbl - sbl-xbl * URI-based filtering URIBL * dspam has worked *very* well for me. Even if you don't really want the spamhaus list, look into using the dsbl. It mostly consists of the worst configured hosts out there -- ones where someone was able to fool it to list itself on the list. I also echo that greylisting is a real pain. Thanks, -- Scott Dier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: TODO for etch ?
On Mon, Jun 20, 2005 at 07:22:08PM +0100, Darren Salt wrote: I demand that Florian Weimer may or may not have written... * Olaf van der Spek: You should set the clock using NTP *before* starting any daemons. Most daemons don't use monotonic clocks (I'm not even sure if Linux supports them at the required level), and some of them fail in strange ways if the system clock warps. Doesn't Linux or NTP support gradually changing the clock exactly to avoid such warps? Gradually skewing the clock doesn't exactly work that well if the offset exceeds a few minutes. You don't want to run with a wrong clock for hours or even days. Maybe ntp, ntpdate etc. should recommend adjtimex? adjtimex is pretty near useless and should not be used. It can make things worse rather than better, especially with the clocks in modern boxes (which are grossly inaccurate). Under *no circumstances* should adjtimex be used at the same time as ntpd. The clock will jitter all over the place because they won't agree and will keep slewing it in opposition to each other. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: TODO for etch ?
On Tue, Jun 21, 2005 at 02:48:14AM +0200, Helmut Wollmersdorfer wrote: Darren Salt wrote: I demand that Florian Weimer may or may not have written... Gradually skewing the clock doesn't exactly work that well if the offset exceeds a few minutes. You don't want to run with a wrong clock for hours or even days. Maybe ntp, ntpdate etc. should recommend adjtimex? ntp has its own sophisticated logic if skewing, but does not correct offsets 500 sec (AFAIK). Having your BIOS clock at local time (e.g. UTC+1), then installing Linux with configuration system clock = UTC, will remain a falseticker. Even offsets of some minutes need a long time to be corrected by ntp. That's not really true, it's just the default configuration. Actually the default configuration in Debian is pretty sucky. It assumes that ntp is used in combination with ntpdate - but ntp upstream is of the considered opinion that this is a bad plan. Nowadays, I always change it to add the -g option to ntpd (disabling the 1000s limit) and the iburst option to the config file (causes ntpd to sync up in seconds when it starts up, instead of hours, before entering normal operation). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: relocation error(s) with various binaries
Ok, I've solved this for my system. I removed X and all associated libraries and started with a system without /usr/X11R6. Then I reinstalled from stable and I have a system working without the errors mentioned below. If I get brave in the next little while I'll try sid, but I need a working system ATM, so it won't be too soon. Thanks to all those who made suggestions. Chris On Thu, 16 Jun 2005, Chris Gorman wrote: On Thu, 16 Jun 2005, Peter Samuelson wrote: [Chris Gorman] + exec /usr/lib/mozilla-firefox/firefox-bin -a firefox /usr/lib/mozilla-firefox/firefox-bin: relocation error: /usr/lib/libXrender.so.1: undefined symbol: _Xglobal_lock Try reinstalling libx11-6. Done. It was one of the ones I reinstalled already, but I tried it again. Unfortunatly the errors persist. Verify that it has the symbol in question: nm --dynamic /usr/X11R6/lib/libX11.so.6 | grep _Xglobal_lock Reveals.. 000c6910 B _Xglobal_lock should reveal it as a B symbol (uninitialised data). I've also tried reinstalling all of mozilla in the event that it had become corrupt. This also didn't resolve the problems. :( Any other suggestions? (I'm thinking about removing all of X and starting over with it.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
* John Hasler ([EMAIL PROTECTED]) wrote: Humberto Massa Guimarães writes: (*) I don't even know if US trademark law allows them to go that far... The notion that we would be infringing their trademark by failing to remove strings that they put in is ludicrous. It's equivalent to Ford demanding that I remove all the Ford logos before selling my truck. Your analogy is flawed. My ford is still a ford if however I try to pass off my completely rebuilt car and tried to pass it off as ford. Basically, the only references that I found in BR case law were to *advertising* and *misrepresenting* something as being from the wrong origin. Same in the US. -- 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: namespace conflict != package Conflict?
Anthony Towns wrote: GNU Interactive Tools hasn't seen an upstream update at all since 2001, and looking at the diffs since .18, doesn't seem to have had any significant changes since 1999. The Debian updates seem mostly to be updating the build system, rather than user-visible changes. I am not sure upstream inactivity by itself is a good measure. For example compare this to GNU rcs. GNU rcs has not had an upstream modification since 1995. I would hate to see this argument applied there that we should remove or rename RCS commands. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
raidtools2 - mdadm change: woes and problems
Hi, The recent change from raidtools2 to mdadm left me out in the cold. Previous package had commands like lsraid, raidhotadd, etc and used the /etc/raiddtab. Since the raidtools2 was removed, the mdadm was never fully configured. There is no mdadm.conf for example which would stop the raids from beeing started on boot (perhaps). Are there any kind of documents describing how to move from raidtools safely to mdadm without loosing a raid? -- [ Clemens Schwaighofer -=:~ ] [ TEQUILA\ Japan IT Group] [6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jp ] signature.asc Description: OpenPGP digital signature
Accepted usbutils 0.71-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 07:44:33 +0200 Source: usbutils Binary: usbutils usbutils-udeb Architecture: source i386 Version: 0.71-5 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: usbutils - USB console utilities usbutils-udeb - USB console utilities (udeb) Closes: 314478 Changes: usbutils (0.71-5) unstable; urgency=low . * Fixed parsing of bVoltageSupport. Thanks to Ludovic Rousseau for the patch (closes: bug#314478). Files: f600e7bdfb8d43047195c47824fd5385 619 utils optional usbutils_0.71-5.dsc bca58c4e20bc08c7f6f2808cd46e3665 7854 utils optional usbutils_0.71-5.diff.gz 999c99f58db44eb844f278a8cc0bceef 91532 utils optional usbutils_0.71-5_i386.deb 492d3cbff33f0018ad2c29de96fb2ed0 75266 debian-installer optional usbutils-udeb_0.71-5_i386.udeb package-type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtliBw3ao2vG823MRAv/GAJ0fNSJK2svObX17nbNP5U+sAXbz7QCeILCi HTrnU7deyhNKX5F1g6WDwEw= =F4l5 -END PGP SIGNATURE- Accepted: usbutils-udeb_0.71-5_i386.udeb to pool/main/u/usbutils/usbutils-udeb_0.71-5_i386.udeb usbutils_0.71-5.diff.gz to pool/main/u/usbutils/usbutils_0.71-5.diff.gz usbutils_0.71-5.dsc to pool/main/u/usbutils/usbutils_0.71-5.dsc usbutils_0.71-5_i386.deb to pool/main/u/usbutils/usbutils_0.71-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octave2.1 2.1.71-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Jun 2005 15:39:44 +0200 Source: octave2.1 Binary: octave2.1-htmldoc octave octave2.1-info octave2.1-emacsen octave2.1 octave2.1-headers octave2.1-doc Architecture: source i386 all Version: 2.1.71-1 Distribution: experimental Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Debian Octave Group [EMAIL PROTECTED] Description: octave - GNU Octave language for numerical computations (2.1 branch) octave2.1 - GNU Octave language for numerical computations (2.1 branch) octave2.1-doc - PDF documentation on the GNU Octave language (2.1 branch) octave2.1-emacsen - Emacs support for the GNU Octave language (2.1 branch) octave2.1-headers - header files for the GNU Octave language (2.1 branch) octave2.1-htmldoc - HTML documentation on the GNU Octave language (2.1 branch) octave2.1-info - GNU Info documentation on the GNU Octave language (2.1 branch) Changes: octave2.1 (2.1.71-1) experimental; urgency=low . +++ Changes by Rafael Laboissiere . * New upstream release, released to experimental because the API number bumped from api-v13 to api-v15. This makes several other Octave-related package unusable and the uploads to unstable must be coordinated. * debian/in/watch: New template file for debian/watch, which takes into account the MAJOR number of the Octave branch (currently either 2.1 or 2.9). * debian/rules (helper-files): Generate debian/watch from debian/in/watch * debian/in/control: Versioned build-dependency on libhdf5-serial-dev (= 1.6.4) Files: d3823d66eb6b6762b0dfac334c644072 950 math optional octave2.1_2.1.71-1.dsc 811df48dfc472013e2d858cc5d1cad00 6896631 math optional octave2.1_2.1.71.orig.tar.gz a3686e51b7c18b272fbfca1e23916f99 30798 math optional octave2.1_2.1.71-1.diff.gz d15d047bbbe2a708a9702ca8b02fa3aa 5590382 math optional octave2.1_2.1.71-1_i386.deb e0937f16c9727c5679a33866b2b96b51 262982 math optional octave2.1-headers_2.1.71-1_i386.deb 94fe8d86e4ce7953d6447cf6d8a3fa86 1773190 doc optional octave2.1-doc_2.1.71-1_all.deb 3316a1b9c99409fe761397135ff5c04a 382950 math optional octave2.1-htmldoc_2.1.71-1_all.deb 720896ea47323476924f24b975e9a3c6 69206 math optional octave2.1-emacsen_2.1.71-1_all.deb cbcf9904e1064111d6d2374fb4d8cb2e 302546 math optional octave2.1-info_2.1.71-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtmLlk3oga0pdcv4RAngOAJwM5ksAVR7iBk3ATiQiBUx+bGNyjACfTiJw Ye1b8DkVm5i/YFwvhfib73k= =LY5N -END PGP SIGNATURE- Accepted: octave2.1-doc_2.1.71-1_all.deb to pool/main/o/octave2.1/octave2.1-doc_2.1.71-1_all.deb octave2.1-emacsen_2.1.71-1_all.deb to pool/main/o/octave2.1/octave2.1-emacsen_2.1.71-1_all.deb octave2.1-headers_2.1.71-1_i386.deb to pool/main/o/octave2.1/octave2.1-headers_2.1.71-1_i386.deb octave2.1-htmldoc_2.1.71-1_all.deb to pool/main/o/octave2.1/octave2.1-htmldoc_2.1.71-1_all.deb octave2.1-info_2.1.71-1_all.deb to pool/main/o/octave2.1/octave2.1-info_2.1.71-1_all.deb octave2.1_2.1.71-1.diff.gz to pool/main/o/octave2.1/octave2.1_2.1.71-1.diff.gz octave2.1_2.1.71-1.dsc to pool/main/o/octave2.1/octave2.1_2.1.71-1.dsc octave2.1_2.1.71-1_i386.deb to pool/main/o/octave2.1/octave2.1_2.1.71-1_i386.deb octave2.1_2.1.71.orig.tar.gz to pool/main/o/octave2.1/octave2.1_2.1.71.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gpib 3.2.04-3 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 16 Jun 2005 18:42:29 +0200 Source: gpib Binary: libgpib-perl php4-gpib libgpib0-dev gpib-modules-source python2.2-gpib libgpib0 python-gpib python2.3-gpib libgpib-bin Architecture: source powerpc all Version: 3.2.04-3 Distribution: unstable Urgency: low Maintainer: Robert Jordens [EMAIL PROTECTED] Changed-By: Robert Jordens [EMAIL PROTECTED] Description: gpib-modules-source - kernel modules for various GPIB boards libgpib-bin - libgpib support applications and configuration libgpib-perl - libgpib perl bindings libgpib0 - C bindings for GPIB (IEEE 488) kernel driver -- headers libgpib0-dev - C bindings for GPIB (IEEE 488) kernel driver -- headers php4-gpib - libgpib php bindings python-gpib - libgpib python bindings (default package) python2.2-gpib - libgpib Python 2.2 bindings python2.3-gpib - libgpib Python 2.3 bindings Changes: gpib (3.2.04-3) unstable; urgency=low . * Pah. Really fix modprobe and modutils files Files: e1f08c47f56f698c2ed2f9bd01b6b2b8 874 science optional gpib_3.2.04-3.dsc 0878d11cd7506dcd3a06b80f25797b43 25166 science optional gpib_3.2.04-3.diff.gz 7a90e4ee8b13d7faecdfd6c09faab38a 117256 science optional gpib-modules-source_3.2.04-3_all.deb 6bf0706ac45070ad141dbdd7a316a609 404428 libdevel optional libgpib0-dev_3.2.04-3_powerpc.deb 34f6865c098d86da786616102e0e9954 46242 libs optional libgpib0_3.2.04-3_powerpc.deb f411ee9cc022cdc1b9a44638c3b592df 27338 science optional libgpib-bin_3.2.04-3_powerpc.deb ce07085324365b240700959ddfbf7237 34724 perl optional libgpib-perl_3.2.04-3_powerpc.deb c78f63e915ab6feb8e62a239ed4512b8 68464 science optional php4-gpib_3.2.04-3_powerpc.deb a7a913629299a2b3787e7633e5c82c6d 19882 python optional python2.3-gpib_3.2.04-3_powerpc.deb 813cac53dffd009c1255bc28bd44096d 19888 python optional python2.2-gpib_3.2.04-3_powerpc.deb aa84cabd697043309b09fdc5dc4d1e86 13514 python optional python-gpib_3.2.04-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtmeuHSjkv+Av7xERAvUJAJ9JX5+Qz10BRmYuu2Pkt5EWoFiLNQCeO92l t38XOMrxHBPw67rpknWZCz0= =RBwU -END PGP SIGNATURE- Accepted: gpib-modules-source_3.2.04-3_all.deb to pool/main/g/gpib/gpib-modules-source_3.2.04-3_all.deb gpib_3.2.04-3.diff.gz to pool/main/g/gpib/gpib_3.2.04-3.diff.gz gpib_3.2.04-3.dsc to pool/main/g/gpib/gpib_3.2.04-3.dsc libgpib-bin_3.2.04-3_powerpc.deb to pool/main/g/gpib/libgpib-bin_3.2.04-3_powerpc.deb libgpib-perl_3.2.04-3_powerpc.deb to pool/main/g/gpib/libgpib-perl_3.2.04-3_powerpc.deb libgpib0-dev_3.2.04-3_powerpc.deb to pool/main/g/gpib/libgpib0-dev_3.2.04-3_powerpc.deb libgpib0_3.2.04-3_powerpc.deb to pool/main/g/gpib/libgpib0_3.2.04-3_powerpc.deb php4-gpib_3.2.04-3_powerpc.deb to pool/main/g/gpib/php4-gpib_3.2.04-3_powerpc.deb python-gpib_3.2.04-3_powerpc.deb to pool/main/g/gpib/python-gpib_3.2.04-3_powerpc.deb python2.2-gpib_3.2.04-3_powerpc.deb to pool/main/g/gpib/python2.2-gpib_3.2.04-3_powerpc.deb python2.3-gpib_3.2.04-3_powerpc.deb to pool/main/g/gpib/python2.3-gpib_3.2.04-3_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xfce4-battery-plugin 0.2.0-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Jun 2005 14:31:28 +0200 Source: xfce4-battery-plugin Binary: xfce4-battery-plugin Architecture: source i386 Version: 0.2.0-7 Distribution: unstable Urgency: low Maintainer: Debian Xfce Maintainers [EMAIL PROTECTED] Changed-By: Emanuele Rocca [EMAIL PROTECTED] Description: xfce4-battery-plugin - battery monitor plugin for the Xfce4 panel Closes: 294308 Changes: xfce4-battery-plugin (0.2.0-7) unstable; urgency=low . * Moving to unstable . xfce4-battery-plugin (0.2.0-6) experimental; urgency=low . * README.Debian added to document APM/ACPI stuff (Closes: #294308) Files: d58d168b51e360fc6136a935c58eaeb4 930 x11 optional xfce4-battery-plugin_0.2.0-7.dsc b6e50f2e3a360ae1ecd07b0d83286b48 2502 x11 optional xfce4-battery-plugin_0.2.0-7.diff.gz 4633a49e6d57c5a79ed18165d45dfc12 19712 x11 optional xfce4-battery-plugin_0.2.0-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtmq6C6DuA+rxm2ARAg9eAJoCZJNPlEfdIqeOiZsO0OHlynURYwCgjI3n GfpHeJpe90E3aIVSj91MRP4= =ZmBS -END PGP SIGNATURE- Accepted: xfce4-battery-plugin_0.2.0-7.diff.gz to pool/main/x/xfce4-battery-plugin/xfce4-battery-plugin_0.2.0-7.diff.gz xfce4-battery-plugin_0.2.0-7.dsc to pool/main/x/xfce4-battery-plugin/xfce4-battery-plugin_0.2.0-7.dsc xfce4-battery-plugin_0.2.0-7_i386.deb to pool/main/x/xfce4-battery-plugin/xfce4-battery-plugin_0.2.0-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted poldi 0.2-cvs2-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 09:21:33 +0200 Source: poldi Binary: libpam-poldi Architecture: source i386 Version: 0.2-cvs2-5 Distribution: experimental Urgency: low Maintainer: Joachim Breitner [EMAIL PROTECTED] Changed-By: Joachim Breitner [EMAIL PROTECTED] Description: libpam-poldi - PAM module allowing authentication using a OpenPGP smartcard Closes: 314764 Changes: poldi (0.2-cvs2-5) experimental; urgency=low . * Closes: #314764: FTBFS in experimental: Not using -fPIC to build shared lib. Files: 21b2951ca94b2f88e9b141fe8b752121 634 admin extra poldi_0.2-cvs2-5.dsc b0b45e36e53147a5ffe5b75043a7ca35 9201 admin extra poldi_0.2-cvs2-5.diff.gz e2da8657c0cec4a47ee35d19a7807251 88420 admin extra libpam-poldi_0.2-cvs2-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtnJi9ijrk0dDIGwRAu6+AJ9k/MWKzWgmPd0MHXZxenM9jEAYHgCfdQ83 W/21S2YQ/DqrikPVR3pj+UU= =8YfC -END PGP SIGNATURE- Accepted: libpam-poldi_0.2-cvs2-5_i386.deb to pool/main/p/poldi/libpam-poldi_0.2-cvs2-5_i386.deb poldi_0.2-cvs2-5.diff.gz to pool/main/p/poldi/poldi_0.2-cvs2-5.diff.gz poldi_0.2-cvs2-5.dsc to pool/main/p/poldi/poldi_0.2-cvs2-5.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted newsgate 1.6-22 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 09:42:35 +0200 Source: newsgate Binary: newsgate Architecture: source i386 Version: 1.6-22 Distribution: unstable Urgency: low Maintainer: Norbert Tretkowski [EMAIL PROTECTED] Changed-By: Norbert Tretkowski [EMAIL PROTECTED] Description: newsgate - Mail to News and News to Mail Gateway Closes: 260729 314677 Changes: newsgate (1.6-22) unstable; urgency=low . * New maintainer. (closes: #314677) * Fixed FTBFS with gcc-3.4, thanks to Andreas Jochens for the patch. (closes: #260729) * Added real package exim4 to mail-transport-agent dependency. Files: 0a0f2d4ba2b1559695740bb4241f18b6 577 non-free/news optional newsgate_1.6-22.dsc 395f46d77c15b0ac8188f8edd0c41f0b 15378 non-free/news optional newsgate_1.6-22.diff.gz 2c91a4e62c8e09a137765e11e6228488 80560 non-free/news extra newsgate_1.6-22_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtnePr/RnCw96jQERAvEeAJ9Y//sMs2/LJ/DapOqef+BNpyaaawCdHhCE OWAo4QDqz4UgibRXnku9mpI= =BxfO -END PGP SIGNATURE- Accepted: newsgate_1.6-22.diff.gz to pool/non-free/n/newsgate/newsgate_1.6-22.diff.gz newsgate_1.6-22.dsc to pool/non-free/n/newsgate/newsgate_1.6-22.dsc newsgate_1.6-22_i386.deb to pool/non-free/n/newsgate/newsgate_1.6-22_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debtags-edit 1.0.1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 10:14:08 +0200 Source: debtags-edit Binary: debtags-edit Architecture: source i386 Version: 1.0.1 Distribution: experimental Urgency: low Maintainer: Enrico Zini [EMAIL PROTECTED] Changed-By: Enrico Zini [EMAIL PROTECTED] Description: debtags-edit - GUI browser and editor for Debian Package Tags Changes: debtags-edit (1.0.1) experimental; urgency=low . * Disabled specials generation as a quick-fix to frequent crashes. I will need to significantly improve its performance before reactivating it again. Files: 09c3a8d84b49e15f94e3dbe63e8db612 608 misc optional debtags-edit_1.0.1.dsc 306adf1da05c3a81713ce3a518e15460 180645 misc optional debtags-edit_1.0.1.tar.gz 032be1e8b031ff8594daf8039ae4f5d5 288346 misc optional debtags-edit_1.0.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtnwW9LSwzHl+v6sRAsTAAJ4xbubhA6vOy9fTV5bpYm6KJ39cPQCeJEaX j9iy/GaTzBh2ZCZ+VIfsg+I= =/Uot -END PGP SIGNATURE- Accepted: debtags-edit_1.0.1.dsc to pool/main/d/debtags-edit/debtags-edit_1.0.1.dsc debtags-edit_1.0.1.tar.gz to pool/main/d/debtags-edit/debtags-edit_1.0.1.tar.gz debtags-edit_1.0.1_i386.deb to pool/main/d/debtags-edit/debtags-edit_1.0.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sooperlooper 1.0.5-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 09:44:24 +0200 Source: sooperlooper Binary: sooperlooper Architecture: source i386 Version: 1.0.5-2 Distribution: unstable Urgency: low Maintainer: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Changed-By: Guenter Geiger (Debian/GNU) [EMAIL PROTECTED] Description: sooperlooper - Looping Sampler Closes: 314970 Changes: sooperlooper (1.0.5-2) unstable; urgency=low . * Applied gcc4 patch (closes: #314970), thanks to Andreas Jochens Files: 8e4103b02253f6a11c1c2fe0fe897989 745 sound optional sooperlooper_1.0.5-2.dsc 759d7390f5ea9702be73da4f3c172088 5829 sound optional sooperlooper_1.0.5-2.diff.gz 93725de8ea480b683115541c862be3b2 482784 sound optional sooperlooper_1.0.5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCtnwJ1pbKhmC2uVgRAghAAJ9CxUNssBwg6B9ZGrbv8nriuagQjQCfVTIt 4F7CXuthsLU+UzNxX0rX+K4= =7JjY -END PGP SIGNATURE- Accepted: sooperlooper_1.0.5-2.diff.gz to pool/main/s/sooperlooper/sooperlooper_1.0.5-2.diff.gz sooperlooper_1.0.5-2.dsc to pool/main/s/sooperlooper/sooperlooper_1.0.5-2.dsc sooperlooper_1.0.5-2_i386.deb to pool/main/s/sooperlooper/sooperlooper_1.0.5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnupod-tools 0.98-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 11:27:40 +0300 Source: gnupod-tools Binary: gnupod-tools Architecture: source all Version: 0.98-3 Distribution: unstable Urgency: low Maintainer: Brian Nelson [EMAIL PROTECTED] Changed-By: Brian Nelson [EMAIL PROTECTED] Description: gnupod-tools - command-line tools for the iPod family of portable music players Changes: gnupod-tools (0.98-3) unstable; urgency=low . * Removed all of the manpages in the debian dir, use the upstream ones from now on * debian/rules: removed the docbook2man stuff * debian/control: removed the dependency on docbook-utils | docbook-to-man * debian/control: (hopefully) improved the package description Files: 2de17c02b6a39cee63dbec0bf485fda1 752 sound optional gnupod-tools_0.98-3.dsc 99468e39987727228ba73e98b7d6a46e 5045 sound optional gnupod-tools_0.98-3.diff.gz 47be5d7b09bf2378903a2b015e71022b 120002 sound optional gnupod-tools_0.98-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtn7u1Ng1YWbyRSERAuvrAJ9iCaj25g6fPlqNHqHZUzw2sTn6gwCfVbST gRvPZ8EpyUMWL/tGW3t33VA= =ZhG6 -END PGP SIGNATURE- Accepted: gnupod-tools_0.98-3.diff.gz to pool/main/g/gnupod-tools/gnupod-tools_0.98-3.diff.gz gnupod-tools_0.98-3.dsc to pool/main/g/gnupod-tools/gnupod-tools_0.98-3.dsc gnupod-tools_0.98-3_all.deb to pool/main/g/gnupod-tools/gnupod-tools_0.98-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fakechroot 0.9+1.3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 10:04:24 +0200 Source: fakechroot Binary: fakechroot Architecture: source i386 Version: 0.9+1.3 Distribution: unstable Urgency: medium Maintainer: Piotr Roszatycki [EMAIL PROTECTED] Changed-By: Piotr Roszatycki [EMAIL PROTECTED] Description: fakechroot - gives a fake chroot environment Changes: fakechroot (0.9+1.3) unstable; urgency=medium . * Clean up the code - no static variables. * narrow_chroot_path(path) macro returns original path if it is outside chroot so getcwd(2) works for /dev and /proc. * Implement lutimes(2) function. * Fixed path for biarch libraries on sparc and amd64. * Updated ldd.fake script. Now works on biarch systems. * Biarch support for s390. * Updated documentation. Files: 4d74ccb5c984040477ed0dbe9dc112fd 640 utils optional fakechroot_0.9+1.3.dsc 2bac69a0daa385f030ebfbac6473618b 52339 utils optional fakechroot_0.9+1.3.tar.gz 0231dba51e3c2de1fbaec66e904963da 61082 utils optional fakechroot_0.9+1.3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtoSNhMHHe8CxClsRAmkHAJ42ROSVBBpsCwRZ0gxcJ1vOoXOBNgCgl0bw mpqmEkL2MZ1Lpx1jWK0ZvGk= =w0Kk -END PGP SIGNATURE- Accepted: fakechroot_0.9+1.3.dsc to pool/main/f/fakechroot/fakechroot_0.9+1.3.dsc fakechroot_0.9+1.3.tar.gz to pool/main/f/fakechroot/fakechroot_0.9+1.3.tar.gz fakechroot_0.9+1.3_i386.deb to pool/main/f/fakechroot/fakechroot_0.9+1.3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nant 0.84+0.85-rc3-8 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Jun 2005 10:10:51 +0100 Source: nant Binary: nant Architecture: source all Version: 0.84+0.85-rc3-8 Distribution: unstable Urgency: low Maintainer: Dave Beckett [EMAIL PROTECTED] Changed-By: Dave Beckett [EMAIL PROTECTED] Description: nant - .NET build tool similar to Ant Changes: nant (0.84+0.85-rc3-8) unstable; urgency=low . * Depend on libmono-dev to get mono.pc at runtime. Files: 2e61b10ce2fadff4af81adf3aeb8dd36 698 devel optional nant_0.84+0.85-rc3-8.dsc 17aafb44c47d7e54ebc0f5fb19386600 10035 devel optional nant_0.84+0.85-rc3-8.diff.gz 1d609691845c9bf017f10c70562272a9 1996428 devel optional nant_0.84+0.85-rc3-8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCtoiSQ+ySUE9xlVoRAiDNAKCDJw2Pi5JncaRXvr0JO7ZjP4+ZSgCfZnfc F/wSQV+f9Soe1RGYifr3kn0= =gtNA -END PGP SIGNATURE- Accepted: nant_0.84+0.85-rc3-8.diff.gz to pool/main/n/nant/nant_0.84+0.85-rc3-8.diff.gz nant_0.84+0.85-rc3-8.dsc to pool/main/n/nant/nant_0.84+0.85-rc3-8.dsc nant_0.84+0.85-rc3-8_all.deb to pool/main/n/nant/nant_0.84+0.85-rc3-8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
