Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade
On Fri, Sep 10, 2021 at 09:59:44PM +0200, Aurelien Jarno wrote:
> On 2021-09-10 20:39, Colin Watson wrote:
> > On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote:
> > > I gave a try with debconf-show instead. I have attached a totally
> > > untested patch to check that we agree on the way to do it.
> >
> > I think you forgot to attach the patch?
>
> Dooh. Please find a new version attached.
The general idea of this looks good to me. I've left some detailed
review comments below, and IMO we should test it against my reproducer
(especially since this preinst patch needs to end up in bullseye).
> > I managed to reproduce the reported bug by taking Neil's full package
> > list, mangling it to roughly make sense on buster, installing all of
> > that, and then doing "apt upgrade && apt full-upgrade" (my own habit is
> > just to do "apt full-upgrade", but in this case the initial "apt
> > upgrade" is crucial). I'm now trying to more or less bisect the package
> > list to find something rather more minimal; this is a slow process, but
> > no roadblocks so far, and I'll let you know when I have something.
>
> Thanks a lot for your help.
OK, it took much longer than I expected because I wasn't able to do it
by just bisecting the package list, but here's a reproducer. I ran this
in a fresh container produced by "lxc launch images:debian/buster"; I
expect other container tools can be made to exhibit this too, though it
may be sensitive to exactly which packages are in the base image.
# apt update && apt -y install gimp libc6-dev postgresql whiptail
# cat >/etc/apt/sources.list <http://deb.debian.org/debian bullseye main
deb http://security.debian.org/debian-security bullseye-security main
# apt update && apt -y upgrade && apt -y dist-upgrade
Removing any of those initial packages, or even disabling installation
of Recommends, seems to evade the bug. I don't fully understand why
this particular package selection has this effect on apt's ordering, and
it's certainly possible that it can be pared down further, but this
seemed a reasonable place to stop. To test a fixed preinst, obviously
the new libc6 can't just be installed using dpkg without invalidating
the test, but adding another source to sources.list before starting the
upgrade should work fine.
> diff --git a/debian/debhelper.in/libc.preinst
> b/debian/debhelper.in/libc.preinst
> index d679db4f..e7808a44 100644
> --- a/debian/debhelper.in/libc.preinst
> +++ b/debian/debhelper.in/libc.preinst
> @@ -21,23 +21,22 @@ kfreebsd_compare_versions () {
>
> if [ "$type" != abort-upgrade -a -z "$DPKG_ROOT" ]
> then
> -# Load debconf module if available and usable
> +# Check if the debconf module is available and usable
I'd suggest initializing "USE_DEBCONF=" here to avoid potential
weirdness in case somebody happens to have that variable set in their
environment for some reason.
> if [ -f /usr/share/debconf/confmodule ]; then
> # cdebconf has a working fallback mechanism in case dialog
> # is not usable, so do not try to do anything smart here
> if [ "$DEBCONF_USE_CDEBCONF" ] ; then
> -. /usr/share/debconf/confmodule
> USE_DEBCONF=1
> # debconf requires perl
> elif perl -e "" 2>/dev/null ; then
> -. /usr/share/debconf/confmodule
> # Check that the selected frontend will work
> if [ -n "$DEBIAN_FRONTEND" ] ; then
> frontend="$DEBIAN_FRONTEND"
> else
> -db_version 2.0
> -db_get debconf/frontend || RET="Dialog"
> -frontend="$RET"
> +# Query the frontend without first sourcing the confmodule
> to avoid
> +# loosing control of the tty. This snipped must not be
> copied blindly.
s/loosing/losing/, and s/snipped/snippet/.
> +frontend="$(echo 'GET debconf/frontend' |
> debconf-communicate | sed '/^0 /!d;s/^0 //')"
> +frontend="${frontend:-Dialog}"
> fi
> frontend=`echo $frontend | tr '[:upper:]' '[:lower:]'`
> case "$frontend" in
> @@ -61,6 +60,11 @@ then
> fi
> fi
>
> +# Load debconf module if available and usable
> +if [ "$USE_DEBCONF" ]
This needs a "; then".
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade
On Fri, Sep 10, 2021 at 09:03:32PM +0200, Aurelien Jarno wrote: > On 2021-09-10 16:51, Colin Watson wrote: > > The only way to fix what libc.preinst is currently trying to do would > > be: > > > > * Fetch the current debconf frontend *without* first sourcing the > >confmodule, e.g. using something like "echo GET debconf/frontend | > >debconf-communicate" which I *think* is safe as long as you haven't > >sourced the confmodule yet; > > > > * Decide whether to use debconf based on this and other information; > > > > * Only source the confmodule if you've positively decided to use it. > > debconf-communicate might be safe, but its manpage explicitly says it > should not be used in maintainer scripts. Strictly, it says "a maintainer script of a package that uses debconf". I think what that really means is that it shouldn't be used after sourcing the debconf confmodule (which is normally the same as using debconf since nearly everything sources it right at the top - but this is a weird edge case). The point is to avoid having multiple processes with the debconf database open at the same time. Put another way, for this purpose, libc6.preinst isn't really a maintainer script that uses debconf until it sources the confmodule. > I gave a try with debconf-show instead. I have attached a totally > untested patch to check that we agree on the way to do it. I think you forgot to attach the patch? I wouldn't completely veto using debconf-show in this very specialized situation, as long as it came with a substantial comment explaining what's going on so that nobody else is tempted to copy it. However, the output format of debconf-show isn't guaranteed, so I'm not very happy about it being used mechanically like this. I'd prefer debconf-communicate if we can ensure that it works in this context, notwithstanding its documentation. > > But a simpler approach might be to update debconf in buster with the > > change from 1.5.76 to check whether whiptail/dialog is usable before > > trying to use it, and then remove at least some of this fragile and > > broken code from libc.preinst. At the very least, USE_DEBCONF=1 must > > always be set if (and only if) the debconf confmodule has been sourced. > > While it is probably a good idea to backport that change in buster to > limit to reduce the risk, we don't require people to upgrade to the > latest buster release before starting an upgrade. > > On the other hand, given that bullseye has a fixed debconf, I fully > agree that we should drop that fragile code for bookworm. We probably agree on both points here. > > I'm currently seeing if I can construct a reduced reproduction recipe > > based on Neil's logs, since it evidently depends on exactly which order > > apt chooses to unpack things early on, and it would be very helpful to > > be able to test fixes properly. > > Thanks, tell me if you need help on that. I managed to reproduce the reported bug by taking Neil's full package list, mangling it to roughly make sense on buster, installing all of that, and then doing "apt upgrade && apt full-upgrade" (my own habit is just to do "apt full-upgrade", but in this case the initial "apt upgrade" is crucial). I'm now trying to more or less bisect the package list to find something rather more minimal; this is a slow process, but no roadblocks so far, and I'll let you know when I have something. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#994042: libc6: debconf text fallback failed to accept input, had to be killed leading to broken dist-upgrade
On Fri, Sep 10, 2021 at 04:02:06PM +0100, Neil Williams wrote: > This is related to #984533 - in my case, there was no effect on the initramfs. > > I am attaching the section of the apt log. (gzipped) > I am also attaching the dpkg -l output for the package list (after upgrade). > > The apt log includes the details of the --purge autoremove operation I > completed > after a reboot, so those packages were also installed on buster too. > > This was an upgrade from buster to bullseye. > apt upgrade worked fine (first part of the log). > > When dist-upgrade started, I got: > > Preparing to unpack .../92-libc6_2.31-13_amd64.deb ... > debconf: unable to initialize frontend: Dialog > debconf: (No usable dialog-like program is installed, so the dialog based > frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line > 78.) > debconf: falling back to frontend: Readline > Checking for services that may need to be restarted... > Checking init scripts... > Do you want to upgrade glibc now? > > Running services and programs that are using NSS need to be restarted, > otherwise they might not be able to do lookup or authentication any more. > The installation process is able to restart some services (such as ssh or > telnetd), but other programs cannot be restarted automatically. One such > program that needs manual stopping and restart after the glibc upgrade by > yourself is xdm - because automatic restart might disconnect your active > X11 sessions. > > This script detected the following installed services which must be > stopped before the upgrade: postgresql > > If you want to interrupt the upgrade now and continue later, please > answer No to the question below. > > Do you want to upgrade glibc now? [Y/n] y > Y The code in libc.preinst that attempts to fall back to text mode, introduced in 2.31-10, is clearly incorrect; apologies for not noticing this earlier. It sources the debconf confmodule and then conditionally sets USE_DEBCONF; but since the debconf confmodule has already been sourced by this point, text mode won't work properly since standard input and output refer to the debconf frontend. (In particular, reading from stdin can't work.) The only way to fix what libc.preinst is currently trying to do would be: * Fetch the current debconf frontend *without* first sourcing the confmodule, e.g. using something like "echo GET debconf/frontend | debconf-communicate" which I *think* is safe as long as you haven't sourced the confmodule yet; * Decide whether to use debconf based on this and other information; * Only source the confmodule if you've positively decided to use it. But a simpler approach might be to update debconf in buster with the change from 1.5.76 to check whether whiptail/dialog is usable before trying to use it, and then remove at least some of this fragile and broken code from libc.preinst. At the very least, USE_DEBCONF=1 must always be set if (and only if) the debconf confmodule has been sourced. I'm currently seeing if I can construct a reduced reproduction recipe based on Neil's logs, since it evidently depends on exactly which order apt chooses to unpack things early on, and it would be very helpful to be able to test fixes properly. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade
Control: reassign -1 libc6 2.31-12 Control: affects -1 openssh-server On Sat, Jul 03, 2021 at 11:36:49AM +0200, Olaf van der Spek wrote: > Op zo 20 jun. 2021 om 10:38 schreef Olaf van der Spek : > > So I think it's not accepting new connections from the start of the > > upgrade run until the end: > > Setting up openssh-sftp-server (1:8.4p1-5) ... > > Setting up console-setup (1.203) ... > > Setting up mime-support (3.66) ... > > Setting up openssh-server (1:8.4p1-5) ... > > Installing new version of config file /etc/init.d/ssh ... > > Installing new version of config file /etc/ssh/moduli ... > > Replacing config file /etc/ssh/sshd_config with new version > > rescue-ssh.target is a disabled or a static unit, not starting it. > > Hi Colin, > > Any thoughts on this? Sorry for my delay - it took me a while to spot the problem. libc6's postinst does arrange to restart services where needed, but in this case it doesn't realize that you have the ssh service installed because you only have the openssh-server package installed, not the ssh metapackage (i.e. the package with the same name as the service). I've proposed https://salsa.debian.org/glibc-team/glibc/-/merge_requests/3 to fix this. glibc maintainers, if there's any way to get this into bullseye, I'm sure it would help avoid some people upgrading remote systems ending up being unable to fix them if something goes wrong between configuring libc6 and configuring openssh-server. Also CCing debian-release for their information, as I know it's pretty late for glibc changes. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 01:44:47PM +0100, Julian Andres Klode wrote: > On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > > The break hasn't been added randomly, but in response to upstream > > release notes and bug #965932. In short the openssh seccomp filters in > > buster are too narrow, and do not allow the new 64-bit syscalls needed > > for 64-bit time_t compatibility to be used. Would it help to get those seccomp filter fixes into buster, and then we could tell people that they have to upgrade to the latest point release first? Awkward but not unprecedented I think. > An alternative solution, for openssh-server would be to avoid using the > new syscalls for 64-bit time_t compatibility I assume (forcing it to > link with older symbol versions?), Changing openssh-server in bullseye can't possibly help here, because if you've upgraded openssh-server then that will include the updated seccomp filters anyway. Changing openssh-server in buster might help, but if so it would be much simpler to take the approach above (backporting the seccomp filter fixes) rather than doing symbol versioning hacks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename
On Tue, Jun 23, 2020 at 11:46:58AM +0100, Ian Jackson wrote:
> Aurelien Jarno writes ("Re: Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks
> with plain filename"):
> > You probably have apparmor installed and enabled on your system.
> > Binaries that are run with an apparmor profile get AT_SECURE enabled,
> > which disables many features that have an impact on security, including
> > preloading libraries.
[...]
> I notice that during startup it does this
> access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or
> but none of my man-db binaries are setuid (I have double-checked).
The name is a slight misnomer, presumably because it predates other
reasons why ld.so might be in secure-execution mode.
> I also notice that something in the invocation stack (presumably
> something in man-db) is changing the LD_PRELOAD value from
> LD_PRELOAD=libgtk3-nocsd.so.0 libeatmydata.so
> to
> LD_PRELOAD=libgtk3-nocsd.so.0:libeatmydata.so
> and I didn't even know spaces were allowed! But this doesn't seem
> relevant.
man-db never sets LD_PRELOAD.
> If this were apparmor I would expect to see an EACCES or EPERM or
> something.
I believe Aurelien's contention is not that AppArmor is denying the
request as such (which would indeed produce some kind of errno along
these lines), but rather that the fact that there's an AppArmor policy
defined for /usr/bin/man puts ld.so into secure-execution mode when
executing that binary.
> > > Colin Watson (CC'd) reports that sid works.
> >
> > I have tested on sid and on experimental, I do not find a different
> > behaviour.
Apologies for the misdirection here: I was only testing in a sid chroot,
and hadn't considered the possible AppArmor issue.
In general, I don't regret my decision to add various confinement
tactics to man as a defence against possible vulnerabilities in the
rendering pipeline for manual pages. However, it is clearly
inconvenient in the sort of case that Ian brings up. I wonder if I need
to provide a separate utility for linting manual pages that doesn't
involve secure-execution mode in any way, in order that it can be used
by build systems without needing to worry about all this stuff.
--
Colin Watson (he/him) [cjwat...@debian.org]
Re: Bug#849923: openssh-server: no login possible after upgrade on x32
clone 849923 -1
reassign -1 linux
retitle -1 linux: x32 __vdso_clock_gettime falls back to x86-64 syscall
thanks
On Tue, Jan 03, 2017 at 02:31:35PM +0100, Thorsten Glaser wrote:
> On Mon, 2 Jan 2017, Aurelien Jarno wrote:
> > Looking at the issue, it actually appears in __vdso_clock_gettime, which
> > is provided by the kernel. This code handle the simple cases (REALTIME,
> > MONOTONIC, REALTIME_COARSE and _MONOTONIC_COARSE) and fallbacks to
> > the syscall in otherwise, CLOCK_BOOTTIME in the case of sshd.
>
> Ouch – and the kernel probably thinks it’s getting away with this as
> the kernel architecture is amd64…
>
> Can you please forward this to someone at the kernel side (either Debian
> or upstream) who can have a look? In the meantime, I’ll point this issue
> out in #debian-x32 on IRC, so the other porters can also look.
I've cloned a kernel bug for this with this message.
> > On 2017-01-02 17:49, Colin Watson wrote:
>
> > > sshd's seccomp sandbox is denying a clock_gettime call. But it's more
>
> Probably a stupid idea, but a short-term stopgap: can we disable seccomp
> on x32 for now? That needs:
Here's a better stopgap that lets us keep the sandbox enabled:
https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=e346421ca6852fbf9f95cf0e764ecc345e5ce21d
> • in debian/rules:
> +confflags += --host=${DEB_HOST_GNU_TYPE}
> This sets $host to x86_64-pc-linux-gnux32 instead of the
> auto-detected x86_64-pc-linux-gnu (which is amd64)
Unnecessary: the default is --build=x86_64-linux-gnux32, and --host
shouldn't be passed when not cross-compiling.
You're probably being misled by config.guess's default, but that's
already overridden appropriately by dpkg/debhelper.
Cheers,
--
Colin Watson [cjwat...@debian.org]
Re: Bug#849923: openssh-server: no login possible after upgrade on x32
On Mon, Jan 02, 2017 at 11:36:55AM +0100, Thorsten Glaser wrote: > After upgrading from 1:7.3p1-5 to 1:7.4p1-3 I can no longer > 'ssh localhost' on x32; switching to openssh-server:i386 with > the exact same configuration works, though. sshd's seccomp sandbox is denying a clock_gettime call. But it's more interesting than that: its seccomp filter allows clock_gettime; but the actual syscall being used is not the x32 clock_gettime (with bit 30 set), but the x86-64 variant instead. You can see a similar effect like this in an x32 environment: strace dmesg -e ... and buried in the output you'll find something like: strace: syscall_228(...) in unsupported 64-bit mode of process PID=19943 Neither sshd nor dmesg is using anything like manual syscall(2) here, just the glibc wrappers. This feels like a glibc bug to me. Shouldn't it be using x32 syscalls consistently? The x86-64 variants work, but that's not very seccomp-friendly. (And if necessary I can hack around it in sshd, but if you agree that it's a glibc bug then I think it should simply be fixed there.) Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#819845: [Debconf-devel] Bug#819845: mention how to reconfigure the items shown by debconf-show
On Sun, Apr 03, 2016 at 11:23:02AM +0800, 積丹尼 Dan Jacobson wrote: > >>>>> "CW" == Colin Watson <cjwat...@debian.org> writes: > > CW> No, I don't see any need to change the debconf documentation here. > CW> dpkg-reconfigure(8) says that it will ask configuration questions, not > CW> that it will ask every single thing mentioned in the output of > CW> debconf-show(1). > > So you need to say that not every thing shown in debconf-show is a > configuration option! It's mainly a debugging aid, and as it stands it only talks about "items", which are quite generic. It seems good enough to me. I'm not going to reply further, so please stop e-mailing me about this. -- Colin Watson [cjwat...@debian.org]
Bug#819845: [Debconf-devel] Bug#819845: mention how to reconfigure the items shown by debconf-show
On Sun, Apr 03, 2016 at 10:09:04AM +0800, 積丹尼 Dan Jacobson wrote: > Also debconf-show should perhaps indicate which items will cause > a subsequent run of dpkg-reconfigure to ask questions, vs. which items > are inaccessible via dpkg-reconfigure. It can't. debconf fundamentally doesn't have this information. (Except to the extent of knowing which questions have already been asked in the past, which debconf-show already tells you via the '*' prefix.) -- Colin Watson [cjwat...@debian.org]
Bug#819845: [Debconf-devel] Bug#819845: mention how to reconfigure the items shown by debconf-show
On Sun, Apr 03, 2016 at 10:06:52AM +0800, 積丹尼 Dan Jacobson wrote: > >>>>> "CW" == Colin Watson <cjwat...@debian.org> writes: > CW> It is not necessarily appropriate to be able to reconfigure every item > CW> shown by debconf-show, because some of them may be used for internal > CW> state tracking by the package's maintainer scripts, or depend on the > CW> current situation at the time when the maintainer scripts are run; > > OK then please mention that on man dpkg-reconfigure. No, I don't see any need to change the debconf documentation here. dpkg-reconfigure(8) says that it will ask configuration questions, not that it will ask every single thing mentioned in the output of debconf-show(1). > And also mention that on man dpkg-reconfigure that it has no secret > --double-force option to get a way to tinker with all the items shown > with debconf-show even if inappropriate, like you said: It also doesn't have a --make-me-a-sandwich option, but I'm not going to spell out all the options it doesn't have. :-) -- Colin Watson [cjwat...@debian.org]
Bug#762677: libc0.3: Hurd futimens does not support UTIME_NOW
Package: libc0.3
Version: 2.19-11
Severity: normal
The futimens patch for the Hurd does not support UTIME_NOW or
UTIME_OMIT. POSIX says:
If the tv_nsec field of a timespec structure has the special value
UTIME_NOW, the file's relevant timestamp shall be set to the greatest
value supported by the file system that is not greater than the
current time. If the tv_nsec field has the special value UTIME_OMIT,
the file's relevant timestamp shall not be changed. In either case,
the tv_sec field shall be ignored.
This is the cause of the current man-db build failure:
https://buildd.debian.org/status/fetch.php?pkg=man-dbarch=hurd-i386ver=2.7.0.1-1stamp=1411530073
Gnulib defines UTIME_NOW to (-1) if it is not defined by the system.
But, since futimens doesn't specifically support it, setting the mtime
to {0, UTIME_NOW} just results in a timestamp one nanosecond less than
the epoch, which is not very useful. The attached test program, when
run with a file name argument, should result in a file whose
modification time is set to the current time.
I'll see if I can modify Gnulib or failing that man-db to work around
this, but of course it would be better for futimens to be fixed.
Thanks,
--
Colin Watson [cjwat...@debian.org]
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include stdlib.h
#include unistd.h
#define MUST(name, cond) \
do { \
if (!(cond)) { \
fprintf (stderr, name failed\n); \
abort (); \
} \
} while (0)
int main (int argc, char **argv)
{
int fd;
struct timespec times[2];
if (argc 2) {
fprintf (stderr, need file name\n);
exit (2);
}
fd = open (argv[1], O_RDWR | O_CREAT | O_TRUNC, 0666);
MUST (open, fd = 0);
times[0].tv_sec = 0;
times[0].tv_nsec = UTIME_NOW;
times[1].tv_sec = 0;
times[1].tv_nsec = UTIME_NOW;
MUST (futimens, futimens (fd, times) == 0);
MUST (close, close (fd) == 0);
return 0;
}
Re: r4943 - in glibc-package/trunk/debian: . patches/localedata
On Sun, Sep 04, 2011 at 05:01:07PM +, Aurelien Jarno wrote: Modified: glibc-package/trunk/debian/changelog glibc-package/trunk/debian/patches/localedata/locale-C.diff Log: * debian/patches/localedata/locale-C.diff: Don't include ISO14651 collation rules in C.UTF-8 locale. I'm curious what the reason for this was. It seems to be implicated in this apt crash in Ubuntu: https://bugs.launchpad.net/bugs/848907 (apt didn't change in the relevant time period; eglibc seems to be the only other reasonable suspect.) I can reproduce the same crash in Debian unstable, with: sudo LC_ALL=C.UTF-8 apt-get update Now, Michael thinks that this is probably an apt bug too, and he's working on fixing it; but I'm curious as to the rationale for this change, since I don't know how many other packages might be affected by similar problems, and what would go wrong if we backed it out? Thanks, -- Colin Watson [cjwat...@debian.org] -- 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/20110913145323.ga...@riva.dynamic.greenend.org.uk
Re: r4943 - in glibc-package/trunk/debian: . patches/localedata
On Tue, Sep 13, 2011 at 03:53:23PM +0100, Colin Watson wrote:
On Sun, Sep 04, 2011 at 05:01:07PM +, Aurelien Jarno wrote:
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/patches/localedata/locale-C.diff
Log:
* debian/patches/localedata/locale-C.diff: Don't include ISO14651
collation rules in C.UTF-8 locale.
I'm curious what the reason for this was. It seems to be implicated in
this apt crash in Ubuntu:
https://bugs.launchpad.net/bugs/848907
(apt didn't change in the relevant time period; eglibc seems to be the
only other reasonable suspect.)
I can reproduce the same crash in Debian unstable, with:
sudo LC_ALL=C.UTF-8 apt-get update
Now, Michael thinks that this is probably an apt bug too, and he's
working on fixing it; but I'm curious as to the rationale for this
change, since I don't know how many other packages might be affected by
similar problems, and what would go wrong if we backed it out?
In particular, this test program fails:
$ cat regcomp.c
#include locale.h
#include sys/types.h
#include regex.h
#include stdio.h
int main (int argc, char **argv)
{
regex_t reg;
setlocale (LC_ALL, );
if (regcomp (reg, [a-z], 0) != 0) {
fprintf (stderr, regcomp failed!\n);
return 1;
}
return 0;
}
$ make CFLAGS='-O2 -g -Wall' regcomp
cc -O2 -g -Wallregcomp.c -o regcomp
$ LC_ALL=C.UTF-8 ./regcomp; echo $?
regcomp failed!
1
This seems to be in conflict with the goal of having a UTF-8-capable but
language-agnostic locale; and it's different from how the C.UTF-8 locale
in d-i behaves.
--
Colin Watson [cjwat...@debian.org]
--
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/20110913153917.gb...@riva.dynamic.greenend.org.uk
Re: r4943 - in glibc-package/trunk/debian: . patches/localedata
On Tue, Sep 13, 2011 at 05:33:19PM +0200, Aurelien Jarno wrote: Yes similar problems have already been reported. This change has been done as a C locale should not have a collation order. Why not? Codepoint order collation is perfectly reasonable for a C locale. Lots of people use LC_COLLATE=C when all they want is for things like [a-z] to work reasonably. -- Colin Watson [cjwat...@debian.org] -- 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/20110913160746.gc...@riva.dynamic.greenend.org.uk
Bug#630077: preinst fails with Linux 3.0
Package: eglibc
Version: 2.13-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric
libc.preinst gets rather upset if your kernel identifies itself as 3.0
(as noted in https://lkml.org/lkml/2011/6/10/309). Here's a patch that
Andy reports as fixing it.
*Building* eglibc on a 3.0 kernel may be a rather different matter. I
haven't tried that ...
=== modified file 'debian/debhelper.in/libc.preinst'
--- debian/debhelper.in/libc.preinst2011-06-09 15:44:22 +
+++ debian/debhelper.in/libc.preinst2011-06-10 16:04:31 +
@@ -25,8 +25,8 @@ rm_conffile() {
}
linux_compare_versions () {
-verA=$(($(echo $1 | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \*
1 + \2 \* 100 + \3/')))
-verB=$(($(echo $3 | sed 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \*
1 + \2 \* 100 + \3/')))
+verA=$(($(echo $1 | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/;
s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 1 + \2 \* 100 + \3/')))
+verB=$(($(echo $3 | sed 's/^\([0-9]*\.[0-9]*\)\([^.0-9]\|$\)/\1.0\2/;
s/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\).*/\1 \* 1 + \2 \* 100 + \3/')))
test $verA -$2 $verB
}
@@ -285,7 +285,7 @@ then
then
# Test to make sure z 255, in x.y.z-n form of kernel version
# Also make sure we don't trip on x.y.zFOO-n form
- kernel_rev=$(uname -r | sed 's/\([0-9]*\.[0-9]*\.\)\([0-9]*\)\(.*\)/\2/')
+ kernel_rev=$(uname -r | sed 's/\([0-9]*\.\)\{1,2\}\([0-9]*\)\(.*\)/\2/')
if [ $kernel_rev -ge 255 ]
then
echo WARNING: Your kernel version indicates a revision number
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
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/20110610162033.gw23...@riva.ucam.org
Bug#511620: putty-tools: psftp segfaults trying to open a remote server
On Mon, Jan 12, 2009 at 10:16:38PM +, brian m. carlson wrote: On Mon, Jan 12, 2009 at 10:02:41PM +, Colin Watson wrote: On Mon, Jan 12, 2009 at 09:13:15PM +, brian m. carlson wrote: fp = (FILE *) 0x0 That would happen if popen() fails. The manual page says: The popen() function returns NULL if the fork(2) or pipe(2) calls fail, or if it cannot allocate memory. This could happen if you've run out of memory or hit a resource limit. Could you please investigate and find out whether one of these things is true? strace may help. I determined that the bug is actually in glibc in experimental. The errno value is set to ENOSYS. Last time I checked, Linux 2.6.27 had working fork(2) and pipe(2) calls, so glibc is doing some pretty crackful things. I also found out that this is not occuring with every popen call, but only some of them. Whether the bug occurs is specific to an invocation, but every such invocation is reproducible. Nevertheless, putty should check the return value of popen. Crashing when popen fails is not exactly robust. Well, it might well have to bail out anyway, but you're right that it shouldn't segfault. For pu...@projects: there are two unchecked popen calls in unix/uxnoise.c, which caused a segfault in this bug report when popen failed (in this case due to a glibc bug as mentioned, but popen could fail due to resource limits). Could you check them and do something better? Since this is in noise generation, I didn't know whether you wanted to bail out or carry on if you have insufficient entropy, so I haven't attempted to supply a patch. Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511620: putty-tools: psftp segfaults trying to open a remote server
On Tue, Jan 13, 2009 at 10:00:10AM +, Colin Watson wrote: On Mon, Jan 12, 2009 at 10:16:38PM +, brian m. carlson wrote: I determined that the bug is actually in glibc in experimental. The errno value is set to ENOSYS. Last time I checked, Linux 2.6.27 had working fork(2) and pipe(2) calls, so glibc is doing some pretty crackful things. I also found out that this is not occuring with every popen call, but only some of them. Whether the bug occurs is specific to an invocation, but every such invocation is reproducible. Nevertheless, putty should check the return value of popen. Crashing when popen fails is not exactly robust. Well, it might well have to bail out anyway, but you're right that it shouldn't segfault. Simon Tatham has fixed this in PuTTY upstream (r8411). I'm going to be attempting to put together a snapshot release of putty to experimental in the near future, which should be enough to fix this bug given that it's only happening with glibc/experimental. Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#458682: ld-linux.so.2: defunct (Debian+lenny/sid)
On Wed, Jan 02, 2008 at 06:09:17AM -0500, Justin Piszcz wrote: Package: libc6 Version: 2.7-4 Problem: There should not be defunct zombie processes in the default Debian Lenny/testing branch. $ ps auxww | grep -i defunct bob 3771 0.0 0.0 0 0 ?Z04:31 0:01 [ld-linux.so.2] defunct This is unlikely to be a glibc bug. If a parent process fails to reap its child when it dies, then the child will remain as a zombie until either the parent finally gets round to reaping it or the parent itself dies and the child is reparented to init, upon which init will reap it. What is bob's parent process? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0
On Tue, Dec 25, 2007 at 07:40:24PM +0100, Florian Weimer wrote: * Colin Watson: [Please don't remove attributions. Vincent Lefevre wrote this bit.] [*] 1.0.0.0 isn't even a valid IP address, is it? Depends on the situation. You wouldn't want to give a host that address, Why not? Subnet zero is no longer reserved. The whole /8 is currently not assigned, but that's a different matter. I was under the impression that it was conventional even if not required to reserve host zero in a given subnet to identify the network itself, to avoid confusion of networks with hosts. Still, we're in agreement on the basic implementation issue so it doesn't matter too much. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457472: openssh-client: ssh resolves some hosts to 1.0.0.0
On Mon, Dec 24, 2007 at 03:07:51PM +0100, Vincent Lefevre wrote: On 2007-12-24 10:49:32 +, Colin Watson wrote: I can't tell for sure from your strace (in future, use -s 1024 so that buffers passed to system calls aren't truncated to quite such a short length), but your diagnosis sounds right, and it doesn't sound like OpenSSH is the appropriate place for a deployed workaround. Reassigning to glibc where the resolver is implemented. OK, I didn't know what OpenSSH used for DNS resolving. As different software behaves differently, this is rather confusing. After more tests, it seems that Iceweasel has the same problem, though other users (as seen in discussions on web forums) reported that Firefox worked (but perhaps they have disabled IPv6 in Firefox or somewhere else). Some users reported the same problem with apt-get with Debian and Ubuntu[*]. So, this probably comes from glibc (I suppose that not all software does IPv6 DNS requests). Indeed, OpenSSH just uses getaddrinfo, which is the newer generation of library support for name resolution. I imagine, though, that the relevant fact is that it does an query and gets garbage back. However, in your particular case, setting 'AddressFamily inet' in /etc/ssh/ssh_config should work around the problem just for ssh. The solution I chose was to disable the DNS forwarding service of the D-Link router; but this meant I had to fill the /etc/resolv.conf manually (I thought the router would provide the DNS servers of the ISP instead of the local 192.168.1.1, but after running pump, the /etc/resolv.conf file is left unchanged). However, the consequence is that Windows machines (which don't support IPv6, thus are not affected by the bug of the router) can no longer use the router's DNS service either. Have you considered asking your router vendor for a firmware upgrade? It sounds like a straightforward bug in their DNS implementation. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420895: tzdata: debconf logic can't handle single-level zones defined in backward
Package: tzdata Version: 2007e-4 Severity: important Justification: breaks debootstrap (Actually, I saw this with 2007e-3ubuntu2 in Ubuntu; but I've looked at the diff to 2007e-4 and I'm fairly sure it suffers from the same problem. Sorry if I'm wrong.) debootstrap has always done this or equivalent before configuring most packages: if [ ! -e $TARGET/etc/localtime ]; then ln -sf /usr/share/zoneinfo/UTC $TARGET/etc/localtime fi Unfortunately this confuses tzdata's new debconf code. A DEBCONF_DEBUG=developer dump looks like this: Setting up tzdata (2007e-3ubuntu2) ... debconf (developer): frontend started debconf (developer): frontend running, package name is tzdata debconf (developer): starting /var/lib/dpkg/info/tzdata.config configure debconf (developer): -- VERSION 2.0 debconf (developer): -- 0 2.0 debconf (developer): -- CAPB backup debconf (developer): -- 0 multiselect escape debconf (developer): -- FSET tzdata/Areas seen true debconf (developer): -- 0 true debconf (developer): -- FSET tzdata/Zones/UTC seen true debconf (developer): -- 10 tzdata/Zones/UTC doesn't exist dpkg: error processing tzdata (--configure): subprocess post-installation script returned error exit status 10 Errors were encountered while processing: tzdata It appears not to like single-level zones (i.e. UTC rather than Etc/UTC). While this could be worked around to some extent in debootstrap, it seems likely that this will also affect upgrades from systems using any single-level timezone name. I can think of two obvious approaches to fix this. One would be to allow any single-level zone name that exists in /usr/share/zoneinfo/. Another (more appealing in terms of elegance, although also probably harder) would be to automatically migrate any zone that's defined using a Link line. What do you think? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349706: linux-kernel-headers: Needs to conflict with amd64-libs-dev 1.1
On Tue, Jan 24, 2006 at 02:03:21PM -0500, Adam C Powell IV wrote: Both linux-kernel-headers in etch and amd64-libs-dev in sarge provide /usr/include/asm/bootsetup.h (among others), leading to a hiccup during sarge-etch upgrade if they are not upgraded in the right order. To force the right order, please have linux-kernel-headers conflict with amd64-libs-dev (1.4) [or whatever version of amd64-libs-dev dropped those files]. Please use Replaces rather than Conflicts here; using Conflicts for moved files makes the package management system's job unnecessarily difficult (because it requires that one package be totally removed from the system temporarily during the upgrade). -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318885: libc6: please drop libdb1-compat dependency for etch
Package: libc6 Version: 2.3.2.ds1-22, 2.3.5-2 Severity: wishlist libc's dependency on libdb1-compat was a transitional measure for sarge, and is not required for etch. Please remove that dependency so that libdb1-compat can be dropped to Priority: extra. Thanks, -- Colin Watson (libdb1-compat maintainer)[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298913: locales: option to locale-gen to avoid regenerating existing locales?
Package: locales Version: 2.3.2.ds1-20 Severity: wishlist Tags: patch It'd be nice if locale-gen had an option to avoid regenerating locales that have already been generated. At the moment, successive calls to locale-gen take O(n^2) time in the number of calls, which is annoying. This is causing us performance issues on the Ubuntu live CD; we pre-generate a bunch of locales, but if the user selects one that isn't pre-generated then we have to run locale-gen, and since locales has not been upgraded there's no reason to generate all the existing locales all over again. (We could use localedef directly, but locale-gen already has some logic that we want, and we'd want to add the locales to /etc/locale.gen anyway for proper integration.) Similarly, it takes a very long time to install several of our language packs, since they each add some locales to /etc/locale.gen and call locale-gen. Attached is a patch that implements a --keep-existing flag, with documentation. It relies on perl-base to figure out whether the locale exists, but perl-base is Essential so that should be OK. Run 'make' in debian/local/manpages/ after applying it. (Eventually, it might be nice to deal with removals from /etc/locale.gen in a similar way, using 'localedef --delete-from-archive'.) Thanks, -- Colin Watson [EMAIL PROTECTED] diff -u glibc-2.3.2.ds1/debian/local/manpages/locale-gen.8.sgml glibc-2.3.2.ds1/debian/local/manpages/locale-gen.8.sgml --- glibc-2.3.2.ds1/debian/local/manpages/locale-gen.8.sgml +++ glibc-2.3.2.ds1/debian/local/manpages/locale-gen.8.sgml @@ -13,7 +13,7 @@ !ENTITY dhfirstname firstnameEduard/firstname !ENTITY dhsurname surnameBloch/surname !-- Please adjust the date whenever revising the manpage. -- - !ENTITY dhdate dateJuly 27, 2001/date + !ENTITY dhdate dateMarch 10, 2005/date !-- SECTION should be 1-8, maybe w/ subsection other parameters are allowed: see man(7), man(1). -- !ENTITY dhsection manvolnum8/manvolnum @@ -54,6 +54,7 @@ refsynopsisdiv cmdsynopsis commanddhpackage;/command + argoption--keep-existing/option/arg /cmdsynopsis /refsynopsisdiv @@ -80,6 +81,24 @@ /refsect1 refsect1 +titleOPTIONS/title + +variablelist + varlistentry +termoption--keep-existing/option/term +listitem + paraBy default, commanddhpackage;/command removes all + existing locales and generates new ones afresh. The + option--keep-existing/option option prevents this, so that + only locales which do not already exist are generated. This is + useful if calling locale-gen a number of times in + succession./para +/listitem + /varlistentry +/variablelist + + /refsect1 + refsect1 titleFILES/title parafilename/etc/locale.gen/filename/para diff -u glibc-2.3.2.ds1/debian/local/usr_sbin/locale-gen glibc-2.3.2.ds1/debian/local/usr_sbin/locale-gen --- glibc-2.3.2.ds1/debian/local/usr_sbin/locale-gen +++ glibc-2.3.2.ds1/debian/local/usr_sbin/locale-gen @@ -11,9 +11,16 @@ [ -f $LOCALEGEN -a -s $LOCALEGEN ] || exit 0; -# Remove all old locale dir and locale-archive before generating new -# locale data. -rm -rf /usr/lib/locale/* || true +KEEP= +if [ $1 = '--keep-existing' ]; then + KEEP=1 +fi + +if [ -z $KEEP ]; then + # Remove all old locale dir and locale-archive before generating new + # locale data. + rm -rf /usr/lib/locale/* || true +fi umask 022 @@ -30,6 +37,10 @@ while read locale charset; do \ case $locale in \#*) continue;; ) continue;; esac; \ is_entry_ok || continue + if [ $KEEP ] PERL_BADLANG=0 perl -MPOSIX -e \ + 'exit 1 unless setlocale(LC_ALL, $ARGV[0])' $locale; then + continue + fi echo -n `echo $locale | sed 's/\([EMAIL PROTECTED]).*/\1/'`; \ echo -n .$charset; \ echo -n `echo $locale | sed 's/\([EMAIL PROTECTED])\([EMAIL PROTECTED])*/\2/'`; \
Bug#264884: globfree() double-frees
On Mon, Sep 13, 2004 at 11:55:38AM -0500, Jeff Licquia wrote: On Sat, 2004-09-11 at 11:33, GOTO Masanori wrote: Currently, there's no problem, so I would like to downgrade this bug to investigate more if there's no comments... I suppose this is between you and the release manager. I can tell you without hesitation that sarge will not certify against LSB 2.0 without this patch, and it may not certify against LSB 1.3 either. This situation violates policy, and causes a number of headaches for a lot of other people as well. OTOH, I am well aware of the constraints placed upon release managers, so I will not object if releasing sarge with this bug is considered to be the best thing for Debian. I would insist on its correction for the first point release, though. At the moment, LSB 1.3 compatibility is release-critical, so if that certification would fail then the problem must be fixed. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody-sarge upgrades on mips: glibc vs. kernel
On Sat, Sep 04, 2004 at 11:54:38AM +0200, Guido Guenther wrote: On Fri, Sep 03, 2004 at 10:42:12PM -0700, Steve Langasek wrote: It's come to my attention that on mips(el), the glibc in sarge is incompatible with the kernel in woody, and the kernel in sarge is incompatible with the glibc in woody. This is an impasse that has to be resolved for sarge's release, so that upgrades from woody to sarge can be supported. What exactly is the issue with kernels in sarge running on woody? As I understand it, it's emulation of missing instructions on certain hardware (at least, that's the case on i386). I'm running 2.4.22 without any problems since several months on mips now. We could then simply add to the release notes that on woody upgrades the kernel has to be updated first, then glibc. Modern kernel packages have dependencies that require a glibc newer than that in woody. To break this deadlock, we need upgrade kernel packages so that there's something to which we can point users in the release notes. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-headers : linux/socket.h + linux/auto_fs.h
On Tue, Aug 31, 2004 at 10:24:59AM +0100, David Greaves wrote: no comment? Even: go away you're not supposed to insert brief explanation here? In general you aren't supposed to include kernel headers from userspace. am-utils probably needs to copy the kernel definitions it needs until such time as there's a proper libc interface (i.e. not in linux/ or asm/). Fixing the problem in the kernel headers may be a good idea regardless. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
On Mon, Aug 30, 2004 at 10:32:53AM +0200, Harald Dunkel wrote: I have read libc6.preinst and postinst, but I am not sure what you are trying to tell? There are some $() inside which could be replaced by `` to support other shells, $() is supported by all POSIX shells. It's not a bashism. Shells so old as not to support this are unlikely to work properly for other reasons. http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_03 -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdb1-compat / glibc6 removing 9 packages
On Mon, Aug 30, 2004 at 11:40:14AM -0400, Julien Lamarche wrote: I wanted to install libdb1-compat glibc6 on Debian ppc woody. That's not a good idea. If you want to upgrade those, you would be far better off upgrading your whole system to sarge. I was wondering if it was expected that installing these would remove 9 packages, including g++. Try 'apt-get install libc6 libc6-dev locales'. If that doesn't work, look there for the problem. (This has nothing much to do with libdb1-compat, by the way.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#267594: libc6 depends on bash
On Fri, Aug 27, 2004 at 06:19:05PM +0200, Harald Dunkel wrote: GOTO Masanori wrote: Bash is required package, so minimum base system should have bash. If you don't use such debian base system, then libc6.postinst becomes meaningless because you don't use the normal debian system. I do not understand why you refuse to add this dependency to the control file. libc6 is a required package too (much more required than bash), but still it is listed in all affected headers, AFAICS. Essential: yes packages do not need to be listed in dependency fields, by definition, and it's considered somewhat bad style for them to be listed; lintian complains about it, for instance. libc6 is not Essential: yes (libraries cannot be), although bash is. See the Debian Policy Manual. In any case, most dependencies on libc6 are versioned, so even if it were Essential: yes this would be irrelevant. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Re: Bug#258956: Starting sshd fails because of missing libutil.s0.1
On Wed, Jul 14, 2004 at 03:32:50PM +0900, GOTO Masanori wrote: Adding ssh is good idea. libcrypt and libutil, I hope you mean :-) No problem. But it increases libc6.udeb size. Is it acceptable for considering floppy size? We don't put libc6-udeb on floppies, or indeed on any initrd images; it's only ever retrieved from the CD or the network. Size constraints aren't a big deal in this case. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#258956: Processed: Re: Bug#258956: Starting sshd fails because of missing libutil.s0.1
On Thu, Jul 15, 2004 at 02:26:25AM +0900, GOTO Masanori wrote: At Wed, 14 Jul 2004 10:19:30 +0100, Colin Watson wrote: We don't put libc6-udeb on floppies, or indeed on any initrd images; it's only ever retrieved from the CD or the network. Size constraints aren't a big deal in this case. OK, I put into libc-udeb.install: debian/tmp-libc/lib/libutil* lib It will be in 2.3.2.ds1-14. Thanks. The bug report also mentions libcrypt, though. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Re: Bug#258956: Starting sshd fails because of missing libutil.s0.1
On Wed, Jul 14, 2004 at 03:32:50PM +0900, GOTO Masanori wrote: Adding ssh is good idea. libcrypt and libutil, I hope you mean :-) No problem. But it increases libc6.udeb size. Is it acceptable for considering floppy size? We don't put libc6-udeb on floppies, or indeed on any initrd images; it's only ever retrieved from the CD or the network. Size constraints aren't a big deal in this case. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#258956: Processed: Re: Bug#258956: Starting sshd fails because of missing libutil.s0.1
On Thu, Jul 15, 2004 at 02:26:25AM +0900, GOTO Masanori wrote: At Wed, 14 Jul 2004 10:19:30 +0100, Colin Watson wrote: We don't put libc6-udeb on floppies, or indeed on any initrd images; it's only ever retrieved from the CD or the network. Size constraints aren't a big deal in this case. OK, I put into libc-udeb.install: debian/tmp-libc/lib/libutil* lib It will be in 2.3.2.ds1-14. Thanks. The bug report also mentions libcrypt, though. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#190399: Bug#246547: amd64 support for glibc 2.3.2.ds1-14
On Thu, Jul 08, 2004 at 05:07:14PM +0200, Goswin von Brederlow wrote: GOTO Masanori [EMAIL PROTECTED] writes: BTW, I concerned gcc multilib + gcc 3.4 support. This may be not happened in sarge. I wait to put the modification of #252720 until the request is come. If we want to release sarge soon, and if we want to put amd64 into sarge, then it's good idea to keep gcc 3.3, IMHO. What's the merit of pushing gcc 3.4 into sarge on amd64? gcc3.4 has better amd64 support (mainly faster). A handfull of compiler ICE are fixed while a handfull of c++ incompatibilites will probably show up and cause FTBFS. The fixed and new bugs probably even out so the remaining argument would be speed. Starting with gcc-3.4 would also save the gcc 3.3 - 3.4 transition but the rest of debian will have to do that anyway so we save nothing. The rest of Debian probably won't be doing this for sarge. The C++ ABI transition is difficult and requires library package renaming; I recommend staying with g++ 3.3, even if it's a little painful. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#190399: Bug#246547: amd64 support for glibc 2.3.2.ds1-14
On Thu, Jul 08, 2004 at 05:07:14PM +0200, Goswin von Brederlow wrote: GOTO Masanori [EMAIL PROTECTED] writes: BTW, I concerned gcc multilib + gcc 3.4 support. This may be not happened in sarge. I wait to put the modification of #252720 until the request is come. If we want to release sarge soon, and if we want to put amd64 into sarge, then it's good idea to keep gcc 3.3, IMHO. What's the merit of pushing gcc 3.4 into sarge on amd64? gcc3.4 has better amd64 support (mainly faster). A handfull of compiler ICE are fixed while a handfull of c++ incompatibilites will probably show up and cause FTBFS. The fixed and new bugs probably even out so the remaining argument would be speed. Starting with gcc-3.4 would also save the gcc 3.3 - 3.4 transition but the rest of debian will have to do that anyway so we save nothing. The rest of Debian probably won't be doing this for sarge. The C++ ABI transition is difficult and requires library package renaming; I recommend staying with g++ 3.3, even if it's a little painful. -- Colin Watson [EMAIL PROTECTED]
Re: cvs commit to glibc-package/debian/debhelper.in by gotom
On Mon, Jul 05, 2004 at 03:22:56AM -0600, Debian GLibc CVS Master wrote: Repository: glibc-package/debian/debhelper.in who:gotom time: Mon Jul 5 03:22:56 MDT 2004 Log Message: - /usr/bin/getconf and getconf.1 are moved from libc-dev to libc. (Closes: #239170) You seem to have forgotten to include a Replaces: header? Replaces: will be needed to avoid breaking upgrades. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#257244: /usr/bin/zdump: zdump Foo returns GMT rather than an error.
On Mon, Jul 05, 2004 at 10:26:47AM +0900, GOTO Masanori wrote: At Sun, 04 Jul 2004 09:35:05 +1000, Robert Collins wrote: I thought I had. Oh well - here's a transcript of a session showing the problem. [EMAIL PROTECTED]:~$ zdump London London Sat Jul 3 23:32:51 2004 London [EMAIL PROTECTED]:~$ zdump GB GB Sun Jul 4 00:32:56 2004 BST [EMAIL PROTECTED]:~$ zdump BST BST Sat Jul 3 23:33:02 2004 BST There is no indication in here which of the three invocation of zdump actually returned useful data. In actual fact, only the zdump GB returns accurate data, the other two calls just return GMT, but not labelleled as such. Read tzname(3): If the TZ variable does appear in the environment but its value is NULL or its value cannot be interpreted using any of the formats specified below, Coordinated Universal Time (UTC) is used. I close this bug as invalid, ok? I think the behaviour is poor regardless of whether it is documented, and I certainly don't think the bug is invalid ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to glibc-package/debian/debhelper.in by gotom
On Mon, Jul 05, 2004 at 03:22:56AM -0600, Debian GLibc CVS Master wrote: Repository: glibc-package/debian/debhelper.in who:gotom time: Mon Jul 5 03:22:56 MDT 2004 Log Message: - /usr/bin/getconf and getconf.1 are moved from libc-dev to libc. (Closes: #239170) You seem to have forgotten to include a Replaces: header? Replaces: will be needed to avoid breaking upgrades. -- Colin Watson [EMAIL PROTECTED]
Bug#257244: /usr/bin/zdump: zdump Foo returns GMT rather than an error.
On Mon, Jul 05, 2004 at 10:26:47AM +0900, GOTO Masanori wrote: At Sun, 04 Jul 2004 09:35:05 +1000, Robert Collins wrote: I thought I had. Oh well - here's a transcript of a session showing the problem. [EMAIL PROTECTED]:~$ zdump London London Sat Jul 3 23:32:51 2004 London [EMAIL PROTECTED]:~$ zdump GB GB Sun Jul 4 00:32:56 2004 BST [EMAIL PROTECTED]:~$ zdump BST BST Sat Jul 3 23:33:02 2004 BST There is no indication in here which of the three invocation of zdump actually returned useful data. In actual fact, only the zdump GB returns accurate data, the other two calls just return GMT, but not labelleled as such. Read tzname(3): If the TZ variable does appear in the environment but its value is NULL or its value cannot be interpreted using any of the formats specified below, Coordinated Universal Time (UTC) is used. I close this bug as invalid, ok? I think the behaviour is poor regardless of whether it is documented, and I certainly don't think the bug is invalid ... -- Colin Watson [EMAIL PROTECTED]
Bug#256440: LC_COLLATE broken using es_ES and es_ES@euro
On Sun, Jun 27, 2004 at 05:39:42AM +0200, Daniel Peña wrote: Package: locales Version: 2.2.5-11.5 When I invoke 'ls [A-Z][A-Z]*' trying to find files starting with 2 upper-case letters, I obtain the listing of all the dir and its subdirs like if I invoked 'ls *'. This happen when LC_COLLATE is set to 'es_ES' or '[EMAIL PROTECTED]' (or LC_ALL=es_ES or LC_ALL=[EMAIL PROTECTED]). When LC_COLLATE is set to 'C' (LANG=es_ES or LANG=[EMAIL PROTECTED] and LC_ALL=) all goes all right. I doubt this is a bug. Many non-C locales have a collation order that sorts like this: AaBbCcDd... If you want ABCD...abcd..., then LC_COLLATE=C is available. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256440: LC_COLLATE broken using es_ES and es_ES@euro
On Sun, Jun 27, 2004 at 05:39:42AM +0200, Daniel Peña wrote: Package: locales Version: 2.2.5-11.5 When I invoke 'ls [A-Z][A-Z]*' trying to find files starting with 2 upper-case letters, I obtain the listing of all the dir and its subdirs like if I invoked 'ls *'. This happen when LC_COLLATE is set to 'es_ES' or '[EMAIL PROTECTED]' (or LC_ALL=es_ES or LC_ALL=[EMAIL PROTECTED]). When LC_COLLATE is set to 'C' (LANG=es_ES or LANG=[EMAIL PROTECTED] and LC_ALL=) all goes all right. I doubt this is a bug. Many non-C locales have a collation order that sorts like this: AaBbCcDd... If you want ABCD...abcd..., then LC_COLLATE=C is available. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: libc6.1 2.3.2.ds1-13 ia64 is broken
On Mon, Jun 07, 2004 at 09:31:23PM +0900, GOTO Masanori wrote: At Sun, 6 Jun 2004 20:21:57 +0200, Rene Engelhard wrote: as grep-excuses shows ncsd depends on libc6 on ia64 where the library is libc6.1 (as you surely know ;) ): [...] Ooh what has happened!? dpkg-deb -I nscd_2.3.2.ds1-12_alpha.deb | grep Depends Depends: libc6.1 (= 2.3.2.ds1-12) dpkg-deb -I nscd_2.3.2.ds1-13_alpha.deb | grep Depends Depends: libc6.1 (= 2.3.2.ds1-13) dpkg-deb -I nscd_2.3.2.ds1-12_ia64.deb | grep Depends Depends: libc6.1 (= 2.3.2.ds1-12) dpkg-deb -I nscd_2.3.2.ds1-13_ia64.deb | grep Depends Depends: libc6 (= 2.3.2.ds1-13) Now I look at: http://buildd.debian.org/build.php?pkg=glibc There is no ia64 entry. This means someone uploads ia64 glibc incorretly. Who? Please dupload binary-only for ia64 again. According to the GPG signature on the .changes, it was LaMont ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6.1 2.3.2.ds1-13 ia64 is broken
On Mon, Jun 07, 2004 at 09:31:23PM +0900, GOTO Masanori wrote: At Sun, 6 Jun 2004 20:21:57 +0200, Rene Engelhard wrote: as grep-excuses shows ncsd depends on libc6 on ia64 where the library is libc6.1 (as you surely know ;) ): [...] Ooh what has happened!? dpkg-deb -I nscd_2.3.2.ds1-12_alpha.deb | grep Depends Depends: libc6.1 (= 2.3.2.ds1-12) dpkg-deb -I nscd_2.3.2.ds1-13_alpha.deb | grep Depends Depends: libc6.1 (= 2.3.2.ds1-13) dpkg-deb -I nscd_2.3.2.ds1-12_ia64.deb | grep Depends Depends: libc6.1 (= 2.3.2.ds1-12) dpkg-deb -I nscd_2.3.2.ds1-13_ia64.deb | grep Depends Depends: libc6 (= 2.3.2.ds1-13) Now I look at: http://buildd.debian.org/build.php?pkg=glibc There is no ia64 entry. This means someone uploads ia64 glibc incorretly. Who? Please dupload binary-only for ia64 again. According to the GPG signature on the .changes, it was LaMont ... -- Colin Watson [EMAIL PROTECTED]
Re: cvs commit to glibc-package/debian/control.in by gotom
On Wed, May 12, 2004 at 07:21:49PM -0600, Debian GLibc CVS Master wrote: Repository: glibc-package/debian/control.in who:gotom time: Wed May 12 19:21:49 MDT 2004 Log Message: * Colin Watson [EMAIL PROTECTED] - debian/rules: Add libnss-dns-udeb and libnss-files-udeb. (Closes: #247430) - debian/.cvsignore: Likewise. - debian/control.in/libc: libc-udeb depends on libnss-dns-udeb and libnss-files-udeb. - debian/debhelper.in/libc-udeb.install: Remove libnss_dns and libnss_files. - debian/rules.d/control.mk: Likewise. - debian/control.in/libnss-dns-udeb: Update description. Files: changed:libc libnss-dns-udeb Goto-san, I think you forgot to 'cvs add' the two new files created by my patch: debian/control.in/libnss-files-udeb debian/debhelper.in/libnss-files-udeb.install Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
On Thu, May 06, 2004 at 01:07:08PM +0200, Bastian Blank wrote: On Wed, May 05, 2004 at 07:49:51PM +0100, Colin Watson wrote: On Wed, May 05, 2004 at 09:56:01AM -0700, Jeff Bailey wrote: (3) make libnss-udeb which includes libnss-dns and libnss-files. I think option (3) is probably the best. NACK, it will break our i386 floppies. I don't mind whether you produce libnss-udeb or two separate libnss-*-udeb packages: although check that nothing depends on the existing libnss-dns-udeb (if so, a provides will be needed), and you'll probably break d-i daily builds for a couple of days if you drop libnss-dns-udeb now. If you go for (3) I think you should still do (1) as well: at least, that's the current arrangement with libnss_dns. Option 3 is not possible. Look at the free space on the i386 floppies. Oh yes, that's indeed an issue ... those floppies are unbelievably tight on space but have to include libnss-dns-udeb. I've uploaded openssh udebs, which are in the NEW queue now. We'd really appreciate having a libnss-files-udeb and the augmented libc-udeb as soon as possible so that we can get on with integration work. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248352: more data on the seed48 problem
On Wed, May 12, 2004 at 03:18:44PM +0200, Tomas Pospisek wrote:
Package: libc6
Version: 2.3.2.ds1-12
Severity: normal
Followup-For: Bug #248352
Here are three more datapoints for the seed48 problem.
--- system 1 ---
$ cat kak.c
#include stdlib.h
unsigned short seed[3] = {0x7d1b, 0xa934, 0xbf10};
int main(int argc, char** argv)
{
seed48(seed);
}
The exit value of that program is undefined, as gcc -Wall should have
hinted. Use either 'return seed48(seed);' or 'seed48(seed); return 0;'.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247430: Patch to add libnss-files-udeb
/libnss-files-udeb.install --- /dev/null 1 Jan 1970 00:00:00 - +++ debian/debhelper.in/libnss-files-udeb.install 12 May 2004 17:05:58 - @@ -0,0 +1,3 @@ +# FIXME: someday we may need to handle installing into non-lib. +debian/tmp-libc/lib/libnss_files*.so* lib + Index: debian/rules.d/control.mk === RCS file: /cvs/glibc/glibc-package/debian/rules.d/control.mk,v retrieving revision 1.10 diff -p -u -r1.10 control.mk --- debian/rules.d/control.mk 18 Apr 2004 07:12:38 - 1.10 +++ debian/rules.d/control.mk 12 May 2004 17:05:58 - @@ -25,7 +25,8 @@ debian/control: debian/control.in/main $ cat debian/control.in/sparc64[EMAIL PROTECTED] cat debian/control.in/s390x [EMAIL PROTECTED] cat debian/control.in/opt[EMAIL PROTECTED] - cat debian/control.in/libnss-dns-udeb[EMAIL PROTECTED] + cat debian/control.in/libnss-dns-udeb[EMAIL PROTECTED] + cat debian/control.in/libnss-files-udeb [EMAIL PROTECTED] sed -e '[EMAIL PROTECTED]@%$(libc)%g;[EMAIL PROTECTED]@%glibc%g' \ -e '[EMAIL PROTECTED]@%$(threads_archs)%g' [EMAIL PROTECTED] $@ rm [EMAIL PROTECTED] Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
On Thu, May 06, 2004 at 01:07:08PM +0200, Bastian Blank wrote: On Wed, May 05, 2004 at 07:49:51PM +0100, Colin Watson wrote: On Wed, May 05, 2004 at 09:56:01AM -0700, Jeff Bailey wrote: (3) make libnss-udeb which includes libnss-dns and libnss-files. I think option (3) is probably the best. NACK, it will break our i386 floppies. I don't mind whether you produce libnss-udeb or two separate libnss-*-udeb packages: although check that nothing depends on the existing libnss-dns-udeb (if so, a provides will be needed), and you'll probably break d-i daily builds for a couple of days if you drop libnss-dns-udeb now. If you go for (3) I think you should still do (1) as well: at least, that's the current arrangement with libnss_dns. Option 3 is not possible. Look at the free space on the i386 floppies. Oh yes, that's indeed an issue ... those floppies are unbelievably tight on space but have to include libnss-dns-udeb. I've uploaded openssh udebs, which are in the NEW queue now. We'd really appreciate having a libnss-files-udeb and the augmented libc-udeb as soon as possible so that we can get on with integration work. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#248352: more data on the seed48 problem
On Wed, May 12, 2004 at 03:18:44PM +0200, Tomas Pospisek wrote:
Package: libc6
Version: 2.3.2.ds1-12
Severity: normal
Followup-For: Bug #248352
Here are three more datapoints for the seed48 problem.
--- system 1 ---
$ cat kak.c
#include stdlib.h
unsigned short seed[3] = {0x7d1b, 0xa934, 0xbf10};
int main(int argc, char** argv)
{
seed48(seed);
}
The exit value of that program is undefined, as gcc -Wall should have
hinted. Use either 'return seed48(seed);' or 'seed48(seed); return 0;'.
--
Colin Watson [EMAIL PROTECTED]
Bug#247430: Patch to add libnss-files-udeb
/libnss-files-udeb.install --- /dev/null 1 Jan 1970 00:00:00 - +++ debian/debhelper.in/libnss-files-udeb.install 12 May 2004 17:05:58 - @@ -0,0 +1,3 @@ +# FIXME: someday we may need to handle installing into non-lib. +debian/tmp-libc/lib/libnss_files*.so* lib + Index: debian/rules.d/control.mk === RCS file: /cvs/glibc/glibc-package/debian/rules.d/control.mk,v retrieving revision 1.10 diff -p -u -r1.10 control.mk --- debian/rules.d/control.mk 18 Apr 2004 07:12:38 - 1.10 +++ debian/rules.d/control.mk 12 May 2004 17:05:58 - @@ -25,7 +25,8 @@ debian/control: debian/control.in/main $ cat debian/control.in/sparc64[EMAIL PROTECTED] cat debian/control.in/s390x [EMAIL PROTECTED] cat debian/control.in/opt[EMAIL PROTECTED] - cat debian/control.in/libnss-dns-udeb[EMAIL PROTECTED] + cat debian/control.in/libnss-dns-udeb[EMAIL PROTECTED] + cat debian/control.in/libnss-files-udeb [EMAIL PROTECTED] sed -e '[EMAIL PROTECTED]@%$(libc)%g;[EMAIL PROTECTED]@%glibc%g' \ -e '[EMAIL PROTECTED]@%$(threads_archs)%g' [EMAIL PROTECTED] $@ rm [EMAIL PROTECTED] Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
On Wed, May 05, 2004 at 06:28:05PM +0200, Bastian Blank wrote: On Thu, May 06, 2004 at 01:17:05AM +0900, GOTO Masanori wrote: Waldi, what do you think about creating libnss-files-udeb? IMHO, there're three ways to support libnss-files: (1) libc6-udeb includes libnss_files.so*. (2) make libnss-files-udeb. (3) make libnss-udeb which includes libnss-dns and libnss-files. Colin's decision is (1). 1 and 2. Agreed. This gives us the greatest flexibility in d-i. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
On Wed, May 05, 2004 at 09:56:01AM -0700, Jeff Bailey wrote: On Thu, May 06, 2004 at 01:17:05AM +0900, GOTO Masanori wrote: Waldi, what do you think about creating libnss-files-udeb? IMHO, there're three ways to support libnss-files: (1) libc6-udeb includes libnss_files.so*. (2) make libnss-files-udeb. (3) make libnss-udeb which includes libnss-dns and libnss-files. Colin's decision is (1). If I understand right, this is to work around a current ugly hack in d-i to make sure that nss is actually loaded on the install media. Firstly, libnss-dns-udeb is already available, and the ugly hack you mention has already been removed (although it might have to be reinstated for libnss_files if it were only available in libc6-udeb). Secondly, this bug is that libnss_files is not available in d-i at all. The solution proposed would be to put libnss-udeb onto the boot media with the reduced glibc. libc-udeb would still get used at a later stage in the installer. I think option (3) is probably the best. I don't mind whether you produce libnss-udeb or two separate libnss-*-udeb packages: although check that nothing depends on the existing libnss-dns-udeb (if so, a provides will be needed), and you'll probably break d-i daily builds for a couple of days if you drop libnss-dns-udeb now. If you go for (3) I think you should still do (1) as well: at least, that's the current arrangement with libnss_dns. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
Package: libc6-udeb Version: 2.3.2.ds1-12 Severity: wishlist Tags: d-i Please add libnss_files to libc6-udeb, so that ssh can be made to work in debian-installer. (S/390 would like this, and I believe certain other configurations too.) I understand that we may also need a libnss-files-udeb like the existing libnss-dns-udeb if we want to be able to support sshd in the early stages of the installer. Thanks, -- Colin Watson [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
On Wed, May 05, 2004 at 06:28:05PM +0200, Bastian Blank wrote: On Thu, May 06, 2004 at 01:17:05AM +0900, GOTO Masanori wrote: Waldi, what do you think about creating libnss-files-udeb? IMHO, there're three ways to support libnss-files: (1) libc6-udeb includes libnss_files.so*. (2) make libnss-files-udeb. (3) make libnss-udeb which includes libnss-dns and libnss-files. Colin's decision is (1). 1 and 2. Agreed. This gives us the greatest flexibility in d-i. -- Colin Watson [EMAIL PROTECTED]
Bug#247430: libc6-udeb: please add libnss_files
Package: libc6-udeb Version: 2.3.2.ds1-12 Severity: wishlist Tags: d-i Please add libnss_files to libc6-udeb, so that ssh can be made to work in debian-installer. (S/390 would like this, and I believe certain other configurations too.) I understand that we may also need a libnss-files-udeb like the existing libnss-dns-udeb if we want to be able to support sshd in the early stages of the installer. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
On Thu, Apr 15, 2004 at 09:40:05PM +1000, Herbert Xu wrote:
On Wed, Apr 14, 2004 at 01:59:01PM +0200, Frank K?ster wrote:
This is how dash calls it in _some_ subdirectories:
configuring in tetex
running /bin/sh ./configure --prefix=/usr --enable-ipc --without-dialog\
--without-texinfo --with-system-ncurses --with-x --with-system-zlib \
--with-system-pnglib --with-system-tifflib --with-system-wwwlib \
--with-system-t1lib --disable-multiplatform --enable-shared \
--mandir=/usr/share/man --infodir=${prefix}/share/info \
--cache-file=.././config.cache --srcdir=.
loading cache .././config.cache
That is, dash replaced the first occurence of ${prefix} by the variable
expansion. This shouldn't happen, because it is enclosed in single
quotes.
This is caused by dash's use of fnmatch(3) which appears to break
on patterns containing [\]...].
Here is a sample program to demonstrate it.
#include stdio.h
#include fnmatch.h
int main(int argc, char **argv)
{
printf(%d\n, fnmatch([\\]a], a, 0));
return 0;
}
fnmatch(3) references glob(7), which says:
Character classes
An expression `[...]' where the first character after the lead-
ing `[' is not an `!' matches a single character, namely any of
the characters enclosed by the brackets. The string enclosed
by the brackets cannot be empty; therefore `]' can be allowed
between the brackets, provided that it is the first character.
(Thus, `[][!]' matches the three characters `[', `]' and `!'.)
...
One can remove the special meaning of `?', `*' and `[' by pre-
ceding them by a backslash, or, in case this is part of a shell
command line, enclosing them in quotes. Between brackets these
characters stand for themselves. Thus, `[[?*\]' matches the
four characters `[', `?', `*' and `\'.
Accordingly, I believe that the pattern in your example means
backslash, followed by a, followed by closing square bracket, not what
you think it means.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#240887: Package building problem.
On Thu, Apr 15, 2004 at 09:40:05PM +1000, Herbert Xu wrote:
On Wed, Apr 14, 2004 at 01:59:01PM +0200, Frank K?ster wrote:
This is how dash calls it in _some_ subdirectories:
configuring in tetex
running /bin/sh ./configure --prefix=/usr --enable-ipc --without-dialog\
--without-texinfo --with-system-ncurses --with-x --with-system-zlib \
--with-system-pnglib --with-system-tifflib --with-system-wwwlib \
--with-system-t1lib --disable-multiplatform --enable-shared \
--mandir=/usr/share/man --infodir=${prefix}/share/info \
--cache-file=.././config.cache --srcdir=.
loading cache .././config.cache
That is, dash replaced the first occurence of ${prefix} by the variable
expansion. This shouldn't happen, because it is enclosed in single
quotes.
This is caused by dash's use of fnmatch(3) which appears to break
on patterns containing [\]...].
Here is a sample program to demonstrate it.
#include stdio.h
#include fnmatch.h
int main(int argc, char **argv)
{
printf(%d\n, fnmatch([\\]a], a, 0));
return 0;
}
fnmatch(3) references glob(7), which says:
Character classes
An expression `[...]' where the first character after the lead-
ing `[' is not an `!' matches a single character, namely any of
the characters enclosed by the brackets. The string enclosed
by the brackets cannot be empty; therefore `]' can be allowed
between the brackets, provided that it is the first character.
(Thus, `[][!]' matches the three characters `[', `]' and `!'.)
...
One can remove the special meaning of `?', `*' and `[' by pre-
ceding them by a backslash, or, in case this is part of a shell
command line, enclosing them in quotes. Between brackets these
characters stand for themselves. Thus, `[[?*\]' matches the
four characters `[', `?', `*' and `\'.
Accordingly, I believe that the pattern in your example means
backslash, followed by a, followed by closing square bracket, not what
you think it means.
--
Colin Watson [EMAIL PROTECTED]
Bug#241996:
On Sun, Apr 04, 2004 at 10:18:12AM +0200, Ronny Vaningh wrote: Package: libc6.1 Version: 2.3.2.ds1-11 I cannot ssh to the box anymore after upgrading libc Running sshd in debug results in debug1: permanently_set_uid: 100/65534 setresgid 65534: Function not implemented debug1: do_cleanup I have the same package versions of libC and ssh on a alpha box running a 2.4 kernel, without encountering any problems I think this is bug #23, which I'll be fixing in openssh shortly. However, I'm interested that it occurred following a libc6.1 upgrade. What version of libc6.1 did you have beforehand? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241996:
reassign 241996 ssh severity 241996 important merge 23 241996 thanks On Sun, Apr 04, 2004 at 05:56:18PM +0200, Ronny Vaningh wrote: I was quite sure that I saw libc mentioned as an updated package some days ago ... I keep the box up to date with apt quite regulary The funky thing is that I upgraded the kernel to the 2.4.25 (-1-generic as packaged) and that this seemed to solve my ssh problem as well. Yes, that's not surprising at all. The problem is ssh not coping gracefully with the setresuid() and setresgid() system calls being missing, and they aren't missing in 2.4.25. I was wondering why this failure seemed to be new, but the use of setres[ug]id() is new in OpenSSH 3.7, which would explain it. I bet the upgrade you noticed also included an upgrade from ssh 3.6-* to 3.8-*. Normally I'd request that glibc provide compatibility stubs, but I don't think that's possible for setres[ug]id(), so ssh just has to deal with it. We have another box with the same architecture (norritake) running testing and had no problems with the ssh on the box, but this one was already running a 2.4 kernel for a long time I know this is not what I would call sufficient info ... sorry Oh well; thanks anyway. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#240901: acknowledged by developer (Re: Bug#240901: (no subject))
On Tue, Mar 30, 2004 at 10:16:53PM +0200, Denis Barbier wrote: On Tue, Mar 30, 2004 at 07:00:38PM +0100, Michael Graham wrote: Denis Barbier wrote: According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=140891msg=47 upstream glibc maintainers seem to strongly disagree, so I am closing this bugreport. Yes, but in that bug report en_AU (libc6 version 2.2.5-4) had also no AM/PM text. And this has now changed, hence my bug report. I was wondering if it could be change for en_GB. I was not referring to the bugreport, but this specific message, in particular: Not filling in the am/pm strings is a mean to say that the people in the country the locale is fow are not to backward as to use the am/pm format anymore. This definitely is the case for the UK. Judging by the writing the author of that text isn't a native speaker of English, so I'm not sure where this information comes from. While the AM/PM format is inferior to the 24-hour format in many ways, it is most certainly false to claim that people in the UK do not use the AM/PM format. AM/PM is still significantly more common than 24-hour in UK everyday speech, signs, written communication, and so on, and I think the onus ought to be on the author of the above to back up his extremely surprising statement with facts. To take an example, Hansard, the official records of parliamentary debates in the House of Commons, records times in the AM/PM format: http://www.parliament.the-stationery-office.co.uk/pa/cm200304/cmhansrd/cm040329/debtext/40329-06.htm#40329-06_time0 -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using SVN instead?
On Sun, Mar 21, 2004 at 08:24:39PM -0500, Nathanael Nerode wrote: Jeff Bailey wrote: I prefer svn over arch because svn seems to work close enough to cvs that I don't need to spend much time learning it. I also think that the upstream author of arch is an ass, but that should really be only a very minor consideration. =) I found I had almost zero trouble switching from cvs to svn (oh, except that mysteriously I have to run 'svn up' before committing slightly more often than I had to run 'cvs up' before commiting, but it's really fast, so I don't mind). This should dispel the mystery: http://svnbook.red-bean.com/svnbook/apas02.html Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#230857: Preinst should rename old devpts.sh to mountkernfs
On Fri, Mar 12, 2004 at 01:26:48PM +0100, Thomas Hood wrote: On Fri, 2004-03-12 at 12:11, GOTO Masanori wrote: Exactly, thanks for your pointing out me. It was my fault, I forgot to handle old devpts.sh. I modified preinst as (1) if old glibc version is 2.3.2.ds1-11, rename devpts.sh to mountkernfs (2) if old glibc version is = 2.3.2.ds1-11, remove devpts.sh. In principle this is the right solution. However, think you should hold off making any more changes until you have discussed the matter with Miquel. I gather that mountkernfs is going to be replaced by a script in the initscripts package which will run at S02. The initscripts package will have to take care of upgrading from all the different ways that libc6 has installed devpts.sh and mountkernfs and it will be easier to do that if libc6 isn't trying to move things around at the same time. I have already discussed this briefly with Miquel. I hope that S02mountkernfs will be implemented soon because we should have some weeks before Sarge's release to work out bugs. Can I remind people that we're planning to freeze the base system for everything except RC bugs on 15th March? (It may slip by a few days, but I very much hope not by much.) -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sem_wait (etc.) manpage
On Mon, Mar 01, 2004 at 12:14:17PM +0100, Peter van Rossum wrote: A friend of mine is looking on his Debian system for the manual page of sem_wait. Do you know where this can be found? I expected it in manpages-dev or maybe in some glibc package, but packages.debian.org doesn't show it anywhere. There seems to be a French translation of it though, funnily enough. His redhad system is happy with man sem_wait, so I feel I should at least come up with a reasonable explanation :-) It's part of sem_init(3) in glibc-doc. man should manage to find it anyway if its database is up-to-date. However, there's a bug here: glibc-doc should include symlinks for sem_wait, sem_trywait, sem_post, sem_getvalue, sem_destroy rather than expecting man to sort it out based on the header of the man page. See policy section 12.1. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#160932: bash: fileglobbing broken with LANG=sv_SE
On Sun, Jan 25, 2004 at 12:07:11PM +0100, Matthias Klose wrote: Tobias writes: Attached is a small script that shows the difference between the too. Personally I think the tcsh is better sorted because of the difference between A and a. bash's behaviour is different than tcsh, dash, zsh, ksh. bash --norc LANG=sv_SE power-post-setup.bmp ls: [A-Z][A-Z]*: No such file or directory ls: [A-Z][A-Z]*: No such file or directory all other shells don't show the file with the lowercase letter. reading bash(1)'s Environment section, one might think, that explicitely setting LC_CTYPE would help, but it does not: LC_COLLATE=C would be what makes the difference, I'd've thought? $ export LANG=en_GB.ISO-8859-1 $ ls -d [A-Z][A-Z]* bin debian misc mp3 public_html src tmp $ export LC_COLLATE=C $ ls -d [A-Z][A-Z]* ls: [A-Z][A-Z]*: No such file or directory -- Colin Watson [EMAIL PROTECTED]
Bug#229461: libc6 - fails to install - uses awk in preinst
On Sun, Jan 25, 2004 at 12:58:19AM +0100, Bastian Blank wrote: Package: libc6 Version: 2.3.2.ds1-11 Severity: grave Seems out of order: it's not broken for everyone. libc6 failes to install: | Unpacking libc6 (from .../libc6_2.3.2.ds1-11_i386.deb) ... | /var/lib/dpkg/tmp.ci/preinst: line 1: awk: command not found | dpkg: error processing /var/cache/apt/archives/libc6_2.3.2.ds1-11_i386.deb (--unpack): | subprocess pre-installation script returned error exit status 127 awk is provided by mawk which is not essential. Santiago Vila has said a number of times in the past that awk is a virtual essential package: you have to have one implementation of it, even though neither is itself essential, and packages are allowed to assume its existence. The base-files dependency on awk mentioned by Jeff implements this. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#229461: libc6 - fails to install - uses awk in preinst
On Sun, Jan 25, 2004 at 12:58:19AM +0100, Bastian Blank wrote: Package: libc6 Version: 2.3.2.ds1-11 Severity: grave Seems out of order: it's not broken for everyone. libc6 failes to install: | Unpacking libc6 (from .../libc6_2.3.2.ds1-11_i386.deb) ... | /var/lib/dpkg/tmp.ci/preinst: line 1: awk: command not found | dpkg: error processing /var/cache/apt/archives/libc6_2.3.2.ds1-11_i386.deb (--unpack): | subprocess pre-installation script returned error exit status 127 awk is provided by mawk which is not essential. Santiago Vila has said a number of times in the past that awk is a virtual essential package: you have to have one implementation of it, even though neither is itself essential, and packages are allowed to assume its existence. The base-files dependency on awk mentioned by Jeff implements this. -- Colin Watson [EMAIL PROTECTED]
Bug#214898: Testing/help needed - experimental glibc version
On Thu, Oct 23, 2003 at 11:10:55AM +0900, GOTO Masanori wrote: At Wed, 22 Oct 2003 11:24:19 -0400, Daniel Jacobowitz wrote: Currently, the default locale setting for the system can be accessed only through /etc/environment, which is a configuration file for PAM. Setting the locale for a daemon currently requires to parse this file, but it is just not the way to go. If, additionnaly to the /etc/environment stuff, the debconf-selected locale was put into /etc/default_locale (a file just containing the locale, nothing else), as suggested Ryan Murray, it would make it much easier for daemons to set their locale to the system default, without relying on an error-prone environment setting. Such a file would be necessary to get a correctly localized gdm for sarge. I think it is fairly easy to achieve, and it could even be used later (after the sarge release) to set the locale using a specific PAM module, instead of using pam_env. This wishlist needs a bit consideration. (1) We store locale setting for 2 files - /etc/environment, /etc/default_locale. Is it good idea? (2) Why do you need to read /etc/default_locale instead of /etc/environment? Is it hard to parse /etc/environment so hard? The locales package already gets it wrong, as it happens. :-) It assumes that quoting is supported when it isn't. I expect that others would make the same mistake. (3) I guess gdm issue is the locale dialog in the login screen. Why can't gdm read /etc/environment file? If you mean it's easier to read /etc/default_locale than to parse /etc/environment, yes it may become one of the reason. But does this change fix the gdm issue? /etc/environment is a configuration file owned by PAM and parsed by the pam_env module at login time. As such, it's a good place to set the default locale for PAM sessions. However, all the world is not a PAM session. gdm before login is one example; init scripts are another; perhaps the login: banner is a third. I don't think it's right for these programs to be parsing a PAM configuration file when they aren't dealing with PAM sessions; they're a completely separate case. In fact, I can certainly imagine cases where I'd want the outside-a-session locale and the default PAM session locale to be different. Say I speak French, but most of my users are German, so for their benefit I decide that the default session locale should be German, but I want to see init scripts localized in French so that I can work out what's going on more easily. Or maybe I want to use LANG=C for init scripts but default to a Unicode locale for sessions where I expect terminal support to be better. It seems to me that having separate configuration for locales outside and inside a session could be useful in the same way as having different locales for different sessions. I'd suggest, though, that /etc/default_locale is a poor name for this; it sounds like it's the file you want to edit for the default locale throughout the system, when in fact it just applies to programs running before login. How about something like /etc/boot-locale or /etc/default/boot-locale, with a comment at the top when generated by locales explaining its purpose? Or maybe /etc/environment-prelogin or similar would be a better name, and it wouldn't have to be limited to locale configuration. Either way, the format should be simple and clearly specified somewhere that's easy to find so that people don't make the mistakes they do when trying to parse /etc/environment. I've cc'ed the PAM maintainer in case I've made any grievous errors in the above. Is there support for comments in /etc/environment? If so, we could also add a comment there directing people to /etc/default/boot-locale or whatever for things that are to affect programs that run before login. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#226836: libc6: syntax error in devpts.sh init script
On Thu, Jan 08, 2004 at 06:56:50PM +0100, Kilian CAVALOTTI wrote: Package: libc6 Version: 2.3.2.ds1-10 Severity: normal Line 17 from /etc/init.d/devpts.sh should be: if [[ $devfs_mounted = 0 $devpts_avail != 0 ]] instead of: if [ $devfs_mounted = 0 $devpts_avail != 0 ] It would be better to use a portable shell construct, such as: if [ $devfs_mounted = 0 ] [ $devpts_avail != 0 ] ([[ ... ]] is bash-specific.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#226836: libc6: syntax error in devpts.sh init script
On Thu, Jan 08, 2004 at 06:56:50PM +0100, Kilian CAVALOTTI wrote: Package: libc6 Version: 2.3.2.ds1-10 Severity: normal Line 17 from /etc/init.d/devpts.sh should be: if [[ $devfs_mounted = 0 $devpts_avail != 0 ]] instead of: if [ $devfs_mounted = 0 $devpts_avail != 0 ] It would be better to use a portable shell construct, such as: if [ $devfs_mounted = 0 ] [ $devpts_avail != 0 ] ([[ ... ]] is bash-specific.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#226345: glibc-doc: Incorrect and unsightly formatting in man pages
On Mon, Jan 05, 2004 at 04:15:56PM -0500, Gregory Stark wrote: There seems to be a strange use of exclamation marks to emphasize text in the glibc-doc man pages. This is not how man pages are formatted. Looking at other man pages it seems the nroff code that should be used for these cases is .BR. Yes, specifically: .BR pthread_equal (3), .BR pthread_join (3), [etc.] This macro just alternates its arguments between bold and roman fonts. (As a point of pedantry, this isn't a feature of [nt]roff itself, but of the -man macro set. The -mdoc macro set, commonly used in BSD-derived documentation, uses the .Xr macro to format cross-references.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time
On Wed, Dec 31, 2003 at 06:46:50PM +0100, Marc Haber wrote: On Wed, Dec 31, 2003 at 04:59:48PM +, Colin Watson wrote: Wouldn't it be much easier and less confusing to users to copy the relevant headers into the packages that need them to build? Probably. But that's a politics decision. I only want my backports to work, and I prefer not spending entire working days for a single backport ;) This has the added advantage of being what you're supposed to do anyway, but it should be easy enough to do that in a backport ... The problem is that my experience shows that a backport works best the less you have changed in the packages. Let me offer another reason, then: backports also work best when the change to the user's system is minimal. Yet what you're proposing is to take a system whose glibc was built with 2.4 kernel headers and shove 2.6 kernel headers onto its include path. Now when you include libc headers which in turn include kernel headers (which is the latter's purpose in life), they'll inevitably pick up the 2.6 ones, and suddenly you've changed the world under the libc's feet. This might work sometimes - maybe even a lot of the time - but, well, good luck untangling the mess when it does go wrong. Copying single header files is much less invasive, and any problems you do see that way will be much easier to debug. Additionally, huge backport patches make it harder to backport later versions. Almost all of the patch would simply be adding files, and then you might have a trivial change to the include path if you're unlucky. This wouldn't be hard at all. Plus, you can probably get the maintainer to include the same patch in later versions. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time
On Wed, Dec 31, 2003 at 06:46:50PM +0100, Marc Haber wrote: On Wed, Dec 31, 2003 at 04:59:48PM +, Colin Watson wrote: Wouldn't it be much easier and less confusing to users to copy the relevant headers into the packages that need them to build? Probably. But that's a politics decision. I only want my backports to work, and I prefer not spending entire working days for a single backport ;) This has the added advantage of being what you're supposed to do anyway, but it should be easy enough to do that in a backport ... The problem is that my experience shows that a backport works best the less you have changed in the packages. Let me offer another reason, then: backports also work best when the change to the user's system is minimal. Yet what you're proposing is to take a system whose glibc was built with 2.4 kernel headers and shove 2.6 kernel headers onto its include path. Now when you include libc headers which in turn include kernel headers (which is the latter's purpose in life), they'll inevitably pick up the 2.6 ones, and suddenly you've changed the world under the libc's feet. This might work sometimes - maybe even a lot of the time - but, well, good luck untangling the mess when it does go wrong. Copying single header files is much less invasive, and any problems you do see that way will be much easier to debug. Additionally, huge backport patches make it harder to backport later versions. Almost all of the patch would simply be adding files, and then you might have a trivial change to the include path if you're unlucky. This wouldn't be hard at all. Plus, you can probably get the maintainer to include the same patch in later versions. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#225300: libc6-dev: sys/poll.h do not define POLLRDNORM
On Wed, Dec 31, 2003 at 01:16:06AM +0100, Simone Piccardi wrote: On Tue, 2003-12-30 at 04:23, Colin Watson wrote: This definitely implies to me that you need to define _XOPEN_SOURCE (__USE_XOPEN may have the same effect but it's supposed to be set by features.h, not the user) in order to get this constant. See 'info libc Feature Test Macros' for information on this kind of thing. Sorry, I was not clear. I defined _XOPEN_SOURCE. But still not working. I'll find the program that do not work in the attachment, and those are the errors: gcc -L./ -lgapil -Wall -g -fPIC poll_echod.c -o pechod poll_echod.c: In function `main': poll_echod.c:167: error: `POLLRDNORM' undeclared (first use in this function) poll_echod.c:167: error: (Each undeclared identifier is reported only once poll_echod.c:167: error: for each function it appears in.) You must #define _XOPEN_SOURCE before anything that #includes features.h. Since that covers practically all system headers, it's best to put the #define before any #include lines. When I make this modification to your test case, the error about POLLRDNORM disappears. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#225671: linux-kernel-headers: please consider making target directory configurable on build time
On Wed, Dec 31, 2003 at 01:24:01PM +0100, Marc Haber wrote: linux-kernel-headers places the headers in /usr/include, which is fine for a sarge or sid system. On woody, however, this makes linux-kernel-headers uninstallable if one doesn't want to update glibc (which is usually exactly what you want to avoid when using woody+backports). Some packages need more recent kernel headers to build (for example, devmapper). To help backporting these packages, it would be a good idea to have an option to build a linux-kernel-headers package that doesn't conflict with woody's libc6-dev. Wouldn't it be much easier and less confusing to users to copy the relevant headers into the packages that need them to build? This has the added advantage of being what you're supposed to do anyway, but it should be easy enough to do that in a backport ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#196177: What's news ?
On Wed, Dec 31, 2003 at 07:39:04AM -0800, Jeff Bailey wrote: On Wed, Dec 31, 2003 at 03:52:42PM +0100, Stephane Leclerc wrote: Package: libc6 Version: 2.3.2.ds1-10 Severity: grave Tags: sid The problem is still present on SID with the last libc6 2.3.2.ds1-10. I previously posted a report on this. Could you please merge both bug reports. Please justify the grave severity. Please do not intentionally open duplicate bug reports. This will only slow us down. He didn't; he just confusingly sent a mail to [EMAIL PROTECTED] formatted as if it were going to [EMAIL PROTECTED] (This may be reportbug brain-damage; I've seen other people doing it too.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#225304: libc6-dev: OPEN_MAX undeclared after using limits.h
On Sun, Dec 28, 2003 at 04:17:07PM +0100, Simone Piccardi wrote: Package: libc6-dev Version: 2.3.2.ds1-10 Severity: normal I'm trying to use OPEN_MAX in a sample program. But it get not declared also after including limits.h. This is deliberate and not a bug. For example, /usr/include/bits/local_lim.h says: /* The kernel header pollutes the namespace with the NR_OPEN symbol and defines LINK_MAX although filesystems have different maxima. A similar thing is true for OPEN_MAX: the limit can be changed at runtime and therefore the macro must not be defined. Remove this after including the header if necessary. */ POSIX does not require OPEN_MAX to be defined as a macro. If such a macro is not defined, you should use sysconf(_SC_OPEN_MAX) to discover the current value. See 'info libc General Limits', particularly the first two paragraphs. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Looking at upstream CVS
On Sat, Dec 27, 2003 at 02:13:45PM -0500, Jeff Bailey wrote: We were holding off a new cvs update until the Sarge release. That doesn't appear to be soon, since there are still buildds that are offline. Scared now. I think a significant new glibc upstream pull right now can only push the sarge release back even further, really. The situation I want to be in is one where we don't have to try to squeeze features into each release because the next one will be reasonably quick; as far as the time to start with that approach goes, now seems pretty good to me. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#225300: libc6-dev: sys/poll.h do not define POLLRDNORM
On Sun, Dec 28, 2003 at 04:15:16PM +0100, Simone Piccardi wrote: Package: libc6-dev Version: 2.3.2.ds1-10 Severity: normal I'm writing an example program using poll. But after including sys/poll.h I still have a 'POLLRDNORM' undeclared error. To have it defined I must define __USE_XOPEN, but no mention of this in the man page. The poll(2) man page on my system, from manpages-dev 1.62-1, reads as follows (in part): The following possible bits in these masks are defined in sys/poll.h #define POLLIN 0x0001/* There is data to read */ #define POLLPRI 0x0002/* There is urgent data to read */ #define POLLOUT 0x0004/* Writing now will not block */ #define POLLERR 0x0008/* Error condition */ #define POLLHUP 0x0010/* Hung up */ #define POLLNVAL0x0020/* Invalid request: fd not open */ When compiling XPG4.2 source one also has #ifdef _XOPEN_SOURCE #define POLLRDNORM 0x0040/* Normal data may be read */ #define POLLRDBAND 0x0080/* Priority data may be read */ #define POLLWRNORM 0x0100/* Writing now will not block */ #define POLLWRBAND 0x0200/* Priority data may be written */ #endif Finally, Linux knows about #ifdef _GNU_SOURCE #define POLLMSG 0x0400 #endif This definitely implies to me that you need to define _XOPEN_SOURCE (__USE_XOPEN may have the same effect but it's supposed to be set by features.h, not the user) in order to get this constant. See 'info libc Feature Test Macros' for information on this kind of thing. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#225304: libc6-dev: OPEN_MAX undeclared after using limits.h
On Sun, Dec 28, 2003 at 04:17:07PM +0100, Simone Piccardi wrote: Package: libc6-dev Version: 2.3.2.ds1-10 Severity: normal I'm trying to use OPEN_MAX in a sample program. But it get not declared also after including limits.h. This is deliberate and not a bug. For example, /usr/include/bits/local_lim.h says: /* The kernel header pollutes the namespace with the NR_OPEN symbol and defines LINK_MAX although filesystems have different maxima. A similar thing is true for OPEN_MAX: the limit can be changed at runtime and therefore the macro must not be defined. Remove this after including the header if necessary. */ POSIX does not require OPEN_MAX to be defined as a macro. If such a macro is not defined, you should use sysconf(_SC_OPEN_MAX) to discover the current value. See 'info libc General Limits', particularly the first two paragraphs. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#224135: libc6: suggests non-existant package
On Tue, Dec 16, 2003 at 12:55:41PM +0300, Al Nikolov wrote: Package: libc6 Version: 2.2.5-11.5 Severity: minor Package 'glibc-doc' doesn't exist in woody. It does exist. My woody box says: $ apt-cache show glibc-doc Package: glibc-doc Priority: optional Section: doc Installed-Size: 6360 Maintainer: Ben Collins [EMAIL PROTECTED] Architecture: all Source: glibc Version: 2.2.5-11.5 Replaces: libc-doc, libc6-doc, glibcdoc Provides: libc-doc Conflicts: libc-doc, libc6-doc, glibcdoc Filename: pool/main/g/glibc/glibc-doc_2.2.5-11.5_all.deb Size: 2698954 MD5sum: a4b3499f4f86d31796017956595f18c2 Description: GNU C Library: Documentation Contains The GNU C Library Reference manual in info and html format as well as man pages for libpthread functions. Also included is the complete GNU C Library ChangeLog. Task: c-dev -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#224135: libc6: suggests non-existant package
On Tue, Dec 16, 2003 at 12:55:41PM +0300, Al Nikolov wrote: Package: libc6 Version: 2.2.5-11.5 Severity: minor Package 'glibc-doc' doesn't exist in woody. It does exist. My woody box says: $ apt-cache show glibc-doc Package: glibc-doc Priority: optional Section: doc Installed-Size: 6360 Maintainer: Ben Collins [EMAIL PROTECTED] Architecture: all Source: glibc Version: 2.2.5-11.5 Replaces: libc-doc, libc6-doc, glibcdoc Provides: libc-doc Conflicts: libc-doc, libc6-doc, glibcdoc Filename: pool/main/g/glibc/glibc-doc_2.2.5-11.5_all.deb Size: 2698954 MD5sum: a4b3499f4f86d31796017956595f18c2 Description: GNU C Library: Documentation Contains The GNU C Library Reference manual in info and html format as well as man pages for libpthread functions. Also included is the complete GNU C Library ChangeLog. Task: c-dev -- Colin Watson [EMAIL PROTECTED]
Re: Bug#223170: linux-ntfs: FTBFS: SCSI_DISK_MAJOR undeclared
On Thu, Dec 11, 2003 at 12:51:26PM +0100, David Martinez CSIC RedIRIS wrote: El Domingo, 7 de Diciembre de 2003 03:19, Daniel Schepler escribió: Package: linux-ntfs Severity: serious Version: 1.7.1-4 From my build log: ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include-D_FILE_OFFSET_BITS=64 -Wall -fms-extensions -O2 -c sd.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include-D_FILE_OFFSET_BITS=64 -Wall -fms-extensions -O2 -c mkntfs.c mkntfs.c: In function `main': mkntfs.c:2582: error: `SCSI_DISK_MAJOR' undeclared (first use in this Hello, Daniel. This is due to the linux-kernel-headers new package. I don't know why has broken my package, and I suspect that many other packages will be affected. This usually means you're including headers such as linux/*.h or asm/*.h directly rather than copying the bits of kernel interface you need (there are currently no userspace-safe headers describing the interface exposed by the kernel). See /usr/share/doc/linux-kernel-headers/README.Debian. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#223170: linux-ntfs: FTBFS: SCSI_DISK_MAJOR undeclared
On Thu, Dec 11, 2003 at 12:51:26PM +0100, David Martinez CSIC RedIRIS wrote: El Domingo, 7 de Diciembre de 2003 03:19, Daniel Schepler escribió: Package: linux-ntfs Severity: serious Version: 1.7.1-4 From my build log: ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include-D_FILE_OFFSET_BITS=64 -Wall -fms-extensions -O2 -c sd.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include-D_FILE_OFFSET_BITS=64 -Wall -fms-extensions -O2 -c mkntfs.c mkntfs.c: In function `main': mkntfs.c:2582: error: `SCSI_DISK_MAJOR' undeclared (first use in this Hello, Daniel. This is due to the linux-kernel-headers new package. I don't know why has broken my package, and I suspect that many other packages will be affected. This usually means you're including headers such as linux/*.h or asm/*.h directly rather than copying the bits of kernel interface you need (there are currently no userspace-safe headers describing the interface exposed by the kernel). See /usr/share/doc/linux-kernel-headers/README.Debian. -- Colin Watson [EMAIL PROTECTED]
Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel
On Wed, Dec 10, 2003 at 08:43:14PM +0100, Karsten Merker wrote: On Wed, Dec 10, 2003 at 06:45:18PM +0100, Massimo Cetra wrote: The bug report has been closed. What about adding a notice, a conflicts or a dependencies to the .deb package? It should at least warn before causing problems. The reason is quite simple - the Cobalts are not yet an officially supported subarchitecture in Debian. We are working on it, but before they can get officially supported, a bunch of Cobalt-specific issues must be resolved. The glibc packagers cannot define a conflicts against a kernel package which does not exist yet. Conflicts on kernel packages are a dubious idea anyway: kernel packages you happen to have installed don't necessarily correspond to what you're running, and you don't have to use kernel packages at all. They are therefore both annoying and unreliable, which is not the best combination. libc's preinst has some uname checks in place of such conflicts. -- Colin Watson [EMAIL PROTECTED]
Bug#223547: Libc6 2.3.2.ds1-10 breaks system functionality on mipsel
On Wed, Dec 10, 2003 at 08:43:14PM +0100, Karsten Merker wrote: On Wed, Dec 10, 2003 at 06:45:18PM +0100, Massimo Cetra wrote: The bug report has been closed. What about adding a notice, a conflicts or a dependencies to the .deb package? It should at least warn before causing problems. The reason is quite simple - the Cobalts are not yet an officially supported subarchitecture in Debian. We are working on it, but before they can get officially supported, a bunch of Cobalt-specific issues must be resolved. The glibc packagers cannot define a conflicts against a kernel package which does not exist yet. Conflicts on kernel packages are a dubious idea anyway: kernel packages you happen to have installed don't necessarily correspond to what you're running, and you don't have to use kernel packages at all. They are therefore both annoying and unreliable, which is not the best combination. libc's preinst has some uname checks in place of such conflicts. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#221850: libc6: resolving broken since ds1-10
On Thu, Nov 20, 2003 at 02:27:32PM +0200, Martin-ric Racine wrote: Package: libc6 Version: 2.3.2.ds1-10 Severity: important Several applications which depend either upon /etc/hosts or upon proper resolving of filesystem paths accross a connection have started failing, since a few days: 1) The stanza 'scp /path/to/file remote:/path/to/' no longer works. 2) NFS mounting from 'remote:/path' no longer works; I end up having to specify 'remote.domain:/path'. 3) Hotway (the Hotmail-to-POP3 gateway) no longer succeeds in fetching mail. I don't maintain glibc, but perhaps information such as an strace of one of these applications would be useful? Failing is usually too little to go on. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux omena 2.4.22-ben2 #1 ti syyskuun 23. 21:23:03 EEST 2003 ppc FWIW, I have no problems with 2.6.0-test9(-bensomethingorother) on powerpc; I don't run 2.4 routinely since it doesn't support X on my graphics card, but I could give it a quick go at some point. That said, I believe I upgraded it to something in the 2.3.2.ds1 series at one point while still running 2.4 without obvious problems. -- Colin Watson [EMAIL PROTECTED]
Bug#221850: libc6: resolving broken since ds1-10
On Thu, Nov 20, 2003 at 02:27:32PM +0200, Martin-ric Racine wrote: Package: libc6 Version: 2.3.2.ds1-10 Severity: important Several applications which depend either upon /etc/hosts or upon proper resolving of filesystem paths accross a connection have started failing, since a few days: 1) The stanza 'scp /path/to/file remote:/path/to/' no longer works. 2) NFS mounting from 'remote:/path' no longer works; I end up having to specify 'remote.domain:/path'. 3) Hotway (the Hotmail-to-POP3 gateway) no longer succeeds in fetching mail. I don't maintain glibc, but perhaps information such as an strace of one of these applications would be useful? Failing is usually too little to go on. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux omena 2.4.22-ben2 #1 ti syyskuun 23. 21:23:03 EEST 2003 ppc FWIW, I have no problems with 2.6.0-test9(-bensomethingorother) on powerpc; I don't run 2.4 routinely since it doesn't support X on my graphics card, but I could give it a quick go at some point. That said, I believe I upgraded it to something in the 2.3.2.ds1 series at one point while still running 2.4 without obvious problems. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220910: Please reopen
On Sat, Nov 15, 2003 at 05:13:33PM +0100, Erwan David wrote: [...] cc -g -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -DNO_EXPOSE_COMPRESSION -I/usr/include/libart-2.0/libart_lgpl/ -I/usr/include/libart-2.0/ -I/usr/include/gdk-pixbuf-1.0 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c -o main.o main.c main.c: In function `ParseArgs': main.c:19: warning: implicit declaration of function `getopt' main.c:23: warning: control reaches end of non-void function main.c: At top level: main.c:16: warning: `ParseArgs' defined but not used Why did getopt disappear ? You're using -ansi, which causes some header files to disable functions not called for by ISO C. getopt() is one such. If you remove that flag you should find that getopt() reappears. See the documentation of the -ansi flag. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#220910: Please reopen
On Sat, Nov 15, 2003 at 05:34:38PM +0100, Erwan David wrote: Le Sat 15/11/2003, Colin Watson disait You're using -ansi, which causes some header files to disable functions not called for by ISO C. getopt() is one such. If you remove that flag you should find that getopt() reappears. See the documentation of the -ansi flag. whole unistd.h is outside iso C, so you mean al unistd.h is unusable using -ansi ? The include of getopt.h in unistd.h is within #ifdef __USE_POSIX2. I think unistd.h assumes IEEE Std 1003.1 by default, which presumably doesn't include getopt(). See the top of /usr/include/features.h for more; it looks like you could define _POSIX_C_SOURCE to 2 in addition to -ansi, for example. -- Colin Watson [EMAIL PROTECTED]
Bug#220910: Please reopen
On Sat, Nov 15, 2003 at 05:13:33PM +0100, Erwan David wrote: [...] cc -g -ansi -pedantic -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -DNO_EXPOSE_COMPRESSION -I/usr/include/libart-2.0/libart_lgpl/ -I/usr/include/libart-2.0/ -I/usr/include/gdk-pixbuf-1.0 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -c -o main.o main.c main.c: In function `ParseArgs': main.c:19: warning: implicit declaration of function `getopt' main.c:23: warning: control reaches end of non-void function main.c: At top level: main.c:16: warning: `ParseArgs' defined but not used Why did getopt disappear ? You're using -ansi, which causes some header files to disable functions not called for by ISO C. getopt() is one such. If you remove that flag you should find that getopt() reappears. See the documentation of the -ansi flag. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220910: Please reopen
On Sat, Nov 15, 2003 at 05:34:38PM +0100, Erwan David wrote: Le Sat 15/11/2003, Colin Watson disait You're using -ansi, which causes some header files to disable functions not called for by ISO C. getopt() is one such. If you remove that flag you should find that getopt() reappears. See the documentation of the -ansi flag. whole unistd.h is outside iso C, so you mean al unistd.h is unusable using -ansi ? The include of getopt.h in unistd.h is within #ifdef __USE_POSIX2. I think unistd.h assumes IEEE Std 1003.1 by default, which presumably doesn't include getopt(). See the top of /usr/include/features.h for more; it looks like you could define _POSIX_C_SOURCE to 2 in addition to -ansi, for example. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#220517: linux-kernel-headers: I2C support broken, prevents building several packages
On Thu, Nov 13, 2003 at 04:14:02PM +0200, Martin-Éric Racine wrote: On Wed, 12 Nov 2003, Daniel Jacobowitz wrote: Kindly read any of the hundred explanations of this decision in the -glibc or -devel archives before ranting about it. Been there, done that, still vehemently oppose to making libc6-dev depend upon the headers of a largely experimental and unproven kernel, namely 2.6-pre9. If it makes a difference to anything you're trying to compile, then that program is very likely buggy. Do not include linux/*.h directly; it's as simple as that. libc6-dev must depend upon a _proven_, _stable_and _trustable_ kernel branch; 2.6 is not one of those, while 2.4 definitely is. You still can't do NPTL with 2.4 headers, though. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#220517: linux-kernel-headers: I2C support broken, prevents building several packages
On Thu, Nov 13, 2003 at 04:14:02PM +0200, Martin-Éric Racine wrote: On Wed, 12 Nov 2003, Daniel Jacobowitz wrote: Kindly read any of the hundred explanations of this decision in the -glibc or -devel archives before ranting about it. Been there, done that, still vehemently oppose to making libc6-dev depend upon the headers of a largely experimental and unproven kernel, namely 2.6-pre9. If it makes a difference to anything you're trying to compile, then that program is very likely buggy. Do not include linux/*.h directly; it's as simple as that. libc6-dev must depend upon a _proven_, _stable_and _trustable_ kernel branch; 2.6 is not one of those, while 2.4 definitely is. You still can't do NPTL with 2.4 headers, though. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218639: Processed: Re: Bug#218639: vlc_0.6.2+cvs20031030-2(hppa/unstable): FTBFS: compile errors
reassign 218639 vlc thanks On Tue, Nov 04, 2003 at 09:48:22AM -0600, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: reassign 218639 linux-kernel-headers Bug#218639: vlc_0.6.2+cvs20031030-2(hppa/unstable): FTBFS: compile errors Bug reassigned from package `vlc' to `linux-kernel-headers'. According to the changelog, the problems with including linux/videodev.h have been fixed in linux-kernel-headers 2.5.999-test7-bk-7. That said, as I understand it you should be making a local copy of the header files you need from /usr/include/linux rather than including them directly. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bug#217355: acknowledged by developer (fixed)
On Thu, Nov 06, 2003 at 06:22:11PM +0100, Hervé Eychenne wrote: On Thu, Nov 06, 2003 at 01:47:14AM +, Colin Watson wrote: Anyway, just wait a bit and it'll be fine, or download the older version of locales by hand. It's not difficult. While waiting or downgrading is an option, I simply insist on the fact that this problem shouldn't issue _at all_, and that it should be fixed by preventing this from happening. If you don't want this to happen, use testing rather than unstable. It's designed to insulate you from (most of) these kinds of problems. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Reopening #218561 (libc6 relocation error)?
On Wed, Nov 05, 2003 at 11:56:57AM +, Colin Watson wrote: On Wed, Nov 05, 2003 at 12:22:26PM +0100, Martin Pitt wrote: [EMAIL PROTECTED]:~/debian/epstool-3.02$ grep -r errno . ./src/epstool.c:#include errno.h ./src/epstool.c:fprintf(stderr, Failed to fork, error=%d\n, errno); ./src/epstool.c:fprintf(stderr, Failed to open stdin/out/err, error=%d\n, errno); ./src/epstool.c:fprintf(stderr, Failed to execute ghostscript, error=%d\n, errno); So epstool.c is the _only_ source file requiring and using errno and it properly includes errno.h. I just found out that it works again if I include errno.h in the module clfile.c. When I run 'gcc -E clfile.c' I see that /usr/include/linux/unistd.h says 'extern int errno;' (for _llseek(), I think). This seems like the real bug, doesn't it? Oh yes, also, clfile.c includes linux/unistd.h. You're not supposed to do this from userspace. Don't include kernel headers from userspace and you won't be vulnerable to this kind of problem. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Exceptions to record for glibc
On Mon, Nov 03, 2003 at 11:51:26PM +0100, Josip Rodin wrote: On Mon, Nov 03, 2003 at 01:49:58PM -0500, Daniel Jacobowitz wrote: setuid-binary usr/lib/pt_chown 4755 root/root is intentional in libc* statically-linked-binary ./sbin/ldconfig is intentional. The lintian -iIv output sais to email this address. If these should be in the BTS, please let me know. Can't we override this with a file in the package? At least we used to be able to. You can, and should :) ... to elaborate, /usr/share/lintian/overrides/libc6 etc.; there should be several existing files in that directory on any system demonstrating the format. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219045: locales: Can't get rid of es_ES@euro locale
On Tue, Nov 04, 2003 at 01:21:02PM +0100, Quim Gil wrote: On dt, 2003-11-04 at 05:32, Daniel Jacobowitz wrote: Try your home directory? Nothing apparently. es_ES appears in the following documents: /home/qgil/vell/home/qgil/evolution/local/Inbox/mbox /home/qgil/evolution/local/Inbox/mbox /home/qgil/evolution/local/Inbox/mbox.ev-summary /home/qgil/evolution/local/Sent/mbox /home/qgil/evolution/local/Sent/mbox.ev-summary /home/qgil/evolution/local/debian/mbox /home/qgil/interactors/config.php Did you remember to grep dotfiles as well, or did you say '*' (which won't include dotfiles in the current directory)? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
