Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Fri, 17.06.11 11:16, Robert Millan (r...@debian.org) wrote: > > 2011/6/17 Joachim Breitner : > > I have applied and uploaded this patch to the Debian package. If there > > will be a better patch that addresses the ifindex issue, I’ll be happy > > to apply that as well. > > Thanks Joachim. I may have a look at improving this, though not right now. > > > BTW, Lennart, I am also applying the attached patch because > > HOST_NAME_MAX does not always exist. If you could include that patch in > > the next version as well, that would be great, as it further reduces the > > difference to the Debian version. > > GNU/kFreeBSD has MAXHOSTNAMELEN, so you could just use this > macro if HOST_NAME_MAX isn't defined. Please don't hardcode such > limits unnecessarily. Is there any good reason why kfreebsd does not set HOST_NAME_MAX but MAXHOSTNAMELEN? Or is it just to annoy people and to litter other people's code with ifdef orgies? HOST_NAME_MAX is POSIX, so I see really no reason to add some compat kludgery, for MAXHOSTNAMELEN. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html Fix your glibc first. And if there's a really good reason not to, then at least supply me with a patch, because otherwise I don't care. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Fri, 17.06.11 09:56, Joachim Breitner (nome...@debian.org) wrote: > Hi, > > Am Dienstag, den 14.06.2011, 23:01 +0200 schrieb Robert Millan: > > 2011/6/14 Lennart Poettering : > > > if LEGACY > > > foo_SOURCES += legacy.c > > > else > > > foo_SOURCES += netlink.c > > > endif > > > > > > In the Makefile.am file. > > > > Here. > > I have applied and uploaded this patch to the Debian package. If there > will be a better patch that addresses the ifindex issue, I’ll be happy > to apply that as well. Hmpf. If you don't fix it nobody will. When I merged this I kinda expected you'd be providing a follow-up patch to fix this. I am not sure I want to leave it in like this, because I'll take the blame for this. Hence, I will revert the patch before the next release if this is not fixed properly. > BTW, Lennart, I am also applying the attached patch because > HOST_NAME_MAX does not always exist. If you could include that patch in > the next version as well, that would be great, as it further reduces the > difference to the Debian version. Ah, one of those Hurd "features". How useless... Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Thu, 16.06.11 10:59, Robert Millan (r...@debian.org) wrote: > > 2011/6/15 Lennart Poettering : > > I have commited this now, though I am pretty sure this is actually > > broken. You cannot just go and make up ifindexes. You need to determine > > the kernel ifindexes for your interfaces. You probably simply need to > > call if_nametoindex() on all ifa_name fields. > > In my tests I didn't observe any ill effects. What is this needed for? It's used all over the place. For example on IPv6 the ifindex is required to make link-local addresses usable. (i.e. a link-local address is private to a specific link, hence you need to specify the link explicitly by means of the ifindex it is behind, which normally happens automatically if you use getaddrinfo() but will not work for you.) Also quite a few other APIs use ifindexes, for example the mcast APIs, or IP_PKTINFO or IP_RECVINTERFACE or IPV6_PKTINFO or IP_MULTICAST_IF. In general it is smart never to deal with interface names internally in apps, but use ifindexes instead, since names can be changed dynamically, and indexes are fixed during the entire existance of an interface. interface names should only be use in user configuration and for presentation purposes. (i.e. on the way in our out of a process, but not in the process itself). So, in short: you are at least breaking mcast, breaking link-local addressing and matching up of addresses with packets right now. And there's probably a lot more. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Tue, 14.06.11 23:01, Robert Millan (r...@debian.org) wrote: > 2011/6/14 Lennart Poettering : > > if LEGACY > > foo_SOURCES += legacy.c > > else > > foo_SOURCES += netlink.c > > endif > > > > In the Makefile.am file. > > Here. I have commited this now, though I am pretty sure this is actually broken. You cannot just go and make up ifindexes. You need to determine the kernel ifindexes for your interfaces. You probably simply need to call if_nametoindex() on all ifa_name fields. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Tue, 14.06.11 17:49, Robert Millan (r...@debian.org) wrote: > 2011/6/13 Lennart Poettering : > >> +#ifdef __linux__ > >> +#include "netlink.c" > >> +#else > >> +#include "legacy.c" > >> +#endif > > > > Urks, no. Please do this in Makefile.am. > > Tried that, but it's a no-go. Automake doesn't support > build time substitutions in _SOURCES AFAICT (its maintainers > seem to confirm this in > http://lists.gnu.org/archive/html/automake/2008-08/msg00047.html) Uh? No. Please use autoconf conditions and then do if LEGACY foo_SOURCES += legacy.c else foo_SOURCES += netlink.c endif In the Makefile.am file. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Mon, 13.06.11 14:13, Robert Millan (r...@debian.org) wrote: > tags 630206 patch > thanks > > 2011/6/13 Robert Millan : > > 2011/6/13 Lennart Poettering : > >> I think it is a major waste of time thinking about BSD and Hurd. > >> > >> That said, I'd be willing to merge a patch that adds support for those > >> legacy systems -- if it is minimal. Note however that it wouldn't be > >> release critical to me, i.e. I will not care if it works or not when > >> releasing a new version. But I geuss that doesn't matter much since it > >> is quite a finished project and I expect very few updates in the future. > > > > Seems simple enough, I'll give it a try. > > Patch attached. To be applied after "mv netlink.h ifconf.h". Sounds mostly good. Can you prep a proper git patch please? > diff -Nur -x aclocal.m4 -x configure -x doc libnss-myhostname-0.3/ifconf.c > libnss-myhostname-0.3.new/ifconf.c > --- libnss-myhostname-0.3/ifconf.c1970-01-01 01:00:00.0 +0100 > +++ libnss-myhostname-0.3.new/ifconf.c2011-06-13 14:06:34.0 > +0200 > @@ -0,0 +1,5 @@ > +#ifdef __linux__ > +#include "netlink.c" > +#else > +#include "legacy.c" > +#endif Urks, no. Please do this in Makefile.am. > diff -Nur -x aclocal.m4 -x configure -x doc libnss-myhostname-0.3/ifconf.h > libnss-myhostname-0.3.new/ifconf.h > --- libnss-myhostname-0.3/ifconf.h2011-05-09 15:00:58.0 +0200 > +++ libnss-myhostname-0.3.new/ifconf.h2011-06-13 14:01:28.0 > +0200 > @@ -3,6 +3,8 @@ > #ifndef foonetlinkhfoo > #define foonetlinkhfoo Please fix the header here. > +fd = socket (AF_INET6, SOCK_DGRAM, 0); Please follow the coding style, we do not place a space between the function name and the opening bracket. Also, this will obviously fail if IPv6 is not enabled. I personally don't care about that, but I am pretty sure the same kids who care about Hurd also care about IPv6-free systems. It's up to you if you want to fix this. I'd merge it either way. This gets particularly strange given that SIOCGIFCONF according to the (Linux) man page only returns IPv4 addresses. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630206: libnss-myhostname: FTBFS: fatal error: asm/types.h: No such file or directory
On Sun, 12.06.11 21:35, Joachim Breitner (nome...@debian.org) wrote: > Hi Christoph, Hello Lennart, > > Am Sonntag, den 12.06.2011, 12:34 +0200 schrieb Christoph Egger: > > Package: src:libnss-myhostname > > Version: 0.3-1 > > Severity: serious > > Tags: sid wheezy > > Justification: fails to build from source (but built successfully in the > > past) > > > > Hi! > > > > Your pacage failed to build on the kfreebsd-* buildds: > > libtool: compile: x86_64-kfreebsd-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. > > -I/build/buildd-libnss-myhostname_0.3-1-kfreebsd-amd64-oyrjWQ/libnss-myhostname-0.3 > > -include ./config.h -Wall -g -O2 -Wall -W -Wextra -pedantic -pipe -Wformat > > -Wold-style-definition -Wdeclaration-after-statement -Wfloat-equal > > -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes > > -Wredundant-decls -Wmissing-noreturn -Wshadow -Wendif-labels > > -Wpointer-arith -Wcast-align -Wwrite-strings -Winline -Wno-unused-parameter > > -ffast-math -fvisibility=hidden -fdiagnostics-show-option -MT netlink.lo > > -MD -MP -MF .deps/netlink.Tpo -c > > /build/buildd-libnss-myhostname_0.3-1-kfreebsd-amd64-oyrjWQ/libnss-myhostname-0.3/netlink.c > > -fPIC -DPIC -o .libs/netlink.o > > /build/buildd-libnss-myhostname_0.3-1-kfreebsd-amd64-oyrjWQ/libnss-myhostname-0.3/netlink.c:25:23: > > fatal error: asm/types.h: No such file or directory > > compilation terminated. > > make[3]: *** [netlink.lo] Error 1 > > > > Full build log at > > https://buildd.debian.org/status/fetch.php?pkg=libnss-myhostname&arch=kfreebsd-amd64&ver=0.3-1&stamp=1307742167 > > > > If you have further questions please mail debian-...@lists.debian.org > > > it seems that nss-myhostname has changed the way it acquires link > addresses between versions 0.2 to 0.3 to make use of the netlink > interface. This breaks the package on hurd and freebsd kernels. What > should we do here? I see three options: I think it is a major waste of time thinking about BSD and Hurd. That said, I'd be willing to merge a patch that adds support for those legacy systems -- if it is minimal. Note however that it wouldn't be release critical to me, i.e. I will not care if it works or not when releasing a new version. But I geuss that doesn't matter much since it is quite a finished project and I expect very few updates in the future. So yupp, if you send me a minimal, non-intrusive patch with proper coding style that does not pollute the Linux code I'd be willing to merge it. The emphasis is on non-intrusive minimalism. > B. Ask Lennart to try to make his program portable. Nah, I will not work on this. Netlink is Linux specific -- it cannot be made on the legacy kernels, and I don't care for the legacy kernels anyway and won't spend time on them. Lennart -- Lennart Poettering - Red Hat, Inc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#393711: Authoritative .local support in nss-mdns / avahi-daemon
On Sun, 24.12.06 22:09, Loïc Minier ([EMAIL PROTECTED]) wrote: Hi! > I just uploaded a nss-mdns NMU which I think addresses the RC issues of > this particular package. One of the major changes is that it now > requires avahi-daemon to resolve .local entries. IIUC, the proper way > to support networks where ".local" is a real domain name is to disable > avahi-daemon when a nameserver claims to have a SOA for the .local > domain. This check should be made everytime the DNS settings change > and on boot, so I think the simplest way is to: > 1) check whether there's a SOA for .local before starting avahi-daemon, > and do not really start it when a start was requested but a SOA was > found > 2) restart avahi-daemon in a dhclient hook to make sure the test is > run with the new DNS settings > 3) restart avahi-daemon in a resolvconf hoook to make sure the test is > run with the new DNS settings The dhclient hook should not be run if resolvconf is installed - because otherwise the hook script might be run twice! The Ubuntu script just silently stops Avahi. This is suboptimal, the user should get some feedback about this. Notifications with the DBUS notification-daemon would be a good thing. Unfortunately, that daemon is solely a session daemon, i.e. it's service cannot be used from a system script. :-( An alternative would be syslog: if test -x /usr/bin/logger ; then logger -p daemon.warning -t avahi < Or something like that. Perhaps we should add a page to our avahi.org wiki and explain the situation there and link it from that syslog message. > I wish you all a Merry Christmas! And if you need to catch me, you > can I wish you a happy new year! Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Bug#393711: libnss-mdns: /etc/nsswitch.conf configuration is broken
80:: as it is used > for link-local addresses (anyone please correct me). Same as IPv4ll here: this range has been defined by the IETF for exclusive link-local use. If anyone uses this for any other purpose he must be very misled or likes to shoot himself in the foot. With a very big gun. Using fe80: or 169.254.0.0 for anything but ll addressing is as stupid as using ::1 or 127.0.0.1 on eth0. > Perhaps it makes sense to run such a test suite on IPv4 and IPv6 > separately, in order to turn on mDNS for one or the other or both (or > to leave it off). > > Part 2) could typically be a /etc/default/libmdns file with > MDNS_BACKWARD_COMPATIBILITY=0 or 1. In the abscence of this file, > cached debconf responses would be used, and in the abscence of these, > the default value would be computed with the test suite, and if debconf > is at low priority, the user would get a debconf screen to override the > guess. As mentioned above, /etc/default/avahi-daemon can be used for this if nss-mdns is compiled with --disable-legacy. > Part 3) could typically be offered by an "enable-mdns" script or > similar, as I believe is nowadays found under Ubuntu to enable mDNS. > This script would simply enforce whatever /etc/default/libmdns has, or > follow command line options. This script could also serve as a > lower-level "force turning off mDNS" or "force turning on mDNS" > administrative tool. >This script could also be called for part 1), this would permit > re-running the auto-detection. /etc/default/avahi-daemon also solves this. > > Obvious problem of the proposal: roaming users with laptops. These > people should decide to either use .local for mDNS or for one of their > site. The resolvconf hook solves this issue. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Bug#393711: libnss-mdns: /etc/nsswitch.conf configuration is broken
Package: libnss-mdns Version: 0.8-6 Severity: serious Hi! The configuration that is patched into /etc/nsswitch.conf by libnss-mdns 0.8-6 is just plain broken and against everything upstream (who happens to be me) or any other person who has any clue about mDNS recommends. The line upstream suggests looks like this: hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 This line resembles closely the behaviour MacOSX - the OS which pioneered mDNS - exposes. Everything else is much worse in its behaviour. In contrast, the line your package version adds has several disadvantages, among them: * Slows down all mDNS lookups * Breaks mDNS lookups when the configured DNS server is not reachable (!) * Is a security hole, because local host info is leaked on unicast dns server and as such the internet * Is a security hole, because people on the internet can redirect local services to other hosts * Increases the burden on internet DNS servers needlessly. (This is a major problem which caused the creation of projects like AS112) * Breaks mDNS RR consistency because the unicast DNS zone .local is kind-of merged with the multicast DNS zone .local. However, the conflict protocol which makes sure that no two host names or service names conflict in the .local zone simply doesn't work against names from the .local unicast domain. In short: while upstream proposes a sensible, working line, your package pointlessly fucks it up and is thus simply broken. Sure, the line upstream recommends has also one disadvantage, which is that it is inherently incompatible with unicast DNS domains called .local. But that's the way mDNS has been designed, and is a simple fact that has to be dealt with administratively and not through applying ugly kludges to upstream's clean code. For further discussion see bug #388864 where many points mentioned above were already discussed. Several people showed interest in maintaining nss-mdns in Debian. As you seem to give a fuck about upstream's technical opinion on these issues or even on the opinions of the mDNS/DNS-SD *designers*, and it is clear that your relationship to upstream is not the best, may I suggest that you simply orphan this package and have someone else looking after it? I am fully aware that you happen to have access to a network where .local is a unicast domain name. Due to this you seem to value compatiblity with that network more than correct behaviour of mDNS. However, Debian is not just about you, but about its users - all of them. If you insist that your line is the better one and refuse to change it to the line I recommend and don't want to orphan the package, then I kindly ask you to fork my package and rename your copy. And please don't put "mdns" in the new package name, since the behaviour you advocate is clearly not the standard mDNS behaviour. Please understand that I don't want to be connected to the broken behaviour your nss-mdns package exposes any longer. Lennart -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libnss-mdns depends on: ii base-files 3.1.16 Debian base system miscellaneous f ii libc62.3.6.ds1-4 GNU C Library: Shared libraries libnss-mdns recommends no packages. -- no debconf information -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392813: looking at this bug..
On Sat, 14.10.06 23:11, Walter Hofmann ([EMAIL PROTECTED]) wrote: > > DO NOT USE "search local" UNLESS YOU REALLY KNOW WHAT YOU DO! And if > > you do use it, don't file bugs about it. I am fully aware that it is > > problematic. > > I read between the lines that the .local domain is something special for > nss-mdns!? Yes, that's exactly the case. .local is the multicast DNS domain. All host names ending in .local are resolved exclusively via mDNS if nss-mdns is installed. > But I definitely need "search local" in resolv.conf. Otherwise, random > services on this machine will break because I didn't enter the fqdn in > many places. I guess then you should disable or deinstall nss-mdns. > But somehow, problably due to some dependency or recommendation, > nss-mdns got installed on my system and gets in bind's way. > So whether nss-mdns does or doesn't support "search local" is of no > concern to me -- I just doesn't want it to interfere with my otherwise > working setup. I am sorry, but I guess your setup is simply incompatible with Zeroconf/Bonjour/Rendezvous/mDNS/DNS-SD/Avahi. If you cannot fix your setup to use a different unicast DNS domain, then I guess you should probably deinstall Avahi and nss-mdns, or a least disable it. It won't work reliable in such a setup. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392813: [EMAIL PROTECTED]: Stop! Wait!]
On Sat, 14.10.06 16:15, Joey Hess ([EMAIL PROTECTED]) wrote: > The problem in the context of Debian is that we're taking previously > working systems that happen to search local, and breaking them by > auto-enabling mdns. I agree that if a user has a working system that > uses madns and adds "search local" to it, it's not a big deal when it > starts being slow and/or breaking[1]. But this is a bit different, and > seems to at least need to be fixed in the context of the Debian > package. I see the problem. Maybe the perl script should not touch /etc/nsswitch.conf if it sees that mdns is already listed there or if "search local" is included in /etc/resolv.conf. The latter check might be useful in all cases because it is either a hint that the users has a unicast-DNS domain called ".local" or that the user manually configured nss-mdns in a way it suited him best. In both cases the package shouldn't touch the user's configuration, I would argue. > One option would be for the Debian package to warn about this at > install/upgrade time, and either remove the search local, or remove the > nsswitch.conf entries. "Not touching" seems to be a better strategy in my eyes, if any of the magic words are already found in the resolver configuration files. BTW: to make "search .local" working properly would require hacking the resolver itself. This is not possible with NSS modules alone, unfortunately. Hacking the resolver is essentially patching the libc, which is nothing I am so keen on. Apple did something like that for MacOSX, but I am not convinced that this is really a good idea in the first place. When I looked into this the last time I came to the conclusion that doing this might offer a few advantages but also creates a lot of disadvantages, which seem to overweight in my eyes. (the major issue being that it makes it much more difficult to disable the mDNS functionality, in addition it is kludgy by definition, because the resolver semantics do not really match the mDNS semantics.) Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392813: looking at this bug..
On Sat, 14.10.06 15:59, Joey Hess ([EMAIL PROTECTED]) wrote: Seems my last mail crossed yours on the way. > Part of the problem is that your /etc/resolv.conf has "search local". > This means that every dns lookup is first tried in the "local" domain, > so it's trying to look up google.com.local. > > If I configure my system the same, with "search local" and avahi disabled, > I can get similar results: > > Could nss-mdns be changed to check for a resolv.conf with "search local" and > somehow avoid all the unnecessary mdns queries for every (!!) dns lookup that > are entailed? Or maybe it could return immediately for domains like > google.com.local while doing its thing for foo.local? Don't use "search local". It will always produce problems like this one. > > (I'd like to be able to put "search local" in my resolv.conf, for networks > that don't have any other dns than mdns, so it seems like a legitimate thing > to want to do.) As I already wrote in my last email, the "search local" is indeed the problem. It is explicitly *not recommended* to use "search local". If people choose to use it it's their problem. "search local" has lots of problems. This one is only one of them. The "search local" functionality is *only* useful in setups where traditional DNS is not used *at all*. In all other cases, don't use it, it causes all kinds of problems and will slow down all lookups. I am really surprised that so many people actually make use this configuration option. I never documented it for nss-mdns. Only a minor entry in my changelog even mentions it. To stress this once more: DO NOT USE "search local" UNLESS YOU REALLY KNOW WHAT YOU DO! And if you do use it, don't file bugs about it. I am fully aware that it is problematic. (Yes, this particular problem is fixable, and I will eventually do so, but it's low-priority to me) Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378608: error building nss-mdns: configure: error: tag name "CXX" already exists
On Thu, 10.08.06 00:22, Sam Morris ([EMAIL PROTECTED]) wrote: > I just realised that the Debian package regenerates all the autotools > stuff! Running the configure script from the pristine upstream tarball > works fine--so I guess this is Debian specific breakage. :/ Ok, then I guess I can leave to the Debian maintainers to fix it. ;-) Oh, and BTW, libtool sucks. Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
