Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 501860

Summary: sys-apps/systemd-210 version bump
Product: Gentoo Linux Reporter: Jason A. Donenfeld <zx2c4>
Component: Current packagesAssignee: Gentoo systemd Team <systemd>
Status: RESOLVED OBSOLETE    
Severity: normal CC: alexander, egorov_egor, genzilla, mail, marduk, martin, mike, rorgoroth
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.html
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 501306    
Bug Blocks:    
Attachments: Install pkg-config files even if enable-compat-libs is not set.
Install pkg-config files even if enable-compat-libs is not set.
Don't automatically start systemd-networkd

Description Jason A. Donenfeld gentoo-dev 2014-02-20 01:59:55 UTC
It's been released!

Reproducible: Always
Comment 1 Mike Gilbert gentoo-dev 2014-02-20 06:30:21 UTC
We should make a decision on --enable-compat-libs before bumping this.
Comment 2 Jason A. Donenfeld gentoo-dev 2014-02-20 12:56:56 UTC
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.
Comment 3 Jason A. Donenfeld gentoo-dev 2014-02-20 12:57:54 UTC
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.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-02-20 16:53:51 UTC
I'd say we ought not install the extra hackery libs but pkg-config files would be very helpful during the migration.
Comment 5 Mike Gilbert gentoo-dev 2014-02-20 17:55:31 UTC
(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.
Comment 6 Jason A. Donenfeld gentoo-dev 2014-02-20 18:02:19 UTC
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.
Comment 7 Mike Gilbert gentoo-dev 2014-02-20 18:11:06 UTC
(In reply to Jason A. Donenfeld from comment #6)

I was hoping to avoid running automake.
Comment 8 Jason A. Donenfeld gentoo-dev 2014-02-20 18:25:56 UTC
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.
Comment 9 Jason A. Donenfeld gentoo-dev 2014-02-20 19:29:33 UTC
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?
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-02-20 19:42:21 UTC
(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.
Comment 11 Jason A. Donenfeld gentoo-dev 2014-02-21 02:46:21 UTC
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
Comment 12 Mike Gilbert gentoo-dev 2014-02-21 02:59:07 UTC
Copying udev maintainers as the network naming changes will affect them.
Comment 13 Mike Gilbert gentoo-dev 2014-02-21 03:05:31 UTC
(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.
Comment 14 Jason A. Donenfeld gentoo-dev 2014-02-21 03:20:31 UTC
--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.
+
Comment 15 Jason A. Donenfeld gentoo-dev 2014-02-21 03:40:14 UTC
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.
Comment 16 Mike Gilbert gentoo-dev 2014-02-21 03:48:38 UTC
(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.
Comment 17 Samuli Suominen (RETIRED) gentoo-dev 2014-02-21 05:39:25 UTC
(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.
Comment 18 Jason A. Donenfeld gentoo-dev 2014-02-21 14:01:24 UTC
(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.
Comment 19 Samuli Suominen (RETIRED) gentoo-dev 2014-02-21 14:03:18 UTC
(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
Comment 20 Samuli Suominen (RETIRED) gentoo-dev 2014-02-21 14:06:14 UTC
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.
Comment 21 Jason A. Donenfeld gentoo-dev 2014-02-21 14:06:30 UTC
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
Comment 22 Jason A. Donenfeld gentoo-dev 2014-02-21 14:07:34 UTC
(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.
Comment 23 Samuli Suominen (RETIRED) gentoo-dev 2014-02-21 14:33:53 UTC
(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
Comment 24 Jason A. Donenfeld gentoo-dev 2014-02-21 14:52:43 UTC
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.
Comment 25 Jason A. Donenfeld gentoo-dev 2014-02-21 15:44:21 UTC
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.
Comment 26 mike@marineau.org 2014-02-21 23:44:17 UTC
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
Comment 27 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-02-24 22:36:11 UTC
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?
Comment 28 Mike Gilbert gentoo-dev 2014-02-24 22:52:14 UTC
(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.
Comment 29 Mike Gilbert gentoo-dev 2014-02-25 02:32:43 UTC
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
Comment 30 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-02-25 15:07:27 UTC
+*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.
Comment 31 Jason A. Donenfeld gentoo-dev 2014-02-25 22:04:30 UTC
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
Comment 32 Jason A. Donenfeld gentoo-dev 2014-02-26 01:07:33 UTC
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.
Comment 33 Martin Väth 2014-02-26 16:41:40 UTC
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.
Comment 34 Mike Gilbert gentoo-dev 2014-02-26 16:56:07 UTC
(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.
Comment 35 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-03-12 08:42:30 UTC
210 has security issues, and 211 is out, so we'd focus on the latter instead.