Depends issue in Helium pkg bunsen-exit

Specifically: bunsen-exit depends on systemd-sysv (or one of the libs that also vanish when you install sysvinit-core).

Swiching to sysvinit causes a lockup attempting to use it, it ought to get pulled on switching and doesn't.It's also reinstallable with its deps missing and oughtn't to be, if clicked, you have to switch to a tty to kill it and average joe mightn't know how, and certainly not what specific process to kill.. short of rebooting.

I don't mind it gone, you expect to have to replace functionality when a package gets removed, point is.. well i know Bunsen isn't strictly Debian.. if it were I'm sure there'd be a breach of Debian policy there somewhere.

A January 2017 bug report discussion and a February 2017 mailing list thread indicate that Debian developers are continuing to support sysvinit. At lest through the Buster release cycle. It's certainlt an officilly supported option in Stretch, even if it's also acknowledged that there's a price for the choice in having to substitute things which depend on systemd.

Meaning in all probability I will too.. by using it.. I know awkward cusses like myself are down to only about 1.5-2% of the Debian population, but there's many packages installed by way lower numbers than that.

edit title to be more meaningful.

Last edited by Bearded_Blunder (2019-01-14 23:57:52)

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Re: Depends issue in Helium pkg bunsen-exit

Bearded_Blunder wrote:

Specifically: bunsen-exit depends on systemd-sysv (or one of the libs that also vanish when you install sysvinit-core).

bunsen-exit depends on systemd. This is because although the exit commands are init agnostic, there is a need for logind, which is only provided by systemd atm. So you can boot with sysvinit as long as you have systemd and systemd-shim installed. More here: https://forums.bunsenlabs.org/viewtopic … 950#p49950

Swiching to sysvinit causes a lockup attempting to use it, it ought to get pulled on switching and doesn't.It's also reinstallable with its deps missing and oughtn't to be...

Indeed, bunsen-exit's dependence on systemd is declared in the control file, which should tell apt not to install it without systemd. (If you use 'dpkg -i' then dependencies are ignored and all bets are off.)

...I'm sure there'd be a breach of Debian policy there somewhere.

I don't think so. If you follow normal practices then everything should work. Debian does allow people to break their systems though...

Anyway, you should be able to use sysvinit to boot up, and continue to use bunsen-exit as long as you also have systemd installed too.

Re: Depends issue in Helium pkg bunsen-exit

Bearded_Blunder wrote:

Swiching to sysvinit causes a lockup attempting to use it, it ought to get pulled on switching and doesn't.It's also reinstallable with its deps missing and oughtn't to be, if clicked, you have to switch to a tty to kill it and average joe mightn't know how, and certainly not what specific process to kill.. short of rebooting.

well i would expect a reboot is in order when switching init systems, no?also, i don't think average joe ever attempts switching init systems.

Re: Depends issue in Helium pkg bunsen-exit

well i would expect a reboot is in order when switching init systems, no?

Quite so- and was done by sudo shutdown -r now just after sudo apt install sysvinit-core

ohnonot wrote:

also, i don't think average joe ever attempts switching init systems.

Average Joe doesn't according to popcon it's about 1.5% of Debian users what about 3 in 200?If that's higher or lower for Bunsen users I couldn't say, as manually configured as it is & being a bunch of tinkerers.. possibly higher

But see my last post, I musta done something screwey, or some update fixed a bug, as I can't make the issue reappear now, and just switching init & apt-mark hold systemd-sysv ( so I don't get switched back) has bunsen-exit still functional, which it wasn't last time.

So basically ignore all this noise :-)

Whole issue becomes moot for Buster anyhow, with systemd-shim pulled, I can't find any working method to switch to sysvinit, or anything else.. systemd becomes no longer the default, but the only working init for any Debian system with standard system utilities installed -- can't even have those if you want to switch, stuff depends on systemd-shim but it's not installable, end of sysvinit.

systemd wrote:

Resistance is futile.. you will be assimilated.

Looks like putting Bunsen over Devuan will be easier than figuring out a native Debian init change for Buster, and I'm sure that config is unsupported & I'll be on my own with any issues if I try it.

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Re: Depends issue in Helium pkg bunsen-exit

Bearded_Blunder wrote:

Whole issue becomes moot for Buster anyhow, with systemd-shim pulled, I can't find any working method to switch to sysvinit, or anything else.. systemd becomes no longer the default, but the only working init for any Debian system with standard system utilities installed -- can't even have those if you want to switch, stuff depends on systemd-shim but it's not installable, end of sysvinit.

systemd wrote:

Resistance is futile.. you will be assimilated.

It's not Debian's (or systemd's) fault:

Debian bug #915038 wrote:

Please remove systemd-shim from the archive. It is dead upstream,unmaintained, uninstallable and broken.

Re: Depends issue in Helium pkg bunsen-exit

At my skill level there'd be no way to test it, with the shim gone & so many things that depend on stuff that depends on systemd-sysv || systemd-shim, with systemd-sysv & sysvinit-core declaring they can't be installed on the same system.. I have played with elogind though not much, less stuff wanted to get autoremoved, suspect I'll hit a roadblock with udev too, and eudev isn't in Debian, maybe I *might* make progress with OpenRC, that can at least install on a command-line system with standard system utils there.. and it doesn't object to systemd being parked alongside it, but I've broke several bare command line installs trying to switch to either.

Sid maybe, but I don't think there'll be time for anyone to spin up a working non-systemd setup for Buster. Lithium is looking suspiciously like systemd or nothing to me.

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

But, I have a favour to ask. Do you have a sysvinit Buster system at hand? If so, I wonder if you could try uninstalling systemd and bunsen-exit, install elogind and then bunsen-exit from this file:https://drive.google.com/open?id=1Y_vIN … uEh26D1A-0(All I did was extend the Depends: field to allow elogind instead of systemd.)And then test if bl-exit works...

Re: Depends issue in Helium pkg bunsen-exit

johnraff wrote:

Do you have a sysvinit Buster system at hand?

Yes.

johnraff wrote:

I wonder if you could try uninstalling systemd and bunsen-exit, install elogind and then bunsen-exit from this file:

Not a hope, it's a bare command-line only system, I can try netinstalling bunsen onto it, i figure that will fail on various depends in about 30 places.. have to see how far I can get with it, but with systemd-sysv pinned/held so installing things doesn't pull in systemd-sysv thus removing sysvinit-core & switching it back, I'm unsure if Bunsen is even *possible* on Buster with Sysvinit at this stage, I've certainly broken several attempts at switching init on a systemd Bunsen/Buster setup.. I've been unable to resolve the various depends..

I haven't started seriously trying netinstalling onto a sysvinit buster yet, the netinstall calls for "standard system utilities" and

So the netinstall won't work right off..at least without effort missing basic tools it uses like um.. say wget & possibly others, I'll have to try multiple times and pull in missing tools and substitue or work round things each time it breaks, wget at least is installable. I recall doing it before I had to substitute some other things along the way even in Stretch.

Hence saying looks like systemd or nothing.. at least so far, or possibly openrc if sysvinit can't be done - I ain't given up, but I'm a long way off being able to try that bunsen-exit package out.

If I do get it up.. and Win 10 doesn't eat the notes again, I might post a (probably very long) howto ...

Last edited by Bearded_Blunder (2019-01-09 22:09:51)

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Re: Depends issue in Helium pkg bunsen-exit

I wonder if you could try uninstalling systemd and bunsen-exit, install elogind and then bunsen-exit from this file:

Not a hope, it's a bare command-line only system, I can try netinstalling bunsen onto it, i figure that will fail on various depends in about 30 places..

Ah fair enough. The Lithium netinstall script might come on line next week, and there will be an experimental Lithium repo in a few days with packages that, while very little different from Helium, should at least install OK on Buster.

...I've certainly broken several attempts at switching init on a systemd Bunsen/Buster setup.. I've been unable to resolve the various depends.....the netinstall calls for "standard system utilities" and

sudo tasksel install standard

fails

There is no "standard" task apparently. It's just something in the Debian installer, and corresponds to the packages listed by

aptitude search ~pstandard ~prequired ~pimportant -F%p

which does include systemd. However, the BL netinstall script doesn't specifically insist on all those packages being installed, it's just part of the pre-install instructions. A lot of them will be needed though (yes, wget), so you could try removing systemd before installing BL or any other desktop, or else installing a subset of "standard" after running the DI.

No other BL package than bunsen-exit has any systemd dependencies as far as I know. Recursive recommends, possibly.

Re: Depends issue in Helium pkg bunsen-exit

I've actually made way more progress on this than I expected, and I actually do now have a very close approximation of Lithium-Alpha installed (slightly edited Helium netinstall on top of sysvinit buster) there's a few packages that seem to have gone away or had substitutions in Buster, of the listed bunsen packages in the netinstall only bunsen-thunar & bunsen-exit refused to install, in the thunar case because it depends on a version of libthunarx that's been replaced with newer. Even managed without leaving the Debian repositories, though it did involve a dirty & doubtless unsupported hack using equivs

Basically a pretend package that depends on libpam-elogind and provides libpam-systemd that fixed the depends on *almost* everything. All kinds of things depend on things that depend on libpam-systemd remove it and gut the system.

You might want to look at the netinstall script though, the any other key to exit on failed installs works, but enter to skip them, also skips everything else that was to be installed.

I'd determined that

aptitude search ~pstandard ~prequired ~pimportant -F%p

listed what

tasksel install standard

tries to install and the only items returned by the search that don't on my bodged test VM are systemd systemd-sysv & netplan.io

However to the meat of the matter, that package you so kindly alterd the depends on, my testing to date is inconclusive, I'll need to try on real hardware to be sure. however:

It installs fine logout and suspend work as expectedhybrid-sleep isn't supported by the virtualbox emulated ACPI, so that makes VirtualBox give an error towards the end of the process.hibernate appears to save the state (much disk activity) and powers off, but I had issues resuming, I suspect it's related to that buggy VB ACPI again

The only bit apt hasn't taken away in the process, and a harmless bit at that.A "Lithium-Dev" netinstall script would make future tryouts easier of course :-) But I think I'm reasonably close.

VirtualBox is a bit buggy to constitute a fair test, and I'd want to tryout 64 bit before I'd claim I have a process too But contrary to what "everyone" claims it looks like a non-systemd graphical environment is possible still in Debian, without files from Devuan or <random repo>

Though I do expect to run into the odd other strane issue here and there.

Last edited by Bearded_Blunder (2019-01-10 13:05:50)

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Re: Depends issue in Helium pkg bunsen-exit

You might want to look at the netinstall script though, the any other key to exit on failed installs works, but enter to skip them, also skips everything else that was to be installed.

Noted. The netinstall is next up, when the base packages are done.

I'd determined that

aptitude search ~pstandard ~prequired ~pimportant -F%p

listed what

tasksel install standard

tries to install and the only items returned by the search that don't on my bodged test VM are systemd systemd-sysv & netplan.io

'tasksel --test install <task>' or 'tasksel --task-packages <task>' are useful. You then usually have to check out the dependencies of some task-* package though...

(modified bunsen-exit) my testing to date is inconclusive, I'll need to try on real hardware to be sure. however:

It installs fine logout and suspend work as expectedhybrid-sleep isn't supported by the virtualbox emulated ACPI, so that makes VirtualBox give an error towards the end of the process.hibernate appears to save the state (much disk activity) and powers off, but I had issues resuming, I suspect it's related to that buggy VB ACPI again

Yes, I don't really expect hibernate or sleep to work on VB, but the reboot and shutdown part is interesting. It's supposed to work even with sysvinit.

the options in lightdm from the button are greyed out too

which might be a hint.

A "Lithium-Dev" netinstall script would make future tryouts easier of course :-)

Coming soon, with luck.

But contrary to what "everyone" claims it looks like a non-systemd graphical environment is possible still in Debian

Actually, not quite everyone - I've seen posts on Debian mailing lists claiming sysvinit is still supported. Anyway, while I'm personally happy enough to use systemd, it's good to know that BL might still be flexible there. We're trying to make it as modular as possible.

Re: Depends issue in Helium pkg bunsen-exit

johnraff wrote:

Yes, I don't really expect hibernate or sleep to work on VB, but the reboot and shutdown part is interesting. It's supposed to work even with sysvinit.

I don't think bl-exit is where it's broken under sysvinit to be honest, dbus is running if I start the dbus monitor, poking the button communicates with dbus, & I can send messages to dbus from a terminal...

The issue *I think* seems to be that under sysvinit the authentication agent polkit-gnome-authentication-agent-1 appears to be broken, which breaks not only shutdown & reboot, but also pkexec If I try starting say gparted from a terminal I get

localuser:root being added to access control list
Error executing command as another user: No authentication agent found.
localuser:root being removed from access control list

It's installed though, I did try switching to lxpolkit to see if it was a gnome thing, the lxde authentication agent did no better, so switched back, I figure if there's a way to get the authentication agent running, it'll probably fix both things. Maybe policykit is assuming bits of systemd are there that aren't there in my setup, just not declaring them as depends...

Daft thing is the elogind libelogind0 libpam-elogind combo actually pull in policykit-1 as a recommend, I just can't figure how to get a policykit authentication agent working under sysvinit... I read somewhere "use one from wheezy", or "use the Devuan one" only I don't fancy that, trying to only use current Debian bits for my frankendebian if I can it'll prove or disprove claims about sysvinit support or otherwise. Now in Gentoo using elogind, one has the choice of compiling with or without user-session support (the systemd dbus-user-session functionality) unfortunately I've no idea if that compile switch is on or off in Debian.

For what it's worth, and in case it makes any difference, a sysvinit install will be using dbus-x11 rather than dbus-user-session the latter depends on systemd.

Last edited by Bearded_Blunder (2019-01-11 18:09:38)

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Re: Depends issue in Helium pkg bunsen-exit

This chunk is off topic a little, & Sorry for the double post, on the other hand I don't think edits show as unread. but:

johnraff wrote:

Thanks for looking at this!

Bearded_Blunder wrote:You might want to look at the netinstall script though, the any other key to exit on failed installs works, but enter to skip them, also skips everything else that was to be installed.

Noted. The netinstall is next up, when the base packages are done.

Turns out, that while grepping logs for errors, I spotted that when you opt to continue after a non-installable package, what happens in the background is that it *appears* that list of remaining packages gets passed as a command all by itself, without

sudo apt install

or

sudo apt install -y

being prepended, and of course that fails, since package names aren't commands.

While I'm on the subject of the netinstall script, I notice you've defined variables for such things as the logdir and backupdir.. to me it would make all kinds of sense to define ones for debian release & bunsen release, that way you'd only have to change "buster" to "next-codename" and "lithium" to "beryllium" in ONE place for the next release, instead of in umpteen, and you'll have to do the umpteen for lithium so why not be changing them to $debiancodename & $element or similar just the once?

Makes it easier to maintain in future.

While I'm nit-picking on the script.. in advance of lithium *please* check if someone commented network-manager out and *don't* clobber /etc/network/interfaces if network-manager is not installed.. a simple grep through pkgs-norecs for ^network-manager would do, or since that happens after the installing dpkg -l | grep ^ii | grep network-manager might be even better! It's a royal pain tracking the backup down to restore.

I didn't comment it out... but since it was after an uninstallable package & got skipped because of previously mentioned bug, interfaces got clobbered, and I had to mend an offline system. :-S Is there any need to clobber it anyway? I don't recall having to if I apt-got network-manager in the normal way, I think it handles the case gracefully in its own postinst or on being started, if not there'd surely be a heap of bugs filed.

Back on topic:

As for the shutdown issues, for what it's worth, the behavior is identical on a Devuan Beowulf (Buster equivalent) netinstall, which mostly works otherwise, thought it was worth testing on that to eliminate artifacts of other parts of the system expecting to find systemd in charge.

Far as I can tell though.. it's not bl-exit that's broken when it's using elogind, but rather the policykit authentication agent ( be it policykit-1-gnome or the lxde/lxqt/mate/other variants ) and possibly the setting of sessions correctly for it under sysvinit.

When I dist-upgrade stretch/helium to buster, in the normal systemd case I start getting asked for a password to reboot or shutdown.

If I netinstall onto buster directly again the default systemd case, I can shutdown & reboot as expected.

The above two cases are actually the reverse of what I expected.

Anyhow, to bypass my busted policykit-1-gnome agent (that's a separate issue) I dropped the following into

With the result both the lightdm button & bl-exit both work in spite of the busted agent.. since they're no longer trying to ask for auth on the way

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, the version in experimental depends libpam-systemd or libpam-elogind-compat, which is effectively what I built with equivs to fake it out).and maybe the virtual package: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, since I just demonstrated the requirement can be bypassed).

So as was your design intent, bunsen-exit is indeed init agnostic when policykit + agent are working, or when policykit can get auth without an agent, it might be only failing & asking auth because of some weird session thing

It's perfectly possible to have libpam-systemd or libpam-elogind ( or indeed systemd or the vanished systemd-shim) installed on a system without policykit-1 or an agent, in which case bunsen-exit would install & not work.

Now, the fact my agent is busted is not an issue with bunsen-exit as such, & fixing that is down to me, or something for help & support rather than a bugreport.

Darn it, now we have 3 issues minimum running about a bug that's only supposed to be about one

Last edited by Bearded_Blunder (2019-01-14 23:54:10)

Blessed is he who expecteth nothing, for he shall not be disappointed...If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Re: Depends issue in Helium pkg bunsen-exit

Many thanks for this feedback!

WRT netinstall,my first action will be just to make a new lithium branch with working content, so people can easily get a test setup of Lithium and we can start looking at all the bug reports that will doubtless come in.However, your suggestions make sense and I'll definitely look at implementing them.

Bearded_Blunder wrote:

While I'm nit-picking on the script.. in advance of lithium *please* check if someone commented network-manager out and *don't* clobber /etc/network/interfaces if network-manager is not installed

...Is there any need to clobber it anyway?

There certainly was at the time it was done. Network manager would respect interfaces already configured and refuse to handle them, with a message to take them out of e/n/i if you didn't want that. Time for another look.

---

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, the version in experimental depends libpam-systemd or libpam-elogind-compat, which is effectively what I built with equivs to fake it out).and maybe the virtual package: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, since I just demonstrated the requirement can be bypassed).

Re: Depends issue in Helium pkg bunsen-exit

Can't find that virtual package anymore polkit-1-auth-agent boo sss.. given there's about half a dozen agents, listing this that the other and the kde one if you want to double the size of your install as alternative deps is a bit of a pest.