tzdata_2020d-1_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 21 Oct 2020 22:21:30 +0200 Source: tzdata Architecture: source Version: 2020d-1 Distribution: unstable Urgency: high Maintainer: GNU Libc Maintainers Changed-By: Aurelien Jarno Changes: tzdata (2020d-1) unstable; urgency=high . * New upstream version, affecting the following future timestamp: - Palestine ends DST earlier than predicted, on 2020-10-24. * Set urgency to high to get the package into testing before the next change. Checksums-Sha1: 0af432af7105c815e40865b4cb8ad5eee8fca01f 2237 tzdata_2020d-1.dsc ac5070c8e2953c90f3ea4ebdba3257d7cc3308be 401479 tzdata_2020d.orig.tar.gz 09cfd367af69140e5ede10416b89db5b4f52be6c 833 tzdata_2020d.orig.tar.gz.asc 9af0e5a308f98252ccc8eb56820f81e5d9eded27 105024 tzdata_2020d-1.debian.tar.xz ac2e2b51d829df0af5e97fef6e0262e1d611cb2c 5539 tzdata_2020d-1_source.buildinfo Checksums-Sha256: e55a51c11ac47c2fe126651ab7f2c5e3786bb2449c0920d21698f4cc5dc35143 2237 tzdata_2020d-1.dsc 8d813957de363387696f05af8a8889afa282ab5016a764c701a20758d39cbaf3 401479 tzdata_2020d.orig.tar.gz dab20578e9ef6823d7cc4593b28b453fc2edb929954e25259942654d1611adb8 833 tzdata_2020d.orig.tar.gz.asc 85b547232850b8869ff43169bd9671634a5b6e60993805d46edd7bb8ff739918 105024 tzdata_2020d-1.debian.tar.xz 3008374d766bbeee358b6c02688a4ab764894373074bfcaf889415e8bd7a7085 5539 tzdata_2020d-1_source.buildinfo Files: 9e64c144d4c6c6ed9cc2f23e2d74bccb 2237 localization required tzdata_2020d-1.dsc 2f58d72e31cf073f5076c2cbf182cba3 401479 localization required tzdata_2020d.orig.tar.gz ff5c277032b47e422ffd5fac64e1aaad 833 localization required tzdata_2020d.orig.tar.gz.asc 33c60b92f88cd875a82cd86ba31f0984 105024 localization required tzdata_2020d-1.debian.tar.xz 1dab107d4d742da7beec23672d3b5026 5539 localization required tzdata_2020d-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAl+QmI4ACgkQE4jA+Jno M2uv7A/8C7yDqNhIUIqXrYuZqCudhB5CMuO9PaJfK2AfxVO+jjXRskUkehJpL8M2 h4XcBR+TsfunQzCOKTkpg1urpw9ruIBl4+g0+GHfhJKo6QOtgBczVGseHUnhfPMx DsjvkvtXdlui1BalvmynrcQNX326JaJ6+xam1FMCJbRrZHRk5RRco/mVB/IukLa/ SAA1Z9V+5Pf5DaCiT/3VMLFYz0NI7VV6MzskxviERfL3hq2RdHj1xb2CcmVh12F9 r+atH7FGnAGYdJI0Q9yva4aYBjrabs8y7C2jN8HRbAP9KeQjuTHSyLbIdCJDB/zb rABTH1nTfUvjqXuodp73hq53iVAG6labnT4Gyd4HXhAEqwSlDlJ3SOSZ9LGXU+6M OQEppgHfZPZ9b3AtH8tzKSkuQoGaiTiKJjoh7M2C2p8Bguk4IXruOue45P1YdhNK 9nK/G/FrDqLY3vx07Op9rOvlDGJQxdfI3YTEf/tmSJQrvlxCgyxh1hNjB6vvo+Mo E9I3CqlR5Dgbo9MxZMlUXcFsw6aPp4pd7Yc2eAENhrU+tLWybcxSqOJ+2ehlAeDy I42a+jrLeESW5wdUdmnfj0i4mTJqhhxKfYzL1jgZoKFUg9k6dPt57aEvMUcHyTvB i9hf79Nhi5fWNUIO4HVDJWILwsFv1s/vNoKTeTcNf4UKRPs64ww= =ZNLW -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of tzdata_2020d-1_source.changes
tzdata_2020d-1_source.changes uploaded successfully to localhost along with the files: tzdata_2020d-1.dsc tzdata_2020d.orig.tar.gz tzdata_2020d.orig.tar.gz.asc tzdata_2020d-1.debian.tar.xz tzdata_2020d-1_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
[Git][glibc-team/tzdata][sid] 3 commits: New upstream version, affecting the following future timestamp:
Aurelien Jarno pushed to branch sid at GNU Libc Maintainers / tzdata Commits: 1e942b5b by Aurelien Jarno at 2020-10-21T22:16:29+02:00 New upstream version, affecting the following future timestamp: * New upstream version, affecting the following future timestamp: - Palestine ends DST earlier than predicted, on 2020-10-24. - - - - - 6d7a195d by Aurelien Jarno at 2020-10-21T22:21:28+02:00 Set urgency to high to get the package into testing before the next change. - - - - - 2ab3fd9b by Aurelien Jarno at 2020-10-21T22:21:36+02:00 releasing package tzdata version 2020d-1 - - - - - 1 changed file: - debian/changelog View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/-/compare/f63a2248b1d6040e6382d427efb4775a70f34480...2ab3fd9bb6accba55a04da25f00d9c8d9926c060 -- View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/-/compare/f63a2248b1d6040e6382d427efb4775a70f34480...2ab3fd9bb6accba55a04da25f00d9c8d9926c060 You're receiving this email because of your account on salsa.debian.org.
[Git][glibc-team/tzdata] Pushed new tag debian/2020d-1
Aurelien Jarno pushed new tag debian/2020d-1 at GNU Libc Maintainers / tzdata -- View it on GitLab: https://salsa.debian.org/glibc-team/tzdata/-/tree/debian/2020d-1 You're receiving this email because of your account on salsa.debian.org.
Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
Hi, On 2020-10-21 11:55, John Paul Adrian Glaubitz wrote: > Hi! > > On 10/19/20 9:12 PM, Aurelien Jarno wrote: > >> jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a > >> *lot* of architectures > >> jrtc27 | if it were up to me the problem would be solved by just > >> deleting sbrk... > >> jrtc27 | FreeBSD just took the stance of not implementing them for new > >> ports > >> jrtc27 | so it's arm64 and riscv64 ports just have no sbrk > >> jrtc27 | cbmuser: looks like the tests are Debian-specific > >> jrtc27 | added as part of Hurd sbrk reworking to test it didn't break > > > > This is a bit exaggerated, this test actually passes on more > > architectures than it fails. Also this doesn't mean the test is useless, > > it means those architectures behaves differently, and that something has > > to be fixed. It could be some architecture specific code or the test > > itself. > > Well, but if it's in the end a feature that no one is using and a test that > isn't even part > of the upstream tests I don't see the point in testing it. brk/sbrk is definitely something deprecated. But it is still part of the API (especially for old architectures) and still used by software like jemalloc, gcl or libgc. This is therefore important to keep this feature in a good shape. It's also used by many less important packages, often just to print a backtrace. If someone has spoons it might be worth opening bugs again those package, so that they stop using brk/sbrk. > >> Can we disable them? With the tests disabled, glibc should pass its > >> testsuite on at least alpha and > >> sparc64. Not sure what the problem with hppa is at the moment. > > > > We can definitely ignore it on the affected architectures, do you please > > give more details why the test is so wrong that it should be ignored on > > *all* architectures? > > I'm just quoting jrtc27 from IRC. I'm not really an expert on that matter. > > > Ignoring it on the affected architectures, will indeed fix alpha. Not > > sure about hppa, ia64 and sparc64 that have other issues. And there is > > no build log for m68k and sh4 to judge. > > It seems that these two tests are currently the only tests that are not being > ignored > that are failing unless I'm missing something (I just looked at the build > log). I guess you mean for sparc64. This is indeed the case when building the sparc64 flavour, but we know that the sparc flavour will fail later. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs
Hi! On 10/19/20 9:12 PM, Aurelien Jarno wrote: >> jrtc27 | misc/tst-sbrk and/or misc/tst-sbrk-pie seem to be failing on a >> *lot* of architectures >> jrtc27 | if it were up to me the problem would be solved by just deleting >> sbrk... >> jrtc27 | FreeBSD just took the stance of not implementing them for new >> ports >> jrtc27 | so it's arm64 and riscv64 ports just have no sbrk >> jrtc27 | cbmuser: looks like the tests are Debian-specific >> jrtc27 | added as part of Hurd sbrk reworking to test it didn't break > > This is a bit exaggerated, this test actually passes on more > architectures than it fails. Also this doesn't mean the test is useless, > it means those architectures behaves differently, and that something has > to be fixed. It could be some architecture specific code or the test > itself. Well, but if it's in the end a feature that no one is using and a test that isn't even part of the upstream tests I don't see the point in testing it. >> Can we disable them? With the tests disabled, glibc should pass its >> testsuite on at least alpha and >> sparc64. Not sure what the problem with hppa is at the moment. > > We can definitely ignore it on the affected architectures, do you please > give more details why the test is so wrong that it should be ignored on > *all* architectures? I'm just quoting jrtc27 from IRC. I'm not really an expert on that matter. > Ignoring it on the affected architectures, will indeed fix alpha. Not > sure about hppa, ia64 and sparc64 that have other issues. And there is > no build log for m68k and sh4 to judge. It seems that these two tests are currently the only tests that are not being ignored that are failing unless I'm missing something (I just looked at the build log). As for m68k and sh4, I currently can't enable the builds there as the fixes by Adhemerval Zanella to unbreak glibc >= 2.28 on qemu-user have not been merged yet anywhere (neither in Debian nor upstream). I know that Adhemerval is testing glibc on my SH-7785LCR board regularly and I know that Andreas Schwab is testing internally at SUSE on m68k (his openSUSE port for m68k is unfortunately not public). Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916276 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
