rustyaxe | found small bug; bird2 package /etc/init.d/bird and bird6 scripts are lacking +x perms | 03:46 |
---|---|---|
gnarface | hmm, rustyaxe it's not a forked package, so typically you'd report that upstream to debian... but i'm unsure what they'd do in this situation. i don't think it's completely unexpected that they'd just patch it by removing the init script entirely. | 04:10 |
gnarface | i also wonder if the bug you're seeing is already the fix for this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965973 | 04:10 |
gnarface | (i only skimmed it, but i notice they're talking about removing permissions to make use of systemd features) | 04:11 |
novideo | i just ran in to this bug again in devuan ceres, had to uninstall systemd-standalone-sysuser: https://bugs.devuan.org/cgi/bugreport.cgi?bug=717 | 18:26 |
novideo | systemd-standalone-sysusers | 18:27 |
Hurgotron | novideo: interesting - what does that package do? | 18:54 |
novideo | Hurgotron: I'm not familiar with systemd-standalone-sysusers but the polkitd postinst script attempts to invoke it, only for it to fail because that polkit.conf file is missing | 19:48 |
novideo | apt-file search polkit.conf shows that the file should be included in polkitd, but I downloaded polkitd_124-1devuan1_amd64.deb, unpacked it and it isn't there | 19:49 |
novideo | debian's polkitd contains the file | 19:55 |
novideo | https://packages.debian.org/sid/amd64/polkitd/filelist | 19:55 |
rwp | Like much of systemd it rewrites and changes the current way things are done for a new way that it wants to do things. Sometimes this hard requires systemd. Sometimes it only requires some glue to work in a non-systemd system. | 20:58 |
rwp | systemd-standalone-sysuser is one such bit of non-systemd glue that can be used to fill the new feature need without having systemd installed. | 20:58 |
rwp | systemd-standalone-sysusers and systemd-standalone-tmpfiles are two packages unfortunately named systemd but are NON-systemd packages which are required as dependencies for other packages that want systemd but don't need it. They are not systemd. I install them so I don't need systemd to be installed. | 21:00 |
novideo | I also dont mind having it installed, but it prevented me from updating polkitd as devuan seems to have removed /usr/lib/sysusers.d/polkit.conf from its polkitd package. if that was intentional, perhaps the invocation of sysusers should also be removed from the package's postint script? | 21:16 |
rwp | According to the bug#717 you reference it was a packaging bug which was subsequently fixed. It looks like someone, you perhaps, appended information to the closed bug report that a problem is once again a problem. | 21:20 |
rwp | I would have submitted a new bug report, and referenced the previous one. Because if it is active again then this is probably a new bug. | 21:20 |
rwp | I don't have polkitd installed. Looking around my collective to see if any of my machines have it installed. | 21:21 |
rwp | I have one Ubuntu based system with polkitd installed. Looking to see what dependency pulled it in. | 21:23 |
CueXXIII | on my system it is blueman that depends on polkitd | 21:24 |
fsmithred | on my daedalus system, gparted needs policykit-1 which needs polkitd | 21:25 |
rwp | If I try to purge -s it on this Ubuntu system it says it needs to eject: packagekit packagekit-tools pkexec policykit-1 polkitd software-properties-common ubuntu-server | 21:25 |
rwp | None of those are anything I care about. I think I will go ahead and purge those just to simplify things. | 21:26 |
rwp | On my Ceres Unstable system if I attempt to install polkitd there it conflicts with libsystemd0 libsystemd-dev removing them. I have systemd-standalone-sysusers installed there. I'll try it to see if I can reproduce the failure. | 21:28 |
fsmithred | dependency conflict or just a version conflict? | 21:29 |
rwp | Oh, I haven't run that system through usrmerge yet and it already had pre-existing usrmerge failures which I had postponed fixing. So that reproducing experiment is invalid because it failed due to that first. | 21:31 |
rwp | fsmithred, https://paste.debian.net/plain/1310610 | 21:31 |
rwp | And I continue to postpone fixing that system's usrmerge problems for now. Must work on other higher priority things instead. I'll get to fixing usrmerge there at some point. | 21:33 |
fsmithred | did you make custom links? | 21:34 |
fsmithred | base-files now depends on usrmerge. Are you sure you didn't get it? | 21:35 |
rwp | Of course I did! (make custom hacks to my system now preventing usrmerge) | 21:36 |
rwp | base-files pulled in usrmerge which then "blew chunks" on my system due to my prior modifications. | 21:36 |
fsmithred | ouch | 21:36 |
rwp | It was expected. | 21:36 |
rwp | turmoil is my victim testing VM that exists to be the testing grounds for things like this. | 21:37 |
rwp | I could wipe it clean and start again. But so far I have always recovered it. Recovered it to fight again another day. And so it remains. | 21:37 |
fsmithred | On your apt-get output: the elogind stuff replaces libsystemd0 | 21:40 |
rwp | fsmithred, Yes. Or maybe I should say, Yes? I think you are trying to tell me something but I did not understand it. | 21:49 |
fsmithred | I was pointing out the dependency chain that wanted to remove libsystemd0 | 21:50 |
fsmithred | at some point, I'm pretty sure I had a system with both libsystemd0 and libelogind0 - probably ceres. | 21:51 |
rwp | Yes. But, well, we were talking about the error reported when installing polkitd with systemd-standalone-sysusers installed. That's the case I was trying to reproduce. | 21:51 |
rwp | So having libsystemd0 pushed out by elogind seems unrelated to the polkitd package install test. That's why I was confused you would mention it. | 21:52 |
novideo | I did not file any new bug report yet | 21:54 |
novideo | bug 717 sounds like they removed polkit.conf from the package, and added it back in to fix it | 21:54 |
novideo | now it looks like someone removed it again | 21:54 |
rwp | At the end of https://bugs.devuan.org/cgi/bugreport.cgi?bug=717 that you cited someone on 13 Mar 2024 today added additional information to that closed bug report. | 21:55 |
novideo | i am not dimitris. if "novideo" is already taken I apologize. this is my first time here in years | 21:57 |
rwp | I didn't know one way or the other, which was why when I mentioned it earlier I mentioned it as a perhaps you with a question about it. | 22:00 |
rwp | For something like this where the bug has been closed as fixed for two years then instead of adding information to a closed bug I would open a new bug and cite the previous as a maybe "deja vu" bug that it had returned. Because it is more likely different. But then it is a new open bug which would get people's attention. | 22:01 |
rwp | I guess I should either fix up my testing VM or I should discard it and produce a newly installed one. Or create yet another one for this test. So that I can try to reproduce the problem. | 22:02 |
novideo | I think it's exactly the same bug, someone removed /usr/lib/sysusers.d/polkit.conf thinking it wasn't needed, and 2 years later someone forgot and did it again. thanks, i'll file a new one | 22:03 |
novideo | you could probably reproduce in chroot | 22:03 |
novideo | i do have merged usr if it matters | 22:03 |
novideo | all you have to do is install systemd-standalone-sysusers first, then install polkitd | 22:04 |
novideo | if systemd-standalone-sysusers isn't installed, polkitd won't try to invoke it | 22:05 |
novideo | if it is, polkitd invokes it but it fails due to the missing config | 22:05 |
novideo | https://paste.gnome.org/p0ngTcp5u | 22:10 |
rwp | I find it really hard to understand the desire for systemd-sysusers and the config file just to eliminate one adduser call and one addgroup call. Makes negative sense to me. | 22:29 |
rwp | Plus for the most part it means we want to keep both alternative methods alive because we want to continue support for non-systemd systems. Which means we simply ADD code without any benefit. | 22:30 |
novideo | anddd i cant install reportbug in ceres cause it depends on libapt-pkg6.0t64 which isn't in the repo | 23:16 |
rwp | By the naming with the "t64" we know it is part of the 64-bit time transition for which everything is rebuilding. | 23:22 |
novideo | well i cant install reportbug until then | 23:28 |
novideo | debian-el and elpa-debian-el packages depend on the t64 package as well | 23:29 |
rrq | perhaps the email API works for you? | 23:29 |
novideo | yes, that's what ill do | 23:30 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!