| 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? | 02:27 |
|---|---|---|
| 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:20 |
| 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? | 03:21 |
| 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 :/ | 04:09 |
| === chihchun_afk is now known as chihchun | ||
| * tsimonq2 is gone: | 05:59 | |
| === bigcat__ is now known as bigcat | ||
| zyga | good morning | 08:02 |
| fgimenez | good morning | 08:12 |
| 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:23 |
| JamesTait | Good morning all! Happy Monday, and happy Martin Luther King Jr. Day! 😃 | 09:44 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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:24 |
| sergiusens | blah1, I don't follow | 13:31 |
| 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:32 |
| 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:33 |
| blah1 | sergiusens: of what software? snappy? | 13:34 |
| sergiusens | the version of snapcraft is what I ask for | 13:34 |
| blah1 | 1.0 | 13:34 |
| 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:35 |
| sergiusens | there are two binaries, named listener and talker, each exec'ed with what is in exec | 13:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| blah1 | Otherwise everyone would be connecting to the same IRC channel ;) | 13:40 |
| 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:56 |
| ogra_ | http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files | 13:57 |
| blah1 | ogra_: that should do what I need | 13:59 |
| blah1 | thanks | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| blah1 | ogra_: that looks really cool but kind of a "running before I walk" kind of deal. | 14:08 |
| Chipaca | blah1: https://github.com/ubuntu-core/snappy-testdata/blob/master/config-example/meta/hooks/config | 14:18 |
| 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:19 |
| blah1 | sergiusens: thx | 14:21 |
| 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:24 |
| 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:25 |
| sergiusens | kyrofa, it should; right after that line of code, there's a CMAKE_PREFIX_PATH.insert(os.path.abspath(__file__), 0) | 14:26 |
| sergiusens | well you get the gist of it, __file__ being _setup_util.py which coincides with rosdir (dirname) | 14:27 |
| kyrofa | sergiusens, gotcha | 14:28 |
| kyrofa | sergiusens, does the face detector work on the rpi, then? Or more problems? | 14:30 |
| sergiusens | kyrofa, same problems | 14:34 |
| sergiusens | kyrofa, might be good to setup a hangout | 14:34 |
| 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:35 |
| kyrofa | sergiusens, sure, I'll ping you when I'm back :) | 14:36 |
| sergiusens | kyrofa, great, I found more logs btw http://paste.ubuntu.com/14567191/ | 14:41 |
| sergiusens | kyrofa, and http://answers.ros.org/question/212847/how-to-get-usb-camera-frame/ | 14:56 |
| * ogra_ would rather want the picture, not the frame :P | 14:57 | |
| 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:44 |
| 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! | 15:59 |
| noise][1 | for 16.04 I assume snappy will be periodically checking all installed packages for updates, is that implemented yet? | 16:01 |
| 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:05 |
| ogra_ | renat, for desktops, yes .... iirc that is what the libertine project does | 16:06 |
| renat | orga_, thanks! Let me investigate it. | 16:06 |
| Chipaca | noise][1: yes, but 16.04 is that which we break all the time | 16:08 |
| Chipaca | noise][1: that is your answer about your question about updates, not your answer to you question about your updates question | 16:09 |
| 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:10 | |
| 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:11 |
| 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:12 |
| Chipaca | noise][1: right now it'll just run update once an hour though | 16:13 |
| Chipaca | give or take 15 minutes | 16:13 |
| Chipaca | OnCalendar=hourly | 16:14 |
| Chipaca | AccuracySec=15min | 16:14 |
| 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:16 |
| 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:17 |
| renat | ogra_, thanks! | 16:19 |
| blah1 | To solve my own problem, I've probably got to use a stage package, huh? | 16:20 |
| 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:22 |
| blah1 | if it matters: I'm building it on a 15.10 box, but snappy core is running on a 15.04 box | 16:23 |
| sergiusens | blah1, maybe create a container or vm on 15.04 to get that out of the way | 16:27 |
| 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! | 16:28 |
| sergiusens | elopio, any idea what's wrong with https://github.com/ubuntu-core/snapcraft/pull/240 ? | 17:05 |
| elopio | sergiusens: it seems coveralls is not parsing the coverage file. | 17:08 |
| elopio | nothing wrong on our side. | 17:08 |
| 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:10 |
| elopio | sergiusens: I'm just looking now at all your comments regarding missing bugs. | 17:11 |
| elopio | I'll start searching for them. | 17:11 |
| 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:12 |
| 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:13 |
| sergiusens | kyrofa, ok, hangout? | 18:31 |
| kyrofa | sergiusens, give me 2 mins | 18:33 |
| kyrofa | sergiusens, alright, standup url | 18:38 |
| sergiusens | kyrofa, sure | 18:40 |
| elopio | sergiusens: I don't understand what you meant with the 1.0 changelog. | 18:40 |
| kyrofa | sergiusens, for your reference: http://wiki.ros.org/ROS/NetworkSetup | 18:45 |
| sergiusens | kyrofa, ok, got it working | 19:01 |
| 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:02 |
| 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:03 |
| kyrofa | sergiusens, is it useable? | 19:04 |
| sergiusens | kyrofa, with patience :-) | 19:04 |
| kyrofa | sergiusens, hahaha | 19:05 |
| kyrofa | sergiusens, I could write a much more performant one, it would just take more time | 19:06 |
| sergiusens | kyrofa, this is fine | 19:06 |
| sergiusens | kyrofa, http://imgur.com/2EtrDqB | 19:07 |
| kyrofa | sergiusens, awesome :) | 19:07 |
| 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:08 |
| kyrofa | sergiusens, so did you end up needing an apparmor/seccomp workaround in the yaml? | 19:09 |
| sergiusens | kyrofa, only due to lazyness | 19:10 |
| sergiusens | kyrofa, http://paste.ubuntu.com/14569194/ | 19:11 |
| 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:12 |
| kyrofa | sergiusens, okay so none of those things are things we'll never be able to access? | 19:13 |
| 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:14 |
| 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:15 |
| 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:18 |
| 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:19 |
| 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:26 |
| camako | Where does snappy redirect an app's stdout? | 19:57 |
| camako | i.e. where do printfs go? | 19:57 |
| === mwhudson is now known as Guest86296 | ||
| === Guest86296 is now known as mwhudson | ||
| === mwhudson is now known as Guest65934 | ||
| === Guest65934 is now known as mwhudson | ||
| 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? | 20:31 |
| kyrofa | bellyfeel, each app has its own read/write space which must be on writable partitions | 21:06 |
| kyrofa | bellyfeel, check out /etc/fstab on the snappy system-- the labels should clue you in | 21:07 |
| kyrofa | bellyfeel, err, paths | 21:07 |
| kyrofa | camako, nothing special is done with the stdout. For binaries you should see it on the terminal, for services the syslog | 21:09 |
| bellyfeel | kyrofa, ok so it's the user vs os space distinction | 21:10 |
| camako | kyrofa, thanks | 21:10 |
| kyrofa | bellyfeel, yeah more or less | 21:11 |
| bellyfeel | so what determines if a directory or file is writable within the ~/ directory? | 21:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| beuno | at least snaps that can be uploaded to the general store for others to install | 21:18 |
| bellyfeel | so the latter is when a snap is trying to access some part of the os/kernel | 21:20 |
| beuno | correct | 21:21 |
| 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:22 |
| enoch85 | kyrofa, hey! just got home | 21:29 |
| kyrofa | enoch85, hey there! | 21:30 |
| enoch85 | so ownCloud is in now= | 21:30 |
| enoch85 | ? | 21:30 |
| enoch85 | (haven't checked) | 21:30 |
| 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:31 |
| 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:32 |
| enoch85 | kyrofa, need any help? | 21:36 |
| kyrofa | enoch85, nah, this shouldn't take too long | 21:37 |
| 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:12 |
| LefterisJP | Can't the staged node binary have the armhf architecture somehow? | 22:13 |
| LefterisJP | (right now it does not) | 22:14 |
| kyrofa | LefterisJP, snapcraft doesn't support cross-compilation right now | 23:12 |
| kyrofa | elopio, you around? | 23:12 |
| elopio | kyrofa: yes | 23:13 |
| 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| kyrofa | elopio, haha, no but thanks for the offer | 23:19 |
| elopio | just double checking... | 23:19 |
| xnox | looks like snappy doesn't know about s390x architecture. | 23:53 |
| 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:56 |
| LefterisJP | kyrofa :) | 23:58 |
| LefterisJP | kyrofa: one other question that you or someone else may be able to answer. | 23:58 |
| 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. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!