[04:34] <mithrison> hi
[04:34] <mithrison> I'm having problem running snap and snapcraft on ubuntu 18 server on raspberry pi.. details and logs --> https://forum.snapcraft.io/t/multipass-on-raspberry-pi-3b/12162/2
[04:40] <amurray> mithrison: looks like this is a known issue https://github.com/CanonicalLtd/multipass/issues/770
[04:42] <mithrison> amurray Is it an issue with Ubuntu 18 specifically?
[04:42] <amurray> mithrison: the ubuntu 18.04 raspberry pi kernel does not support kvm - see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1783961 for more info
[04:44] <mithrison> So use 16? amurray
[04:45] <mithrison> the proper way to enable KVM support on any pi is to set:dtoverlay=vc4-kms-v3din the config.txt file of the bootloader, the kernel is specifically set up for this via the included raspberry pi foundation patches.
[04:45] <mithrison> That's exactly what I did BTW
[04:46] <amurray> mithrison: hmm ok - sorry I am not sure (am not a rpi expert) ogra ^^^ ?
[05:19] <mborzecki> morning
[06:00] <zyga> Hey
[06:01] <mborzecki> zyga: hey hey
[06:53] <zyga> mborzecki: I have an errand in the morning
[06:53] <zyga> I sent a small python PR
[06:53] <zyga> I have more on GH but after this one
[06:53] <zyga> I will be online in about an hour
[06:53] <mborzecki> zyga: i reviewed 2 python prs from you, is that something new?
[07:00] <mvo> hey hey, what did I miss yesterday?
[07:01] <mborzecki> mvo: hey, probably not much, thursday felt a bit slow
[07:01] <mvo> mborzecki: 'k
[07:02] <mvo> mborzecki: I think I owe you a review, what was the PR again?
[07:02] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/7041 :)
[07:03] <mvo> aha, yes
[07:03] <mvo> doing that now before anything else gets in the way
[07:10] <mborzecki> mvo: thank you!
=== pstolowski|afk is now known as pstolowski
[07:25] <pstolowski> mornings!
[07:27] <mvo> hey pstolowski, good morning
[07:27] <mborzecki> pstolowski: hey
[07:48] <mborzecki> mvo: about post staging callback, for instance i'm using it to copy bootenv files generated by snap prepare-image to the structure that contains system-boot data
[08:05] <zyga> re
[08:05] <zyga> mborzecki: looking now, sorry, some stuff took longer than we expected
[08:09] <zyga> mborzecki: replied to both https://github.com/snapcore/snapd/pull/7065 and https://github.com/snapcore/snapd/pull/7068
[08:09] <zyga> hey mvo
[08:11] <mvo> hey zyga - in a meeting right now
[08:12] <zyga> mvo: hey, nothing urgent, just wanted to say hi :)
[08:12] <zyga> pstolowski, mborzecki: if you guys +1 https://github.com/snapcore/snapd/pull/7068 I will open a small follow-up and then we have the path towards those namespace tests :)
[08:13] <zyga> there are two more python changes needed but they are much simpler than even this simple pr :)
[08:26] <mborzecki> mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip
[08:27] <mborzecki> mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip/c
[08:27] <mborzecki> mvo: 3rd time's the charm: https://github.com/bboozzoo/snapd/tree/bboozzoo/gadget-update-wip
[08:36] <zyga> pstolowski: https://bugs.launchpad.net/snappy/+bug/1835342
[08:36] <zyga> what do you think?
[08:37] <pstolowski> zyga: woah, let me take a look
[08:38] <zyga> pstolowski: I guess that now with snap connections we  just show something we  always had and did
[08:40] <pstolowski> hmm, our parsing errors aren't very nice: error: cannot pack "/home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/snap-failing-interface-hooks": cannot parse snap.yaml: yaml: unmarshal errors:
[08:40] <pstolowski>   line 3: cannot unmarshal !!seq into map[string]interface {}
[08:42] <zyga> yeah
[08:42] <zyga> what is !!seq?
[08:43] <zyga> https://github.com/snapcore/snapd/pull/7065 is green, just needs reviews
[08:43] <zyga> +52,-1, all python test code
[08:45] <pstolowski> zyga: probably the array: "plugs: [home,network]"
[08:48] <pstolowski> zyga: re that bug, i suspect on refresh we don't remove obsolete plugs from conn state (only from the repo), and 'snap connections' shows conns from state; reloadConnections bites again
[08:50] <zyga> pstolowski: that's correct
[08:50] <zyga> pstolowski: on rollback we'd not restore connections otherwise
[08:50] <zyga> pstolowski: perhaps we should allow snap disconnect to remove stale connections that are not represented in the repo?
[08:51] <pstolowski> zyga: +1. also, i wonder if restart cures it (stray connections cleanup logic)
[08:51] <zyga> pstolowski: hmm, indeed
[08:52] <pstolowski> zyga: and maybe that's the explanation of entire stray connections issue that this cleanup was made for
[08:53] <pstolowski> we blamed some unknown bug in old snapd
[08:53] <zyga> I think we always knew this  part
[08:53] <zyga> that snaps can change interfaces over revisions
[08:53] <zyga> and  we don't do anything about the connections
[08:53] <zyga> we chose not to remove them early on
[08:53] <zyga> and  later on did
[08:54] <pstolowski> zyga: ah, we simply never shown them
[08:54] <zyga> until we grew snap connections
[08:54] <pstolowski> yes
[08:55] <zyga> brb, moving
[09:03] <pstolowski> zyga: i can take this bug after i finish current work on connects
[09:03] <zyga> yeah, no rush
[09:13] <pstolowski> zyga: updated the bug report
[09:20] <zyga> thanks
[09:28] <zyga> re
[09:28] <zyga> ondra: thanks for the call, I learned useful things
[09:29] <ondra> zyga and thank you for looking into this :)
[09:30] <mborzecki> zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c6
[09:30] <zyga> looking
[09:32] <zyga> mborzecki: it is helpful to the  reporter but I think we will eventually entirely do runtime detection or static declaration that must be provided by the distribution
[09:32] <zyga> mborzecki: in either case it is useful to the reporter, thank you
[09:33] <zyga> I need a 2nd review (thanks mborzecki) for simple python function https://github.com/snapcore/snapd/pull/7065
[09:37] <pstolowski> looking
[09:39] <zyga> pstolowski: thank you!
[09:43] <zyga> eh, travis has stale state
[09:46] <zyga> pstolowski: thank you!
[09:47] <zyga> pstolowski: would you mind doing another one in the same file: https://github.com/snapcore/snapd/pull/7068
[09:48] <pstolowski> zyga: sure. has conflicts though
[09:48] <zyga> aww, one sec
[09:52] <zyga> pstolowski: resolved
[09:55] <zyga> mborzecki: wow https://github.com/rswier/c4
[09:56] <pstolowski> zyga: 1-1 in a moment, will take a look afterwards
[09:56] <zyga> thank you
[09:56] <mborzecki> zyga: reads like an entry to ioccc
[09:59] <pstolowski> zyga: i'm working on a spread test with a failing connect- hook (just exit 1); what's the reason i see multiple debug messages like this in the failing task log: https://paste.ubuntu.com/p/M3J7gVrDjX/
[09:59] <pstolowski> ?
[10:00] <zyga> you must have SNAPD_DEBUG=1 or SNAP_CONFINE_DEBUG=yes  set
[10:29] <zyga> brb
[10:31] <pstolowski> zyga: got it; i think it would make sense to give more context in that message, and if possible show it just once
[10:31] <zyga> pstolowski: it cannot be shown once
[10:31] <zyga> pstolowski: each one is a real mount happening
[10:31] <zyga> pstolowski: it's spread all over the code
[10:31] <pstolowski> zyga: ah, got it
[10:31] <zyga> pstolowski: I lament that we cannot show you what is going on
[10:31] <zyga> pstolowski: but i fought that battle and lost
[10:31] <zyga> pstolowski: and we only show what is mounted when we die :/
[10:32] <zyga> pstolowski: or when we run debug build
[10:33] <mborzecki> zyga: hm mountsnoop maybe? it's from bcc
[10:34] <mborzecki> zyga: uh, nvm, thought you wanted to track all the mounts ;)
[10:35] <zyga> Nah, just print a debug message
[10:43] <zyga> pstolowski: replied, thanks for looking
[10:52] <pstolowski> zyga: one more comment
[10:52] <zyga> looking
[10:56] <zyga> pstolowski: fixed! thank you
[10:57] <pstolowski> zyga: should we have a simple test for that?
[10:57] <zyga> pstolowski: main is untested but now we can add actual tests easily, yeah
[11:07] <zyga> pstolowski: pushed  :)
[11:08] <pstolowski> ty
[11:09] <pstolowski> +1
[11:13] <zyga> pstolowski: thanks, I'll add more tests in a separate PR
[11:55]  * zyga goes for lunch
[12:20] <vidal72[m]> is this being worked on? https://bugzilla.redhat.com/show_bug.cgi?id=1438079
[12:26] <sergiusens> zyga: hye, do you still want review? got your notification as I was taking off flying over to my parents with my eldest for the winter break
[12:31] <zyga> re
[12:31] <zyga> sergiusens: thank you, it's all good
[12:31] <zyga> vidal72[m]: checking
[12:32] <zyga> vidal72[m]: no, not at present
[12:32] <zyga> vidal72[m]: we don't have anyone idle that can jump into it, we have other commitments first
[12:32] <zyga> pstolowski: more tests https://github.com/snapcore/snapd/pull/7069
[12:33] <zyga> vidal72[m]: I will likely work on it but I don't control my work queue directly
[12:36] <zyga> mborzecki, pstolowski: essential but simple https://github.com/snapcore/snapd/pull/7070
[12:36] <zyga> just use what we've built
[12:38] <zyga> I tried to explain why this is useful for the upcoming namespace tests
[12:41] <zyga> I only have one more branch to propose for mountinfo-tool (that I know of) for the test branch to be useful
[12:41] <zyga> but we are super close now
=== ricab is now known as ricab|lunch
[13:43] <ogra> mvo, i seem to remember you had a patch to timedated that prevented the symlink issues we had with it ... couold it be that this patch got lost ? (seems abeato is running into the issues we had before that again)
[13:58] <mvo> ogra: possible, I resurrected two patches around this area but maybe I missed one
[13:59] <ogra> yeah, they are quite old (from pitti originally i think ... around 15.04)
[14:01] <zyga> mvo: second review for https://github.com/snapcore/snapd/pull/7069 pretty please?
[14:02] <zyga> just unit tests for python
[14:04] <mvo> zyga: in a meeting right now
[14:04] <zyga> mvo: no worries, thanks
[14:04] <zyga> mborzecki, pstolowski: https://github.com/snapcore/snapd/pull/7071 one more python renumbering pR
[14:05] <zyga> this time with tests up front :)
[14:06] <zyga> oh, sergio is off?
[14:06] <zyga> ah right I remember now
[14:14] <zyga> actually
[14:15] <zyga> ijohnson: can you look at https://github.com/snapcore/snapd/pull/7071 and https://github.com/snapcore/snapd/pull/7069
[14:15] <zyga> I think you will use this tool a lot
[14:15] <ijohnson> zyga: sure
[14:15] <zyga> mountinfo-tool is a bit like findmnt, but more tailored to what we do
[14:15] <zyga> the context is that I'm extending it to propose a new spread test that measures the configuration of the mount namespace
[14:16] <zyga> and the extensions are mainly to build a deterministic view of the mount table
[14:16] <zyga> with things like memory size or boot ordering of cgroup mount units neutered
[14:16] <zyga> the tool started without any tests so I'm also adding some small unit tests as I go
[14:16] <ijohnson> zyga: interesting yes that sounds very useful I will look into mountinfo-tool today
[14:17] <zyga> in spread debug shell it is on path
[14:17] <zyga> and works on each os
[14:17] <zyga> well, each distro
[14:18] <Laney> hi
[14:19] <Laney> using snapcraft, is it possible to natively build for i386 on my amd64 machine?
[14:19] <Laney> launching an i386 multipass VM or lxd container should work, but I don't see an option for it, only --target-arch which says it's going to cross compile
[14:28] <zyga> Laney: I don't know of any option, perhaps sergiusens can help?
[14:29] <zyga> wow, I just did something cool
[14:29] <zyga> I don't know which key I hit
[14:29] <zyga> but I got a cool tab completion I never saw before:
[14:30] <zyga> zyga@yantra:~/snapd/tests/lib/bin> {.m{ountinfo-tool.swp,ypy_cache},M{ATCH,akefile},REBOOT,any-python,cleanup{,-frames},host,mountinfo-tool,not,snap-tool,unshared{,-slave}} ^C
[14:30] <zyga> how do I do that?
=== ricab|lunch is now known as ricab
[15:01] <mvo> cmatsuoka: just fyi, I created a "uc20" branch for snapd and added a PR with your changes. I will do the same for our other git repos and update spike-tools. this way we should have a bit more consistency :)
[15:03] <zyga> https://github.com/snapcore/snapd/pull/7071 is green
[15:04] <cmatsuoka> mvo: excellent, this should make things easier
[15:06] <cmatsuoka> mvo: uc20 meaning the uc20 spike, right? we'll probably have to start over for the "real" uc20
[15:06] <mvo> cmatsuoka: yeah, for the real uc20 we need a new name :) maybe just 20?
[15:07] <cmatsuoka> mvo: could be, did we use just 18 for core 18?
[15:07] <mvo> cmatsuoka: yes
[15:08] <cmatsuoka> mvo: 20 for the real thing then :D
[15:45] <ogra> ppisati, have you seen https://forum.snapcraft.io/t/how-do-i-add-support-for-a-custom-touch-screen-on-my-raspberry-pi/12148 ?
[15:45] <ogra> (i'm a bit out of ideas here)
[15:50] <Laney> I ended up making an i386 VM myself with multipass (passing it the URL to a cloud image!) and then using --destructive-mode or whatever it is, since we apparently don't produce minimal cloud images for anything other than amd64 & snapcraft uses cloud-images.u.c rather than the ubuntu: remote built into lxd
[15:52] <zyga> https://github.com/snapcore/snapd/pull/7071 anyone?
[15:53] <zyga> Laney: I have https://spread.zygoon.pl
[15:53] <zyga> not sure if that helps you with an image
[15:53] <zyga> it's a qemu vm with ubuntu/ubuntu credentials
[15:55] <Laney> zyga: thx, what I needed in this case was the ability to tell multipass and snapcraft to launch i386 images, guess I should be a good citizen and file bugs really
[15:55] <zyga> yeah
[15:55] <zyga> I *think* it should be supported
[15:55] <zyga> Saviq: ^ ?
[15:56]  * zyga fires another round of spread
[15:56] <Saviq> zyga, Laney: yeah we could certainly launch CPU-compatible images, what we've so far said we did not want to do was emulation (i.e. arm on x86)
[15:57] <Saviq> but we may have to revisit that, especially if that would mean you could run/build arm on x86 Windows/macOS
[15:58] <Saviq> I was worried about the state of qemu's emulation support, remembering our phone times and virt Launchpad builders
[15:58] <Laney> Saviq: hey there
[15:58] <Laney> my bug's not going to be about emulation or anything, but by all means feel free to do that too :D
[15:59] <cjwatson> zyga: that's complete-into-braces, M-{
[16:10] <zyga> cjwatson: thank you!
=== pstolowski is now known as pstolowski|afk
[16:20] <zyga> mvo: schema anyone https://github.com/cuelang/cue
[16:20] <mvo> zyga: nice
[16:21] <zyga> niemeyer: ^^ cue for schema
[16:21] <zyga> and maybe for data too
[16:28] <ogra> Laney, simply dont use VMs at all ... create a conventioanl i386 lxd container, install snapcraft in it and "export SNAPCRAFT_BUILD_ENVIRONMENT=host" ... then just build (no --target-arch or any other options)
[16:29] <Laney> ogra: sure, that seems to be more or less what --destructive-mode does too
[16:30] <ogra> thats how i (have to ) use snapcraft for arm and arm64 too ... multipass is just getting in the way if you are not always using amd64
[16:30] <ogra> yeah, --destructive-mode is similar to that
[16:30] <Laney> but I think the situation could be improved a bit, that's what my requests are about :)
[16:31] <ogra> by making multipass optional ;)
[16:31] <Laney> no way, the multipass exprience is great
[16:31] <ogra> or rather have it detect if its on non amd64/non-windows/non-macos
[16:31] <ogra> and fall back to lxd
[16:32] <ogra> as someone who 90% of the time builds for non x86 i find the multipass experience most awful
[16:32] <Laney> there's no reason it couldn't launch an i386 vm for me (in fact it can if you go find the .img yourself)
[16:32] <Laney> dunno if there's any big blockers on arm tho
[16:32] <ogra> no kvm/qemu would be the first one ;)
[16:33] <Laney> hmm
[16:33] <Laney> how do the clouds work?
[16:33] <ogra> aarch64 ...
[16:33] <ogra> (that has kvm and spins up armhf VMs i think)
[16:34] <Laney> oh right, yes, I meant arm64
[16:34] <Laney> we make armhf containers indeed
[16:34] <ogra> but most our arm devs dont have fancy arm64 machines at home
[16:34] <ogra> they want to quickly build snaps for/on their Rpi
[16:34] <ogra> (many of our customers too sadly)
[16:36] <Laney> nod
[16:36] <Laney> I think they and you would appreciate a slick experience there too, either great cross compilation support or emulation
[16:36]  * Laney simply hasn't used that himself
[16:37] <ogra> we had that with snapcraft 2.0
[16:37] <ogra> even fancy cross building in lxd
[16:40] <zyga> mvo: any chance for a review today?
[16:43] <sergiusens> Laney: your request seems doable, but perhaps not this cycle as we are really underpowered for any extra load now
[16:43] <Laney> hey sergiusens!
[16:43] <Laney> it's ok, no particular priority from me
[16:46] <sergiusens> great, there are plans in the air, but nothing that can be done short term and wouldn't be a hack
[16:53] <mvo> zyga: not looking great, already relatively late - which one is the most important one you need?
[17:05] <zyga> mvo: this one  https://github.com/snapcore/snapd/pull/7071
[17:06] <zyga> just test tool tweaks (with tests)
[17:07] <zyga> mvo: I have some more state on top but it will be in separate PRs, sorting for determinism and small tweak to renumbering that shrinks delta between unrelated options
[17:25]  * ijohnson relocates to coffee shop
[17:43]  * zyga fights non-reproducible output
[17:57] <Eickmeyer> With Chromium moving to snap-only in Ubuntu, I'd like to get this issue moved along as quickly as possible for users of Ubuntu Studio: https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/13
[17:57] <Eickmeyer> How can I get this going? I don't know much about how to work with snaps.
[18:15] <ardaguclu_> Could you please review?, https://github.com/snapcore/snapd/pull/7050. I made a dummy mistake by sending this PR from master branch and now I can not continue other issues.
[18:46] <zyga> ardaguclu_: hey
[18:47] <zyga> ardaguclu_: you can always close it and reopen  anew one
[18:47] <ardaguclu_> zyga: hey
[18:47] <zyga> ardaguclu_: I think this is something for pstolowski|afk to review next week
[18:47] <zyga> I'm not familiar with that part to review it
[18:47] <ardaguclu_> zyga: thanks, that would be better closing and opening again
[18:47] <zyga> it's really tricky and I tried recently and spectacularly failed to fix that
[18:49] <ardaguclu_> after looking at issues at launchpad, is it ok directly solving or asking here before that
[18:50] <zyga> ardaguclu_: it's best to talk but trying does not hurt
[18:50] <zyga> some issues are harder than others
[18:51] <zyga> this one is particularly complex as behavior differs across host system and go version
[18:51] <ardaguclu_> ok, thanks
[18:51] <zyga> it requires careful analysis of behavior to  come up with reasonable patches
[18:51] <zyga> I failed at that btw
[18:51] <ardaguclu_> I tried it 18.04 and 16.04
[18:51] <zyga> thank you for contributing though, perhaps  there is something  else you want to look at?
[18:52] <zyga> ardaguclu_: our spread suite runs on centos, amazon linux, fedora and many others
[18:52] <ardaguclu_> but you are right, there are lots of different versions
[18:52] <zyga> yeah
[18:52] <zyga> some build with gccgo
[18:52] <zyga> some with go
[18:52] <zyga> 1.9, 1.10, 1.12
[18:52] <zyga> etc etc
[18:52] <ardaguclu_> yeah definitely
[18:52] <zyga> then depedning on what is happening on the host network, the errors are somehow conveyed to go
[18:53] <zyga> so (go-version, glibc-version, go-resover-vs-libc-resolver, network behavior) => (error object)
[18:53] <ardaguclu_> what is the approaches such problems in our case
[18:53] <zyga> the trick is to map the error object to a should-we-rertry flag
[18:53] <ardaguclu_> trying at whole versions
[18:54] <zyga> we don't have the  set of tuples that  describe possiblities
[18:54] <zyga> so changes are kind of ad-hoc
[18:54] <zyga> we need data first
[18:54] <ardaguclu_> ok, thank you very much
[18:54]  * zyga makes the final coffee of the day to work on another bug
[18:55] <zyga> ardaguclu_: thank you! :)
[18:55] <ardaguclu_> I really like snap, that's why, I will continue contribution :)
[18:55] <zyga> ardaguclu_: do stick around, it's great to have contributions
[18:59] <zyga> jjohansen: hey, do you have a second for a quick question
[19:00] <jjohansen> zyga: uhmmm, never :)
[19:00] <jjohansen> what is it?
[19:00] <zyga> jjohansen: what is the difference beween network and  network_v8/
[19:00] <jjohansen> zyga: may I ask why you are messing around in the packed protocol?
[19:00] <jjohansen> :)
[19:01] <zyga> jjohansen: I'm not but we look for both and some kernels have v8 but not the other one
[19:03] <zyga> jjohansen: (what I mean by "look  for both" is snapd checks advertised kernel features)
[19:03] <zyga> jjohansen: is v8 enough if present?
[19:04] <jjohansen> zyga: v8 requires the yet to be released apparmor 3
[19:04] <zyga> I see
[19:04] <zyga> should we look for v8 then?
[19:04] <jjohansen> its a clean abi break that came about from Linus's revert it 4.15
[19:04] <zyga> mmm
[19:04] <zyga> I recall that, yes
[19:05] <jjohansen> yes, upstream and debian will only ever have v8
[19:05] <jjohansen> we will carry a compat patch in ubuntu/suse for several years to support old userspaces
[19:05] <zyga> jjohansen: aha,  I understand now
[19:05] <zyga> jjohansen: and is the  apparmor_parser in ubuntu today using  network or networkv8?
[19:06] <zyga> 2.13* AFAIR
[19:06] <jjohansen> it is using network
[19:06] <zyga> ok
[19:06] <jjohansen> you will require abi rules in policy to get network_v8
[19:06] <zyga> so perhaps we don't need to check for network_v8
[19:06] <zyga> until we do
[19:07] <jjohansen> sure, looking for it atm won't get you anything
[19:07] <zyga> thank you, that was what I was curious about
[19:07] <zyga> I'll adjust snapd next week when jdstrand can review it
[19:09] <zyga> jjohansen: speaking of which, is the  packing protocol documented? I tried to "reverse" it at one point by going through the kernel sources and  compiling various crafted profiles but I failed to decompile the packed state machine
[19:10] <jjohansen> zyga: I have some documentation started but its certainly not any even close to reasonable shape
[19:10] <jjohansen> zyga: there are some tools coming that will help with the whole thing
[19:10] <zyga> jjohansen: would you be interested if I tried to help in that  in small capacity?
[19:11] <jjohansen> They can handle the unpacking and output in clean text the state machine
[19:11] <zyga> interesting, that's what I was looking for at the time
[19:12] <jjohansen> zyga: I am always interested in help, as long as the help doesn't take more effort than I get back out
[19:13] <jjohansen> zyga: ping me in a couple of weeks, next week is bad for me
[19:13] <zyga> jjohansen: gladly
[19:13] <zyga> jjohansen: if you send me any git places to look, I can try to  familiarize myself with what is being made
[19:14] <jjohansen> zyga: I have to dig for it, the work is pre our move to git
[19:15] <zyga> jjohansen: no rush, I mainly follow apparmor from linus tree
[19:15] <zyga> (though that's usually "late")
[19:15] <jjohansen> ah, yeah this is userspace stuff so it will be landing in the gitlab side of things
[19:16] <jjohansen> I'll see if I can't get a branch up as a WIP pull request
[19:16] <zyga> jjohansen: which repo holds the userspace stuff?
[19:16] <jjohansen> https://gitlab.com/apparmor/apparmor/
[19:17] <jjohansen> zyga: and if you want to go a little broader https://gitlab.com/apparmor/
[19:18] <jjohansen> we are going to start moving to doing kernel dev in gitlab side of things and the sync it to the kernel.org tree instead of directly commiting
[19:19] <zyga> jjohansen: thanks, understood
[19:46]  * zyga found a bug in the ref code, finally
[22:07]  * zyga EOWs