Bug#1036104: tzdata.zi has a typo in the backported Egypt DST rules
Ping - this is still present in 2021a-1+deb11u10 (bullseye). Also, would it be possible for the "version 2021a" string in /usr/share/zoneinfo/tzdata.zi to be updated when you backport changes to that file? The 2021a-1+deb11u10 version of that file contains a number of backported changes from 2023c (such as Egypt DST changes) but an application that compares a tzdata.zi file with "version 2022a" to the 2021a-1+deb11u10 one with "version 2021a" will conclude that the latter is outdated and the former should be used. However, the 2022a file would not contain the Egypt DST changes, and the "2021a" from 2021a-1+deb11u10 actually does contain them. Could you add some kind of Debian-specific discriminator to the file? E.g. use "# version 2021a-1+deb11u10" ? That would still sort lexicographically before 2022a despite being newer, but it would at least allow an application to distinguish between 2021a-1+deb11u10 and 2021a-1+deb11u9. This is important for the GCC C++ standard library, which inspects that version line to determine if the file on disk has been updated and should be reparsed. A long-running application will not pick up the changes to your /usr/share/zoneinfo/tzdata.zi file if a sysadmin updates the tzdata package, because the version line doesn't change when you update it.
Bug#1036104: tzdata.zi has a typo in the backported Egypt DST rules
Package: tzdata Version: 2021a-1+deb11u10 Severity: important Tags: patch X-Debbugs-Cc: deb...@kayari.org Dear Maintainer, * What led up to the situation? GCC 13 uses the /usr/share/zoneinfo/tzdata.zi file to implement support for the C++20 time zone library. * What exactly did you do (or not do) that was effective (or ineffective)? Basic use of std::chrono::tzdb with GCC 13 fails on Debian stable, because the tzdata.zi file cannot be parsed, and so only UTC time zones are supported. I originally filed this upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109857 Further investigation revealed it's a Debian-specific bug in the tzdata.zi file. * What was the outcome of this action? Attempting to use any non-UTC time zone in C++ programs will fail. * What outcome did you expect instead? The tzdata.zi file should be valid according to the zic(8) man page. Specifically: The fields that make up a rule line are: [...] TO Gives the final year in which the rule applies. In addition to minimum and maximum (as above), the word only (or an abbreviation) may be used to repeat the value of the FROM field. The tzdata-2021a-1+deb11u10 package contains a backport of the Egypt DST changes from this commit: https://github.com/eggert/tz/commit/dcd8cbed23201416cbd3bbf43f669737693282d7 However that has a typo, which was fixed by this commit, which is not present in the Debian package: https://github.com/eggert/tz/commit/af242d11b62584808a66851b8707148bf1ee8d0a Please backport the typo fix. -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.2.14-200.fc37.x86_64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.77 tzdata recommends no packages. tzdata suggests no packages. -- debconf information: tzdata/Zones/America: tzdata/Zones/Asia: * tzdata/Areas: Etc tzdata/Zones/Africa: tzdata/Zones/Pacific: tzdata/Zones/Indian: tzdata/Zones/US: tzdata/Zones/Arctic: * tzdata/Zones/Etc: UTC tzdata/Zones/Australia: tzdata/Zones/Europe: tzdata/Zones/Antarctica: tzdata/Zones/Atlantic:
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
On 23/04/20 09:23 +0100, Jonathan Wakely wrote: On 23/04/20 06:32 +0200, Helmut Grohne wrote: Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. Right. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. Or Debian should fix what they're going to break. This is not quite precise. The offending -isystem /usr/include/ flag is already being passed. According to what you write later, doing so is broken today. It just happens to work by accident. So all we do is making the present breakage visible. I am proposing to replace those two #include_next with plain #include. That'll solve the problem described above, but it is not entirely obvious that doing so doesn't break something else. After switching those #include_next to #include, libstdc++-v3/include/c_global/cstdlib will continue to temporarily will #include . Now, it'll search all include directories. It may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's version. We cannot tell which. If it finds the one from libstdc++-v3, the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and immediately #include_next skipping the rest of the header. That in turn will find the libc version. So in both cases, it ends up using the right one. Precisely what we wanted. As Marc said, this doesn't work. That is not very precise either. Marc said that it won't fix all cases. In practice, it would make those work that don't #include but use #include instead. Marc also indicated that using include_next for a header of a different name is wrong. So this is a bug in libstdc++ regardless of whether it breaks or unbreaks other pieces of software. He said he doesn't like it, that doesn't mean it's a bug or actually causes incorrect results. Whereas using -isystem provably *does* break the implementation, making it impossible for #include to meet the requirements of the C++ standard. And your proposed patch doesn't prevent that. If a program tries to include it needs to get the libstdc++ version, otherwise only the libc versions of certain functions are defined. That means the additional C++ overloads such as ::abs(long) and ::abs(long long) won't be defined. That is the reason why libstdc++ provides its own . And if you do -isystem /usr/include (or any other option that causes libstdc++'s to be skipped) that doesn't work. Only ::abs(int) gets defined. So -isystem /usr/include breaks code, with or without your patch. It is very difficult to disagree with -isystem /usr/include or -isystem /usr/include/ being broken and unsupported. Having you state it that clearly does help with communicating to other upstreams. For this reason, I've looked into the remaining cases. It turns out that there aren't that many left. In particular chromium, opencv and vtk got fixed in the mean time. Basically all remaining failures could be attributed to qmake, which passes all directories below /usr/include (including /usr/include and /usr/include/ if a .pc file mentions them) using -isystem. I've sent a patch https://bugs.debian.org/958479 to make qmake stop doing that. I therefore agree with you that the patch I sent for libstdc++ is not necessary to make packages build on Debian. Removing the offending -isystem flags from the respective builds is a manageable option and has already happened to a large extend. Yes, I introduced the current and wrappers years ago in GCC 6, and so I'm surprised to see it coming up again now. Several packages had problems and already fixed them. We can conclude that the motivation for my patch is not a good one, because it embraces broken behaviour. However, the use of include_next remains a bug, because the name of the including and the name of the included header differ, and it should be fixed on that ground. Not liking something is not a bug. You need to demonstrate an actual bug (e.g. failure to compile, non-conformance to the C++ standard) that is not caused by user error (like misuse of -isystem) to argue for fixing something. N.B. the GCC docs are quite clear that reordering include directories risk breaking GCC's necessary use of #include_next: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
On 23/04/20 06:32 +0200, Helmut Grohne wrote: Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: > Now you are probably going to say that "-isystem /usr/include" is a bad > idea and that you shouldn't do that. Right. > I'm inclined to agree. This isn't a > problem just yet. Debian wants to move /usr/include/stdlib.h to > /usr/include//stdlib.h. After that move, the problematic flag > becomes "-isystem /usr/include/". Unfortunately, around 30 > Debian packages[1] do pass exactly that flag. Regardless whether doing > so is a bad idea, I guess we will have to support that. Or Debian should fix what they're going to break. This is not quite precise. The offending -isystem /usr/include/ flag is already being passed. According to what you write later, doing so is broken today. It just happens to work by accident. So all we do is making the present breakage visible. > I am proposing to replace those two #include_next with plain #include. > That'll solve the problem described above, but it is not entirely > obvious that doing so doesn't break something else. > > After switching those #include_next to #include, > libstdc++-v3/include/c_global/cstdlib will continue to temporarily > will #include . Now, it'll search all include directories. It > may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's > version. We cannot tell which. If it finds the one from libstdc++-v3, > the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and > immediately #include_next skipping the rest of the header. > That in turn will find the libc version. So in both cases, it ends up > using the right one. Precisely what we wanted. As Marc said, this doesn't work. That is not very precise either. Marc said that it won't fix all cases. In practice, it would make those work that don't #include but use #include instead. Marc also indicated that using include_next for a header of a different name is wrong. So this is a bug in libstdc++ regardless of whether it breaks or unbreaks other pieces of software. He said he doesn't like it, that doesn't mean it's a bug or actually causes incorrect results. Whereas using -isystem provably *does* break the implementation, making it impossible for #include to meet the requirements of the C++ standard. And your proposed patch doesn't prevent that. If a program tries to include it needs to get the libstdc++ version, otherwise only the libc versions of certain functions are defined. That means the additional C++ overloads such as ::abs(long) and ::abs(long long) won't be defined. That is the reason why libstdc++ provides its own . And if you do -isystem /usr/include (or any other option that causes libstdc++'s to be skipped) that doesn't work. Only ::abs(int) gets defined. So -isystem /usr/include breaks code, with or without your patch. It is very difficult to disagree with -isystem /usr/include or -isystem /usr/include/ being broken and unsupported. Having you state it that clearly does help with communicating to other upstreams. For this reason, I've looked into the remaining cases. It turns out that there aren't that many left. In particular chromium, opencv and vtk got fixed in the mean time. Basically all remaining failures could be attributed to qmake, which passes all directories below /usr/include (including /usr/include and /usr/include/ if a .pc file mentions them) using -isystem. I've sent a patch https://bugs.debian.org/958479 to make qmake stop doing that. I therefore agree with you that the patch I sent for libstdc++ is not necessary to make packages build on Debian. Removing the offending -isystem flags from the respective builds is a manageable option and has already happened to a large extend. Yes, I introduced the current and wrappers years ago in GCC 6, and so I'm surprised to see it coming up again now. Several packages had problems and already fixed them. We can conclude that the motivation for my patch is not a good one, because it embraces broken behaviour. However, the use of include_next remains a bug, because the name of the including and the name of the included header differ, and it should be fixed on that ground. Not liking something is not a bug. You need to demonstrate an actual bug (e.g. failure to compile, non-conformance to the C++ standard) that is not caused by user error (like misuse of -isystem) to argue for fixing something.
Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers
On 20/04/20 07:01 +0200, Helmut Grohne wrote: The and headers need their counter parts and from the libc respectively, but libstdc++ wraps these headers. Now and include these headers using $ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null In file included from :1: /usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory 75 | #include_next | ^~ compilation terminated. $ What happens here is that g++ includes libstdc++-v3/include/c_global/cstdlib. That header temporarily #defines _GLIBCXX_INCLUDE_NEXT_C_HEADERS and then does #include_next . libstdc++-v3's replacement libstdc++-v3/include/c_comaptibility/stdlib.h happens to come earlier and is not considered. Unfortunately, the -isystem above inserted glibc's header before the location containing , so the #include_next continues searching and fails to find . Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. Right. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. Or Debian should fix what they're going to break. I am proposing to replace those two #include_next with plain #include. That'll solve the problem described above, but it is not entirely obvious that doing so doesn't break something else. After switching those #include_next to #include, libstdc++-v3/include/c_global/cstdlib will continue to temporarily will #include . Now, it'll search all include directories. It may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's version. We cannot tell which. If it finds the one from libstdc++-v3, the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and immediately #include_next skipping the rest of the header. That in turn will find the libc version. So in both cases, it ends up using the right one. Precisely what we wanted. As Marc said, this doesn't work. If a program tries to include it needs to get the libstdc++ version, otherwise only the libc versions of certain functions are defined. That means the additional C++ overloads such as ::abs(long) and ::abs(long long) won't be defined. That is the reason why libstdc++ provides its own . And if you do -isystem /usr/include (or any other option that causes libstdc++'s to be skipped) that doesn't work. Only ::abs(int) gets defined. So -isystem /usr/include breaks code, with or without your patch.
