| tasker | I'm having issues getting "core" to install because the snap daemon is looking explicitly for "mount.squashfs" and "umount.squashfs". what package provides those? and, perhaps a better question, why can't the code simply look for "mount"? | 00:22 |
|---|---|---|
| tasker | I should explain that I can't install "core" because those two utilities don't exist on my system. | 00:25 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mborzecki | morning | 05:12 |
| zyga | Good morning | 06:33 |
| mvo | zyga: hey, good morning | 06:37 |
| zyga | Hey :-) | 06:46 |
| zyga | Just drinking coffee | 06:46 |
| zyga | A bit sleepy still | 06:46 |
| mborzecki | mvo: zyga: hey | 06:52 |
| mvo | hey mborzecki ! | 06:58 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning o/ | 07:09 |
| mvo | hey pstolowski ! | 07:09 |
| mvo | pstolowski: does 6669 or 6712 need further samuele input? I saw he commented on both but it looks like you addressed all his input. would like to see if we can move forward here | 07:10 |
| pstolowski | mvo: no, i think we could move forward with them, i don't think there is anything controversial there; i can tweak in a followup if Samuele finds anything after it lands | 07:17 |
| mvo | pstolowski: cool, thanks | 07:20 |
| zyga | in the office, finally | 07:21 |
| pstolowski | mvo: btw not sure if you saw my comment to https://github.com/snapcore/snapd/pull/6755 | 07:21 |
| pstolowski | mvo: one of the dns-related messages that we use in retry code ("Temporary...") seems to be coming from glib (I grepped glib sources) and i think it can be translated :( | 07:22 |
| mvo | pstolowski: uhoh | 07:22 |
| mvo | pstolowski: I have not seen it :/ thats annoying for sure | 07:22 |
| pstolowski | mvo: perhaps we should simply catch *net.DNSError and don't try to be too smart wrt error message | 07:23 |
| mborzecki | pstolowski: glibc right? | 07:23 |
| pstolowski | mborzecki: right | 07:23 |
| mborzecki | pstolowski: actually an interesting problem, whether the error message by the time it's accessible in Go, is translated according to locale :/ that would be most unfortunate | 07:37 |
| pstolowski | mborzecki: i haven't actually verified that. just found the error in the code, and then in all po/*po files of glibc. don't know how the error is propagated to go | 07:39 |
| pstolowski | mborzecki: i'll actually cook something to check that under PL locale | 07:41 |
| brlin | 430.09 NVIDIA graphics driver seems to broke OpenGL support: https://forum.snapcraft.io/t/call-for-testing-obs-studio-snap/4298/39 | 07:46 |
| zyga | brlin: ack | 07:53 |
| brlin | zyga: Tks! | 07:53 |
| zyga | brlin: we have poor support for nvidia and have roadmap item to improve that but it will likely slip a little | 07:53 |
| brlin | (not really care much as I use intel graphics) | 07:54 |
| pstolowski | mvo, mborzecki : ok, false alarm with translated error msg, i think we're good. under pl locale i'm getting: | 07:57 |
| pstolowski | $ ping www.sadaa.pl | 07:57 |
| pstolowski | ping: www.sadaa.pl: Odwzorowanie nazwy jest chwilowo niemożliwe | 07:57 |
| pstolowski | but with go test: | 07:57 |
| pstolowski | panic: Get https://asjhdaksdjhka.org/get: dial tcp: lookup asjhdaksdjhka.org: Temporary failure in name resolution | 07:57 |
| pstolowski | it seems only the standard cli utils get the translated messages | 07:57 |
| mborzecki | zyga: added some notes under https://github.com/snapcore/snapd/pull/6759 looks like something fishy with go toolchain, and not 1.10 specific | 08:21 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/6759#issuecomment-484931067 | 08:47 |
| zyga | mborzecki: if you remove the need for C, go build defaults change | 08:47 |
| zyga | mborzecki: I observed this when working on BuildID originaly | 08:48 |
| zyga | *originally | 08:48 |
| mborzecki | zyga: hm the resulting test binary is still dynamically linked and gcc is involved in the build process, so it's not exatly the same as CGO_ENABLED=0 | 08:51 |
| zyga | what was that pixel font... | 09:02 |
| Chipaca | zyga: pixel font? | 09:24 |
| zyga | yeah | 09:24 |
| zyga | whenever I work on low-dpi screen I use that font | 09:24 |
| zyga | anyway | 09:24 |
| zyga | I found something good enough for now | 09:24 |
| Chipaca | zyga: neep alt? | 09:24 |
| Chipaca | in xfonts-jmk | 09:25 |
| zyga | offtopic: it would be good to be able to ship fonts in snaps | 09:25 |
| zyga | and have them work on the host | 09:25 |
| zyga | I would really like that | 09:25 |
| pstolowski | zyga: can we land https://github.com/snapcore/snapd/pull/6777 or do we need to verify CLA? | 09:31 |
| zyga | pstolowski: 1) typos are not significant contribution that is protected by copyright and 2) we have automatic CLA verification in travis | 09:31 |
| pstolowski | zyga: ah ok | 09:31 |
| Chipaca | zyga: pstolowski: the travis CLA verification does have a "don't know" result which does not block | 09:34 |
| Chipaca | so you shold look at the output if you're unsure about a contributor | 09:35 |
| zyga | I didn't know that | 09:35 |
| zyga | but anyway, in this case this is clearly not copyrightable because it is not a creative work | 09:35 |
| Chipaca | in this case, it's not brlin's first contribution :-) | 09:35 |
| brlin | I thought I already signed the CLA...? | 09:36 |
| * brlin Checking it out so it won't be a problem | 09:37 | |
| Chipaca | brlin: yeah, your first one wouldn't've gone in if not | 09:38 |
| pstolowski | would be great to land https://github.com/snapcore/snapd/pull/6717 | 09:53 |
| pstolowski | needs 2nd review though | 09:53 |
| zyga | pstolowski: I'm reworking your test | 09:53 |
| zyga | pstolowski: I will push there in 10 mintues | 09:53 |
| zyga | ahh | 09:53 |
| zyga | wrong branch | 09:53 |
| zyga | yes | 09:53 |
| zyga | please review and let's land that | 09:53 |
| zyga | mvo: will you be handling cherry-picking for 2.39? | 09:53 |
| * zyga is puzzled | 10:11 | |
| mborzecki | need to drop the kids at school for some extra classes, back in ~30 | 10:12 |
| Chipaca | "extra classes" is parent-speak for "torture" | 10:15 |
| zyga | lol | 10:16 |
| pstolowski | mvo: https://github.com/snapcore/snapd/pull/6733 can land? | 10:29 |
| mvo | pstolowski: looking | 10:31 |
| mvo | zyga: sorry for the delay, had a meeting - yeah, I take care of 2.39 cherry picks in general, anything I should cherry-pick? | 10:32 |
| zyga | thank you | 10:32 |
| zyga | mvo: I'm not done yet, ideally tomorrow morning | 10:32 |
| mvo | pstolowski: yes, thank you! | 10:32 |
| mvo | pstolowski: that was just waiting for the second review :) | 10:32 |
| mvo | zyga: cool! thanks | 10:32 |
| pstolowski | btw https://github.com/snapcore/snapd/pull/6712 needs second review (hint! hint! ;)) | 10:33 |
| mvo | pstolowski: :) yes, its on my list but not super high (yet) unfortunately | 10:34 |
| mborzecki | re | 10:36 |
| mborzecki | Chipaca: that would 'piano classes' or somesuch | 10:36 |
| Chipaca | mborzecki: 'culture appreciation classes' | 10:37 |
| mborzecki | hahaha | 10:37 |
| === degville is now known as degville-afk | ||
| zyga | pstolowski: I found that the stale fix is insufficient | 10:56 |
| zyga | pstolowski: working on a bit of more code to do it | 10:57 |
| zyga | pstolowski: I expanded your unit test and found the issue | 10:57 |
| pstolowski | zyga: oh interesting | 11:00 |
| zyga | pstolowski: I was unsure about the unit test so I started tweaking it towards "more obvious" | 11:01 |
| zyga | pstolowski: essentially more than one thing calls backend.Setup | 11:02 |
| pstolowski | uhm | 11:12 |
| pstolowski | cachio: hey, can https://github.com/snapcore/snapd/pull/6710 be updated for 19.04 now? | 11:14 |
| cachio | pstolowski, checking | 11:19 |
| cachio | pstolowski, still I need to fix the test snap-handle-link | 11:21 |
| cachio | which fails on 19.04 | 11:21 |
| pstolowski | cachio: ack, thanks | 11:21 |
| zyga | Chipaca: https://explainshell.com | 11:24 |
| * Chipaca pastes etelpmoc.sh in | 11:26 | |
| * Chipaca is thwarted by 414 Request-URI Too Large | 11:26 | |
| * Chipaca lunches | 11:33 | |
| mborzecki | zyga: https://explainshell.com/explain?cmd=false+%7C%7C+%3A | 11:34 |
| cachio | zyga, hey, if you take a quick look to this one #6694 would be really nice | 11:34 |
| mborzecki | that site is not too helpful | 11:34 |
| mborzecki | zyga: mvo: are you on 19.04? can you check if that appears? https://forum.snapcraft.io/t/selinux-warning-when-running-lxc/11100 | 11:52 |
| zyga | mborzecki: I'm on 19.04 | 11:53 |
| mborzecki | zyga: do you see this warning? | 11:54 |
| zyga | mborzecki: let me check, don't know | 11:54 |
| zyga | or can I queue this | 11:55 |
| zyga | my mind is set for attribute work now | 11:55 |
| mborzecki | zyga: sure | 11:55 |
| mvo | mborzecki: I'm on 19.04, I can check after lunch | 11:55 |
| mborzecki | mvo: thanks | 11:55 |
| mborzecki | off to pick up the kids, back in 30 | 12:00 |
| === degville-afk is now known as degville | ||
| cachio | mborzecki, hey | 12:17 |
| cachio | I am researching the issue related to the xdg-open on 19.04 | 12:17 |
| cachio | mborzecki, I found that it works well https://paste.ubuntu.com/p/jq2ZnkXPtB/ | 12:17 |
| cachio | when we don't install the package evolution-data-server | 12:18 |
| cachio | mborzecki, otherwise it fails | 12:18 |
| cachio | like this https://paste.ubuntu.com/p/bqGhTbhSbj/ | 12:18 |
| cachio | mborzecki, any idea why it could be happening? | 12:18 |
| mborzecki | re | 12:21 |
| mborzecki | cachio: will take a look | 12:24 |
| cachio | mborzecki, thanks | 12:25 |
| cachio | I have debug session open | 12:25 |
| cachio | if you want to use it | 12:25 |
| cachio | for both scenarios | 12:25 |
| jdstrand | mvo: remind me. say I want to create a test snap and have it in the store, I know that I put its source in tests/lib/snaps, but after I snapcraft register and upload, who should I add as a collaborator? | 12:51 |
| jdstrand | it seems like mvo and Chipaca | 12:52 |
| jdstrand | that's cool | 12:52 |
| Chipaca | jdstrand: cachio also maybe? | 12:53 |
| Chipaca | jdstrand: i'm not collab on all of 'em fwiw | 12:53 |
| Chipaca | nobody invites me to the fun parties any more :-p | 12:53 |
| jdstrand | hehe | 12:53 |
| cachio | jdstrand, yes please | 12:53 |
| jdstrand | I looked at hello-world and classic :) | 12:53 |
| cachio | add me too | 12:54 |
| jdstrand | cachio: sure, np | 12:54 |
| cachio | jdstrand, thanks | 12:54 |
| mvo | mborzecki: I did not get this warning when just running lxc | 12:59 |
| mborzecki | mvo: interesting, thanks | 13:00 |
| mborzecki | cachio: can you check whether installing evolution-data-server somehow pulls in gnome-software? if not, then whether gnome-software is installed before the test actually executes | 13:12 |
| cachio | mborzecki, https://paste.ubuntu.com/p/Pjm2gr6FpN/ | 13:16 |
| cachio | just suggested | 13:16 |
| cachio | but a lot of gnome-* stuff | 13:16 |
| cachio | Chipaca, when you have time, could yo uplease take a look to https://github.com/snapcore/spread/pull/70 ? | 13:18 |
| zyga | F**************L | 13:20 |
| mvo | zyga: ? | 13:20 |
| roadmr | falayaralfalil? | 13:20 |
| zyga | mvo: just realized the test shows the bug is deeper than I thought on refresh :) | 13:22 |
| zyga | mvo: the unit tests I added were good enough to show it would still be broken in one case | 13:23 |
| Chipaca | roadmr: frontosphenoidal | 13:31 |
| mborzecki | cachio: mhm, so maybe we need to run some mime update thingy | 13:33 |
| jdstrand | cachio: hey, so I have the ability to create amd64, i386, arm64 and armhf snaps, so I am doing that for the new test-snapd-setpriority snap. I was thinking that I wouldn't worry about ppc64el or s390x unless you felt otherwise. if you do feel otherwise, what is the recommended way to provide those? | 13:37 |
| tasker | I'm having issues getting "core" to install because the snap daemon is looking explicitly for "mount.squashfs" and "umount.squashfs" both of which I don't have on my system. what package provides those? and, perhaps a better question, why can't the code simply look for "mount"? | 13:37 |
| cachio | jdstrand, I usually create those on launchap | 13:37 |
| xnox | jdstrand, launchpad can build snaps for all architectures, include ppc64el & s390x. Or are you building without launchpad? | 13:38 |
| cachio | jdstrand, on this project https://code.launchpad.net/~snappy-dev/snappy-hub/ | 13:38 |
| Chipaca | tasker: mount always looks for mount.<filesystem> afaik | 13:38 |
| xnox | jdstrand, and they are not special arches at all, anybody can enabled them on anything. | 13:38 |
| cachio | jdstrand, we store all the snapd to build | 13:38 |
| Chipaca | tasker: bah, dunno | 13:38 |
| Chipaca | tasker: I don't have a mount.squashfs here and things work | 13:38 |
| Chipaca | tasker: maybe it's trying that because your kernel doesn't support squashfs? | 13:39 |
| tasker | Chipaca: it does. | 13:39 |
| jdstrand | cachio: I looked there and did not see other test snaps | 13:39 |
| Chipaca | tasker: can you pastebin the output of 'snap version'? | 13:39 |
| cachio | jdstrand, most of the tests snaps are there | 13:40 |
| jdstrand | xnox: right, I realize that and do it all the time. this is a spread test snap and I didn't see/know where LP builds of test snaps are is all | 13:40 |
| cachio | jdstrand, for example lp:~snappy-dev/snappy-hub/test-snapd-profiler | 13:40 |
| * jdstrand looks again | 13:40 | |
| xnox | ah | 13:40 |
| xnox | ok | 13:40 |
| jdstrand | cachio: I might've benn looking in git | 13:40 |
| jdstrand | been* | 13:40 |
| jdstrand | heh, I typoed as 'snappy-hug' | 13:41 |
| cachio | hehehe | 13:42 |
| jdstrand | cachio: yeah, I looked at git. ok, I'll do the bzr dance and go from there. thanks | 13:43 |
| cachio | jdstrand, np | 13:43 |
| cachio | jdstrand, yaw | 13:43 |
| tasker | Chipaca: http://dpaste.com/1EQZGDW | 13:44 |
| Chipaca | tasker: what do you get in 'dmesg' when the snap fails to mount? | 13:50 |
| tasker | nothing | 13:50 |
| Chipaca | tasker: what error do you get from snapd when you try to install? | 13:50 |
| tasker | I'm going back through the strace again. maybe the mount utilities aren't the problem. | 13:51 |
| tasker | Chipaca: http://dpaste.com/07T5MHT | 13:51 |
| cmatsuoka | mup_: you're so quiet, are you alive? | 13:51 |
| Chipaca | tasker: that's strange, but ok, let's back up a bit | 13:52 |
| Chipaca | tasker: try this: snap download core (more to follow when that's done) | 13:53 |
| tasker | Chipaca: done. | 13:53 |
| Chipaca | tasker: now try to mount the .snap file, e.g. sudo mount core_6673.snap /mnt | 13:54 |
| mborzecki | tasker: also try 'grep squashfs /proc/filesystems' | 13:55 |
| tasker | yes. I can mount squashfs. | 13:55 |
| Chipaca | tasker: that 'mount' worked, then? | 13:55 |
| tasker | yes, thank you. | 13:55 |
| Chipaca | tasker: ok, can you pastebin the output of 'snap tasks --last=install' please? | 13:55 |
| Chipaca | tasker: (feel free to umount that snap) | 13:56 |
| * Chipaca very puzzled at this point | 13:56 | |
| tasker | Chipaca: http://dpaste.com/3AMJJ9D | 13:57 |
| mborzecki | tasker: can you post `journalctl --since 8:44`? | 13:59 |
| Chipaca | --system, also | 14:00 |
| mborzecki | tasker: right, journalctl --system --sice 8:44 | 14:00 |
| tasker | I cannot. don't have journalctl. | 14:00 |
| Chipaca | tasker: what | 14:01 |
| tasker | and if you follow up with "snap won't work without systemd", I'm done with this experiment. | 14:01 |
| Chipaca | tasker: snap does not work without systemd | 14:01 |
| tasker | . ) | 14:01 |
| tasker | okie doke! | 14:01 |
| tasker | thanks a bunch. | 14:01 |
| Chipaca | tasker: we delegate a lot of stuff to systemd ¯\_(ツ)_/¯ including the mounting of stuff | 14:03 |
| Chipaca | we're open to people writing different backends for other init systems, but so far nobody has offered | 14:04 |
| tasker | I'm not mad. saddened, perhaps, but not mad. | 14:04 |
| tasker | good luck! | 14:05 |
| tasker | thanks again for your help. | 14:05 |
| Chipaca | why would you be mad? | 14:05 |
| zyga | mvo, pstolowski: I'll grab coffee and lunch | 14:15 |
| zyga | I'll share what I have after that | 14:15 |
| roadmr | zyga shares his coffee and lunch? :) | 14:15 |
| zyga | changes have some impact so not great | 14:15 |
| * zyga is happy to share that too :) | 14:15 | |
| roadmr | :D | 14:16 |
| pstolowski | :) | 14:16 |
| mborzecki | guys, i'm out of ideas, what could we do about a setup like this: https://forum.snapcraft.io/t/selinux-warning-when-running-lxc/11100/ | 14:38 |
| mborzecki | it's a mix of custom mainline kernel, which somehow got selinux enabled, plus selinuxfs is somehow mounted during boot | 14:39 |
| mborzecki | but userspace tools are missing (as in https://github.com/PowerShell/PowerShell/issues/9252 ) or the userland is totally unprepared for selinux (i.e. missing policy and so on) | 14:39 |
| mborzecki | i suspect this will break with 2.39 | 14:40 |
| mborzecki | Chipaca: wow, that kerlen that you linked, i looked at the config patches, +CONFIG_DEFAULT_SECURITY="selinux" +CONFIG_DEFAULT_SECURITY_SELINUX=y in debian.master/config/config.common.ubuntu | 14:44 |
| Chipaca | mborzecki: detect a selinux with no policies as part of 'not supported'? | 14:44 |
| Chipaca | mborzecki: ouch | 14:44 |
| Chipaca | mborzecki: maybe ask kernel people about this then | 14:45 |
| Chipaca | maybe we're dropping apparmor for 5.0 :-p | 14:45 |
| * Chipaca hides | 14:45 | |
| mborzecki | i seriously wonder how did the system even boot properly | 14:46 |
| Chipaca | Zombie processes detected, machine is haunted. | 14:47 |
| Chipaca | ^ bofh knows all | 14:47 |
| mborzecki | psdoom window pops up | 14:47 |
| Chipaca | man why are we not packaging psdoom | 14:49 |
| zyga | back from coffee | 14:56 |
| zyga | sorry, sleepy since I slept so little last night | 14:56 |
| Chipaca | apology accepted | 15:01 |
| zyga | https://memegenerator.net/img/instances/64599905/apology-accepted.jpg | 15:02 |
| zyga | like this? :D | 15:02 |
| === juliank is now known as juliank|dalek | ||
| === juliank|dalek is now known as juliank | ||
| mborzecki | Chipaca: as far as selinux enabled detection is concerned: https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/enabled.c#L11-L21 | 15:06 |
| jdstrand | mvo: thinking through how to require that golang-seccomp is patched, since daemon user will have terribly incorrect bpf otherwise | 15:21 |
| jdstrand | mvo: I'm having trouble. golang-seccomp doesn't declare anything that we can use in system-key (eg, a version or something) | 15:21 |
| jdstrand | mvo: we could try to generate a tiny bpf and they see if it is correct, but that is kinda yucky | 15:22 |
| jdstrand | mvo: I do know that golang-seccomp is adding a new func called GetApi() for the new libseccomp call. that was added after the patch to AND | 15:23 |
| zyga | pstolowski: I'm running spread after adjusting unit tests | 15:24 |
| jdstrand | mvo: so, in theory, we could reference that somewhere in the code and then snapd would fail to build. this would force people to update (we would fetch/merge into the vendored code) | 15:24 |
| zyga | jdstrand: can we vendor golang-seccomp in snapd to the extent that we only depend on libseccomp and have a slimmed-down version of golang-seccomp for just the functions that we use? | 15:24 |
| zyga | pstolowski: I'd like to proceed as follows | 15:25 |
| zyga | pstolowski: I have some changes to unit tests in ifacestate | 15:25 |
| zyga | pstolowski: those should hopefully not depend on the fixes that are coming after them | 15:25 |
| jdstrand | zyga: we already vendor it. the problem is fedora and debian strip it out and use the system golang-seccomp. if we vendored everything, there is no problem | 15:25 |
| zyga | pstolowski: the motivation is simple: lots of tests use a common consumer/producer yaml that has lots of quirky attributes and hooks | 15:26 |
| zyga | jdstrand: not vendor in that sense | 15:26 |
| jdstrand | zyga: debian and fedora should be fixed soon, but I'm worried about other systems | 15:26 |
| zyga | jdstrand: make it a part of snapd tree | 15:26 |
| zyga | jdstrand: strip rest of the code | 15:26 |
| zyga | jdstrand: drop the vendored dep | 15:26 |
| jdstrand | oh | 15:26 |
| jdstrand | hrm | 15:26 |
| jdstrand | you mean an embedded code copy | 15:26 |
| zyga | jdstrand: yes, but much reduced | 15:26 |
| jdstrand | zyga: it wouldn't be 'much reduced'. it is already small and we are using most of the api | 15:27 |
| zyga | jdstrand: well, perhaps there would be still something to shed | 15:27 |
| zyga | I like the fact that it removes one moving part | 15:27 |
| zyga | and changes it to something we can instantly correct as we need to | 15:27 |
| jdstrand | zyga: a) I wouldn't necessarily want to just chop up golang-seccomp. I think it is fine to import wholesale and sit on it, which is what we are effectively doing now for most systems | 15:29 |
| jdstrand | zyga: b) but for the ones we don't do it on (eg, fedora and debian), they aren't going to be too keen on the embedded code copy since it is just circumventing their policy | 15:29 |
| Chipaca | jdstrand: AFAICT using GetApi would also force using 2.4.0 | 15:30 |
| Chipaca | 2.4.0+ i mean | 15:30 |
| zyga | hence the simplification, I really mean a one-way copy and integration | 15:30 |
| jdstrand | Chipaca: yes | 15:30 |
| Chipaca | which is probably fine, but i thought we wanted to support but downgrade <2.4.0? | 15:30 |
| jdstrand | zyga: I know what you are saying. I'm saying I know distros and the whole reasons they balk at vendoring the way we do now are still there with an embedded code copy | 15:31 |
| zyga | mhm | 15:31 |
| zyga | but at some point it does become a gray area | 15:31 |
| jdstrand | Chipaca: there are a spectrum of options. one is failing the build. one is trying to detect at runtime and degrading. I wanted to see if GetApi() was available for use at runtime, but it doesn't seem go supports that. reflect doesn't help cause it isn't an obj. it is a package function. If I could be proven wrong, I would go that route | 15:32 |
| jdstrand | zyga: for the distros that are enforcing not vendoring, there is no gray | 15:33 |
| jdstrand | zyga: again, if we embedded, I would strongly advocate *not* changing the imported code | 15:33 |
| jdstrand | we use like 90% of the api. maybe more | 15:34 |
| zyga | mmm | 15:34 |
| zyga | well | 15:35 |
| zyga | or we can rewrite it :) | 15:35 |
| zyga | I would love to over summer holidays | 15:35 |
| jdstrand | please stop suggesting that :) | 15:35 |
| Chipaca | haha, like zyga takes holidays | 15:35 |
| jdstrand | it has taken years for people to get it to the point that it is working now | 15:35 |
| zyga | haha, yes, | 15:35 |
| zyga | jdstrand: well, I honestly think it's not something that is hard to do :-) | 15:35 |
| jdstrand | I know you don't ;) | 15:36 |
| zyga | also we'd need a subset of real functionality and we'd have flexibility of doing more things | 15:36 |
| jdstrand | but if you look at the seccomp library, it is hairy, tricky code | 15:36 |
| zyga | I still think the API is quirky, the results are (now) good but were not good before | 15:36 |
| zyga | and I think way more can be done | 15:36 |
| zyga | I did read libseccomp before, I didn't check the rewrite but I was honestly surprised by how complex that was, not for a good reason | 15:37 |
| zyga | the only valuable parts of libseccomp are: linux doesn't expose syscall numbers to userspace so libseccomp has to carry those, libseccomp has fallback code for multiplexers and deprecated syscalls (but even those are surprising IMO) | 15:37 |
| zyga | but that's an orthogonal discussion | 15:37 |
| jdstrand | I can't express strongly enough that rewriting a complex library that deals with various arch quirks and kernels that has wide industry adoption is a bad idea | 15:38 |
| zyga | jdstrand: and is written in C | 15:38 |
| jdstrand | this doesn't help my daemon user PR | 15:39 |
| zyga | jdstrand: that same library was fundamentally broken for years <- this wasn't sent somehow | 15:39 |
| zyga | yes, I agree | 15:39 |
| zyga | I'm just casually exploring the topic | 15:39 |
| zyga | I don't argue towards doing this for the daemon work | 15:39 |
| zyga | but doing this could remove *all of* snap-seccomp | 15:39 |
| jdstrand | Chipaca: do you know of a way to detect if a package implements a function at runtime? | 15:39 |
| zyga | and make it all a part of snapd | 15:39 |
| jdstrand | I don't know how else I can express 'bad idea' :) | 15:40 |
| Chipaca | jdstrand: I looked into it a bit, and no, sadly, not at the package level without doing horrible things | 15:40 |
| Chipaca | jdstrand: if there were a method on a struct that we could look for, that, yes | 15:40 |
| zyga | jdstrand: dlopen? | 15:40 |
| jdstrand | Chipaca: yeah, I spent too much time on it this morning already | 15:41 |
| jdstrand | zyga: dlopen what? | 15:41 |
| zyga | jdstrand: dlopen the so file, look up the symbol, | 15:41 |
| zyga | <jdstrand> Chipaca: do you know of a way to detect if a package implements a function at runtime? | 15:41 |
| jdstrand | zyga: there isn't an so. I'm talking about golang-seccomp | 15:42 |
| zyga | I see | 15:42 |
| zyga | in go that's impossible AFAIK | 15:42 |
| zyga | well, there's reflect but I don't see the value | 15:42 |
| zyga | it's a compile time thing | 15:42 |
| jdstrand | zyga: there are libseccomp bugs. I can and have worked around that because I dan downgrade if GetLibraryVersion is < 2.4 | 15:42 |
| jdstrand | zyga: but the golang-seccomp bug... there isn't version info in the package and I can't seem to do a cheap check at runtime | 15:43 |
| zyga | jdstrand: make that a runtime choice? | 15:43 |
| zyga | aha | 15:43 |
| zyga | well | 15:43 |
| Chipaca | oooh, ooh | 15:43 |
| * zyga waits for Chipaca's idea | 15:43 | |
| Chipaca | jdstrand: so you could do this | 15:43 |
| pstolowski | zyga: sounds good, yeah, all those consumer/producer yamls there grew organically and out of control | 15:43 |
| zyga | pstolowski: +1 preparing a patch now | 15:43 |
| zyga | sorry, got distracted by family discussion that for some reason moved into the office | 15:43 |
| pstolowski | :) | 15:44 |
| jdstrand | zyga: also, if you see above, reflect doesn't work cause it is a func in a package, not a func on an object with a method | 15:45 |
| * jdstrand is curious about Chipaca's idea | 15:45 | |
| Chipaca | sorry, putting it into code | 15:45 |
| zyga | jdstrand: indeed | 15:45 |
| Chipaca | jdstrand: seccomp.ScmpAction(6).String() | 15:45 |
| Chipaca | jdstrand: the commit that changes the result of that, is the same that adds GetApi | 15:46 |
| mvo | jdstrand: was in a meeting will read backlog | 15:46 |
| Chipaca | or the one just before it? | 15:47 |
| Chipaca | jdstrand: but I think that gets us there | 15:47 |
| Chipaca | oh no, drat | 15:47 |
| Chipaca | Date: Thu Sep 21 03:14:51 2017 +0000 | 15:47 |
| Chipaca | i read that wrong :-( | 15:47 |
| Chipaca | bah, dunno | 15:48 |
| Chipaca | these are all old commits | 15:48 |
| * zyga recommends just rewriting it all in Go | 15:48 | |
| * Chipaca whaps zyga over the head | 15:49 | |
| Chipaca | jdstrand: the commit that adds GetApi is from | 15:49 |
| Chipaca | Date: Wed Oct 25 05:44:14 2017 +0000 | 15:49 |
| Chipaca | is the one in distros really older than this? | 15:50 |
| jdstrand | Chipaca: ah, hmm. let me look | 15:50 |
| Chipaca | jdstrand: if it is, then checking that String would work (it's not the same commit but it's probably good enough) | 15:51 |
| jdstrand | well you know, I could also just look for the actlog stuff | 15:51 |
| Chipaca | jdstrand: that's what that String does | 15:51 |
| jdstrand | Apr 19 2017 is the magic day | 15:51 |
| Chipaca | it's either ActLog or Unrecognised | 15:52 |
| jdstrand | Chipaca: ah right. we even do that in snap-seccomp. billiant :) | 15:52 |
| Chipaca | hah | 15:52 |
| jdstrand | I can work with that. thanks :) | 15:52 |
| jdstrand | Chipaca: I don't know why I got focused on the other stuff. thanks for listening and setting me straight :) | 15:55 |
| Chipaca | jdstrand: it even mentions GetApi in snap-seccomp :-) now that i know what to look for | 15:56 |
| jdstrand | mvo: Chipaca set me straight. we are all good | 16:00 |
| * Chipaca would gladly have set jdstrand queer, but thinks this is what they wanted | 16:00 | |
| jdstrand | hehe | 16:02 |
| === pstolowski is now known as pstolowski|afk | ||
| * cachio lunch | 16:03 | |
| mvo | jdstrand: cool | 16:04 |
| * mvo hugs jdstrand and Chipaca | 16:04 | |
| Chipaca | :-) | 16:04 |
| alan_g | jdstrand, any thoughts on the best name for this? https://forum.snapcraft.io/t/negotiating-a-vt-session-with-logind-needs-a-new-interface/10969 | 16:05 |
| alan_g | greyback and I have kicked around variants of "session" "login-session" & "logind-session" | 16:05 |
| zyga | pstolowski|afk: https://github.com/snapcore/snapd/pull/6779/files | 16:12 |
| zyga | aw, he's gone :| | 16:12 |
| * mvo grumbles about build failures of the snapd snap | 16:12 | |
| jdstrand | alan_g: I suggest starting with 'login-session-control' and we can iterate in the PR | 16:16 |
| alan_g | jdstrand, WFM | 16:17 |
| zyga | mvo: I'll EOD now given that my branch is blocked by 6779 | 16:18 |
| zyga | mvo: the essential fix is in https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c | 16:18 |
| zyga | it's stacked on top of that | 16:18 |
| zyga | I spawned a swarm of test machines to see if it breaks anything | 16:19 |
| zyga | and I will go out for a bike ride now | 16:19 |
| zyga | mvo: let's try to attempt to fix the stale tools bug tomorrow | 16:19 |
| mvo | zyga: thank you! | 17:03 |
| * jdstrand hrms | 17:53 | |
| jdstrand | sandbox/seccomp/compiler.go:27:2: build constraints exclude all Go files in /Users/travis/gopath/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang | 17:53 |
| jdstrand | this is with the brew build | 17:53 |
| jdstrand | halp | 17:53 |
| jdstrand | zyga: did you do anything with brew? ^ | 17:58 |
| jdstrand | zyga: (in the past that is; I need to adjust sandbox/seccomp/compiler.go I guess | 17:59 |
| Chipaca | jdstrand: that's the osx build | 17:59 |
| Chipaca | jdstrand: why is the osx build pulling in seccomp :-) | 17:59 |
| * Chipaca looks at the diff | 18:00 | |
| jdstrand | apparently my PR did that | 18:00 |
| jdstrand | https://github.com/snapcore/snapd/pull/6780 | 18:00 |
| jdstrand | I need to use golang-seccomp to check for ActLog in check_snap.go | 18:00 |
| Chipaca | jdstrand: so, move GoSeccompCanActLog out to a compiler_linux.go file | 18:01 |
| Chipaca | that should do the trick? probably | 18:01 |
| Chipaca | jdstrand: you can test locally by doing GOOS=darwin go build ./cmd/snap | 18:01 |
| jdstrand | ok | 18:01 |
| jdstrand | Chipaca: should I create a compiler_???.go with GoSeccompCanActLog? | 18:02 |
| jdstrand | if so, what is ??? ? | 18:02 |
| Chipaca | jdstrand: compiler_linux.go, as i said? | 18:02 |
| Chipaca | or am i missing something | 18:02 |
| jdstrand | Chipaca: yes, but then osx will not have GoSeccompCanActLog() | 18:03 |
| Chipaca | jdstrand: and what uses that? | 18:03 |
| jdstrand | check_snap.go | 18:03 |
| * cachio afk | 18:03 | |
| jdstrand | Chipaca: sorry. this pr is to support a check in the daemon user pr | 18:04 |
| jdstrand | Chipaca: for this pr, sure, compiler_linux.go | 18:04 |
| Chipaca | jdstrand: osx only builds cmd/snap, nothing else, if that helps? | 18:04 |
| * Chipaca tries to understand but is a little tired | 18:05 | |
| jdstrand | Chipaca: but in the daemon user pr, check_snap.go from overlord/snapstate is going to call that | 18:05 |
| Chipaca | jdstrand: ah, but cmd/snap doesn't use that | 18:05 |
| Chipaca | jdstrand: overlord isn't built for osx | 18:05 |
| jdstrand | Chipaca: I see | 18:05 |
| Chipaca | so you won't need a compiler_other.go | 18:05 |
| jdstrand | I was thinking that it would be in there since it is happening during snap install | 18:06 |
| jdstrand | gotcha. thanks again! :) | 18:06 |
| Chipaca | jdstrand: anything that tries to talk to snapd errors out, on osx | 18:06 |
| jdstrand | ack | 18:07 |
| jdstrand | Chipaca: that fixed it right up. thanks again :) | 18:28 |
| zyga | jdstrand: I did something with brew long time ago but not recently | 18:35 |
| Chipaca | zyga: all fixed now | 18:36 |
| zyga | Chipaca: cool, thank you! | 18:36 |
| Chipaca | well, allegedly | 18:36 |
| * zyga just returned from a walk | 18:36 | |
| Chipaca | :-) | 18:36 |
| zyga | now tempted to go on a bike ride | 18:36 |
| zyga | to close the "rings" :) | 18:36 |
| zyga | I'd love to land https://github.com/snapcore/snapd/pull/6779 | 18:36 |
| zyga | if anyone wants to look at boring changes | 18:36 |
| zyga | but not today, today is rest day | 18:36 |
| Chipaca | i'm off to the shops | 18:37 |
| Chipaca | gonna get me some curry or sth | 18:37 |
| zyga | thank you Chipaca ! | 18:37 |
| Chipaca | o/ | 18:37 |
| zyga | mvo: if you want to help, please land ^ | 18:37 |
| mvo | zyga: oh, interessting? what is the background there? | 18:38 |
| zyga | mvo: it's spelled out in the PR :) | 18:38 |
| zyga | but the extra description is as follows | 18:38 |
| zyga | lots of tests just use "consumerYaml" and "producerYaml" | 18:38 |
| zyga | and happily add extra crap to the definitions | 18:38 |
| zyga | so now they are a monster with all kinds of apps hooks plugs and stuff | 18:38 |
| zyga | and crazy hard to follow tests result from that | 18:39 |
| zyga | as I worked on https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c | 18:39 |
| zyga | I realized it would impact tests less if I change some of the existing tests | 18:39 |
| zyga | to use a smaller version of consumer/producer yaml | 18:39 |
| zyga | which has ... well, just what the test needs | 18:39 |
| zyga | so there's less noise in changes | 18:39 |
| zyga | as you can see in the patch I linked to, it changes two existing unit tests | 18:39 |
| zyga | but only those tests because only those tests meaningfully interact with what is changed | 18:40 |
| zyga | without the yaml patches from that PR it would also affect a random collection of tests that just happen to have random properties added to consumer/producer yaml that is shared and grew organically over time | 18:40 |
| jdstrand | zyga: I thought I remembered you did which is why I asked; figured you'd at least point me to the right person, but, Chipaca to the rescue :) | 18:41 |
| zyga | jdstrand: yeah, I was the ssh-to-macos-du-jour ;) | 18:42 |
| zyga | jdstrand: I wondered if this is a CVE | 18:42 |
| zyga | https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c | 18:42 |
| zyga | jdstrand: if you have a browser with sandbox and then refresh but stay on the stale attribute forever | 18:42 |
| zyga | or something along the same vein | 18:42 |
| zyga | anyway, I need to make tea | 18:43 |
| zyga | I'll check back later | 18:43 |
| zyga | jdstrand: it's enough to read the commit message to get an idea about the impact | 18:43 |
| jdstrand | zyga: it's definitely a bug worth fixing (thanks!). in the grand scheme of things, I don't consider it a cve. In isolation, arguably so, but considering the store and snap declarations, probably not since the publisher was granted use of the attribute and can remove and add at will. | 18:47 |
| jdstrand | zyga: it would affect a snap declaration that revoked, but that isn't terribly different from the old bug where a user disconnected and then on refresh the interface was connected again | 18:48 |
| zyga | +1 | 18:48 |
| jdstrand | zyga: I say just fix it and be done with it. if someone argues for it to be one, we can reconsider | 18:48 |
| jdstrand | zyga: you probably noticed we finally have CVEs for those 2 snap-confine issues. I think I cc'd you on the email to oss-sec | 18:49 |
| jdstrand | zyga: just fyi | 18:49 |
| zyga | I noticed, thank you! | 18:49 |
| zyga | Yes, I started following the ML | 18:50 |
| jdstrand | zyga: in other news, making the world a better place: https://github.com/seccomp/libseccomp-golang/issues/32 | 18:51 |
| zyga | jdstrand: oh indeed, thank you | 18:53 |
| zyga | And I’m sorry about my desire to rewrite all external deps as a part of snapd :-) | 18:53 |
| jdstrand | hehe | 18:54 |
| zyga | Apparmor parser is in that list as well | 18:55 |
| zyga | Ultimate way to both understand something and control it | 18:55 |
| jdstrand | I know it is | 18:55 |
| jdstrand | :) | 18:55 |
| jdstrand | erf | 19:04 |
| jdstrand | sandbox/seccomp/compiler_linux.go:22:2: build constraints exclude all Go files in /home/ubuntu/gocode/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang | 19:04 |
| jdstrand | I keep hitting this no cgo thing | 19:04 |
| * jdstrand make it a snap-seccomp command and calls out to it | 19:04 | |
| jdstrand | makes* | 19:05 |
| zyga | jdstrand: do you want a shell on my iMac pro? | 19:18 |
| jdstrand | zyga: compiler_linux.go fixed brew. now I'm hitting this with CGO_ENABLED=0 | 19:18 |
| jdstrand | so the approach is not viable | 19:18 |
| * jdstrand sighs | 19:18 | |
| * zyga hugs jdstrand | 19:19 | |
| * zyga merged and opened a new PR from his phone | 19:29 | |
| roadmr | but can it make phone calls? ;-| | 19:34 |
| zyga | roadmr: who knows, is that a feature? :-) | 19:35 |
| roadmr | well it enables me to not have a landline, so I'd call it a feature :D | 19:36 |
| roadmr | interestingly, the cell phone company does NOT allow you to put one of their numbers as your primary contact number - they still assume you have a landline or other bootstrappy phone. My primary contact number with them has been out of service for 8 years :) | 19:37 |
| roadmr | (as soon as I got the cell phone, I cancelled that other number) | 19:37 |
| zyga | We hardly call anyone on phone numbers now. It is mostly spam calls and more spam calls | 19:39 |
| zyga | Intro family calls are all telegram and FaceTime | 19:39 |
| zyga | Intra | 19:39 |
| roadmr | hehe nice | 19:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
