Bug#1002627: marked as done (transition: alglib)
Your message dated Wed, 5 Jan 2022 23:12:46 +0100 with message-id and subject line Re: Bug#1002627: transition: alglib has caused the Debian Bug report #1002627, regarding transition: alglib 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.) -- 1002627: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002627 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 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear release team, please provide a slot for the transition of alglib. All reverse-dependencies are checked and not FTBFS are detected. So the tranition should be short and easy. Thanks, Anton Ben file: title = "alglib"; is_affected = .depends ~ "libalglib3.17" | .depends ~ "libalglib3.18"; is_good = .depends ~ "libalglib3.18"; is_bad = .depends ~ "libalglib3.17"; -BEGIN PGP SIGNATURE- iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmHHknARHGdsYWRrQGRl Ymlhbi5vcmcACgkQ0+Fzg8+n/wb+Eg//VXgqo+MEfluKITlUQyu3bjJ0WP8rbRDb Bf/0/cHAxjvhowRUI4h9KlyVfhkfDrXQ1+a7p4+M37XFj6uMxpvKrRBUJbfpjwge D3ydsaS636bjcxhPL6Bf2UXLtAidQ4jWJgNjzgGevxyoTUeKvQX8CqrbYBi7HcxS zr8JmfaJwwClRXgzhO34mWt5MxdhxlthjNMI17jrrkVxN8SbKYv7eablO3Nre4Mi SDv16/Gd0T8ldOn41EfNz9F0Sm66XxNlNj7kCRP7c0EDtR/IBJ28NoaBh6jaoU/1 vGvhfsqXaO2XFXcgB4OW/wu3+ioL/Xv6rz88Ec44nEm5Tlbfv2gGfaKD7P2QBa0K K5WdJOPrZTRfgimr02SS+tXdCZb/d+ucH44tvTgWxWiRFFIrKy+WRQsidYHZpfdP F0CpRmDcydtr7fxxxz/yQFoUmDaB4wNF/wGOc1nhyH0PupaLEgDekbNuwzqlMu7K TA/fj+6D5ws4FBxwauVEpWV2Qb8gwJByFXTaDt7vzEhlsDIwgjHP+TVdERyPhYE2 nhs/Hs+RUsYACEjqOk7HXGE+uIrsG05iD8yxFsgGsRdCssESWov5TBJwwm2Vlqq2 JOa/0Vv8iagsarO+neTiKhtRWW1LHqkmVye5uo9wTevj1Ws80aHETAWJqODOSfzU BBTMi+957/A= =yKYi -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On 2021-12-30 21:22:56 +0100, Sebastian Ramacher wrote: > Control: tags -1 confirmed > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-alglib.html > > On 2021-12-25 22:51:46 +0100, Anton Gladky wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > > > Dear release team, > > > > please provide a slot for the transition of alglib. > > All reverse-dependencies are checked and not FTBFS are detected. > > So the tranition should be short and easy. > > Please go ahead libalglib3.17 got removed from testing. Cheers > > Cheers > > > > > Thanks, > > > > Anton > > > > > > Ben file: > > > > title = "alglib"; > > is_affected = .depends ~ "libalglib3.17" | .depends ~ "libalglib3.18"; > > is_good = .depends ~ "libalglib3.18"; > > is_bad = .depends ~ "libalglib3.17"; > > > > > > -- > Sebastian Ramacher -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Bug#1003188: bullseye-pu: package mmdebstrap/0.7.5-2.2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jo...@debian.org
[ Reason ]
Currently, when a user happens to have an ASCII armored key in
/etc/apt/trusted.gpg.d, running mmdebstrap without any special options
will not work. See #1003175 for details.
The problem is fixed in unstable and testing, starting with 0.8.0-1.
[ Impact ]
Users will either have to remove an ASCII armored key from their
/etc/apt/trusted.gpg.d or supply keys to mmdebstrap manually. But either
is unlikely to happen because the error message does not give a clue
about the actual cause of the problem.
[ Tests ]
Me and two users checked that the attached debdiff fixed the
problem. If desired, I can also add a test from the upstream project
to the debdiff but that would double its size. Essentially, the change
is already well tested upstream.
[ Risks ]
In the worst case, GPG key autodetection breaks and one has to pass the
keyring material to mmdebstrap manually. This is what users with ASCII
armored keys in /etc/apt/trusted.gpg.d already have to do today without
this patch.
[ 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 ]
GPG is called with --show-keys instead of with --list-keys. The latter
requires "public keyring v4" key material while the former also allows
ASCII armored keys.
[ Other info ]
This is my first upload to a stable release, so stupid mistakes can be
hiding anywhere.
Thanks!
cheers, josch
diff -Nru mmdebstrap-0.7.5/debian/changelog mmdebstrap-0.7.5/debian/changelog
--- mmdebstrap-0.7.5/debian/changelog 2021-05-07 17:30:39.0 +0200
+++ mmdebstrap-0.7.5/debian/changelog 2022-01-05 16:05:13.0 +0100
@@ -1,3 +1,10 @@
+mmdebstrap (0.7.5-2.2+deb11u1) bullseye; urgency=medium
+
+ * Do not error out with ASCII armored keyrings in /etc/apt/trusted.gpg.d
+(closes: #1003175)
+
+ -- Johannes Schauer Marin Rodrigues Wed, 05 Jan 2022
16:05:13 +0100
+
mmdebstrap (0.7.5-2.2) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
---
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
1970-01-01 01:00:00.0 +0100
+++
mmdebstrap-0.7.5/debian/patches/0001-Do-not-use-gpg-trust-model-always.patch
2022-01-05 16:04:09.0 +0100
@@ -0,0 +1,23 @@
+From 91d8be5f9c204f0ee8d524eb1382934e608a9d43 Mon Sep 17 00:00:00 2001
+From: Johannes Schauer Marin Rodrigues
+Date: Thu, 26 Aug 2021 07:58:27 +0200
+Subject: [PATCH] Do not use gpg --trust-model=always
+
+ - gpg will not create a trustdb when running with --update-trustdb with
+ --trust-model=always:
+ gpg: no need for a trustdb update with 'always' trust model
+ - subsequent gpg calls will fail because there is no trustdb in GPGHOME
+---
+ mmdebstrap | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/mmdebstrap
b/mmdebstrap
+@@ -4861,7 +4861,6 @@ sub main() {
+ '--ignore-time-conflict', '--no-options',
+ '--no-default-keyring', '--homedir',
+ $gpghome, '--no-auto-check-trustdb',
+-'--trust-model', 'always'
+ );
+ my ($ret, $message);
+ {
diff -Nru
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
---
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
1970-01-01 01:00:00.0 +0100
+++
mmdebstrap-0.7.5/debian/patches/0001-gpg-handle-ASCII-armored-keyrings-as-well.patch
2022-01-05 16:05:13.0 +0100
@@ -0,0 +1,75 @@
+From ccd4b5c163d322045c92f734f43bb5e1945fa774 Mon Sep 17 00:00:00 2001
+From: Konstantin Demin
+Date: Thu, 15 Apr 2021 03:00:39 +0300
+Subject: [PATCH] gpg: handle ASCII-armored keyrings as well
+
+gpg command "--list-keys" requires input files to be passed with
+option "--keyring" and each file must match type "public keyring v4"
+while gpg command "--show-keys" doesn't require extra options and
+handles also ASCII-armored public keyrings as well.
+
+Signed-off-by: Konstantin Demin
+---
+ mmdebstrap | 28 +---
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/mmdebstrap
b/mmdebstrap
+@@ -4880,30 +4880,37 @@ sub main() {
+ . " signed-by value";
+ last;
+ }
++# initialize gpg trustdb with empty one
++{
++`@gpgcmd --update-trustdb >/dev/null 2>/dev/null`;
++$? ==
Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))
On Sun, 2021-12-19 at 18:47 +, Adam D. Barratt wrote: [...] > How does this sound as text for an SUA? > > " > http-parser is a parser for HTTP messages, designed to be used in > high > performance HTTP applications. > > The update to http-parser included in the 10.10 point release > introduced > a regression affecting dependent applications. This update resolves > that > regression. > > If you use http-parser, we strongly recommend that you install this > update. > " Quick post-holidays ping on the above. Regards, Adam
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On 1/5/22 13:14, Mattia Rizzolo wrote: On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote: I suppose I'll see how it goes in the coming few days. So it's not crashing but it's being unbearably slow in gmail, to the point that I just wasn't able to type a mail there, while throwing one CPU core to 100%. Also it was kind go generally slow in several other sites, compared to v93. Always compared to v93, it takes far longer (and by far much much more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open all the time, trusting the browser to reopen them where I left when I close it). I didn't mesure anything and I don't have any numbers to share, but that's what I see. At least, it looks like it has not been leaking as much memory as v93 was (that in this regard was buggier than v90). I've been testing on x11 (under xfce). Are you using wayland, by chance?
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Wed, Jan 05, 2022 at 01:52:33PM +0100, Mattia Rizzolo wrote: > I suppose I'll see how it goes in the coming few days. So it's not crashing but it's being unbearably slow in gmail, to the point that I just wasn't able to type a mail there, while throwing one CPU core to 100%. Also it was kind go generally slow in several other sites, compared to v93. Always compared to v93, it takes far longer (and by far much much more CPU) to reopen the whole session (I keep ~50 tabs in 3 windows open all the time, trusting the browser to reopen them where I left when I close it). I didn't mesure anything and I don't have any numbers to share, but that's what I see. At least, it looks like it has not been leaking as much memory as v93 was (that in this regard was buggier than v90). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Processed: transition: perl 5.34
Processing control commands: > block -1 with 1002093 997267 997189 Bug #1003176 [release.debian.org] transition: perl 5.34 1003176 was not blocked by any bugs. 1003176 was not blocking any bugs. Added blocking bug(s) of 1003176: 1002093, 997189, and 997267 -- 1003176: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003176 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1003176: transition: perl 5.34
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-p...@lists.debian.org, p...@packages.debian.org Control: block -1 with 1002093 997267 997189 Hi, we'd like a transition slot for Perl 5.34. Should have done this months ago, but real life has interfered. Sorry about that. Perl 5.36 is scheluded for May or so, and I expect that will be our target for bookworm. Nevertheless, it's probably best to do this incrementally and have a 5.34 transition now in case 5.36 turns out to be difficult for some reason. The changes in 5.34 are quite small, as upstream spent most of that release cycle planning Perl 7 (which did not quite work out.) This reflects in the very low number regressions we found in our test rebuilds, visible at https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.34-transition;users=debian-p...@lists.debian.org with just one bug open (openscap, not in testing). I did a full archive test rebuild back in May, and partial test rebuilds in August. Coming back to this now, I've done another round of test rebuilds for those packages that will need binNMUs. I don't think another full round is necessary: it seems unlikely that the other packages might have introduced any Perl 5.34 related regressions in the meantime. There's a few packages that have unrelated build failures in current sid. I'm marking the ones in testing as blockers for this. Not sure if this Ben file is correct but hope it helps a bit: title = "perl"; is_affected = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ "libperl5.32|perlapi-5.32"; is_good = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ "libperl5.34|perlapi-5.34"; is_bad = .depends ~ "libperl5.32|perlapi-5.32" | .pre-depends ~ "libperl5.32|perlapi-5.32"; Thanks for your work, -- Niko Tyni nt...@debian.org
Bug#1003173: bullseye-pu: package nvidia-cuda-toolkit/11.2.2-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, I'd like to update nvidia-cuda-toolkit in bullseye/non-free in order to disable the non-functional python3 support in cuda-gdb. This causes segmentation faults if libpython2.7.so.1 is available on the system, due to dlopening that library even if we built cuda-gdb against python3.x. (python3 support in cuda-gdb became functional and was re-enabled in 11.4, it does not look fixable in 11.2 due to incomplete python3 support) I'll take this opportunity to also update the bundled openjdk-8 snapshot to the version currently in unstable, probably fixing a ton of CVEs. Upstream treats the cuda toolkit as a bundle of several individually versioned components, unfortunately the versions are not always monotonic... In order to detect (and workaround) the versioning errors at buildtime (and not by ftp-master rejecting the binary packages), I've automated that in debian/rules. That change may look big, but to show that it does not affect the resulting binary packages I'm also attaching a binary debdiff against a rebuild of 11.2.2-3 as 11.2.2-3+deb11u1 with no further changes than the version bump. Andreas nct-11.2.2-3+deb11u1.diff.xz Description: application/xz nvidia-cuda-toolkit_11.2.2-3+deb11u1_amd64.changes.bindiff.xz Description: application/xz
Processed: Re: Bug#1003085: small transition: libportal 0.5
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-libportal.html Bug #1003085 [release.debian.org] small transition: libportal 0.5 Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-libportal.html'. -- 1003085: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003085 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1003085: small transition: libportal 0.5
Control: forwarded -1 https://release.debian.org/transitions/html/auto-libportal.html On Tue, 04 Jan 2022 at 11:12:54 +0100, Emilio Pozuelo Monfort wrote: > > I'd like to upgrade libportal from 0.4 (currently in testing) to 0.5 > > (in experimental). > > Go ahead. libportal and gnome-builder uploaded to unstable and built on release architectures. Please binNMU xdg-desktop-portal when convenient, I think this might be correct: nmu xdg-desktop-portal_1.12.1-1 . ANY . -m 'Rebuild with libportal 0.5 (#1003085)' Thanks, smcv
Processed: Re: Bug#1003004: transition: capnproto
Processing control commands: > tags -1 confirmed Bug #1003004 [release.debian.org] transition: capnproto Added tag(s) confirmed. > forwarded -1 https://release.debian.org/transitions/html/auto-capnproto.html Bug #1003004 [release.debian.org] transition: capnproto Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/auto-capnproto.html'. -- 1003004: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003004 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1003004: transition: capnproto
Control: tags -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-capnproto.html On 2022-01-02 08:42:45 -0800, tony mancill wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi Release Team, > > capnproto 0.8.0 has been in experimental for over a year now [1], so > there is already an auto-transition page [2]. > > All of the reverse dependencies *except* for clickhouse should smoothly. > clickhouse [3] is FTBFS against 0.8.0, but the package has already been > removed from testing due to FTBFS against gcc 11 [4]. Given that > clickhouse isn't receiving much attention and we have received requests > to update captnproto, we would like to proceed with the transition. Please go ahead Cheers > > Thank you, > tony > > [1] https://tracker.debian.org/pkg/capnproto > [2] https://release.debian.org/transitions/html/auto-capnproto.html > [3] https://tracker.debian.org/pkg/clickhouse > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996130 > > Ben file: > > title = "capnproto"; > is_affected = .depends ~ "libcapnp-0.7.0" | .depends ~ "libcapnp-0.8.0"; > is_good = .depends ~ "libcapnp-0.8.0"; > is_bad = .depends ~ "libcapnp-0.7.0"; -- Sebastian Ramacher signature.asc Description: PGP signature
Re: chromium: Update to version 94.0.4606.61 (security-fixes)
On Tue, Jan 04, 2022 at 06:46:46PM -0500, Andres Salomon wrote: > On 1/4/22 15:15, Mattia Rizzolo wrote: > > On Tue, Jan 04, 2022 at 02:50:20PM -0500, Andres Salomon wrote: > > > I pushed a commit to the skip-a11y-checks branch, please give that a try. > > > I > > > need to take a look at other distributions that are shipping chromium to > > > see > > > if they're just disabling DCHECKs outright, or what. > > Just took a look at fedora, arch, and ungoogle-chromium debian packaging. > They're all setting is_official_build=true, which completely disables those > DCHECKs. We should probably set it like that as well, although the > dcheck_is_configurable=true thing that I added to the skip-a11y-checks > branch should at least allow the DCHECKs to not be fatal - so there's no > need to restart your build. So, this one at least didn't crash on me as soon as I started. Also, it looks like the saved passwords that went away came back, so I reckon perhaps the local storage format changed in the upgrade, so v93 wasn't able to see them anymore, or something similar. I suppose I'll see how it goes in the coming few days. Thank you for your work! -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
