Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Wed, May 14, 2014 at 1:05 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Umut Tezduyar Lindskog at 13/05/14 18:37 did gyre and gimble: On Wednesday, May 7, 2014, Colin Guthrie gm...@colin.guthr.ie mailto:gm...@colin.guthr.ie wrote: 'Twas brillig, and Umut Tezduyar Lindskog at 04/03/14 12:44 did gyre and gimble: Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. As you have stated, it matters for build time and we have build machines not running the latest and greatest SW. I wouldn't be surprised if we are not alone. Yeah, some of our build nodes are actually pretty old too, but that shouldn't matter really as the building happens inside a chroot with the latest packages, which includes latest ln. Do you really build on an older node against older libs with older ln etc? I would have thought you'd also have some kind of chroot on these nodes when building too no? No. We just have virtual machines with Debian Wheezy to do the build. Forgive my ignorance, but I'm curious as to how that works now :) No worries. So the build runs on an older distro, but it's built *for* newer versions of the distro (I don't recall all the Debian names, so I'd have to look up exactly how old Wheezy is...) - is that correct? We are cross compiling for our own distro. Our build machines which execute the programs to do the build are Debian stable. Umut Assuming that's right, how do you deal with linking against older system libraries etc when building the package? If you do not install all the new deps (and buildchain) in a chroot, how are they installed and made available to the compiler? Are they just installed somehow relocated and passed in as compile time options (i.e. overriding the pkgconfig path etc.) Thanks! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
'Twas brillig, and Umut Tezduyar Lindskog at 13/05/14 18:37 did gyre and gimble: On Wednesday, May 7, 2014, Colin Guthrie gm...@colin.guthr.ie mailto:gm...@colin.guthr.ie wrote: 'Twas brillig, and Umut Tezduyar Lindskog at 04/03/14 12:44 did gyre and gimble: Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. As you have stated, it matters for build time and we have build machines not running the latest and greatest SW. I wouldn't be surprised if we are not alone. Yeah, some of our build nodes are actually pretty old too, but that shouldn't matter really as the building happens inside a chroot with the latest packages, which includes latest ln. Do you really build on an older node against older libs with older ln etc? I would have thought you'd also have some kind of chroot on these nodes when building too no? No. We just have virtual machines with Debian Wheezy to do the build. Forgive my ignorance, but I'm curious as to how that works now :) So the build runs on an older distro, but it's built *for* newer versions of the distro (I don't recall all the Debian names, so I'd have to look up exactly how old Wheezy is...) - is that correct? Assuming that's right, how do you deal with linking against older system libraries etc when building the package? If you do not install all the new deps (and buildchain) in a chroot, how are they installed and made available to the compiler? Are they just installed somehow relocated and passed in as compile time options (i.e. overriding the pkgconfig path etc.) Thanks! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Wednesday, May 7, 2014, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Umut Tezduyar Lindskog at 04/03/14 12:44 did gyre and gimble: Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. As you have stated, it matters for build time and we have build machines not running the latest and greatest SW. I wouldn't be surprised if we are not alone. Yeah, some of our build nodes are actually pretty old too, but that shouldn't matter really as the building happens inside a chroot with the latest packages, which includes latest ln. Do you really build on an older node against older libs with older ln etc? I would have thought you'd also have some kind of chroot on these nodes when building too no? No. We just have virtual machines with Debian Wheezy to do the build. Umut Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org javascript:; http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
'Twas brillig, and Umut Tezduyar Lindskog at 04/03/14 12:44 did gyre and gimble: Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. As you have stated, it matters for build time and we have build machines not running the latest and greatest SW. I wouldn't be surprised if we are not alone. Yeah, some of our build nodes are actually pretty old too, but that shouldn't matter really as the building happens inside a chroot with the latest packages, which includes latest ln. Do you really build on an older node against older libs with older ln etc? I would have thought you'd also have some kind of chroot on these nodes when building too no? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
Hi, From: systemd-devel-boun...@lists.freedesktop.org [systemd-devel-boun...@lists.freedesktop.org] On Behalf Of Lennart Poettering [lenn...@poettering.net] Sent: Tuesday, March 04, 2014 2:38 PM To: Umut Tezduyar Cc: systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink On Tue, 04.03.14 12:00, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, Stable version of some distros (Debian Wheezy nor Ubuntu LTS 12.04) still don't have support for this. Is it not possible to solve it in another way. I'd be happy to merge a patch that adds an autoconf check for this and then falls back to absolute symlinks if the relative ones don't work. Is this something you would be interested: http://lists.openembedded.org/pipermail/openembedded-core/2014-March/090162.html Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Tue, 11.03.14 22:04, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Is this something you would be interested: http://lists.openembedded.org/pipermail/openembedded-core/2014-March/090162.html Well, this is implemented in python, and we don't want a python dependency for the build system... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On 04/03/14 11:00, Umut Tezduyar wrote: Stable version of some distros (Debian Wheezy nor Ubuntu LTS 12.04) still don't have support for this. Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. The development versions of Debian and Ubuntu, where a newer systemd will be introduced and compiled, already have recent coreutils and a somewhat recent systemd. Having said that, for the packaged systemd on Debian and Ubuntu it's irrelevant whether these symlinks are relative or absolute, because dh_link will adjust them after installation to be in the form Debian Policy says they should be (absolute if symlink and target are in different top-level directories like /lib and /usr, relative if they are in the same top-level directory). The situation that *does* matter on infrequently-released distributions (Debian stable, Ubuntu LTS, RHEL, SLED, etc.) is the upgrade from one stable release to the next; being able to install most packages from release n on release n-1, usually lowest-level/most-depended-on first, is desirable to avoid dependency loops (can't upgrade to the new pkgA without the new pkgB, can't upgrade to the new pkgB without the new pkgA, no way to proceed). S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
Hi, -Original Message- From: systemd-devel-boun...@lists.freedesktop.org [mailto:systemd- devel-boun...@lists.freedesktop.org] On Behalf Of Simon McVittie Sent: den 4 mars 2014 12:56 To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink On 04/03/14 11:00, Umut Tezduyar wrote: Stable version of some distros (Debian Wheezy nor Ubuntu LTS 12.04) still don't have support for this. Does that actually matter much? This ln usage is at build time, not install time, and those stable versions aren't going to upgrade to a current systemd, because avoiding non-minimal upgrades is the whole point of stable distro releases. As you have stated, it matters for build time and we have build machines not running the latest and greatest SW. I wouldn't be surprised if we are not alone. The development versions of Debian and Ubuntu, where a newer systemd will be introduced and compiled, already have recent coreutils and a somewhat recent systemd. Having said that, for the packaged systemd on Debian and Ubuntu it's irrelevant whether these symlinks are relative or absolute, because dh_link will adjust them after installation to be in the form Debian Policy says they should be (absolute if symlink and target are in different top-level directories like /lib and /usr, relative if they are in the same top-level directory). The situation that *does* matter on infrequently-released distributions (Debian stable, Ubuntu LTS, RHEL, SLED, etc.) is the upgrade from one stable release to the next; being able to install most packages from release n on release n-1, usually lowest-level/most-depended-on first, is desirable to avoid dependency loops (can't upgrade to the new pkgA without the new pkgB, can't upgrade to the new pkgB without the new pkgA, no way to proceed). S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Tue, 04.03.14 12:00, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, Stable version of some distros (Debian Wheezy nor Ubuntu LTS 12.04) still don't have support for this. Is it not possible to solve it in another way. I'd be happy to merge a patch that adds an autoconf check for this and then falls back to absolute symlinks if the relative ones don't work. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Mon, 03.03.14 16:26, Mike Gilbert (flop...@gentoo.org) wrote: On Mon, Mar 3, 2014 at 11:57 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 03.03.14 16:12, Michael Biebl (mbi...@gmail.com) wrote: The patch looked ok to me as is, but I can certainly add a --relative if you prefer. Should dbus1-generator-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(usergeneratordir) $(AM_V_LN)$(LN_S) -f $(systemgeneratordir)/systemd-dbus1-generator $(DESTDIR)$(usergeneratordir)/systemd-dbus1-generator be updated then as well? I now changed the makefile to only generate relative symlinks. THis makes use of ln --relative -s everywhere, which has been supported in coreutils for 2y or so, hence I figure this should be OK. If this breaks for people we can consider making use of this only after an autoconf check. Would someone mind adding a Backport note for at least my original commit? I'm not so sure about tagging Lennart's more extensive change. Added. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Sun, 02.03.14 23:37, Mike Gilbert (flop...@gentoo.org) wrote: The symlink is created in bindir (/usr/bin), and points to a binary which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A relative symlink does not work here. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 38445fb..e7134a2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \ bus-proxyd-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir) - $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge + $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge bus-proxyd-uninstall-hook: rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge This really sounds like we want to use ln's --relative option here, so that the symlink is relative regardless what the setup is. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
2014-03-03 15:32 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Sun, 02.03.14 23:37, Mike Gilbert (flop...@gentoo.org) wrote: The symlink is created in bindir (/usr/bin), and points to a binary which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A relative symlink does not work here. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 38445fb..e7134a2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \ bus-proxyd-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir) - $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge + $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge bus-proxyd-uninstall-hook: rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge This really sounds like we want to use ln's --relative option here, so that the symlink is relative regardless what the setup is. The patch looked ok to me as is, but I can certainly add a --relative if you prefer. Should dbus1-generator-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(usergeneratordir) $(AM_V_LN)$(LN_S) -f $(systemgeneratordir)/systemd-dbus1-generator $(DESTDIR)$(usergeneratordir)/systemd-dbus1-generator be updated then as well? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Mon, Mar 03, 2014 at 04:16:28PM +0100, Michael Biebl wrote: 2014-03-03 16:12 GMT+01:00 Michael Biebl mbi...@gmail.com: This really sounds like we want to use ln's --relative option here, so that the symlink is relative regardless what the setup is. The patch looked ok to me as is, but I can certainly add a --relative if you prefer. Btw, what's the reason why you prefer relative symlinks in this case? Works when looking at a container from outside? Is nicer during package creation? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Mon, 03.03.14 16:12, Michael Biebl (mbi...@gmail.com) wrote: The patch looked ok to me as is, but I can certainly add a --relative if you prefer. Should dbus1-generator-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(usergeneratordir) $(AM_V_LN)$(LN_S) -f $(systemgeneratordir)/systemd-dbus1-generator $(DESTDIR)$(usergeneratordir)/systemd-dbus1-generator be updated then as well? I now changed the makefile to only generate relative symlinks. THis makes use of ln --relative -s everywhere, which has been supported in coreutils for 2y or so, hence I figure this should be OK. If this breaks for people we can consider making use of this only after an autoconf check. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
On Mon, Mar 3, 2014 at 11:57 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 03.03.14 16:12, Michael Biebl (mbi...@gmail.com) wrote: The patch looked ok to me as is, but I can certainly add a --relative if you prefer. Should dbus1-generator-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(usergeneratordir) $(AM_V_LN)$(LN_S) -f $(systemgeneratordir)/systemd-dbus1-generator $(DESTDIR)$(usergeneratordir)/systemd-dbus1-generator be updated then as well? I now changed the makefile to only generate relative symlinks. THis makes use of ln --relative -s everywhere, which has been supported in coreutils for 2y or so, hence I figure this should be OK. If this breaks for people we can consider making use of this only after an autoconf check. Would someone mind adding a Backport note for at least my original commit? I'm not so sure about tagging Lennart's more extensive change. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
The symlink is created in bindir (/usr/bin), and points to a binary which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A relative symlink does not work here. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 38445fb..e7134a2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \ bus-proxyd-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir) - $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge + $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge bus-proxyd-uninstall-hook: rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink
2014-03-03 5:37 GMT+01:00 Mike Gilbert flop...@gentoo.org: The symlink is created in bindir (/usr/bin), and points to a binary which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A relative symlink does not work here. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 38445fb..e7134a2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \ bus-proxyd-install-hook: $(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir) - $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge + $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd $(DESTDIR)$(bindir)/systemd-stdio-bridge bus-proxyd-uninstall-hook: rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Applied, thanks Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
