[00:12] PR snapd#6109 opened: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME [00:15] PR snapd#6110 opened: spread.yaml: add openSUSE Tumbleweed [00:16] PR snapd#6111 opened: packaging/opensuse: move most logic to snapd.mk [00:18] jdstrand: FYI https://github.com/snapcore/snapd/pull/6111 is the thing I was talking about [00:18] PR #6111: packaging/opensuse: move most logic to snapd.mk [02:28] how do I say "rain is coming", because you saw on the forecast, in a normal conversation? === blackboxsw is now known as blackboxsw_away [06:36] Good morning [06:39] PR snapd#6093 closed: daemon: spool sideloaded snap into blob dir [06:40] hey zyga [06:44] zyga: 6110 has two test failures in the new tumbleweed tests [06:44] zyga: and 6109 has some new comments [06:47] PR snapd#6101 closed: switch travis unit tests to xenial [06:57] Thank you [06:57] Tumbleweed failed for me locally but I wanted to share this with Sergio [06:58] I’ll get a shower and be back soon [06:59] I posted 6111, curious to know what you think [07:00] zyga: sure, thanks [07:32] Man, I can barely see where I’m going in this fog === pstolowski|afk is now known as pstolowski [07:59] morning [08:00] hey pstolowski - good morning [08:00] re [08:00] good morning pawel [08:07] mvo: can I push https://github.com/snapcore/snapd/pull/6109 for 2.36.1 as well? [08:07] PR #6109: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME [08:08] zyga: yeah, please tag it [08:08] zyga: 6096 needs a second review [08:08] looking [08:08] zyga: I will release 2.36.1 once this is green [08:09] done [08:14] ta [08:22] mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/snapcraft/20181030_213532_e6942@/log.gz this is in bionic-proposed. could you have a look? that's the python3.6 3.6.7 update [08:23] doko: snapcraft is sergiusens baby - I assume this happens all the time and is not a one-off race or something in their suite? [08:24] doko: hm, hm, "{{{The package python3-dev has unmet dependencies:}}}" [08:24] doko: is/was there some inconsistency in the archive when this ran maybe? [08:28] I'll run it again [08:29] ta [08:54] mvo: shall I squash https://github.com/snapcore/snapd/pull/6096 [08:54] PR #6096: spread.yaml: add more systems to the autopkgtest and qemu backends [08:56] mvo: adopted baby, its your original baby formed with another Michael, you have commit number 3 after all 😉 [08:56] sergiusens: haha [08:56] sergiusens: true [09:03] PR snapd#6096 closed: spread.yaml: add more systems to the autopkgtest and qemu backends [09:22] PR snapd#6112 opened: correct localInstallCleanup doc comment [09:35] hi, I'm having a hard time getting a python-based core18 classic snap to work. if I install it on xenial, I get this: https://paste.ubuntu.com/p/PbPq2bp5md/ [09:37] Chipaca, hi, so I've been trying to fix that snap of mine wrt python3, but I see this issue on xenial: https://paste.ubuntu.com/p/PbPq2bp5md/ [09:37] Chipaca, is snapcraft doing something wrong with python3? [09:37] ackk: looking at your log [09:37] thanks zyga [09:37] Chipaca: hi, #6112 [09:37] PR #6112: correct localInstallCleanup doc comment [09:37] The x3 vs x5 aspect is curious [09:38] Is the python interpreter present in x5 as well? [09:38] ackk: classic snap? [09:38] zyga, ah sorry, that was because I run from history, x5 is the last attempt [09:38] Chipaca, yes, classis, python, core18 [09:38] *classic [09:38] Classic as in classic confinement? [09:38] ackk: snap list --all sshoot ? [09:39] pedronis: ah good catch and thanks [09:40] Chipaca, https://paste.ubuntu.com/p/RvDdMMzW2g/ [09:40] zyga, yes [09:40] is there another type of classic? :) [09:40] Well classic system [09:40] ackk: a snap can be classic, a system can be classic, and there is a devmode snap that's called "classic" [09:40] ah I see [09:41] It is the classic problem of name overloading ;) [09:41] (I'm testing in a xenial lxd if that matters) [09:41] zyga, classic joke, classic :) [09:41] ackk: you built this on 18.04? [09:41] Chipaca, yes [09:42] ackk: on 18.04, what happens when you run python from the snap like that? [09:42] ackk: that is [09:42] ackk: please, snap run --shell sshoot, start python3 in there, let me know how it goes (i'll have more things for you to do in the python) [09:43] pstolowski: didn't we have a way to disable a service froma hook? [09:43] Chipaca, it starts (and "sshoot" also works) [09:44] Chipaca: well, not really, the only way to do something with services from hook is via snapctl [09:46] ackk: import _crypt [09:46] ackk: print(_crypt) [09:46] pstolowski: grmbl [09:46] pstolowski: i'll see if i can fix this :-) [09:46] Chipaca, [09:47] x1! [09:47] zyga, different container, this is bionic [09:47] Ah [09:50] pstolowski: where are hooks documented, for snap developers? [09:51] ackk: can you ldd the python binary in the snap? [09:51] ackk: from inside the snap [09:51] Chipaca: oh you... [09:51] sparkiegeek: i have a developer wanting to use them [09:51] Chipaca: https://forum.snapcraft.io/t/supported-snap-hooks/3795 and https://forum.snapcraft.io/t/interface-hooks/8214 [09:52] pstolowski: thanks [09:52] pstolowski: I'm also going to look into disabling :-) [09:53] nice [09:53] sparkiegeek: or wait, have I continued to break the store [09:53] Chipaca: nah, not today [09:53] Chipaca, https://paste.ubuntu.com/p/kjFbQccfQV/ (bionic and xenial) [09:54] Chipaca, isn't the last entry problematic? it points to the system library [09:55] ackk: yes [09:55] ackk: i think so at least :-) [09:55] ackk: there's this other little-known classic python snap we could look at for inspiration [09:55] ackk: schnappcraft, or something like that, probably about getting drunk [09:56] lol [09:56] Chipaca, isn't snapcraft also classic? :) [09:56] ackk: but not core18 which might be the extra quirk here [09:56] right [09:58] Chipaca, so, is that a core18 bug? 'cause the library isn't there in core18 [09:59] degville: hey, just noticed in https://forum.snapcraft.io/t/interface-hooks/8214 - is the colon at the end of "Interface hooks can read the attributes of the affected plug and slot by using the snapctl command, as defined by the snap’s snap.yaml:" sentence intended? [09:59] PR snapd#6109 closed: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME [10:00] Chipaca, indeed on xenial that's a broken link [10:00] pstolowski: no - good spot, thanks. [10:01] Chipaca, https://paste.ubuntu.com/p/h7MmBYgjjp/ [10:10] mvo, ^ maybe you have insight [10:13] ackk: I lack context, is the problem that the symlink is absolute? [10:13] mvo, no, the problem is that it's broken on xenial, as the ld.so version is different [10:14] mvo, should core18 perhaps include ld.so as well? [10:14] mvo, it's 2.23 not 2.27 on xenial [10:17] ackk: I think the problem is actually that this link needs to be relative, i.e. /lib64/ld-linux-x86-64.so.2 must point to ../lib... [10:17] ackk: let me look into this [10:17] mvo, ah, so it should point to the snap [10:19] ackk: yeah, the file is there [10:20] ackk: there in the snap [10:20] mvo, ah so it's just a symlink issue [10:21] ackk: sorry i'm at the summit and only have half an ear for this right now ;-) [10:21] ackk: yeah, looking at the fix now [10:21] Chipaca, np it seems mvo has found the culprit [10:22] nice [10:22] * Chipaca hugs mvo [10:22] Chipaca, mvo, thanks [10:25] PR snapd#6113 opened: overlord/ifacestate: handler for hotplug-connect task [10:25] mvo: sudo find /snap/core18/current/ -type l -printf "%l from %p\n" | grep ^/ [10:26] PR core18#88 opened: hooks: make ld-so symlink in /lib64 relative [10:26] Chipaca: hrm, that are many [10:26] ackk: the above PR should fix the issue [10:26] mvo: I don't know if they're all bad though, but yes there are :-) [10:26] pstolowski: "snapctl stop --disable theservice" from within the snap works [10:26] pstolowski: from the install hook i mean [10:26] Chipaca: *sigh* thanks :) [10:27] Chipaca: ah, of course, i forgot stop had the flag /o\... sorry about that [10:28] mvo, cool, thanks [10:35] PR snapd#6112 closed: correct localInstallCleanup doc comment [10:38] mvo: thank you for cherry picking into 2.36 [10:38] Chipaca: I did a first pass on the epochs PR, I understad your focus is elsewhere this week, either way let me know if you disagree when you can look at it [10:39] zyga: my pleasure - we are complete now, I wait for travis and once its green will do 2.36.1 (maybe after lunch, depending on travis) [10:39] super [10:41] zyga: in the meantime I'm packaging/patching fontconfg like its 1998 [10:42] mvo: does current fontconifg support older cache formats/ [10:43] as in, can it write all formats from one binary [10:44] zyga: not afaict [10:44] mvo: tumbleweed fails on gpg key management from snap keys and all [10:45] I wonder if this is a sign of trouble to come in disco with new package sync [10:45] but I won't look more today [10:45] back to user mounts [10:45] I'll do a brief packaging update with 2.36.1 but other than that I'm happy with current state [10:45] zyga: what gnupg does it have? [10:46] https://www.irccloud.com/pastebin/rUQqGjEg/ [10:46] 2.2.10 [10:46] we'll need to dig [10:49] pedronis: thank you. I'll get to it tomorrow, i expect [10:49] tomorrow i'll be staying home [10:51] * zyga is on the road today but trying to focus [11:14] * zyga is in a car dealer shop, on headphones listening to music, writing C on opensuse [11:14] I wonder if people think I'm some kind of evil nasty hacker [11:15] oh, I also have a dog with me [11:16] so maybe they are scared to check :D [11:26] zyga: is you screen flooded with wall of text in a matrix-style all the time? ;) [11:43] is there still no way to remove a snap config option once set? [11:43] snap never forgets? [11:47] ahasenack: correct, best approximation is setting to empty string or emptying a larger context [11:47] what does "emptying a larger context" mean? [11:48] if you have foo.bar and foo.baz setting foo to {}, not saying it's useful in general [11:49] ah, by larger you meant something like parent [11:49] yes [11:49] ok, thx [11:49] we do plan to allow some resetting, still haven't happened yet [12:05] PR snapd#6052 closed: snap, store, overlod/snapstate: always send epochs [12:19] pstolowski: hollywood has a purpose ;-) [12:19] * zyga is back home [12:43] PR snapd#6114 opened: Handler for hotplug-disconnect task [12:54] zyga: got a weird snap-exec error about not finding a profile that went away with removing and reinstalling a snap, is this something you'd be interested in? [12:54] mvo, hey [12:54] mvo, did you see the log I sent you yesterday? [12:54] does it help? [12:55] Chipaca: indeed [12:55] Chipaca: can you tell me more [12:55] zyga: pstolowski: did we end up reusing/abusing addImplicitSlots for hot plug slots as well? [12:55] zyga: i'm waiting for a copy of the problem [12:56] pedronis: yes [12:56] pedronis: I believe so [12:56] :/ [12:56] pedronis: addImplicitSlots now looks also into the state ("hotplug-slots" map) [12:56] what do you think should happen there? [12:57] we should really find a different way to factor that [12:57] it's not the hot plug part I'm not keen on [12:57] it's as usual the addImplicitSlot sprinkled around part [12:57] mixing the two doesn't make things better tough [12:57] I had one idea with keeping well-know snap.Info for core/snapd and only ever handling implicit slots in one single spot at one time [12:58] this is what I did in one of the exploratory branches long ago when core18 was being prepared [12:59] the advantage was that we traded complexity all around snap info [12:59] zyga: http://paste.ubuntu.com/p/KzM4NGdRQs/ [12:59] for special casing one snap [13:00] PR snapcraft#2396 opened: Partial Revert "build providers: fix osx non base and injection" [13:00] pstolowski: zyga: anyway things are as they are, we really need to clean this up at some point [13:00] tough [13:01] I agree, we just need to write down what we are willing to accept [13:01] Chipaca: 1411 was setup-profiles [13:02] "ready-time": "2018-11-08T12:41:47.570494396Z" [13:02] this is when it was ready [13:02] pedronis: yes i agree, i just didn't want to get into rabbit of refactoring before hotplug, similiar to what happened with various refactorings before interface hooks [13:02] *rabbit hole [13:02] pre-refresh hook was 1406 [13:02] it was ready on "ready-time": "2018-11-08T12:41:47.570530073Z" [13:02] so it was after [13:03] do you have kernel logs from the system? [13:03] can you extract the range a second before 12:41:47 [13:03] zyga: person's now in a meeting, but i'll ask [13:03] woa, [13:03] actually [13:03] zyga: probably yes [13:03] its not ! [13:03] I misread [13:03] not ! <- not not [13:04] the sub-second parts show that setup-profiles was after the hook? [13:04] * zyga double checks that [13:04] zyga: do vs undo? [13:04] eh, perhaps [13:04] this sucks, I wish we had better data there [13:04] yes [13:05] kenrel logs will have useful facts but probably not that resolution (though I may be wrong) [13:05] zyga: easiest would be to ask them to 'dmesg -H | pastebinit', would that be enough? [13:05] yes [13:05] asked [13:06] but, they're in a meeting [13:06] so i'll let you know :-) [13:06] zyga: http://paste.ubuntu.com/p/MfKnvp8bD7/ [13:08] [ +0.000004] audit: type=1400 audit(1541680843.472:176): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/snap/core/5742/usr/lib/snapd/snap-confine" name="snap.code-oss.hook.pre-refresh" pid=15781 comm="snap-confine" [13:08] [ +0.005188] audit: type=1400 audit(1541681530.284:182): apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.code-oss.hook.pre-refresh" pid=17895 comm="apparmor_parser" [13:09] so we certainly tried to run the hook before we loaded profiles [13:09] pstolowski: ^ can you tell me from the top of your head, the pre-refresh hook, when is it ran in the sequence of snap refresh? [13:09] pstolowski: and if I have a snap with no revisions and install it, would that hook run? [13:10] Chipaca: can someone report a bug about this [13:10] for tracking [13:10] I'll assign it to myself [13:10] zyga: from top of my head not, but let me take a quick look. first off, it only runs if refreshing [13:10] Chipaca: if you can you please at least collect the basic info about the snap (confinement, hooks) and if this can be reproduced (snap remove foo; ... snap install foo # KABOOM) [13:11] pstolowski: I wonder if we can ever do this: [13:11] pstolowski: run pre-refresh hook on fresh install [13:11] pstolowski: when there's no prior revision [13:11] pstolowski: for context, I'm trying to read the already landed hot plug code and also looking at recent hot plug PR that have landed [13:11] pstolowski: and it somehow ends up in a sequence where we haven't installed the snap yet so it doesn't have security setup done [13:12] zyga: it runs after mount-snap, before stop-snap-services, remove-aliases, unlink-current-snap and before switching to the new revision [13:13] pedronis: ok. the biggest chunk that landed was udevmonitor stuff, after that only very small bits to set the stage [13:13] zyga: how can it be not installed if it's a refresh [13:13] pstolowski, pedronis: about implicit slots, I have a feeling it would be good for snapd to track the implicit system slots and hot plug slots explicitly in ifacestate [13:13] as a first step towards refactoring [13:14] isn't that what the current code does? [13:14] pedronis: I don't know yet [13:14] pedronis: but the hook profile was not replaced [13:14] it was _loaded_ [13:14] so it seems like it was loaded for the first time at that stage [13:14] and that can only happen if the snap was never installed (even before because of a bug in profile removal code) [13:15] zyga: btw relatedly remember that you have an open task about merging setup/remove-profiles into *link* tasks [13:15] pedronis: yes, that's true [13:15] pedronis: though awe need to write down TODOs and schedule them [13:15] *we [13:16] zyga: yes, we do need to do that [13:16] this is an long standing open one though, not saying it's a priority now [13:16] pedronis: I have a hunch that we ran the hook from this snap, the one being installed [13:16] just reminding it because it's related to this area [13:16] * zyga nods [13:19] this would be pretty unexpected given that we run it before current link changes and before setup profiles [13:21] right [13:21] but that's how it looks like [13:21] before setup profiles for sure [13:32] pstolowski: I'm seeing some small typoes etc going over the code, if I don't see anything major I will do a small PR with tweaks if it's ok with you [13:35] any idea why 'snap run --strace snap.app args' would just print "exit status 1" [13:35] ? [13:37] pedronis: sure, np, thanks [13:39] Chipaca: hmmm, strace it ;) [13:39] jokes aside, probably no strace? [13:39] pstolowski: I'm confused by ensureUniqureName, it seems to remove "-" when clearing the suffix, but is not adding "-" when attaching the suffix [13:40] PR snapd#6115 opened: cmd: update autogen.sh for opensuse [13:42] zyga: they have strace [13:43] pstolowski: it seems to be by design, it's tested behavior, but is not documented/explained in the comment [13:44] pedronis: https://github.com/snapcore/snapd/pull/6116 is the simplified feature flag storage for snap-confine [13:44] PR snapd#6116 opened: cmd/libsnap: add simplified feature flag checker [13:44] PR #6116: cmd/libsnap: add simplified feature flag checker [13:44] zyga: https://dpaste.de/FNWL/raw [13:44] Chipaca: lookking [13:44] zyga: not helping :-) [13:44] Chipaca: denials [13:44] ? [13:45] Chipaca: if you want I can jump into standup HO and you can walk me through this in the next 15 minutes [13:45] zyga: what's the context for that [13:45] pedronis: indeed, just found the PR https://github.com/snapcore/snapd/pull/5782 ; it was requested in the review - see https://github.com/snapcore/snapd/pull/5782#discussion_r217018767 [13:45] pedronis: we need to learn about enabled experimental features from snap-confine and snap-update-ns [13:45] PR #5782: ifacestate: helpers for generating slot names for hotplug [13:45] pedronis: this is the idea that Gustavo presented (just stat a file) in response to the facts PR [13:46] pstolowski: is not super clear from the discussion tough that it needs to be removed, if it's then not added [13:46] zyga: http://paste.ubuntu.com/p/XVVzYWNHR7/ [13:46] pstolowski: the test for sure look weird [13:47] jdstrand, did you see https://bugs.launchpad.net/bugs/1802124 yet ? [13:47] Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge [13:48] Chipaca: this is a snap in a container? [13:48] Chipaca: I suspect that may not work fully [13:49] Chipaca: ah, parallels VM [13:50] bug report: on a mac, running parallels, running ubuntu, running lxd as a snap, running another version of ubuntu, running a snap with --strace is not supported [13:50] pstolowski: also I would it work if the base name ends with digits? [13:50] ogra: uhh, there is extra code in this section [13:51] mvo, is "core" needed even if a snap depends on "core18" ? [13:51] pstolowski: we trim only one digit? [13:51] how do we know it's enough [13:51] jdstrand, yeah, sseems to be https://github.com/snapcore/snapd/commit/093b3662047123fe684a0d1dae27775593f1dc1f [13:51] Chipaca: hey, seems you fiddled with ptrace_* for PTRACE_GETFPXREGS? (see https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124). looks like there is an armhf case [13:51] Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge [13:51] pstolowski: this line is very weird: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/hotplug_test.go#L243 [13:52] ogra: there is a commit after that which is meant to address archs without fp [13:52] ah [13:52] and with fp [13:53] ackk: you shouldn't need core if you just depend on core18 [13:54] mvo, that's weird, we have a (strict) snap that doesn't work if you don't have core [13:54] ackk: oh, please tell me more [13:54] ackk: how can I reproduce this? [13:54] pstolowski: to be clear wasn't my intention to rehash already landed code, but this bit looks weird coming fresh to it [13:54] Chipaca: it looks like the policy isn't conditionally adding/removing the fp variants [13:55] mvo, https://pastebin.canonical.com/p/kTv7H5Q65Q/ [13:55] mvo, i have core18 installed only [13:55] if I install core, it works [13:55] pstolowski: also that function is not used yet, is that right? [13:55] pedronis: no, we take entire numeric suffix with strconv.Atoi(proposedName[len(prefix):]); then increment it until we have unique name as a whole. the point is to generate unique name and the example slot3-5 -> slot36 may look weird but is guaranteed to be unique [13:55] mvo, this is a proprietary snap unfortunately, lemme see if I can get you something that you can try [13:55] ackk: aha, interessting, I think you hit a bug, let me look at this [13:56] ackk: its ok, I can probably trigger it somehow, I suspect its a bug with snap-confine that it does not use the right base when it runs the hooks [13:56] pedronis: it is used in the huge hotplug PR, but not in master yet, no [13:56] mvo, ah I see [13:57] ackk: interesting [13:57] we need to be told of the base explicitly [13:57] another thing we could fix with facts alone :/ [13:57] * zyga looks [13:58] we pass --base every time there's a base defined in the snap [13:58] this is the code path used both by hooks and by apps [13:58] pstolowski: why do we remove the "-" ? [13:58] pstolowski: it just seems a mix of two version of the code, I don't understand how it relates to uniqueness [13:59] zyga: hm, apparently something is not quite wired up in the code path :/ [13:59] zyga: I do remember work on this [13:59] zyga: anyway, will look after the meeting [13:59] k [13:59] mvo zyga thanks [13:59] pstolowski: it also means slot3-5 and slot35 will both produce slot36, I don't know if thats a feature or a bug [13:59]