[02:41] PR snapcraft#2089 closed: many: remove support for remote lxd per project containers [03:02] PR snapcraft#2091 closed: meta: soften warning about using passthrough [04:40] good morning [04:47] * zyga notices https://github.com/apple/foundationdb/ [05:13] morning [05:31] hey hey [06:01] google cloud packages repo for fedora had their gpg keys change [06:01] i'm testing a fix [06:15] thanks [06:15] * zyga had a rough morning with upset daugher [06:15] daughter [06:17] PR snapd#5076 opened: spread: auto accept key changes when calling dnf makecache [06:17] zyga: i've resarted the build in #5074, it failed synchronizing fedora repo [06:17] PR #5074: interfaces/apparmor: add test case for tricky writable mimic [06:17] mborzecki: ah, it's not ready yet [06:17] that's all right [06:17] I will force push a full fix and tests on top [06:18] ok === pstolowski|afk is now known as pstolowski [07:20] mornings [07:26] morning o/ [07:26] #5072 needs a 2nd review [07:26] PR #5072: snap,overlord/snapstate: introduce and use BrokenSnapError [08:04] * zyga keeps fighting the bug that pawel found [08:07] zyga: new one? [08:07] no, still the same one [08:07] it's just tricky to get the rules right [08:07] I know what I'm missing [08:07] but iteration is a bit painful [08:11] m-v-o is off today? [08:11] pedronis: yes [08:11] he said he'd be off yesterday IIC [08:11] IIRC [08:12] ye [08:12] s [08:12] yesteray he said he'd be off today and monday [08:12] ah, ok [08:12] thx [08:17] PR snapd#5072 closed: snap,overlord/snapstate: introduce and use BrokenSnapError [08:17] zyga: merged ^ [08:17] nice, thank you! [08:17] so one less "snap try" bug [08:18] I think there are some other places that may need similar changes [08:18] like there's ReadInfo that takes a container [08:18] it has the same issues [08:18] I'm not sure Broken and Error should have the same value (we have more context when we use Broken but we can revisit later) [08:18] zyga: we use it in much more precise contexts [08:18] usually before we are installing something [08:18] so we want the errors [08:19] mmm, [08:19] it's not clear that one will fail while the other will not [08:19] ? [08:19] I mean, from reading the documentation and function name [08:19] it's error prone [08:19] they both fail [08:19] you didn't make not fail [08:19] yes but one returns different errors than the other [08:20] sorry, I said that in a confusing way [08:20] the code is almost the same but the error values are not [08:20] one is about the installed snaps [08:20] maybe the error name, comment is not quite right [08:21] ReadInfo reads the snap information for the *installed* snap ... that's always been documented like that [08:22] but yes, BrokenSnapError doc is a bit insufficient [08:24] it seems snap/info.go needs a general doc review, some comments are out of date [08:24] yes, I agree [08:24] like I see a mention of File that doesn't exist anymore [08:24] i think i'm doing the whole system-nickname-core wrong, i did a change to replace core with system in data returned by /v2/interfaces endpoint, but that feels wrong, if one is using this api endpoint then the data returned would change, but there would no change in api version [08:25] yes, not sure we can do that [08:25] not sure if a lot of external parties are using interfaces though [08:25] on the other hand [08:25] instead should probably only accept system as nickname for core, and do the right thing as if 'core' was passed [08:25] we are doing the new connections work [08:26] and snap interfaces is going away [08:26] so maybe we need to do it only in the new stuff [08:27] zyga: I mean a not to look at snap/info.go docs at some point [08:27] *a note [08:27] ack [08:28] pedronis: hey, quick question wrt to what Gustavo asked in the interface hooks review about deny-auto-connection and deny-connection; i see them consistently used in majority of base decls, so I presume they are not denied by default? [08:28] pedronis: so maybe this, on POST to /v2/interfaces dealias system to core, but when you just query the interfaces, at the client side, present core as system by default, unless someone asked for 'core' specifically [08:28] pstolowski: the deny-connection bit is a bit strange, given is a test interface we probably don't want auto-connect though [08:29] pstolowski: it's a bit unclear though given it's a test interface [08:29] so the output of the endpoints does not change, it still accepts the 'nickname', and a new client can act accordingly to user's query [08:32] pstolowski: basically I don't think you want the deny-connection bit [08:33] pstolowski: it's saying that it cannot be connect on core, but can be connected on classic [08:34] pedronis: right. indeed, it doesn't make sense to deny that [08:46] I have to go to school, sorry, daughter is trouble today [08:48] must be the weather [08:55] damn, when running daemon unit tests, 3 tests fail, if I run them separately, they all pass, something not cleaned up in teardown [08:58] _unit_ tests [08:58] wat [08:58] (granted the daemon unit tests are the worst) [08:59] Chipaca: daemon/api, exactly what i'm working on right now [08:59] mborzecki: i'm so sorry [09:02] it all started when i started mocking 'core' snap in one of the tests, new it's special but didn't expect this [09:02] s/new/knew/ [09:19] re [09:25] shouldn't https://github.com/snapcore/snapd/blob/master/daemon/api_test.go#L3498 be cleaned up? [09:29] there's no way atm, it could [09:31] pedronis: added this https://paste.ubuntu.com/p/9z58cTd53S/ and a corresponding call in api tests, so far it's not failing anymore [09:34] * Chipaca goes afk [09:38] * Chipaca returns [09:48] niemeyer: i've addressed your comments to interface hooks, with one open question; thanks for the review! [10:05] gah [10:05] darn [10:05] I need to think [10:05] this apparmor rule issue is terrible [10:11] zyga: which one? the xmas tree? [10:11] yes [10:12] oh [10:12] * pstolowski is going for a walk [10:13] zyga: see what you did :) [10:14] I would love to go for a walk myself [10:14] but I have to crack this issue [10:14] poor chap couldn't stand being reminded of that rule [10:19] PR snapd#5076 closed: spread: auto accept key changes when calling dnf makecache [10:35] * zyga -> break for pen&paper debugging [10:43] chop tree test https://www.irccloud.com/pastebin/t1Vah68j/ [10:44] jdstrand: hey [11:02] Chipaca, mborzecki: can you please review https://github.com/snapcore/snapd/pull/3963 [11:02] PR #3963: cmd/snap-confine: add support for per-user mounts [11:02] it's got two +1s [11:02] but is important enough for extra reviews [11:03] zyga: lunch now, meeting after, then standup, then school run, so … after that? [11:03] sure [11:03] k [11:16] zyga, ogra@acheron:~$ snap run snapcraft-forum [11:16] cannot change profile for the next exec call: No such file or directory [11:16] snap-update-ns failed with code 1: No such file or directory [11:16] ogra@acheron:~$ snapcraft-forum [11:16] cannot change profile for the next exec call: No such file or directory [11:16] snap-update-ns failed with code 1: No such file or directory [11:16] ogra@acheron:~$ [11:17] ogra_: hey, what is snap version? [11:17] (after a reboot on 16.04 ... whats going on there (other snaps seem to start though) [11:17] ls /var/lib/snapd/apparmor/profiles [11:17] ogra@acheron:~$ snap version [11:17] snap 2.32.3 [11:17] snapd 2.32.3 [11:17] series 16 [11:17] ubuntu 16.04 [11:17] kernel 4.13.0-38-generic [11:17] sudo cat /sys/kernel/security/apparmor/profiles [11:17] update to .5 (beta) and see if this is fixing it [11:18] https://paste.ubuntu.com/p/fTz2QFW3wZ/ [11:18] ... refreshing ... [11:18] ogra_: what is snapcraft-forum [11:18] and why don't you have profiles for it [11:18] is it active? [11:18] is it mounted? [11:19] its a sideloaded electron snap for the forum [11:19] nothing fancy about it beyond that [11:19] mmm [11:19] you don't have any profiles for it [11:19] is it "snap try" [11:19] (same snap runs fine on my desktop that i also rebooted today with latest updates) [11:20] no, its just a sideloaded snap .. hasnt changed for 4-5 months, used daily [11:20] is it in /var/lib/snapd/snaps [11:20] zyga, beta fxes it [11:20] and is it listed in 'snap list'? [11:20] indeed it is [11:20] hmm [11:20] reboot a few times to see if this happens [11:20] and it starts fine now with beta [11:20] I don't know why we'd _not_ show that snap [11:20] yeah because beta update regenerated profiles [11:21] but why was it missing? [11:21] can you show your snap changes? [11:21] om26er: just fyi, sublime-text grew from zero users to over a thousand pretty much overnight [11:21] i really cant reboot a few times now (thats always some effort to bring my scripts back up etc ... and i'm busy implementing fulld-disk-encryption) [11:21] popey: wow :D [11:21] om26er: dunno if you did any marketing, but we didn't [11:21] that's pretty neat [11:21] ogra@acheron:~$ snap changes [11:21] ID Status Spawn Ready Summary [11:21] 201 Done 2018-04-19T12:48:57Z 2018-04-19T12:49:01Z Auto-refresh snap "snapcraft" [11:21] 202 Done 2018-04-19T18:13:56Z 2018-04-19T18:14:00Z Auto-refresh snap "snapcraft" [11:21] 203 Done 2018-04-20T09:28:56Z 2018-04-20T09:28:59Z Auto-refresh snap "snapcraft" [11:21] 204 Done 2018-04-20T11:18:23Z 2018-04-20T11:18:55Z Refresh "core" snap from "beta" channel [11:21] i expect it'll be 2K next week. [11:22] ogra_: intersting [11:22] nothing interesting in snap changes either [11:22] ogra_: I believe this is something serious [11:22] ogra_: sergiusens also reported this happening to another snap [11:22] eclipse jumped about the same rate too! [11:22] on reboot we randomly don't see a given snap [11:22] that sounds bad indeed [11:22] popey: share this with sublime-text upstream [11:22] oh we will :D [11:22] ogra_: this is artful? [11:22] once it plateaus a little [11:22] ah xenial [11:23] same As my test machine [11:23] yeah, see snap version above :) [11:23] I tried to reproduce it but no luck [11:23] yeah :/ [11:23] using hwe kernel here [11:23] popey: did you see my classic analyser? [11:23] (non-hwe on my desktop FWIW) [11:23] i did, but didn't use it - i wasn't the one having problems [11:23] popey: sure but it's not the point [11:23] you can run sublime-text [11:23] and run that script on the process [11:24] to see which things are packaged incorrectly [11:24] even if it works for $person [11:24] on, interesting [11:24] it doesn't mean it's correct [11:24] this let's you see what is wrong [11:24] try it :) [11:24] I want to snap that helper [11:24] but I need to convince jdstrand [11:24] or make it classically confined [11:24] but I'd rather just make interfaces powerful enough [11:26] zyga, wow ... just looking at syslog ... there are other oddities ... see the hexchat messages https://paste.ubuntu.com/p/qQpCZ8fgRh/ [11:26] Apr 20 13:18:44 acheron snapd[4918]: 2018/04/20 13:18:44.109729 helpers.go:217: cannot connect plug "gsettings" [11:26] from snap "hexchat", no such plug [11:26] PR #20: Feature/snapfs cleanup kernel assets [11:27] yeah [11:27] hmm, that happened just now [11:27] so [11:27] ogra_: "snap interfaces hex chat" [11:27] snap interfaces shows them all connected fine [11:27] (without the space, sorry, spellchecker does this) [11:28] can you restart snapd and see if something similar happens (to any snap) [11:28] oh [11:28] oh? [11:28] :desktop-legacy hexchat,shattered-pixel-dungeon,telegram-desktop,vlc [11:28] :network gping,hexchat,lxd,packageproxy,shattered-pixel-dungeon,snapcraft-forum,telegram-desktop,usbtop,vlc,wine2 [11:28] :network-bind hexchat,mjpg-streamer,packageproxy,shattered-pixel-dungeon,telegram-desktop,usbtop,vlc,wine2 [11:28] :unity7 hexchat,shattered-pixel-dungeon,snapcraft-forum,telegram-desktop,vlc,wine2 [11:28] :x11 hexchat,shattered-pixel-dungeon,snapcraft-forum,vlc,wine2 [11:28] hexchat:hexchat - [11:28] no home [11:28] cat the hex chat's snap.yaml please [11:28] (or pulse) [11:28] its the one from the store ... one sec [11:28] maybe that's harmless now [11:28] maybe it just dropped those plugs [11:29] we have some code in 2.33 that will remove stale connections [11:29] http://paste.ubuntu.com/p/VGNzX4hZRJ/ [11:29] interesting [11:29] why does it look for pulse/home/gsettings if they are not defined [11:29] ogra_: because it remembered those were connected [11:29] that's fine, that's harmless [11:29] ok [11:30] ok, if you see this issue again (not having apparmor profile) do let me know [11:30] (not sure why they would be connected and now not anymre though) [11:30] will do [11:30] well, they were connected at some point in time [11:30] so we remember that [11:30] and we never forget until you remove the snap :) [11:30] (but don't do that, that's silly) [11:30] as snap refreshes the set of interfaces can change [11:31] sure, i get that ... but that snap hasnt changed in a month [11:31] ogra@acheron:~$ snap info hexchat|grep refresh [11:31] refreshed: 2018-03-19T06:50:55+01:00 [11:31] ogra_, zyga, popey: yes, I logged a bug on snapd for the profiles magically going away [11:32] will it try connecting every reboot even though it should know the interfaces are gone after the first attempt ? === popeycore is now known as popey_ [11:32] ogra_: https://bugs.launchpad.net/snapd/+bug/1764998 [11:32] Bug #1764998: profiles making a run for it

[11:33] (i know it is harmless but the probing surely wastes boot time every boot ... ) [11:33] zyga and no, I am not going to beta, last time I did that I had to reinstall my entire system [11:33] well, but that at least guarantees yu have a clean system every now and then :P [11:33] PR snapd#5077 opened: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests [11:34] sergiusens, beta solved it for me [11:34] ogra_: yes but it takes microseconds to check they are missing [11:34] sergiusens: ! [11:34] ogra_: please add it to the bug :-P [11:34] zyga: the code that removes stale connections hasn't landed yet [11:34] sergiusens: what happened? [11:34] but no, no beta for me [11:34] zyga: there was a bug in core, my snaps stopped working and I had to spend the day reinstalling [11:35] atm beta == candidate [11:35] and candidate wil becomed stable ~Monday [11:35] could you not switch back to stable? [11:35] zyga: no, there was a bug where channel switching was broken in beta ;-) [11:35] zyga: candidate and beta are the same right now [11:35] sergiusens: switch, refresh and revert well all broken? [11:35] pedronis: ack [11:36] zyga: refresh was, and yes, there was no way to move back, I troubleshooted with mvo at that time [11:39] pstolowski (cc pedronis): interfaces/policy/basedeclaration.go describes the thought behind stuff [11:40] pstolowski (cc pedronis): that states that deny-connection should be used with app-provided slots. grepping for deny-connection, I don't see anything that is *only* an implicit core slot that has deny-connection [11:40] jdstrand: this the dummy test interface though [11:40] it's a bit unclear what rules should applay to it [11:41] it doesn't open anything [11:41] pstolowski: the one where it is both core and app, we should have: [11:41] deny-connection: [11:41] on-classic: false [11:41] pedronis: what is the 'dummy test interface'? [11:41] * jdstrand is lacking context [11:41] jdstrand: it's in a big PR about interface hooks that you should probably read [11:41] (tough it's big) [11:41] oh that one [11:42] I've let zyga know-- I am working on a couple of things with critical priority for Berlin so not able to get to that yet [11:42] with luck, next week [11:42] good luck jdstrand [11:43] jdstrand: yep. that's the interface i introduced strictly for testing purposes as it was the only way to test that interface hooks work end-to-end; it doesn't do anything [11:43] pstolowski: can you describe what the interface does? it sounds like like it literally does nothing. if it does nothing, there is no reason for it to have anything beyond: [11:43] allow-installation: [11:43] slot-snap-type: [11:43] -core [11:44] pstolowski: (in terms of security) [11:44] jdstrand: i did as requested with signal-desktop last night, happy to follow up today. https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982/13 [11:44] jdstrand: it attached to some test apps though, not core [11:44] pstolowski: ie, let connect and auto-connect. if you need it to do something else for test purposes, just do what you want [11:44] ok [11:44] -app [11:44] but yes, it does notighin [11:44] - core [11:45] and probably shouldn't auto-connect, mostly to avoud confusion, unless some tests really need that [11:45] pstolowski: is this supposed to mimic how other interfaces act, or it just needs something in the base decl and you're wondering what? [11:46] jdstrand: notice that the review request, or at least looking at it, was not particularly for this, is that that PR changes a bit how policy is enforced [11:46] pstolowski: (since it does nothing, I would argue that you can put anything you wnat in the base decl) [11:46] jdstrand: because it now accounts for dynamic intrface attrs coming from hooks [11:47] jdstrand: it's an interface that has a few attributes both on slot and plug side; some are defined in snap's yaml and some have values dynamically created at runtime by slot/plug hooks. the slot of "dummy" interface is offered by test snap [11:47] popey: that is disappointing [11:48] pstolowski: ok, so it is meant to *only* be provided by the test snap, *not* ever core? [11:49] jdstrand: correct [11:49] pstolowski: I suggest: [11:49] dummy: [11:49] allow-installation: [11:50] slot-snap-type: [11:50] - app [11:50] deny-connection: true [11:50] then add a snap decl for your test snap [11:50] pstolowski: is the snap local or from the store? [11:51] this would mimic what we typically would do. if you don't care about the the snap decl integration, you could drop the deny-connection bit, but add a comment as to why [11:52] pstolowski: also, I'm guessing this is for 2.33 and *not* 2.32.something? [11:53] jdstrand: correct, this is 2.33 material [11:53] ok [11:53] niemeyer, today I'll be 5 minutes late in the standup [11:53] I will have it at the top of my list to review after the two critical things I'm working on [11:53] hopefully that translates to next week, though popey's url means possibly not [11:54] jdstrand: would it help if I gave you the script / setup I'm using to build signal? [11:54] so you don't block on me [11:55] popey: I'm probably going to need to have the full tree to build the thing to see what is happening. I mean, I can resquash, resquash, resquash, ... ad nauseum snaps big snaps and it works fine [11:56] jdstrand: well, I clone, patch, build. But I automated it with a litte script in lxd [11:56] popey: it seems they are maybe doing something weird or there is a disparity in the squashfs-tools inside and outside the container [11:56] popey: is signal classic? [11:56] no [11:57] popey: yes please. if it is public, can you just put that into the forum topic? [11:57] ok [11:58] lemme dist-upgrade my container, try and build again and see [11:58] pedronis: the snap is local [11:58] popey: oh, yes, please. we did have to patch squashfs-tools for symlinks, but that was *ages* ago [11:59] it would be awesome if that is all it was... [11:59] only had a few updates, including snapcraft 2.41, but not squashfs-tools [11:59] trying anyway [11:59] if you have the 2.41 deb in there, then probably not it [11:59] jdstrand: thanks for the suggestions [12:01] pstolowski: you're welcome. sorry I can't review sonner, but I'll get to it [12:01] popey: thanks for retesting btw [12:01] np [12:01] I want this fixed as much as you :) [12:03] popey: I'm not sure that's possible, but thanks! ;P [12:03] haha [12:04] zyga: you keep referring to snapping a helper and convincing me. is this the environ access? [12:04] jdstrand: np and thanks [12:04] popey: would it be possible to do one-time upload of dev version of s-t to edge? [12:05] zyga: yeah, I'll take a look. [12:05] jdstrand: it was ... [12:05] jdstrand: (more than that) [12:05] both of the things [12:05] let me look, I have that somewhere [12:06] basically, I didn't care for it [12:06] classic-snap-analyzer https://www.irccloud.com/pastebin/Sk6YiLvk/ [12:06] I wanted to get environment to check if SNAP_NAME is set (to be smart about finding snap processes) [12:06] I wanted proc/pid/maps to see what is loaded [12:06] /proc/pid/maps and /proc/pid/environ [12:06] I think there are some misc files I could use but that's bare minimum [12:07] btw, did you know you can poll on /proc/pid/mounts? :) [12:07] it's cool, I didn't know [12:07] :( failed again jdstrand [12:07] jdstrand: also consider /proc/pid/map_files/ [12:07] it's very similar to maps but laid out differnetly [12:07] *differently [12:08]