Systemd maintainer for Debian quits after spat with Poettering

BLizgreat! · 2019-01-19 05:59:41

^^ BB: Different strokes etc etc.

Better hop out of this thread, as <nameless>d is one of those subjects. Have pondered installing Gentoo for a longggggg time too. Then I visit it's user manual, a couple pages into it and I come back to my senses and am forced to admit I'm too damn lazy to mess with all of that !

Lol ... of course Damo, glad you're back and hoping you're well recovered my friend.

Last edited by BLizgreat! (2019-01-19 06:01:59)

ohnonot · 2019-01-19 07:00:12

So - this has been making the rounds on various forums.
First of all a big thank you to THX1138:
This is the first time I see somebody adding context!
I took a while to read through the issue - here's a summary:

biebl opens an issue where systemd breaks a udev rule that has been working for a long time - apparently something that debian uses internally, so it would break existing debian installations?
poettering replies noncommittally, maybe even dismissively, just refering to other, already closed issues (but in a way that shows that he understands the issue)
biebl insists that the new behaviour breaks things and is therefore bad
other people resist, which makes biebl's comments increasingly ill-tempered, culminating in: "I guess I'll stop filing bug reports"
poettering and yet other people think about how this can be fixed so that both parties are happy (keep the new feature, but in a way that it doesn't break existing configuration) - and in the end they do, and the same day they come up with a commit that (apparently) fixes what biebl reported
unfortunately, by this time, yet another systemd shitstorm has kicked loose and biebl made their grant exit already

I might be biased because I've been using archlinux since 2014, at which time it's been using systemd for 2 years already, but to my layman eyes most "anti systemd arguments" crumble to dust upon closer inspection, just like this one.
also i cannot imagine anybody on archlinux' developer team throwing a hissy fit like that.
sorry biebl, you overreacted.
understandable, given the general athmosphere around systemd and debian especially, but still.

and unlike many people, i admit that i'm not a software developer and therefore wisely keep my mouth shut about things I don't fully understand.

or1o9 · 2019-01-19 08:50:04

ohnonot wrote:

and unlike many people, i admit that i'm not a software developer and therefore wisely keep my mouth shut about things I don't fully understand.

Amen.

S7.L · 2019-01-19 13:46:22

ohnonot, i dont believe mbieble had any sort of fit or dummy spit, it doesn't show in his messages. It sounds like he is stepping back to have a break and to what he perceives as stupidity in what is going on with systemd as he obviously knows more than you or I about it.

I mean if you perceive "What's going on is just too stupid/crazy." in regards to his comments on freedesktop as having a fit seems a bit of an exaggeration imo.

Last edited by S7.L (2019-01-19 13:49:11)

BLizgreat! · 2019-01-19 14:21:42

That's it !!! Gloves are coming off !!! SysV's mamma is so bloated it ought to have it's own zipcode !

Bearded_Blunder · 2019-01-19 23:20:39

@misko_2083 Well, as I understand it libsystemd0 is harmless by itself, if you want rid just because it has systemd in the name though, then your easiest answer is Devuan, antiX obviously take the view that they'll start you off without systemd, but since init is & should be your choice, you're free to install it, or parts of it, or anything that depends on it, exactly like you're free to pick which network software you install and if you don't like e.g policykit-1 blocking it is down to you. You'll block network-manager in the process in that example but still be able to use wicd or connman, same for systemd so they don't default to pinning it, you make it sound like

sudo nano -w /etc/apt/preferences.d/block-systemd wrote:

Package: systemd-sysv
Pin: release *
Pin-Priority: -1

Package: systemd
Pin: release *
Pin-Priority: -1

or

sudo nano -w /etc/apt/preferences.d/fanatical-systemd-block wrote:

Package: *systemd*
Pin: release *
Pin-Priority: -1

is difficult to do.
The point is they're giving you the choice it's then up to you what you do with that choice.
Either of those pins will stop you installing stuff that tries to pull in systemd, and may break other stuff, near certainty in pure Debian .

I don't think the second one can even be done in recent pure Debian, too much is built against libsystemd0.

If antiX defaulted to applying either, they'd probably hear lots of whining about what you suddenly couldn't install, they probably lack the resources & manpower to patch and rebuild everything they'd hear such moans about. Though to be fair answering "Well if you want Gnome, install systemd then" would actually be valid, exactly as "If you want MS Office, install Windows then." would be they're only letting you choose, not limiting your freedom.

They do make it way easier than trying the same thing on Debian, they've taken a huge chunk of work off you if you want to be systemd free, so props to them for that. There's a big difference between default to something else (antiX) and ban systemd (Devuan). Ether philosiphy is valid for the distro concerned, neither is "wrong".

But back onto topic:

ohnonot wrote:

3. biebl insists that the new behaviour breaks things and is therefore bad

A point upon which I find myself in complete agreement with biebl, existing settings and behaviour shouldn't be changed without notice on a running system, especially if they have been set manually. It's one of the bedrock tenets of Debian's *stable* release, testing & sid are another story.

I get enough of that kind of thing with Windows 10.

bigbenaugust · 2019-01-20 00:24:37

BL installer for Slackware, then?

THX1138 · 2019-01-20 15:21:58

BLizgreat! post #18 great post enjoyed it a lot. You are correct about the distributions being held to ransom by the users to a certain extent, but look what happens when you ignore the users, as in Ubuntu and Mate, Gnomeshell and its entire userbase hahaha, etc.

BLizgreat! · 2019-01-20 15:52:40

Thanks and no worries.

bigbenaugust · 2019-01-25 21:01:32

I went ahead and ran the BL netinstall script on an antiX base install in a VM. Pretty boring, actually. Switched to lightdm from slim and it looked the same. (Not sure what else I was expecting, really). The only broken thing was bl-exit, which I imagine requires systemd.

Bearded_Blunder · 2019-01-25 21:30:36

The bl-exit package requires a working dbus, policykit-1 & policykit-1-gnome (or other auth agent) though the stated "Depends" say systemd || systemd-shim,. (I think), you can work around the auth agent by making a policykit rule that returns "yes" for unix-user:* for whichever you use of the shutdown, reboot, hibernate, & hybrid-sleep actions. You might even get away with consolekit/consolekit2 rather than elogind for session tracking, I haven't worked that angle since consolekit ( either variant) is no longer available in Debian.

Various other things invoke pkexec, which requires a working policykit-1, something I haven't managed with elogind in Debian (or Devuan even)

You'll be missing the custom grub background & some other minors stuff too, & allowing bl-welcome to enable backports (which would be Debian ones) would be let's say "unwise".

Regards the DM slim is unmaintained and has some security issues, lightdm is a better choice in that regard, though it doesn't suppoert elogind, sddm allegedly does, if you can get polkit working....

Last edited by Bearded_Blunder (2019-01-25 21:47:53)

DeepDayze · 2019-01-26 03:09:41

Bearded_Blunder wrote:

The bl-exit package requires a working dbus, policykit-1 & policykit-1-gnome (or other auth agent) though the stated "Depends" say systemd || systemd-shim,. (I think), you can work around the auth agent by making a policykit rule that returns "yes" for unix-user:* for whichever you use of the shutdown, reboot, hibernate, & hybrid-sleep actions. You might even get away with consolekit/consolekit2 rather than elogind for session tracking, I haven't worked that angle since consolekit ( either variant) is no longer available in Debian.
Various other things invoke pkexec, which requires a working policykit-1, something I haven't managed with elogind in Debian (or Devuan even)
You'll be missing the custom grub background & some other minors stuff too, & allowing bl-welcome to enable backports (which would be Debian ones) would be let's say "unwise".
Regards the DM slim is unmaintained and has some security issues, lightdm is a better choice in that regard, though it doesn't suppoert elogind, sddm allegedly does, if you can get polkit working....

Maybe someone should post a bug report for adding elogind support to LightDM and maybe one for polkit-1 to add better support for elogind too.

Bearded_Blunder · 2019-01-26 12:27:27

DeepDayze wrote:

Maybe someone should post a bug report for adding elogind support to LightDM and maybe one for polkit-1 to add better support for elogind too.

Well, the elogind people & Gentoo devs are tackling that with upstream wherever they can, I've tried recompiling polkit-1, but it only has broken support even so, unless you tweak it, there's a patch waiting upstream that's been waiting 9 months & not merged, a detail missed when support was originally added. Even with that added I still had issues, I read somwhere elogind has issues tracking sessions if X runs SUID which may be the remaining tweak needed looking in htop X appears to be owned by root. I can't find the reference now. Anyhow starting X other than suid root is apparently the thing sddm can & lightdm can't, if I'm remembering right.

Anyhow, I think the time to RFP elogind-versions of such things is after upstream have the support working At which point it's easy, just alter package name to distinguish it, tweak build-deps to elogind libs, & change the compile options in debian/rules At that stage you stand a fair chance, if you're trying to get Debian to add support upstream doesn't include or that's broken upstream, it's a tad less likely. They will need recompiling for which session tracking is in use though systemd || elogind meaning separate versions at least for polkit, possibly other things judging by what gets rebuilt if you switch one to t'other on Gentoo. In a perfect world you wouldn't need to, but the world ain't perfect & you apparently do even though elogind is basically systemd code.

bigbenaugust · 2019-01-29 21:10:51

I also just ran the BL netinstall script on a Devuan default netinstall (which installed xfce). Seems terminator and lxappearance didn't install by default, but did install manually OK afterwards. Devuan also uses wicd over NetworkManager, so I'd have to VPN from the command line for work. And of course, bl-exit is broken. I did switch slim for lightdm as with antiX.

I was pleasantly surprised that the Devuan netinst ISO uses the Debian installer and not the Refracta installer that I don't like very much.

Bearded_Blunder · 2019-01-29 22:31:07

As to bl-exit, is your Devuan install using elogind or consolekit for session tracking? Thing with that is, if policykit is working & you're using elogind (and those are working, they weren't properly for me, but I was installing on Beowulf rather than Ascii), bl-exit should actually work despite what the depends say, can't say at all with consolekit, might work if policykit & dbus do.

It won't be installed though, as it's pulled in as a recommend on some other package, and being Devuan, no systemd to satisfy its stated depends.

As it sits in the repos, bunsen-exit states it depends on systemd, python2.7, python-gtk2, python-dbus
systemd is there because of systemd-logind, which elogind provides in Devuan.

The python stuff is because it's python, it makes calls via dbus, which poicylkit checks if you're allowed for the shutdown reboot etc. options & executes if you are..

bugreport wrote:

So addressing the depends issue: bunsen-exit actually does or should depend (directly) it seems to me on:
policykit-1 (which in turn depends on dbus + libpam-systemd + others which I faked out with libpam-elogind,
<snip>
polkit-1-auth-agent (supplied by default in bunsen by policykit-1-gnome & needed also for pkexec though any of the agents should do there also, this should probably be at minimum a recommend.......

I've had it working on a non-systemd debian install, though I did have to create a policykit rule that returns yes for those actions for unix-user:* since in that setup I can't get an auth agent running, at least not yet. Soooo basically I'm saying, if for example `pkexec gparted` works, bunsen-exit stands a very high chance of working too, assuming the non-systemd depends are satisfied & contol in the .deb is tweaked to allow installing it.

As an alternate to Network-Manager (and newer versions ditched the direct systemd depend in favour of systemd-logind, upstream have a compile option for elogind to provide the logind functionality, so you're likely to see it reappear in Devuan, it works just dandy on my sysvinit/elogind Debian, policykit issues aside even without the recompile) alternately, connman/cmst could provide a system-tray icon, has no systemd depends, and there's a VPN package that integrates & provides VPN stuff in the UI (Qt UI I'm afraid) .

bigbenaugust · 2019-01-30 15:22:23

Bearded_Blunder wrote:

As to bl-exit, is your Devuan install using elogind or consolekit for session tracking? Thing with that is, if policykit is working & you're using elogind (and those are working, they weren't properly for me, but I was installing on Beowulf rather than Ascii), bl-exit should actually work despite what the depends say, can't say at all with consolekit, might work if policykit & dbus do.

I'm sorry, I've already deleted the partition from the VM.

Bearded_Blunder · 2019-02-01 21:49:50

I'm starting to detest policykit almost as bad as systemd to be honest, seems to be part of the same sort of org.unfreedesktop mission creep.. get tentacles in everywhere & lock you in. I've got growing respect for Michael Biebl, what he has to say in this bugreport about why we're all using an older policykit version makes much sense to me also.

I just wish Poettering worked for Microsoft, he'd have a difficult time making Win 10 any worse, & could leave Linux alone without ruining it.

johnraff · 2019-02-02 02:07:26

Bearded_Blunder wrote:

Michael Biebl, what he has to say in this bugreport about why we're all using an older policykit version makes much sense to me also.

Me too. (Read also the comments in the 2012 blogpost.)
For now, just happy that pkla files will continue to work in Buster.
Maybe by Bullseye Debian will have added a patch so they go on working...

Michael Biebl wrote:

An idea that was floating around, was to write a .rules file which is
able to read the old, declarative .pkla files.

Bearded_Blunder · 2019-02-02 03:06:23

I kinda liked that idea.. read the .pkla files but that means building an interpreter for them, and interpreters are notoriously subject to flaws and exploits. Plus no such reader/interpreter seems to have appeared or been written despite the interval since that post. The whole point is that policykit/)Poetteringkit is straying from the KISS principle.

Typical Poettering, drop support for sound, TESTED & simple, require *his new stupid overcomplicated, bloated, not-properly-documented & UN-proven-by-time-in-use idea* regardless.. rather like systemd in fact. As to polkit/localauthority um.. it's the thing that actually *permits me* to have a *working* sysvinit/buster install in combination with faking out libsystemd by libelogind using equivs.. it's a concerted effort it seems to prevent *any other* init bar Poettering's personal pet one. I ain't worked out any other working solution to avoiding systemd in actual native *Debian* (rather than Devuan) than defining .pkla rules so of course support for .pkla files gets dropped! That said, using a full programming language like JS might just permit me to finesse the restriction, it is after all rather more flexible than something declaritive.. we''ll see maybe I can figure something out *soddit though* I *almost* had a future-ish proof alternative process for running Bunsen under *other than* systemd natively, rather than moving to Devuan, much as I'd hate to now I'm autistically *used to* debian. Seems subject to being broke by any update to poetteringkit-1 now though

The hours fekkin Poettering's caused me to waste, just so I can set things up *the right way* instead of *his way* is ridiculous!

It's not even entirely clear to me, aside from the "require systemd" agenda, why policykit is even needed, unix permissions do actually work.

Apologies if this comes off as a rant, but I've been drinking & am therefore inclined to be blunt and honest rather than diplomatic.

THX1138 · 2019-02-03 15:54:40

ohnonot wrote:

i admit that i'm not a software developer and therefore wisely keep my mouth shut about things I don't fully understand.

Surely, though you are entitled to an opinion over the effects of systemd? You dont have to understand every technical detail of chip design to know whether you like how the CPU and motherboard perform. Otherwise that's like saying that your decisions on what you like and dont like can only be informed by those who design things even if they design them badly. Example: I dont know exactly how Renault tune their engines and how they make them, I just know I dont like Renault cars

#21 2019-01-19 05:59:41

Re: Systemd maintainer for Debian quits after spat with Poettering

#22 2019-01-19 07:00:12

Re: Systemd maintainer for Debian quits after spat with Poettering

#23 2019-01-19 08:50:04

Re: Systemd maintainer for Debian quits after spat with Poettering

#24 2019-01-19 13:46:22

Re: Systemd maintainer for Debian quits after spat with Poettering

#25 2019-01-19 14:21:42

Re: Systemd maintainer for Debian quits after spat with Poettering

#26 2019-01-19 23:20:39

Re: Systemd maintainer for Debian quits after spat with Poettering

#27 2019-01-20 00:24:37

Re: Systemd maintainer for Debian quits after spat with Poettering

#28 2019-01-20 15:21:58

Re: Systemd maintainer for Debian quits after spat with Poettering

#29 2019-01-20 15:52:40

Re: Systemd maintainer for Debian quits after spat with Poettering

#30 2019-01-25 21:01:32

Re: Systemd maintainer for Debian quits after spat with Poettering

#31 2019-01-25 21:30:36

Re: Systemd maintainer for Debian quits after spat with Poettering

#32 2019-01-26 03:09:41

Re: Systemd maintainer for Debian quits after spat with Poettering

#33 2019-01-26 12:27:27

Re: Systemd maintainer for Debian quits after spat with Poettering

#34 2019-01-29 21:10:51

Re: Systemd maintainer for Debian quits after spat with Poettering

#35 2019-01-29 22:31:07

Re: Systemd maintainer for Debian quits after spat with Poettering

#36 2019-01-30 15:22:23

Re: Systemd maintainer for Debian quits after spat with Poettering

#37 2019-02-01 21:49:50

Re: Systemd maintainer for Debian quits after spat with Poettering

#38 2019-02-02 02:07:26

Re: Systemd maintainer for Debian quits after spat with Poettering

#39 2019-02-02 03:06:23

Re: Systemd maintainer for Debian quits after spat with Poettering

#40 2019-02-03 15:54:40

Re: Systemd maintainer for Debian quits after spat with Poettering

Board footer