[00:21] <mup> PR snapd#7691 closed: builtin/browser_support.go: allow monitoring process memory utilizati… <Created by Erick555> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7691>
[01:20] <mup> PR snapd#7693 opened: Enabled GPG plug to access extra socket <Created by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
[01:35] <mup> PR snapd#7693 closed: Enabled GPG plug to access extra socket <Created by Kedstar99> <Closed by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
[01:38] <mup> PR snapd#7693 opened: Enabled GPG plug to access extra socket <Created by Kedstar99> <https://github.com/snapcore/snapd/pull/7693>
[05:47] <mup> PR snapd#7689 closed: client,daemon: pass sha3-384 in /v2/download to the client <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7689>
[05:50] <mup> PR snapd#7692 closed: tests: opensuse tumbleweed has similar issue than arch linux with snap --strace <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7692>
[06:15] <mborzecki> morning
[06:19] <mvo> hey mborzecki
[06:20] <mborzecki> -3 in the morning
[06:20] <zyga> Hey
[06:21] <zyga> I’ll start sometime after 8
[06:21] <zyga> Sorry about all the bug spam from last night
[06:28] <mborzecki> zyga:  hey
[07:05] <mup> PR snapd#7684 closed: tests: disable mount-ns test in release/2.42 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7684>
[07:06] <mup> PR snapd#7661 closed: packaging: tweak handling of usr.lib.snapd.snap-confine <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7661>
[07:51] <pstolowski> morning
[08:09] <zyga> hey pawel
[08:12] <zyga> hey mvo
[08:31] <zyga> rebooting
[08:39] <mborzecki> pstolowski: hey
[08:40] <pedronis> #7679 needs a 2nd review
[08:40] <mup> PR #7679: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7679>
[09:17] <mup> PR snapd#7685 closed: snapstate,devicestate: make OldModel() available in DeviceContext <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7685>
[09:49] <ondra> sergiusens can you translate for me this error "Snap 'grade' was set to 'stable' but must be 'devel'." and "Set 'grade' to 'devel' or use a stable base for this snap."
[09:50] <ondra> sergiusens candidate channel and something what worked yesterday
[09:53] <mup> PR snapd#7679 closed: many: changes to testing in preparation of Core 20 seed consuming code <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7679>
[10:11] <sergiusens> ondra: can you share your snapcraft.yaml?
[10:11] <sergiusens> and build-environment
[10:11] <ondra> sergiusens https://git.launchpad.net/~ondrak/ondras-snaps/+git/openhab-snap/tree/snap/snapcraft.yaml?h=milestone-ondra
[10:12] <ondra> sergiusens build in LP with candidate channels for core/core18/snapcraft
[10:13] <sergiusens> ondra: oh, building with candidate channel of core18 could do it, let me look into it
[10:13] <ondra> sergiusens that seems like way to constraining
[10:14] <sergiusens> ondra: it was done to support core20, non-stable base means you can create a non-stable snap
[10:15] <sergiusens> ondra: and yes, it is a way of constraining, it is exactly what grade is
[10:15] <sergiusens> but I will need to think if your use case is one we want to allow for a stable grade
[10:15] <ondra> sergiusens so I will be only able to build stable grade with stable base snap installed on build machine?
[10:16]  * sergiusens notices it is well before working hours and parts
[10:17] <ondra> sergiusens because we build and push into non stable channels and then promote, this will essentially kill use-cases when we want test build agains future stable core snap
[10:52] <mup> PR snapd#7694 opened: many: load/consume Core 20 seeds (aka recovery systems) <Created by pedronis> <https://github.com/snapcore/snapd/pull/7694>
[11:01] <mup> PR snapd#7695 opened: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7695>
[11:03]  * Chipaca takes a break
[11:06] <mup> PR snapd#7696 opened: cmd/snap,image: initial support for Core 20 in prepare-image with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7696>
[11:07] <pedronis> Chipaca: mvo: ^ those are the current PRs,  7694 is the base and the larger one
[11:07] <mvo> pedronis: thank you
[11:09] <Chipaca> pedronis: ack
[11:11] <mup> PR snapd#7697 opened: interfaces/apparmor: handle pre-seeding mode <Prebaking> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7697>
[11:13] <mup> PR snapd#7650 closed: o/ifacestate: unify code into autoConnectChecker.addAutoConnections <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7650>
[11:52]  * pstolowski lunch
[12:07] <mup> PR snapd#7698 opened: seed/internal: doc comment fix and drop handled TODOs <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7698>
[12:17] <mup> PR snapd#7674 closed: interfaces: de-duplicate emitted update-ns profiles (2.42) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7674>
[12:21] <mborzecki> pedronis: i've updated #7665
[12:21] <mup> PR #7665:  devicestate: add support for gadget->gadget remodel  <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7665>
[12:30] <pedronis> mborzecki: I put it into my queue again
[12:43] <mup> PR snapd#7699 opened: release: 2.42.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7699>
[13:29] <mborzecki> cachio: hi, can you check whether fedora 31 images are already available in gce?
[13:30] <cachio> mborzecki, sure
[13:32] <ijohnson> morning folks, how is travis doing this morning
[13:32] <cachio> mborzecki, sorry, I forgot
[13:32] <ijohnson> some really weird failures it seems overnight, I had a unit test fail on me for snapstate.SnapState not having a Channel field but it definitely has that field?
[13:33] <cachio> mborzecki, we build fedora images
[13:33] <cachio> because are not published for gce
[13:33] <mborzecki> cachio: oh, using the cloud.fedoraproject.org ones?
[13:33] <cachio> mborzecki, we use the cloud ones yes
[13:34] <mborzecki> cachio: then 31 are up at https://alt.fedoraproject.org/cloud/
[13:35] <cachio> mborzecki, I could create one by using http://fedora.c3sl.ufpr.br/linux/releases/31/Cloud/x86_64/images/
[13:41] <mborzecki> cachio: sgtm, thanks!
[13:57] <Chipaca> zyga: https://github.com/whitequark/unfork/blob/master/README.md
[13:57] <zyga> Chipaca: I read that
[13:57] <zyga> neat stuff
[13:58] <Chipaca> zyga: i thought you might've
[13:58] <Chipaca> but, yeah
[13:58] <Chipaca> bonkers
[14:27] <zyga> mvo: I simplified this stuff, no snap-confine changes required
[14:27] <zyga> mvo: it's just a small go change now
[14:31] <mvo> zyga: oh?
[14:31] <mvo> zyga: how did you do that?
[14:31] <zyga> mvo: it works super nice already
[14:31] <zyga> mvo: working on snapd side now
[14:31] <zyga> mvo: we can actually wire it in cmd_run.go
[14:31] <mvo> zyga: what is the mechanism that you use there?
[14:31] <mvo> zyga: just looking for a flag file?
[14:31] <zyga> mvo: the same as before, yes
[14:32] <mvo> zyga: nice
[14:32] <zyga> mvo: if there's a feature flag enabled
[14:32] <zyga> mvo: and the inhibit file is present
[14:32] <zyga> mvo: loop on the presence
[14:32]  * mvo nods
[14:32] <zyga> mvo: // TODO: ask snapd for details
[14:32] <zyga> mvo: it even _runs_ the app later
[14:32] <zyga> it is easier and better than the idea that snap-confine execs that
[14:33] <mvo> zyga: nice
[14:35] <Chipaca> in unrelated news, don't do an image search for 'grub size', if you're thinking about bootloaders.
[14:39] <jdstrand> woo, looks at those small snap-update-ns profiles in 2.42.1
[14:39] <zyga> jdstrand: indeed :)
[14:39] <jdstrand> zyga: ^ (hi)
[14:39] <zyga> fixing bugs is the bests part of this job
[14:39] <jdstrand> zyga: I did notice, and this isn't a big deal, that there is a blank line between every rule
[14:40] <zyga> I noticed
[14:40] <zyga> I'll fix it up, just a bit annoying at the time
[14:40]  * jdstrand nods
[14:40] <zyga> snippets are joined with "\n" automatically
[14:40] <jdstrand> yeah
[14:40] <jdstrand> zyga: not a big deal. loving the reduced ruleset :)
[14:40] <zyga> requires either some test adjustment or some careful coding to prevent spurious \n
[14:40]  * jdstrand hugs zyga 
[14:40] <zyga> yeah, I will second what you said in a review
[14:41] <zyga> it's surprisingly readable
[14:41] <zyga> because it builds a context
[14:41] <zyga> and adds incremental changes
[14:41] <zyga> I didn't plan for that, it just ended up working better than I expected
[14:41] <jdstrand> zyga: I know, right? that OrderedSet worked wonderfully
[14:41] <jdstrand> me too :)
[14:41] <zyga> jdstrand: I'm doing a small prototype but I will be pushing that cgroup PR forward soon
[14:41] <zyga> jdstrand: with fixes that make lxd work
[14:42] <jdstrand> zyga: sweet :)
[14:43] <jdstrand> I want to update my test vms to 2.42.1 now that the dupe rules are gone, but I can what for stable
[14:43] <jdstrand> I'll just have to 'settle' for fast refreshes on my laptop for the next week or so :)
[14:47] <zyga> jdstrand: I noticed that it's also useful for development
[14:47] <zyga> jdstrand: because system key regeneration is super fast now
[14:48] <zyga> jdstrand: it was mainly slow because of this, apparently
[14:48]  * zyga breaks for some food
[14:58] <ijohnson> mvo: pedronis: assuming y'alls calendars are up to date, there's a 30m window in about an hour where we could meet to discuss if you want (I don't think the discussion would take 30m though)
[15:01] <ijohnson> also different topic, but should I get another review on #7581, or am I good to merge that? I had to tweak the tests slightly to disable core16 tests of the Info D-Bus method, not sure if that warrants more reviews
[15:01] <mup> PR #7581: tests: add netplan test on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7581>
[15:07] <mup> PR snapd#7700 opened: many: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
[15:17] <pedronis> ijohnson: it works for me, don't know about mvo
[15:18] <mvo> ijohnson: yes, works for me
[15:18] <cachio> Chipaca, hey https://paste.ubuntu.com/p/qPWP4nF48F/
[15:18] <cachio> on pi3, snap list does not show latest/
[15:18] <cachio> and it breaks the listing test
[15:19] <ijohnson> Cool I'll just send out a calendar invite just to be sure
[15:19] <cachio> Chipaca, it should show latest/edge?
[15:19] <mup> PR snapd#7698 closed: seed/internal: doc comment fix and drop handled TODOs <Simple 😃> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7698>
[15:20] <mup> PR snapd#7581 closed: tests: add netplan test on ubuntu core <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7581>
[15:21] <Chipaca> cachio: it depends, but probably yes
[15:21] <Chipaca> mmm
[15:21]  * Chipaca looks at what's on edge
[15:23] <cachio> Chipaca, I just refreshed and then did snap list
[15:23] <Chipaca> hmmm
[15:24] <Chipaca> there might be a bug somewhere
[15:24] <Chipaca> on edge
[15:24] <Chipaca> I'm seeing a tracking of "latest"
[15:24] <Chipaca> not "stable", not "latest/stable", just "latest"
[15:24] <Chipaca> that's not good
[15:24] <Chipaca> cachio: what channel are you looking at?
[15:25] <cachio> I have created an image with channel stable
[15:25] <cachio> and then refreshed core to edge
[15:25] <cachio> and I see what I pasted
[15:29] <Chipaca> cachio: let me think a bit
[15:29] <Chipaca> cachio: also, let me start with something sane because my local snapd has seen some shit (and might be doing its best)
[15:29] <cachio> Chipaca, hehee
[15:29] <cachio> sure
[15:29] <cachio> take your time
[15:30] <Chipaca> cachio: also, also, most of my channels work is not on master yet
[15:31] <Chipaca> cachio: and there's no code to add latest/ on master
[15:31] <Chipaca> afaik?
[15:31]  * Chipaca checks again
[15:31] <cachio> it si merged to master I think
[15:31] <Chipaca> ah, yes, there is, for the tracking channel, yes
[15:32] <Chipaca> in state
[15:32] <Chipaca> cachio: what does 'snap info' say for that snap?
[15:32] <Chipaca> cachio: in 'tracking:'
[15:32] <cachio> Chipaca, https://paste.ubuntu.com/p/TWHsVz6j6g/
[15:32] <cachio> tracking : edge
[15:33] <zyga> re
[15:34] <Chipaca> cachio: ok give me a bit
[15:34] <cachio> Chipaca, sure
[15:41]  * cachio lunch
[15:41] <Chipaca> cachio: ok, so i'm seeing this "latest" bug on stable; after your lunch we can talk
[15:41] <Chipaca> one dge i mean
[15:42] <cachio> sure
[15:42] <cachio> tell me now
[15:42] <cachio> lunch can wait
[15:42] <Chipaca> cachio: so. tell me what you did, on the pi3
[15:42] <cachio> Chipaca, so, is it a bug?
[15:42] <Chipaca> there is a bug, but it's not the one you told me :) so you tell me
[15:43] <cachio> hehe
[15:43] <cachio> Chipaca, I created a stable image
[15:43] <Chipaca> with you so far
[15:43] <cachio> then I booted that image in the pi3
[15:43] <Chipaca> ok
[15:43] <cachio> then I refreshed the core snap from edge
[15:43] <Chipaca> ok
[15:43] <cachio> rebooted
[15:44] <cachio> and did snap list
[15:44] <cachio> that's it
[15:44] <Chipaca> ok
[15:44] <Chipaca> there is no code that would've magically converted the 2.42 "stable" to "latest/stable" in 2.43
[15:44] <Chipaca> if you install something new, say: snap install --beta http
[15:44] <Chipaca> then you'd see latest/beta
[15:45] <Chipaca> the code to fix state is still up for review
[15:45] <Chipaca> cachio: are you thinking of cutting edge to candidate or something?
[15:46] <Chipaca> because i wouldn't ship with part of this channels work
[15:46] <Chipaca> i'd recommend backing out the change, or merging the rest of it
[15:46] <cachio> Chipaca, add
[15:46] <cachio> ok
[15:47] <Chipaca> cachio: the bug _I_ saw was that the code for 'snap list' turns "latest/stable" into "latest", which could be confusing, but it's only for display so it's not a biggie
[15:47] <Chipaca> and it would not be a problem with the rest of channels
[15:47] <cachio> in that case the problem is the test, but should automatically be fixed soon
[15:47] <Chipaca> ok
[15:48] <Chipaca> well, should be, but reviews are hard to come by :)
[15:49] <cachio> Chipaca, agree :)
[15:49] <cachio> thanks for the help
[15:52]  * cachio lunch for real now
[16:33]  * Chipaca steps away for a while
[16:36]  * Chipaca lied
[16:48] <Chipaca> ok, now yes
[16:48] <Chipaca> bbl, ttfn
[17:03] <jdstrand> zyga: in case you didn't see and possibly relevent for your pr: https://bugs.launchpad.net/bugs/1850667
[17:03] <mup> Bug #1850667: cgroup v2 is not fully supported yet, proceeding with partial confinement <docker.io (Ubuntu):New> <lxd (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1850667>
[17:06] <mup> PR snapcraft#2779 closed: ci: switch to travis workspaces <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2779>
[17:12] <mup> PR snapcraft#2780 opened: remote-build: rename `--arch` to `--build-arch` <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2780>
[17:15] <zyga> jdstrand: thank you
[17:23] <zyga> jdstrand: relevant to this is https://github.com/snapcore/snapd/pull/7614
[17:23] <mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
[17:24] <zyga> jdstrand: not urgent but if you look at the PR text you can see where this is going
[17:24] <zyga> jdstrand: I have code that is close to handling v2 as well
[17:24] <zyga> jdstrand: but not fully working, it's been touched a while ago the last time
[17:25] <zyga> jdstrand: but this moves us towards real v2 support end to end, without partial
[17:26] <jdstrand> zyga: ack, thanks. it is on my list but not at the very top. hopefully late this/early next week
[17:26] <zyga> jdstrand: but first, that agent needs to land
[17:26] <zyga> jdstrand: no rush, I'm off on Friday
[17:26] <zyga> jdstrand: really no rush, it's post vancouver topic
[17:26] <jdstrand> ok, thanks
[17:26] <zyga> jdstrand: but after that we could get full v2 support in about three weeks
[17:26] <jdstrand> ok even better. cause the stuff in front is all pre-vancouver :)
[17:27] <jdstrand> zyga: that's really cool :)
[17:27] <zyga> jdstrand: yeah
[17:41] <mvo> pedronis: I pushed an update to 7649
[17:41] <mvo> pedronis: if that looks good I will push the same approach to 7682
[17:41] <mvo> pedronis: should be small and simple to review
[17:42] <pedronis> mvo: do you want me to look tonight? or tomorrow?
[17:42] <mvo> pedronis: tomorrow is fine of course
[17:42] <pedronis> ok
[18:57]  * cmatsuoka steps into another strange race-like behavior when partitioning disks
[19:03]  * Chipaca AFKs for another while
[19:03]  * cachio afk
[19:12] <Saviq> jdstrand: hey, I'm trying to make snapcraft compatible with strict multipass, which means piping file contents via stdio rather than throwing file paths around
[19:12] <Saviq> basically I need the equivalent of: cat /tmp/tmp6q6ur_co/snapd.snap | multipass transfer - snapcraft-multipass:/var/tmp/snapd.snap
[19:12] <Saviq> but when I do this in python, I'm getting a denial:
[19:13] <Saviq> https://pastebin.ubuntu.com/p/6nnw6GNjWG/
[19:27] <Saviq> it seems like Python is making some kind of a short circuit between the confined process and the file being read?
[19:34] <jdstrand> Saviq: hey, that's funny you should mention that as I was doing an investigation on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1849753
[19:34] <mup> Bug #1849753: AppArmor profile prohibits classic snap from inheriting file descriptors <amd64> <apport-bug> <focal> <wayland-session> <AppArmor:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1849753>
[19:35] <jdstrand> Saviq: it is the same issue you are seeing ('file_inherit' is blocked with snap-confine)
[19:36] <jdstrand> Saviq: you could probably do: multipass transfer - snapcraft-multipass:/var/tmp/snapd.snap < /tmp/tmp6q6ur_co/snapd.snap
[19:37] <jdstrand> Saviq: well, maybe not since you said python is doing this to you
[19:38] <jdstrand> Saviq: I can't think of a way to do that besides making python read from /dev/stdin
[19:38] <jdstrand> (and I'm not sure otoh how to make it do that)
[19:39] <jdstrand> Saviq: dan from our team might have a suggestion
[19:40] <Saviq> jdstrand: right, in this case the calling process (snapcraft) is classic and the callee is strict, but I suppose the same thing applies
[19:41] <Saviq> but yeah I may be able to do the shell dance
[19:43] <jdstrand> Saviq: that doesn't matter, it is that you are calling something in /snap/bin which calls snap run, which calls snap-confine and it doesn't have access at the profile transition when the path is revalidated
[19:44] <jdstrand> Saviq: you could also trying calling something in /snap/whatever/current/... instead, outside of confinement, but that is likely not ideal
[19:44] <jdstrand> s/outside/which ends up being outside/
[19:44] <Saviq> yeah, a "cat file | multipass…" works fine
[19:45] <Saviq> "multipass… < file" has the same denial
[19:45] <Saviq> which I suppose makes sense
[19:51] <jdstrand> Saviq: ah, yes on both counts
[19:52] <mup> PR snapcraft#2781 opened: yaml_utils: move _load_yaml from project for re-use (and add tests) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2781>
[19:53] <Saviq> now… what's the reverse of "cat"… like "tee", but without printing to stdout :D
[19:54] <Saviq> ah, `dd` to the rescue :P
[19:56] <Saviq> but all that really won't be cross-platform…
[19:57] <jdstrand> there won't be an immediate fix for that bug. but there are some options to investigate before we have proper fd delegation in apparmor at least
[19:58] <jdstrand> that came out wrong
[19:58] <jdstrand> proper fd delegation would allow us to fix that. before we have that, there might be some things we can do, but that needs investigating
[20:00] <Saviq> it looks like I'll really have to read the file into memory to feed it in again…
[20:01] <Saviq> what's weird(ish) is that python claims that from 3.4 onwards the fds are non-inheritable, which I thought for a bit could avoid this…
[20:04] <mup> PR snapcraft#2782 opened: snapcraft: introduce click-based YAML configuration file support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2782>
[20:26] <mup> PR snapd#7701 opened: overlord: add kernel rollback accross reboots manager test and fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7701>
[20:46] <techalchemy> jdstrand, how's this
[20:46] <jdstrand> techalchemy: thanks! :)
[20:47] <mup> PR snapd#7702 opened: tests: adding fedora 31 to google-unstable backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702>
[21:22] <mup> PR snapcraft#2783 opened: cli: run review tools before pushing to the store if available <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2783>
[22:40] <mup> PR snapcraft#2780 closed: remote-build: option renames for arch, user, and accept-public-upload <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2780>
[22:40] <mup> PR snapcraft#2781 closed: yaml_utils: move _load_yaml from project for re-use (and add tests) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2781>
[23:16] <mup> PR snapcraft#2784 opened: [multipass] use stdio to get data in/out of Multipass <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/2784>
[23:43] <mup> PR snapd#7703 opened: cmd/snap: make 'snap list' shorten latest/$RISK to $RISK <Channels 🏷️> <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7703>
[23:46] <mup> PR snapcraft#2785 opened: remote-build: add initial command unit tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2785>