| 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:07 |
| josharenson | ^^ that actually worked pretty well | 00:08 |
| qengho | josharenson: Are you distributing some python, or something made with python? | 00:10 |
| josharenson | qengho: something made with python | 00:12 |
| qengho | I'd "build-packages" python, instead of "plugin: python". I think so. Not sure. | 00:12 |
| 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:13 |
| josharenson | qengho: yeah, thanks | 00:14 |
| qengho | You probably get a smaller package than with plugin-python. | 00:14 |
| ZenHarbinger | BTW, I did update the answer on askubuntu. that is all. 'nite! | 00:21 |
| sergiusens | elopio the last one https://github.com/ubuntu-core/snapcraft/pull/499 | 01:46 |
| * sergiusens goes to bed | 01:46 | |
| elopio | good night. | 01:48 |
| swami | hi | 01:54 |
| swami | can someone help answer this question, posted in the dev mailing list? https://lists.ubuntu.com/archives/snappy-devel/2016-May/001802.html | 01:56 |
| === chihchun_afk is now known as chihchun | ||
| === Aria22 is now known as Aria22|away | ||
| === chihchun is now known as chihchun_afk | ||
| 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 | 04:31 |
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 07:25 |
| slvn | hello! | 07:33 |
| slvn | no bug report for today :) | 07:34 |
| 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:35 |
| zyga | slvn: you should go with 16 | 07:36 |
| zyga | slvn: that's "stable", that s what people will get | 07:36 |
| slvn | zyga, ok, it makes sense, that's what I chose | 07:37 |
| slvn | zyga, btw, I published a basic snap app, using SDL2, with SDL2 log debug enabled. may be useful for testing... | 07:39 |
| 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:40 |
| slvn | (it's more like a testing sample for me, than a real app) | 07:41 |
| 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:44 |
| noizer | they told me to look in the /lib dir | 07:45 |
| noizer | and there you can see arm-linux-gnueabihf | 07:45 |
| noizer | zyga or is there a way too see it better? | 07:46 |
| zyga | no, you seem to be right, one set | 07:48 |
| 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:49 |
| zyga | noizer: trying now | 07:55 |
| noizer | zyga Ok :p | 07:55 |
| zyga | geez pi1 is slow like hell | 08:03 |
| zyga | it's happening, just ... ... ... slowly | 08:03 |
| noizer | zyga I know thats not realy fun | 08:07 |
| zyga | (in other news debootstrap is written in perl, perl is slow) | 08:08 |
| 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:14 |
| zyga | as long as you are in the armel chroot, yes | 08:18 |
| noizer | awesome :D | 08:20 |
| noizer | then it will be faster to compile on the armel chroot :D | 08:21 |
| 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:28 |
| noizer | debootstrap command not found :s | 08:29 |
| === davmor2_ is now known as davmor2 | ||
| noizer | zyga how long does it take for debootstrap? | 08:40 |
| 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:43 |
| 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 | 08:44 |
| noizer | zyga and still busy with you? | 09:37 |
| mvo | ogra_: hm, what is up with livecd-rootfs in ppa:snappy-dev/image - can those changes get merged to trunk? | 09:59 |
| ogra_ | mvo, sure ... thats effectively only the addition of uboot-tools to all arches (everything else was reverted again ... | 10:00 |
| 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:01 |
| ogra_ | mvo, well, we dont use trunk in xenial ... | 10:02 |
| === Aria22|away is now known as Aria | ||
| ogra_ | (and i have set yakkety builds to manual, dailies come from xenial currently) | 10:03 |
| ogra_ | (for cdimage that is) | 10:03 |
| 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:06 |
| ogra_ | xenial images use the xenial livecd-rootfs ... we'd have to SRU the changes like with any other package | 10:07 |
| ogra_ | thats what i mean ... | 10:08 |
| mvo | ogra_: *cough* | 10:09 |
| ogra_ | *grin* | 10:09 |
| === Aria is now known as Aria|away | ||
| noizer | zyga: its done ove rhere | 11:09 |
| zyga | noizer: cool, chroot away | 11:09 |
| === chihchun is now known as chihchun_afk | ||
| noizer | zyga ps how can i see its succesfully done? | 11:09 |
| zyga | noizer: if id crashed you'd know | 11:10 |
| noizer | because i got some warnings | 11:10 |
| zyga | like? | 11:10 |
| noizer | W:Failure while installing base packages | 11:12 |
| noizer | ... | 11:12 |
| zyga | anything more? | 11:13 |
| noizer | wait I will send you a picture | 11:13 |
| 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:14 |
| 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:15 |
| * 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:16 |
| 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:17 | |
| zyga | brb | 11:18 |
| ogra_ | wait, are you trying to bootstrap armel on an armhf machine ? | 11:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| zyga | yep | 11:23 |
| zyga | sudo raspi-config | 11:23 |
| zyga | pick the expand filesystem option from the menu | 11:23 |
| noizer | debootstrap is started again | 11:28 |
| === Aria|away is now known as Aria | ||
| kyrofa | Good morning | 12:03 |
| sergiusens | good morning everyone! | 12:03 |
| sergiusens | mvo so follow up from my apt issues, this fixes it https://github.com/ubuntu-core/snapcraft/pull/499 | 12:04 |
| === chihchun_afk is now known as chihchun | ||
| zyga | jdstrand: hey | 12:25 |
| 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:30 |
| zyga | noise][: bind mount /proc and /sys into the chroot, chroot inside, try to build your app | 12:31 |
| noizer | zyga chroot /path/to/dir | 12:32 |
| noizer | is it that you mean | 12:33 |
| noizer | of coure after bind mount ... | 12:33 |
| sergiusens | kyrofa maybe 45? | 12:33 |
| kyrofa | sergiusens, sounds good | 12:34 |
| zyga | noise][: chroot armel; if you followed the command I used earlire | 12:34 |
| noizer | Ok | 12:35 |
| 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:36 |
| noizer | ogra_: hahahah xD sorry resolving :p:p | 12:37 |
| ogra_ | :) | 12:37 |
| zyga | that reolves the situation | 12:38 |
| noizer | how is the ubuntu summit? | 12:38 |
| zyga | good | 12:38 |
| 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 | 12:39 |
| jdstrand | zyga: hi! :) | 13:13 |
| zyga | hey, good morning :) | 13:13 |
| jdstrand | good afternoon :) | 13:13 |
| zyga | jdstrand: I have an intereting bug, I have no idea what the cause is: https://bugs.launchpad.net/snappy/+bug/1578091 | 13:14 |
| ubottu | Launchpad bug 1578091 in Snappy "Unable to read /proc/$$/cmdline, even with devmode" [Undecided,New] | 13:14 |
| zyga | jdstrand: this breaks sdl (which I already fixed) but I wonder why this happens | 13:14 |
| 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:15 |
| 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:16 |
| jdstrand | ok, we have an explicit denial for that | 13:17 |
| jdstrand | deny @{PROC}/@{pid}/cmdline | 13:17 |
| 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:18 |
| jdstrand | zyga: does the app work ok without it? | 13:19 |
| * jdstrand would think it is a bug in complain mode that it is enforcing an explicit deny | 13:20 | |
| 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:21 |
| jjohansen | zyga: because complain mode only applies to denials that are caused by missing rules, not for rules that already exist | 13:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:27 |
| zyga | sure, thank you :) | 13:28 |
| jdstrand | np | 13:28 |
| * zyga goes to send the fix to SDL upstream | 13:30 | |
| dholbach | sergiusens, kyrofa, hum... same for the "snapcraft roadmap" session :-/ | 13:36 |
| kyrofa | dholbach, understood. sergiusens do you have experience setting up the hangout-on-air? | 13:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| sborovkov | zyga: understood | 13:43 |
| dholbach | kyrofa, sergiusens: you might have to change to the classic interface of Google+ | 13:43 |
| 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:44 |
| 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:45 |
| sborovkov | thanks | 13:46 |
| kyrofa | dholbach, should I just give you the URL so you can update summit, then? | 13:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| zyga | jdstrand: we need to fix it buy you can reference a (good) bug :) | 13:51 |
| zyga | jdstrand, sborovkov: https://bugs.launchpad.net/snappy/+bug/1578217 | 13:52 |
| ubottu | Launchpad bug 1578217 in Snappy "No way to use shm_open(3)" [Undecided,New] | 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:52 |
| 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:53 |
| 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:54 |
| sergiusens | kyrofa sort of | 13:59 |
| sergiusens | kyrofa forgot to check my hair | 13:59 |
| sergiusens | kyrofa where is the link to join? | 13:59 |
| kyrofa | sergiusens, hahaha, I just did the same | 14:00 |
| elopio | good morning. | 14:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| sborovkov | zyga: yes | 14:12 |
| zyga | sborovkov: thanks | 14:12 |
| jdstrand | chromium also suffers from this | 14:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| jdstrand | I can't quite see how those heroics would work | 14:19 |
| ssweeny | is there a way to stop/start/restart a service within a snap? | 14:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:43 |
| davidcalle | dholbach: ^ | 14:44 |
| 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:45 |
| dholbach | davidcalle, I'm happy to help - just let me know | 14:46 |
| davidcalle | dholbach: thanks, no worries | 14:46 |
| 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:47 |
| 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:48 |
| 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 |
| === manik_ is now known as manik | ||
| 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:49 |
| 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:50 |
| 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:51 |
| dholbach | jamiebennett, but if there's anything else we can help with, we're happy to help obviously | 14:52 |
| 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:53 |
| 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:56 |
| 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:57 |
| * zyga -> session | 14:58 | |
| zyga | yes | 14:58 |
| noizer | Ok xD | 14:58 |
| noizer | brb | 14:58 |
| didrocks | jamiebennett: dholbach: we were talking about the get starting | 15:03 |
| didrocks | not the upstream doc itself | 15:03 |
| didrocks | getting started* | 15:03 |
| 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:05 |
| dholbach | http://summit.ubuntu.com/uos-1605/meeting/22673/snappy-docs-next-steps/ (or ping us for joining the hangout) | 15:06 |
| didrocks | dholbach: in meetings right now though :( | 15:08 |
| * dholbach hugs didrocks | 15:08 | |
| 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:09 |
| 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:14 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:26 |
| 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:28 |
| 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:29 |
| ysionneau | hmm which ubuntu package contains the "snappy" tool? | 15:31 |
| ysionneau | (to do "snappy build" to builda gadget snap) | 15:31 |
| sergiusens | ysionneau snapcraft build <dir> | 15:36 |
| 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:46 |
| sergiusens | ysionneau correct; all gadgets can be built with snapcraft now | 15:48 |
| ysionneau | cool | 15:49 |
| ysionneau | for the kernel snap, it seems the 'kernel-device-tree', 'kernel-image-path' are not accepted anymore :o | 15:50 |
| ysionneau | correct ? | 15:50 |
| 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:52 |
| 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! | 15:53 |
| jdstrand | zyga, niemeyer: fyi, bug #1578287 | 16:05 |
| ubottu | bug 1578287 in Snappy "inconsistency between 'snap interfaces' and 'snap connect/disconnect'" [Undecided,New] https://launchpad.net/bugs/1578287 | 16:05 |
| zyga | jdstrand: ack, I'll read it after the session | 16:06 |
| lool | dduffey: https://github.com/lool/quagga-snap | 16:08 |
| lool | dduffey: it's cargo-culted from the other one and was only build tested | 16:09 |
| ysionneau | sergiusens: ah thanks for the help ! | 16:11 |
| ysionneau | (indeed trees is more correct) | 16:11 |
| niemeyer | jdstrand: Commented on the issue | 16:21 |
| niemeyer | zyga: ^ | 16:21 |
| jdstrand | niemeyer: thanks | 16:24 |
| jdstrand | fwiw, I agree that snap interfaces slots then plugs order should not change | 16:24 |
| === charles_ is now known as charles | ||
| * zyga nods | 16:28 | |
| zyga | I was thinking about it as well | 16:28 |
| 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 | 16:29 |
| sergiusens | elopio is the testing infra broken? | 17:30 |
| 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:33 |
| sergiusens | zyga ah, it failed immediately so that might be it | 17:38 |
| 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:55 |
| 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 | 18:56 |
| 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:10 |
| dpm | sounds like a plan | 19:11 |
| 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:16 |
| 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:32 |
| 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:33 |
| 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:34 |
| * zyga -> EOD | 19:58 | |
| 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:06 |
| kgunn | blackout24: try snap --help | 20:22 |
| 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:23 |
| kgunn | snap find will list the entire store if given on arg | 20:24 |
| 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:25 |
| blackout24 | Ahh you misundertood me. I mean if there is some file that specifies the server where snaps are fetched from. | 20:26 |
| pedronis | blackout24: the channel is selected per snap when one installs/refreshes (--channel argument) | 20:28 |
| 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 | 20:33 |
| === chihchun_afk is now known as chihchun | ||
| === evanmeag_ is now known as evanmeagher | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!