Bug#760182: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
[ Sorry for the lag. ] Michael Biebl bi...@debian.org (2014-09-02): Am 02.09.2014 10:03, schrieb Ritesh Raj Sarraf: And by the way, can someone please shed some more light on Debian bug: 760182 Per the bug report, there is no systemd support in d-i. Which then means that I need to disable systemd support ? In your udeb build, yes. That typically means you do a dual-build, one for d-i with reduced features and dependencies and and one for the regular deb build. A typical example for this is software using selinux, where there is a non-selinux build for d-i. udev/systemd itself actually does such a dual-build for libudev1-udeb/udev-udeb [1]. The alternative would be, that the systemd package would provide udebs for the library packages. Those would be unused though in d-i atm, so I'm not sure if the d-i maintainers want to go that route. CC: debian-boot for their input. Well, if we can manage to avoid pulling more packages into d-i, all the best. Mraw, KiBi. signature.asc Description: Digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 01:33 PM, Ritesh Raj Sarraf wrote: Could you elaborate a bit more, why those are needed? What is upstream doing about this? The block storage has many components that work closely with one another. Take an example, root fs on LVM on Multipath on iSCSI. The flow for such a setup is to: 1) Start iSCSI and discover the LUNs 2) Detect and create mulitpath maps for matching LUNs in DM Multipath 3) Detect and Activate Volume Group out of the newly detected DM Multipath Physical Volumes 4) Mount the file system. The same can be applied to the shutdown sequence. You want to have proper checks in place before initiating a shutdown of the service. One would argue that the service should not stop if it has active services. Many of the services (mulitpath, iscsi, for example) have a 2 part component. One in the kernel and the other in userspace. The kernel space service will not terminate if any service is active. But the userspace is not so forgiving. In open-iscsi, if you ask the daemon to shutdown, it will. If there are active sessions, the kernel component will not terminate the current sessions. But the userspace daemon will be shutdown. That means, that when there is the next state failure, open-iscsi will have no idea of determining that a LUN state has changed Similar is the case with DM Multipath. The userspace DM Multipath daemon is responsible for polling and keeping an up-to-date status of the Device Mapper maps. If the userspace daemon is inactive, and underneath there is a fabric state change, there is no way to propagate that error to the upper layers. These design issues, since they are part of the core storage stack, if triggered, leave you with a machine with no access to your root disk. Any process at that time, may get into a 'DI' process state or an immediate device failure. The only action then would be to hardware reset your machine. This is why we do a lot of checks in the init scripts to warn the user. Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11). I'm not sure what Red Hat or SUSE has chosen for their latest releases, as I don't work on those products any more. My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. Hi, I did not get any comment on this. How are others doing similar stuff while migrating to systemd ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote: My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. I did not get any comment on this. How are others doing similar stuff while migrating to systemd ? Well, you can always separate the important setup/teardown logic in one or more scripts, call them from the systemd unit and also from the initscript to not have duplicated logic. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Wednesday 03 September 2014 06:51 PM, Henrique de Moraes Holschuh wrote: On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote: My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. I did not get any comment on this. How are others doing similar stuff while migrating to systemd ? Well, you can always separate the important setup/teardown logic in one or more scripts, call them from the systemd unit and also from the initscript to not have duplicated logic. Or better let it be as a shell init script and let systemd handle it in compatibility mode. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Monday 01 September 2014 07:48 PM, Michael Biebl wrote: In native init scripts, we did a lot of check before starting and shutting down the daemon. Things like checking the root device, or tiggering LVM Volume Group activitation. They were easily done in shell. What would the systemd team recommend for it ? Could you elaborate a bit more, why those are needed? What is upstream doing about this? The block storage has many components that work closely with one another. Take an example, root fs on LVM on Multipath on iSCSI. The flow for such a setup is to: 1) Start iSCSI and discover the LUNs 2) Detect and create mulitpath maps for matching LUNs in DM Multipath 3) Detect and Activate Volume Group out of the newly detected DM Multipath Physical Volumes 4) Mount the file system. The same can be applied to the shutdown sequence. You want to have proper checks in place before initiating a shutdown of the service. One would argue that the service should not stop if it has active services. Many of the services (mulitpath, iscsi, for example) have a 2 part component. One in the kernel and the other in userspace. The kernel space service will not terminate if any service is active. But the userspace is not so forgiving. In open-iscsi, if you ask the daemon to shutdown, it will. If there are active sessions, the kernel component will not terminate the current sessions. But the userspace daemon will be shutdown. That means, that when there is the next state failure, open-iscsi will have no idea of determining that a LUN state has changed Similar is the case with DM Multipath. The userspace DM Multipath daemon is responsible for polling and keeping an up-to-date status of the Device Mapper maps. If the userspace daemon is inactive, and underneath there is a fabric state change, there is no way to propagate that error to the upper layers. These design issues, since they are part of the core storage stack, if triggered, leave you with a machine with no access to your root disk. Any process at that time, may get into a 'DI' process state or an immediate device failure. The only action then would be to hardware reset your machine. This is why we do a lot of checks in the init scripts to warn the user. Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11). I'm not sure what Red Hat or SUSE has chosen for their latest releases, as I don't work on those products any more. My inclination is to ship both, the systemd service files and the init scripts, in their current form along with whatever limitations each may have, and let the user choose. And by the way, can someone please shed some more light on Debian bug: 760182 Per the bug report, there is no systemd support in d-i. Which then means that I need to disable systemd support ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 12:46 AM, Christian Hofstaedtler wrote: In native init scripts, we did a lot of check before starting and shutting down the daemon. Things like checking the root device, or tiggering LVM Volume Group activitation. They were easily done in shell. What would the systemd team recommend for it ? That probably depends on why you were doing these things in the first place. It'd be my understanding that udev should take care about most stuff, and for the root device, your initramfs-tools hook should do it. Yes. udev did take care of many things. But not all got covered by udev. Please see my other email for the problem. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Tuesday 02 September 2014 03:00 AM, Michael Biebl wrote: Also, please don't simply override the lintian warning [1]. It is there for a reason. [1] http://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=0783f2ec40f512adfda04c542c5ed38b53bf1247 Yes. After having talked to you, in the next upload, I'll apply the systemd service matching to the init script name. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760182: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 02.09.2014 10:03, schrieb Ritesh Raj Sarraf: And by the way, can someone please shed some more light on Debian bug: 760182 Per the bug report, there is no systemd support in d-i. Which then means that I need to disable systemd support ? In your udeb build, yes. That typically means you do a dual-build, one for d-i with reduced features and dependencies and and one for the regular deb build. A typical example for this is software using selinux, where there is a non-selinux build for d-i. udev/systemd itself actually does such a dual-build for libudev1-udeb/udev-udeb [1]. The alternative would be, that the systemd package would provide udebs for the library packages. Those would be unused though in d-i atm, so I'm not sure if the d-i maintainers want to go that route. CC: debian-boot for their input. [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules#n38 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#760182: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 02.09.2014 10:03, schrieb Ritesh Raj Sarraf: And by the way, can someone please shed some more light on Debian bug: 760182 Per the bug report, there is no systemd support in d-i. Which then means that I need to disable systemd support ? In your udeb build, yes. That typically means you do a dual-build, one for d-i with reduced features and dependencies and and one for the regular deb build. A typical example for this is software using selinux, where there is a non-selinux build for d-i. udev/systemd itself actually does such a dual-build for libudev1-udeb/udev-udeb [1]. The alternative would be, that the systemd package would provide udebs for the library packages. Those would be unused though in d-i atm, so I'm not sure if the d-i maintainers want to go that route. CC: debian-boot for their input. [1] http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules#n38 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Sunday 31 August 2014 12:30 AM, Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC -DLIB_STRING=\lib\ -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory #include systemd/sd-daemon.h ^ compilation terminated. ../Makefile.inc:57: recipe for target 'uxsock.o' failed make[2]: *** [uxsock.o] Error 1 I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf: I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? Looking at the build logs [1], the package itself builds fine but you have missing files, which dh_install --fail-missing complains about: dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), aborting Keep in mind, that in Debian the systemd service files are installed in /lib/systemd/system. [1] https://buildd.debian.org/status/package.php?p=multipath-toolssuite=unstable -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
* Ritesh Raj Sarraf r...@debian.org, 2014-09-01, 16:20: cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC -DLIB_STRING=\lib\ -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory #include systemd/sd-daemon.h ^ compilation terminated. ../Makefile.inc:57: recipe for target 'uxsock.o' failed make[2]: *** [uxsock.o] Error 1 I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? The error is: | dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), aborting | make: *** [install] Error 2 Upstream build system uses systemctl(1) to decide whether or not build with systemd support enabled. Unsurprisingly, systemctl does not exist in buildd chroots. You should either add systemd to build-depends, or fix the build system to be less non-deterministic. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 01.09.2014 13:25, schrieb Michael Biebl: Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf: I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? Looking at the build logs [1], the package itself builds fine but you have missing files, which dh_install --fail-missing complains about: dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), aborting Keep in mind, that in Debian the systemd service files are installed in /lib/systemd/system. By quickly glancing over the package, I also noted that you ship a systemd .service file named multipathd.service but the SysV init scripts are named /etc/init.d/multipath-tools and /etc/init.d/multipath-tools-boot (not quite sure why there are two). systemd continues to start your SysV init scripts, but I assume this is not wanted? Typically, the SysV init script and the systemd .service file should have the same name, this way systemd will automatically pick the native .service unit. If you want to keep the upstream name for the .service, this is absolutely file as well (and even encouraged), but you should make sure the SysV init script is not run then. There are two possible ways: Provide a symlink(alias) /lib/systemd/system/sysvinit_name.service → /lib/systemd/system/upstream_service_file_name or mask the SysV init script by shipping a symlink pointing to /dev/null. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Mon, 1 Sep 2014 13:24:20 +0200 Jakub Wilk jw...@debian.org wrote: * Ritesh Raj Sarraf r...@debian.org, 2014-09-01, 16:20: cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC -DLIB_STRING=\lib\ -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory #include systemd/sd-daemon.h ^ compilation terminated. ../Makefile.inc:57: recipe for target 'uxsock.o' failed make[2]: *** [uxsock.o] Error 1 I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? The error is: | dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), aborting | make: *** [install] Error 2 Upstream build system uses systemctl(1) to decide whether or not build with systemd support enabled. Unsurprisingly, systemctl does not exist in buildd chroots. You should either add systemd to build-depends, or fix the build system to be less non-deterministic. For completeness sake, this is the relevant makefile section: ifndef SYSTEMD ifeq ($(shell systemctl --version /dev/null 21 echo 1), 1) SYSTEMD = $(shell systemctl --version 2 /dev/null | sed -n 's/systemd \([0-9]*\)/\1/p') endif endif So you might want to use $(MAKE) $(OPTFLAGS) LIB=lib SYSTEMD=1 in your debian/rules to get a more reliable build result. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 01.09.2014 13:37, schrieb Michael Biebl: Am 01.09.2014 13:25, schrieb Michael Biebl: Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf: I fixed this one by adding a build-dep to systemd dev library. But for some reason, the build is failing on all architectures. But the same builds fine in my pbuilder. Any help ?? Looking at the build logs [1], the package itself builds fine but you have missing files, which dh_install --fail-missing complains about: dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), aborting Keep in mind, that in Debian the systemd service files are installed in /lib/systemd/system. By quickly glancing over the package, I also noted that you ship a systemd .service file named multipathd.service but the SysV init scripts are named /etc/init.d/multipath-tools and /etc/init.d/multipath-tools-boot (not quite sure why there are two). systemd continues to start your SysV init scripts, but I assume this is not wanted? Typically, the SysV init script and the systemd .service file should have the same name, this way systemd will automatically pick the native .service unit. If you want to keep the upstream name for the .service, this is absolutely file as well (and even encouraged), but you should make sure the SysV init script is not run then. There are two possible ways: Provide a symlink(alias) /lib/systemd/system/sysvinit_name.service → /lib/systemd/system/upstream_service_file_name or mask the SysV init script by shipping a symlink pointing to /dev/null. Another issue: You install the native .service file but you aren't actually enabling it. We recommend to use dh-systemd for that. Since ./multipathd/multipathd.service also references a multipathd.socket unit, make sure this one is installed as well. If you have further questions, please don't hesitate to ask the pkg-systemd-maintainers mailing list. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
On Monday 01 September 2014 05:56 PM, Michael Biebl wrote: By quickly glancing over the package, I also noted that you ship a systemd .service file named multipathd.service but the SysV init scripts are named /etc/init.d/multipath-tools and /etc/init.d/multipath-tools-boot (not quite sure why there are two). Yes. That's how they have been since beginning. Changing the init script now may break for users who may have been using it. systemd continues to start your SysV init scripts, but I assume this is not wanted? Typically, the SysV init script and the systemd .service file should have the same name, this way systemd will automatically pick the native .service unit. If you want to keep the upstream name for the .service, this is absolutely file as well (and even encouraged), but you should make sure the SysV init script is not run then. There are two possible ways: Provide a symlink(alias) /lib/systemd/system/sysvinit_name.service → /lib/systemd/system/upstream_service_file_name or mask the SysV init script by shipping a symlink pointing to /dev/null. Okay.. I'll look into it. Another issue: You install the native .service file but you aren't actually enabling it. We recommend to use dh-systemd for that. Thanks. Will look into it too. Since ./multipathd/multipathd.service also references a multipathd.socket unit, make sure this one is installed as well. Yes. I'm installing them both. If you have further questions, please don't hesitate to ask the pkg-systemd-maintainers mailing list. In native init scripts, we did a lot of check before starting and shutting down the daemon. Things like checking the root device, or tiggering LVM Volume Group activitation. They were easily done in shell. What would the systemd team recommend for it ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 01.09.2014 15:05, schrieb Ritesh Raj Sarraf: On Monday 01 September 2014 05:56 PM, Michael Biebl wrote: If you have further questions, please don't hesitate to ask the pkg-systemd-maintainers mailing list. In native init scripts, we did a lot of check before starting and shutting down the daemon. Things like checking the root device, or tiggering LVM Volume Group activitation. They were easily done in shell. What would the systemd team recommend for it ? Could you elaborate a bit more, why those are needed? What is upstream doing about this? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
In native init scripts, we did a lot of check before starting and shutting down the daemon. Things like checking the root device, or tiggering LVM Volume Group activitation. They were easily done in shell. What would the systemd team recommend for it ? That probably depends on why you were doing these things in the first place. It'd be my understanding that udev should take care about most stuff, and for the root device, your initramfs-tools hook should do it. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Am 01.09.2014 14:26, schrieb Michael Biebl: Am 01.09.2014 13:37, schrieb Michael Biebl: By quickly glancing over the package, I also noted that you ship a systemd .service file named multipathd.service but the SysV init scripts are named /etc/init.d/multipath-tools and /etc/init.d/multipath-tools-boot (not quite sure why there are two). systemd continues to start your SysV init scripts, but I assume this is not wanted? Typically, the SysV init script and the systemd .service file should have the same name, this way systemd will automatically pick the native .service unit. If you want to keep the upstream name for the .service, this is absolutely file as well (and even encouraged), but you should make sure the SysV init script is not run then. There are two possible ways: Provide a symlink(alias) /lib/systemd/system/sysvinit_name.service → /lib/systemd/system/upstream_service_file_name or mask the SysV init script by shipping a symlink pointing to /dev/null. Also, please don't simply override the lintian warning [1]. It is there for a reason. [1] http://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=0783f2ec40f512adfda04c542c5ed38b53bf1247 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
Source: multipath-tools Version: 0.5.0-1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20140830 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC -DLIB_STRING=\lib\ -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory #include systemd/sd-daemon.h ^ compilation terminated. ../Makefile.inc:57: recipe for target 'uxsock.o' failed make[2]: *** [uxsock.o] Error 1 The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2014/08/30/multipath-tools_0.5.0-1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. The build was done with DEB_BUILD_OPTIONS=parallel=4, so if your packaging tries to support this, it might be a good idea to explore whether this might be the cause of the failure. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
