diff mbox series

[walnascar] systemd.bbclass: generate preset for templates

Message ID 20250604110022.210041-1-mns@gomspace.com
State Accepted
Delegated to: Steve Sakoman
Headers show
Series [walnascar] systemd.bbclass: generate preset for templates | expand

Commit Message

Martin Siegumfeldt June 4, 2025, 11 a.m. UTC
From: Patrick Williams <patrick@stwcx.xyz>

There was a regression introduced by the change to use
systemd-systemctl-native rather than a python fake implementation,
which caused template units to not be properly enabled when set in
the SYSTEMD_SERVICE variable.  Through investigation, it seems that
the best way to re-enable template instances is to handle them
explicitly in the systemd.bbclass and enable them with `preset`, like
most units are handled[1,2].

Per the systemd.preset manpage, the format for template units is
different than for regular units[3].  We need to coalesce all the
template instances onto a single line and emit them as an additional
space-deliminated argument.

Ran this against openbmc's phosphor-ipmi-net recipe and generated
the following preset file:
```
$ cat packages-split/phosphor-ipmi-net/usr/lib/systemd/system-preset/98-phosphor-ipmi-net.preset
enable phosphor-ipmi-net@.service eth0
enable phosphor-ipmi-net@.socket eth0
```

[1]: https://lore.kernel.org/openembedded-core/Z2ch.1747051947055246176.oktf@lists.openembedded.org/
[2]: https://lore.kernel.org/openembedded-core/aDdoTVtCmElpURYD@heinlein/
[3]: https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html

Fixes: 7a580800db39 ("systemd: Build the systemctl executable")
(From OE-Core rev: f33d9b1f434e40a459614d8dc21ce45e11581008)

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes-recipe/systemd.bbclass | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comments

Martin Siegumfeldt June 9, 2025, 7:10 p.m. UTC | #1
Friendly ping
Gyorgy Sarvari June 9, 2025, 7:31 p.m. UTC | #2
On 6/9/25 21:10, Martin Siegumfeldt via lists.openembedded.org wrote:
> Friendly ping
>
It seems that your patch has been added[1] to the walnascar-nut branch
(which is a staging branch for Walnascar). It has however most probably
missed the merge window for version 5.2.1 by a couple of days. The next
Walnascar release, 5.2.2 is expected to be released mid-July.

[1]:
https://git.openembedded.org/openembedded-core-contrib/commit/meta/classes-recipe/systemd.bbclass?h=stable/walnascar-nut&id=ea207dce1f5f8579d8ddde487ac9852f50bfc792
Martin Siegumfeldt June 10, 2025, 5:22 a.m. UTC | #3
> 
> It seems that your patch has been added[1] to the walnascar-nut branch
> (which is a staging branch for Walnascar). It has however most probably
> missed the merge window for version 5.2.1 by a couple of days. The next
> Walnascar release, 5.2.2 is expected to be released mid-July.
> 
> [1]:
> https://git.openembedded.org/openembedded-core-contrib/commit/meta/classes-recipe/systemd.bbclass?h=stable/walnascar-nut&id=ea207dce1f5f8579d8ddde487ac9852f50bfc792
> 

Thanks for the update Gyorgy. I was expecting it to appear within https://git.yoctoproject.org/poky/log/?h=walnascar-next but was obviously wrong. Out of curiosity, is this process described anywhere?
Gyorgy Sarvari June 10, 2025, 8:32 a.m. UTC | #4
On 6/10/25 07:22, Martin Siegumfeldt via lists.openembedded.org wrote:
>
>     It seems that your patch has been added[1] to the walnascar-nut branch
>     (which is a staging branch for Walnascar). It has however most
>     probably
>     missed the merge window for version 5.2.1 by a couple of days. The
>     next
>     Walnascar release, 5.2.2 is expected to be released mid-July.
>
>     [1]:
>     https://git.openembedded.org/openembedded-core-contrib/commit/meta/classes-recipe/systemd.bbclass?h=stable/walnascar-nut&id=ea207dce1f5f8579d8ddde487ac9852f50bfc792
>     <https://git.openembedded.org/openembedded-core-contrib/commit/meta/classes-recipe/systemd.bbclass?h=stable/walnascar-nut&id=ea207dce1f5f8579d8ddde487ac9852f50bfc792>
>
> Thanks for the update Gyorgy. I was expecting it to appear within
> https://git.yoctoproject.org/poky/log/?h=walnascar-next but was
> obviously wrong. Out of curiosity, is this process described anywhere?
>
The release schedule is part of the Stephen Jolley's weekly status
email[1].
Regarding the branches, there are some docs[2], but tbh it doesn't ring
true for stable branches. And there are also some docs about the
release/QA process[3]. But I learned a lot about the release process by
lurking around.

[1]: e.g. https://lists.yoctoproject.org/g/yocto/message/65459
[2]:
https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#tracking-the-status-of-patches
[3]: https://docs.yoctoproject.org/test-manual/test-process.html
diff mbox series

Patch

diff --git a/meta/classes-recipe/systemd.bbclass b/meta/classes-recipe/systemd.bbclass
index 4c9f51d33d..12c59647be 100644
--- a/meta/classes-recipe/systemd.bbclass
+++ b/meta/classes-recipe/systemd.bbclass
@@ -224,6 +224,8 @@  python systemd_populate_packages() {
                         service, pkg_systemd, "Also looked for service unit '{0}'.".format(base) if base is not None else ""))
 
     def systemd_create_presets(pkg, action, user):
+        import re
+
         # Check there is at least one service of given type (system/user), don't
         # create empty files.
         needs_preset = False
@@ -239,10 +241,17 @@  python systemd_populate_packages() {
         presetf = oe.path.join(d.getVar("PKGD"), d.getVar("systemd_unitdir"), "%s-preset/98-%s.preset" % (prefix, pkg))
         bb.utils.mkdirhier(os.path.dirname(presetf))
         with open(presetf, 'a') as fd:
+            template_services = {}
             for service in d.getVar('SYSTEMD_SERVICE:%s' % pkg).split():
                 if not systemd_service_exists(service, user, d):
                     continue
-                fd.write("%s %s\n" % (action,service))
+                if '@' in service and '@.' not in service:
+                    (servicename, instance, service_type) = re.split('[@.]', service)
+                    template_services.setdefault(servicename + '@.' + service_type, []).append(instance)
+                else:
+                    fd.write("%s %s\n" % (action,service))
+            for template, instances in template_services.items():
+                fd.write("%s %s %s\n" % (action, template, ' '.join(instances)))
         d.appendVar("FILES:%s" % pkg, ' ' + oe.path.join(d.getVar("systemd_unitdir"), "%s-preset/98-%s.preset" % (prefix, pkg)))
 
     # Run all modifications once when creating package