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