=== ubott2 is now known as ubottu === chihchun_afk is now known as chihchun === zyga-afk is now known as zyga [07:02] good morning [07:21] good morning [09:19] o/ ! [09:20] good morning snappy'ers! [09:20] hey [09:20] question - do all installed snapps get passed all configs to the config hook? [09:20] longsleep: hi! how's things [09:21] trying to understand snappy config :) [09:21] longsleep: "all configs", as in configs for all apps? [09:21] err yes [09:21] longsleep: err no :) [09:21] there was an example somewhere [09:21] so how does webdm know the ports of all the apps? [09:21] snaps [09:22] longsleep: webdm cheats (it has a handcrafted security policy) [09:22] longsleep: it can call "snappy config" for every app [09:22] ah ok [09:22] longsleep: and that would print out the config [09:22] it doesn't *actually* exec out snappy config [09:22] it links against snappy-the-library [09:23] got it - so then the problem is how i can share config between multiple snaps? [09:23] tricky [09:24] longsleep: can you explain a little of why you need it? [09:24] well i for example i have to share secrets between snaps - to make shared secret auth work [09:24] ah [09:25] longsleep: and there isn't a logical "owner" of the secrets? [09:25] and i might have to know what ports another snap is using to connect to the services there [09:25] Chipaca: well i assume someone could be made the logical owner, but how does the information get to the snaps which need it [09:26] i mean i could put it all into a single snap - thats what i would try to avoid though [09:27] longsleep: make the owner a framework, so the others can depend on it, and give it a command that prints out the needed info? [09:27] longsleep: i'm not sure that would work, but i think maybe we should make that work if it doesn't [09:27] :) [09:27] yes i think that would work [09:28] at least for the configuration stuff where each snap is not the logical owner [09:28] ports are a different story [09:28] wrt ports, you need a discovery mechanism, or making them non-negotiable [09:29] i want to make them configurable and negotiable [09:29] the discovery mechanism can be a script as per above, or something like avahi [09:30] you mean a snap could provide a script that prints ot the information other snaps might want? [09:30] can i call stuff provided as binaries of snap-a from snap-b then? [09:31] i should know that, but i'm rusty from my holidays. let me check. [09:31] heh :) these are good suggestions - i will try them for sure [09:32] Chipaca is back \o/ [09:32] for now i just want to make the ports for spreed-webrtc a configuration [09:32] ogra_: allegedly :) [09:32] :) [09:32] we'll see for how long (!) [09:32] hey ! [09:33] ogra_: just before going away i was asked if i was willing and able to work on a zomg urgent thing [09:33] ogra_: as per [09:33] ogra_: so i don't know how it's played out yet :) [09:34] other question - the internal ports in package.yaml, these are the ports supposed to listen on local interface only or what is the meaning of internal in that context? [09:35] eep! snappy update just got 'no space left on device' [09:35] as i understand it it is for "package intercommunication" [09:35] ogra_: thats good then - so i should probably add that as well [09:40] What about the ports in package.yaml if i make those configuration, would webdm know about it? I am still unsure what the ports section in package.yaml actually is doing [09:40] webdm uses the external port for the "open" link in the details page [09:41] yes the one marked external/ui - but what if that is a configuration ? [09:42] i mean i currently ship with port 8000 as webdm does not support https links. But now i want to add configuration so people can choose to expose this on port 80 [09:42] then webdm would have to link there [09:43] and i want to have an option to disable all the external ports and only keep the internal one so a reverse proxy can take it over [10:00] hey! how cron works in Snappy? Tried to add crontab job - everything is read-only :( [10:01] it will use whatever systemd provides as cron replacement ... [10:01] not sure where we stand with that thouh [10:02] ogra_, thanks! [10:02] i think we plan to expose timers [10:02] but haven't done so yet [10:02] timers as in systemd.timer(5) [10:03] Chipaca, but it's not implemented yet? [10:04] ok, got it, thx [10:11] biezpal: ubuntu-core itself installs a timer, if you need an example (it's /lib/systemd/system/snappy-autopilot.timer; when we expose this, yours would be installed to a different directory, but would be the same thing) (it'd be exposed in a way that we generate the timer ourselves, so if for any reason we need to port snappy to a non-systemd system we could still do it) [10:18] Chipaca, thanks a lot [10:26] ah i just found a interesting line in the docs: Some key/value pairs in the configuration are fixed, for example all applications that listen to a port must support the "ports" config option. [10:27] is that the same ports as found in package.yaml? [10:30] I want remove docker, but since some apps are using docker, it will not remove [10:30] (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy remove docker [10:30] Removing docker [10:30] framework still in use by: owncloud === erkules_ is now known as erkules [10:31] Rlyeh: remove the dependencies first [10:32] Rlyeh: sudo snappy remove owncloud docker [10:32] Rlyeh: will work [10:33] I won't remove owncloud [10:33] I don't know owncloud service name to stop [10:33] Rlyeh: sorry, i don't understand [10:33] Rlyeh: why won't you remove owncloud? [10:34] I just want to reinstall docker [10:35] I think it will be remove if I stop owncloud service, right? [10:36] It seems docker doesn't work properly [10:36] Rlyeh: still not understanding, here; sorry :-( [10:36] Rlyeh: you want to reinstall docker because it's not working properly? [10:38] yes [10:38] I updated docker from 1.6.1 to 1.6.2 to day [10:39] After reboot, owncloud was not working [10:39] Rlyeh: and how is it not working properly? [10:39] I checked and port 443 was close [10:40] Rlyeh: and if you roll back docker does owncloud work again? [10:40] Rollbacks the docker, but still docker not working [10:40] hum....... [10:40] dholbach: 'sup? [10:41] I don't know what happened but I have to fix this [10:41] Because of owncloud [10:41] Chipaca, have you seen something like this before? http://pastebin.ubuntu.com/12070190/ [10:41] dholbach: it's a pastebin link. I've seen many of those! [10:41] :-p [10:42] riiiiiiiiiiight [10:42] dholbach, yeah., we require that you run snapcraft on your phone now for building so we check the system-image config :P [10:43] Do you know owncloud service name to stop ? [10:43] Rlyeh, systemctl|grep owncloud [10:43] then just use systemctl stop [10:44] Thank you ogra [10:44] or snappy service owncloud stop [10:44] in new enough snappys [10:44] dholbach, you get that error only by running add-apt-repo ? thats really odd [10:45] ogra_, it is [10:45] dholbach: i hadn't seen it, but it seems you can ignore it [10:45] it's probably aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously [10:45] deffinitely a bug, but seems add-apt-repo is still doing the right thing [10:46] aptsources [10:46] dholbach: so [10:47] dholbach: file a bug against aptsources [10:47] dholbach: then continue with your day :) [10:47] ok cool, will do [10:47] in fact i can probably provide a patch for you to include in your bug [10:48] gimme a sec, then i'll give you a diff, if you could try that it'd be nice [10:50] Chipaca, https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1484470 [10:50] Launchpad bug 1484470 in python-apt (Ubuntu) "aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously" [Undecided,New] [10:50] dholbach: could you try http://pastebin.ubuntu.com/12070228/ ? [10:52] wait, that's wrong [10:52] dholbach: hold it [10:52] dholbach: ETOORUSHED [10:54] dholbach: http://pastebin.ubuntu.com/12070249/ [10:54] Chipaca, fixed [10:55] at least there's no message now [10:55] exactly :) [10:55] judging by "usage: system-image-cli ......." [10:55] it might be that s-i-c is called with the wrong parameters? [10:55] h no [10:55] ah no [10:55] nevermind :) [10:56] dholbach: config not found [10:56] yep [10:57] dholbach: should i make this a merge against python-apt, or just include the diff in the bug and let somebody else handle it? [10:57] that's a question for mvo :) [10:57] making an MP then [10:58] eep [10:58] never change gpg keys the week before your holidays [10:59] oops [11:00] https://code.launchpad.net/~chipaca/python-apt/no-stderr-for-you-mister-system-image-cli/+merge/267935 [11:40] hmm [11:41] was there a way to make ubuntu-core-launcher output verbose in syslog ? [11:41] Aug 13 11:40:24 localhost ubuntu-core-launcher[1761]: execv failed: Permission denied [11:41] not actually helpful ... [11:44] ogra_: you probably got something in syslog about that [11:44] no, thats my issue :) [11:45] nothing beyond that and the .service then tellin me it exited 1 [11:47] ogra_: can you actually exec the thing you're trying to exec? [11:47] hard to tell ... my LD_LIBRARY_PATH is like 1000 pages long :P [11:48] * ogra_ tries to get xfbdev to run on a rpi [11:48] mainly as "lunch exercise" [11:49] ogra_: ahhh [11:50] ogra_: did you check the obvious, ie unix perms for executables and dynamic libraries? [11:50] sure, the tree loosk fine [11:50] so anyome has thoughts if the config hooks port yaml format is the same as of package.yaml - i did it that way now but does it make sense? [11:50] i think it is [11:52] ah! i was going to check that, and got dragged into this python-apt madness [11:52] longsleep: if you install webdm, what does 'snappy config webdm' spit out? [11:52] longsleep: because it's got a port [11:53] that is broken [11:53] i thnk i have added a bug for this already [11:54] Cn [11:55] Chipaca: ah yes https://bugs.launchpad.net/webdm/+bug/1482720 [11:55] Launchpad bug 1482720 in webdm "Webdm config seems to be broken / KeyError on snappy config webdm" [Undecided,New] [11:55] ARGH ! [11:55] WAT [11:55] * ogra_ bangs head against wall [11:55] Chipaca: but from the code at http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/hooks/config it does nothing related to ports [11:55] * Chipaca quickly slips pillow between ogra and wall [11:55] start-service.sh .... not executable ... sigh ... so silly [11:56] ogra_: \o/ [11:56] ogra_: glad i asked the silly question first, then :) [11:56] yeah, thanks ! [11:57] longsleep: can you add a try/except around lines 64 and 65, just to see the output? [11:57] longsleep: i can provide a patch if you don't python [11:58] Chipaca: i have many years python history - going for lunch now but will check in 20 minutes or so thanks! === kickinz1 is now known as kickinz1|lunch [12:02] longsleep: excellent! and buen provecho :) [12:04] I say "buen provecho", and dpm comes in [12:05] i'm not a suspicious person, but ... :-p [12:14] Chipaca: i am back with lunch - config is empty as is expected from reading the hook code (it only exposes avahi-hostname) [12:16] Chipaca: if you are intersted, my hook now returns this yaml: http://paste.ubuntu.com/12070607/ - what do you say? [12:19] longsleep: and assigning them works? [12:19] sergiusens: longsleep is trying to make external ports configurable and negotiable [12:20] Chipaca: well, i am just writing that part but i would not see why not as this is all in my hook and just a matter of my applying them to the service config. [12:22] longsleep: Chipaca we don't have the backend ready for that so doing it through config seems fine [12:22] Chipaca: are you back at work? Or just leasure? [12:25] sergiusens: back at work! [12:25] sergiusens: already having two simultaneous meetings (if you don't count this) [12:39] ogra_, I also can report piglow success using your rpi2 image :) [12:39] yippie ! [12:40] ogra_, but of course, when I package as a snap, I get apparmor denials. Are there any templates or caps I can use that will grant me access? [12:40] (to the i2c device, I mean) [12:41] https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ take a look at the webcam example [12:44] ogra_, ah, perfect, thank you :) [12:46] ogra_, well, not quite. Is making an OEM snap the only way to provision hardware like that? [12:56] kyrofa, where does it say it is an oem snap ? [12:56] should be just a normal snap but you need to manually enable the hw access after install [12:57] ogra_, oh okay. The first bit of the document talks about manually enabling hw access, but then it goes through the process of creating an OEM snap to do it automatically [12:57] ogra_, so there's no way to request hw access from a regular snap? === kickinz1|lunch is now known as kickinz1 [13:08] kyrofa: the manual process is the "trusted helper" or lack thereof ;-) [13:09] sergiusens, ah, okay so that's the vision for how regular old snaps can get hw access? [13:12] kyrofa: depends; on personal I guess it would be through the trusted helper system [13:12] on custom devices, you would build your custom gadget [13:13] sergiusens, gadget being another kind of snap? I've not gotten into that just yet [13:15] kyrofa: it's what is the oem today [13:15] sergiusens, gotcha [13:29] sergiusens, I have a snap for arm that uses the piglow (via i2c). Knowing that it requires i2c support and requires explicit hw access granting, is that something I can submit to the store? [13:30] kyrofa: yes you can [13:31] kyrofa: users of it just need to explicitly allow the crazy things it would do with your hardware [13:32] now it would be really great if webdm would actually show the description for packages ... then youo could even tell the users what they need to do :P [13:40] ogra_, no... that would be too much... [13:40] heh [13:43] ogra_, the description should be in debian/control of the generated snap, right? [13:43] ogra_, ah, nevermind. The manifest [13:57] ogra_: in rolling that should all work; once we have snap uploads per release it can go into 15.04 [14:01] sergiusens, why is only the first two paragraphs of the meta/readme used? Makes it tough to format things decently [14:01] sergiusens, just space concerns? [14:01] kyrofa: don't get me started on how much I dislike that readme.md ;) [14:02] sergiusens, ah, okay. As long as I'm not the only one ;) [14:21] hmm, why can i not set TMPDIR in my service start script ? [14:21] seems to still point to /tmp ... no matter what i do [14:24] ogra_: I thought Chipaca worked on mounting tmp for snaps into a new namespace [14:24] yep [14:25] you get a private tmp [14:25] and you like it [14:25] so you need to define "see" ;-) [14:25] i do, xorg doesnt :P [14:25] ogra_: what's xorg trying to do? [14:25] http://paste.ubuntu.com/12071355/ [14:25] compiling a keymap in /tmp [14:25] trying to set TMPDIR doesnt make it pick up any different dir [14:26] and it also doesnt seem to pick up whatever is set by the launcher [14:26] ogra_: could you list /tmp/ for me please? [14:26] oh, wait ... [14:26] did the tmpdir cange land in 15.04 ? === jkridner|work is now known as jkridner [14:27] ogra_: quisió! but maybe not [14:27] ogra_: but looking at /tmp/ after a run will tell you [14:27] fgimenez: my throat hurst a little. Lets talk here today. [14:28] Chipaca, hmm ... might be helpful if it also cleaned up after itself http://paste.ubuntu.com/12071402/ [14:28] only 500 tmpdirs :P [14:29] elopio, ok take care! [14:29] fgimenez: I agree that parsing the writer output is the most simple thing to do now. [14:30] elopio, ok, the outputWriter type is what we need, but now is difficult to use [14:30] ogra_: that's the private tmp signature there [14:30] ogra_: look inside those, at permissions [14:30] fgimenez: yes, we need help from niemayer there. [14:30] hopefully we haven't broken that (!!) [14:31] Chipaca, but why does itr leave them behind ? [14:31] elopio, hopefully i'll push something today for the parsing approach, it's quite easy given the current output [14:31] (and inside which of them would i look now, so many choices !) [14:32] (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/ [14:32] total 0 [14:32] drwxrwxrwt 3 root root 60 Aug 13 14:04 tmp [14:32] (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/tmp/ [14:32] total 0 [14:32] permissions seem fine [14:32] ogra_: i think the consensus was we wanted to clean them up with something like tmpreaper, not right after things stopped [14:32] hmm, k [14:33] elopio, good news, we have a new docker framework version ready thanks to kickinz1 :) [14:33] elopio, http://10.55.32.19:8080/job/daily-1504/ [14:33] plars: the ppa is updated. Here's the script: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh [14:33] the prob is that if you develop and your service crashes in a loop you might end up with 500 dirs there :) [14:34] fgimenez: cool. One failure in there in a restart, I haven't seen that one. [14:34] ogra_: conversely, if your app crashes in a loop and we clean up tmp, and the crash was because of tmp wackiness, ... [14:34] but it's nice, we can start collecting stats :) [14:34] Chipaca, well, anyway, xkb doesnt seem to see the TMPDIR at all according to the log [14:34] (II) XKB: generating xkmfile /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm [14:34] elopio, yes :) that execution was strange, it got stuck in the first update for almost one hour, then it gave that error... [14:35] that doesnt look like it uses TMPDIR [14:35] elopio, enyway, if you can put an instance to execute the tests it would be great to compare results [14:35] *anyway [14:36] ogra_: which is weird, because it doesn't have to [14:36] fgimenez: ok, let me trigger one. [14:36] ogra_: that is, you have a private /tmp/ [14:36] Chipaca, ah, so /tmp should be transparent ? [14:36] ogra_: you don't need to "see" TMPDIR or anything [14:36] ok [14:36] ogra_: the env vars were left for backwards compat, but enough things ignore them that you have a whole /tmp just for you [14:36] elopio: cool, I'll check it out in just a bit [14:36] that just happens to be a subdir of /tmp/ :) [14:37] o/ [14:37] right [14:37] plars: you wget that script, and run it passing the ip. Let me know what happens.. [14:37] probably thats a red herring [14:39] elopio: a lot of errors it looks like [14:41] plars: paste please. [14:42] elopio: I'm working through them... it looks like the first was because I needed bzr, now it seems to want golang installed [14:43] um, that's right, it will need debs. [14:43] I didn't take thata into account... so not really that different from installing from the ppa. [14:44] elopio: will it also need autopkgtest? [14:44] I suspect it won't need some of those things [14:44] since I'm not using it for provisioning [14:44] I had hoped all the go build pieces could be skipped - I thought that was the point of providing the go binary [14:45] oh, it needs git also [14:45] elopio: ^ I didn't even see git mentioned in the control file [14:48] plars: yes, autopkgtest from wily. [14:48] ok [14:48] plars: that was my naive idea yesterday. Now I realize it makes no sense. [14:48] so it seems that one way or another, this is going to need a lot of customization on the host ahead of time [14:49] we could reduce the set up needed by providing also a binary for snappy tests, but not much. [14:49] plars: yes. [14:49] elopio: if we install from your ppa, does it automatically get the right version of autopkgtest? [14:49] plars: only if the host is in wily. [14:50] elopio: I'm not opposed to setting it up on the test hosts, but I do worry it will cause you some pain in the future to do it this way. Having everything self-contained means you can make fewer assumptions about the test environment, and separates concerns about the tests vs. hardware much better [14:50] elopio: no, the host is on trusty here [14:51] plars: even if we don't use autopkgtest for provisioning, we need it for reboots. So that's one dependency we can't easily work around. [14:51] elopio: so installing from the ppa wouldn't help us anyway [14:51] plars: so install it as explained in _integration-tests/README.mf [14:51] *md [14:51] elopio: how often do you think this package will change? [14:52] plars: very often, but we won't need to update it every time. [14:56] https://www.irccloud.com/pastebin/IA0r1xOX/ [14:56] elopio: ^ === chihchun is now known as chihchun_afk [15:01] mterry to the rescue ! [15:01] ogra_, what's up? [15:02] mterry, you packaged some xorg snap once ... how did you havdle the keymap generation ? [15:02] *handle [15:02] * ogra_ is stuck with that ... and i cant convince xorg to not try to use a kbd at all [15:03] ogra_, I believe deb2snap has a hack for that. In tools/fixes, it copies over /var/lib/xkb/*.xkm into the snap [15:03] oh, so you generate them in advance ? [15:03] i'll take a look [15:04] ogra_, and then another hack that places them in $SNAP_APP_DATA_PATH (since that's where the ld-preload code looks for them [15:04] ogra_, yeah, they are just sitting there on the system that runs deb2snap, so I figured we'd just use those [15:04] ah, i'm trying to get along without any preloading (works fine apart from that one thing) [15:08] plars: sorry, I'm on the stand up. Let me try... [15:09] elopio: no rush [15:20] plars: I don't get that error. fgimenez: any ideas? https://www.irccloud.com/pastebin/IA0r1xOX/ [15:25] elopio, never seen before, "Syntax error: Unterminated quoted string" [15:26] sergiusens, does hw-assign not take effect on a running process? I always have to restart it in order for it to access the hw [15:26] * ogra_ sends the terminator ovber [15:27] fgimenez: this looks just fine: go run ./_integration-tests/main.go -ip 192.168.1.148. No idea what might be wrong in there. [15:27] kyrofa: I am not sure, but I guess so since the apparmor profile is extended and needs to re run so it is reconfined [15:27] not sure you can reconfine on the fly [15:27] jdstrand: ? ^ [15:28] plars: can you set up your GOPATH, branch snappy and run the tests from there? That will give us a better clue of where's the problem. [15:28] sergiusens, this gave me the impression it was possible: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ [15:29] Notice how it assigns the hw and voila, it works [15:29] But mine doesn't work that way :P [15:29] elopio, the testbed is amd64, right? [15:29] fgimenez: yes according to plars. [15:29] ah, wait, we are not building for arm. [15:30] the host is amd64, the test bed is arm. [15:31] hw-assign does more than apparmor-- it will setup the device cgroup and add the device to that cgroup. as such, I believe you much relaunch the process (unless there is a way to update the cgroups for a running process-- I don't know) [15:31] fgimenez: in the end, we need snappy-test-job to receive all the flags that snappy integration tests receive. Is there a better way to do it instead of copying everything? [15:31] possibly worth a bug for the core guys to look at [15:31] elopio: fgimenez: no, the testbed is bbb [15:32] elopio: fgimenez: I said the test host is amd64 [15:32] the agent host that is [15:32] plars: yes, my mistake. [15:32] jdstrand, so the link above must have missed a step? [15:32] bbb, obviously, is not [15:32] plars, elopio then we need an -arch flag too [15:32] fgimenez: adding it... [15:33] kyrofa: yes. that may have been written before mvo implemented the cgroup bits (things were landing hot at the time) [15:34] jdstrand, ah, okay. Thank you! [15:35] elopio, flag.Visit could be handy for passing the options around, but anyway the flags should be defined in the entrypoint, and we have two of them now... [15:37] jdstrand, is the only way to do that via a reboot? [15:37] jdstrand, or can I request a service restart via snappy? [15:37] oh no, just restart the service [15:38] HEY ! everyone congratulate longsleep !!! seems we'll have the first snappy based commercial device on the market soon ;) [15:39] congrats! [15:39] kyrofa: give me a moment [15:39] secure videochat FTW ! [15:39] screw these hangouts :) [15:41] kyrofa: systemctl -a | grep [15:41] kyrofa: then restart with: [15:41] sudo systemctl stop [15:41] sudo systemctl start [15:41] jdstrand, alright, thanks! [15:43] jdstrand, I saw some mailing list noise about auto-restart a while back. Was that ever implemented? [15:43] I'm not sure. I think there was a branch. sergiusens ^ [15:44] kyrofa: I think that would still require you to kill the process [15:44] (so it could restart) [15:44] jdstrand, which is easy. If I'm denied access, die [15:44] but maybe more was exposed [15:44] yes, but then you will be auto restarted [15:45] Which would solve this problem, wouldn't it? [15:45] Or are you saying the parent process wouldn't let the confinement happen? [15:45] so, I'll defer to the people who implemented/are implementing the feature to explain how it works :) [15:45] kyrofa: I'm saying if you never ran hw-assign, it would loop until you did [15:45] Ah right, agreed [15:46] but ceratinly that was thought about [15:46] jdstrand: that was for config changes and the idea was that services would HUP [15:47] sergiusens, ah, so that won't help me eh? [15:47] there are config changes, but there is also the bit about services autorestarting if they die [15:47] * ogra_ remembers that too [15:48] jdstrand: that should be in already [15:48] https://bugs.launchpad.net/snappy/+bug/1461917 [15:48] Launchpad bug 1461917 in Snappy "snappy app services should auto restart" [High,Fix committed] [15:48] jdstrand: I have my services under dev dying and respawning all the time now [15:48] not released :) [15:48] and for 15.04, it says it is fixed [15:48] oh, right [15:49] kyrofa: so, maybe just kill your process and it will come up [15:49] well, my xserver snap here dies all the time and restarts in a loop ... so yes, seems to work :) [15:49]