Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.06.2007 um 13:29 schrieb Christoph Mende: On Tue, 12 Jun 2007 12:59:42 +0200 cilly [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 12:53 PM, cilly wrote: Additional: Sometimes the chance for the users to place the ebuild comfortably into overlay is simply taken, since the ebuild has been removed and doesn't exist after a sync anymore. It's not, CVS keeps every ebuild around, just go to sources.gentoo.org and hit Show X dead files in the dir of the ebuild you want ;) The problem is rather that the patches are gone from the distfiles mirror after two weeks. The sources often stay upstream, but could also be gone. Is there an archive for these files I missed? Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGcACzyZx3L/ph1soRAutQAKCMQ2f6nCzoXgATbIPTO6sbTv32ugCeP+JP tqC13Sfmy1t30jU6aCWgZug= =A832 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Wed, Jun 13, 2007 at 04:35:31PM +0200, Robert Buchholz wrote:
The problem is rather that the patches are gone from the distfiles
mirror after two weeks. The sources often stay upstream, but could
also be gone.
Is there an archive for these files I missed?
That archive ('purgatory' being the name used for it) isn't publically
accessible; had suggested it in the past, but infra folks didn't
think it would be needed.
Few issues if it were opened up;
1) it's not a true vcs, just a directory. Meaning
1.a) it's collapsing down the trees history of distfile names; if
ebuild x refs 'patch', gets removed, 'patch' goes into purgatory. If
ebuild y refs 'patch', which is a different file, then gets removed,
ebuild ys' version of 'patch' is whats is now in purgatory (last used
basically).
1.b) skimped a bit in the description above; 'patch' gets removed from
purgatory when ebuild 'y' is added to the tree- the chksums will
differ, thus it throws out the copy that no longer is relevant to it's
job (maintaining the mirror image).
2) if implemented, likely to be a single box- meaning stuff shouldn't
rely on it as an upstream URI, they should mirror it themselves.
3) mirror maintenance, if an ebuild is added to the tree that uses
that specific distfile name, as hinted at in 1.b, the file is removed
from purgatory- this *includes* if the chksums match. Basically, if
the file is needed on the mirror image, it copies it over and wipes
the purgatory copy of it (intention is to keep space usage down).
This obviously would break any ebuilds daftly ignoring #2, and using
the purgatory host as an upstream URI.
Personally, I think at least for devs, having access to purgatory
would be a good thing. Folks seem to have learned over the last few
years, but dealt with a lot of requests where a dev screwed up and
needed to pull a file out of purgatory. Perhaps they've gotten wiser
since, dunno. Either way, if trying to pull a file out of
purgatory, bug your friendly infra monkey, or zmedico if you need a
specific file out- they ought to have access.
For effectively random anonymous, http/ftp, not sure about
that. Think some form of access is needed, don't think it should
really be usable as an upstream host.
~harring
pgprSYrkkKd1y.pgp
Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
cilly wrote: Hi all, I think it's worth to discuss the `behaviour of removing ebuilds from the tree`. Currently it's up to the developer, some people are more conservative, some prefer to get rid of certain stuff asap. You should differentiate between ~ and stable ones btw... In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets updated the older ebuild gets removed in the same turn. This happens only when: - there are security concerns - the old ebuild was there till ages and the new one had been in ~ since ages. In my opinion, it is better to keep the older ebuild around for a while since if there are some bugs in the newer ebuild, users are able to downgrade easily. that's is quite up to the specific applications IMHO. What do you think? I'd leave it up to the developer, nothing is lost in gentoo and fetching from the attic isn't exactly difficult. Still probably having a note to make people aware of that could be useful since the problem you pointed doesn't require any more work to be solved. PS: other topics to be discussed `Not to modify ebuilds which are already in the tree... even if masked` what do you think? I probably understood what you mean and well, no, I don't think is a good idea. lu - that prefers less rules and more people aware. -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 11:40:26AM +0200, cilly wrote: In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets updated the older ebuild gets removed in the same turn. In my opinion, it is better to keep the older ebuild around for a while since if there are some bugs in the newer ebuild, users are able to downgrade easily. My suggestion is to set up a guidline similar like it exists for marking the ebuilds as stable (4 weeks). Probably, a time period for removing ebuilds would be nice to have, I think 2 weeks would be reasonable if there aren't any known bugs of the newer ebuild. Of course, if the newer ebuild has bugs, which do not exist in the older ebuild the older ebuild should still be kept to let the user be able to choose, which version they want. What do you think? I think that setting arbitrary guidelines that try to rule every situation is just *plain* wrong. Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) As usual, deep known of the package you are removing and common sense is way better than guidelines 'to rule them all'. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgppo3ZKWtso0.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 11:59:28AM +0200, Luca Barbato wrote: lu - that prefers less rules and more people aware. Couldn't agree more. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpliNQUioYQL.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote: I think that setting arbitrary guidelines that try to rule every situation is just *plain* wrong. Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) As usual, deep known of the package you are removing and common sense is way better than guidelines 'to rule them all'. I see myself very often upgrading and encountering a bug which requires me to downgrade. But a downgrade isn't easily possible since the last stable ebuild has already been replaced by the newer and buggy one. The bug must not be in the ebuild itself, sometimes a version-upgrade (upstream) brings new features and new bugs. Sometimes it is nearly impossible for a package maintainer to get an overview of possible bugs, may be upstream bugs, or typos. Related to these issues, I really recommend to add timeline like it exists for adding to stable tree. Cec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 12:14:37PM +0200, cilly wrote: On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote: I think that setting arbitrary guidelines that try to rule every situation is just *plain* wrong. Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) As usual, deep known of the package you are removing and common sense is way better than guidelines 'to rule them all'. I see myself very often upgrading and encountering a bug which requires me to downgrade. But a downgrade isn't easily possible since the last stable ebuild has already been replaced by the newer and buggy one. The bug must not be in the ebuild itself, sometimes a version-upgrade (upstream) brings new features and new bugs. Sometimes it is nearly impossible for a package maintainer to get an overview of possible bugs, may be upstream bugs, or typos. Well, if maintainers can't properly follow upstream development they should probably seek help in their maintenance job. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpIOT3TR5mfk.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 12:21 PM, Fernando J. Pereda wrote: Well, if maintainers can't properly follow upstream development they should probably seek help in their maintenance job. Hi Fernando, well, I wouldn't bring up this discussion if there aren't any problems. I `think` a reminder to all devs about managing ebuilds, i.e. with the following link: http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html would be a solution. What do you think? Cec. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
Fernando J. Pereda wrote: Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) Can you clarify this? What scenarios do you run into where it isn't good for stable users to have access to more than one version of the software? One thing that I noticed is that in many cases there are multiple testing versions of a package available, and one stable version. So, if you run unstable you can pick and choose, but if you're running stable (which in theory should be the target audience gentoo aims for) then you get your choice of only one. I tend to think that unless something unusual is going on that old packages should be kept around for a while (a few weeks at least). The same should apply to packages in testing as well. Actually, that could be a whole separate topic. There have been many times that I've had to upgrade to a package in testing to get some needed feature, but then it gets deleted in favor of some other package in testing - and the stable package sits at its current version for ages. Unless a package in testing has a reasonably serious problem of some kind it would seem to make more sense to me to have ebuilds not removed until they've been stabilized and then obsoleted. An exception would be revision bumps - no sense stabilizing an ebuild revision that has a simple bugfix available without an upstream version change. Others have pointed out that inflexible rules aren't always the answer. I'd agree in general, but there should be guidelines. Maybe certain packages shouldn't have multiple stable versions to choose from. But when certain packages becomes 80% of them then I'd wonder if there really is a good reason for this... smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cilly wrote: well, I wouldn't bring up this discussion if there aren't any problems. Hi Cecilia, perhaps you could go into some more specifics of these problems? Which packages were removed and were they stable, testing or masked at the time of removal? What problems did the removal cause? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbngop/VmCx0OL2wRAkfoAKCyuL8a8n4o3iZB1sH3qrHWWWlKlQCgwTl+ XDGLe9penKS9ymmxcrAyobU= =nGUG -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
Richard Freeman wrote: Can you clarify this? What scenarios do you run into where it isn't good for stable users to have access to more than one version of the software? - Security issues. - Downgrade to hell scenarios - Other colorful issues that may happen from time to time. One thing that I noticed is that in many cases there are multiple testing versions of a package available, and one stable version. So, if you run unstable you can pick and choose, but if you're running stable (which in theory should be the target audience gentoo aims for) then you get your choice of only one. The stable one is supposed to be the best available, the ~ ones are supposed to be in flux I tend to think that unless something unusual is going on that old packages should be kept around for a while (a few weeks at least). Happens more than often =) Others have pointed out that inflexible rules aren't always the answer. I'd agree in general, but there should be guidelines. Maybe certain packages shouldn't have multiple stable versions to choose from. But when certain packages becomes 80% of them then I'd wonder if there really is a good reason for this... Keep in mind that the trade off is : - our time - our sanity - what provide to our used - the quality of what we provide to out users. We all try our best to not burn out while serving you the best we could think. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 06:36:31AM -0400, Richard Freeman wrote: Fernando J. Pereda wrote: Some of the packages I maintain are better removed when a new maintenance version is released. And I plan to keep it that way :) Can you clarify this? What scenarios do you run into where it isn't good for stable users to have access to more than one version of the software? Known to be buggy versions. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpXkRY28H2IT.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 12:40 PM, Marijn Schouten (hkBst) wrote: Hi Cecilia, perhaps you could go into some more specifics of these problems? Which packages were removed and were they stable, testing or masked at the time of removal? What problems did the removal cause? Marijn Hi Marijn, please, understand that I do not want to `blame` any developer, unless it is discussed here with a final solution. Since I am not a gentoo-dev, some of the devs `may not understand` my concerns and probably `feel offended`. Cheers, Cec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 12:48 PM, Luca Barbato wrote: Keep in mind that the trade off is : - our time - our sanity - what provide to our used - the quality of what we provide to out users. We all try our best to not burn out while serving you the best we could think. Does it make such a difference if ebuilds are kept for a few weeks? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote: Known to be buggy versions. Of course, there are bugs in every version. Sometimes a user must be able to choose which bug is more problematic, i.e. the bug in the newer ebuild which makes the package unusable for them or the older bug which has a security issue the users are aware of but not present, i.e. prevented by firewall. A timeline of two weeks would allow the user to easily downgrade and if necessary put the ebuild in overlay. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard Freeman wrote: One thing that I noticed is that in many cases there are multiple testing versions of a package available, and one stable version. So, if you run unstable you can pick and choose, but if you're running stable (which in theory should be the target audience gentoo aims for) then you get your choice of only one. I think this is a consequence of the strict rules for stabling packages and removing stable packages. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbny9p/VmCx0OL2wRAp29AJ9V3Nvok7ol9QQCRSj62FP03dEl6wCaA5Df mm/NURPVPSwcHcBeA3fKOnE= =Mvgs -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 12:53 PM, cilly wrote: Of course, there are bugs in every version. Sometimes a user must be able to choose which bug is more problematic, i.e. the bug in the newer ebuild which makes the package unusable for them or the older bug which has a security issue the users are aware of but not present, i.e. prevented by firewall. A timeline of two weeks would allow the user to easily downgrade and if necessary put the ebuild in overlay. Additional: Sometimes the chance for the users to place the ebuild comfortably into overlay is simply taken, since the ebuild has been removed and doesn't exist after a sync anymore. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, Jun 12, 2007 at 12:53:16PM +0200, cilly wrote: On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote: Known to be buggy versions. Of course, there are bugs in every version. Sometimes a user must be able to choose which bug is more problematic, i.e. the bug in the newer ebuild which makes the package unusable for them or the older bug which has a security issue the users are aware of but not present, i.e. prevented by firewall. A timeline of two weeks would allow the user to easily downgrade and if necessary put the ebuild in overlay. If the user thinks he knows better than me which version he wants to use, there is the code. I'll still keep in Gentoo's tree whatever *I* feel it is best for every gentoo user. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpN2eS7eF6so.pgp Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cilly wrote: please, understand that I do not want to `blame` any developer, unless it is discussed here with a final solution. Since I am not a gentoo-dev, some of the devs `may not understand` my concerns and probably `feel offended`. Hi Cecilia, Nobody will feel offended by your bug report. I'm asking you to go into specifics precisely because I want to better understand what the exact problem is. Or you could start using lilypond and tell me all that is wrong with it (a lot). When 2.10.26 comes out in probably a few days I'll be removing all other testing versions, except 2.11.26, because they have problems with the newest fontforge. I hope 2.10.26 will be good enough to be stabled. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbn7Yp/VmCx0OL2wRAjM2AJ0UdBKDsb+u0CVHvttKwAakqKvLgACfYer9 9J70SOJpZNkMNIkXe30OnRo= =9nCO -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
cilly kirjoitti: On Jun 12, 2007, at 12:48 PM, Luca Barbato wrote: Keep in mind that the trade off is : - our time - our sanity - what provide to our used - the quality of what we provide to out users. We all try our best to not burn out while serving you the best we could think. Does it make such a difference if ebuilds are kept for a few weeks? Nope and they should usually be kept but we can't make a hard rule because there are cases where the old ebuilds don't work any more. If you find that a broken version slipped the cracks of the arch teams and made it to stable with the old version removed, file a bug to bugs.gentoo.org and hopefully the maintainer learns from his/her mistake of removing it too soon. If the maintainer keeps on doing the same thing, then you can try to escalate things to qa/devrel. If you are using ~arch, then encountering some broken stuff is fully expected, just file a bug and the maintainer is expected to react in a timely manner. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 1:03 PM, Fernando J. Pereda wrote: If the user thinks he knows better than me which version he wants to use, there is the code. I'll still keep in Gentoo's tree whatever *I* feel it is best for every gentoo user. Fernando, I do not complain against you, may be if everyone would act as you I / we / some won't have problems at all. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
cilly wrote: Sometimes the chance for the users to place the ebuild comfortably into overlay is simply taken, since the ebuild has been removed and doesn't exist after a sync anymore. any ebuild from day 0 till now lives in the cvs, you can fetch it from the cvs attic anytime, I'm afraid this information isn't exactly well known =/ lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Tue, 12 Jun 2007 12:59:42 +0200 cilly [EMAIL PROTECTED] wrote: On Jun 12, 2007, at 12:53 PM, cilly wrote: Additional: Sometimes the chance for the users to place the ebuild comfortably into overlay is simply taken, since the ebuild has been removed and doesn't exist after a sync anymore. It's not, CVS keeps every ebuild around, just go to sources.gentoo.org and hit Show X dead files in the dir of the ebuild you want ;) signature.asc Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 1:27 PM, Luca Barbato wrote: any ebuild from day 0 till now lives in the cvs, you can fetch it from the cvs attic anytime, I'm afraid this information isn't exactly well known =/ I am aware of it, but this means much more frickle-time (forget frickle if you don't know it :). -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 1:29 PM, Christoph Mende wrote: It's not, CVS keeps every ebuild around, just go to sources.gentoo.org and hit Show X dead files in the dir of the ebuild you want ;) so you misunderstood comfortably :) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 1:21 PM, Petteri Räty wrote: Nope and they should usually be kept but we can't make a hard rule because there are cases where the old ebuilds don't work any more. If you find that a broken version slipped the cracks of the arch teams and made it to stable with the old version removed, file a bug to bugs.gentoo.org and hopefully the maintainer learns from his/her mistake of removing it too soon. If the maintainer keeps on doing the same thing, then you can try to escalate things to qa/devrel. If you are using ~arch, then encountering some broken stuff is fully expected, just file a bug and the maintainer is expected to react in a timely manner. I agree, if an ebuild is broken then it should be removed since it doesn't work at all. But rather than exchanging the broken ebuild with a version bump it is sometimes more advisable to repair the broken ebuild and increase the integer of -rx instead of replacing the broken ebuild with a masked one. Very often bugs are filed after a package has been unmasked and so it is better to have a working older ebuild. Of course, this is just a case scenario which may happen. To prevent such rare cases is in mind of every user. Well, I still think, leave it up to the users and give them time to choose between ebuilds and move them to overlay, instead of forcing them to query the source for dead packages.-- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
Btw, both of your issues could probably be solved by bug 126059 without adding new rules or new work for ebuild devs. -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
On Jun 12, 2007, at 2:55 PM, Marius Mauch wrote: Btw, both of your issues could probably be solved by bug 126059 without adding new rules or new work for ebuild devs. Thanks a lot for this, I totally agree. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cilly wrote: On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote: Known to be buggy versions. Of course, there are bugs in every version. Sometimes a user must be able to choose which bug is more problematic, i.e. the bug in the newer ebuild which makes the package unusable for them or the older bug which has a security issue the users are aware of but not present, i.e. prevented by firewall. A timeline of two weeks would allow the user to easily downgrade and if necessary put the ebuild in overlay. Hello, We (developers) won't immediately remove old packages versions if there is no a good reason for it, at least in my case. One of the main motivation for fast removal are security concerns, they sometimes happen and they don't even get into our bugzilla database , but the maintainer of the package is aware of it from upstream reports, so these might be unknown problems for our users. Best recommendation is that you trust the package maintainer and report bugs in the new packages if you find them. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGbsQ8aTNpke9pJcURAugPAJ9MuOmIFMzNNAx7DqKCm/ZuxLj5mACfcOf/ W3oxNo4aXWZLGlT9D5HblQ4= =GLS5 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
