Summary: | sys-fs/lvm2-2.02.100 - configure needs --exec-prefix | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Tsoy <alexander> |
Component: | [OLD] Core system | Assignee: | Robin Johnson <robbat2> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | agk, cardoe, eugene.shalygin, floppym, pacho, rose |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | lvm2-2.02.100.ebuild.patch |
Description
Alexander Tsoy
2013-09-13 12:41:50 UTC
Created attachment 358574 [details, diff]
lvm2-2.02.100.ebuild.patch
Probably "--sbindir" is also redundant and can be dropped.
(In reply to Alexander Tsoy from comment #1) > Created attachment 358574 [details, diff] [details, diff] > lvm2-2.02.100.ebuild.patch > > Probably "--sbindir" is also redundant and can be dropped. applied that patch now. Sorry, but my LVs still aren't activated after boot. # journalctl -b | grep lvm Sep 13 21:41:51 hiro.oops.intern lvm[343]: No volume groups found Sep 13 21:41:51 hiro.oops.intern lvm[337]: No volume groups found Sep 13 21:41:51 hiro.oops.intern lvm[422]: No volume groups found my PV is a mdadm-raid ... should there be some waiting for the mdadm-raid to be activated? I see the LVs after booting .. but not activated. (In reply to Stefan G. Weichinger from comment #2) > (In reply to Alexander Tsoy from comment #1) > > Created attachment 358574 [details, diff] [details, diff] [details, diff] > > lvm2-2.02.100.ebuild.patch > > > > Probably "--sbindir" is also redundant and can be dropped. > > applied that patch now. > > Sorry, but my LVs still aren't activated after boot. Hmm.. It works for me. > > # journalctl -b | grep lvm > Sep 13 21:41:51 hiro.oops.intern lvm[343]: No volume groups found > Sep 13 21:41:51 hiro.oops.intern lvm[337]: No volume groups found > Sep 13 21:41:51 hiro.oops.intern lvm[422]: No volume groups found > > my PV is a mdadm-raid ... should there be some waiting for the mdadm-raid to > be activated? My PVs are also on MD arrays. MD devices should be activated by udev before lvm2: $ sudo grep ^After /run/systemd/generator/lvm2-activation-early.service After=systemd-udev-settle.service > > I see the LVs after booting .. but not activated. I have no idea what is wrong on your system. =/ *** Bug 484880 has been marked as a duplicate of this bug. *** I guess this isn't needed any longer? - --with-dmeventd-path=/sbin/dmeventd \ (In reply to Pacho Ramos from comment #5) > I guess this isn't needed any longer? > - --with-dmeventd-path=/sbin/dmeventd \ From configure ($lvm_exec_prefix is a value passed by --exec-prefix): # Check whether --with-dmeventd-path was given. if test "${with_dmeventd_path+set}" = set; then : withval=$with_dmeventd_path; DMEVENTD_PATH=$withval else DMEVENTD_PATH="$lvm_exec_prefix/sbin/dmeventd" fi patch looks good to me. can someone commit it for me? pacho? i can't anymore today +*lvm2-2.02.100-r1 (14 Sep 2013) + + 14 Sep 2013; Mike Gilbert <floppym@gentoo.org> +lvm2-2.02.100-r1.ebuild, + -lvm2-2.02.100.ebuild: + Pass --exec-prefix to configure, bug 484752 by Alexander Tsoy. after the 2.02.100-r1 update is get this: $ sudo systemctl status lvm2-lvmetad.service lvm2-lvmetad.service - LVM2 metadata daemon Loaded: error (Reason: Invalid argument) Active: active (running) since Sat 2013-09-14 12:42:37 EDT; 6h ago Docs: man:lvmetad(8) Main PID: 181 (lvmetad) CGroup: /system.slice/lvm2-lvmetad.service └─181 /sbin/lvmetad Sep 14 12:42:37 harrisl-desktop systemd[1]: Starting LVM2 metadata daemon... Sep 14 12:42:37 harrisl-desktop systemd[1]: Started LVM2 metadata daemon. Sep 14 18:40:29 harrisl-desktop systemd[1]: [/usr/lib64/systemd/system/lvm2-lvmetad.service:12] Executable path is not absolute, ignoring: ${exec_prefix}/sbin/lvmetad Sep 14 18:40:29 harrisl-desktop systemd[1]: [/usr/lib64/systemd/system/lvm2-lvmetad.service:13] Executable path is not absolute, ignoring: ${exec_prefix}/sbin/lvmetad -R Sep 14 18:40:29 harrisl-desktop systemd[1]: lvm2-lvmetad.service lacks ExecStart setting. Refusing. Sep 14 18:40:29 harrisl-desktop systemd[1]: Cannot add dependency job for unit lvm2-lvmetad.service, ignoring: Unit lvm2-lvmetad.service failed to load: Invalid argument. See system logs and 'sy...' for details. Hint: Some lines were ellipsized, use -l to show in full. similar for lmv2-monitor.service I haven't rebooted so all is still running but I am worried something is broken. Bah, they are using @sbindir@ in the unit file, which doesn't get fully expanded because it is intended for use in Makefile.in. +*lvm2-2.02.100-r2 (14 Sep 2013) + + 14 Sep 2013; Mike Gilbert <floppym@gentoo.org> +lvm2-2.02.100-r2.ebuild, + lvm2-2.02.100-r1.ebuild: + Restore --sbindir to work around broken @sbindir@ usage, bug 484752. This should really be changed upstream, so I'm reopening this bug. *** Bug 485098 has been marked as a duplicate of this bug. *** (In reply to Mike Gilbert from comment #10) > Bah, they are using @sbindir@ in the unit file, which doesn't get fully > expanded because it is intended for use in Makefile.in. > > +*lvm2-2.02.100-r2 (14 Sep 2013) > + > + 14 Sep 2013; Mike Gilbert <floppym@gentoo.org> +lvm2-2.02.100-r2.ebuild, > + lvm2-2.02.100-r1.ebuild: > + Restore --sbindir to work around broken @sbindir@ usage, bug 484752. > > > This should really be changed upstream, so I'm reopening this bug. The .ebuild is fine in tree and everything was set up by just ./configure flags properly, no? No need to have this bug open here then (In reply to Samuli Suominen from comment #12) > The .ebuild is fine in tree and everything was set up by just ./configure > flags properly, no? > No need to have this bug open here then Well the problem still exists upstream; they should not be using configure to do the @sbindir@ substitution, and should instead do it using sed in the Makefile. There is a description of this in the autoconf manual: http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables If the Gentoo maintainers of this package want to close it, that's fine. I believe that agk had some good reasons for it, so I'm closing as upstream issue for now. |