[00:13] <fazer> I'm trying to rebase my branch on git and it says could not apply 'commitxyz'. Does nayone know how I can fix this?
[07:31] <shuduo> is there any way to specify archive mirror server for snapcraft local plugin using instead of automatically pick up by determined by IP geo?
[08:15] <zyga> good mornign
[08:15] <zyga> focus for today: capability security
[09:18] <JamesTait> Good morning all!  Happy Thursday, and happy Organise Your Home Day! 😃
[09:24]  * zyga pushed https://github.com/ubuntu-core/snappy/pull/324
[09:24] <zyga> same security aspect of bool file as in one of the earlier merge request
[09:24] <zyga> s
[09:24] <zyga> this time based on the type interface patches
[10:08] <Chipaca> ogra_: https://www.treats4geeks.com/
[10:09] <Chipaca> ogra_: a quad-core imx6 with wifi+bt+3g+gps+9-axis imu
[10:10] <Chipaca> not cheap tho
[10:16] <ogra_> well, it has a lot of stuff on board :)
[11:11] <persistentstorag> Hi! Where would I write persistent data to? Let's say I ran my seedbox as a collection of snaps. Looking for something similar to docker data volumes, or a home directory.
[11:12] <ogra_> SNAP_APP_DATA_PATH or SNAP_APP_USER_DATA_PATH point to writable spaces in the snap env (the latter only for binaries a user can execute, the foremer is the writable and persistent package dir)
[11:13] <ogra_> hmm, probably without "APP", sorry
[11:18] <persistentstorag> SNAP_APP_DATA_PATH seems to be what I'm looking for, thanks!
[11:21] <enoch85> kyrofa, let's get to work ;)
[11:28] <zyga> ogra_: hey :)
[11:47] <shuduo> is there any way to specify archive mirror server for snapcraft local plugin using instead of automatically pick up by determined by IP geo?
[12:27] <kyrofa> enoch85, hey there :)
[12:29] <enoch85> kyrofa, hey :9
[12:29] <enoch85> :)
[13:34] <sergiusens_> kyrofa, here's a small present https://github.com/ubuntu-core/snapcraft/pull/230
[13:34] <sergiusens_> good morning
[13:34] <kyrofa> sergiusens_, good morning!
[13:35] <kyrofa> sergiusens, wait... why didn't we hit that before?
[13:36] <sergiusens> kyrofa, I have no clue; maybe check if /usr/bin/python exists on 15.04
[13:36] <sergiusens> which it might as well
[13:36] <kyrofa> Yeah that's what I'm assuming
[13:36] <kyrofa> It does indeed exist
[13:36] <kyrofa> But it's been removed on xenial eh?
[13:37] <sergiusens> hah, there we go; yeah, cloud-init moved to python3 so that might have removed the dep
[13:37] <sergiusens> kyrofa, it still fails though
[13:37] <sergiusens> kyrofa, [rosrun] Couldn't find executable named listener below /snaps/ros-example.sideload/IKKNUNfbERGD/opt/ros/indigo/share/beginner_tutorials
[13:38] <sergiusens> kyrofa, I see talker under lib though (it is looking for it in share)
[13:38] <sergiusens> kyrofa, this part of ros is black magic to me
[13:38] <kyrofa> Yeah it shouldn't be looking in there... odd
[13:39] <sergiusens> kyrofa, any clues where to look?
[13:43] <kyrofa> sergiusens, no that's never happened to me before
[13:44] <kyrofa> sergiusens, I do plan on looking into this by the way... just trying to knock out the .snaps first
[13:44] <kyrofa> sergiusens, I feel like you're procrastinating on those slides... ;)
[13:45] <sergiusens> kyrofa, sure, maybe we land this PR as is then? It does fix the specific bug :-P
[13:45] <sergiusens> kyrofa, slides ... right and look at the time
[13:45] <sergiusens> darn
[13:45] <kyrofa> sergiusens, hahaha
[13:46] <kyrofa> ogra_, is this still valid? "Note: the snappy update command will currently not work with Raspberry Pi 2 images. It requires hosting the device tarball on a system-image server, which is not yet available."
[13:47] <sergiusens> kyrofa, use mvo's recently announce pi2 images (if you are looking into rolling)
[13:51] <kyrofa> sergiusens, no I'm just trying to figure out if that comment it out of date. People are suggesting not to use Core on the rpi2 due to it
[13:54] <sergiusens> kyrofa, I suppose with mvo's announcement that is indeed out of date for rolling
[13:55] <mvo> kyrofa: pi2 in rolling will update just fine
[13:55] <mvo> kyrofa: well, unless there are nasty bugs of course
[13:55] <kyrofa> sergiusens, does autopilot automatically update all installed snaps?
[13:55] <kyrofa> mvo, excellent thank you
[13:57] <sergiusens> kyrofa, it is of course not production ready, but it is tinkerer ready
[13:57] <kyrofa> sergiusens, right, of course
[14:09] <sergiusens> kyrofa, one more https://github.com/ubuntu-core/snapcraft/pull/231
[14:57] <elopio> kyrofa: so, what I'm thinking is that after you are done with owncloud you would enjoy packaging syncthing ^_^
[14:57] <kyrofa> elopio, how have I not heard of that?
[14:59] <elopio> hipster synching.
[14:59] <kyrofa> Hahaha
[15:03] <kyrofa> elopio, this has been an excellent experience though. I feel like it's really pushing snapcraft
[15:05] <peacememories> question: is there an api for snappy that e.g. a framework could use to control it?
[15:12] <kyrofa> peacememories, control what exactly?
[15:12] <peacememories> installing .snap files, for example
[15:13] <kyrofa> peacememories, can you explain what you have in mind?
[15:13] <kyrofa> peacememories, e.g. you just described webdm. Have you used that?
[15:14] <peacememories> not yet, no. gimme a second, looking into it
[15:14] <kyrofa> peacememories, the short answer to your question is yes. The longer answer is that you may be trying to do something that has already been done :)
[15:15] <peacememories> what i'm trying to achieve: control what version of a software is installed on the device (stereomatching engine on a stereo camera)
[15:15] <peacememories> remotely, of course
[15:15] <kyrofa> peacememories, via something other than SSH I assume?
[15:16] <peacememories> yes
[15:16] <kyrofa> peacememories, GUI only?
[15:16] <peacememories> actually without any gui, i guess. there will be a gui, but that will probably be built in house
[15:17] <kyrofa> peacememories, yeah, look at webdm. You may like that. If it doesn't do exactly what you want consider contributing to it
[15:17] <kyrofa> peacememories, failing that, yes, there's an API you can use
[15:17] <kyrofa> peacememories, Chipaca is your best resource regarding that, I think
[15:18] <kgunn> mvo: i'm sure you have plenty to do, but wondering if you might want to jot down an idea for u-d-f, when i create my core image...i always need to resize afterward (my mir stuff is meaty)
[15:19] <kgunn> wondering if you might add a size option
[15:20] <kyrofa> kgunn may be something you want to mention to sergiusens. He's been talking about revamping u-d-f
[15:21] <peacememories> btw, does snappy support having multiple versions of a software installed, with one being active?
[15:22] <kgunn> sure
[15:23] <peacememories> that's definitely neat
[15:23] <peacememories> still trying to wrap my head around where to put everything and how to manage software on an embedded snappy device
[15:23] <kgunn> oh peacememories lol, sure @letting sergiusens know
[15:23] <kgunn> but i suppose the answer is still yes to that
[15:23] <peacememories> oh^^
[15:24] <kgunn> peacememories: but i should let the experts speak
[15:24] <kyrofa> peacememories, kgunn perhaps the better answer is "kinda"? I'm not sure you can have a newer version installed while the older is active
[15:24] <kgunn> right...
[15:24] <kgunn> it always takes the latest
[15:24] <kyrofa> peacememories, but the old versions remain there, yes
[15:24] <kyrofa> peacememories, to allow for rollbacks
[15:25] <peacememories> hmm
[15:26] <kyrofa> Chipaca will know if there's a way around that
[15:28] <peacememories> maybe what i'm trying to do would be abusing the snappy architecture. seems a bit like it
[15:29] <peacememories> i'm trying a bit hard to make this work, mainly because i don't know any other small embedded distros with AB-partition update capabilities
[15:30] <kyrofa> peacememories, what are you trying to accomplish with the multiple versions?
[15:30] <peacememories> kyrofa, the ability to quickly choose the running version of a software via a management interface
[15:30] <peacememories> i could do a workaround that saves the .snap files on the system and uses a local install
[15:31] <mvo> kgunn: hi, there is a --size option :) is it not working?
[15:31] <kyrofa> peacememories, that may be a better idea
[15:31] <kgunn> mvo: doh!
[15:31] <kyrofa> peacememories, I'm afraid anything else may result in trying to fight snappy
[15:31] <peacememories> our semantics would probably be the same as 'rollback' anyway, but the current idea for the management interface doesn't mesh too well with that :/
[15:32] <kyrofa> peacememories, there's a problem though
[15:32] <peacememories> hm?
[15:32] <kyrofa> peacememories, upgrades copy the old version's data, rollbacks go back to the old version of the data. Uninstalling and installing a new one won't do either-- data would be empty
[15:33] <kyrofa> peacememories, does the .snap in question have data?
[15:33] <peacememories> not right now, no. a different snap might, though
[15:34] <kyrofa> peacememories, something to keep in mind then
[15:34] <peacememories> i'm assuming a .snap install of a newer version doesn't register as an upgrade?
[15:35] <kyrofa> peacememories, hmm... good question. Sideloaded I'd say no, but if not sideloaded I'm not sure what happens. You may even get a "already installed" type of error. mvo do you know the answer to that?
[15:36] <kyrofa> Well, I'm not sure how you'd accomplish what you're trying without sideloading, so perhaps the answer to your question is no
[15:37] <kyrofa> peacememories, though it's important to point out that copying the data is as easy as cp -r over ssh
[15:37] <elopio> oh sad day.
[15:38] <kyrofa> elopio, what's up?
[15:38] <elopio> stgraber: the lxd import started failing on travis.
[15:38] <elopio> Image manifest: http://cloud-images.ubuntu.com/server/xenial/20160105/xenial-server-cloudimg-amd64.manifest
[15:38] <elopio> error: HTTP Error 404: Not Found
[15:38] <kyrofa> elopio, is that what you're using in the tests?
[15:38] <elopio> that URL indeed returns a 404. Do I need to update something?
[15:39] <elopio> kyrofa: I'm just asking for the daily xenial.
[15:39] <kyrofa> change the datetime to current?
[15:39] <kyrofa> elopio, datestamp, rather
[15:39] <kyrofa> elopio, http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64.manifest
[15:41] <elopio> kyrofa: I'm not sure where to put the date. The command is "lxd-images import ubuntu xenial --stream daily --alias ubuntu"
[15:41] <kyrofa> elopio, oh...
[15:41] <kyrofa> elopio, stgraber question then, I suppose?
[15:42] <elopio> pindonga: good I gave you an ETA of friday. The branch was all green for a couple of hours, then we had the travis outage, and now this.
[15:42] <elopio> it's cursed.
[15:42] <pindonga> :(
[15:47] <kyrofa> elopio, have you built a cmake part before?
[15:57] <mvo> kyrofa: uh, sorry, was in a meeting. is the question still open?
[15:57] <kyrofa> mvo, I don't think so, no worries :)
[15:58] <elopio> kyrofa: I don't think os.
[15:58] <elopio> *so
[16:02] <stgraber> elopio: xenial simple stream is busted, the cloud team is on it
[16:05] <kyrofa> elopio, how would you feel if we added some sort of installflags option to the autotools/cmake/make plugins?
[16:05] <kyrofa> elopio, I really want a make -j8 here :P
[16:06] <kyrofa> elopio, compiling some things single threaded take forrrreeeever.
[16:06]  * kyrofa looks at mysql
[16:06] <elopio> stgraber: ah, thanks for the info. I'll wait.
[16:07] <elopio> kyrofa: I would like that. But if feels weird to hardcode j8 on your yaml.
[16:07] <kyrofa> elopio, can you think of a better way?
[16:07] <elopio> kyrofa: it would be really cool to be able to pass command line args from the snapcraft binary to the plugin. But sounds messy too.
[16:07] <kyrofa> Hmm... yeah that sounds more involved. But I agree
[16:08] <elopio> maybe something like --plugin-flag autotools:-j8
[16:08] <elopio> I have the feeling that Sergio will hate this :)
[16:09] <kyrofa> Me too. I can imagine installflags being useful for things other than things as hardware-dependent as -j though. For instance, the apache installation has a number of "install this elsewhere" type of flags
[16:09] <kyrofa> Wow that sentence had terrible grammar. I'm sorry
[16:10] <kyrofa> elopio, so maybe since that gets us part way there, it's a better solution for now?
[16:10] <elopio> I think I got it. Maybe a config file? I wonder how juju does it.
[16:10] <elopio> I mean,  I think I got what you meant on that sentence, not that I got the solution.
[16:11] <kyrofa> Heh
[16:11] <elopio> kyrofa: if you pass -j8 and you have less than 8, it will just do less parallelization right? So it's not terrible to hardcode it.
[16:12] <elopio> then you can plug it to a fancier way to receive the value. Config or command line, or smart guess.
[16:12] <kyrofa> elopio, right, it'll make 8 threads and they just won't be able to work concurrently
[16:14] <kyrofa> elopio, so you think the installflags sounds okay? If the .snap author wants to hardcode something, it's his problem
[16:14] <elopio> fgimenez: https://xkcd.com/1629/ That's you explaining your jenkins farm :D
[16:17] <fgimenez> elopio, not enough tools IMO but accurate anyway :D
[16:17] <kyrofa> elopio, have you ever listened to explanations of openstack? http://cube-drone.com/comics/c/alien-geometries
[16:18] <elopio> haha, yes. Swipes left for tinder. lol.
[16:20] <peacememories> hm, the path to deploy snappy as a 'firmware' is a lot more clear than the path to keep said firmware up to date
[16:20] <kyrofa> My favorite is "Trove -> Mostly just sits there." I never could figure that thing out
[16:30] <kyrofa> peacememories, how so?
[16:31] <kyrofa> peacememories, keeping it up to date is one of the biggest upsides to snappy
[16:32] <peacememories> to keep my snaps up to date seems to require them being in the official store though
[16:32] <peacememories> ideally i'd like to have the ability to do a firmware upgrade a la digital cameras
[16:33] <peacememories> which would basically be "update the oem snap", which doesn't seem to be possible
[16:33] <kyrofa> peacememories, completely offline?
[16:33] <peacememories> that's one of the requirements, yes
[16:34] <peacememories> there's two update modes for us atm: a managment server tells sends the software to the device and tells it to update
[16:34] <peacememories> or a user plugs in a usb with an update
[16:35] <kyrofa> peacememories, I know there are ongoing discussions about private stores, but that's something I don't know much about (I'd refer you to bueno, but he doesn't seem to be around at the moment)
[16:35] <peacememories> our structure is not really set in stone yet, but can't come up with many other ideas
[16:36] <peacememories> yeah, i've read about private stores being 'on the horizon'
[16:36] <kyrofa> peacememories, yeah you're not the only person that's looking for that. I'm just not sure what the state of it is exactly
[16:36] <kyrofa> peacememories, I suggest you send out a snappy-devel mailing list post about it
[16:37] <kyrofa> peacememories, that way you can be sure the right eyes see it rather than trying to wait until they're on IRC
[16:37] <peacememories> i'll do that. also i'll need to test whether using snappy install *.snap can upgrade packages
[16:37] <peacememories> thanks for your help so far =)
[16:38] <kyrofa> peacememories, no problem, sorry my knowledge is a bit limited :)
[16:39] <peacememories> i wish there was more info out there about deploying embedded systems^^ this is my first voyage into the field and it's pretty daunting
[16:40] <kyrofa> peacememories, the problem you often run into is that embedded systems are almost always proprietary
[16:40] <kyrofa> peacememories, so not a lot on google
[16:40] <peacememories> indeed
[16:41] <kyrofa> peacememories, but there are some open-source embedded communities, like the rpi, gumstix, and ubuntu core
[16:41] <kyrofa> peacememories, lots of "learn by doing" in your future ;)
[16:42] <peacememories> yep. not sure if i'm looking forward to that^^
[16:43] <kyrofa> peacememories, not the fastest way to learn, but one of the best
[16:43] <peacememories> i should probably write a blog about this stuff. add a bit to the information out there, even if it's just 'how not to do it'
[16:44] <kyrofa> peacememories, definitely
[17:20] <peacememories> okay, so when i install with --allow-unauthenticated my snap gets installed as sideloaded
[17:20] <kyrofa> peacememories, right
[17:21] <peacememories> and i assume the only signatures snappy accepts are from the ubuntu store
[17:21]  * zyga posted https://github.com/ubuntu-core/snappy/pull/326
[17:21] <zyga> this lets capability types hand out bits of security for variou security subsystems
[17:22] <zyga> another approach at the security aspect
[17:22] <kyrofa> peacememories, indeed, which leads back to the private store
[17:22]  * peacememories sighs
[17:22] <zyga> jdstrand: ^^ perhaps you can have a look
[17:22] <zyga> jdstrand: it's different from the earlier approach
[17:22] <zyga> jdstrand: but I think this is closer in intent to what hwaccess was doing than before
[17:23] <zyga> jdstrand: one thing I'd love to know about is how device nodes are pushed to the dev namespace today (who's doing that)
[17:23] <zyga> jdstrand: because nothing in the design handles that yet
[17:58] <sergiusens> kyrofa, hey, you are indeed right that there is no shebang; there is although an "embedded shebang"
[17:59] <kyrofa> sergiusens, huh? :P
[17:59] <kyrofa> sergiusens, I mean, no #! or anything
[18:00] <kyrofa> sergiusens, compiling mysql is taking so long I have time to look into this all of a sudden :P
[18:01] <sergiusens> kyrofa, http://paste.ubuntu.com/14497580/ line 30 there is originally /usr/bin/python
[18:02] <kyrofa> sergiusens, indeed, and I have more lines than you between 1-3
[18:02] <sergiusens> kyrofa, which may indicate that I fixed this incorrectly
[18:02] <kyrofa> sergiusens, with another /usr/bin/python. But still no #!, which means the regex won't catch it... no?
[18:02] <jdstrand> zyga: I haven't looked at the code yet, but to answer your question: hw-assign creates /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules and /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml
[18:03] <sergiusens> kyrofa, or maybe is too greedy
[18:03] <sergiusens> kyrofa, I'll look at it now
[18:03] <kyrofa> sergiusens, alright. I'm looking into the stupid share thing now
[18:03] <jdstrand> zyga: then hwaccess updates the profile for what is in /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml
[18:03] <sergiusens> kyrofa, what share?
[18:03] <jdstrand> zyga: s/profile/security policy/
[18:03] <sergiusens> kyrofa, getting rid of the ros plugin altogether? :-)
[18:04] <kyrofa> sergiusens, ha! I mean launching out of share instead of lib
[18:04] <sergiusens> kyrofa, k, it might be related
[18:04] <zyga> jdstrand: oh, thanks I didn't know about the udev rule!
[18:04] <zyga> jdstrand: I'll add that
[18:05] <jdstrand> zyga: then on app launch, ubuntu-core-launcher sees if /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules exists. if it doesn't, it just launches the app in the normal way. if it does, it creates a device cgroup and puts the devices in /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules into an app-specific cgroup
[18:06] <jdstrand> zyga: in this manner, apparmor prevents reading devices when no hardware is assigned, and cgroups allow the device to be used by the app
[18:06] <zyga> jdstrand: so /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml + /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules
[18:06] <zyga> jdstrand: do we need to run a command to recompile anything after those two are made?
[18:06] <jdstrand> in an ideal world we wouldn't use a cgroup for this and just rely on apparmor, but that is the parser performance conversation we had before
[18:07] <jdstrand> zyga: yes, snappy needs to regenerate the apparmor policy if /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml is created/updated/removed
[18:08] <zyga> jdstrand: how is that done (regenerate)
[18:08] <jdstrand> zyga: but it shouldn't regenerate the policy if /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml is unchanged
[18:08] <jdstrand> (the regeneration is the slow (relatively) operation)
[18:09] <jdstrand> zyga: see AddHWAccess(). it calls regenerateAppArmorRules(snapname)
[18:10] <zyga> jdstrand: ok, I'll follow that along
[18:10] <zyga> jdstrand: I'll try to get apparmor support sufficient to blink LEDs on raspberry pi tomorrow
[18:10] <zyga> (without hwaccess)
[18:10] <jdstrand> zyga: hwaccess.go should be fairly easy to follow with the above context
[18:11] <jdstrand> zyga: cool!
[18:16] <sergiusens> kyrofa, this is what I have in the catkin part originally http://paste.ubuntu.com/14497678/
[18:17] <kyrofa> sergiusens, yeah, same
[18:18] <sergiusens> kyrofa, ah, the regex wipes line 4 and 5 :-)
[18:18] <sergiusens> err 3 and 4
[18:19] <kyrofa> sergiusens, how is that possible? It looks for # followed by !. The .* is perhaps too greedy, but what about that?
[18:20] <sergiusens> kyrofa, yeah, it should be a broken file in the end
[18:21] <kyrofa> sergiusens, no... it shouldn't match lines 3-4 at all!
[18:21] <kyrofa> sergiusens, right?
[18:21] <sergiusens> oh because of the !
[18:21] <kyrofa> Right
[18:24] <sergiusens> kyrofa, more so, the regex matches nothing on this file ;-)
[18:24] <kyrofa> sergiusens, exactly!
[18:25] <sergiusens> kyrofa, the first line says it is autogenerated though; any idea if that is during packaging or during unpack or what?
[18:25] <kyrofa> sergiusens, I expect it's during compilation
[18:25] <kyrofa> So during packaging
[18:25] <sergiusens> kyrofa, of ros itself
[18:25] <kyrofa> Right
[18:25] <sergiusens> right
[18:27] <kyrofa> Figured out the rosrun problem
[18:28] <kyrofa> More shebangs
[18:28] <kyrofa> sergiusens, time for a grep... what are we dealing with here now that python2 is no longer on the image...
[18:29] <elopio> woohoo, lxd working again.
[18:29] <sergiusens> kyrofa, maybe take over the MP and I'll get to the other things
[18:29] <sergiusens> elopio, nice
[18:29] <kyrofa> sergiusens, perhaps instead of patching just _setup_util, the post build step should be one big search/replace. Yeah I got it
[18:41] <sergiusens> kyrofa, I hope the second sentence was a mid reply and not you writing to yourself ;-)
[18:41] <kyrofa> sergiusens, :P
[18:44] <sergiusens> kyrofa, I myself seem to have started out the day with the wrong foot :-)
[18:44] <kyrofa> sergiusens, hahaha
[18:45] <kyrofa> sergiusens, you got your car at least?
[18:48] <sergiusens> kyrofa, yeah, I got there and it seemed there was a screw up on when I was supposed to pick it up
[18:48] <sergiusens> at least it was all checked up; just missing the final "car wash"
[18:48] <kyrofa> sergiusens, that sounds annoying
[18:49] <sergiusens> kyrofa, yeah, and no ranting emails from ogra_ to read on my phone :-)
[19:59] <sergiusens> kyrofa, now that this passsses (with many s's), care to look https://github.com/ubuntu-core/snapcraft/pull/231 ?
[19:59] <sergiusens> kyrofa, it will make testing the listener and talker easier
[20:28] <enoch85> kyrofa, here?
[20:31] <kyrofa> sergiusens, fixed the bug, though I hit another-- the caps have changed on rolling
[20:31] <kyrofa> sergiusens, network-listener is no longer default?
[20:31] <sergiusens> kyrofa, ask jdstrand for the equiv :-)
[20:32] <kyrofa> jdstrand, on 15.04 if all I use is the network I don't have to do anything regarding caps. That seems to have changed on rolling?
[20:33] <sergiusens> kyrofa, what error do you get?
[20:33] <jdstrand> if you want to use the network as a client, you should use network-client
[20:33] <kyrofa> sergiusens, a bad syscall :P
[20:33] <kyrofa> sergiusens, bind
[20:33] <jdstrand> if you want to use the network as a service, use network-listener
[20:34] <kyrofa> jdstrand, oh interesting-- network-client is the default?
[20:34] <jdstrand> network-client is given if you don't specify anything
[20:34] <jdstrand> if you start specifying other stuff, you need to specify it
[20:34] <jdstrand> too
[20:34] <kyrofa> jdstrand, what is the difference between the client and listener?
[20:35] <kyrofa> jdstrand, are you just assuming clients won't bind?
[20:35] <kyrofa> Oh duh, thinking binaries, sorry
[20:35] <kyrofa> jdstrand, understood, thanks
[20:35] <jdstrand> np
[20:35] <jdstrand> there is also unix-listener if you need to bind to a unix socket
[20:35] <kyrofa> jdstrand, awesome :)
[20:36] <jdstrand> (network-listener is for binding to a network socket)
[20:36] <jdstrand> at this point, they aren't different, but they will be soon
[20:37] <kyrofa> jdstrand, does network-listener encompass network-client?
[20:39] <jdstrand> kyrofa: no. there are some apparmor rules that are different
[20:39] <jdstrand> network-listener might be all you need now, but that is a different question
[20:40] <kyrofa> jdstrand, hmm. I guess we'll find out
[20:40] <jdstrand> (ie you may not need the rules that differentiate them)
[20:40] <jdstrand> in 16.10 and later they will be more different
[20:47] <kyrofa> jdstrand, is there a reason /proc/pid/status is disallowed in the profile?
[20:48] <kyrofa> jdstrand, rather, not present
[20:49] <jdstrand> kyrofa: that's queued for stable, fixed in 16.04.12 on rolling
[20:49] <kyrofa> jdstrand, ah excellent-- mysql needs it
[20:49] <kyrofa> jdstrand, any chance we can get that back in 15.04?
[20:50] <kyrofa> jdstrand, or is that what you meant by stable?
[20:50] <jdstrand> that is what I meant be stable
[20:50] <jdstrand> by*
[20:50] <wxl> so i have problems creating images with ubuntu-device-flash and i greped the entire code for it for the word "partition" since my problem is "issues when partitioning" and there's no result. any clues as to where else i can start looking?
[20:51] <kyrofa> jdstrand, any ETA for that?
[20:51] <jdstrand> kyrofa: maybe I can get it in real quick since a stable image is queued to be built
[20:51] <kyrofa> jdstrand, you would be my hero
[21:01] <jdstrand> kyrofa: it is in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages. hopefully I got it in in time
[21:02] <kyrofa> Thanks jdstrand! Sorry for the rush, but I really appreciate it
[21:02] <jdstrand> I already had it prepared
[21:02] <jdstrand> I was waiting for feedback on another thing that I would add depending on what they said
[21:03] <jdstrand> so I just uploaded what I had. no biggie :)
[21:03] <kyrofa> jdstrand, excellent :)
[21:04] <jdstrand> I thought it weird that access never came up before last week
[21:04]  * jdstrand shrugs
[21:04] <kyrofa> jdstrand, how can I track that so I know when I can snappy update to get it?
[21:04] <kyrofa> jdstrand, more and more people using it, I would guess
[21:05] <jdstrand> sure, it just seems like that access was so basic
[21:05] <jdstrand> anyhoo
[21:05] <kyrofa> jdstrand, indeed
[21:05] <jdstrand> well, mvo is doing a stable update for something else
[21:05] <jdstrand> I think there might be a manifest somewhere for snappy stable images, but I can never seem to remember where it is
[21:06] <jdstrand> if the images updates, do 'dpkg -l|grep ubuntu-core-security' and see if 15.04.12~ppa15 is installed (that is what I would do if I didn't want to ask anyone)
[21:08] <kyrofa> jdstrand, alright, thanks :)
[21:11] <sergiusens> kyrofa, is this what I need http://wiki.ros.org/image_view ?
[21:12] <kyrofa> sergiusens, yes
[21:12] <sergiusens> kyrofa, iow, I need a trusty machine, right?
[21:12] <kyrofa> sergiusens, it's in their repos as well if you want to just setup ROS on an lxc
[21:13] <kyrofa> sergiusens, that's safest anyway
[21:13] <sergiusens> kyrofa, does it expose it over the web? I'll setup a trusty lxc
[21:13] <sergiusens> kyrofa, I just setup a 16.04 ubuntu core laptop to test
[21:13] <sergiusens> so I am also making your snap 16.04 ready ;-)
[21:14] <kyrofa> sergiusens, nahh nothing runs by default unless you run it
[21:14] <kyrofa> sergiusens, ooo, living on the edge!
[21:14] <sergiusens> kyrofa, of course
[21:15] <sergiusens> kyrofa, right, I'm confused by this messaging Nodelet version of image_view. Brings up a display window for a sensor_msgs/Image topic.
[21:15] <kyrofa> sergiusens, the face_detector publishes a sensor_msgs/Image
[21:15] <kyrofa> sergiusens, so image_view subscribes to that and displays it in a window
[21:16] <sergiusens> kyrofa, right, I will need my lxc to have knowledge of such windowing system :-)
[21:16] <kyrofa> sergiusens, I just do reverse-X
[21:16] <sergiusens> kyrofa, as in ssh -Y or -X ?
[21:16] <kyrofa> sergiusens, lxc GUIs were too painful for me
[21:16] <kyrofa> sergiusens, yeah, ssh -X
[22:20] <rickspencer3> does anyone know which GPIO pins work on the rpi2 "out of the box"?
[22:26] <rickspencer3> arg, never mind, I was holding it upside down :/
[22:50] <elopio> rickspencer3: like with the pins facing the table? ;)
[22:50] <rickspencer3> something like that
[22:50] <rickspencer3> no, I guess I should have said "I was holding it backwards"
[22:51] <rickspencer3> the arduino is designed for people like me, they label the pins :)
[22:53]  * rickspencer3 wonders if getting some dinner might help
[22:57] <kyrofa> elopio, hahaha, funny image
[22:57] <elopio> rickspencer3: I got this https://www.adafruit.com/products/2314 and then I realized I had to learn to solder first :)
[23:14] <kyrofa> elopio, ROS stuff runs on xenial now with this: https://github.com/ubuntu-core/snapcraft/pull/232
[23:28] <elopio> kyrofa: cool. I just left PITA style comments.
[23:29] <kyrofa> elopio, thanks! :)