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 pr
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=srt&m=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 debian.org email, please
Pierre Habouzit 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 > > 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
Re: Mozilla Foundation Trademarks
* Michael K. Edwards ([EMAIL PROTECTED]) wrote: > On 6/19/05, Eric Dorland <[EMAIL PROTECTED]> wrote: > > * Michael K. Edwards ([EMAIL PROTECTED]) wrote: > > > I wouldn't say "accept" it, I would say "acknowledge" the safety zone > > > offered unilaterally by the Mozilla Foundation, and as a courtesy to > > > them make some effort to stay comfortably within it while continuing > > > to ship under the Mozilla names. Their trademark policy is surely > > > less draconian than, say, Red Hat's, and we aren't going around > > > purging the RedHat Package Manager from Debian. > > > > I think you're playing word games now. Even if this is a unilateral > > "gift" we still need to decide if we want it or not. > > Of course; and as the maintainer, you are going to be the one making > that call. I'm just chary of using words like "offer" and "accept" > because they suggest that we are in the contract zone. I think (I > could be wrong; IANAL) that, in the free software arena, it's actually > better for both sides for the trademark holder to say: > > "We aren't exactly licensing all and sundry to manufacture products > under our brand. Our product line includes both the source code and > the 'official' binaries; we are of the opinion that third parties who > follow these guidelines when building and distributing their own > binaries are merely re-packaging our source code product (under > standards like Coty v. Prestonettes in the US and X, Y, and Z > elsewhere) and using our trademarks descriptively. > > "We reserve the right to decide unilaterally that someone either has > created a product of their own (to which our trademark can't be > applied without license) or isn't doing an adequate job of QA in the > course of re-packaging. But if and when that happens, we're going to > follow the steps outlined here to try to bring them into voluntary > compliance before we demand that they either accept a formal license > and traditional oversight procedures or cease to apply our trademarks > to their modified version of our product." > > >From what I've read, that's as open a policy as a trademark holder can > offer and still retain control of the trademark in the long run. I > may be overstating here how far the Mozilla Foundation is willing to > go; but if a modus vivendi can be reached in which the only thing > special about Debian is that the guidelines more or less reflect the > maintainer's actual practice, I think that sits more comfortably with > DFSG #8 than a license per se. If the mozilla foundation come up with something like that I would be satisfied, as long as the guidelines as reasonable and allow me to do things I need to do as a maintainer. > > > If the offer from six months ago still stands (which, to my > > > recollection and in my non-lawyer view, read like a unilateral "safety > > > zone" rather than a trademark license as such), that's extraordinarily > > > accommodating on MoFo's part. It's a square deal from people with a > > > pretty good reputation for square deals. They deserve better from > > > Debian than to have their flagship products obscured by a rename when > > > they haven't done anything nasty to anyone yet. > > > > What reputation are you referring to? Not that I necessarily disagree, > > but what are you basing that assessment on? > > Their rebranding isn't special for Netscape/AOL and other corporate > partners; they've worked very hard to make it accessible to third > parties without any need for explicit cooperation with them. They're > going through the agony of relicensing their entire code base under > MPL/LGPL/GPL so that GPL projects can cherry-pick at source code > level. They're good citizens in W3C standards space even when the > committee decisions go against them (e. g., XUL vs. XForms). I don't > know the details of their CA certificate handling, but at least they > _have_ a policy and respond constructively to criticism of it. And > Mitch Kapor and the rest of the MoFo board have a lot of street cred > as individuals. Point taken. But I'm not sure what you mean by their Netscape rebranding isn't special. Netscape doesn't claim their browser is Firefox, so there isn't a problem from that perspective. > > > The FSF has, at best, completely failed to offer leadership with > > > respect to free software and trademarks, as the MySQL case and the Red > > > Hat / UnixCD mess have shown. I think it would be rather gratifying > > > if Debian could step in to fill the void. And it would be kind of > > > nice to have a workable modus vivendi to exhibit if and when the Linux > > > Mark Institute (or the OpenSSL team or the PHP folks or Red Hat or > > > MySQL) comes knocking. > > > > I do have to agree that guidance when it comes to trademark situations > > is sorely lacking. There doesn't seem to be that consistent a > > viewpoint with Debian either unfortunately. > > It's a sticky wicket. Free software enthusiasts (among whom I count > myself) don't li
Re: Mozilla Foundation Trademarks
* John Hasler ([EMAIL PROTECTED]) wrote: > 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. If their policy is not legally enforceable then we've wasted a lot of time discussing it. Do you have any backup to this claim? -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Re: Mozilla Foundation Trademarks
* Eric Dorland ([EMAIL PROTECTED]) wrote: > > I'd certainly > be interested in trying to develop some sort of policy for Debian regarding trademarks. I'm not sure how much weight it could carry, but at least if people like the ideas. -- 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
