[00:07] <josharenson> I have a python script that is a wrapper for my build process. I'm currently using cmake as my plugin and my CMakeLists.txt just calls execute_process on the python script. This is stupid. Should I just make the plugin python and name my script setup.py even though its not really a python module?
[00:07] <josharenson> I guess I could use make too...
[00:08] <josharenson> ^^ that actually worked pretty well
[00:10] <qengho> josharenson: Are you distributing some python, or something made with python?
[00:12] <josharenson> qengho: something made with python
[00:12] <qengho> I'd "build-packages" python, instead of "plugin: python". I think so. Not sure.
[00:13] <josharenson> qengho: Yeah I added python as a build-package and made this http://pastebin.ubuntu.com/16209847/ my makefile
[00:13] <josharenson> seems reasonable
[00:13] <qengho> Cool!
[00:14] <josharenson> qengho: yeah, thanks
[00:14] <qengho> You probably get a smaller package than with plugin-python.
[00:21] <ZenHarbinger> BTW, I did update the answer on askubuntu. that is all. 'nite!
[01:46] <sergiusens> elopio the last one https://github.com/ubuntu-core/snapcraft/pull/499
[01:46]  * sergiusens goes to bed
[01:48] <elopio> good night.
[01:54] <swami> hi
[01:56] <swami> can someone help answer this question, posted in the dev mailing list? https://lists.ubuntu.com/archives/snappy-devel/2016-May/001802.html
[04:31] <example6> Hi guys. I'm trying to build a snap that just runs a shell script that runs a pre-built executable made for a specific system. Right now I'm just using the 'make' plugin to copy my files and wrapper into place, and I've added daemon: simple and my wrapper as a run command but it doesn't seem to be starting when I install or reboot. Any advice on making this happen?
[04:31] <example6> I can't seem to find any documentation on it
[07:25] <zyga> good morning
[07:33] <slvn> hello!
[07:34] <slvn> no bug report for today :)
[07:35] <slvn> just a question, I was wondering the signication, when publishing a snap, of "series : 15.04/rolling core, 16, rolling core" ?
[07:35] <zyga> slvn: well, it where is your snap going to work?
[07:36] <zyga> slvn: you should go with 16
[07:36] <zyga> slvn: that's "stable", that s what people will get
[07:37] <slvn> zyga, ok, it makes sense, that's what I chose
[07:39] <slvn> zyga, btw, I published a basic snap app, using SDL2, with SDL2 log debug enabled. may be useful for testing...
[07:40] <zyga> slvn: what is the name of the snap?
[07:40] <slvn> zyga, tic-tac-toe . At first, this is a mobile game, but it runs also on desktop.
[07:41] <slvn> (it's more like a testing sample for me, than a real app)
[07:44] <noizer> zyga: Hi I installed my rpi1 and looked if it is soft floating but it is hard floating how can that be?
[07:44] <zyga> it cannot
[07:44] <zyga> how did you check that?
[07:45] <noizer> they told me to look in the /lib dir
[07:45] <noizer> and there you can see arm-linux-gnueabihf
[07:46] <noizer> zyga or is there a way too see it better?
[07:48] <zyga> no, you seem to be right, one set
[07:49] <zyga> though not all is lost
[07:49] <zyga> you should be able to run an armel chroot now, let me show you how to make one
[07:49] <noizer> ok
[07:55] <zyga> noizer: trying now
[07:55] <noizer> zyga Ok :p
[08:03] <zyga> geez pi1 is slow like hell
[08:03] <zyga> it's happening, just ... ... ... slowly
[08:07] <noizer> zyga I know thats not realy fun
[08:08] <zyga> (in other news debootstrap is written in perl, perl is slow)
[08:14] <noizer> Maybe a other question about it. When I'm developing further on this application can i compile it then on the rpi3 or rpi2?
[08:18] <zyga> as long as you are in the armel chroot, yes
[08:20] <noizer> awesome :D
[08:21] <noizer> then it will be faster to compile on the armel chroot :D
[08:28] <zyga> noizer: anyway, you can give this a try, sudo debootstrap --arch=armel sid armel
[08:28] <zyga> noizer: this will create the directory "armel" with a debian chroot
[08:29] <noizer> debootstrap command not found :s
[08:40] <noizer> zyga how long does it take for debootstrap?
[08:43] <zyga> noizer: on pi1 ~ hour
[08:43] <zyga> on pc ~ minute
[08:43] <noizer> does we need to make it on rpi1?
[08:43] <zyga> yes
[08:43] <noizer> pfff hate that
[08:44] <zyga> it's possible to do on pc but stage 1/2 stuff is more complicated and you need to finish a lot of the slow part on the real hw anyway
[08:44] <noizer> zyga ok np i'll wait
[09:37] <noizer> zyga and  still busy with you?
[09:59] <mvo> ogra_: hm, what is up with livecd-rootfs in ppa:snappy-dev/image - can those changes get merged to trunk?
[10:00] <ogra_> mvo, sure ... thats effectively only the addition of uboot-tools to all arches (everything else was reverted again ...
[10:01] <ogra_> note that we still dont have an x86 uboot gadget, so we still dont know if uboot on x86 will work with the changes we did
[10:01] <mvo> ogra_: ok
[10:01] <mvo> ogra_: I have a trivial change for the new kernel spec :)
[10:01] <mvo> ogra_: I commited to trunk already and merged your stuff and uploaded, I was just surprised at first
[10:02] <ogra_> mvo, well, we dont use trunk in xenial ...
[10:03] <ogra_> (and i have set yakkety builds to manual, dailies come from xenial currently)
[10:03] <ogra_> (for cdimage that is)
[10:06] <mvo> ogra_: we use the ppa version in the xenial ppa, that is what you are saying, right?
[10:06] <ogra_> mvo, or if we delete that we use the xenial version from the xenial archive :)
[10:07] <ogra_> xenial images use the xenial livecd-rootfs ... we'd have to SRU the changes like with any other package
[10:08] <ogra_> thats what i mean ...
[10:09] <mvo> ogra_: *cough*
[10:09] <ogra_> *grin*
[11:09] <noizer> zyga: its done ove rhere
[11:09] <zyga> noizer: cool, chroot away
[11:09] <noizer> zyga ps how can i see its succesfully done?
[11:10] <zyga> noizer: if id crashed you'd know
[11:10] <noizer> because i got some warnings
[11:10] <zyga> like?
[11:12] <noizer> W:Failure while installing base packages
[11:12] <noizer> ...
[11:13] <zyga> anything more?
[11:13] <noizer> wait I will send you a picture
[11:14] <zyga> I recommend ssh, you can copy paste stuff
[11:14] <zyga> but a photo works too
[11:14] <noizer> haha i didn't use this time ssh
[11:15] <ogra_> and for taking the photo, we recommend using an ubuntu phone
[11:15] <ogra_> :)
[11:15] <noizer> hehehe I want the new ubuntu phone
[11:15] <zyga> you can then scp the photo off the phone :)
[11:15] <noizer> do you got an ubuntu phone?
[11:16]  * ogra_ has three ... and just ordered the MX5pro last week
[11:16] <ogra_> (but i used to work on the phone team before snappy :) )
[11:16] <noizer> http://imgur.com/Inp1Qm7
[11:17] <noizer> ogra_: ooh is it good the new ubuntu phone?
[11:17] <ogra_> can you push the bootstrap.log file somewhere ?
[11:17] <ogra_> noizer, i can tell you once i have it in my hands :)
[11:17] <noizer> ogra_: oooh ok xD
[11:17] <noizer> ps i try to push it
[11:17]  * ogra_ hopes it arrives before the sprint ... but my hopes are low
[11:18] <zyga> brb
[11:18] <ogra_> wait, are you trying to bootstrap armel on an armhf machine ?
[11:19] <noizer> http://pastebin.com/h0nBVQc8
[11:19] <noizer> on the raspberry pi 1
[11:19] <ogra_> cannot copy extracted data for './usr/share/man/man1/req.1ssl.gz' to '/usr/share/man/man1/req.1ssl.gz.dpkg-new': failed to write (No space left on device)
[11:19] <ogra_> there is your issue
[11:20] <noizer> omg
[11:20] <noizer> thats 8gb of space and not enough omg
[11:20] <noizer> or does i need to expand it maybe
[11:20] <ogra_> check with "df -h"
[11:21] <noizer> ogra_:  dammed only 4gb
[11:21] <noizer> how can i expand it easily?
[11:21] <ogra_> is that a snappy install ? +
[11:21] <noizer> raspbian
[11:21] <ogra_> ah
[11:22] <ogra_> no idea then ... i'D try with gparted
[11:22] <ogra_> (on the PC )
[11:22] <noizer> yea thats the way I always do it
[11:22] <zyga> noizer: there's something in raspi-config AFAIR
[11:23] <zyga> yep
[11:23] <zyga> sudo raspi-config
[11:23] <zyga> pick the expand filesystem option from the menu
[11:28] <noizer> debootstrap is started again
[12:03] <kyrofa> Good morning
[12:03] <sergiusens> good morning everyone!
[12:04] <sergiusens> mvo so follow up from my apt issues, this fixes it https://github.com/ubuntu-core/snapcraft/pull/499
[12:25] <zyga> jdstrand: hey
[12:30] <kyrofa> sergiusens, meet in 30?
[12:30] <noizer> zyga can you tell me the following steps (raspi is still busy but i can prepare myself then)
[12:31] <zyga> noise][: bind mount /proc and /sys into the chroot, chroot inside, try to build your app
[12:32] <noizer> zyga chroot /path/to/dir
[12:33] <noizer> is it that you mean
[12:33] <noizer> of coure after bind mount ...
[12:33] <sergiusens> kyrofa maybe 45?
[12:34] <kyrofa> sergiusens, sounds good
[12:34] <zyga> noise][: chroot armel; if you followed the command I used earlire
[12:35] <noizer> Ok
[12:36] <noizer> hopefully is he almost done he is now reloving dependencies of base packages :s
[12:36] <ogra_> re loving :)
[12:36] <ogra_> love it back !
[12:37] <noizer> ogra_: hahahah xD sorry resolving :p:p
[12:37] <ogra_> :)
[12:38] <zyga> that reolves the situation
[12:38] <noizer> how is the ubuntu summit?
[12:38] <zyga> good
[12:39] <zyga> I always like the fact that UOS is recorded
[12:39] <zyga> UDS was fun but if you weren't there, you lost 90% of it
[12:39] <zyga> UOS is more egalitarian
[12:39] <noizer> heheheh xD
[13:13] <jdstrand> zyga: hi! :)
[13:13] <zyga> hey, good morning :)
[13:13] <jdstrand> good afternoon :)
[13:14] <zyga> jdstrand: I have an intereting bug, I have no idea what the cause is: https://bugs.launchpad.net/snappy/+bug/1578091
[13:14] <zyga> jdstrand: this breaks sdl (which I already fixed) but I wonder why this happens
[13:15] <jdstrand> let me check something
[13:15] <jdstrand> zyga: to be clear, the profile is otherwise in complain mode, it is loaded in the kernel and you are seeing an apparmor denial?
[13:15] <zyga> yes
[13:16] <zyga> no
[13:16] <zyga> not apparmor denial
[13:16] <zyga> I jus get EPERM
[13:16] <zyga> just run hello world and cat it
[13:16] <zyga> that's why I don't get it:)
[13:16] <jdstrand> what are the permissions on the file?
[13:16] <zyga> maybe /proc mount point something
[13:16] <zyga> r-r-r-
[13:16] <zyga> they are not the problem
[13:16] <zyga> no idea :)
[13:16] <jdstrand> zyga: can you access the file outside of confinement?
[13:16] <zyga> yes
[13:17] <jdstrand> ok, we have an explicit denial for that
[13:17] <jdstrand> deny @{PROC}/@{pid}/cmdline
[13:18] <jdstrand> I will need to talk to tyhicks or jjohansen on what complain mode is supposed to do wrt explicit denies
[13:18] <jdstrand> they'll be online a bit later
[13:19] <jdstrand> zyga: does the app work ok without it?
[13:20]  * jdstrand would think it is a bug in complain mode that it is enforcing an explicit deny
[13:21] <jjohansen> jdstrand: explicit denies override complain mode. Basically complain mode only applies to that which there isn't a rule for.
[13:21] <jdstrand> ok, I see
[13:21] <jdstrand> jjohansen: good morning-- I wasn't expecting you here now :)
[13:21] <zyga> no, it crashes
[13:21] <dholbach> sergiusens, kyrofa: will you be able to run the "how to snap your software" session later on yourself?
[13:21] <zyga> jdstrand: btw, why is this deny working even in complain mode
[13:21] <dholbach> it looks like I'm double-booked and would need to go to the CoC review session as well
[13:22] <jjohansen> zyga: because complain mode only applies to denials that are caused by missing rules, not for rules that already exist
[13:23] <zyga> ah, I see, thank you
[13:23] <sergiusens> dholbach we need a secretary
[13:23] <sergiusens> :-P
[13:23] <sergiusens> dholbach if you cannot I guess we have no choice, right? :-)
[13:24] <dholbach> sergiusens, theoretically it should just be a matter of setting up a hangout-on-air in your canonical account (if you have more than 10 participants) and adding the youtube link to summit
[13:24] <dholbach> sergiusens, if all else fails, I'd need to follow up with the CC on the CoC over email later on
[13:25] <jdstrand> zyga: ok, so if we have crashes then we should remove the explicit deny. I'll update the bug and assign to me.
[13:25] <zyga> jdstrand: thank you
[13:25] <zyga> jdstrand: if it is on the snappy side I can quickly remove that denial
[13:25] <zyga> jdstrand: I didn't look yet
[13:27] <jdstrand> zyga: I'd prefer the PR came from me (it is on the snappy side) since I want to update the comment, reference a bug, etc. I have a couple other things I want to adjust in the policy too. I can get to it today
[13:28] <zyga> sure, thank you :)
[13:28] <jdstrand> np
[13:30]  * zyga goes to send the fix to SDL upstream
[13:36] <dholbach> sergiusens, kyrofa, hum... same for the "snapcraft roadmap" session :-/
[13:38] <kyrofa> dholbach, understood. sergiusens do you have experience setting up the hangout-on-air?
[13:39] <kyrofa> dholbach, does that require a G+ account associated with the Canonical email?
[13:39] <sborovkov> zyga: Hello, did you succeed yesterday with your solution for shared memory?
[13:39] <dholbach> kyrofa, it can be your personal account as well if you don't plan to have more than 10 attendees
[13:40] <zyga> sborovkov: yes but it is so hacky that we'll work on a better solution that doesn't require code modification
[13:40] <zyga> sborovkov: as right now the "solution" requires snappy changes, ubuntu-core-launcher changes and a small helper library (I've published it at. ... )
[13:40] <zyga> sborovkov: I'll open a bug and collect all the details there
[13:41] <sborovkov> zyga: Oh. That's a lot of things. Is the proper solution going to be any time soon?
[13:41] <zyga> sborovkov: https://github.com/zyga/snappy-runtime-helper (though it's not useful really)
[13:41] <zyga> sborovkov: at around sru-2
[13:41] <zyga> sborovkov: ~2 weeks
[13:41] <zyga> +/- a week
[13:41] <sborovkov> zyga: got it
[13:41] <dholbach> kyrofa, looking for the link to the docs right now
[13:41] <zyga> sborovkov: I hope to have it merged before
[13:41] <zyga> sborovkov: this is the release time
[13:42] <dholbach> kyrofa, sergiusens: https://wiki.ubuntu.com/UDS/Sessions :)
[13:42] <zyga> sborovkov: you can look at what my hack does above
[13:42] <kyrofa> dholbach, alright I can do it in that case (I already had a personal G+ before Canonical, and google doesn't let you merge them or anything)
[13:42] <zyga> sborovkov: but you will still need to change ubuntu-core-launcher to mkdir a directory for you
[13:42] <zyga> sborovkov: so that's a bit not optimal
[13:43] <sborovkov> zyga: understood
[13:43] <dholbach> kyrofa, sergiusens: you might have to change to the classic interface of Google+
[13:44] <dholbach> kyrofa, sergiusens: thanks guys - I'm sorry, but I just got dragged into the other meetings
[13:44] <kyrofa> dholbach, hey, you're an important guy!
[13:45] <dholbach> kyrofa, you too! :-)
[13:45] <sborovkov> zyga: can you post me the issue url when you create it, so I can keep track of this
[13:45] <kyrofa> dholbach, and no problem :)
[13:45] <zyga> sborovkov: gladly, I was actually getting started on this
[13:46] <sborovkov> thanks
[13:47] <kyrofa> dholbach, should I just give you the URL so you can update summit, then?
[13:48] <dholbach> kyrofa, you should be able to put it into "edit hangout details" on the session page in summit
[13:48] <dholbach> but I can do it for you too
[13:48] <dholbach> what's the link?
[13:48] <kyrofa> dholbach, all I see is "skip this session," so I must not have that capability
[13:48] <kyrofa> dholbach, can you give it to me?
[13:49] <dholbach> oh ok
[13:49] <dholbach> I set your attendance to required and thought that would do it
[13:49] <dholbach> just give me the link and I'll add it for you
[13:49] <dholbach> not sure what the issue is :-/
[13:50] <jdstrand> zyga: did you do the snappy side of SNAP_REVISION for shm? I'm in that file now and can do it as part of my PR if you haven't
[13:50] <zyga> jdstrand: one sec
[13:50] <zyga> jdstrand: I'm filing the bug now
[13:51] <zyga> jdstrand: we need to fix it buy you can reference a (good) bug :)
[13:52] <zyga> jdstrand, sborovkov: https://bugs.launchpad.net/snappy/+bug/1578217
[13:52] <dholbach> kyrofa, do you have the youtube link?
[13:52] <kyrofa> dholbach, event page: https://plus.google.com/events/cosa4a1b1rr2vv0kfiei60jq424
[13:52] <jdstrand> zyga: ok, I'll do the policy part of that
[13:52] <kyrofa> Oh youtube: http://youtu.be/ME_pLU9GMfo
[13:53] <zyga> jdstrand: great, thank you
[13:53] <dholbach> kyrofa, http://summit.ubuntu.com/uos-1605/meeting/22683/the-snapcraft-roadmap/ is updated O:-)
[13:53]  * zyga does a strong coffee in anticipation of UOS
[13:53] <dholbach> kyrofa, teamwork ⁵
[13:53] <kyrofa> dholbach, thank you! I'll ping you again for the next one :)
[13:53] <zyga> jdstrand: we should think about support for refreshing rules across sru updates
[13:53]  * dholbach hugs kyrofa :-)
[13:53] <dholbach> thanks!
[13:53] <zyga> jdstrand: my code that originally did this was rejected and we need a nice and elegant solution
[13:54] <zyga> jdstrand: (for stuff that changes in template.go)
[13:54] <jdstrand> yes
[13:54]  * kyrofa hugs dholbach back :)
[13:54] <sergiusens> kyrofa you got it, right? sorry was distracted!
[13:54] <kyrofa> sergiusens, no problem, yeah all set
[13:59] <sergiusens> kyrofa sort of
[13:59] <sergiusens> kyrofa forgot to check my hair
[13:59] <sergiusens> kyrofa where is the link to join?
[14:00] <kyrofa> sergiusens, hahaha, I just did the same
[14:02] <elopio> good morning.
[14:04] <jdstrand> zyga: well, that shm bug is asking for more than what I thought it was. I was just going to chop off SNAP_REVISION
[14:04] <jdstrand> zyga: please see my comment
[14:05] <zyga> checking
[14:05] <jdstrand> I imagine that pulseaudio will create the files underneath the bind mount and the client would never see them
[14:05] <zyga> jdstrand: hmm, you are right
[14:06] <jdstrand> zyga: we could instead allow creating files in the directory under an app-specific name
[14:06] <zyga> jdstrand: I'll test this with near-real changes, what I did was to mkdir the missing directories manually and to *not* adjust the policy but to use my hacky preload library (linked from the bug)
[14:07] <jdstrand> eg, /dev/shm/<snapname>.*
[14:07] <zyga> jdstrand: I'm not sure if it is the pulse client or server making those files in /dev/shm (in general) though, if it is the client and it shares the path via X11 ipc then we're in trouble
[14:07] <jdstrand> I have no idea
[14:07] <zyga> but without the bind mount it would mean that we need something like my preload helper to make this work which seems wrong
[14:08] <zyga> but I'll develop this further before we commit
[14:08] <jdstrand> I think we are introuble either way
[14:08] <zyga> yes, I fear you might be right
[14:08] <jdstrand> cause if the server creates it, it is under the mount and if the client creates it, it is in /dev/shm/snap/... (and the server won't know about it)
[14:09] <jdstrand> zyga: did you see my comment? we could allow app-specific names in the top level
[14:09] <zyga> jdstrand: we could ask someone that knows pulseaudio (or check ourselves); the problem is that we should not make this pulse specific :/
[14:09] <zyga> app-specific names won't work, many apps use a random ID
[14:09] <jdstrand> zyga: no, pulseaudio is but one example I know of
[14:10] <jdstrand> zyga: this is getting into an area where apps are going to need to work with the system. ie, they can't read arbitrary stuff our of /etc either
[14:10] <jdstrand> or write all over $HOME
[14:10] <zyga> jdstrand: yes, we should just estimate what is the better approach
[14:10] <zyga> jdstrand: let me do some more experiments
[14:10] <zyga> jdstrand: I'll check iff the bind mount would work
[14:10] <jdstrand> traditional apps are always going to butt up against the sandbox in some ways
[14:11] <zyga> jdstrand: with pulse
[14:11] <zyga> jdstrand: and if the top-level one would work as you suggested
[14:11] <jdstrand> ok
[14:11] <zyga> jdstrand: thanks for the insight, I totally didn't think about this
[14:11] <jdstrand> zyga: note the top-level one is obviously so we don't use a bind mount
[14:11] <zyga> right
[14:11] <jdstrand> ok, I'll leave this bit alone for now
[14:11] <zyga> sborovkov: what was the app you were interested in? webkit?
[14:12] <sborovkov> zyga: yes
[14:12] <zyga> sborovkov: thanks
[14:12] <jdstrand> chromium also suffers from this
[14:14] <jdstrand> zyga: note, on touch we allowed .org.chromium.Chromium.*. we could do the same for webkit and then also allow /dev/shm/snap.$SNAP.*
[14:15] <zyga> do you know if chromium was patched?
[14:15] <jdstrand> zyga: as a stop-gap until we get fuller apparmor mediation of shm
[14:15] <zyga> if it was then we can allow anything sane, if it *wasn't* patched then I'm interested in the technical bits that made it work
[14:15] <jdstrand> zyga: on Touch we provide oxide. our oxide was not patched to an app-specific patch (though it could/should have been)
[14:16] <jdstrand> zyga: the technical bits was that we allowed the path it (ie upstream) wanted
[14:16] <zyga> mmm
[14:16] <jdstrand> ie, we punted on Touch until we had fuller apparmor mediation of shm
[14:16] <zyga> I see
[14:16] <zyga> OK
[14:17] <jdstrand> so we have a choice to do the same here or to force devs to adjust their apps
[14:17] <jdstrand> assuming your bind mount investigation doesn't pan out
[14:17] <zyga> btw, the pulse exercise, I suspect that the snapped pulseaudio and deb-based pulseaudio would work makes the exercise more interesting
[14:17] <zyga> right?
[14:18] <jdstrand> snapped pulseaudio could not work I don't think cause its files would be in its snap-specific area that is not shared by the client's snap-specific area
[14:18] <jdstrand> unless we did some brittle heroics
[14:19] <jdstrand> I can't quite see how those heroics would work
[14:20] <ssweeny> is there a way to stop/start/restart a service within a snap?
[14:21] <sborovkov> ssweeny: systemctl?
[14:21] <jdstrand> maybe if there was a 'pulseaudio' dir in /dev/shm, then pulseaudio has a bind mount for it, so its writes to /dev/shm/pulseaudio... but that is really /dev/shm/pulasudio/pulseaudio.... then all the apps bind mount with passthrough /dev/shm/pulseaudio/... I'm not sure. this is getting weird
[14:21] <jdstrand> sborovkov: that won't work. apps can't use systemctl
[14:22] <jdstrand> ssweeny: you are free to stop and start daemons within your snap via signals, scripts, etc, but not systemctl
[14:22] <ssweeny> hmm
[14:22] <jdstrand> ssweeny: I suggest writing out a pidfile to $SNAP_DATA and then sending HUP or similar
[14:22] <zyga> ssweeny: proper API for service management is coming in a few weeks
[14:22] <ssweeny> ah, I see
[14:22] <zyga> ssweeny: we removed the older API because it had the wrong abstractions
[14:23] <zyga> ssweeny: more news after the sprint next week
[14:23] <jdstrand> zyga: are you talking about the snapd API for 'snappy service' that was removed?
[14:23] <zyga> yes
[14:23] <ssweeny> jdstrand, zyga, ok I can work around until the API is updated
[14:23] <ssweeny> thanks!
[14:23] <jdstrand> zyga: note, 'snappy service' couldn't be used by snaps to manipulate there snaps either
[14:23] <zyga> jdstrand: that's true, unless they had snapd-control
[14:24] <jdstrand> I can see that a properly designed API could be used
[14:24] <jdstrand> but snapd-control gives away way too much currently
[14:25] <ssweeny> my use case is that I have a runtime test fixture that stops the currently-running service and starts its own copy then when the test finishes it restarts the installed service
[14:25] <jdstrand> snapd could be designed to allow safe APIs though
[14:25] <zyga> jdstrand: yes, that's a good point
[14:25] <ssweeny> it'd be useful to expose that in a snap for developers but not critical
[14:25] <zyga> jdstrand: could use the peer info to allow self-managemnet
[14:25] <jdstrand> yes
[14:26] <jdstrand> but probably would need a safe socket and an unsafe socket and then have two different interfaces, one that anyone can use and one not
[14:43] <davidcalle> jamiebennett: thanks for the reports on the snapcraft doc, will be imported asap
[14:43] <jamiebennett> davidcalle, thanks. Not sure how much has already been fixed with didrocks update so will stop filing bugs until the new pages are live
[14:44] <davidcalle> dholbach: ^
[14:45] <davidcalle> dholbach: I'll do it after the scopes UOS session
[14:45] <dholbach> jamiebennett, which update? or which pages was this about?
[14:45] <davidcalle> dholbach: snapcraft intro tutorial
[14:45] <dholbach> ah ok
[14:46] <dholbach> davidcalle, I'm happy to help - just let me know
[14:46] <davidcalle> dholbach: thanks, no worries
[14:47] <qengho> Is that "ubuntu-device-flash" that ogra_ or mvo use to make images any different than the one in the repo? Obvious answer is yes, but not sure why.
[14:47] <ogra_> It moved forward since relase
[14:48] <jamiebennett> dholbach, talking to didrocks he has already made some changes to the documentation, pending review and upload by the community team. Do you have these changes?
[14:48] <qengho> ogra_: And that's not in yakkety or a PPA?
[14:48] <ogra_> nope
[14:48] <zyga> qengho: it is also a fork with different features
[14:48] <qengho> Where's the source?
[14:49] <zyga> qengho: we hope to merge it during the y cycle
[14:49] <dholbach> jamiebennett, no - did they land in snapcraft trunk or is this another page which just lives in the CMS?
[14:49] <zyga> qengho: probably in mvo's fork
[14:49] <ogra_> will be SRUed to xenial once the gadget and kernel formats are final
[14:49] <zyga> (branch on LP)
[14:49] <qengho> Suppose I want a binary for armhf. What branch?
[14:49] <jamiebennett> didrocks, ^^^ who has your doc changes?
[14:50] <jamiebennett> didrocks, Or did I misunderstand?
[14:50] <zyga> I don't really know
[14:50] <mvo> qengho: lp:~snappy-dev/goget-ubuntu-touch/all-snaps
[14:50] <mvo> qengho: let me know, if its too tricky to build I can do an arm version
[14:51] <dholbach> jamiebennett, a couple of things changed in snapcraft and snappy and we're going to pull in these changes, no problem
[14:51] <qengho> mvo: thanks.
[14:52] <dholbach> jamiebennett, but if there's anything else we can help with, we're happy to help obviously
[14:53] <jamiebennett> dholbach, Thanks. The docs in github are easier to change, the CMS changes we will need your help with.
[14:53] <dholbach> jamiebennett, some of the snappy/snapcraft people already have access to it, but sure, happy to help :)
[14:53] <jamiebennett> dholbach, Ah, OK
[14:56] <noizer> zyga debootstrap installed
[14:56] <sergiusens> jamiebennett can I get removed from owning doc changes? didrocks and asac have the same item; I am glad to help or even draft it though
[14:57] <noizer> zyga it was proc and sys that i needed to mount?
[14:57] <zyga> yes
[14:57] <zyga> mount --bind /proc /path/to/armel/proc
[14:57] <jamiebennett> sergiusens, sure, we can move that to didrocks with asac and you contributing
[14:57] <noizer> zyga same thing for sys?
[14:58]  * zyga -> session
[14:58] <zyga> yes
[14:58] <noizer> Ok xD
[14:58] <noizer> brb
[15:03] <didrocks> jamiebennett: dholbach: we were talking about the get starting
[15:03] <didrocks> not the upstream doc itself
[15:03] <didrocks> getting started*
[15:05] <dholbach> ah cool
[15:05] <dholbach> let's chat about this later on
[15:05] <jamiebennett> OK
[15:05] <dholbach> or... we're in the snappy docs: next steps session right now
[15:06] <dholbach> http://summit.ubuntu.com/uos-1605/meeting/22673/snappy-docs-next-steps/ (or ping us for joining the hangout)
[15:08] <didrocks> dholbach: in meetings right now though :(
[15:08]  * dholbach hugs didrocks 
[15:09] <dholbach> didrocks, let's chat after UOS then :)
[15:09]  * didrocks hugs dholbach
[15:09] <didrocks> yeah
[15:09] <dholbach> great - it's been a while :)
[15:14] <dduffey> lool, trying to build your quagga snap, looks like the custom plugin is not executing from the src directory ... I suspect an environmental variable change potentially?
[15:20] <lool> dduffey: I'm trying to build an upstream snap right now
[15:20] <lool> dduffey: (I had most of the reply written down, but wanted to go back with the start of an upstream snap)
[15:20] <dduffey> lool, sweet
[15:21] <lool> dduffey: not sure which custom plugin you mean?
[15:21] <dduffey> lool there were a few other things (patch failure, some yaml changes, etc.) ... but got stuck on when it runs the quagga build
[15:22] <dduffey> x-custom in:
[15:22] <dduffey> http://bazaar.launchpad.net/~lool/+junk/quagga-snap/view/head:/snapcraft.yaml
[15:22] <dduffey> when it runs dpkg-buildpackage, it looks like it is not running it from parts/quagga/src
[15:22] <dduffey> and I'm doing this from 16.04
[15:24] <lool> dduffey: Oh right, I think I was unpacking the package myself into the source tree; didn't want to check this in though
[15:26] <dduffey> lool I see that in the README, so I think I did the same ... i.e. parts/quagga/src has content (including debian/changelog), but the build fails saying it cannot find debian/changelog
[15:28] <lool> dduffey: afraid it escapes my mind; would you mind switching to the upstream snap instead?
[15:28] <dduffey> lool, yeah, where is it?
[15:29] <lool> dduffey: WIP  :-)
[15:29] <lool> I've started it with this email, almost have something building
[15:29] <dduffey> lool, ah, okay, I'll back off then :)
[15:31] <ysionneau> hmm which ubuntu package contains the "snappy" tool?
[15:31] <ysionneau> (to do "snappy build" to builda gadget snap)
[15:36] <sergiusens> ysionneau snapcraft build <dir>
[15:46] <ysionneau> sergiusens: if my gadget snap only has meta/snap.yaml, I can do snapcraft snap . ?
[15:46] <ysionneau> it seems to work and produces a squashfs
[15:48] <sergiusens> ysionneau correct; all gadgets can be built with snapcraft now
[15:49] <ysionneau> cool
[15:50] <ysionneau> for the kernel snap, it seems the 'kernel-device-tree', 'kernel-image-path' are not accepted anymore :o
[15:50] <ysionneau> correct ?
[15:52] <dholbach> kyrofa, let me know if you want me to add the youtube link for you :-)
[15:52] <sergiusens> ysionneau kernel-image-path is implied from target
[15:52] <sergiusens> ysionneau so yeah, that is gone
[15:53] <sergiusens> ysionneau the kernel-device-tree is missing an s
[15:53] <kyrofa> dholbach, yes please: https://plus.google.com/events/ck0qgm3n2q9tg977qlafvs217vo and http://youtu.be/qvlJlgVMML4
[15:53] <sergiusens> ysionneau `snapcraft help kernel` should be correct
[15:53] <dholbach> kyrofa, updated! :-)
[15:53] <dholbach> thanks!
[16:05] <jdstrand> zyga, niemeyer: fyi, bug #1578287
[16:06] <zyga> jdstrand: ack, I'll read it after the session
[16:08] <lool> dduffey: https://github.com/lool/quagga-snap
[16:09] <lool> dduffey: it's cargo-culted from the other one and was only build tested
[16:11] <ysionneau> sergiusens: ah thanks for the help !
[16:11] <ysionneau> (indeed trees is more correct)
[16:21] <niemeyer> jdstrand: Commented on the issue
[16:21] <niemeyer> zyga: ^
[16:24] <jdstrand> niemeyer: thanks
[16:24] <jdstrand> fwiw, I agree that snap interfaces slots then plugs order should not change
[16:28]  * zyga nods
[16:28] <zyga> I was thinking about it as well
[16:29] <zyga> I'd like to let people make it work in any order but fist ensure that we validate plug/slot uniqueness correctly
[16:29] <zyga> I also wonder how thish should look like on the REST API
[16:29] <zyga> I'd rather have the rest API precise unless we pass a flag that says otherwise
[16:29] <zyga> but perhaps that's not required
[16:29] <zyga> just worth thinking about the api apart from the UX
[17:30] <sergiusens> elopio is the testing infra broken?
[17:33] <zyga> sergiusens: some stuff were broken in the morning
[17:33] <zyga> sergiusens: both on IP connectivity and on what the stuff actually did
[17:38] <sergiusens> zyga ah, it failed immediately so that might be it
[18:55] <example6> Hi guys. Still struggling with this one problem of getting my snap to run automatically after install / reboot. Is there anything I should be putting in my Makefile to make this happen?
[18:56] <example6> in my apps: in snapcraft.yaml I just have one app that runs my wrapper as a daemon
[18:56] <example6> but it doesn't seem like the wrapper is being run at all
[19:10] <dpm> dholbach, so tomorrow I'll be back home for the snaps on desktop demo, so I should be able to run my main desktop and not have to worry about x86
[19:10] <dholbach> cool
[19:10] <dholbach> let's chat beforehand
[19:11] <dpm> sounds like a plan
[19:16] <zyga> example6: you want to use daemon: ... entry
[19:16] <zyga> example6: look at snapcraft examples
[19:16] <zyga> example6: there are existing things doing that
[19:32] <example6> zyga: that's what I did. I have daemon: simple along with my command: in my basic app. I can't seem to find any log of it failing however
[19:32] <example6> the command: just runs the wrapper script
[19:32] <zyga> example6: check if the systemd unit was generated in /etc/systemd/system/
[19:33] <zyga> example6: use systemctl to see if it was started
[19:33] <zyga> example6: use journalctl to see the logs
[19:33] <zyga> example6: try to install a snapcraft example and see it run
[19:33] <zyga> example6: and then iterate on it to look more like your snap
[19:33] <example6> alright, thank you zyga
[19:34] <zyga> example6: in the end it might fail because of confinement, try installing the snap with --devmode
[19:34] <example6> Good to know, thank you
[19:58]  * zyga -> EOD
[20:06] <blackout24> Hi, is there something like a sources.list file for snappy? How does it select the channel and the server to find the snaps from the store?
[20:06] <blackout24> Or is all of that hardcoded into the snap binary?
[20:22] <kgunn> blackout24: try snap --help
[20:23] <kgunn> snap list will show you what snaps are on the device
[20:23] <kgunn> unfortunately, as least that i know, no good way to see what's in the snap
[20:24] <kgunn> snap find will list the entire store if given on arg
[20:25] <kgunn> and for install, you can give a channel, but if you don't it'll use the device default (however the image is stitched i suppose)
[20:26] <blackout24> Ahh you misundertood me. I  mean if there is some file that specifies the server where snaps are fetched from.
[20:28] <pedronis> blackout24: the channel is selected per snap when one installs/refreshes (--channel argument)
[20:33] <pedronis> blackout24: there is nothing like sources.list, there will be ways to do offline installs but still secured by assertions etc, that's an area that will evolve over time
[20:33] <blackout24> thanks