Re: [systemd-devel] git requires now linux api userspace headers = 3.13 to build?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31.03.2014 17:18, Tom Gundersen wrote:
I remember reading a while back here = 3.7 being required and
that being reworked to not require so new, but looks like
something backfired there...
Ah, my bad. I did the rework, but forgot to put in the #ifdef's.
Will do.
The following errors seem to imply = 3.10 is now required (which
wouldn't match with the README) - or that this older issue hasn't been
fixed completely (because the 3.8 headers were being used):
Makefile:11905: recipe for target
'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:70:10:
error: 'IFLA_VLAN_PROTOCOL' undeclared here (not in a function)
[IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
^
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
error: array index in initializer not of integer type
[IFLA_VLAN_PROTOCOL]= { .type = NLA_U16 },
^
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:70:9:
error: (near initialization for 'rtnl_link_info_data_vlan_types')
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
error: array index in initializer exceeds array bounds
[IFLA_CARRIER] = { .type = NLA_U8 },
^
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
error: (near initialization for 'rtnl_link_types')
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
warning: excess elements in array initializer [enabled by default]
/var/tmp/paludis/build/sys-apps-systemd-213-r1/work/systemd-213/src/libsystemd/sd-rtnl/rtnl-types.c:231:9:
warning: (near initialization for 'rtnl_link_types') [enabled by default]
make[2]: ***
[src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo] Error 1
- --
Best regards, Wulf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlOIWAcACgkQnuVXRcSi+5orSQCfbiPrFGwzpPwXW38U7BzHwp/r
rDkAoKEE2X47VPKfK2W1KD9hM58RvBed
=W2ca
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] configure.ac: Add a --with-python option.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Zbigniew, On 08.10.2012 14:34, Zbigniew Jędrzejewski-Szmek wrote: I think that a patch which adds the explicit switch, but leaves the default as autodetect, would be welcome. Thanks for your feedback! You'll find the updated patch with the inverted logic attached. - -- Best regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBzB2QACgkQnuVXRcSi+5o+1ACg122jlwHYsL6TO70d3iCkp7OL VsEAoJvdhZqQl1k9GugHCEbiDi4DDrRz =rCDg -END PGP SIGNATURE- From 0e758c4d47428c75b346d51571cb186c65494264 Mon Sep 17 00:00:00 2001 From: Wulf C. Krueger philant...@exherbo.org Date: Sat, 6 Oct 2012 11:37:44 +0200 Subject: [PATCH] configure.ac: Add a --without-python option. Being able to be explicit about Python support (in addition to the default of auto-detecting it) and acting upon the result, specifying it as an option gains us more control about both dependencies and the resulting build. Furthermore, relying purely on auto-detection can lead to problems for source-based distros. E. g. systemd being built before *both* 32-bit 64-bit ABIs are installed will lead to build failures as systemd's build system will pick up either 32-/64-bit Python, conclude both are available and fail if that's not the case. --- configure.ac | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/configure.ac b/configure.ac index 5d7d0c2..1ba266c 100644 --- a/configure.ac +++ b/configure.ac @@ -90,19 +90,26 @@ fi # we use python to build the man page index, and for systemd-python have_python=no have_python_devel=no -AM_PATH_PYTHON(,, [:]) -if test $PYTHON != : ; then -have_python=yes -AC_PATH_PROG([PYTHON_CONFIG], python-config) - -if test -n $PYTHON_CONFIG ; then -have_python_devel=yes -PYTHON_CFLAGS=`$PYTHON_CONFIG --cflags` -PYTHON_LIBS=`$PYTHON_CONFIG --libs` -AC_SUBST(PYTHON_CFLAGS) -AC_SUBST(PYTHON_LIBS) + +AC_ARG_WITH([python], +[AS_HELP_STRING([--without-python], [Disable building the man page index and systemd-python (default: test)])]) + +AS_IF([test x$with_python != xno], [ +AM_PATH_PYTHON(,, [:]) +if test $PYTHON != : ; then +have_python=yes +AC_PATH_PROG([PYTHON_CONFIG], python-config) + +if test -n $PYTHON_CONFIG ; then +have_python_devel=yes +PYTHON_CFLAGS=`$PYTHON_CONFIG --cflags` +PYTHON_LIBS=`$PYTHON_CONFIG --libs` +AC_SUBST(PYTHON_CFLAGS) +AC_SUBST(PYTHON_LIBS) +fi fi -fi +]) + AM_CONDITIONAL([HAVE_PYTHON], [test $have_python = yes]) AM_CONDITIONAL([HAVE_PYTHON_DEVEL], [test $have_python_devel = yes]) -- 1.7.12.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] configure.ac: Add a --with-python option.
From: Wulf C. Krueger philant...@exherbo.org Being explicit about Python support rather than auto-detecting it and acting upon the result, specifying it as an option gains us more control about both dependencies and the resulting build. Furthermore, relying purely on auto-detection can lead to problems for source-based distros. E. g. systemd being built before *both* 32-bit 64-bit ABIs are installed will lead to build failures as systemd's build system will pick up either 32-/64-bit Python, conclude both are available and fail if that's not the case. Signed-off-by: Wulf C. Krueger philant...@exherbo.org --- configure.ac | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/configure.ac b/configure.ac index 5d7d0c2..6308270 100644 --- a/configure.ac +++ b/configure.ac @@ -90,19 +90,26 @@ fi # we use python to build the man page index, and for systemd-python have_python=no have_python_devel=no -AM_PATH_PYTHON(,, [:]) -if test $PYTHON != : ; then -have_python=yes -AC_PATH_PROG([PYTHON_CONFIG], python-config) - -if test -n $PYTHON_CONFIG ; then -have_python_devel=yes -PYTHON_CFLAGS=`$PYTHON_CONFIG --cflags` -PYTHON_LIBS=`$PYTHON_CONFIG --libs` -AC_SUBST(PYTHON_CFLAGS) -AC_SUBST(PYTHON_LIBS) + +AC_ARG_WITH([python], +[AS_HELP_STRING([--with-python], [Build the man page index and systemd-python (default: disabled)])]) + +AS_IF([test x$with_python = xyes], [ +AM_PATH_PYTHON(,, [:]) +if test $PYTHON != : ; then +have_python=yes +AC_PATH_PROG([PYTHON_CONFIG], python-config) + +if test -n $PYTHON_CONFIG ; then +have_python_devel=yes +PYTHON_CFLAGS=`$PYTHON_CONFIG --cflags` +PYTHON_LIBS=`$PYTHON_CONFIG --libs` +AC_SUBST(PYTHON_CFLAGS) +AC_SUBST(PYTHON_LIBS) +fi fi -fi +]) + AM_CONDITIONAL([HAVE_PYTHON], [test $have_python = yes]) AM_CONDITIONAL([HAVE_PYTHON_DEVEL], [test $have_python_devel = yes]) -- 1.7.12.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Lucas,
On 14.06.2012 15:48, Lucas De Marchi wrote:
on source-based distros like gentoo or lfs, and on distros that do not
Don't you have the ability to split the built package in gentoo?
I can confirm and emphasize what William already wrote - for us
source-based distros (Exherbo in my case), there are basically two
approaches:
1. Enable building udev without the systemd parts on the build system
level. This is what William did and the cleanest solution, IMHO.
2. Disable whatever systemd-only parts that can be disabled on the build
system level (e. g. --disable-localed), build the remainder and delete
anything that's still only systemd-specific.
This is error-prone, maintenance-intensive and all around ugly - and I
can prove it ;-) by an excerpt from our udev Exheres (what William
called the build script):
# Remove everything not belonging to what-used-to-be-udev.
edo rm -r
${IMAGE}/etc/{bash_completion.d,dbus-1,modules-load.d,sysctl.d,systemd,tmpfiles.d,xdg}
edo rm -r ${IMAGE}/usr/bin/{journalctl,systemctl,systemd*}
edo rm -r ${IMAGE}/usr/include/systemd
edo rm -r ${IMAGE}/usr/*/{modules-load.d,sysctl.d,tmpfiles.d}
edo rm -r ${IMAGE}/usr/*/systemd/system
edo rm -r ${IMAGE}/usr/*/systemd/system-*
edo rm -r ${IMAGE}/usr/*/systemd/systemd-*
edo rm -r ${IMAGE}/usr/*/systemd/user
edo rm -r ${IMAGE}/usr/*/libsystemd*
edo rm -r ${IMAGE}/usr/*/pkgconfig/libsystemd*
edo rm -r ${IMAGE}/usr/${LIBDIR}/systemd
edo rm -r ${IMAGE}/usr/share/{dbus,polkit}-1
edo rm -r ${IMAGE}/usr/share/man/man{1,3,5}
edo rm -r ${IMAGE}/usr/share/man/man7/{daemon.7,sd-*,systemd*}
edo rm -r
${IMAGE}/usr/share/man/man8/{halt,pam_systemd,poweroff,reboot,runlevel,shutdown,systemd*,telinit}.8
edo rm -r ${IMAGE}/usr/share/pkgconfig/systemd.pc
It's messy as you can see and could be solved rather elegantly by
William's nice and clean work (thanks, William, I was too lazy :) ).
Of course, all this could be avoided if systemd ruled the (Linux) world
but, alas, we're not there (yet) and the way this merge was done did,
unfortunately create some unnecessary antagonism which could be eased at
least a bit if we systemd proponents could generously pat the haters'
backs and say hey, look what they did for you!. ;-)
Joking aside: Considering the elegance and neatness of systemd as a
whole, this would fit in perfectly, IMHO.
--
Best regards, Wulf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Auke, On 14.06.2012 23:05, Kok, Auke-jan H wrote: or pick mdev Let me quote someone about mdev: Haha, mdev, yeah right. Have fun with that... greg k-h (Source: http://article.gmane.org/gmane.linux.gentoo.devel/73627) Nothing prevents you from staying on udev-182 for a few more weeks/months. You're not missing that much. What are we supposed to do in case of security issues with 182? -- Best regards, Wulf ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] setting up to allow separate udev and systemd builds
Hello Auke, On 15.06.2012 06:26, Kok, Auke-jan H wrote: This is a design problem in ALL source based distro's (including the one I worked on for years) and can't be fixed by upstream. Source distro's should really work on doing a proper `make DESTDIR= install` At least Gentoo and Exherbo have been doing that for years. At Exherbo, we do a lot of sanity checks before we move things from DESTDIR to the live fs so don't worry, we don't need to be aided by upstreams at that. :-) 4) Can be maintained out of tree for now: Nothing prevents gentoo from keeping this patch out of tree for their purposes. Yes, we could, but what about exherbo, funtoo, linux from scratch and the other source based distros that may be out there? they could pull the patch from gentoo's repository. We at Exherbo try very hard to avoid any downstream-only patches in order to avoid fragmentation and errors introduced by us (or any third-party). This ensures that we're usually very, very near to what upstreams expect (and support). I think this patch would be a lot more acceptable if you drop the split Makefile.am, remove the --disable-systemd option and just create an extra make install-udev target. It would be a lot smaller too. And it would mostly defeat the purpose. The only remaining benefit would be avoiding the need to manually sort things out. -- Best regards, Wulf ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Lennart,
On 14.05.2012 23:34, Lennart Poettering wrote:
I'll bring this closer to home. Why does make
DESTDIR=%{buildroot} install write to $(sysconfdir) when you've
always proclaimed that it's admin territory? Why not write this
link as: $(systemunitdir)/getty.target.wants/getty@tty1.service?
Since this is just about enabling, not about shipping
configuration. People will frequently not enable the getty on tty1,
on servers with serial gettys and on containers for example.
I'd say, leave the entire enabling part to the distro/packager and
don't do the linking at all.
It's up to the distro to decide about a sane default installation with
respect to about every other part of systemd already - why make this
an exception?
- --
Best regards, Wulf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+yeo0ACgkQnuVXRcSi+5pffwCeN4nbBuJAu2OmwqA1di3m43d8
db8An0hy4mfbgGsfj6/kbAcdU+WfmkQp
=3lBX
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Mounting /dev/pts
Hello, currently, /dev/pts is mounted without the usual options by systemd. If /dev/pts is not mounted with the GID of the tty group, glibc (it assumes tty as the group name, too) runs pt_chown which is generally undesirable since it needs to be setuid (and is owned by root) and according to grantpt(3) With Linux devpts no such helper binary is required. Furthermore, having glibc run pt_chown effectively prevents strace -f'ing any program that creates a pty (assuming it checks for errors properly), e. g. strace -f urxvt. Setting mode=0620 should be done as well as it makes mesg y the default on newly created PTYs (cf. mount(8)) which allows using write(1p). Both options are, to the best of my knowledge, commonly used among Linux distros when mounting /dev/pts. I have tried to come up with a patch myself but failed disgracefully, I'm afraid. Best regards, Wulf signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mounting /dev/pts
noexec,nosuid,gid=tty,mode=0620. [...] I guess Wulf's point isn't, that options in /etc/fstab are not applied but rather that systemd should mount /dev/pts with those options. Indeed. Thanks for point it out, Michael. Hmm, I normally would be happy to do that, but I am a bit concerned about the gid=tty parameter. Before we pass that off to the kernel we'd have to look that up and pass a numeric gid on. Yes, that's what I failed at. :) Hence I'd actually prefer if people apply this in /etc/fstab. Well, that would work for new installations but programatically fiddling with an existing fstab is, IMHO, dangerous, too. I can't really compare that with the dangers of NSS lookups in early userspace, though. Educating users to make such a change in existing installations themselves would theoretically be possible but at least my experience as a distro dev is that you'd have to physically nail such a notice to a user's head in order to make them notice (not to speak of actually doing) anything. Another (rather daring) option would be to try defining well-known GIDs (e. g. from what I've seen tty has usually GID 5) and use that to avoid the need to look the GID up. Anyway, having systemd mount /dev/pts with the above options would be the best solution, IMHO. Best regards, Wulf signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mounting /dev/pts
Hello Lennart, OK, commited a patch now which semi-hardcodes tty=5. It can be overriden with --with-tty-gid= on compile time. However, at this point given that all distros use tty=5 somebody doing this for tty!=5 is a nasty boy, and I'll tell his mom. This should fix your issues. Please test! This works perfectly, thanks. Best regards, Wulf signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: Systemd port on custom embedded linux
The abstract socket namespace support was enabled when compiling dbus. It's simply a bug: https://bugs.freedesktop.org/show_bug.cgi?id=29895 Best regards, Wulf signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
