[02:42] <lotuspsychje> good morning
=== TheRedQueen is now known as Drone
[06:13] <takov751> Moornimg
[07:51] <Haxxa> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/ whats the default passwd for root?
[09:06] <oerheks> user ubuntu pass clear?
[11:11] <bigfoot-> btw, this bug just bit me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908516
[11:11] <ubottu> Debian bug 908516 in evince "Apparmor profile breaks print preview" [Normal,Fixed]
[11:12] <bigfoot-> (tried to open multiple PDFs with one evince command line, evince a.pdf b.pdf c.pdf; -> a.pdf gets opened, plus error msgs for b and c -> Error launching evince file:///home/XY/.../b.pdf: Failed to execute child process “/bin/sh” (Permission denied))
[11:13] <bigfoot-> ... I guess, again I won't create an Ubuntu bug report because I upgraded from 19.10 ...
[11:16] <oerheks> regression? this does not happen on 18.04 evince 3.28.4-0ubuntu1.2
[11:17] <bigfoot-> didn't happen in 19.10 either.  this is a 20.04 regression.
[11:17] <bigfoot-> either way I've been told not to open bug reports from bugs observed in an upgraded system ...
[11:17] <oerheks> sure, file a bugreport.
[11:18] <oerheks> oh
[11:18] <bigfoot-> (this is not a clean 20.04 install; it has been upgraded all the way since 16.something)
[11:18] <oerheks> well
[11:19] <oerheks> i see Focal should have  3.35.92-1
[11:19] <oerheks> https://launchpad.net/ubuntu/+source/evince
[11:19] <oerheks> check yours??
[11:19] <bigfoot-> Yes, that's the one I have.
[11:20] <bigfoot-> And it's definitively an AppArmor-caused issue, I see DENIED log entries associated with my running evince.
=== genii_ is now known as genii
[15:59] <mcphail> bigfoot-: why on earth would someone ask you to avoid filing a bug report on an upgraded system?
[16:01] <lotuspsychje> mcphail: i adviced you help test devel release on a clean daily, to avoid giving the devs extra work
[16:01] <lotuspsychje> *him
[16:01] <oerheks> i never knew this rule too.
[16:01] <mcphail> But upgrades are supported and should be tested
[16:02] <lotuspsychje> well, we often get users here that force upgrades when they shouldnt yet, and get corrupted issues, that does not occur on clean dailys
[16:03] <lotuspsychje> so, i advice to at least compare their issues on a clean daily
[16:04] <mcphail> Yes, fair enough to compare to a clean daily. But still worth filing against the upgraded system version, referencing the behaviour on the clean daily, is it not?
[16:04] <oerheks> the debian bugreport mentioned is invalid.
[16:05] <oerheks> regression, sure, but can you guys reproduce it?
[16:05] <lotuspsychje> if they compare sure, but thats often not the case, they jump from non-lts release to an early devel release, thats just wrong in my opinion
[16:05] <mcphail> I'm on Mate here. Can't reproduce it on Atril, which is an evince fork, I think
[18:57] <bigfoot-> It's probably not the exact same bug, but in the same ballpark (evince trying to do something that AppArmor prevents it to do).
[21:37] <CarlFK> is there a torrent for focal? 
[21:38] <oerheks> CarlFK, nope :-(
[21:38] <CarlFK> meh, no prob - I'm guessing if it was a problem there would be.
[21:39] <CarlFK> why did rsynd  do this?  http://paste.ubuntu.com/p/4pyFjkDdRY/
[21:40] <CarlFK> er, rsync.  not d.
[21:40] <CarlFK> zsync seems to be working ok, so im not fussed. 
[22:00] <CarlFK> live, install, wifi picker - the SSIDs are alphabetical, not by power 
[22:01] <CarlFK> should I log an issue?
[22:01] <oerheks> sounds normal?
[22:03] <CarlFK> I would expect sorted by power so that the close one was at the top of the list 
[22:34] <FurretUber> Are scripts located in /lib/systemd/system-shutdown no longer executed?
[22:35] <FurretUber> There is one computer that has a serial port which communicates to a projector, and the command to power off the projector can't be send on reboot or kexec
[22:36] <FurretUber> The way I had found back then (16.04) was to have one script that checks if it was a poweroff or halt that was sent. And, if yes, it would run screen to send the required command to power the projector off
[22:36] <FurretUber> Now, I'm not sure it just not work or there is some race condition or something. The script that does this is the exact same used on 16.04
[22:38] <CarlFK> FurretUber: pastebin it 
[22:39] <FurretUber> https://paste.ubuntu.com/p/C4BBWBnGDc/
[22:47] <FurretUber> The sleep command was required back then because, without at least one second, the command wouldn't be sent in time for the projector
[22:49] <CarlFK> FurretUber: for systemd, you need a file that looks like this: https://salsa.debian.org/debconf-video-team/ansible/-/blob/master/roles/opsis-ingest/files/videoteam-ingest.service
[22:50] <CarlFK> your script gets called from ExecStart=/usr/local/bin/videoteam-ingest
[22:51] <FurretUber> A service file didn't work when I tried. Because it ran on reboot and poweroff. The script I sent before is speficically for system-shutdown
[22:51] <FurretUber> systemd-shutdown is, supposedly, the last thing that runs before the shutdown. It even has to be on this case, as the projector is the screen
[22:52] <CarlFK> oh wow, I didn't know about the "run all in this dir" thing.. https://unix.stackexchange.com/questions/347306/how-to-execute-scripts-in-usr-lib-systemd-system-shutdown-at-reboot-or-shutdow
[22:54] <FurretUber> This is being very useful for cases where there is some special hardware that requires some setup or configuration to power off properly. At least, until 20.04 :(
[22:55] <CarlFK> FurretUber: I would ask in /j #systemd - likely get to the bottom of this sooner there, and then if they say "somethings broke, log an issue" then you know what is broken 
[22:56] <FurretUber> I will try there, thank you
[23:06] <FurretUber> Thinking on that now, it's possible to query the projector if it's on or off. A while loop running until it is powered off may work...