It's been released! Reproducible: Always
We should make a decision on --enable-compat-libs before bumping this.
Definitely absolutely we should compile withOUT compat-libs. They only work on x86 due to their use of IFUNC <https://bugzilla.redhat.com/show_bug.cgi?id=1067245>. It'd also be a good way to migrate packages that depend on them (which ones?) to use the newer functions, which, afaik, involve just changing the -l flag.
Also, the 9999 build currently has +kdbus in IUSE. The release notes for 209 suggest that our 209 ebuild should be merely kdbus in IUSE, so that it's not on by default.
I'd say we ought not install the extra hackery libs but pkg-config files would be very helpful during the migration.
(In reply to Michał Górny from comment #4) Hmm... that will require some build system hackery, or we just remove the libraries in src_install.
Created attachment 370894 [details, diff] Install pkg-config files even if enable-compat-libs is not set. (In reply to Mike Gilbert from comment #5) > (In reply to Michał Górny from comment #4) > > Hmm... that will require some build system hackery, or we just remove the > libraries in src_install. Wham bam, see attached. That was exceptionally easy.
(In reply to Jason A. Donenfeld from comment #6) I was hoping to avoid running automake.
Created attachment 370896 [details, diff] Install pkg-config files even if enable-compat-libs is not set. Okay, this one both edits the autoconf file, as before, as well as the shipped .in file for configure to use, so that we don't have to run autoconf again.
Lennart says he's gonna release 210 without the IFUNC funkiness: <http://lists.freedesktop.org/archives/systemd-devel/2014-February/017187.html>. Maybe we should wait for this, then? And perhaps, at that point, we should add a compat USE flag, which is off by default, and have packages that need the compat libs USE-depend on it?
(In reply to Jason A. Donenfeld from comment #9) > Lennart says he's gonna release 210 without the IFUNC funkiness: > <http://lists.freedesktop.org/archives/systemd-devel/2014-February/017187. > html>. > > Maybe we should wait for this, then? Sounds like a good idea. Thanks for mailing them. > And perhaps, at that point, we should add a compat USE flag, which is off by > default, and have packages that need the compat libs USE-depend on it? No need to. We'll just enable the compat for some time, wait for all offenders to be fixed and disable it in a future version/revbump.
Oh boy, this is a big bump. Other things we need to get done before we can bump: - 80-net-name-slot.rules is gone, and 99-default.link replaces it. We should probably document this and have a consistent way for folks to have oldstyle net names. <http://git.zx2c4.com/systemd/commit/?id=daeb71> - The bluetooth unit files seem to have changed or are somehow incompatible with 209. - 209 complains about ControlGroup= in services, such as with rtkit-daemon.service, so these will have to be updated
Copying udev maintainers as the network naming changes will affect them.
(In reply to Jason A. Donenfeld from comment #3) > Also, the 9999 build currently has +kdbus in IUSE. The release notes for 209 > suggest that our 209 ebuild should be merely kdbus in IUSE, so that it's not > on by default. + 21 Feb 2014; Mike Gilbert <floppym@gentoo.org> systemd-9999.ebuild: + Disable kdbus by default to match upstream behavior.
--enable-compat-libs is now enabled in 9999, in anticipation of 210. + 21 Feb 2014; Jason A. Donenfeld <zx2c4@gentoo.org> systemd-9999.ebuild: + Compat libs for 9999. +
Created attachment 370930 [details, diff] Don't automatically start systemd-networkd For whatever reason, systemd-209 wants networkd to always run by default on all machines, with the only way of preventing it being a 'systemctl mask'. It makes more sense for it to be a normal enable-able unit, with 'systemctl enable', so that it's opt-in for Gentoo users.
(In reply to Jason A. Donenfeld from comment #15) As I mentioned in IRC, networkd doesn't seem to do anything unless you create a configuration for it. Let's not apply this unless upstream accepts it.
(In reply to Jason A. Donenfeld from comment #11) > Oh boy, this is a big bump. Other things we need to get done before we can > bump: > > - 80-net-name-slot.rules is gone, and 99-default.link replaces it. We should > probably document this and have a consistent way for folks to have oldstyle > net names. <http://git.zx2c4.com/systemd/commit/?id=daeb71> (In reply to Mike Gilbert from comment #12) > Copying udev maintainers as the network naming changes will affect them. This has been known for month or so now, and udev-9999.ebuild has been out-of-sync since that commit happened in git. So, net.ifnames=0 will still work to disable the new naming, but instead of replacing or symlinking 80-net-name-slot.rules to /dev/null same threatement should now be applied to the .link file (was it really named 99-default.link?) I've warned WilliamH in private at IRC about it, I hope he remembers it, that we can't do 209 bump straight to ~arch but it needs a p.mask time. I don't even know yet if we can make the new way work with sys-fs/udev at all, as I don't know how tied it is to systemd itself. I'm going to hospital for a week starting from monday for a review period (backpain) and won't be available, so if I don't manage to get this bump done during this weekend, it will be postponed for entire week unless someone else figures it all out. I also don't think there is any hurry for the 209 bump, as all the major fixes are already in 208 for what udev is concerned. I just wanted to give a status update, that there is currently 'no status' and there might not be for entire +-10 days. This does NOT mean i'm abandoning ship, it really just means I'll be away for the *one* week.
(In reply to Mike Gilbert from comment #16) > As I mentioned in IRC, networkd doesn't seem to do anything unless you > create a configuration for it. Let's not apply this unless upstream accepts > it. Yes but, in agreement with the upstream developers, it shouldn't be running wasting resources if it has nothing to do. That's why they've merged my commit. They've put another one on top enables it by default in /etc during make install (instead of /usr/lib), which is still stupid, but allows administrators to "systemctl disable" it, which is nice, and probably something we should document as well.
(In reply to Jason A. Donenfeld from comment #18) > (In reply to Mike Gilbert from comment #16) > > As I mentioned in IRC, networkd doesn't seem to do anything unless you > > create a configuration for it. Let's not apply this unless upstream accepts > > it. > > Yes but, in agreement with the upstream developers, it shouldn't be running > wasting resources if it has nothing to do. > > That's why they've merged my commit. Say what? commit msg: "enable networkd by default" http://cgit.freedesktop.org/systemd/systemd/commit/?id=ca1a3847695d02ebe62007d8f335f23d3fe04638
OK, =sys-fs/udev-209 is in Portage w/ network interface naming working. Upstream networkdir= is using $(prefix) instead of $(rootprefix) which is an bug and I'll try to submit a patch for it. However, the code itself is looking at both /usr/lib/systemd/network/ and /lib/systemd/network/ as-is. Since systemd-udevd goes to / and network configuration file, 99-default.link, needs to be around during early boot, of course I've made sys-fs/udev install 99-default.link to /lib/systemd/network/ I don't think there is anything left for udev-bugs@ here. If you disagree, please reCC.
Regarding the network interface thing, apparently this is what arch does for it: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/systemd.install?h=packages/systemd#n65
(In reply to Samuli Suominen from comment #19) > Say what? > > commit msg: "enable networkd by default" > > http://cgit.freedesktop.org/systemd/systemd/commit/ > ?id=ca1a3847695d02ebe62007d8f335f23d3fe04638 http://cgit.freedesktop.org/systemd/systemd/commit/?id=c4a0b20 They merged my commit, then put another one on top as I explained in my previous post.
(In reply to Jason A. Donenfeld from comment #21) > Regarding the network interface thing, apparently this is what arch does for > it: > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/systemd. > install?h=packages/systemd#n65 Their logic is incomplete as it might be any XX-yyyy.rules in /etc/udev/rules.d/ and we have in fact encouraged names like 76-my-network.rules in the past, so hard to figure out what user has done in /etc/udev/rules.d/ I've updated the wiki: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_208_to_209 And I'm thinking about sending a news item too, before adding KEYWORDS to >=sys-fs/udev-209's ebuild Anyways, there is not much left to say about the iface naming, and if there is, it propably doesn't belong here
It looks like what they prefer to do is mask out 80-net-setup-link.rules. This seems like an approach more in line with what we're doing before. "80-net-name-slot.rules" became "80-net-setup-link.rules", which is easier to understand.
And they've updated the wiki to reflect this: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ "You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's rule file for the default policy: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules (since v209: this file was called 80-net-name-slot.rules in release v197 through v208)" Our suggestion should follow suit.
Just wanted to add a couple quick notes on this release I found: - libseccomp-1.0 appears to be insufficent, libseccomp-2.1.1 works - the configure script forces --without-python if lxml isn't installed and then chokes on --enable-python-devel. Adding lxml to the dependencies under python? fixed the issue. - --enable-compat-libs causes the following ld abort for me on gcc 4.6.3, 4.7.3-r1 and binutils 2.23.1, 2.23.2, and 2.24-r2. So for now I'm sticking with the pkg-config patch posted here. libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/libsystemd_journal_la-libsystemd-journal.o -Wl,-rpath -Wl,/var/tmp/portage/sys-apps/systemd-9999/work/systemd-9999-amd64/.libs -Wl,--as-needed ./.libs/libsystemd.so -lrt -lresolv -ldl -flto -O2 -march=core-avx-i -Wl,--no-undefined -Wl,--gc-sections -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,-fuse-ld=gold -Wl,--version-script=/var/tmp/portage/sys-apps/systemd-9999/work/systemd-9999/src/compat-libs/libsystemd-journal.sym -Wl,-O1 -pthread -Wl,-soname -Wl,libsystemd-journal.so.0 -o .libs/libsystemd-journal.so.0.11.4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: BFD (GNU Binutils) 2.24 internal error, aborting at /var/tmp/portage/sys-devel/binutils-2.24-r2/work/binutils-2.24/bfd/elf64-x86-64.c line 3363 in elf_x86_64_relocate_section /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: Please report this bug. collect2: error: ld returned 1 exit status
I think we're pretty much good-to-go with v210. Open questions: 1. do we want to drop compat .so* already or do we want to wait for 210-r1 or 211, and test rev-deps in the meantime? 2. do we want to do something special about network rule changes? 3. do we want it to go straight to ~arch or via p.mask?
(In reply to Michał Górny from comment #27) > I think we're pretty much good-to-go with v210. > > Open questions: > > 1. do we want to drop compat .so* already or do we want to wait for 210-r1 > or 211, and test rev-deps in the meantime? Keep the compat libs for now; we need to test stuff. Maybe add a forced use flag (compat-libs) to make it simple to disable. > 2. do we want to do something special about network rule changes? If people have masked 80-net-name-slot.rules, I suppose we could convert that to a mask of 80-net-setup-link.rules. I would check for a /dev/null symlink, but ewarn for anything else. > 3. do we want it to go straight to ~arch or via p.mask? I would prefer to have it masked for a week or so.
I have been getting this QA notice, but it seems invalid based on my build log. * QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /usr/lib64/libnss_myhostname.so.2 * /usr/lib64/libgudev-1.0.so.0.2.0 * /usr/lib/libnss_myhostname.so.2 * /usr/lib/libgudev-1.0.so.0.2.0
+*systemd-210 (25 Feb 2014) + + 25 Feb 2014; Michał Górny <mgorny@gentoo.org> +systemd-210.ebuild, + systemd-9999.ebuild: + Version bump, bug #501860. Well, since it's being committed p.masked, I've removed the libs but kept pkg-config files. As for network rules, I didn't do anything special right now but there's still time to do it.
We're running into this problem too: https://bugs.kde.org/show_bug.cgi?id=331403 https://bugs.archlinux.org/task/38986?project=1&openedfrom=-1+week
The KDE issues have now been solved. The current 210/9999 builds have compat-libs *disabled*, by the way. Not sure what the intended behavior is, but by default they're disabled, so if we want them, we need to pass the enable flag.
Some minor notes: 1. After upgrading to systemd-210, it is necessary to reemerge dbus (revdep-rebuild) or you might end up with a pretty unbootable system. Perhaps a subslot dependency should be set? 2. Mount units can no longer set FsckPassNo (which is presumably now also ignored in /etc/fstab). 3. Please discourage using kdbus for now: As far as I understand, without policies, this can easily lead to privilege raising exploits.
(In reply to Martin Väth from comment #33) > 1. After upgrading to systemd-210, it is necessary to reemerge dbus > (revdep-rebuild) or you might end up with a pretty unbootable system. > Perhaps a subslot dependency should be set? Yeah, portage users will get a preserved-libs warning. A slot-operator dependency would indeed be appropriate here.
210 has security issues, and 211 is out, so we'd focus on the latter instead.
