=== chihchun_afk is now known as chihchun [08:05] good morning [08:19] good morning [09:00] Hey guys good morning. (If you are located in Europe) :) [09:00] In an experimental snapp I am playing with I have a binary which tries to access the $SNAP_APP_PATH variable [09:01] Instead of getting the /apps/NAME/version/ path I get the current directory there. [09:01] Any idea why and/or how I can get the actual path? [09:43] Good morning all; happy Thursday, and happy Old Rock Day! 😃 🎸 [09:50] exit [09:52] Hi all! I'm trying to make a webcam using program work. But apparmor denies me usage of my webcam (Denies ac [09:52] Hi all! I'm trying to make a webcam using program work. But apparmor denies me usage of my webcam (Denies access to the /sys/bus) === femdom is now known as renat [09:54] I can see that in OEM snap I can unmask webcam device in the "assign" setting. But is it possible to whitelist that webcam in the regular app snap? [09:55] I will ask my question again since it seems nobody saw it :) [09:55] In an experimental snapp I am playing with I have a binary which tries to access the $SNAP_APP_PATH variable [09:55] but it shows to be the current directory instead of what I would expect [09:55] anyone knows why? [10:01] LefterisJP, how are you trying to access? [10:01] Please see this http://pastebin.com/f0d2NRGZ [10:01] Notice that SNAP_APP_PATH becomes your workdir just before your application is started [10:03] I am simply trying to run the binary manually since running it from Appname.binary did not work and wanted to see why this happened. [10:03] The binary is the shell script from the go-template that chooses the "correct architecture" binary [10:04] from this post: https://insights.ubuntu.com/2015/06/03/so-you-want-to-write-a-snappy-app/ [10:07] This is the shell script in question: https://gist.github.com/LefterisJP/90d7a91933db92011a02 [10:07] for it to work I would expect snapp_dir=$SNAP_APP_PATH when echoed to show the /apps/name/version/ directory [10:08] Doesn't this happend because of line 30?\ [10:09] Please, see your wrapper in the /apps/bin/ directory [10:09] You will see a script which sets all SNAP_* variables [10:11] If it's your experimental script - you can just copy - paste all SNAP_* vars there and see if that helps. [10:17] it's not due to line 30 since I tried to echo the $SNAP_APP_PATH even before those lines, and then it seems to be empty. [10:18] But indeed you are right, there is a script in /apps/bin which looks like the one you linked. I can of course manually paste them and I expect it to work, but what would that achieve? I would like to be able to access these variables from my binary (and the shell script I linked assumes this is possible to select the right architecture) [10:32] hmm I think I understand. When I run the binary, then this wrapper at /apps/bin runs which in turn should call the architecture selection script. [10:32] No [10:32] There should be one more wrapper script [10:32] I am getting appname Geth.sideload not allowed so this is why I tried to run the binary directory [10:32] [10:33] /s/directory/directly [10:34] apps/bin/wrapper should run /apps/snapname.sideload/current/bin/binary.wrapper which should run /apps/snapname.sideload/current/bin/binary [10:34] Ok I am trying to see why I am getting sideload not allowed, so I am gonna go through all these [10:35] Maybe I'm wrong. [10:36] But anyhow if you use SNAP_* variables - you need to execute script in /apps/bin/ which sets all appropriate variables [10:39] Any idea why one would get this "Sideload not allowed" error? [10:39] This is what I get when I run the /appas/bin/wrapper [10:40] Don't know. Maybe you can find an answer if you run dmesg [10:54] so basically this part of the /apps/bin/wrapper script (last line) seems to fail [10:55] ubuntu-core-launcher Geth.sideload Geth.sideload_.-bin-geth_IJXfQHMIaSVL /apps/Geth.sideload/IJXfQHMIaSVL/bin/geth "$@" [10:55] with appname Geth.sideload not allowed [10:55] IF I use snappy-remote --url FOO install PACKAGE isn't it enough? Do I need something different to properly allow executing a sideloaded app? [12:05] kyrofa, ping [12:16] so I think I have pinned down the problem a bit more [12:16] I have installed the hello-world example which calls its binary also via ubuntu-launcher [12:16] ubuntu-core-launcher hello-world.canonical b c [12:16] Will give an error about the path [12:17] which is okay [12:17] but ubuntu-core-launcher Geth.sideload b c will give an error about the appname not being allowed [12:18] Why would ubuntu-core launcher not allow me to launch an app with that name when I have already installed it and it appears as sideloaded when I do `snappy list` ? [12:22] Chipaca, can you help out there [12:22] where? [12:22] LefterisJP, are you on rolling or 15.04? [12:22] Chipaca, ^ sideloading and core launcher failures [12:22] LefterisJP: what are you doing, exactly? [12:22] then again, I haven't grabbed all the details to the problem :-) [12:24] I am using an ubuntu 15.10 with snappy tools. I snapify a directory with snappy-build and get the package. Then I upload it to my Rpi with snappy-remote. [12:24] Once there I can confirm it's sideloaded with snappy list [12:25] But when I try to run the Binary by doing Geth.geth I get the: [12:25] appname Geth.sideload not allowed [12:25] error [12:25] LefterisJP: do you have click-reviewers-tools installed? [12:25] LefterisJP: I don't think you can use uppercase there, but i might be wrong [12:26] So I have been digging to find out why this happens, and it's an error omitted by this ubuntu-core-launcher used in the wrapper script. [12:26] Good morning [12:26] enoch85, pong [12:26] Chipaca: Good idea. I will try with all lowercase too. What about the click-reviewers-tools? Is it supposed to be in the target or in the host machine? [12:27] LefterisJP: if you have it installed on the host machine, `snap build` will warn you about stuff [12:27] kyrofa, hey Kyle! :) How is your schedule today? :? [12:27] LefterisJP: as long as you have a recent-enough one installed, it'll give you the same warnings as the store would [12:28] kyrofa, morning [12:28] Chipaca: Just checked. I do have it. And snappy build gives no warnings. [12:30] LefterisJP: hmm... i don't believe you =) [12:30] LefterisJP: you should be getting "malformed name" with an uppercase package name [12:31] LefterisJP: i just checked this [12:31] LefterisJP: maybe you have an older snappy that *didn't* run click-review automatically? [12:32] LefterisJP: try running it by hand: click-review [12:32] e.g., $ click-review Hello-world_1.0.18_all.snap [12:32] Errors [12:32] ------ [12:32] - lint:snappy_name_valid [12:32] malformed 'name': 'Hello-world' [12:32] Hello-world_1.0.18_all.snap: FAIL [12:32] ahh wait [12:32] I had already changed the name .... [12:33] LefterisJP: ah :) [12:33] let me try again [12:34] enoch85, this morning is a little full, but this afternoon is a bit more open === chihchun is now known as chihchun_afk [12:34] nah .. changed it back and snappy build did not complain. [12:35] http://postimg.org/image/jek4a32o5/ [12:35] Maybe I do have an older version. [12:35] Let me see if the RPI likes the lowercase name though [12:35] LefterisJP: you can always run click-review by hand, as above [12:35] sergiusens, elopio I need to miss standup today-- I have a doctor's appointment [12:35] kyrofa, no worries [12:36] LefterisJP: i'd suggest you add the ppa to have the most recent stuff if you're going to be building stuff with snappy long-term [12:38] Chipaca: Will do. Thanks. Good to know this tool exists. [12:41] Chipaca: Which ppa? I only have the one mentioned in the Get Started guide. [12:41] ppa:snappy-dev/tools [12:42] LefterisJP: hm, that's probably right. What does `apt-cache policy ubuntu-snappy-cli` say? [12:43] Installed: 1.5ubuntu1 [12:43] Candidate: 1.5ubuntu1 [12:43] Version table: [12:43] *** 1.5ubuntu1 0 [12:43] 500 http://gb.archive.ubuntu.com/ubuntu/ wily/universe amd64 Packages [12:43] 100 /var/lib/dpkg/status [12:43] [12:46] huh [12:46] mvo_: ping [12:49] LefterisJP: i guess that is the right version for 15.04 compatibility (which is stable snappy until 16.04) [12:49] but we might want to enable click-review (i thought we had?); hence mvo_ ping === popey_ is now known as popey [12:52] Chipaca: understood. Anyway it really helps since I am already getting other errors with my snap thanks to these tools. `Error could not find binary`. Looking into what it is now [12:53] LefterisJP: 👍 [13:01] Hi guys! It's Renat from Screenly. I have more and more questions=) [13:03] First - how I can enable access to the webcam in the snapcraft.yaml file? I want to use webcam snap (C++ app with OpenCV). And when I try to run it - that app doesn't work. Because of AppArmor. I've used hw-assign to enable /dev/video0 for my snap. [13:03] But it doesn't work anyhow. [13:03] From dmesg I can see [13:03] apparmor="DENIED" operation="open" profile="webstreamer.sideload_camcapture_IJXBNQHfABEX" name="/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1/1-1:1.0/video4linux/video0/dev [13:08] renat, I'll defer that to jdstrand ^ [13:09] sergiusens, thanks [13:17] sergiusens, take another look at https://github.com/ubuntu-core/snapcraft/pull/206 when you're able? [13:18] kyrofa, cool, I will go to my regular work now, but I'll be back in your afternoon. As I said earlier, feel free to work without me. :) Later! [13:18] enoch85, sounds good! [14:12] If I am having trouble with an executable inside an Ubuntu core installation on the Raspberry PI is there any way to invoke common Unix tools like strace and ldd to see what could be wrong? [14:12] (Want to find out why my cross-compiled executable does not run) [14:13] kyrofa, sorry one more comment [14:13] sergiusens, no need to be sorry! Thanks for being thorough :) [14:14] LefterisJP, not exactly strace but `sudo snappy install snappy-debug` [14:14] it will help out with all the security warnings and such [14:15] sergiusens, fixed [14:17] sergiusens: thanks. Will try it out [14:20] kyrofa, just fwiw, I thought you said we needed the exact format for closing bugs '(Closes LP: #XXXX)' or is 'Fixes ...' also fine? [14:20] kyrofa, or just LP: #XXXX [14:21] you must be gone by now :-P [14:21] sergiusens, right, Closes|LP is the default pattern [14:21] sergiusens, so LP: #XXX [14:22] sergiusens, alright I gotta run [14:22] Chipaca: ups, sorry for the delay. yes, I thought we did enbable that, wonder what happend here. did you figure it out already or should I have a look [14:22] mvo_: i haven't looked [14:45] sergiusens: sorry, I hit the close button but you kept talking :) [14:45] elopio, no, mutual [14:45] I did not notice you hit it [14:45] :-P === lool- is now known as lool [15:01] stgraber: yesterday I almost got all the tests passing in the travis lxc. But then I wanted to run them as the user, not as root, and it fails when the tests try to run sudo, like this: http://pastebin.ubuntu.com/14430440/ [15:01] sudo: no tty present and no askpass program specified [15:01] Do you know a good way to work that around? [15:04] stgraber@castiana:~$ lxc exec blah -- su - ubuntu -c "sudo ls /" [15:04] bin dev home lib64 media opt root sbin sys usr [15:04] boot etc lib lost+found mnt proc run srv tmp var [15:04] seems to work here, can you give me the url to your travis.yml again? [15:05] stgraber: I rolled back to root late last night: https://github.com/elopio/snapcraft/blob/lxd/.travis.yml [15:11] elopio: ah, the difference is probably that I was tested with the official cloud images rather than the minimal image we have on images.linuxcontainers.org [15:12] stgraber: should I be using the official cloud image instead? [15:13] elopio: instead of "lxc remote add..." do "lxd-images import ubuntu xenial --stream daily --alias ubuntu" and instead of "lxc launch images:..." do "lxc launch ubuntu xenial" [15:14] I like that :D [15:14] elopio: I think so, that'll solve the sudo issue at least and probably save you a few dependencies too. Some folks still prefer the other images due to their size, they are about half the size of the cloud images [15:47] renat: you use hw-assign for things in /sys/devices too. It can be used with globs (one '*' for everything in a directory, '**' for subdirectories too and end with a '/' and it is everything in that directory. eg, 'sudo snappy hw-assign foo.sideload '/sys/devices/**/video4linux/video0/' [15:47] renat: note, this is going to change with the new capabilities work [15:49] zyga: fyi (and I think we are on the same page here) is that when we do a capabilities assignment (eg, assign camera which maps to /dev/video0 underneath (whatever the syntax ends up)) then we get not only the /dev/video0 but also /sys/devices/**/video4linux/video0/ (and related items) [15:50] s/is that// [15:50] renat: hey, did you see my comment to you regarding hw-assign? you dropped off right after I gave it [15:50] renat: in case not: you use hw-assign for things in /sys/devices too. It can be used with globs (one '*' for everything in a directory, '**' for subdirectories too and end with a '/' and it is everything in that directory. eg, 'sudo snappy hw-assign foo.sideload '/sys/devices/**/video4linux/video0/' [15:51] renat: note, this is going to change with the new capabilities work [15:57] jdstrand, thanks. Where I can read about new capabilities? So this mean - it's not possible to enable access to the device until snap is not installed? [15:58] renat: the new capabilities work was announced on snappy-devel@ in Nov/Dec. it is still being defined/implemented and isn't available yet on any images [15:58] well, maybe it is in parts. perhaps zyga can point you at something [15:59] jdstrand, understood. Thanks. [16:19] * sergiusens takes a break from implementing the new format for snap apps [16:41] jdstrand: hey [16:41] jdstrand: that's up to the capability to decide, I have some code I want to show you for some review [16:41] jdstrand: but probably tomorrow, I'm trying to make something that I can propose in parallel to other branches aimed at trunk [16:42] jdstrand: I'd like to understand how to plan for the major flag day when snappy uses capabilites to boot [16:42] jdstrand: and to do that I need to get everyone to agree on a few details [16:43] jdstrand: and to ask you and tyhicks about some details of ubuntu-launcher and apparmor/seccom bits [16:43] jdstrand: specifically, exactyl which file is read / written by which tool outside of snappy itself [16:43] jdstrand: *exactly [16:43] jdstrand: I read most of aa and snappy code related to that but I don't want to bet I'm correct [16:44] jdstrand: as for the actual security bits, I'll show you a branch/gist in one hour, we can discuss it tomorrow/next week [16:57] sergiusens: hmm.. cant find a python pip example anymore : [16:57] :( [16:58] * asac feels blind [16:58] python3 and py2 seem to not be doing pip stuff anymore [16:58] but rather pull from git a tree [17:01] asac, there are many, te most simple one using whatever is in setup.py https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pypi-config/snapcraft.yaml [17:02] asac, using `python-packages` https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pip-requirements-list/snapcraft.yaml [17:02] asac, and requirements.txt https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pip-requirements-file/snapcraft.yaml [17:03] asac, also `snapcraft help python3` [17:03] or 2 [17:03] sergiusens: why no example/ anuymore? [17:03] asac, I don't think there ever was an example [17:08] Guys. It's me again. Sorry=( For the some reason /dev/vchiq device not appearing in snappy. But I can see it in Raspbian. [17:10] Tried to load vchiq by modprobe, with no result. Maybe it's compiled in somehow. [17:11] Maybe it's because udev. Let me investigate. [17:12] sergiusens: really odd ... i see https://aws.amazon.com/de/cli/ that pip install awscli should do the trick [17:12] but if i do this it doesnt yield a bin/aws et. [17:12] etc [17:13] well look at en: https://aws.amazon.com/cli/ [17:13] hello all. I have an armhf c++ project that depends on several 3rd-party libraries (zmq, jsoncpp, eigen, etc) that I've been running on a bunch of beaglebone blacks with debian. I'd like to port this project, and a couple of others, to snappy in order to take advantage of the atomic updating/rollback features. What approach do you all recommend? Should I adapt the project to use snapcraft, or build as I have been with make, and [17:13] include all of the libs manually in the snap? [17:15] Or... do you think I'm better off just implementing the update/rollback features myself and not using snappy? [17:16] Thanks in advance for your help :) [17:18] zyga: ack [17:18] jdstrand: thanks! [17:21] asac, strange since we already had aws' cli working with snapcraft [17:48] jdstrand: I won't have the gist for discussion today, sorry :/ [17:48] jdstrand: I got more food for though with hooks, I'm processing that now [18:01] Nevermind guys. vchiq worked after firmware upgrade using rpi-update. [18:06] zyga: no worries-- I've got plenty to do :) tomorrow or ideally monday would work best for me. enjoy your evening :) [18:09] jdstrand, sorry for disturbing you. Not sure if it's important, but your current Raspberry PI2 firmware with vchiq support broken. I don't know who is responsible for that, but you may want to update your raspberry pi image with newer firmware. [18:11] ogra_: iirc, that is something you'd be interested in ^ [18:12] renat: thanks [18:13] vchiq ? [18:13] * ogra_ googles [18:14] well, i doubt anything on the RPi is even remotely ready for graphical stuff yet [18:14] i was planning to take a look after my vacation though [18:26] renat, please file a bug :) [18:27] ogra_, ok. [18:48] Chipaca, are you still around? [18:48] kyrofa: no [18:48] kyrofa: 'sup? [18:48] Chipaca, okay I'll ask tomorrow ;) [18:48] kyrofa: i've got 5 minutes before the risotto needs tending again [18:49] * sergiusens notices that Chipaca is always needs to leave as soon as food is ready implying he might be eating all day [18:49] :-D [18:50] * Chipaca agrees [18:50] Chipaca, okay this should be relatively quick. The discussion here (https://github.com/ubuntu-core/snappy/pull/264) culminating in the ML post just sent... I don't understand what he's saying. We redefine $HOME=$SNAP_APP_USER_DATA_PATH anyway [18:50] kyrofa: ah. i haven't read the email yet. [18:50] kyrofa, he's saying running sudo should make $HOME point to the euid [18:50] today, sudo preserves your env on ubuntu [18:50] sergiusens, but the wrapper effectively does that [18:51] sergiusens, well, along with #264's fix [18:51] kyrofa, you might be completely right here; we have too many wrappers to keep track of ;-) [18:51] sergiusens, yeah there's that problem too :P [18:52] kyrofa: I think #264 is one implementation of this, but [18:53] kyrofa: maybe we should just get euid's home directly and not worry [18:53] Chipaca, so really it's a different implementation altogether. Before the wrapper it touched, $HOME should point elsewhere? [18:54] Chipaca, which is where you were coming from with the libc comment, okay I think I gotcha [18:55] something like that, yes [18:56] Chipaca, okay thank you! I just wanted to understand where he was coming from there [18:56] any1 able to answer questions about mir, xmir or shared libs in snappy? [18:56] kyrofa: just read gustavo's email, and i think his proposal is sane and is basically what you're trying to do with 264 but gives us a framework against which to check the other things; i still need to look at what we're doing vs what we want to do [18:58] Chipaca, okay. I'm going to leave #264 alone until I get some better guidance. I can tweak that as needed, close and do something earlier in the process, or just let you deal with it [18:58] mterry: are u online? [18:59] kyrofa: +1.33̑ [18:59] kyrofa: My concern, which I'm trying to address in that mail, is that we've been solving that issue in small pieces, and with slightly different semantics each time [18:59] jerryG: what's your question about shared libs in snappy? [19:00] niemeyer, oh I'm sorry-- I would have just asked you but I was trying to put the e before the i and it wasn't tab-completing, so I figured you weren't online :P [19:00] kyrofa: Rather than tweaking where the user data points to, I hope we can make it consistently point to the user's home, so everything falls from that [19:00] kyrofa: No worries [19:00] niemeyer, and yeah, I'm on board with that [19:00] niemeyer, we'll still need to create the directory when it comes to services, though [19:00] this breaks the "sudo vim finds my .vimrc", but i don't see a way around that [19:01] kyrofa: If there's consensus around that approach, it's clear how to fix the problem in every case [19:01] and so many apps get that wrong and write the user's config when uid!=euid, it's not worth it tbh [19:01] kyrofa: Why are services any different? [19:02] Chipaca: I have 2 questions: 1. how do I add shared libraries (files) in snapcraft.yaml, 2. how do I include xmir in my app, [19:02] niemeyer, just because the binary wrapper makes sure user data path exists, services do not [19:02] kyrofa: That sounds like a bug on itself [19:02] jerryG: shared libraries should be added automatically aiui [19:02] niemeyer, agreed [19:02] kyrofa: In the sense that services shouldn't have a complete different path for everything [19:02] kyrofa: services are not that special [19:03] jerryG: i know nothing about xmir, but maybe somebody else here does =) [19:03] niemeyer, yeah I think that should be removed from the wrapper and added to ubuntu-core-launcher [19:03] niemeyer, makes them more similar [19:03] the wrapper needs cleaning up a lot [19:03] for 16.04 [19:04] including nuking the silly tmpfile thing we did pre-1504 [19:04] (i mean silly to still be doing it now we no longer do it) [19:04] kyrofa: I still haven't visited the whole code base, and this is an area I'm specifically less aware about, so I'm afraid of saying yes or no.. perhaps would be my best answer before I know more [19:05] niemeyer, understood! +1 on your proposal though [19:05] niemeyer, I'll respond to the ML though [19:05] Chipaca: pre-1504 makes it sounds *really* old :D [19:05] Hahaha [19:05] kyrofa: Thanks, appreciated [19:05] Chipaca: how do I wrap program with LD_PRELOAD? like mterry did? [19:05] jerryG, am now, back from lunch [19:06] mterry: great!.. how does libsnappypreload.so work? How do I include .so files in my snaps? [19:06] niemeyer: ditto for SNAPP_ variables [19:06] jerryG, look at how https://github.com/mikix/deb2snap works [19:06] jerryG: libsnappypreload.so is *old* [19:06] jerryG: what are you trying to do? [19:06] jerryG, it has most of the grossness on display -- src for libsnappypreload [19:06] jerryG, and wrappers to use it [19:06] jerryG, but it's a super gross way to do things [19:06] i mean, the old way to do thinigs =) [19:07] jerryG, Chipaca can explain the new fun way [19:07] no no, i can have dinner [19:07] which is almost the same thing, but different [19:07] * Chipaca afk's [19:07] heh [19:07] jerryG, well *someone* can explain the new ways (using snapcraft and such) [19:07] jerryG, I'm not so involved with that [19:07] sergiusens: ^^ [19:08] mterry: ok thanks. Can you answer questions about xmir and mir? or is that different now too? [19:09] jerryG, it maybe be different, I'm not sure how snapcraft helps integrate those [19:11] mterry: I read that xmir must be implemented in the snap, and use mir as a framework [19:14] jerryG, yeah that's still the current plan I think [19:15] mterry: how do I implement xmir in the snap? is that similar to the way you did it? or is that different now with snapcraft? [19:15] sergiusens, alright 1.0 is ready to go. Want to take another look at the changelog? [19:15] Chipaca: thanks for the help :} [19:16] sergiusens, any other backports/features need to go into that? [19:16] jerryG, I don't know how different it is in snapcraft these days [19:16] elopio keeps stealing my travis [19:16] His tests take forever [19:17] mterry: is there any docs or any way to check?... I couldn't find much about xmir and mir in snappy other than your git [19:17] jerryG, I don't know! The only intel I have is ancient when I made deb2snap [19:17] :-/ [19:18] jerryG, maybe tedg knows? [19:18] mterry: k thx. what do they have u working on now? [19:19] jerryG, oh I work on the phone [19:19] jerryG, which isn't *yet* on snappy :) [19:23] mterry: oic [19:23] kyrofa, let me take a minute or two on that [19:24] sergiusens, take your time. I'm sorry for dragging it out but I'm happy with it now :) [19:28] mterry, jerryG we are getting rid of frameworks for 16.04 [19:29] for the new way to setup mir, talk to kgunn, he's working on a wiki part (not done yet I believe) [19:29] tht said, I have no idea how display stuff works, much less xmir [19:30] sergiusens: can u help with shared libraries?... can I include them manually instead of using apt-get? [19:31] sergiusens: interesting decision to remove frameworks [19:32] jerryG, what do you mean by manually? you have a lib already? use the copy plugin [19:32] sergiusens: kk [19:34] kyrofa, ok, back from work. are you here? [19:34] enoch85, I am :) [19:34] jerryG: as sergiusens, i've just learned myself that things are changing for 16.04 wrt frameworks and security policy... [19:35] so even i'm back at the drawing board for mir [19:35] kgunn, oh, I thought frameworks wouldn't affect the 'single snap model' [19:36] sergiusens: you're right in that sense, it's only related in that, aiui we can't split out sec caps to different parts within a snap [19:36] and sec team doesn't want too much capability in a snap for a client app [19:37] so i'm being pushed back to the 2 snap approach [19:37] kgunn, I thought the idea was for each app in a snap to have its own capabilties [19:37] kgunn, oh, yeah, that brings in a lot more work [19:38] sergiusens: right, it was a feasible way (the 1 snap) but wouldn't scale.... [19:38] and doesn't really match the framework going away (as can't set you're own policy) === Saviq_ is now known as Saviq === plars_ is now known as plars [19:42] kgunn: On 15.04 stable, to use xmir, do I need to include it inside snap and utilize mir framework?.. if so... how do I include xmir inside snap? === thesheff17_ is now known as thesheff17 [19:44] kgunn: are you going to ubucon? [19:48] Hello all, the company I work for is considering Ubuntu Core as the basis for an IoT product that we are building on top of the BeagleBone Black. Is Snappy mature enough for commercial production? [19:50] Doughy: no [19:50] Doughy: well.. depends on what ur doing [19:51] jerryG: We would like to use it as the embedded distribution on the BBB. We are attracted to the update features. [19:52] Basically we have a gateway device with the Beaglebone Black, that runs our application and web server. We would like our interface to have an "UPDATE NOW" button that allows us to push both OS and application updates to the device. [19:53] kgunn: you are able to use different 'caps' within a snap now and with the new capabilities work [19:53] kgunn: eg: [19:53] apps: [19:53] - name: foo [19:54] caps: ... [19:54] - name: bar [19:54] caps: ... [19:55] kgunn: this will look different than 'caps' in 16.04, but this sort of thing will be available. what won't available is defining raw security-policy. people will have to work with Canonical to define the new capabilities (security caps currently) [19:56] but the two snap approach (server/shell and client app) is a cleaner model than everyone forking mir+app [19:57] and it happens to work well with the new capabilities approach [20:00] what also won't be available is shipping framework-policy === josepht` is now known as josepht [20:03] got it, so really, reviewing for the store not scaling is the main reason [20:04] jerryG: yes, you would need to include xmir in your client snap === wililupy is now known as wililupy|Lunch [20:04] xmir is just a client from mir's perspective [20:04] not going to ubucon === wililupy|Lunch is now known as wililupy [20:09] sergiusens, why does the autotools plugin run `./configure --prefix=` ? Is that intentional? [20:10] kyrofa, we have that from original code, maybe mvo_ or mterry know [20:10] kyrofa, I always meant to ask [20:10] sergiusens, it breaks my apache build [20:11] mterry, any clues there? [20:11] kyrofa, fix it to anything that makes sense ('/' or '/usr') [20:11] kyrofa, prefix is commonly /usr or /usr/local [20:12] kyrofa, I found some packages that broke with prefix=/ [20:12] kyrofa, if you do a --prefix in configflags the last one takes precedence I believe [20:12] kyrofa, but I didn't find one that broke with prefix= [20:12] kyrofa, (and I wanted one of them purely for cosmetic reasons, so that all files in the snap weren't full of /usr paths [20:13] mterry, that makes sense, thank you for the explanation! It just hanging there looked... bug-like [20:13] sergiusens, good to know, I'll give that a shot :) [20:13] sergiusens, not a bit autotools user here [20:15] s/bit/big/ [20:16] Anyone know if there is a way I can get someone from Canonical on the phone? I'm willing to pay for it. I need answers around Ubuntu Core and can't seem to get them. [20:17] kyrofa, I am mostly done with the work to support snap.yaml, package.yaml, readme.md and all the hooks (icon, license and config) :-D [20:17] just pending a rewrite of all the unit tests :-P [20:17] Doughy, have you tried the snappy mailing list? [20:18] sergiusens, awesome! [20:18] sergiusens, you work too fast. Makes the rest of us look bad [20:20] Doughy, Ubuntu Core is pretty stable, but it is indeed under heavy development. You would need to be aware of that [20:20] kyrofa, nah; once you see this you will notice it wasn't that complicated [20:23] Doughy, what specific questions do you have? [20:24] kyrofa, I have an armhf c++ project that depends on several 3rd-party libraries (zmq, jsoncpp, eigen, etc) that I've been running on a bunch of beaglebone blacks with debian. I'd like to port this project, and a couple of others, to snappy in order to take advantage of the atomic updating/rollback features. What approach do you all recommend? Should I adapt the project to use snapcraft, or build as I have been with make, and include a [20:25] ...in the snap. [20:25] Doughy, alright, so a current limitation of snapcraft is an inability to cross-compile, so you would need an arm environment in which to run it (e.g. a qemu vm) [20:25] OK, that's not a problem. [20:26] Doughy, and that's only if you choose to do the build with snapcraft. If you keep your current built methodology, you can cross-compile yourself and simply package the result as a .snap [20:26] Doughy, how do you include the 3rd party libs? Do you compile from source? .deb packages? [20:27] Compiling from source. [20:27] Doughy, man you're golden if you can live with the cross-compile limitation of snapcraft [20:28] Is there a good example of a C++ snap that uses 3rd party libraries that we can go off? [20:30] Doughy, hmm... you know I don't think there is. But I'm currently working on one I'd be happy to share once I make some more progress [20:31] Doughy, there are examples of using libs packaged as .debs, but not source depending on source that I know of [20:31] kyrofa, That would be awesome. Really appreciate it. Do you work for Canonical? [20:31] Doughy, I do [20:31] kyrofa, there are simple examples in c, 'downloader_with_wiki_parts' and 'libpipeline' [20:32] Ah, thanks sergiusens. Doughy check out https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/libpipeline [20:33] kyrofa, Does Canonical offer any paid support for this kind of stuff? Some way to get direct support as we develop rather than hoping to find you here? [20:33] We'd be willing to pay to make sure we can get questions answered quickly. [20:33] Thanks for the link. We've seen that link., [20:34] Doughy, yeah, we just need to put you in touch with the right people. Mind shooting me your email in a PM? [20:34] Awesome. Will do now. === aPragmatist is now known as ummon [21:35] kyrofa, ok, so early morning we can do the release; I'll create a hangout so you can see how boring it is [21:36]