Please branch and build systemd-extras in epel10. If you do not wish to maintain systemd-extras in epel10, or do not think you will be able to do this in a timely manner, the EPEL Packagers SIG would be happy to be a co-maintainer of the package; please add the epel-packagers-sig group through https://src.fedoraproject.org/rpms/systemd-extras/addgroup and grant it commit access, or collaborator access on epel* branches.
Will you be able to branch and build systemd-extras in epel10? The EPEL Packagers SIG would be happy to be a co-maintainer if you do not wish to build it on epel10.
I will try to work on this, however it makes less sense to me to just branch systemd-extras for epel10 to build the old systemd version.
...especially as some people will yell, if a later update of systemd-extras contains breaking changes.
Yeah it probably makes sense to use 256 for epel10, as that's what's shipping in c10s at the moment.
https://repo.dynavirt.com/stream10/systemd-extras-257.2-1.el10/
+1 Need this for netplan in epel10
+1 we need this for OpenStack-Ansible
Will you be able to branch and build systemd-extras in epel10? I would be happy to be a co-maintainer if you do not wish to build it on epel10 (FAS: jonathanspw).
*** Bug 2359219 has been marked as a duplicate of this bug. ***
Sorry! It's on the top of my to-do list for the weekend.
(In reply to nucleo from comment #5) > https://repo.dynavirt.com/stream10/systemd-extras-257.2-1.el10/ Could you explain why you added these files to systemd-networkd? - /usr/lib/systemd/network/80-6rd-tunnel.link - /usr/lib/systemd/network/80-container-vb.link - /usr/lib/systemd/network/80-container-ve.link - /usr/lib/systemd/network/80-container-vz.link - /usr/lib/systemd/network/80-namespace-ns.link - /usr/lib/systemd/network/80-vm-vt.link
While targetting 257.7, I run into some issues, of which most have been solved. While it's building, it still needs some polishing and testing (on top of my to-do list for next weekend). And I need to understand whether the *.link files really should be part of systemd-networkd (see comment #11), where help/input is welcome.
I am not maintain packages on that link. I posted link here only as possible solution in absence of package in el10 EPEL. These files included in systemd package in Fedora but missing el10 systemd, so systemd-networkd looks like only place for them.
systemd .link dropins are processed by udev, not by systemd-networkd, that's likely why they're being shipped in the main systemd package in Fedora.
+1 to .link explanation. While you create them as part as network configuration, it's systemd-udev which process them: http://www.freedesktop.org/software/systemd/man/latest/systemd.link.html
nucleo, Davide, Dmitriy: So...what's your expectation? Should systemd-networkd simply ship the *.link files for EL10 (even they are processed by systemd-udev), because systemd in EL10 doesn't do so?
@Robert I personally don't care at all about .link files, as this is part of the networkd configuration. So whenever you create a new interface - you need to also create a .link along with .network and .netdev. Once new .link files are placed you do restart dbus and systemd-udevd to get devices created. Only then you restart systemd-networkd to configure these devices. So for me value of default .link files is arguable tbh. I _think_ you can also check how systemd-networkd is packaged for hyperscale SIG: https://mirror.stream.centos.org/SIGs/10-stream/hyperscale/ Another thing regarding that, is that I've spotted that you're building systemd-extras against stream 10. As for us the reason, why we can't use hyperscale SIG, is because systemd breaks really badly once attempted to be spawned on Rocky/Alma linux (or any other RHEL derivative). So expectation from EPEL for systemd-extra would be to work outside of CentOS Stream 10, as this is currently a blocker to start upgrades to Rocky/Alma Linux 10 for us.
(In reply to Dmitriy Rabotjagov from comment #17) > I _think_ you can also check how systemd-networkd is packaged for hyperscale > SIG: https://mirror.stream.centos.org/SIGs/10-stream/hyperscale/ Thank you for the pointer, will have a look to it. > Another thing regarding that, is that I've spotted that you're building > systemd-extras against stream 10. As for us the reason, why we can't use > hyperscale SIG, is because systemd breaks really badly once attempted to be > spawned on Rocky/Alma linux (or any other RHEL derivative). I am not sure what you mean: I built systemd-extras for EL8 and EL9 not against Stream, and as it comes to 10, I will build systemd-extras for both, EL10 and EL10.1 (where latter is currently Stream). Given I also ensure no linking against libsystemd-shared or similar, there is no package dependency from systemd-networkd (and systemd-timesyncd) to a specific systemd version.
> and as it comes to 10, I will build systemd-extras for both, EL10 and EL10.1 (where latter is currently Stream) Sorry, I just spotted `stream10` in URI in your comment 11 so decided to mention that we're having issue with hyperscale SIG and networkd from there :) EL8 and EL9 always worked perfectly, so I totally trust your judgement here!
Hi! Sorry, are there any updates on the topic?
Hi! Sorry for pings, but this report is over a year old now and absent systemd-networkd a blocker for us to start consuming EL10. Do you need any help or maybe co-maintenance of the package?
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
FEDORA-EPEL-2025-b3ba07d093 (systemd-extras-257.9-1.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b3ba07d093
FEDORA-EPEL-2025-0c72091106 (systemd-extras-257.9-1.el10_1) has been submitted as an update to Fedora EPEL 10.1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-0c72091106
FEDORA-EPEL-2025-acfc83398c (systemd-extras-257.9-1.el10_0) has been submitted as an update to Fedora EPEL 10.0. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-acfc83398c
FEDORA-EPEL-2025-b3ba07d093 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b3ba07d093 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-0c72091106 has been pushed to the Fedora EPEL 10.1 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-0c72091106 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-acfc83398c has been pushed to the Fedora EPEL 10.0 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-acfc83398c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I'm sorry that it took so long for systemd-extras in EPEL 10.
Oh, by the way, the SELinux policy in RHEL 10.0 doesn't cover systemd-networkd v257. However, it still worked for me, even there were some AVC denials. From what I see in the Git commits the SELinux policy should be updated for RHEL 10.1. In case we need a (temporary) SELinux module for systemd-networkd, some help would be appreciated.
FEDORA-EPEL-2025-0c72091106 (systemd-extras-257.9-2.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-b3ba07d093 (systemd-extras-257.9-2.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2025-acfc83398c (systemd-extras-257.9-2.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository. If problem still persists, please make note of it in this bug report.