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