[03:11] <xcub_> Hi, I have a question about using snapcraft if anyone wants to help
[04:19] <tzununbekov> Hi all. We have package that mounts Btrfs volume in SNAP_DATA_PATH. When we update this package, all data is copied from old data path to new, but volume is still mounted in old one. Is there any way to handle it?
[04:24] <tzununbekov> asac, Chipaca, ogra_ this causes a doubling of used disk space
[08:09] <dholbach> good morning
[08:11] <fgimenez> good morning
[09:26] <JamesTait> Good morning all; happy Tuesday and happy Cat Herders Day! 😼
[10:05]  * Chipaca is happy not being a car herder
[10:07] <davmor2> Chipaca: car herder is just a posh name for a carpark attendant right
[10:07] <Chipaca> davmor2: i read it as "manager"
[10:07] <Chipaca> davmor2: so yes
[12:11] <tzununbekov> Hi all. We have package that mounts Btrfs volume in SNAP_DATA_PATH. When we update this package, all data is copied from old data path to new, but volume is still mounted in old one. This causes a doubling of used disk space. asac , ogra_ , Chipaca , is there any way to handle it?
[12:12] <Chipaca> tzununbekov: at the moment unfortunately no, but there will be soon
[12:12] <ogra_> i guess only by mounting your volume one level up (which you cant do from your snap i guess)
[12:13] <ogra_> if you work on a standalone device you could also just label your btrfs volume "writable", copy the actual writable partition content into it and drop the label from the original writable partitions
[12:13] <ogra_> -s
[12:14] <Chipaca> tzununbekov: that is, there is going to be a place where you can put things to not have them copied over, but it's not there yet
[12:15] <ogra_> right
[12:15] <ogra_> in the current setup you can only mangle stuff on a system level to make it work
[12:16] <ogra_> (it ould still be duplicated but you have both copies in your btrfs)
[12:16] <ogra_> *would
[12:17] <tzununbekov> ogra_, as workaround, we are mounting btrfs into /mnt but we think it's not Snappy way :)
[12:18] <ogra_> well, the snappy way is very flexible :)
[12:18] <ogra_> if you build an appliance i guess /mnt is suitable
[12:18] <tzununbekov> Chipaca, when we can wait for this feature?
[12:18] <ogra_> if you build a snap package just for the store, expecting /mnt is indeed imposssible
[12:19] <Chipaca> ogra_: but then so is mounting something
[12:19] <ogra_> right
[12:20] <tzununbekov> ogra_, is there any way to have our own store for appliance if we need updates?
[12:21] <ogra_> you can have some sub-store for your product, yes
[12:21] <ogra_> beuno is your man for this :)
[12:22] <tzununbekov> nice, where can we read more about sub-store thing?
[12:22] <beuno> tzununbekov, hi!  Yes, I can hook you up with some of our commercial folks to help you with that
[12:22] <beuno> tzununbekov, drop an email to: maarten.ectors@canonical.com
[12:23] <beuno> he'll get you sorted
[12:23] <tzununbekov> beuno, sub-store is commercial product? :D
[12:24] <beuno> tzununbekov, it depends on what you need from it. I'd suggest you discuss it a bit and see what the options are
[12:25] <beuno> we generally prefer software is widely available for all devices, but if someone wants to build a self-contained product we have some tools to help them out
[12:26] <tzununbekov> thank you, guys, we should discuss it in our team :)
[12:52] <jdstrand> sergiusens: re xenial/all snaps. ok, well, the review tools that understand all snaps is in xenial now. if you wnat them somewhere else too, let me know
[12:58] <sergiusens> jdstrand, no worries, and I am off today all through Wednesday and Thursday so I have no rush at all :-)
[14:24] <stevebiscuit> Chipaca: just a small MP if you could be so kind - https://code.launchpad.net/~stevenwilkin/webdm/snaps-always-have-origins/+merge/280595
[14:26]  * Chipaca looks at the mp
[14:26]  * Chipaca looks at stevebiscuit 
[14:26] <Chipaca> stevebiscuit: I don't know enough about webdm to know whether this will blow up all over the place or not
[14:26] <Chipaca> stevebiscuit: are you working on webdm now? that is, if this blows up, are all the pieces yours?
[14:26] <beuno> Chipaca, he is
[14:27] <stevebiscuit> :D
[14:28] <Chipaca> i'm happy to rubber stamp this; i'd be happier if sergio could give it a look at least at first
[14:28] <Chipaca> but he's not around and i don't want to block steve
[14:29] <beuno> Chipaca, to be fair, nothing breaks until a snap is uploaded
[14:29] <Chipaca> exactly why i'm so lackadaisical about this :-)
[14:31] <stevebiscuit> Chipaca: ta. Sergio had commented yesterday about snaps always having origins which would eventually become assertions
[14:32] <kyrofa> elopio, sorry, computer crash
[14:34] <plars> fgimenez: elopio: I tried a merge of the no_init and the gocheck_list branch here, and it doesn't seem to work right for me, but could be something I'm messing up. Also I'm just running it on my local machine, since all I'm trying to do right now is get a list of tests
[14:36] <Chipaca> stevebiscuit: while the snaps themselves have an origin in the theoretical sense, the system as it stands doesn't always use that origin to address things, and some parts will break if you try to use a full name where a bare name is expected
[14:36] <Chipaca> stevebiscuit: if webdm is abstracting that stuff away, then good job :-)
[14:36] <plars> elopio: first, go test -c ./integration-tests/tests -o ./integration-tests/bin/integration.test doesn't seem to produce a binary in ./integration-tests/bin, it just produces ./tests.test instead
[14:37] <Chipaca> stevebiscuit: the REST API also hides that, and only shows full names (or tries to!)
[14:37] <Chipaca> stevebiscuit: so it's the right move _even if it breaks things right now_
[14:37] <plars> elopio: which does seem to show me help, so at least the no_init bits seem ok, but trying to run it with -gocheck.list or -check.list gets me nothing, it seems to try to run instead
[14:37] <Chipaca> stevebiscuit: but you still get to keep the pieces :-)
[14:38] <Chipaca> stevebiscuit: also, as you move to the rest api, please do poke me if anything doesn't work as expected, or is awkward, or could be cleaner or better or ...
[14:40] <fgimenez> plars, about the -o flag not working, that might be related with the go version, iirc it have being added more or less recently
[14:41] <stevebiscuit> Chipaca: will do. Cheers for the background. I'm happy to keep tracking things and picking up the pieces to get webdm to 16.04 :)
[14:42] <fgimenez> plars, does "./tests.test -gocheck.list" work?
[14:42] <plars> fgimenez: not as far as I can tell, it seem to try to start executing tests
[14:42] <fgimenez> plars, it seems that not all the changes proposed have been merged then
[14:43] <fgimenez> plars, you should have in place the changes from the two branches
[14:43] <plars> fgimenez: all I did was take a current branch of trunk, and merge those two branches from elopio
[14:45] <fgimenez> plars, that should be enough, can you check if integration-tests/testutils/runner/runner.go, integration-tests/tests/base_test.go and integration-tests/testutils/common/common.go have the proposed changes?
[14:49] <plars> fgimenez: yes, they are all there
[14:50] <elopio> plars: cd integration-tests/tests && go test -check.list
[14:51] <elopio> also go test -c ./integration-tests/tests/ && ./tests.test -check.list
[14:51] <elopio> both work here.
[14:52] <plars> elopio: flag provided but not defined: -test.list
[14:52] <elopio> plars: -check.list
[14:52] <plars> elopio: could this all be because I'm using go from trusty instead of something newer?
[14:52] <elopio> fgimenez: hello! I have small branches for you.
[14:52] <elopio> plars: yes, that could be a problem.
[14:53] <plars> elopio: with -check.list it just gives me a lot of test failures, seems to try to run
[14:53] <plars> elopio: which are you using then? the one from wily?
[14:53] <elopio> plars: wily and xenial.
[14:53] <plars> ok, I'll try with a newer version after the standup, thanks
[14:54] <plars> elopio: is this something to do with go itself? or gocheck? or what?
[14:54] <elopio> plars: I don't know, I haven't tried it on trusty. I'm just saying that it could be your machine, because it's working here.
[14:55] <elopio> plars: let me know how it goes in x for you.
[14:55] <plars> will do
[14:57] <Chipaca> plars: i think there's a ppa with trusty stuff you can use if you need to
[14:58] <Chipaca> mvo knows more but he's away today and tomorrow
[14:58] <Chipaca> plars: basically, everything changed, from go to libraries
[14:58] <Chipaca> so a lot of backports
[14:58] <Chipaca> i think right now there's a build failure in trusty because of crypto moving
[14:58] <Chipaca> but i haven't checked
[14:58] <fgimenez> elopio, ok, i have a couple of them for you too :)
[14:59] <elopio> fgimenez: I'm looking at them.
[14:59] <elopio> fgimenez: https://github.com/testing-cabal/subunit-go/pull/3
[14:59] <elopio> fgimenez: https://github.com/testing-cabal/subunit-go/pull/4
[15:08] <elopio> fgimenez: get yourself a smiley sticker for that urltrigger.
[15:16] <fgimenez> elopio, yes, it will be useful in terms of resource usage, and also the reports for the image builds will be more meaningful
[15:17] <elopio> fgimenez: and I'm not sure if you saw the ping here: https://github.com/ubuntu-core/snappy/pull/257
[15:17] <elopio> I hope I didn't duplicate your work.
[15:17] <fgimenez> elopio, sure http://162.213.35.179:8080/job/stress/ i was waiting until we have that straight line long enough :D
[15:18] <elopio> woot
[15:18] <elopio> fgimenez: I did some runs yesterday and got permission error on docker ifconfig. I'm glad that doesn't seem to be happening in there.
[15:19] <fgimenez> elopio, the ubuntuFan suite is excluded in that executions using the tag
[15:19] <elopio> fgimenez: so when you are happy with the stress testing, you'll land the PR and enable the comments in github??? ^_^
[15:20] <fgimenez> elopio, i think so, i wanted to coordinate with you, but we are ready to go
[15:22] <elopio> fgimenez: go for it! I'm picturing an image of you pushing a huge red button.
[15:22] <elopio> fgimenez: I'll try to reproduce the fan problem and report a bug if it's still happening.
[15:26] <Chipaca> elopio: we could get fgimenez a http://www.amazon.co.uk/dp/B004D18MCK
[15:26] <fgimenez> elopio, for doing the PR thing properly we should create a bot user in github, and one of the owners should add it as a collaborator in the project
[15:26] <fgimenez> Chipaca, elopio please!
[15:27] <elopio> +1, he's earned it.
[15:28] <elopio> fgimenez: Chipaca is owner.
[15:28]  * Chipaca owns ALL the things
[15:30] <fgimenez> Chipaca, elopio ok, any github user will do, you should send me the username and pass to put them in jenkins, once the user is a collaborator of the project all should be working
[15:31] <fgimenez> Chipaca, elopio i can create the user, but perhaps the email should be one owned by the team? also i'm not good with bot names :)
[15:31] <elopio> Chipaca: who's your favourite robot?
[15:34] <Chipaca> elopio: what's this robot doing?
[15:34] <Chipaca> elopio: 'm-o' might be a bad github name :-)
[15:34] <elopio> Chipaca: triggering jenkins runs and reporting the results back.
[15:36] <elopio> m-o is great :) Already taken.
[15:36] <elopio> fgimenez: lets call it snappy-m-o.
[15:37] <Chipaca> or snappy-bo
[15:39] <elopio> I'm not sure if that's a joke or you like a robot called bo.
[15:40] <Chipaca> elopio: nah, it's just a diminutive suffix (which sorta sounds like "bot")
[15:42] <fgimenez> Chipaca, elopio snappy-bo then? about the email, should i put Chipaca's? or snappy-internal? this is important in order to be able to reset the password
[15:43] <elopio> fgimenez: I'm creating snappy-m-o. I'm using the u1test@canonical.com email.
[15:43] <fgimenez> elopio, ok thx! send me the pass when you have it
[15:47] <elopio> Chipaca: please add it to the org https://github.com/snappy-m-o
[15:57] <balloons> is anyone about who might be able to help review some snapcraft packages and provide help and insight?
[15:57] <elopio> balloons: shoot. kyrofa and I might be able to help.
[15:57] <elopio> and if we can't, sergio comes tomorrow.
[15:58] <Chipaca> elopio: as a contributor, or as a member?
[15:58] <kyrofa> balloons, yeah we're here :)
[15:58] <Chipaca> elopio: if the former, to what project?
[15:59] <balloons> excellent. So I've been helping a couple students package some go applications with snapcraft. But click-review tools is failing them due to missing hooks. Let me give you the link
[16:00] <kyrofa> balloons, alright
[16:00] <balloons> Also, my own personal question. I don't see anywhere in the guides on how to test a snap package you create. I was thinking of copying it to my snappy installation and installing it, but is there a recommended way?
[16:00] <balloons> ohh.. I just now see Sideloading your snap
[16:00] <kyrofa> balloons, yeah I just sideload into a virtualized install
[16:00] <balloons> the first is here: https://github.com/RGA15071999/martini-gorm-snapcraft
[16:00] <elopio> Chipaca: it must have push rights, so it needs push & pull rights on the org.
[16:00] <kyrofa> balloons, although we're adding a "try"
[16:01] <Chipaca> elopio: you can push as a collaborator, you don't need to be an owner, but it's per-project instead of per-org
[16:01] <balloons> xcub, feel free to ask questions as well. These folks know more than me :-)
[16:01] <Chipaca> elopio: hence my question as to on what do you want it to operate
[16:01] <elopio> Chipaca: yes, collaborator to snappy.
[16:01] <kyrofa> Hey xcub :)
[16:01] <balloons> can you link to your source so they can view it also?
[16:01] <elopio> no need to make it owner.
[16:01] <xcub> https://github.com/trustmaster/gochat
[16:02] <balloons> xcub, right, but where's your yaml file
[16:02] <fgimenez> Chipaca, elopio it's explained here https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin
[16:03] <fgimenez> Chipaca, elopio the hooks have been already set up, no need for administrator rights
[16:03] <xcub> i'm on my chromebook right now and haven't pushed it to my repository, but all it really is is just a single parts: with plugin: go and source: https://github.com/trustmaster/gochat
[16:03] <Chipaca> fgimenez: so what do i need to do?
[16:04] <kyrofa> balloons, xcub and if I understand correctly, the .snap builds fine but click-review doesn't like it?
[16:04] <fgimenez> Chipaca, just invite snappy-m-o to join as collaborator, it should receive an email to confirm
[16:04] <balloons> kyrofa, yes that's correct. The review gives ERROR: could not find required 'hooks' in manifest:
[16:05] <kyrofa> Hmm... yeah we've been moving away from click underlying snappy
[16:05] <balloons> ohh, what do i need install for snappy-remote? snappy-remote: command not found
[16:05] <kyrofa> elopio, should the click review tools still be working for snappy?
[16:06] <Chipaca> fgimenez: there, i think
[16:07] <elopio> yes, mail received.
[16:07] <Chipaca> kyrofa: yes, they should
[16:07] <elopio> kyrofa: yes.
[16:07] <Chipaca> kyrofa: you might need a very recent one though
[16:07] <jdstrand> zyga: hi! fyi, I'm starting to create the agreed to capabilities. My plan is to simply upload ubuntu-core-security with all the new ones and the renamed existing ones, with symlinks from the old-named ones to the renamed ones, ideally today. This will allow people to use 'caps' in the current yaml format for everything
[16:07] <kyrofa> balloons, snappy-remote should be in here: https://launchpad.net/~snappy-dev/+archive/ubuntu/tools
[16:07] <jdstrand> zyga: and we can transition away from the symlinks after the holidays
[16:07] <elopio> balloons: what's your ubuntu version?
[16:08] <balloons> xenial, with no snappy ppa's
[16:09] <jdstrand> zyga: I think in this new world it makes sense to change the paths to not have the paltform version in the path, but I don't want to change that before the holidays and we can discuss that later
[16:09] <jdstrand> tyhicks: (fyi my last 3 comments)
[16:09] <zyga> jdstrand: hi
[16:09] <elopio> balloons: if you want to run the snaps in 15.04, you need to generate them in vivid.
[16:10] <zyga> jdstrand: that sounds good to me
[16:10] <balloons> elopio, sure, but I didn't make the snap I want to run, heh
[16:10] <elopio> balloons: I do it in an lxc.
[16:10] <zyga> jdstrand: I'm proceeding with capability type system, with plugs for apparmor, seccomp, dbus and kernel capabilities
[16:10] <balloons> elopio, ack.
[16:10] <zyga> jdstrand: I'll show you what I have tomorrow
[16:10] <elopio> balloons: right, just saying... :)
[16:10] <zyga> jdstrand: (I've manually migrated the old bool-file type)
[16:10] <elopio> I'll give it a try.
[16:11] <zyga> jdstrand: I'm also working on a way for us to cooperate around the source code
[16:11] <jdstrand> zyga: cool. I figured, the fewer code changes that need to be coordinated before the holidays, the better. that way, you can focus on code and I can policy. you can depend on where stuff lives for now, and we'll adjust after the holidays
[16:11] <balloons> Chipaca, kyrofa, so how can we know what metadata is missing? the review tools don't really say
[16:11] <jdstrand> zyga: ack, sounds fine
[16:11] <elopio> balloons: I get Issues while validating snapcraft.yaml: 'icon.png' is not a 'icon-path'
[16:11] <Chipaca> ummm
[16:12] <Chipaca> wait, you're running review-tools on snapcraft.yaml?
[16:12] <Chipaca> that doesn't sound right?
[16:12] <kyrofa> elopio, is that a 2.0 thing?
[16:12] <elopio> balloons: that's a weird way to say that you need an icon.png in the repo.
[16:12] <ogra_> elopio, "touch icon.png"
[16:12] <ogra_> :)
[16:13] <elopio> right, or that ^ :)
[16:13] <zyga> jdstrand: note that I'm still not sure gustavo will agree to standalone capabilities (as in, not baked into snappy)
[16:13] <zyga> jdstrand: though that will have to wait till next month since everyone is shutting down
[16:13] <jdstrand> zyga: you mentioned apparmor and seccomp as distinct things. today they are two things that are referenced with a single name (I know you know that). I bring this up because if they are distict as I understand your suggestion (as opposed to being combined in one 'security policy' capability), then perhaps that makes things more complicated
[16:14] <jdstrand> zyga: also, if we ever decide to change/add to the security mechanisms, then the names 'apparmor' and 'seccomp' might not make sense
[16:14] <jdstrand> zyga: food for thought-- all this can be worked out after the holiday too
[16:14] <zyga> jdstrand: they are only distinct as in concepts
[16:15] <zyga> jdstrand: it's all one thing behind each capability type
[16:15] <jdstrand> ok, cool
[16:15] <zyga> jdstrand: I haven't looked at capabilities (linux) yet
[16:15] <zyga> jdstrand: are they somehow baked into apparmor?
[16:15] <zyga> jdstrand: (dbus is standalone from what I understand)
[16:15] <jdstrand> apparmor mediates linux capabilities, yes
[16:15] <balloons> Rob1507, so elopio is saying you need an icon.png
[16:15] <jdstrand> I think you can ignore them for now
[16:15] <elopio> hello Rob1507
[16:16] <elopio> after adding the icon, I could generate the snap.
[16:16] <Rob1507> hello elopio
[16:16] <elopio> I am running xenial, so I'm doing the build in a vivid lxc.
[16:16] <Rob1507> yeah
[16:16] <Rob1507> elopio, because I haven't uploaded icon :D
[16:16] <Rob1507> I was able to generate it at home, because icon was in place
[16:17] <zyga> jdstrand: that sounds good, thanks
[16:17] <jdstrand> zyga: dbus is a little muddier. apparmor mediates dbus, but dbus bus policy (separate from apparmor) needs to be set up first
[16:17] <elopio> Rob1507: cool. So when are you getting the review tools error?
[16:17] <kyrofa> elopio, do the review tools pass after that, then?
[16:17] <zyga> jdstrand: yes, that is my understanding
[16:18] <zyga> jdstrand: from my POV, there's a bit of code that knows how to do that given some template that's associated with the type
[16:18] <zyga> jdstrand: the language in the template is different but that's all
[16:18] <Rob1507> elopio, some kind of NodeJS errors I think.
[16:18] <elopio> kyrofa: nop.
[16:18] <Rob1507>  elopio, you mean software center errors right?
[16:18] <jdstrand> zyga: sounds good
[16:19] <balloons> xcub, feel free to just you pastebin.com to paste your yaml file and share it too
[16:20] <elopio> Rob1507: hum, not trying anything related with software center here. I mean that I see your error now
[16:20] <elopio> http://pastebin.ubuntu.com/14029192/
[16:20] <balloons> elopio, right, that's what i got.
[16:21] <xcub> this is my yaml file: http://pastebin.com/0eMUYzDq
[16:21] <elopio> balloons: Rob1507: that doesn't prevent you to install the generated snap.
[16:22] <elopio> it should pass, so we probably got snapcraft out of sync with the reviewer tools.
[16:22] <elopio> Rob1507: now what you are missing is a binary or a service.
[16:23] <elopio> hello xcub
[16:23] <fgimenez> Chipaca, elopio something is wrong, snappy-m-o should have write access to the repo http://paste.ubuntu.com/14029244/
[16:23] <elopio> xcub: I could also generate a gochat snap with your yaml, after adding the icon.
[16:24] <plars> elopio: so go 1.5.1 in wily doesn't seem to be new enough either, or else something else is wrong
[16:24] <xcub> i could generate a snap as well, its just that the ubuntu software center rejects it due to some json error
[16:24] <plars> elopio: I noticed that I get different (but still failed output) if I do not only -gocheck.list but -gocheck.vv, so it's at least catching args
[16:25] <xcub> And I don't know anway to test the validity of the package
[16:25] <Rob1507> elopio, the same thing is for me
[16:25] <fgimenez> Chipaca, elopio if just giving write access to the repo is not possible (not sure about how to do this) adding the bot as a member of the organization worked fine for me in the tests
[16:25] <Chipaca> fgimenez: elopio: try this way?
[16:25] <Chipaca> (invitation pending)
[16:26] <Rob1507>  elopio, can you see which binary or service is missing
[16:26] <elopio> Chipaca: fgimenez: accepted.
[16:26] <Chipaca> fgimenez: try now?
[16:26] <balloons> xcub, Rob1507 install click-reviewers-tools if you want to run the review on your snaps
[16:26] <elopio> Rob1507: no, I mean that for your snap to do something useful, it needs to expose a binary or service.
[16:26] <fgimenez> Chipaca, elopio so cute! :D https://github.com/ubuntu-core
[16:27] <xcub> what do you mean by expose a binary or service?
[16:28] <Rob1507> elopio, If i want to snap a number converter program, which service i need to expose?
[16:29] <elopio> xcub: Rob1507: take a look at https://github.com/ubuntu-core/snapcraft/blob/master/examples/godd/snapcraft.yaml
[16:29] <elopio> see how it defines a binaries section, and in there it tells how to execute the program.
[16:29] <elopio> without that, the snap files will be installed but there will be nothing to run.
[16:29] <Rob1507> elopio, It makes sense, I will take a look now :)
[16:30] <elopio> balloons: I'm not sure what is this about the software store.
[16:30] <elopio> there is a bug somewhere with the review, clearly, but I can upload the snap to myapps.
[16:30] <xcub> ohhh, so after I run snapcraft the first time, I can take a look in the snap directory and see where the binary is, the update the .yaml file to where it is?
[16:31] <elopio> ahh, there I see the json error.
[16:31] <elopio> okay, I'll report the bug.
[16:32] <Chipaca> fgimenez: is it working?
[16:33] <balloons> elopio, I asked them to upload the apps to myapps for publishing
[16:34] <fgimenez> Chipaca, yes, it can connect :) https://github.com/ubuntu-core/snappy/pull/253, here, clicking in "Show all checks" there's a new "integration test" entry written by the bot
[16:34] <elopio> Rob1507: xcub: balloons: once you add the binary, the click review passes.
[16:34] <elopio> so the bug is that the error message when you don't define a binary is terrible.
[16:34] <Chipaca> fgimenez: woop woop
[16:35] <fgimenez> Chipaca, we'll see it working with the next PR, including a link to the jenkins job in the VPN
[16:35] <Rob1507> elopio, sorry for that
[16:35] <elopio> Rob1507: hey, not your fault at all.
[16:35] <elopio> thanks for finding a bug.
[16:37] <xcub> thank you for your help, elopio.
[16:37] <plars> elopio: fgimenez: this is what I get: http://paste.ubuntu.com/14029558/
[16:38] <elopio> plars: right, it's running the setup for you. Give me a second to set it up in wily again.
[16:55] <elopio> dholbach: kyrofa: Now we have some docs about python and java in parts.md, and docs about ros in ros.md.
[16:56] <elopio> should we put all of them in parts.md, or separate all of them in different files?
[16:57] <dholbach> elopio: I think if we have more content for a particular part we can move it into its own file(?)
[16:57] <dholbach> elopio: the bits about java and python looked to me like they only illustrated what parts can look like
[16:57] <dholbach> so like an extension of the article
[16:58] <dholbach> that's also how it was structured in the app developer manual
[16:58] <dholbach> (where I stole the docs from :-))
[16:58] <elopio> dholbach: that makes sense. ros is too big to put it in there.
[16:58] <dholbach> yep
[16:59] <dholbach> all rightie... I call it a day - see you all tomorrow :)
[16:59] <kyrofa> elopio, yeah that would make for a massive file, especially as we have more documented plugins
[17:05] <elopio> plars: this is on wily: http://paste.ubuntu.com/14030135/
[18:32] <kyrofa> elopio, can you take another look at https://github.com/ubuntu-core/snapcraft/pull/163 when you're able? It should be ready to go-ish
[18:35] <elopio> kyrofa: sure, I'm just missing to review the tests. I'll do that after lunch.
[18:35] <elopio> kyrofa: I'm +1 on landing it, but I'm not sure if Sergio's comment meant he wanted to give it a full review.
[18:35] <kyrofa> elopio, ah right, forgot about that
[18:45] <Rob1507> elopio, sorry, but can you just remind which package I need to use for review?
[18:46] <elopio> Rob1507: install click-reviewers-tools, and then run click-review /path/to/file.snap
[18:47] <Rob1507> elopio, ok thanks
[18:52] <Rob1507> elopio, and what result should I have?
[18:52] <Rob1507> pass?
[18:53] <elopio> Rob1507: yup, pass.
[18:53] <elopio> then when you upload to myapss, it will pass too. It's the same tool they use to check.
[18:53] <Rob1507> elopio, wonderful, thanks for great help ^_^
[18:54] <elopio> Rob1507: np. Thanks to you.
[19:02] <plars> elopio: so did you have to do something different?
[19:03] <plars> elopio: doing it that way, for me, gives me exactly the same as the pastebin I sent earlier
[19:14] <Rob1507> elopio, can I ask something?
[19:18] <kyrofa> Rob1507, you never need to ask :)
[19:18] <kyrofa> Rob1507, rather, ask to ask, heh
[19:19] <Rob1507> kyrofa, I want to port a go app, but cannot find any application that may be useful. Can you suggest one?
[19:20] <kyrofa> Rob1507, just any go app? Oof
[19:20] <kyrofa> Rob1507, when you say "port," do you mean package as a .snap?
[19:21] <Rob1507> kyrofa,
[19:21] <Rob1507> kyrofa, Yes, creating .snap
[19:22] <Rob1507> kyrofa, I have done one. It is working but it was testing program. I want to take one that may be useful for others
[19:24] <kyrofa> Rob1507, I don't have one off the top of my head, but it might be useful to look at the trending GitHub repos written in Go: https://github.com/trending?l=go
[19:26] <Rob1507> kyrofa, I look at them. Actually I choosed test program from there :D . What do you think, may goplay be useful?
[19:26] <Rob1507> it is html5 player
[19:28] <kyrofa> Rob1507, I've not seen that one
[19:28] <kyrofa> https://github.com/otium/ytdl might be useful
[19:31] <Rob1507> kyrofa, great suggestion, thanks :D
[19:31] <kyrofa> Rob1507, sure thing
[19:53] <plars> elopio: I also tried putting it on snappy and running it from there, I still get the same errors
[19:53] <plars> elopio: do I need to set up this json config file first for it or something? It complains a lot about that
[19:58] <Rob1507> kyrofa, https://myapps.developer.ubuntu.com/dev/click-apps/4184/
[19:59] <kyrofa> Rob1507, I don't have permission to access that page
[19:59] <kyrofa> Rob1507, I assume that's only yours?
[19:59] <Rob1507> kyrofa, sorry :D
[20:07] <Rob1507> kyrofa, One more thing. I published work on myapps. Can you access it?
[20:08] <kyrofa> Rob1507, to the length of my knowledge, myapps only shows your own apps
[20:08] <kyrofa> Rob1507, so: no. I can only see mine :)
[20:09] <Rob1507> kyrofa, how can I share it?
[20:09] <Rob1507> GitHub?
[20:09] <kyrofa> Rob1507, you did in fact publish it? Then it should be in the store once the approval passes
[20:10] <Rob1507> it's status is published
[20:15] <kyrofa> Grrr.... elopio I need your help
[20:20] <Rob1507> kyrofa, I can send you .snap
[20:20] <kyrofa> Rob1507, if it's published I can grab it from the store. Are you wanting me to do something with it?
[20:22] <Rob1507> yes just test it
[20:34] <kyrofa> elopio, ah, nevermind, I went another direction with it
[20:35] <kyrofa> elopio, I think there's a bug somewhere with python coverage with respect to exceptions
[20:43] <plars> elopio: ok, so I figured out what was wrong, and managed to fix it for me, but there *must* be a better way than what I did
[22:47] <xcub_> elopio, can you review my task: https://codein.withgoogle.com/dashboard/task-instances/5486692492378112/
[23:22] <camako> ted, we were talking about the rasp pi2 graphics drivers yesterday. Do you know where I'd get the android drivers?
[23:23] <camako> tedg ^
[23:24] <tedg> camako: I don't know about the android ones, but there are X ones. I think that ogra_  has instructions on using,them, but I'm not sure where they are. Probably a bit late for him.
[23:25] <camako> tedg, o ok.. mesa drivers perhaps? I'll ask him tomorrow. thanks..