[01:14] <sergiusens> elopio: do you know if the launchpad api can now check git repos?
[01:14] <sergiusens> elopio: I guess we aren't using tarmac anymore for MPs, are we?
[03:17] <guest> "Thank you developers"
[03:17] <guest> Owncloud works again
[03:18] <guest> But an old question:
[03:19] <guest> How can I change the storage location from "/var/www/data" to a folder in a usb drive?
[03:39] <guest> Bad time for question, I guess you all are asleep :)
[06:56] <dnlplm> Hello
[06:57] <dnlplm> I have a question related to a snap package
[06:57] <dnlplm> is there a way to unpack a snap package?
[08:50] <vsuojanen> curious how do you update the snaps and distribute the updates to 100 devices? what component is it listens and startups update if there are changes in the service/cluster? is there a local connection config in each Snappy system ?
[09:04] <ogra_> vsuojanen, afaik the component is snappy itself
[09:04] <Chipaca> vsuojanen: snappy is not at this point cluster-aware, if I understand your question correctly.
[09:05] <ogra_> well, you can easily have a central server that pushes snaps via snappy-remote
[09:06] <Chipaca> ogra_: yes, but that's like saying ubuntu is cluster-aware because it ships with ssh
[09:06] <ogra_> :D
[09:07] <ogra_> its all a matter of the shell scripts you add ;)
[09:07] <tbr> didn't someone replace docker with a shell script?
[09:07] <ogra_> heh, yeah
[09:08] <Chipaca> it would be nice to be able to say "uppdate the cluster in phases, have no more than one rack in each dc updating at the same time, switch over after first N upgraded" or something
[09:08] <Chipaca> tbr: nah, docker would need at *least* five lines in that script
[09:08] <Chipaca> too much work
[09:09] <Chipaca> what we replaced with a shell script was the idea of snappy-remote
[09:09] <ogra_> well, there is always ; to make it a single (very long) line :)
[09:11] <Chipaca> ogra_: not beyond 2090962 characters (on my system)
[09:11] <ogra_> lol
[09:11] <Chipaca> xargs --show-limits ftw
[09:27] <vsuojanen> i didn't get now all, but you say snappy-remote ?
[09:29] <vsuojanen> yes i just have the idea of delivering updates to devices without interrupting client device use
[09:33] <Chipaca> vsuojanen: by default snappy checks the store periodically and updates things that are updatable
[09:34] <vsuojanen> I don't have a clue what is available from you and what are the best practices. I'm just interested aboth delivering updates this way
[09:34] <vsuojanen> *u
[09:45] <vsuojanen> thank you. it's here https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
[13:23] <ogra_> Chipaca, did you see the mail on snappy-app-devel ?
[13:24] <ogra_> looks a bit like the binary isnt found by ubuntu-core-launcher to me
[13:41] <Chipaca> ogra_: subject of said mail?
[13:41] <ogra_> "execv failed when running my self-built customized minicom"
[13:41] <ogra_> the strace in there is a bit sparese
[13:41] <Chipaca> ogra_: i haven't got anything from snappy-app-devel since aug 6
[13:41] <ogra_> *sparse
[13:42] <Chipaca> and there it seems to be via snappy-devel
[13:43] <Chipaca> ogra_: can you ask them to pop on here?
[13:43] <ogra_> sure
[13:43] <Chipaca> ogra_: that strace is needing a -f so we can see the second execv
[13:44] <Chipaca> ogra_: so it's either not finding the binary, or the binary is needing libraries that it isn't finding
[13:44] <Chipaca> ogra_: given that they've gotten as far as they have, money is slightly more on the latter
[13:46] <ogra_> i answered
[13:49] <Chipaca> ogra_: my hero
[13:49] <Chipaca> :-p
[13:49] <ogra_> lol
[13:53] <longsleep> love is everywhere!
[14:00] <Chipaca> and especially in this hummous!
[14:00]  * Chipaca is having a slightly late lunch on a very lovely sunny afternoon here outside london
[14:01] <davmor2> Chipaca: man you so funny
[14:01] <ogra_> same here ... *munch* *munch*
[14:01] <Chipaca> davmor2: hummous is serious stuff
[14:01] <davmor2> Chipaca: ask jibel if it is sunny in London it breaks the weather apps tests that looks for rain and london
[14:02] <Chipaca> davmor2: https://goo.gl/photos/aEffhN6NM3Ca88T47
[14:04] <ogra_> pisa near london !
[14:04] <davmor2> Chipaca: you could be anywhere you don't blag me with your holiday snaps of Italy ;)  No Queen genuine or pearly and you are not in London :D
[14:06] <Chipaca> davmor2: https://goo.gl/photos/yVWnTzftxoufYLjo6
[14:06] <Chipaca> davmor2: of course, i could've carried it with me to wherever
[14:07] <Chipaca> davmor2: but i'm not going out to hunt for better proof at this time, sorry
[14:12] <dnlplm> hello
[14:12] <Chipaca> dnlplm: hello hello
[14:12] <dnlplm> I wrote the mail in snappy-devel
[14:13] <Chipaca> dnlplm: were you able to re-run strace with -f?
[14:13] <dnlplm> yes, I have it
[14:13] <Chipaca> dnlplm: pastebin?
[14:13] <dnlplm> ok, just a minute and I will put it
[14:14] <dnlplm> thanks for your support
[14:15] <dnlplm> http://pastebin.com/nKW8478x
[14:18] <ogra_> dnlplm, hmm, does /apps/minicom.sideload/2.7/minicom actually exist ?
[14:18] <ogra_> (and hi !)
[14:19] <dnlplm> actually not
[14:19] <dnlplm> so this is the problem
[14:19] <ogra_> yeah
[14:20] <dnlplm> I installed the package with snappy-remote
[14:20] <dnlplm> so does this mean that there is a problem in my .yaml file?
[14:20] <ogra_> oh, i see whats wrong .... your package.yaml has no exec: entry for the binary
[14:20] <ogra_> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
[14:21] <ogra_> binaries:
[14:21] <ogra_>  - name: binary
[14:21] <ogra_>    exec: path/to/binary
[14:21] <ogra_> the path is reltive to the install path (i.e. /apps/minicom.sideload/2.7/)
[14:21] <ogra_> *relative
[14:22] <ogra_> (and indeed your binary needs to exist in the place you point to :) )
[14:22] <dnlplm> ok, I thought that the binary was copied in the correct dir
[14:22] <dnlplm> by the installer
[14:22] <dnlplm> I will change the exec entry
[14:22] <dnlplm> thank you very much
[14:22] <ogra_> have you been using snapcraft to create the snap ?
[14:23] <ogra_> (sounds like a but if so ... )
[14:23] <ogra_> *bug
[14:23] <dnlplm> snappy build
[14:23] <ogra_> ah
[14:23] <ogra_> snappy build just rolls whatever you have in the dir you call it in (or give as argument) into a snap ... it doesnt modify the content in any way
[14:24] <dnlplm> ok
[14:24] <ogra_> so your binary indeed needs to be there already
[14:24] <dnlplm> so a possible solution is to create the dir  tree
[14:24] <dnlplm> same of the target?
[14:25] <dnlplm> or maybe I should use snapcraft
[14:25] <ogra_> well, i usually create a bin/ dir where i put the binary in
[14:25] <ogra_> and point the exec line to bin/mybinary
[14:26] <dnlplm> ok
[14:26] <dnlplm> sounds easier
[14:26] <dnlplm> thanks, I will try the suggested change
[14:26] <ogra_> let us know how it goes :)
[14:27] <dnlplm> sure
[14:37] <Chipaca> ogra_: you don't need an "exec" line, IIRC, in which case it looks for "./name"
[14:37] <ogra_> ah
[14:37] <Chipaca> ogra_: s/, IIRC,//
[14:38] <ogra_> the doc above only says:
[14:38] <ogra_> Binaries have to be declared. As above, you can provide a list of the binary names you want to export to users when they install your app.
[14:38] <ogra_> and has the exec: in the example
[14:39] <Chipaca> ogra_: mhmm
[14:43]  * ogra_ files bug 1487505 as a reminder
[14:46] <Chipaca> ogra_: exec might be mandatory for the review tools tho
[14:46] <ogra_> ah
[14:46] <Chipaca> i haven't checked
[14:46] <Chipaca> and the sooner we fold the review tools into snappy itself the better
[14:46] <Chipaca> but, there it is
[14:47] <Chipaca> snappy tries to be generous with what it receives
[14:47] <Chipaca> whereas the store doesn't have that luxury
[14:47] <ogra_> yeah
[14:47] <ogra_> well, we can always close the bug
[14:48] <Chipaca> exec itself shouldn't matter one way or another, but it's the mindset
[14:48] <ogra_> yup
[14:48] <Chipaca> anyway! hope that unblocked dnlplm. Wondering where the binary was, such that he thought we'd find it by magic :)
[14:48] <ogra_> the binary alone might not help though, might still need libs
[14:48] <dnlplm> solved :-)
[14:49] <ogra_> cool !
[14:49] <dnlplm> I simply added the entry
[14:49] <dnlplm> exec: meta/bin/minicom
[14:49] <dnlplm> and now it is working without any issue
[14:49] <Chipaca> um
[14:49] <ogra_> oh, dont put it into meta :)
[14:49] <Chipaca> dnlplm: don't put it into meta/ please
[14:49] <Chipaca> dnlplm: we pretend "meta/" is ours :)
[14:49] <ogra_> meta should only have packaging info
[14:50] <dnlplm> ok
[14:50] <dnlplm> simply bin/minicom
[14:50] <ogra_> yeah
[14:51] <Chipaca> dnlplm: nothing would've broken _today_ (i think?) with it being in meta/, but if tomorrow we decided to use meta/bin for something we wouldn't go around checking if you were ok with it
[14:51] <Chipaca> dnlplm: in that sense it's "ours"
[14:52] <dnlplm> that's fine
[14:52] <dnlplm> I understand your concern
[16:51] <ted> Testing my snapcraft demo and it seems the docker framework is broken.
[16:51] <ted> It uses a 'pwd' where that'll be the directory of the app, not the framework.
[16:51] <ted> Seems that /app/docker/current/ works as a good replacement :-)
[18:41] <sergiusens> Chipaca: do you know if launchpad's api export git already?
[18:41] <sergiusens> git branches, MPs and such