Bug#940852: tzdata should install tzdata.zi file

Package: tzdata Version: 2019c-1 The upstream tzdata by default installs a file /usr/share/zoneinfo/tzdata.zi that contains version info along with the exact source used to generate the TZif binary files. This file was introduced in tzdb 2017c but apparently Debian hasn't picked it up yet. It

Bug#867283: Crash in glibc's mktime in low-memory situations

I proposed a patch here: https://sourceware.org/bugzilla/show_bug.cgi?id=21716#c1 Please give it a try.

Bug#783122: tzdata: Wrong data for Europe/Minsk

This problem should go away (or at least be different) once Ubuntu updates to tz 2016g, which no longer uses "MSK" to abbreviate Minsk Time. 2016g uses "+03" instead, as part of the push to use numeric time zone abbreviations instead of inventing alphabetic ones.

Bug#186568: bug#22793: grep -E assertion failure with back references

arn...@skeeve.com wrote: Paul Eggert wrote: With recent 'grep' you can work around the problem by configuring --with-included-regex. Not so. I did a fresh ./boostrap ./configure --with-included-regex make and it still core dumps: $ echo abc | ./s

Bug#602162: /usr/share/zoneinfo/Australia/Sydney: DST indistinguishable

This bug is fixed in the recently-released 2014f release of the tz database, and when that release propagates into Debian you should be able to close this bug report. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@

Bug#373930: getcwd assertion failure on ia64

Package: libc6 Version: 2.3.2.ds1-22sarge3 Severity: important Tags: patch fixed-upstream Bob Proulx reports in that CVS coreutils won't build on an ia64 machine due to an assertion failure in the pwd-long test. This stems fr

Bug#351049: FW: Bug#351049: libc6: America/Havana DST info wrong for 2005/2006

> From: Lionel Elie Mamane [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 02, 2006 9:18 AM > > Cuba did not switch back to non-DST time on October 2005, but the > timezone info in libc thinks it did: Thanks for reporting this. This bug was fixed in the tzdata2005o release (2005-11-28) and w

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

> From: GOTO Masanori <[EMAIL PROTECTED]> > Date: Fri, 08 Oct 2004 11:34:27 +0900 > Could I close this bug? Yes, please do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#196177: libc6: mktime mishandles dates before 1970 (regression from 3.0r1)

This bug was fixed upstream as follows: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/time/mktime.c.diff?r1=1.60&r2=1.61&cvsroot=glibc Rather than futz with that patch by itself, though, I suggest simply upgrading to the latest trunk version (1.66) of mktime.c in glibc. You can get it here: http

Bug#303920: FW: Bug#303920: libc6: Nicaragua introduces DST at 12:00pm 09/04/ 2005

[EMAIL PROTECTED] writes: > How can I stay in sync with this issue? For the tz database, you can visit . You can also subscribe to the tz mailing list as described in (look for "subscribe"). For Debian, you can visit

Bug#303920: FW: Bug#303920: libc6: Nicaragua introduces DST at 12:00pm 09/04/ 2005

a.gob.ni/buscador_gaceta/BD/DECRETOS/2005/Decreto%2023-2005%20Se%20adelanta%20en%20una%20hora%20en%20todo%20el%20territorio%20nacional%20apartir%20de%20las%2024horas%20del%2009%20de%20Abril.pdf +# +# From Paul Eggert (2005-04-12): +# The decree doesn't say anything about daylight saving, bu

Bug#286717: glr bison default actions broken

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > Did you mean to send this to a different bug report? Oops, yes, sorry, it should have been Debian bug 195946. Sorry about the cut and paste error. I'll resubmit it with the right bug number. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a

Bug#286717: glr bison default actions broken

I cannot reproduce the bug in Bison 2.0 (the current stable release). It has many improvements to glr.c in this area, and for now I'm going to assume that they have fixed the bug. You can get it here: ftp://ftp.gnu.org/gnu/bison/bison-2.0.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] wi

Bug#286717: glibc: locale initialisation failure if cannot mmap locale.alias

GOTO Masanori <[EMAIL PROTECTED]> writes: > Thus, this is not bug of either glibc or coreutils. Paul, how do you > think about this? Your analysis sounds good to me. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#177940: mktime.c fix

GOTO Masanori <[EMAIL PROTECTED]> writes: > Is this patch still needed? OK, I have now submitted a series of bug fixes to glibc which will (if accepted) sync glibc mktime.c to gnulib mktime.c. Here are URLs: http://sources.redhat.com/bugzilla/show_bug.cgi?id=468 http://sources.redhat.com/bugzil

Bug#177940: mktime.c fix

GOTO Masanori <[EMAIL PROTECTED]> writes: > Is this patch still needed? I'm not sure what you mean by "still needed", but I'll see what I can do about porting the gnulib mktime.c fixes into glibc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [

Bug#262782: [Bug-tar] free(valloc()): invalid pointer

<http://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html#Aligned%20Memory%20Blocks> That being said, tar should work around the Debian bug, as similar problems apparently occur on a few other platforms. I installed the following patch into the tar CVS main branc

Bug#230050: getcontext doesn't report alternate stack correctly

Package: libc6 Version: 2.2.5-11.5 This is a followup to Debian bug 136249. Herbert Xu suggested that I refile the getcontext part of that bug against libc6. The problem is that getcontext does not fill in the correct information when it is executed on the alternate stack. A sample program illu

Bug#230050: getcontext doesn't report alternate stack correctly

Package: libc6 Version: 2.2.5-11.5 This is a followup to Debian bug 136249. Herbert Xu suggested that I refile the getcontext part of that bug against libc6. The problem is that getcontext does not fill in the correct information when it is executed on the alternate stack. A sample program illu

Bug#177940: mktime.c fix

Jeff Bailey <[EMAIL PROTECTED]> writes: > It's been a while since I've looked at this, but it appears that the > files should be identical, right? (All the #ifdef _LIBC constructs are > still in place). If yes, I can put together a series of patches to get > it back in sync. Thanks for voluntee

Bug#177940: mktime.c fix

Jeff Bailey <[EMAIL PROTECTED]> writes: > It's been a while since I've looked at this, but it appears that the > files should be identical, right? (All the #ifdef _LIBC constructs are > still in place). If yes, I can put together a series of patches to get > it back in sync. Thanks for voluntee

Bug#177940: mktime.c fix

Jeff Bailey <[EMAIL PROTECTED]> writes: > Thanks for the fix for mktime.c[0] - Is this a file that will eventually > be synchronized into glibc as part of the usual gnulib administrivia? That's the intent, but it's been several months now and I haven't gotten around to it. Is that something that

Bug#177940: mktime.c fix

Jeff Bailey <[EMAIL PROTECTED]> writes: > Thanks for the fix for mktime.c[0] - Is this a file that will eventually > be synchronized into glibc as part of the usual gnulib administrivia? That's the intent, but it's been several months now and I haven't gotten around to it. Is that something that

Bug#89098: Timezone POSIX compliance bug.

Roland McGrath <[EMAIL PROTECTED]> writes: > Off hand I cannot see why we clip the given values at all. I'd guess that a reasonable amount of glibc code will break if the UTC offset is enormous (e.g., on the order of 2**31 seconds). Also, I wouldn't be surprised if some of the time-zone-adjustin

Bug#89098: Timezone POSIX compliance bug.

Roland McGrath <[EMAIL PROTECTED]> writes: > Off hand I cannot see why we clip the given values at all. I'd guess that a reasonable amount of glibc code will break if the UTC offset is enormous (e.g., on the order of 2**31 seconds). Also, I wouldn't be surprised if some of the time-zone-adjustin

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

[EMAIL PROTECTED] (Denis Barbier) writes: > Some users run in POSIX mode (see #185924), but Debian glibc comes > with a locale-gen script which is a frontend to localedef. > In this script, POSIXLY_CORRECT is unset (see #206784), so our > users should not be affected by the requested change. Some

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

[EMAIL PROTECTED] (Denis Barbier) writes: > Some users run in POSIX mode (see #185924), but Debian glibc comes > with a locale-gen script which is a frontend to localedef. > In this script, POSIXLY_CORRECT is unset (see #206784), so our > users should not be affected by the requested change. Some

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

[EMAIL PROTECTED] (Denis Barbier) writes: > I am not sure what you mean by "user-defined locales", since your > patch does not check UID. I meant locales that are generated by a user. In this particular case, it's a POSIX-conformance-test shell script that generates the locales. > As autobuilde

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

[EMAIL PROTECTED] (Denis Barbier) writes: > I am not sure what you mean by "user-defined locales", since your > patch does not check UID. I meant locales that are generated by a user. In this particular case, it's a POSIX-conformance-test shell script that generates the locales. > As autobuilde

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

t entirely satisfactory of course, but it should get the job done for now. 2003-10-03 Paul Eggert <[EMAIL PROTECTED]> * locale/programs/localedef.c (main): Reject attempts to create multibyte locales when operating in strict POSIX mode. --- glibc-2.3.2-8/glibc-2.3.2/locale

Bug#214028: localedef, LSB 1.3 conformance, and Debian standard utilities

t entirely satisfactory of course, but it should get the job done for now. 2003-10-03 Paul Eggert <[EMAIL PROTECTED]> * locale/programs/localedef.c (main): Reject attempts to create multibyte locales when operating in strict POSIX mode. --- glibc-2.3.2-8/glibc-2.3.2/locale

Bug#202243: glibc utimes glitch with coreutils 'touch'

GOTO Masanori <[EMAIL PROTECTED]> writes: > "Historically, utimes truncated when it couldn't store the > microseconds" is BSD's original implementation? Yes. I don't know where that phrase in the standard about "rounding" came from. Quite possibly it's just a glitch in the standard, and "trunca

Bug#202243: glibc utimes glitch with coreutils 'touch'

GOTO Masanori <[EMAIL PROTECTED]> writes: > So I patched Jakub's modification for 2.3.2-3, ok? If you installed the patch in then you should be OK, but if it's some other patch then I'd like to know what it was. -- To UNSUBSCRIBE,

Re: libc6 posix version/breakage

Michael Stone <[EMAIL PROTECTED]> writes: > I don't know that there's a full list of *packages* that might be > affected. diffutils is also affected. In POSIX 1003.1-2001, command invocations like "diff -c2" and "diff -c -2" are no longer allowed; you are supposed to use "diff -C 2" instead. Si

Bug#202243: glibc utimes glitch with coreutils 'touch'

d, as that would avoid all this mess entirely.) I'll submit an alternate patch to coreutils so that it works around this glibc glitch. The simplest workaround is to not invoke utimes when building with glibc; perhaps I can improve on that, but I don't know. I propose the following patch to f

Bug#177940: AC_FUNC_MKTIME fail when timezone is set to GMT-2

I looked into this bug (Debian bug 177940) and wrote the following patch to mktime.c. Please give it a try. You should be able to apply this patch to libc6's mktime.c. http://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/lib/mktime.c.diff?r1=1.36&r2=1.37 -- To UNSUBSCRIBE, email to [EMAIL PR

Bug#196177: libc6: mktime mishandles dates before 1970 (regression from 3.0r1)

Package: libc6 Version: 2.3.1-16 Severity: normal Tags: patch I ran into this problem because I assigned a Python programming time zone problem to my students . Students who were running Debian testing could not do the assignment because

Bug#177940: AC_FUNC_MKTIME fail when timezone is set to GMT-2

I looked into this bug (Debian bug 177940) and wrote the following patch to mktime.c. Please give it a try. You should be able to apply this patch to libc6's mktime.c. http://savannah.gnu.org/cgi-bin/viewcvs/gnulib/gnulib/lib/mktime.c.diff?r1=1.36&r2=1.37

Bug#196177: libc6: mktime mishandles dates before 1970 (regression from 3.0r1)

Package: libc6 Version: 2.3.1-16 Severity: normal Tags: patch I ran into this problem because I assigned a Python programming time zone problem to my students . Students who were running Debian testing could not do the assignment because