[04:11] <jibel> morning all
[05:10] <duflu> Hi jibel 
[05:32] <seb128> goood morning desktopers
[05:39] <duflu> Hi seb128. How goes?
[05:39] <seb128> duflu, hey! a bit tired but alright, you?
[05:39] <duflu> jibel, btw those AMD stats are still ~1% (?)
[05:40] <duflu> seb128, yeah I got a reasonable sleep so feel good. Could be better though. Still experimenting with new pillows
[05:47] <jibel> duflu, I didn't have a look yet
[05:47] <jibel> salut seb128 
[06:07] <seb128> lut jibel, comment ça va ?
[06:10] <didrocks> good morning
[06:12] <duflu> Hi didrocks 
[06:18] <luna_> morning
[06:21] <jibel> seb128, ça va bien, on avance bien sur l'encryption, c'est motivant
[06:23] <didrocks> good afternoon duflu 
[06:37] <seb128> jibel, super :)
[06:37] <seb128> lut didrocks, comment ça va ?
[06:37] <seb128> hey luna_
[06:37] <didrocks> salut seb128, ça va, et toi ?
[06:38] <seb128> ça va aussi :)
[06:42] <oSoMoN> good morning desktoppers
[07:18] <marcustomlinson> morning callmepk jibel duflu seb128 didrocks luna_ oSoMoN
[07:19] <callmepk> Morning marcustomlinson jibel duflu seb128 didrocks luna_ oSoMoN 
[07:25] <didrocks> hey marcustomlinson, callmepk, oSoMoN 
[07:33] <seb128> lot oSoMoN, hey marcustomlinson, callmepk, how are you today?
[07:33] <oSoMoN> morning marcustomlinson, callmepk, didrocks, seb128 & everyone else :)
[07:34] <marcustomlinson> seb128, hey! a bit tired but alright ;)
[07:34] <callmepk> I am great! how are you seb128?
[07:35] <seb128> callmepk, I'm alright thanks
[07:49] <duflu> Hi marcustomlinson, callmepk, oSoMoN, world
[08:04] <Laney> \o
[08:05] <seb128> hey Laney, how are you?
[08:05] <duflu> Hi Laney
[08:07] <Laney> hey seb128 duflu 
[08:07] <Laney> yeah doing good, don't know why we have this second winter though, that's not ok imo
[08:07] <Laney> you?
[08:08] <duflu> I'll swap you. We're over a week into actual winter and it's still 24 degrees
[08:09] <Laney> It's going to peak at like 13 today
[08:09] <didrocks> hey Laney 
[08:09] <Laney> Definitely up for a swap
[08:09] <Laney> hey didrocks!
[08:45] <didrocks> cking: hey, FYI, after a final round of testing I’m going to upload zfs-linux if you don’t have anything else to upload. It readds zsys support which was dropped in previous debian merge by accident I guess, add encryption support and now that the upstream PR on the dep loop with encryption is accepted (not merged yet), I’m backporting it.
[09:18] <popey> Hey. My laptop ran out of space in /boot (zfs) 131MB size and each initrd was 82MB so it blew up. I tried updating, but for some reason my laptop locked up (i915 issue). I rebooted and now it won't even give me grub. Is there a "boot from live cd, and here's how you mount zfs pools to fix it" type guide?
[09:29] <didrocks> popey: I don’t think there is this guide, but it will be good to have. In groovy, we blocked autosnapshotting when reaching 80% of max capacity (the SRU is waiting for reviews). The fact that grub doesn’t even start is another bug assigned to foundation (but from their meeting discussion, it sounded like it’s a WONT FIX for them)
[09:30] <didrocks> so, we only have a mitigation on the ZSys side, but it will be good to have at least grub fixed to prevent this to happen (even without snapshots, you can file up your ZFS disk and then, can’t boot)
[09:45] <juliank> popey, didrocks I had a user on reddit recently that had issues with recovery as well, I got him to mount datasets individually which worked for him, as automatic mounting was borked or something, despite the pool being i,ported to /mnt
[09:46] <juliank> popey: FWIW, the steps should be zpool import BPOOL /mnt, zfs mount -a AFAIUI
[09:46] <juliank> and then you should see it in /mnt/boot AFAIUI
[09:46] <juliank> but I might be wrong
[09:48] <juliank> their grub only got to a commandline, it was terrible
[09:49] <juliank> and I guess zpool import and individual zfs mount per dataset would work too
[09:50] <didrocks> I think you meant zpool import rpool -R /mnt && zpool import bpool -R /mnt/boot && mount /dev/sda1 (if efi is there) /mnt/boot/efi && mount --bind /mnt/boot/efi/grub /mnt/boot/grub
[09:50] <didrocks> so that you can chroot then in /mnt and do what you need
[09:51] <juliank> ah yes, you need to run grub-mkconfig/update-grub
[09:51] <didrocks> juliank: FYI, the grub issue is bug #1867542
[10:38] <cking> didrocks, i'm not going to upload zfs in the next 10 days or so
[10:39] <cking> so please feel free to upload
[10:39] <didrocks> cking: will do! There is some unknown if the upstream PR is really fixing the issue. I’m going to upload it and track upstream development, commenting there as needed
[10:41] <cking> i'm only planning to add kernel driver related bugfixes now such as compat shims for 5.8+ kernels etc
[10:41] <cking> and they can wait until you are done
[10:41] <didrocks> ack, I’m going to upload right now (j_ibel and I just finished testing)
[10:42] <cking> cool
[10:42] <didrocks> will be good for us to talk about the performance discussion we started whenever you have time
[10:42] <cking> the latest code as the AES crypto accelleration and I've SRU'd the first round of this to focal
[10:43] <Laney> seb128: when you get a minute you can revert that change to the i386 script we did yesterday (just the script bit)
[10:43] <Laney> it appears in the output now so doesn't need a special case any more
[10:43] <popey> didrocks (sorry, was afk). Well that's disappointing. I guess I need to figure out a way to recover the data on my laptop and wipe it
[10:43] <didrocks> cking: I meant the other discussion, where Matt raised about init_on_alloc
[10:44] <cking> didrocks, ah, yes, that's on my TODO list for next week
[10:44] <didrocks> popey: feel free to raise it on the bug I linked, I agree that grub not booting is concerning
[10:44] <didrocks> cking: excellent!
[10:44] <didrocks> popey: tell me if the commands I gave is working for you
[10:44] <didrocks> we can turn that into a wiki page on zsys project
[10:46] <didrocks> popey: I hope our ZSys 0.4.6 will hit focal soon (once out of UNAPPROVED), which will mitigate the issue, but not prevent people to file up their disks with ZFS and making grub not booting
[10:58] <popey> will do. i'm on vacation so booted into windows right now. need to get this fixed before next week. will have a play with it later.
[11:00] <didrocks> popey: keep us posted and enjoy your holidays :)
[11:00] <popey> will do, thanks.
[12:16] <ricotz> oSoMoN, thanks for the firefox patches :)
[12:53] <oSoMoN> ricotz, you're welcome, I'm glad you noticed and this didn't conflict with the update to 78.0~b5
[13:06] <seb128> Laney, you are confident it's not needed anymore? there are other similars entries in the script that haven't been cleared out in the past so I prefer to check (sorry, days are short enough atm so I don't want to spend time trying to understand what's happening exactly with the bootstraping and the i386 process)
[13:48] <Laney> seb128: well, try remove it and run the script on dry-run, but yeah I am
[14:13] <seb128> Laney, confirmed and commited
[14:14] <Laney> danke!
[14:16] <seb128> bitte!
[14:21] <ogra> tsk ... germans 
[14:22] <hellsworth> good morning desktopers
[14:27] <oSoMoN> good morning hellsworth 
[14:28] <hellsworth> hi there oSoMoN :)
[14:30] <oSoMoN> seb128, tjaalton: for xorg-server 2:1.20.8-2ubuntu3, the r-cran-gwidgetstcltk autopkgtests on armhf and ppc64el need to be retried with an additional trigger on the version in proposed (r-cran-gwidgetstcltk/0.0-55.1-3)
[14:41] <seb128> oSoMoN, thx, I'm doing that
[14:42] <oSoMoN> cheers
[14:45] <tjaalton> oSoMoN: ah, I forgot that part earlier today
[14:49] <kenvandine> sigh... libjpeg triggered another USN refresh of like everything
[14:50] <seb128> :(
[14:50] <seb128> snaps are hard work to maintain
[14:56] <Laney> wtb auto rebuild + re-publish on USN
[14:57] <seb128> would be nice
[15:12] <oSoMoN> this requires at least some minimal amount of automated testing, but yeah, that would be nice (and something we should work on)
[16:21] <kenvandine> i'
[16:21] <kenvandine> i've got some automation
[16:22] <kenvandine> i'd really like to trigger the rebuilds from trello :)
[16:22] <kenvandine> card created -> rebuild -> move to needs testing when the build finishes
[16:23] <kenvandine> last week it was time consuming because i had some snaps that were failing to build since branching gnome-3-36 and some others that needed updating so i did it all at once
[16:28] <marcustomlinson> lp scripting ftw
[16:33] <marcustomlinson> you’ll also need to do things like build sdk snaps before platform snaps before app snaps
[16:35] <marcustomlinson> oh actually, the sdk would need to be published to stable before the platform picks it up
[16:36]  * marcustomlinson tries pulling his spanner out of the works
[16:38] <marcustomlinson> kenvandine, do platform snaps still build from candidate sdk snaps?
[16:38] <kenvandine>  candidate
[16:39] <marcustomlinson> ok ignore my comment about publishing to stable first then
[16:39] <kenvandine> but still, we need to trigger the platform from the sdk build
[16:39] <marcustomlinson> right
[16:40] <marcustomlinson> and having the apps build after sdk and platform snaps is nice because it’ll confirm they build with the new bases
[16:40] <marcustomlinson> Oh sorry no, those do pull from stable
[16:41] <kenvandine> YEAH
[16:41] <kenvandine> whoops :)
[16:41] <kenvandine> what i really want is build.snapcraft.io to support gitlab like it does for github
[16:41] <kenvandine> then we can use the API to trigger builds 
[16:42] <kenvandine> and
[16:42] <kenvandine> we'll get more builds for free
[16:42] <marcustomlinson> but your automated test thingies from cwayne confirm apps build with new platform builds right?
[16:42] <kenvandine> that doesn't build
[16:42] <kenvandine> it's a screenshot of the running app from the candidate channel
[16:43] <marcustomlinson> ah, but against a candidate platform?
[16:43] <kenvandine> so when a content snap is updated i can quickly see that some of the snaps load and look right
[16:43] <kenvandine> yes
[16:43] <marcustomlinson> or candidate apps using stable platform :P
[16:43] <kenvandine> and gtk-common-themes from candidate
[16:43] <marcustomlinson> ok cool
[16:43] <marcustomlinson> just checking ;)
[16:46] <marcustomlinson> so technically it should be: build sdk snaps -> build platform snaps -> test -> release -> build app snaps -> test -> release
[16:46] <marcustomlinson> that first test would have to be against test snaps
[16:47] <marcustomlinson> ones that build against the new sdk
[16:47] <marcustomlinson> perhaps cwayne could add a build step to the testing?
[16:48] <marcustomlinson> /s/new/candidate
[16:53] <marcustomlinson> anywho :) goodnight all
[19:22] <hellsworth> ogra: is there something special i need to do to get UC20 to boot in kvm? I've tried my same qemu-virgil command used for ubuntu-core-18-amd64.img, but used on the current beta of ubuntu-core-20-amd64.img and i just get a preboot screen saying invalid signature.
[19:23] <ogra> there should be an unsigned image ... not sure the signed one works i kvm (better ask in #snappy, i haent done much with core20 yet... specifically on obsolete arches like x86 😉 )
[19:24] <ogra> *havent
[19:24] <hellsworth> ha
[19:24] <hellsworth> ok
[19:24] <hellsworth> thanks
[22:36] <PaulePanter> Dell Lattitude and Precision laptop get into a state, where they do not boot with power cable unplugged. :/
[22:37] <PaulePanter> https://bugs.launchpad.net/bugs/1661741
[22:37] <PaulePanter> https://bugs.launchpad.net/dell-sputnik/+bug/1871491
[22:37] <PaulePanter> Any help appreciated.
[22:37] <PaulePanter> They are part of Dell’s Sputnik program, so I am pretty suprised, there is such a bug, and nobody cares.