4803 2013-07-02 19:18:51 +0000 systemd.class does not handle multilib well when package has multiple services 2013-09-11 11:40:58 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core unspecified Other Multiple RESOLVED FIXED Medium normal 1.5 1 sgw ross.burton meta.mr.watcher meta.watcher ross.burton sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 34284 0 sgw 2013-07-02 19:18:51 +0000 I was building a multilib system with systemd enabled and found that avahi is reporting installed / not shipped issues with /lib/systemd. I tracked this down to the systemd.bbclass spliting and matching on SYSTEMD_SERVICE and SYSTEM_PACKAGES. When I ran bitbake with -e, I got the following: env:# $SYSTEMD_SERVICE_avahi-dnsconfd env:SYSTEMD_SERVICE_avahi-dnsconfd="avahi-dnsconfd.service" env:# $SYSTEMD_PACKAGES [2 operations] env:SYSTEMD_PACKAGES="lib64-avahi-daemon lib64-avahi-dnsconfd" env:# $SYSTEMD_SERVICE_avahi-daemon env:SYSTEMD_SERVICE_avahi-daemon="avahi-daemon.service" Seems the SYSTEMD_PACKAGES has lib64- while the _SERVER is from the recipe (ie not autogenerated from systemd.bbclass) When there is only one PACKAGE/SERVICE then systemd.bbclass auto generates the values and they look correct and both have the lib64- prefix env.ssh:# $SYSTEMD_PACKAGES env.ssh:SYSTEMD_PACKAGES="lib64-openssh" env.ssh:# $SYSTEMD_SERVICE_${PN} [2 operations] env.ssh:# "SYSTEMD_SERVICE_lib64-openssh" 34315 1 ross.burton 2013-07-03 16:15:00 +0000 I reviewed that class, so I'll take this. 36429 2 ross.burton 2013-09-09 16:16:32 +0000 "[PATCH] avahi: use correct names in SYSTEMD_SERVICE_* variables" sent. 36532 3 ross.burton 2013-09-11 11:40:58 +0000 Fixed in oe-core 013cc8b6397c29e8f0d7adf63d8e06caab778da2.