[03:35] <liuxg> has anyone done django on snappy ubuntu? I have a little problem in getting it to work. it seems that the urls is not working though it works well on the desktop environment. thanks
[03:53] <liuxg> does anyone know what "build-packages: [libssl-dev]" means in the snapcraft.yaml syntax?
[07:20] <dholbach> good morning
[07:22] <svij> morning dholbach
[07:22] <dholbach> hi svij
[09:42] <liuxg> dholbach, ping
[09:44] <dholbach> liuxg: pong
[09:45] <liuxg> dholbach, I just found the example snapcraft.yaml at the link https://github.com/ubuntu-core/snapcraft/blob/master/examples/downloader-with-wiki-parts/snapcraft.yaml, what is the use of the "build-package"?
[09:46] <liuxg> dholbach, it looks like that it installs the package for the project. However, if I remove it, the project still can be successfully compiled
[09:47] <dholbach> liuxg: it's there, so somebody who tries to use your snapcraft.yaml locally has the required packages installed for the build
[09:49] <liuxg> dholbach, oh right, it is used use to install to the host computer, right? then can we do the same for "curl" in the example?
[09:50] <dholbach> yes, it should work for everything
[09:50] <liuxg> dholbach, you are right. I previously installed the package for "libssl-dev", so now I do not need it, and I can still successfully compile it.
[09:50] <dholbach> :)
[09:52] <liuxg> dholbach, by the way, I have used your stage-packages method to install the django stuff, and I successfully compiled them into the project. However, the project does not run in the KVM. the project works well on desktop.
[09:53] <dholbach> liuxg: did you find out why?
[09:53] <dholbach> it would be really nice if you could write up your story and send it to snappy-app-devel@lists.u.c
[09:53] <dholbach> others could start helping with your project
[09:53] <dholbach> and learn from it
[09:53] <dholbach> there is a lot to be learnt from your experience
[09:53] <liuxg> dholbach, I do not know why it happens to be like that. the app is started, but the ulrs are not routed, so still something is wrong about it..
[09:54] <dholbach> ah... do you redirect the ports when using kvm?
[09:54] <liuxg> dholbach, yes, I will do that for sure. yes, I redirect it to the port 8090
[09:54] <dholbach> ok
[09:55] <liuxg> dholbach, this is a little bit frustrating since the debugging on snappy is limited, and sometimes is not so easy to spot the problems
[10:03] <liuxg> dholbach, I have never received emails from snappy-app-devel@lists.u.c?
[10:03] <dholbach> liuxg: are you signed up for it? https://lists.ubuntu.com/mailman/listinfo/snappy-app-devel
[10:04] <liuxg> dholbach, where to subscribe the mailing list？I only receive emails from snappy-app-devel-request@lists.ubuntu.com, are they the same?
[10:04] <dholbach> snappy-app-devel-request is no mailing list - it's just the email you interact with to (un)subscribe
[10:05] <liuxg> dholbach, ok. I got it. sorry for the confusion!
[10:05] <dholbach> no worries
[10:17] <JamesTait> Good morning all; happy Friday, and happy birthday to UNICEF! 😃
[10:17] <liuxg> dholbach, I am now trying to use snappy-app-devel@lists.u.c, but it complains that it it not recognized.
[10:18] <dholbach> did you expand u.c to ubuntu.com?
[10:18] <dholbach> sorry, I was just using a shortened version
[10:19] <liuxg> dholbach, No, I did not, sorry
[10:19] <liuxg> dholbach, I just sent one email for it.
[10:19] <dholbach> ok cool
[10:20] <liuxg> dholbach, yesterday, I sent one email, but I used the wrong email address :) I sent it to snappy-app-devel-request@lists.ubuntu.com
[10:21] <dholbach> I'm glad we fixed this issue now too :-D
[10:21] <liuxg> dholbach, yeah, it is true. I am going to have my dinner. Have a great weekend!
[10:22] <dholbach> you too! have a good one! :)
[10:22] <liuxg> dholbach, thanks! :)
[10:39] <ogra_> GRRRR
[10:39] <ogra_> why has apt suddenly a system user ?
[10:42] <xnox> "security"
[10:43]  * ogra_ goes and fixes livecd-rootfs to respect that ... 
[13:47] <MikeB> QUESTION: How do I apply patches to pull'ed code before it is built?
[13:47] <cyphermox> hi. is there a snap for unity? If I wanted to install snappy on my laptop but still have a graphical interface?
[13:48] <kyrofa> cyphermox, not yet. We're still working on the graphical snap pieces
[13:48] <cyphermox> kyrofa: ok, thanks
[15:28] <MikeB> In snapcraft, how does one apply local patches to pull'ed code before building?
[15:29] <ogra_> MikeB, i dont think there is a way yet despite pushing your while modiied tree to github or so
[15:29] <ogra_> *whole
[15:31] <MikeB> ogra_, thanks. I'm surprised there's no such way to do that.
[15:32] <ogra_> i think it is planned ... sergiuens could tell, but he isnt around
[16:54] <Chipaca> ogra_: yes, the don't-take-over-networking is landed
[16:54] <Chipaca> ogra_: all the way to 15.04 even
[16:54] <Chipaca> it's an oem snap option
[16:55] <ogra_> ah, i'll tell morphis (next week i guess)
[16:55] <Chipaca> ogra_: something ridonculous like please-dont-use-networking-because-you-suck-ok: false
[16:56] <Chipaca> ogra_: skip-ifup-provisioning
[16:56] <ogra_> neat
[16:57] <Chipaca> under oem in the oem snap yaml
[16:57] <ogra_> k
[17:04] <elopio> kyrofa: I almost made it with mailpile, but got stuck on apparmor denials...
[17:04] <elopio> http://pastebin.ubuntu.com/13935183/
[17:04] <kyrofa> elopio, those are just the stupid .pyc ones though
[17:05] <kyrofa> elopio, I think you can ignore those
[17:05] <elopio> kyrofa: well, the server is not starting. I thought it was because of this.
[17:05] <kyrofa> elopio, I doubt it. Sure there isn't a more meaningful denial in there?
[17:05] <kyrofa> elopio, have you run it with snappy-debug?
[17:06] <elopio> that's the only thing I see on dmesg, and on the service log it says it all went fine.
[17:06] <elopio> I haven't tried snappy-debug before. /me tries.
[17:10] <kyrofa> elopio, yeah snappy install snappy-debug, then sudo snappy-debug scanlog (IIRC)
[17:14] <elopio> kyrofa: yes, just unlink and mknod on pyc files. Lots and lots of them.
[17:14] <kyrofa> elopio, huh... I thought that wasn't a fatal python error?
[17:15] <kyrofa> elopio, I just figure it's unable to save the compiled version so it has to do it everytime. Too bad
[17:15] <kyrofa> elopio, maybe barry knows better?
[17:16] <kyrofa> I wonder if there's a way to redirect where python tries to put those
[17:16] <elopio> kyrofa: well, I'm not sure this is the cause. It's just the only output I get.
[17:17] <kyrofa> elopio, good point. It may be the thing simply malfunctioning, external to apparmor all together
[17:18] <elopio> or me doing something stupid. That's always an option :)
[17:18] <elopio> anyway, context swtich now.
[17:28] <barry> kyrofa: sorry, what's the issue?
[17:28] <kyrofa> barry, when making a python .snap, we always see denials trying to create .pyc files
[17:29] <barry> kyrofa: "denials"?  write errors?
[17:29] <kyrofa> barry, 1: Can that ever be a fatal error? 2: Is there any way to redirect where python tries to put those files? 3: Is there a big benefit to putting them somewhere else?
[17:30] <kyrofa> barry, apparmor denials, although even if apparmor didn't get it the .snap's directory is read-only
[17:32] <barry> kyrofa: technically, pyc files are just a cache of the compilation step.  they aren't *required* but they are a very good idea if you want it to be fast.  -B/PYTHONDONTWRITEBYTECODE=1 can be used to disable writing pyc files, but you can't really put the pyc files in a different place by default (you could in py3 if you wrote a custom import hook).  i don't think there's much benefit to the added complexity of putting them somewhere
[17:32] <barry> else.  this is also somewhat different between py2 and py3 (with the latter using __pycache__ directories next to the .py files)
[17:33] <kyrofa> barry, ah, exactly the information I was looking for, thank you!
[17:33] <kyrofa> elopio, perhaps you could try the above to reduce apparmor noise and see if you have any other errors you're missing?
[17:34] <barry> np!
[17:34] <elopio> kyrofa: I'll try that. Also it seems that the command line argument they give to just run the server doesn't work.
[17:34] <elopio> and if I don't pass it, the service is not left running either, something kills it.
[19:05] <wililupy> Does anyone know of any documentation on what all options can go in the snapcraft.yaml file?
[19:38] <kyrofa> elopio, https://github.com/ubuntu-core/snapcraft/pull/163 when you're able
[19:38] <kyrofa> wililupy, sorry, I just saw your question
[19:39] <kyrofa> wililupy, a PR is sitting to add just that-- you can likely learn from it if you like: https://github.com/ubuntu-core/snapcraft/pull/146
[19:59] <wililupy> kyrofa: excellent thank you. I'll look it over. My snap is "partially working" now, but I keep having permission issues for packet capturing, which I'm hopeing is something I can just add to the binaries: or services: section
[19:59] <kyrofa> wililupy, alright, well come back if you continue to have troubles :)
[20:47] <kyrofa> jdstrand, have we made any more progress on bug #1466234 ?
[21:01] <kyrofa> ogra_, I'm looking for some documentation on port negotiation
[21:01] <kyrofa> ogra_, any pointers?
[21:01] <ogra_> negotziation ? no
[21:02] <ogra_> probably Chipaca has an idea
[21:05] <kyrofa> ogra_, oh... the docs say "there is no implementation for this yet" :P
[21:05] <ogra_> heh, i have never needed it
[21:05] <kyrofa> ogra_, yeah, I was trying to pave the way to having multiple ROS snaps installed
[21:05]  * ogra_ has the ports in his snaps configurble via snappy config ;)
[21:05] <ogra_> +a
[21:05] <kyrofa> ogra_, how does that work?
[21:06] <kyrofa> ogra_, perhaps I could make a workaround for now
[21:06] <kyrofa> ogra_, https://developer.ubuntu.com/en/snappy/guides/config-command/ ?
[21:07] <ogra_> well, i'm pretty non-std and prefer to use shell for such stuff :) but have a look http://bazaar.launchpad.net/~ogra/+junk/packageproxy/files
[21:07] <ogra_> snapcraft.yaml defines config.sh ... config.sh writes a yaml file as well as the actual confi for the app/service
[21:09] <ogra_> your config tool can indeed be a python script, go or C ...
[21:11] <kyrofa> ogra_, nice, okay thanks!