[00:43] <mup> PR snapd#8373 closed: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
=== luk3yx` is now known as luk3yx
[05:39] <mborzecki> morning
[05:42] <mborzecki> and back
[05:52] <mup> PR snapd#8376 closed: daemon: make POST /v2/systems/<label> root only <Simple 😃> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8376>
[05:52] <mborzecki> yay
[06:01] <jamesh> The travis jobs are precariously close to the 50 minute timeout
[06:03] <mborzecki> jamesh: trying to squeeze every minute of that test runs ;)
[06:03] <mborzecki> mvo: hey
[06:04] <jamesh> mborzecki: I've had a few test runs that seem to have just been unlucky and were killed
[06:05] <mborzecki> jamesh: yeah, the margin is just below 5 minutes now, if anything gets delayed (such as lxd test) we may easily hit the limit
[06:06] <mvo> hey mborzecki
[06:08] <mvo> mborzecki: this all sounds we really want to move to GH
[06:10] <mvo> mborzecki: are tests failing a lot this morning?
[06:11] <mborzecki> mvo: 2 of my prs had their travis jobs restarted (or they did not run since yday)
[06:11] <jamesh> mvo: not particularly more than usual.  I was just commenting on one of my runs getting failed by Travis's 50 minute timeout
[06:12] <jamesh> and that the usual successful runs aren't enormously shorter than that limit
[06:12] <mvo> right :/
[06:13] <jamesh> maybe we should stop adding new tests
[06:14] <jamesh> :-)
[06:14] <mvo> heh :) remove one exiting for each new test
[06:17] <mvo> hm, looking at 8392, what does "shealding" mean? "This is because the cloud team is shealding by default all the ubuntu
[06:17] <mvo> images on gce "?
[06:17]  * mvo maybe just did not had enough tea
[06:19] <mup> PR snapd#8391 closed: tests: fix cross build tests when installing dependencies <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8391>
[06:21] <mup> PR snapd#8387 closed: store: search v2 tweaks <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8387>
[06:30] <zyga> o/
[06:31] <zyga> mvo: github-has-no-50-minute-limit (just saying)
[06:31] <zyga> we could move all travis spread jobs over
[06:31] <zyga> and leave some boring checks for next
[06:33] <mvo> zyga: yeah
[06:33] <jamesh> I don't know.  A "remove two tests for each new test added" policy sounds appealing
[06:34] <jamesh> get rid of that regulation
[06:44] <mvo> jamesh: if I want to report a bug on GH actions to support "fail-ignore" or something, what's the most appropriate place/component in their issues, do you have a suggestion?
[06:45] <zyga> Their community thing
[06:46] <zyga> But that is reported already
[06:46] <jamesh> mvo: I've seen some general bugs filed against https://github.com/actions/toolkit/.  The forum is also worth looking at
[06:46] <jamesh> mvo: given that each job shows up as a separate check suite, is it needed?
[06:49] <mvo> jamesh: I would like to see the overall tickmark green or red
[06:49] <mvo> jamesh: it's kind of annoying to have to go to the details, it's minor, agreed :)
[06:50] <mvo> jamesh: we have a bunch of "unstable" systems that have frequent e.g. package manager mirror issues and it would be nice to not count those in the overall "is-green" assesment on the GH pull overview page
[06:58] <mup> PR snapd#8386 closed: many: support immediate reboot <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8386>
[07:03] <pstolowski> morning
[07:03] <mvo> pstolowski: good morning - do you think you could have  a quick look at 8383 ? needs a review
[07:04] <pstolowski> mvo: yes, of course
[07:04] <mvo> jamesh: looks like 8289 is ready, it's just spread that's not quite there?
[07:04] <mvo> jamesh: but it has two plus one etc? can I squash merge it?
[07:06] <jamesh> mvo: yes.  This was the one that hit the 50 minute kill timeout on the travis jobs
[07:06] <jamesh> mvo: I think it is good to go
[07:06] <mvo> jamesh: thanks, merged
[07:07] <mup> PR snapd#8289 closed: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8289>
[07:07] <mborzecki> yay!
[07:07] <jamesh> yay!
[07:08] <mborzecki> mvo: 44.2? :)
[07:09] <mvo> mborzecki: there will be a .2 for the search-v2 :)
[07:09] <mborzecki> mvo: cool, can we include the portal proxy as well?
[07:12] <mvo> mborzecki: I just cherry picked it, I think we want it
[07:12] <mvo> unless pedronis feels it's too much of a change to include the portal-proxy in 2.44.2
[07:15] <pedronis> mvo: jamesh: what are the risks? it will not be tested much if it goes into .2
[07:19] <jamesh> pedronis: that snaps calling /usr/bin/xdg-open will fail.  The PR's spread tests provide decent confidence for the systems it runs on.  It probably works on the older systems where the test fixture doesn't run.
[07:19] <jamesh> pedronis: it should make no difference on systems that don't have xdg-desktop-portal installed at all
[07:20] <pedronis> mvo: when are you cutting .2 ?
[07:21] <jamesh> (the spread test runs against the system's real xdg-desktop-portal daemon)
[07:33] <mborzecki> #8305 needs a 2nd review
[07:34] <mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
[07:34] <mvo> pedronis: soon, today ideally
[07:35] <mvo> pedronis: I would like to go over the 2.44 marked PRs today, i.e. I'm trying to get the seed warning done
[07:35] <mvo> pedronis: eh, seed-failed warning
=== pedronis_ is now known as pedronis
[07:37] <pedronis> mvo: there's a small risk of needing a .3 which would be annoying
[07:41] <mvo> pedronis: yeah, I don't have super strong opinions, we could be conservative and punt the portal stuff to 2.45
[08:08]  * zyga switches to reviews 
[08:13]  * zyga reads 8305
[08:14] <mvo> pedronis, degville I updated the warning text in 8372, I think we should move forward with the warning as a start
[08:15] <degville> mvo: thanks, I'll take a look.
[08:37] <zyga> times are interesting
[08:37] <zyga> my kids are doing more video calls than I do
[08:40] <zyga> mborzecki: what is the marker file for again, to trigger the whole workflow of selection?
[08:40] <mborzecki> zyga: to indicate that we detected the trigger during boot
[08:41] <zyga> and then run the chooser?
[08:41] <mborzecki> yes
[08:43] <mborzecki> the console conf integration bits only start the chooser iff the marker file is present already, but the extra sanity checks in the chooser do not harm
[08:43] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8305#pullrequestreview-385359049
[08:44] <mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
[08:46] <zyga> mborzecki: I'll pick up another review but please ping me for more iteration on this, even if you just reply to my comments
[08:47] <abeato> hey, I am trying to run the UC20 image from cdimage with kvm+tianocore, but kvm crashes on me when selecting install/recovery option, are there any instructions on how to test UC20?
[08:49] <mvo> abeato: hm, kvm+uefi (OVMF) should work, did you enable virtio? without virtio on the disk grub is incredible slow in uefi mode
[08:50] <abeato> mvo, I'm using this command line (no virtio, I'll try that): kvm -m 1024 -redir :8022::22 -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd ubuntu-core-20-amd64.img
[08:55] <zyga> actually
[08:56] <zyga> do we have a single place that explains how to run core20
[08:56] <zyga> I'd love to try it
[08:56] <zyga> but it seems that at least for now it's a bit of black magic and goat sacrifice
[08:57] <jamesh> zyga or mvo: could I trouble you to merge https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/364742 ?  -- this is for a snap used by my dbus-activation branch.
[08:57] <zyga> snappy-hub :)
[08:57] <jamesh> (unfortunately it is probably a little more effort than just hitting a button though)
[08:57] <zyga> sure
[08:58] <jamesh> thanks
[08:58] <zyga> do we need to rebuild the snap and publish it
[08:58] <zyga> or just merge the branch
[08:58] <zyga> oh, it's bzr
[08:58] <jamesh> the snap needs rebuilding, but that might happen automatically
[08:58]  * zyga checks if bzr is in focal
[08:58] <jamesh> it is
[08:58] <jamesh> well, brz is
[09:00] <abeato> zyga, re: UC20, +1 on that :)
[09:02] <mvo> jamesh: in a meeting right now, if zyga can help that would be great
[09:02] <zyga> jamesh: it's merged
[09:02] <zyga> mvo: done
[09:02] <zyga> jamesh: let me know if the snap needs poking to build
[09:02] <zyga> but https://code.launchpad.net/~mvo/+snap/test-snapd-dbus-service claims it's building automatically
[09:05] <jamesh> I'll keep an eye on it to make sure it starts.  Thank you
[09:13] <mborzecki> hmm has the pi kernel grown?
[09:13] <zyga> cheers: )
[09:13] <zyga> mborzecki: how big is it?
[09:15] <mborzecki> 22M
[09:19] <zyga> for pi 4?
[09:19] <zyga> or pi 2-3?
[09:20] <mborzecki> idk, pi-kernel
[09:20] <mborzecki> whicheven tht supports
[09:38] <mup> PR snapd#8369 closed: boot, overlord/devicestate, daemon:  implement requesting boot into a given recovery system <Needs Samuele review> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8369>
[09:40] <zyga> mvo: https://github.com/snapcore/snapd/pull/8390#pullrequestreview-385400365
[09:40] <mup> PR #8390: state: add state.CopyState() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
[09:45] <zyga> mvo: https://github.com/snapcore/snapd/pull/8382#issuecomment-607148635
[09:45] <mup> PR #8382: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[09:49] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378/files#diff-459c7505a1a8a6c804c8a0cf9032350eR82 is unused, is usage of opts coming later?
[09:49] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[09:52] <pstolowski> zyga: it's needed because all methods must implement common interface now. but perhaps it can be unnamed there
[09:52] <zyga> ah, I see
[09:52] <pstolowski> not every method will use opts internally
[09:52] <zyga> I'm mid-way through so perhaps it gets clear as I go down
[09:52] <zyga> thanks
[09:52] <zyga> I see
[09:52] <zyga> just asking :)
[09:53] <pstolowski> zyga: sure!
[09:55] <mup> PR snapd#8393 opened: cmd/snap,seed: validate full seeds (UC 16/18) for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8393>
[09:56] <mvo> zyga: thanks, looking
[09:56] <zyga> mvo: ping me for a follow-up of any kind please
[10:01] <mvo> zyga: thanks
[10:03] <mup> PR snapd#8383 closed: store: support for search API v2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8383>
[10:15] <mup> PR snapd#8394 opened: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[10:17] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378#pullrequestreview-385430838
[10:17] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[10:19] <zyga> mvo: https://github.com/snapcore/snapd/pull/8394#pullrequestreview-385450682
[10:19] <mup> PR #8394: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[10:19]  * zyga breaks to take the dog out
[10:21] <jamesh> mvo: when you're not busy, could you flip this snap build recipe over to building against Bionic? https://code.launchpad.net/~mvo/+snap/test-snapd-dbus-service
[10:25] <pstolowski> zyga: thanks, replied. i'll check if opts can be left unnamed
[10:26] <mvo> jamesh: do you have the link at hand? happy to do that
[10:34] <mup> PR snapd#8343 closed: config, features: move and rename config.GetFeatureFlag helper to features.Flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8343>
[10:39] <mvo> pedronis: when you have a moment, could you please have a look at 8372 ? hopefully very simple
[10:40] <mvo> jamesh: nevermind, updated and triggered a rebuild
[10:45] <mup> PR snapd#8395 opened: o/ifacestate: handle interface hooks when preseeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/8395>
[11:08] <pedronis> mvo: there some preexisting comments by zyga there that are not answered, also I think we can remove the XXX
[11:34] <zyga> re
[11:34] <zyga> back, sorry for the lag, $events at home
[11:48] <pedronis> pstolowski: made some suggestions in 8378
[11:52] <pstolowski> ty
[11:54] <zyga> mborzecki: FYI https://wiki.archlinux.org/index.php/Talk:Snap
[11:54] <pstolowski> pedronis: yep, sounds good
[11:54] <mborzecki> zyga: yeah, it's a known thing, we have a forum topic about that too
[11:55] <mborzecki> zyga: imo the 'workaround' doesn't make sens anymore, but we don't know what's wrong yet
[11:55] <zyga> yeah, just wanted to let you know about the talk page
[11:55] <mborzecki> zyga: mhm, i get email notifications about edits there :)
[11:55] <zyga> ah, ok
[11:55]  * zyga too :)
[11:55] <mborzecki> but than's for poking me :)
[11:55] <mborzecki> thanks ;)
[12:30] <zyga> FYI https://bugs.launchpad.net/snapd/+bug/1870123
[12:30] <mup> Bug #1870123: Panic: unlocking unlocked mutex in unit test <snapd:New> <https://launchpad.net/bugs/1870123>
[12:33] <pstolowski> zyga: pushed the changes to #8378, per Samuele's suggestions
[12:33] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[12:33] <zyga> looking
[12:36] <cachio> mvo, debian sid is failing to update https://travis-ci.org/github/snapcore/spread-cron/builds/668599845
[12:37] <cachio> I tried many things to correct that but the repo is not consistent
[12:37] <pedronis> pstolowski: the validateOnly where not core only, no?
[12:37] <cachio> mvo, any idea about a workaround?
[12:37] <zyga>  clang : Depends: clang-9 (>= 9~) but it is not going to be installed
[12:37] <pedronis> pstolowski: otherwise looks good
[12:38] <zyga> hmm
[12:38] <zyga> the debian image has weird repos:
[12:38] <zyga> W: GPG error: http://dl.google.com/linux/chrome/deb stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 78BD65473CB3BD13
[12:38] <zyga> why do we have a chrome PPA in a test image?
[12:41] <pedronis> pstolowski: btw we the tests were passing, maybe we need to mock release.OnClassic a bit more carefully
[12:42] <pedronis> that's old, not really related to the new code
[12:49] <pstolowski> pedronis: yes, you're right, thanks for catching!
[12:52] <mup> PR snapcraft#3006 opened: repo: always use host release and arch for Ubuntu <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3006>
[12:54] <cachio> zyga, hi
[12:54] <cachio> I saw that today
[12:54] <cachio> + rm -rf /tmp/snap.rootfs_SwGmI3 /tmp/snap.test-snapd-sh /tmp/snap.test-snapd-simple-service
[12:54] <cachio> rm: cannot remove '/tmp/snap.rootfs_SwGmI3': Device or resource busy
[12:55] <cachio> is it similar to what you sent yesterday
[12:55] <cachio> the issue in postrm
[12:55] <cachio> ?
[12:56] <mup> PR snapd#8372 closed: devicestate: generate warning if seeding fails <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8372>
[13:05] <zyga> cachio: no, that's not the same issue
[13:31] <mup> PR snapcraft#3007 opened: go: support projects with multiple binaries when using go.mod <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3007>
[13:34] <zyga> pedronis: I will review the user session daemons PRs
[13:34] <zyga> so the pi 4 heatsink without fans for folks in .pl: https://botland.com.pl/pl/obudowy-do-raspberry-pi/15107-obudowa-do-raspberry-pi-4b-aluminiowa-czarna-lt-4b03.html
[13:35] <zyga> and the version with fans https://botland.com.pl/pl/obudowy-do-raspberry-pi/15106-obudowa-do-raspberry-pi-4b-aluminiowa-z-dwoma-wentylatorami-czarna-lt-4b02.html
[13:35] <zyga> I bought both and I think the fans are useful, the heatsink got pretty hot otherwise
[13:35] <zyga> the same product can be obtained in other countries
[13:36] <zyga> it's brand new so should be coming in stock
[13:37] <ijohnson> abeato: just for the record are you also specifying the -bios option to ovmf ?
[13:39] <abeato> ijohnson, I tried that later and it crashed too - maybe the daily had some problem
[13:39] <ijohnson> mmm like you don't even get to the kernel ?
[13:40] <abeato> ijohnson, no - but later I created a UC20 image myself with some help from lool and I could get it to run
[13:40]  * zyga will grab some food and get back to reviews
[13:40] <ijohnson> abeato: ok were you using the image from cdimage originally?
[13:40] <abeato> I found other problems though - the network interface was not found by console-conf
[13:40] <abeato> yes
[13:41] <ijohnson> abeato: ok yeah I think there's something wrong with the images on cdimage, needs some investigation
[13:41] <abeato> ok
[13:50] <ijohnson> abeato: fwiw I just booted a fresh image I built with all edge or 20/edge snaps and it had a network connection fine, my qemu parameters are this:
[13:50] <ijohnson> https://www.irccloud.com/pastebin/C5EmaXnz/
[13:50] <abeato> ijohnson, thanks, will give that a try
[13:51] <ijohnson> and I built from this model: https://github.com/snapcore/models/blob/master/ubuntu-core-20-amd64-edge.model with these snaps:
[13:51] <ijohnson> https://www.irccloud.com/pastebin/nkoV2isM/
[13:52] <abeato> cool!
[13:54] <cachio> zyga, something insteresting
[13:54] <cachio> in bionic and focal we install evolution-data-server pkg
[13:54] <cachio> zyga, but https://paste.ubuntu.com/p/YSxvmGnSRK/
[13:54] <zyga> mmm
[13:55] <zyga> maybe do rdepends gdm3
[13:55] <zyga> and see what's there
[13:55] <zyga> something is pulling it in for sure
[13:55] <cachio> yes
[13:55] <cachio> 1 minutes, I am starting the instance
[13:56] <lool> abeato: how did you resolve the network connection issue?
[13:57] <zyga> cachio: rdepends you can check locally
[13:57] <abeato> lool, I've not solved it yet :) - I was about to try ijohnson stuff
[13:57] <lool>     -device virtio-net-pci,netdev=mynet0 \
[13:57] <lool> let's see  :-)
[13:59] <cachio> zyga, https://paste.ubuntu.com/p/BxZvWzWV99/
[14:00] <zyga> cachio: try this command
[14:00] <zyga> apt-cache rdepends gdm3 https://www.irccloud.com/pastebin/fVU2NVJt/
[14:00] <zyga> cachio: we must have got one of those installed
[14:00] <zyga> _or_ it's a recommends that is followed
[14:03] <cachio> I'll try that
[14:19] <mup> PR snapcraft#3004 closed: storeapi: add channel-map endpoint <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3004>
[14:20] <ijohnson> abeato: any luck?
[14:20] <cachio> zyga, none of them is installed https://paste.ubuntu.com/p/vHqV7gK2Tk/
[14:20] <mborzecki> zyga: ijohnson: pstolowski: which of you would like to take a look at https://github.com/CanonicalLtd/subiquity/pull/655 ?
[14:20] <mup> PR CanonicalLtd/subiquity#655: console_conf: implement UC20 recovery chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/655>
[14:21] <mborzecki> it might not match exactly our python formatting/naming rules, but tried to make it as close to what is already in subuiquity as i could
[14:21] <ijohnson> mborzecki: I can take a look at it, but I'm far from a python expert so I'll really just be reviewing for logic and not style or pythonicness
[14:21] <ijohnson> also wow that PR keeps growing :-)
[14:22] <mborzecki> thanks!
[14:22] <ijohnson> last I looked it was like 500 lines
[14:22] <mborzecki> ijohnson: tests made it grow a lot
[14:22] <mup> PR snapcraft#2995 closed: Add gcc to the build-packages for the gnome-3-34 extension <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2995>
[14:23] <cachio> zyga, I think –no-install-recommends should be used as you suggested
[14:23] <cachio> y
[14:25] <cachio> zyga, https://paste.ubuntu.com/p/bPVYwr9cgt/
[14:25] <cachio> zyga, I'll create a new PR in snapd to address that, thanks
[14:26] <pstolowski> mborzecki: i can take a look too, with same remark as Ian
[14:26] <mborzecki> pstolowski: thanks!
[14:28] <mvo> thanks zyga for help with this --no-intsall-recommends
[14:31] <zyga> I can look soon
[14:33] <mvo> zyga: I updated 8394
[14:35] <zyga> cachio: yeah, that's great
[14:35]  * zyga checks backlog
[14:42] <mup> PR snapd#8396 opened: tests: install dependencies with apt using --no-intsall-recommends <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8396>
[14:44] <zyga> mborzecki: as a meta-comment, it would be great to have some type annotations there
[14:45] <abeato> ijohnson, I just see a "Create bond" option, is that expected?
[14:45] <pstolowski> zyga: can you take another look at #8378?
[14:45] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[14:45] <zyga> pstolowski: sure
[14:45] <ijohnson> abeato: no :-/
[14:45] <ijohnson> abeato: what version of qemu are you using ?
[14:45] <zyga> we should snap qemu
[14:45] <ijohnson> abeato: I have QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu4)
[14:46] <ijohnson> zyga: someone did I think? but it was not qemu directly it was one of the higher level things
[14:46] <abeato> ijohnson, I wonder if it is OVMF_CODE.ms.fd, I do not have that
[14:47] <abeato> ijohnson,  2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23 - bionic, I guess I need to upgrade
[14:47] <ijohnson> oh wow yeah I think you need a new qemu version, can you try with a focal machine qemu ?
[14:47] <ijohnson> cmatsuoka: do you remember what the oldest version of qemu we have successfully booted uc20 with is? I seem to remember you had an old version for a while
[14:48] <ijohnson> abeato: re: OVMF_CODE I don't think that's an issue you wouldn't have made it to booting kernel and such if that was the issue
[14:48] <cmatsuoka> ijohnson: it was the stock bionic qemu I think
[14:48] <abeato> ijohnson, will try newer qemu, thanks
[14:48] <cmatsuoka> ijohnson: but with a newer ovmf
[14:49] <cmatsuoka> from... eoan?
[14:49] <ijohnson> ahhhh
[14:49] <ijohnson> cmatsuoka: but again that wouldn't affect networking would it?
[14:49] <cmatsuoka> never had problems with networking
[14:55] <cmatsuoka> mm wait, I think in early images we did have some problems with network options in console-conf
[14:56] <cmatsuoka> but it's already fixed
[15:11] <ijohnson> cmatsuoka: yeah I've never had problems with no network save when I wasn't able to boot it at all, but the oldest version of qemu I used was disco
[15:12] <ijohnson> (the version of qemu from disco)
[15:18] <zyga> mvo: https://github.com/snapcore/snapd/pull/8394#discussion_r401697213
[15:18] <mup> PR #8394: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[15:20] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378#pullrequestreview-385691376 +1
[15:20] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[15:21] <pstolowski> zyga: thanks!
[15:26] <zyga> hmm
[15:26] <zyga> latest lxd is not working on arm
[15:26] <zyga> fresh install fails
[15:26] <zyga> Error: Get "http://unix.socket/1.0": dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
[15:26] <zyga> ah, on core we're not adding the user to the lxd group
[15:26] <zyga> bummer
[15:29] <zyga> I'll resume reviews in an hour
[15:29] <zyga> my family needs some help
[15:29] <zyga> o/
[15:31] <mvo> zyga: thanks, in meetings but looking now
[15:33]  * ijohnson takes a break
[15:35] <mvo> zyga: please reload 8394, looks ok to me, looks like the comment thing stale detection was not working
[15:35] <zyga> mvo: I reloaded and it's still saying "Output if seeding was successful"
[15:35] <zyga> is that expected?
[15:36] <mvo> zyga: yeah, it's different from before
[15:36] <zyga> oh
[15:36] <mvo> zyga: do you think this should be different?
[15:36] <zyga> I mean the word output is weird
[15:36] <zyga> output what?
[15:36] <mvo> zyga: "Output true/false if seeding was successful"?
[15:36] <zyga> yeah but the help message just says "output if seeding was succesful"
[15:36] <zyga> what you said above is better
[15:38] <mvo> zyga: ok, will update
[15:38] <zyga> it's ok
[15:38] <zyga> I can send a follow up
[15:38] <zyga> just wasn't sure if github is broken
[15:38] <zyga> or if we are talking about separate things without knowing it
[15:38] <zyga> mvo: LGTM and I'll send a patch
[15:39] <zyga> +1
[15:39] <mvo> zyga: updated
[15:40] <zyga> thank you :)
[15:40] <mvo> zyga: slightly changed but hopefully good
[15:40] <mvo> zyga: let me know :)
[15:40] <zyga> yeah, that's good :)
[15:40] <zyga> thanks!
[15:40] <mvo> zyga: thank you!
[15:40] <mvo> zyga: this will unblock 2.44.2 :)
[16:16] <mup> PR snapd#8394 closed: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[16:21] <cachio> cmatsuoka, zyga reboot loop in digital ocean also happens
[16:21] <cachio> same bahaviour
[16:21] <cachio> so it is not related to gce
[16:24] <mvo> zyga, ijohnson I updated 8382 to use the snap debug validate-seed to properly fix/disable this
[16:25] <ijohnson> mvo: nice looking now
[16:26] <mvo> ijohnson: indeed, I'm much happier with this than with what we had before
[16:26] <ijohnson> yes this will hopefully make it a much better experience for users who run into this
[16:27] <ijohnson> mvo thanks, approved
[16:27] <mvo> \o/
[16:27] <mvo> thank you!
[16:28] <mup> PR snapd#8393 closed: cmd/snap,seed: validate full seeds (UC 16/18) for 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8393>
[16:29] <mvo> cachio: do we need anything for 2.44.2, any test fixes or anything? if not I will most likely finalize it tonight/tomorrow morning
[16:30] <cachio> mvo, no
[16:30] <cachio> mvo, no so far
[16:34] <mvo> cool
[16:35] <mup> PR snapd#8384 closed: tests: run "lxd" test again (reverts PR#8381) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8384>
[16:46] <zyga> mvo: looking
[16:47] <mup> PR snapd#8370 closed: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8370>
[16:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/8382#pullrequestreview-385768438
[16:49] <mup> PR #8382: packaging: detect/disable broken seed in the postinst <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[17:06] <mvo> zyga: replied
[17:07] <zyga> mvo: approved, thanks
[17:07] <mvo> zyga: \o/
[17:09] <jdstrand> mvo (cc ijohnson): I reviewed PR 8304 (and removed the blocked tag)
[17:09] <mup> PR #8304: usersession/userd: add zoommtg url support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
[17:09] <jdstrand> ijohnson: note, there is a non-blocking comment in there about zoomus://
[17:10] <ijohnson> thanks jdstrand I haven't seen that before, have you ever seen zoomus:// ?
[17:10] <jdstrand> ijohnson: no, just in that blog. it seems like it is just for iOS/android
[17:10] <ijohnson> jdstrand: ack
[17:10] <jdstrand> ijohnson: but I don't know for sure
[17:12] <mup> PR snapd#8304 closed: usersession/userd: add zoommtg url support <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
[17:20] <ijohnson> mvo: do you want to cherry-pick 8304 on top of release/2.44  ?
[17:27] <ogra> jdstrand, snap install zoom-client ;) (sadlyy i cant make it register a mime type to open zoomus:// urls yet)
[17:30] <jdstrand> ogra: https://forum.snapcraft.io/t/allow-snaps-to-register-new-mime-types/6467/10
[17:30] <jdstrand> ogra: I suggest Wimpress or someone raise this in stakeholders meetings to see if it can get roadmapped
[17:31] <ogra> well, it isnt urgent and i know there are more pressing tasks on the TOD of the snapd team ... but yeah, i saw that
[17:31] <ogra> *TODO
[17:32] <ogra> iirc that thread is pretty old already
[17:32]  * ogra checks again
[17:32] <jdstrand> ogra: it is, but with new comments
[17:32] <jdstrand> ish
[17:33] <ogra> yeah
[17:42] <cjp256> stgraber: came across an random failure `aa-exec: Permission denied` during `lxd waitready` following snap install: https://travis-ci.org/github/snapcore/snapcraft/jobs/666847835#L403  I'm not sure if it's an LXD issue or maybe a snapd issue?  Any idea?  Happy to submit a bug report, just wanted to send it to the right place :)
[17:43] <stgraber> cjp256: sounds like the lxd-support interface wasn't properly connected or applied
[17:44] <cjp256> stgraber: thanks!
[17:57] <cjp256> stgraber: fwiw, reported at https://bugs.launchpad.net/snappy/+bug/1870201
[17:57] <mup> Bug #1870201: lxd-support interface doesn't appear to get properly connected/ready <Snappy:New> <https://launchpad.net/bugs/1870201>
[17:58] <mup> Bug #1870201 opened: lxd-support interface doesn't appear to get properly connected/ready <Snappy:New> <https://launchpad.net/bugs/1870201>
[18:36] <interfect> Hey, what directories does snapd store state in?
[18:37] <interfect> I'm trying to run snapd inside Docker, and I need to set up volumes wherever snapd writes files it expects to read later, so I can destroy and recreate the container and not lose installed snaps.
[18:38] <interfect> Apparently preserving /var/run/snapd and /var/cache/snapd is not sufficient. Where else does snapd write to?
[18:39] <ogra> /etc/systemd/system ....
[18:39] <ogra> and /varLib/snapd
[18:39] <ogra> */var/lib/snapd
[18:40] <ogra> and if you have users also ~/snap and all the data therein
[18:48] <interfect> Hm. It looks like it drops files in /etc/systemd/system which need to be preserved, next to a bunch of files from the base image that also need to be there. So you can't just mount an empty host directory there to hold snapd's files, because that would hide all the files from the base system.
[19:09] <zyga> stgraber, cjp256 we've seen this randomly in tests as well
[19:09] <zyga> but I'm skeptical it's on snapd side, we really don't run any commands before confinement is set up
[19:10] <zyga> as for the case that an interface is not connected we would have to look
[19:10] <zyga> stgraber: when does lxd use aa-exec? super early on?
[19:11] <mup> PR snapd#8392 closed: tests: remove google-tpm backend from spread.yaml <Simple 😃> <Skip spread> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8392>
[19:11] <mup> PR snapd#8396 closed: tests: install dependencies with apt using --no-install-recommends <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8396>
[19:12] <stgraber> zyga: in this case, cjp256 is running the "lxd" command from the snap which does use the a--exec wrapper logic
[19:13] <zyga> cjp256: in the case when it failed, did it work just a moment later
[19:13] <zyga> cjp256: or did you have to do something to fix it?
[19:13] <cjp256> zyga: it was on google spread, i couldn't really do anything to test that unfortunately
[19:13] <zyga> aha
[19:13] <zyga> yeah, same as we saw :/
[19:13] <zyga> it's rather infrequent, maybe once a week
[19:13] <cjp256> but i expect that it worked fine on the next attempt
[19:14] <cjp256> i imagine we can just write a simple script to loop the same steps and maybe repro
[19:18] <interfect> OK I worked out how to get the volume to initialize from the container with https://github.com/MatchbookLab/local-persist but preserving /etc/systemd/system and /var/lib/snapd and /home isn't enough to make snapd keep its state across destruction and recreation of the container.
[19:18] <interfect> Or rather it seems that the snap stays installed but the command it sets up on the PATH goes away
[19:19] <interfect> Is /snap/bin bind-mounted over from somewhere else on the filesystem or something?
[19:24] <ijohnson> interfect: unfortunately snapd inside docker does not really work, because snapd needs lots of permissions to run, so even if you can get all the files in place, snapd would probably not start successfully
[19:27] <interfect> No I have it starting successfully, and I can even run snaps!
[19:28] <interfect> It looks like mounting /snap as a Docker volume also solves the persistence problem.
[19:28] <interfect> I'm working on top of https://github.com/ogra1/snapd-docker
[19:28] <interfect> But I'm adding the bits I need to also grant X11 access
[19:29] <interfect> It manages to turn off enough of Docker's confinement that snapd can run and do its confinement.
[19:29] <interfect> The only problem I have left is that I need to start a snap as root before it runs properly as my user.
[19:30] <interfect> Otherwise I get something like: cannot preserve mount namespace of process 875 as teatime.mnt: Permission denied
[19:31] <interfect> The only Google result for that error is the snapd source code; can anyone explain why it needs to preserve a mount namespace and why it would only work if root is running the `snap` binary? `snapd` is running as root the whole time.
[20:18] <ijohnson> interfect: ah well if you're using the bits from ogra's snapd-docker then you've already probably read the large security caveats there
[20:18] <ijohnson> interfect: why can't you run snaps outside of docker anyways?
[20:19] <ijohnson> interfect: I don't know exactly what you need to allow to make that mount namespace error go away, but it's quite likely that things have changed in snapd enough that ogra's project doesn't fully work there
[20:32] <mup> PR snapcraft#3008 opened: cli: use the channel-map api for status <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3008>
[21:06] <interfect> ijohnson: My home directory isn't under /home on my system, so I'm trying to work around the lack of any support in snapd for this: https://forum.snapcraft.io/t/support-for-non-home-homedirs/11209
[21:07] <interfect> ijohnson: If I run snapd and all the snaps in a Docker container, I can mount my real home directory as /home/$USER in the container, and also provide a /etc/passwd that claims that that is my home directory.
[21:08] <interfect> The recommended workaround of bind mounting your home directory into /home isn't sufficient, because it looks at /etc/passwd instead of $HOME for the user executing the snap to try and figure out where the home directory is.
[21:09] <interfect> So in addition to doing the bind mount you would still have to actually change your home directory to /home/$USER, as far as I can tell.
[21:10] <interfect> There must be a much lighter-weight way to trick snap/snapd into thinking your home directory is actually set to /home/$USER, but I haven't found one, and putting the whole thing in Docker seems to actually mostly work.
[21:21] <interfect> IMHO if Snap apps just saw my home directory as /home/$USER wherever it *really* was, it would save me a lot of headaches. I'm not sure having a consistent view of file paths between snap apps and the rest of the system is really that important.
[22:37] <mup> PR snapd#8397 opened: cmd/snap-confine/mount-support-nvidia.c: add libnvoptix as nvidia library <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8397>
=== Bruce is now known as Guest39351
[23:17] <mup> PR snapd#8254 closed: usersession/userd: add "zoommtg" to the white list of URL schemes handled by xdg-open <⛔ Blocked> <Created by troyready> <Closed by troyready> <https://github.com/snapcore/snapd/pull/8254>