[06:00] morning everyone [06:33] good morning [06:39] hey zyga :) [06:39] amurray, oh hi :) [06:39] amurray, back from xmas break? [06:39] (carry-over burned?) [06:40] yep, about to take my kids to the pool for swimming lessons so will relocate to the wifi there :) - hows things? [06:45] amurray, pool, swimming - I keep getting surprised by the other hemisphere thing :) [06:45] amurray, good, just winter kicking in finally [06:46] amurray, prepping my FOSDEM talk [06:52] amurray: by the way, have you had a chance to look at the snapd security reviews? Till has been asking for status on the snapctl one. [06:53] morning [06:54] hey mborzecki [06:55] zyga: hey [07:33] zyga: on friday i preapred an update for the snapd package in opensuse, i'll be opening a request to system:snappy in a bit [07:34] mborzecki, thank you! [07:40] good morning mvo [07:42] jamesh: ficfdjcnggefhgnnrbdivicircgiffth [07:42] ugh.. sorry mashed my yubikey by mistake [07:42] jamesh: no not yet, I was tied up doing snap reviews last week, so hopefully this week (although with sprint prep etc it's looking a bit dicey...) - apologies [07:42] amurray: okay, thanks. [07:42] good morning zyga [07:43] jamesh: it's still on my todo list so I'm still hopeful [07:44] mvo: hey [07:44] hey mborzecki [07:52] PR snapd#9818 closed: cmd/libsnap-confine-private: make unit tests execute happily in a container [07:59] jamesh: hi, do you remember whether your fix for launching xwayland in mutter landed? [08:14] hm something is broken on opensuse: [08:14] type=AVC msg=audit(1610352782.280:380): apparmor="DENIED" operation="create" profile="snap.ohmygiraffe.ohmygiraffe" pid=7486 comm="love-0.9" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" [08:15] mborzecki: it was fixed in groovy-updates, and upstream in Mutter 3.38.2. [08:15] ofc connecting to x does not work at this point [08:15] jamesh: thanks! [08:16] mborzecki: the change wasn't merged to mutter master, so GNOME 4.0 will require the snapd side fix [08:16] next one is 4.0 already? [08:16] yeah [08:17] at least, that's the plan right now [08:17] It's still an incremental release rather than a big shake up like GNOME 2.0 or 3.0 [08:21] amurray: still around? do you know whether socket(AF_UNIX, .. , 0) would be covered by some apparmor abstraction by default, or is there an explicit rule needed? [08:23] ha i see `unix (create),` in /etc/apparmor.d/abstractions/base so wth happens there? [08:27] morning [08:27] good morning pstolowski [08:44] pstolowski: hey [09:12] anyone can access https://bugs.launchpad.net/snapd/+bug/1901489 ? [09:12] it's refrenced in our apparmor profiles but appears to be private [09:14] mborzecki: I can subscribe you to it, if you want [09:14] jamesh: please do, thanks! [09:14] mborzecki: done [09:15] jamesh: thank you! [09:18] mborzecki: the decision seemed to be that it wasn't a security bug, so perhaps it could be made public [09:19] (and it was fixed in the previous release of snapd) [09:19] tbh it needs to be public as we refer to that bug in every apparmor profile that plugs x11 [09:51] mborzecki: hey, are you blocked on anything for finishing the kernel commandline update resealing? [09:51] mvo: no, i need to get back to the brach and update it [09:52] mvo: trying to deal with pacakge updates in other distros atm [09:52] fedora is done, but there's trouble in opensuse land [09:52] zyga: i've addressed your suggestion re ini section handling, doing some testing and will push soon [09:52] mborzecki: ta [10:28] pstolowski, cool, just ping me for review any time please [10:29] working on FOSDEM talk [10:29] mvo, zmk moved up the review ladder, should be through NEW soon [10:29] zyga: nice [11:49] PR snapcraft#3408 opened: elf: extract defined symbol versions [12:17] pstolowski, https://github.com/snapcore/snapd/pull/9817#pullrequestreview-565298574 [12:17] PR #9817: cmd/snapd-generator: don't create mount overrides for snap-try snaps inside lxc [12:17] pstolowski, the comment feature is definitely a separate pass [12:18] cmatsuoka, hey claudio :) [12:18] long time no see [12:23] pstolowski, mborzecki: btw; did you guys see the new C and C++ error definitions? [12:23] finally sane error handling in C++ [12:24] and finally nice error handling in C [12:24] and it's one spec! :) [12:24] not error prone, well defined, easily usable [12:24] zyga: got link? [12:24] pstolowski, as a quick comment, my earlier code had two functions that would let you do per-line processing [12:25] and have ini-file and key=value file things more clealry [12:25] *clearly and cleanly perhaps [12:25] mborzecki, one sec [12:25] it's still in the history of the PR i believe [12:26] mborzecki, offtopic: getpolarized is a nice way to store scientific & research documents [12:27] mborzecki, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2289.pdf [12:29] mborzecki, I'm going to adopt that for my own projects for sure [12:29] zyga: coming to your production compiler in 5-10 yrs xD [12:29] nah, you don't need anything new [12:29] read the spec [12:29] it's really a way to return an union [12:29] and know if the error path or success path was taken [12:30] suspect it will be in gcc/clang instantly and backported as library to older compilers [12:31] * zyga returns to FOSDEM stuff [12:37] pedronis, good morning [12:40] is there a userspace tool to parse the binary apparmor profile? [12:40] mborzecki, no [12:40] zyga: haven't seen that c/c++ spec. sounds cool but it's a pitty it will always be a mixed bag of styles & legacy stuff when you are interacting with 3rd party APIs, the adoption of new features is terribly slow [12:40] mborzecki, I looked at this a while and there's only kernel code [12:41] pstolowski, I agree, any susccessful tech has some legacy [12:41] mborzecki, I wrote a part of the parser for the binary profile myself [12:41] mborzecki, I got stuck on a section that involved decoding the state machine that seems to include things that are standard and I'm familiar with (DFA/NFA) [12:41] zyga: hi [12:41] mborzecki, as well as some now concepts that I had to decode via code journeys [12:42] mborzecki, I can find that code but it's partial and doesn't show all the bits yet [12:42] maybe i can dump something with -D at least, the broken profile is rather small now [12:43] mborzecki, nope, not that I recall [12:43] I mean, I can show you the kernel side [12:43] I think that would be very useful [12:43] I would re-start that in go (I originally used python) [12:43] interested? [12:44] a parser and (perhaps, though not sure it is possible) decompiler [12:44] (not sure because DFA optimization and even basic processing makes irreversible changes so perfect source reconstruction is impossible [12:47] zyga: nah, i hoped there's some ready tool i could try and compare the outputs with, but i don't want to spend too much time on it [13:19] pstolowski, hi [13:19] pstolowski, could you run preseed test' [13:19] ? [13:20] cachio: hi! sorry, i haven't tried yet since Friday, busy with other things, will do later today [13:24] pstolowski, ok, current 21.04 image is still broken [13:40] cachio: ack, thanks [13:59] cachio, FYI, I've created the repo for our spread for at https://git.ostc-eu.org/OSTC/tools/oh-spread [14:00] it's sadly crossing the github/gitlab boundary [14:00] so no github actions, for example [14:00] I'll push the code in a moment [14:24] PR snapcraft#3409 opened: Fix a few licenses in ros-related test files [14:38] * pstolowski lunch [14:42] cachio, I'm setting up a pipeline for spread [14:43] cachio, I've seen some errors from go vet [14:43] cachio, https://git.ostc-eu.org/OSTC/tools/oh-spread/-/jobs/1048 [14:43] cachio, have you seen those or fixed those in your fork? [14:43] I'll fix those shortly in case they were under the radar before [14:43] niemeyer, ^ [14:54] PR snapcraft#3410 opened: project: enable experimental target-arch support for core20 [14:56] zyga, hi [14:56] let me check [14:57] cachio, the dead code bits are due to a change in the go compilre [14:57] *compiler [14:57] and seem harmless, just need fixing [14:57] the mutex corruption is real [14:58] zyga, which go compiler are you using there? [14:59] latest, let me check [15:00] cachio, 1.15.6 [15:01] we use 1.10.4 [15:01] by default [15:02] zyga, it is quite old the current one [15:02] yeah, that's a bit old now [15:03] zyga, so, which is the idea for testing in gitlab? [15:03] because currently tests are executed on gce [15:03] cachio, we use gitlab for everything [15:03] cachio, including for project tracking [15:03] zyga, so the testing of spread will be done in qemu or lxd? [15:04] cachio, gitlab pipelines let you run whatever you want [15:04] cachio, right now I want unit tests [15:04] cachio, and then self-test via spread [15:04] zyga, ok [15:04] cachio, though I don't have a GCE token yet, I'm okay with that [15:04] cachio, the main usage. for me, will be qemu [15:04] so I'll definitely run those [15:04] zyga, perfect [15:05] cachio, but my first concern are unit tests [15:05] cachio, as all the upcoming changes just need those [15:05] zyga, yes [15:06] there are not many unit tests [15:06] cachio, yeah, but I plan to add those with the changes I make [15:06] it is mostly tested by spread tests [15:06] it's just something easier tested at this level [15:06] zyga, agree [15:35] * cachio lunch [15:35] ijohnson, classy response there! [15:35] haha thanks [15:35] I was carried away [15:36] haha no worries, thanks for responding! I appreciate your prompt responses to comments on bugs :-) [15:36] well, to some of them [15:37] I need to improve my inbox filtering [15:37] I really miss the "bundles" that google inbox used to provide [15:38] that simple little UI element made it so much more manageable to me, like I can see when a kind of email is new as the bundle bubbles up, but if there are many such kinds of emails I don't get distracted by all of those [15:38] now I just have a bunch of labels and "skip the inbox" kind of filtering setup so I have to remember to go check the label folders manually rather than have them naturally bubble up to the top [15:38] oh well [15:38] I think I need to switch to folder-per-project [15:38] I just didn't set that up yet [15:39] and move from gmail off to fastmail with my launchpad traffic [16:09] PR snapd#9820 opened: o/snapshotstate: handle conflicts between snapshot forget, export and import [16:30] cachio, first patch :) [16:35] niemeyer, cachio: https://github.com/snapcore/spread/pull/111 [16:35] PR spread#111: Do not copy log.Logger and the contained sync.Mutex [16:36] * zyga notices the typo in the branch name [16:36] oh well [17:30] ooof is master broken [17:31] https://pastebin.ubuntu.com/p/RPBhtSQYXK/ [17:42] ijohnson, oh [17:43] weird, older library? [17:43] ijohnson, how did that happen? [17:46] cachio, I think spread CI is a bit broken [17:46] https://travis-ci.org/github/snapcore/spread/builds/753973306 [17:47] it's testing with old go vet perhaps [17:47] and _aix is not a feature flag [17:47] zyga: no idea I'll have to look at it in a bit, it was from a spread runner [17:47] ijohnson, let me know if you have a PR up [17:48] zyga: you mean to see the error or one that fixes it? [17:48] zyga, checking [17:48] I don't have a fix up but will probably look at it after my lunch [17:49] ijohnson, if you get stuck ping me, I'll gladly look [17:50] sure thanks for the offer, hopefully it's something silly === ijohnson is now known as ijohnson|lunch [17:55] cachio, term_unix_aix is being compiled together with term_unix_linux [17:56] cachio, can you bump go version used there? [17:56] "1.10" [17:57] zyga, this is declared in .travis [17:57] ah, [17:57] should I bump it? [17:57] well, we could use same versio we have for snapd [17:58] zyga, it needs a new PR [17:59] cachio, what's the version used for snapd? [17:59] cachio, though I suspect some chicken and egg will happen [17:59] 1.10 :) [17:59] new vet will pick up the issues I ran into [17:59] hmm, but that's the version used now? [17:59] ah, wait [18:00] best_golang=golang-1.10 [18:00] zyga, this is version we use for testing [18:00] this is using 1.10 [18:00] cachio, ok, can you suggest a way out of the situation [18:01] disable go vet? bump base go version, pin old go dependencies [18:01] the problem here is that spread itself is not self-sufficient but pulls dependcies [18:01] but those dependencies have abandoned old go [18:01] so it's not passing [18:01] what's the solution? [18:02] I think we could bump go [18:02] perhaps to 1.13 from focal? [18:02] seems to be the more correct thing to do [18:02] 1.13.8 [18:02] I would love to introduce module support so that we can pin the right versions of dependencies [18:02] right now it's all a moving target [18:02] zyga, did you arleady tried 1.13.8? [18:03] we can try that [18:03] I'll create a PR and see if that works well [18:03] yes, go vet is okay there [18:03] but I also have more patches in my tree (mainly go.mod support) [18:03] but I _suspect_ that's fine [18:03] zyga, ok, so lets bump to 13.8 [18:04] zyga, do you want to create the PR¡ [18:04] ? [18:04] just need to update the .travis.yml file with the desired version [18:04] cachio, yeah, [18:05] cachio, I'll do that later today though that version will pick up other errors and fail as well [18:05] also update the spread.yaml [18:05] we'll iterate [18:05] at some point we need all the fixes together [18:05] GOVERSION: 1.10.4 -> GOVERSION: 1.13.8 [18:05] and also we need to update hte system which is used for testing [18:06] ubuntu-18.04-64 -> ubuntu-20.04-64: [18:06] there's one more issue in humbox [18:06] yeah [18:06] I think that's a good start [18:07] cool, I'll get back to that :) [18:07] zyga, nice, thanks [18:35] zyga: I see the issue with that snap-confine unit test failure, it was only on trusty, and trusty's glib is too old to use g_autofree [18:36] I'll file a pr after I verify my fix works via spread [18:36] see also https://github.com/snapcore/snapd/pull/9818 [18:36] PR #9818: cmd/libsnap-confine-private: make unit tests execute happily in a container [18:41] ijohnson|lunch, ahh [18:41] nice [18:42] ijohnson|lunch, current status: playing talisman :) [18:43] Nice! Enjoy [18:43] * ijohnson|lunch is getting groceries over lunch, not quite as entertaining [18:55] PR snapd#9821 opened: tests: skip interfaces-openvswitch spread test on debian sid [19:40] PR snapd#9822 opened: tests: new actions workflow to autotically tag a PR with "Run Nested" [20:06] * cachio afk === ijohnson|lunch is now known as ijohnson [20:26] zyga: hey if you're around, I have a fix https://github.com/snapcore/snapd/pull/9823 [20:26] PR #9823: cmd/libsnap-confine-private/cleanup-funcs-test.c: rm g_autofree usage <⚠ Critical> [20:26] cachio: ^ [20:26] yeah [20:26] around just fixing uplink at home (back on backup) [20:28] nice, thanks! [20:28] ijohnson reviewed [20:29] thanks! [20:30] PR snapd#9823 opened: cmd/libsnap-confine-private/cleanup-funcs-test.c: rm g_autofree usage <⚠ Critical> [20:31] ijohnson back on other link [20:45] PR snapd#9824 opened: interfaces/greengrass-support: back-port interface changes to 2.48 [21:30] PR snapcraft#3408 closed: elf: extract defined symbol versions [21:36] PR snapd#9825 opened: tests: using labeler action to add automatically a label to run nested tests <⛔ Blocked> [21:45] PR snapcraft#3360 closed: project loader: advanced grammar support for lists [22:26] Bug #1911066 opened: snapctl get fails to get all the config [23:46] PR snapd#9823 closed: cmd/libsnap-confine-private/cleanup-funcs-test.c: rm g_autofree usage <⚠ Critical>