[03:12] <guiverc> has anyone been able to write groovy ISO to thumb-drive & boot on hardware; I grabbed ubu-stud, xub, ubu, kubu, sunday night (AU est) & all failed, again grabbed with lubu & failed too.. groovy; 4 thumb-drives & written from two boxes..  (repeat of #ubuntu+1 question; "unable to find medium container a live file system \n Attempt interactive netboot from a URL?"
[03:14] <duflu> A month ago, yes :) I haven't tried it since then
[03:16] <guiverc> thanks duflu, I zsync'd lubuntu sunday morning (melb time) & no issues... today fail ... but I seem to wear-out thumb-drives thus why I've not raised lp bug report..
[03:22] <guiverc> the issue maybe only on old BIOS boxes; just booted on EUFI thingy & getting different reaction..
[03:25] <guiverc> i can boot 20.04 (groovy daily) on uefi box, not older BIOS (multiple boxes tried)
[03:25] <guiverc> i'll raise a bug report...  :) thanks duflu 
[04:13] <guiverc> it's not all BIOS boxes; impacts only older (maybe)
[04:51] <duflu> guiverc, I've just grabbed the latest image and will do some evening testing soon. You can also make modern machines into legacy "BIOS" machines in the BIOS settings
[04:52] <guiverc> duflu, I've now tested numerous boxes, mentioned in https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/1883040 ; most BIOS actually pass it turns out..
[04:56] <duflu> Stupid me. I've been advocating for years that people should download each daily image to help ISO triage, and I didn't
[04:57] <guiverc> we gotta work within the number of hours in our day
[04:58] <duflu> I mean "ISO bisection"
[05:18] <guiverc> xnox, no focal ISO at http://iso.qa.ubuntu.com/qatracker/milestones/408/builds/214469/downloads - https://bugs.launchpad.net/ubuntu-qa-website/+bug/1876525
[05:34] <duflu> guiverc, try http://cdimage.ubuntu.com/focal/daily-live/
[05:35] <guiverc> thanks duflu 
[05:52] <guiverc> I'll grab it tonight.. (avoid bandwidth quota issues.. zsync says heaps of change..)
[06:05] <jibel> guiverc, I fixed the links for lubuntu and ubuntu. I've to go through each series manually. It'll take a moment to fix them all
[06:07] <didrocks> good morning
[06:09] <oSoMoN> good morning desktoppers
[06:09] <oSoMoN> salut didrocks 
[06:11] <duflu> Hi jibel, didrocks, oSoMoN 
[06:14] <oSoMoN> hey duflu 
[06:17] <guiverc> thank you jibel 
[06:17] <didrocks> hey oSoMoN, duflu 
[06:33] <seb128> goood morning desktopers
[06:33] <jibel> hello world
[06:34] <duflu> Hi seb128 
[06:35] <didrocks> salut jibel 
[06:43] <oSoMoN> salut seb128, jibel 
[06:47] <duflu> Back in a bit
[06:53] <marcustomlinson> good morning duflu jibel didrocks oSoMoN seb128
[06:55] <oSoMoN> good morning marcustomlinson 
[07:08] <jibel> didrocks, salut
[07:08] <jibel> didrocks, does https://paste.debian.net/1151539/ look good to you?
[07:15] <didrocks> jibel: yeah, I didn’t spot any typos compared to yesterday
[07:15] <didrocks> hey marcustomlinson 
[07:20] <PaulePanter> If Canonical people working on Dell (Sputnik project) and with contact to Dell are in here, it’d be great if you looked at https://bugs.launchpad.net/dell-sputnik/+bug/1871491.
[07:37] <seb128> hey duflu didrocks jibel marcustomlinson oSoMoN, how is it going today?
[07:38] <jibel> today is wet
[07:38] <jibel> like it's raining all the sky forgot to rain over the last 3 months
[07:38] <seb128> PaulePanter, hey, the most recent comment on that bug state it was a bios issue and fixed with the update published by Dell, what do you expect us to look at exactly?
[07:39] <seb128> jibel, enjoy being sitting at the computer in a dry place :)
[07:39] <marcustomlinson> hey seb128, yeah doing alright, you?
[07:39] <seb128> marcustomlinson, I'm fine thanks!
[07:39] <didrocks> (enjoy… doing perl and debian patches :p)
[07:40] <seb128> good old perl!
[07:41] <didrocks> old -> yeah
[07:41] <didrocks> good -> we can debate :p
[07:41] <didrocks> perl -> definitively perl
[07:41] <jibel> I switched to emacs to write debian patches in perl
[07:42] <jibel> somethings wrong with me today obviously
[07:42] <didrocks> too many wrong things in one sentence
[07:42] <didrocks> it could be worse with s/write/read
[07:44] <oSoMoN> seb128, I'm good, thanks! it's been raining heavily for the past two days here, and the sky is still very grey, looking forward to the sun coming back
[07:45] <seb128> hopefully for the w.e ;)
[07:54] <PaulePanter> seb128: https://bugs.launchpad.net/dell-sputnik/+bug/1866343
[07:56] <PaulePanter> seb128: The last comment in https://bugs.launchpad.net/dell-sputnik/+bug/1661741 asks to re-open the report.
[07:59] <PaulePanter> seb128: I asked the user to clarify in https://bugs.launchpad.net/dell-sputnik/+bug/1661741.
[08:00] <PaulePanter> seb128: Maybe my issue is different after all.
[08:00] <Laney> greetings
[08:01] <marcustomlinson> hey Laney
[08:01] <duflu> 🖖Laney
[08:02] <Laney> jibel: I get the perl part, but the emacs part is where you need to be saved
[08:02]  * Laney sends help
[08:02] <Laney> hey marcustomlinson duflu 
[08:28] <oSoMoN> hey Laney 
[08:28] <seb128> hey Laney, how are you?
[08:29] <seb128> PaulePanter, right, it's a bit unclear if there is still an issue and what it is, I think it would help to have a clean report after testing on focal with updated bios if that's stil an issue there
[08:31] <seb128> Laney, you are gnome-session co-maintainer now right? could you try to review https://gitlab.gnome.org/GNOME/gnome-session/-/merge_requests/46 ? it's a change the oem team cares about
[08:34] <didrocks> hey Laney 
[08:35] <Laney> hi oSoMoN seb128 didrocks 
[08:35] <Laney> ok
[08:35] <seb128> thx
[08:48] <jibel> Trevinho, is there a way to switch between all the windows of all the workspaces with alt tab? I've org.gnome.shell.app-switcher current-workspace-only set to false but it works only for super tab 
[08:49] <jibel> I'm on g-s 3.36.3-1ubuntu2
[08:50] <didrocks> I was wrong, it’s another schema, same key name but another schema
[08:50] <jibel> nvm the key is window-switcher
[08:50] <didrocks> I think we should have both having the same value by default, no?
[08:50] <didrocks> either both to true (window switch and application switcher) or both to false
[08:51] <didrocks> (Note that having different defaults is upstream, we don’t override any of them)
[12:27] <popey> didrocks finally got some time to try and fix my laptop, booted into 20.04 live, and tried the first command which is "sudo zpool import rpool -R /mnt" which fails saying it's used by another system and I need to use -f, is that okay?
[12:40] <didrocks> popey: yes, the issue is that it’s not been properly umounted (due to the error on boot)
[12:40] <didrocks> so -f is fine
[12:40] <popey> ok
[12:41] <didrocks> (it’s to avoid 2 different systems mounting the same disk while running)
[12:42] <popey> these mount commands aren't right. I end up with /boot/boot and /boot/efi and /boot/grub in the chroot, which doesn't look right
[12:45] <didrocks> popey: hum, as I wrote them from memory. I probably did miss something :)  sorry is was zpool import bpool -R /mnt (not /mnt/boot)
[12:45] <didrocks> it*
[12:45] <didrocks> this is why we need to take some time to put that in ZSys wiki until the grub issue is fixed (if ever fixed)
[12:46] <popey> I think my best course is to backup and nuke this
[12:46] <didrocks> popey: at least, if you wait for a couple of weeks, you can setup encryption with groovy :)
[12:47] <popey> Hah! I'm not falling for this again! :D
[12:47] <popey> I remember upgrading away from an LTS sat next to you at a sprint some years ago.
[12:47] <popey> never again :D
[12:47] <didrocks> but we got it working at the end! Remember this :)
[12:48] <didrocks> and you really wanted to try the new Yaru :p
[12:48] <popey> Fair
[12:48] <didrocks> I’ll try to get to a screw up system (full disk) next week and write that recovery wiki page
[12:51] <popey> sweet
[12:52]  * popey finds a 2TB disk to backup onto
[14:30] <jibel> Laney, we're trying to decrypt a user volume on login using systemd. With gdm, ssh or login from a tty the user session is activated properly including the mount home dir. But it doesn't with sudo or su. With these tools the session is not visible in loginctl. Do you know why there is a difference between gdm/ssh and sudo/su/login/..., and if it's on purpose?
[14:30] <didrocks> Note that we checked that all pam configuration are calling pam_systemd.so
[14:31] <didrocks> (even those not opening this logind session)
[14:34] <jibel> Laney, for example with ssh I see in the journal "Started Session 53 of user u."
[14:34] <jibel> but nothing with su
[14:36] <ddstreet> jibel you're using 'su -' to create a login session?
[14:36] <ddstreet> or 'su -l'
[14:37] <jibel> su -
[14:37] <jibel> but there is not difference with -l, logind is not called at all
[14:47] <hellsworth> good morning desktopers
[14:47] <marcustomlinson> hey hellsworth
[14:48] <oSoMoN> good morning hellsworth 
[14:48] <hellsworth> hi guys
[14:49] <didrocks> hey hellsworth 
[14:50] <hellsworth> o/ didrocks 
[14:53] <Laney> jibel: didrocks: not sure, I know logind isn't started via su/sudo but not exactly how
[14:54] <Laney> did you look at the different things in /etc/pam.d/?
[14:55] <jibel> yes, we added a pam_exec after each line of each pam config file to trace the calls. And we just know that pam_systemd doesn't ask logind to create a session with su or sudo but cannot figure out why.
[14:57] <jibel> ah actually "pam_systemd(su-l:session): Not creating session: Already running in a session or user slice"
[15:00] <Laney> makes sense
[15:01] <Laney> use machinectl shell or something
[15:45] <didrocks> ok, we can workaround all that by an elegant solution based on .automount units with IdleTimeout
[15:49] <Laney> did you look into what homed is doing with decrypting on login? feels like a similar problem
[15:50] <jibel> not yet
[15:51] <didrocks> Laney: the issue is that no systemd integration for helping ZFS is wanted upstream
[15:51] <didrocks> Lennart was clear on a bug report about that
[15:51] <didrocks> so, we’ll see
[15:51] <Laney> right, I think it's a homed pam module rather
[17:13] <Laney> ok, see you monday!
[17:16] <oSoMoN> have a good week-end Laney 
[18:13] <oSoMoN> hellsworth, fontforge/s390x is now built in groovy-proposed, so I retried https://launchpad.net/ubuntu/+source/libreoffice/1:6.4.4-0ubuntu1/+build/19401810
[18:21] <hellsworth> oSoMoN: thank you so so much!