[09:32] <flexiondotorg> Morning desktopers. Just me?
[09:57] <davmor2> Morning all
[09:58] <davmor2> man nothing but meetings so far this morning
[09:58] <davmor2> flexiondotorg: you are not alone \o/
[09:58] <flexiondotorg> davmor2, Hello
[09:59] <davmor2> flexiondotorg: man that is a big echo
[12:18] <flocculant> 'cho 'cho 'cho
[14:13] <tkamppeter> xnox, hi
[14:17] <ximion> Laney: hi! regarding the AppStream "your data is wrong" issue, I hope I can resolve the autopkgtest issues today and make the package ready for x-updates
[14:18] <ximion> the AS test failure is harmless (and I should have fixed it right away...), the Isenkram issue is weird, doesn't even seem related - could be triggered due to AS now exposing more metadata
[14:18] <ximion> in any case, I'll look into that
[15:39] <xnox> tkamppeter, yes?
[15:45] <tkamppeter> I want to ask you whether you could help on bug 1642966.
[15:45] <ubot5`> bug 1642966 in systemd (Ubuntu) "package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1" [High,Confirmed] https://launchpad.net/bugs/1642966
[15:45] <tkamppeter> Have a look especially at comment #49.
[15:47] <tkamppeter> It looks for me that something was changed recently having the debhelper not shutting down the cups.path unit file any more during shutdown, making CUPS being triggered right after the shutdown of the main unit and so the shutdown break.
[15:47] <tkamppeter> Looks like a problem in the debhelpers for systemd.
[15:47] <tkamppeter> xnox ^^
[15:50] <xnox> tkamppeter, bug report from mark.... horum.
[15:50] <tkamppeter> xnox, tons of duplicates, sabdfl is only one of the people hitting this bug.
[15:53] <xnox> tkamppeter, something is very wrong. Still reading. My current guess is that '.path' unit is missing partof/bindsto => such that whenever the main service file is gracefully stopped, the path unit should stop too, as we are done with this thing.
[15:53] <xnox> suspecting that daemon removes file from monitored path, on shutdown, which triggers the .path unit, to restart the thing again.
[15:55] <xnox> tkamppeter, also I use google chrome printer (e.g. upload things to google drive / google chrome and print from there direct to printer) e.g. I have stopped using cups itself on ubuntu years ago =/
[15:56] <xnox> but i can setup up cups to play with this.
[15:58] <xnox> tkamppeter, re comment #39 i think you need "PartOf=" is some of these units https://www.freedesktop.org/software/systemd/man/systemd.unit.html -> Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.
[15:59] <tkamppeter> xnox, CUPS has a so-called keepalive file with which it tells whether it should be started right on the next boot (if it has remaining jobs, shares printers, or the web interface is active) or not (start on demand only, like on next job) .
[16:00] <tkamppeter> So on shutdown CUPS removes the keepalive file if on next boot only on-demand is needed, and it keeps the file if on next boot CUPS is needed right away.
[16:01] <xnox> tkamppeter, in systemd's opinion i would start cups on boot, always, and then auto-shutdown if not needed (no jobs left, no shared printers, to web interface active) and disintegrate back into on demand launch for next job if and when that arrives.
[16:02] <xnox> this on-demand logic is backwards, and .path units are not meant for this type of state conservation.
[16:03] <tkamppeter> xnox, adding PartOf=cups in cups.path (and cups.socket) should solve the problem. Am I right?
[16:04] <xnox> tkamppeter, hehe =) just writting "xnox," in the comment does not send me an owl or a telegram =) but nice try. You could have subscribed me to the bug report, before adding that comment.
[16:04] <xnox> tkamppeter, i believe so. But i think you only want that on the .path unit.
[16:04] <xnox> tkamppeter, because you want .socket to be alive (for on demand printing?!) to active the otherwise dead .service unit.
[16:05] <xnox> tkamppeter, but before uploading that it needs testing. This is certainly an interesting bug to work on.
[16:05] <xnox> targetting this for myself to look at before break for christmas.
[16:05] <tkamppeter> xnox, I had subscribed you to the bug and you are still subscribed.
[16:06] <xnox> =(
[16:06] <xnox> weird
[16:07] <xnox> tkamppeter, huh, i do have emails about it. but they are fairly context less and marked as read. I'm so sorry for missing this. And thank you for pinging me about it.
[16:08] <tkamppeter> xnox, it was some days after my comment #49, when I realized that there was no answer from the systemd or debhelper side, that I decided to subscribe you and add comment #50 to assure that you get a notification.
[16:08] <tkamppeter> xnox, I did not want to re-post the longish comment #49.
[16:20] <tkamppeter> xnox, note also that the unit files of CUPS are supplied upstream. So you should also report an upstream bug on CU{PS, either about a fix for cups.path or about always starting CUPS on boot but closing immediately if nothing has to be done from boot on.
[16:23] <xnox> tkamppeter, ack.
[16:23] <tkamppeter> xnox, what do I have to run after editing a unit file?
[16:24] <xnox> tkamppeter, systemctl daemon-reload
[16:27] <tkamppeter> xnox, Thank you. I have now added PartOf=cups.service to the [Unit] section of cups.path and then done the daemon-reload. With this I do not get the error message in the reproducer of comment #18 any more.
[16:27] <tkamppeter> xnox, seems that this is the solution, to be applied in cups upstream.
[16:33] <xnox> tkamppeter, to use the statefile to launchd cupd on boot only, i think you want a generator that does "[ -f /var/lib/that/state/file ] && ln -s ../../lib/systemd/system/cups.service $1/multi-user.target.wants/cups.service" or some such.
[16:34] <xnox> tkamppeter, such that on boot, systemd runs the generators; which checks if that file is on disk; and if it is, adds cups.service to the initial transaction of service to start on boot.
[16:36] <tkamppeter> xnox, I think I will stay with CUPS' architecture and try the adding of the "PartOf=cups.service" at first.
[16:42] <tkamppeter> xnox, posted https://github.com/apple/cups/issues/4935
[16:43] <tkamppeter> The bug bot is not recognizing GitHub issues.
[16:48] <tkamppeter> xnox, I asked the users for testing now, comment #52