Bug#1080441: multipath-tools tgtbasedmpaths test fails when checking multipathd.socket
Package: multipath-tools Version: 0.9.9-1 For some reason I am not sure of yet, the multipathd.socket seems to be inconsistent in being enabled during the tgtbasedmpaths test. This is technically fine, as long as the service is enabled. This creates an issue with the check I recently added to monitor the socket. In my manual testing I always saw the socket enabled, but in Debian's CI[0] and Ubuntu's CI[1], some architectures are failing. Interestingly, amd64 in Debian's CI is failing[2], but is passing just fine for Ubuntu[3]. I say for now, let's _allow_ the socket to be inactive at startup, but only inactive which is a return code of 3 from systemctl. Thus, the autopkgtest will accept a return code of either 0 or 3. I have staged this change[4] in MR!17, please consider it. Welcome to additional thoughts on this too, apologies on the troubles adding this one line has caused, but it's highlighting an inconsistency which is exactly what I wanted to keep a lookout for. [0] - https://ci.debian.net/packages/m/multipath-tools/ [1] - https://autopkgtest.ubuntu.com/packages/multipath-tools [2] - https://ci.debian.net/packages/m/multipath-tools/unstable/amd64/ [3] - https://autopkgtest.ubuntu.com/packages/multipath-tools/oracular/amd64 [4] - https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/17
Bug#1078223: kpartx is not ran from dmraid udev rules with latest multipath-tools
Thanks Chris. I haven't tested it yet, but I would imagine that bookworm is still suffering from this issue, since multipath-tools is at 0.9.4-3+deb12u1. I totally understand removing this project, but feel free to consider making a patch such as this for users who are interested in the stable release. No worries if not - I'll look at patching this on the Ubuntu side since there's some clear desire for it even if the upstream project is dead. -Mitch
Bug#1078223: kpartx is not ran from dmraid udev rules with latest multipath-tools
Package: dmraid
Version: 1.0.0.rc16-12
Hello,
dmraid has an issue where kpartx is not run on boot.
This is due to the udev rule being triggered by DM_STATE, which is no
longer set. It used to be set by multipath-tools, but no longer does
since multipath-tools version 0.8.8-1[0].
What this means is that dmraid will work so you can see the block
device itself, but upon boot no partitions will be shown, and users
will have to manually run kpartx. This is the good case when the
partition is not the boot drive, if a user is using the latest
multipath-tools and dmraid for a boot drive, the partitions will not
be seen and fail to boot.
We can either reinstate the env file, or change the trigger. I'm
thinking about changing the trigger which looks like:
diff --git a/debian/dmraid.udev b/debian/dmraid.udev
index a4a1ab7..407d57b 100644
--- a/debian/dmraid.udev
+++ b/debian/dmraid.udev
@@ -4,5 +4,5 @@
SUBSYSTEM=="block", ACTION=="add", ENV{ID_TYPE}=="disk",
ENV{ID_FS_USAGE}=="raid", KERNEL=="hd[a-z]|sd[a-z]", \
RUN+="/sbin/dmraid-activate %k"
-ENV{DM_STATE}=="ACTIVE", ENV{DM_UUID}=="DMRAID-*", \
-RUN+="/sbin/kpartx -a /dev/$kernel"
\ No newline at end of file
+ENV{DM_ACTIVATION}=="1", ENV{DM_UUID}=="DMRAID-*", \
+RUN+="/sbin/kpartx -a /dev/$kernel"
Relevant Ubuntu bug [1].
[0] -
https://salsa.debian.org/linux-blocks-team/multipath-tools/-/commit/4ab9ce259ffa75ed3e2d145b3f2effc22af7b4c6
[1] - https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/2047303
Bug#1077630: debian/watch does not track upstream tarball correctly
Package: rabbitmq-server Version: 3.12.2-1 the debian/watch file does not track the upstream tarball correctly. Also, the upstream tarball should be verified. I prepared a fix for these issues at [0]. [0] - https://salsa.debian.org/openstack-team/third-party/rabbitmq-server/-/merge_requests/8
Bug#1077188: Depend on newer libwine-dev
Package: dxvk Version: 2.4-2 Please consider build-depending on libwine-dev from src:wine which is newer than libwine-development-dev. This package failed to sync into Ubuntu because we stopped syncing wine-development due to [0], but still have wine in our repositories. I think it makes sense to use libwine-dev since it is a newer version at the moment (9.0~repack-4 versus 8.21~repack-1). [0] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988246
Bug#1074403: fix multipath-tools tgtbasedmpaths brace expansion
Package: multipath-tools Version: 0.9.8-1 Apologies, I broke tgtbasedmpaths by adding brace expansion directly to the dep8 script. I prepared an MP up at [0] to fix this. Please take a look at it. As an aside, why is this failure not showing up in https://ci.debian.net/packages/m/multipath-tools/unstable/amd64/ ? I only see the initramfs test running [0] - https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/16
Bug#1018874: etckeeper noisy when using bzr/brz
Hi, any activity on this bug? I also made a MR for your consideration at https://salsa.debian.org/debian/etckeeper/-/merge_requests/3 Thanks, -Mitch
Bug#1069680: Add systemctl socket status to tgtbasedmpaths test
Package: multipath-tools Version: 0.9.7-7 Subject: Add systemctl socket status to tgtbasedmpaths test Hi, I have a simple MR up at https://salsa.debian.org/linux-blocks-team/multipath-tools/-/merge_requests/12. This adds the socket to the systemctl status command for the dep8 test. I'm working on updating the socket/service interactions so it'd be nice to have the status of the socket in this dep8 test. Thanks! -Mitch
Bug#1069311: php-symfony-polyfill: Fix typo in pkg-php-tools-autoloaders for php84
Package: php-symfony-polyfill Version: 1.29.0-3 Subject: Fix typo in pkg-php-tools-autoloaders for php84 Hi, I have a simple MR up at https://salsa.debian.org/php-team/pear/php-symfony-polyfill/-/merge_requests/2 to fix a typo in the autoloaders. Thanks! -Mitch
Bug#1069260: FTBFS in Ubuntu noble
Package: php-symfony-polyfill
Version: 1.29.0-3
Subject: FTBFS in Ubuntu noble
I am writing this bug report to give a heads up that php-symfony-polyfill
is FTBFS on Ubuntu noble[0]. In our archive we have php8.3 installed so I
imagine you will run into similar issues once php upgrades.
We see many failures that look like:
136) Symfony\Polyfill\Tests\Intl\Idn\IdnTest::testToAsciiTransitional
with data set #2213 ('α‘βγ>ΜΈπ²=ΜΈ', 'α‘β.β―π²β ', array(4096, 128, 128),
'xn--p8e650b.xn--1ch3a7084l', array(4096, 128, 128),
'xn--p8e.xn--1ch3a7084l', array(128, 128))
Expected to find errors, but found none.
Failed asserting that 0 is not identical to 0.
/<>/tests/Intl/Idn/IdnTest.php:195
No real actions need to be taken here, as mentioned before I'm just giving
a heads up for when php8.3 is being used.
Thanks,
-Mitch
[0] -
https://launchpad.net/ubuntu/+source/php-symfony-polyfill/1.29.0-3/+build/27878277
