Hi Cyril,

I plan to split out udev-udeb and libudev1-udeb from the current
src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to
apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable
until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Luca,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current
src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to
apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Indeed, that looks like a very solid plan, thanks! Especially if the
split package gets sync'd from time to time (as opposed to be forgotten
about forever — which could work for some other components, but not
quite for something as dynamic and tied to the Linux kernel as udev).

Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable
until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

I think this heads-up is sufficient. Depending on the versioning and
timing of the two source packages, and when you drop the udeb, there
might be a smoothless transition (~ “live takeover”), or a going-away- then-back-again, and we can live with daily builds being broken for a
few days anyway. There's no imminent release either, so all good.

The list of udeb-producing packages is monitored and I'll update it
indeed. I might have to tweak some tooling to get meaningful diffs to
build the next release announcement, but that's really just for me.

I don't think there's anything else that should care about such details
(the tricky part I could think of is the Built-Using generation and even
that doesn't seem to list either systemd or udev so everything should be
fine already).

Feel free to go ahead whenever you are ready. I'll probably see the
package getting out of NEW on my own, but feel free to follow up once
it's ACCEPTED if you remember/can spare a minute, so that others know
the “red moment due to the systemd split” moment (if any) is over.


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmeHzKkACgkQ/5FK8MKz VSBgghAAsfKOWhYSu1J0Bv/wD2UOgylWV0q8ZRhdfIDxhpQ5KxC913hfA3umGUMi PaZybnInjg58kGrSebWFzJRSuQHUgaitrkD4GamaViptYwy7LNehXci5d4SIaU7t 7lpPuvqXdg1amaHI/oEX5YjdqH24pqYv8zUTuFVG9xQpP44hR+/DQBjbuLJRMSdm rqDLMAO7dKAflO9rOc0fbotiroRb9+hmdKqnj+HnrFHkqC6p73Pku9rZkov0adb4 nTZRF078BOSgu3Ep06N91iYlXrkaThUidVSO8e52f6mEVfU3Rt5HS+Pd9LT+zd+w Gl0f67KX16eI+LHE4YjxyD5YDt8kTm5+Ig47gXQ09pm1GleP+RZulN3fsl4XD4C5 1rDAlcpcwB6QRtQ3tWYfQq7JNYA4sF6UB6oKDtkh4Fv2c9pmsUVxBi5wNHS5SL06 4TdlEP6XjSAEA3DyKG+AB6CCxgI1LpV6oZVsYk4YiCr/t2GgqNjSlWOqPzHaomgd vtKYBJlflisTnUgecfadOfne+X5o9CgHc0JVA5+pR/a0o0jvtdZhi2NGxrO8ac0X 3T6xEyd2Qa4vfvoUAeqgXsWw+4KThkUCGn3mYpzleTPMDiqqLjS7IsAntWrMuHjp 6bdMBh7kmAtkYARTFUqYqIeCcpMkPyqSUvTL6xLr4wKsik7AkrQ=
=Eaz5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Wed, 15 Jan 2025 at 14:56, Cyril Brulebois <kibi@debian.org> wrote:

Hi Luca,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Indeed, that looks like a very solid plan, thanks! Especially if the
split package gets sync'd from time to time (as opposed to be forgotten
about forever — which could work for some other components, but not
quite for something as dynamic and tied to the Linux kernel as udev).

Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

I think this heads-up is sufficient. Depending on the versioning and
timing of the two source packages, and when you drop the udeb, there
might be a smoothless transition (~ “live takeover”), or a going-away- then-back-again, and we can live with daily builds being broken for a
few days anyway. There's no imminent release either, so all good.

The list of udeb-producing packages is monitored and I'll update it
indeed. I might have to tweak some tooling to get meaningful diffs to
build the next release announcement, but that's really just for me.

I don't think there's anything else that should care about such details
(the tricky part I could think of is the Built-Using generation and even
that doesn't seem to list either systemd or udev so everything should be
fine already).

Feel free to go ahead whenever you are ready. I'll probably see the
package getting out of NEW on my own, but feel free to follow up once
it's ACCEPTED if you remember/can spare a minute, so that others know
the “red moment due to the systemd split” moment (if any) is over.

New source package has been accepted and both uploads are now in unstable

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Luca Boccassi <bluca@debian.org> (2025-01-17):

New source package has been accepted and both uploads are now in unstable

Thanks for the heads-up.

I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing udev-udeb between testing and unstable)

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id

Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

More importantly, udev-udeb isn't installable, as it depends on libkmod2
(not its udeb counterpart) — and that's the only change in Depends.

This seems to be picked up via:

debian/udev-udeb.substvars:dlopen:Recommends=libkmod2

which is a variable that wasn't being used for udev-udeb before the
split but is now:

Package: udev-udeb
Build-Profiles: <!noudeb>
Package-Type: udeb
-Section: debian-installer
Architecture: linux-any
Depends: ${shlibs:Depends},
${misc:Depends},
- util-linux-udeb
+ ${dlopen:Recommends},
+ ${dlopen:Suggests},
+ util-linux-udeb,

Package: libudev1-udeb
Build-Profiles: <!noudeb>
Package-Type: udeb
-Section: debian-installer
Architecture: linux-any
Depends: ${shlibs:Depends},
- ${misc:Depends}
+ ${misc:Depends},
+ ${dlopen:Recommends},
+ ${dlopen:Suggests},


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmeLSmwACgkQ/5FK8MKz VSDB5g//XR6KTEqN84tYR/PuOwCJQJ3muCBtT0YEFtnicZHmv4sllgYq0/2G2bvJ zGv1dSGAVv1fwHk1DjjEYN6yTKrhrQjb/Kv+lFxhzSqNODPxJxx6MP5pdJ2hu3UU 52hqYcAX08zaBfu+Iq/46psP7VS28rkOGKD4qDLnJm/mdPUOWDfm8nUdAcX7NMLj zmo4TSVBoLWZrX48M8Lgy1Sah7Egxtr7h3tCTxkenu1P9AaV6NAwHXRQLh9tTart W0agDWfHkoAadVGBewxohbWpVs6y6hFGqYRWjtA7yjcUPqWhJpnowDEn9BxOJRnG hng38abWBc9VMmijcZZFIQbh7ihoeaZY7eTOiZo2t4uKBaWVAfddC2aowsDzi/Jm +suKleTls/4ueKhbAdJzfUhJqZ2uq3hc8Zf8VkH6ZH3L2Aw/L8cJ+PRvuA82oBVC +BEKmFdzhqCHUvlfF+4IRSs7Zj7C6ce5twnjdiGERItVl8xrJUcMTg62H1knaAP3 kA4hMD1LtUihwxnaAPrUYQQZyHFlefcG2ruLCGV5avKwMPwMhdI7cM/42cAk9yO+ RobkLIFukYvdo5lALo+nkUicViA4PFDICmGDfzB35O0m7cl6jeooE0/h4KocuSux lkFUoJYbxb6JD3wVOSx5O140z4LHh1oL18HDtgR2UGtys2nsh0k=
=6yPo
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Sat, 18 Jan 2025 at 06:30, Cyril Brulebois <kibi@debian.org> wrote:

Hi,

Luca Boccassi <bluca@debian.org> (2025-01-17):

New source package has been accepted and both uploads are now in unstable

Thanks for the heads-up.

I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing udev-udeb between testing and unstable)

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id

Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

The old udev-udeb.install was severely bitrotting, as it seems it was
copied at some point from the main one, but then largely left as-is.
Normally dh-missing would warn about these things, but of course the
main udev package is picking all new files up, so there was no
warning.
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. It seems correct that all rules files (and
all helper tools that are called in them) are shipped, rather than an
arbitrary subset. Those are all rules and tools that were added since
the last time udev-udeb.install was changed.
And it seems to me the network files serve no purpose, as there's no
networkd udeb, no?

More importantly, udev-udeb isn't installable, as it depends on libkmod2
(not its udeb counterpart) — and that's the only change in Depends.

This seems to be picked up via:

debian/udev-udeb.substvars:dlopen:Recommends=libkmod2

Whops, good catch - I had forgotten that addon cannot deal with udebs.
Removed and added libkmod2 manually, on its way to unstable now.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Luca Boccassi <bluca@debian.org> (2025-01-18):

The old udev-udeb.install was severely bitrotting, as it seems it was
copied at some point from the main one, but then largely left as-is.
Normally dh-missing would warn about these things, but of course the
main udev package is picking all new files up, so there was no
warning.
I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. […]

I wasn't meaning to sound like I'm challenging or anything, I just
debdiff'd old and new udebs, saw a lot of changes (in addition to the
extra dependency), that's why I asked.

Thanks for the confirmation/background.

Whops, good catch - I had forgotten that addon cannot deal with udebs. Removed and added libkmod2 manually, on its way to unstable now.

Things are looking good again on the (un)installability side, thanks!


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmeL334ACgkQ/5FK8MKz VSBHvg//bxa2mDrPIY0p+H7X26vZCZdkHLk2JwH7TpmF9aJaTbl7lBWbudWl4+RJ J7eXMy8GORrz35VpRCnB4yTYH+1BtlhluazHnXMUsr+Gx9G/9sIOH9zi2jQ8upkO F94B/I6ZQBMiJ2/xOmc/ZG/C0d0/kY9YRGYvG4s7T2Qx8sOxRWshBX/eJh4hYOLK TIoxLEE0T1tIu5t91Wapm2FBDCcEEqwV6nQYjQGzkS4/SJ/6SvVRYc2I3O/7AjvS WhHpuQackIopd94t7NGVqMehkZ2N2D5irgFI2/vaKYLPk9LtqUvhPxAiruQ2LmYz 6PryndgoWWUMe+sie5lzPg42LoB2LQ+7ZlB3ZLNuSg6YtXYUYKHVhPiZLSNRvxTR T0iv7d8CF6QUxbO3pPrlobc04ZHNhOyAifnpZIr6TP18zIMw9LXS18XM49qeo3EC sn12bkJ4+SBQCmgS5APwDBkIylGUrP7k8s/6nByBRVwi18EirpACAC2cMCJqIJrT UQP1Pl2ViDhgLee/jZwRT+vD1jCCHN1AcHVsiYQIdJ3XA6CE2RWsbwGDaXyJvdJa 5zuMDuksZIqQmuS3xQmr0pin8ZnwZhsLkN0o7cTlC0T7jsy/JKG5+zuzq2JDRRlF tFI7Rk8ZG6IjLPaGiKIFPLp6IwrLoigthMJG9mu9FZA4OF6SKPU=
=Ybb1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Sat, 18 Jan 2025 at 17:06, Cyril Brulebois <kibi@debian.org> wrote:

Luca Boccassi <bluca@debian.org> (2025-01-18):

The old udev-udeb.install was severely bitrotting, as it seems it was copied at some point from the main one, but then largely left as-is. Normally dh-missing would warn about these things, but of course the
main udev package is picking all new files up, so there was no
warning.
I think the changes here are right and I did them intentionally, but correct me if I'm wrong. […]

I wasn't meaning to sound like I'm challenging or anything, I just
debdiff'd old and new udebs, saw a lot of changes (in addition to the
extra dependency), that's why I asked.

Thanks for the confirmation/background.

It didn't sound like that at all, no worries. If you see any problems
in the installer due to the lack of those network files, or the
presence of the rules files, let me know and I'll change it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current
src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.

(I'll file the mdadm bug report later on, I'm on my way out.)


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmeSJE8ACgkQ/5FK8MKz VSAj2A//TUpLVTDPmFNq21CbOXkSMPsL5tfKD50mQC4eZIY6Q+mrVc9LDOhIgBhc c5N/D4Pc/hOOSKr7EJ8gX55ZzO4pDjMB91ne87fZtWTn2+3Rzv5hs2kexPkvuAey SqubYNJNClUmfQwQxJw/X5QtGNM+rIISLRFaUh/VgZkCz8dDhkiJWr7wgBYv3chQ APgbpuT1vYIDMlowQEYFHr2B+/mmyM9DoFy0XYOrzJMN2OwRttG8TaMkLrACioBm nS88a8RQbO5YdQqik5NBW99iVA6O2kw1UbFI5ZYLG3ujIeQFQWNYgnwyATSbqsA1 byhY/iLHqU+tthc33j/3s1TLRLdv2CLa5zjnlzseWlf9vV8xT0NXSL/q4K3+Fzaa 3NFT+pLs7M+bj9m0jo6EHaGhd9YGXNElw+ate99KAi+BQ1pM2s8kwjxDSOL5ouTL S3PNP0s25423TWkDW+weYmCuNW6a1ZFihqycMp9pqHEIY2IwPQ62g40D18RpqHNT rAkGGvN7YXNtJXigSjQHEj2HqAiba1QWnunWqB0Y/nj4y7H5SfOHxbcqlsHa+omy 1PyAjclhCos+GHdljPxFFXx6dMcLyrCtMGQsbXKs1j9t6OedL8zHT1EviFIzgpQm 7/krTCMWnOoeX7Ym+2R5iII66i6wVOWN5KSC6jZ50GBSZucQAHs=
=xsFs
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Thu, 23 Jan 2025 at 11:13, Cyril Brulebois <kibi@debian.org> wrote:

Hi,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.

(I'll file the mdadm bug report later on, I'm on my way out.)

Thanks for the report, this looks like to be the problem, in DEBIAN/shlibs:

libudev 1 libudev1 (>= 257.2)
udeb: libudev 1 libudev1-udeb (>= 257.2)

became

libudev 1 libudev1 (>= 257.2)

I'll do a few experiments and upload a fix as soon as I have it

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 23 Jan 2025 at 11:56, Luca Boccassi <bluca@debian.org> wrote:

On Thu, 23 Jan 2025 at 11:13, Cyril Brulebois <kibi@debian.org> wrote:

Hi,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.

(I'll file the mdadm bug report later on, I'm on my way out.)

Thanks for the report, this looks like to be the problem, in DEBIAN/shlibs:

libudev 1 libudev1 (>= 257.2)
udeb: libudev 1 libudev1-udeb (>= 257.2)

became

libudev 1 libudev1 (>= 257.2)

I'll do a few experiments and upload a fix as soon as I have it

Ok I have a fix that results in:

Package: mdadm-udeb
Source: mdadm
Version: 4.4-2
Architecture: amd64
Maintainer: Daniel Baumann <daniel.baumann@progress-linux.org>
Installed-Size: 1040
Depends: libc6-udeb (>= 2.40), libudev1-udeb (>= 247)

Which looks correct to me, so I'll upload that. mdadm will require a
rebuild afterwards. Thanks for finding this!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/01/2025 at 11:46, Luca Boccassi wrote:

On Sat, 18 Jan 2025 at 06:30, Cyril Brulebois <kibi@debian.org> wrote:

I'm seeing a lot of things that are different, for what should be just a
new revision/move. Are those expected? (diff generated on amd64, diffing
udev-udeb between testing and unstable)

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules >> -rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules >> -rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id

Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link >> -rw-r--r-- root/root /usr/lib/systemd/network/99-default.link

(...)

I think the changes here are right and I did them intentionally, but
correct me if I'm wrong. It seems correct that all rules files (and
all helper tools that are called in them) are shipped, rather than an arbitrary subset. Those are all rules and tools that were added since
the last time udev-udeb.install was changed.

Does the installer really need rules for joysticks, cameras, v4l... ?
The new package installed size grows by 500kB (mostly due to additional
helper tools), which can be significant on low memory systems.

And it seems to me the network files serve no purpose, as there's no
networkd udeb, no?

I suspect that bug #1093907 ("predictable" name is not enforced) is
caused by the removal of these files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 23 Jan 2025 at 14:01, Luca Boccassi <bluca@debian.org> wrote:

On Thu, 23 Jan 2025 at 11:56, Luca Boccassi <bluca@debian.org> wrote:

On Thu, 23 Jan 2025 at 11:13, Cyril Brulebois <kibi@debian.org> wrote:

Hi,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current src:systemd source package/repo into a new src:systemd-udeb (forked from the old one, so generated udebs will be the same).

The current set of packages doesn't work as the shlibs now only references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.

(I'll file the mdadm bug report later on, I'm on my way out.)

Thanks for the report, this looks like to be the problem, in DEBIAN/shlibs:

libudev 1 libudev1 (>= 257.2)
udeb: libudev 1 libudev1-udeb (>= 257.2)

became

libudev 1 libudev1 (>= 257.2)

I'll do a few experiments and upload a fix as soon as I have it

Ok I have a fix that results in:

Package: mdadm-udeb
Source: mdadm
Version: 4.4-2
Architecture: amd64
Maintainer: Daniel Baumann <daniel.baumann@progress-linux.org> Installed-Size: 1040
Depends: libc6-udeb (>= 2.40), libudev1-udeb (>= 247)

Which looks correct to me, so I'll upload that. mdadm will require a
rebuild afterwards. Thanks for finding this!

The fix is in unstable for all release arches, and I've re-tested the
mdadm build and the generated dependencies look correct, so mdadm can
be rebuilt now and it should work again. Please let me know if more
such issues appear.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 24 Jan 2025 at 08:43, Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

On 18/01/2025 at 11:46, Luca Boccassi wrote:

On Sat, 18 Jan 2025 at 06:30, Cyril Brulebois <kibi@debian.org> wrote:

I'm seeing a lot of things that are different, for what should be just a >> new revision/move. Are those expected? (diff generated on amd64, diffing >> udev-udeb between testing and unstable)

Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-autosuspend.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-dmi-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-drm.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-evdev.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-fido-id.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-infiniband.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-alsa.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-mtd.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-persistent-v4l.rules >> -rw-r--r-- root/root /usr/lib/udev/rules.d/60-sensor.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/60-serial.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-camera.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-joystick.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-memory.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-mouse.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/70-touchpad.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/78-sound-card.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/81-net-dhcp.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/90-iocost.rules
-rw-r--r-- root/root /usr/lib/udev/rules.d/99-systemd.rules
-rwxr-xr-x root/root /usr/lib/udev/dmi_memory_id
-rwxr-xr-x root/root /usr/lib/udev/fido_id
-rwxr-xr-x root/root /usr/lib/udev/iocost
-rwxr-xr-x root/root /usr/lib/udev/mtd_probe
-rwxr-xr-x root/root /usr/lib/udev/v4l_id

Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/systemd/network/73-usb-net-by-mac.link
-rw-r--r-- root/root /usr/lib/systemd/network/99-default.link (...)

I think the changes here are right and I did them intentionally, but correct me if I'm wrong. It seems correct that all rules files (and
all helper tools that are called in them) are shipped, rather than an arbitrary subset. Those are all rules and tools that were added since
the last time udev-udeb.install was changed.

Does the installer really need rules for joysticks, cameras, v4l... ?
The new package installed size grows by 500kB (mostly due to additional helper tools), which can be significant on low memory systems.

Most of these seem to be useful, yes - storage, network, input
devices, output devices. I don't think it's worth excluding a couple
of small rules files, unless they actively cause trouble.

And it seems to me the network files serve no purpose, as there's no networkd udeb, no?

I suspect that bug #1093907 ("predictable" name is not enforced) is
caused by the removal of these files.

Strange, I guess these are used in some form then. I'll upload shortly
with these added back, thanks for the report.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Luca,

Luca Boccassi <bluca@debian.org> (2025-05-12):

In https://release.debian.org/britney/hints/freeze I see:

block-udeb systemd
block-udeb systemd-udeb

but the first one should no longer be there, right? Would it be
possible to amend it, please?

Absolutely:

commit c6faf50ca3228b81d680f06a98ede58c746b5030 (HEAD -> ftp-master)
Author: Cyril Brulebois <kibi@debian.org>
Date: Mon May 12 21:33:03 2025 +0000

freeze_hints: remove systemd

Thanks to Luca Boccassi for the reminder!

Link: https://lists.debian.org/debian-boot/2025/05/msg00119.html

Are you maintaining that list yourself, or is it RT, or both, or
someone else?

I have a (user, not group/role) crontab that checks whether udeb-producing packages are missing from that list, and I'm adjusting it after checking
what's happening (I think some mistakes happened, but I couldn't name any without some research).

The crontab doesn't check the converse, because dropping udebs is rather uncommon (unless packages go away entirely, which might or might not
result in some cleanup…).

Without trying to justify anything, I think I added systemd-udeb at the
time you mentioned you were thinking about then were about to introducing
it, and I didn't remove systemd at the same time because you/I/we weren't
sure about the timing on the NEW side (and the associated binary/binaries takeover).

Here's what the git log says, which might confirm/infirm the very vague recollection above:

commit 6dbceab050aae1b5f673bab41491f7bca2a9a5d8
Author: Cyril Brulebois <kibi@debian.org>
Date: Fri Jan 31 18:33:17 2025 +0000

freeze_hints: add systemd-udeb

If you ever need to look into the history, see etc/freeze_hints in
respighi:/srv/release.debian.org/britney/code/b1


The whole release team has access, I'm usually the one committing stuff
there (at least regarding udebs; freezing/thawing is usually someone else,
see `git shortlog -- etc/freeze_hints` if you're curious.)


Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgiaxkACgkQ/5FK8MKz VSCzsw/9E+CixCZuZwMkiUAp69bXngIq3K9JiC8jbcC8OZYyQ1VxYEXYh6Lyf+ti 7RaFdwlE+98ZfKDI1N0LsAluB6RF9ctcwiDfjFKHgnu/ZU2TqqZYXbcKauHSJVCj BWuY1q3rmTYD+qPl9gU1DumB1WRiPYoCAJAYA6RVP3XJ7BRI3BJJKe1khj/YLEyN vWbvOZxuev1sl9BI2g0sKzzQmqgudyKXQluzggi572jv5EP9BfiGXWs5BMF5h5P9 zELC72m8QaRhlC8X9mqx1y/KNrYnCvf2cBpfB9nFxXWeSUFxQLBMVrpNSaTb2o36 bBeE/OLJWgCqyi3lIq1uU1zlyLvn8a1TnwgB8TJH8eTkpxZv4ds894aT/jod6xZi 3BW57QfxM5XAtr3pr9nfvx67fvP01esJ3MIHozMyPuYvjXk1aKlk7dCqkWEC5NOQ 2GQTGt9uYI1hKJN5K+F0J2KdTY8vT9S8AYvm/sDUkGfMYgL6r0TBzIkMxObWqDNo /Jvjhfzzg9RH0ZKurR6kq/tbKV1e1ctKywGKmzH1R8JQmu9SWchBcwYNHpOQ2IqS NG3423lnq1VcrxNlwq3RA0QbqUIEjUNjHOrlxthKzjEFdLFTuzRe90vA72MXVfQ0 ijaO494FnGLz4rEkIOAitAPY44ioIhrz8XZLuItmuJDKS+R5u4Q=
=dk77
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

On Wed, 15 Jan 2025 at 14:56, Cyril Brulebois <kibi@debian.org> wrote:

Hi Luca,

Luca Boccassi <bluca@debian.org> (2025-01-15):

I plan to split out udev-udeb and libudev1-udeb from the current src:systemd source package/repo into a new src:systemd-udeb (forked
from the old one, so generated udebs will be the same).

This should greatly reduce your workload as src:systemd uploads will
no longer be in your way and require actions/reviews, and I do not
plan to update src:systemd-udeb more than once per major upstream
release in unstable, and never in stable-p-u. It will also allow me to apply several improvements to src:systemd that are currently blocked
by the fact that udebs are built from it. The udeb source package will
be much smaller and leaner, with drastically cut build deps and so on.
So it should be a win/win all around.

Indeed, that looks like a very solid plan, thanks! Especially if the
split package gets sync'd from time to time (as opposed to be forgotten
about forever — which could work for some other components, but not
quite for something as dynamic and tied to the Linux kernel as udev).

Are there any particular precautions I should take? It will require a
trip through NEW, so for a time the udeb might disappear from unstable until it is processed, but hopefully won't be too long. I think
there's somewhere a list of source packages building udebs, that will
need to be updated. Anything else?

I think this heads-up is sufficient. Depending on the versioning and
timing of the two source packages, and when you drop the udeb, there
might be a smoothless transition (~ “live takeover”), or a going-away- then-back-again, and we can live with daily builds being broken for a
few days anyway. There's no imminent release either, so all good.

The list of udeb-producing packages is monitored and I'll update it
indeed. I might have to tweak some tooling to get meaningful diffs to
build the next release announcement, but that's really just for me.

I don't think there's anything else that should care about such details
(the tricky part I could think of is the Built-Using generation and even
that doesn't seem to list either systemd or udev so everything should be
fine already).

Feel free to go ahead whenever you are ready. I'll probably see the
package getting out of NEW on my own, but feel free to follow up once
it's ACCEPTED if you remember/can spare a minute, so that others know
the “red moment due to the systemd split” moment (if any) is over.

Hi Cyril,

In https://release.debian.org/britney/hints/freeze I see:

block-udeb systemd
block-udeb systemd-udeb

but the first one should no longer be there, right? Would it be
possible to amend it, please?
Are you maintaining that list yourself, or is it RT, or both, or someone else?

Thanks!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 12 May 2025 at 22:41, Cyril Brulebois <kibi@debian.org> wrote:

Hi Luca,

Luca Boccassi <bluca@debian.org> (2025-05-12):

In https://release.debian.org/britney/hints/freeze I see:

block-udeb systemd
block-udeb systemd-udeb

but the first one should no longer be there, right? Would it be
possible to amend it, please?

Absolutely:

commit c6faf50ca3228b81d680f06a98ede58c746b5030 (HEAD -> ftp-master)
Author: Cyril Brulebois <kibi@debian.org>
Date: Mon May 12 21:33:03 2025 +0000

freeze_hints: remove systemd

Thanks to Luca Boccassi for the reminder!

Link: https://lists.debian.org/debian-boot/2025/05/msg00119.html

Are you maintaining that list yourself, or is it RT, or both, or
someone else?

I have a (user, not group/role) crontab that checks whether udeb-producing packages are missing from that list, and I'm adjusting it after checking what's happening (I think some mistakes happened, but I couldn't name any without some research).

The crontab doesn't check the converse, because dropping udebs is rather uncommon (unless packages go away entirely, which might or might not
result in some cleanup…).

Without trying to justify anything, I think I added systemd-udeb at the
time you mentioned you were thinking about then were about to introducing
it, and I didn't remove systemd at the same time because you/I/we weren't sure about the timing on the NEW side (and the associated binary/binaries takeover).

Here's what the git log says, which might confirm/infirm the very vague recollection above:

commit 6dbceab050aae1b5f673bab41491f7bca2a9a5d8
Author: Cyril Brulebois <kibi@debian.org>
Date: Fri Jan 31 18:33:17 2025 +0000

freeze_hints: add systemd-udeb

If you ever need to look into the history, see etc/freeze_hints in
respighi:/srv/release.debian.org/britney/code/b1

The whole release team has access, I'm usually the one committing stuff
there (at least regarding udebs; freezing/thawing is usually someone else, see `git shortlog -- etc/freeze_hints` if you're curious.)

Thank you very much for the quick fix and the explanation!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)