[01:39] <mup> PR snapcraft#1186 closed: demos: add ROS content sharing demo <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1186>
[01:51] <olympionex> 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] <olympionex> hmm, looks like its using requests.get with allow_redirects=True
[01:54] <sergiusens> olympionex: seems like a credentials thing, can the file be downloaded anonymously?
[01:54] <sergiusens> can you wget the file?
[01:54] <olympionex> yeah
[01:54] <sergiusens> from the link that is
[01:58] <olympionex> copied and pasted the url from the yaml just to make sure
[01:58] <olympionex> and it works fine with wget
[01:58] <olympionex> but the pull phase of snapcraft is only getting some html
[01:59] <olympionex> its a link share on dropbox which means anyone with the link should be able to download it, so no required login
[02:08] <olympionex> sergiusens: here is a demo pastebin
[02:08] <olympionex> http://pastebin.com/jdZuNVD4
[02:15] <mup> PR snapcraft#1194 opened: tests: remove repo.Ubuntu patch for plugins <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1194>
[02:47] <olympionex> 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] <olympionex> changing the links to dl=1 caused snapcraft to work fine
[03:07] <sergiusens> great
[03:07] <sergiusens> oh dear, it is already Wednesday here
[03:57] <mup> PR snapcraft#1191 closed: tests: run the CLA check in a docker container <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1191>
[04:00] <mup> PR snapcraft#1194 closed: tests: remove repo.Ubuntu patch for plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1194>
[08:34] <shuduo> 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] <zyga> shuduo: hi
[08:40] <shuduo> zyga: hi
[08:40] <zyga> 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] <zyga> shuduo: the COPR build is disabled now
[08:41] <zyga> 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] <zyga> shuduo: I may re-start the COPR package with vendorized deps as that would help to unblock people
[08:41] <zyga> shuduo: but I really need help with extra maintenance work as my main duties are as upstream developer
[08:41] <shuduo> zyga: interesting I just tried 24 today and see snap works good.
[08:42] <zyga> shuduo: it must be an older build
[08:42] <zyga> shuduo: we are at snapd 2.23.1 now (2.24 will release today)
[08:43] <zyga> 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] <zyga> *now
[08:43] <shuduo> zyga: it's 2.22.1 on fedora 24.
[08:47] <zyga> hmmmm?
[08:47] <zyga> that's super odd :)
[08:47] <zyga> shuduo: where did you get your package again?
[08:47] <zyga> shuduo: did you build it yourself?
[08:47] <zyga> the CORP repo is unused for months
[08:48] <shuduo> 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] <zyga> shuduo: I try to document the current status on the snapd wiki here ...
[08:49] <shuduo> zyga: i just follow the instructions of snapcraft.io
[08:49] <zyga> https://github.com/snapcore/snapd/wiki/Distributions
[08:49]  * zyga goes to add opensuse to supported list there
[08:50] <zyga> (opensuse is supported since last week-ish)
[08:50] <shuduo> then i find it from https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
[08:50] <zyga> shuduo: but that is snapd 2.14
[08:50] <zyga> anyway
[08:51] <zyga> I need to spend some time on Fedora support
[08:51] <zyga> ideally after the 2.24 release tonight
[08:51] <zyga> I could re-enable COPR easily with the vendorized deps
[08:51] <zyga> (so same bits you get on ubuntu)
[08:51] <zyga> and I could work towards packaging missing stuff
[08:51] <zyga> shuduo: stick around; I can do this on Friday
[08:51] <shuduo> zyga: i have customer ask if snap acn run with centos
[08:52] <zyga> shuduo: do you need fedora or centos?
[08:52] <zyga> shuduo: it can, though package is still far away
[08:52] <zyga> https://new.zygoon.pl/post/case-study-snapd-on-centos/
[08:52] <shuduo> zyga: i believe commercial customer need centos
[08:52] <zyga> but you can build it from source to see
[08:52] <zyga> shuduo: if you want to help on that I'll gladly welcome you on board :)
[08:52] <zyga> shuduo: centos package could be built from COPR
[08:52] <shuduo> zyga: great. i will try it.
[08:53] <zyga> shuduo: with all vendorized bits it should not be hard (famous last words ;-)
[08:53] <zyga> shuduo: but the issue is strictly on packaging, the code works fine
[08:54] <shuduo> zyga: i would like to study how to do that first. :)
[08:54] <zyga> shuduo: look at the blog post and stick around, I'm sure you can help
[08:57] <shuduo> zyga: btw, seems debian is broken. https://bugs.launchpad.net/snapd/+bug/1672984.
[08:57] <mup> Bug #1672984: can't install hello-world snap on debian <snapd:New> <https://launchpad.net/bugs/1672984>
[09:00] <shuduo> zyga: yes, dnf info snapd show it's 2.14. sorry my wrong msg.
[09:46] <zyga> shuduo: that's ok then, no mystery :)
[10:02] <zyga> tyhicks: hey, could you do a review for us today?
[10:16] <gbisson> 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] <gbisson> has anyone seen this? It seems that my interface is busy at the time of the request
[10:26] <mup> PR snapd#3032 opened: cmd: rename all unit tests to $command/unit-test <Created by zyga> <https://github.com/snapcore/snapd/pull/3032>
[10:26] <mup> PR snapd#3033 opened: cmd/libsnap: make mountinfo structures public <Created by zyga> <https://github.com/snapcore/snapd/pull/3033>
[10:34] <zyga> gbisson: looks like kernel/driver issue
[10:39] <gbisson> zyga: well the driver is working fine though, and the connection is working just fine after that message
[10:40] <gbisson> 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] <zyga> gbisson: "fine" may not be "correct" though, I'm not a kernel expert
[10:41] <zyga> tyhicks: specifically this PR: https://github.com/snapcore/snapd/pull/3031
[10:41] <mup> PR snapd#3031: cmd/snap-confine-suid-trampoline: add new helper <Created by zyga> <https://github.com/snapcore/snapd/pull/3031>
[10:42] <gbisson> 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] <mup> PR snapd#3034 opened: interfaces: log if the system goes into ForceDevMode <Created by mvo5> <https://github.com/snapcore/snapd/pull/3034>
[11:14] <liuxg> 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] <mup> Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1590679>
[11:48] <jacekn> hello. Where can I find some examples of "scriplets"? I'm interested in finding out how to use them with go plugin
[12:02] <liuxg> jdstrand, ping
[12:11] <mup> PR snapd#2979 closed: tests: add ubuntu-core-16-32 system to the external backend and fix docker test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2979>
[12:12] <brunch875> 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] <brunch875> and... how friendly is snappy with other managers?
[12:15] <stub> 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] <gbisson> 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] <gbisson> 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
[13:55] <mvo> gbisson: hello, thanks for reporting that issue! do you still have access to the system that is stuck?
[13:55] <mvo> gbisson: and you mention a fresh image is also stuck? what system is that? what version/architecture?
[14:01] <gbisson> mvo: yes, here is our source code: https://github.com/boundarydevices/ubuntu-core
[14:01] <gbisson> mvo: it is based on the roseapple tree but targets our (Boundary Devices) platforms which are i.MX processors based
[14:04] <mvo> gbisson: aha, thank you! I was wondering how to reproduce this myself, but it looks like might be tricky :)
[14:04] <mvo> gbisson: on the fresh system I assume you can not even get to a login/create-user screen ?
[14:05] <gbisson> yes I can
[14:05] <gbisson> mvo: as said above, I can ssh and look at snap change 1
[14:05] <mvo> gbisson: aha, great!
[14:05] <gbisson> mvo: this is where I've seen it got stuck at step
[14:05] <mvo> gbisson: could you pastebin or mail /var/log/syslog  please?
[14:05] <gbisson> mvo: sure, give me a minute or two
[14:05] <mvo> gbisson: maybe we can get a clue from that data what is going on
[14:06] <mvo> gbisson: no problem, take your time, I'm here for at least 3 more hours :)
[14:06] <tyhicks> zyga: hey - I can have a look at that today
[14:06] <tyhicks> zyga: I'll also have a look at 2624 today
[14:13] <gbisson> mvo: here it is: http://pastebin.com/ubNsYu7A
[14:15] <pedronis> tyhicks: we are trying to do without #3031 it seems, mvo is working on that
[14:18] <mvo> gbisson: thanks, that is very interessting. it seems like http://paste.ubuntu.com/24182859/ might be crucial, two apparmor denials
[14:18] <zyga> tyhicks: thanks
[14:18] <mvo> gbisson: if you run scmp_sys_resolver 282 - what do you see on this system?
[14:18] <zyga> tyhicks: we're looking at writing snap-update-ns in go to avoid putting more and more complexity in C
[14:19] <mvo> 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] <gbisson> mvo: returns "bind"
[14:23] <tyhicks> ok, I'll leave 3031 on the list of reviews to do today
[14:24] <gbisson> mvo: what can I do to overcome that issue? what I really don't understand is how previous rev could work
[14:25] <mvo> gbisson: thanks first of all for the syscall info
[14:26] <mvo> 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] <mvo> 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] <gbisson> mvo: oh ok, thanks that explains the difference indeed
[14:27] <gbisson> mvo: could it be that I'm missing a kernel configuration?
[14:27] <gbisson> mvo: I'm using our regular Ubuntu defconfig
[14:28] <mvo> 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] <zyga> interesting error mvo, gbisson
[14:29] <zyga> is this the configure hook on core?
[14:29] <gbisson> mvo: I still have my working image available too if needs to make some comparison
[14:29] <zyga> mvo: it must have network-bind, network plugs
[14:29] <mvo> zyga: yeah, it looks like it
[14:29] <zyga> mvo: otherwise no game (because golang design)
[14:29] <gbisson> zyga: yes, the hook on core
[14:29] <zyga> mvo: this is the issue I looked at months ago
[14:29] <zyga> mvo: it's still reported somewhere on snapd
[14:29] <mvo> zyga: core support does not have it
[14:29] <zyga> mvo: golang probes for network support on startup (to see if it has ipv6)
[14:30] <zyga> mvo: there we go, a simple workaround for 2.24 is needed
[14:30] <mvo> zyga: the core snap only has "core-support" as the available plug
[14:30] <mvo> zyga: ok, I can easily add this to the core snap
[14:30] <zyga> I'll try to find the bug report now
[14:30] <mvo> zyga: but *why* is this happening for gbisson and not on our test machines?
[14:31] <gbisson> mvo: I agree, I have a RPi3 which I updated and it worked
[14:31] <zyga> mvo: not sure
[14:32] <gbisson> mvo: at first I blamed my own snaps (gadget and kernel) but it actually fails before even looking at those
[14:32] <gbisson> mvo: which is why I suspect the kernel configuration (or the kernel revision)
[14:33] <mvo> gbisson: this is arm32, right (armhf in ubuntu terms)?
[14:33] <gbisson> mvo: RPi3 is based on 4.4 but I'm on 4.1
[14:33] <gbisson> mvo: yes
[14:33] <mvo> gbisson: the kernel version is an interessting data point
[14:33] <zyga> I cannot find it now
[14:34] <zyga> mvo: maybe (long shot) different syscalls on arm
[14:34] <mvo> zyga: was thinking that too
[14:34] <zyga> mvo: like i386/amd64 do totally different stuff for socket related calls
[14:34] <mvo> zyga: its "bind" (seccomp) and "net_admin" (appamror) that is denied
[14:34] <zyga> mvo: we had issues that only showed on one arch and not the other
[14:34] <zyga> right
[14:34] <zyga> why is net_admin needed?!?
[14:35] <zyga> bind is golang for sure
[14:35] <zyga> it really sucks that this magic happens
[14:35] <mvo> maybe net_admin is also bind?
[14:35] <zyga> and we cannot just say "don't"
[14:35] <zyga> mvo: I doubt that
[14:35] <zyga> feels like another golang query on startup
[14:36] <zyga> gbisson: what hardware is this on?
[14:36] <zyga> gbisson: and what kernel?
[14:36] <mvo> gbisson: if you run "snap changes" coud you pastebin that as well please
[14:36] <mvo> zyga: see above, he said this, one sec
[14:36] <mvo> zyga: https://github.com/boundarydevices/ubuntu-core
[14:36] <zyga> aha
[14:36] <mvo> zyga: pretty cool, its a port to  Boundary Devices Nitrogen
[14:36] <mvo> (whatever that is :)
[14:36] <mvo> armhf based
[14:36] <zyga> warp speed ahead!
[14:36] <mvo> zyga: and kernel 4.1
[14:37] <zyga> maybe a kernel bug/config/whatever
[14:37] <gbisson> mvo: http://pastebin.com/HSmGYQtF
[14:37] <zyga> not sure
[14:37]  * zyga -> reboot
[14:38] <mup> PR snapd#3035 opened: tests: fix interfaces-cups-control for zesty <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3035>
[14:42] <mvo> gbisson: nice, thank oyu
[14:43] <mvo> 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] <gbisson> mvo: still there: /bin/sh -e /snap/core/1443/meta/hooks/configure
[14:44] <mvo> gbisson: ohhh
[14:44] <gbisson> mvo: can I kill it?
[14:44] <mvo> gbisson: can you strace that?
[14:44] <gbisson> sure
[14:44] <mvo> gbisson: please don't kill it :)
[14:45] <mvo> gbisson: you will have to scp strace to the system first most likely
[14:45] <gbisson> mvo: strace not found haha
[14:45] <gbisson> mvo: oh ok
[14:45] <gbisson> mvo: do you have one binary I could use by any chance? (for armhf)
[14:47] <gbisson> mvo: I have a weird output: read(3,
[14:47] <mvo> gbisson: lsof -p should tell you what fd this read is (adn you need to copy lsof again)
[14:49] <gbisson> mvo: using procfs instead: 3 -> pipe:[12466]
[14:52] <mvo> 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] <gbisson> mvo: well yes I'd rather have you do that
[14:55] <gbisson> mvo: I've never messed with snap manually before
[14:55] <mvo> 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] <mvo> gbisson: let me create that and I will ping me
[14:55] <gbisson> ok
[15:02] <mup> PR snapd#3015 closed: interfaces: alphabetize framebuffer in base decl and add it to all_test.go <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3015>
[15:05] <mvo> 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] <gbisson> mvo: sure, please ping me when it's ready and then I'll need 5minutes to create and flash a new image
[15:09] <gbisson> mvo: thanks!
[15:19] <zyga> gbisson: hey
[15:19] <zyga> gbisson: can you please pastebin /var/lib/snapd/seccomp/profiles/snap.core.hook.configure
[15:23] <gbisson> zyga: sure, give me a few minutes to reboot the board
[15:23] <zyga> gbisson: thank you
[15:24] <zyga> gbisson: and can you please do one more thing once the board is up
[15:24] <zyga> though not sure how yet,
[15:24] <zyga> one sec
[15:25] <gbisson> zyga: there: http://pastebin.com/PD5hYd7p
[15:25] <gbisson> sure, it stays up now
[15:26] <zyga> checking!
[15:26] <zyga> gbisson: tip, pastebin.ubuntu.com == no ads
[15:26] <mvo> with noscript and umatrix also no adds :)
[15:26] <mvo> ads
[15:27] <gbisson> zyga: pastebin.ubuntu.com = one more word to type ;) I'll try it next time
[15:27] <zyga> gbisson: ok, you need strace for armhf
[15:28] <gbisson> I have strace for armhf
[15:28] <zyga> gbisson: there's a .conf file you can use
[15:28] <zyga> gbisson: ok, run strace -o log /snap/core/current/usr/bin/snapctl
[15:28] <zyga> gbisson: and pastebin that
[15:28] <gbisson> zyga: I took strace from our Ubuntu xenial release
[15:28] <zyga> that's good
[15:28] <zyga> gbisson: I use the classic snap (sudo snap install classic; sudo classic) to get apt-get and then install/copy strace to ~
[15:29] <zyga> but it's the same thing you got
[15:29] <gbisson> error: snapctl cannot run without args
[15:31] <zyga> that's fine
[15:31] <zyga> we care about what it does earlier
[15:31] <zyga> (it did some things that it chokes on under confinement)(
[15:31] <zyga> (it did some things that it chokes on under confinement)
[15:31] <zyga> can you pastebin the log now?
[15:32] <gbisson> zyga: http://pastebin.ubuntu.com/24183212/
[15:32] <zyga> 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] <zyga> so far so good
[15:32] <zyga> ok, one more sec and one more test
[15:34] <zyga> 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] <zyga> gbisson: this is a smoke test, it should crash
[15:35] <gbisson> zyga: should I sudo? doesn't seem to do much
[15:36] <zyga> gbisson: no
[15:36] <zyga> gbisson: no sudo, just as is
[15:36] <zyga> gbisson: what happens when you ran that?
[15:37] <gbisson> zyga: nothing
[15:37] <zyga> did it crash?
[15:37] <zyga> anything in journal?
[15:37] <gbisson> zyga: it doesn't return so far but no trace whatsoever
[15:39] <gbisson> zyga: the journal gives the same SECCOMP denial as before
[15:39] <gbisson> zyga: which makes sense I guess
[15:39] <mvo> and its hanging? so the same symtpoms as before
[15:39] <elopio> didrocks: do you know how to add an event to the Ubuntu facebook page?
[15:40] <gbisson> mvo: yes, but it's normal I haven't changed the image yet, is the edge core ready yet?
[15:40] <zyga> gbisson: perfect
[15:40] <mvo> gbisson: not quite but close
[15:40] <zyga> gbisson: kill it (remains)
[15:40] <zyga> mvo: one of the thread gets killed
[15:41] <zyga> mvo: and go doesn't recover
[15:41] <zyga> mvo: I have a theory, just making a simple case to try
[15:41] <mvo> zyga: oh, that makes sense
[15:43] <didrocks> elopio: I don't, but you should talk to amrisha, she owns the facebook page
[15:46] <zyga> gbisson: ok, ready
[15:46] <zyga> gbisson: a few things you need to do:
[15:46] <zyga> gbisson: go to /var/lib/snapd/ then in {apparmor,seccomp}/profiles/snap.core.hook.configure you need to make two changes:
[15:47] <zyga> gbisson: look at http://pastebin.ubuntu.com/24183261/
[15:47] <zyga> gbisson: in the seccomp profile you need to add "ptrace" and "process_vm_readv" (on separate lines, without quotes)
[15:47] <mup> PR snapd#3036 opened: tests: fix classic-ubuntu-core-transition race <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3036>
[15:48] <zyga> gbisson: in apparmor profile you need to add, before the final closing brace, "/writable/strace ixr," (the trailing comma is relevant)
[15:48] <zyga> gbisson: and then "ptrace,"
[15:49] <zyga> gbisson: then copy strace to /writable "sudo cp strace /writable" (wherever you had strace)
[15:49] <zyga> gbisson: and reload apparmor profile with "sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.core.hook.configure"
[15:49] <zyga> gbisson: this should set the stage to the real test:
[15:49] <zyga> SNAP_NAME=core sudo -E /usr/lib/snapd/snap-confine snap.core.hook.configure /writable/strace /snap/core/current/usr/bin/snapctl
[15:49] <zyga> gbisson: this should give us at least partial log of the thing crashing
[15:50] <zyga> mvo: ^^
[15:51] <zyga> gbisson: gbisson (sorry add -f after strace)
[15:51] <zyga> 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] <zyga> gbisson: don't redirect this anywhere as it will change the test
[15:51] <zyga> gbisson: once we have some data we can tweak the profile on your disk to pass
[15:51] <mvo> zyga: the new core snap is available
[15:51] <zyga> gbisson: and figure out why this is happening
[15:52] <zyga> gbisson: before you update, please finish this test
[15:52] <zyga> mvo: thanks!
[15:53] <gbisson> zyga: http://pastebin.ubuntu.com/24183281/
[15:53] <gbisson> zyga: the first part is the journal
[15:53] <gbisson> zyga: below is the command output as-is
[15:55] <mvo> 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] <zyga> re
[16:02] <zyga> looking at logs
[16:03] <zyga> gbisson: can you append "bind" without quotes to the end of /var/lib/snapd/seccomp/profiles/snap.core.hook.configure
[16:03] <zyga> gbisson: and re-run the test
[16:03] <zyga> gbisson: (we should be ready to try mvo's idea next)
[16:05] <zyga> hmm, curious
[16:05] <zyga> mvo: so ...
[16:05] <zyga> this is different:
[16:05] <zyga> in my run I see:socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = -1 EACCES (Permission denied)
[16:05] <zyga> socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EACCES (Permission denied)
[16:05] <zyga> so nothing happens next (no bind)
[16:05] <zyga> but in gbisson's run I see:
[16:05] <zyga> [pid  1720] socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[16:05] <zyga> [pid  1720] close(3)                    = 0
[16:06] <zyga> so my run doens't reach bind
[16:06] <zyga> it fails on socket
[16:06] <zyga> but there (somehow) socket passes
[16:06] <zyga> no idea why
[16:06] <zyga> 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] <gbisson> zyga: no, definitely not, it is based on 4.1.15 with no particular apparmor backport
[16:09] <zyga> gbisson: ah
[16:09] <zyga> gbisson: then you should not expect this to work much
[16:09] <zyga> mvo: ^
[16:09] <mvo> zyga: well, maybe
[16:10] <zyga> gbisson: snapd really requires a particular version of apparmor
[16:10] <mvo> zyga: we have forced-devmode now based on apparmor
[16:10] <zyga> gbisson: sadly the one that is not upstream yet
[16:10] <mvo> zyga: but then, snap-confine is not ready for this yet :/
[16:10] <zyga> mvo: I'm super curious to see if it gets picked up
[16:10] <zyga> mvo: how can I check if a given system is devmode?
[16:10] <zyga> mvo: IMO we should print a note (each time) "snap list" is used in devmode distro
[16:11] <mvo> zyga: there is a PR for this ;)
[16:11] <zyga> "This system does not offer effective confinement. Running untrusted applications can put your systemd and data at risk"
[16:11] <zyga> mvo: devmode is just too dangerous
[16:11] <zyga> (silent devmode)
[16:11] <mvo> zyga: agreed
[16:12]  * zyga typed "systemd" instead of system
[16:12] <zyga> eh :)
[16:12] <mvo> zyga: so once gbisson refreshes to the new version syslog should have somthing like "started snapd/2.23 (series 16,devmode)"
[16:12] <zyga> gbisson: so my recommendation, port the apparmor tree and the problem goes away
[16:13] <gbisson> zyga: will try that, is the latest linux-stable ok or should another tree be used?
[16:14] <gbisson> zyga: well there's no change on apparmor with latest 4.1 stable anyway
[16:14] <mvo> gbisson: I'm curious what will happen if you switch to an image from edge
[16:14] <mup> PR snapd#3037 opened: interfaces: dbus backend spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/3037>
[16:15] <mvo> 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] <gbisson> mvo: ok, so I should still try that edge image?
[16:17] <zyga> gbisson: unfortunately no
[16:17] <zyga> gbisson: you need ubuntu-specific patches that are not upstream yet
[16:18] <zyga> gbisson: those can be found on the kernel.ubuntu.com
[16:18] <gbisson> zyga: so what you are telling is that no-one can create its own OS image right now
[16:18] <zyga> gbisson: not sure if this is hard to port, apparmor is self-contained but maybe some patches span subsystems
[16:18] <zyga> gbisson: not with confinement on stock kernel
[16:18] <zyga> gbisson: each sponsored kernel from canonical has apparmor ported
[16:19] <zyga> gbisson: and we're merging this upstream but it's a queue
[16:19] <gbisson> zyga: and what happens if I change the confinement to devmode?
[16:19] <zyga> gbisson: old stuff gets merged but more bugfixes and features are added
[16:19] <zyga> gbisson: no confinement
[16:19] <zyga> gbisson: it switches off entirely (see mvo's update)
[16:20] <zyga> gbisson: while more fixes and features land upstream it may be 4.13 where our current patches are zero
[16:20] <zyga> gbisson: but I cannot promise that we don't have more after
[16:20] <zyga> gbisson: apparmor is pushed by many things we're doing
[16:20] <zyga> gbisson: and more exposure shows more bugs that we fix (the latest set that landed in 4.11 was mostly just bugfixes)
[16:21] <gbisson> 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] <zyga> gbisson: you don't need to backport from 4.13
[16:23] <zyga> gbisson: but you need to backport security fixes from ubuntu's apparmor tree to get effective confinement
[16:24] <zyga> gbisson: earlier we had a few kernels published where this was done (for common kernel versions)
[16:24] <zyga> gbisson: but I don't know if those are supported and maintained
[16:24] <gbisson> zyga: can you point me to the specific tree?
[16:24] <zyga> gbisson: which version are you on now?
[16:24] <gbisson> zyga: 4.1
[16:24] <zyga> thanks
[16:25] <zyga> https://github.com/snapcore/sample-kernels/branches
[16:25] <zyga> 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] <zyga> gbisson: but looking at those they feel unmaintained (more like a one off that was done earlier)
[16:27] <zyga> gbisson: you can also review http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/ for UBUNTU SAUCE matching apparmor
[16:27] <zyga> all such patches are really desired
[16:27] <zyga> gbisson: e.g. http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/log/?qt=grep&q=apparmor
[16:30] <mvo> gbisson: I will be off for some minutes, if you have a chance to boot a fresh edge core based image, I'm keen to see the results :)
[16:30] <mvo> gbisson: i.e. I will read backlog
[16:30] <zyga> gbisson: I'm off to, kids home, need to attend stuff
[16:30] <gbisson> zyga: thanks for your help! I'll look at the apparmor patches
[16:33] <gbisson> mvo: but will I need the apparmor patches anyway?
[16:33] <mup> PR snapcraft#1195 opened: [experimental] run unit tests in osx <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1195>
[16:33] <gbisson> mvo: cause if I do I'm not sure I want to spend much time on this
[16:39] <zyga> gbisson: (quick look) it depends on what you are after
[16:39] <zyga> gbisson: if you are are after a quick demo you don't need much
[16:39] <zyga> gbisson: if you want a real product that is supported you need to patch security issues
[16:40] <zyga> gbisson: there's nothing in between
[16:41] <gbisson> zyga: we usually give OS images freely available for all our platforms on our website (https://boundarydevices.com/wiki/operating-systems/) so our customers can pick the one they want
[16:42] <gbisson> zyga: but here the problem is that if I give an image where if the customer does a "snap refresh" it breaks I'm not sure I want them to experience that
[16:43] <zyga> gbisson: that is a bug and that will get fixed (in current master you will be in devmode and won't use apparmor)
[16:43] <zyga> gbisson: seccomp probably won't be used either
[16:43] <zyga> gbisson: but this will not be the best way to experience snapd as it will be insecure
[16:44] <zyga> gbisson: so my only point was that to really say you support snaps you should support security features of your kernel
[16:44] <gbisson> zyga: I'm fine if I can be in devmode for this "demo" image, all I want is customers being able to snap install etc..
[16:46] <gbisson> mvo: I get an error when logging in:  error: while creating user: cannot communicate with server: Post
[16:46] <gbisson> http://localhost/v2/create-user: EOF
[16:51] <elopio> thanks didrocks
[17:05] <mup> PR snapd#3024 closed: interfaces: use apparmor spec in the apparmor backend <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3024>
[17:46] <mup> PR snapd#3036 closed: tests: fix classic-ubuntu-core-transition race <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3036>
[18:07] <mvo> gbisson: uh, so the edge image is clearly worse :/
[18:15] <mup> PR snapd#3034 closed: interfaces: log if the system goes into ForceDevMode <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3034>
[18:24] <mup> PR snapd#3023 closed: cmd: validate SNAP_NAME <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3023>
[18:30] <mup> PR snapd#3038 opened: misc: revert "Log if the system goes into ForceDevMode" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3038>
[18:45] <gbisson> mvo: I'm curious where is the RPi3 kernel tree for the image you provide?
[19:00] <mup> PR snapcraft#1175 closed: demo files for snaping the bitcoin-qt client <Created by torusJKL> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1175>
[19:08] <zyga> tyhicks: hey
[19:08] <zyga> tyhicks: did you have a chance to review 2624?
[19:11] <tyhicks> zyga: yeah - I'm testing the apparmor rule
[19:11] <zyga> thanks
[19:12] <zyga> tyhicks: release night so if you want to block it please hurry up ;-)
[19:12] <tyhicks> ah, didn't realize
[19:13] <tyhicks> zyga: do I need to review 3031 immediately, too?
[19:13] <zyga> tyhicks: I think we rejected that already because udev cannot be linked statically so we cannot use it
[19:14] <zyga> tyhicks: please review 2624 first if you cna
[19:14] <zyga> can*
[19:27] <tyhicks> zyga: done
[19:29] <tyhicks> zyga: I don't guess I'll review 3031 unless I hear that it is still needed
[20:35] <mup> PR snapd#3028 closed: interfaces: seccomp tests cleanup <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3028>
[20:44] <mup> PR snapd#3038 closed: misc: revert "Log if the system goes into ForceDevMode" <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3038>
[20:46] <mup> PR snapd#3035 closed: tests: fix interfaces-cups-control for zesty <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3035>
[21:45] <zyga> tyhicks: thank you!
[21:45] <zyga> tyhicks: I made the profile tighter as suggested; both rules
[21:45] <zyga> tyhicks: with two +1's I'll merge it once it shows up all green
[21:46]  * zyga waves goodbye
[21:46] <zyga> see you tomorrow
[21:49] <tyhicks> zyga: np - have a good one
[23:01] <liuxg> jdstrand, ping
[23:16] <torusJKL> I have created a snap of a QT program.
[23:16] <torusJKL> When I run it using the desktop link the GUI looks really bad.
[23:16] <torusJKL> If I run it directly from /snap/myApp/current/bin/ then it looks nice and integrated into my system.
[23:17] <torusJKL> What am I missing here?
[23:18] <torusJKL> Here is my snapcraft.yaml file: https://github.com/torusJKL/snapcraft-projects/blob/master/bitcoin-qt/snapcraft.yaml
[23:55] <torusJKL> It looks to me like the following: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357
[23:56] <torusJKL> I'm using the part desktop-qt5 but how do I add the gtk3 dependencies (e.g. "canberra-gtk-module")?