[02:27] <imnichol> I'm playing around with creating a znc snap, and I'm running into an issue where "snapcraft stage" fails, but running "./configure" succeeds.  Is there any way to see what snapcraft is doing differently?
[03:20] <imnichol> Is there a way to configure a post-install script to run after a snap is installed?  I need to kick off the generation of a configuration script
[03:21] <imnichol> Oh wait, I could probably use the copy section of snapcraft.yaml and copy over a template config
[03:21] <imnichol> But if I do that, will the user be able to modify it with their own configuration?
[04:09] <imnichol> Is there something like a home directory for snaps?  znc looks for it's config file in ~/.znc/config/znc.conf so if I can't place the config file there, then I need to hack on znc itself, which is more work :/
[05:59]  * tsimonq2 is gone: 
[08:02] <zyga> good morning
[08:12] <fgimenez> good morning
[09:23] <LefterisJP> Hey guys I have a question for framework/app filesystem structure. I have some data that keeps growing and need them to persist over upgrades and it would be nice if they are not duplicated at all upgrades. Where can I place such data?
[09:44] <JamesTait> Good morning all! Happy Monday, and happy Martin Luther King Jr. Day! 😃
[13:24] <blah1> I'm working through the snapcraft tutorial, and it doesn't have a step for editing package.yaml.  What step should I do that in?
[13:31] <sergiusens> blah1, I don't follow
[13:32] <blah1> sergiusens: I'm playing around with building a snap from znc just to get an idea of how snaps are built
[13:32] <blah1> I can get it staged just fine
[13:32] <sergiusens> blah1, I don't follow the specific question you asked ;-)
[13:32] <blah1> ah
[13:32] <sergiusens> blah1, oh, but I misread
[13:32] <sergiusens> package.yaml, you are not supposed to edit
[13:32] <blah1> uh, how about this: "is package.yaml automatically generated or do I have to create it?
[13:33] <sergiusens> it is automatically generated from snapcraft.yaml
[13:33] <blah1> Ok, is there a way to call the program with specific flags then?
[13:33] <sergiusens> blah1, are you using 1.x or 2x?
[13:34] <blah1> sergiusens: of what software?  snappy?
[13:34] <sergiusens> the version of snapcraft is what I ask for
[13:34] <blah1> 1.0
[13:35] <sergiusens> blah1, so in snapcraft.yaml you must have a binaries or services entry; if your command is a binary, add an exec, if it is a service add it to start
[13:35] <sergiusens> blah1, here's an example https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/ros/snapcraft.yaml
[13:35] <blah1> sergiusens: oh ok that makes sense
[13:36] <sergiusens> there are two binaries, named listener and talker, each exec'ed with what is in exec
[13:37] <blah1> sergiusens: so I could do something like "binaries: server: exec: znc --whatever flags here"?
[13:37] <blah1> I'm assuming that the "talker" and "listener" entries tehre are arbitrary
[13:37] <sergiusens> blah1, there is one minor problem in params here, envvars are not allowed do to security problems; we've solved that in 2.x though with some magic wrappings (might backport it or not)
[13:37] <sergiusens> blah1, those are the names you want your binaries exposed as
[13:37] <blah1> sergiusens: ok makes sense
[13:37] <blah1> what do you mean by problem with params?
[13:38] <sergiusens> blah1, once installed on Ubuntu Core, they will be accessed as 'ros-example.listener' and 'ros-example.talker'
[13:38] <sergiusens> blah1, the one you gave as an example should work fine
[13:38] <blah1> ok awesome
[13:38] <sergiusens> blah1, this won't work though 'exec: znc --tmpdir $TMP' ... as '$' is a non valid char
[13:39] <sergiusens> it would work in 2.x though
[13:39] <blah1> sergiusens: ok yeah, that shouldn't be an issue
[13:39] <blah1> Is there a way for me to put a config file somewhere where the user could modify it?
[13:39] <blah1> I'm working with znc and obviously everyone's going to need to put unique data in the conf file
[13:40] <blah1> Otherwise everyone would be connecting to the same IRC channel ;)
[13:56] <ogra_> blah1, i have a bip package with a "snappy config" hook ... perhaps you want to look at that one ... though that does only use global configs
[13:57] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files
[13:59] <blah1> ogra_: that should do what I need
[13:59] <blah1> thanks
[14:00] <ogra_> mind you, most people wouldnt consider shell good for parsing yaml though ... yxou might want to look inot a python or GO way or some such
[14:00] <ogra_> (talking about config.sh here)
[14:01] <blah1> ogra_: actually, I think I can do it even more simply since I can point znc to an arbitrary conf file
[14:01] <ogra_> well, but then you need to edit the config by hand
[14:02] <blah1> I just need to know where to put it so that someone can edit the .conf once they install the snap
[14:02] <blah1> ogra_: true
[14:02] <ogra_> instead of using snappy config
[14:02] <blah1> Oh yeah I see what you mean
[14:08] <blah1> ogra_: that looks really cool but kind of a "running before I walk" kind of deal.
[14:18] <Chipaca> blah1: https://github.com/ubuntu-core/snappy-testdata/blob/master/config-example/meta/hooks/config
[14:19] <sergiusens> blah1, doing it the snapcraft way, look at the config stuff in the webcam-webui example (one level above the link I gave you)
[14:21] <blah1> sergiusens: thx
[14:24] <kyrofa> sergiusens, saw your PR. How is this not a problem on amd64?
[14:24] <kyrofa> elopio, travis doesn't offer any way to run tests on arm, I assume?
[14:25] <sergiusens> kyrofa, I am not sure; no denials there
[14:25] <sergiusens> kyrofa, well we don't run the tests on arm or x86 using travis
[14:25] <elopio> kyrofa: you are right.
[14:25] <sergiusens> kyrofa, are you back in action?
[14:25] <sergiusens> or just lurking?
[14:25] <kyrofa> sergiusens, bizarre. But you can confirm it continues to work on amd64?
[14:25] <kyrofa> sergiusens, no I need to bring my brother back to DC here pretty quick, but I will be after that
[14:26] <sergiusens> kyrofa, it should; right after that line of code, there's a CMAKE_PREFIX_PATH.insert(os.path.abspath(__file__), 0)
[14:27] <sergiusens> well you get the gist of it, __file__ being _setup_util.py which coincides with rosdir (dirname)
[14:28] <kyrofa> sergiusens, gotcha
[14:30] <kyrofa> sergiusens, does the face detector work on the rpi, then? Or more problems?
[14:34] <sergiusens> kyrofa, same problems
[14:34] <sergiusens> kyrofa, might be good to setup a hangout
[14:35] <kyrofa> sergiusens, hmm... and no denials? Maybe I'll flash regular-old Ubuntu on my rpi and see if it's a snappy thing or an rpi thing or what
[14:36] <kyrofa> sergiusens, sure, I'll ping you when I'm back :)
[14:41] <sergiusens> kyrofa, great, I found more logs btw http://paste.ubuntu.com/14567191/
[14:56] <sergiusens> kyrofa, and http://answers.ros.org/question/212847/how-to-get-usb-camera-frame/
[14:57]  * ogra_ would rather want the picture, not the frame :P
[15:44] <sergiusens> kyrofa, so in summary I think I need to learn how to change the capture pixel fmt from mjpeg to yuyv with roslaunch files (as I can't change that could, well, hmmm
[15:59] <fgimenez> elopio, jenkins master is building after pushing your changes to my fork https://hub.docker.com/r/fgimenez/snappy-jenkins/builds/
[15:59] <elopio> fgimenez: thank you!
[16:01] <noise][1> for 16.04 I assume snappy will be periodically checking all installed packages for updates, is that implemented yet?
[16:05] <renat> Hi guys! Are you planning to include support of snaps running in chroot?
[16:05] <noise][1> Chipaca: do you happen to know about my updates question ^^^ ?
[16:06] <ogra_> renat, for desktops, yes .... iirc that is what the libertine project does
[16:06] <renat> orga_, thanks! Let me investigate it.
[16:08] <Chipaca> noise][1: yes, but 16.04 is that which we break all the time
[16:09] <Chipaca> noise][1: that is your answer about your question about updates, not your answer to you question about your updates question
[16:10] <Chipaca> noise][1: in particular, if the 16.04 you're talking about is pre-all-snaps, I don't think it'll continue updating
[16:10]  * noise][1 shakes head in confusion :)
[16:11] <noise][1> Chipaca: 2 followups: how often is that check going to be, and I don't think we have a bulk query api for CPI so that'll be one CPI hit per installed package right?
[16:11] <Chipaca> noise][1: we have a bulk query api for cpi
[16:12] <Chipaca> noise][1: I think we settled on checking a few times throughout the day, downloading when available, and installing once a day
[16:12] <noise][1> ah, (checks CPI APIs again - click-metadata endpoint), that's good.
[16:12] <noise][1> Chipaca: excellent, thx for the details
[16:13] <Chipaca> noise][1: right now it'll just run update once an hour though
[16:13] <Chipaca> give or take 15 minutes
[16:14] <Chipaca> OnCalendar=hourly
[16:14] <Chipaca> AccuracySec=15min
[16:16] <noise][1> Chipaca: we'll probably want that to be less often by launch
[16:16] <Chipaca> noise][1: that's in a snappy system, fwiw
[16:16] <Chipaca> noise][1: I have no idea how often (nor how) snappy mode would do it
[16:16] <blah1> I've managed to build and sideload a snap, but when I try to start the service it fails with the error here: https://paste.ubuntu.com/14567702/
[16:17] <renat> orga_, seems it's not what we want. We need ultra light approach, for example with systemd-nspawn?
[16:17] <blah1> I thought that running "snapcraft stage" was meant to add the libraries in the right location and take care of that, or did I misunderstand?
[16:17] <ogra_> renat, well, there are lxd and docker frameworks
[16:19] <renat> ogra_, thanks!
[16:20] <blah1> To solve my own problem, I've probably got to use a stage package, huh?
[16:22] <Chipaca> blah1: you're building against the wrong libcxx
[16:22] <Chipaca> blah1: libstdc++ i mean
[16:22] <sergiusens> blah1, most likely, is znc from source?
[16:22] <blah1> sergiusens: yes
[16:23] <blah1> if it matters: I'm building it on a 15.10 box, but snappy core is running on a 15.04 box
[16:27] <sergiusens> blah1, maybe create a container or vm on 15.04 to get that out of the way
[16:28] <sergiusens> blah1, the quick solution though is to add a stage-package stanza and add libstdc++ in there
[16:28] <sergiusens> iirc that is the package name
[16:28] <blah1> Alright, thanks!
[17:05] <sergiusens> elopio, any idea what's wrong with https://github.com/ubuntu-core/snapcraft/pull/240 ?
[17:08] <elopio> sergiusens: it seems coveralls is not parsing the coverage file.
[17:08] <elopio> nothing wrong on our side.
[17:10] <sergiusens> elopio, ok then; once that's in I think we are good for a 2.0
[17:10] <sergiusens> elopio, did you update the changelog btw?
[17:11] <elopio> sergiusens: I'm just looking now at all your comments regarding missing bugs.
[17:11] <elopio> I'll start searching for them.
[18:12] <kyrofa> sergiusens, elopio okay I'm actually here now
[18:12] <sergiusens> kyrofa, great, I'm leaving for lunch :-P
[18:12] <kyrofa> sergiusens, hahaha
[18:13] <sergiusens> kyrofa, but I have been succesful!
[18:13] <kyrofa> sergiusens, no way! Awesome!
[18:13] <sergiusens> kyrofa, well, almost; no more camera errors
[18:13] <kyrofa> sergiusens, but no image?
[18:13] <sergiusens> kyrofa, now I need to figure out rosrun imgviewer
[18:13] <kyrofa> sergiusens, ah, that I can help with :)
[18:13] <kyrofa> sergiusens, go eat, ping me
[18:13] <sergiusens> kyrofa, ok; will be back in a bit :-)
[18:31] <sergiusens> kyrofa, ok, hangout?
[18:33] <kyrofa> sergiusens, give me 2 mins
[18:38] <kyrofa> sergiusens, alright, standup url
[18:40] <sergiusens> kyrofa, sure
[18:40] <elopio> sergiusens: I don't understand what you meant with the 1.0 changelog.
[18:45] <kyrofa> sergiusens, for your reference: http://wiki.ros.org/ROS/NetworkSetup
[19:01] <sergiusens> kyrofa, ok, got it working
[19:02] <sergiusens> kyrofa, the hz thing
[19:02] <kyrofa> sergiusens, excellent! The next step you pretty much have: `rosrun image_view image_view image:=<topic you want to view>`
[19:02] <kyrofa> sergiusens, use /camera/image_raw to get the raw feed, and the faces one to get faces
[19:02] <kyrofa> sergiusens, image_view does require X
[19:03] <kyrofa> sergiusens, so make sure you have that reversed or something
[19:03] <sergiusens> kyrofa, \o/
[19:03] <kyrofa> sergiusens, yeah? Fantastic!!
[19:03] <kyrofa> sergiusens, how is the performance of the face detection on that thing?
[19:04] <kyrofa> sergiusens, is it useable?
[19:04] <sergiusens> kyrofa, with patience :-)
[19:05] <kyrofa> sergiusens, hahaha
[19:06] <kyrofa> sergiusens, I could write a much more performant one, it would just take more time
[19:06] <sergiusens> kyrofa, this is fine
[19:07] <sergiusens> kyrofa, http://imgur.com/2EtrDqB
[19:07] <kyrofa> sergiusens, awesome :)
[19:08] <kyrofa> sergiusens, I'm sorry that was such a painful experience
[19:08] <sergiusens> kyrofa, so, network latency even though it is all wired comes into effect, I am also doing two streams
[19:08] <sergiusens> and the webcam is low res
[19:08] <sergiusens> kyrofa, and it is an rpi2 :-P
[19:08] <kyrofa> sergiusens, yeah, definitely
[19:08] <sergiusens> kyrofa, this was a good excersice that got rid of plenty of bugs
[19:09] <kyrofa> sergiusens, so did you end up needing an apparmor/seccomp workaround in the yaml?
[19:10] <sergiusens> kyrofa, only due to lazyness
[19:11] <sergiusens> kyrofa, http://paste.ubuntu.com/14569194/
[19:12] <kyrofa> sergiusens, so it definitely needed more permissions than it could get from snappy? If you weren't in a hurry, would we just be waiting for capabilities?
[19:12] <sergiusens> kyrofa, yeah, we are basically waiting on zyga; and the udev thing is probably fixable; the mounts is totally ignorable
[19:13] <kyrofa> sergiusens, okay so none of those things are things we'll never be able to access?
[19:14] <sergiusens> kyrofa, mounts is probably a never allowed lightly
[19:14] <kyrofa> sergiusens, but non-fatal
[19:14] <sergiusens> kyrofa, I don't know what we may encounter with other packages, but this one is pretty sane
[19:14] <kyrofa> sergiusens, okay, good deal
[19:14] <sergiusens> I'll experiment more and polish now
[19:15] <kyrofa> sergiusens, thanks for doing that man
[19:15] <sergiusens> kyrofa, heh, well I'll probably spend some family time as I travel in 12 hours (5:30 AM flight)
[19:15] <sergiusens> kyrofa, and polish on the way :-)
[19:15] <kyrofa> sergiusens, yeah do that!
[19:18] <sergiusens> elopio, btw with 1.0 I mean, grab the changelog corresponding to 1.0 from the 1.x branch, copy and paste in between 0.6 and 2.0 :-)
[19:19] <elopio> sergiusens: I thought about that but it didn't seem correct. Many of the 1.0 entries are from backports from the master branch.
[19:19] <elopio> they would be duplicated, and they refer to stuff that never happened in this branch.
[19:26] <sergiusens> elopio, yeah, but it seems to be the way it is done
[19:26] <sergiusens> elopio, this is what dholbach did before
[19:26] <elopio> sergiusens: if you say so, it's coming...
[19:57] <camako> Where does snappy redirect an app's stdout?
[19:57] <camako> i.e. where do printfs go?
[20:31] <bellyfeel> I understand that snappy uses a read-only filesystem, but why am I able to write to certain files within the hierarchy? What's the distinction?
[21:06] <kyrofa> bellyfeel, each app has its own read/write space which must be on writable partitions
[21:07] <kyrofa> bellyfeel, check out /etc/fstab on the snappy system-- the labels should clue you in
[21:07] <kyrofa> bellyfeel, err, paths
[21:09] <kyrofa> camako, nothing special is done with the stdout. For binaries you should see it on the terminal, for services the syslog
[21:10] <bellyfeel> kyrofa, ok so it's the user vs os space distinction
[21:10] <camako> kyrofa, thanks
[21:11] <kyrofa> bellyfeel, yeah more or less
[21:14] <bellyfeel> so what determines if a directory or file is writable within the ~/ directory?
[21:15] <beuno> bellyfeel, apps can only write to their own space, they are confined from the rest
[21:15] <bellyfeel> for example i can modify /etc/sysctl but not /etc/modules
[21:16] <beuno> you shouldn't be able to modify anything outside of your own writable space when confined
[21:16] <beuno> not even the app's own files
[21:16] <beuno> is this on 15.04 or rolling?
[21:17] <bellyfeel> rolling
[21:17] <beuno> so there are 2 levels of confinement
[21:17] <beuno> some parts of the system are hardcode read-only
[21:17] <beuno> and some of them you will be confined when building a proper snap
[21:18] <beuno> at least snaps that can be uploaded to the general store for others to install
[21:20] <bellyfeel> so the latter is when a snap is trying to access some part of the os/kernel
[21:21] <beuno> correct
[21:22] <beuno> or a file outside of its own realm
[21:22] <beuno> like a file from another app
[21:22] <beuno> the general idea is that people can generally safely install apps and trust they won't be stealing data or otherwise being malicious outside of themselves
[21:29] <enoch85> kyrofa, hey! just got home
[21:30] <kyrofa> enoch85, hey there!
[21:30] <enoch85> so ownCloud is in now=
[21:30] <enoch85> ?
[21:30] <enoch85> (haven't checked)
[21:31] <kyrofa> enoch85, it's in progress. I got the answer to my mysql extension question by looking at the owncloud src, and it's PDO
[21:31] <kyrofa> enoch85, so I'm working on that now. Looks like I need a few more PHP extensions enabled as well
[21:31] <enoch85> kyrofa, ok cool
[21:31] <kyrofa> enoch85, but I have the owncloud error page working telling me what I'm missing, so I feel quite close
[21:31] <enoch85> kyrofa, I have the full list in my code
[21:31] <enoch85> kyrofa, have you checked?
[21:32] <kyrofa> enoch85, no-- some of these are probably included in the .deb, so I'm letting owncloud tell me
[21:32] <enoch85> kyrofa, https://github.com/enoch85/ownCloud-VM/blob/master/beta/owncloud_install.sh#L88-L106
[21:32] <enoch85> kyrofa, okok
[21:36] <enoch85> kyrofa, need any help?
[21:37] <kyrofa> enoch85, nah, this shouldn't take too long
[22:12] <LefterisJP> when I have architecture set to armhf in snapcraft and use node.js in a part like this: parts:
[22:12] <LefterisJP>    test-webserver:
[22:12] <LefterisJP>      plugin: nodejs
[22:12] <LefterisJP>      node-packages:
[22:12] <LefterisJP>        - web3
[22:13] <LefterisJP> Can't the staged node binary have the armhf architecture somehow?
[22:14] <LefterisJP> (right now it does not)
[23:12] <kyrofa> LefterisJP, snapcraft doesn't support cross-compilation right now
[23:12] <kyrofa> elopio, you around?
[23:13] <elopio> kyrofa: yes
[23:14] <kyrofa> elopio, can you think of any reason why an app in my .snap would be linking to /usr/lib/arch/libkrb5.so.3 when there's a perfectly good one in $SNAP_APP_PATH/usr/lib/arch/libkrb5.so.3 ?
[23:15] <kyrofa> elopio, I see $SNAP_APP_PATH/usr/lib/x86_64-linux-gnu in the .wrapper LD_LIBRARY_PATH, which to me means it should have precedence over the one in /usr/lib
[23:17] <elopio> kyrofa: yes. The only related change I can think of was renaming the $SNAP_APP_PATH var, but afaik the old was has not been removed.
[23:17] <elopio> kyrofa: sorry, I don't know.
[23:17] <kyrofa> elopio, that's alright, I wanted to whine more than anything
[23:17] <kyrofa> elopio, glad to know you're still here
[23:18] <elopio> kyrofa: ok, then keep going :)
[23:18] <kyrofa> elopio, :P
[23:18] <elopio> kyrofa: I was about to leave for the gym, and bbl. Do you need me here?
[23:19] <kyrofa> elopio, haha, no but thanks for the offer
[23:19] <elopio> just double checking...
[23:53] <xnox> looks like snappy doesn't know about s390x architecture.
[23:56] <LefterisJP> kyrofa: The solution right now was to simply include an armhf-node binary and copy it inside the staging aread by using the copy plugin in snapcraft. Not elegant but working. Guess this can be later improved in snapcraft itself.
[23:56] <kyrofa> LefterisJP, you you have the right idea. That way you can create a .snap that can be run on multiple architectures
[23:58] <LefterisJP> kyrofa :)
[23:58] <LefterisJP> kyrofa: one other question that you or someone else may be able to answer.
[23:59] <kyrofa> LefterisJP, sure
[23:59] <LefterisJP> kyrofa: What would be a directory for a framework to write data to that should be persistent across updates? I am making a framework for ethereum, which runs a client and downloads the blockchain. Re-syncing the blockchain with each upgrade would be a no-go.