Processed: bug 1057856 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=31144
Processing commands for cont...@bugs.debian.org: > forwarded 1057856 https://sourceware.org/bugzilla/show_bug.cgi?id=31144 Bug #1057856 [libc6] glibc: mktime now returns clock for UTC with isdst=1 Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=31144'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1057856: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057856 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1057856: glibc: mktime now returns clock for UTC with isdst=1
Hello, Thank you for the quick answer and the details provided. You can submit the test program to the upstream bugzilla, no problem. Best regards, Paulo Tomé On Mon, Dec 11, 2023 at 9:36 PM Aurelien Jarno wrote: > Hi, > > On 2023-12-09 18:23, Paulo Tomé wrote: > > Package: libc6 > > Version: 2.36-9+deb12u3 > > Severity: normal > > Tags: upstream > > X-Debbugs-Cc: paulo.t...@gmail.com > > > > Dear Maintainer, > > > > *** Reporter, please consider answering these questions, where > appropriate *** > > > >* What led up to the situation? > >* What exactly did you do (or not do) that was effective (or > > ineffective)? > >* What was the outcome of this action? > >* What outcome did you expect instead? > > > > *** End of the template - remove these template lines *** > > > > After compiling Erlang from source (erlang.org) a test case failed. The > > test case detects if local time is converted correctly to universal time > > even if isdst=1 for the UTC timezone. The following issue reports the > > details: https://github.com/erlang/otp/issues/7938 > > > > I created a small test program that reproduces the behavior. The program > > calls mktime for a certain date, with isdst=1 in the tm struct. > > Thanks for the details and for the reproducer, that's very helpful. > > > When setting TZ=UTC in the environment, mktime returns a valid clock > > offset by one hour. In previous versions of glibc (tested 2.35 on Ubuntu > > LTS 22.04.3) the same call to mktime returns -1. The error (-1) makes > > sense, since the UTC timezone does not have DST. > > > > After downloading the Debian glibc-source for 2.36, I see a patch that > > could explain this behavior. > > > > /usr/src/glibc/debian/patches/git-updates.diff > > > > + /* No unusual DST offset was found nearby. Assume one-hour DST. > */ > > + t += 60 * 60 * dst_difference; > > + if (mktime_min <= t && t <= mktime_max && convert_time (convert, > t, )) > > + goto offset_found; > > + > >__set_errno (EOVERFLOW); > >return -1; > > } > > > > This change was not present on the other glibc I tested (2.35 on > > Ubuntu). I checked upstream glibc 2.38 and the change is in the source. > > Yes, I confirm this changes explains the behaviour you are observing. It > comes from the following upstream commit, which has been introduced in > the 2.37 release and backported in the 2.34, 2.35 and 2.36 upstream > stable trees: > > > https://sourceware.org/git/?p=glibc.git;a=commit;h=83859e1115269cf56d21669361d4ddbe2687831c > > > I'm not sure if this is a bug, but for the UTC timezone I would expect > > an error if we asked for the time with DST. > > This not clear to me if it is a bug or not. Quoting the standard (ISO C > or POSIX): > > A positive or 0 value for tm_isdst shall cause mktime() to presume > initially that Daylight Savings Time, respectively, is or is not in > effect for the specified time. A negative value for tm_isdst shall > cause mktime() to attempt to determine whether Daylight Savings Time > is in effect for the specified time. > > The word "presume initially" looks like an initial guess should be > provided (for disambiguating two identical dates), but it doesn't > enforce the result. > > That said, looking at the FreeBSD libc implementation, it seems the > original glibc behaviour is the correct one. The best is probably to > report the issue upstream. > > > For reference, this is the test program: > > Thanks. Do you mind if I submit your test program to the upstream > bugzilla? Or do you prefer to submit the bug yourself? > > Regards > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://aurel32.net >
Bug#1057856: glibc: mktime now returns clock for UTC with isdst=1
Hi, On 2023-12-09 18:23, Paulo Tomé wrote: > Package: libc6 > Version: 2.36-9+deb12u3 > Severity: normal > Tags: upstream > X-Debbugs-Cc: paulo.t...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > After compiling Erlang from source (erlang.org) a test case failed. The > test case detects if local time is converted correctly to universal time > even if isdst=1 for the UTC timezone. The following issue reports the > details: https://github.com/erlang/otp/issues/7938 > > I created a small test program that reproduces the behavior. The program > calls mktime for a certain date, with isdst=1 in the tm struct. Thanks for the details and for the reproducer, that's very helpful. > When setting TZ=UTC in the environment, mktime returns a valid clock > offset by one hour. In previous versions of glibc (tested 2.35 on Ubuntu > LTS 22.04.3) the same call to mktime returns -1. The error (-1) makes > sense, since the UTC timezone does not have DST. > > After downloading the Debian glibc-source for 2.36, I see a patch that > could explain this behavior. > > /usr/src/glibc/debian/patches/git-updates.diff > > + /* No unusual DST offset was found nearby. Assume one-hour DST. */ > + t += 60 * 60 * dst_difference; > + if (mktime_min <= t && t <= mktime_max && convert_time (convert, t, > )) > + goto offset_found; > + >__set_errno (EOVERFLOW); >return -1; > } > > This change was not present on the other glibc I tested (2.35 on > Ubuntu). I checked upstream glibc 2.38 and the change is in the source. Yes, I confirm this changes explains the behaviour you are observing. It comes from the following upstream commit, which has been introduced in the 2.37 release and backported in the 2.34, 2.35 and 2.36 upstream stable trees: https://sourceware.org/git/?p=glibc.git;a=commit;h=83859e1115269cf56d21669361d4ddbe2687831c > I'm not sure if this is a bug, but for the UTC timezone I would expect > an error if we asked for the time with DST. This not clear to me if it is a bug or not. Quoting the standard (ISO C or POSIX): A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. The word "presume initially" looks like an initial guess should be provided (for disambiguating two identical dates), but it doesn't enforce the result. That said, looking at the FreeBSD libc implementation, it seems the original glibc behaviour is the correct one. The best is probably to report the issue upstream. > For reference, this is the test program: Thanks. Do you mind if I submit your test program to the upstream bugzilla? Or do you prefer to submit the bug yourself? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1057783: libc6:amd64.postinst may lack of response for a long time.
Hi, On 2023-12-08 21:04, ChenPi11 wrote: > Package: libc6 > Version: 2.37-13 > Severity: normal > Tags: d-i > X-Debbugs-Cc: wushengwuxi-msctino...@outlook.com > > Dear Maintainer, > > When apt was configuring the libc6:amd64 after I upgraded all packages, It > lack of response for a long time (more than 3 hours). > Then, I founded that `ischroot` program was blocking the post-install > script. I think the bug is ischroot's at first. But it ONLY unresponsive here. > I know the apt is not in chroot, so I removed the command and set > `TELINIT` to `no`. After I did this, the configure process became > normaly. Thanks for the report. It happens that the call to ischroot is essential to not break the system when executing in a chroot. Therefore we have to understand why ischroot is hanging. As the problem is not reproducible here, could you please use strace with the -p option on the hanging ischroot process to get a better idea why it hangs? Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
