| 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:34 |
| amurray | mithrison: looks like this is a known issue https://github.com/CanonicalLtd/multipass/issues/770 | 04:40 |
| 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:42 |
| mithrison | So use 16? amurray | 04:44 |
| 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:45 |
| amurray | mithrison: hmm ok - sorry I am not sure (am not a rpi expert) ogra ^^^ ? | 04:46 |
| mborzecki | morning | 05:19 |
| zyga | Hey | 06:00 |
| mborzecki | zyga: hey hey | 06:01 |
| 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? | 06:53 |
| mvo | hey hey, what did I miss yesterday? | 07:00 |
| mborzecki | mvo: hey, probably not much, thursday felt a bit slow | 07:01 |
| mvo | mborzecki: 'k | 07:01 |
| 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:02 |
| mvo | aha, yes | 07:03 |
| mvo | doing that now before anything else gets in the way | 07:03 |
| mborzecki | mvo: thank you! | 07:10 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings! | 07:25 |
| mvo | hey pstolowski, good morning | 07:27 |
| mborzecki | pstolowski: hey | 07:27 |
| 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 | 07:48 |
| zyga | re | 08:05 |
| zyga | mborzecki: looking now, sorry, some stuff took longer than we expected | 08:05 |
| 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:09 |
| mvo | hey zyga - in a meeting right now | 08:11 |
| 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:12 |
| zyga | there are two more python changes needed but they are much simpler than even this simple pr :) | 08:13 |
| mborzecki | mvo: https://github.com/bboozzoo/snapd/blob/bboozzoo/gadget-update-wip | 08:26 |
| 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:27 |
| zyga | pstolowski: https://bugs.launchpad.net/snappy/+bug/1835342 | 08:36 |
| zyga | what do you think? | 08:36 |
| pstolowski | zyga: woah, let me take a look | 08:37 |
| zyga | pstolowski: I guess that now with snap connections we just show something we always had and did | 08:38 |
| 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:40 |
| zyga | yeah | 08:42 |
| zyga | what is !!seq? | 08:42 |
| zyga | https://github.com/snapcore/snapd/pull/7065 is green, just needs reviews | 08:43 |
| zyga | +52,-1, all python test code | 08:43 |
| pstolowski | zyga: probably the array: "plugs: [home,network]" | 08:45 |
| 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:48 |
| 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:50 |
| pstolowski | zyga: +1. also, i wonder if restart cures it (stray connections cleanup logic) | 08:51 |
| zyga | pstolowski: hmm, indeed | 08:51 |
| pstolowski | zyga: and maybe that's the explanation of entire stray connections issue that this cleanup was made for | 08:52 |
| 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:53 |
| pstolowski | zyga: ah, we simply never shown them | 08:54 |
| zyga | until we grew snap connections | 08:54 |
| pstolowski | yes | 08:54 |
| zyga | brb, moving | 08:55 |
| pstolowski | zyga: i can take this bug after i finish current work on connects | 09:03 |
| zyga | yeah, no rush | 09:03 |
| pstolowski | zyga: updated the bug report | 09:13 |
| zyga | thanks | 09:20 |
| zyga | re | 09:28 |
| zyga | ondra: thanks for the call, I learned useful things | 09:28 |
| ondra | zyga and thank you for looking into this :) | 09:29 |
| mborzecki | zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1726382#c6 | 09:30 |
| zyga | looking | 09:30 |
| 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:32 |
| zyga | I need a 2nd review (thanks mborzecki) for simple python function https://github.com/snapcore/snapd/pull/7065 | 09:33 |
| pstolowski | looking | 09:37 |
| zyga | pstolowski: thank you! | 09:39 |
| zyga | eh, travis has stale state | 09:43 |
| zyga | pstolowski: thank you! | 09:46 |
| zyga | pstolowski: would you mind doing another one in the same file: https://github.com/snapcore/snapd/pull/7068 | 09:47 |
| pstolowski | zyga: sure. has conflicts though | 09:48 |
| zyga | aww, one sec | 09:48 |
| zyga | pstolowski: resolved | 09:52 |
| zyga | mborzecki: wow https://github.com/rswier/c4 | 09:55 |
| 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:56 |
| 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 | ? | 09:59 |
| zyga | you must have SNAPD_DEBUG=1 or SNAP_CONFINE_DEBUG=yes set | 10:00 |
| zyga | brb | 10:29 |
| 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:31 |
| zyga | pstolowski: or when we run debug build | 10:32 |
| mborzecki | zyga: hm mountsnoop maybe? it's from bcc | 10:33 |
| mborzecki | zyga: uh, nvm, thought you wanted to track all the mounts ;) | 10:34 |
| zyga | Nah, just print a debug message | 10:35 |
| zyga | pstolowski: replied, thanks for looking | 10:43 |
| pstolowski | zyga: one more comment | 10:52 |
| zyga | looking | 10:52 |
| zyga | pstolowski: fixed! thank you | 10:56 |
| 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 | 10:57 |
| zyga | pstolowski: pushed :) | 11:07 |
| pstolowski | ty | 11:08 |
| pstolowski | +1 | 11:09 |
| zyga | pstolowski: thanks, I'll add more tests in a separate PR | 11:13 |
| * zyga goes for lunch | 11:55 | |
| vidal72[m] | is this being worked on? https://bugzilla.redhat.com/show_bug.cgi?id=1438079 | 12:20 |
| 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:26 |
| zyga | re | 12:31 |
| zyga | sergiusens: thank you, it's all good | 12:31 |
| zyga | vidal72[m]: checking | 12:31 |
| 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:32 |
| zyga | vidal72[m]: I will likely work on it but I don't control my work queue directly | 12:33 |
| zyga | mborzecki, pstolowski: essential but simple https://github.com/snapcore/snapd/pull/7070 | 12:36 |
| zyga | just use what we've built | 12:36 |
| zyga | I tried to explain why this is useful for the upcoming namespace tests | 12:38 |
| 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 | 12:41 |
| === ricab is now known as ricab|lunch | ||
| 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:43 |
| mvo | ogra: possible, I resurrected two patches around this area but maybe I missed one | 13:58 |
| ogra | yeah, they are quite old (from pitti originally i think ... around 15.04) | 13:59 |
| zyga | mvo: second review for https://github.com/snapcore/snapd/pull/7069 pretty please? | 14:01 |
| zyga | just unit tests for python | 14:02 |
| 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:04 |
| zyga | this time with tests up front :) | 14:05 |
| zyga | oh, sergio is off? | 14:06 |
| zyga | ah right I remember now | 14:06 |
| zyga | actually | 14:14 |
| 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:15 |
| 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:16 |
| zyga | in spread debug shell it is on path | 14:17 |
| zyga | and works on each os | 14:17 |
| zyga | well, each distro | 14:17 |
| Laney | hi | 14:18 |
| 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:19 |
| zyga | Laney: I don't know of any option, perhaps sergiusens can help? | 14:28 |
| 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:29 |
| 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? | 14:30 |
| === ricab|lunch is now known as ricab | ||
| 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:01 |
| zyga | https://github.com/snapcore/snapd/pull/7071 is green | 15:03 |
| cmatsuoka | mvo: excellent, this should make things easier | 15:04 |
| 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:06 |
| cmatsuoka | mvo: could be, did we use just 18 for core 18? | 15:07 |
| mvo | cmatsuoka: yes | 15:07 |
| cmatsuoka | mvo: 20 for the real thing then :D | 15:08 |
| 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:45 |
| 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:50 |
| zyga | https://github.com/snapcore/snapd/pull/7071 anyone? | 15:52 |
| 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:53 |
| 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:55 |
| * 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:56 |
| Saviq | but we may have to revisit that, especially if that would mean you could run/build arm on x86 Windows/macOS | 15:57 |
| 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:58 |
| cjwatson | zyga: that's complete-into-braces, M-{ | 15:59 |
| zyga | cjwatson: thank you! | 16:10 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | mvo: schema anyone https://github.com/cuelang/cue | 16:20 |
| mvo | zyga: nice | 16:20 |
| zyga | niemeyer: ^^ cue for schema | 16:21 |
| zyga | and maybe for data too | 16:21 |
| 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:28 |
| Laney | ogra: sure, that seems to be more or less what --destructive-mode does too | 16:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:36 | |
| ogra | we had that with snapcraft 2.0 | 16:37 |
| ogra | even fancy cross building in lxd | 16:37 |
| zyga | mvo: any chance for a review today? | 16:40 |
| 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:43 |
| sergiusens | great, there are plans in the air, but nothing that can be done short term and wouldn't be a hack | 16:46 |
| mvo | zyga: not looking great, already relatively late - which one is the most important one you need? | 16:53 |
| zyga | mvo: this one https://github.com/snapcore/snapd/pull/7071 | 17:05 |
| zyga | just test tool tweaks (with tests) | 17:06 |
| 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:07 |
| * ijohnson relocates to coffee shop | 17:25 | |
| * zyga fights non-reproducible output | 17:43 | |
| 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. | 17:57 |
| 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:15 |
| zyga | ardaguclu_: hey | 18:46 |
| 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:47 |
| ardaguclu_ | after looking at issues at launchpad, is it ok directly solving or asking here before that | 18:49 |
| zyga | ardaguclu_: it's best to talk but trying does not hurt | 18:50 |
| zyga | some issues are harder than others | 18:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 | |
| 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:55 |
| zyga | jjohansen: hey, do you have a second for a quick question | 18:59 |
| 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:00 |
| zyga | jjohansen: I'm not but we look for both and some kernels have v8 but not the other one | 19:01 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| jjohansen | zyga: I am always interested in help, as long as the help doesn't take more effort than I get back out | 19:12 |
| 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:13 |
| jjohansen | zyga: I have to dig for it, the work is pre our move to git | 19:14 |
| 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:15 |
| 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:16 |
| jjohansen | zyga: and if you want to go a little broader https://gitlab.com/apparmor/ | 19:17 |
| 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:18 |
| zyga | jjohansen: thanks, understood | 19:19 |
| * zyga found a bug in the ref code, finally | 19:46 | |
| * zyga EOWs | 22:07 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!