Bug#1069048: live-boot fails to DHCP on all NICs with link up
ping? If nobody really cares about this bug, would it be ok to NMU the fix to Unstable, so that I can later backport it to Bookworm? Cheers, Thomas Goirand (zigo)
Bug#1040186: NMU for fixing this bug in Bookworm
Hi, Since there's been very low activity in this bug, and that I cannot see if the current maintainer is willing to fix the bug, I have opened a bug against the Stable release team to fix this issue in Bookworm: https://bugs.debian.org/1071264 You'll find the package debdiff over there. Please let me know if you prefer to fix this yourself, or if it's ok for me to upload the fixed package in Bookworm. Cheers, Thomas Goirand (zigo)
Bug#1071264: autopkgtest fails with networkx 3.2.1
Source: seirsplus Version: 1.0.9-1 Severity: serious Hi, Your package fails autopkgtest with the current version of networkx in Unstable. Please fix it. Cheers, Thomas Goirand (zigo)
Bug#1071029: RM: python-randomize -- ROM; nose removal, unused anymore
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-random...@packages.debian.org Control: affects -1 + src:python-randomize Hi, As we're trying to remove nose from Debian, it's time to remove this nose plugin. There's no reverse dependency in unstable anymore. Indeed, I fixed python-influxdb-client, and only the version in testing still has the python3-randomize build-depends. Please remove python-randomize from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070819: Please package latest version of python-googleapi
Source: python-googleapi Version: 1.7.12-1 Severity: important Hi, The current version of python-googleapi still includes old deprecated modules like mock (instead of unittest.mock), or oauth2client. I intend to attempt removing the oauth2client from Debian, as it FTBFS and is deprecated upstream. Please package the latest python-googleapi as it looks up-to-date regarding those things, and then you can probably remove build-depends on mock, six, oauth2client and so on. Also, it'd be nice to get this library in the DPT, as it is used by many. Cheers, Thomas Goirand (zigo)
Bug#1069097: openstack-dashboard: postinst error makes designate-dashboard to FTBFS randomly
Hi Santiago, I wasn't able to reproduce this bug. Can you help? Cheers, Thomas Goirand (zigo)
Bug#1070741: Fixed
Hi Scott, Sorry, I fixed python-openstackclient and removed its build-depends on python3-karborclient today (and removed the moreinfo tag on this bug). FYI, it was there so openstackclient could generate its autocompletion and doc correctly with karborclient support. Cheers, Thomas Goirand (zigo)
Bug#1065652: Needed by python-memcache
Hi, This package is needed by latest version of python-memcache. So I'm therefore doing an ITP instead of the original RFS for this package. Cheers, Thomas Goirand (zigo)
Bug#1070741: RM: python-karborclient -- ROM; unmaintained upstream, leaf package
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-karborcli...@packages.debian.org Control: affects -1 + src:python-karborclient Hi, Please remove python-karborclient from Debian. The upstream project has been dead for a long time already. Cheers, Thomas Goirand (zigo)
Bug#1070739: bookworm-pu: package python-glance-store/4.1.0-4
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: python-glance-st...@packages.debian.org Control: affects -1 + src:python-glance-store [ Reason ] I would like to update python-glance-store/4.1.0-4 to python-glance-store/4.1.1-1+deb12u1 to address CVE-2024-1141 (aka: #1063795). [ Impact ] S3 credentials may otherwise continue to be logged in glance's log if loglevel is set to DEBUG. [ Tests ] The package contains and run unit tests at build time, plus autopkgtest. Upstream runs extensive functional tests, and so do I, doing a full OpenStack deployment with this package. No regression has been found. [ Risks ] Minimum. Only the S3 backend is impacted. [ 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 ] The point release announcement was published last year: https://lists.openstack.org/archives/list/release-annou...@lists.openstack.org/thread/PY26MG7DBD4UVJDEXWMSIM4TGS52F4VX/ It can be broken down this way: e9d2509 Add force to os-brick disconnect 3d3467d Fix tox4 error 8034cdc Update TOX_CONSTRAINTS_FILE for stable/zed c05c7e5 Update .gitreview for stable/zed Let me explain the commits. e9d2509 contains the fix for CVE-2023-2088 that was already in Bookworm, and that I'm therefore droping. The other 3 commits are to address internal OpenStack CI and Git infra, and are not code change. They can therefore be ignore. So really, this update only contains the fix for CVE-2024-1141 and nothing else, even though the upstream version bumps. Last thing: I rewrote the patch header this way (not shown in the attached debdiff, as I fired-up reporbug -b before realizing the patch header needed some edits): Author: lujie Date: Fri, 19 Jan 2024 13:12:20 +0800 Description: CVE-2024-1141: Do not show access_key in s3 driver Avoid possible leakage of s3 access keys by not including them in log messages. . This patch includes commit d6e531af4821c8466b1e9404f12f89f6216417f2 (change I8dc564bed33d6fc71965f4f573ae9109b410b1d4), which addressed some more log messages that the original patch had missed. . The two commits are squashed here for ease in backporting (and also to make sure that *both* are always backported). Change-Id: I9193df38d613259b61bb369fa1040fb2c51a21d7 Origin: upstream, https://review.opendev.org/c/openstack/glance_store/+/907736 Bug: https://launchpad.net/bugs/2047688 Bug-Debian: https://bugs.debian.org/1063795 Last-Update: 2024-05-08 Please allow me to upload python-glance-store to Bookworm for the next point release. Cheers, Thomas Goirand (zigo) diff -Nru python-glance-store-4.1.0/debian/changelog python-glance-store-4.1.1/debian/changelog --- python-glance-store-4.1.0/debian/changelog 2023-05-12 08:52:34.0 +0200 +++ python-glance-store-4.1.1/debian/changelog 2023-09-01 15:10:49.0 +0200 @@ -1,3 +1,13 @@ +python-glance-store (4.1.1-1+deb12u1) bookworm; urgency=medium + + * New upstream release. + * Drop CVE-2023-2088_Add_force_to_os-brick_disconnect.patch applied +upstream. + * CVE-2024-1141: Glance Store access key logged in DEBUG log level. Add +upstream patch: Do not show access_key in s3 driver (Closes: #1063795). + + -- Thomas Goirand Fri, 01 Sep 2023 15:10:49 +0200 + python-glance-store (4.1.0-4) unstable; urgency=medium * CVE-2023-2088: Unauthorized volume access through deleted volume diff -Nru python-glance-store-4.1.0/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch python-glance-store-4.1.1/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch --- python-glance-store-4.1.0/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch 2023-05-12 08:52:34.0 +0200 +++ python-glance-store-4.1.1/debian/patches/CVE-2023-2088_Add_force_to_os-brick_disconnect.patch 1970-01-01 01:00:00.0 +0100 @@ -1,94 +0,0 @@ -Author: Brian Rosmaita -Date: Tue, 18 Apr 2023 11:22:27 -0400 -Description: CVE-2023-2088: Add force to os-brick disconnect - In order to be sure that devices are being removed from the host, - we should be using the 'force' parameter with os-brick's - disconnect_volume() method. -Bug: https://launchpad.net/bugs/2004555 -Change-Id: I63d09ad9ef465bc154c85a9ea125449c039d1b90 -Bug-Debian: https://bugs.debian.org/1035978 -Origin: upstream, https://review.opendev.org/c/openstack/glance_store/+/882853 -Last-Update: 2023-05-12 - -diff --git a/glance_store/_drivers/cinder.py b/glance_store/_drivers/cinder.py -index 3509348..7405b7a 100644 a/glance_store/_drivers/cinder.py -+++ b/glance_store/_drivers/cinder.py -@@ -831,7 +831,10 @@ - client, attachment.id, volume_id, host, conn, - connection_info, device) - else
Bug#1070682: Please update to inih 58
Source: libinih Version: 57-1 Severity: normal Hi, Please upgrade this package to version 58. It contains the function ini_parse that I need for upgrading to the latest version of lenovolegionlinux. Cheers, Thomas Goirand (zigo)
Bug#1064401: python-requests-kerberos: please package version 0.14
Hi, FYI, version 0.14 needs python-pyspnego that I'm going to package. Cheers, Thomas Goirand (zigo)
Bug#1070477: RM: freezer-api -- ROM; unmaintained upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: freezer-...@packages.debian.org Control: affects -1 + src:freezer-api Hi, freezer was already removed from Debian, let's also remove freezer-api. Cheers, Thomas Goirand (zigo)
Bug#1070292: Dep removed from python-influxdb-client
I've uploaded the fix to python-influxdb-client. Thomas
Bug#1070223: RM: python-ara -- ROM; unmaintained package
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-...@packages.debian.org Control: affects -1 + src:python-ara Hi, I went to see with Michal Arbet, the current maintainer of the package, how he could fix the current open bugs, and he has no time for it. He agreed for this package to be removed, rather then having it bitrot in Unstable. Please remove python-ara from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070222: RM: sahara -- ROM; unmaintained upstream, RC buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sah...@packages.debian.org Control: affects -1 + src:sahara Hi, Sahara FTBFS (unit tests failures), and is unmaintained upstream. It's time to get it removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070061: RM: python-ospurge -- ROM; unmaintained upstream, RC buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, This package needs to be removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#1070060: RM: networking-mlnx -- ROM; unmaintained upstream, FTBFS
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, networking-mlnx is unmaintained upstream, probably because there's better options these days (like networking-generic-switch). Please remove networking-mlnx from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, Narcis Garcia wrote: > Could you review this patch for pre-wget phase, so it considers that a > NIC succeeds whet it acquires default gateway address? Checking if a NIC has a default gateway interface is not the right way to check if that nick should be in use. There are some configurations where it's ok that there would be *NO* default gateway. This is a perfectly valid DHCP setup. The only way to check if it worked, is simply what's done right now: check if dhclient gets an IP address. This part isn't even in the patch itself, the only thing that this patch does, is listing the cards with the link up, to pass it to the next step (ie: dhcp), which this patch doesn't touch (it's written properly already, and works with multiple network interface in the DEVICES= variable in /conf/param.conf). So there's IMO nothing more to do in this patch. Cheers, Thomas Goirand (zigo)
Bug#1070045: RM: heat-cfntools -- ROM; unmaintained upstream, RC buggy
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: heat-cfnto...@packages.debian.org Control: affects -1 + src:heat-cfntools Hi, heat-cfntools depends on boto (ie: not boto3, so the version of the lib which is unmaintained), and has lost support from upstream. So it's time to get it removed from Debian. Cheers, Thomas Goirand (zigo)
Bug#1066842: Updating extrepo-offline-data in Debian Stable (debdiff)
Hi Jonathan, I have removed the +1 from version number as you mentioned, and uploaded to bookworm. Please accept the package. Jonathan wrote: > Is this actually a backport of current unstable though? In which case > it should include the changelog from 1.0.4 and be 1.0.4~deb12u1. It is *not* a backport of the entire 1.0.4 package as per in Unstable, as it would have include changes in non-data parts of the package. As I wrote earlier, I've simply copied the "repos" data-only folder from 1.0.4, and made a new 1.0.3+deb12u1 with it, to avoid unwanted / dangerous / untested changes. Thanks for accepting this update, Cheers, Thomas Goirand (zigo)
Bug#1069712: RM: murano-dashboard -- ROM; unmaintained, CVE
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: murano-dashbo...@packages.debian.org Control: affects -1 + src:murano-dashboard Hi, As we're removing murano (see the other bug report about it for murano removal), we should also remove murano-dashboard. Cheers, Thomas Goirand (zigo)
Bug#1069711: RM: murano -- ROM; unmaintained, CVE
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: mur...@packages.debian.org Control: affects -1 + src:murano Hi, Murano appears unmaintained upstream, and should be removed asap from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069673: RM: openstack-nose -- ROM; obsolete, nose removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: openstack-n...@packages.debian.org Control: affects -1 + src:openstack-nose Hi, Swift was the only use of this plugin, but I have just uploaded removing that build-depends from Swift, so this package can go. Please remove openstack-nose from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069277: RM: python-nose-exclude -- ROM; obsolete, unused
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nose-excl...@packages.debian.org Control: affects -1 + src:python-nose-exclude Hi, The last reverse dependency for python-nose-exclude was watcher-dashboard, but I fixed this. So python-nose-exclude can be removed from Debian as well, continuing the effort to remove nose from Debian. Cheers, Thomas Goirand (zigo)
Bug#1069276: RM: python-nose-parameterized -- ROM; obsolete, unused
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nose-parameteri...@packages.debian.org Control: affects -1 + src:python-nose-parameterized Hi, Once python-nose-timer is removed from the archive (see its matching bug), then python-nose-parameterized can go as well, continuing the archive-wide effort to remove nose from the archive. Cheers, Thomas Goirand (zigo)
Bug#1069239: RM: python-nosehtmloutput -- ROM; obsolete, nose removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nosehtmlout...@packages.debian.org Control: affects -1 + src:python-nosehtmloutput Hi, As we're trying to remove nose from Debian, this package should be removed as well. Cheers, Thomas Goirand (zigo)
Bug#1069238: RM: python-nose-timer -- ROM; obsolete, nose removal
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-nose-ti...@packages.debian.org Control: affects -1 + src:python-nose-timer Hi, As we're trying to remove nose, and this package has no reverse depends, it's time to remove python-nose-timer. Cheers, Thomas Goirand (zigo)
Bug#1069230: ITP: python-sherlock -- distributed inter-process locks with a choice of backend
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-sherlock Version : 0.4.1 Upstream Contact: Vaidik Kapoor * URL : https://github.com/py-sherlock/sherlock * License : Expat Programming Lang: Python Description : distributed inter-process locks with a choice of backend Sherlock is a library that provides easy-to-use distributed inter-process locks and also allows you to choose a backend of your choice for lock synchronization. Note: this is a new dependency of magnum-cluster-api OpenStack module.
Bug#1069229: ITP: python-haproxyadmin -- work with HAProxy via the stats socket
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-haproxyadmin Version : 0.2.4 Upstream Contact: Pavlos Parissis * URL : https://github.com/unixsurfer/haproxyadmin * License : Apache-2.0 Programming Lang: Python Description : work with HAProxy via the stats socket Haproxyadmin is a Python library for interacting with HAProxy load balancer to perform operations such as enabling/disabling servers. It does that by issuing the appropriate commands over the stats socket provided by HAProxy. It also uses that stats socket for retrieving statistics and changing settings. Note: this is a new dependency of the magnum-cluster-api module for OpenStack.
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, If there's 10 NICs with a working dhcpd, only one will be configured (the first one), so that the live OS can fetch the squashfs. The fact that all 10 NICs will be configured with an IP address depends on what you put in the live image. By default, I believe all will be configured when the system is up, but *not* at the squashfs wget phase. So, what I'm fixing with this patch, is just the pre-wget phase, so that it tries all NICs. When the first one succeeds, the scripts don't attempt to get DHCP from another NIC at this stage. That's not different from the past behavior though. I hope you understood and I explained well enough this time! :) Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, With my patch, the first NIC that gets an IP address from DHCP will be used. All NICs will be tried one by one, with the default 15 seconds timeout. The order of NICs stays the same as before, as in: the first NIC that gets a link up will be tried first. So there's no regression possible. Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi Narcis, The current behavior is that live-boot will attempt DHCP from the first NIC that is detected with link up. Cheers, Thomas Goirand (zigo)
Bug#1069052: FTBFS with SQLAlchemy 2.x
Source: gertty Version: 1.6.0-1 Severity: important Tags: patch Hi, As per subject, there's a patch upstream here to fix this bug: https://review.opendev.org/c/ttygroup/gertty/+/880123 Cheers, Thomas Goirand (zigo)
Bug#1069048: live-boot fails to DHCP on all NICs with link up
Package: live-boot
Version: 1:20230131
Severity: important
Tags: patch
Hi,
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. On each run, as soon as there
is one interface with link up, the script will exit, leaving no time
for other NICs to be up in any eventual subsequent run.
This only works if:
- one is lucky
- if only the interfaces with DHCP have an actual ethernet link.
For cases where there is more than one interface with the link up,
but only one is connected to a DHCPd server, it is possible that it
will fail (depending which card will have the link first).
The attached patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
We've tested this patch in production, with such a case where it
was failing (ie: our 25Gbits/s cards were detected first, but were not
connected to a DHCP server, while the 1Gbits/s cards that were supposed
to be holding the network boot were never tried by live-boot). And
this patch fixed things for us.
Please merge this patch if you feel like it's correct. I also would
like to have it fixed in Stable if possible (once I have the approval
from the team).
Cheers,
Thomas Goirand (zigo)
P.S: If one would like to test it, the easiest way is to build a
Debian live the normal way, then unpack the ramdisk with cpio with
something like this:
zstdcat | | cpio -idmv
Then recompress like this:
find . | cpio --create --format='newc' | zstd >
If running an older version of Debian, replacing zstdcat by zcat and
zstd by "gzip -9" also works.
>From 899aa9e8625570137fc57c4ed675bcb090119ace Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 15 Apr 2024 15:40:46 +0200
Subject: [PATCH] Do DHCP on multiple interfaces
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. If there is more than one
interface, but only one is found during a run, then it currently
gives-up searching for other interfaces and exits.
This works if one is lucky, or if only the interfaces with DHCP
have an actual ethernet link. For cases where there is more than
one interface with the link up, but only one is connected to a
DHCPd server, it is possible that it will fail (depending which
card will have the link first).
This patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
---
components/9990-select-eth-device.sh | 68
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a/components/9990-select-eth-device.sh
b/components/9990-select-eth-device.sh
index b660a3d..719a234 100755
--- a/components/9990-select-eth-device.sh
+++ b/components/9990-select-eth-device.sh
@@ -93,46 +93,56 @@ Select_eth_device ()
fi
found_eth_dev=""
- while true
+ echo -n "Looking for a connected Ethernet interface."
+
+ for interface in $l_interfaces
do
- echo -n "Looking for a connected Ethernet interface ..."
+ # ATTR{carrier} is not set if this is not done
+ echo -n " $interface ?"
+ ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
+ sleep 1
+ done
+
+ echo ''
+ for step in 1 2 3 4 5
+ do
for interface in $l_interfaces
do
- # ATTR{carrier} is not set if this is not done
- echo -n " $interface ?"
- ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
- sleep 1
- done
-
- echo ''
+ # Skip the interface if it's already found.
+ IN_IT=no
+ for DEV in $found_eth_dev ; do
+ if [ "${DEV}" = "$interface" ] ; then
+ IN_IT=yes
+ fi
+ done
- for step in 1 2 3 4 5
- do
- for interface in $l_interfaces
- do
+ if [ "${IN_IT}" = "no" ] ; then
ip link set $interface up
carrier=$(cat /sys/class/net/$interface/carrier
\
2>/dev/null)
# link detected
-
-
Bug#1068377: python-oslo.messaging: please make the build reproducible
Hi Chris, Thanks for your patch. However, a better patch would be to use the sample_default= directive of oslo.config, which is printing in the generated doc, whatever the value of sample_default, while continuing to keep the default= value that can contain something programmatic. This avoids writing the "if blah is None" as you've put it. I've sent this upstream and patched olso.messaging accordingly. Cheers, Thomas Goirand (zigo)
Bug#970021: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)
On 3/25/24 19:17, Julian Gilbey wrote: Hi all, [NB: sent to d-science, d-python, d-devel and the RFP bug; reply-to set to d-science and the RFP bug only] An update on Apache Arrow, and in particular the Python library PyArrow. For those who don't know: Apache Arrow is a development platform for in-memory analytics. It contains a set of technologies that enable big data systems to process and move data fast. It specifies a standardized language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The project is developing a multi-language collection of libraries for solving systems problems related to in-memory analytical data processing. This includes such topics as: * Zero-copy shared memory and RPC-based data movement * Reading and writing file formats (like CSV, Apache ORC, and Apache Parquet) * In-memory analytics and query processing (from: https://arrow.apache.org/docs/index.html) Pandas has announced that Pandas 3.x will depend on PyArrow in a critical way (it will back the "string" datatype), and it is due to be released imminently. So this is a plea for anyone looking for something really helpful to do: it would be great to have a group of developers finally package this! There was some initial work done (see the RFP bug report for details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021), but that is fairly old now. As Apache Arrow supports numerous languages, it may well benefit from having a group of developers with different areas of expertise to build it. (Or perhaps it would make more sense to split the upstream source into a collection of different Debian source packages for the different supported languages. I don't know.) Unfortunately I don't have the capacity to devote any time to it myself. Thanks in advance for anyone who can step forward for this! Best wishes, Julian Hi, I may not have much available time to help, though I'd love to have Arrow in Debian, as Ceph uses it, and currently use an embedded version. Cheers, Thomas Goirand (zigo)
Bug#1067333: Further investigation
Hi,
I tried rebuilding autosuspend in Sid, and the build lead to this
traceback in Java:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line
223, in html_visit_plantuml
fnames = dict((e, render_plantuml(self, node, e))
File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line
223, in
fnames = dict((e, render_plantuml(self, node, e))
^^
File "/usr/lib/python3/dist-packages/sphinxcontrib/plantuml.py", line
116, in render_plantuml
raise PlantUmlError('error while running plantuml\n\n' +
serr.decode('utf-8'))
sphinxcontrib.plantuml.PlantUmlError: error while running plantuml
Exception in thread "main" java.lang.InternalError:
java.lang.reflect.InvocationTargetException
at
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:87)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at
java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:75)
at
java.desktop/sun.font.SunFontManager.getInstance(SunFontManager.java:248)
at
java.desktop/sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:266)
at
java.desktop/sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:871)
at net.sourceforge.plantuml.Run.forceOpenJdkResourceLoad(Run.java:230)
at net.sourceforge.plantuml.Run.main(Run.java:137)
Caused by: java.lang.reflect.InvocationTargetException
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at
java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:85)
... 7 more
Caused by: java.lang.RuntimeException: Fontconfig head is null, check
your fonts or fonts configuration
at
java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1271)
at
java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:224)
at
java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:106)
at
java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:358)
at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:315)
at
java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
at java.desktop/sun.font.SunFontManager.(SunFontManager.java:315)
at java.desktop/sun.awt.FcFontManager.(FcFontManager.java:35)
at java.desktop/sun.awt.X11FontManager.(X11FontManager.java:56)
... 13 more
so the issue seems to be in PlantUML rather than its sphinxcontrib
wrapper in Python.
Please note that the part that raised the error in Python is probably
broken, but when there's no error when starting PlantUML, the module
should still be ok.
I'm reassigning the bug to PlantUML. Please deal between autosuspend and
PlantUML.
Cheers,
Thomas Goirand (zigo)
Bug#1067063: Fix in experimental
Hi, OpenStack Carcal is about to be released, and the fix must be in the package in Experimental already. Cheers, Thomas Goirand (zigo)
Bug#1067014: accesses internet during build
Source: mapclassify Version: 2.6.1-3 Severity: important Hi, During the build, mapclassify is using intersphinx, which is collecting information from the internet during build. Please remove the intersphinx module from docs/conf.py. Cheers, Thomas Goirand (zigo)
Bug#1067011: ITP: python-observabilityclient -- OpenStack Observability Client
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-observabilityclient Version : 0.1.1 Upstream Contact: OpenStack Foundation * URL : https://infrawatch.github.io/documentation/ * License : Apache-2.0 Programming Lang: Python Description : OpenStack Observability Client observabilityclient is an OpenStackClient (OSC) plugin implementation that implements commands for management of Prometheus. This is a new dependency of OpenStack.
Bug#1066927: ITP: python-momepy -- Urban Morphology Measuring Toolkit
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-momepy Version : 0.7.0 Upstream Contact: Martin Fleischmann * URL : https://github.com/pysal/momepy * License : BSD-3-clause Programming Lang: Python Description : Urban Morphology Measuring Toolkit Momepy is a library for quantitative analysis of urban form - urban morphometrics. It is part of PySAL (Python Spatial Analysis Library) and is built on top of GeoPandas, other PySAL modules, and networkX. Note: this is a new dependency of networkx, so we can continue to build its documentation.
Bug#1066925: ITP: python-contextily -- Context geo-tiles in Python
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-contextily Version : 1.5.2 Upstream Contact: Dani Arribas-Bel * URL : https://github.com/geopandas/contextily * License : BSD-3-clause Programming Lang: Python Description : Context geo-tiles in Python Contextily is a package to retrieve tile maps from the internet. It can add those tiles as basemap to matplotlib figures or write tile maps to disk into geospatial raster files. Bounding boxes can be passed in both WGS84 (EPSG:4326) and Spheric Mercator (EPSG:3857). Note: this is a new build-depends for networkx, so we can continue to build its documentation.
Bug#1066922: ITP: python-mercantile -- Web mercator XYZ tile utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-mercantile Version : 1.2.1 Upstream Contact: Sean Gillies * URL : https://github.com/mapbox/mercantile * License : BSD-3-clause Programming Lang: Python Description : Web mercator XYZ tile utilities The mercantile module provides ul(xtile, ytile, zoom) and bounds(xtile, ytile, zoom) functions that respectively return the upper left corner and bounding longitudes and latitudes for XYZ tiles, a xy(lng, lat) function that returns spherical mercator x and y coordinates, a tile(lng, lat, zoom) function that returns the tile containing a given point, and quadkey conversion functions quadkey(xtile, ytile, zoom) and quadkey_to_tile(quadkey) for translating between quadkey and tile coordinates. Note: This is a new build-dependency for networkx so we can continue to build its documentation.
Bug#1066901: RM: python-reactivex -- ROM; duplicate
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, python-reactivex is a mistake, as there's already a package called python3-rx that contains the same thing. IMO, the issue is the python3-rx package name, as it matches neither the pypi name, or the egg-name, but never mind... :P Sorry for this. Cheers, Thomas Goirand (zigo)
Bug#1066184: ITP: networking-generic-switch -- OpenStack virtual network service - networking-generic-switch
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: networking-generic-switch Version : 7.2.0 Upstream Contact: OpenStack Foundation * URL : https://github.com/openstack/networking-generic-switch * License : Apache-2.0 Programming Lang: Python Description : OpenStack virtual network service - networking-generic-switch Neutron provides an API to dynamically request and configure virtual networks. These networks connect "interfaces" from other OpenStack services (such as vNICs from Nova VMs). The Neutron API supports extensions to provide advanced network capabilities, including QoS, ACLs, and network monitoring. . This package provides the networking-generic-switch ML2 plugin.
Bug#1066089: ITP: python-reactivex -- asynchronous and event-based programs using observable collections
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-reactivex Version : 4.0.4 Upstream Contact: Dag Brattli * URL : http://reactivex.io, https://github.com/ReactiveX/RxPY * License : Expat Programming Lang: Python Description : asynchronous and event-based programs using observable collections This package provides a library for composing asynchronous and event-based programs using observable collections and query operator functions in Python. Using Rx, developers represent asynchronous data streams with Observables, query asynchronous data streams using operators, and parameterize concurrency in data/event streams using Schedulers.
Bug#1066087: ITP: python-influxdb-client -- InfluxDB 2.0 Python client library
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-influxdb-client Version : 1.40.0 Upstream Contact: InfluxData, Inc. * URL : https://github.com/influxdata/influxdb-client-python * License : Expat Programming Lang: Python Description : InfluxDB 2.0 Python client library Client library for use with InfluxDB 2.x and Flux. InfluxDB 3.x users should instead use the lightweight v3 client library (influxdb3-python). InfluxDB 1.x users should use the v1 client library (influxdb-python). For ease of migration and a consistent query and write experience, v2 users should consider using InfluxQL and the v1 client library (influxdb-python). . The API of the influxdb-client is not the backwards-compatible with the old one influxdb-python.
Bug#1065823: ITP: lenovolegionlinux -- CLI and GUI for Lenovo Legion laptops fan and power control
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: lenovolegionlinux Version : 0.0.9 Upstream Contact: johnfanv2 * URL : https://github.com/johnfanv2/LenovoLegionLinux/ * License : GPL-2 Programming Lang: C, Python Description : CLI and GUI for Lenovo Legion laptops fan and power control This package provides a command line interface and a graphical user interface for controlling many power and fan behavior for Lenovo Legion Laptops. It is implemented in Python. . This package also sets fan curve on startup for Lenovo Legion laptops, and apply different profiles if the battery charge is plugged or not.
Bug#1020648: extrepo-data: reproducible builds: "testing" suite resolves differently depending on build date
On 3/8/24 13:20, Wouter Verhelst wrote: I have not yet considered whether we want to provide common updates to stable. Perhaps I should talk to the SRMs about that... If you missed it, I have just opened a thread in debian-release@l.d.o about it. Please join the discussion. Looking at the source of Debian::DistroInfo, there does not currently appear to be a way to ask for information at a given date, but that sounds like a reasonable wishlist for Debian::DistroInfo to provide. Once that's available, updating extrpo-offline-data to use that to build on a source epoch in the past seems like a reasonable course of action to fix this bug. Yes, this sounds like that a better way to fix the issue overall! Indeed. Agreed. Thomas Goirand (zigo)
Bug#1065470: RM: ceph [armel armhf i386] -- ROM; 32 bits not supported upstream, too hard to maintain
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: c...@packages.debian.org Control: affects -1 + src:ceph Hi there! We tried to retain 32 bits support for as long as it was possible in this package, but at this point, we (ie: myself and bzed) believe it's not reasonable to continue with it. There's no CI upstream supporting it, and it becomes increasingly difficult to support these small platforms that don't have enough address space to compile without many tricks. I already filled bugs against reverse dependencies, that were linked against librados-dev or librbd-dev, and at this point, it should be all fixed already. If not, bugs can be raised to serious. Note that Ceph 18.2.x still doesn't build against mips64el, and at this point, I'm not sure we will continue to support it, as I don't have the skills, upstream doesn't support it, and nobody is volunteering for help. I'm not sure how to reach porters for help btw. Cheers, Thomas Goirand (zigo)
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
On 2/27/24 08:07, Bernd Zeimetz wrote: Hi Steve, I would not bother too much, actually I'm winding why ceph was not yet removed from the 32bit architectures. It's just not supported by upstream and although it builds, I would not trust it to work correctly. Bernd Hi Bernd, Well, Ceph 18.2.x was able to build in unstable. It's not anymore, because of the Cython 3.0 transition that made src/pybind/rados/rados.pxd not buildable. Otherwise, I would have upload it... If you know how to fix, please help. All reverse 32 bits use of Ceph must have been removed already from Debian at this point. I believe I did everything else that was needed for 18.2.x to be in good enough shape for Unstable, but I'm a bit stuck on that Cython 3 pb. :/ I've pushed my latest work (ie: upgrading to 18.2.1+ds) to Git... Cheers, Thomas Goirand (zigo)
Bug#1062065: ceph: NMU diff for 64-bit time_t transition
On 1/31/24 10:00, Steve Langasek wrote: Source: ceph Version: 16.2.11+ds-5 Severity: serious Tags: patch pending Justification: library ABI skew on upgrade User: debian-...@lists.debian.org Usertags: time-t Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified ceph as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to have a library transition, which is most easily done by renaming the runtime library package. Since turning on 64-bit time_t is being handled centrally through a change to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is important that libraries affected by this ABI change all be uploaded close together in time. Therefore I have prepared a 0-day NMU for ceph which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. Hi Steve, The time_t transition was only for 32 bits arch support, right? It needs nothing in 64 bits arch. If that's the case, then you can remove Ceph from your list. The Experimental package of Ceph, already lost support for 32 bits, and I asked all reverse dependency maintainers to remove Ceph support on 32 bits arch (this includes various packages like Samba, Qemu, etc.). When I'll have time to work on Ceph again, then I'll upload Ceph 18.2.x from Experimental, and that will mean no 32 bits support for Ceph in Debian anymore. Can you please confirm that I'm right above, so that on my next upload of Ceph 18.2.x to unstable, I can close this bug? Cheers, Thomas Goirand (zigo)
Bug#1064526: Please package upstream release 3.9.0
Source: prettytable Version: 3.6.0-1 Severity: wishlist Hi, The next OpenStack release codename Caracal needs upstream version 3.9.0, could you please upgrade your package to that version? Cheers, Thomas Goirand (zigo)
Bug#1064503: Please pacakge new upstream release 3.2.1
Package: python3-networkx Version: 2.8.8-1 Severity: wishlist Hi Sandro, For the next forthcomming OpenStack Caracal release (due for next month), it needs upstream release 3.2.1. Cloud you please upgrade your package? Thanks in advance, Cheers, Thomas Goirand (zigo)
Bug#1064502: ITP: python-aiounittest -- test asyncio code more easily
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-aiounittest Version : 1.4.2 Upstream Contact: Krzysztof Warunek * URL : https://github.com/kwarunek/aiounittest * License : Expat Programming Lang: Python Description : test asyncio code more easily The aiounittest is a helper library to ease of your pain (and boilerplate), when writing a test of the asynchronous code (:code:`asyncio`). With this library, it is possible to test: * synchronous code (same as the unittest.TestCase from the std lib) * asynchronous code: it supports syntax like async/await (Python 3.5+) and asyncio.coroutine/yield from (Python 3.4). Note: this is a new build-dependency for python-ddt, which is used for testing OpenStack.
Bug#1064501: Please package new upstream release 1.60.1
Package: python3-grpcio Version: 1.54.0 Severity: wishlist Hi Laszlo, For the next OpenStack release (codename: Caracal), python3-tooz needs the new python3-grpcio 1.60.1 from upstream. Could you please package this new release, or alternatively, allow me to do so? Please let me know. Cheers, Thomas Goirand (zigo)
Bug#1064275: autopkgtest failure with python-jsonschema 4.19.2
Source: asdf-standard Version: 1.0.3-1 Severity: serious Hi, as per this: https://qa.debian.org/excuses.php?experimental=1=python-jsonschema your package has autopkgtest regressions. Since python-jsonschema was staged in Experimental for so long, I'm uploading it to unstable, making this bug severity serious. Cheers, Thomas Goirand (zigo)
Bug#1063899: ITP: auxilium -- tool for parse args in many shell (bash, ksh,zsh)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: auxilium Version : 0.0.9 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/auxilium * License : Apache-2.0 Programming Lang: Bash Description : tool for parse args in many shell (bash, ksh,zsh) This help you to parse command-line arguments. You can source it in your shell script and use different function to add argument, print usage and parse arguments
Bug#1063854: RM: senlin -- ROM; unmaintained
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sen...@packages.debian.org Control: affects -1 + src:senlin Hi, As per this document: https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html Senlin is unmaintained and inactive. Let's remove it from Debian. Cheers, Thomas Goirand (zigo)
Bug#1063848: RM: sahara -- ROM; unmaintained upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: sah...@packages.debian.org Control: affects -1 + src:sahara Hi, As per this document: https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html Sahara is inactive and unmaintained. Let's remove it from Debian. Cheers, Thomas Goirand (zigo)
Bug#1063850: RM: freezer -- ROM; unmaintained
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: free...@packages.debian.org Control: affects -1 + src:freezer As per this document: https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html Freezer is inactive and unmaintained. Please remove it from Debian. That's 2 source packages: - freezer - freezer-api Cheers, Thomas Goirand (zigo)
Bug#1063849: RM: monasca-api\ -- ROM; unmaintained
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, As per this document: https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html Monasca is unmaintained and inactive. Let's remove it from Debian. That's 2 source packages: - monasca-api - monasca-common Cheers, Thomas Goirand (zigo)
Bug#1026224: [patch] live-build: Option "-b netboot" fails on arm64 architecture
Hi!
This simple patch fixes the issue. I tried opening an MR on Salsa but it
seems Salsa has some issues currently (going to the merge request page
after the push leads to an error 500-something).
Cheers,
Thomas Goirand (zigo)
diff --git a/scripts/build/binary_netboot b/scripts/build/binary_netboot
index c88bc6296..d74a118f2 100755
--- a/scripts/build/binary_netboot
+++ b/scripts/build/binary_netboot
@@ -50,6 +50,7 @@ ROOT_DIR=${LB_MODE}-live
mv binary ${ROOT_DIR}
mkdir binary.tmp
+mkdir -p tftpboot
mv ${ROOT_DIR} tftpboot binary.tmp
cd binary.tmp
Bug#1061390: iwlwifi: crash when disabling wifi
Source: linux Version: 6.1.69-1 Severity: important Hi, In some cases, when I disable wifi with the network manager GUI (ie: right click, "Enable Wifi" to disable it), my iwlwifi driver crashes, with the crash dump attached to this bug report. When this happen, then my network stack is kind of completely broken, and I have to reboot. Let me know what I can do to improve this bug report. Maybe install the debug kernel? Cheers, Thomas Goirand (zigo) [114704.251050] iwlwifi :6f:00.0: RF_KILL bit toggled to disable radio. [114704.251053] iwlwifi :6f:00.0: reporting RF_KILL (radio disabled) [114704.265509] wlp111s0: deauthenticating from f0:9f:c2:ff:9f:62 by local choice (Reason: 3=DEAUTH_LEAVING) [114706.269470] iwlwifi :6f:00.0: fail to flush all tx fifo queues Q 5 [114706.271154] iwlwifi :6f:00.0: Queue 5 is active on fifo 3 and stuck for 1 ms. SW [5, 6] HW [6, 6] FH TRB=0x080305005 [114708.273433] iwlwifi :6f:00.0: fail to flush all tx fifo queues Q 5 [114708.274068] iwlwifi :6f:00.0: Queue 5 is active on fifo 3 and stuck for 1 ms. SW [5, 6] HW [6, 6] FH TRB=0x080305005 [114708.274125] [ cut here ] [114708.274127] WARNING: CPU: 0 PID: 80864 at net/mac80211/sta_info.c:1297 __sta_info_destroy_part2+0x12e/0x160 [mac80211] [114708.274291] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device tun ctr ccm rfcomm xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype iptable_filter br_netfilter bridge stp llc cpufreq_ondemand cpufreq_userspace cpufreq_conservative cpufreq_powersave scsi_transport_iscsi nvme_fabrics cmac algif_hash algif_skcipher af_alg overlay qrtr bnep snd_hda_codec_hdmi snd_sof_pci_intel_cnl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp binfmt_misc snd_sof xfs snd_sof_utils nls_ascii soundwire_bus nls_cp437 snd_soc_skl vfat squashfs fat snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_acpi_intel_match snd_soc_acpi iwlmvm snd_ctl_led snd_soc_core x86_pkg_temp_thermal snd_hda_codec_realtek intel_powerclamp btusb coretemp snd_hda_codec_generic btrtl snd_compress [114708.274367] mac80211 btbcm snd_hda_intel btintel snd_intel_dspcfg kvm_intel btmtk snd_intel_sdw_acpi dell_rbtn bluetooth libarc4 snd_hda_codec kvm uvcvideo snd_hda_core jitterentropy_rng snd_hwdep videobuf2_vmalloc dell_laptop iwlwifi snd_pcm_oss irqbypass videobuf2_memops ledtrig_audio dell_wmi drbg snd_mixer_oss videobuf2_v4l2 processor_thermal_device_pci_legacy joydev mei_hdcp mei_wdt rapl processor_thermal_device dell_smbios intel_rapl_msr ansi_cprng dell_smm_hwmon snd_pcm videobuf2_common iTCO_wdt cfg80211 processor_thermal_rfim intel_cstate ucsi_acpi dcdbas dell_wmi_sysman ecdh_generic processor_thermal_mbox snd_timer intel_pmc_bxt intel_uncore videodev processor_thermal_rapl mei_me dell_wmi_descriptor typec_ucsi firmware_attributes_class pcspkr roles iTCO_vendor_support snd intel_rapl_common intel_wmi_thunderbolt wmi_bmof mc watchdog rfkill ee1004 soundcore mei ecc typec int3403_thermal intel_soc_dts_iosf int3400_thermal intel_hid intel_pch_thermal int340x_thermal_zone [114708.274434] dell_smo8800 ac intel_pmc_core acpi_thermal_rel acpi_pad sparse_keymap hid_multitouch evdev serio_raw msr i2c_dev parport_pc ppdev lp parport fuse loop efi_pstore configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_compress usbhid dm_crypt dm_mod efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod i915 crc32_pclmul drm_buddy crc32c_intel i2c_algo_bit nvme drm_display_helper ghash_clmulni_intel sha512_ssse3 nvme_core cec ahci sha512_generic hid_generic t10_pi rc_core rtsx_pci_sdmmc libahci sha256_ssse3 xhci_pci crc64_rocksoft_generic ttm sha1_ssse3 crc64_rocksoft xhci_hcd libata crc_t10dif mmc_core drm_kms_helper crct10dif_generic usbcore intel_lpss_pci i2c_hid_acpi aesni_intel scsi_mod i2c_i801 i2c_hid video crct10dif_pclmul crypto_simd intel_lpss crc64 cryptd drm e1000e i2c_smbus rtsx_pci crct10dif_common scsi_common idma64 usb_common [114708.274507] hid battery wmi button [114708.274511] CPU: 0 PID: 80864 Comm: kworker/0:0 Tainted: G X 6.1.0-17-amd64 #1 Debian 6.1.69-1 [114708.274514] Hardware name: Dell Inc. Precision 7530/0C1D71, BIOS 1.29.1 07/05/2023 [114708.274516] Workqueue: events cfg80211_rfkill_block_work [cfg80211] [114708.274576] RIP: 0010:__sta_info_destroy_part2+0x12e/0x160 [mac80211] [114708.274631] Code: bb d4 00 00 00 00 0f 84 71 ff ff ff 45 31 c0 b9 01 00 00 00 48 89 da 4c 89 e6 48 89 ef e8 2a 94 ff ff 85 c0 0f 84 53 ff ff ff <0f> 0b e9 4c ff ff ff be 03 00 00 00 48 89 df e8 be e9 ff ff 85 c0 [114708.274634] RSP: 0018:
Bug#1058099: pyro4: FTBFS: AttributeError: 'CoreTests' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? debdiff for NMU
Hi Laszlo,
Please see attached diff to fix the issue. It's kind of trivial to fix,
as you may see... Could you please upload it to unstable ASAP, or allow
me to NMU this fix?
Cheers,
Thomas Goirand (zigo)diff -Nru pyro4-4.82/debian/changelog pyro4-4.82/debian/changelog
--- pyro4-4.82/debian/changelog 2023-11-06 17:31:51.0 +0100
+++ pyro4-4.82/debian/changelog 2024-01-11 16:43:48.0 +0100
@@ -1,3 +1,11 @@
+pyro4 (4.82-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS by adding a patch:
+- use-self.assertEqual-not-self.assertEquals.patch (Closes: #1058099).
+
+ -- Thomas Goirand Thu, 11 Jan 2024 16:43:48 +0100
+
pyro4 (4.82-3) unstable; urgency=medium
* Fix FTBFS with Sphinx 7.1 (closes: #1042648).
diff -Nru pyro4-4.82/debian/patches/series pyro4-4.82/debian/patches/series
--- pyro4-4.82/debian/patches/series2023-01-02 21:48:48.0 +0100
+++ pyro4-4.82/debian/patches/series2024-01-11 16:36:09.0 +0100
@@ -1,2 +1,3 @@
skip_networked_tests.patch
fix-ftbfs-python3.11.patch
+use-self.assertEqual-not-self.assertEquals.patch
diff -Nru
pyro4-4.82/debian/patches/use-self.assertEqual-not-self.assertEquals.patch
pyro4-4.82/debian/patches/use-self.assertEqual-not-self.assertEquals.patch
--- pyro4-4.82/debian/patches/use-self.assertEqual-not-self.assertEquals.patch
1970-01-01 01:00:00.0 +0100
+++ pyro4-4.82/debian/patches/use-self.assertEqual-not-self.assertEquals.patch
2024-01-11 16:39:05.0 +0100
@@ -0,0 +1,17 @@
+Description: Use self.assertEqual not self.assertEquals
+Author: Thomas Goirand
+Bug-Debian: https://bugs.debian.org/1058099
+Forwarded: no
+Last-Update: 2024-01-11
+
+--- pyro4-4.82.orig/tests/PyroTests/test_core.py
pyro4-4.82/tests/PyroTests/test_core.py
+@@ -359,7 +359,7 @@ class CoreTests(unittest.TestCase):
+ with self.assertRaises(Pyro4.errors.PyroError):
+ Pyro4.Proxy("test")
+ with Pyro4.Proxy("test", connected_socket=s1) as p:
+-self.assertEquals("<>:0",
p._pyroUri.location)
++self.assertEqual("<>:0",
p._pyroUri.location)
+ self.assertIsNotNone(p._pyroConnection)
+ p._pyroRelease()
+ self.assertIsNotNone(p._pyroConnection)
Bug#1058794: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On 1/4/24 00:30, Alexandre Detiste wrote: Le lun. 11 déc. 2023 à 16:43, Andreas Tille a écrit : Control: tags -1 help [Bug #1056419 in CC since the issue seems to be caused by python-future] Hi Vincent, I tried to upgrade python-future to the latest upstream version in the hope that this would solve the issue reported in bug #1042244. Unfortunately this is not the case and now with Python3.12 we also have to deal with the removal of imp (which affects bug #1056419). I'd like to ask for help on debian-python list since I'm pretty overworked with other stuff. Please also review my rude patch[1] to hack around a shinx issue. It would be great to have some better solution here. The better solution is to remove python3-future altogether. I very much agree with this. Most of the time, it's simply patching out stuff like: from __future__ import in every .py of the package, and you're done. So it's quite easy to do. As we removed Python 2.7 2 releases ago, it's probably a good time to finish the transition... :) Cheers, Thomas Goirand (zigo)
Bug#1058318: flask-login: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
On 1/3/24 22:22, Julian Gilbey wrote: On Fri, Dec 22, 2023 at 12:04:48AM +0100, Gregor Riepl wrote: Hi Carsten, [...] My point was that if, for whatever reason, werkzeug 3.0.1 is not yet fit for release, it should be enough to upgrade to 2.3.5 to address these unit test failures. [...] That doesn't make any sense to me. These deprecations are obviously in werkzeug and not flask-login. Why would changes in flask-login fix them? Not saying flask-login shouldn't be updated, but that's not the right scope for this bug report. Just to throw in: these werkzeug failures are also causing a similar FTBFS in debugpy; I've temporarily addressed it by skipping these unit tests, but that's not a great solution. I just took a quick look at upgrading the unstable/testing version of werkzeug to 2.3.8 in the meantime. It was pretty quick, and the package tests all pass. Shall I upload it to unstable? On salsa, I would push to debian/2.x for the Debian branch and to upstream-2.x for the upstream, so as not to prevent merging the experimental branch into debian/master later. Actually, it is probably OK to use the upstream branch for this update without causing problems, but might be better to be safe. (Incidentally, while doing this, I spotted one bug with the current experimental version: it is missing a Build-Depends on python3-markupsafe.) Best wishes, Julian Hi Julian, I do not agree with Casten here. Please do upload 2.3.8 to unstable if it fixes things, so we have time to address all the Python 3.12 issues right now. Please hold on uploading 3.x (as well as werkzeug) if this can wait, because we need to address all the Python 3.12 issues first, and now is not a good time to transition any other components. Upgrading flask+werkzeug is *NOT* urgent. Fixing all 3.12 issues must be our current priority. Cheers, Thomas Goirand (zigo)
Bug#1059614: ITP: ikvswitch -- virtual switch infrastructure designed for complex network deployment testing
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ikvswitch Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/debian/ikvswitch * License : Apache-2.0 Programming Lang: Shell Description : virtual switch infrastructure designed for complex network deployment testing This package sets up virtual machines that will act as 2 spine switches and 3 racks with 2 leaf switches each, to simulate a datacenter setup. All 8 switches are connected to each other over un-numbered IPv6 link-local addresses over which a BGP link is established (ie: this is a bgp-to-the-host setup, or L3 only networking). . Once setup, it is possible for the user to connect virtual machines to this virtual infrastructure. Each VM can be connected to 2 rack switches over BGP as well. . The goal of this package is to be able to experiment with virtual machines, as if they were physical machines installed into 3 physical racks, with this type of L3 connectivity only. Note: I'm planning to use this for testing complex OpenStack networking setup, but that's far from being the only use case: this is very general purpose.
Bug#1058927: live-build doesn't create tftpboot under arm64 and fails
Package: live-build Version: 1:20230502 Severity: important Hi, Under Bookworm, when doing lb build after lb config this way: lb config -b netboot [...] lb build fails to create the tftpboot folder, which it cleans when starting. As a result, lb build just fails with "tftpboot: no such file or directory" (something like that). I tried under Bookworm, not sure if this is also in Unstable. Note that I've seen this behavior only under arm64, not in x86. So something must be wrong under this arch... Cheers, Thomas Goirand (zigo)
Bug#1058219: Fix pending
Hi, The "slice(0, -1, None)" failed unit tests are due to #1058895 in SQLAlchemy, and for the has_calls -> assert_has_calls I have a patch locally, but can't upload unless SQLAlchemy is fixed. Cheers, Thomas Goirand (zigo)
Bug#1058162: Fixed, but waiting on sqlalchemy
Hi, There's a bunch of tests failing because of #1058895 in SQLAlchemy, the remaining 2 unit test failures, I have a patch for them, but this needs for SQLAlchemy to be fixed before I can upload. Cheers, Thomas Goirand (zigo)
Bug#1058895: python 3.12 slices are hashable, affects one area of Row for 1.4 only
Package: python3-sqlalchemy Version: 1.4.46+ds1-1 Severity: serious Hi, SQLAlchemy 1.4.47+ds1-1 in unstable is affected by this upstream bug: https://github.com/sqlalchemy/sqlalchemy/issues/9819 Latest upstream release for 1.4.x (ie: 1.4.50). I tried building it locally, and rebuild affected packages (for OpenStack), and this fixes these bugs (or at least, it's part of solving these bugs as there are also other issues unrelated): https://bugs.debian.org/1058183 (barbican) https://bugs.debian.org/1058123 (neutron-vpnaas) (FTBFS reported fixed by eventlet, but package affected by this bug) https://bugs.debian.org/1058219 (senlin) https://bugs.debian.org/1058233 (sahara) https://bugs.debian.org/1058531 (heat) (some other failures, but also affected) There's probably more (I didn't attempt to rebuild all affected packages yet), but these are 5 examples of packages that FTBFS because of this problem. It'd be nice if we could have the patch in Unstable with this series 1.4.x before uploading 2.x, so that I have a chance to fix all Python 3.12 bugs and not mix SQLA 2.x and Py 3.12 problems. Cheers, Thomas Goirand (zigo)
Bug#1058097: python-openstackclient: FTBFS: AttributeError: module 'sys' has no attribute 'builtin_module_names'
I'm not getting what's been reported, but this now: File "", line 1360, in _find_and_load File "", line 1331, in _find_and_load_unlocked File "", line 935, in _load_unlocked File "", line 1176, in exec_module File "", line 58, in AttributeError: module 'sys' has no attribute 'byteorder' Working on it... Though is it possible that this is a bug in the interpreter itself? Cheers, Thomas Goirand (zigo)
Bug#1058315: python3-nose: from nose.tools import assert_equals, assert_raises FAILS
Hi, As you may see by the reassigned bug, doing this: from nose.tools import assert_equals, assert_raises fails under Python 3.12, when it works under 3.11. Cheers, Thomas Goirand (zigo)
Bug#1057636: ITP: swift-tools -- Swift cluster cli helpers utilities
On 12/7/23 08:14, Andrea Pappacoda wrote: Hi Thomas, maybe swift-tools is a bit too generic as the name of this package. Well, it is a generic package name, because it contains generic tools for swift, so that's on purpose. And it goes together with "ceph-tools" which we also author. So no, I do not intend to change the package name. The first thing I though when reading it, was a set of tools to help > development with the Swift programming language. Swift, the OpenStack object storage, was invented way before Apple decided to steal this name. Not my fault... Maybe it'd be better to add "openstack" or "cluster" to the package name? Thanks, but no. Swift can be used without OpenStack, and other swift packages don't contain the word "openstack" or "cluster", so it makes no sense to do that. Also, the short description contains the word "cluster". On top of this, there's no mention of the swift language anywhere in Debian, and the Swift stuff from Apple aren't free software so they will *never* be in Debian, so there's no confusion possible. Cheers, Thomas Goirand (zigo)
Bug#1056233: Issue isn't what's described
Hi, The issue described in this bug report is invalid, however, there was another one which I just fixed (adding Fix_invalid_assert_calls.patch). I'll use the same bug report then. Cheers, Thomas Goirand (zigo)
Bug#1058186: Issue likely to be in python3-future
Hi, According to the trace, I can see: > File "/usr/lib/python3/dist-packages/future/standard_library/__init__.py", line 65, in > import imp > ModuleNotFoundError: No module named 'imp' This comes from the python3-future package, not from swiftclient. I tried fixing python3-future for Python 3.12, however, there are other issues that needs to be fixed in that package, so it's harder than just fixing a bad import. I wont be able to tell for sure if swiftclient can build with Python 3.12 until future is fixed. Cheers, Thomas Goirand (zigo)
Bug#1058361: ITP: python-pyasyncore -- asyncore for Python 3.12 onwards
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-pyasyncore Version : 1.0.2 Upstream Contact: Simon Robinson * URL : https://github.com/simonrob/pyasyncore * License : Python Software Foundation License Programming Lang: Python Description : asyncore for Python 3.12 onwards This package contains the asyncore module as found in Python versions prior to 3.12. It is provided so that existing code relying on "import asyncore" is able to continue being used without significant refactoring. . The module's source code is taken directly from the Python standard library. The specific version of asyncore.py used is the last update before the addition of removal warnings at import time, and is essentially equivalent to the version provided with Python 3.9. . Please note that new projects should prefer asyncio. Note that I'm creating this package as a temporary measure to fix some of the 3.12 issues that are ongoing. Projects like Taskflow cannot be easily converted to asyncio, because some other packages are using both Eventlet and Taskflow, and asyncio is not compatible with Eventlet. So we have to live with this for a while more, until Eventlet can be fixed to use asyncio...
Bug#1043240: transition: pandas 1.5 -> 2.1
On 12/11/23 08:12, Matthias Klose wrote: On 10.12.23 14:06, Rebecca N. Palmer wrote: I'd like to move forward with the pandas 1.5 -> 2.1 transition reasonably soon. Given that pandas 2.x is *not* required for Python 3.12 (but is required for Cython 3.0), should we wait for the Python 3.12 transition to be done first? These are broken by pandas 2.x and have a possible (but untested) fix in their bug - please test and apply it: dask(?) dials influxdb-python* python-altair python-feather-format python-upsetplot seaborn tqdm* (* = this package is currently also broken for a non-pandas reason, probably Python 3.12, that I don't have a fix for) These are broken by pandas 2.x and have no known-to-me fix: augur cnvkit dyda emperor esda mirtop pymatgen pyranges python-anndata python-biom-format python-cooler python-nanoget python-skbio python-ulmo q2-quality-control q2-demux q2-taxa q2-types q2templates sklearn-pandas Some generic things to try are pandas.util.testing -> pandas.testing, .iteritems() -> .items(), and if one exists, a more recent upstream version. Is this an acceptable amount of breakage or should we continue to wait? Bear in mind that if we wait too long, we may be forced into it by some transition further up the stack (e.g. a future Python or numpy) that breaks pandas 1.x. up to the maintainers. But please wait at least until the current pandas and numpy migrated to testing, e.g. that the autopkg tests of pandas and numpy triggered by python3-defaults pass. Is there a way to see the binNMUs which are still stuck in unstable, and don't migrate? Matthias As a reminder: it's best practice to first upload the new release to Experimental, so we can see what happens with autopkgtest before destroying everything at once... Cheers, Thomas Goirand (zigo)
Bug#1057666: Please add bash-completion to vboxmanage
Package: virtualbox Version: 7.0.6-dfsg-1~bpo12+1 Severity: wishlist Tags: patch Hi there! Thanks for maintaining Virtualbox! I noticed that there's no bash-completion for the vboxmanage utility, which is kind of frustrating, and make the CLI unnecessarily hard to use. FYI, there's one bash-completion script available here, released under the BSD-3-clause license: https://github.com/gryf/vboxmanage-bash-completion It'd be awesome to have it added to the Debian package by default. Cheers, Thomas Goirand (zigo)
Bug#1057636: ITP: swift-tools -- Swift cluster cli helpers utilities
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: swift-tools Version : 0.0.1 Upstream Contact: Philippe Seraphin * URL : https://salsa.debian.org/openstack-team/third-party/swift-tools * License : Apache-2.0 Programming Lang: Python Description : Swift cluster cli helpers utilities This package contains a set of utilities to help managing Swift cluster. It helps, for example: * check rebalance status * check status of the cluster * check max oldest completion
Bug#1057389: ITP: haproxy-cmd -- command line utility to control backends of haproxy
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: haproxy-cmd Version : 0.0.1 Upstream Contact: Thomas Goirand * URL : https://salsa.debian.org/openstack-team/third-party/haproxy-cmd * License : Apache-2.0 Programming Lang: Python Description : command line utility to control backends of haproxy This package contains a helper to send commands through the haproxy socket, so it is possible to maintain servers part of a cluster by draining, enabling and stopping servers part of a backend. . This utility is, in fact, a wrapper around the haproxy admin socket, so it is easier to use, with bash-completion and so on.
Bug#1055516: python3-jsonschema: New upstream version available
Hi, As per this: https://qa.debian.org/excuses.php?experimental=1=python-jsonschema version 4.19 introduces regressions in at least 5 packages... Patches to fix these are warmly welcome. Also, I'm not sure why this same page reports that the package is "uninstallable on arch arm64"... Cheers, Thomas Goirand (zigo)
Bug#1056964: RM: openvswitch [armel armhf i386] -- ROM; not really useful on 32 bits
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: openvswi...@packages.debian.org Control: affects -1 + src:openvswitch Hi, I've uploaded openvswitch removing support for 32 bits. Please remove the package for these arch (am I right that we only have 3x 32 bits remaining these days?). The reason is: dpdk maintainers also want to remove 32 bits support, and for me, it's continuously painful to maintain a list of non-working unit tests that are too much time-sensitive and failing in these slow arch. It also feels like unnecessary effort to continue supporting 32 bits, as it's increasing likely that nobody is using OVS on 32 bits arch. Cheers, Thomas Goirand (zigo)
Bug#1056723: rabbitmq-server: CVE-2023-46118
On 11/27/23 09:14, Thomas Goirand wrote:
On 11/25/23 13:41, Salvatore Bonaccorso wrote:
Source: rabbitmq-server
Version: 3.10.8-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/rabbitmq/rabbitmq-server/pull/9708
X-Debbugs-Cc: car...@debian.org, Debian Security Team
Hi,
The following vulnerability was published for rabbitmq-server.
CVE-2023-46118[0]:
| RabbitMQ is a multi-protocol messaging and streaming broker. HTTP
| API did not enforce an HTTP request body limit, making it vulnerable
| for denial of service (DoS) attacks with very large messages. An
| authenticated user with sufficient credentials can publish a very
| large messages over the HTTP API and cause target node to be
| terminated by an "out-of-memory killer"-like mechanism. This
| vulnerability has been patched in versions 3.11.24 and 3.12.7.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
Hi,
Please find the attached debdiff to fix Bookworm. I'd very much would
like to upload it to bookworm-security, if the security team agrees, as
anyone with a rabbitmq-server exposed to internet will be vulnerable to
the DOS.
Note that I've uploaded 3.10.8-3 to unstable also fixing this CVE.
Please let me know if you also feel like a DSA should be published, or
if you feel like I should deal with the stable release team,
Cheers,
Thomas Goirand (zigo)
Please also find the Bullseye debdiff attached to this message.
Cheers,
Thomas Goirand (zigo)
diff -Nru rabbitmq-server-3.8.9/debian/changelog
rabbitmq-server-3.8.9/debian/changelog
--- rabbitmq-server-3.8.9/debian/changelog 2021-04-10 22:59:57.0
+0200
+++ rabbitmq-server-3.8.9/debian/changelog 2023-11-27 09:21:56.0
+0100
@@ -1,3 +1,13 @@
+rabbitmq-server (3.8.9-3+deb11u1) bullseye-security; urgency=medium
+
+ * CVE-2023-46118: Denial of Service by publishing large messages over the
+HTTP API. Applied upstream patches that introduce a limit of 10MB:
+- Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
+- Introduce_HTTP_request_body_limit_for_definition_uploads.patch
+(Closes: #1056723).
+
+ -- Thomas Goirand Mon, 27 Nov 2023 09:21:56 +0100
+
rabbitmq-server (3.8.9-3) unstable; urgency=medium
[ Adam Cecile ]
diff -Nru
rabbitmq-server-3.8.9/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
rabbitmq-server-3.8.9/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
---
rabbitmq-server-3.8.9/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
1970-01-01 01:00:00.0 +0100
+++
rabbitmq-server-3.8.9/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
2023-11-27 09:21:56.0 +0100
@@ -0,0 +1,52 @@
+Subject: CVE-2023-46118 (1/2): Reduce default HTTP API request body size limit
to 10 MiB
+ per discussion with the team.
+ .
+ It should be enough to accomodate a definition file with about
+ 100K queues.
+Author: Michael Klishin
+Date: Mon, 16 Oct 2023 06:48:23 -0400
+Bug-Debian: https://bugs.debian.org/1056723
+Origin: upstream,
https://github.com/rabbitmq/rabbitmq-server/pull/9708/commits/c6d0382be4d9b6f4d0ab9466b397e353adfa92e0
+Last-Update: 2023-11-27
+
+Index: rabbitmq-server/deps/rabbitmq_management/Makefile
+===
+--- rabbitmq-server.orig/deps/rabbitmq_management/Makefile
rabbitmq-server/deps/rabbitmq_management/Makefile
+@@ -12,7 +12,8 @@ define PROJECT_ENV
+
+ {cors_allow_origins, []},
+ {cors_max_age, 1800},
+- {content_security_policy, "script-src 'self' 'unsafe-eval'
'unsafe-inline'; object-src 'self'"}
++ {content_security_policy, "script-src 'self' 'unsafe-eval'
'unsafe-inline'; object-src 'self'"},
++ {max_http_body_size, 1000}
+ ]
+ endef
+
+Index:
rabbitmq-server/deps/rabbitmq_management/priv/schema/rabbitmq_management.schema
+===
+---
rabbitmq-server.orig/deps/rabbitmq_management/priv/schema/rabbitmq_management.schema
rabbitmq-server/deps/rabbitmq_management/priv/schema/rabbitmq_management.schema
+@@ -20,6 +20,22 @@
+ {mapping, "management.http_log_dir", "rabbitmq_management.http_log_dir",
+ [{datatype, string}]}.
+
++%% Max HTTP body limit
++{mapping, "management.http.max_body_size",
"rabbitmq_management.max_http_body_size",
++[{datatype, integer}, {validators, ["non_negative_integer"]}]}.
++{translation, "rabbitmq_management.max_http_body_size",
++fun(Conf) ->
++case cuttlefish:conf_get("management.http.max_body_size", Conf,
undefined) of
++%% 20 MiB allows f
Bug#1056723: rabbitmq-server: CVE-2023-46118
On 11/25/23 13:41, Salvatore Bonaccorso wrote:
Source: rabbitmq-server
Version: 3.10.8-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/rabbitmq/rabbitmq-server/pull/9708
X-Debbugs-Cc: car...@debian.org, Debian Security Team
Hi,
The following vulnerability was published for rabbitmq-server.
CVE-2023-46118[0]:
| RabbitMQ is a multi-protocol messaging and streaming broker. HTTP
| API did not enforce an HTTP request body limit, making it vulnerable
| for denial of service (DoS) attacks with very large messages. An
| authenticated user with sufficient credentials can publish a very
| large messages over the HTTP API and cause target node to be
| terminated by an "out-of-memory killer"-like mechanism. This
| vulnerability has been patched in versions 3.11.24 and 3.12.7.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
Hi,
Please find the attached debdiff to fix Bookworm. I'd very much would
like to upload it to bookworm-security, if the security team agrees, as
anyone with a rabbitmq-server exposed to internet will be vulnerable to
the DOS.
Note that I've uploaded 3.10.8-3 to unstable also fixing this CVE.
Please let me know if you also feel like a DSA should be published, or
if you feel like I should deal with the stable release team,
Cheers,
Thomas Goirand (zigo)
diff -Nru rabbitmq-server-3.10.8/debian/changelog
rabbitmq-server-3.10.8/debian/changelog
--- rabbitmq-server-3.10.8/debian/changelog 2022-10-15 12:42:19.0
+0200
+++ rabbitmq-server-3.10.8/debian/changelog 2023-11-27 08:25:34.0
+0100
@@ -1,3 +1,13 @@
+rabbitmq-server (3.10.8-1.1+deb12u1) unstable; urgency=high
+
+ * CVE-2023-46118: Denial of Service by publishing large messages over the
+HTTP API. Applied upstream patches that introduce a limit of 10MB:
+- Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
+- Introduce_HTTP_request_body_limit_for_definition_uploads.patch
+(Closes: #1056723).
+
+ -- Thomas Goirand Mon, 27 Nov 2023 08:25:34 +0100
+
rabbitmq-server (3.10.8-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru
rabbitmq-server-3.10.8/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
rabbitmq-server-3.10.8/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
---
rabbitmq-server-3.10.8/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
1970-01-01 01:00:00.0 +0100
+++
rabbitmq-server-3.10.8/debian/patches/CVE-2023-46118_1_Reduce_default_HTTP_API_request_body_size_limit_to_10_MiB.patch
2023-11-27 08:25:34.0 +0100
@@ -0,0 +1,66 @@
+Subject: CVE-2023-46118 (1/2): Reduce default HTTP API request body size limit
to 10 MiB
+ per discussion with the team.
+ .
+ It should be enough to accomodate a definition file with about
+ 100K queues.
+Author: Michael Klishin
+Date: Mon, 16 Oct 2023 06:48:23 -0400
+Bug-Debian: https://bugs.debian.org/1056723
+Origin: upstream,
https://github.com/rabbitmq/rabbitmq-server/pull/9708/commits/c6d0382be4d9b6f4d0ab9466b397e353adfa92e0
+Last-Update: 2023-11-27
+
+Index: rabbitmq-server/deps/rabbitmq_management/BUILD.bazel
+===
+--- rabbitmq-server.orig/deps/rabbitmq_management/BUILD.bazel
rabbitmq-server/deps/rabbitmq_management/BUILD.bazel
+@@ -36,7 +36,8 @@ APP_ENV = """[
+
+ {cors_allow_origins, []},
+ {cors_max_age, 1800},
+- {content_security_policy, "script-src 'self' 'unsafe-eval'
'unsafe-inline'; object-src 'self'"}
++ {content_security_policy, "script-src 'self' 'unsafe-eval'
'unsafe-inline'; object-src 'self'"},
++ {max_http_body_size, 1000}
+ ]"""
+
+ DEPS = [
+Index: rabbitmq-server/deps/rabbitmq_management/Makefile
+===
+--- rabbitmq-server.orig/deps/rabbitmq_management/Makefile
rabbitmq-server/deps/rabbitmq_management/Makefile
+@@ -12,7 +12,8 @@ define PROJECT_ENV
+
+ {cors_allow_origins, []},
+ {cors_max_age, 1800},
+- {content_security_policy, "script-src 'self' 'unsafe-eval'
'unsafe-inline'; object-src 'self'"}
++ {content_security_policy, "script-src 'self' 'unsafe-eval'
'unsafe-inline'; object-src 'self'"},
++ {max_http_body_size, 1000}
+ ]
+ endef
+
+Index:
rabbitmq-server/deps/rabbitmq_management/priv/schema/rabbitmq_management.schema
+===
+---
rabbitmq-server.orig/deps/rabbitmq_management/priv/schema/rabbitmq_management.schema
rabbitmq-server/deps/rabbitmq_management/priv/schema
Bug#1055498: greenlet needs an update to 3.x to support Python 3.12
Hi, I need this fix too, to be able to test the fixes for Eventlet. FYI, if this can help, the pull request added Py 3.12 support is here: https://github.com/python-greenlet/greenlet/pull/327 Cheers, Thomas Goirand (zigo)
Bug#1055516: Uploaded python-jsonschema-specifications
Hi, FYI, I have just uploaded python-jsonschema-specifications, when it clears the NEW queue, I can move forward with updating python-jsonschema. Cheers, Thomas Goirand (zigo)
Bug#1055516: Ongoing work
Hi, FYI, to package latest version, I need python-jsonschema-specifications that I started packaging, but now this one needs the latest version of python3-referencing. As per here: https://github.com/python-jsonschema/referencing/commit/fdc8ab0116c82622a1ed0cd642e51237788ad1eb version 0.31.0 of referencing add "referencing.jsonschema.EMPTY_REGISTRY" that jsonschema-specifications uses (at least during tests, maybe more...). Roland, can you upgrade referencing to 0.31.0 then? Cheers, Thomas Goirand (zigo)
Bug#1056044: ITP: python-jsonschema-specifications -- JSON Schema meta-schemas and vocabularies, exposed as a Registry
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-jsonschema-specifications Version : 2023.11.1 Upstream Contact: Julian Berman * URL : https://github.com/python-jsonschema/jsonschema-specifications * License : Expat Programming Lang: Python Description : JSON Schema meta-schemas and vocabularies, exposed as a Registry This package contains JSON support files from the JSON Schema Specifications (metaschemas, vocabularies, etc.), packaged for runtime access from Python as a referencing-based Schema Registry. Note: This package is needed to update python-jsonschema to the latest upsteram release.
Bug#1055514: opensysusers: ineffective diversion of /bin/systemd-sysusers due to /usr-merge and DEP17
Hi Helmut, Thanks for following-up in this bug, and thanks for your patience. Helmut Grohne : > The diversion setup bears a significant downside: While the API > existing API of the sysusers interface is relatively stable, systemd > keeps adding features and when systemd calls systemd-sysusers it wants > to be able to rely on its latest features. A diverted systemd-sysusers > may not provide what is needed here. I've read this argument countless times. Here's my remarks. If the API of this systemd component changes all the time, when it's supposed to be used by our packages, then we'd better avoid systemd-sysusers at all costs, and declare it as not useable in the long run, because constantly changing. This would be a strong case for using only opensysusers. Lucky, that's as much as I know, *NOT* the case, and what you're describing is hopefully just FUD. If that's not, please be explicit explaining which part of the API of systemd-sysusers changed, or what feature was added: I'd be very curious to know, and it'd be nice to be able to add the missing feature in opensysusers. If you cannot explain what's not stable in this API, or what feature was added recently that is missing from opensysusers, then I would strongly suggest stopping spreading this kind of fake news, and let other people re-implement parts of systemd if they feel like it. If this is only a theoretical point, that systemd-sysusers *MAY* one day implement a new feature, then the thing that counts is if opensysusers is able to implement it as well, in a timely manner, to be able to stay compatible. If that's the case, then there's nothing to be afraid of. So please care to explain... That being said, I agree (and always did) that dpkg-divert was, and is (still) wrong, and should be replaced by a better solution. That was my point of view in the first place, and what I wrote to the tech-committee a few years ago. > A possible compromise could be that opensysusers stops diverting > systemd-sysusers and installs the symbolic link without diversion such > that systemd becomes the preferred provider when coinstalled. I don't understand why we're not then using update-alternatives. It has always been my idea to do so, and have systemd-sysuser having a higher priority over opensysusers... What's the blocker? You wrote it has issues with /usr-merge, why would it be the case, if we only do stuff in /usr/bin? Andrea Pappacoda : > since the upstream developers (i.e. the Artix Linux maintainers) > stopped development in favour of systemd-standalone-sysusers[ I wouldn't be scared of upstream being gone in the case of opensysusers, as this is a quite simple component to maintain. Though it's entirely your call. Cheers, Thomas Goirand (zigo)
Bug#1055512: RM: python-pypowervm -- ROM; Not maintained upstream, not needed anymore, buggy, no reverse depends
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Hi, Upstream support for pypowervm was dropped in OpenStack Nova (ie: compute), and therefore, we don't need this package in Debian anymore too. Let's remove it. Cheers, Thomas Goirand (zigo)
Bug#1054649: openstack-cluster-installer: block device list can be incorrect when using NVMe drives and/or RAID
Hi Jim, Thanks for the patch. FYI, I applied it pristine, I have just renamed the function "get_non_system_block_devices()" instead of just "get_block_devices", so it is easier to understand what the function does without looking into it. I'm very happy that you're proposing this type of refactoring, and I have to admit that the code is too much spagetti-like as it evolved over time... :/ So really, thanks a lot. Note that if you want to retain your patch ownership, you could send merge requests, otherwise, I'm marked as the author of the patches, which isn't very nice to your good work. :) Cheers, Thomas Goirand (zigo)
Bug#1028393: Feature request: Support for custom repository package signing key
Hi Jim, FYI, I'm applying your patch, though /etc/apt/trusted.gpg.d is deprecated. We should instead use the "signed-by" thingy in the sources.list, and store the keyring somewhere in /usr/share. I'd strongly suggest that you address this issue soonish if you care about this feature for Trixie. Also, I would also strongly recommend getting away from aptly in the favor of ftpsync, which is easy to implement. If you haven't seen it, I also maintain puppet-module-debian-archvsync so it's easy to maintain your mirror with puppet: https://packages.debian.org/puppet-module-debian-archvsync Cheers, Thomas Goirand (zigo)
Bug#1042648: pyro4: FTBFS with Sphinx 7.1, docutils 0.20: rm: cannot remove '/<>/debian/pyro4-doc/usr/share/doc/pyro4-doc//html/_static/underscore.js': No such file or directory
Hi, FYI, simply removing from d/rules: override_dh_installdocs: [...] rm $(DOCDIR)/html/_static/underscore.js fixes the build. Can this be done and uploaded ASAP please? Or alternatively, is this OK for an NMU? Cheers, Thomas Goirand (zigo)
Bug#1042628: Couldn't reproduce either
Hi, I also tried to reproduce and couldn't. I therefore lowered severity of this bug waiting for Lucas answer, to avoid AUTORM. Cheers, Thomas Goirand (zigo)
Bug#1054116: ITP: puppet-module-puppet -- Puppet module for Puppet itself (client and server)
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: puppet-module-puppet Version : 18.0.0 Upstream Contact: Theforeman * URL : https://github.com/theforeman/puppet-puppet * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Puppet itself (client and server) Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module contains a puppet to setup, configure and maintain puppet itself, client and server.
Bug#1054113: ITP: puppet-module-extlib -- Puppet module for Extlib
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: puppet-module-extlib Version : 7.0.0 Upstream Contact: Vox Pupuli * URL : https://github.com/voxpupuli/puppet-extlib * License : Apache-2.0 Programming Lang: Puppet, Ruby Description : Puppet module for Extlib Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module contains extlib: functions and facts that are out of scope for stdlib. Some of them are even intrinsically tied to stdlib.. This is a dependency to package puppet-module-puppet (ie: a puppet module to setup and configure the puppet agent & server).
Bug#1053832: bookworm-pu: package ceph/16.2.11+ds-2 (CVE-2023-43040)
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: c...@packages.debian.org
Control: affects -1 + src:ceph
Hi,
[ Reason ]
CVE-2023-43040
[ Impact ]
security issue with RGW with improperly verified POST keys.
[ Tests ]
Upstream runs an extensive unit and functional test suite.
[ Risks ]
There's no modification of the code, just a move of a small
block of code to the appropriate location. So I believe the
risk is minimal.
[ 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 ]
Just the upstream patch as per the debdiff.
[ Other info ]
Note that the debdiff shows changes in the src/test/debian-jessie
and src/test/ubuntu-16.04 folders. These are generated by the
upstream code, and fixing these would be IMO unecessary effort to
change something that has no consequence on the generated binaries.
So please ignore these.
diff -Nru ceph-16.2.11+ds/debian/changelog ceph-16.2.11+ds/debian/changelog
--- ceph-16.2.11+ds/debian/changelog2023-02-16 11:54:41.0 +0100
+++ ceph-16.2.11+ds/debian/changelog2023-10-09 10:43:41.0 +0200
@@ -1,3 +1,11 @@
+ceph (16.2.11+ds-2+deb12u1) bookworm; urgency=medium
+
+ * CVE-2023-43040: security issue with RGW with improperly verified POST keys.
+Applied upstream fix: rgw: Fix bucket validation against POST policies
+(Closes: #1053690).
+
+ -- Thomas Goirand Mon, 09 Oct 2023 10:43:41 +0200
+
ceph (16.2.11+ds-2) unstable; urgency=medium
* Add missing python3-distutils runtime depends in ceph-common.
diff -Nru
ceph-16.2.11+ds/debian/patches/CVE-2023-43040_rgw_Fix_bucket_validation_against_POST_policies.patch
ceph-16.2.11+ds/debian/patches/CVE-2023-43040_rgw_Fix_bucket_validation_against_POST_policies.patch
---
ceph-16.2.11+ds/debian/patches/CVE-2023-43040_rgw_Fix_bucket_validation_against_POST_policies.patch
1970-01-01 01:00:00.0 +0100
+++
ceph-16.2.11+ds/debian/patches/CVE-2023-43040_rgw_Fix_bucket_validation_against_POST_policies.patch
2023-10-09 10:43:41.0 +0200
@@ -0,0 +1,44 @@
+Author: Joshua Baergen
+Date: Wed, 17 May 2023 12:17:09 -0600
+Description: CVE-2023-43040 rgw: Fix bucket validation against POST policies
+ It's possible that user could provide a form part as a part of a POST
+ object upload that uses 'bucket' as a key; in this case, it was
+ overriding what was being set in the validation env (which is the real
+ bucket being modified). The result of this is that a user could actually
+ upload to any bucket accessible by the specified access key by matching
+ the bucket in the POST policy in said POST form part.
+ .
+ Fix this simply by setting the bucket to the correct value after the
+ POST form parts are processed, ignoring the form part above if
+ specified.
+Bug: https://tracker.ceph.com/issues/63004
+Signed-off-by: Joshua Baergen
+Origin:
https://github.com/ceph/ceph/commit/98bfb71cb38899333deb58dd2562037450fd7fa8.patch
+Last-Date: 2024-10-09
+
+Index: ceph/src/rgw/rgw_rest_s3.cc
+===
+--- ceph.orig/src/rgw/rgw_rest_s3.cc
ceph/src/rgw/rgw_rest_s3.cc
+@@ -2661,10 +2661,6 @@ int RGWPostObj_ObjStore_S3::get_params(o
+
+ map_qs_metadata(s);
+
+- ldpp_dout(this, 20) << "adding bucket to policy env: " <<
s->bucket->get_name()
+- << dendl;
+- env.add_var("bucket", s->bucket->get_name());
+-
+ bool done;
+ do {
+ struct post_form_part part;
+@@ -2715,6 +2711,10 @@ int RGWPostObj_ObjStore_S3::get_params(o
+ env.add_var(part.name, part_str);
+ } while (!done);
+
++ ldpp_dout(this, 20) << "adding bucket to policy env: " <<
s->bucket->get_name()
++ << dendl;
++ env.add_var("bucket", s->bucket->get_name());
++
+ string object_str;
+ if (!part_str(parts, "key", _str)) {
+ err_msg = "Key not specified";
diff -Nru ceph-16.2.11+ds/debian/patches/series
ceph-16.2.11+ds/debian/patches/series
--- ceph-16.2.11+ds/debian/patches/series 2023-02-16 11:54:41.0
+0100
+++ ceph-16.2.11+ds/debian/patches/series 2023-10-09 10:43:41.0
+0200
@@ -23,3 +23,4 @@
CVE-2022-3650_1_ceph-crash_drop_privleges_to_run_as_ceph_user_rather_than_root.patch
CVE-2022-3650_2_ceph-crash_fix_stderr_handling.patch
CVE-2022-3854_1_rgw_Guard_against_malformed_bucket_URLs.patch
+CVE-2023-43040_rgw_Fix_bucket_validation_against_POST_policies.patch
diff -Nru ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog
ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog
--- ceph-16.2.11+ds/src/test/debian-jessie/debian/changelog 2023-02-16
11:54:41.0 +0100
+++ ceph-16.2.11+ds/src/test/debian-jessie/d
