[05:26] <mborzecki> morning
[05:57] <jamesh> mborzecki: are you able to restart the failed sub-job in https://travis-ci.org/snapcore/snapd/builds/562037700 ?
[06:01] <mborzecki> jamesh: sure, let me check
[06:01] <jamesh> thank you
[06:02] <mborzecki> jamesh: ok, restarted
[06:22] <zyga> Hello
[06:34] <mborzecki> zyga: hey
[06:45] <zyga> I will be around in 30
[06:55] <mborzecki> need to run a quick errand
[06:55] <mborzecki> mvo: morning
[06:55] <mborzecki> zyga: mvo: i'm updating the notes on cgroups https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7 and testing some things along the way
[06:55] <mborzecki> back in 30 or so
[07:02] <mvo> hey mborzecki
[07:02] <mvo> mborzecki: nice, thank you!
[07:11] <zyga> back now
[07:11] <zyga> mborzecki: looking
[07:12] <zyga> mvo: some good progress last week, apart from me forgetting to modify data sets for ubuntu core the new mount ns test is good
[07:13] <mup> PR snapd#7139 closed: tests: don't leak /run/netns mount <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7139>
[07:13] <zyga> mborzecki: I have answers to some of the TODOs there
[07:18] <mup> PR snapd#7127 closed: tests: removing support for ubuntu cosmic on spread test suite <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7127>
[07:24]  * zyga breakfast
[07:53] <zyga> mborzecki: do you think my explanation on https://github.com/snapcore/snapd/pull/7138 makes sense?
[07:53] <mup> PR #7138: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <https://github.com/snapcore/snapd/pull/7138>
[08:03] <mborzecki> re
[08:28] <mup> PR snapd#7138 closed: tests: remove lxd / lxcfs if pre-installed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7138>
[08:29] <mvo> mup is back!
[08:29] <mvo> woooooh!
[08:33] <Chipaca> pedronis: WDYT of returning an ad-hoc struct from GetCurrentBlah?
[08:34] <pedronis> Chipaca: it's fine,  adding Revision to PlaceInfo wouldn't be a bad idea
[08:34] <pedronis> but is a chunk of work because Info.Revision exists
[08:35] <Chipaca> pedronis: yeah, i'd need to hunt down all those first, but it's easy to do :-)
[08:35] <Chipaca> pedronis: should I park this, do the revision thing, and then do this?
[08:35] <Chipaca> i could timebox it to ~1h
[08:37] <jamesh> zyga: did you have any more comments on https://github.com/snapcore/snapd/pull/6959 (adding osutil.EnsureTreeState) after the last round of changes?
[08:37] <mup> PR #6959: osutil: add EnsureTreeState helper <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6959>
[08:37] <pedronis> Chipaca: let's start with a simple struct
[08:37] <pedronis> and consider the other issue separately
[08:38] <mup> PR snapd#7141 closed: tests: add mountinfo-tool --ref-x1000 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7141>
[08:38] <zyga> jamesh: I'll review it now
[08:38] <jamesh> zyga: thanks!
[08:38] <Chipaca> pedronis: ack
[08:39] <jamesh> zyga: I think everything is ready to land for https://github.com/snapcore/snapd/pull/7054 too
[08:39] <mup> PR #7054: interfaces: add an interface that grants access to the PackageKit service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7054>
[08:39] <zyga> jamesh: I'll check it out as well
[08:39] <zyga> ah, I remember it :)
[08:47] <Chipaca> pedronis: a single struct with kernel and core names and revisions, or two structs each with just naem and revision?
[08:47]  * Chipaca is full of silly questions today
[08:47] <Chipaca> pedronis: i think two structs works better in this case
[08:47] <Chipaca> pedronis: but I don't know how you expect this to grow, yet
[08:49] <ackk> hi, is there a way to strace a program manually run inside a "snap run --shell" session ?
[08:50] <pedronis> Chipaca: sorry, I still think this should take snap.Type
[08:50] <Chipaca> :-(
[08:50] <pedronis> (it's the thing we need anyway going forward)
[08:50] <Chipaca> so much work done n times
[08:50] <Chipaca> but, ok
[08:51] <Chipaca> also it becomes a bunch of ifs again which is ugly
[08:51] <Chipaca> augh
[08:51] <pedronis> Chipaca: ?
[08:52] <Chipaca> pedronis: if type is kernel look for snap_kernel if type is core or base or os look for snap_core
[08:52] <pedronis> Chipaca: you understand that the one in booted goes way
[08:52] <pedronis> then, though
[08:52] <pedronis> that one has an if/switch anyway
[08:52] <Chipaca> ah, good point
[08:53] <pedronis> sorry, I thought this through but wasn't explicit
[08:53] <Chipaca> pedronis: booted has two calls to this though, and one of them will be calling this twice
[08:53] <pedronis> yes
[08:53] <pedronis> I know
[08:53] <Chipaca> ok
[08:53] <pedronis> that was my comment about efficient
[08:53] <Chipaca> on it
[08:53] <Chipaca> yeah, i figured
[08:53] <pedronis> but we'll need to change that anyway
[08:53] <pedronis> because at some point base and kernel info will be in two different places
[08:53] <pedronis> so something has to give
[09:04] <Chipaca> pedronis: a problem(ish, maybe more so in the future) with making it take type is that UpdateBootRevisions would, on the surface, need to know whether to use base or core
[09:04] <Chipaca> right now it makes no difference and I'll just use TypeOS
[09:05] <Chipaca> but core20 might make that harder
[09:05] <pedronis> Chipaca: I expect all this code to change again
[09:06] <Chipaca> "Ave, Haxor, morituri te salutant"
[09:06] <pedronis> Chipaca: I would use TypeBase thoug, no?  and have a comment where used
[09:06] <Chipaca> pedronis: the result is the same either way -- why Base and not OS?
[09:07] <pedronis> Chipaca: because OS is "legacy" (dreaded word)
[09:07] <Chipaca> :-)
[09:07]  * Chipaca does «legacy, err := boot.GetCurrentBoot(snap.TypeOS)»
[09:07] <Chipaca> pedronis: base it is then
[09:11] <Chipaca> pedronis: type NameAndRevno, or type NameAndRevision?
[09:11] <mup> PR snapd#7140 closed: overlord/devicestate: update gadget update handlers and mocks <Gadget update> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7140>
[09:15] <popey_> jwheare: is 0.13.0 based off an internal branch?
[09:15] <jwheare> it's master
[09:15] <jwheare> hence edge channel
[09:16] <popey_> ahh okay
[09:16] <popey_> we'll start the machinery to create a pr for irccloud-desktop to put a face-punching dialog in it later
[09:16] <popey_> in preparation
[09:17] <tomwardill> yay, irccloud and snaps <3
[09:19]  * tomwardill switched
[09:38] <pedronis> Chipaca: NameAndRevision
[09:40] <Chipaca> hmm, i've had to add boot vars to one of the manager tests for it to pass
[09:40] <Chipaca> something's leaking :-|
[09:40] <Chipaca> should probably add ad-hoc methods to MockBootloader to set these things instead of raw boot vars
[09:45] <pedronis> Chipaca: mmh, probably slightly better to have a function that takes a MockBootloader instead of a method
[09:45] <pedronis> we might have many mock bootloaders laters
[09:45] <pedronis> maybe
[09:45] <pedronis> or something else
[09:46] <pedronis> Chipaca: boottest.SetBoot(bootloader,...) or something
[09:47] <Chipaca> pedronis: boottest.SetBootKernel(kernel, bootloader...)?
[09:48] <Chipaca> wth why does seahorse suddenly refuse to see my gpg keys
[09:48] <Chipaca> i'm going to have to edit the expiration on the terminal, like a caveman
[09:48] <pedronis> Chipaca: that works though, and SetBootBase ?
[09:48] <pedronis> doesn't need to take many for now
[09:48] <pedronis> I mean many bootloaders
[09:49] <Chipaca> pedronis: and SetBootMode maybe
[09:49] <Chipaca> i'll look to see how much that one is set outside of boot itself
[09:49] <Chipaca> first need to sort out my gpg keys as they've _just_ expired :)
[09:50] <mup> PR snapd#7054 closed: interfaces: add an interface that grants access to the PackageKit service <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7054>
[09:59] <jwheare> popey_: 0.13.0 has now been released, but the snap will continue to be edge channel due to the config perms crash
[10:04] <mvo> pedronis 7132 has a small suggestion and needs a test fix - if you agree with the ideas in there I could do it before lunch if you are busy
[10:06] <pedronis> mvo: given you have the changes, yes please, then it can be merged, right? if/when green
[10:07] <pedronis> *changes already
[10:12] <mvo> pedronis: I have the unroll, I need to fix one test failure that the PR has right now but hopefully easy
[10:18] <pedronis> mvo: something is missing to call StartUp I suppose
[10:19] <mvo> pedronis: yeah, happy to poke at it, just don't want to duplicate work :)
[10:19] <mvo> (i.e. want to ensure I don't look at this if you also do or know what to do etc)
[10:22] <pedronis> mvo: it's a one line fix
[10:23] <pedronis> mvo: this is likely the safest (going forward) fix:  https://pastebin.ubuntu.com/p/bbg7hzqyyW/
[10:26] <Chipaca> pedronis: I didn't add a SetBootMode one because the tests that are setting that seem to be caring about the mechanics of the whole update/rollback via boot things, so it'd be a rather bigger refactor
[10:26] <pedronis> that's fine
[10:26] <Chipaca> ie they set boot_mode and also snap_try_core
[10:27] <Chipaca> er, snap_mode*
[10:27] <Chipaca> probably worthwhile doing at some point, but not as part of this :)
[10:27] <mvo> pedronis: \o/
[10:33] <pedronis> Chipaca: +1, with some cosmetic nitpicks
[10:34] <Chipaca> pedronis: thanks
[10:34] <pedronis> probably need a 2nd look from mvo again
[10:34] <pedronis> given it changed quite a bit
[10:36] <jamesh> pedronis: re. your comments on https://github.com/snapcore/snapd/pull/6954, is designing a new REST API a blocker for the PR, or could that be delayed to a later PR (but before new API methods that actually do something are added)?
[10:36] <mup> PR #6954: sessionagent: add a REST interface with socket activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6954>
[10:54] <Chipaca> mvo: requested a re-review on #7142 as it's changed quite a bit
[10:54] <mup> PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot <Created by chipaca> <https://github.com/snapcore/snapd/pull/7142>
[10:58] <pedronis> jamesh: I plan to tweak it (slightly) and land it myself at this point, either today or tomorrow
[10:58] <jamesh> pedronis: okay.  Thanks!
[10:59] <mvo> Chipaca: sure, will do
[11:06] <pedronis> jamesh: also, I made a small comment and asked a question in the EnsureTreeState one, it seems super close
[11:25] <pedronis> mvo: Chipaca: I'm going to merge 6923 (I undid the renaming because I used cstrs all over the place, so if we want a better spelling we should change it across separately)
[11:27] <mup> PR snapd#6923 closed: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) <Complex> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6923>
[11:28] <Chipaca> pedronis: ¯\_(ツ)_/¯
[11:29] <pedronis> Chipaca: I don't have a strong preference, I think I choose the horrible names because some lines were very long but oh well
[11:29] <jwheare> jamesh: any thoughts on next steps for 7129?
[11:30] <mborzecki> mvo: one of our dependencies, github.com/ojii/gettext.go is no longer available in fedora
[11:31] <mborzecki> mvo: also they're using gopkg.in/cheggaaa/pb.v1 rather than github.com/cheggaaa/pb now
[11:34] <mup> PR snapd#7121 closed: tests: part2 making tests work on ubuntu-core-18 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7121>
[11:40] <jwheare> mup ignored me https://github.com/snapcore/snapd/pull/7129
[11:40] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[11:47] <zyga> mvo: https://github.com/snapcore/snapd/pull/7091 is green :)
[11:47] <mup> PR #7091: tests: measure properties of various  mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/7091>
[11:47] <zyga> mborzecki: can you have a 2nd look on the test
[11:47] <zyga> mborzecki: I tweaked it a little
[11:47] <zyga> mborzecki: I will adjust the wording, though ideally in a follow up since this took a while to get to
[11:53]  * zyga lunch
[12:16] <pedronis> is the hyper-v image still broken: https://forum.snapcraft.io/t/error-too-early-for-operation-device-not-yet-seeded-or-device-model-not-acknowledged/12421 ?
[12:20] <mup> PR # closed: snapd#5644, snapd#5822, snapd#6108, snapd#6258, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6666, snapd#6697, snapd#6705, snapd#6708, snapd#6714, snapd#6767, snapd#6839, snapd#6891, snapd#6950, snapd#6954, snapd#6959, snapd#6972, snapd#7005,
[12:20] <mup> snapd#7010, snapd#7031, snapd#7042, snapd#7066, snapd#7067, snapd#7073, snapd#7074, snapd#7079, snapd#7081, snapd#7087, snapd#7088, snapd#7091, snapd#7092, snapd#7109, snapd#7110, snapd#7111, snapd#7112, snapd#7124, snapd#7125, snapd#7126, snapd#7128, snapd#7129, snapd#7130, snapd#7131, snapd#7132,
[12:20] <mup> snapd#7133, snapd#7135, snapd#7136, snapd#7137, snapd#7142
[12:21] <mup> PR # opened: snapd#5644, snapd#5822, snapd#6108, snapd#6258, snapd#6341, snapd#6347, snapd#6360, snapd#6367, snapd#6404, snapd#6436, snapd#6666, snapd#6697, snapd#6705, snapd#6708, snapd#6714, snapd#6767, snapd#6839, snapd#6891, snapd#6950, snapd#6954, snapd#6959, snapd#6972, snapd#7005,
[12:21] <mup> snapd#7010, snapd#7031, snapd#7042, snapd#7066, snapd#7067, snapd#7073, snapd#7074, snapd#7079, snapd#7081, snapd#7087, snapd#7088, snapd#7091, snapd#7092, snapd#7109, snapd#7110, snapd#7111, snapd#7112, snapd#7124, snapd#7125, snapd#7126, snapd#7128, snapd#7129, snapd#7130, snapd#7131, snapd#7132,
[12:21] <mup> snapd#7133, snapd#7135, snapd#7136, snapd#7137, snapd#7142, snapd#7143
[12:29] <zyga> pedronis: I can check
[12:29] <zyga> pedronis: I have my windows hyper-v laptop
[12:38] <zyga> pedronis: there are two images available in the windows gallery: 19.04 and 18.04.2
[12:38] <zyga> I'll create each and let you know
[12:51] <mup> PR snapd#7091 closed: tests: measure properties of various  mount namespaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7091>
[12:54] <mup> PR snapd#7144 opened: tests: measure mount namespaces on Ubuntu 14.04 <Created by zyga> <https://github.com/snapcore/snapd/pull/7144>
[13:11] <mup> PR snapd#6959 closed: osutil: add EnsureTreeState helper <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6959>
[13:16] <ogra> Chipaca, i assume hello and hello-world havent been updated to base: core18 ?
[13:17] <Chipaca> ogra: correct
[13:17] <Chipaca> ogra: snap info tells you as much i think
[13:17] <ogra> right, then i guess my assumption is correct too
[13:17] <ogra> (and the tutorial needs fixing)
[13:17] <Chipaca> ogra: which is your assumption?
[13:18] <ogra> snapd wont start because the core snap doesnt exist but the hello snap is a required snap
[13:18] <ogra> so seeding cant complete
[13:18] <ogra> since a UC18 image only has core18 ... obviously
[13:22] <jdstrand> pedronis: fyi, I responded to https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411 (little surprised I wasn't invited to participate, but that's ok so long as the discussion continues in the forum)
[13:23] <pedronis> jdstrand: sorry, I thought about maybe to invite but was a last minute meeting
[13:24] <pedronis> jdstrand: also today we need to talk with foundation about the plan
[13:24] <mup> PR snapd#7145 opened: packaging/fedora: github.com/cheggaaa/pb is no longer used <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7145>
[13:24] <jdstrand> pedronis, mvo: also, fyi, https://github.com/snapcore/snapd/pull/7111, https://github.com/snapcore/snapd/pull/7112 and https://github.com/snapcore/snapd/pull/7124 should be ready for review (there is one small thing I want to do in a subsequent PR, but it isn't required)
[13:24] <mup> PR #7111: many: support system-usernames for 'snap_daemon' user <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7111>
[13:24] <mup> PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7112>
[13:24] <mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
[13:24] <jdstrand> pedronis: no worries
[13:25] <jdstrand> I've unblocked all of them and marked for 2.441
[13:25] <jdstrand> 2.41
[13:26]  * jdstrand also has docs to write and forum posts to update
[13:26] <Chipaca> 2.44.1.441.14
[13:26] <jdstrand> hehe
[13:28] <jdstrand> pedronis: oh, and I
[13:28] <jdstrand> 'm mashing 'Restart' for PR 7124's tests (normal intermittent non-PR related failures)
[13:29] <mup> PR #7124: many: create system-usernames user/group if both don't exist <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7124>
[13:29] <jdstrand> the other two have passed
[13:30] <Chipaca> mvo: https://knowyourmeme.com/memes/naruto-run
[13:31] <mvo> Chipaca: ta
[13:32] <Chipaca> mvo: can't have our manager falling that far behind
[14:08] <mup> PR snapd#7146 opened: UC20: cmd/snap-verify: sketch of snap-verify <Created by pedronis> <https://github.com/snapcore/snapd/pull/7146>
[14:11]  * cachio AFK
[14:23] <mup> PR core-build#47 closed: initramfs: restore wait-for-root calls <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/47>
[14:40] <ackk> jdstrand, hi, did you by chance manage to reproduce the issue with systemd-detect-virt not working in a VM?
[14:50] <Chipaca> ackk: in which vm?
[14:50] <Chipaca> ackk: and not working how?
[14:51] <ackk> Chipaca, https://bugs.launchpad.net/snapd/+bug/1831473
[14:51] <ackk> (recent comments)
[14:51] <mup> Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:New for jdstrand> <https://launchpad.net/bugs/1831473>
[14:51] <Chipaca> ackk: ah ok
[14:52] <Chipaca> ackk: for a moment i thought maybe it had something to do with systemd-detect-virt using capabilities instead of setuid
[14:53] <ackk> Chipaca, it doesn't seems not being able to read /proc/1/sched is really an issue (I did mention it since I was getting a denial there)
[15:05] <Chipaca> ackk: I blame mvo
[15:07] <ogra> he's so easy to blame
[15:15] <cwayne> ogra: not as easy as ondra though
[15:16] <ogra> true dat ....
[15:22] <mvo> Chipaca: wuut?
[15:29] <ijohnson> cwayne: don't you mean ondras
[15:29] <cwayne> I refuse to believe there's more than one
[15:42] <ogra> since people recently start mixing up ogra and ondra all the time in pings i guess he just wants to be more than me now :P
[15:55] <ackk> Chipaca, so you know what's going wrong, or just generically blaming mvo? :)
[15:57] <Chipaca> ackk: just generically
[15:57] <ackk> heh
[16:14] <pedronis> we should really stop to naively nest test suite, we just get test duplication
[16:14] <pedronis> I found another case
[16:15] <pedronis> mvo: seems it's you again
[16:15] <mvo> pedronis: oh no
[16:15] <mvo> pedronis: I remember doing that recently but I thought I extracted into a baseFooSuite
[16:15] <mvo> pedronis: which one is it?
[16:15] <pedronis> yes, you did that
[16:15] <pedronis> in validate_seed_test
[16:15] <pedronis> I fixed it
[16:16] <pedronis> yes, you need a base suite
[16:16] <pedronis> though in that case
[16:16] <pedronis> it was silly
[16:16] <pedronis> we needed 2 things
[16:16] <mvo> pedronis: thank you, let me check the PR to see what I did wrong
[16:16] <pedronis> but I found another one
[16:16] <pedronis> mvo: if you take a full suite an wrap in another check will run all the tests again
[16:17] <mup> PR snapd#7132 closed: overlord,daemon,cmd/snapd:  move expensive startup to dedicated StartUp methods <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7132>
[16:17] <mvo> pedronis: indeed, where did this happen?
[16:17] <pedronis> mvo: now I find this one: https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_set_test.go#L33
[16:17] <pedronis> this one is old
[16:17] <mvo> pedronis: oh, right - shall I fix or will you? sorry for that :(
[16:18] <pedronis> let me see how hard it is to fix
[16:18] <pedronis> mvo: anyway I'm mostly mentioning because is the 2nd time I see this recently
[16:18] <pedronis> and it's a bit annoying to untangle after the fact
[16:18] <pedronis> also slower tests
[16:18] <pedronis> and confusing failures
[16:19] <mvo> pedronis: yes, sry again
[16:20] <pedronis> seems there's a BaseSnapSuite
[16:20] <pedronis> so maybe just a mistyping
[16:20] <pedronis> not sure
[16:20] <pedronis> it's old
[16:21] <pedronis> easy fix
[16:22] <mvo> pedronis: let me know if I can help
[16:22] <pedronis> no it's fine
[16:22] <pedronis> just I was doing something unrelated that breaks many tests (shallowly)
[16:22] <pedronis> and I was getting many double failures
[16:29] <pedronis> ijohnson: https://forum.snapcraft.io/t/netplan-apply-inside-snaps/12411/10 it sounds like the granularity of the api will be restarting services, it will be the full apply afaiu, double checking with mvo
[16:30] <ijohnson> pedronis: perhaps I misunderstood, will `netplan apply` just have a check at the top for running in strict snap, and if so use dbus?
[16:32] <pedronis> ijohnson: for some value of top
[16:32] <pedronis> mvo: do you have your first pass somewhere?
[16:36] <ondra> cwayne because one is not enough :P
[16:39] <mvo> pedronis: yes, one sec
[16:39] <mvo> pedronis, ijohnson https://github.com/CanonicalLtd/netplan/compare/master...mvo5:dbus?expand=1
[16:39] <ijohnson> thanks mvo
[16:40] <pedronis> yea, is the fully apply
[16:40] <pedronis> that's what I had expected
[16:41] <mvo> ijohnson, pedronis why would we do something different?
[16:41] <ijohnson> okay, so what is the "snapd approved" way to check that a snap is in strict confinement? is checking for $SNAP is sufficient?
[16:41] <ijohnson> mvo: I was confused from the meeting, I thought it would be just to call out for restarting the services
[16:42] <mvo> ijohnson: no worries
[16:42] <pedronis> ijohnson: there isn't one right now I think
[16:42] <mvo> ijohnson: detecting strict confinement is something we need to think about, I have no clear answer
[16:43] <ijohnson> ok, well what I've always recommended is just checking for $SNAP, so perhaps that's sufficient for netplan
[16:45] <mvo> ijohnson: I think so
[16:45] <mvo> ijohnson: as you can see in the pr this part is not done yet
[16:46] <ijohnson> right I was just thinking that if you don't get it done before you are off I could try and take this over
[16:47] <mvo> ijohnson: sure, I'm almost EOD (plus bad network) so feel free to branch from this repo and add what is needed :) the python bits plus I want to explore tests
[16:48] <ijohnson> ok, I was going to work on the snap model first, but if I get blocked on that this afternoon/evening I will look into your branch
[16:48] <mvo> ijohnson: also no strong opinion on gio vs libsystemd for the service, I slightly prefer libsystemd
[16:48] <ijohnson> I'm not super familiar with either of them, so I'll go with whatever you prefer :-)
[16:50] <mup> PR snapd#7147 opened: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
[16:50] <mup> PR snapcraft#2636 closed: Release changelog for 3.7 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2636>
[16:50] <mvo> ijohnson: heh, in this case I think you don't have to touch the C code, I think that part is done
[16:50] <ijohnson> +1
[16:50] <pedronis> Chipaca: #7147 is what we discussed briefly this morning (it just unblocks mentally to decide what to do in the agent PR)
[16:51] <mup> PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client <Created by pedronis> <https://github.com/snapcore/snapd/pull/7147>
[16:51] <pedronis> ijohnson: could update your forum topic to reflect better the plan
[16:51] <ijohnson> pedronis: ack
[16:51] <pedronis> thx
[16:52] <ogra> pedronis, did you follow https://forum.snapcraft.io/t/error-too-early-for-operation-device-not-yet-seeded-or-device-model-not-acknowledged/12421 ?
[16:52] <pedronis> which part?
[16:53] <ogra> it seems rather serious that you need to know in advance which base the snaps use that you put into required-snaps (and that the image fails in fatal ways if you dont)
[16:53] <pedronis> recent prepare-image will error
[16:53] <pedronis> if you miss one
[16:53] <ijohnson> pedronis: updated forum post
[16:53]  * ijohnson lunches
[16:53] <ogra> well, prepate-image errors if you dont explicitly seed core
[16:54] <pedronis> core is mostly always added
[16:54] <ogra> not on core18 images
[16:54] <pedronis> that's true
[16:54] <pedronis> but then it will error
[16:54] <pedronis> no?
[16:55] <ogra> my core18 builds all only have snapd, core18, gadget and kernel
[16:55] <pedronis> ah, maybe it doesn't
[16:55] <pedronis> but it will
[16:55] <ogra> ok
[16:55] <pedronis> there's branch that is fixing some of this area
[16:55] <pedronis> I think you are right, current code
[16:55] <ogra> good, so we dont need a bug the
[16:55] <pedronis> just ignores the missing core
[16:55] <ogra> *then
[16:56] <ogra> right ... and then seeding on firstboot explodes
[17:03] <mvo> pedronis: uh oh https://paste.ubuntu.com/p/h369DwHwzZ/
[17:03] <mvo> pedronis: snapd is crashing on me (edge)
[17:08] <ogra> jdstrand, snap info joule-linux .... <- this smells pretty rotten (i wonder what we should do about it, i only found out about it because of https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#2 (which i didnt know about til today))
[17:09] <ogra> (some would perhaps say s/rotten/ripened/ :P )
[18:07] <mup> PR snapd#7148 opened: configstate: fix crash in purgeNulls <Created by mvo5> <https://github.com/snapcore/snapd/pull/7148>
[18:15] <bcdonadio> as a user of a snap package, what's the easiest way to have a given env var always set when invoking the app?
[18:15] <bcdonadio> like: $ MYVAR=myvalue myapp
[18:16] <bcdonadio> where myapp is a snap package
[18:42] <jdstrand> ogra: jesse is the uploaded. he could request to have it removed
[18:42] <jdstrand> uploader*
[18:47] <diddledan> bcdonadio: if the snap doesn't overwrite that particular variable it is done the same way you'd do any app
[18:49]  * ijohnson wonders what to do if a snap does overwrite that variable
[18:52] <diddledan> in those cases unless the snap allows you to set it yourself, such as via a `snap set` command, then you're out of luck
[18:55] <ijohnson> diddledan: yeah, it would be nice if there was a way to do that though, perhaps a mechanism where the snap can declare it either takes the user's value or the value defined in snapcraft.yaml
[18:55] <ijohnson> (with the user's value taking precedence)
[19:18] <zyga> kenvandine, mvo: I just tested the 19.04 hyper v image and it is busted
[19:18] <zyga> I can create an account, log in and then the session dies
[19:18] <zyga> 18.04.2 image is downloading, I'll report back
[19:18] <zyga> ubuntu images download x10 slower than windows images
[19:18] <zyga> windows image is 13GB and downloads in minutes
[19:19] <zyga> ubuntu is 1/10th and downloads in hours
[19:19] <ijohnson> zyga where is it downloaded from?
[19:19] <kenvandine> zyga: snap is broken in that image
[19:20] <kenvandine> we've been trying to get new images posted... but running into more problems
[20:07] <zyga> ijohnson: I used the "gallery" built into windows hyper-v quick create
[20:07] <zyga> ijohnson: I don't know
[20:07] <ijohnson> hmm that's really odd
[20:08] <zyga> kenvandine: ack, I just wanted to report this since pedronis asked today
[20:08] <zyga> kenvandine: I'm booting the 18.04.2 image now
[20:12] <zyga> kenvandine: the 18.04.2 image is also busted
[20:12] <zyga> kicks me out of the system as soon as I log in
[20:12] <kenvandine> zyga: yeah, same issue
[20:12] <kenvandine> oh wait, you can't login in the one in quick create?
[20:13] <kenvandine> the version in quick create has the snapd seeding problem
[20:13]  * Pharaoh_Atem waves
[20:13] <kenvandine> those both worked for me this morning
[20:13] <kenvandine> zyga: but snap seeding was busted
[20:13] <kenvandine> we're working on new images, but have run into dependency issues with the hwe packages
[20:15] <zyga> kenvandine: yes, I tried the ones from quick create
[20:15] <zyga> kenvandine: do you want me to report this somehow?
[20:15] <zyga> Pharaoh_Atem: o/
[20:16] <kenvandine> We are going to post new images anyway to fix the snap seeding issue
[20:16] <kenvandine> which we'll run through the test plan
[20:16] <zyga> kenvandine: ok
[20:16] <kenvandine> i wonder if this month's Windows update broke something
[20:16] <kenvandine> i've told it not to install the updates yesterday
[20:16] <zyga> shall I just remove the one I created?
[20:17] <kenvandine> yeah
[20:17] <kenvandine> nothing you can do with it
[20:17] <zyga> I'm running insiders
[20:17] <kenvandine> ah!
[20:17] <zyga> kenvandine: btw, I also created a windows machine for comparison and that one booted
[20:17] <kenvandine> they might have other issues
[20:17] <kenvandine> i'll have Will try it tomorrow with insiders to make sure it works
[20:17] <zyga> ok
[20:17] <zyga> I'll EOD now
[20:17] <zyga> ttyl
[20:17] <kenvandine> and maybe we'll have you test it next week too
[20:17] <kenvandine> good night
[21:25] <bcdonadio> diddledan: gotcha, I will try to work that out with the package maintainer then, currently there are no settings for that snap
[23:09] <mup> PR snapcraft#2638 opened: remote-build rebased on 3.7 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2638>