[01:39] PR snapcraft#1186 closed: demos: add ROS content sharing demo [01:51] has anybody used snapcraft with a source file on dropbox? It appears that whatever mechanism dropbox is using to download the source is not following the redirects. There is just a file with html. I'm looking through the snapcraft code, but is it not using wget or something similar/ [01:54] hmm, looks like its using requests.get with allow_redirects=True [01:54] olympionex: seems like a credentials thing, can the file be downloaded anonymously? [01:54] can you wget the file? [01:54] yeah [01:54] from the link that is [01:58] copied and pasted the url from the yaml just to make sure [01:58] and it works fine with wget [01:58] but the pull phase of snapcraft is only getting some html [01:59] its a link share on dropbox which means anyone with the link should be able to download it, so no required login [02:08] sergiusens: here is a demo pastebin [02:08] http://pastebin.com/jdZuNVD4 [02:15] PR snapcraft#1194 opened: tests: remove repo.Ubuntu patch for plugins === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [02:47] sergiusens: nevermind, I was misinformed by something I read earlier. Apparently the url param at the end of the dropbox links determines whether its for a direct download or for just viewing the file on dropbox. I had read that dl=1 compressed the file but that appears not to be true [02:47] changing the links to dl=1 caused snapcraft to work fine === chihchun_afk is now known as chihchun [03:07] great [03:07] oh dear, it is already Wednesday here === chihchun is now known as chihchun_afk [03:57] PR snapcraft#1191 closed: tests: run the CLA check in a docker container [04:00] PR snapcraft#1194 closed: tests: remove repo.Ubuntu patch for plugins === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:34] zyga: hi, i tried to run "dnf install snapd" on fedora 25 but failed with "Failed to synchronize cache for repo 'zyga-snapcore', disabling." I believe it need be built against fedroa 25 as it works well on 24. [08:40] shuduo: hi [08:40] zyga: hi [08:40] shuduo: there are no build for fedora 24/25/26 yet; still on a TODO list, I need help if you are interested (we need two prerequisites packaged) [08:40] shuduo: the COPR build is disabled now [08:41] shuduo: and we have a package almost ready to release into the archive but because of the extra work to de-vendorize everything (which is starved for time) it has not been released [08:41] shuduo: I may re-start the COPR package with vendorized deps as that would help to unblock people [08:41] shuduo: but I really need help with extra maintenance work as my main duties are as upstream developer [08:41] zyga: interesting I just tried 24 today and see snap works good. [08:42] shuduo: it must be an older build [08:42] shuduo: we are at snapd 2.23.1 now (2.24 will release today) [08:43] shuduo: and 2.24 is good to release for fedora (like I built it for opensuse) but the extra golang deps are a blocker onw [08:43] *now [08:43] zyga: it's 2.22.1 on fedora 24. [08:47] hmmmm? [08:47] that's super odd :) [08:47] shuduo: where did you get your package again? [08:47] shuduo: did you build it yourself? [08:47] the CORP repo is unused for months [08:48] zyga: sorry i'm not familiar to dnf/copr since i did not use fedora quite long time. i am checking snapd status on other distro since it may help to some customer engagement [08:49] shuduo: I try to document the current status on the snapd wiki here ... [08:49] zyga: i just follow the instructions of snapcraft.io [08:49] https://github.com/snapcore/snapd/wiki/Distributions [08:49] * zyga goes to add opensuse to supported list there [08:50] (opensuse is supported since last week-ish) [08:50] then i find it from https://copr.fedorainfracloud.org/coprs/zyga/snapcore/ [08:50] shuduo: but that is snapd 2.14 [08:50] anyway [08:51] I need to spend some time on Fedora support [08:51] ideally after the 2.24 release tonight [08:51] I could re-enable COPR easily with the vendorized deps [08:51] (so same bits you get on ubuntu) [08:51] and I could work towards packaging missing stuff [08:51] shuduo: stick around; I can do this on Friday [08:51] zyga: i have customer ask if snap acn run with centos [08:52] shuduo: do you need fedora or centos? [08:52] shuduo: it can, though package is still far away [08:52] https://new.zygoon.pl/post/case-study-snapd-on-centos/ [08:52] zyga: i believe commercial customer need centos [08:52] but you can build it from source to see [08:52] shuduo: if you want to help on that I'll gladly welcome you on board :) [08:52] shuduo: centos package could be built from COPR [08:52] zyga: great. i will try it. [08:53] shuduo: with all vendorized bits it should not be hard (famous last words ;-) [08:53] shuduo: but the issue is strictly on packaging, the code works fine [08:54] zyga: i would like to study how to do that first. :) [08:54] shuduo: look at the blog post and stick around, I'm sure you can help [08:57] zyga: btw, seems debian is broken. https://bugs.launchpad.net/snapd/+bug/1672984. [08:57] Bug #1672984: can't install hello-world snap on debian [09:00] zyga: yes, dnf info snapd show it's 2.14. sorry my wrong msg. === davmor2_ is now known as davmor2 [09:46] shuduo: that's ok then, no mystery :) [10:02] tyhicks: hey, could you do a review for us today? [10:16] hi all, when booting a board with TI WL127x chip on it I get the following "warning" at bootup: set_link_flags failed File "/usr/lib/python3/dist-packages/probert/network.py", line 454, in wlan_event self.rtlistener.set_link_flags(ifindex, IFF_UP) RuntimeError: rtnl_link_change failed -16 [10:17] has anyone seen this? It seems that my interface is busy at the time of the request [10:26] PR snapd#3032 opened: cmd: rename all unit tests to $command/unit-test [10:26] PR snapd#3033 opened: cmd/libsnap: make mountinfo structures public [10:34] gbisson: looks like kernel/driver issue [10:39] zyga: well the driver is working fine though, and the connection is working just fine after that message [10:40] zyga: the driver is pretty well supported in mainline: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/net/wireless/ti [10:40] gbisson: "fine" may not be "correct" though, I'm not a kernel expert [10:41] tyhicks: specifically this PR: https://github.com/snapcore/snapd/pull/3031 [10:41] PR snapd#3031: cmd/snap-confine-suid-trampoline: add new helper [10:42] zyga: but I agree I don't see that warning on RPi, maybe someone else will try with TI someday, we'll see, thanks anyway [11:08] PR snapd#3034 opened: interfaces: log if the system goes into ForceDevMode [11:14] mvo, currently, my application has the problem described in the bug, https://bugs.launchpad.net/snappy/+bug/1590679 in strict mode. However, I cannot find any missing apparmor policy output when I use snappy-debug [11:14] Bug #1590679: Apps can't own session bus names (unity7 interface)

=== chihchun is now known as chihchun_afk [11:48] hello. Where can I find some examples of "scriplets"? I'm interested in finding out how to use them with go plugin === petevg is now known as petevg_afk [12:02] jdstrand, ping [12:11] PR snapd#2979 closed: tests: add ubuntu-core-16-32 system to the external backend and fix docker test [12:12] guys I see that apt's python3-scipy version is 1.7 but pip3's version is 1.9. Will snaps solve these outdated issues? [12:13] and... how friendly is snappy with other managers? [12:15] snaps embed dependencies, and by default you will embed the latest version. Snaps don't conflict at all with other package managers, because they keep everything separate in /snap. [12:16] since today's udpate to stable core my system gets stuck at "Run configure hook of "core" snap if present" when looking at "snap change 1" [12:19] note that I couldn't do a "snap refresh" since it would get stuck. So I've created another image with latest core inside, and now the "Initialize system state" is stuck === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [13:55] gbisson: hello, thanks for reporting that issue! do you still have access to the system that is stuck? [13:55] gbisson: and you mention a fresh image is also stuck? what system is that? what version/architecture? [14:01] mvo: yes, here is our source code: https://github.com/boundarydevices/ubuntu-core [14:01] mvo: it is based on the roseapple tree but targets our (Boundary Devices) platforms which are i.MX processors based [14:04] gbisson: aha, thank you! I was wondering how to reproduce this myself, but it looks like might be tricky :) [14:04] gbisson: on the fresh system I assume you can not even get to a login/create-user screen ? [14:05] yes I can [14:05] mvo: as said above, I can ssh and look at snap change 1 [14:05] gbisson: aha, great! [14:05] mvo: this is where I've seen it got stuck at step [14:05] gbisson: could you pastebin or mail /var/log/syslog please? [14:05] mvo: sure, give me a minute or two [14:05] gbisson: maybe we can get a clue from that data what is going on [14:06] gbisson: no problem, take your time, I'm here for at least 3 more hours :) [14:06] zyga: hey - I can have a look at that today [14:06] zyga: I'll also have a look at 2624 today [14:13] mvo: here it is: http://pastebin.com/ubNsYu7A [14:15] tyhicks: we are trying to do without #3031 it seems, mvo is working on that [14:18] gbisson: thanks, that is very interessting. it seems like http://paste.ubuntu.com/24182859/ might be crucial, two apparmor denials [14:18] tyhicks: thanks [14:18] gbisson: if you run scmp_sys_resolver 282 - what do you see on this system? [14:18] tyhicks: we're looking at writing snap-update-ns in go to avoid putting more and more complexity in C [14:19] pedronis, tyhicks: #3031 might still be needed, unfortuantely, I was looking into a static linked version of snap-confine but udev is not available as a static lib it seems [14:22] mvo: returns "bind" [14:23] ok, I'll leave 3031 on the list of reviews to do today [14:24] mvo: what can I do to overcome that issue? what I really don't understand is how previous rev could work [14:25] gbisson: thanks first of all for the syscall info [14:26] gbisson: the previous rev was not using the configure hoook in the core snap, that is something new so there is an actual behaviour change here [14:26] gbisson: but I'm confused why its a problem on your platform but not on our platforms :/ it should just work for you too [14:27] mvo: oh ok, thanks that explains the difference indeed [14:27] mvo: could it be that I'm missing a kernel configuration? [14:27] mvo: I'm using our regular Ubuntu defconfig [14:28] gbisson: that should be ok then, also if normal snaps work then things with this new configure hook should also work. its the same class of confinement [14:28] interesting error mvo, gbisson [14:29] is this the configure hook on core? [14:29] mvo: I still have my working image available too if needs to make some comparison [14:29] mvo: it must have network-bind, network plugs [14:29] zyga: yeah, it looks like it [14:29] mvo: otherwise no game (because golang design) [14:29] zyga: yes, the hook on core [14:29] mvo: this is the issue I looked at months ago [14:29] mvo: it's still reported somewhere on snapd [14:29] zyga: core support does not have it [14:29] mvo: golang probes for network support on startup (to see if it has ipv6) [14:30] mvo: there we go, a simple workaround for 2.24 is needed [14:30] zyga: the core snap only has "core-support" as the available plug [14:30] zyga: ok, I can easily add this to the core snap [14:30] I'll try to find the bug report now [14:30] zyga: but *why* is this happening for gbisson and not on our test machines? [14:31] mvo: I agree, I have a RPi3 which I updated and it worked [14:31] mvo: not sure [14:32] mvo: at first I blamed my own snaps (gadget and kernel) but it actually fails before even looking at those [14:32] mvo: which is why I suspect the kernel configuration (or the kernel revision) [14:33] gbisson: this is arm32, right (armhf in ubuntu terms)? [14:33] mvo: RPi3 is based on 4.4 but I'm on 4.1 [14:33] mvo: yes [14:33] gbisson: the kernel version is an interessting data point [14:33] I cannot find it now [14:34] mvo: maybe (long shot) different syscalls on arm [14:34] zyga: was thinking that too [14:34] mvo: like i386/amd64 do totally different stuff for socket related calls [14:34] zyga: its "bind" (seccomp) and "net_admin" (appamror) that is denied [14:34] mvo: we had issues that only showed on one arch and not the other [14:34] right [14:34] why is net_admin needed?!? [14:35] bind is golang for sure [14:35] it really sucks that this magic happens [14:35] maybe net_admin is also bind? [14:35] and we cannot just say "don't" [14:35] mvo: I doubt that [14:35] feels like another golang query on startup [14:36] gbisson: what hardware is this on? [14:36] gbisson: and what kernel? [14:36] gbisson: if you run "snap changes" coud you pastebin that as well please [14:36] zyga: see above, he said this, one sec [14:36] zyga: https://github.com/boundarydevices/ubuntu-core [14:36] aha [14:36] zyga: pretty cool, its a port to Boundary Devices Nitrogen [14:36] (whatever that is :) [14:36] armhf based [14:36] warp speed ahead! [14:36] zyga: and kernel 4.1 [14:37] maybe a kernel bug/config/whatever [14:37] mvo: http://pastebin.com/HSmGYQtF [14:37] not sure [14:37] * zyga -> reboot [14:38] PR snapd#3035 opened: tests: fix interfaces-cups-control for zesty [14:42] gbisson: nice, thank oyu [14:43] gbisson: I think there is at least one bug in our code, it should not hang in there, I assuem you don't have a configure process running in this system anymore (or do you)? the code should have noticed that the child died [14:44] mvo: still there: /bin/sh -e /snap/core/1443/meta/hooks/configure [14:44] gbisson: ohhh [14:44] mvo: can I kill it? [14:44] gbisson: can you strace that? [14:44] sure [14:44] gbisson: please don't kill it :) [14:45] gbisson: you will have to scp strace to the system first most likely [14:45] mvo: strace not found haha [14:45] mvo: oh ok [14:45] mvo: do you have one binary I could use by any chance? (for armhf) [14:47] mvo: I have a weird output: read(3, [14:47] gbisson: lsof -p should tell you what fd this read is (adn you need to copy lsof again) [14:49] mvo: using procfs instead: 3 -> pipe:[12466] [14:52] gbisson: I would like to add the network-bind to the plugs of the core snap to see if that fixes the issue for you. is that something you could do yourself ? by just snap download core, unsquafs, adding the plug and re-squash and ubild an image? if its too dificult I could add it to our edge snap and you would have to build an edge image [14:54] mvo: well yes I'd rather have you do that [14:55] mvo: I've never messed with snap manually before [14:55] gbisson: :) no problem, I'm super happy about a test case for this issue, we had some anecdotal reports but never someone who could reproduce it [14:55] gbisson: let me create that and I will ping me [14:55] ok [15:02] PR snapd#3015 closed: interfaces: alphabetize framebuffer in base decl and add it to all_test.go [15:05] gbisson: I added the plug and triggered a new build, there should be a new core snap in "edge" in ~30min or so, I can ping you once its there. I assume building with a core from edge is no problem? curious to see/hear if the result is different with that :) [15:09] mvo: sure, please ping me when it's ready and then I'll need 5minutes to create and flash a new image [15:09] mvo: thanks! [15:19] gbisson: hey [15:19] gbisson: can you please pastebin /var/lib/snapd/seccomp/profiles/snap.core.hook.configure [15:23] zyga: sure, give me a few minutes to reboot the board [15:23] gbisson: thank you [15:24] gbisson: and can you please do one more thing once the board is up [15:24] though not sure how yet, [15:24] one sec [15:25] zyga: there: http://pastebin.com/PD5hYd7p [15:25] sure, it stays up now [15:26] checking! [15:26] gbisson: tip, pastebin.ubuntu.com == no ads [15:26] with noscript and umatrix also no adds :) [15:26] ads [15:27] zyga: pastebin.ubuntu.com = one more word to type ;) I'll try it next time [15:27] gbisson: ok, you need strace for armhf [15:28] I have strace for armhf [15:28] gbisson: there's a .conf file you can use [15:28] gbisson: ok, run strace -o log /snap/core/current/usr/bin/snapctl [15:28] gbisson: and pastebin that [15:28] zyga: I took strace from our Ubuntu xenial release [15:28] that's good [15:28] gbisson: I use the classic snap (sudo snap install classic; sudo classic) to get apt-get and then install/copy strace to ~ [15:29] but it's the same thing you got [15:29] error: snapctl cannot run without args [15:31] that's fine [15:31] we care about what it does earlier [15:31] (it did some things that it chokes on under confinement)( [15:31] (it did some things that it chokes on under confinement) [15:31] can you pastebin the log now? [15:32] zyga: http://pastebin.ubuntu.com/24183212/ [15:32] bind(4, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 [15:32] so far so good [15:32] ok, one more sec and one more test [15:34] gbisson: can you now run: SNAP_NAME=core /usr/lib/snapd/snap-confine snap.core.hook.configure /snap/core/current/usr/bin/snapctl [15:34] gbisson: this is a smoke test, it should crash [15:35] zyga: should I sudo? doesn't seem to do much [15:36] gbisson: no [15:36] gbisson: no sudo, just as is [15:36] gbisson: what happens when you ran that? [15:37] zyga: nothing [15:37] did it crash? [15:37] anything in journal? [15:37] zyga: it doesn't return so far but no trace whatsoever [15:39] zyga: the journal gives the same SECCOMP denial as before [15:39] zyga: which makes sense I guess [15:39] and its hanging? so the same symtpoms as before [15:39] didrocks: do you know how to add an event to the Ubuntu facebook page? [15:40] mvo: yes, but it's normal I haven't changed the image yet, is the edge core ready yet? [15:40] gbisson: perfect [15:40] gbisson: not quite but close [15:40] gbisson: kill it (remains) [15:40] mvo: one of the thread gets killed [15:41] mvo: and go doesn't recover [15:41] mvo: I have a theory, just making a simple case to try [15:41] zyga: oh, that makes sense [15:43] elopio: I don't, but you should talk to amrisha, she owns the facebook page [15:46] gbisson: ok, ready [15:46] gbisson: a few things you need to do: [15:46] gbisson: go to /var/lib/snapd/ then in {apparmor,seccomp}/profiles/snap.core.hook.configure you need to make two changes: [15:47] gbisson: look at http://pastebin.ubuntu.com/24183261/ [15:47] gbisson: in the seccomp profile you need to add "ptrace" and "process_vm_readv" (on separate lines, without quotes) [15:47] PR snapd#3036 opened: tests: fix classic-ubuntu-core-transition race [15:48] gbisson: in apparmor profile you need to add, before the final closing brace, "/writable/strace ixr," (the trailing comma is relevant) [15:48] gbisson: and then "ptrace," [15:49] gbisson: then copy strace to /writable "sudo cp strace /writable" (wherever you had strace) [15:49] gbisson: and reload apparmor profile with "sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.core.hook.configure" [15:49] gbisson: this should set the stage to the real test: [15:49] SNAP_NAME=core sudo -E /usr/lib/snapd/snap-confine snap.core.hook.configure /writable/strace /snap/core/current/usr/bin/snapctl [15:49] gbisson: this should give us at least partial log of the thing crashing [15:50] mvo: ^^ [15:51] gbisson: gbisson (sorry add -f after strace) [15:51] SNAP_NAME=core sudo -E /usr/lib/snapd/snap-confine snap.core.hook.configure /writable/strace -f /snap/core/current/usr/bin/snapctl [15:51] gbisson: don't redirect this anywhere as it will change the test [15:51] gbisson: once we have some data we can tweak the profile on your disk to pass [15:51] zyga: the new core snap is available [15:51] gbisson: and figure out why this is happening [15:52] gbisson: before you update, please finish this test [15:52] mvo: thanks! [15:53] zyga: http://pastebin.ubuntu.com/24183281/ [15:53] zyga: the first part is the journal [15:53] zyga: below is the command output as-is [15:55] zyga: so once you are ready gbisson can create a new image. or do you have a new theory already (sorry have not read all of the scrollback yet) [16:02] re [16:02] looking at logs [16:03] gbisson: can you append "bind" without quotes to the end of /var/lib/snapd/seccomp/profiles/snap.core.hook.configure [16:03] gbisson: and re-run the test [16:03] gbisson: (we should be ready to try mvo's idea next) [16:05] hmm, curious [16:05] mvo: so ... [16:05] this is different: [16:05] in my run I see:socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = -1 EACCES (Permission denied) [16:05] socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EACCES (Permission denied) [16:05] so nothing happens next (no bind) [16:05] but in gbisson's run I see: [16:05] [pid 1720] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 [16:05] [pid 1720] close(3) = 0 [16:06] so my run doens't reach bind [16:06] it fails on socket [16:06] but there (somehow) socket passes [16:06] no idea why [16:06] gbisson: maybe your kernel doesn't have the full apparmor patchset, are you actively pulling new changes from the apparmor directory in the ubuntu kernel? [16:09] zyga: no, definitely not, it is based on 4.1.15 with no particular apparmor backport [16:09] gbisson: ah [16:09] gbisson: then you should not expect this to work much [16:09] mvo: ^ [16:09] zyga: well, maybe [16:10] gbisson: snapd really requires a particular version of apparmor [16:10] zyga: we have forced-devmode now based on apparmor [16:10] gbisson: sadly the one that is not upstream yet [16:10] zyga: but then, snap-confine is not ready for this yet :/ [16:10] mvo: I'm super curious to see if it gets picked up [16:10] mvo: how can I check if a given system is devmode? [16:10] mvo: IMO we should print a note (each time) "snap list" is used in devmode distro [16:11] zyga: there is a PR for this ;) [16:11] "This system does not offer effective confinement. Running untrusted applications can put your systemd and data at risk" [16:11] mvo: devmode is just too dangerous [16:11] (silent devmode) [16:11] zyga: agreed [16:12] * zyga typed "systemd" instead of system [16:12] eh :) [16:12] zyga: so once gbisson refreshes to the new version syslog should have somthing like "started snapd/2.23 (series 16,devmode)" [16:12] gbisson: so my recommendation, port the apparmor tree and the problem goes away [16:13] zyga: will try that, is the latest linux-stable ok or should another tree be used? [16:14] zyga: well there's no change on apparmor with latest 4.1 stable anyway [16:14] gbisson: I'm curious what will happen if you switch to an image from edge [16:14] PR snapd#3037 opened: interfaces: dbus backend spec [16:15] gbisson: if it is apparmor missing (what zyga suggested) then this version will be a step forward but it will still not fully work, we will need to fix snap-confine for this too which is planned but not quite there yet [16:17] mvo: ok, so I should still try that edge image? [16:17] gbisson: unfortunately no [16:17] gbisson: you need ubuntu-specific patches that are not upstream yet [16:18] gbisson: those can be found on the kernel.ubuntu.com [16:18] zyga: so what you are telling is that no-one can create its own OS image right now [16:18] gbisson: not sure if this is hard to port, apparmor is self-contained but maybe some patches span subsystems [16:18] gbisson: not with confinement on stock kernel [16:18] gbisson: each sponsored kernel from canonical has apparmor ported [16:19] gbisson: and we're merging this upstream but it's a queue [16:19] zyga: and what happens if I change the confinement to devmode? [16:19] gbisson: old stuff gets merged but more bugfixes and features are added [16:19] gbisson: no confinement [16:19] gbisson: it switches off entirely (see mvo's update) [16:20] gbisson: while more fixes and features land upstream it may be 4.13 where our current patches are zero [16:20] gbisson: but I cannot promise that we don't have more after [16:20] gbisson: apparmor is pushed by many things we're doing [16:20] gbisson: and more exposure shows more bugs that we fix (the latest set that landed in 4.11 was mostly just bugfixes) [16:21] zyga: ok but the problem is that my kernel is common across OSes so far (Ubuntu, Debian, Yocto, Buildroot) and don't want to backport things from 4.13 is I risk to break anything [16:23] gbisson: you don't need to backport from 4.13 [16:23] gbisson: but you need to backport security fixes from ubuntu's apparmor tree to get effective confinement [16:24] gbisson: earlier we had a few kernels published where this was done (for common kernel versions) [16:24] gbisson: but I don't know if those are supported and maintained [16:24] zyga: can you point me to the specific tree? [16:24] gbisson: which version are you on now? [16:24] zyga: 4.1 [16:24] thanks [16:25] https://github.com/snapcore/sample-kernels/branches [16:25] gbisson: I can get you in touch with someone commercial at Canonical if you'd like to get backported security patches for 4.1 [16:26] gbisson: but looking at those they feel unmaintained (more like a one off that was done earlier) [16:27] gbisson: you can also review http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/ for UBUNTU SAUCE matching apparmor [16:27] all such patches are really desired [16:27] gbisson: e.g. http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?qt=grep&q=apparmor [16:30]