| mup | PR snapd#6109 opened: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6109> | 00:12 |
|---|---|---|
| mup | PR snapd#6110 opened: spread.yaml: add openSUSE Tumbleweed <Created by zyga> <https://github.com/snapcore/snapd/pull/6110> | 00:15 |
| mup | PR snapd#6111 opened: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111> | 00:16 |
| zyga | jdstrand: FYI https://github.com/snapcore/snapd/pull/6111 is the thing I was talking about | 00:18 |
| mup | PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111> | 00:18 |
| erio | how do I say "rain is coming", because you saw on the forecast, in a normal conversation? | 02:28 |
| === blackboxsw is now known as blackboxsw_away | ||
| zyga | Good morning | 06:36 |
| mup | PR snapd#6093 closed: daemon: spool sideloaded snap into blob dir <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6093> | 06:39 |
| mvo | hey zyga | 06:40 |
| mvo | zyga: 6110 has two test failures in the new tumbleweed tests | 06:44 |
| mvo | zyga: and 6109 has some new comments | 06:44 |
| mup | PR snapd#6101 closed: switch travis unit tests to xenial <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6101> | 06:47 |
| zyga | Thank you | 06:57 |
| zyga | Tumbleweed failed for me locally but I wanted to share this with Sergio | 06:57 |
| zyga | I’ll get a shower and be back soon | 06:58 |
| zyga | I posted 6111, curious to know what you think | 06:59 |
| mvo | zyga: sure, thanks | 07:00 |
| zyga | Man, I can barely see where I’m going in this fog | 07:32 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:59 |
| mvo | hey pstolowski - good morning | 08:00 |
| zyga | re | 08:00 |
| zyga | good morning pawel | 08:00 |
| zyga | mvo: can I push https://github.com/snapcore/snapd/pull/6109 for 2.36.1 as well? | 08:07 |
| mup | PR #6109: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6109> | 08:07 |
| mvo | zyga: yeah, please tag it | 08:08 |
| mvo | zyga: 6096 needs a second review | 08:08 |
| zyga | looking | 08:08 |
| mvo | zyga: I will release 2.36.1 once this is green | 08:08 |
| zyga | done | 08:09 |
| mvo | ta | 08:14 |
| doko | 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:22 |
| mvo | 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:23 |
| mvo | doko: hm, hm, "{{{The package python3-dev has unmet dependencies:}}}" | 08:24 |
| mvo | doko: is/was there some inconsistency in the archive when this ran maybe? | 08:24 |
| doko | I'll run it again | 08:28 |
| mvo | ta | 08:29 |
| zyga | mvo: shall I squash https://github.com/snapcore/snapd/pull/6096 | 08:54 |
| mup | PR #6096: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <https://github.com/snapcore/snapd/pull/6096> | 08:54 |
| sergiusens | mvo: adopted baby, its your original baby formed with another Michael, you have commit number 3 after all 😉 | 08:56 |
| mvo | sergiusens: haha | 08:56 |
| mvo | sergiusens: true | 08:56 |
| mup | PR snapd#6096 closed: spread.yaml: add more systems to the autopkgtest and qemu backends <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6096> | 09:03 |
| mup | PR snapd#6112 opened: correct localInstallCleanup doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/6112> | 09:22 |
| ackk | 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:35 |
| ackk | 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 |
| ackk | Chipaca, is snapcraft doing something wrong with python3? | 09:37 |
| zyga | ackk: looking at your log | 09:37 |
| ackk | thanks zyga | 09:37 |
| pedronis | Chipaca: hi, #6112 | 09:37 |
| mup | PR #6112: correct localInstallCleanup doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/6112> | 09:37 |
| zyga | The x3 vs x5 aspect is curious | 09:37 |
| zyga | Is the python interpreter present in x5 as well? | 09:38 |
| Chipaca | ackk: classic snap? | 09:38 |
| ackk | zyga, ah sorry, that was because I run from history, x5 is the last attempt | 09:38 |
| ackk | Chipaca, yes, classis, python, core18 | 09:38 |
| ackk | *classic | 09:38 |
| zyga | Classic as in classic confinement? | 09:38 |
| Chipaca | ackk: snap list --all sshoot ? | 09:38 |
| Chipaca | pedronis: ah good catch and thanks | 09:39 |
| ackk | Chipaca, https://paste.ubuntu.com/p/RvDdMMzW2g/ | 09:40 |
| ackk | zyga, yes | 09:40 |
| ackk | is there another type of classic? :) | 09:40 |
| zyga | Well classic system | 09:40 |
| Chipaca | ackk: a snap can be classic, a system can be classic, and there is a devmode snap that's called "classic" | 09:40 |
| ackk | ah I see | 09:40 |
| zyga | It is the classic problem of name overloading ;) | 09:41 |
| ackk | (I'm testing in a xenial lxd if that matters) | 09:41 |
| ackk | zyga, classic joke, classic :) | 09:41 |
| Chipaca | ackk: you built this on 18.04? | 09:41 |
| ackk | Chipaca, yes | 09:41 |
| Chipaca | ackk: on 18.04, what happens when you run python from the snap like that? | 09:42 |
| Chipaca | ackk: that is | 09:42 |
| Chipaca | 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:42 |
| Chipaca | pstolowski: didn't we have a way to disable a service froma hook? | 09:43 |
| ackk | Chipaca, it starts (and "sshoot" also works) | 09:43 |
| pstolowski | Chipaca: well, not really, the only way to do something with services from hook is via snapctl | 09:44 |
| Chipaca | ackk: import _crypt | 09:46 |
| Chipaca | ackk: print(_crypt) | 09:46 |
| Chipaca | pstolowski: grmbl | 09:46 |
| Chipaca | pstolowski: i'll see if i can fix this :-) | 09:46 |
| ackk | Chipaca, <module '_crypt' from '/snap/sshoot/x1/usr/lib/python3.6/lib-dynload/_crypt.cpython-36m-x86_64-linux-gnu.so'> | 09:46 |
| zyga | x1! | 09:47 |
| ackk | zyga, different container, this is bionic | 09:47 |
| zyga | Ah | 09:47 |
| Chipaca | pstolowski: where are hooks documented, for snap developers? | 09:50 |
| Chipaca | ackk: can you ldd the python binary in the snap? | 09:51 |
| Chipaca | ackk: from inside the snap | 09:51 |
| sparkiegeek | Chipaca: oh you... | 09:51 |
| Chipaca | sparkiegeek: i have a developer wanting to use them | 09:51 |
| pstolowski | Chipaca: https://forum.snapcraft.io/t/supported-snap-hooks/3795 and https://forum.snapcraft.io/t/interface-hooks/8214 | 09:51 |
| Chipaca | pstolowski: thanks | 09:52 |
| Chipaca | pstolowski: I'm also going to look into disabling :-) | 09:52 |
| pstolowski | nice | 09:53 |
| Chipaca | sparkiegeek: or wait, have I continued to break the store | 09:53 |
| sparkiegeek | Chipaca: nah, not today | 09:53 |
| ackk | Chipaca, https://paste.ubuntu.com/p/kjFbQccfQV/ (bionic and xenial) | 09:53 |
| ackk | Chipaca, isn't the last entry problematic? it points to the system library | 09:54 |
| Chipaca | ackk: yes | 09:55 |
| Chipaca | ackk: i think so at least :-) | 09:55 |
| Chipaca | ackk: there's this other little-known classic python snap we could look at for inspiration | 09:55 |
| Chipaca | ackk: schnappcraft, or something like that, probably about getting drunk | 09:55 |
| ackk | lol | 09:56 |
| ackk | Chipaca, isn't snapcraft also classic? :) | 09:56 |
| Chipaca | ackk: but not core18 which might be the extra quirk here | 09:56 |
| ackk | right | 09:56 |
| ackk | Chipaca, so, is that a core18 bug? 'cause the library isn't there in core18 | 09:58 |
| pstolowski | 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 |
| mup | PR snapd#6109 closed: interfaces/apparmor: allow access to /run/snap.$SNAP_INSTANCE_NAME <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6109> | 09:59 |
| ackk | Chipaca, indeed on xenial that's a broken link | 10:00 |
| degville | pstolowski: no - good spot, thanks. | 10:00 |
| ackk | Chipaca, https://paste.ubuntu.com/p/h7MmBYgjjp/ | 10:01 |
| ackk | mvo, ^ maybe you have insight | 10:10 |
| mvo | ackk: I lack context, is the problem that the symlink is absolute? | 10:13 |
| ackk | mvo, no, the problem is that it's broken on xenial, as the ld.so version is different | 10:13 |
| ackk | mvo, should core18 perhaps include ld.so as well? | 10:14 |
| ackk | mvo, it's 2.23 not 2.27 on xenial | 10:14 |
| mvo | 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 |
| mvo | ackk: let me look into this | 10:17 |
| ackk | mvo, ah, so it should point to the snap | 10:17 |
| mvo | ackk: yeah, the file is there | 10:19 |
| mvo | ackk: there in the snap | 10:20 |
| ackk | mvo, ah so it's just a symlink issue | 10:20 |
| Chipaca | ackk: sorry i'm at the summit and only have half an ear for this right now ;-) | 10:21 |
| mvo | ackk: yeah, looking at the fix now | 10:21 |
| ackk | Chipaca, np it seems mvo has found the culprit | 10:21 |
| Chipaca | nice | 10:22 |
| * Chipaca hugs mvo | 10:22 | |
| ackk | Chipaca, mvo, thanks | 10:22 |
| mup | PR snapd#6113 opened: overlord/ifacestate: handler for hotplug-connect task <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113> | 10:25 |
| Chipaca | mvo: sudo find /snap/core18/current/ -type l -printf "%l from %p\n" | grep ^/ | 10:25 |
| mup | PR core18#88 opened: hooks: make ld-so symlink in /lib64 relative <Created by mvo5> <https://github.com/snapcore/core18/pull/88> | 10:26 |
| mvo | Chipaca: hrm, that are many | 10:26 |
| mvo | ackk: the above PR should fix the issue | 10:26 |
| Chipaca | mvo: I don't know if they're all bad though, but yes there are :-) | 10:26 |
| Chipaca | pstolowski: "snapctl stop --disable theservice" from within the snap works | 10:26 |
| Chipaca | pstolowski: from the install hook i mean | 10:26 |
| mvo | Chipaca: *sigh* thanks :) | 10:26 |
| pstolowski | Chipaca: ah, of course, i forgot stop had the flag /o\... sorry about that | 10:27 |
| ackk | mvo, cool, thanks | 10:28 |
| mup | PR snapd#6112 closed: correct localInstallCleanup doc comment <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6112> | 10:35 |
| zyga | mvo: thank you for cherry picking into 2.36 | 10:38 |
| pedronis | 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:38 |
| mvo | 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 |
| zyga | super | 10:39 |
| mvo | zyga: in the meantime I'm packaging/patching fontconfg like its 1998 | 10:41 |
| zyga | mvo: does current fontconifg support older cache formats/ | 10:42 |
| zyga | as in, can it write all formats from one binary | 10:43 |
| mvo | zyga: not afaict | 10:44 |
| zyga | mvo: tumbleweed fails on gpg key management from snap keys and all | 10:44 |
| zyga | I wonder if this is a sign of trouble to come in disco with new package sync | 10:45 |
| zyga | but I won't look more today | 10:45 |
| zyga | back to user mounts | 10:45 |
| zyga | I'll do a brief packaging update with 2.36.1 but other than that I'm happy with current state | 10:45 |
| pedronis | zyga: what gnupg does it have? | 10:45 |
| zyga | https://www.irccloud.com/pastebin/rUQqGjEg/ | 10:46 |
| zyga | 2.2.10 | 10:46 |
| pedronis | we'll need to dig | 10:46 |
| Chipaca | pedronis: thank you. I'll get to it tomorrow, i expect | 10:49 |
| Chipaca | tomorrow i'll be staying home | 10:49 |
| * zyga is on the road today but trying to focus | 10:51 | |
| * zyga is in a car dealer shop, on headphones listening to music, writing C on opensuse | 11:14 | |
| zyga | I wonder if people think I'm some kind of evil nasty hacker | 11:14 |
| zyga | oh, I also have a dog with me | 11:15 |
| zyga | so maybe they are scared to check :D | 11:16 |
| pstolowski | zyga: is you screen flooded with wall of text in a matrix-style all the time? ;) | 11:26 |
| ahasenack | is there still no way to remove a snap config option once set? | 11:43 |
| ahasenack | snap never forgets? | 11:43 |
| pedronis | ahasenack: correct, best approximation is setting to empty string or emptying a larger context | 11:47 |
| ahasenack | what does "emptying a larger context" mean? | 11:47 |
| pedronis | if you have foo.bar and foo.baz setting foo to {}, not saying it's useful in general | 11:48 |
| ahasenack | ah, by larger you meant something like parent | 11:49 |
| pedronis | yes | 11:49 |
| ahasenack | ok, thx | 11:49 |
| pedronis | we do plan to allow some resetting, still haven't happened yet | 11:49 |
| mup | PR snapd#6052 closed: snap, store, overlod/snapstate: always send epochs <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6052> | 12:05 |
| zyga | pstolowski: hollywood has a purpose ;-) | 12:19 |
| * zyga is back home | 12:19 | |
| mup | PR snapd#6114 opened: Handler for hotplug-disconnect task <Created by stolowski> <https://github.com/snapcore/snapd/pull/6114> | 12:43 |
| Chipaca | 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 |
| cachio | mvo, hey | 12:54 |
| cachio | mvo, did you see the log I sent you yesterday? | 12:54 |
| cachio | does it help? | 12:54 |
| zyga | Chipaca: indeed | 12:55 |
| zyga | Chipaca: can you tell me more | 12:55 |
| pedronis | zyga: pstolowski: did we end up reusing/abusing addImplicitSlots for hot plug slots as well? | 12:55 |
| Chipaca | zyga: i'm waiting for a copy of the problem | 12:55 |
| pstolowski | pedronis: yes | 12:56 |
| zyga | pedronis: I believe so | 12:56 |
| pedronis | :/ | 12:56 |
| pstolowski | pedronis: addImplicitSlots now looks also into the state ("hotplug-slots" map) | 12:56 |
| zyga | what do you think should happen there? | 12:56 |
| pedronis | we should really find a different way to factor that | 12:57 |
| pedronis | it's not the hot plug part I'm not keen on | 12:57 |
| pedronis | it's as usual the addImplicitSlot sprinkled around part | 12:57 |
| pedronis | mixing the two doesn't make things better tough | 12:57 |
| zyga | 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:57 |
| zyga | this is what I did in one of the exploratory branches long ago when core18 was being prepared | 12:58 |
| zyga | the advantage was that we traded complexity all around snap info | 12:59 |
| Chipaca | zyga: http://paste.ubuntu.com/p/KzM4NGdRQs/ | 12:59 |
| zyga | for special casing one snap | 12:59 |
| mup | PR snapcraft#2396 opened: Partial Revert "build providers: fix osx non base and injection" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2396> | 13:00 |
| pedronis | pstolowski: zyga: anyway things are as they are, we really need to clean this up at some point | 13:00 |
| pedronis | tough | 13:00 |
| zyga | I agree, we just need to write down what we are willing to accept | 13:01 |
| zyga | Chipaca: 1411 was setup-profiles | 13:01 |
| zyga | "ready-time": "2018-11-08T12:41:47.570494396Z" | 13:02 |
| zyga | this is when it was ready | 13:02 |
| pstolowski | 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 |
| pstolowski | *rabbit hole | 13:02 |
| zyga | pre-refresh hook was 1406 | 13:02 |
| zyga | it was ready on "ready-time": "2018-11-08T12:41:47.570530073Z" | 13:02 |
| zyga | so it was after | 13:02 |
| zyga | do you have kernel logs from the system? | 13:03 |
| zyga | can you extract the range a second before 12:41:47 | 13:03 |
| Chipaca | zyga: person's now in a meeting, but i'll ask | 13:03 |
| zyga | woa, | 13:03 |
| zyga | actually | 13:03 |
| Chipaca | zyga: probably yes | 13:03 |
| zyga | its not ! | 13:03 |
| zyga | I misread | 13:03 |
| Chipaca | not ! <- not not | 13:03 |
| zyga | the sub-second parts show that setup-profiles was after the hook? | 13:04 |
| * zyga double checks that | 13:04 | |
| Chipaca | zyga: do vs undo? | 13:04 |
| zyga | eh, perhaps | 13:04 |
| zyga | this sucks, I wish we had better data there | 13:04 |
| Chipaca | yes | 13:04 |
| zyga | kenrel logs will have useful facts but probably not that resolution (though I may be wrong) | 13:05 |
| Chipaca | zyga: easiest would be to ask them to 'dmesg -H | pastebinit', would that be enough? | 13:05 |
| zyga | yes | 13:05 |
| Chipaca | asked | 13:05 |
| Chipaca | but, they're in a meeting | 13:06 |
| Chipaca | so i'll let you know :-) | 13:06 |
| Chipaca | zyga: http://paste.ubuntu.com/p/MfKnvp8bD7/ | 13:06 |
| zyga | [ +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 |
| zyga | [ +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:08 |
| zyga | so we certainly tried to run the hook before we loaded profiles | 13:09 |
| zyga | 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 |
| zyga | pstolowski: and if I have a snap with no revisions and install it, would that hook run? | 13:09 |
| zyga | Chipaca: can someone report a bug about this | 13:10 |
| zyga | for tracking | 13:10 |
| zyga | I'll assign it to myself | 13:10 |
| pstolowski | zyga: from top of my head not, but let me take a quick look. first off, it only runs if refreshing | 13:10 |
| zyga | 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:10 |
| zyga | pstolowski: I wonder if we can ever do this: | 13:11 |
| zyga | pstolowski: run pre-refresh hook on fresh install | 13:11 |
| zyga | pstolowski: when there's no prior revision | 13:11 |
| pedronis | 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 |
| zyga | 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:11 |
| pstolowski | zyga: it runs after mount-snap, before stop-snap-services, remove-aliases, unlink-current-snap and before switching to the new revision | 13:12 |
| pstolowski | pedronis: ok. the biggest chunk that landed was udevmonitor stuff, after that only very small bits to set the stage | 13:13 |
| pedronis | zyga: how can it be not installed if it's a refresh | 13:13 |
| zyga | 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 |
| zyga | as a first step towards refactoring | 13:13 |
| pedronis | isn't that what the current code does? | 13:14 |
| zyga | pedronis: I don't know yet | 13:14 |
| zyga | pedronis: but the hook profile was not replaced | 13:14 |
| zyga | it was _loaded_ | 13:14 |
| zyga | so it seems like it was loaded for the first time at that stage | 13:14 |
| zyga | and that can only happen if the snap was never installed (even before because of a bug in profile removal code) | 13:14 |
| pedronis | zyga: btw relatedly remember that you have an open task about merging setup/remove-profiles into *link* tasks | 13:15 |
| zyga | pedronis: yes, that's true | 13:15 |
| zyga | pedronis: though awe need to write down TODOs and schedule them | 13:15 |
| zyga | *we | 13:15 |
| pedronis | zyga: yes, we do need to do that | 13:16 |
| pedronis | this is an long standing open one though, not saying it's a priority now | 13:16 |
| zyga | pedronis: I have a hunch that we ran the hook from this snap, the one being installed | 13:16 |
| pedronis | just reminding it because it's related to this area | 13:16 |
| * zyga nods | 13:16 | |
| pstolowski | this would be pretty unexpected given that we run it before current link changes and before setup profiles | 13:19 |
| zyga | right | 13:21 |
| zyga | but that's how it looks like | 13:21 |
| zyga | before setup profiles for sure | 13:21 |
| pedronis | 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:32 |
| Chipaca | any idea why 'snap run --strace snap.app args' would just print "exit status 1" | 13:35 |
| Chipaca | ? | 13:35 |
| pstolowski | pedronis: sure, np, thanks | 13:37 |
| zyga | Chipaca: hmmm, strace it ;) | 13:39 |
| zyga | jokes aside, probably no strace? | 13:39 |
| pedronis | pstolowski: I'm confused by ensureUniqureName, it seems to remove "-" when clearing the suffix, but is not adding "-" when attaching the suffix | 13:39 |
| mup | PR snapd#6115 opened: cmd: update autogen.sh for opensuse <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6115> | 13:40 |
| Chipaca | zyga: they have strace | 13:42 |
| pedronis | pstolowski: it seems to be by design, it's tested behavior, but is not documented/explained in the comment | 13:43 |
| zyga | pedronis: https://github.com/snapcore/snapd/pull/6116 is the simplified feature flag storage for snap-confine | 13:44 |
| mup | PR snapd#6116 opened: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116> | 13:44 |
| mup | PR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116> | 13:44 |
| Chipaca | zyga: https://dpaste.de/FNWL/raw | 13:44 |
| zyga | Chipaca: lookking | 13:44 |
| Chipaca | zyga: not helping :-) | 13:44 |
| zyga | Chipaca: denials | 13:44 |
| zyga | ? | 13:44 |
| zyga | Chipaca: if you want I can jump into standup HO and you can walk me through this in the next 15 minutes | 13:45 |
| pedronis | zyga: what's the context for that | 13:45 |
| pstolowski | 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 |
| zyga | pedronis: we need to learn about enabled experimental features from snap-confine and snap-update-ns | 13:45 |
| mup | PR #5782: ifacestate: helpers for generating slot names for hotplug <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5782> | 13:45 |
| zyga | pedronis: this is the idea that Gustavo presented (just stat a file) in response to the facts PR | 13:45 |
| pedronis | pstolowski: is not super clear from the discussion tough that it needs to be removed, if it's then not added | 13:46 |
| Chipaca | zyga: http://paste.ubuntu.com/p/XVVzYWNHR7/ | 13:46 |
| pedronis | pstolowski: the test for sure look weird | 13:46 |
| ogra | jdstrand, did you see https://bugs.launchpad.net/bugs/1802124 yet ? | 13:47 |
| mup | Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):New> <https://launchpad.net/bugs/1802124> | 13:47 |
| zyga | Chipaca: this is a snap in a container? | 13:48 |
| zyga | Chipaca: I suspect that may not work fully | 13:48 |
| zyga | Chipaca: ah, parallels VM | 13:49 |
| zyga | 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 |
| pedronis | pstolowski: also I would it work if the base name ends with digits? | 13:50 |
| jdstrand | ogra: uhh, there is extra code in this section | 13:50 |
| ackk | mvo, is "core" needed even if a snap depends on "core18" ? | 13:51 |
| pedronis | pstolowski: we trim only one digit? | 13:51 |
| pedronis | how do we know it's enough | 13:51 |
| ogra | jdstrand, yeah, sseems to be https://github.com/snapcore/snapd/commit/093b3662047123fe684a0d1dae27775593f1dc1f | 13:51 |
| jdstrand | 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 |
| mup | Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):New> <https://launchpad.net/bugs/1802124> | 13:51 |
| pedronis | pstolowski: this line is very weird: https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/hotplug_test.go#L243 | 13:51 |
| jdstrand | ogra: there is a commit after that which is meant to address archs without fp | 13:52 |
| ogra | ah | 13:52 |
| jdstrand | and with fp | 13:52 |
| mvo | ackk: you shouldn't need core if you just depend on core18 | 13:53 |
| ackk | mvo, that's weird, we have a (strict) snap that doesn't work if you don't have core | 13:54 |
| mvo | ackk: oh, please tell me more | 13:54 |
| mvo | ackk: how can I reproduce this? | 13:54 |
| pedronis | pstolowski: to be clear wasn't my intention to rehash already landed code, but this bit looks weird coming fresh to it | 13:54 |
| jdstrand | Chipaca: it looks like the policy isn't conditionally adding/removing the fp variants | 13:54 |
| ackk | mvo, https://pastebin.canonical.com/p/kTv7H5Q65Q/ | 13:55 |
| ackk | mvo, i have core18 installed only | 13:55 |
| ackk | if I install core, it works | 13:55 |
| pedronis | pstolowski: also that function is not used yet, is that right? | 13:55 |
| pstolowski | 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 |
| ackk | mvo, this is a proprietary snap unfortunately, lemme see if I can get you something that you can try | 13:55 |
| mvo | ackk: aha, interessting, I think you hit a bug, let me look at this | 13:55 |
| mvo | 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 |
| pstolowski | pedronis: it is used in the huge hotplug PR, but not in master yet, no | 13:56 |
| ackk | mvo, ah I see | 13:56 |
| zyga | ackk: interesting | 13:57 |
| zyga | we need to be told of the base explicitly | 13:57 |
| zyga | another thing we could fix with facts alone :/ | 13:57 |
| * zyga looks | 13:57 | |
| zyga | we pass --base every time there's a base defined in the snap | 13:58 |
| zyga | this is the code path used both by hooks and by apps | 13:58 |
| pedronis | pstolowski: why do we remove the "-" ? | 13:58 |
| pedronis | pstolowski: it just seems a mix of two version of the code, I don't understand how it relates to uniqueness | 13:58 |
| mvo | zyga: hm, apparently something is not quite wired up in the code path :/ | 13:59 |
| mvo | zyga: I do remember work on this | 13:59 |
| mvo | zyga: anyway, will look after the meeting | 13:59 |
| zyga | k | 13:59 |
| ackk | mvo zyga thanks | 13:59 |
| pedronis | 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 |
| zyga | mvo: what is odd is that for hooks we parse the revision | 13:59 |
| zyga | and use that | 13:59 |
| zyga | from snap.Revision | 13:59 |
| pstolowski | pedronis: that's not going to be a problem | 14:00 |
| zyga | for apps we just use R(0) | 14:00 |
| Chipaca | jdstrand: i thought zyga was looking into fixing the PTRACE thing, but yes | 14:00 |
| pstolowski | pedronis: at any given point the function is guaranteed to generate a unique name | 14:00 |
| pedronis | pstolowski: again, can base name end in numbers? | 14:00 |
| Chipaca | jdstrand: I fiddled with them because they failed to build | 14:00 |
| jdstrand | Chipaca: I don't know-- ogra pinged me about it | 14:00 |
| Chipaca | jdstrand: so now we have a runtime failure | 14:00 |
| Chipaca | because that's life | 14:00 |
| pedronis | pstolowski: to create, what, slot names? | 14:00 |
| pedronis | pstolowski: those also need not to too confusing | 14:01 |
| pstolowski | pedronis: do you mean "slot1234" ? | 14:01 |
| zyga | mvo: I'm sorry, hooks use --revision from snap run | 14:01 |
| zyga | not from snap info | 14:01 |
| pstolowski | pedronis: sorry, im confused by what do you mean by base? | 14:02 |
| kjackal | Hi snappy people, I am trying core18 because of the layouts and I get this error: "cannot update snap namespace: cannot create writable mimic over "/snap/microk8s/x1/": permission denie" | 14:03 |
| pedronis | pstolowski: you start from a name that might not be unique, I suppose the output of suggestedSlotName ? | 14:03 |
| pedronis | and then you make it unique | 14:03 |
| pstolowski | pedronis: yes that's right. btw, standup | 14:04 |
| jdstrand | zyga: so, we perhaps probably shouldn't be failing with error here. we ignore unknown syscalls. perhaps we should ignore these unknown PTRACE args. *or* we mock them up like with AF_IB, AF_MLPS, etc | 14:04 |
| jdstrand | zyga: honestly, I was surprised we didn't do the latter, but I wasn't involved in that build pr | 14:04 |
| zyga | (standup) | 14:05 |
| jdstrand | that's the extent of my thoughts | 14:05 |
| jdstrand | actually that's not true | 14:06 |
| jdstrand | zyga: readNumber could return something to signify skipping and continue the loop (silently ignore the rule) | 14:07 |
| zyga | not sure if this is what we should do, but I'll reply after the call | 14:08 |
| kjackal | jdstrand: I am following the your steps on for a strict microk8s. Got snapcraft 3.0 that has layouts, updated the snapctaft.yaml with base: core18, applied your patch. It seems to compile but failes in the install hook with https://pastebin.ubuntu.com/p/mcXnz52NkQ/ | 14:08 |
| jdstrand | kinda 6 of 1. AF_IB we use a #define. we could #define here, but is that #define the same across archs? if not, skip seems reasonable. I don't think I care for browser_support.go having to understand arch-specific details about fp/fpx | 14:09 |
| jdstrand | kjackal: sounds like there is an apparmor denial in the snap-update-ns profile. can you check you log? | 14:10 |
| jdstrand | zyga: ^ (6 of 1 comment; but also fyi kjackal's) | 14:11 |
| roadmr | jdstrand: hy there! Hey a question - for the purpose of e.g. snap track approval, who other than Gustavo and Mark qualifies as an architect? the post detailing this just says "etc" | 14:14 |
| kjackal | jdstrand: zyga: indeed there is this "audit[22699]: AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-upda | 14:21 |
| kjackal | te-ns.microk8s" name="/tmp/.snap/snap/microk8s/x1/" pid=22699 comm="3" srcname="/snap/microk8s/x1/" flags="rw, rbind" | 14:21 |
| kjackal | N" that does not tell me much | 14:21 |
| jdstrand | roadmr: no one. perhaps pedronis now? if we add pedronis, we should update the docs | 14:21 |
| roadmr | \o/ | 14:22 |
| roadmr | we should add him, he rocks :) | 14:22 |
| kjackal | This looks similar https://forum.snapcraft.io/t/core18-issues/5216 | 14:22 |
| jdstrand | kjackal: that is a different issue. I didn't test with core18. this might be a change relevant to that or new PRs in this area. actually, zyga did land some stuff to make it no longer experimental... need his input | 14:24 |
| zyga | I'm out of touch with this issue now | 14:24 |
| zyga | still in a call | 14:25 |
| zyga | is there a report about it anywhere or should I scan the backlog on irc? | 14:26 |
| jdstrand | zyga: there are two unrelated issues now. the fp/fpx that we discussed and a sun denial with microk8s using layouts with core18 | 14:27 |
| jdstrand | that kjackal brought up | 14:27 |
| zyga | jdstrand: aha, can we get a paste of the mount profile and of the apparmor profile for sun? | 14:28 |
| jdstrand | zyga: afaik, it is all backscroll | 14:28 |
| jdstrand | kjackal: ^ | 14:28 |
| zyga | kjackal: ^ if you know how to collect the two please do | 14:28 |
| zyga | kjackal: otherwise ask | 14:28 |
| zyga | kjackal: essentially /var/lib/snapd/apparmor/snap-update-ns.$foo | 14:28 |
| zyga | and /var/lib/snapd/mount/snap.$foo.fstab | 14:29 |
| zyga | jdstrand: I wrote a branch where I keep a log of all the ops done by snap-update-ns | 14:29 |
| zyga | I need to clean it up and propose | 14:29 |
| zyga | it is very useful for debugging | 14:30 |
| zyga | kjackal: you can also set SNAPD_DEBUG=1 and run the app to see more debug | 14:30 |
| jdstrand | zyga: sounds handy | 14:31 |
| === blackboxsw_away is now known as blackboxsw | ||
| zyga | mvo: so the issue | 14:36 |
| kjackal | wait up zyga. My guess is you want something from /var/lib/snapd/apparmor/profiles/ . This is where the snap-update-ns-* is . However I do not see snap-update-ns.microk8s. What is $foo? | 14:36 |
| mup | PR snapcraft#2397 opened: cmake plugin: use native primitives <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2397> | 14:36 |
| mup | PR snapcraft#2398 opened: gnome extension <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2398> | 14:36 |
| zyga | cachio: please just remind me how that was invoked, | 14:36 |
| kjackal | same for /var/lib/snapd/mount/snap.$foo.fstab | 14:36 |
| zyga | kjackal: $foo is snap name | 14:36 |
| zyga | kjackal: did this snap have a hook that exploded on install? | 14:36 |
| zyga | if so the installation would be reverted | 14:37 |
| zyga | kjackal: and the corresponding files removed | 14:37 |
| zyga | kjackal: if so my suggestion would be to remove all hooks to debug this (^ no way to install a snap without hooks or keep it broken) | 14:37 |
| zyga | mvo: so the issue | 14:37 |
| zyga | mvo: snap-confine runs snap-device-helper | 14:37 |
| zyga | mvo: with hardcoded locations | 14:37 |
| kjackal | ok, trying this now | 14:37 |
| zyga | mvo: that match core and ubuntu | 14:37 |
| zyga | mvo: this is done after pivot root, so in the mount namespace of the snap already | 14:39 |
| mvo | zyga: right, don't we bind mount things from the host (/usr/lib/snapd) into the base ? | 14:39 |
| zyga | mvo: yes that's right | 14:40 |
| * ogra hugs kyrofa | 14:40 | |
| * kyrofa hugs ogra back | 14:42 | |
| kyrofa | Seriously | 14:42 |
| ogra | yeah :) | 14:43 |
| zyga | DEBUG: performing operation: (disabled) use debug build to see details | 14:43 |
| * zyga _hates_ that part of snap-confine | 14:43 | |
| zyga | security in the way of usability | 14:43 |
| zyga | mvo: we don't bind mount it in this case, the base is "core" | 14:44 |
| zyga | mvo: so the fact that we cannot find it is surprising | 14:44 |
| mvo | zyga: yeah, that is surprising | 14:44 |
| zyga | DEBUG: snap-update-ns executable: /usr/libexec/snapd/snap-update-ns | 14:44 |
| zyga | perhaps we infer the wrong location? | 14:44 |
| mvo | zyga: yeah, that seems to be it - this runs on a libexec idstro? | 14:45 |
| zyga | useful debug logs from the fedora29 issue https://www.irccloud.com/pastebin/TTN36845/ | 14:45 |
| zyga | please have a look, I'm still reading as well | 14:45 |
| zyga | yes, fedora 29 | 14:45 |
| cachio | zyga, test-snapd-udev-input-subsystem.slot | 14:45 |
| roadmr | zyga: wow that fedora29 snap is like stitch, destroys everything it touches? | 14:46 |
| roadmr | :D | 14:46 |
| zyga | roadmr: destroys all bugs | 14:46 |
| roadmr | zyga: true that :) | 14:46 |
| zyga | https://www.youtube.com/watch?v=JTTwlAT_AwU | 14:47 |
| zyga | ha | 14:50 |
| zyga | mvo: I understand now | 14:50 |
| zyga | ar, wait, no :/ | 14:51 |
| zyga | hmmm | 14:51 |
| zyga | so | 14:51 |
| zyga | google:fedora-29-64 /# /usr/lib/snapd/snap-device-helper | 14:51 |
| zyga | -bash: /usr/lib/snapd/snap-device-helper: /usr/bin/sh: bad interpreter: No such file or directory | 14:51 |
| zyga | initially I thought this is PATH | 14:52 |
| zyga | but | 14:52 |
| zyga | the file has a wrong shbang | 14:52 |
| zyga | it says /usr/bin/sh! | 14:52 |
| zyga | not /bin/sh | 14:52 |
| zyga | google:fedora-29-64 /root# nsenter -m/run/snapd/ns/test-snapd-udev-input-subsystem.mnt | 14:53 |
| zyga | -bash: ls: command not found | 14:53 |
| zyga | -bash: /usr/libexec/grepconf.sh: No such file or directory | 14:53 |
| zyga | -bash: /usr/libexec/grepconf.sh: No such file or directory | 14:53 |
| zyga | -bash: sed: command not found | 14:53 |
| zyga | google:fedora-29-64 /# /bin/ls -l /usr/bin/sh | 14:53 |
| zyga | /bin/ls: cannot access '/usr/bin/sh': No such file or directory | 14:53 |
| zyga | google:fedora-29-64 /# /bin/ls -l /bin/sh | 14:53 |
| zyga | lrwxrwxrwx. 1 root root 4 Nov 8 14:18 /bin/sh -> dash | 14:53 |
| zyga | mvo: let me propose a quick PR | 14:53 |
| ogra | fancy | 14:53 |
| mvo | zyga: gar | 14:53 |
| zyga | oaoaaah? | 14:53 |
| zyga | what | 14:53 |
| zyga | the file has /bin/sh in the tree | 14:53 |
| roadmr | aioueee | 14:53 |
| mvo | zyga: yeah, I just did a git grep | 14:54 |
| mvo | zyga: this is strange | 14:54 |
| roadmr | (as long as we're resorting to guttural sounds) | 14:54 |
| zyga | mvo: | 14:54 |
| zyga | mvo: sorry, the file is from the host distro | 14:54 |
| zyga | fedora rewrites the shebang (apparently!) | 14:54 |
| zyga | but why would it be bind mounted there? | 14:54 |
| zyga | so we run with fedora29 version of snap-device-helper | 14:55 |
| zyga | so we must have did the bind mount for /usr/libexec/snapd /usr/lib/snapd | 14:55 |
| * zyga confirms | 14:55 | |
| zyga | mountinfo in the app mount ns https://www.irccloud.com/pastebin/qSQmhrPV/ | 14:56 |
| mup | PR snapd#6117 opened: overlord/ifacestate: don't remove the dash when generating unique slot name <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6117> | 14:58 |
| pstolowski | pedronis: ^ | 14:58 |
| zyga | mvo: there is no such mount | 14:58 |
| pedronis | thx | 14:58 |
| * zyga wonders | 14:58 | |
| cachio | zyga, mvo I need to go to take my son | 15:00 |
| mvo | zyga: hm, what snaps is that? | 15:00 |
| mvo | cachio: ok | 15:00 |
| zyga | mvo: so it's not mounted | 15:00 |
| zyga | the core snap is busted | 15:00 |
| zyga | https://www.irccloud.com/pastebin/3uE4g7eh/ | 15:00 |
| cachio | if you need a new machine just add fedora-29-64 to the spread.yaml | 15:00 |
| zyga | theory: in CI when we repackage core and inject snapd | 15:00 |
| zyga | the locally built snapd.rpm has replaced shebang | 15:01 |
| * zyga looks | 15:01 | |
| * cachio afk | 15:01 | |
| zyga | mvo: this would only break in CI | 15:01 |
| zyga | mvo: not in real world | 15:01 |
| zyga | real world doesn't inject snapd from RPM into core snap | 15:01 |
| mvo | zyga: aha, because we rewrite the core in ci | 15:01 |
| zyga | actually, I wonder what that was supposed to do | 15:01 |
| mvo | zyga: indeed | 15:01 |
| zyga | I sure hope we don't have both /usr/lib/snapd and /usr/libexec/snapd | 15:02 |
| * zyga checks that first | 15:02 | |
| zyga | mvo: confirmed, prepare.sh has | 15:03 |
| zyga | cp -a "$LIBEXECDIR"/snapd/* squashfs-root/usr/lib/snapd/ | 15:03 |
| zyga | so we take the host's rpm that was mangled | 15:03 |
| zyga | and inject that into the built package | 15:03 |
| zyga | this is broken | 15:04 |
| zyga | not only in the sense that this path is rewritten | 15:04 |
| zyga | snap-confine compiled on fedora is incompatible with core | 15:04 |
| zyga | I think we need to take a step back | 15:04 |
| zyga | without making snap-confine and other C programs compatible with every distribution | 15:04 |
| zyga | we cannot just insert them into the core snap during testing | 15:05 |
| zyga | they will expect different paths | 15:05 |
| zyga | it just happened to work because a path was hard-coded there | 15:05 |
| zyga | not using @libexecdir@ | 15:05 |
| zyga | but other parts will not be so useful | 15:05 |
| zyga | the binary is linked with fedora locations | 15:05 |
| zyga | it makes no sense to just inject it into a core snap with ubuntu chroot | 15:05 |
| zyga | mvo: let's have a call about this if you don't mind | 15:05 |
| zyga | I think our fedora testing story was super lucky so far :) | 15:06 |
| zyga | snap-confine ldd inside and out https://www.irccloud.com/pastebin/OkT431Pi/ | 15:07 |
| zyga | mvo: and even if we make it 100% unaware of the distribution configuration | 15:07 |
| zyga | things like libc version will be at play | 15:07 |
| zyga | as we move to fedora30 and beyond | 15:07 |
| zyga | snap-confine linked in fedora30 might not run on ubuntu 16.04 | 15:08 |
| zyga | I think the extent of testing fedora29 by repackaging core is a bit broken | 15:08 |
| zyga | we need to repackage core as if it was built on ubuntu | 15:08 |
| zyga | and test that | 15:08 |
| zyga | that's the realistic test IMO | 15:08 |
| zyga | mvo: I'll make coffee and let's have a call, ok? | 15:08 |
| mvo | zyga: let me finish some things here first, then yes | 15:09 |
| pstolowski | zyga: re hook issue & pre-refresh, can I help? what do we know so far (logs, a reproducer?) | 15:11 |
| zyga | pstolowski: I don't have a reproducer, didn't try | 15:14 |
| zyga | what we know is: | 15:15 |
| zyga | http://paste.ubuntu.com/p/MfKnvp8bD7/ | 15:15 |
| zyga | at the bottom | 15:15 |
| zyga | lines 865- | 15:15 |
| zyga | 865 says we didn't have the apparmor profile but we tried to execute a pre-refresh hook | 15:16 |
| zyga | then line 871 tells us we loaded (not replaced, loaded) the apparmor profile for the pre-refresh hook | 15:16 |
| zyga | that's all I know | 15:16 |
| kjackal | zyga: Just got the logs you asked https://pastebin.ubuntu.com/p/cRW8jX2XGM/ . Would you prefer a forum topic? | 15:17 |
| zyga | kjackal: something tracable, yes, may be a bug report or a forum post | 15:17 |
| zyga | kjackal: too many topics now :) | 15:17 |
| zyga | kjackal: can you also get the /var/lib/snapd/mount/snap.$foo.fstab please | 15:18 |
| kjackal | zyga: it is on the pastebin line 7, right? | 15:19 |
| zyga | ah | 15:19 |
| zyga | perfect | 15:19 |
| zyga | kjackal: let's have a bug report | 15:19 |
| zyga | bugs can be assigned | 15:19 |
| zyga | forum topics are swaaaamped | 15:19 |
| zyga | kjackal: I'm sorry, the issue with fedora is fundamental to our testing and development story | 15:20 |
| kjackal | where do you keep bug reports? | 15:20 |
| zyga | we need to tackle it | 15:20 |
| zyga | kjackal: launchpad.net/snapd please | 15:20 |
| kjackal | yes no worries | 15:20 |
| kjackal | thanks | 15:20 |
| zyga | mvo: ready when you are | 15:20 |
| zyga | mvo: https://meet.google.com/mcs-qqzz-idp?authuser=0 | 15:21 |
| pstolowski | zyga: thanks, i'll see if i can find anything | 15:23 |
| zyga | mvo: I wrote a quick summary | 15:29 |
| pstolowski | zyga: can we have state.json for the hook issue? | 15:29 |
| zyga | https://www.irccloud.com/pastebin/QhF9iWhq/ | 15:29 |
| zyga | pstolowski: yes | 15:29 |
| zyga | https://www.irccloud.com/pastebin/nYonNbqH/ | 15:30 |
| zyga | pstolowski: we analysed that and determined that task timestamps are not super useful because of undo | 15:31 |
| zyga | we should store undo timestamps separately | 15:31 |
| zyga | pedronis: ^ for debugging we should probably store undo timestamps in the state | 15:31 |
| pstolowski | zyga: this state is missing waittasks/halttask and is generally stipped down; do we have a complete state? | 15:37 |
| mup | PR snapcraft#2399 opened: Cmake find root build snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2399> | 15:39 |
| mvo | ackk: hm, I may need access to your snap afterall, I wrote a testcase with a configure hook and core18 only and it works for me | 15:40 |
| ackk | mvo, ok, hold on | 15:41 |
| mvo | ackk: also please pastebin "snap version" | 15:45 |
| Chipaca | mvo: silly question that i could probably answer with grep: where's the snapd sanity check? | 15:50 |
| mvo | Chipaca: sanity/check.go iirc | 15:50 |
| Chipaca | mvo: thanks | 15:51 |
| diddledan | zyga or jdstrand, can you help with dbus ownership? on ubuntu transmission-gtk doesn't need a slot but on kubuntu it seems to require a defined slot. also transmission-qt and transmission-gtk both use the same dbus name, so we're wondering if the store allows two snaps to have the same dbus slot definition? | 15:59 |
| thresh | A tool snapcraft depends on could not be found: 'execstack'. | 15:59 |
| thresh | is that something I miss from the docker image I build? | 16:00 |
| thresh | I see that package is in debian, but not in ubuntu | 16:02 |
| thresh | hm, it's actually in universe, but not shown on packages.ubuntu.com | 16:04 |
| thresh | and it's actually installed | 16:04 |
| sparkiegeek | packages.ubuntu.com is broken atm | 16:05 |
| sparkiegeek | https://bugs.launchpad.net/pkg-website/+bug/1801518 | 16:05 |
| mup | Bug #1801518: Search is broken <pkg-website:Confirmed> <https://launchpad.net/bugs/1801518> | 16:06 |
| thresh | oic | 16:06 |
| kjackal | zyga: Here is the bug on microk8s https://bugs.launchpad.net/snapd/+bug/1802332 | 16:07 |
| mup | Bug #1802332: Apparmor complains in strict confinement with base: core18 <snapd:New> <https://launchpad.net/bugs/1802332> | 16:07 |
| thresh | here's the snapcraft output on execstack: https://code.videolan.org/snippets/871 | 16:07 |
| zyga | kjackal: thank you | 16:07 |
| thresh | I don't have /usr/sbin in $PATH, too | 16:07 |
| kjackal | jdstrand: I noticed that "kernel-module-observe" is not available but your patch had it there. Should I know anything about it? Merged with something else? Renamed? Not needed? | 16:08 |
| kjackal | I am not in the position yet to see what breaks and what works, just asking because I had to comment it out | 16:09 |
| mup | PR snapd#6118 opened: tests: add core18 only hooks test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6118> | 16:17 |
| Chipaca | pstolowski: where does the stdout/stderr of hooks go? | 16:18 |
| zyga | mvo: actually | 16:21 |
| zyga | mvo: on fedora29 running core18 test the same bug will happen; we need to switch the bind mount to use core's or snap's version of /usr/lib/snapd | 16:22 |
| zyga | the bind mount used for bases | 16:22 |
| ogra | Chipaca, the journal (at lest i find the output of mine there regulary) | 16:22 |
| zyga | I realised while cleaning up the notes | 16:22 |
| mvo | zyga: indeed | 16:22 |
| sparkiegeek | ogra: clue for where abouts? | 16:22 |
| mvo | zyga: we need the snapd snap | 16:22 |
| ogra | sparkiegeek, journalctl -f ... then install/rmove7configure the snap in another terminal | 16:22 |
| ogra | *install/remove/configure | 16:23 |
| pedronis | zyga: we need a bug or forum post on that or it will get lost | 16:23 |
| pedronis | I mean storing undo timestamps | 16:23 |
| zyga | I'm doing that now | 16:23 |
| zyga | ah | 16:23 |
| sparkiegeek | ogra: doesn't seem to help :( | 16:23 |
| zyga | I'm not doing that now | 16:23 |
| zyga | I will file a bug yes | 16:24 |
| zyga | I'm writing a post about the issue Sergio found and we just debugged with mvo | 16:24 |
| * pedronis was in a longish meeting | 16:24 | |
| pedronis | zyga: anyway if undo is involved, then might well be the issue that would be solved by merging *-profiles with *link* | 16:25 |
| zyga | pedronis: I don't think the issue is related to undo | 16:25 |
| pedronis | ah ok | 16:25 |
| zyga | it's just that we have fewer bits of data about it to debug clearly from timestamps alone | 16:25 |
| zyga | we know for sure from kernel logs that we ran a hook before we setup security | 16:25 |
| zyga | pstolowski: ^ actually this makes sense :D | 16:26 |
| pedronis | yes, but not having security when we should and undo | 16:26 |
| zyga | that hook should run before we setup security | 16:26 |
| zyga | because security setup will switch the world for the NEXT revision of the snap | 16:26 |
| pedronis | are the a possible of form of the bug | 16:26 |
| pstolowski | Chipaca: to task's log i believe, however there is a catch afair, it only goes there if hook fails | 16:26 |
| zyga | pedronis: yes, in this particular case we didn't have security because that snap was not installed yet, the bug is that we ran the hook at all, not that we didn't have security | 16:26 |
| ogra | sparkiegeek, weird, i always see mine ... though i'm typically watching on UC ... not sure if thats any different (i wouldnt expect so though) | 16:26 |
| pedronis | ah, interesting | 16:27 |
| pedronis | ok | 16:27 |
| zyga | (we had nil security because that's the first install, we ran the pre-refresh hook of the installed snap in this nil security before we proceeded to setup security for the revision being installed) | 16:27 |
| zyga | I'll add this to the reporty | 16:27 |
| pstolowski | zyga: this is super weird, it could only happen if we had a snap in snapstate but it wasn't actually installed (?), in which case IsInstalled() would lie | 16:29 |
| zyga | but we do | 16:30 |
| zyga | we are installing it | 16:30 |
| zyga | do we have a test for this situation | 16:30 |
| zyga | snap install snap-with-pre-refresh-hook | 16:30 |
| zyga | perhaps it ends up in snap state too early | 16:30 |
| pstolowski | zyga: that would mean we have other serious issues | 16:31 |
| pstolowski | zyga: we have a bunch of checks around isInstalled | 16:31 |
| zyga | pstolowski: it would be good to try this. case | 16:31 |
| zyga | make a simple snap with pre-refresh hook | 16:31 |
| zyga | and install it | 16:31 |
| pstolowski | zyga: ok, i'll do this | 16:31 |
| mup | PR snapd#6119 opened: sanity: refuse to try to do things on WSL <Created by chipaca> <https://github.com/snapcore/snapd/pull/6119> | 16:33 |
| Chipaca | mvo: ^ my sanity question was about this | 16:33 |
| pstolowski | zyga: wait, we do have spread test already | 16:33 |
| zyga | mvo: https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394 | 16:33 |
| zyga | mvo: please sign off that you agree with what it says | 16:34 |
| zyga | you can edit it I believe | 16:34 |
| zyga | pstolowski: then I don't know | 16:34 |
| zyga | pstolowski: chase this with chipaca tomorrow please | 16:34 |
| zyga | we need to reproduce it really | 16:34 |
| pstolowski | zyga: install-refresh-remove-hooks | 16:34 |
| zyga | pstolowski: maybe interplay with other hooks is important | 16:35 |
| zyga | try making a quick test with just one hook | 16:35 |
| pstolowski | ok | 16:35 |
| zyga | and base (not sure if relevant) | 16:35 |
| pstolowski | zyga: just one hook - pre-refresh - worked. does the hook need to do anything to trigger profile issue? | 16:37 |
| zyga | no | 16:37 |
| zyga | it would not be able to execute at all | 16:37 |
| pstolowski | right, it's snap-confine erroring early | 16:37 |
| pstolowski | zyga: just pre-refresh hook, without base, and with base:core18, both worked | 16:44 |
| Chipaca | zyga: chase what? (scrollback from where?) | 16:44 |
| pstolowski | zyga: do you have full state.json? | 16:44 |
| zyga | pstolowski: I don't have anything else, it's all from backlog in this channel | 16:44 |
| zyga | Chipaca: that bug with pre-refresh-hook | 16:44 |
| zyga | pedronis, Chipaca: related to this bug I filed https://bugs.launchpad.net/snapd/+bug/1802339 | 16:45 |
| mup | Bug #1802339: Tasks should carry separate timestamps for undo paths <snapd:New> <https://launchpad.net/bugs/1802339> | 16:45 |
| pstolowski | zyga: who reported it originally? | 16:45 |
| zyga | pstolowski: someone from the sprint Chipaca is at | 16:45 |
| zyga | Chipaca: wanna see something terrible | 16:45 |
| pstolowski | aha | 16:45 |
| zyga | https://forum.snapcraft.io/t/issue-with-repackaged-core-and-testing/8394 | 16:46 |
| zyga | kaboom | 16:46 |
| pedronis | we already discussed that ^ in the past | 16:46 |
| pedronis | we also said it was going to bite us at some point | 16:46 |
| mvo | Chipaca: \o/ | 16:47 |
| * zyga needs to break for a while to vent | 16:48 | |
| pedronis | zyga: also that post doesn't list snap-exec, doesn't it always come from the base? | 16:49 |
| pedronis | or is that the bind mount bit? | 16:50 |
| pstolowski | Chipaca: can you find who that was reporting pre-refresh issue, and get more info? state.json for starters | 16:51 |
| Chipaca | pstolowski: which pre-refresh issue? | 16:52 |
| Chipaca | gah | 16:52 |
| * Chipaca reads backlog again | 16:52 | |
| Chipaca | ah | 16:54 |
| pstolowski | Chipaca: somebody hit an issue where pre-refresh hook was run without security profile (=failed with denials), as if snap wasn't installed. in theory (and according to the code) this hook should run of old revision of the snap, before switching to new revision on refresh | 16:54 |
| pstolowski | s/run of/run for/ | 16:55 |
| Chipaca | was this related to the dmesg -H pastebin? | 16:55 |
| pstolowski | Chipaca: the lof is http://paste.ubuntu.com/p/MfKnvp8bD7/ | 16:55 |
| pstolowski | *log | 16:55 |
| Chipaca | ah yes | 16:56 |
| pstolowski | Chipaca: pastebin from "joao" | 16:56 |
| Chipaca | yes | 16:56 |
| Chipaca | pstolowski: i'll get the state.json | 16:57 |
| === dkessel_ is now known as dkessel | ||
| Chipaca | pstolowski: zyga: for extra fun, they got the same thing again in the post-refresh hook, afterwards | 17:01 |
| Chipaca | pstolowski: zyga: i've send you guys the state json | 17:01 |
| Chipaca | niemeyer: github is rate-limiting us which is why sometimes travis statuses don't make it back | 17:02 |
| Chipaca | niemeyer: e.g. https://github.com/snapcore/snapd/pull/6107 | 17:02 |
| mup | PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107> | 17:02 |
| Chipaca | niemeyer: i have logs to prove it | 17:02 |
| pstolowski | Chipaca: very curious. can you look around if their installations is sane? we use IsInstalled() check for this hooks, i cannot think of a case where this would lie, except for some inconsistency? | 17:02 |
| Chipaca | niemeyer: can youchat with them and ask them to bump our limits a bit? | 17:02 |
| Chipaca | niemeyer: i'll fwd the email | 17:03 |
| Chipaca | with the logs | 17:03 |
| pstolowski | thanks for the state, lookiing | 17:03 |
| pedronis | if it's that, yes IsInstalled returning true for non installed snap would be very weird | 17:04 |
| niemeyer | Chipaca: Huh.. curious | 17:04 |
| sparkiegeek | is it possible to delete a configuration key for a snap? i.e. 'snap set mysnap foo=bar; snap set mysnap foo=; snap get mysnap | grep foo' returning no hits | 17:05 |
| niemeyer | Chipaca: Thanks, will follow up | 17:05 |
| pedronis | sparkiegeek: not at the moment | 17:06 |
| pstolowski | Chipaca, pedronis, zyga from quick glance at the state, they seem to be using try mode quite a bit, which i hinted could be a factor, i think this is the first suspect | 17:07 |
| Chipaca | try mode + hooks = bad news? | 17:07 |
| Chipaca | that's a big bummer | 17:08 |
| Chipaca | what's the situations in which it'd fail? | 17:08 |
| Chipaca | pstolowski: ^ | 17:08 |
| pstolowski | Chipaca: they should work obviously; is IsInstalled check correct for try mode? | 17:08 |
| pedronis | Chipaca: try on top of a try, is really a refresh | 17:09 |
| Chipaca | pedronis: yes | 17:09 |
| pedronis | but if the two use the same dir | 17:09 |
| Chipaca | ah | 17:09 |
| pedronis | not sure what it means | 17:09 |
| Chipaca | ok, i'll see if this helps | 17:09 |
| pedronis | Chipaca: one thing to try, snap try something without a prerefresh hook | 17:09 |
| pedronis | now you try the same dir but you added a prerefresh hook | 17:09 |
| pedronis | I suppose: boom | 17:09 |
| pedronis | I feel their pain, but is not quite trivial to solve either | 17:10 |
| pedronis | we would need to remember things that atm we don't care to | 17:11 |
| Chipaca | where's our CoW support a t | 17:11 |
| Chipaca | at* | 17:11 |
| Chipaca | the dev isn't blocked on this, fwiw, so there's not that much urgency | 17:11 |
| Chipaca | but it does seem to match what we were seeing | 17:12 |
| pedronis | Chipaca: or yes, take a snapshot somehow , unclear when or how | 17:12 |
| Chipaca | pedronis: they were doing try+try to test the pre- and post-refresh hooks :-) | 17:13 |
| pedronis | doesn't quite work | 17:13 |
| pedronis | they need a 2nd checkout | 17:13 |
| pedronis | atm | 17:13 |
| pedronis | I fear | 17:13 |
| pedronis | I suppose it can of works | 17:13 |
| pedronis | if there are no interfaces involved | 17:13 |
| pedronis | anyway is not a well supported/understood case by our code | 17:14 |
| pedronis | try is really a best effort big hammer | 17:14 |
| pedronis | I suppose we should at least document this kind of sharp edges somewhere | 17:14 |
| mup | PR snapcraft#2400 opened: tests: fix maven spread test <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2400> | 17:15 |
| pedronis | Chipaca: can we get a bug or forum post on this now that is better understood? | 17:16 |
| pedronis | otherwise it will wash away | 17:16 |
| Chipaca | pedronis: i'll give it a try | 17:17 |
| * Chipaca would giggle but is too tired | 17:17 | |
| pstolowski | it's interesting, i've just tested this scenario (snap try without pre-refresh, then snap-try with pre-refresh, same dir), it fails but differently | 17:17 |
| pstolowski | Run pre-refresh hook of "snap-hooks" snap if present (run hook "pre-refresh": cannot stat /var/lib/snapd/seccomp/bpf/snap.snap-hooks.hook.pre-refresh.bin: No such file or directory | 17:18 |
| pstolowski | and after a few minutes, after timeout | 17:18 |
| pstolowski | no denials | 17:18 |
| mup | PR snapcraft#2401 opened: ci: reduce spread system declarations <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2401> | 17:18 |
| Chipaca | hmm | 17:19 |
| pedronis | pstolowski: does it have an interface that hook? | 17:19 |
| pedronis | I mean needs to need an interface to get a denial | 17:19 |
| popey | ondra: your avahi-client snap - should I be able to see avahi advertised services in the office? | 17:19 |
| pstolowski | pedronis: no hook, only home interface | 17:19 |
| pedronis | anyway it's similar but different | 17:20 |
| pedronis | maybe they did enough to have a bf | 17:20 |
| pedronis | bpf | 17:20 |
| pedronis | in their case | 17:20 |
| pedronis | but not the right apparmor profile | 17:20 |
| pedronis | yet | 17:20 |
| mup | PR snapcraft#2402 opened: packaging: update requests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2402> | 17:21 |
| pstolowski | right. anyway, good that we know it's snap try | 17:22 |
| * pedronis eoding | 17:22 | |
| pstolowski | eod as well | 17:22 |
| pstolowski | cu | 17:22 |
| === pstolowski is now known as pstolowski|afk | ||
| ondra | popey yep | 17:24 |
| ondra | popey that is exactly it's purpose :) | 17:24 |
| Chipaca | pstolowski|afk: pedronis: zyga: https://forum.snapcraft.io/t/snap-try-snap-try-hooks-fun/8400 | 17:24 |
| popey | ondra: how do you operate it? | 17:24 |
| ondra | popey but easier to use snappy-discover | 17:25 |
| popey | ooh | 17:25 |
| pstolowski|afk | Chipaca: thanks! s/-remove/-refresh/ | 17:25 |
| ondra | popey then no need to use params | 17:25 |
| ondra | popey mind, UC device needs to run avahi in first place :) | 17:25 |
| Chipaca | d'oh | 17:26 |
| popey | not on core | 17:26 |
| * Chipaca should've EOWed after lunch | 17:26 | |
| ondra | popey ok then avahi-client | 17:26 |
| ondra | popey what is device's name> | 17:26 |
| ondra | ? | 17:26 |
| popey | ondra: Volumio | 17:27 |
| popey | ah, avahi-client has a bunch of not-automatically-connected interfaces | 17:28 |
| ondra | popey yeah you need to connect manually | 17:28 |
| ondra | popey 10.20.65.140, 10.20.65.210 | 17:28 |
| popey | what did you do? | 17:28 |
| ondra | popey on macOS lanscan | 17:29 |
| popey | wrong answer :) | 17:29 |
| ondra | popey it does whole scan | 17:29 |
| popey | I'm trying to prove avahi on snap | 17:29 |
| popey | we have a broken snap and trying to prove avahi in snap works | 17:29 |
| ondra | popey OK let me get you right command | 17:29 |
| hackedhead | are there instructions for installing the snap system from source? (my distro doesn't ship with a package: Slackware) | 17:32 |
| popey | hackedhead: great question. I'd love to see a doc for bootstrapping snapd from sauce | 17:34 |
| popey | Chipaca: ^ :D | 17:34 |
| Chipaca | 1. get systemd | 17:34 |
| popey | 2. ??? | 17:34 |
| Chipaca | 3. profit | 17:34 |
| * Chipaca wins | 17:35 | |
| ondra | popey avahi-client.browse -a | grep Volumino | 17:36 |
| cachio | Chipaca, hey, any idea about what could be causing this on rpi 3: https://paste.ubuntu.com/p/B9RsstFFwj/ | 17:37 |
| Chipaca | cachio: yes | 17:37 |
| cachio | Chipaca, :) | 17:38 |
| ogra | popey, avahi in snaps does not work ... i started a thread about it a month or two ago | 17:40 |
| Chipaca | cachio: mozilla broke snapd on non-intel architectures, and we let them | 17:40 |
| cachio | Chipaca, nice | 17:40 |
| Chipaca | cachio: i thought zyga was fixing this but apparently no | 17:40 |
| ogra | popey, here is a hack in a wrapper script https://github.com/ogra1/dashkiosk-client-browser/blob/master/chromium.launcher ... and here is the thread https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603 | 17:41 |
| ondra | ogra what? what do you mean? | 17:41 |
| popey | oddly my machine can't see any avahi things | 17:41 |
| popey | another laptop can! | 17:41 |
| popey | on the same network | 17:41 |
| ogra | ondra, snaps can not use mdns due to nsswitch.conf | 17:41 |
| ondra | ogra ah, that's when you want to use libc | 17:41 |
| cachio | Chipaca, good to know, thanks | 17:42 |
| * zyga lost track of things to fix | 17:42 | |
| popey | typo, works now | 17:42 |
| ondra | ogra avahi client still works | 17:42 |
| ogra | popey, you can use layouts to overcome that but that means you are forced to snapcraft 3.0 and core18 | 17:42 |
| zyga | Sorry about that chipaca | 17:42 |
| ogra | ondra, sure ... | 17:42 |
| Chipaca | cachio: ¯\_(ツ)_/¯ | 17:42 |
| ondra | ogra core 18? | 17:42 |
| Chipaca | cachio: i think this blocks 2.36 | 17:42 |
| ogra | ondra, <popey> we have a broken snap and trying to prove avahi in snap works | 17:42 |
| ogra | ondra, yes, for layouts without passthrough | 17:42 |
| Chipaca | zyga: no problem | 17:43 |
| Chipaca | zyga: i mean | 17:43 |
| Chipaca | zyga: i'm very tired, i'm probably not the only one | 17:43 |
| Chipaca | i might just work half a day tomorrow | 17:43 |
| zyga | are you fixing the ptrace bug? | 17:45 |
| zyga | Can you file it please, even a small bug for tracking | 17:45 |
| zyga | I think we need to fix our ability to store, triage and react to issues | 17:46 |
| jdstrand | zyga: you mentioned 2.36.1 will be released today. I don't think it can be released if the fp/fpx ptrace issue is present since if it goes to stable, you'll blow up kiosks | 17:46 |
| jdstrand | zyga: perhaps it is best to revert the PRs if you don't have time. then reintroduce in 2.36.2 | 17:46 |
| zyga | Ack | 17:47 |
| Chipaca | zyga: go for it | 17:47 |
| zyga | I agree but I don’t know if the issue is in edge/master only | 17:47 |
| zyga | Or also in the release branch | 17:48 |
| Chipaca | didn't 2.36 already inlcude the fp/fpx thing? | 17:48 |
| zyga | Chipaca: ack, the bug is on me now | 17:48 |
| Chipaca | zyga: i meant go for filing it | 17:48 |
| zyga | I don’t remember Chipaca | 17:48 |
| jdstrand | zyga: actually, it seems it is only in master. I just checked out 2.36 and don't see the code. sorry | 17:48 |
| Chipaca | zyga: remember what | 17:49 |
| zyga | I’m taking the dog out now, took a break before. After I am back I will report the bug, check if it present in the release branch and coordinate with mvo | 17:49 |
| * Chipaca is confused | 17:49 | |
| Chipaca | zyga: ah | 17:49 |
| Chipaca | zyga: walk away | 17:49 |
| Chipaca | zyga: okk | 17:49 |
| zyga | Chipaca, IRC is slow from phone | 17:49 |
| zyga | Sorry about that | 17:49 |
| Chipaca | zyga: i'll fix tomorrow if you haven't by the time i wake up | 17:50 |
| Chipaca | i plan to not wake up early | 17:50 |
| zyga | Ok | 17:50 |
| Chipaca | :-) | 17:50 |
| zyga | Good plan | 17:50 |
| * Chipaca hasn't felt this tired in a while | 17:50 | |
| zyga | I keep doing 1-2am | 17:50 |
| zyga | :/ | 17:50 |
| Chipaca | have i mentioned how being in a room full of people tires me out? :-) | 17:50 |
| Chipaca | and that, yes :-D | 17:50 |
| zyga | Hey | 17:52 |
| zyga | At least you are not sharing a room this week :-) | 17:52 |
| mup | PR snapcraft#2396 closed: Partial Revert "build providers: fix osx non base and injection" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2396> | 17:54 |
| pedronis | jdstrand: I don't think, we meant released to stable, 2.36 didn't even make it to candidate | 17:58 |
| pedronis | unless me is very confused | 17:58 |
| pedronis | jdstrand: I think mvo meant pushing .1 to beta | 17:59 |
| pedronis | or so I hope | 17:59 |
| zyga | re | 18:06 |
| zyga | pedronis: that's correct | 18:06 |
| mvo | zyga: ok | 18:12 |
| mvo | pedronis: yeah, the plan is to push .1 today but I will wait for zyga to get back to me about this issue that jdstrand described (fp/fpx) | 18:13 |
| zyga | mvo: on that now | 18:14 |
| zyga | mvo: release branch is not affected | 18:18 |
| zyga | go for .1 | 18:18 |
| zyga | I'll fix the master issue | 18:18 |
| zyga | Chipaca, jdstrand: FYI filed as https://bugs.launchpad.net/snapd/+bug/1802362 | 18:18 |
| mup | Bug #1802362: browser-support broken on certain arches due to ptrace <snapd:In Progress by zyga> <https://launchpad.net/bugs/1802362> | 18:18 |
| Chipaca | zyga: ACK | 18:18 |
| Chipaca | EOD from me (mostly) | 18:19 |
| mvo | zyga: ta | 18:26 |
| * zyga pours a glass of Jim beam and gets to work | 18:27 | |
| zyga | pedronis: I saw your comment on the forum. I will respond and improve the post tomorrow. Today I just want to wrap up | 18:29 |
| jdstrand | mvo, pedronis: yeah I mispoke, 2.36 isn't affected by the fp/fpx | 18:54 |
| jdstrand | zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124 already existed for that | 18:55 |
| mup | Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1802124> | 18:55 |
| jdstrand | zyga: I also think your conclusion in your bug is wrong. just like with AF_IB or or that set_tls is an arm-specific call, the policy shouldn't be arch specific. the backend should be smarter | 18:58 |
| zyga | I think I swing towards that conclusion as well now | 18:58 |
| zyga | it's easier to handle on that end | 18:59 |
| jdstrand | zyga: yeah. a profiler should only have to worry about policy being safe or not. the backend can just be smart about archs | 18:59 |
| jdstrand | zyga: cool, thanks | 18:59 |
| zyga | thank you :) | 18:59 |
| sborovkov | Hello, is the kernel with B+ support released to stable? | 19:00 |
| jdstrand | zyga: not sure who will be assigned to that, but ahppy to review it (I can't jump on it right away, otherwise I would) | 19:00 |
| zyga | I am fixing it now | 19:00 |
| zyga | just trying to make sure I understand it and can see the fix working | 19:01 |
| mvo | zyga: how do I reset the mount namespaces again? I suspect I Know why my test is not reproducing the core failure that ack reported | 19:23 |
| zyga | mvo: just use snap-discar-dns | 19:24 |
| zyga | discard-ns | 19:24 |
| zyga | mvo: /usr/lib/snapd/snap-discard-ns snap-name | 19:24 |
| mvo | zyga: no args? | 19:24 |
| zyga | note that it does more than it used to long time ago so please use that rather than work on unmounting the mount namespace alone | 19:24 |
| zyga | just the snap name | 19:24 |
| ijohnson | zyga: does discard-ns also undo the device cgroup setup for a snap? | 19:25 |
| zyga | no | 19:25 |
| zyga | interesting | 19:25 |
| ijohnson | is there a command that does that? | 19:25 |
| zyga | nope | 19:26 |
| zyga | we never remove them | 19:26 |
| zyga | ijohnson: (feels like a bug) | 19:26 |
| ijohnson | I currently have had to just reboot my machine to get it to go away after uninstalling a snap with the device cgroup on it | 19:26 |
| ijohnson | shall I file a bug about it? | 19:26 |
| zyga | please | 19:27 |
| ijohnson | okay, will do in a bit, about to go out for lunch | 19:27 |
| zyga | ijohnson: AFAIK that's been true since snapd got started | 19:27 |
| zyga | ijohnson: I have some related work on refreshes pending | 19:27 |
| zyga | so I think we can fix it then | 19:27 |
| ijohnson | okay cool | 19:28 |
| zyga | ijohnson: you can stop rebooting | 19:28 |
| zyga | it should be easy to clean up for development | 19:28 |
| ijohnson | yeah I'm sure there's a way I haven't looked into it too much yet though | 19:29 |
| * ijohnson -> lunch | 19:29 | |
| mvo | zyga: I'm afraid we need something like 6118 for 2.36 | 19:57 |
| zyga | looking | 19:57 |
| mvo | zyga: i.e. on classic we have the quirks code in snap-confine that always assumes core | 19:58 |
| zyga | mmmm | 19:58 |
| zyga | I think that should only run on core, not on core18 | 19:58 |
| zyga | quirks need to die | 19:58 |
| zyga | they are useless now | 19:58 |
| zyga | so I suspect we could just ditch them | 19:58 |
| zyga | lxd is a snap | 19:59 |
| mvo | zyga: fair enough, I can fix the PR | 19:59 |
| zyga | I'm sorry that it lived for so long | 19:59 |
| zyga | let me read the PR in full | 19:59 |
| zyga | mvo: the patch looks good | 20:01 |
| zyga | I don't oppose merging it | 20:01 |
| zyga | we should follow up with removal of quirks for base != "core" | 20:01 |
| mvo | zyga: thanks, lets see if CI is happy too | 20:01 |
| zyga | that is, quirks only on classic when running against core | 20:01 |
| zyga | I suspect we could sync with stgraber and remove it entirely now | 20:01 |
| zyga | quirks exist for one reason: | 20:01 |
| zyga | allow lxd from the host to be visible in the snap | 20:01 |
| zyga | specifically the socket | 20:01 |
| zyga | but I think the socket moved since | 20:01 |
| mvo | zyga: oh, nice | 20:02 |
| zyga | for super compatibility I would probably stick to deprecation | 20:02 |
| mvo | zyga: well, I can trivially add "if base_snap_name == "core" to the PR | 20:02 |
| zyga | but maybe we can skip ahead and just drop it | 20:02 |
| zyga | yeah, plese | 20:02 |
| zyga | once green | 20:02 |
| stgraber | zyga: what's that? | 20:02 |
| zyga | I don't want to derail evening | 20:02 |
| zyga | stgraber: hey, | 20:02 |
| zyga | stgraber: we have a quirk in snapd that puts /var/lib/lxd from the host into the snap mount namespace | 20:02 |
| stgraber | that wasn't for lxd | 20:03 |
| zyga | it was added to allow snaps to talk to lxd socket that is otherwise not visible in the core snap (/var/lib/lxd doesn't even exist there) | 20:03 |
| zyga | no? | 20:03 |
| zyga | what was it for? | 20:03 |
| stgraber | the LXD snap never accessed /var/lib/lxd | 20:03 |
| zyga | (mental shortcut: it was for snaps that want to talk to lxd) | 20:03 |
| stgraber | well, lxd.migrate does but it always used /var/lib/snapd/hostfs/var/lib/lxd | 20:03 |
| zyga | where does lxd keep the socket now? | 20:04 |
| stgraber | yeah, probably was for some other random snaps that wanted to talk to a non-snap LXD on the host, no idea what those would be | 20:04 |
| zyga | stgraber: that's correct | 20:04 |
| zyga | it was behind an interface access so we could probably check too | 20:04 |
| zyga | (across store snaps) | 20:05 |
| zyga | where does lxd store the socket now? | 20:05 |
| stgraber | these days, they should be using the LXD snap anyway, socket would be at /var/snap/lxd/common/lxd/unix.socket | 20:05 |
| mvo | ackk: 6118 has a fix, thanks for reporting the core18 only bug | 20:05 |
| stgraber | lxd-client interface gets you access to that | 20:05 |
| zyga | stgraber: thank you | 20:05 |
| zyga | mvo: I just checked the interface | 20:06 |
| stgraber | if someone really needs to talk to the non-snap LXD, I guess a lxd-deb-client interface or something could be introduced that gets you /var/lib/snapd/hostfs/var/lib/lxd/unix.socket | 20:06 |
| zyga | there is no interface that grants access to /var/lib/lxd anymore | 20:06 |
| zyga | I think we can remove this quirk entirely now | 20:06 |
| zyga | stgraber: I agree | 20:07 |
| zyga | jdstrand: FYI, based on the discussion above I think we can remove the quirk for /var/lib/lxd | 20:07 |
| zyga | mvo: let's go ahead with your fix as-is | 20:07 |
| zyga | and then clean up by removing the whole hack | 20:07 |
| zyga | along with extra permissions | 20:07 |
| zyga | tests and what not | 20:07 |
| mvo | zyga: ok, lets see what CI says | 20:34 |
| zyga | I took forever to boot a pi3 | 20:34 |
| zyga | to ensure that ptrace issue is fixed | 20:35 |
| zyga | but it's not for the release so no stress | 20:35 |
| zyga | mvo: offtopic, I think we may strip our snapd bits | 20:39 |
| zyga | I wonder what's the size of snapd.snap with stripped go | 20:39 |
| ackk | mvo, great, thank you for the fix | 20:41 |
| mvo | zyga: good point | 20:42 |
| mvo | zyga: strip> yeah | 20:56 |
| mvo | zyga: tests still running, I check the PR in the morning, need sleep :/ | 20:56 |
| zyga | ok | 20:56 |
| zyga | ttyl | 20:56 |
| * mvo waves | 20:57 | |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/6120 | 21:10 |
| zyga | not sure if it will pass | 21:10 |
| mup | PR #6120: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <https://github.com/snapcore/snapd/pull/6120> | 21:10 |
| zyga | it works on armv7 | 21:10 |
| zyga | (and on amd64) | 21:11 |
| mup | PR snapd#6120 opened: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <https://github.com/snapcore/snapd/pull/6120> | 21:11 |
| zyga | thanks to chipaca's brilliant cross-built test suite we will know soon if it passes on other arhces | 21:11 |
| zyga | *arches | 21:11 |
| zyga | jdstrand: anyway, I'll EOD now, please let me know what you think about this patch | 21:11 |
| zyga | jdstrand: can you look at the update on https://github.com/snapcore/snapd/pull/6120 | 21:57 |
| mup | PR #6120: cmd/snap-seccomp: add full complement of ptrace constants <Created by zyga> <https://github.com/snapcore/snapd/pull/6120> | 21:57 |
| zyga | not sure if you like it still | 21:57 |
| zyga | ideally I'd say that some things are -1 or NaN or similar | 21:58 |
| zyga | but it's hard in the current structure since -1 is a valid value at that level | 21:58 |
| zyga | I could refactor that if you want | 21:58 |
| zyga | though I don't believe it is required for this specific part (ptrace constants) | 21:58 |
| zyga | specifically the set we are dealing with here | 21:58 |
| zyga | jdstrand: not sure if you have the time but I would love a quick look at a simple open, fstatat function; https://github.com/snapcore/snapd/pull/6116 | 22:00 |
| mup | PR #6116: cmd/libsnap: add simplified feature flag checker <Created by zyga> <https://github.com/snapcore/snapd/pull/6116> | 22:00 |
| zyga | the code is at https://github.com/snapcore/snapd/pull/6116/files#diff-034bb7401eb457bc8862f9b4ee97edc8R33 | 22:00 |
| zyga | the rests are tests | 22:00 |
| jdstrand | zyga: if you were going to go that route, I think readNumber would have to return a 3rd value, 'skip' rather than interpreting the value | 22:01 |
| zyga | yeah | 22:01 |
| jdstrand | zyga: but this is like what we do for AF_IB, etc | 22:01 |
| zyga | it just sucks because we have the knowledge in C as a macro | 22:01 |
| jdstrand | what you're doing now | 22:01 |
| jdstrand | I'm ok with the approach, just verifying something | 22:01 |
| zyga | it's all doable, just a bit more uphill | 22:01 |
| zyga | thank you | 22:01 |
| zyga | FYI: I ran cross compile tests locally (thanks to chipaca's fantastic cross test suite) | 22:02 |
| zyga | where locally is really locally invoked spread :) | 22:02 |
| mup | PR snapd#6115 closed: cmd: update autogen.sh for opensuse <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6115> | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!