[05:09] morning [05:12] PR snapd#7282 closed: asserts: move Model to its own model.go [06:06] if `snap set core ..` will set a value, is there a command/option to show the value before without changing? [06:12] guiverc: there's snap get, try `snap get system -d` (system is an alias for core) [06:14] thanks mborzecki, appreciated.. i expected a bunch of results but only "seed".. thank you. (now I have two!) [06:30] mvo: hey [06:30] mvo: pushed a little patch to https://github.com/snapcore/snapd/pull/7288 [06:30] PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice [06:32] mborzecki: thank you [06:32] mborzecki: looking [06:33] mborzecki: are tests any happier this morning? [06:33] PR snapd#7293 closed: interfaces: k8s worker node updates - 2.41 [06:34] PR snapd#7292 closed: interfaces: k8s worker node updates [06:35] mvo: snap_daemon pops up, unless one was lucky to hit the right spread seed/job sequence [06:36] mborzecki: aha, shellecheck ! thank you [06:36] zyga: second review of 7288? [06:36] zyga: please :) [06:36] mborzecki: thanks, lets try to get the fix in then [06:36] mborzecki: or we merge sergios fix and put mine on top [06:36] mborzecki: its missing the --extrausers but otherwise is good afaict [06:36] mvo: fine either way [06:37] * mvo flips a coin [06:37] mvo: https://github.com/snapcore/snapd/pull/7166 has some unforseen consequences in spread tests [06:37] PR #7166: client: add doTimeout to http.Client{Timeout} <⛔ Blocked> [06:37] mborzecki: oh no [06:37] mborzecki: lets park it for now, it seems its full of it [06:37] mborzecki: I mean, its a snake nest [06:39] mvo: in detail tests/main/snap-network-errors fails, we try to cause a dns timeout to trigger particular error message, but we hit the context deadline earlier than that :) [06:42] PR snapd#7284 closed: tests: clean user and group for test system-usernames-install-twice [06:46] PR snapd#7291 closed: tests: add new cases into arch_test [06:49] PR snapd#7289 closed: tests: ubuntu 18.10 removed from the google-sru backend on the spread.yaml [06:52] shame that images:ubuntu/... in lxd is different, the speed we get from it is impresssssive (almost 100Mb/sec) === pstolowski|afk is now known as pstolowski [07:13] morning [07:15] mvo: ouch :( [07:16] pstolowski: good morning [07:16] pstolowski: ouch for what? [07:17] mvo: for images; and hey :) [07:17] pstolowski: heh - yes! [07:17] pstolowski: hopefully its something silly but I have no idea right now, running spread to get a machine [07:17] pstolowski: but the speed is impressive [07:18] uhm [07:18] pstolowski: hey [07:23] good late morning [07:25] mvo: that images:ubuntu is different is very eyebrow-raising [07:25] I would love to understand that more, I'll ask stephane [07:32] pedronis: just fyi, I updated the official spreadsheet with some "c" and the roadmap forum [07:32] zyga: ta [07:35] mvo: thx [07:37] pstolowski: https://github.com/snapcore/snapd/pull/7287#pullrequestreview-277252195 [07:37] PR #7287: hookstate/ctlcmd: snapctl unset command [07:38] zyga: ty [07:51] mvo: zyga: https://events.linuxfoundation.org/events/linux-security-summit-north-america-2019/program/schedule/ sadly slide deck is not available, will have to wait for videos [07:52] mvo: zyga: duh, bad link, try this https://sched.co/RHal [07:52] yeah, I noticed your interest on twitter :) [07:54] mborzecki: interessting [07:57] zyga: yeah, https://static.sched.com/hosted_files/lssna19/e5/LSS2019-Retrospective-16-9.pdf this talk in particular could be interesting [07:58] zyga: like their naming, 'research directorate' :D [07:58] we should have a research overlord [07:59] PR snapd#7294 opened: tests: trivial snapctl test cleanup [07:59] mvo: ^ a byproduct of your #7287 review ;) [07:59] PR #7287: hookstate/ctlcmd: snapctl unset command [08:07] pstolowski: heh, nice [08:07] pstolowski: thank you! [08:12] hmm [08:12] mborzecki: can you open snap-mgmt.sh.in please [08:12] mborzecki: go to line 50 [08:12] mborzecki: it says [08:12] units=$(systemctl list-unit-files --no-legend --full | grep -vF snap.mount.service || true) [08:12] mborzecki: would you expect that to produce output? [08:13] ah, sorry ignore me [08:13] * zyga is silly [08:15] zyga: hmm looking at the code, we could do better and glob unit names, though idk if the mock systemctl in 14.04 supports that [08:15] mborzecki: my problem was that it inherited "set -x" [08:15] so it was super noisy in test output and I got confused about why I'm looking at all the shell output that looked like systemctl output [08:16] zyga: right, so globbing would fix that ;) [08:16] zyga: systemctl list-unit-files --no-legend --full var-lib-snapd-snap\* [08:17] mborzecki: set +x :D [08:24] mborzecki, zyga: can you somehow figure out if we have an rpm that provdies buildrequires for golang.org/x/net (or /x/net/http2)? [08:24] on suse and fedora? [08:25] checking [08:25] mvo: probably golang-x-net-devel [08:26] mvo: actually rpm has a nice thing for that [08:27] mborzecki: nice [08:27] rpm -q --whatprovides 'golang(golang.org/x/net/http2)' [08:27] zyga: cool, what does it output for you on suse? [08:27] nothing provides it [08:27] checking fedora [08:28] zyga: meh, thats slightly sad [08:28] mvo: the nice aspect is that the golang() function takes a normal go import [08:28] mvo: that's ok, just vendor [08:28] zyga: you need to have the package instaled for that to work though [08:28] suse switched policy [08:28] zyga: we vendor on opensuse? [08:28] mborzecki: ahh [08:28] zyga: nice [08:28] mvo: yes [08:29] zyga: dnf provides 'golang(golang.org/x/net/http2)' [08:29] golang-x-net-http-devel in rawhide at least [08:30] zypper what-provides 'golang(golang.org/x/net/http2)' -> empty [08:30] mvo: fedora 29 -> ... (checking) [08:31] this may make 7285 not viable - oh well [08:31] :( [08:32] yes [08:32] :( [08:32] mvo: look https://www.irccloud.com/pastebin/qcjPShoI/ [08:33] that reminded me of gorilla PR & fedora again. onto it [08:34] zyga: thanks, so fedora seems to be fine [08:46] mvo: what is the firstboot speedup trello card about? [08:51] pstolowski: don't worry about it just yet, I tried to put people to the next tasks we need to do, its still a bit tentative. the idea for this card is that we want to do certain operations during image creation already (like hashing and puting the wrappers in place) instead of doing these expensive operations in firstboot [08:53] stgraber: it looks like the images:ubuntu/* do not have fuse installed by default so snapd will not work there (our snapfuse help dies with a confusing mount error). could those be added? (cc zyga) [08:55] mvo: thank you :) [08:57] brb [08:57] mvo: i see, makes sense. 19.10 is not too far away though ;) [08:58] zyga: makes me wonder if there's a switch for dnf that does the same as rpm -q --provides [08:59] pstolowski: yes [09:00] pstolowski: its not far and there is stuff that needs finishing first but I think its one of the next things we need to tackle :) [09:00] mvo: sounds good [09:00] hi, snapcraft question, "system-usernames" still needs to be passed via "passthrough", right? [09:01] zyga: dnf repoquery --provides golang-x-net-http-devel-0-0.53.20190622git1da14a5.fc31.noarch :P [09:07] ackk: yes [09:12] pedronis, thanks [09:13] re [09:14] needs a 2nd review https://github.com/snapcore/snapd/pull/7273 [09:14] PR #7273: gadget, overlord/devicestate: rename Position/Layout [09:16] mborzecki: found a typo in that nfs test [09:19] zyga: haha [09:19] umount vs unmount [09:19] man... [09:19] on the up side, cleanup-tool will fix that [09:19] because it will not be spelled at all [09:39] PR snapd#7295 opened: tests: spam test logs less while waiting for systemd unit to stop [09:40] PR snapd#7296 opened: tests: remove redundant activation check for snapd.socket snapd.service [10:10] mvo: shall we land https://github.com/snapcore/snapd/pull/7288 ? [10:10] PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice [10:16] + apt-key add - [10:16] + wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key [10:16] gpg: no valid OpenPGP data found. [10:16] hmmm, not a great day today [10:18] mborzecki: if it has 2 +1 yes - I saw anohter failure recently [10:19] mborzecki: I think the fix from sergio is not complete [10:19] mvo: did you see that gpg error? [10:31] zyga: I did not [10:37] PR snapd#7297 opened: cmd/snap-mgmt: set +x on startup [10:47] nfs-test is now clean on arch [10:47] nfs-support test [10:47] I also found a few minor mistakes there, all corrected now [11:16] sigh. snap downloads broken right now. [11:16] good time to have lunch [11:16] uh [11:16] Chipaca: store side? [11:16] yes [11:16] uh [11:16] ok, break time [11:16] yes [11:16] just kidding [11:16] review time [11:17] or actually I *could* go on a bike ride [11:24] zyga: https://paste.ubuntu.com/p/xYgYggB78W/ the diff is here: https://paste.ubuntu.com/p/HMxFrdjVxs/ [11:24] looking [11:25] mborzecki: something doesn't look right [11:25] the MS_SLAVE change must happen after unshare [11:26] also tabs-vs-spaces :) [11:26] mborzecki: move the /var/snap and SNAP_MOUNT_DIR changes to global setup [11:26] I think the rest is ok [11:26] mborzecki: please run the mount-ns test and see what it tells you before and after [11:27] zyga: unshare(CLONEW_NEWNS) is called before sc_setup_parallel_instance_classic_mounts() [11:27] mborzecki: also, to see what happens, always unshare for classic snaps [11:27] mborzecki: right but what setup parellel instance classic mount does is too much [11:27] the loop must be in the global setup code [11:27] well [11:28] not must but should be :) [11:28] otherwise you are making this change here after unshare [11:28] but it propagates out anyway [11:28] because / is shared [11:28] so let's be explicit and make it globally so [11:28] ah, right [11:28] ok, let me fix that [11:28] thanks! [11:28] and make sure to run that test :) [11:28] yup === ricab is now known as ricab|lunch [11:48] * zyga -> coffee [11:57] Chipaca: should we run the connectivity check in the 'before we waste spread time' part of the check? [11:58] PR snapd#7298 opened: tests: clean up after NFS tests [12:04] ok really time for that coffee [12:33] parallel installed go and node seem to work https://paste.ubuntu.com/p/jQwzJM2Bht/ [12:33] my jsfu is too low to test anything more than simple file writes though [12:35] mborzecki: where is lsof on arch? [12:35] mborzecki: I found a pair of interesting bugs in tests [12:37] ok, found it [12:37] extra/lsof [12:46] PR snapcraft#2668 closed: Restore cmake artifacts [12:47] PR snapd#7299 opened: sanity: report proper errror when fuse is needed but not available [12:47] PR snapd#7300 opened: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** [12:47] jdstrand: thanks for this one! is it the only change we need? [12:49] PR snapd#7301 opened: interfaces/network-{control,manager}: allow 'k' on /run/resolvconf/** - 2.41 [12:50] mvo: np. sorry about the kernel regression [12:50] jdstrand: no worries [12:50] mvo: curious, what is the timeline for 2.41? should I do a 2.40 PR? [12:52] PR snapcraft#2674 opened: file_utils: introduce link_or_copy_files [12:53] jdstrand: release to stable planned on sep 9, see https://forum.snapcraft.io/t/the-snapd-roadmap/1973 [12:54] mvo: you make such pretty tables :) [12:54] * jdstrand would resort to ascii art [12:55] PR snapcraft#2675 opened: docs: quick init for lxd in HACKING.md [12:56] PR snapd#7302 opened: cmd/snap-confine: add support for parallel instances of classic snaps [12:56] zyga: the code is up, we can interate on this ^^ [12:59] jdstrand, hi, thanks for the new snapd build, seems to work nicely. To confirm, that's called 2.40 but it's basicaly 2.41 right? [13:02] ackk: it is, but you should be able to use --edge now [13:02] edge, maybe beta [13:02] sorry, --beta [13:02] jdstrand, nice [13:02] ackk: https://forum.snapcraft.io/t/the-snapd-roadmap/1973 [13:02] yeah I was just looking at that :) [13:03] probably both actually (I see today that edge has the properly version) [13:03] jdstrand, is the snap_daemon user created by the deb or snapd itself? IOW do we need the 2.41 deb to be in bionic to get that, or will the beta snap do it? [13:04] mvo: 2.5 weeks might be a little too long for robertliu on that bug. we might need an out of band snapd build with that cherrypick. please advise. [13:04] PR snapd#7294 closed: tests: trivial snapctl test cleanup [13:04] mvo: there is a possibility that there could be another similar bug or two, but I don't think many [13:04] ackk: it is created by snapd [13:05] jdstrand, oh cool, so on a clean bionic install snap install snapd --beta should be all we need? [13:05] ackk: this will work with just beta and on core [13:05] ackk: yep [13:05] awesome [13:05] * ackk gives that a spin [13:07] # snap install --beta snapd [13:07] error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet [13:07] jdstrand, ^ but I have core18 installed [13:07] I guess I need "core" as well? [13:07] mvo: not many because as I said in the bug, all the interfaces have been run through later kernels. in this NM case, the NM 1.2 snap on uc16 did something different than the 1.10 snap. I don't think there are going to be a lot of these [13:08] ackk: on bionic, just 'core' [13:10] ackk: afaik, bionic won't reexec into the snapd snap yet. (also, looking at snap info snapd, edge and beta appear to be new enough, though report 2.40 still) [13:11] jdstrand, I think it does if you have the latest deb? [13:12] jdstrand: good, thank you [13:13] ackk: that is a question for others here [13:14] mvo: do you want a 2.40 PR? [13:14] jdstrand: its fine, I can cherry pick there [13:14] jdstrand: I hope there will no 2.40 point release though [13:15] jdstrand, so I'm confused, on bionic do I just install core or core + snapd --beta? [13:15] mvo: do you require a point release for a hotfix? (not sure what you would call that). I'm a little concerned since it is network-manager we need that [13:15] ackk: all I did in my testing was the deb in the archive and core --beta [13:16] jdstrand, oh ok cool [13:16] thanks [13:16] ackk: if you have the snapd snap installed, then I guess you could try a newer one of it, but someone else would need to comment [13:17] jdstrand, yeah my next question was indeed, if you have both core and snapd, which snapd is being re-exec'd ? [13:19] mvo: anyhoo, let me know if you need anything. since you are reading this, could you comment on ackk's question? [13:21] mborzecki: review sent [13:21] zyga: thx [13:24] PR snapd#7296 closed: tests: remove redundant activation check for snapd.socket snapd.service === ricab|lunch is now known as ricab [13:27] jdstrand: could you look at https://github.com/snapcore/snapd/pull/7205 please [13:27] it's just a RFC, 12 lines of code [13:27] PR #7205: rfc: introduce confinement options failsafe flag [13:27] jdstrand, will beta be versioned 2.41 at some point, or just at release? [13:28] ackk: that would be another question for mvo [13:28] jdstrand, he, sorry [13:28] ackk: the fact that snap info show it as 2.41, I would expect snap version to be the same [13:28] I see 2.40 in snap info snapd" [13:29] jdstrand, also snap version reports 2.40 [13:29] zyga: I could destroy as system in less than that ;) [13:29] s/as/a/ [13:29] jdstrand: I know you could, but I can only propose a small RFC :D [13:30] I thought I looked at this already... [13:30] jdstrand: perhaps at the sprint [13:30] yeah, I didn't publicly comment apparently [13:31] ackk: its a bug, its on my list, next beta for the snapd snap should have a 2.41~preN version again [13:31] jdstrand: thank you [13:31] mvo: can you describe when reexec happens wrt the deb, core, core18 and the snapd snap? [13:31] mvo: in this case bionic, but also generally [13:32] mvo, ah, awesom thanks. I take that means that "assumes: [snapd2.41]" will work at that point? [13:32] * jdstrand doesn't know either, but should [13:32] jdstrand: re-exec will check the version and use semantic version compare to decide if it should re-exec [13:35] mvo: so it knows to check all of core, core18 and snapd snaps? [13:36] that was the bit I wasn't sure of. I've only ever personally worked with core [13:42] I thought if the snap has a base: declaration, the snapd snap was used instead [13:44] mborzecki: https://github.com/snapcore/snapd/pull/7298 is green [13:44] PR #7298: tests: clean up after NFS tests [13:44] mvo: if you could review I would be 50% closer to green classic mount table [13:52] zyga: ok, I see what I can do [14:29] * zyga is having lunch [14:32] mborzecki: can you review https://github.com/snapcore/snapd/pull/7290 please [14:32] PR #7290: tests: allow test user XDG_RUNTIME_DIR to phase out [14:34] * Chipaca thinks he found the bug and is as happy as a partridge [14:35] * Chipaca suspects "feliz como perdiz" does not translate well === ubott2 is now known as ubottu [14:52] PR snapd#7303 opened: Allow reading an Xwayland Xauth file. Fixes LP: #1840925 [14:53] jdstrand, your opinion welcome on the above ^ [15:28] PR snapd#7304 opened: many: move channel parsing to snap/channel [15:29] Chipaca: that's probably something for you to review ^ [15:31] pedronis: tag me for it please [15:35] just adding unit tests for the bits that broke the world :-) [15:37] it was: when you have a model, and the model has a base that is not "core", and you install "core", the new code tried to setnextboot to it [15:37] which was a lot of fun [15:38] Chipaca: the code tried to change next boot to core? i [15:38] the tests were broken because they tested a snap that was called "core" but was type snap.TypeBase [15:38] which is not the type of "core" in the wild :-) [15:38] mvo: the new code [15:38] Chipaca: aha, ok [15:38] Chipaca: puhh, I was concerned :) [15:38] Chipaca: thanks for tracking this down! [15:39] and while doing that i've thought of ways to make it simpler, but at this point it'll probably be a sneaky followup [15:40] also, i've got a fix for a bug in download i need to push [15:40] also also i need a break [15:40] * Chipaca breaks [15:40] wrt bug in download: https://forum.snapcraft.io/t/snaps-download-should-be-resumable/3561/11?u=chipaca and down [15:40] * Chipaca really breaks [15:50] PR snapd#7305 opened: check-pr-title.py: allow {} in pr prefix [15:59] hey mvo, since git blame says you last touched TestInstallDefaultProviderRunThrough, should the order of the ops in the fake ops be deterministic? The test seems to expect that, but I am getting different ordering of the ops every time I run [16:00] all I changed was I added new ops when my additional backend methods run, but those are always in the same relative positions [16:00] (need to step out for a couple minutes, but we can also discuss tomorrow during SU if it's near your EOD too) [16:01] ijohnson: I'm near EOD sry but also slightly puzzled, this test runs all the time so if its not deterministic must be causing this (I probably lack context) [16:02] okay, np I'll dig deeper later this afternoon and we can sync up on it tomorrow [16:02] ijohnson: you said you are adding ops? [16:02] if you are missing wait between tasks [16:02] to the fake ops in the fakeSnappyBackend [16:02] you might get out of order stuff [16:02] hmm [16:02] ijohnson: if you're getting ops in random order, it usually means some of the tasks are not chained up properly (WaitFor etc); are you touching task creating code as well? [16:02] ^ this [16:03] it's possible I'm missing those, but I'm not creating actual Task structs, just additional ops in the fakeSnappyBackend to track what was called [16:03] just like f.appendOp(&fakeOp{...}} [16:03] * ijohnson will be back in a little bit [16:05] ijohnson: hard to tell without more context.. maybe create a draft of your PR so I can take a look [16:19] ijohnson: eod here.. if you won't figure this out i can look at this tomorrow morning [16:19] * pstolowski pstolowski|afk [16:19] PR snapd#7306 opened: overlord/configstate: sort patch keys to have deterministic order with snap set [16:41] pstolowski: https://github.com/snapcore/snapd/pull/7306#pullrequestreview-277924024 [16:41] PR #7306: overlord/configstate: sort patch keys to have deterministic order with snap set [16:47] pstolowski: if I can't figure it out by my EOD I'll push up the changes to my PR and add a comment there explaining it [16:47] * pedronis dinner [17:03] mvo: https://github.com/snapcore/snapd/pull/7288/files#r316296747 [17:03] PR #7288: tests: cleanup "snap_daemon" user in system-usernames-install-twice