[05:26] morning [05:57] mborzecki: are you able to restart the failed sub-job in https://travis-ci.org/snapcore/snapd/builds/562037700 ? [06:01] jamesh: sure, let me check [06:01] thank you [06:02] jamesh: ok, restarted [06:22] Hello [06:34] zyga: hey [06:45] I will be around in 30 [06:55] need to run a quick errand [06:55] mvo: morning [06:55] zyga: mvo: i'm updating the notes on cgroups https://gist.github.com/bboozzoo/76b1535c93686a27bb7fdbaad0f560f7 and testing some things along the way [06:55] back in 30 or so [07:02] hey mborzecki [07:02] mborzecki: nice, thank you! [07:11] back now [07:11] mborzecki: looking [07:12] 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] PR snapd#7139 closed: tests: don't leak /run/netns mount [07:13] mborzecki: I have answers to some of the TODOs there [07:18] PR snapd#7127 closed: tests: removing support for ubuntu cosmic on spread test suite === JanC_ is now known as JanC [07:24] * zyga breakfast [07:53] mborzecki: do you think my explanation on https://github.com/snapcore/snapd/pull/7138 makes sense? [07:53] PR #7138: tests: remove lxd / lxcfs if pre-installed [08:03] re [08:28] PR snapd#7138 closed: tests: remove lxd / lxcfs if pre-installed [08:29] mup is back! [08:29] woooooh! [08:33] pedronis: WDYT of returning an ad-hoc struct from GetCurrentBlah? [08:34] Chipaca: it's fine, adding Revision to PlaceInfo wouldn't be a bad idea [08:34] but is a chunk of work because Info.Revision exists [08:35] pedronis: yeah, i'd need to hunt down all those first, but it's easy to do :-) [08:35] pedronis: should I park this, do the revision thing, and then do this? [08:35] i could timebox it to ~1h [08:37] 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] PR #6959: osutil: add EnsureTreeState helper [08:37] Chipaca: let's start with a simple struct [08:37] and consider the other issue separately [08:38] PR snapd#7141 closed: tests: add mountinfo-tool --ref-x1000 [08:38] jamesh: I'll review it now [08:38] zyga: thanks! [08:38] pedronis: ack [08:39] zyga: I think everything is ready to land for https://github.com/snapcore/snapd/pull/7054 too [08:39] PR #7054: interfaces: add an interface that grants access to the PackageKit service [08:39] jamesh: I'll check it out as well [08:39] ah, I remember it :) [08:47] 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] pedronis: i think two structs works better in this case [08:47] pedronis: but I don't know how you expect this to grow, yet [08:49] hi, is there a way to strace a program manually run inside a "snap run --shell" session ? [08:50] Chipaca: sorry, I still think this should take snap.Type [08:50] :-( [08:50] (it's the thing we need anyway going forward) [08:50] so much work done n times [08:50] but, ok [08:51] also it becomes a bunch of ifs again which is ugly [08:51] augh [08:51] Chipaca: ? [08:52] pedronis: if type is kernel look for snap_kernel if type is core or base or os look for snap_core [08:52] Chipaca: you understand that the one in booted goes way [08:52] then, though [08:52] that one has an if/switch anyway [08:52] ah, good point [08:53] sorry, I thought this through but wasn't explicit [08:53] pedronis: booted has two calls to this though, and one of them will be calling this twice [08:53] yes [08:53] I know [08:53] ok [08:53] that was my comment about efficient [08:53] on it [08:53] yeah, i figured [08:53] but we'll need to change that anyway [08:53] because at some point base and kernel info will be in two different places [08:53] so something has to give [09:04] 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] right now it makes no difference and I'll just use TypeOS [09:05] but core20 might make that harder [09:05] Chipaca: I expect all this code to change again [09:06] "Ave, Haxor, morituri te salutant" [09:06] Chipaca: I would use TypeBase thoug, no? and have a comment where used [09:06] pedronis: the result is the same either way -- why Base and not OS? [09:07] Chipaca: because OS is "legacy" (dreaded word) [09:07] :-) [09:07] * Chipaca does «legacy, err := boot.GetCurrentBoot(snap.TypeOS)» [09:07] pedronis: base it is then [09:11] pedronis: type NameAndRevno, or type NameAndRevision? [09:11] PR snapd#7140 closed: overlord/devicestate: update gadget update handlers and mocks [09:15] jwheare: is 0.13.0 based off an internal branch? [09:15] it's master [09:15] hence edge channel [09:16] ahh okay [09:16] we'll start the machinery to create a pr for irccloud-desktop to put a face-punching dialog in it later [09:16] in preparation [09:17] yay, irccloud and snaps <3 [09:19] * tomwardill switched === alan_g_ is now known as alan_g [09:38] Chipaca: NameAndRevision [09:40] hmm, i've had to add boot vars to one of the manager tests for it to pass [09:40] something's leaking :-| [09:40] should probably add ad-hoc methods to MockBootloader to set these things instead of raw boot vars [09:45] Chipaca: mmh, probably slightly better to have a function that takes a MockBootloader instead of a method [09:45] we might have many mock bootloaders laters [09:45] maybe [09:45] or something else [09:46] Chipaca: boottest.SetBoot(bootloader,...) or something [09:47] pedronis: boottest.SetBootKernel(kernel, bootloader...)? [09:48] wth why does seahorse suddenly refuse to see my gpg keys [09:48] i'm going to have to edit the expiration on the terminal, like a caveman [09:48] Chipaca: that works though, and SetBootBase ? [09:48] doesn't need to take many for now [09:48] I mean many bootloaders [09:49] pedronis: and SetBootMode maybe [09:49] i'll look to see how much that one is set outside of boot itself [09:49] first need to sort out my gpg keys as they've _just_ expired :) [09:50] PR snapd#7054 closed: interfaces: add an interface that grants access to the PackageKit service [09:59] 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] 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] mvo: given you have the changes, yes please, then it can be merged, right? if/when green [10:07] *changes already [10:12] pedronis: I have the unroll, I need to fix one test failure that the PR has right now but hopefully easy [10:18] mvo: something is missing to call StartUp I suppose [10:19] pedronis: yeah, happy to poke at it, just don't want to duplicate work :) [10:19] (i.e. want to ensure I don't look at this if you also do or know what to do etc) [10:22] mvo: it's a one line fix [10:23] mvo: this is likely the safest (going forward) fix: https://pastebin.ubuntu.com/p/bbg7hzqyyW/ [10:26] 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] that's fine [10:26] ie they set boot_mode and also snap_try_core [10:27] er, snap_mode* [10:27] probably worthwhile doing at some point, but not as part of this :) [10:27] pedronis: \o/ [10:33] Chipaca: +1, with some cosmetic nitpicks [10:34] pedronis: thanks [10:34] probably need a 2nd look from mvo again [10:34] given it changed quite a bit [10:36] 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] PR #6954: sessionagent: add a REST interface with socket activation [10:54] mvo: requested a re-review on #7142 as it's changed quite a bit [10:54] PR #7142: boot, o/snapst, o/devicest: limit knowledge of boot vars to boot [10:58] jamesh: I plan to tweak it (slightly) and land it myself at this point, either today or tomorrow [10:58] pedronis: okay. Thanks! [10:59] Chipaca: sure, will do [11:06] jamesh: also, I made a small comment and asked a question in the EnsureTreeState one, it seems super close [11:25] 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] PR snapd#6923 closed: interfaces/policy: minimal policy check for replacing sanitizeReservedFor... helpers (1/2) [11:28] pedronis: ¯\_(ツ)_/¯ [11:29] 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] jamesh: any thoughts on next steps for 7129? [11:30] mvo: one of our dependencies, github.com/ojii/gettext.go is no longer available in fedora [11:31] mvo: also they're using gopkg.in/cheggaaa/pb.v1 rather than github.com/cheggaaa/pb now [11:34] PR snapd#7121 closed: tests: part2 making tests work on ubuntu-core-18 [11:40] mup ignored me https://github.com/snapcore/snapd/pull/7129 [11:40] PR #7129: userd: allow setting default-url-scheme-handler [11:47] mvo: https://github.com/snapcore/snapd/pull/7091 is green :) [11:47] PR #7091: tests: measure properties of various mount namespaces [11:47] mborzecki: can you have a 2nd look on the test [11:47] mborzecki: I tweaked it a little [11:47] 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] 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] 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] 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] snapd#7133, snapd#7135, snapd#7136, snapd#7137, snapd#7142 [12:21] 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] 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] snapd#7133, snapd#7135, snapd#7136, snapd#7137, snapd#7142, snapd#7143 [12:29] pedronis: I can check [12:29] pedronis: I have my windows hyper-v laptop [12:38] pedronis: there are two images available in the windows gallery: 19.04 and 18.04.2 [12:38] I'll create each and let you know [12:51] PR snapd#7091 closed: tests: measure properties of various mount namespaces [12:54] PR snapd#7144 opened: tests: measure mount namespaces on Ubuntu 14.04 [13:11] PR snapd#6959 closed: osutil: add EnsureTreeState helper [13:16] Chipaca, i assume hello and hello-world havent been updated to base: core18 ? [13:17] ogra: correct [13:17] ogra: snap info tells you as much i think [13:17] right, then i guess my assumption is correct too [13:17] (and the tutorial needs fixing) [13:17] ogra: which is your assumption? [13:18] snapd wont start because the core snap doesnt exist but the hello snap is a required snap [13:18] so seeding cant complete [13:18] since a UC18 image only has core18 ... obviously [13:22] 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] jdstrand: sorry, I thought about maybe to invite but was a last minute meeting [13:24] jdstrand: also today we need to talk with foundation about the plan [13:24] PR snapd#7145 opened: packaging/fedora: github.com/cheggaaa/pb is no longer used [13:24] 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] PR #7111: many: support system-usernames for 'snap_daemon' user [13:24] PR #7112: many: allow 'system-usernames' with libseccomp > 2.4 and golang-seccomp > 0.9.0 [13:24] PR #7124: many: create system-usernames user/group if both don't exist [13:24] pedronis: no worries [13:25] I've unblocked all of them and marked for 2.441 [13:25] 2.41 [13:26] * jdstrand also has docs to write and forum posts to update [13:26] 2.44.1.441.14 [13:26] hehe [13:28] pedronis: oh, and I [13:28] 'm mashing 'Restart' for PR 7124's tests (normal intermittent non-PR related failures) [13:29] PR #7124: many: create system-usernames user/group if both don't exist [13:29] the other two have passed [13:30] mvo: https://knowyourmeme.com/memes/naruto-run [13:31] Chipaca: ta [13:32] mvo: can't have our manager falling that far behind [14:08] PR snapd#7146 opened: UC20: cmd/snap-verify: sketch of snap-verify [14:11] * cachio AFK [14:23] PR core-build#47 closed: initramfs: restore wait-for-root calls [14:40] jdstrand, hi, did you by chance manage to reproduce the issue with systemd-detect-virt not working in a VM? [14:50] ackk: in which vm? [14:50] ackk: and not working how? [14:51] Chipaca, https://bugs.launchpad.net/snapd/+bug/1831473 [14:51] (recent comments) [14:51] Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap [14:51] ackk: ah ok [14:52] ackk: for a moment i thought maybe it had something to do with systemd-detect-virt using capabilities instead of setuid [14:53] 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] ackk: I blame mvo [15:07] he's so easy to blame [15:15] ogra: not as easy as ondra though [15:16] true dat .... [15:22] Chipaca: wuut? [15:29] cwayne: don't you mean ondras [15:29] I refuse to believe there's more than one [15:42] 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] Chipaca, so you know what's going wrong, or just generically blaming mvo? :) [15:57] ackk: just generically [15:57] heh [16:14] we should really stop to naively nest test suite, we just get test duplication [16:14] I found another case [16:15] mvo: seems it's you again [16:15] pedronis: oh no [16:15] pedronis: I remember doing that recently but I thought I extracted into a baseFooSuite [16:15] pedronis: which one is it? [16:15] yes, you did that [16:15] in validate_seed_test [16:15] I fixed it [16:16] yes, you need a base suite [16:16] though in that case [16:16] it was silly [16:16] we needed 2 things [16:16] pedronis: thank you, let me check the PR to see what I did wrong [16:16] but I found another one [16:16] mvo: if you take a full suite an wrap in another check will run all the tests again [16:17] PR snapd#7132 closed: overlord,daemon,cmd/snapd: move expensive startup to dedicated StartUp methods [16:17] pedronis: indeed, where did this happen? [16:17] mvo: now I find this one: https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_set_test.go#L33 [16:17] this one is old [16:17] pedronis: oh, right - shall I fix or will you? sorry for that :( [16:18] let me see how hard it is to fix [16:18] mvo: anyway I'm mostly mentioning because is the 2nd time I see this recently [16:18] and it's a bit annoying to untangle after the fact [16:18] also slower tests [16:18] and confusing failures [16:19] pedronis: yes, sry again [16:20] seems there's a BaseSnapSuite [16:20] so maybe just a mistyping [16:20] not sure [16:20] it's old [16:21] easy fix [16:22] pedronis: let me know if I can help [16:22] no it's fine [16:22] just I was doing something unrelated that breaks many tests (shallowly) [16:22] and I was getting many double failures [16:29] 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] 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] ijohnson: for some value of top [16:32] mvo: do you have your first pass somewhere? [16:36] cwayne because one is not enough :P [16:39] pedronis: yes, one sec [16:39] pedronis, ijohnson https://github.com/CanonicalLtd/netplan/compare/master...mvo5:dbus?expand=1 [16:39] thanks mvo [16:40] yea, is the fully apply [16:40] that's what I had expected [16:41] ijohnson, pedronis why would we do something different? [16:41] 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] mvo: I was confused from the meeting, I thought it would be just to call out for restarting the services [16:42] ijohnson: no worries [16:42] ijohnson: there isn't one right now I think [16:42] ijohnson: detecting strict confinement is something we need to think about, I have no clear answer [16:43] ok, well what I've always recommended is just checking for $SNAP, so perhaps that's sufficient for netplan [16:45] ijohnson: I think so [16:45] ijohnson: as you can see in the pr this part is not done yet [16:46] 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] 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] 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] ijohnson: also no strong opinion on gio vs libsystemd for the service, I slightly prefer libsystemd [16:48] I'm not super familiar with either of them, so I'll go with whatever you prefer :-) [16:50] PR snapd#7147 opened: client,cmd/snap: stop depending on status/status-code in the JSON responses in client [16:50] PR snapcraft#2636 closed: Release changelog for 3.7 [16:50] ijohnson: heh, in this case I think you don't have to touch the C code, I think that part is done [16:50] +1 [16:50] Chipaca: #7147 is what we discussed briefly this morning (it just unblocks mentally to decide what to do in the agent PR) [16:51] PR #7147: client,cmd/snap: stop depending on status/status-code in the JSON responses in client [16:51] ijohnson: could update your forum topic to reflect better the plan [16:51] pedronis: ack [16:51] thx [16:52] 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] which part? [16:53] 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] recent prepare-image will error [16:53] if you miss one [16:53] pedronis: updated forum post [16:53] * ijohnson lunches [16:53] well, prepate-image errors if you dont explicitly seed core [16:54] core is mostly always added [16:54] not on core18 images [16:54] that's true [16:54] but then it will error [16:54] no? [16:55] my core18 builds all only have snapd, core18, gadget and kernel [16:55] ah, maybe it doesn't [16:55] but it will [16:55] ok [16:55] there's branch that is fixing some of this area [16:55] I think you are right, current code [16:55] good, so we dont need a bug the [16:55] just ignores the missing core [16:55] *then [16:56] right ... and then seeding on firstboot explodes [17:03] pedronis: uh oh https://paste.ubuntu.com/p/h369DwHwzZ/ [17:03] pedronis: snapd is crashing on me (edge) [17:08] 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] (some would perhaps say s/rotten/ripened/ :P ) [18:07] PR snapd#7148 opened: configstate: fix crash in purgeNulls [18:15] 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] like: $ MYVAR=myvalue myapp [18:16] where myapp is a snap package [18:42] ogra: jesse is the uploaded. he could request to have it removed [18:42] uploader* [18:47]