[00:22] 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:25] I should explain that I can't install "core" because those two utilities don't exist on my system. === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:12] morning [06:33] Good morning [06:37] zyga: hey, good morning [06:46] Hey :-) [06:46] Just drinking coffee [06:46] A bit sleepy still [06:52] mvo: zyga: hey [06:58] hey mborzecki ! === pstolowski|afk is now known as pstolowski [07:09] morning o/ [07:09] hey pstolowski ! [07:10] 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:17] 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:20] pstolowski: cool, thanks [07:21] in the office, finally [07:21] mvo: btw not sure if you saw my comment to https://github.com/snapcore/snapd/pull/6755 [07:22] 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] pstolowski: uhoh [07:22] pstolowski: I have not seen it :/ thats annoying for sure [07:23] mvo: perhaps we should simply catch *net.DNSError and don't try to be too smart wrt error message [07:23] pstolowski: glibc right? [07:23] mborzecki: right [07:37] 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:39] 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:41] mborzecki: i'll actually cook something to check that under PL locale [07:46] 430.09 NVIDIA graphics driver seems to broke OpenGL support: https://forum.snapcraft.io/t/call-for-testing-obs-studio-snap/4298/39 [07:53] brlin: ack [07:53] zyga: Tks! [07:53] brlin: we have poor support for nvidia and have roadmap item to improve that but it will likely slip a little [07:54] (not really care much as I use intel graphics) [07:57] mvo, mborzecki : ok, false alarm with translated error msg, i think we're good. under pl locale i'm getting: [07:57] $ ping www.sadaa.pl [07:57] ping: www.sadaa.pl: Odwzorowanie nazwy jest chwilowo niemożliwe [07:57] but with go test: [07:57] panic: Get https://asjhdaksdjhka.org/get: dial tcp: lookup asjhdaksdjhka.org: Temporary failure in name resolution [07:57] it seems only the standard cli utils get the translated messages [08:21] 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:47] mborzecki: https://github.com/snapcore/snapd/pull/6759#issuecomment-484931067 [08:47] mborzecki: if you remove the need for C, go build defaults change [08:48] mborzecki: I observed this when working on BuildID originaly [08:48] *originally [08:51] 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 [09:02] what was that pixel font... [09:24] zyga: pixel font? [09:24] yeah [09:24] whenever I work on low-dpi screen I use that font [09:24] anyway [09:24] I found something good enough for now [09:24] zyga: neep alt? [09:25] in xfonts-jmk [09:25] offtopic: it would be good to be able to ship fonts in snaps [09:25] and have them work on the host [09:25] I would really like that [09:31] zyga: can we land https://github.com/snapcore/snapd/pull/6777 or do we need to verify CLA? [09:31] pstolowski: 1) typos are not significant contribution that is protected by copyright and 2) we have automatic CLA verification in travis [09:31] zyga: ah ok [09:34] zyga: pstolowski: the travis CLA verification does have a "don't know" result which does not block [09:35] so you shold look at the output if you're unsure about a contributor [09:35] I didn't know that [09:35] but anyway, in this case this is clearly not copyrightable because it is not a creative work [09:35] in this case, it's not brlin's first contribution :-) [09:36] I thought I already signed the CLA...? [09:37] * brlin Checking it out so it won't be a problem [09:38] brlin: yeah, your first one wouldn't've gone in if not [09:53] would be great to land https://github.com/snapcore/snapd/pull/6717 [09:53] needs 2nd review though [09:53] pstolowski: I'm reworking your test [09:53] pstolowski: I will push there in 10 mintues [09:53] ahh [09:53] wrong branch [09:53] yes [09:53] please review and let's land that [09:53] mvo: will you be handling cherry-picking for 2.39? [10:11] * zyga is puzzled [10:12] need to drop the kids at school for some extra classes, back in ~30 [10:15] "extra classes" is parent-speak for "torture" [10:16] lol [10:29] mvo: https://github.com/snapcore/snapd/pull/6733 can land? [10:31] pstolowski: looking [10:32] 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] thank you [10:32] mvo: I'm not done yet, ideally tomorrow morning [10:32] pstolowski: yes, thank you! [10:32] pstolowski: that was just waiting for the second review :) [10:32] zyga: cool! thanks [10:33] btw https://github.com/snapcore/snapd/pull/6712 needs second review (hint! hint! ;)) [10:34] pstolowski: :) yes, its on my list but not super high (yet) unfortunately [10:36] re [10:36] Chipaca: that would 'piano classes' or somesuch [10:37] mborzecki: 'culture appreciation classes' [10:37] hahaha === degville is now known as degville-afk [10:56] pstolowski: I found that the stale fix is insufficient [10:57] pstolowski: working on a bit of more code to do it [10:57] pstolowski: I expanded your unit test and found the issue [11:00] zyga: oh interesting [11:01] pstolowski: I was unsure about the unit test so I started tweaking it towards "more obvious" [11:02] pstolowski: essentially more than one thing calls backend.Setup [11:12] uhm [11:14] cachio: hey, can https://github.com/snapcore/snapd/pull/6710 be updated for 19.04 now? [11:19] pstolowski, checking [11:21] pstolowski, still I need to fix the test snap-handle-link [11:21] which fails on 19.04 [11:21] cachio: ack, thanks [11:24] Chipaca: https://explainshell.com [11:26] * Chipaca pastes etelpmoc.sh in [11:26] * Chipaca is thwarted by 414 Request-URI Too Large [11:33] * Chipaca lunches [11:34] zyga: https://explainshell.com/explain?cmd=false+%7C%7C+%3A [11:34] zyga, hey, if you take a quick look to this one #6694 would be really nice [11:34] that site is not too helpful [11:52] 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:53] mborzecki: I'm on 19.04 [11:54] zyga: do you see this warning? [11:54] mborzecki: let me check, don't know [11:55] or can I queue this [11:55] my mind is set for attribute work now [11:55] zyga: sure [11:55] mborzecki: I'm on 19.04, I can check after lunch [11:55] mvo: thanks [12:00] off to pick up the kids, back in 30 === degville-afk is now known as degville [12:17] mborzecki, hey [12:17] I am researching the issue related to the xdg-open on 19.04 [12:17] mborzecki, I found that it works well https://paste.ubuntu.com/p/jq2ZnkXPtB/ [12:18] when we don't install the package evolution-data-server [12:18] mborzecki, otherwise it fails [12:18] like this https://paste.ubuntu.com/p/bqGhTbhSbj/ [12:18] mborzecki, any idea why it could be happening? [12:21] re [12:24] cachio: will take a look [12:25] mborzecki, thanks [12:25] I have debug session open [12:25] if you want to use it [12:25] for both scenarios [12:51] 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:52] it seems like mvo and Chipaca [12:52] that's cool [12:53] jdstrand: cachio also maybe? [12:53] jdstrand: i'm not collab on all of 'em fwiw [12:53] nobody invites me to the fun parties any more :-p [12:53] hehe [12:53] jdstrand, yes please [12:53] I looked at hello-world and classic :) [12:54] add me too [12:54] cachio: sure, np [12:54] jdstrand, thanks [12:59] mborzecki: I did not get this warning when just running lxc [13:00] mvo: interesting, thanks [13:12] 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:16] mborzecki, https://paste.ubuntu.com/p/Pjm2gr6FpN/ [13:16] just suggested [13:16] but a lot of gnome-* stuff [13:18] Chipaca, when you have time, could yo uplease take a look to https://github.com/snapcore/spread/pull/70 ? [13:20] F**************L [13:20] zyga: ? [13:20] falayaralfalil? [13:22] mvo: just realized the test shows the bug is deeper than I thought on refresh :) [13:23] mvo: the unit tests I added were good enough to show it would still be broken in one case [13:31] roadmr: frontosphenoidal [13:33] cachio: mhm, so maybe we need to run some mime update thingy [13:37] 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] 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] jdstrand, I usually create those on launchap [13:38] jdstrand, launchpad can build snaps for all architectures, include ppc64el & s390x. Or are you building without launchpad? [13:38] jdstrand, on this project https://code.launchpad.net/~snappy-dev/snappy-hub/ [13:38] tasker: mount always looks for mount. afaik [13:38] jdstrand, and they are not special arches at all, anybody can enabled them on anything. [13:38] jdstrand, we store all the snapd to build [13:38] tasker: bah, dunno [13:38] tasker: I don't have a mount.squashfs here and things work [13:39] tasker: maybe it's trying that because your kernel doesn't support squashfs? [13:39] Chipaca: it does. [13:39] cachio: I looked there and did not see other test snaps [13:39] tasker: can you pastebin the output of 'snap version'? [13:40] jdstrand, most of the tests snaps are there [13:40] 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] jdstrand, for example lp:~snappy-dev/snappy-hub/test-snapd-profiler [13:40] * jdstrand looks again [13:40] ah [13:40] ok [13:40] cachio: I might've benn looking in git [13:40] been* [13:41] heh, I typoed as 'snappy-hug' [13:42] hehehe [13:43] cachio: yeah, I looked at git. ok, I'll do the bzr dance and go from there. thanks [13:43] jdstrand, np [13:43] jdstrand, yaw [13:44] Chipaca: http://dpaste.com/1EQZGDW [13:50] tasker: what do you get in 'dmesg' when the snap fails to mount? [13:50] nothing [13:50] tasker: what error do you get from snapd when you try to install? [13:51] I'm going back through the strace again. maybe the mount utilities aren't the problem. [13:51] Chipaca: http://dpaste.com/07T5MHT [13:51] mup_: you're so quiet, are you alive? [13:52] tasker: that's strange, but ok, let's back up a bit [13:53] tasker: try this: snap download core (more to follow when that's done) [13:53] Chipaca: done. [13:54] tasker: now try to mount the .snap file, e.g. sudo mount core_6673.snap /mnt [13:55] tasker: also try 'grep squashfs /proc/filesystems' [13:55] yes. I can mount squashfs. [13:55] tasker: that 'mount' worked, then? [13:55] yes, thank you. [13:55] tasker: ok, can you pastebin the output of 'snap tasks --last=install' please? [13:56] tasker: (feel free to umount that snap) [13:56] * Chipaca very puzzled at this point [13:57] Chipaca: http://dpaste.com/3AMJJ9D [13:59] tasker: can you post `journalctl --since 8:44`? [14:00] --system, also [14:00] tasker: right, journalctl --system --sice 8:44 [14:00] I cannot. don't have journalctl. [14:01] tasker: what [14:01] and if you follow up with "snap won't work without systemd", I'm done with this experiment. [14:01] tasker: snap does not work without systemd [14:01] . ) [14:01] okie doke! [14:01] thanks a bunch. [14:03] tasker: we delegate a lot of stuff to systemd ¯\_(ツ)_/¯ including the mounting of stuff [14:04] we're open to people writing different backends for other init systems, but so far nobody has offered [14:04] I'm not mad. saddened, perhaps, but not mad. [14:05] good luck! [14:05] thanks again for your help. [14:05] why would you be mad? [14:15] mvo, pstolowski: I'll grab coffee and lunch [14:15] I'll share what I have after that [14:15] zyga shares his coffee and lunch? :) [14:15] changes have some impact so not great [14:15] * zyga is happy to share that too :) [14:16] :D [14:16] :) [14:38] 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:39] it's a mix of custom mainline kernel, which somehow got selinux enabled, plus selinuxfs is somehow mounted during boot [14:39] 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:40] i suspect this will break with 2.39 [14:44] 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] mborzecki: detect a selinux with no policies as part of 'not supported'? [14:44] mborzecki: ouch [14:45] mborzecki: maybe ask kernel people about this then [14:45] maybe we're dropping apparmor for 5.0 :-p [14:45] * Chipaca hides [14:46] i seriously wonder how did the system even boot properly [14:47] Zombie processes detected, machine is haunted. [14:47] ^ bofh knows all [14:47] psdoom window pops up [14:49] man why are we not packaging psdoom [14:56] back from coffee [14:56] sorry, sleepy since I slept so little last night [15:01] apology accepted [15:02] https://memegenerator.net/img/instances/64599905/apology-accepted.jpg [15:02] like this? :D === juliank is now known as juliank|dalek === juliank|dalek is now known as juliank [15:06] Chipaca: as far as selinux enabled detection is concerned: https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/enabled.c#L11-L21 [15:21] mvo: thinking through how to require that golang-seccomp is patched, since daemon user will have terribly incorrect bpf otherwise [15:21] mvo: I'm having trouble. golang-seccomp doesn't declare anything that we can use in system-key (eg, a version or something) [15:22] mvo: we could try to generate a tiny bpf and they see if it is correct, but that is kinda yucky [15:23] 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:24] pstolowski: I'm running spread after adjusting unit tests [15:24] 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] 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:25] pstolowski: I'd like to proceed as follows [15:25] pstolowski: I have some changes to unit tests in ifacestate [15:25] pstolowski: those should hopefully not depend on the fixes that are coming after them [15:25] 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:26] pstolowski: the motivation is simple: lots of tests use a common consumer/producer yaml that has lots of quirky attributes and hooks [15:26] jdstrand: not vendor in that sense [15:26] zyga: debian and fedora should be fixed soon, but I'm worried about other systems [15:26] jdstrand: make it a part of snapd tree [15:26] jdstrand: strip rest of the code [15:26] jdstrand: drop the vendored dep [15:26] oh [15:26] hrm [15:26] you mean an embedded code copy [15:26] jdstrand: yes, but much reduced [15:27] zyga: it wouldn't be 'much reduced'. it is already small and we are using most of the api [15:27] jdstrand: well, perhaps there would be still something to shed [15:27] I like the fact that it removes one moving part [15:27] and changes it to something we can instantly correct as we need to [15:29] 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] 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:30] jdstrand: AFAICT using GetApi would also force using 2.4.0 [15:30] 2.4.0+ i mean [15:30] hence the simplification, I really mean a one-way copy and integration [15:30] Chipaca: yes [15:30] which is probably fine, but i thought we wanted to support but downgrade <2.4.0? [15:31] 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] mhm [15:31] but at some point it does become a gray area [15:32] 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:33] zyga: for the distros that are enforcing not vendoring, there is no gray [15:33] zyga: again, if we embedded, I would strongly advocate *not* changing the imported code [15:34] we use like 90% of the api. maybe more [15:34] mmm [15:35] well [15:35] or we can rewrite it :) [15:35] I would love to over summer holidays [15:35] please stop suggesting that :) [15:35] haha, like zyga takes holidays [15:35] it has taken years for people to get it to the point that it is working now [15:35] haha, yes, [15:35] jdstrand: well, I honestly think it's not something that is hard to do :-) [15:36] I know you don't ;) [15:36] also we'd need a subset of real functionality and we'd have flexibility of doing more things [15:36] but if you look at the seccomp library, it is hairy, tricky code [15:36] I still think the API is quirky, the results are (now) good but were not good before [15:36] and I think way more can be done [15:37] 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] 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] but that's an orthogonal discussion [15:38] 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] jdstrand: and is written in C [15:39] this doesn't help my daemon user PR [15:39] jdstrand: that same library was fundamentally broken for years <- this wasn't sent somehow [15:39] yes, I agree [15:39] I'm just casually exploring the topic [15:39] I don't argue towards doing this for the daemon work [15:39] but doing this could remove *all of* snap-seccomp [15:39] Chipaca: do you know of a way to detect if a package implements a function at runtime? [15:39] and make it all a part of snapd [15:40] I don't know how else I can express 'bad idea' :) [15:40] jdstrand: I looked into it a bit, and no, sadly, not at the package level without doing horrible things [15:40] jdstrand: if there were a method on a struct that we could look for, that, yes [15:40] jdstrand: dlopen? [15:41] Chipaca: yeah, I spent too much time on it this morning already [15:41] zyga: dlopen what? [15:41] jdstrand: dlopen the so file, look up the symbol, [15:41] Chipaca: do you know of a way to detect if a package implements a function at runtime? [15:42] zyga: there isn't an so. I'm talking about golang-seccomp [15:42] I see [15:42] in go that's impossible AFAIK [15:42] well, there's reflect but I don't see the value [15:42] it's a compile time thing [15:42] zyga: there are libseccomp bugs. I can and have worked around that because I dan downgrade if GetLibraryVersion is < 2.4 [15:43] 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] jdstrand: make that a runtime choice? [15:43] aha [15:43] well [15:43] oooh, ooh [15:43] * zyga waits for Chipaca's idea [15:43] jdstrand: so you could do this [15:43] zyga: sounds good, yeah, all those consumer/producer yamls there grew organically and out of control [15:43] pstolowski: +1 preparing a patch now [15:43] sorry, got distracted by family discussion that for some reason moved into the office [15:44] :) [15:45] 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] sorry, putting it into code [15:45] jdstrand: indeed [15:45] jdstrand: seccomp.ScmpAction(6).String() [15:46] jdstrand: the commit that changes the result of that, is the same that adds GetApi [15:46] jdstrand: was in a meeting will read backlog [15:47] or the one just before it? [15:47] jdstrand: but I think that gets us there [15:47] oh no, drat [15:47] Date: Thu Sep 21 03:14:51 2017 +0000 [15:47] i read that wrong :-( [15:48] bah, dunno [15:48] these are all old commits [15:48] * zyga recommends just rewriting it all in Go [15:49] * Chipaca whaps zyga over the head [15:49] jdstrand: the commit that adds GetApi is from [15:49] Date: Wed Oct 25 05:44:14 2017 +0000 [15:50] is the one in distros really older than this? [15:50] Chipaca: ah, hmm. let me look [15:51] jdstrand: if it is, then checking that String would work (it's not the same commit but it's probably good enough) [15:51] well you know, I could also just look for the actlog stuff [15:51] jdstrand: that's what that String does [15:51] Apr 19 2017 is the magic day [15:52] it's either ActLog or Unrecognised [15:52] Chipaca: ah right. we even do that in snap-seccomp. billiant :) [15:52] hah [15:52] I can work with that. thanks :) [15:55] Chipaca: I don't know why I got focused on the other stuff. thanks for listening and setting me straight :) [15:56] jdstrand: it even mentions GetApi in snap-seccomp :-) now that i know what to look for [16:00] 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:02] hehe === pstolowski is now known as pstolowski|afk [16:03] * cachio lunch [16:04] jdstrand: cool [16:04] * mvo hugs jdstrand and Chipaca [16:04] :-) [16:05] 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] greyback and I have kicked around variants of "session" "login-session" & "logind-session" [16:12] pstolowski|afk: https://github.com/snapcore/snapd/pull/6779/files [16:12] aw, he's gone :| [16:12] * mvo grumbles about build failures of the snapd snap [16:16] alan_g: I suggest starting with 'login-session-control' and we can iterate in the PR [16:17] jdstrand, WFM [16:18] mvo: I'll EOD now given that my branch is blocked by 6779 [16:18] mvo: the essential fix is in https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c [16:18] it's stacked on top of that [16:19] I spawned a swarm of test machines to see if it breaks anything [16:19] and I will go out for a bike ride now [16:19] mvo: let's try to attempt to fix the stale tools bug tomorrow [17:03] zyga: thank you! [17:53] * jdstrand hrms [17:53] 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] this is with the brew build [17:53] halp [17:58] zyga: did you do anything with brew? ^ [17:59] zyga: (in the past that is; I need to adjust sandbox/seccomp/compiler.go I guess [17:59] jdstrand: that's the osx build [17:59] jdstrand: why is the osx build pulling in seccomp :-) [18:00] * Chipaca looks at the diff [18:00] apparently my PR did that [18:00] https://github.com/snapcore/snapd/pull/6780 [18:00] I need to use golang-seccomp to check for ActLog in check_snap.go [18:01] jdstrand: so, move GoSeccompCanActLog out to a compiler_linux.go file [18:01] that should do the trick? probably [18:01] jdstrand: you can test locally by doing GOOS=darwin go build ./cmd/snap [18:01] ok [18:02] Chipaca: should I create a compiler_???.go with GoSeccompCanActLog? [18:02] if so, what is ??? ? [18:02] jdstrand: compiler_linux.go, as i said? [18:02] or am i missing something [18:03] Chipaca: yes, but then osx will not have GoSeccompCanActLog() [18:03] jdstrand: and what uses that? [18:03] check_snap.go [18:03] * cachio afk [18:04] Chipaca: sorry. this pr is to support a check in the daemon user pr [18:04] Chipaca: for this pr, sure, compiler_linux.go [18:04]