Bug#626472: libc6: gethostbyname fails if label ends with dash
Package: libc6
Version: 2.11.2-10
Severity: normal
Compare:
$ host foo-.tumblr.com
foo-.tumblr.com is an alias for proxy-tumblelogs.d1.tumblr.com.
proxy-tumblelogs.d1.tumblr.com has address 174.121.98.168
$
and
$ getent hosts foo-.tumblr.com
$ echo $?
2
$
By contrast:
$ getent hosts foo.tumblr.com
174.121.98.168 proxy-tumblelogs.d1.tumblr.com foo.tumblr.com
tcpdump/wireshark shows that the DNS query for foo-.tumblr.com does go
out, and is answered with the CNAME and A (for
proxy-tumblelogs.d1.tumblr.com), but gethostbyname just returns
failure with errno set to EBADMSG. Here's a test program that shows
that:
#include
#include
#include
#include
#include
int main (int argc, char *argv[]) {
char *hostname = "foo-.tumblr.com";
struct hostent *r=gethostbyname2(hostname, AF_INET);
perror("ghbn2 returned error");
return 0;
}
As a consequence, any program that uses gethostbyname (and possibly
other glibc name resolution interfaces) cannot resolve any domain name
that contain a label that ends with a dash, or possibly this is
limited to the ones that resolve to a CNAME.
Labels that end with a dash ("-") in in a domain name are not 100%
RFC-conformant, but they are used in the wild, e.g. in
http://barefeetdreams-.tumblr.com/
I presume that the DNS stub resolver of "other OS" accepts to resolve
such a name, else the author of the above page would have noticed her
blog is not reachable.
On a Debian GNU/Linux machine, trying to load this URL won't work,
obviously, because of this bug. You can work around that and check for
yourself there is an active website behind that address by adding
174.121.98.168 barefeetdreams-.tumblr.com
to /etc/hosts
For interoperability purposes, I think it would be best to accept such
"technically invalid" domains.
-- System Information:
Debian Release: squeeze/sid
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'stable'), (400, 'testing'), (300,
'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libc-bin 2.11.2-10 Embedded GNU C Library: Binaries
ii libgcc1 1:4.4.5-8 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.24Debian configuration management sy
ii glibc-doc 2.11.2-6+squeeze1 Embedded GNU C Library: Documentat
ii locales2.11.2-6+squeeze1 Embedded GNU C Library: National L
-- debconf information:
* glibc/upgrade: true
* glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: gdm openbsd-inetd exim4 cups cron
--
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/20110512083401.ga16...@doggy.mamane.lu
Bug#626472: libc6: gethostbyname fails if label ends with dash
On Thu, May 12, 2011 at 10:34:01AM +0200, Lionel Elie Mamane wrote:
> Labels that end with a dash ("-") in in a domain name are not 100%
> RFC-conformant, but they are used in the wild, e.g. in
> http://barefeetdreams-.tumblr.com/
I found another one:
http://ryall-.tumblr.com/
--
Lionel
--
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/20110512134708.ga18...@doggy.mamane.lu
Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility
Package: libc6 Version: 2.11.1-1 Severity: important On amd64, one specific program behaves differently when run with libc6 2.10.2-9 (or earlier) than when run with libc6 2.11.1-1 (or later). So this smells like it could be either a libc6 backwards binary compatibility bug to me, or plainly a bug somewhere in eglibc. I suppose it is also possible that the program makes an invalid (not guaranteed) assumption and (e)glibc 2.11 changed something that breaks that assumption. The incorrect behaviour does not occur with the i386 version of the program, even with newer libc6. Neither on a full i386 Debian GNU/Linux, nor with the i386 version of the program installed on an amd64 Debian GNU/Linux with "--force-architecture" and ia32-libs. The program is Symantec's Backup Exec Remote Agent for Linux and UNIX Servers, versions 2010R2 (13.0.4164) and 2010R3 (13.0.5204); hereafter called "beremote". Alas, it is proprietary and all that, so precise debugging and testing is rather complicated. In particular, I don't know if a recompile and/or relink against newer headers / libraries would "fix" the program's behaviour or not. The incorrect behaviour is that in the backup, many directory names are mangled and/or duplicated. For example, /boot is split between /boot and /bott, and /boot/grub becomes /boot/guub. Filenames seem to be OK. I've run beremote under various variants of gdb, strace, ltrace and latrace, but I haven't been able to pinpoint a specific call to a libc function that returns a wrong result. All I see is that beremote does readdir(), and then the directory name (e.g. "boot") reappears mangled (e.g. "bott") in a call to wmemcpy. I would appreciate detailed instructions on how to better pinpoint it: as l(a)trace does not support *wchar_t strings, but gdb (sid version) does, I've been mainly using gdb breakpoints to look at what happens (after installing libc6-dbg), but that is rather onerous and it shows me only the libc functions I thought to put a breakpoint on, not all calls like l(a)trace would. I can send you the strace, ltrace and latrace outputs if it is useful. I've started from a lenny system: problem does not appear. Upgraded kernel to squeeze version, problem does not appear. Upgraded libc6 to squeeze, problem appears. I started taking versions from snapshot.debian.org until I found that problem appears with 2.11.1-1, but not 2.10.2-9. So it looks like a 2.10 vs 2.11 thing. I vaguely looked at the NEWS file and diff of source code between those versions, the only thing that struck my eye is: * New optimized string functions for x86-64: strstr, strcasestr, memcmp, strcspn, strpbrk, strspn, strcpy, stpcpy, strncpy, strcmp (SSE2, SSE4.2), strncmp (SSE2, SSE4.2), strchr (SSE4.2), strrchr (SSE4.2). Contributed by H.J. Lu. strlen, rawmemchr, strcmp (SSSE3), strncmp (SSSE3). Implemented by Ulrich Drepper. But I think that if these functions were buggy, we would have noticed! So, unlikely. -- System Information: Versions of packages libc6 depends on: ii libc-bin 2.11.1-1Embedded GNU C Library: Binaries ii libgcc1 1:4.3.2-1.1 GCC support library -- debconf information excluded -- 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/20111017080344.ga6...@capsaicin.mamane.lu
Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility
On Mon, Oct 17, 2011 at 10:43:57AM +0200, Aurelien Jarno wrote:
> On Mon, Oct 17, 2011 at 10:03:44AM +0200, Lionel Elie Mamane wrote:
>> Package: libc6
>> Version: 2.11.1-1
>> Severity: important
>> On amd64, one specific program behaves differently when run with
>> libc6 2.10.2-9 (or earlier) than when run with libc6 2.11.1-1 (or
>> later).
>> (..) it looks like a 2.10 vs 2.11 thing. I vaguely looked at the NEWS file
>> and diff of source code between those versions, the only thing that struck
>> my eye is:
>> * New optimized string functions for x86-64: strstr, strcasestr, memcmp,
>> strcspn, strpbrk, strspn, strcpy, stpcpy, strncpy, strcmp (SSE2, SSE4.2),
>> strncmp (SSE2, SSE4.2), strchr (SSE4.2), strrchr (SSE4.2).
>> Contributed by H.J. Lu.
>> strlen, rawmemchr, strcmp (SSSE3), strncmp (SSSE3).
>> Implemented by Ulrich Drepper.
>> But I think that if these functions were buggy, we would have noticed!
>> So, unlikely.
> This is likely to be these functions actually, and more precisely
> memcpy(). C standards specifies that the source and dest areas
> should not overlap, otherwise memmove() should be used
> instead. Recent version of the libc uses to optimize this function,
> but some binaries use memcpy() while they should use memmove().
> Given your code is closed source and thus can't be fixed, the best
> is to use the provided wrapper, see
> /usr/share/doc/libc6/NEWS.Debian.gz for more information about how
> to use them.
Interesting theory, but according the NEWS.Debian.gz of *sid* and the
BTS entries linked to, the issue you refer to seems to be new to
(e)glibc 2.13, not (e)glibc 2.11... And the problem was originally
observed in *squeeze*. And I've just checked for overlap by running
these on the latrace output:
grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) <= strtonum($5)
&& strtonum($8) + strtonum($11) >= strtonum($5)) print "overlap: " $5 " " $8 "
" $11 }'
grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) >= strtonum($5)
&& strtonum($5) + strtonum($11) >= strtonum($8)) print "overlap: " $5 " " $8 "
" $11 }'
Do you happen to have another theory, that would apply to a change
between 2.10 and 2.11?
--
Lionel
--
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/20111017092514.ga9...@capsaicin.mamane.lu
Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility
On Mon, Oct 17, 2011 at 08:44:25AM -0500, Jonathan Nieder wrote: > Jonathan Nieder wrote: >> Lionel Elie Mamane wrote: >>> And I've just checked for overlap by running >>> these on the latrace output: > [...] >> Could you try the analagous checks with strcpy and stpcpy? > Ah, I have another idea. Could you try the libc6 package from wheezy > or sid? > If my hunch is right, it will work fine, and you ran into something > like PR12159 (bug#635885). No, the problem appears on a mix of *lenny* and sid with libc6 2.13-21. -- Lionel -- 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/20111017144426.ga3...@capsaicin.mamane.lu
Bug#645592: libc6: 2.11 (maybe?) breaks backwards (binary) compatibility
On Mon, Oct 17, 2011 at 05:14:23AM -0500, Jonathan Nieder wrote:
> Lionel Elie Mamane wrote:
>> And I've just checked for overlap by running
>> these on the latrace output:
>> grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) <=
>> strtonum($5) && strtonum($8) + strtonum($11) >= strtonum($5)) print
>> "overlap: " $5 " " $8 " " $11 }'
>> grep ' memcpy(' | sed 's/[(,)]/ /g' | gawk '{if ( strtonum($8) >=
>> strtonum($5) && strtonum($5) + strtonum($11) >= strtonum($8)) print
>> "overlap: " $5 " " $8 " " $11 }'
> Could you try the analagous checks with strcpy and stpcpy?
I extended latrace to handle wchar_t*, too.
I found those with overlap:
6734 wcscpy(dest = 0x7f6c5d40a570, src = (0x7f6c5d40a574, 33)
"\\honey.domain.gestman.lu\[ROOT]"") [/lib/x86_64-linux-gnu/libc.so.6] {
6734 } wcscpy = (0x7f6c5d40a570, 33) "\\honey.domain.gestman.lu\[ROOT]""
6734 wcscpy(dest = 0x7f6c5d42b9e0, src = (0x7f6c5d42b9e4, 33)
"\\honey.domain.gestman.lu\[ROOT]"") [/lib/x86_64-linux-gnu/libc.so.6] {
6734 } wcscpy = (0x7f6c5d42b9e0, 33) "\\honey.domain.gestman.lu\[ROOT]""
However, in both cases the result looks like it is what the programmer
(erroneously) expects?
Neither stpcpy, nor wcpcpy appears in the latrace.
--
Lionel
--
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/20111017160840.gb3...@capsaicin.mamane.lu
Bug#239061: Segfault when setting up glibc-doc
On Tue, Jun 29, 2004 at 07:50:10PM +0900, GOTO Masanori wrote: > At Sat, 20 Mar 2004 17:37:33 +0100, > Josep Lladonosa i Capell wrote: >> Setting up glibc-doc (2.3.2.ds1-11) ... >> /var/lib/dpkg/info/glibc-doc.postinst: line 19: 7661 Segmentation fault >> in >> stall-info --quiet --section "GNU C library functions" "GNU C library >> functions" >> /usr/share/info/libc-dir-add.info >> The problem: dpkg version. Stable version was 1.9.21. I've >> upgraded 'manually' to latest dpkg (1.10.20), and glibc-doc could >> be set up... >> Perhaps a dependency has to be added... > Yes, "#220841: dpkg: install-info segmentation fault" is the actual > problem. > But I dislike adding Depends or Conflicts because: > (1) install-info is included in dpkg and various packages use this > file. But such packages does not depends on dpkg because dpkg > is essential required package. I don't like to add depends: > dpkg. The dependency is superfluous only if unversioned. > (2) Moreover, various package which use install-info does not handle > this problem. I don't like to increase depends or conflicts > entries for this kind of bug. If the other packages don't trigger the bug, they don't need to depend on a recent enough version of dpkg. And if they do trigger the bug, because they do it wrong is not a reason to do it wrong, too ;) > (3) This problem is occured when your dpkg is old (woody) and you > want to install sarge's glibc-doc. I wonder we need to support > such situation. I think we should. People mixing stable and testing/unstable, or more simply doing stage-wise upgrades is relatively common. We should give them the hint that dpkg should be upgraded first. > Upgrading from woody to sarge is concerned item, but I think dpkg > should also be upgraded at the same time. The versioned depends would guarantee that dpkg would be upgraded before glibc-doc. -- Lionel
Bug#221215: Bug#239061: Segfault when setting up glibc-doc
On Wed, Jun 30, 2004 at 04:03:25AM +0900, GOTO Masanori wrote: > I didn't write important information previously that I tried to > reappear this bug on my "chroot woody" environment, but it was > failed. > I tried to upgrade this chroot woody from woody to sarge with > "apt-get dist-upgrade" after installing woody's glibc-doc. This bug > was not appeared. > At Tue, 29 Jun 2004 15:18:23 +0200, > Lionel Elie Mamane wrote: >>> (2) Moreover, various package which use install-info does not handle >>> this problem. I don't like to increase depends or conflicts >>> entries for this kind of bug. >> If the other packages don't trigger the bug, they don't need to depend >> on a recent enough version of dpkg. And if they do trigger the bug, >> because they do it wrong is not a reason to do it wrong, too ;) > Did you confirm this bug was affected to other packages? No, I didn't, >>> (3) This problem is occured when your dpkg is old (woody) and you >>> want to install sarge's glibc-doc. I wonder we need to support >>> such situation. >> I think we should. People mixing stable and testing/unstable, or more >> simply doing stage-wise upgrades is relatively common. We should give >> them the hint that dpkg should be upgraded first. > Did you confirm this bug? I encountered it with glibc-doc, upgraded dpkg to fix it and continued my upgrade. So, I didn't see if it hits other packages. > At least the current upgrade does not induce this problem, I think > we don't need depends or conflicts. If the woody -> sarge transition is OK, then the need for it is greatly reduced. -- Lionel
Bug#319303: include it in kernelcapi.h ?
Hi, I've noted that kernelcapi.h also uses __user and is #include'd by capi.h . So maybe the "best" fix is to #include compiler.h in kernelcapi.h, not in capi.h. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455762: gethostbyname fails on IPv6 addresses, even with "options inet6"
Adam Majer wrote: > According to documentation, IPv6 and IPv4 addresses specified should > be returned without the need to resolve them. No explicit IPv6 > address seems to work. I reproduced this bug even with "options inet6" in /etc/resolv.conf With the "options inet6", symbolic names that resolve to an entry work, though. As do IPv6 entries in /etc/hosts (such as "ip6-localhost"). On the other hand, the system seems to have some intelligence, because (without "options inet6"), ip6-localhost returns 127.0.0.1, and that ain't from DNS. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426118: glibc: documentation-by-comment of strtok() wrong on final state of first argument
Package: glibc
Version: 2.5-4
Extract from file string/strtok.c:
/* Parse S into tokens separated by characters in DELIM.
If S is NULL, the last string strtok() was called with is
used. For example:
char s[] = "-abc-=-def";
x = strtok(s, "-"); // x = "abc"
x = strtok(NULL, "-="); // x = "def"
x = strtok(NULL, "="); // x = NULL
// s = "abc\0-def\0"
*/
This, according to my understanding, says that after this code gets
executed, the contents of s is "abc\0-def\0" followed by one
unspecified character (to account for the original length of s, which
is reduced by one in the value given at the end).
This is wrong. The contents of s after execution of this code is
"-abc\0=-def\0" as running the attached program will demonstrate.
Note that the behaviour described in the comment would imply that
strtok is Θ(strlen(s)^2) (quadratic time, and no less, in the
worst case), because it would in some cases shift the whole string by
one (or more?) positions to the left, which is a linear operation.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.18-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
#include
#include
char s[] = "-abc-=-def";
const size_t ls = sizeof s;
void prints(void) {
size_t i;
for(i=0; i < ls; ++i) {
if ( s[i] < 32 )
printf("\\0%.0o", s[i]);
else
printf("%c", s[i]);
}
printf("\n");
}
int main(int argc, char* argv[]) {
char *x;
x = strtok(s, "-");
x = strtok(NULL, "-=");
x = strtok(NULL, "=");
prints();
return 0;
}
Bug#834706: libc6-dev: needs versioned dependency on linux-libc-dev for SYS_getrandom
Package: libc6-dev Version: 2.23-4 Severity: serious Justification: Policy 3.5 /usr/include/x86_64-linux-gnu/bits/syscall.h contains #define SYS_getrandom __NR_getrandom but that is not defined in stable's linux-libc-dev (version 3.16.7-ckt25-2 and security update 3.16.7-ckt25-2+deb8u3). For this #define to work, libc6-dev needs a versioned depends on a newer version of linux-libc-dev. The version now in sid and testing (4.6.4-1) works but probably the requirement is more lax than that. -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libc6-dev depends on: ii libc-dev-bin2.23-4 ii libc6 2.23-4 ii linux-libc-dev 4.6.4-1 libc6-dev recommends no packages. Versions of packages libc6-dev suggests: ii glibc-doc 2.19-18+deb8u4 ii manpages-dev 3.74-1 -- no debconf information
Bug#834706: libc6-dev: needs versioned dependency on linux-libc-dev for SYS_getrandom
On Thu, Aug 18, 2016 at 09:53:20AM +0200, Lionel Elie Mamane wrote: > libc6-dev needs a versioned depends on a newer version of > linux-libc-dev. The version now in sid and testing (4.6.4-1) works > but probably the requirement is more lax than that. Rumours suggest that 3.6.17 would be enough, since that's when the getrandom() syscall was introduced. -- Lionel
Bug#834706: libc6-dev: needs versioned dependency on linux-libc-dev for SYS_getrandom
On Thu, Aug 18, 2016 at 03:52:48PM +0200, Aurelien Jarno wrote:
> On 2016-08-18 09:53, Lionel Elie Mamane wrote:
>> /usr/include/x86_64-linux-gnu/bits/syscall.h
>> contains
>> #define SYS_getrandom __NR_getrandom
>> but that is not defined in stable's linux-libc-dev (version
>> 3.16.7-ckt25-2 and security update 3.16.7-ckt25-2+deb8u3).
>> For this #define to work, libc6-dev needs a versioned depends on a
>> newer version of linux-libc-dev. The version now in sid and testing
>> (4.6.4-1) works but probably the requirement is more lax than that.
> I am not sure about that. This kind of new features are usually
> detected by the configure scripts of the software, given anyway that
> the presence of the syscall definition doesn't imply that the
> running kernel has support for it.
I encountered this issue when compiling mutt. It contains this code:
#if defined(SYS_getrandom) && defined(__linux__)
long ret;
do {
ret = syscall(SYS_getrandom, out, len, 0, 0, 0, 0);
} while ((ret == -1) && (errno == EINTR));
if (ret == len) return;
// more stuff, removed here because not useful to the point
#endif
That code fails to compile with a new libc6-dev and old
linux-libc-dev, with an error message along the lines of
symbol __NR_getrandom not defined
If you mean to say this mutt code is buggy, then fine, I defer to your
expertise. You can reassign this bug to mutt with an explanation of
what it _should_ do.
> Also I am not sure Policy 3.5 applies there, most of the packages
> work correctly there, so the dependency is not "required" for
> packages to "work correctly".
I understand "work correctly" as "works completely correctly", not
"most of the package works correctly", and always have. I won't fight
you if you disagree and downgrade the severity.
--
Lionel
Bug#351049: libc6: America/Havana DST info wrong for 2005/2006
Package: libc6 Version: 2.3.5-12.1 Severity: normal Cuba did not switch back to non-DST time on October 2005, but the timezone info in libc thinks it did: RuleCuba2005max - Oct lastSun 0:00s 0 S That line should probably be changed to RuleCuba2006max - Oct lastSun 0:00s 0 S Source: http://www.timeanddate.com/worldclock/timezone.html?n=99 (and a friend that spent vacation in Cuba) Note that the timezone/northamerica says: # From Evert van der Veer via Steffen Thorsen (2004-10-28): # Cuba is not going back to standard time this year. # From Paul Eggert (2004-10-28): # http://www.granma.cu/ingles/2004/septiembre/juev30/41medid-i.html # says that it's due to a problem at the Antonio Guiteras # thermoelectric plant, and says "This October there will be no return # to normal hours (after daylight saving time)". # For now, let's assume that it's a one-year temporary measure. ^ So it became a two-year temporary measure? We are not sure if it won't become a 3+ year temporary measure. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-deb1-64bit Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351049: libc6: America/Havana DST info wrong for 2005/2006
tags 351049 +fixed-upstream thanks On Thu, Feb 02, 2006 at 03:06:44PM +0100, Lionel Elie Mamane wrote: > Cuba did not switch back to non-DST time on October 2005, but the > timezone info in libc thinks it did: > RuleCuba2005max - Oct lastSun 0:00s 0 S > That line should probably be changed to > RuleCuba2006max - Oct lastSun 0:00s 0 S This has actually already happened upstream, in CVS commit by "roland" on 10 Jan 2006, revision 1.29 of libc/timezone/northamerica. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
timezone data packaged separately and in volatile?
Hi,
I just realised that the timezone data in glibc is taken from an
upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data
sometimes changes, more rapidly than our release cycle (and than any
release cycle we can reasonable have).
Examples include the Cuba "no stop to daylight saving" nearly
last-minute change in November 2005 (affecting changes effective
1 October 2005) or the upcoming Indiana changes (to be effective in
April 2006) that got into the database on 30 January 2006.
Currently, for these changes to propagate to Debian, these delays
occur:
- upstream glibc synchronises with their upstream (this took about
month and a half for the Cuba example).
- glibc release (or Debian packages CVS snapshot or Debian glibc
patched for newer upstream upstream release)
- Debian packages glibc release, with all portability issues and
all.
- Debian release
What I propose, due to the somewhat tight schedule sometimes in play:
- Package the timezone data as a separate (source+binary) package
tzdata, directly from glibc's upstream.
- Put that package in volatile.debian.net .
This would allow updating the timezone data, that is subject to
short-delay political changes, independently from the sensitive
libc6{,.1} package. And thus have it in volatile :)
The tzdata package could be the only source of timezone data (and
libc6{,.1} would depend on it, it would be required, essential) or
libc6{,.1} could still ship its copy, which would be diverted by
tzdata and replaced by its newer copy. In the second scenario, I'd
imagine tzdata to be of priority important or standard and installed
by default on new installs (maybe suggested / recommended by
libc6?). Probably making it simple and taking the first solution would
be best.
libc6 currently "Replaces: timezone, timezones", which suggests that
we were doing something like that before but we moved away from this
solution. Why?
The Debian glibc maintainers seem to sometimes go to a newer-than
upstream tzdata release in the Debian patch.
Is there any issue I'm missing? Thoughts?
--
Lionel Elie Mamane
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, Feb 09, 2006 at 07:42:25PM +0900, GOTO Masanori wrote: > At Tue, 7 Feb 2006 14:30:01 +1100, > Anand Kumria wrote: >> On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: >>> I just realised that the timezone data in glibc is taken from an >>> upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data >>> sometimes changes, more rapidly than our release cycle (and than >>> any release cycle we can reasonable have). >> But that doesn't mean that we can issue an update to a stable package. >> Currently they are mainly done for security purposes -- but stable >> updates should not be confined to only that. They should be done >> to keep the system functional. > Note that I was planning to separate timezone package from glibc > package (but I forgot it). It'll be available by the next release, > etch. Excellent! Thank you. Do you mean in a separate source package or in a binary package generated by glibc? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: timezone data packaged separately and in volatile?
On Thu, Feb 09, 2006 at 07:42:25PM +0900, GOTO Masanori wrote: > At Tue, 7 Feb 2006 14:30:01 +1100, > Anand Kumria wrote: >> On Thu, Feb 02, 2006 at 11:42:31PM +0100, Lionel Elie Mamane wrote: >>> I just realised that the timezone data in glibc is taken from an >>> upstream database (namely ftp://elsie.nci.nih.gov/pub/). This data >>> sometimes changes, more rapidly than our release cycle (and than >>> any release cycle we can reasonable have). >> But that doesn't mean that we can issue an update to a stable package. >> Currently they are mainly done for security purposes -- but stable >> updates should not be confined to only that. They should be done >> to keep the system functional. > Note that I was planning to separate timezone package from glibc > package (but I forgot it). It'll be available by the next release, > etch. To get things rolling, I have prepared an updated glibc for sarge with just the timezone data updated to the latest upstream upstream. It is at http://people.debian.org/~lmamane/glibc/ . Technically right now it is correct neither as a NMU (wrong version number, not mentioned in changelog), nor as MU (because I'm not a glibc maintainer). http://people.debian.org/~lmamane/glibc/glibc_22-sarge0.diff is the interdiff (the difference between what's now in sarge and what I've prepared). So: - glibc maintainers, would you approve of such an update to a point release of sarge? If yes, shall I make an NMU of it or shall you prepare a package (replace my "-- " line in the changelog by one of yours) and submit it to joey? - Martin, would you take such an update if approved or submitted by the glibc maintainers? Best Regards, -- Lionel signature.asc Description: Digital signature
Re: For those who care about stable updates (update)
On Thu, Mar 09, 2006 at 06:26:40PM +0100, Martin Zobel-Helas wrote: > we are aiming to release the second update to Debian 3.1 sarge > (3.1r2) as soon as possible. Current plan is to do it within the > next 4 weeks. Shall we try to get the timezone data update in there? Do you want me to prepare it as a NMU, to prepare a MU you only have to sign, you want to do it yourselves? http://people.debian.org/~lmamane/glibc/ contains my prepared packages. I'll "just" have to adapt the changelog to become an NMU or you change the "-- " line of the changelog with one of your names. (In all cases, you review the changes first.) -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221215: glibc-doc: Missing versioned depend (or conflict) on dpkg
Package: glibc-doc Version: 2.3.2.ds1-10 Severity: important The post-install of this version of glibc-doc depends on some bugfix present only in a later version of dpkg, but doesn't say so in its depends / conflicts fields. With dpkg 1.9.21, here is the error message one gets: Setting up glibc-doc (2.3.2.ds1-10) ... /var/lib/dpkg/info/glibc-doc.postinst: line 19: 23305 Segmentation fault install-info --quiet --section "GNU C library functions" "GNU C library functions" /usr/share/info/libc-dir-add.info dpkg: error processing glibc-doc (--configure): subprocess post-installation script returned error exit status 139 Once dpkg 1.10.18 is installed, post-install of glibc-doc goes well. I didn't test intermediary versions of dpkg. Please depend on a new-enough version of dpkg or conflict with too-old dpkg. -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux tofu 2.4.20-usagi+devmap #1 mer avr 9 16:18:03 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- no debconf information
Bug#239061: Segfault when setting up glibc-doc
On Tue, Jun 29, 2004 at 07:50:10PM +0900, GOTO Masanori wrote: > At Sat, 20 Mar 2004 17:37:33 +0100, > Josep Lladonosa i Capell wrote: >> Setting up glibc-doc (2.3.2.ds1-11) ... >> /var/lib/dpkg/info/glibc-doc.postinst: line 19: 7661 Segmentation fault >> in >> stall-info --quiet --section "GNU C library functions" "GNU C library >> functions" >> /usr/share/info/libc-dir-add.info >> The problem: dpkg version. Stable version was 1.9.21. I've >> upgraded 'manually' to latest dpkg (1.10.20), and glibc-doc could >> be set up... >> Perhaps a dependency has to be added... > Yes, "#220841: dpkg: install-info segmentation fault" is the actual > problem. > But I dislike adding Depends or Conflicts because: > (1) install-info is included in dpkg and various packages use this > file. But such packages does not depends on dpkg because dpkg > is essential required package. I don't like to add depends: > dpkg. The dependency is superfluous only if unversioned. > (2) Moreover, various package which use install-info does not handle > this problem. I don't like to increase depends or conflicts > entries for this kind of bug. If the other packages don't trigger the bug, they don't need to depend on a recent enough version of dpkg. And if they do trigger the bug, because they do it wrong is not a reason to do it wrong, too ;) > (3) This problem is occured when your dpkg is old (woody) and you > want to install sarge's glibc-doc. I wonder we need to support > such situation. I think we should. People mixing stable and testing/unstable, or more simply doing stage-wise upgrades is relatively common. We should give them the hint that dpkg should be upgraded first. > Upgrading from woody to sarge is concerned item, but I think dpkg > should also be upgraded at the same time. The versioned depends would guarantee that dpkg would be upgraded before glibc-doc. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221215: Bug#239061: Segfault when setting up glibc-doc
On Wed, Jun 30, 2004 at 04:03:25AM +0900, GOTO Masanori wrote: > I didn't write important information previously that I tried to > reappear this bug on my "chroot woody" environment, but it was > failed. > I tried to upgrade this chroot woody from woody to sarge with > "apt-get dist-upgrade" after installing woody's glibc-doc. This bug > was not appeared. > At Tue, 29 Jun 2004 15:18:23 +0200, > Lionel Elie Mamane wrote: >>> (2) Moreover, various package which use install-info does not handle >>> this problem. I don't like to increase depends or conflicts >>> entries for this kind of bug. >> If the other packages don't trigger the bug, they don't need to depend >> on a recent enough version of dpkg. And if they do trigger the bug, >> because they do it wrong is not a reason to do it wrong, too ;) > Did you confirm this bug was affected to other packages? No, I didn't, >>> (3) This problem is occured when your dpkg is old (woody) and you >>> want to install sarge's glibc-doc. I wonder we need to support >>> such situation. >> I think we should. People mixing stable and testing/unstable, or more >> simply doing stage-wise upgrades is relatively common. We should give >> them the hint that dpkg should be upgraded first. > Did you confirm this bug? I encountered it with glibc-doc, upgraded dpkg to fix it and continued my upgrade. So, I didn't see if it hits other packages. > At least the current upgrade does not induce this problem, I think > we don't need depends or conflicts. If the woody -> sarge transition is OK, then the need for it is greatly reduced. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#221215: glibc-doc: Missing versioned depend (or conflict) on dpkg
Package: glibc-doc Version: 2.3.2.ds1-10 Severity: important The post-install of this version of glibc-doc depends on some bugfix present only in a later version of dpkg, but doesn't say so in its depends / conflicts fields. With dpkg 1.9.21, here is the error message one gets: Setting up glibc-doc (2.3.2.ds1-10) ... /var/lib/dpkg/info/glibc-doc.postinst: line 19: 23305 Segmentation fault install-info --quiet --section "GNU C library functions" "GNU C library functions" /usr/share/info/libc-dir-add.info dpkg: error processing glibc-doc (--configure): subprocess post-installation script returned error exit status 139 Once dpkg 1.10.18 is installed, post-install of glibc-doc goes well. I didn't test intermediary versions of dpkg. Please depend on a new-enough version of dpkg or conflict with too-old dpkg. -- System Information: Debian Release: 3.0 Architecture: i386 Kernel: Linux tofu 2.4.20-usagi+devmap #1 mer avr 9 16:18:03 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
