[02:02] PR snapcraft#2258 closed: build providers: snapcraft images for multipass [02:05] PR snapcraft#2256 closed: local source: don't include .snapcraft directory [02:40] leeloo dallas multipass [02:56] one of the posts on the forum says that fine-grained network mediation is on the snapcraft roadmap; does anyone know where the proprosal for this is? [03:57] https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588 [03:57] * Doctor_Nick shakes head sadly [03:57] Bug #796588: Fine-grained network mediation

[04:47] Good morning === pbek_ is now known as pbek [04:47] There is a power outage here. I only have my laptop and phone [04:48] Some phases are being turned on and off so I’ll leave my desktop off for now [04:48] Some phases are being turned on and off so I’ll leave my desktop off for now [05:06] morning [05:08] Hey [05:21] zyga: wow, got +1 on mount mappings PR, would you like to do another pass there? [05:21] yeah [05:21] just breakfasting [05:22] zyga: wonder if i should pester jdstrand for review there as well [05:23] mborzecki: I think Jamie will be back today or perhaps tomorrow [05:23] mborzecki: I'll be back soon, there was a power outage last night and I'll work from my laptop doing reviews more than anything [05:23] zyga: oh, was there a thunderstorm or sth? [05:33] no idea [05:33] whole street went dark [05:33] around after 1AM [05:33] I was brushing my teeth when it happened [05:33] some parts of AC returned at 3-4AM [05:35] zyga: maybe it was planned shutdown :) [05:35] it broke my print :( [05:35] it's going to be another 9 hours [05:36] zyga: printing weapons of mass destruction? [05:36] companion cubes :) [05:36] hahah [05:36] damn, don't remember the last time i played portal [05:37] I was printing calibration cubes [05:38] of increasing size [05:38] oh and power is out again [05:38] I just switched to LTE from my laptop [05:38] man... [05:38] I want to see if Z axis is stable [05:38] and if there is any wobbling on the printer bed that causes layer misalignment as the print continues [05:55] heh, some PRs failed yesterday either getting go packages from github or poking the snap store, must have been an outage at some cloud provider [06:00] zyga: shoud i review #5802 or #5805 first? [06:00] PR #5802: cmd/snap-update-ns: introduce trespassing state tracking [06:00] PR #5805: cmd/snap-update-ns: enforce trespassing checks [06:11] Mmmm [06:12] 5802 please [06:12] I’ll get to reviews in a moment, my wife forgot her phone to work [06:12] yeah, that'll be handy for debugging [06:30] re, still on LTE but some phases are back so my computer is up :) [06:31] mborzecki: which PRs are best to review first? [06:31] zyga: mine? [06:32] heh - s/mine?/mine!!!/ ;) [06:32] mvo: hey [06:32] hey mborzecki [06:32] for me github is super slow and right now timing out :/ [06:32] mvo: that's about right :) [06:32] mborzecki: yes [06:33] hey mvo :) [06:33] mvo: at least you have power :D [06:33] mvo: had 5570 stuck in build pending status, but the travis job was already green [06:33] I spent way too much time last night on selinux [06:33] but I think I'm making progress [06:33] I'll do reviews today and respond to feedback [06:33] mborzecki: aha, let me look (or try to :) [06:33] but I will try to fix some selinux issues [06:33] mvo: restarted it already [06:33] mborzecki: if its green I can override it [06:34] zyga: i only have 2 other prs, #5770, #5785, independent of each other, pick whichever [06:34] PR #5770: many: provide salt for generating instance-key in store requests [06:34] PR #5785: tests,interfaces: run interfaces-account-control on UC18 [06:35] PR snapd#5632 closed: overlord: integrate device enumeration with udev monitor [06:35] mvo: #5808 also failed because of github/store connectivity issues, i've restarted it earlier [06:35] PR #5808: snapd-env-generator: fix when PATH is empty or unset [06:35] mborzecki: cool, thanks for this [06:36] mborzecki: thanks [06:37] mvo: since you commented on both 5770, 5785, could you take another look? [06:37] btw. snap list --all bails with parallel installed snaps :P [06:38] mborzecki: bails? [06:38] what does it do [06:39] zyga: probably some bad globbing, all you get is https://paste.ubuntu.com/p/TqWXGDFNrJ/ [06:39] ah [06:39] it tries to find snap by name [06:39] it's actually poking an incorrect path [06:39] but ignoring the instance name [06:39] that's ... odd :) [06:39] well [06:39] yup [06:39] power is back! [06:39] fix coming up soon [06:40] I restarted my printer, 9 hours left :( [06:40] mborzecki: 5785 looks like its not from you [06:40] mvo: 5758, sorry :) [06:43] mborzecki: sure, looking === pstolowski|afk is now known as pstolowski [07:12] morning [07:12] all right, the parallel installs integration branch has been update with all the PRs so far, the travis job should still be green [07:12] pstolowski: hey [07:13] mborzecki: sorry for making the 2nd branch so big btw [07:14] mborzecki: it's tad scary at 1K2 [07:14] mborzecki: but at the same time it shows what it takes to lug that state around; maybe there is a better way? [07:15] zyga: once 5802 lands the other one should 'appear' smaller, right? [07:15] yes [07:16] wish there was a mode in gh where you can view the diff against some other PR [07:17] i suppose you can fiddle with the url directly, but that's quite inconvenient [07:18] yeah [07:18] LP had that feature [07:27] https://github.com/snapcore/snapd/pull/5808 doesn't want to get geen [07:27] green* [07:27] PR #5808: snapd-env-generator: fix when PATH is empty or unset [07:45] mborzecki: some small comment to #5770 [07:45] PR #5770: many: provide salt for generating instance-key in store requests [07:47] pedronis: thanks, looking [07:52] mborzecki: yeah, I like the suggestion of pedronis. its probably me overthinking things, but the fact that we added "salt" felt to me like we make a strong promise about the "strength" of the hash we send to the store. i.e. before it was just a way to sort things, now we protect it actively. I did some back of the envelope calculations and I think we should be fine with the 16 char secret, for peace of mind I would even up [07:52] it to 32 but then we should be really fine [07:55] mvo: refresh-privacy-key sounds good to me too, naming is hard heh :) [07:56] mborzecki: it totally is [07:56] mborzecki: thank you, I like this name too [07:57] pedronis: if you could re-review 5803 that would be great (its the content provider hang fix) [07:58] in a sec [08:01] pedronis: no rush, the tests are unhappy anyway :/ [08:03] zyga: going over your tresspassing PR and asking some naive questions [08:03] sure [08:03] thank you! [08:05] hmmm [08:05] go crashes on "go build" [08:06] not something I wanted to see in the morning [08:06] it crashes in osutil [08:06] on golang 1.11 [08:06] ah, wait on 1.10.1 [08:15] Mornings [08:15] hey :) [08:15] mborzecki: Something is not quite right with the "system" alias on the interfaces command [08:15] mborzecki: "snap info core" stopped working on my machine [08:16] Sorry, not info [08:16] interfaecs [08:16] niemeyer: o/ [08:16] pstolowski, zyga: Heyas [08:16] niemeyer: we're discussing that just now [08:16] niemeyer: my hunch is that's the remapping that was added in 2.35 and daemon now knowing if client is aware of the change [08:16] zyga: ^^ [08:17] zyga: Where? [08:17] zyga: Don't see it [08:17] the "snap interface core" stopped working beause the response is "system:..." and the filtering is done client side [08:17] niemeyer: in the internal channel [08:19] mvo: got FAIL: snapstate_test.go:10921: snapmgrTestSuite.TestInstallDefaultProviderRunThrough after running the tests in a loop for ~1h locally [08:19] mborzecki: So, we need to do something about this.. [08:19] mvo: investigating it this morning [08:19] mvo: +1 with some nitpicks [08:20] mborzecki: We should probably wait until tomorrow as I have a call with them in my late afternoon, so will be able to tell in more detail what else we need, but we definitely need to fix the behavior of "snap interfaces core" [08:21] pstolowski: nice, thanks for finding this [08:21] mvo: well, i haven't found the cause yet :) [08:21] We originally had some logic that would detect whether the query was made for core, and if so keep the name untouched [08:22] pstolowski: heh, thanks for "almost-finding" this then ,) [08:34] niemeyer: we could make snap interfaces always show the actual snap [08:34] ie not do the core/core18/fedoracore/snapd -> system translation on the way out [08:34] core-fedora? fedore? [08:34] Chipaca: Yeah, I think we should always present the actual name if people requested for that specific name [08:35] Chipaca: Not sure if that's their issue, though.. that's why I'd like to talk to them first [08:35] niemeyer: i meant in /v2/interfaces directly [08:35] niemeyer: agreed, totally [08:35] we've had too much run-around-and-fix-it due to chinese whispers [08:36] Chipaca: Right, also mean /v2/interfaces directly [08:37] niemeyer: in /v2/interfaces, without specifying any select parameter, you get a list of stuff that talks about "system" [08:37] (this is the legacy interfaces listing) [08:44] eeenteresting: https://code.visualstudio.com/blogs/2018/09/10/introducing-github-pullrequests [08:45] Chipaca: Ah, okay.. so you mean having interfaces never return the alias [08:45] Chipaca: Sure, that's the revert option [08:45] Chipaca: We may need to do that depending on how bad their issue is [08:45] niemeyer: … at least the legacy one [08:45] Yeah [08:46] niemeyer: so if we find out they're not using select=, we can do that and not touch the new [08:46] anyhow, back to coding for me [08:47] (shout for reviews) [08:47] Chipaca: Or we just finish that new command [08:47] ("connections") [08:47] niemeyer: I suspect they're talking to the socket [08:49] gopkg.in is down, btw [08:49] Well, it's not down.. [08:49] GitHub is blocking it [08:49] So if anyone has a good contact there, please let me know [08:49] niemeyer: you could say Microsoft is blocking it, to make it sound more ominous (to me) [08:50] Chipaca: It's a bit ironic indeed, to be honest [08:50] It's running for 4 years now [08:50] the empire is blockading it? [08:50] we need rogue one [08:51] hey all, while working on the mir-kiosk tutorials we stepped on a mine of sorts, we have a race between mir-kiosk starting and creating the wayland socket and the app starting and being able to connect to it, what would you say would be the right solution across snaps? obvious one is a loop+timeout in a wrapper, but every app out there would need to include one, is there anything better do you think? [08:51] both mir-kiosk and the kiosk app are snap daemons with restart-condition: always, but systemd bails on the app if it restarts too quickly anyway [08:52] PR snapd#5810 opened: rfc: restore "core" as the API-level host for implicit slots [08:53] Saviq: hmm! [08:53] Saviq: socket activation :) [08:54] zyga: are they in the same snap? [08:54] but it's tricky unless the socket is in a public space like /var/lib/snapd/$SNAP_NAME/common [08:54] um [08:54] Saviq: are they in the same snap? [08:54] Chipaca: socket activation would work in all cases [08:55] no, separate snaps [08:56] zyga: if they were in the same snap, Before= would do the trick [08:56] but we'd need to make mir-kiosk socket-activatable... but you're right that does sound like the right approach [08:56] Chipaca: perhaps, only if the snaps also use sd notify [08:56] Chipaca: otherwise the socket may not be ready for real [08:56] zyga: yup [08:57] Saviq: another thing we could do [08:57] Saviq: is expose RestartSec [08:58] Saviq: you could try to see if that'd do the trick; it's how long to sleep before actually restarting [08:58] yeah that would work, but the "we could expose" part is a bit scary in terms of timelines ;) [08:59] Saviq: agreed :-) [08:59] I think it might actually be easier to make mir-kiosk socket-activatable [08:59] Saviq: you can fake restartsec by adding 'sleep 1' to the top of your wrapper script though [08:59] Saviq: which is a lot easier than checking the socket in there :-) [08:59] indeed :) [09:00] Saviq: the default sleep is 100ms which is probably too low for anything involved, anyway [09:00] Saviq: mir-kiosk is c++, yes? [09:01] Chipaca: yes [09:01] well, *mir* is, mir-kiosk is just a wrapper around it [09:01] does gopkg.in has issues or is it github? [09:02] /o\ it's wrappers all the way down [09:02] :D [09:02] mborzecki: I see gopkg.in down [09:02] mborzecki: https://mobile.twitter.com/gniemeyer/status/1039433916019613696 [09:02] Chipaca: really it's just startup scripts [09:02] that don't really fit in mir proper [09:03] Saviq: but to make it socket-activatable you'd have to make mir itself be socket-activatable [09:03] ? [09:03] yes [09:03] Chipaca: zyga: thx [09:03] which should be easy, as far I can tell [09:03] just "if systemd gives you a socket, use it; otherwise create your own" [09:04] Saviq: yep, there's example code (in C) for how to cover some corner cases well [09:04] Saviq: http://0pointer.de/blog/projects/socket-activation.html [09:05] Saviq: example 3 (at the bottom) [09:05] yeah that's what I was looking at [09:05] Chipaca: we just have to use de-vendorized packages while github and gopkg.in is down ;) [09:06] zyga: brb devendorizing self [09:09] chipa.ca/internal/organs ;) [09:10] * Chipaca cannot get chipa.ca [09:10] I don't understand myself either sometimes [09:11] zyga: no, i mean, i need to be a canadian business to buy chipa.ca [09:12] mvo: dunno if you saw https://forum.snapcraft.io/t/snapctl-not-found-in-base-core18-snaps-hooks/7297 [09:14] launchpad is not responding to post requests for me [09:17] Chipaca: I saw it but it not fully read it yet [09:18] Chipaca: I suspect this is a problem with stable [09:18] Chipaca: stable core18 [09:19] mvo: I checked on edge [09:19] Chipaca: oh, you did - ok [09:19] mvo: no snapd installed, snapctl is dangling [09:19] no snapd snap i mean [09:19] how does that work, a symlink ? [09:19] yep [09:19] Chipaca: oh course [09:19] did we break snap-confine binding [09:19] of those things? [09:19] mvo: in fact i can't install snapd :-) [09:20] because i'm not a gadget with a model or sth [09:20] ah [09:20] core18 expects them to come from snapd [09:20] pedronis: dunno [09:20] but here it's core and core18 [09:20] fun [09:20] ye [09:20] (too many moving parts problem) [09:20] yes [09:20] (not enough tests) [09:20] it's bind-mountingn the directory from core (i assume) and that's missing snapctl [09:21] Chipaca: which is odd, we move it there a while ago [09:21] Chipaca: when I ls /usr/lib/snapd/snapctl I see it [09:21] Chipaca: but nevermind, I will write a spread test [09:22] Chipaca: for this case and that will give us a) an answer b) a regression test [09:22] pedronis: about the missing restores in snapstate, I'm working on a PR for this [09:22] pedronis, pstolowski: This is repeating ad-infinitum here: [09:22] mvo: I'm not sure they are needed to be honest [09:22] 2018-09-11T09:21:52Z INFO auto-connect of snap "gopkg" will be retried because of "gopkg" - "core" conflict [09:22] mvo: true, I can see it there in core [09:22] dunno what's going on [09:22] Command was [09:22] snap install ~niemeyer/gopkg_2018.03.27_amd64.snap --dangerous [09:23] pedronis: oh, right - we may set on in SetUpTest [09:23] pedronis: let me double check that [09:23] the mock is strange [09:23] because the style is a bit different around those tests [09:23] niemeyer: is that pulling in core as well? [09:23] pedronis: Yeah [09:24] is not sorted [09:24] gopkg was scheduled before core [09:24] Yeah [09:24] pedronis: The strange thing is that core did finish [09:24] ah [09:24] then it's bizarre [09:24] pedronis: and even then gopkg couldn't get installed [09:24] Just kept retrying [09:25] pedronis: We really need those conflict improvements :( [09:25] installing core independently works of course [09:25] a bit unclear why if core finished is still waiting [09:25] that seems trange [09:26] pedronis: happy to make it less strange, I just need some more details what concerns you (not urgent) [09:26] Anyone familiar with core18 kind of stuff? Does https://bugs.launchpad.net/launchpad-buildd/+bug/1791907 sound like a plausible diagnosis from me? [09:26] Bug #1791907: Cannot build base snaps [09:26] mvo: just that having a full mock function seems overkill [09:26] if we never restore anway [09:27] pedronis: Yeah, and it retried every 5 secs [09:27] pedronis: I just looked and I think we should restore, we don't mock in SetUpTest so this is currently leaking [09:27] Suspect that's easy to reproduce [09:27] mvo: no, the problem is that the style is mixed [09:27] pedronis: otoh I can do a "SetModel" and use that in SetupTest and in the tests without a restore [09:28] mvo: really mockModel are th odd ones [09:28] pstolowski: Can you dig into that please? It's closely related to the bits you're touching, and worked fine until recently [09:28] pstolowski: SHould be easy to reproduce.. the local snap file just had network and network-bind plugs [09:28] No other interfaces [09:29] niemeyer: yes, looking [09:29] mvo: yes, SetModel would be more in style [09:29] pedronis: ok, so SetModel() and no restore? happy to do that [09:30] mvo: again snapstate_test.go is probably getting too big [09:30] pedronis: what can we do about it? splitting it into more logical chunks? [09:31] maybe [09:31] but yeah, its gigantic :/ [09:32] it's doing odd things [09:32] pedronis: I will attack the snapctl on core18 issue now, then look at missing content provider warnings and then I should have time for the SetModel cleanup [09:32] like having a suite in the middle of another for example [09:32] pedronis: what odd things in particular? [09:32] pstolowski: hey, I replied to your comments on the PR [09:32] pedronis: right [09:32] just a sign it's hard to navigate in it [09:32] zyga: k thx [09:32] pedronis: +1 [09:33] mvo: anyway, I think the style there atm is no Mock if the value is a function that is originally nil, just put it back to nil in TearDown [09:34] pedronis: +1 [09:35] mvo: this is fun: grep "Suite)" snapstate_test.go, you can see the suites mixed [09:37] :/ indeed [09:38] mvo: snapstate_test.go api_test.go and store_test.go are the largest files [09:38] in that order (descending) [09:41] niemeyer: should this guy put your name in that field? https://github.com/snapcore/snapd/pull/5799#issuecomment-420201428 [09:41] PR #5799: Install snap-failure binary on Fedora [09:46] mborzecki: Yeah, that's fine [09:59] mborzecki: Eldar just signed it [09:59] niemeyer: yup, he posted a note in github too [10:11] PR snapd#5811 opened: tests: add test that runs snapctl with a core18 snap [10:17] * Chipaca wonders why the rabbits look so tasty, down their rabbitholes [10:17] who's in charge of building the docker images? [10:17] snapcraft* [10:17] snapcraft docker images* [10:17] diddledan: no idea [10:18] hmm, I don't know what I can do to help this person then: https://forum.snapcraft.io/t/permission-denied-when-building-with-snapcore-snapcraft/7186/20 [10:19] seems the :stable tagged image can't build desktop app snaps (cannot find the desktop-launch script when it has definitely been placed into prime) and the :latest image doesn't include a fix that the person is needing [10:20] PR snapd#5812 opened: snapstate: refactor tests to use SetModel* [10:20] Phew.. [10:20] gopkg.in is back up now.. GH debugged the issue on their end and deployed changes to fix it [10:20] It doesn't look like it was actual firewalling [10:21] niemeyer: go forth and pkg in! [10:21] diddledan: Forth is a bit strange, but quite a unique and interesting language :) [10:21] haha [10:22] I've never seen forth code I think [10:23] niemeyer: sometime, when you're needinig a break, give Wizard's Bane a read [10:29] mborzecki: doing one more pass on https://github.com/snapcore/snapd/pull/5713/files [10:29] PR #5713: many: mount namespace mapping for parallel installs of snaps

[10:29] but first, more coffee - I'm feeling awake now [10:29] zyga: thanks [10:29] niemeyer: so far unsuccessful in reproducing the issue you observed - i tested on a clean xenial with custom snapd (current trunk) and no core, then snap install --dangerous mytestsnap (it has network and network-bind plugs; core gets installed, they get autoconnected). were you testing this on cosmic? [10:30]