systemd-30 was released over a week ago. Please bump. Reproducible: Always
Just to inform - systemd 31 is in the wild.
Created attachment 281559 [details] sys-fs/udev-172.ebuild
Created attachment 281561 [details] sys-apps/systemd-32.ebuild
Really, what's the point of attaching random complete ebuilds to bugreports?
I've committed -32 unkeyworded. I will keyword it as soon as udev is bumped. I think I'll bump to -34 directly, and omit -33 too due to build problems.
Is 32 somehow problematic to use/test? Would it help things if I test something? I'd be happy to give it a try but I am scared off by it being masked. Additionally I didn't really find a Changelog in the tarballs (using 29-r2 for now) so I couldn't check if I want or need it ;-)
(In reply to comment #6) > Is 32 somehow problematic to use/test? The problem is that systemd needs the newer udev (bug 375263) ... but it's taking a while :/
(In reply to comment #7) > (In reply to comment #6) > > Is 32 somehow problematic to use/test? > > The problem is that systemd needs the newer udev (bug 375263) ... but it's > taking a while :/ uh, I see. So no -32 for me for now. OK.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Is 32 somehow problematic to use/test? > > > > The problem is that systemd needs the newer udev (bug 375263) ... but it's > > taking a while :/ > > uh, I see. > So no -32 for me for now. OK. You can use udev-9999 but beware that it seems to have persistent-net broken.
(In reply to comment #9) > You can use udev-9999 but beware that it seems to have persistent-net broken. thanks. I have issues w/ my cryptsetup-partition (it gets mounted multiple times with systemd, or not at all sometimes) and from time to time there is no wifi. Is this related to udev vs. systemd? udev-171-r1 currently in use here. All this works fine with openrc ...
systemd 35 is out.
(In reply to comment #11) > systemd 35 is out. It's in gx86 already. It requires you to do package.keywords on it & udev temporarily.
systemd 37 is out.
> (as soon as udev is bumped) Is udev *ever* going to be bumped? It's already 3 versions and over 3 months behind... Could someone maybe make a masked udev ebuild so that us, systemd users, could use it, and not have to use the live version from git?
udev 174 was released: http://people.freedesktop.org/~kay/ Could someone bump it and also systemd?
(In reply to comment #15) > udev 174 was released: http://people.freedesktop.org/~kay/ > > Could someone bump it and also systemd? systemd is up-to-date (but masked). For udev, please make noise on the udev bug.
Ok, new udev is in tree masked now; I added systemd to that mask and re-introduced the keywords. Those who used udev-9999 because of that, can now return to release versions like: # flaggie udev %** # diffmask -a '<udev-9999'
Any reason systemd-44 is delayed? (Released a week ago)
(In reply to comment #18) > Any reason systemd-44 is delayed? (Released a week ago) Bug #408879. I'll probably just bump directly to -45.
Given the upstream source tree merge of udev and systemd I've merged the systemd ebuild into sys-fs/udev (with the systemd useflag determining whether to setup systemd, extra deps etc) sys-apps/systemd becomes a virtual DEPENDing on sys-fs/udev[systemd]. It's not yet tested, and probably contains bugs but I'll attach it here for comments.
Created attachment 307837 [details] Proposed first shot at udev/systemd post merge ebuild
I know given openrc dependency on udev, this may make sense. But from a generic point of view, udev was absorbed by systemd. Thus the more logical packaging is to have sys-apps/systemd and it would always build udev. sys-fs/udev would be a separate package, built from systemd's source code using the udev only build. It could conflict with sys-apps/systemd, and should be used by sys-apps/openrc.
(In reply to comment #22) > sys-fs/udev would be a separate package, built from systemd's source code > using the udev only build. It could conflict with sys-apps/systemd, and > should be used by sys-apps/openrc. In that case, would it still be possible to have systemd and OpenRC installed side-by-side and both functioning? This is important (IMO) because it lets me easily determine if a problem I'm having is due to systemd or not.
After an initial test build/install there's a few use_enables that should be dropped and ChangeLog no longer exists. I'll attached a update after further testing.
With my proposal they would conflict. Actually I have openrc as fallback from the early days when I worked on porting systemd to gentoo. Most of the time I have problems is some openrc and systemd fighting. Making them exclusively would help solving problems and I really see no gain in having them both together. In the past (first versions of systemd) it was rough on debug and hard to recover, these days it's stable and easy on those. There is no reason to rely on openrc anymore.
I had considered both approaches have merits, but thought I'd throw things together and see what comes out. Plus it gives us something material to discuss.
Any hint how to build udev only from the merged tree? Best I seem to have managed is to explicitly build udevd udevadm and then install everything manually, not really ideal, and that still requires system deps during configure...
Hint: ask upstream. Or wait for them to sort that out rather than suggesting even worse kind of ugliness.
I wasn't really suggesting that :) I was considering re-writing the configure.ac and top-level Makefile.am though...unless somebody else knew of something I'm missing...?
Upstream suggests it's too broken to work on right now: "it's not even fully working, it boots here, but that's all"...
Considering the upstream's decision and problems resulting from it, I've released -44 with a patch to fix bug #408879. It also finally syncs the ebuild with -9999, as systemd-ui is in the tree already.
* Detected file collision(s): * * /usr/share/man/man1/systemadm.1.bz2 * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * sys-apps/systemd-44 * /usr/share/man/man1/systemadm.1.bz2 * * Package 'sys-apps/systemd-ui-1' NOT merged due to file collisions. If * necessary, refer to your elog messages for the whole content of the * above message.
I've committed a fixed version. Please try in next 12hrs.
