| 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:39 |
|---|---|---|
| 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:51 |
| 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:54 |
| 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:58 |
| olympionex | its a link share on dropbox which means anyone with the link should be able to download it, so no required login | 01:59 |
| olympionex | sergiusens: here is a demo pastebin | 02:08 |
| olympionex | http://pastebin.com/jdZuNVD4 | 02:08 |
| mup | PR snapcraft#1194 opened: tests: remove repo.Ubuntu patch for plugins <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1194> | 02:15 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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 | 02:47 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | great | 03:07 |
| sergiusens | oh dear, it is already Wednesday here | 03:07 |
| === chihchun is now known as chihchun_afk | ||
| 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> | 03:57 |
| 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> | 04:00 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| 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:34 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:47 |
| 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:48 |
| 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:49 | |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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> | 08:57 |
| shuduo | zyga: yes, dnf info snapd show it's 2.14. sorry my wrong msg. | 09:00 |
| === davmor2_ is now known as davmor2 | ||
| zyga | shuduo: that's ok then, no mystery :) | 09:46 |
| zyga | tyhicks: hey, could you do a review for us today? | 10:02 |
| 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:16 |
| gbisson | has anyone seen this? It seems that my interface is busy at the time of the request | 10:17 |
| 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:26 |
| zyga | gbisson: looks like kernel/driver issue | 10:34 |
| gbisson | zyga: well the driver is working fine though, and the connection is working just fine after that message | 10:39 |
| 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:40 |
| 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:41 |
| 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 | 10:42 |
| mup | PR snapd#3034 opened: interfaces: log if the system goes into ForceDevMode <Created by mvo5> <https://github.com/snapcore/snapd/pull/3034> | 11:08 |
| 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:14 |
| === chihchun is now known as chihchun_afk | ||
| jacekn | hello. Where can I find some examples of "scriplets"? I'm interested in finding out how to use them with go plugin | 11:48 |
| === petevg is now known as petevg_afk | ||
| liuxg | jdstrand, ping | 12:02 |
| 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:11 |
| 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:12 |
| brunch875 | and... how friendly is snappy with other managers? | 12:13 |
| 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:15 |
| 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:16 |
| 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 | 12:19 |
| === 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 | ||
| 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? | 13:55 |
| 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:01 |
| 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:04 |
| 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:05 |
| 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:06 |
| gbisson | mvo: here it is: http://pastebin.com/ubNsYu7A | 14:13 |
| pedronis | tyhicks: we are trying to do without #3031 it seems, mvo is working on that | 14:15 |
| 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:18 |
| 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:19 |
| gbisson | mvo: returns "bind" | 14:22 |
| tyhicks | ok, I'll leave 3031 on the list of reviews to do today | 14:23 |
| gbisson | mvo: what can I do to overcome that issue? what I really don't understand is how previous rev could work | 14:24 |
| mvo | gbisson: thanks first of all for the syscall info | 14:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| gbisson | mvo: I agree, I have a RPi3 which I updated and it worked | 14:31 |
| zyga | mvo: not sure | 14:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 | |
| mup | PR snapd#3035 opened: tests: fix interfaces-cups-control for zesty <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3035> | 14:38 |
| mvo | gbisson: nice, thank oyu | 14:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:47 |
| gbisson | mvo: using procfs instead: 3 -> pipe:[12466] | 14:49 |
| 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:52 |
| gbisson | mvo: well yes I'd rather have you do that | 14:54 |
| 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 | 14:55 |
| 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:02 |
| 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:05 |
| 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:09 |
| zyga | gbisson: hey | 15:19 |
| zyga | gbisson: can you please pastebin /var/lib/snapd/seccomp/profiles/snap.core.hook.configure | 15:19 |
| gbisson | zyga: sure, give me a few minutes to reboot the board | 15:23 |
| zyga | gbisson: thank you | 15:23 |
| 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:24 |
| gbisson | zyga: there: http://pastebin.com/PD5hYd7p | 15:25 |
| gbisson | sure, it stays up now | 15:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| zyga | but it's the same thing you got | 15:29 |
| gbisson | error: snapctl cannot run without args | 15:29 |
| 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:31 |
| 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:32 |
| 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:34 |
| gbisson | zyga: should I sudo? doesn't seem to do much | 15:35 |
| zyga | gbisson: no | 15:36 |
| zyga | gbisson: no sudo, just as is | 15:36 |
| zyga | gbisson: what happens when you ran that? | 15:36 |
| 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:37 |
| 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:39 |
| 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:40 |
| 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:41 |
| didrocks | elopio: I don't, but you should talk to amrisha, she owns the facebook page | 15:43 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| zyga | mvo: ^^ | 15:50 |
| 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:51 |
| zyga | gbisson: before you update, please finish this test | 15:52 |
| zyga | mvo: thanks! | 15:52 |
| 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:53 |
| 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) | 15:55 |
| zyga | re | 16:02 |
| zyga | looking at logs | 16:02 |
| 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:03 |
| 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:05 |
| 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:06 |
| 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:09 |
| 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:10 |
| 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:11 |
| * 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:12 |
| gbisson | zyga: will try that, is the latest linux-stable ok or should another tree be used? | 16:13 |
| 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| zyga | gbisson: but looking at those they feel unmaintained (more like a one off that was done earlier) | 16:26 |
| 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:27 |
| 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:30 |
| 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:33 |
| 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:39 |
| zyga | gbisson: there's nothing in between | 16:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| elopio | thanks didrocks | 16:51 |
| 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:05 |
| 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> | 17:46 |
| mvo | gbisson: uh, so the edge image is clearly worse :/ | 18:07 |
| 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:15 |
| mup | PR snapd#3023 closed: cmd: validate SNAP_NAME <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3023> | 18:24 |
| 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:30 |
| gbisson | mvo: I'm curious where is the RPi3 kernel tree for the image you provide? | 18:45 |
| 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:00 |
| zyga | tyhicks: hey | 19:08 |
| zyga | tyhicks: did you have a chance to review 2624? | 19:08 |
| tyhicks | zyga: yeah - I'm testing the apparmor rule | 19:11 |
| zyga | thanks | 19:11 |
| zyga | tyhicks: release night so if you want to block it please hurry up ;-) | 19:12 |
| tyhicks | ah, didn't realize | 19:12 |
| 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:13 |
| zyga | tyhicks: please review 2624 first if you cna | 19:14 |
| zyga | can* | 19:14 |
| tyhicks | zyga: done | 19:27 |
| tyhicks | zyga: I don't guess I'll review 3031 unless I hear that it is still needed | 19:29 |
| mup | PR snapd#3028 closed: interfaces: seccomp tests cleanup <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3028> | 20:35 |
| 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:44 |
| 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> | 20:46 |
| 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:45 |
| * zyga waves goodbye | 21:46 | |
| zyga | see you tomorrow | 21:46 |
| tyhicks | zyga: np - have a good one | 21:49 |
| liuxg | jdstrand, ping | 23:01 |
| 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:16 |
| torusJKL | What am I missing here? | 23:17 |
| torusJKL | Here is my snapcraft.yaml file: https://github.com/torusJKL/snapcraft-projects/blob/master/bitcoin-qt/snapcraft.yaml | 23:18 |
| torusJKL | It looks to me like the following: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1584357 | 23:55 |
| torusJKL | I'm using the part desktop-qt5 but how do I add the gtk3 dependencies (e.g. "canberra-gtk-module")? | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!