Re: Getting python3-ilorest and ilorest uploaded in sync
Hello Thomas, Am 12.03.25 um 09:39 schrieb Thomas Goirand: There is a ongoing hassle with python-redfish as both packages use the same module path, it's not resolved yet and would need to get fixed by HPE I think. I have just seen #1093034 about this. But I'm very pessimistic HPE will move ever to get this solved so bot Python libraries can live together. Did you open a bug upstream for this? Karsten Schöke did this a while ago. https://github.com/HewlettPackard/python-ilorest-library/issues/168 -- Regards Carsten
Re: Getting python3-ilorest and ilorest uploaded in sync
On 3/11/25 15:29, Carsten Schoenert wrote: I'm totally fine if the new version 6.x goes into Trixie. If you want to pick over the package feel free, otherwise I can try to have a look at the weekend. FYI, I did the work, but got stuck because of this: https://github.com/HewlettPackard/python-redfish-utility/issues/110 I'll wait for upstream to reply before attempting to fix this myself. Cheers, Thomas Goirand (zigo)
Bug#1100177: transition: coq-elpi 2.5.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpu...@debian.org X-Debbugs-Cc: Debian OCaml Maintainers A new upstream version of coq-elpi is out ; it requires rebuilding all depending packages, and updating some of them (see below). I'm waiting for the "go!" signal to upload the new packages. Cheers, J.Puydt PS: here is the transition script, obtained using: coq-wanna-build coq-elpi 2.5.0-1 coq-quickchick 2.1.0-1 coqeal 2.1.0-1 nmu coq-hierarchy-builder_1.8.1-1+b2 . ANY . -m 'Rebuild because of upload of coq-elpi=2.5.0-1' dw coq-hierarchy-builder_1.8.1-1+b2 . ANY . -m 'coq-elpi >= 2.5.0-1' nmu coq-corn_8.20.0-1+b2 . ANY . -m 'Rebuild because of upload of coq- elpi=2.5.0-1' dw coq-corn_8.20.0-1+b2 . ANY . -m 'coq-elpi >= 2.5.0-1' nmu ssreflect_2.3.0-1+b7 . ANY . -m 'Rebuild because of upload of coq- hierarchy-builder=1.8.1-1+b2' dw ssreflect_2.3.0-1+b7 . ANY . -m 'coq-hierarchy-builder >= 1.8.1- 1+b2' dw coq-quickchick_2.1.0-1 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-deriving_0.2.1-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coq-deriving_0.2.1-1+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-reglang_1.2.1-4+b13 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coq-reglang_1.2.1-4+b13 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-relation-algebra_1.7.11-1+b6 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coq-relation-algebra_1.7.11-1+b6 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' nmu coquelicot_3.4.3-1+b2 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw coquelicot_3.4.3-1+b2 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-bigenough_1.0.2-1+b3 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw mathcomp-bigenough_1.0.2-1+b3 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-finmap_2.1.0-3+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw mathcomp-finmap_2.1.0-3+b7 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-zify_1.5.0+2.0+8.16-4+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7' dw mathcomp-zify_1.5.0+2.0+8.16-4+b7 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' nmu mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'Rebuild because of upload of coq-elpi=2.5.0-1 mathcomp-zify=1.5.0+2.0+8.16-4+b7 ssreflect=2.3.0-1+b7' dw mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'coq-elpi >= 2.5.0- 1' dw mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'mathcomp-zify >= 1.5.0+2.0+8.16-4+b7' dw mathcomp-algebra-tactics_1.2.4-1+b4 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' nmu mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'Rebuild because of upload of mathcomp-finmap=2.1.0-3+b7 mathcomp-bigenough=1.0.2-1+b3 coq- elpi=2.5.0-1 coq-hierarchy-builder=1.8.1-1+b2 ssreflect=2.3.0-1+b7' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'mathcomp-finmap >= 2.1.0- 3+b7' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b3' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'coq-elpi >= 2.5.0-1' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'coq-hierarchy-builder >= 1.8.1-1+b2' dw mathcomp-analysis_1.9.0-1+b1 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-extructures_0.5.0-1+b6 . ANY . -m 'Rebuild because of upload of coq-deriving=0.2.1-1+b6 ssreflect=2.3.0-1+b7' dw coq-extructures_0.5.0-1+b6 . ANY . -m 'coq-deriving >= 0.2.1-1+b6' dw coq-extructures_0.5.0-1+b6 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu coq-interval_4.11.1-1+b8 . ANY . -m 'Rebuild because of upload of coquelicot=3.4.3-1+b2 ssreflect=2.3.0-1+b7' dw coq-interval_4.11.1-1+b8 . ANY . -m 'coquelicot >= 3.4.3-1+b2' dw coq-interval_4.11.1-1+b8 . ANY . -m 'ssreflect >= 2.3.0-1+b7' nmu mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7 mathcomp-finmap=2.1.0-3+b7 mathcomp- bigenough=1.0.2-1+b3' dw mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' dw mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'mathcomp-finmap >= 2.1.0-3+b7' dw mathcomp-multinomials_2.3.0-1+b7 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b3' nmu mathcomp-real-closed_2.0.2-1+b7 . ANY . -m 'Rebuild because of upload of ssreflect=2.3.0-1+b7 mathcomp-bigenough=1.0.2-1+b3' dw mathcomp-real-closed_2.0.2-1+b7 . ANY . -m 'ssreflect >= 2.3.0- 1+b7' dw mathcomp-real-closed_2.0.2-1+b7 . ANY . -m 'mathcomp-bigenough >= 1.0.2-1+b3' dw coqeal_2.1.0-1 . ANY . -m 'ssreflect >= 2.3.0-1+b7' dw coqeal_2.1.0-1 . ANY . -m 'mathcomp-real-closed >= 2.0.2-1+b7'
Bug#1100365: nmu: emacs_1:30.1+1-4
Package: release.debian.org Severity: normal X-Debbugs-Cc: em...@packages.debian.org Control: affects -1 + src:emacs User: release.debian@packages.debian.org Usertags: binnmu nmu emacs_1:30.1+1-4 . ANY . unstable . -m "Rebuild against tree-sitter 0.22" I think I overlooked an ABI incompatibility when uploading tree-sitter 0.22, which is causing emacs to crash when it is running with the new libtree-sitter0 package (#1100171). Please binNMU emacs, and then I'll follow up with a tree-sitter upload to add Breaks to avoid partial upgrades.
Bug#1099646: transition: gnat
Hi Nicolas The binNMU of alire was scheduled, but FTBFS on armel and armhf [1]. I assumed this is the same issue reported in #1096181, so I marked the bug affecting alire and tagged it ftbfs. For the record, the armel and armhf builds were retried recently with gcc-14 14.2.0-18 in unstable, but failed again. I still see some packages involved in this transition with new versions in experimental that have not yet been uploaded to unstable. I'd like to avoid a situation where we are waiting on each other. Please let us know if you expect further action from the release time at this point. Regards Graham [1] https://buildd.debian.org/status/package.php?p=alire
Bug#1099400: dgit 10.7+deb12u3 flagged for acceptance
package release.debian.org tags 1099400 = 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: dgit Version: 10.7+deb12u3 Explanation: add missing parameters for source upload target
Bug#1100336: bookworm-pu: package nginx/1.22.1-9+deb12u2
Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ng...@packages.debian.org, Jan Mojžíš
Control: affects -1 + src:nginx
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I’d like to upload a backport of patches fixing for CVE-2024-7347.
This issue has been fixed in the nginx version currently in trixie/unstable.
I also plan to upload a similar fix to the nginx version in bullseye, so to
ensure users don’t update from nginx with this bug fixed to one that’s
still vulnerable, I’d like to fix it in bullsworm as well.
[ Reason ]
Nginx has a vulnerability in the ngx_http_mp4_module, which might allow
an attacker to over-read nginx worker memory resulting in its termination
using a specially crafted mp4 file. The issue only affects nginx if it
is built with the ngx_http_mp4_module and the mp4 directive is used in
the configuration file. Additionally, the attack is possible only if an
attacker can trigger the processing of a specially crafted mp4 file with
the ngx_http_mp4_module.
[ Impact ]
Since this bug is going to be fixed in bullseye, users may hit the
vulnerability once they upgrade to booksworm.
[ Tests ]
I ran the automated tests (autopkgtests) included in the package.
[ Risks ]
This change is trivial.
[ 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 ]
This is a trivial cherry-pick of the upstream commits
7362d01658b and 88955b1044e without any manual fixups.
Thanks.
--
Cheers,
Andrej
diff -Nru nginx-1.22.1/debian/changelog nginx-1.22.1/debian/changelog
--- nginx-1.22.1/debian/changelog 2025-02-17 20:40:29.0 +0100
+++ nginx-1.22.1/debian/changelog 2025-03-12 18:55:08.0 +0100
@@ -1,3 +1,12 @@
+nginx (1.22.1-9+deb12u2) bookworm; urgency=medium
+
+ * Non-maintainer upload by the LTS Team.
+ * Add upstream patches for CVE-2024-7347:
+- mp4: fix buffer underread while updating stsz atom
+- mp4: reject unordered chunks in stsc atom
+
+ -- Andrej Shadura Wed, 12 Mar 2025 18:55:08 +0100
+
nginx (1.22.1-9+deb12u1) bookworm; urgency=medium
* d/p/CVE-2025-23419.patch add, backport CVE-2025-23419 fix.
diff -Nru nginx-1.22.1/debian/patches/CVE-2024-7347-1.patch
nginx-1.22.1/debian/patches/CVE-2024-7347-1.patch
--- nginx-1.22.1/debian/patches/CVE-2024-7347-1.patch 1970-01-01
01:00:00.0 +0100
+++ nginx-1.22.1/debian/patches/CVE-2024-7347-1.patch 2025-03-12
18:54:39.0 +0100
@@ -0,0 +1,49 @@
+From: Roman Arutyunyan
+Date: Mon, 12 Aug 2024 18:20:43 +0400
+Subject: Mp4: fixed buffer underread while updating stsz atom.
+
+While cropping an stsc atom in ngx_http_mp4_crop_stsc_data(), a 32-bit integer
+overflow could happen, which could result in incorrect seeking and a very large
+value stored in "samples". This resulted in a large invalid value of
+trak->end_chunk_samples. This value is further used to calculate the value of
+trak->end_chunk_samples_size in ngx_http_mp4_update_stsz_atom(). While doing
+this, a large invalid value of trak->end_chunk_samples could result in reading
+memory before stsz atom start. This could potentially result in a segfault.
+
+Origin: upstream,
https://github.com/nginx/nginx/commit/7362d01658b61184108c21278443910da68f93b4
+---
+ src/http/modules/ngx_http_mp4_module.c | 7 ---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/src/http/modules/ngx_http_mp4_module.c
b/src/http/modules/ngx_http_mp4_module.c
+index 4eff01e..460d091 100644
+--- a/src/http/modules/ngx_http_mp4_module.c
b/src/http/modules/ngx_http_mp4_module.c
+@@ -3098,7 +3098,8 @@ static ngx_int_t
+ ngx_http_mp4_crop_stsc_data(ngx_http_mp4_file_t *mp4,
+ ngx_http_mp4_trak_t *trak, ngx_uint_t start)
+ {
+-uint32_t start_sample, chunk, samples, id, next_chunk, n,
++uint64_t n;
++uint32_t start_sample, chunk, samples, id, next_chunk,
+prev_samples;
+ ngx_buf_t *data, *buf;
+ ngx_uint_t entries, target_chunk, chunk_samples;
+@@ -3159,7 +3160,7 @@ ngx_http_mp4_crop_stsc_data(ngx_http_mp4_file_t *mp4,
+"samples:%uD, id:%uD",
+start_sample, chunk, next_chunk - chunk, samples, id);
+
+-n = (next_chunk - chunk) * samples;
++n = (uint64_t) (next_chunk - chunk) * samples;
+
+ if (start_sample < n) {
+ goto found;
+@@ -3181,7 +3182,7 @@ ngx_http_mp4_crop_stsc_data(ngx_http_mp4_file_t *mp4,
+"sample:%uD, chunk:%uD, chunks:%uD, samples:%uD",
+start_sample, chunk, next_chunk - chunk, samples);
+
+-n = (next_chunk - chunk) * samples;
++n = (uint64_t) (next_chunk - chunk) * samples;
+
+ if (start_sample > n) {
+ ngx_log_error(NGX_LOG_ERR, mp4->file.log, 0,
d
Processed: bookworm-pu: package nginx/1.22.1-9+deb12u2
Processing control commands: > affects -1 + src:nginx Bug #1100336 [release.debian.org] bookworm-pu: package nginx/1.22.1-9+deb12u2 Added indication that 1100336 affects src:nginx -- 1100336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100336 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1100166: transition: onnxruntime
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 = src:onnxruntime Dear release managers, Upstream has just released onnxruntime 1.21.0, leading to a SONAME change. I would like to request a transition slot for it. Additional information: * I have modified my patch to include only MAJOR.MINOR version numbers in the SOVERSION. So we could expect less frequent transitions afterwards. * The only rev-dep gst-plugins-bad1.0 can compile without issue. Ben file (automatic one looks good): title = "onnxruntime"; is_affected = .depends ~ "libonnxruntime1.20.1" | .depends ~ "libonnxruntime1.21"; is_good = .depends ~ "libonnxruntime1.21"; is_bad = .depends ~ "libonnxruntime1.20.1"; -- Thanks, Shengqi Chen
Processed: transition: onnxruntime
Processing control commands: > affects -1 = src:onnxruntime Bug #1100166 [release.debian.org] transition: onnxruntime Added indication that 1100166 affects src:onnxruntime -- 1100166: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100166 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Getting python3-ilorest and ilorest uploaded in sync
On 3/11/25 15:29, Carsten Schoenert wrote: I count one time, but this doesn't matter in the end. It's been the 3rd time, but right, let's move on. Could we *PLEASE* communicate and get to upload both at the same time? So far, I've been communicating with you about this privately. This time, I'm adding the release team list as recipient, to get the release team attention, and to make sure the message is publicly seen and ACK that I've made such a request. If the bad practice of rogue uploads continue, I may escalate this further. You've been (politely) warned... Yes, we've had a conversion in the past about some coordinated uploads and there was no and never an intention from my side in the past to block any other packages, why should I've an interest in such doings. If this was happen I need to apologize about that. No worries. It's more that I've really forgotten about we need to coordinate the work. Also, would you be ok to move your package to the Python team, so I get upload rights as well? I don't mind, I also would not mind if you want to put yourself into the Uploaders field and remove me there. > In the past I had an interest in the package as I was using this on may day job, this isn't the case anymore. That's the case for me. We have hundreds of HPe servers at my work, and we use ilorest daily to change settings. I'll move the package to the DPT the next hours. Thanks for moving the package, I can see it already reached https://salsa.debian.org/python-team/packages/python-ilorest. Though I do not want to kick you out of the project. :) Version 6.0.0 has been released 6 hours ago, and is available. Should we package these for Trixie? The library freeze is in 4 days... Once done, IMO, no further upload should be done before Trixie is out. Your thoughts? I'm totally fine if the new version 6.x goes into Trixie. If you want to pick over the package feel free, otherwise I can try to have a look at the weekend. Ok, I'll do this soon (maybe today?). There is a ongoing hassle with python-redfish as both packages use the same module path, it's not resolved yet and would need to get fixed by HPE I think. I have just seen #1093034 about this. But I'm very pessimistic HPE will move ever to get this solved so bot Python libraries can live together. Did you open a bug upstream for this? Cheers, Thomas Goirand (zigo)
Processed: nmu: emacs_1:30.1+1-4
Processing control commands: > affects -1 + src:emacs Bug #1100365 [release.debian.org] nmu: emacs_1:30.1+1-4 Added indication that 1100365 affects src:emacs -- 1100365: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100365 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1094736: transition: libcdio
* gregor herrmann: > > % apt-cache --no-all-versions show libiso9660-12 > Package: libiso9660-12 > > Source: libcdio > Version: 2.2.0-1 > Installed-Size: 76 > Maintainer: Gabriel F. T. Gomes > Architecture: amd64 > Depends: libc6 (>= 2.14), libcdio19t64 (>= 2.1.0) This is probably due to the fact that libiso9660 is built from the same source as libcdio; thus, when libiso9660 is built, it is linked against the version of libcdio installed on the build system, which is version 2.1.0-5. Perhaps the build rules for the libcdio (source-)package should require libiso9660 to be linked against the newly built libcdio, but I don't think that this is how these things are usually done. I'm a little bit confused, as well, but thank you very much for digging into this. This information you shared is very useful.
Bug#1094736: transition: libcdio
On Tue, 11 Mar 2025 16:44:14 -0700, Gabriel F. T. Gomes wrote: 1. Maybe my worries about the ABI break and libdevice-cdio-perl were not actually too conservative. 2. Why does using an old version of libcdio (not libiso9660) is causing the issue? Should libcdio's SONAME have been bumped (by upstream), as well? What surprises me a bit: % apt-cache --no-all-versions show libdevice-cdio-perl Package: libdevice-cdio-perl Source: libdevice-cdio-perl (2.0.0-2) Version: 2.0.0-2+b5 Installed-Size: 612 Maintainer: Debian Perl Group Architecture: amd64 Depends: perl (>= 5.40.1-2), perlapi-5.40.1, libc6 (>= 2.38), libcdio19t64 (>= 2.1.0), libiso9660-12 (>= 2.2.0) i.e. libdevice-cdio-perl needs the newer libiso9660-12 but is fine with the old libcdio19t64. But this is in sync with: % apt-cache --no-all-versions show libiso9660-12 Package: libiso9660-12 Source: libcdio Version: 2.2.0-1 Installed-Size: 76 Maintainer: Gabriel F. T. Gomes Architecture: amd64 Depends: libc6 (>= 2.14), libcdio19t64 (>= 2.1.0) Cheers, gregor, still confused -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
