| Summary: | ~sys-apps/systemd-197 with several packages - fatal error: systemd/sd-daemon.h: No such file or directory | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Albert W. Hopkins <marduk> |
| Component: | [OLD] Core system | Assignee: | Gentoo systemd Team <systemd> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | public.avatar, ssuominen |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
It seems the issue is this header file is not included with systemd, but with udev now. Also it appears that /usr/include/systemd does not get considered in systemd's pkgconfig file, so packages that use pkgconfig to get the header paths dont' pick it up. Adding the following to /usr/share/pkgconfig/systemd.pc allows the failing packages to (re)build:
includedir=/usr/include/systemd
Could you try upgrading udev to 197-r4? I've bumped the blocker to not accept older versions which lack the sd-daemon.h header. If that doesn't help, please let me know and we'll see why is that. You have to use at least -r3 (and if you are a ~arch user, you must upgrade to -r4). If you emerged -r3 on stable system by unmasking it before it was intended to hit stable, you have to re-emerge -r3. Every reference of sd-daemon.h in systemd tarball has #include <systemd/sd-daemon.h> And sd-daemon.h and .pc file are installed starting from -r3 (like explained above) No probs here (In reply to comment #3) > You have to use at least -r3 (and if you are a ~arch user, you must upgrade > to -r4). If you emerged -r3 on stable system by unmasking it before it was > intended to hit stable, you have to re-emerge -r3. > > Every reference of sd-daemon.h in systemd tarball has #include > <systemd/sd-daemon.h> > > And sd-daemon.h and .pc file are installed starting from -r3 (like explained > above) > The problem seems to be with udev-197-r3, but goes away in r4. At the time I reported this bug r4 wasn't available. I'm in ~arch. Before I had masked udev-197 entirely because there was no systemd-197 in portage and so the requirements for systemd were not met. When systemd-197 became available in portage I unmasked udev-197 and that's when I got the postinst messages about rebuilding packages, and then the build failures. So in summary, it appears that udev-197-r4 has the fix but that wasn't available at the time I submitted the bug. Indeed if I downgrade to udev-197-r3 I can still recreate the issue. (In reply to comment #4) > (In reply to comment #3) > > You have to use at least -r3 (and if you are a ~arch user, you must upgrade > > to -r4). If you emerged -r3 on stable system by unmasking it before it was > > intended to hit stable, you have to re-emerge -r3. > > > > Every reference of sd-daemon.h in systemd tarball has #include > > <systemd/sd-daemon.h> > > > > And sd-daemon.h and .pc file are installed starting from -r3 (like explained > > above) > > > > The problem seems to be with udev-197-r3, but goes away in r4. At the time > I reported this bug r4 wasn't available. > > I'm in ~arch. Before I had masked udev-197 entirely because there was no > systemd-197 in portage and so the requirements for systemd were not met. > When systemd-197 became available in portage I unmasked udev-197 and that's > when I got the postinst messages about rebuilding packages, and then the > build failures. > > So in summary, it appears that udev-197-r4 has the fix but that wasn't > available at the time I submitted the bug. Indeed if I downgrade to > udev-197-r3 I can still recreate the issue. okay, it's somewhat my fault because I didn't revision bump when I fixed the missing header. but -r4 is the revision bump now, so this one is solved. don't get offended by the resolution invalid :-) thanks anyway for caring & reporting! @systemd maintainers: just depend on >=sys-fs/udev-197-r3 so you can stabilize systemd, because -r4 of udev is not going stable anytime soon it looks stable users got the sd-daemon.h fix from -r3. (In reply to comment #6) Confirmed. I updated the blocker to !<sys-fs/udev-197-r3. *** Bug 453380 has been marked as a duplicate of this bug. *** |
After upgrading to udev-197 and, subsequently, systemd-197 the postinst message says to rebuild packages with files in /usr/lib/udev. But some of those packages fail with the following error: fatal error: systemd/sd-daemon.h: No such file or directory These packages fail: [ebuild R ] sys-power/upower-0.9.19 USE="introspection systemd -debug -doc -ios" 0 kB [ebuild R ] media-sound/pulseaudio-3.0 USE="X alsa bluetooth dbus gdbm glib gnome orc realtime systemd udev -asyncns -avahi -caps -doc -equalizer -gtk -ipv6 -jack -libsamplerate -lirc (-neon) (-oss) -ssl (-system-wide) -tcpd {-test} -webrtc-aec -xen" 0 kB [ebuild R ] sys-fs/udisks-2.0.91:2 USE="introspection systemd -crypt -debug -gptfdisk (-selinux)" 0 kB OTOH they (re)build successfully with the *-196 packages. In the mean time, I've masked the *-197 packages (I'm also having issues with lvm.service starting on systemd-197, but may be related to the above): [ebuild U ] sys-fs/udev-197-r3 [196-r1] USE="acl gudev hwdb introspection keymap kmod static-libs -doc -openrc (-selinux)" 0 kB [ebuild U ] sys-apps/systemd-197 [196] USE="acl kmod pam python xattr -audit -cryptsetup -gcrypt -http -lzma -qrcode (-selinux) -tcpd -vanilla" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 0 kB