Bug#1036884: Schedule
On 2/7/24 08:10, Mattias Ellert wrote: Personally I think it would have made more sense to file these bugs with minor or normal severity (since they are simply informational at this stage) and then upgrade them to serious when the transition starts (at which point they become RC). I'd downgrade the severity to important like we do for FTBFS bugreports of rdeps involved in not yet started transitions. Once the transition starts with the upload of dpkg to unstable the severity should be raised to serious. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1036884: Schedule
Hi! The earliest of the RC bugs filed for this transition have now been unresolved long enough to trigger AUTORM threats. This is unfortunate, since the maintainers can't do anything to fix them, since they are un-fixable until the required changes to the default compiler flags are implemented. In order for threats of removal not to trigger maintainers to blindly applying the proposed patches and uploading to unstable to close the bugs, you should either start the transition now or downgrade the severity of the bugs. Personally I think it would have made more sense to file these bugs with minor or normal severity (since they are simply informational at this stage) and then upgrade them to serious when the transition starts (at which point they become RC). Do you have an estimate when the uploads to unstable will start? Mattias signature.asc Description: This is a digitally signed message part
Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
On Tue, Feb 06, 2024 at 06:01:43PM +, Jonathan Wiltshire wrote: > On Tue, Jul 25, 2023 at 10:19:50PM +0100, Jonathan Wiltshire wrote: > > Control: tag -1 moreinfo > > > > On Mon, Dec 05, 2022 at 11:22:51PM -0800, tony mancill wrote: > > > As the upstream author notes in [3], the issue is present in inlined > > > code, thus applications built against capnproto must be rebuilt against > > > the patched version. > > > > This doesn't immediately make any of us enthusiastic, it has to be said... > > Can we get the proposed debdiff at least please? > > > > The hazards are: > > - ftbfs in the rdeps in stable > > - much reduced testing of proposed-updates vs. for example sid/testing > > > > > The issue for unstable and bookworm is being addressed via an > > > upload to experimental [4] and a subsequent transition [5]. Easy > > > enough... > > > > > > For stable (and old-stable), we need to introduce 0.7.1, a new upstream > > > version that generates a (new) libcapnp-0.7.1 binary package to address > > > the vulnerability. Once those are present in the archive, we can > > > trigger rebuilds of the reverse dependencies. At this time I am asking > > > for bullseye. > > > > > > [ Reason ] > > > This is to address CVE-2022-46149 [1]. > > > > > > [ Impact ] > > > Packages built with capnproto in bullseye will remain potentially > > > vulnerable to the CVE. > > > > > > [ Tests ] > > > I have built the package in a clean bullseye chroot and then used ratt to > > > rebuilt the (8) bullseye r-deps: > > > > > > - clickhouse_18.16.1+ds-7.2 > > > - harvest-tools_1.3-6 > > > - laminar_1.0-3 > > > - librime_1.6.1+dfsg1-1 > > > - mash_2.2.2+dfsg-2 > > > - mir_1.8.0+dfsg1-18 > > > - rr_5.4.0-2 > > > - sonic-visualiser_4.2-1 > > > > laminar in particular doesn't seem to have much maintainer attention. If > > there are problems with the rdeps on rebuild are you going to be in a > > position to resolve them? That's a fair question and I don't have a ready answer other than it depends on how much attention is needed. I am a member of the backports ACL now (I wasn't when this was filed), so I can help with uploads, but I don't have a history with the r-deps. > > > [ Risks ] > > > The upstream author has stated that there are no known vulnerable > > > applications, yet advises that all capnproto users rebuild their > > > applications using patched versions of capnproto. > > > > An abundance of caution? Otherwise the statements seem at odds with each > > other. Agreed. I don't have a strong sense for the security risk to end users. > > > If this is not amenable to stable-proposed-updates, would you recommend > > > backports? > > > > I'm not sure a transition in backports is going to be well received either. > > Let's start with the debdiff and at least know what we're looking at. > > Ping? Thank you for the gentle reminder. I parsed the "not well received" comment and somehow skimmed past the request for the debdiff, got busy, etc... The full debdiff is attached, but it's mostly comprised of non-functional build system and autoconf drift. A pared-down diff with only the packaging and true (semantic) upstream changes is attached as well. Thank you, tony diff -Nru capnproto-0.7.0/aclocal.m4 capnproto-0.7.1/aclocal.m4 --- capnproto-0.7.0/aclocal.m4 2018-08-28 18:13:57.0 -0700 +++ capnproto-0.7.1/aclocal.m4 2022-11-29 07:55:16.0 -0800 @@ -1,6 +1,6 @@ -# generated automatically by aclocal 1.16.1 -*- Autoconf -*- +# generated automatically by aclocal 1.16.3 -*- Autoconf -*- -# Copyright (C) 1996-2018 Free Software Foundation, Inc. +# Copyright (C) 1996-2020 Free Software Foundation, Inc. # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -20,7 +20,7 @@ If you have problems, you may need to regenerate the build system entirely. To do so, use the procedure documented by the package, typically 'autoreconf'.])]) -# Copyright (C) 2002-2018 Free Software Foundation, Inc. +# Copyright (C) 2002-2020 Free Software Foundation, Inc. # # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, @@ -35,7 +35,7 @@ [am__api_version='1.16' dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to dnl require some minimum version. Point them to the right macro. -m4_if([$1], [1.16.1], [], +m4_if([$1], [1.16.3], [], [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl ]) @@ -51,14 +51,14 @@ # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced. # This function is AC_REQUIREd by AM_INIT_AUTOMAKE. AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION], -[AM_AUTOMAKE_VERSION([1.16.1])dnl +[AM_AUTOMAKE_VERSION([1.16.3])dnl m4_ifndef([AC_AUTOCONF_VERSION], [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))]) # AM_AUX_DIR_EXPAND
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_mips64el-buildd.changes ACCEPT Processing changes file: qemu_7.2+dfsg-7+deb12u5_mipsel-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_arm64-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_s390x-buildd.changes ACCEPT
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Control: tags -1 bookworm-backports signature.asc Description: This is a digitally signed message part
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_amd64-buildd.changes ACCEPT
Processed: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Processing control commands: > affects -1 + src:golang-github-go-jose-go-jose Bug #1063371 [release.debian.org] nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp Added indication that 1063371 affects src:golang-github-go-jose-go-jose > affects -1 + src:golang-github-tinylib-msgp Bug #1063371 [release.debian.org] nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp Added indication that 1063371 affects src:golang-github-tinylib-msgp -- 1063371: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063371 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1063371: nmu: golang-github-go-jose-go-jose, golang-github-tinylib-msgp
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Tags: bookworm-backports Control: affects -1 + src:golang-github-go-jose-go-jose Control: affects -1 + src:golang-github-tinylib-msgp nmu golang-github-go-jose-go-jose_3.0.1-2~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" nmu golang-github-tinylib-msgp_1.1.9-1~bpo12+1 . amd64 . bookworm-backports . -m "Build on buildd" I would like for the amd64 builds to happen on official buildds, rather than relying on my amd64 upload as part of processing through BACKPORTS-NEW. I'm not sure when the next update in unstable to either package will be, so I'd like to schedule a binNMU. Thanks, Mathias signature.asc Description: This is a digitally signed message part
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_i386-buildd.changes ACCEPT Processing changes file: qemu_7.2+dfsg-7+deb12u5_ppc64el-buildd.changes ACCEPT
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_all-buildd.changes ACCEPT Processing changes file: qemu_7.2+dfsg-7+deb12u5_armel-buildd.changes ACCEPT Processing changes file: qemu_7.2+dfsg-7+deb12u5_armhf-buildd.changes ACCEPT
Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)
Hi Jonathan, On Tue, Nov 14, 2023 at 11:26:54PM +0100, Bernhard Schmidt wrote: [ Reason ] openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN data channel offload). There is one annoying bug tracked as Bug#1055809 where on heavily loaded TCP servers a refcount issue might occur and the module will become unusable. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Sorry, my bad, I'm getting old. I'm still interested. Considering the version in unstable is currently 0.0+git20231103-1 should the upload be versioned 0.0+git20231103-0+deb12u1 (like originally proposed) or 0.0+git20231103-1~deb12u1 ? Bernhard
NEW changes in stable-new
Processing changes file: qemu_7.2+dfsg-7+deb12u5_source.changes ACCEPT
Processed: tagging 1057107
Processing commands for cont...@bugs.debian.org: > # info was provided AFAICS > tags 1057107 - moreinfo Bug #1057107 [release.debian.org] bullseye-pu: package libssh2/1.9.0-2 Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 1057107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057107 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Hi Nicolas, On Tue, Feb 06, 2024 at 01:46:04PM -0500, Nicolas Mora wrote: > Control: tag - moreinfo > > Thanks, > > Sorry, it seems that I'm not very well aware of the BTS process, according > to [1] this is how I should untag the bug. > > [1] https://www.debian.org/Bugs/server-control If you provide the moreinfo which was requested, then you can remove the tag as follows (or with an equivalent control command, e.g. using -1 for the bug if directly interacting with the bug). tags 1057107 - moreinfo Hope this helps, too bad we missed for this upload the 11.9. Regards, Salvatore
Processed: qemu 7.2+dfsg-7+deb12u5 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 1062044 = bookworm pending Bug #1062044 [release.debian.org] bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u4 Ignoring request to alter tags of bug #1062044 to the same tags previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 1062044: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062044 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1062044: qemu 7.2+dfsg-7+deb12u5 flagged for acceptance
package release.debian.org tags 1062044 = bookworm pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm. Thanks for your contribution! Upload details == Package: qemu Version: 7.2+dfsg-7+deb12u5 Explanation: revert patch causing regressions in suspend / resume functionality
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Control: tag +1 moreinfo Thanks,
Processed: Re: Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Processing control commands: > tag -1 moreinfo Bug #1057107 [release.debian.org] bullseye-pu: package libssh2/1.9.0-2 Ignoring request to alter tags of bug #1057107 to the same tags previously set -- 1057107: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057107 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Control: tag -1 moreinfo Thanks,
Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1
On Tue, 6 Feb 2024 at 18:13, Jonathan Wiltshire wrote: > > Hi, > > On Fri, Sep 08, 2023 at 01:32:05PM +0200, Frode Nordahl wrote: > > We would like to upload the latest stable point release of ovn 23.03 > > to bookworm-p-u. Stable release branches are maintained upstream with > > the intention of providing bug fixes only and no compatibility > > breakages, and with automated non-trivial CI jobs that also cover > > Debian and Ubuntu. > > > > Debdiff attached. Packaging updated with gbp/salsa config for new > > bookworm stable branch and in-flight patches to fix an issue with > > unnecessary logging breaking one of the tests introduced in the point > > release. > > This request was approved but not uploaded in time for the previous point > release (12.5). Should it be included in 12.6, or should this request be > abandoned and closed? Sorry, I missed that this was already approved and I was waiting for a go-ahead. I have done the upload just now.
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Control: tag - moreinfo Thanks, Sorry, it seems that I'm not very well aware of the BTS process, according to [1] this is how I should untag the bug. [1] https://www.debian.org/Bugs/server-control
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:55, Adam D. Barratt : On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote: .. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +- -- This is the relevant bit for size IMO. If you're happy with the result then please upload as soon as you're ready. Yes, I'm happy with the result. Well, - as much as one can be happy here, choosing between one bug or another, - but it is at least a status-quo and we don't have known regressions in debian stable due to this. I just re-ran upstream testsuite just to be extra sure, and am running my bunch of guests as well, everything works as expected so far. I wont try to reproduce the issues this patch (which I'm reverting) fixed, though ;) Uploaded +deb12u5 now, waiting to be picked up. Thank you for the patience and all the work! /mjt
Bug#1043412: bookworm-pu: package quicktext/5.6
Hi, On Sun, Aug 27, 2023 at 02:37:30PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Thu, Aug 10, 2023 at 04:13:22PM +0200, Mechtilde Stehmann wrote: > > This package is an extension to thunderbird. After thunderbird > > will be updated to version 115.* in bookwork > > it is necessary to update this extension too. > > Thunderbird is not 115 in bookworm at present, and I'm not aware of > currently plans for that to change. Have I missed something? I guess it is now; do you still intend to update this package in bookworm to suit? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)
Hi, On Tue, Nov 14, 2023 at 11:26:54PM +0100, Bernhard Schmidt wrote: > [ Reason ] > openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN > data channel offload). There is one annoying bug tracked as Bug#1055809 where > on > heavily loaded TCP servers a refcount issue might occur and the module will > become unusable. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1051466: bookworm-pu: package ovn/23.03.1-1~deb12u1
Hi, On Fri, Sep 08, 2023 at 01:32:05PM +0200, Frode Nordahl wrote: > We would like to upload the latest stable point release of ovn 23.03 > to bookworm-p-u. Stable release branches are maintained upstream with > the intention of providing bug fixes only and no compatibility > breakages, and with automated non-trivial CI jobs that also cover > Debian and Ubuntu. > > Debdiff attached. Packaging updated with gbp/salsa config for new > bookworm stable branch and in-flight patches to fix an issue with > unnecessary logging breaking one of the tests introduced in the point > release. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1049988: bookworm-pu: package riemann-c-client/1.10.4-2
Hi, On Thu, Aug 17, 2023 at 01:01:01PM -1000, Romain Tartière wrote: > [ Reason ] > Due to improper return value checks, when communicating with a remote > server over TLS riemann-c-client sometimes send the same data fragment > multiple times, resulting in the server receiving a malformed payload. > > This happen with all versions of TLS, but TLS 1.3 trigger this bad > behaviour more often. With more and more services using TLS 1.3, this > problem is more and more prevalent. > > [ Impact ] > When the client send a large payload over TLS faster than the network > can send it, the improper return value checks cause portions of that > data to be send multiple times to the server. When the transfer > eventually finish, the server detect that the payload is invalid and > drop the connection. The client will then reconnect and retry the > transfer that might fail again and again. > > Beside error messages in the server logs, these data corrupt data > transfer cause an unexpectedly hight bandwidth usage. This request was approved but not uploaded in time for the previous point release (12.5). Should it be included in 12.6, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: closing 1021176
Processing commands for cont...@bugs.debian.org: > close 1021176 Bug #1021176 [release.debian.org] bullseye-pu: package openvswitch/2.15.0+ds1-2+deb11u1 Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1021176: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021176 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060774: bullseye-pu: netatalk/3.1.12~ds-8+deb11u2
Hi, On Tue, Jan 16, 2024 at 08:30:52AM +, Daniel Markstedt wrote: > 2024年1月16日 (火) 02:53, Adam D. Barratt > <[a...@adam-barratt.org.uk](mailto:2024年1月16日 (火) 02:53, Adam D. Barratt < href=)> 送信: > > > Control: tags -1 + moreinfo > > > > On Sun, 2024-01-14 at 06:23 +, Daniel Markstedt wrote: > >> CVE-2022-22995 > >> Ref. advisory: https://netatalk.sourceforge.io/CVE-2022-22995.php > >> > >> The attached patch can be applied to Debian oldstable to address the > >> vulnerability. > >> > > > > In order to approve an upload, we need to see a full source debdiff of > > the proposed new package, not just the isolated patch. Please remove > > the moreinfo tag when providing that. > > Adam, thanks for following up on this request. > I will work on a debdiff when I’m back home this coming weekend. > Right now I’m working offsite without access to a personal computer. Ping? It's now too late for 11.9 but your request can be considered for 11.10 if you send a debdiff. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: closing 1035310
Processing commands for cont...@bugs.debian.org: > close 1035310 Bug #1035310 [release.debian.org] bullseye-pu: package xz-utils/5.2.11-0~deb11u1 Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1035310: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035310 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1057107: bullseye-pu: package libssh2/1.9.0-2
Hi, On Tue, Dec 19, 2023 at 07:52:02PM -0500, Nicolas Mora wrote: > Hello, > > Thank you for the feedback, the new attached debdiff should fix these. Sorry, your message was not seen in time for 11.9 because the request is still tagged moreinfo. It will be considered for 11.10. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1057084: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.248.02-4~deb11u1
Hi, On Wed, Nov 29, 2023 at 02:38:08PM +0100, Andreas Beckmann wrote: > [ Reason ] > The Tesla 450 driver series has reached End of Life. I'd like to turn it > into transitional packages to ease switching to the Tesla 470 driver > series. We did the same with the Tesla 460 series after that reached EoL > last year. The 470 series supports a superset of GPUs, so this switch is > not a regression in terms of supported devices or features. This request was approved but not uploaded in time for the previous point release (11.9). Should it be included in 11.10, or should this request be abandoned and closed? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1049982: bullseye-pu: package riemann-c-client/1.10.4-2+b2
Hi, On Thu, Aug 17, 2023 at 10:17:48AM -1000, Romain Tartière wrote: > [ Reason ] > Due to improper return value checks, when communicating with a remote > server over TLS riemann-c-client sometimes send the same data fragment > multiple times, resulting in the server receiving a malformed payload. > > This happen with all versions of TLS, but TLS 1.3 trigger this bad > behaviour more often. With more and more services using TLS 1.3, this > problem is more and more prevalent. > > > [ Impact ] > When the client send a large payload over TLS faster than the network > can send it, the improper return value checks cause portions of that > data to be send multiple times to the server. When the transfer > eventually finish, the server detect that the payload is invalid and > drop the connection. The client will then reconnect and retry the > transfer that might fail again and again. > > Beside error messages in the server logs, these data corrupt data > transfer cause an unexpectedly hight bandwidth usage. This request was approved but not uploaded in time for the previous point releases (11.8 and 11.9). Should it be included in 11.10, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1025518: bullseye-pu: package capnproto/0.7.1-1+deb11u1
On Tue, Jul 25, 2023 at 10:19:50PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 moreinfo > > On Mon, Dec 05, 2022 at 11:22:51PM -0800, tony mancill wrote: > > As the upstream author notes in [3], the issue is present in inlined > > code, thus applications built against capnproto must be rebuilt against > > the patched version. > > This doesn't immediately make any of us enthusiastic, it has to be said... > Can we get the proposed debdiff at least please? > > The hazards are: > - ftbfs in the rdeps in stable > - much reduced testing of proposed-updates vs. for example sid/testing > > > The issue for unstable and bookworm is being addressed via an > > upload to experimental [4] and a subsequent transition [5]. Easy > > enough... > > > > For stable (and old-stable), we need to introduce 0.7.1, a new upstream > > version that generates a (new) libcapnp-0.7.1 binary package to address > > the vulnerability. Once those are present in the archive, we can > > trigger rebuilds of the reverse dependencies. At this time I am asking > > for bullseye. > > > > [ Reason ] > > This is to address CVE-2022-46149 [1]. > > > > [ Impact ] > > Packages built with capnproto in bullseye will remain potentially > > vulnerable to the CVE. > > > > [ Tests ] > > I have built the package in a clean bullseye chroot and then used ratt to > > rebuilt the (8) bullseye r-deps: > > > > - clickhouse_18.16.1+ds-7.2 > > - harvest-tools_1.3-6 > > - laminar_1.0-3 > > - librime_1.6.1+dfsg1-1 > > - mash_2.2.2+dfsg-2 > > - mir_1.8.0+dfsg1-18 > > - rr_5.4.0-2 > > - sonic-visualiser_4.2-1 > > laminar in particular doesn't seem to have much maintainer attention. If > there are problems with the rdeps on rebuild are you going to be in a > position to resolve them? > > > [ Risks ] > > The upstream author has stated that there are no known vulnerable > > applications, yet advises that all capnproto users rebuild their > > applications using patched versions of capnproto. > > An abundance of caution? Otherwise the statements seem at odds with each > other. > > > If this is not amenable to stable-proposed-updates, would you recommend > > backports? > > I'm not sure a transition in backports is going to be well received either. > Let's start with the debdiff and at least know what we're looking at. Ping? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: closing 1050591
Processing commands for cont...@bugs.debian.org: > close 1050591 Bug #1050591 [release.debian.org] bullseye-pu: package awstats/7.8-2+deb11u2 Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1050591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050591 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote: > 06.02.2024 20:33, Adam D. Barratt: > > On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: > > > problematic upstream commit (on master) is this one: > > > https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 > > > Technically we already froze p-u for 12.5 on Sunday evening, as > > previously announced. If you could get an upload just fixing that > > single issue with a small change uploaded today then I'd be tempted > > to > > accept it anyway. > > Oh. I knew we're getting late, but not *that* late. > The point release(s) are on Saturday, and we always freeze a week beforehand. > The change isn't small per se, as the commit is rather large (mostly > due to many changed tests, - it changes order of output in quite some > places). Here's the diffstat: > > monitor/qmp.c | 17 + > qapi/qmp-dispatch.c | 24 +- > -- This is the relevant bit for size IMO. If you're happy with the result then please upload as soon as you're ready. Regards, Adam
Bug#1037188: bullseye-pu: package git/2.30.2-1+deb11u3
Hi, On Sun, Oct 08, 2023 at 01:05:24PM +0100, Jonathan Wiltshire wrote: > On Thu, Jul 27, 2023 at 03:52:52PM +0200, Andreas Beckmann wrote: > > Control: tag -1 - moreinfo > > > > On 08/07/2023 19.25, Adam D. Barratt wrote: > > > It looks like not all of the postinst was removed - was that > > > intentional? It's presumably harmless, but now leads to a lintian > > > warning, which is why I noticed. :-) > > > > That git-el.postinst code was already removed by > > c4b054cf0e debian: drop support for upgrades from pre-1.7.9.5 versions > > (Mon Dec 28 20:13:48 2020 -0800) > > and I missed the opportunity to simply delete the whole file when I > > backported > > 67b73aadeb debian: remove git-el package (Mon May 31 15:03:12 2021 -0700). > > The remaining bits should be harmless (it's a postinst script for a package > > no longer in d/control), but if you prefer, I can reupload with the cruft > > bits removed, too. Should save a few brain cycles on future updates ;-) > > Yes please; I'll reject the existing upload in a moment so you can re-use > the version. There hasn't been any movement on this bug for the previous point release 11.8 nor the frozen 11.9. Should it be included in 11.10, or should this request be abandoned and closed? Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1029008: Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?
Control: close -1 Hi, On Tue, Jul 25, 2023 at 10:26:06PM +0100, Jonathan Wiltshire wrote: > Control: tag -1 confirmed > > Hi, > > On Mon, Jan 16, 2023 at 07:41:21AM +0100, László Böszörményi wrote: > > On Mon, Jan 16, 2023 at 6:38 AM Salvatore Bonaccorso > > wrote: > > > On Sun, Jan 15, 2023 at 04:57:24PM -0500, Daniel Kahn Gillmor wrote: > > > > I was looking into CVE-2022-24859 and pypdf2, and trying to figure out > > > > whether the version in bullseye is still vulnerable, as it appears to be > > > > according to the security tracker: > > [...] > > > It is still unfixed in bullseye TTBOMK, but would not warrant a DSA. > > Indeed, it's not yet fixed for Bullseye and doesn't warrant a DSA as > > the max impact is an infinite loop in the user's own process. > > > > > Can you propose a fix for it with cherry-picking the pull request > > > changes for the next bullseye point release? > > Correct, it needs to go via Bullseye point update. I attached the > > short change which has the original commit as Salvatore noted. > > Either of the proposed diffs is fine; please go ahead. This package has not been uploaded in time for two consecutive point releases now, so I am closing the request. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Processed: Re: Bug#1029008: Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?
Processing control commands: > close -1 Bug #1029008 [release.debian.org] bullseye-pu: package pypdf2/1.26.0-4+deb11u1 Marked Bug as done -- 1029008: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029008 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1023740: bullseye-pu: package python-scciclient/0.8.0-2
Processing control commands: > close -1 Bug #1023740 [release.debian.org] bullseye-pu: package python-scciclient/0.8.0-2 Marked Bug as done -- 1023740: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023740 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023740: bullseye-pu: package python-scciclient/0.8.0-2
Control: close -1 On Wed, Nov 09, 2022 at 01:00:15PM +0100, Thomas Goirand wrote: > [ Reason ] > This patch fixes the lack of TLS verification with scciclient. > > [ Impact ] > Man in the middle attack is possible without this patch. This package has not been uploaded in time for two consecutive point releases now, so I am closing the request. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:33, Adam D. Barratt: On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 Technically we already froze p-u for 12.5 on Sunday evening, as previously announced. If you could get an upload just fixing that single issue with a small change uploaded today then I'd be tempted to accept it anyway. Oh. I knew we're getting late, but not *that* late. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +--- tests/qemu-iotests/060.out|4 ++-- tests/qemu-iotests/071.out|4 ++-- tests/qemu-iotests/081.out| 16 tests/qemu-iotests/087.out| 12 ++-- tests/qemu-iotests/108.out|2 +- tests/qemu-iotests/109|4 ++-- tests/qemu-iotests/109.out| 78 +- tests/qemu-iotests/117.out|2 +- tests/qemu-iotests/120.out|2 +- tests/qemu-iotests/127.out|2 +- tests/qemu-iotests/140.out|2 +- tests/qemu-iotests/143.out|2 +- tests/qemu-iotests/156.out|2 +- tests/qemu-iotests/176.out| 16 tests/qemu-iotests/182.out|2 +- tests/qemu-iotests/183.out|4 ++-- tests/qemu-iotests/184.out| 32 tests/qemu-iotests/185|6 +++--- tests/qemu-iotests/185.out| 45 + tests/qemu-iotests/191.out| 16 tests/qemu-iotests/195.out| 16 tests/qemu-iotests/223.out| 12 ++-- tests/qemu-iotests/227.out| 32 tests/qemu-iotests/247.out|2 +- tests/qemu-iotests/273.out|8 tests/qemu-iotests/308|4 ++-- tests/qemu-iotests/308.out|2 +- tests/qemu-iotests/tests/qsd-jobs.out |4 ++-- 30 files changed, 173 insertions(+), 201 deletions(-) (as you can see, first two are the gist of it, the rest are the consequences). I'm including a complete revert of this single commit together with all the testsuite changes, ie, exactly as it is, - while the upstream testsuite isn't used in debian directly, it still works, and I'm running it right now locally just to be sure (though it definitely worked before that commit has been initially applied, so it should be okay). Presumably the bugs being fixed by that commit already exist in bookworm's qemu, so not including the commit isn't a regression? Yes, exactly, that's why I wrote about the status-quo. Please also attach a debdiff against the previous upload. Attached.diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog --- qemu-7.2+dfsg/debian/changelog 2024-01-30 19:15:04.0 +0300 +++ qemu-7.2+dfsg/debian/changelog 2024-02-06 20:38:06.0 +0300 @@ -1,3 +1,12 @@ +qemu (1:7.2+dfsg-7+deb12u5) bookworm; urgency=medium + + * +revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch +Revert a single upstream change in 7.2.9 which, while fixed a few qemu +lockup bugs, introduced a regression in suspend-resume-hibernate cycle +(triggered by cryptsetup autopkgtest) + + -- Michael Tokarev Tue, 06 Feb 2024 20:38:06 +0300 + qemu (1:7.2+dfsg-7+deb12u4) bookworm; urgency=medium [ Michael Tokarev ] diff -Nru qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch --- qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 1970-01-01 03:00:00.0 +0300 +++ qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 2024-02-06 20:36:21.0 +0300 @@ -0,0 +1,1544 @@ +From 84a139b0289470994f8a518034d69186f5ad5bb9 Mon Sep 17 00:00:00 2001 +From: Michael Tokarev +Date: Tue, 6 Feb 2024 20:35:22 +0300 +Subject: [PATCH] Revert "monitor: only run coroutine commands in + qemu_aio_context" + +This reverts commit 8ec90598e922a604c222bdbc6289bed7279dced6. +Causes a regression at least in suspend-resume-hibernate cycle, +let's revert it to restore the status quo for now. +--- + monitor/qmp.c | 17 ++ + qapi/qmp-dispatch.c | 24 + + tests/qemu-iotests/060.out| 4 +- +
Processed: Re: Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup
Processing control commands: > tag -1 moreinfo Bug #1052455 [release.debian.org] bookworm-pu: package freetype/2.12.1+dfsg-5+deb12u1 Added tag(s) moreinfo. -- 1052455: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052455 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052455: RE: freetype 2.12.1+dfsg-5+deb12u1 makes chromium segfault at startup
Control: tag -1 moreinfo Hi, On Fri, Sep 29, 2023 at 12:22:41AM +1000, Hugh McMaster wrote: > After discussing the timing of Debian 12.2 with a release manager, I’ll > revert the change shortly. > What's your plan at this point? We have skipped this update in two point releases now and it needs a resolution. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: > e problematic upstream commit (on master) is this one: > https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 > It has links to 2 bugs it is fixing, and there are quite a few > other bugs which are fixed too. > > I can add a revert of this single commit (with all tests) for debian > stable (for deb12u5 release) on top of current deb12u4. I think > this would be best, despite the way it goes, - first the change is > added in v7.2.9.diff, and next removed in a followup revert, - > because this way we follow upstream releases, and this patch > will be easy to remove in subsequent update. [...] > re thing, if the solution will be found in a couple of days, > I'll try to push that one instead, but it also depends on the > complexity and possible risks there, and timeline. Technically we already froze p-u for 12.5 on Sunday evening, as previously announced. If you could get an upload just fixing that single issue with a small change uploaded today then I'd be tempted to accept it anyway. Presumably the bugs being fixed by that commit already exist in bookworm's qemu, so not including the commit isn't a regression? Please also attach a debdiff against the previous upload. Regards, Adam
NEW changes in stable-new
Processing changes file: debian-installer-netboot-images_20230607+deb12u5_all-buildd.changes ACCEPT
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
03.02.2024 12:47, Michael Tokarev wrote: It looks like we broke suspend/resume in this version of qemu. Oops. Is that related to the cryptsetup failure, or a separate issue? Yes, it is related to cryptsetup autopkgtest failure. It looks like this is the only place where suspend/resume code in qemu is actually being used, - it's rather rare to suspend (hybernate) a virtual machine, and cryptsetup performs testing of how the encrypted filesystem is unlocked (or not) on resume. So, while the problematic upstream commit fixes quite a few real potential qemu lockups, it introduces a new lockup in suspend- resume-hibernate cycle. The problem isn't understood yet, and we're getting close to the 12.5 release. The problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 It has links to 2 bugs it is fixing, and there are quite a few other bugs which are fixed too. I can add a revert of this single commit (with all tests) for debian stable (for deb12u5 release) on top of current deb12u4. I think this would be best, despite the way it goes, - first the change is added in v7.2.9.diff, and next removed in a followup revert, - because this way we follow upstream releases, and this patch will be easy to remove in subsequent update. Alternatively we probably can ignore cryptsetup autopkgtest failure, but this smells somewhat wrong, I think it's better to restore the status quo for now, even in such a weird way (applying and reverting a patch). What do you think? Sure thing, if the solution will be found in a couple of days, I'll try to push that one instead, but it also depends on the complexity and possible risks there, and timeline. Thanks, /mjt
NEW changes in stable-new
Processing changes file: debian-installer-netboot-images_20230607+deb12u5_source.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: debian-installer-netboot-images_20210731+deb11u10_all-buildd.changes ACCEPT
NEW changes in oldstable-new
Processing changes file: debian-installer-netboot-images_20210731+deb11u10_source.changes ACCEPT
Bug#1061645: poco: NMU diff for 64-bit time_t transition
Hi Bastian On 2024-02-06 12:34:32 +0100, Bastian Germann wrote: > Hi Lucas, > > Please use the latest experimental QA upload for the 64-bit time_t transition > instead of uploading your NMU. > The other planned transition is documented in #1061645. > All library package names are SO-bumped, which should be enough to fulfill > your intended change. > This is a cross-posting to ensure the release team is aware of that. Please beaware that we are doing time_t first and pause all other transitions until that is complete. We will process the poco transition independently after time_t is done. Please do not entangle them. Cheers -- Sebastian Ramacher
Bug#1061645: poco: NMU diff for 64-bit time_t transition
Hi Lucas, Please use the latest experimental QA upload for the 64-bit time_t transition instead of uploading your NMU. The other planned transition is documented in #1061645. All library package names are SO-bumped, which should be enough to fulfill your intended change. This is a cross-posting to ensure the release team is aware of that. Thanks, Bastian
Bug#1061565: marked as done (nmu: rust-alacritty_0.12.2-2)
Your message dated Tue, 6 Feb 2024 09:05:50 +0100 with message-id and subject line Re: Bug#1061565: nmu: rust-alacritty_0.12.2-2 has caused the Debian Bug report #1061565, regarding nmu: rust-alacritty_0.12.2-2 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.) -- 1061565: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061565 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: binnmu X-Debbugs-Cc: rust-alacri...@packages.debian.org Control: affects -1 + src:rust-alacritty nmu rust-alacritty_0.12.2-2 . ANY . unstable . -m "Rebuild against rust-smithay-client-toolkit 0.16.1" This is needed to fix #1061563 (crash with recent sway versions). --- End Message --- --- Begin Message --- On 2024-02-05 22:21:09 -0500, James McCoy wrote: > On Fri, Jan 26, 2024 at 10:16:50AM -0500, James McCoy wrote: > > nmu rust-alacritty_0.12.2-2 . ANY . unstable . -m "Rebuild against > > rust-smithay-client-toolkit 0.16.1" > > > > This is needed to fix #1061563 (crash with recent sway versions). > > Ping? It'd be nice to get this fixed, since other things are blocking > an update of alacritty. Scheduled. Cheers -- Sebastian Ramacher--- End Message ---
