tzdata_2018i-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 30 Dec 2018 21:02:04 -0500 Source: tzdata Binary: tzdata Architecture: source Version: 2018i-1 Distribution: unstable Urgency: high Maintainer: GNU Libc Maintainers Changed-By: Clint Adams Description: tzdata - time zone and daylight-saving time data Changes: tzdata (2018i-1) unstable; urgency=high . * New upstream version, affecting the following future timestamps: - São Tomé and Príncipe switches from +01 to +00 on 2019-01-01. Checksums-Sha1: 962eb314cd42111ba46bd4ce522f3cbde548b8cf 2257 tzdata_2018i-1.dsc bd5cd102c4a3c8206834b9bc6922437cc698c3c0 377009 tzdata_2018i.orig.tar.gz cbd4fc97ab585de717189e3c28d19d85c557d0f0 833 tzdata_2018i.orig.tar.gz.asc 5714b952770158b1d5b29bcc866dd58f33635621 104424 tzdata_2018i-1.debian.tar.xz f5383a94111da9bcbc3fcfa37e240a7395f45d72 4984 tzdata_2018i-1_source.buildinfo Checksums-Sha256: 6907aa3fa8b3c995df1859ae53aa48958af8b991219f55381974e3845cd52f0f 2257 tzdata_2018i-1.dsc 82c45ef84ca3bc01d0a4a397ba8adeb8f7f199c6550740587c6ac5a7108c00d9 377009 tzdata_2018i.orig.tar.gz eeaef7ccf3f1ea35274f480ad439c1ac0d6bb2a266f3dffd34ea6f282d915f2b 833 tzdata_2018i.orig.tar.gz.asc ba23503a4023f79f6e05e60fe95466ef17200fdec038c01781bc38f58144514b 104424 tzdata_2018i-1.debian.tar.xz 12df6a4cf65504bb37d6153446445692554bb392c0b453a587e24338a6722492 4984 tzdata_2018i-1_source.buildinfo Files: 8cbcca432a28d5a63af819e95416a287 2257 localization required tzdata_2018i-1.dsc b3f0a1a789480a036e58466cd0702477 377009 localization required tzdata_2018i.orig.tar.gz bbba65b6a2bf80a34ebf43473b8053a3 833 localization required tzdata_2018i.orig.tar.gz.asc abde640c01a343539936d924521b28cf 104424 localization required tzdata_2018i-1.debian.tar.xz bb8126648d42f5263297e5983a06a02a 4984 localization required tzdata_2018i-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEdYHsh0BT5sgHeRubVZIzHhmdOKgFAlwpeTgRHGNsaW50QGRl Ymlhbi5vcmcACgkQVZIzHhmdOKhNNw/+IY6w039bMlu7XdgOFOz1rEgZ6hJnmkHi wyFLdvxmBZKoNhr00+E/xBf+6pTbvdeuOlxSFnylAv68Rk+EjqPM7SB3IkH7mOKZ MlLEj8IU1zskkFtIZ8oIkjXY8MgUzAKzVp/GgmXzI1d3KjxxkyRIFLHrRIziuqB+ hjWT+BjMYN45sPxfHkHY8X0z/rNIc32jo3RAHkEpv/44xLgzLu9Cchxc7Kg5eWwr F3nhcv3pWe/2lx475gIXdTVzRK+q7T/hA4hPQMgw6m3bQgqy8uyCP443rXwPHklA htUJ0oG7GAy2QaQz2/AZfnrKZ+DkUBECXbJt6yHEg66E3UthqUveSvWH4P+CStqR ttZ5jCzTrI5sG3FSpBMCcIzJ+H7SIfmoTWICih1q93y5mGpvJOXym54upyNZiP4A ejoi83ePHErbPj+G3hAuJdoz8/VGm+vxmBPBaUWNs/FOmYmzKu53KrrpnuXWVmWU Jl7IXY2BSf8utrd576OTq40rt6pLIl9jK4ak+U9xeZf6agRoTLg5/F1Y0ZFPiFHf Qde3VMT83Tq7JgZrtFwGkOh9+gJRAspNpiXipyWx24tkXtSgGkRqwRZ1xDWdq9Yx yYaKJMhvkGnxbpZtrScX3g//QkJA9kU9QIJsPpcbVMNAiqhoEUpca4Y8LLIfKOpC YWCmdLV7oNk= =ZIWk -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of tzdata_2018i-1_source.changes
tzdata_2018i-1_source.changes uploaded successfully to localhost along with the files: tzdata_2018i-1.dsc tzdata_2018i.orig.tar.gz tzdata_2018i.orig.tar.gz.asc tzdata_2018i-1.debian.tar.xz tzdata_2018i-1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
[Git][glibc-team/tzdata] Pushed new tag debian/2018i-1
Clint Adams pushed new tag debian/2018i-1 at GNU Libc Maintainers / tzdata -- View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/tree/debian/2018i-1 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/tzdata][sid] 2018i: São Tomé and Príncipe switches from +01 to +00 on 2019-01-01
Clint Adams pushed to branch sid at GNU Libc Maintainers / tzdata Commits: a0df1db8 by Clint Adams at 2018-12-31T02:03:46Z 2018i: São Tomé and Príncipe switches from +01 to +00 on 2019-01-01 - - - - - 1 changed file: - debian/changelog View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/commit/a0df1db828cfc45f1958fb1b72994be97bf1bd95 -- View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/commit/a0df1db828cfc45f1958fb1b72994be97bf1bd95 You're receiving this email because of your account on salsa.debian.org.
Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install
On 2017-10-07 13:47, Steve Langasek wrote: > On Sat, Oct 07, 2017 at 07:17:56AM +0200, Adam Borowski wrote: > > Control: reassign -1 locales > > > On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote: > > > When Debian 9 is installed with the en-us locale selected, the clock > > > defaults > > > to 24 hour time in the resulting install. This is odd because the normal > > > means > > > of representing the time in the area covered by en-us is to separate the > > > day > > > into two 12-hour segments. (localization issue) > No, this is a nonsense argument. The en_US.UTF-8 locale must reflect the > actual usage in the US. "Well, systems use it as a default, so we're going > to overload it" would be idiotic. Totally correct, the locales should reflect the actual usage in a country and language, which is not always something easy to do and often controversial. > There's also no reason to believe that's actually what has happened here. Now that things have calm down, let's ignore the various hypothesis and let's look at the code. The two constants from LC_TIME representing the time, as defined by POSIX and ISO/IEC 14652 are: - D_T_FMT: String for formatting date and time. - T_FMT: Time format string. | $ LC_TIME=en_US.UTF-8 locale -c LC_TIME -k | egrep '^t_fmt=|^d_t_fmt=' | d_t_fmt="%a %d %b %Y %r %Z" | t_fmt="%r" In both cases the "%r" format specification is used which correspond to the time in a.m. or p.m. notation. This two constants correspond in strftime(3) respectively to the "%c" format specification (The preferred date and time representation for the current locale) and the "%X" format specification (The preferred time representation for the current locale without the date). This can be confirmed with the date utility: | $ LC_TIME=C.UTF-8 date +%c | Sun Dec 30 23:21:57 2018 | $ LC_TIME=en_GB.UTF-8 date +%c | Sun 30 Dec 2018 23:21:57 CET | $ LC_TIME=en_US.UTF-8 date +%c | Sun 30 Dec 2018 11:21:57 PM CET | $ LC_TIME=C.UTF-8 date +%X | 23:21:57 | $ LC_TIME=en_GB.UTF-8 date +%X | 23:21:57 | $ LC_TIME=en_US.UTF-8 date +%X | 11:21:57 PM In addition to POSIX and ISO/IEC 14652, the GNU libc also defines the "date_fmt" constant, which is use by the date(1) utility to display the date and time. It's an optional field, which defaults to "%a %b %e %H:%M:%S %Z %Y" if not defined. For what I understand the goal of this new constant is to always display the timezone, as the default way of displaying the time usually does not contain it for countries no spanning multiple time zones. > As to the actual bug, I don't know if this represents a deliberate change or > if it's accidental. Speaking for myself as an American, I can confirm the > described behavior... and can say that it completely escaped my notice, > because I prefer 24h time whenever given the option. Nevertheless, if this > bug is to be deemed 'wontfix', it must be done solely with respect to what > is correct for the *US* locale. The "date_fmt" constant has been added back in 2000, and the en_US locale never got it defined. Actually not that many locales define this constant as the default is often sane. It should only be used by date(1) so other applications should correctly display the time in 12h format. For me the proper way to fix this bug would be to define "date_fmt" for the en_US locale. I don't think this should be controversial given both "t_fmt" and "d_t_fmt" are already in 12 hours format. I will propose a patch upstream in that regard, as I prefer to avoid diverging on locales aspect. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
tzdata_2018h-0+deb9u1_amd64.changes ACCEPTED into proposed-updates->stable-new, proposed-updates
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 30 Dec 2018 14:11:33 +0100 Source: tzdata Binary: tzdata Architecture: source all Version: 2018h-0+deb9u1 Distribution: stretch Urgency: medium Maintainer: GNU Libc Maintainers Changed-By: Aurelien Jarno Description: tzdata - time zone and daylight-saving time data Changes: tzdata (2018h-0+deb9u1) stretch; urgency=medium . * New upstream version, affecting the following past and future timestamps: - Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. A new zone Asia/Qostanay has been added, because Qostanay, Kazakhstan didn't move. - Metlakatla, Alaska observes PST this winter only. Checksums-Sha1: 0cb54e73eb56267ce4409571d0aca0ad79539a8d 2270 tzdata_2018h-0+deb9u1.dsc b4019421361351451ca7b7f8670ae6b475ecf240 376711 tzdata_2018h.orig.tar.gz 4ee559f3c61f54651f0652860d3f0c0d29506b11 833 tzdata_2018h.orig.tar.gz.asc 91f914a2ede3ccef18d07bd0a98e32fafe4b10ee 101536 tzdata_2018h-0+deb9u1.debian.tar.xz 9137e3b20dee56097be11412398324416d7e5e1a 272400 tzdata_2018h-0+deb9u1_all.deb d3075eefd2646ff9772ab3520dd24557f9b8e7f1 5835 tzdata_2018h-0+deb9u1_amd64.buildinfo Checksums-Sha256: f1deb577d0cadec12931fcefe22dcdb2d150f6379fb8ed6a77b2fc40aa2f848b 2270 tzdata_2018h-0+deb9u1.dsc b8cbcf3e46aed30ad27c40d5bed68c16cf759384d14cc6411b84460c88bdd91f 376711 tzdata_2018h.orig.tar.gz 47a17076d39a632412196ee3fe73567832d17d03937f030afe43de5c3f5a8d5e 833 tzdata_2018h.orig.tar.gz.asc a12462822f0ca9751af74ce0268bbc80a77463fd4dfa2cc6f7f744a9f165dc35 101536 tzdata_2018h-0+deb9u1.debian.tar.xz bd7079df5f25306a90a3c3140003c53fba844a1b1bf72985cade4c4779c62965 272400 tzdata_2018h-0+deb9u1_all.deb 33dead75d11d77f60702e6de9192b12f3195e1700a04fbed7a780877c8f21dc2 5835 tzdata_2018h-0+deb9u1_amd64.buildinfo Files: 0b09dcf2bf062986fdbd9297033ab51b 2270 localization required tzdata_2018h-0+deb9u1.dsc 7ad1b70c53f0629728ae90565360c2fd 376711 localization required tzdata_2018h.orig.tar.gz db3fbea5745f3ad92df05c6e9f0bfacb 833 localization required tzdata_2018h.orig.tar.gz.asc 4a2711182d08c0b9ff1c5c9a85c46a1e 101536 localization required tzdata_2018h-0+deb9u1.debian.tar.xz 25875ccf92bf5dae855bff2a849155f6 272400 localization required tzdata_2018h-0+deb9u1_all.deb 276d11aad7e0b52bfab1f00d0702f937 5835 localization required tzdata_2018h-0+deb9u1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAlwoxEAACgkQE4jA+Jno M2tpHg//Y1iK0/JY/iu1BpTFDOa24006p4UOqHfTaczmW73ROmnCV9ygT7YVMXAu wCM4KDEvmAok7xjr9IPS+xewm1Xl72T/HkNW9CjJmO9LOfcsBwQlAK4dNxwB/IzG /7IdW5omx7ORmIB6yekPsQQIJ5as3q7FYOAwairtAXbQheVQKj7DHc+NYrSowPjy qbaZHkT5Pz1sweqUW7klAALyIs65jbYQozX9IB4iCAworTvordT5MWxN+FNho4aS a2zA64dXV2CTwvrcFB2r3B8ek1YL86YHAUDzFsOqkJJZRhsVJ81LHSgsE9KxBXuD mKBkLyDWS7JUIhWHAsh6O4EL1d7M5dXmF8ktsRQUU5D01xHPWtePXv5SO316PeIl hWAyN+DYPgeyQiDaMrylu12myJLE8RVo+GP2zrfHM96AScyD4JMSz/8lxVtkkfgU 8f41nSmTzQQMUaUnsTBwxf6EOfRB994xI58JBwMP7DkxRbkjdJMWOo+5y/R01sCc tXq3LRd3twMjrsowyOsnZRFKZCNDiQblCGLcp1nxPgMKWBpnQDsV+danfORPQtRX fsYSoSnd2kiHnS6KcbIKwUA+io9RuGF5PKaD0EOeNqgPu6AeIL2PXw1PR3mzimeT wh2ziSquyCOh88uvDJqp2+kMbS0lqK9eOCXOARTCNjpmYFLQ8Zg= =1pIc -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#758632: marked as done (libc6: can't set locale hy_AM.armscii8)
Your message dated Sun, 30 Dec 2018 21:44:15 +0100 with message-id <20181230204415.ga6...@aurel32.net> and subject line Re: Bug#758632: libc6: can't set locale hy_AM.armscii8 has caused the Debian Bug report #758632, regarding libc6: can't set locale hy_AM.armscii8 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 758632: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758632 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libc6 Version: 2.19-9 Severity: minor "locale -a" lists "hy_AM.armscii8" as one of the locales; but this locale cannot be set: $ locale -a | grep AM. hy_AM.armscii8 $ LC_ALL=hy_AM.armscii8 locale charmap locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968 Curiously enough, "hy_AM.armscii-8" works: $ LC_ALL=hy_AM.armscii-8 locale charmap ARMSCII-8 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libc6 depends on: ii libgcc1 1:4.9.1-7 Versions of packages libc6 recommends: pn libc6-i686 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.53 pn glibc-doc ii locales2.19-9 ii locales-all [locales] 2.19-9 -- Jakub Wilk --- End Message --- --- Begin Message --- Version: 2.28-1 On 2014-08-19 15:10, Jakub Wilk wrote: > Package: libc6 > Version: 2.19-9 > Severity: minor > > "locale -a" lists "hy_AM.armscii8" as one of the locales; but this locale > cannot be set: > > $ locale -a | grep AM. > hy_AM.armscii8 > > $ LC_ALL=hy_AM.armscii8 locale charmap > locale: Cannot set LC_CTYPE to default locale: No such file or directory > locale: Cannot set LC_MESSAGES to default locale: No such file or directory > locale: Cannot set LC_ALL to default locale: No such file or directory > ANSI_X3.4-1968 > > > Curiously enough, "hy_AM.armscii-8" works: > > $ LC_ALL=hy_AM.armscii-8 locale charmap > ARMSCII-8 This is BZ 19527 upstream, which has been fixed in glibc 2.28. Closing the bug with this version. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Processed: bug 758632 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=19527
Processing commands for cont...@bugs.debian.org: > forwarded 758632 https://sourceware.org/bugzilla/show_bug.cgi?id=19527 Bug #758632 [libc6] libc6: can't set locale hy_AM.armscii8 Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=19527'. > thanks Stopping processing here. Please contact me if you need assistance. -- 758632: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758632 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 913348 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=24045
Processing commands for cont...@bugs.debian.org: > forwarded 913348 https://sourceware.org/bugzilla/show_bug.cgi?id=24045 Bug #913348 [locales] Locale "i18n" has possibly a wrong value in LC_ADDRESS category Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=24045'. > thanks Stopping processing here. Please contact me if you need assistance. -- 913348: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913348 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 913929 is forwarded to https://sourceware.org/bugzilla/show_bug.cgi?id=18035
Processing commands for cont...@bugs.debian.org: > forwarded 913929 https://sourceware.org/bugzilla/show_bug.cgi?id=18035 Bug #913929 [libc-bin] pldd never stops Set Bug forwarded-to-address to 'https://sourceware.org/bugzilla/show_bug.cgi?id=18035'. > thanks Stopping processing here. Please contact me if you need assistance. -- 913929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913929 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#867283: marked as done (Crash in glibc's mktime in low-memory situations)
Your message dated Sun, 30 Dec 2018 20:51:24 +0100 with message-id <20181230195124.ga2...@aurel32.net> and subject line Re: Bug#867283: Crash in glibc's mktime in low-memory situations has caused the Debian Bug report #867283, regarding Crash in glibc's mktime in low-memory situations to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 867283: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867283 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: glibc Version: 2.19-18+deb8u10 By fuzzing my own software using American Fuzzy Lop and its provided libdislocator (an "abusive allocator" library), I found a code path in glibc that causes a SIGABRT where it probably shouldn't. In a low-memory situation, I got the following stack trace: #0 0x76319067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7631a448 in __GI_abort () at abort.c:89 #2 0x76312266 in __assert_fail_base (fmt=0x7644af18 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7644893f "num_types == 1", file=file@entry=0x76448936 "tzfile.c", line=line@entry=779, function=function@entry=0x7644fc90 <__PRETTY_FUNCTION__.6261> "__tzfile_compute") at assert.c:92 #3 0x76312312 in __GI___assert_fail (assertion=assertion@entry=0x7644893f "num_types == 1", file=file@entry=0x76448936 "tzfile.c", line=line@entry=779, function=function@entry=0x7644fc90 <__PRETTY_FUNCTION__.6261> "__tzfile_compute") at assert.c:101 #4 0x76391907 in __tzfile_compute (timer=1447111074, use_localtime=use_localtime@entry=1, leap_correct=leap_correct@entry=0x7fffd848, leap_hit=leap_hit@entry=0x7fffd844, tp=tp@entry=0x7fffd960) at tzfile.c:779 #5 0x76390429 in __tz_convert (timer=0x7fffd948, use_localtime=1, tp=0x7fffd960) at tzset.c:635 #6 0x7638eab0 in ranged_convert (convert=0x7638e940 <__localtime_r>, t=0x7fffd948, tp=0x7fffd960) at mktime.c:310 #7 0x7638edd5 in __mktime_internal (tp=0x7fffdab0, convert=0x7638e940 <__localtime_r>, offset=0x7668bab8 ) at mktime.c:478 #8 0x76c02083 in OpenMPT::mpt::Date::Unix::FromUTC (timeUtc=...) at common/mptTime.cpp:115 mktime is supposed to return -1 and, according to cplusplus.com, has a no-throw guarantee for C++ code. So even if some internal memory cannot be allocated, I expect mktime to return with an error value and not cause a SIGABRT. I found it difficult to reproduce this outside my afl-instrumented environment, but I hope the stack trace helps with verifying whether this is a valid bug. If you need a test case to reproduce, let me know. Cheers, Johannes --- End Message --- --- Begin Message --- Version: 2.28-1 On 2017-07-05 22:22, Johannes Schultz wrote: > (Mail was initially only sent to Carlos, sorry for that :)) > > > If you have the opportunity please file a match bug with upstream at > > sourceware.org/bugzilla. That way upstream is made aware of the issue. > > The bug is now being tracked at: > https://sourceware.org/bugzilla/show_bug.cgi?id=21716 This bug has been fixed upstream in both master and in the 2.28 branch. It appeared in Debian in glibc version 2.28-1. I am therefore closing the bug with this version. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Processed: Bug #909047 in glibc marked as pending
Processing control commands: > tag -1 pending Bug #909047 [libc6] libc6.preinst: possible typo in 's/\bsamaba\b/smbd/g' Added tag(s) pending. -- 909047: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909047 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#909047: libc6.preinst: possible typo in 's/\bsamaba\b/smbd/g'
On 2018-09-17 22:30, Ansgar Burchardt wrote: > Package: libc6 > Version: 2.27-6 > Severity: normal > > libc6.preinst includes: > > -e's/\bsamaba\b/smbd/g' > > This looks like a typo to me. I assume it should be samba instead of > samaba? Good catch thanks. It will be fixed in the next upload. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
[Git][glibc-team/glibc][sid] debian/script.in/nsscheck.sh: fix a typo s/samaba/samba/. Closes: #909047.
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / glibc Commits: 593a2a58 by Aurelien Jarno at 2018-12-30T19:46:01Z debian/script.in/nsscheck.sh: fix a typo s/samaba/samba/. Closes: #909047. - - - - - 2 changed files: - debian/changelog - debian/script.in/nsscheck.sh View it on GitLab: https://salsa.debian.org/glibc-team/glibc/commit/593a2a5821c13dca9b56482cc42213711bc0412e -- View it on GitLab: https://salsa.debian.org/glibc-team/glibc/commit/593a2a5821c13dca9b56482cc42213711bc0412e You're receiving this email because of your account on salsa.debian.org.
Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture
Hi,
On 2018-08-22 13:02, Андрей Доценко wrote:
> Package: libc6
> Version: 2.24-11+deb9-u3
>
> Using sem_timedwait on i686 gives random results. In out proprietary
> software semaphore used by two processes and located in shared memory
> mapped with mmap. All works under amd64 architecture and under another some
> distibutions. But under Debian Stretch amd64 sem_timedwait always blocks
> for timeout and returns ETIMEOUT error. Meanwhile it acquires the lock
> decreasing semaphore value.
>
> I've tried to make test for this bug. Test reproduces bug only with ASAN
> enabled. Without ASAN enabled it always passes. I've attached test but
> without ASAN support to show that I don't miss anything. I can modify test
> to enable ASAN support but if somebody ask.
Thanks, I have been able to reproduce the problem here, even with glibc
2.29. I have attached a version which doesn't need cmake nor check.
On your side, have you been able to reproduce the problem *without*
ASAN, even on a bigger codebase? I wonder if it is actually a side
effect of ASAN.
> I've discovered that symbols used by i686 are different from those from
> amd64. On amd64 symbols are:
> ~$ nm "${PROJ_PATH}/Docker/debian/9/amd64/test-bugs/test-bugs" | grep sem_
> U sem_destroy@@GLIBC_2.2.5
> U sem_getvalue@@GLIBC_2.2.5
> U sem_init@@GLIBC_2.2.5
> U sem_post@@GLIBC_2.2.5
> U sem_timedwait@@GLIBC_2.2.5
> 004019b0 t test_process_sem_timedwait
> 004011c0 t test_process_sem_timedwait_nolock
>
> But under i686 symbols are different:
> ~$ nm "${PROJ_PATH}/Docker/debian/9/i386/test-bugs/test-bugs" | grep sem_
> U sem_destroy@@GLIBC_2.1
> U sem_getvalue@@GLIBC_2.1
> U sem_init@@GLIBC_2.1
> U sem_post@@GLIBC_2.1
> U sem_timedwait@@GLIBC_2.2
> 08049f50 t test_process_sem_timedwait
> 08048ee0 t test_process_sem_timedwait_nolock
>
> As you can see symbols are different for i686. Version of sem_init,
> sem_wait, sem_post, sem_destroy and sem_getvalue is GLIBC_2.1, but version
> of sem_timedwait is GLIBC_2.2.
This is perfectly normal. glibc 2.2.5 is the first glibc version that
supported the amd64 architecture.
> Replacing sem_timedwait with sem_wait makes all work on i686 architecture.
> So sem_wait is ok, but sem_timedwait is not.
I confirm that.
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
/* Build with: gcc -o bug906917 bug906917.c -pthread -fsanitize=address */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main()
{
sem_t *sem =
mmap(NULL, sizeof(*sem), PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
int r;
r = sem_init(sem, 1, 0);
if (r == -1) {
perror("sem_init");
}
assert(r == 0);
pid_t pid = fork();
if (pid == 0) {
r = sem_post(sem);
if (r == -1) {
exit(1);
}
exit(0);
}
assert(pid > 0);
int exit_status;
pid_t child_pid;
do {
child_pid = waitpid(pid, _status, 0);
}
while ((child_pid == -1) && (errno == EINTR));
if (child_pid == -1) {
perror("waitpid");
}
assert(child_pid == pid);
assert(WIFEXITED(exit_status));
assert(WEXITSTATUS(exit_status) == 0);
struct timespec abstime;
r = clock_gettime(CLOCK_REALTIME, );
assert(r == 0);
abstime.tv_sec += 5;
int value = -1;
sem_getvalue(sem, );
assert(value == 1);
do {
r = sem_timedwait(sem, );
}
while ((r == -1) && (errno == EINTR));
if (r == -1) {
perror("sem_timedwait");
}
assert(r == 0);
value = -1;
sem_getvalue(sem, );
assert(value == 0);
sem_destroy(sem);
return 0;
}
Bug#914999: [libc6] Locking problems into libc6
On 2018-12-12 17:11, Roman Savochenko wrote: > Hello, Aurelien > > On 12/4/18 1:24 PM, Roman Savochenko wrote: > > On 11/29/18 9:13 PM, Aurelien Jarno wrote: > > > > 1. For my program, I was needed to create extra locking about > > > > the function > > > > getaddrinfo(), but that resolved the problem only for my calls > > > > but for the > > > > external libraries like to MySQL, MariaDB I yet have the crashes and it > > > > cannot be fixed at all. > > > Can you give more details about the issue, the symptoms, possible crash > > > backtrace, way to reproduce it. Without this details, there are very few > > > chances to be able to fix the bug. > > > > Yes, I had there a crash, but it appeared next as a problem into > > libMariaDB (Bug#915515). Also I had early observed differences into real > > address passed to getaddrinfo() and taken from the real connection, what > > I have not observed now. So this item I remove from causes to GLibC > > problems while. > > Vice versa, the first problem is actual one for GLibC since: > > * I have observed twice the difference, please see on the included >screenshot. I indeed see two different IPs circled in red. Now I don't get what they are, if they should be different or not and how that relates to glibc. > * Also I have seen once for very long locking into the function >getaddrinfo()->poll() for some VPN (FortiClient in the case), see to >the crash report, got after the program termination by SIGSEGV. poll() has nothing to do with locking, it just hang there waiting for an answer to a DNS request sent by the functions called through getaddrinfo(). According to the trace, the timeout is set to about 5 seconds. The others thread waiting for poll() are called from libglib-2.0 and from libxcb.so.1. As for the segmentation fault, it happens in pthread_cond_timedwait.S called directly from libQt5Core.so.5. Without more info, it's difficult to say if it's due to a bug in glibc or if the argument passed to this function are corrupted, for example because the data pointed by QMutex* are corrupted. Do you have another way to reproduce the issue that is actually easier than using openscada? > > There are thousands of packages in different versions between Debian 8 > > > and Debian 9. You have found it's not related to the kernel, but I fail > > > to see how that shows it's a libc6 issue. For example when you have > > > tried the kernel from Debian 9 in Debian 8, have you also tried with the > > > rtl8192 firmware from Debian 9? > > I will compare the firmware, thanks. > I have installed of equal package firmware-realtek 20161130-4 on Debian 9 > and this problem is actual yet. > > > Anyway if we want to know that the problem is related with glibc, please > > > try to install glibc packages (libc*, possibly locales* and nscd if > > > needed) from Debian 9 onto a working Debian 8 installation and see if > > > the problem appears. > > I going to try that also, thanks. > > I have updated the package libc6 up to version 2.24 on Debian 8 and both of > the two last item, RTL8192eu and WIFI HotSpot, continue to work. > > Where can I move then the problems with RTL8192eu and WIFI HotSpot on Debian > 9? The best would be to look the logs in /var/log/syslog to check what is the issue. It could be a dhcp issue, a network-manager issue or a wpasupplicant issue depending what you are using. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#912600: marked as done (glibc-source: spin-lock.h not found when building)
Your message dated Sun, 30 Dec 2018 16:09:07 +0100 with message-id <20181230150907.ga13...@aurel32.net> and subject line Re: Bug#912600: glibc-source: spin-lock.h not found when building has caused the Debian Bug report #912600, regarding glibc-source: spin-lock.h not found when building to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 912600: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912600 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: glibc-source Version: 2.24-11+deb9u3 Severity: serious Justification: fails to build from source (but built successfully in the past) -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) glibc-source depends on no packages. Versions of packages glibc-source recommends: ii xz-utils 5.2.2-1.2+b1 glibc-source suggests no packages. -- no debconf information I've followed the instructions in the INSTALL file, at the step when I run make in the build directory, I got this problem: In file included from libpthread/include/pthread/pthreadtypes.h:95:0, from libpthread/sysdeps/pthread/bits/pthreadtypes.h:27, from ./posix/sys/types.h:270, from include/sys/types.h:1, from misc/sys/uio.h:23, from :3: libpthread/sysdeps/pthread/bits/condition.h:23:28: fatal error: bits/spin-lock.h: No such file or directory #include --- End Message --- --- Begin Message --- Hi, On 2018-11-01 19:46, Max wrote: > Package: glibc-source > Version: 2.24-11+deb9u3 > Severity: serious > Justification: fails to build from source (but built successfully in the past) Note that the way you have followed is not the way to rebuild a package in debian. glibc-source is used to provide the glibc sources for the cross-toolchain packages. If you just want to rebuild the package, you should get the source with: - apt-get source glibc - cd glibc-2.24 - dpkg-buildpackage or debuild Therefore this justification doesn't apply and the package still builds fine from source. > I've followed the instructions in the INSTALL file, at the step when I run > make in the build directory, I got this problem: This file is the upstream way to build the glibc from sources. > In file included from libpthread/include/pthread/pthreadtypes.h:95:0, > from libpthread/sysdeps/pthread/bits/pthreadtypes.h:27, > from ./posix/sys/types.h:270, > from include/sys/types.h:1, > from misc/sys/uio.h:23, > from :3: > libpthread/sysdeps/pthread/bits/condition.h:23:28: fatal error: > bits/spin-lock.h: No such file or directory > #include You have forgotten to pass the list of addons to the configure script, try to add --enable-add-ons=libidn. You will also need to pass --enable-obsolete-nsl for the build to succeed. With these explanations, I guess the bug can be closed. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
tzdata_2018h-0+deb9u1_amd64.changes ACCEPTED into proposed-updates->stable-new
Mapping stretch to stable. Mapping stable to proposed-updates. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 30 Dec 2018 14:11:33 +0100 Source: tzdata Binary: tzdata Architecture: source all Version: 2018h-0+deb9u1 Distribution: stretch Urgency: medium Maintainer: GNU Libc Maintainers Changed-By: Aurelien Jarno Description: tzdata - time zone and daylight-saving time data Changes: tzdata (2018h-0+deb9u1) stretch; urgency=medium . * New upstream version, affecting the following past and future timestamps: - Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. A new zone Asia/Qostanay has been added, because Qostanay, Kazakhstan didn't move. - Metlakatla, Alaska observes PST this winter only. Checksums-Sha1: 0cb54e73eb56267ce4409571d0aca0ad79539a8d 2270 tzdata_2018h-0+deb9u1.dsc b4019421361351451ca7b7f8670ae6b475ecf240 376711 tzdata_2018h.orig.tar.gz 4ee559f3c61f54651f0652860d3f0c0d29506b11 833 tzdata_2018h.orig.tar.gz.asc 91f914a2ede3ccef18d07bd0a98e32fafe4b10ee 101536 tzdata_2018h-0+deb9u1.debian.tar.xz 9137e3b20dee56097be11412398324416d7e5e1a 272400 tzdata_2018h-0+deb9u1_all.deb d3075eefd2646ff9772ab3520dd24557f9b8e7f1 5835 tzdata_2018h-0+deb9u1_amd64.buildinfo Checksums-Sha256: f1deb577d0cadec12931fcefe22dcdb2d150f6379fb8ed6a77b2fc40aa2f848b 2270 tzdata_2018h-0+deb9u1.dsc b8cbcf3e46aed30ad27c40d5bed68c16cf759384d14cc6411b84460c88bdd91f 376711 tzdata_2018h.orig.tar.gz 47a17076d39a632412196ee3fe73567832d17d03937f030afe43de5c3f5a8d5e 833 tzdata_2018h.orig.tar.gz.asc a12462822f0ca9751af74ce0268bbc80a77463fd4dfa2cc6f7f744a9f165dc35 101536 tzdata_2018h-0+deb9u1.debian.tar.xz bd7079df5f25306a90a3c3140003c53fba844a1b1bf72985cade4c4779c62965 272400 tzdata_2018h-0+deb9u1_all.deb 33dead75d11d77f60702e6de9192b12f3195e1700a04fbed7a780877c8f21dc2 5835 tzdata_2018h-0+deb9u1_amd64.buildinfo Files: 0b09dcf2bf062986fdbd9297033ab51b 2270 localization required tzdata_2018h-0+deb9u1.dsc 7ad1b70c53f0629728ae90565360c2fd 376711 localization required tzdata_2018h.orig.tar.gz db3fbea5745f3ad92df05c6e9f0bfacb 833 localization required tzdata_2018h.orig.tar.gz.asc 4a2711182d08c0b9ff1c5c9a85c46a1e 101536 localization required tzdata_2018h-0+deb9u1.debian.tar.xz 25875ccf92bf5dae855bff2a849155f6 272400 localization required tzdata_2018h-0+deb9u1_all.deb 276d11aad7e0b52bfab1f00d0702f937 5835 localization required tzdata_2018h-0+deb9u1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAlwoxEAACgkQE4jA+Jno M2tpHg//Y1iK0/JY/iu1BpTFDOa24006p4UOqHfTaczmW73ROmnCV9ygT7YVMXAu wCM4KDEvmAok7xjr9IPS+xewm1Xl72T/HkNW9CjJmO9LOfcsBwQlAK4dNxwB/IzG /7IdW5omx7ORmIB6yekPsQQIJ5as3q7FYOAwairtAXbQheVQKj7DHc+NYrSowPjy qbaZHkT5Pz1sweqUW7klAALyIs65jbYQozX9IB4iCAworTvordT5MWxN+FNho4aS a2zA64dXV2CTwvrcFB2r3B8ek1YL86YHAUDzFsOqkJJZRhsVJ81LHSgsE9KxBXuD mKBkLyDWS7JUIhWHAsh6O4EL1d7M5dXmF8ktsRQUU5D01xHPWtePXv5SO316PeIl hWAyN+DYPgeyQiDaMrylu12myJLE8RVo+GP2zrfHM96AScyD4JMSz/8lxVtkkfgU 8f41nSmTzQQMUaUnsTBwxf6EOfRB994xI58JBwMP7DkxRbkjdJMWOo+5y/R01sCc tXq3LRd3twMjrsowyOsnZRFKZCNDiQblCGLcp1nxPgMKWBpnQDsV+danfORPQtRX fsYSoSnd2kiHnS6KcbIKwUA+io9RuGF5PKaD0EOeNqgPu6AeIL2PXw1PR3mzimeT wh2ziSquyCOh88uvDJqp2+kMbS0lqK9eOCXOARTCNjpmYFLQ8Zg= =1pIc -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of tzdata_2018h-0+deb9u1_amd64.changes
tzdata_2018h-0+deb9u1_amd64.changes uploaded successfully to localhost along with the files: tzdata_2018h-0+deb9u1.dsc tzdata_2018h.orig.tar.gz tzdata_2018h.orig.tar.gz.asc tzdata_2018h-0+deb9u1.debian.tar.xz tzdata_2018h-0+deb9u1_all.deb tzdata_2018h-0+deb9u1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
[Git][glibc-team/tzdata] Pushed new tag debian/2018h-0+deb9u1
Aurelien Jarno pushed new tag debian/2018h-0+deb9u1 at GNU Libc Maintainers / tzdata -- View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/tree/debian/2018h-0+deb9u1 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/tzdata][stretch] 3 commits: New upstream version, affecting the following past and future timestamps:
Aurelien Jarno pushed to branch stretch at GNU Libc Maintainers / tzdata Commits: 965ce358 by Aurelien Jarno at 2018-12-30T13:04:00Z New upstream version, affecting the following past and future timestamps: * New upstream version, affecting the following past and future timestamps: - Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. A new zone Asia/Qostanay has been added, because Qostanay, Kazakhstan didnt move. - Metlakatla, Alaska observes PST this winter only. - - - - - b9fb92a8 by Aurelien Jarno at 2018-12-30T13:11:29Z Import templates and translations - - - - - 707e3753 by Aurelien Jarno at 2018-12-30T13:11:39Z releasing package tzdata version 2018h-0+deb9u1 - - - - - 30 changed files: - debian/changelog - debian/po/be.po - debian/po/bg.po - debian/po/ca.po - debian/po/cs.po - debian/po/da.po - debian/po/de.po - debian/po/en.po - debian/po/es.po - debian/po/eu.po - debian/po/fi.po - debian/po/fr.po - debian/po/gl.po - debian/po/gu.po - debian/po/he.po - debian/po/hr.po - debian/po/hu.po - debian/po/id.po - debian/po/it.po - debian/po/ja.po - debian/po/ku.po - debian/po/lt.po - debian/po/ml.po - debian/po/nl.po - debian/po/pl.po - debian/po/pt.po - debian/po/pt_BR.po - debian/po/ru.po - debian/po/sk.po - debian/po/sq.po View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/compare/3b7e89d9a730e9f1d1b6021d12b53fdca18694fd...707e375349fc83b7800ac9f9609de637c106e634 -- View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/compare/3b7e89d9a730e9f1d1b6021d12b53fdca18694fd...707e375349fc83b7800ac9f9609de637c106e634 You're receiving this email because of your account on salsa.debian.org.
