vcswatch reports that
this package seems to have new commits in its VCS but has
not yet updated debian/changelog. You should consider updating
the Debian changelog and uploading this new version into the archive.
Here are the relevant commit logs:
commit da64f9c94c8567bb8e04688a8f9d5a29b930ae75
Author: Thomas Lange <lange@debian.org>
Date: Sun Jul 12 17:36:49 2026 +0200
remove unused variable
commit 8c5b53319b4ca58c8374409efb9b7f8ecbe1d97d
Author: Thomas Lange <lange@debian.org>
Date: Sun Jul 12 17:36:24 2026 +0200
avoid globbing
commit 7d5c0da5669095bc885e321ce5d3f6a55b89fdcc
Author: petur <petur.egilsson@nacosmarine.com>
Date: Mon Apr 20 21:43:19 2026 +0200
fai-do-scripts: abort at first script exceeding $STOP_ON_ERROR
commit 225b14b8098e1923dbf3e36a6143ddfd6937672e
Author: petur <petur.egilsson@nacosmarine.com>
Date: Mon Apr 20 21:43:16 2026 +0200
call_hook: check task_error after executed hooks, Closes: #1121552
commit 01c84cf7ee5e932c64388df2d8202a1339acc156
Author: Florent Carli <florent.carli@rte-france.com>
Date: Mon Jun 8 18:32:03 2026 +0200
setup-storage: wait for LV device node before using it
After lvcreate returns, the kernel has created the underlying /dev/dm-N
device, but the friendly-name symlinks /dev/<vg>/<lv> (and
/dev/mapper/<vg>-<lv>) are only created asynchronously once udev
processes the corresponding uevent. setup-storage already calls
"udevadm settle" before every command, but that relies on a reachable,
responsive udev daemon and can return prematurely or be a no-op when
udev is slow or unreachable -- e.g. in privileged containers sharing
the host's /dev (see https://github.com/rancher/os/issues/838) -- which
leads to intermittent "mkfs.ext4: No such file or directory" failures.
Add wait_for_device(), a small bounded poll loop for the device node
itself, and slot it into the LV creation command chain between
lvcreate and anything that consumes /dev/<vg>/<lv> (mkfs, resize, ...).
This is environment-agnostic and catches the case where udevadm settle
alone is not sufficient.
commit 225b839ef837b9cc09348fe3914a5d6bf3fec687
Author: Thomas Lange <lange@debian.org>
Date: Thu Jul 2 18:08:26 2026 +0200
show supported hwcap of CPU