| === ubott2 is now known as ubottu | ||
| === chihchun_afk is now known as chihchun | ||
| === zyga-afk is now known as zyga | ||
| fgimenez | good morning | 07:02 |
|---|---|---|
| dholbach | good morning | 07:21 |
| Chipaca | o/ ! | 09:19 |
| Chipaca | good morning snappy'ers! | 09:20 |
| longsleep | hey | 09:20 |
| longsleep | question - do all installed snapps get passed all configs to the config hook? | 09:20 |
| Chipaca | longsleep: hi! how's things | 09:20 |
| longsleep | trying to understand snappy config :) | 09:21 |
| Chipaca | longsleep: "all configs", as in configs for all apps? | 09:21 |
| longsleep | err yes | 09:21 |
| Chipaca | longsleep: err no :) | 09:21 |
| Chipaca | there was an example somewhere | 09:21 |
| longsleep | so how does webdm know the ports of all the apps? | 09:21 |
| longsleep | snaps | 09:21 |
| Chipaca | longsleep: webdm cheats (it has a handcrafted security policy) | 09:22 |
| Chipaca | longsleep: it can call "snappy config" for every app | 09:22 |
| longsleep | ah ok | 09:22 |
| Chipaca | longsleep: and that would print out the config | 09:22 |
| Chipaca | it doesn't *actually* exec out snappy config | 09:22 |
| Chipaca | it links against snappy-the-library | 09:22 |
| longsleep | got it - so then the problem is how i can share config between multiple snaps? | 09:23 |
| Chipaca | tricky | 09:23 |
| Chipaca | longsleep: can you explain a little of why you need it? | 09:24 |
| longsleep | well i for example i have to share secrets between snaps - to make shared secret auth work | 09:24 |
| Chipaca | ah | 09:24 |
| Chipaca | longsleep: and there isn't a logical "owner" of the secrets? | 09:25 |
| longsleep | and i might have to know what ports another snap is using to connect to the services there | 09:25 |
| longsleep | Chipaca: well i assume someone could be made the logical owner, but how does the information get to the snaps which need it | 09:25 |
| longsleep | i mean i could put it all into a single snap - thats what i would try to avoid though | 09:26 |
| Chipaca | 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 |
| Chipaca | longsleep: i'm not sure that would work, but i think maybe we should make that work if it doesn't | 09:27 |
| Chipaca | :) | 09:27 |
| longsleep | yes i think that would work | 09:27 |
| longsleep | at least for the configuration stuff where each snap is not the logical owner | 09:28 |
| longsleep | ports are a different story | 09:28 |
| Chipaca | wrt ports, you need a discovery mechanism, or making them non-negotiable | 09:28 |
| longsleep | i want to make them configurable and negotiable | 09:29 |
| Chipaca | the discovery mechanism can be a script as per above, or something like avahi | 09:29 |
| longsleep | you mean a snap could provide a script that prints ot the information other snaps might want? | 09:30 |
| longsleep | can i call stuff provided as binaries of snap-a from snap-b then? | 09:30 |
| Chipaca | i should know that, but i'm rusty from my holidays. let me check. | 09:31 |
| longsleep | heh :) these are good suggestions - i will try them for sure | 09:31 |
| ogra_ | Chipaca is back \o/ | 09:32 |
| longsleep | for now i just want to make the ports for spreed-webrtc a configuration | 09:32 |
| Chipaca | ogra_: allegedly :) | 09:32 |
| ogra_ | :) | 09:32 |
| Chipaca | we'll see for how long (!) | 09:32 |
| ogra_ | hey ! | 09:32 |
| Chipaca | ogra_: just before going away i was asked if i was willing and able to work on a zomg urgent thing | 09:33 |
| Chipaca | ogra_: as per | 09:33 |
| Chipaca | ogra_: so i don't know how it's played out yet :) | 09:33 |
| longsleep | 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:34 |
| Chipaca | eep! snappy update just got 'no space left on device' | 09:35 |
| ogra_ | as i understand it it is for "package intercommunication" | 09:35 |
| longsleep | ogra_: thats good then - so i should probably add that as well | 09:35 |
| longsleep | 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 |
| ogra_ | webdm uses the external port for the "open" link in the details page | 09:40 |
| longsleep | yes the one marked external/ui - but what if that is a configuration ? | 09:41 |
| longsleep | 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 |
| longsleep | then webdm would have to link there | 09:42 |
| longsleep | 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 | 09:43 |
| biezpal | hey! how cron works in Snappy? Tried to add crontab job - everything is read-only :( | 10:00 |
| ogra_ | it will use whatever systemd provides as cron replacement ... | 10:01 |
| ogra_ | not sure where we stand with that thouh | 10:01 |
| biezpal | ogra_, thanks! | 10:02 |
| Chipaca | i think we plan to expose timers | 10:02 |
| Chipaca | but haven't done so yet | 10:02 |
| Chipaca | timers as in systemd.timer(5) | 10:02 |
| biezpal | Chipaca, but it's not implemented yet? | 10:03 |
| biezpal | ok, got it, thx | 10:04 |
| Chipaca | 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:11 |
| biezpal | Chipaca, thanks a lot | 10:18 |
| longsleep | 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:26 |
| longsleep | is that the same ports as found in package.yaml? | 10:27 |
| Rlyeh | I want remove docker, but since some apps are using docker, it will not remove | 10:30 |
| Rlyeh | (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy remove docker | 10:30 |
| Rlyeh | Removing docker | 10:30 |
| Rlyeh | framework still in use by: owncloud | 10:30 |
| === erkules_ is now known as erkules | ||
| Chipaca | Rlyeh: remove the dependencies first | 10:31 |
| Chipaca | Rlyeh: sudo snappy remove owncloud docker | 10:32 |
| Chipaca | Rlyeh: will work | 10:32 |
| Rlyeh | I won't remove owncloud | 10:33 |
| Rlyeh | I don't know owncloud service name to stop | 10:33 |
| Chipaca | Rlyeh: sorry, i don't understand | 10:33 |
| Chipaca | Rlyeh: why won't you remove owncloud? | 10:33 |
| Rlyeh | I just want to reinstall docker | 10:34 |
| Rlyeh | I think it will be remove if I stop owncloud service, right? | 10:35 |
| Rlyeh | It seems docker doesn't work properly | 10:36 |
| Chipaca | Rlyeh: still not understanding, here; sorry :-( | 10:36 |
| Chipaca | Rlyeh: you want to reinstall docker because it's not working properly? | 10:36 |
| Rlyeh | yes | 10:38 |
| Rlyeh | I updated docker from 1.6.1 to 1.6.2 to day | 10:38 |
| Rlyeh | After reboot, owncloud was not working | 10:39 |
| Chipaca | Rlyeh: and how is it not working properly? | 10:39 |
| Rlyeh | I checked and port 443 was close | 10:39 |
| Chipaca | Rlyeh: and if you roll back docker does owncloud work again? | 10:40 |
| Rlyeh | Rollbacks the docker, but still docker not working | 10:40 |
| dholbach | hum....... | 10:40 |
| Chipaca | dholbach: 'sup? | 10:40 |
| Rlyeh | I don't know what happened but I have to fix this | 10:41 |
| Rlyeh | Because of owncloud | 10:41 |
| dholbach | Chipaca, have you seen something like this before? http://pastebin.ubuntu.com/12070190/ | 10:41 |
| Chipaca | dholbach: it's a pastebin link. I've seen many of those! | 10:41 |
| Chipaca | :-p | 10:41 |
| dholbach | riiiiiiiiiiight | 10:42 |
| ogra_ | dholbach, yeah., we require that you run snapcraft on your phone now for building so we check the system-image config :P | 10:42 |
| Rlyeh | Do you know owncloud service name to stop ? | 10:43 |
| ogra_ | Rlyeh, systemctl|grep owncloud | 10:43 |
| ogra_ | then just use systemctl stop | 10:43 |
| Rlyeh | Thank you ogra | 10:44 |
| Chipaca | or snappy service owncloud stop | 10:44 |
| Chipaca | in new enough snappys | 10:44 |
| ogra_ | dholbach, you get that error only by running add-apt-repo ? thats really odd | 10:44 |
| dholbach | ogra_, it is | 10:45 |
| Chipaca | dholbach: i hadn't seen it, but it seems you can ignore it | 10:45 |
| Chipaca | it's probably aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously | 10:45 |
| Chipaca | deffinitely a bug, but seems add-apt-repo is still doing the right thing | 10:45 |
| Chipaca | aptsources | 10:46 |
| Chipaca | dholbach: so | 10:46 |
| Chipaca | dholbach: file a bug against aptsources | 10:47 |
| Chipaca | dholbach: then continue with your day :) | 10:47 |
| dholbach | ok cool, will do | 10:47 |
| Chipaca | in fact i can probably provide a patch for you to include in your bug | 10:47 |
| Chipaca | gimme a sec, then i'll give you a diff, if you could try that it'd be nice | 10:48 |
| dholbach | Chipaca, https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1484470 | 10:50 |
| ubottu | Launchpad bug 1484470 in python-apt (Ubuntu) "aptsources.sourceslist or softwareproperties.ppa calling out to system-image-cli erroneously" [Undecided,New] | 10:50 |
| Chipaca | dholbach: could you try http://pastebin.ubuntu.com/12070228/ ? | 10:50 |
| Chipaca | wait, that's wrong | 10:52 |
| Chipaca | dholbach: hold it | 10:52 |
| Chipaca | dholbach: ETOORUSHED | 10:52 |
| Chipaca | dholbach: http://pastebin.ubuntu.com/12070249/ | 10:54 |
| dholbach | Chipaca, fixed | 10:54 |
| dholbach | at least there's no message now | 10:55 |
| Chipaca | exactly :) | 10:55 |
| dholbach | judging by "usage: system-image-cli ......." | 10:55 |
| dholbach | it might be that s-i-c is called with the wrong parameters? | 10:55 |
| dholbach | h no | 10:55 |
| dholbach | ah no | 10:55 |
| dholbach | nevermind :) | 10:55 |
| Chipaca | dholbach: config not found | 10:56 |
| dholbach | yep | 10:56 |
| Chipaca | 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 |
| dholbach | that's a question for mvo :) | 10:57 |
| Chipaca | making an MP then | 10:57 |
| Chipaca | eep | 10:58 |
| Chipaca | never change gpg keys the week before your holidays | 10:58 |
| dholbach | oops | 10:59 |
| Chipaca | https://code.launchpad.net/~chipaca/python-apt/no-stderr-for-you-mister-system-image-cli/+merge/267935 | 11:00 |
| ogra_ | hmm | 11:40 |
| ogra_ | was there a way to make ubuntu-core-launcher output verbose in syslog ? | 11:41 |
| ogra_ | Aug 13 11:40:24 localhost ubuntu-core-launcher[1761]: execv failed: Permission denied | 11:41 |
| ogra_ | not actually helpful ... | 11:41 |
| Chipaca | ogra_: you probably got something in syslog about that | 11:44 |
| ogra_ | no, thats my issue :) | 11:44 |
| ogra_ | nothing beyond that and the .service then tellin me it exited 1 | 11:45 |
| Chipaca | ogra_: can you actually exec the thing you're trying to exec? | 11:47 |
| ogra_ | hard to tell ... my LD_LIBRARY_PATH is like 1000 pages long :P | 11:47 |
| * ogra_ tries to get xfbdev to run on a rpi | 11:48 | |
| ogra_ | mainly as "lunch exercise" | 11:48 |
| Chipaca | ogra_: ahhh | 11:49 |
| Chipaca | ogra_: did you check the obvious, ie unix perms for executables and dynamic libraries? | 11:50 |
| ogra_ | sure, the tree loosk fine | 11:50 |
| longsleep | 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 |
| ogra_ | i think it is | 11:50 |
| Chipaca | ah! i was going to check that, and got dragged into this python-apt madness | 11:52 |
| Chipaca | longsleep: if you install webdm, what does 'snappy config webdm' spit out? | 11:52 |
| Chipaca | longsleep: because it's got a port | 11:52 |
| longsleep | that is broken | 11:53 |
| longsleep | i thnk i have added a bug for this already | 11:53 |
| longsleep | Cn | 11:54 |
| longsleep | Chipaca: ah yes https://bugs.launchpad.net/webdm/+bug/1482720 | 11:55 |
| ubottu | Launchpad bug 1482720 in webdm "Webdm config seems to be broken / KeyError on snappy config webdm" [Undecided,New] | 11:55 |
| ogra_ | ARGH ! | 11:55 |
| Chipaca | WAT | 11:55 |
| * ogra_ bangs head against wall | 11:55 | |
| longsleep | 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 | |
| ogra_ | start-service.sh .... not executable ... sigh ... so silly | 11:55 |
| Chipaca | ogra_: \o/ | 11:56 |
| Chipaca | ogra_: glad i asked the silly question first, then :) | 11:56 |
| ogra_ | yeah, thanks ! | 11:56 |
| Chipaca | longsleep: can you add a try/except around lines 64 and 65, just to see the output? | 11:57 |
| Chipaca | longsleep: i can provide a patch if you don't python | 11:57 |
| longsleep | Chipaca: i have many years python history - going for lunch now but will check in 20 minutes or so thanks! | 11:58 |
| === kickinz1 is now known as kickinz1|lunch | ||
| Chipaca | longsleep: excellent! and buen provecho :) | 12:02 |
| Chipaca | I say "buen provecho", and dpm comes in | 12:04 |
| Chipaca | i'm not a suspicious person, but ... :-p | 12:05 |
| longsleep | Chipaca: i am back with lunch - config is empty as is expected from reading the hook code (it only exposes avahi-hostname) | 12:14 |
| longsleep | Chipaca: if you are intersted, my hook now returns this yaml: http://paste.ubuntu.com/12070607/ - what do you say? | 12:16 |
| Chipaca | longsleep: and assigning them works? | 12:19 |
| Chipaca | sergiusens: longsleep is trying to make external ports configurable and negotiable | 12:19 |
| longsleep | 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:20 |
| sergiusens | longsleep: Chipaca we don't have the backend ready for that so doing it through config seems fine | 12:22 |
| sergiusens | Chipaca: are you back at work? Or just leasure? | 12:22 |
| Chipaca | sergiusens: back at work! | 12:25 |
| Chipaca | sergiusens: already having two simultaneous meetings (if you don't count this) | 12:25 |
| kyrofa | ogra_, I also can report piglow success using your rpi2 image :) | 12:39 |
| ogra_ | yippie ! | 12:39 |
| kyrofa | 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 |
| kyrofa | (to the i2c device, I mean) | 12:40 |
| ogra_ | https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ take a look at the webcam example | 12:41 |
| kyrofa | ogra_, ah, perfect, thank you :) | 12:44 |
| kyrofa | ogra_, well, not quite. Is making an OEM snap the only way to provision hardware like that? | 12:46 |
| ogra_ | kyrofa, where does it say it is an oem snap ? | 12:56 |
| ogra_ | should be just a normal snap but you need to manually enable the hw access after install | 12:56 |
| kyrofa | 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 |
| kyrofa | ogra_, so there's no way to request hw access from a regular snap? | 12:57 |
| === kickinz1|lunch is now known as kickinz1 | ||
| sergiusens | kyrofa: the manual process is the "trusted helper" or lack thereof ;-) | 13:08 |
| kyrofa | sergiusens, ah, okay so that's the vision for how regular old snaps can get hw access? | 13:09 |
| sergiusens | kyrofa: depends; on personal I guess it would be through the trusted helper system | 13:12 |
| sergiusens | on custom devices, you would build your custom gadget | 13:12 |
| kyrofa | sergiusens, gadget being another kind of snap? I've not gotten into that just yet | 13:13 |
| sergiusens | kyrofa: it's what is the oem today | 13:15 |
| kyrofa | sergiusens, gotcha | 13:15 |
| kyrofa | 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:29 |
| sergiusens | kyrofa: yes you can | 13:30 |
| sergiusens | kyrofa: users of it just need to explicitly allow the crazy things it would do with your hardware | 13:31 |
| ogra_ | 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:32 |
| kyrofa | ogra_, no... that would be too much... | 13:40 |
| ogra_ | heh | 13:40 |
| kyrofa | ogra_, the description should be in debian/control of the generated snap, right? | 13:43 |
| kyrofa | ogra_, ah, nevermind. The manifest | 13:43 |
| sergiusens | ogra_: in rolling that should all work; once we have snap uploads per release it can go into 15.04 | 13:57 |
| kyrofa | sergiusens, why is only the first two paragraphs of the meta/readme used? Makes it tough to format things decently | 14:01 |
| kyrofa | sergiusens, just space concerns? | 14:01 |
| sergiusens | kyrofa: don't get me started on how much I dislike that readme.md ;) | 14:01 |
| kyrofa | sergiusens, ah, okay. As long as I'm not the only one ;) | 14:02 |
| ogra_ | hmm, why can i not set TMPDIR in my service start script ? | 14:21 |
| ogra_ | seems to still point to /tmp ... no matter what i do | 14:21 |
| sergiusens | ogra_: I thought Chipaca worked on mounting tmp for snaps into a new namespace | 14:24 |
| Chipaca | yep | 14:24 |
| Chipaca | you get a private tmp | 14:25 |
| Chipaca | and you like it | 14:25 |
| sergiusens | so you need to define "see" ;-) | 14:25 |
| ogra_ | i do, xorg doesnt :P | 14:25 |
| Chipaca | ogra_: what's xorg trying to do? | 14:25 |
| ogra_ | http://paste.ubuntu.com/12071355/ | 14:25 |
| ogra_ | compiling a keymap in /tmp | 14:25 |
| ogra_ | trying to set TMPDIR doesnt make it pick up any different dir | 14:25 |
| ogra_ | and it also doesnt seem to pick up whatever is set by the launcher | 14:26 |
| Chipaca | ogra_: could you list /tmp/ for me please? | 14:26 |
| ogra_ | oh, wait ... | 14:26 |
| ogra_ | did the tmpdir cange land in 15.04 ? | 14:26 |
| === jkridner|work is now known as jkridner | ||
| Chipaca | ogra_: quisió! but maybe not | 14:27 |
| Chipaca | ogra_: but looking at /tmp/ after a run will tell you | 14:27 |
| elopio | fgimenez: my throat hurst a little. Lets talk here today. | 14:27 |
| ogra_ | Chipaca, hmm ... might be helpful if it also cleaned up after itself http://paste.ubuntu.com/12071402/ | 14:28 |
| ogra_ | only 500 tmpdirs :P | 14:28 |
| fgimenez | elopio, ok take care! | 14:29 |
| elopio | fgimenez: I agree that parsing the writer output is the most simple thing to do now. | 14:29 |
| fgimenez | elopio, ok, the outputWriter type is what we need, but now is difficult to use | 14:30 |
| Chipaca | ogra_: that's the private tmp signature there | 14:30 |
| Chipaca | ogra_: look inside those, at permissions | 14:30 |
| elopio | fgimenez: yes, we need help from niemayer there. | 14:30 |
| Chipaca | hopefully we haven't broken that (!!) | 14:30 |
| ogra_ | Chipaca, but why does itr leave them behind ? | 14:31 |
| fgimenez | elopio, hopefully i'll push something today for the parsing approach, it's quite easy given the current output | 14:31 |
| ogra_ | (and inside which of them would i look now, so many choices !) | 14:31 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/ | 14:32 |
| ogra_ | total 0 | 14:32 |
| ogra_ | drwxrwxrwt 3 root root 60 Aug 13 14:04 tmp | 14:32 |
| ogra_ | (RaspberryPi2)ubuntu@localhost:~$ sudo ls -l /tmp/snap.0_xserver-fbdev.sideload_zoK1gY/tmp/ | 14:32 |
| ogra_ | total 0 | 14:32 |
| ogra_ | permissions seem fine | 14:32 |
| Chipaca | ogra_: i think the consensus was we wanted to clean them up with something like tmpreaper, not right after things stopped | 14:32 |
| ogra_ | hmm, k | 14:32 |
| fgimenez | elopio, good news, we have a new docker framework version ready thanks to kickinz1 :) | 14:33 |
| fgimenez | elopio, http://10.55.32.19:8080/job/daily-1504/ | 14:33 |
| elopio | plars: the ppa is updated. Here's the script: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh | 14:33 |
| ogra_ | the prob is that if you develop and your service crashes in a loop you might end up with 500 dirs there :) | 14:33 |
| elopio | fgimenez: cool. One failure in there in a restart, I haven't seen that one. | 14:34 |
| Chipaca | ogra_: conversely, if your app crashes in a loop and we clean up tmp, and the crash was because of tmp wackiness, ... | 14:34 |
| elopio | but it's nice, we can start collecting stats :) | 14:34 |
| ogra_ | Chipaca, well, anyway, xkb doesnt seem to see the TMPDIR at all according to the log | 14:34 |
| ogra_ | (II) XKB: generating xkmfile /tmp/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm | 14:34 |
| fgimenez | elopio, yes :) that execution was strange, it got stuck in the first update for almost one hour, then it gave that error... | 14:34 |
| ogra_ | that doesnt look like it uses TMPDIR | 14:35 |
| fgimenez | elopio, enyway, if you can put an instance to execute the tests it would be great to compare results | 14:35 |
| fgimenez | *anyway | 14:35 |
| Chipaca | ogra_: which is weird, because it doesn't have to | 14:36 |
| elopio | fgimenez: ok, let me trigger one. | 14:36 |
| Chipaca | ogra_: that is, you have a private /tmp/ | 14:36 |
| ogra_ | Chipaca, ah, so /tmp should be transparent ? | 14:36 |
| Chipaca | ogra_: you don't need to "see" TMPDIR or anything | 14:36 |
| ogra_ | ok | 14:36 |
| Chipaca | 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 |
| plars | elopio: cool, I'll check it out in just a bit | 14:36 |
| Chipaca | that just happens to be a subdir of /tmp/ :) | 14:36 |
| kickinz1 | o/ | 14:37 |
| ogra_ | right | 14:37 |
| elopio | plars: you wget that script, and run it passing the ip. Let me know what happens.. | 14:37 |
| ogra_ | probably thats a red herring | 14:37 |
| plars | elopio: a lot of errors it looks like | 14:39 |
| elopio | plars: paste please. | 14:41 |
| plars | elopio: I'm working through them... it looks like the first was because I needed bzr, now it seems to want golang installed | 14:42 |
| elopio | um, that's right, it will need debs. | 14:43 |
| elopio | I didn't take thata into account... so not really that different from installing from the ppa. | 14:43 |
| plars | elopio: will it also need autopkgtest? | 14:44 |
| plars | I suspect it won't need some of those things | 14:44 |
| plars | since I'm not using it for provisioning | 14:44 |
| plars | I had hoped all the go build pieces could be skipped - I thought that was the point of providing the go binary | 14:44 |
| plars | oh, it needs git also | 14:45 |
| plars | elopio: ^ I didn't even see git mentioned in the control file | 14:45 |
| elopio | plars: yes, autopkgtest from wily. | 14:48 |
| plars | ok | 14:48 |
| elopio | plars: that was my naive idea yesterday. Now I realize it makes no sense. | 14:48 |
| plars | so it seems that one way or another, this is going to need a lot of customization on the host ahead of time | 14:48 |
| elopio | we could reduce the set up needed by providing also a binary for snappy tests, but not much. | 14:49 |
| elopio | plars: yes. | 14:49 |
| plars | elopio: if we install from your ppa, does it automatically get the right version of autopkgtest? | 14:49 |
| elopio | plars: only if the host is in wily. | 14:49 |
| plars | 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 |
| plars | elopio: no, the host is on trusty here | 14:50 |
| elopio | 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 |
| plars | elopio: so installing from the ppa wouldn't help us anyway | 14:51 |
| elopio | plars: so install it as explained in _integration-tests/README.mf | 14:51 |
| elopio | *md | 14:51 |
| plars | elopio: how often do you think this package will change? | 14:51 |
| elopio | plars: very often, but we won't need to update it every time. | 14:52 |
| plars | https://www.irccloud.com/pastebin/IA0r1xOX/ | 14:56 |
| plars | elopio: ^ | 14:56 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mterry to the rescue ! | 15:01 |
| mterry | ogra_, what's up? | 15:01 |
| ogra_ | mterry, you packaged some xorg snap once ... how did you havdle the keymap generation ? | 15:02 |
| ogra_ | *handle | 15:02 |
| * ogra_ is stuck with that ... and i cant convince xorg to not try to use a kbd at all | 15:02 | |
| mterry | ogra_, I believe deb2snap has a hack for that. In tools/fixes, it copies over /var/lib/xkb/*.xkm into the snap | 15:03 |
| ogra_ | oh, so you generate them in advance ? | 15:03 |
| ogra_ | i'll take a look | 15:03 |
| mterry | 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 |
| mterry | ogra_, yeah, they are just sitting there on the system that runs deb2snap, so I figured we'd just use those | 15:04 |
| ogra_ | ah, i'm trying to get along without any preloading (works fine apart from that one thing) | 15:04 |
| elopio | plars: sorry, I'm on the stand up. Let me try... | 15:08 |
| plars | elopio: no rush | 15:09 |
| elopio | plars: I don't get that error. fgimenez: any ideas? https://www.irccloud.com/pastebin/IA0r1xOX/ | 15:20 |
| fgimenez | elopio, never seen before, "Syntax error: Unterminated quoted string" | 15:25 |
| kyrofa | 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:26 | |
| elopio | 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 |
| sergiusens | 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 |
| sergiusens | not sure you can reconfine on the fly | 15:27 |
| sergiusens | jdstrand: ? ^ | 15:27 |
| elopio | 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 |
| kyrofa | sergiusens, this gave me the impression it was possible: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ | 15:28 |
| kyrofa | Notice how it assigns the hw and voila, it works | 15:29 |
| kyrofa | But mine doesn't work that way :P | 15:29 |
| fgimenez | elopio, the testbed is amd64, right? | 15:29 |
| elopio | fgimenez: yes according to plars. | 15:29 |
| elopio | ah, wait, we are not building for arm. | 15:29 |
| elopio | the host is amd64, the test bed is arm. | 15:30 |
| jdstrand | 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 |
| elopio | 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 |
| jdstrand | possibly worth a bug for the core guys to look at | 15:31 |
| plars | elopio: fgimenez: no, the testbed is bbb | 15:31 |
| plars | elopio: fgimenez: I said the test host is amd64 | 15:32 |
| plars | the agent host that is | 15:32 |
| elopio | plars: yes, my mistake. | 15:32 |
| kyrofa | jdstrand, so the link above must have missed a step? | 15:32 |
| plars | bbb, obviously, is not | 15:32 |
| fgimenez | plars, elopio then we need an -arch flag too | 15:32 |
| elopio | fgimenez: adding it... | 15:32 |
| jdstrand | kyrofa: yes. that may have been written before mvo implemented the cgroup bits (things were landing hot at the time) | 15:33 |
| kyrofa | jdstrand, ah, okay. Thank you! | 15:34 |
| fgimenez | 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:35 |
| kyrofa | jdstrand, is the only way to do that via a reboot? | 15:37 |
| kyrofa | jdstrand, or can I request a service restart via snappy? | 15:37 |
| jdstrand | oh no, just restart the service | 15:37 |
| ogra_ | HEY ! everyone congratulate longsleep !!! seems we'll have the first snappy based commercial device on the market soon ;) | 15:38 |
| jdstrand | congrats! | 15:39 |
| jdstrand | kyrofa: give me a moment | 15:39 |
| ogra_ | secure videochat FTW ! | 15:39 |
| ogra_ | screw these hangouts :) | 15:39 |
| jdstrand | kyrofa: systemctl -a | grep <your service> | 15:41 |
| jdstrand | kyrofa: then restart with: | 15:41 |
| jdstrand | sudo systemctl stop <service name> | 15:41 |
| jdstrand | sudo systemctl start <service name> | 15:41 |
| kyrofa | jdstrand, alright, thanks! | 15:41 |
| kyrofa | jdstrand, I saw some mailing list noise about auto-restart a while back. Was that ever implemented? | 15:43 |
| jdstrand | I'm not sure. I think there was a branch. sergiusens ^ | 15:43 |
| jdstrand | kyrofa: I think that would still require you to kill the process | 15:44 |
| jdstrand | (so it could restart) | 15:44 |
| kyrofa | jdstrand, which is easy. If I'm denied access, die | 15:44 |
| jdstrand | but maybe more was exposed | 15:44 |
| jdstrand | yes, but then you will be auto restarted | 15:44 |
| kyrofa | Which would solve this problem, wouldn't it? | 15:45 |
| kyrofa | Or are you saying the parent process wouldn't let the confinement happen? | 15:45 |
| jdstrand | so, I'll defer to the people who implemented/are implementing the feature to explain how it works :) | 15:45 |
| jdstrand | kyrofa: I'm saying if you never ran hw-assign, it would loop until you did | 15:45 |
| kyrofa | Ah right, agreed | 15:45 |
| jdstrand | but ceratinly that was thought about | 15:46 |
| sergiusens | jdstrand: that was for config changes and the idea was that services would HUP | 15:46 |
| kyrofa | sergiusens, ah, so that won't help me eh? | 15:47 |
| jdstrand | there are config changes, but there is also the bit about services autorestarting if they die | 15:47 |
| * ogra_ remembers that too | 15:47 | |
| sergiusens | jdstrand: that should be in already | 15:48 |
| jdstrand | https://bugs.launchpad.net/snappy/+bug/1461917 | 15:48 |
| ubottu | Launchpad bug 1461917 in Snappy "snappy app services should auto restart" [High,Fix committed] | 15:48 |
| sergiusens | jdstrand: I have my services under dev dying and respawning all the time now | 15:48 |
| ogra_ | not released :) | 15:48 |
| jdstrand | and for 15.04, it says it is fixed | 15:48 |
| ogra_ | oh, right | 15:48 |
| jdstrand | kyrofa: so, maybe just kill your process and it will come up | 15:49 |
| ogra_ | well, my xserver snap here dies all the time and restarts in a loop ... so yes, seems to work :) | 15:49 |
| kyrofa | jdstrand, trying | 15:49 |
| jdstrand | sergiusens: hw-assign probably needs to HUP things | 15:49 |
| kyrofa | jdstrand, no such luck. ogra_ think your i2c image included those changes? | 15:50 |
| jdstrand | kyrofa: summary of backscroll-- kyrofa has a service that is denied access. he uses hw-assign. that does not take effect until the process is restarted. this is certainly because of the running process' cgroup and it not picking up the device cgroup change until the next invocation | 15:50 |
| ogra_ | kyrofa, i'm staring at a syslog where a broken snap gets permanently restarted in a loop, so yes, i thnk they are in | 15:50 |
| jdstrand | err | 15:50 |
| jdstrand | sergiusens: ^ | 15:51 |
| jdstrand | kyrofa: are you on 15.04? | 15:51 |
| kyrofa | jdstrand, yeah. Let me see what happens if I just exit with a non-zero status... | 15:52 |
| jdstrand | that may do it | 15:53 |
| jdstrand | Restart=on-failure | 15:53 |
| sergiusens | jdstrand: that's automatic now | 15:54 |
| jdstrand | right, that is what I'm saying | 15:54 |
| jdstrand | I'm looking at the diff and see that was added | 15:54 |
| jdstrand | sergiusens: oh wait, what are you referring to, the on-failure or the cgroup? | 15:54 |
| ogra_ | http://paste.ubuntu.com/12071972/ on failure works fine ... | 15:56 |
| kyrofa | jdstrand, interesting, it DOES work, but I get this after a few times: start request repeated too quickly | 15:56 |
| ogra_ | if the executable dies it gets auto respawned | 15:56 |
| kyrofa | There seems to be some sort of rate limiting or something | 15:56 |
| dholbach | mterry, if you have a quick look at bug 1484515 and bug 1484538 can you maybe tell me if I'm doing it wrong? :) | 15:57 |
| ubottu | bug 1484515 in Snapcraft "File exists: '/home/daniel/dev/apps/xwax.snap/parts/xwax/build'" [Undecided,New] https://launchpad.net/bugs/1484515 | 15:57 |
| ubottu | bug 1484538 in Snapcraft "meta/package.yaml exists, but not found" [Undecided,New] https://launchpad.net/bugs/1484538 | 15:57 |
| jdstrand | kyrofa: yeah. so I see in http://www.freedesktop.org/software/systemd/man/systemd.service.html that on-failure ignores if the process is sent TERM (the default by kill) | 15:57 |
| jdstrand | kyrofa: I bet if you do kill -9 it would work | 15:57 |
| fgimenez | elopio, ping me if you need the ppa to be rebuilt | 15:58 |
| elopio | fgimenez: https://code.launchpad.net/~elopio/snappy-tests-job/arch/+merge/267969 | 15:59 |
| kyrofa | jdstrand, that was with a non-zero exit status | 16:00 |
| kyrofa | jdstrand, so if it dies quickly it will only do it a few times | 16:00 |
| jdstrand | kyrofa: right. I'm saying, remove the non-zero exit status bit (it detected the loop I mentioned before), and simply send it kill -9 | 16:00 |
| jdstrand | I bet that will work | 16:01 |
| jdstrand | I imagine the fix for this is that after hw-assign, have snappy simply restart the affected services. that probably makes most sense anyway cause if the sevice started without access to the device, it may not notice it all of a sudden has access | 16:03 |
| kyrofa | jdstrand, you're right, that works | 16:03 |
| jdstrand | cool | 16:03 |
| kyrofa | jdstrand, yeah, that's the position I'm in now. I mean, it's impossible for it to notice that it all of a sudden has access since it's effectively still confined | 16:04 |
| jdstrand | kyrofa: would you mind filing a bug on this? https://bugs.launchpad.net/snappy/+filebug | 16:04 |
| kyrofa | jdstrand, definitey | 16:04 |
| jdstrand | kyrofa: feel free to copy/paste from the irc backscroll | 16:04 |
| elopio | fgimenez: thanks for the review. And yes, now I need a ppa rebuild. | 16:05 |
| fgimenez | elopio, ok :) https://code.launchpad.net/~fgimenez/+recipe/snappy-tests-job-daily | 16:07 |
| elopio | fgimenez: thanks! sorry for keeping you late. | 16:07 |
| joc_ | hi, could any members of Snappy Devs have a look at my snapcraft branch? i have attempted to add a new plugin and would appreciate any feedback before requesting a merge lp:~jocave/snapcraft/plainbox-provider-plugin | 16:07 |
| fgimenez | elopio, np at all, how could we transfer the ppa to the team? | 16:08 |
| elopio | fgimenez: I think these packages should go to the tools ppa. | 16:08 |
| kyrofa | jdstrand, even with hw-assign restarting affected processes, I'm still not sure how I'm supposed to write a service that requires a hw resource | 16:11 |
| fgimenez | elopio, ok, let me know if something is needed from my side o/ | 16:11 |
| kyrofa | jdstrand, if I die immediately I'll get restart throttled by systemd. If I retry constantly I know I'll never get access to it due to confinement not changing on a running process | 16:12 |
| kyrofa | jdstrand, what's the best way to handle this? | 16:12 |
| mterry | dholbach, heyo! Saw your message. I switched off the snappy team back to unity8. Looks like you figured out the meta package one a bit more tho | 16:20 |
| dholbach | wow, ok | 16:20 |
| dholbach | all the best with unity8! | 16:20 |
| mterry | dholbach, the file-exists one is weird, since we use exist_ok=True when making the directory | 16:21 |
| dholbach | mterry, it's a link - that's probably why | 16:22 |
| kyrofa | sergiusens, any opinion on how to best write a service that requires access to hw? ^^ | 16:22 |
| jdstrand | kyrofa: I suggest checking the return code of the open. if it fails, you can choose to die hard with exit 1 (perhaps logging to use hw-assign) or to fail gracefully and keep trying to access it | 16:27 |
| jdstrand | kyrofa: the hw-assign restart should do a stop/start, so if you are already stopped (ie, you failed with non-zero) you should be ok | 16:28 |
| elopio | plars: script updated. | 16:28 |
| jdstrand | but really it is up to you as the app author | 16:28 |
| plars | elopio: ack, thanks | 16:28 |
| kyrofa | jdstrand, very good. I think the best solution there is probably to exit with a good log message then | 16:29 |
| kyrofa | jdstrand, crap, except the nice log message gets eaten by systemd's "ack! it's restarting too fast" errors: http://pastebin.ubuntu.com/12072279/ | 16:35 |
| jdstrand | kyrofa: you could exit 0 | 16:36 |
| jdstrand | kyrofa: that won't trigger on-failure | 16:36 |
| plars | elopio: this seems to be working a lot better so far | 16:36 |
| kyrofa | Oh. Yeah, good idea | 16:36 |
| plars | elopio: any thoughts on how you might get the results out? | 16:36 |
| plars | elopio: that's something that could be added to the script | 16:36 |
| elopio | plars: autopkgtest saves them in the output directory, which I think is set to /tmp/snappy-test | 16:37 |
| elopio | let me confirm. | 16:37 |
| plars | elopio: right, but that doesn't help you any | 16:37 |
| plars | elopio: you'll want to upload them somewhere I assume? | 16:37 |
| plars | elopio: get them back into a jenkins job, or something like that? | 16:37 |
| elopio | plars: yes, I need the agent to send them back to me. | 16:38 |
| elopio | plars: you can put them anywhere, and save the url in the result payload. | 16:38 |
| plars | elopio: talk to ev to be sure, but I don't think there's any plans for SPI to do that. The agent can pick up a json file with a limited amount of data in it, but probably not your full results that you care about | 16:38 |
| plars | elopio: it's not really up to me - it's what ever you define in your script about where to put them. I'm just saying, saving them to /tmp is probably not going to help you here | 16:39 |
| elopio | plars: so far, I just need a true or false in that json. Federico is working on saving the results as subunit, which we can translate to junit if you want. That's all we need. | 16:39 |
| elopio | maybe for things like snapcraft we'll need other artifacts. | 16:40 |
| kyrofa | jdstrand, should hw-assign start a service that has exited without error though? | 16:40 |
| kyrofa | jdstrand, or is it a case of "Well, it's a snappy service. It should expect to always be running" | 16:40 |
| plars | elopio: so for that, you'll want to have your script output something called 'spi_test_result.json' at the end | 16:41 |
| jdstrand | I think it is the latter. it is an interesting discussion point | 16:41 |
| elopio | plars: sure. But the agent should take care of the upload. Otherwise we'll have to pass the credentials in the script. | 16:41 |
| plars | elopio: upload to where? I don't think they have plans to define where you store your results - at least that's what I've always heard, but you could ask | 16:42 |
| kyrofa | jdstrand, I'll make a note of it on the bug | 16:42 |
| kyrofa | jdstrand, thanks for all your help :) | 16:43 |
| jdstrand | np | 16:43 |
| elopio | plars: anywhere you want. This is not upload to spi, this is upload to any storage. What we pass to spi is only the url to that storage. | 16:43 |
| plars | elopio: it's not up to me either | 16:44 |
| plars | elopio: I am just providing the hardware | 16:44 |
| elopio | when we talked to ev and noise][, I was thinking I was going to control the agent so I thought about uploading to swift. | 16:44 |
| plars | elopio: as far as I care, you can put them in /tmp... they'll likely get lost there, but I'm not the one that needs to see them :) | 16:44 |
| elopio | now that I don't control the agent, I can't control the upload either. | 16:44 |
| plars | elopio: no, but you control your script - and that's where the upload happens from | 16:45 |
| plars | elopio: all the agent can do is run the commands defined - which for this one gives you a list of commands to run | 16:45 |
| elopio | plars: but I certainly shouldn't send my canonistack credentials on this script. | 16:45 |
| plars | elopio: which is why I recommended putting it in a script like that | 16:45 |
| plars | elopio: I don't have canonistack credentials here either, or any intention of using it | 16:45 |
| plars | elopio: nor do I know where you want them, how long to retain data, whether the data is private... | 16:46 |
| plars | elopio: only you can know what you want done with your results, or even which results you want to collect | 16:46 |
| elopio | plars: just give me true of false for now. | 16:46 |
| plars | elopio: otherwise, I'm either just guessing, or having to be way over-concerned with what each particular test wants and where they want it - rather than providing the hardware service | 16:47 |
| plars | elopio: I can't even give you a true or false - I'm telling you what you need to do to get that though | 16:47 |
| plars | elopio: you need to export that file mentioned earlier, and the spi agent itself (not anything I control) picks that up to provide a result back to SPI | 16:48 |
| plars | elopio: afaik, it's arbitrary json up to some limit in size, so you can put whatever you want in it | 16:48 |
| elopio | plars: you can tell me if the script I gave you exit with 0 or not. That's the only thing I need for now. | 16:48 |
| plars | elopio: I can't do that in my stuff, because then it would override what anybody does | 16:49 |
| plars | elopio: and I don't know how to interpret your results | 16:49 |
| plars | elopio: is it not just as easy for you, and more beneficial, to add an echo at the end of your script? | 16:49 |
| elopio | plars: ok, then we'll wait for the subunit change. | 16:50 |
| plars | elopio: if that's all you need, then you could add a last line in your .sh file to do something like echo "{'result': '$?'}" > spi_test_result.json | 16:50 |
| plars | elopio: and then later, you can have it actually save a url there, if you push it somewhere, or add an image #, or whatever you like | 16:51 |
| elopio | plars: ok. is that the name you want? | 16:51 |
| noise][ | elopio: the agent will send test_status="PASSED" if the testcommand exits w/0 | 16:51 |
| plars | elopio: it's not what I want, it's the name defined in the documentation - I have no control over this part | 16:51 |
| elopio | I can't upload anything to an URL, because I won't send the password to the SPI server. But I don't need that yet either, so no point on discussing about it. | 16:52 |
| plars | elopio: but you can put whatever you like in there, up to 4000 bytes iirc? (noise][ is that right?) | 16:52 |
| noise][ | elopio: see the "Actors and Results" section at the very bottom of the docs | 16:52 |
| noise][ | plars: correct. | 16:52 |
| plars | elopio: nor do I, but the spi server doesn't store stuff like that anyway | 16:52 |
| ev | Yes, separation of concerns. SPI is not offering test artefact storage; that's something you need to give your tests the smarts to handle. Neither SPI nor the Lab should have any knowledge about how test results or result metadata is formatted. | 16:52 |
| plars | elopio: you're results server does | 16:52 |
| plars | elopio: for instance, cert team will almost certainly have the results from plainbox uploaded to the certification server | 16:53 |
| plars | the tool they use to run tests has some sort of exporter module (not a checkbox dev, so I'm fuzzy on this) to push the results there | 16:53 |
| plars | I think it can export other things too, but that's the one that would make sense, because it saves it off to a remote result server | 16:54 |
| plars | but you wouldn't care to have that | 16:54 |
| plars | or if you do, you can I guess, but you'd probably want to run your tests in a plainbox provider | 16:54 |
| elopio | at this moment, I just care about true or false, and get subunit working. | 16:54 |
| plars | but neither the agent, nor the provisioning kit know anything about that | 16:54 |
| elopio | then I'll care about other things, and we'll figure out how to get them. | 16:55 |
| ev | plars: I think a reasonable compromise might be that the credentials live on disk where they're used | 16:57 |
| ev | Like how mojo specs are done | 16:57 |
| plars | elopio: cool, these tests still seem to be running well, but they take a while. Any idea how long on bbb? | 16:58 |
| ev | So the tests might know the path to creds, but they're stored on the agent's host | 16:58 |
| ev | Reasonable, or are you worried this breaks separation of concerns? | 16:58 |
| elopio | plars: with my new microsd that says something like hc1, around 30 minutes. | 16:59 |
| elopio | with my old one, more close to 1 hour. | 16:59 |
| plars | ev: it certainly breaks separation of concerns, but so does the local setup needed on the agent host so that his tests will run. It might be nicer if we could find some other way, but I'm happy to make it work for now as long as everyone understands the inherent fragility of doing it that way | 16:59 |
| elopio | noise][: ok, I updated the script with set -e. That's good enough for me now. | 17:00 |
| plars | ev: ^ tests > 1hour still a problem? | 17:00 |
| plars | elopio: I don't think it automatically saves the output | 17:00 |
| plars | elopio: oh, sorry I misread. nm :) | 17:01 |
| plars | somehow I thought you said -x | 17:01 |
| ev | plars, elopio: tests greater than an hour are a problem, yes | 17:06 |
| elopio | the tests that take a lot of time are the failover tests, which are the useful ones. | 17:06 |
| elopio | and currently we have only like 4. | 17:07 |
| elopio | we could just run them on the cloud, but then the usefulness of the bbb lab is not that much. | 17:07 |
| plars | ev: is there any way for the test spec to give it better hints about how long it should run? | 17:07 |
| elopio | there are some things that will reduce the time, like caching the update download. But I'm not sure when we'll have that. | 17:08 |
| ev | plars: not yet, but it's intended: https://trello.com/c/eJF6ngJs/110-story-document-intended-behaviour-of-long-running-tests-exceeding-the-timeout | 17:08 |
| plars | elopio: I think, iiuc, it would work right now, but if it takes too long it could end up looping | 17:09 |
| ev | (see Celso's comment in that card) | 17:09 |
| ev | yeah, it'd loop | 17:09 |
| elopio | another thing we have in mind is to deploy many cloud instances and run the tests in parallel. But with the current agent approach for bbbs, we have access to only one. | 17:10 |
| ev | I'm going to book us a meeting to discuss the credentials thing and setupcommand/testcommand being pushed a bit more towards the tests | 17:10 |
| plars | ev: is there some way to uniquely identify the agent? One big hint that could make this more efficient is if the agent requests a test opp, never acks, and requests one again | 17:11 |
| elopio | ev: ok. If possible, please make it around this time. | 17:11 |
| elopio | ev: even better if you can make it at 14:00 utc, so we have federico. | 17:12 |
| plars | then we could be more permissive with the timeout, default it to 2 days or something crazy | 17:12 |
| plars | should still be possible to override though I think, since there could be a test spec that wants to run some long stress test for a month | 17:13 |
| ev | elopio, plars, noise][: invite sent | 17:16 |
| ev | plars: I've added your thoughts to the card | 17:16 |
| ev | and I've moved it up, as this is going to bite us quick it seems | 17:17 |
| ev | elopio, plars: is that your assessment as well? | 17:17 |
| plars | ev: I hope so, if it bites us soon then it means we're making great progress on fully getting these things running and doing something useful :) | 17:19 |
| elopio | ev: yes, we want to add more tests, so the time will definitely increase even if we find a way to run the current tests faster. | 17:21 |
| ev | thanks guys | 17:22 |
| plars | https://www.irccloud.com/pastebin/rH0vRoXl/ | 17:43 |
| plars | elopio: some more errors after running for a little over an hour ^ | 17:44 |
| plars | elopio: I'm just running the script by hand for now | 17:44 |
| elopio | plars: that script is for rolling | 17:44 |
| elopio | your bbb is in 15.04. We need a different script, or to pass an argument to that script. | 17:44 |
| plars | elopio: oh cool. Well that will be controlled by what image we tell it to install, so that's no problem then | 17:45 |
| plars | cool | 17:45 |
| elopio | plars: yes, I suppose it's better to make a different test image, different script. | 17:47 |
| longsleep | Mhm snapp config docs say that the service will be restarted by snappy automatically. Does not seem to be true. | 17:56 |
| plars | elopio: either would work fine. That would be in the spec to tell it which to call, and the spec is defined for a given image type | 17:57 |
| plars | so it could call different scripts or pass different args, or whatever makes sense | 17:58 |
| ogra_ | longsleep, file it :) | 18:03 |
| kyrofa | sergiusens, jdstrand Restart=on-failure is only put in the .service file for a sideloaded snap, not for one installed from the store. Is that on purpose? | 18:35 |
| * jdstrand did not implement this feature, but this sounds like a bug | 18:36 | |
| kyrofa | jdstrand, alright, I'll log that one as well | 18:40 |
| longsleep | ogra_: filed bug #1484641 | 18:44 |
| nothal | Bug #1484641: snappy config command does not restart service after setting the configuration <Snappy:New> <http://launchpad.net/bugs/1484641> | 18:44 |
| ubottu | bug 1484641 in Snappy "snappy config command does not restart service after setting the configuration" [Undecided,New] https://launchpad.net/bugs/1484641 | 18:44 |
| longsleep | But i pushed a new Spreed WebRTC version with configuration hook to the store nethertheless. Works fine as long as you know how to get the systemd service named and to restart it. | 18:45 |
| kyrofa | sergiusens, double-checking before I log a bug: https://bugs.launchpad.net/snappy/+bug/1461917 is fixed for `snap:qpy install` invocations (from the store or | 18:57 |
| ubottu | Launchpad bug 1461917 in Snappy "snappy app services should auto restart" [High,Fix committed] | 18:57 |
| kyrofa | Argh | 18:57 |
| kyrofa | sergiusens, double-checking before I log a bug: https://bugs.launchpad.net/snappy/+bug/1461917 is fixed for `snappy install` invocations (from the store or sideloaded), but NOT for things installed via webdm | 18:58 |
| kyrofa | sergiusens, I thought those followed the same execution path through the snappy lib | 18:58 |
| sergiusens | kyrofa: right, but webdm would need to be rebuilt, so log a webdm bug ;) | 19:05 |
| kyrofa | sergiusens, I just added webdm as an also-effects. Is that okay? | 19:06 |
| sergiusens | yeah | 19:06 |
| kyrofa | sergiusens, ooooooh right... static linking.... | 19:06 |
| kyrofa | sergiusens, man that takes a while to get your head around | 19:07 |
| pcoca | Hi everyone, I'm using snapcraft and using the ubuntu pluging I got error about files in common | 20:15 |
| pcoca | Is there any way to fix that problem? | 20:15 |
| ted | pcoca, They're probably trying to install the same thing, so for instance if you were using a python3-project and installed python-dev they'd conflict. | 20:26 |
| pcoca | ted: so, I should get rid of some of the packages | 20:27 |
| pcoca | ted: thanks! | 20:27 |
| pcoca | ted: Let's see if I can get the functionality getting rid of some packages :) | 20:27 |
| ted | Heh, you don't need packages! ;-) | 20:27 |
| === zyga is now known as zyga-afk | ||
| pcoca | ted: Hi Ted, Still with the same issue, I'm not able to make a snapcraft out of a python script that requires opencv, I've tried several plugins python2-project, python3-project, ubuntu | 22:24 |
| pcoca | ted: I'm almost thinking about converting the python script to a deb, and then deb2snap, instead of snapcraft :) | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!