Re: Debian package without released upstream source
Jörg Sommer <[EMAIL PROTECTED]> writes: > Hallo Nelson, > > Nelson A. de Oliveira <[EMAIL PROTECTED]> wrote: >> Hi! >> >> On 6/4/06, Jörg Sommer <[EMAIL PROTECTED]> wrote: >>> Now, my question is: Can I release a package that bases on not-released >>> sources? If so, I request for an sponsor. Otherwise, what should I do? >>> Wait? >> >> Well... you can. >> >> I saw on >> http://sourceforge.net/project/showfiles.php?group_id=10646&release_id=241671 >> that it's a release candidate version, right? > > No. The source is here: http://dev.atmarama.org/xindy-2.2-beta2.tar.gz > It's really outside of sourceforge. I've got it told here in the second > mail: > http://sourceforge.net/mailarchive/forum.php?thread_id=9429234&forum_id=41680 > >> There is no problem that the version is a release candidate or a beta >> version or something else. You can release a package based on those >> versions. > > Good to know. Just make sure to use a version that sorts lower than a future actual 2.2 release. Optimaly 2.2~beta2 would be used but I think the DAK still doesn't accept those. 2.1.99+2.2-beta might be a good choice. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[RFS] museek+: file-sharing application for the SoulSeek peer-to-peer network
Hi, I'm looking for a sponsor to upload museek+. Museek+ is a client for the SoulSeek network (like Nicotine, already in Debian) but it's in client/server mode. Museek+ provides 5 packages : * museekd : the daemon, written in C++ * museeq : A C++/Qt GUI * mucous : A Python/Curses GUI for console * museek-python-bindings : Python bindings for the C++ daemon * museekd-tools : A few tools to manage a remote museekd This software is very active and I'm really interrested in it. I'm working with the upstream author, as I provide a Trac for development : http://museekplus.le-vert.net/ http://www.le-vert.net/divers/debian-packages/museek+/ http://www.le-vert.net/divers/debian-packages/museek+/museek+_0.1.9-1.dsc Thanks ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: hearts-0.1-1 -- The classic Hearts card game for the GNOME desktop
Hello, I am the developer of Hearts for GNOME (http://www.gnome-hearts.org) and I just packaged the upcoming 0.1 release for Debian. I am looking for a sponsor who is willing to check and upload the package for me. Hearts is an implementation of the classic card game for the GNOME desktop, featuring configurable rulesets and editable computer opponents to satisfy widely diverging playing styles. Hearts is Free Software, released under the GNU General Public License and should be able to run on any computer that can run the GNOME desktop. Features: * Various rulesets with configurable options * Multiple computer opponents with differing styles of play * Drag & drop adding of new opponents * Easy creation and modification of opponents through Lua scripting Known bugs and missing features: * Undo/redo not implemented yet (the buttons are greyed out) * I haven't tested it in pbuilder on sid yet. debootstrapping sid is broken at the moment (see #369928). Other people have tested it with a version of sid that was a few days older and that worked. pbuilding it in ubuntu dapper also works correctly. Download: http://www.jejik.com/files/hearts/temp/hearts_0.1.orig.tar.gz http://www.jejik.com/files/hearts/temp/hearts_0.1-1.dsc http://www.jejik.com/files/hearts/temp/hearts_0.1-1.diff.gz http://www.jejik.com/files/hearts/temp/hearts_0.1-1_source.build http://www.jejik.com/files/hearts/temp/hearts_0.1-1_source.changes Thanks in advance, -- Sander Marechal http://www.gnome-hearts.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Charles Plessy <[EMAIL PROTECTED]> wrote: > I have made /usr/share/doc/probcons-extra a symlink to > /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK > to do such things? ^^ this is important Yes, this is written in Policy. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] museek+: file-sharing application for the SoulSeek peer-to-peer network
Adam Cécile (Le_Vert) wrote: > * museek-python-bindings : Python bindings for the C++ daemon I think the name of this package should be "python-museek". http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names -- Lukáš Lalinský -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hearts-0.1-1 -- The classic Hearts card game for the GNOME desktop
On 6/5/06, Sander Marechal <[EMAIL PROTECTED]> wrote: Hello, I am the developer of Hearts for GNOME (http://www.gnome-hearts.org) and I just packaged the upcoming 0.1 release for Debian. I am looking for a sponsor who is willing to check and upload the package for me. You could take care of this warning, first thing (just looked over the build log) "W: hearts source: newer-standards-version 3.7.2.0" Generally that would mean just bumping the standards version, but you should check. http://www.jejik.com/files/hearts/temp/hearts_0.1-1_source.build -- Regards, EddyP = "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hearts-0.1-1 -- The classic Hearts card game for the GNOME desktop
On (05/06/06 14:10), Eddy Petri??or wrote: > You could take care of this warning, first thing (just looked over the > build log) > > "W: hearts source: newer-standards-version 3.7.2.0" > > Generally that would mean just bumping the standards version, but you > should check. That warning is the other way round, the standards version defined in debian/control is newer that the latest lintian knows about. It is a false positive in this case, as Lintian has not been updated to recognise the latest version. I would say remove DEB_TAR_SRCDIR := hearts-0.1 DEB_AUTO_CLEANUP_RCS:= yes from debian/rules. (I think the second is unecessary). You could also put a statement something like The Debian packaging is (C) 2006, Sander Marechal <[EMAIL PROTECTED]> and is licensed under the GPL version 2 or later, see above. in debian/copyright. [To the rest of the list, I was one of the people that built the package in pbuilder and it worked fine] James -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Le Mon, Jun 05, 2006 at 01:04:37PM +0200, Florent Rougon a écrit : > Charles Plessy <[EMAIL PROTECTED]> wrote: > > > I have made /usr/share/doc/probcons-extra a symlink to > > /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK > > to do such things? ^^ >this is important > > Yes, this is written in Policy. Dear Florent, Thanks for the hint. As the policy says: "Please note that this does not override the section on changelog files below, so the file /usr/share/package/changelog.Debian.gz must refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (same source package and version)." Is there a way to make sure that probcons-extra will depend on the probcons package with the same version as itself? Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Hi!
On 6/5/06, Charles Plessy <[EMAIL PROTECTED]> wrote:
Is there a way to make sure that probcons-extra will depend on the
probcons package with the same version as itself?
Yes.
Just use
Depends: probcons (= ${Source-Version})
inside the probcons-extra section.
Best regards,
Nelson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] museek+: file-sharing application for the SoulSeek peer-to-peer network
Lukáš Lalinský a écrit : Adam Cécile (Le_Vert) wrote: * museek-python-bindings : Python bindings for the C++ daemon I think the name of this package should be "python-museek". http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names Package updated :) http://www.le-vert.net/divers/debian-packages/museek+/ http://www.le-vert.net/divers/debian-packages/museek+/museek+_0.1.9-1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: hearts-0.1-1 -- The classic Hearts card game for the GNOME desktop
James Westby wrote: On (05/06/06 14:10), Eddy Petri??or wrote: You could take care of this warning, first thing (just looked over the build log) "W: hearts source: newer-standards-version 3.7.2.0" Generally that would mean just bumping the standards version, but you should check. That warning is the other way round, the standards version defined in debian/control is newer that the latest lintian knows about. It is a false positive in this case, as Lintian has not been updated to recognise the latest version. Yes, I have the same thing. Unfortunately I cannot update lintian or linda. I built the source package on ubuntu dapper. Lintian/linda ultimately depend on glibc and I get a version conflict between debian's glibc and ubuntu's glibc if I try installing them manually. I would say remove DEB_TAR_SRCDIR := hearts-0.1 DEB_AUTO_CLEANUP_RCS:= yes Done. from debian/rules. (I think the second is unecessary). You could also put a statement something like The Debian packaging is (C) 2006, Sander Marechal <[EMAIL PROTECTED]> and is licensed under the GPL version 2 or later, see above. in debian/copyright. Done. The files on my website have been re-uploaded. Thanks for the suggestions. -- Sander Marechal http://www.gnome-hearts.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: geany
Hi, I'm looking for a sponsor for my program Geany. Package name: geany Version : 0.7 Upstream Author : Enrico Tröger (me ;-)) URL : http://geany.uvena.de/ License : GPL Programming Lang: C, C++ Description : A fast and lightweight IDE using GTK2 Geany is a small and fast editor with basic features of an integrated development environment. It has some nice features like code completion, call tips, code folding and symbol/tag lists. Geany supports 19 different filetypes. It is actively developed (by me) and it aims to be small and fast. Download: http://debian.uvena.de/unstable/geany_0.7-1.diff.gz http://debian.uvena.de/unstable/geany_0.7-1.dsc http://debian.uvena.de/unstable/geany_0.7-1_i386.changes http://debian.uvena.de/unstable/geany_0.7-1_i386.deb http://debian.uvena.de/unstable/geany_0.7.orig.tar.gz or just use deb http://debian.uvena.de/ ./unstable/ This is my first RFS and the first Debian package which is not only built for me. Could there be any problems because I'm the maintainer and upstream? regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.key Geany, a lightweight IDE using GTK2 - http://geany.uvena.de pgpuRnuTDv7cX.pgp Description: PGP signature
RFS: collectd - statistics collection daemon
Hi, I'm looking for a sponsor for my collectd package. collectd is a small daemon that collects various system statistics and saves them to RRD files. Since it is written in C and stays in memory it is very fast and easy on the system. The statistics are very fine grained since the files are updated every 10 seconds. The package is linda and lintian clean and builds with pbuilder. The source package is available from http://debian.tokkee.org/debian.org/collectd/ Thanks a lot in advance. Cheers, Sebastian -- Sebastian "tokkee" Harl GnuPG-ID: 0x8501C7FC http://tokkee.org/ signature.asc Description: Digital signature
lost ITP?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've sent an ITP on libvrb last night (at about 23:19 CET), but I cannot see it on d-d and in the BTS. However, I got the copy to my personal inbox. I saw ITPs on d-d and in the BTS posted this afternoon. Is it possible that the ITPs are not processed in FIFO-style? Or should I forward the ITP from my inbox to somewhere? Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEhEtWGJRwVVqzMkMRAjQiAJ43mqbrDNLZoA66QNOXy1CM7v4/9wCgkyxS 5pCmb/syttclWskhalNypv8= =zJDI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
On Mon, 2006-06-05 at 09:29 -0300, Nelson A. de Oliveira wrote:
> Just use
> Depends: probcons (= ${Source-Version})
Please don't use Source-Version - from the dpkg-gencontrol manual:
"The source package version (from the changelog file). This variable is
now deprecated as its meaning is different from its function, please use
the source:Version or binary:Version as appropriate."
The reason that this is depreciated is that it was causing packages to
be inappropriately not binNMUable, which is annoying for the release
managers.
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: RFS: geany
On Mon, 2006-06-05 at 16:26 +0200, Enrico Tröger wrote: > Geany is a small and fast editor with basic features of an integrated > development environment. It has some nice features like code > completion, call tips, code folding and symbol/tag lists. Geany > supports 19 different filetypes. It is actively developed (by me) and > it aims to be small and fast. I was checking, but could not figure out how it is different to the very similar looking Anjuta? > Could there be any problems because I'm the maintainer and upstream? None. It's even better. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: geany
On Mon, 05 Jun 2006 20:12:51 +0200, Laszlo Boszormenyi <[EMAIL PROTECTED]> wrote: > On Mon, 2006-06-05 at 16:26 +0200, Enrico Tröger wrote: > > Geany is a small and fast editor with basic features of an > > integrated development environment. It has some nice features like > > code completion, call tips, code folding and symbol/tag lists. Geany > > supports 19 different filetypes. It is actively developed (by me) > > and it aims to be small and fast. > I was checking, but could not figure out how it is different to the > very similar looking Anjuta? Geany is smaller and has less features but therefore it is faster and doesn't blow up the user with unneeded, complicated things. Another important point is, that Geany _only_ depends on GTK2(and its dependencies), Anjuta need a lot of gnome libraries. This is one of the most important reasons I wrote Geany and why people use it. I think Geany is easier to use but this is very subjective because I'm the developer ;-). > > Could there be any problems because I'm the maintainer and upstream? > None. It's even better. Good. Nice to hear. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.key Geany, a lightweight IDE using GTK2 - http://geany.uvena.de pgpLhocJJYqyt.pgp Description: PGP signature
Re: RFC/RFS: bfilter, aspell-hr, myspell-hr
Thanks for uploading. I see that parser at NEW didn't catch the "Closes:" line. I will close that bug once it's accepted. Two more questions. What is the default procedure after I make a new revision or new upstream release arrives? Upload to mentors and inform you? What if I receive a bugreport which I don't know how to solve? For example, a FTBFS on some "exotic architecture"? Regards, Vedran Furač
Re: RFC/RFS: bfilter, aspell-hr, myspell-hr
Vedran Furaè <[EMAIL PROTECTED]> wrote: > Thanks for uploading. I see that parser at NEW didn't catch the "Closes:" > line. I will close that bug once it's accepted. If you used the right syntax, that probably happened because it wasn't part of the last changelog entry, in which case dpkg-buildpackage's -v option should have been used for the upload. Otherwise, it's a bug and should be reported. > What if I receive a bugreport which I don't know how to solve? For > example, a FTBFS on some "exotic architecture"? For this specific example, you should look for appropriate mailing-lists (the porters for that architecture / buildd admins, or a list for Debian users of that architecture). You should be able to find these lists on http://www.debian.org/ports/ (otherwise, Google and file a bug report to get www.debian.org updated). More generally, if there is a bug you really don't know how to solve, you can file an RFH bug on wnpp (Request For Help) to tell the world about it. See: http://lists.debian.org/debian-devel-announce/2004/08/msg0.html -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: optional building of a package
Hi!
On 6/5/06, Paul Wise <[EMAIL PROTECTED]> wrote:
On Mon, 2006-06-05 at 09:29 -0300, Nelson A. de Oliveira wrote:
> Just use
> Depends: probcons (= ${Source-Version})
Please don't use Source-Version - from the dpkg-gencontrol manual:
"The source package version (from the changelog file). This variable is
now deprecated as its meaning is different from its function, please use
the source:Version or binary:Version as appropriate."
The reason that this is depreciated is that it was causing packages to
be inappropriately not binNMUable, which is annoying for the release
managers.
Hmm... good to learn this!
Thank you very much!
All the best,
Nelson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Avoiding the Linux version of "DLL Hell"...
I'm a realtively new user of Linux and Debian. It took me a while to get used to the way software is installed on Linux, although I think I'm finally getting the hang of it. I've got some limited programming experience, and I'd like to take my experience with Debian's packaging system to the next level by creating my own packages. I've downloaded the Debian Mantainer's Guide, but I've got a question about Debian packages and dependencies. The question stems from a problem I seem to run into a lot with my Debian box. I want to install a Debian package named "Package A". Package A lists as a dependency another Debian package named "Library A". However, if Package A requires version 2.0 of "Library A", while another Debian package I have installed on my system, named "Package B" requires version 1.0 of Library A that I already have installed. Here is my question. Can I create a custom Debian package for Library A that satisfies the dependency requirements of Package A, but still keep the older version of Library A required by my other programs? In essence, I want to create my own custom Debian Packages to avoid conflicts in package dependencies. Is this plausible? Thanks for the advice. I look forward to being able to contribute useful packages to the Debian Community. Scott Huey
Re: Avoiding the Linux version of "DLL Hell"...
Redefined Horizons <[EMAIL PROTECTED]> wrote: > I want to install a Debian package named "Package A". > Package A lists as a dependency another Debian package named "Library A". > However, if Package A requires version 2.0 of "Library A", while another > Debian package I have installed on my system, named "Package B" requires > version 1.0 of Library A that I already have installed. In an ideal world, this wouldn't happen; - Library packages should be named not only after the library they provide, but the ABI version of that library as well. (eg; libgnutls11, libgnutls12, libgnutls13). - Binaries depend on the package that contains the version of the library they were compiled against. - These libraries have unique sonames (the stuff that comes after the ".so" in the filename; libgnutls.so.11, etc) - These libraries should never conflict, *however* in most cases their -dev packages probably should (because the -dev package provides the root ".so" that ld/libtool looks for, as well as header files specific to that ABI/API). Of course, not every library comes out in such an "ideal" way, but those that don't are a pain to properly link against anyway. :-) > Here is my question. Can I create a custom Debian package for Library A > that satisfies the dependency requirements of Package A, but still keep > the older version of Library A required by my other programs? > > In essence, I want to create my own custom Debian Packages to avoid > conflicts in package dependencies. Is this plausible? Definately, although building such a package sounds a little bit convoluted. If you actually *need* this, then it probably means that said library was either improperly packaged or improperly developed, so maybe a bug should be raised against the offending package(s) too. :-) > Thanks for the advice. I look forward to being able to contribute useful > packages to the Debian Community. Me too! Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Avoiding the Linux version of "DLL Hell"...
"Redefined Horizons" <[EMAIL PROTECTED]> wrote: > Here is my question. Can I create a custom Debian package for Library A that > satisfies the dependency requirements of Package A, but still keep the older > version of Library A required by my other programs? Of course. Look for example at the GTK+ library. In both sarge and sid, you'll find GTK+ 1.2 and GTK+ 2 (packages libgtk*), as well as packages using GTK+ 1.2, and packages using GTK+ 2. > In essence, I want to create my own custom Debian Packages to avoid > conflicts in package dependencies. Is this plausible? Yes, dpkg allows you to express dependencies in a comfortable way. Besides the New Maintainer's Guide, which you've already found, you should really read the Debian Policy to get a better understanding of these things. HTH, -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Avoiding the Linux version of "DLL Hell"...
Thank you Florent and Tyler. You have answered my questions. Tyler, What is the proper procedure for notifying the maintainer of a package about the dependency problem? Florent, Where do I find the "Policy" that you speak of? Scott Huey On 6/5/06, Florent Rougon <[EMAIL PROTECTED]> wrote: "Redefined Horizons" <[EMAIL PROTECTED] > wrote:> Here is my question. Can I create a custom Debian package for Library A that> satisfies the dependency requirements of Package A, but still keep the older> version of Library A required by my other programs? Of course. Look for example at the GTK+ library. In both sarge and sid,you'll find GTK+ 1.2 and GTK+ 2 (packages libgtk*), as well as packagesusing GTK+ 1.2, and packages using GTK+ 2.> In essence, I want to create my own custom Debian Packages to avoid > conflicts in package dependencies. Is this plausible?Yes, dpkg allows you to express dependencies in a comfortable way.Besides the New Maintainer's Guide, which you've already found, youshould really read the Debian Policy to get a better understanding of these things.HTH,--Florent--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Avoiding the Linux version of "DLL Hell"...
Redefined Horizons <[EMAIL PROTECTED]> wrote: > Tyler, > What is the proper procedure for notifying the maintainer of a package about > the dependency problem? A good way is to use the "reportbug" utility that comes with debian; "reportbug ". Cheers, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Avoiding the Linux version of "DLL Hell"...
On 06/05/2006 07:42 PM, Redefined Horizons wrote: > Where do I find the "Policy" that you speak of? Check the Developers' Corner[1], you'll find lots of links to relevant documentation. Please do not top post[2]. K.- [1] http://www.debian.org/devel/ [2] http://en.wikipedia.org/wiki/Top_posting -- Lucas Wall <[EMAIL PROTECTED]> .''`. Buenos Aires, Argentina: :ø : Debian GNU/Linux http://www.kadath.com.ar `. `' http://www.debian.org PGP: 1024D/84FB46D6 `- 5D25 528A 83AB 489B 356Ahttp://people.debian.org/~lwall 4087 BC9B 4733 84FB 46D6mailto:[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: Debian package without released upstream source
Hallo Goswin, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Just make sure to use a version that sorts lower than a future actual > 2.2 release. Optimaly 2.2~beta2 would be used but I think the DAK > still doesn't accept those. 2.1.99+2.2-beta might be a good choice. Good objection. I've changed this. In a PM, someone raised the objection that the source tar.gz might be a temporary file. I assume this, too. But I expect when upstream removes this file, it places a new one at sourceforge. Does anyone share this objection? Should I not use this tar ball? BTW: What can I do, if I can't run pbuilder? Exist an open pbuilder network? I've split the package in a architecture dependent and independent package, because lintian complained about a huge /usr/share. Now I need to verify if my split build dependencies are correct. Bye, Jörg. -- "UNIX was not designed to stop people from doing stupid things, because that would also stop them from doing clever things." -- Doug Gwyn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
