NEW changes in stable-new
Processing changes file: grub2_2.02+dfsg1-20+deb10u3_mipsel-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: grub2_2.02+dfsg1-20+deb10u3_mips64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: grub2_2.02+dfsg1-20+deb10u3_amd64-buildd.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_armel-buildd.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_i386.changes ACCEPT
NEW changes in stable-new
Processing changes file: grub2_2.02+dfsg1-20+deb10u3_arm64-buildd.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_armhf-buildd.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_mips-buildd.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_ppc64el-buildd.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_s390x-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: mini-buildd_1.0.36+deb10u1_all.changes ACCEPT
NEW changes in stable-new
Processing changes file: coturn_4.5.1.1-1.1+deb10u2_source.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_amd64-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_arm64-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_armel-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_armhf-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_i386-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_mips-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_mips64el-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_mipsel-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_ppc64el-buildd.changes ACCEPT Processing changes file: coturn_4.5.1.1-1.1+deb10u2_s390x-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_source.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_all.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_amd64-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_arm64-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_armel-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_armhf-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_i386.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_mips-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_mips64el-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_mipsel-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_ppc64el-buildd.changes ACCEPT Processing changes file: flatpak_1.2.5-0+deb10u2_s390x.changes ACCEPT Processing changes file: grub2_2.02+dfsg1-20+deb10u3_source.changes ACCEPT Processing changes file: mini-buildd_1.0.36+deb10u1_source.changes ACCEPT
Bug#980133: buster-pu: package libdbd-csv-perl/0.5300-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org,y...@debian.org,elb...@debian.org
[ Reason ]
After the fixes to libdbi-perl (pending for the point release) to
address #972180 / CVE-2014-10402, libdbd-csv-perl showed autopkgtest
failures as reported by Paul Gevers.
For unstable this was back when the CVE was addressed reported as
#974134.
[ Impact ]
libdbd-csv-perl would have test failures in t/11_dsnlist.t.
[ Tests ]
Full build for libdbd-csv-perl with the upstream patch applied and
builded and tested with the libdbi-perl/1.642-1+deb10u2 version which
pending for the buster point release.
[ Risks ]
Should be, as the update fixes just the broken test and this fix was
in unstable for a while.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Apply upstream changes to t/11_dsnlist.t to work with the
CVE-2014-10402 fixes applied to libdbi-perl.
[ Other info ]
None
Regards,
Salvatore
diff -Nru libdbd-csv-perl-0.5300/debian/changelog
libdbd-csv-perl-0.5300/debian/changelog
--- libdbd-csv-perl-0.5300/debian/changelog 2018-05-22 06:46:21.0
+0200
+++ libdbd-csv-perl-0.5300/debian/changelog 2021-01-14 22:56:01.0
+0100
@@ -1,3 +1,12 @@
+libdbd-csv-perl (0.5300-1+deb10u1) buster; urgency=medium
+
+ * Team upload.
+
+ [ Dominic Hargreaves ]
+ * Fix test failure with libdbi-perl 1.642-1+deb10u2 (Closes: #974134)
+
+ -- Salvatore Bonaccorso Thu, 14 Jan 2021 22:56:01 +0100
+
libdbd-csv-perl (0.5300-1) unstable; urgency=medium
* Import upstream version 0.53
diff -Nru libdbd-csv-perl-0.5300/debian/patches/0001-f_dir-should-exist.patch
libdbd-csv-perl-0.5300/debian/patches/0001-f_dir-should-exist.patch
--- libdbd-csv-perl-0.5300/debian/patches/0001-f_dir-should-exist.patch
1970-01-01 01:00:00.0 +0100
+++ libdbd-csv-perl-0.5300/debian/patches/0001-f_dir-should-exist.patch
2021-01-14 22:56:01.0 +0100
@@ -0,0 +1,38 @@
+From 88c3ca044a3881eab62d6d2d38490351fd421386 Mon Sep 17 00:00:00 2001
+From: "H.Merijn Brand - Tux"
+Date: Wed, 28 Oct 2020 15:56:53 +0100
+Subject: [PATCH] f_dir should exist
+
+From a CVE fix in DBI-1.644 / DBD::File-0.45
+---
+ t/11_dsnlist.t | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/t/11_dsnlist.t b/t/11_dsnlist.t
+index 8370976..3e97d45 100644
+--- a/t/11_dsnlist.t
b/t/11_dsnlist.t
+@@ -24,9 +24,19 @@ ok (@dsn >= 2, "more
than one");
+ ok ($dbh->disconnect, "disconnect");
+
+ # Try different DSN's
+-foreach my $d (qw( . example lib t )) {
++foreach my $d (qw( . examples lib t )) {
+ ok (my $dns = Connect ("dbi:CSV:f_dir=$d"), "use $d as f_dir");
+ ok ($dbh->disconnect, "disconnect");
+ }
+
++if ($DBD::File::VERSION ge "0.45") {
++my @err;
++is (eval {
++ local $SIG{__WARN__} = sub { push @err => @_ };
++ local $SIG{__DIE__} = sub { push @err => @_ };
++ Connect ("dbi:CSV:f_dir=d/non/exist/here");
++ }, undef, "f_dir = nonexting dir");
++like ("@err", qr{d/non/exist/here}, "Error caught");
++}
++
+ done_testing ();
+--
+2.20.1
+
diff -Nru libdbd-csv-perl-0.5300/debian/patches/series
libdbd-csv-perl-0.5300/debian/patches/series
--- libdbd-csv-perl-0.5300/debian/patches/series1970-01-01
01:00:00.0 +0100
+++ libdbd-csv-perl-0.5300/debian/patches/series2021-01-14
22:56:01.0 +0100
@@ -0,0 +1 @@
+0001-f_dir-should-exist.patch
Processed: grub2 2.02+dfsg1-20+deb10u3 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 976094 = buster pending Bug #976094 [release.debian.org] buster-pu: package grub2/2.02+dfsg1-20+deb10u3 Added tag(s) pending; removed tag(s) confirmed and d-i. > thanks Stopping processing here. Please contact me if you need assistance. -- 976094: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976094 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: mini-buildd 1.0.36+deb10u1 flagged for acceptance
Processing commands for cont...@bugs.debian.org: > package release.debian.org Limiting to bugs with field 'package' containing at least one of 'release.debian.org' Limit currently set to 'package':'release.debian.org' > tags 955277 = buster pending Bug #955277 [release.debian.org] buster-pu: package mini-buildd/1.0.36 Added tag(s) pending; removed tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 955277: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955277 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#976094: grub2 2.02+dfsg1-20+deb10u3 flagged for acceptance
package release.debian.org tags 976094 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: grub2 Version: 2.02+dfsg1-20+deb10u3 Explanation: when upgrading grub-pc noninteractively, bail out if grub-install fails; explicitly check whether the target device exists before running grub-install; grub-install: Add backup and restore; don't call grub-install on fresh install of grub-pc
Bug#955277: mini-buildd 1.0.36+deb10u1 flagged for acceptance
package release.debian.org tags 955277 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: mini-buildd Version: 1.0.36+deb10u1 Explanation: builder.py: sbuild call: set '--no-arch-all' explicitly
Bug#973342: libdbi-perl 1.642-1+deb10u2 flagged for acceptance
Hi Paul, On Thu, Jan 14, 2021 at 10:29:06PM +0100, Paul Gevers wrote: > Hi all, > > On Sun, 20 Dec 2020 18:48:21 + Adam D Barratt > wrote: > > The upload referenced by this bug report has been flagged for acceptance > > into the proposed-updates queue for Debian buster. > > The queue overview page [1] shows regressions in the autopkgtest of > libdbd-csv-perl on all architectures. I have the impression that the > test may actually be trying to do what this CVE is closing. Can you confirm? Looks right indeed, and would be the same cause as #974134. So we should address this as well in the point release. Regards, Salvaotre
Bug#973342: libdbi-perl 1.642-1+deb10u2 flagged for acceptance
Hi all, On Sun, 20 Dec 2020 18:48:21 + Adam D Barratt wrote: > The upload referenced by this bug report has been flagged for acceptance into > the proposed-updates queue for Debian buster. The queue overview page [1] shows regressions in the autopkgtest of libdbd-csv-perl on all architectures. I have the impression that the test may actually be trying to do what this CVE is closing. Can you confirm? Paul [1] https://release.debian.org/proposed-updates/stable.html OpenPGP_signature Description: OpenPGP digital signature
Bug#959469: buster-pu: package openssl/1.1.1g-1
On 2021-01-14 19:03:37 [+0100], Kurt Roeckx wrote: > > Do you have pointers to upstream issues? > > There are a whole bunch of other issues and pull requests related to > this. I hope this is the end of the regressions in the X509 code. Okay. Please ping once this gets sorted out and I will prepease unstalbe/stable uploads. The m2crypto issue got resolved in unstable \o/. > Kurt Sebastianc
Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, Jan 14, 2021 at 05:43:00PM +, Adam D. Barratt wrote: > Hi, > > On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote: > > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior > > wrote: > [...] > > > The i release in unstable managed to migrate to testing. It was > > > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue > > > got fixed in unstable (the testuite was updated) and is not an > > > issue in stable (the package builds, the testsuite gets ignored). > > > The m2crypto issue is a different story and is still open in BTS > > > (#977655). I *think* someone added an override or the ci-system was > > > kind to Kurt/me and looked the other way :) > > > The m2crypto package in stable and bpo will FTBFS with the updated > > > openssl package. > > > > > > I'm not aware of other issues. > > > > I think there are at least 2 upstream issues since the 1.1.1i > > release we want to fix first. As far as I know, they haven't been > > fixed upstream yet. > > Just to confirm, these are issues that you'd want to have fixed before > adding 1.1.1i to stable, presumably requiring further uploads to > unstable first? Yes. > Do you have pointers to upstream issues? They both got merged today: commit 76ed0c0ad119569f6e6f6c96b27b76d3b110413b (origin/OpenSSL_1_1_1-stable) Author: Dr. David von Oheimb Date: Mon Dec 28 11:25:59 2020 +0100 x509_vfy.c: Fix a regression in find_isser() ...in case the candidate issuer cert is identical to the target cert. Fixes #13739 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13749) commit fb1e2411042f0367c2560e4ec5e4b1189ca9cd45 Author: Dr. David von Oheimb Date: Wed Dec 30 09:57:49 2020 +0100 X509_cmp(): Fix comparison in case x509v3_cache_extensions() failed to due to invalid cert This is the backport of #13755 to v1.1.1. Fixes #13698 Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/13756) There are a whole bunch of other issues and pull requests related to this. I hope this is the end of the regressions in the X509 code. Kurt
Bug#959469: buster-pu: package openssl/1.1.1g-1
Hi, On Fri, 2021-01-08 at 23:59 +0100, Kurt Roeckx wrote: > On Fri, Jan 08, 2021 at 11:39:13PM +0100, Sebastian Andrzej Siewior > wrote: [...] > > The i release in unstable managed to migrate to testing. It was > > blocked due to ci by m2crypto and swi-prolog. The swi-prolog issue > > got fixed in unstable (the testuite was updated) and is not an > > issue in stable (the package builds, the testsuite gets ignored). > > The m2crypto issue is a different story and is still open in BTS > > (#977655). I *think* someone added an override or the ci-system was > > kind to Kurt/me and looked the other way :) > > The m2crypto package in stable and bpo will FTBFS with the updated > > openssl package. > > > > I'm not aware of other issues. > > I think there are at least 2 upstream issues since the 1.1.1i > release we want to fix first. As far as I know, they haven't been > fixed upstream yet. Just to confirm, these are issues that you'd want to have fixed before adding 1.1.1i to stable, presumably requiring further uploads to unstable first? Do you have pointers to upstream issues? Regards, Adam
Processed: reassign 980088 to release.debian.org
Processing commands for cont...@bugs.debian.org: > reassign 980088 release.debian.org Bug #980088 [release.] britney adds reference link for removed packages Warning: Unknown package 'release.' Bug reassigned from package 'release.' to 'release.debian.org'. Ignoring request to alter found versions of bug #980088 to the same values previously set Ignoring request to alter fixed versions of bug #980088 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 980088: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980088 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#980088: silxs autopkgtest
Package: release. User: release.debian@package.debian.org Severity: minor Usertag: britney Control: retitle -1 britney adds reference link for removed packages Hi Frederic-Emmanuel On 14-01-2021 09:26, PICCA Frederic-Emmanuel wrote: > I try to understand something about autopkgtest and britney migration. Good that you reach out. However, the excuses are generated by the code under the responsibility of the Release Team, hence CC-ing (via the BTS). > If you look here, > > https://tracker.debian.org/pkg/silx > > the autopkgtest on ppc64el says, regression, but If I look here > > https://ci.debian.net/packages/s/silx/testing/ppc64el/ Even more interesting, if you click on the link to the log of the ppc64el reference log you'll find that it ends with command1 FAIL badpkg command2 FAIL badpkg > it failes from the begining, so to my opinion this is not a regression. We consider it a regression if the package is new in testing (it was removed) and the "new" test fails. We declared failing autopkgtests RC-buggy, so with the migration we would *add* an RC buggy package. I agree there is a bug, britney shouldn't show the "reference run" result. > for info this test faild because the pacakge does not build on ppc64el, du to > the pyopencl dependency :). For new tests in source packages that build both arch:all and arch:any packages this situation unfortunately requires either specifying the Architectures in the d/t/control file, or overruling by the Release Team. You *can* add the (recently supported) Architecture field to your package, but Graham already overruled it for now anyways. > Is there something wrong or should I mark the test not for ppc64el ? The latter gives *you* control, so that's good. On the other hand, I can understand it when you don't want to remember to keep that in sync with which archs your package builds on. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#980043: marked as done (transition: superlu-dist)
Your message dated Thu, 14 Jan 2021 21:35:30 +1100 with message-id <3fafd74d13b3687bdb5c4b2c4cea4...@debian.org> and subject line Re: Bug#980043: transition: superlu-dist has caused the Debian Bug report #980043, regarding transition: superlu-dist 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.) -- 980043: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980043 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The latest version of superlu-dist introduces a API/ABI bump (it came in superlu-dist 6.3, but we can pick it up from v6.4) The new package is currently waiting in the NEW queue aimed at experimental. I wanted to file this transition request ahead of time before it's accepted to give you notice that it's coming, since the debian stable freeze will start soon. The new version introduces support for complex numbers as well as real numbers, along with other performance improvements, so would be nice to get it into the forthcoming stable release. I would update hypre from 2.18 to 2.20 at the same time (the API change in superlu-dist means that hypre needs to be upgraded too) I've confirmed that both petsc and sundials build and pass tests with superlu-dist 6.4 and hypre 2.20, and will check again once libsuperlu-dist6.4 is available in experimental. Ben file: title = "superlu-dist"; is_affected = .depends ~ "libsuperlu-dist6" | .depends ~ "libsuperlu-dist6.4"; is_good = .depends ~ "libsuperlu-dist6.4"; is_bad = .depends ~ "libsuperlu-dist6"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- OK, we will have to wait. Since we're waiting for the NEW queue anyway, I'll close this request for now and reissue when the bell tolls. Drew On 2021-01-14 19:59, Sebastian Ramacher wrote: On 2021-01-13 22:24:53, Drew Parsons wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition The latest version of superlu-dist introduces a API/ABI bump (it came in superlu-dist 6.3, but we can pick it up from v6.4) The new package is currently waiting in the NEW queue aimed at experimental. I wanted to file this transition request ahead of time before it's accepted to give you notice that it's coming, since the debian stable freeze will start soon. Sorry, but it's too late for bullseye. The transition freeze was on January 12th (see also [1]). This transition will have to wait until after the release of bullseye. Cheers [1] https://lists.debian.org/debian-devel-announce/2021/01/msg2.html The new version introduces support for complex numbers as well as real numbers, along with other performance improvements, so would be nice to get it into the forthcoming stable release. I would update hypre from 2.18 to 2.20 at the same time (the API change in superlu-dist means that hypre needs to be upgraded too) I've confirmed that both petsc and sundials build and pass tests with superlu-dist 6.4 and hypre 2.20, and will check again once libsuperlu-dist6.4 is available in experimental. Ben file: title = "superlu-dist"; is_affected = .depends ~ "libsuperlu-dist6" | .depends ~ "libsuperlu-dist6.4"; is_good = .depends ~ "libsuperlu-dist6.4"; is_bad = .depends ~ "libsuperlu-dist6"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message ---
Bug#980087: release.debian.org: autopkgtest fails trying to install packages not in arch
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: britney android-platform-art as this in debian/tests/control: https://salsa.debian.org/android-tools-team/android-platform-art/-/blob/master/debian/tests/control Tests: dexdump-dexlist Depends: dexdump, dexlist autopkgtest fails on ppc64el with: https://ci.debian.net/data/autopkgtest/testing/ppc64el/a/android-platform-art/9669069/log.gz E: Unable to locate package dexdump E: Unable to locate package dexlist dexdump and dexlist are part of src:android-platform-art but are not built for ppc64el. britney should automatically know that Depends: dexdump, dexlist cannot be fulfilled on ppc64el and skip the test. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#968894: release.debian.org: binNMUs requests for libxcrypt "transition"
On 2020-08-27 21:53, Aurelien Jarno wrote: > Hi, > > On 2020-08-23 17:06, Sebastian Ramacher wrote: > > On 2020-08-23 13:37:42 +0200, Aurelien Jarno wrote: > > > Package: release.debian.org > > > Severity: normal > > > X-Debbugs-Cc: debian-gl...@lists.debian.org, m...@linux.it > > > > > > Dear release team, > > > > > > Back in December we moved libcrypt.so.1 from the libc6 package to the > > > libcrypt1 package, which is built from the libxcrypt source package. > > > libcrypt will eventually get removed from glibc upstream, this will > > > allow faster development independently from glibc. > > > > > > As the ABI is compatible the "transition" has been transparent, libc6 > > > depending on libcrypt1, and libc6-dev depending on libcrypt-dev. > > > However it would be good to rebuild the affected packages: > > > - They will get a direct dependency on libcrypt1. That would open the > > > possibility to remove the libc6 dependency on libcrypt1 in bookworm. > > > That would also allow to identify the affected packages to remove the > > > libc6-dev dependency on libcrypt-dev, or to handle a possible ABI > > > transition. > > > - They might start using additional functionalities (e.g. hashing > > > algorithms) provided by libcrypt1. > > > > > > Many packages have already been rebuilt against libxcrypt due to source > > > uploads or unrelated binNMUs. We are now down to less than 80 affected > > > packages on amd64, so it's probably acceptable to start binNMUing them. > > > > > > You will find the list below. It has been computed on amd64 only as it's > > > a long operation involving unpacking all the packages in the archive and > > > checking all the binaries they contains. As the change has been > > > introduced at the same time on all architectures, I believe the same > > > binNMUs are need for all of them, and anyway we need to keep them in > > > sync for multiarch libraries. Once we have been able to get all of the > > > packages fixed on amd64, I'll also check the other architectures to see > > > if some of them have been missed. > > [snip] > > > Scheduled binNMUs on all architectures. > > Thanks for scheduling the binNMUs. We are down to the following list in > sid/amd64: A small update of the current status. - In bullseye, only pam_1.3.1-5 is still affected. This has been fixed by a new upload to sid, but the package doesn't migrate due to autopkgtests regressions on armhf and ppc64el. It would be important for bookworm to get this package fixed in bullseye. - In sid the following packages are still affected, they all FTBFS: cernlib_20061220+dfsg3-4.4 (#957080) gadmin-proftpd_1:0.4.2-1 (#957248) gauche_0.9.6-10 (#957256) gauche-c-wrapper_0.6.1-11 (#925691) geant321_1:3.21.14.dfsg-11 (#957263) gridengine_8.1.9+dfsg-9 (#957310) mclibs_20061220+dfsg3-3.1 (#957522) mysql-5.7_5.7.26-1 (#969115) quagga_1.2.4-4 (#957737) yap_6.2.2-6 (#877034) If they are not fixed in a reasonable time, I'll ask ftp-masters for their removal. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#980084: nmu: binNMUs for statically linked binaries built with glibc (<< 2.31)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear release team, Now that (build-)essential is frozen, the glibc package will only see minor changes up to the bullseye release. I therefore think it's the good moment to binNMUs packages with binaries statically linked against older versions of glibc. This will reduce the number of glibc versions shipped in bullseye and gives time ahead of the release to find possible issues that could be introduced by this rebuilds (the autopkgtests can't detect issues due to the statically linkage). Here is a first list of binNMUs for packages built using glibc (<< 2.31): nmu aide_0.16.1-1 . ANY . -m "Rebuild against latest glibc" # currently 2.28-8 nmu cdebootstrap_0.7.7 . ANY . -m "Rebuild against latest glibc" # currently 2.28-10 nmu prelink_0.0.20131005-1.1 . ANY . -m "Rebuild against latest glibc" # currently 2.30-4 nmu sash_3.8-5 . ANY . -m "Rebuild against latest glibc" # currently 2.28-8 nmu tripwire_2.4.3.7-3 . ANY . -m "Rebuild against latest glibc" # currently 2.30-4 nmu zsh_5.8-5 . ANY . -m "Rebuild against latest glibc" # currently 2.30-8 nmu zutils_1.9-1 . ANY . -m "Rebuild against latest glibc" # currently 2.30-8 The are a few other packages not built with the latest glibc, but they are at least built with glibc (>= 2.31-3). I think we can binNMU them later in the release process, as there might be a new glibc upload or they might also get uploaded in the meantime. Regards, Aurelien
Bug#976811: transition: php8.0
Hi Ondřej On 2021-01-12 12:40:22, Ondřej Surý wrote: > I guess we are going to release with PHP 7.4 then. Not the ideal choice, > but I will do whatever I can to support it. > > However, I would like to get an official statement from the release team > what's their position, so we can go forward. Pretty please? > > Also an advice on how to proceed next time this happens. The timing of our > freeze and new PHP release coincidentally goes together. Should I start the > transition with alpha/beta/rc instead of the first final release? The timing is not ideal and there are still quite a bunch of blocking bugs open. Given also list of autopkgtest regressions reported for the php-defaults version in experimental, I'm not even sure if all of them have been reported to the BTS. I'm also CCing the security team for their input in case the have a strong opinion on this transition. To avoid the same situation for the bookworm freeze, I think staging the transition early in experimental with alpha/beta/rc version with the corresponding php-defaults change would make sense. This would help to get most of the FTBFS bugs and autopkgtest regressiones reported and would give the maintainers time to fix them beforehand. Cheers and sorry for not replying earlier. > > > Ondrej > > On Fri, 11 Dec 2020 at 18:01, Ondřej Surý wrote: > > > The main problem is the PHP release schedule: > > https://www.php.net/supported-versions.php > > > > If we release with PHP 7.4, the upstream security support will end sooner > > than security support for Debian bullseye. If we release with PHP 8.0 we > > will have full three years of upstream support. > > > > There’s still month before the transition freeze and we will have time to > > fix the downstream users after the transition is over. > > > > I think the transition is worth the trouble. Having official security > > support is important especially for PHP. > > > > Ondřej > > -- > > Ondřej Surý (He/Him) > > > > On 11. 12. 2020, at 17:38, David Prévot wrote: > > > > Hi Ondřej, > > > > Le Tue, Dec 08, 2020 at 09:28:38AM +0100, Ondřej Surý a écrit : > > > > I would like to transition the PHP to version 8.0; > > > > > > The timing of this request makes me uneasy: php8.0 has been in Debian > > for less than a week, and we are a month away from the transition > > freeze. > > > > it's not such a huge bump as it was with 5.6 -> 7.0 and > > > > > > If I remember correctly, the 7.3 -> 7.4 was not a huge bump either, yet > > php7.4 packages were in Debian months before the actual transition > > happen, and it took months for the updated php-defaults to actually > > migrates into testing. > > > > most of the packages that were compatible with PHP > > > > 7.4 are working just fine with PHP 8.0. > > > > > > That does not match my experience as a maintainer of about a hundred > > packages relying on PHP. Many upstream are currently releasing updates > > to fix compatibility with PHP 8.0, and many more have not yet done so. > > > > I’m actually surprised to discover this request in the BTS without any > > prior communication with teams involved in PHP related packaging. > > > > For example, PHPUnit 8 as currently available in unstable and testing is > > expected to run on PHP 8 (thanks to upstream updates less than two weeks > > ago), yet “Please note that the code coverage functionality is not > > available for PHPUnit 8.5 on PHP 8.” (from upstream changelog 8.5.12). > > So shipping PHPUnit 8 with PHP 8 would mean having a major > > fonctionnality unavailable for the whole Bullseye life cycle. PHPUnit 9 > > is available from experimental, yet uploading to unstable would mean > > having to deal with dozens of breakage (in the FTBFS form): > > > > https://release.debian.org/britney/pseudo-excuses-experimental.html#phpunit > > > > PHPUnit is just one example, but it seems unrealistic to ship version 9 > > with Bullseye (I really abandonned this option months ago). Other > > packages will break (and I suspect the number of breakage will be high). > > > > This kind of disruptive change would hopefully be better suited early in > > the release cycle rather than just before the beginning of the freeze. > > > > That said, it would be nice to have an updated php-default in > > *experimental* to help have a grasp of the possible brekages. > > > > Regards > > > > David > > > > -- Sebastian Ramacher
Bug#976811: transition: php8.0
Hi Ondřej, On 12-01-2021 12:40, Ondřej Surý wrote: > I guess we are going to release with PHP 7.4 then. Not the ideal > choice, but I will do whatever I can to support it. That's correct. > However, I would like to get an official statement from the release team > what's their position, so we can go forward. Pretty please? The transition freeze has started, so we'll not transition to php8.0 in bullseye. > Also an advice on how to proceed next time this happens. The timing of > our freeze and new PHP release coincidentally goes together. Should I > start the transition with alpha/beta/rc instead of the first final release? For next time I advice: 1) Most importantly: communicate your plans earlier to the Release Team (and relevant other Teams; the fact that you surprised an active PHP maintainer wasn't a good sign to us). 2) Working with alpha/beta/rc can start early in experimental, especially as, like in this case, there is considerable fall out. The fall out needs to be identified (with rebuilds and autopkgtests (see 3) and should ideally be fixed before the transition start, but at least bugs need to be filed, ideally with patches or update instructions. Experimental is meant for this. In the end, it's your call as a maintainer if you request to start the transition already with alpha, beta or rc releases. 3) Adding a new php version to experimental apparently only really shows it's fall out if also php-defaults is updated, I recommend to do that early too, as the experimental pseudo excuses will also tell you how autopkgtests are faring with that change, which is extremely useful. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#980043: transition: superlu-dist
On 2021-01-13 22:24:53, Drew Parsons wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > The latest version of superlu-dist introduces a API/ABI bump (it came > in superlu-dist 6.3, but we can pick it up from v6.4) > > The new package is currently waiting in the NEW queue aimed at > experimental. I wanted to file this transition request ahead of time > before it's accepted to give you notice that it's coming, since the > debian stable freeze will start soon. Sorry, but it's too late for bullseye. The transition freeze was on January 12th (see also [1]). This transition will have to wait until after the release of bullseye. Cheers [1] https://lists.debian.org/debian-devel-announce/2021/01/msg2.html > > The new version introduces support for complex numbers as well as real > numbers, along with other performance improvements, so would be nice > to get it into the forthcoming stable release. > > I would update hypre from 2.18 to 2.20 at the same time (the API > change in superlu-dist means that hypre needs to be upgraded too) > > I've confirmed that both petsc and sundials build and pass tests with > superlu-dist 6.4 and hypre 2.20, and will check again once > libsuperlu-dist6.4 is available in experimental. > > Ben file: > > title = "superlu-dist"; > is_affected = .depends ~ "libsuperlu-dist6" | .depends ~ "libsuperlu-dist6.4"; > is_good = .depends ~ "libsuperlu-dist6.4"; > is_bad = .depends ~ "libsuperlu-dist6"; > > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), > LANGUAGE=en_AU:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Sebastian Ramacher
