Bug#904102: locales: Interface is in english but french is set.
Package: locales Version: 2.27-3 Severity: normal Dear Maintainer, I set my interface in french (i have only FR in locales list) But not working, only english. In gnome setting panel i have mixed language : Menu is in French and content is in english. Thank you alexandre@debian:~$ locale LANG=fr_FR.UTF-8 LANGUAGE= LC_CTYPE="fr_FR.UTF-8" LC_NUMERIC=fr_FR.UTF-8 LC_TIME=fr_FR.UTF-8 LC_COLLATE="fr_FR.UTF-8" LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES="fr_FR.UTF-8" LC_PAPER=fr_FR.UTF-8 LC_NAME="fr_FR.UTF-8" LC_ADDRESS="fr_FR.UTF-8" LC_TELEPHONE="fr_FR.UTF-8" LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION="fr_FR.UTF-8" LC_ALL= -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-rc7-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages locales depends on: ii debconf [debconf-2.0] 1.5.67 ii libc-bin 2.27-3 ii libc-l10n 2.27-3 locales recommends no packages. locales suggests no packages. -- debconf information: * locales/locales_to_be_generated: fr_FR ISO-8859-1, fr_FR.UTF-8 UTF-8, fr_FR@euro ISO-8859-15 * locales/default_environment_locale: fr_FR.UTF-8
Bug#714219: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
On Jul 1, 2013, Thorsten Glaser wrote: > This would always avoid returning a NULL value, thus unbreaking > all applications that use that assumption. It seems to me that this would turn a very visible fault into a silent fault. In general, the former is more desirable; consider how much headscratching would ensue should a password mysteriously fail to be recognized, compared with that resulting from a segfault for dereferencing the result of crypt. > the argument that crypt() must either always return NULL or never, That argument is only valid as long as you're within standard-specified boundaries. The standard specifies a limited alphabet for the salt, and if you pass in arguments that don't satisfy the specified requirements, all best are off as far as the standard is concerned. It's undefined behavior, that could take such forms as returning NULL or any random pointer to garbage, crashing, running DES or any other algorithm on the inputs disregarding or not the salt, stealing your life partner or destroying the universe ;-) Indeed, once we frame the situation as “POSIX crypt implements DES”, and combine that with “FIPS mandates no DES”, the only possible outcome of combining both requirements is to conclude that POSIX crypt must be disabled altogether, which is perfectly compatible with returning NULL and setting errno when crypt is called in a standard-compliant way: that functionality is not available. Now, once you bring extensions to the standard into the picture, then the requirements from the standard are no longer strictly applicable. That's why the choice of alternate encryption algorithms is done using salt characters that are outside the POSIX mandated alphabet. Under the “undefined behavior” rule in the standard, it is perfectly acceptable for the implementation to behave however it likes; under the rules of each individual extension, it is perfectly ok for the implementation to recognize the requests for the extension to be used and proceed to encrypt accordingly. Which leaves us with the cases of an extension that is disabled, not implemented, or not even known of. I see no reason to treat them differently it from the case in which DES crypt is requested but it's not available (disabled or not implemented): return NULL, setting errno accordingly. > • returning NULL if it’s not valid DES (or an otherwise unrecognised > algorithm, e.g. #if !__OPTION_EGLIBC_CRYPT_UFC, probably too) is > just the wrong thing to do, and it does break GNU CVS, among others. While I had a great concern with this sort of breakage, to the point of having voiced concerns when I first proposed the patch, and when we first encountered regressions in applications because of it, I also have concern for silent failures that might arise at the introduction or removal of additional extensions selected by out-of-std-alphabet salt. If, when we fail to recognize an extension, we fallback to DES crypt, we generate encrypted passwords that will fail to verify by implementations that recognize the extension, and vice-versa. This is a far more confusing failure mode, which makes it far less desirable to me. At this point, I'd rather we took the opportunity to fix code that makes unsafe assumptions about the behavior of crypt than push the problem on for users to figure out when a glibc upgrade causes passwords to fail to be recognized because the salt suggests the use of a different, newly-recognized encryption algorithm. This is my current rationale for the current implementation, after two rounds of discussion on its merits. I must admit I'm not comfortable with the change that was made to out-of-alphabet DES salt, but ATM I'm even less comfortable with the alternatives. I didn't always favor the current situation, and that might change again depending on arguments I get. But then, I don't have the final word on any of this ;-) So, if the rationale above doesn't make you as (un)happy as I am about the current state of crypt in glibc, please bring forth your counterarguments and let's see if we can all come to a sensible agreement. Anyway, thanks for the report, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/orehbgj44n@livre.home
Problems installing libncurses5-dev
Sorry, but I have this problems installing your package. Alexandre Gondim dos Santos The following packages have unmet dependencies: libncurses5-dev: Depends: libc-dev E: Broken packages Package libc-dev is a virtual package provided by: libc6-dev 2.3.2.ds1-13 You should explicitly select one to install. E: Package libc-dev has no installation candidate The following packages have unmet dependencies: libc6-dev: Depends: libc6 (= 2.3.2.ds1-13) but 2.3.2.ds1-16 is to be installed E: Broken packages __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/
Re: issue with wchar.h
On Tue, 13 Jul 2004 09:15:47 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> Do you not have /usr/include/wchar.h?
No!
> Suggest you reinstall libc6-dev in that case.
Done. /usr/include/wchar.h is now available.
Thanks for your help.
Alexandre
--
Il vente, c'est le vent de la mer qui nous tourmente. - Pierre Mac Orlan
Re: issue with wchar.h
On Tue, 13 Jul 2004 09:15:47 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> Do you not have /usr/include/wchar.h?
No!
> Suggest you reinstall libc6-dev in that case.
Done. /usr/include/wchar.h is now available.
Thanks for your help.
Alexandre
--
Il vente, c'est le vent de la mer qui nous tourmente. - Pierre Mac Orlan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
issue with wchar.h
Hello, I'm the maintainer of Nedit and I have an issue to compile my package with the last version of the libc6 (2.3.2.ds1-13) : [...] make[2]: Entering directory `/home/alex/paquets/nedit/nedit-5.3/util' cc -O -I/usr/X11R6/include -DUSE_DIRENT -DUSE_LPR_PRINT_CMD -DBUILD_UNTESTED_NEDIT -c -o DialogF.o DialogF.c Dans le fichier inclus à partir de /usr/include/libio.h:32, à partir de /usr/include/stdio.h:72, à partir de DialogF.c:28: /usr/include/_G_config.h:24:19: wchar.h : Aucun fichier ou répertoire de ce type [...] gcc cannot find the file wchar.h. This file can be found in /usr/include/bits. If we look gconv.h : #include at the line 28 and for stdin.h : #include Is it normal? Many thanks for your help, and sorry for the disturb if it is not a libc6 issue. Alexandre Pineau ps : please cc me since I'm not subscrived to the list. -- Il vente, c'est le vent de la mer qui nous tourmente. - Pierre Mac Orlan
issue with wchar.h
Hello, I'm the maintainer of Nedit and I have an issue to compile my package with the last version of the libc6 (2.3.2.ds1-13) : [...] make[2]: Entering directory `/home/alex/paquets/nedit/nedit-5.3/util' cc -O -I/usr/X11R6/include -DUSE_DIRENT -DUSE_LPR_PRINT_CMD -DBUILD_UNTESTED_NEDIT -c -o DialogF.o DialogF.c Dans le fichier inclus à partir de /usr/include/libio.h:32, à partir de /usr/include/stdio.h:72, à partir de DialogF.c:28: /usr/include/_G_config.h:24:19: wchar.h : Aucun fichier ou répertoire de ce type [...] gcc cannot find the file wchar.h. This file can be found in /usr/include/bits. If we look gconv.h : #include at the line 28 and for stdin.h : #include Is it normal? Many thanks for your help, and sorry for the disturb if it is not a libc6 issue. Alexandre Pineau ps : please cc me since I'm not subscrived to the list. -- Il vente, c'est le vent de la mer qui nous tourmente. - Pierre Mac Orlan
Bug#223769: libc6: Actually a kernel bug.
On Mon, Jan 05, 2004 at 07:27:42PM -0800, Jeff Bailey wrote : > On Tue, Jan 06, 2004 at 09:37:41AM +0900, GOTO Masanori wrote: > > > >From glibc 2.3.2.ds1-8, libc6.preinst checks kernel version on mips > > because of this IPC issue. I wonder why libc6.postrm in libc6 2.3.2-7 > > causes this error. Alexandre, please show us your kernel version. > > Moreover, please show us where your script was stopped. I think the > > recent version should work. Is this really "grave" bug? Is this bug > > happened on other mips users' machines? > The kernel version is : Linux version 2.4.18 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002 (Debian prerelease)) #2 Fri May 31 17:40:33 BST 2002 You can find the config file at http://debian.zetnet.co.uk/pm/mips-cobalt/kernel/config.full I can't use newer kernel because they just won't compile. I think it is a grave bug because it prevents installing libc6 and so it prevents upgrading a lot of packages. > The clue I'm working on is this: > > Errors were encountered while processing: > /var/cache/apt/archives/libc6_2.3.2.ds1-10_mipsel.deb > > It's mipsel, not mips. My plan was to adjust libc.preinst so that it > picks up the minimum kernel version from the various sysdeps files. The > only complication is hppa, which has strange kernel versions. That way > it would be taken care of for everyone, whenever the minimum version was > updated. > If I have correctly understood, the difference between mips and mipsel is the endianess. -- Alexandre Belloni AE-UTBM: http://ae.utbm.fr - - Lolut: http://lolut.utbm.info Key fingerprint = A7C6 7CD4 4328 59D1 79FD B8BB 945F 4DD5 B634 89BD pgpuvkN9ysmSg.pgp Description: PGP signature
Bug#223769: libc6: Actually a kernel bug.
On Mon, Jan 05, 2004 at 07:27:42PM -0800, Jeff Bailey wrote : > On Tue, Jan 06, 2004 at 09:37:41AM +0900, GOTO Masanori wrote: > > > >From glibc 2.3.2.ds1-8, libc6.preinst checks kernel version on mips > > because of this IPC issue. I wonder why libc6.postrm in libc6 2.3.2-7 > > causes this error. Alexandre, please show us your kernel version. > > Moreover, please show us where your script was stopped. I think the > > recent version should work. Is this really "grave" bug? Is this bug > > happened on other mips users' machines? > The kernel version is : Linux version 2.4.18 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002 (Debian prerelease)) #2 Fri May 31 17:40:33 BST 2002 You can find the config file at http://debian.zetnet.co.uk/pm/mips-cobalt/kernel/config.full I can't use newer kernel because they just won't compile. I think it is a grave bug because it prevents installing libc6 and so it prevents upgrading a lot of packages. > The clue I'm working on is this: > > Errors were encountered while processing: > /var/cache/apt/archives/libc6_2.3.2.ds1-10_mipsel.deb > > It's mipsel, not mips. My plan was to adjust libc.preinst so that it > picks up the minimum kernel version from the various sysdeps files. The > only complication is hppa, which has strange kernel versions. That way > it would be taken care of for everyone, whenever the minimum version was > updated. > If I have correctly understood, the difference between mips and mipsel is the endianess. -- Alexandre Belloni AE-UTBM: http://ae.utbm.fr - - Lolut: http://lolut.utbm.info Key fingerprint = A7C6 7CD4 4328 59D1 79FD B8BB 945F 4DD5 B634 89BD pgp0.pgp Description: PGP signature
Bug#223769: libc6 won't upgrade on mips
Package: libc6 Version: 2.3.2.ds1-10 Severity: grave Hello, I have two cobalts RaQ2 (mips) running Debian Sarge. Upgrading libc6 just doesn't work. Here are the errors : Preparing to replace libc6 2.3.2-7 (using .../libc6_2.3.2.ds1-10_mipsel.deb) ... Unpacking replacement libc6 ... dpkg: warning - old post-removal script returned error exit status 184 dpkg - trying script from the new package instead ... dpkg: error processing /var/cache/apt/archives/libc6_2.3.2.ds1-10_mipsel.deb (--unpack): subprocess new post-removal script returned error exit status 184 dpkg: error while cleaning up: subprocess pre-installation script returned error exit status 255 Errors were encountered while processing: /var/cache/apt/archives/libc6_2.3.2.ds1-10_mipsel.deb E: Sub-process /usr/bin/dpkg returned an error code (1) If I understand correctly the message, it seems it is libc6 2.3.2-7 postrm scrip that is broken. -- Alexandre Belloni AE-UTBM: http://ae.utbm.fr - - Lolut: http://lolut.utbm.info Key fingerprint = A7C6 7CD4 4328 59D1 79FD B8BB 945F 4DD5 B634 89BD pgp8usOHuLT5b.pgp Description: PGP signature
Bug#223769: libc6 won't upgrade on mips
Package: libc6 Version: 2.3.2.ds1-10 Severity: grave Hello, I have two cobalts RaQ2 (mips) running Debian Sarge. Upgrading libc6 just doesn't work. Here are the errors : Preparing to replace libc6 2.3.2-7 (using .../libc6_2.3.2.ds1-10_mipsel.deb) ... Unpacking replacement libc6 ... dpkg: warning - old post-removal script returned error exit status 184 dpkg - trying script from the new package instead ... dpkg: error processing /var/cache/apt/archives/libc6_2.3.2.ds1-10_mipsel.deb (--unpack): subprocess new post-removal script returned error exit status 184 dpkg: error while cleaning up: subprocess pre-installation script returned error exit status 255 Errors were encountered while processing: /var/cache/apt/archives/libc6_2.3.2.ds1-10_mipsel.deb E: Sub-process /usr/bin/dpkg returned an error code (1) If I understand correctly the message, it seems it is libc6 2.3.2-7 postrm scrip that is broken. -- Alexandre Belloni AE-UTBM: http://ae.utbm.fr - - Lolut: http://lolut.utbm.info Key fingerprint = A7C6 7CD4 4328 59D1 79FD B8BB 945F 4DD5 B634 89BD pgp0.pgp Description: PGP signature
Bug#187385: Wine/Mono app crashes with SIGSEGV on dlopen()
After update to glib 2.3.2-1, I've got a different problem. I think it is connected to the __errno_location and __h_errno_location. http://www.winehq.com/index.php?issue=155#Threading%20Problems%20with%20 glibc%202.3 Unfortunately, this happens before Wine calls dlopen(). So, I cannot really confirm resolution of the problem now. But may be successful test of Quake3 Arena (Bug#167564) can also confirm the resolution of this problem. Sincerely, Alexandre Pigolkine -Original Message- From: GOTO Masanori [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 3. April 2003 18:05 To: Alexandre Pigolkine; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#187385: Wine/Mono app crashes with SIGSEGV on dlopen() At Thu, 3 Apr 2003 01:46:18 +0200, Alexandre Pigolkine wrote: > The same problem was reproduced on different computers. > > I think that the behaviour is simular to the one described in NVidia > readme and this will help to resolve the problem: > > ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4349/README.txt > > Q: Some OpenGL applications (like Quake3 Arena) crash when I > start them on Red Hat Linux 9.0. > A: Some versions of the glibc package shipped by Red Hat that support > TLS do not properly handle using dlopen() to access shared libraries > which utilize some TLS models. This problem is exhibited, for example, > when Quake3 Area dlopen()'s NVIDIA's libGL library. Please obtain > at least glibc-2.3.2-11.9 which is available as an update from Red > Hat. We plan to dupload the next version glibc 2.3.2-1, so I think they can be closed at the time. Could you test my experimental glibc 2.3.2-1 and confirm it's resolved or not? I put it: http://people.debian.org/~gotom/ BTW, thanks for the information about Quake3 Arena (Bug#167564) which seems being the same dlopen() bug. Regards, -- gotom
Bug#187385: Wine/Mono app crashes with SIGSEGV on dlopen()
After update to glib 2.3.2-1, I've got a different problem. I think it is connected to the __errno_location and __h_errno_location. http://www.winehq.com/index.php?issue=155#Threading%20Problems%20with%20 glibc%202.3 Unfortunately, this happens before Wine calls dlopen(). So, I cannot really confirm resolution of the problem now. But may be successful test of Quake3 Arena (Bug#167564) can also confirm the resolution of this problem. Sincerely, Alexandre Pigolkine -Original Message- From: GOTO Masanori [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 3. April 2003 18:05 To: Alexandre Pigolkine; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#187385: Wine/Mono app crashes with SIGSEGV on dlopen() At Thu, 3 Apr 2003 01:46:18 +0200, Alexandre Pigolkine wrote: > The same problem was reproduced on different computers. > > I think that the behaviour is simular to the one described in NVidia > readme and this will help to resolve the problem: > > ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4349/README.txt > > Q: Some OpenGL applications (like Quake3 Arena) crash when I > start them on Red Hat Linux 9.0. > A: Some versions of the glibc package shipped by Red Hat that support > TLS do not properly handle using dlopen() to access shared libraries > which utilize some TLS models. This problem is exhibited, for example, > when Quake3 Area dlopen()'s NVIDIA's libGL library. Please obtain > at least glibc-2.3.2-11.9 which is available as an update from Red > Hat. We plan to dupload the next version glibc 2.3.2-1, so I think they can be closed at the time. Could you test my experimental glibc 2.3.2-1 and confirm it's resolved or not? I put it: http://people.debian.org/~gotom/ BTW, thanks for the information about Quake3 Arena (Bug#167564) which seems being the same dlopen() bug. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#187385: Wine/Mono app crashes with SIGSEGV on dlopen()
Package: libc6 Version: 2.3.1-16 Kernel: 2.4.18-bf2.4 Debian GNU/Linux 3.0 with packages from Debian Sid (unstable) When I run Wine application which embeds the Mono JIT engine it crashes at startup. GDB backtrace is: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1286)] 0x40009587 in _dl_catch_error_internal () from /lib/ld-linux.so.2 (gdb) where #0 0x40009587 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #1 0x4032d27d in dlerror () from /lib/libdl.so.2 #2 0x4032ceb7 in dlopen () from /lib/libdl.so.2 #3 0x40106940 in wine_dlopen (filename=0x805e8f0 "/usr/local/lib/wine/kernel32.dll.so", flag=2, error=0x40742bf0 "?'[EMAIL PROTECTED]@??\001@@[EMAIL PROTECTED]", errorsize=256) at port.c:517 #4 0x4010635e in dlopen_dll (name=0x40742d08 "kernel32.dll", error=0x40742bf0 "?'[EMAIL PROTECTED]@??\001@@[EMAIL PROTECTED]", errorsize=256, test_only=0) at loader.c:152 #5 0x4010684a in wine_dll_load (filename=0x40742d08 "kernel32.dll", error=0x40742bf0 "?'[EMAIL PROTECTED]@??\001@@[EMAIL PROTECTED]", errorsize=256) at loader.c:387 Crash happens after the first call to the __libc_dl_error_tsd (libpthread.so.0) on the thread 1 . Before this, code in _dl_catch_error_internal calls startup_error_tsd( ld_linux.so.2) on thread 0 and function works fine. If I check memory content in the debugger just before expected SIGSEGV, application doesn't crash immediately, but some different error happens later. The same problem was reproduced on different computers. I think that the behaviour is simular to the one described in NVidia readme and this will help to resolve the problem: ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4349/README.txt Q: Some OpenGL applications (like Quake3 Arena) crash when I start them on Red Hat Linux 9.0. A: Some versions of the glibc package shipped by Red Hat that support TLS do not properly handle using dlopen() to access shared libraries which utilize some TLS models. This problem is exhibited, for example, when Quake3 Area dlopen()'s NVIDIA's libGL library. Please obtain at least glibc-2.3.2-11.9 which is available as an update from Red Hat. Alexandre Pigolkine
Bug#187385: Wine/Mono app crashes with SIGSEGV on dlopen()
Package: libc6 Version: 2.3.1-16 Kernel: 2.4.18-bf2.4 Debian GNU/Linux 3.0 with packages from Debian Sid (unstable) When I run Wine application which embeds the Mono JIT engine it crashes at startup. GDB backtrace is: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1286)] 0x40009587 in _dl_catch_error_internal () from /lib/ld-linux.so.2 (gdb) where #0 0x40009587 in _dl_catch_error_internal () from /lib/ld-linux.so.2 #1 0x4032d27d in dlerror () from /lib/libdl.so.2 #2 0x4032ceb7 in dlopen () from /lib/libdl.so.2 #3 0x40106940 in wine_dlopen (filename=0x805e8f0 "/usr/local/lib/wine/kernel32.dll.so", flag=2, error=0x40742bf0 "?'[EMAIL PROTECTED]@??\001@@[EMAIL PROTECTED]", errorsize=256) at port.c:517 #4 0x4010635e in dlopen_dll (name=0x40742d08 "kernel32.dll", error=0x40742bf0 "?'[EMAIL PROTECTED]@??\001@@[EMAIL PROTECTED]", errorsize=256, test_only=0) at loader.c:152 #5 0x4010684a in wine_dll_load (filename=0x40742d08 "kernel32.dll", error=0x40742bf0 "?'[EMAIL PROTECTED]@??\001@@[EMAIL PROTECTED]", errorsize=256) at loader.c:387 Crash happens after the first call to the __libc_dl_error_tsd (libpthread.so.0) on the thread 1 . Before this, code in _dl_catch_error_internal calls startup_error_tsd( ld_linux.so.2) on thread 0 and function works fine. If I check memory content in the debugger just before expected SIGSEGV, application doesn't crash immediately, but some different error happens later. The same problem was reproduced on different computers. I think that the behaviour is simular to the one described in NVidia readme and this will help to resolve the problem: ftp://download.nvidia.com/XFree86/Linux-x86/1.0-4349/README.txt Q: Some OpenGL applications (like Quake3 Arena) crash when I start them on Red Hat Linux 9.0. A: Some versions of the glibc package shipped by Red Hat that support TLS do not properly handle using dlopen() to access shared libraries which utilize some TLS models. This problem is exhibited, for example, when Quake3 Area dlopen()'s NVIDIA's libGL library. Please obtain at least glibc-2.3.2-11.9 which is available as an update from Red Hat. Alexandre Pigolkine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
