[06:58] <dholbach> good morning
[07:12] <clobrano> good morning
[08:09] <Chipaca> goood morning people!
[08:38] <mvo> hey Chipaca, good morning!
[08:38] <Chipaca> mvo: how's things?
[08:39] <mvo> Chipaca: busy, but good otherwise, how are you?
[08:39] <Chipaca> mvo: considering breakfast
[08:39] <Chipaca> :)
[08:39] <mvo> Chipaca: do it!
[08:39] <Chipaca> mvo: i need to fix the way we're using husks, i learned
[08:40] <Chipaca> um
[08:40] <Chipaca> not husks
[08:40] <Chipaca> the other thing
[08:40] <Chipaca> tombs
[08:40] <mvo> Chipaca: oh? how so?
[08:40] <mvo> Chipaca: the way you used them looked super nice
[08:41] <Chipaca> mvo: the function you give to tomb.Go is supposed to check whether the tomb.Kill has been called
[08:41] <Chipaca> mvo: http.Serve does not do that :)
[08:41] <Chipaca> i learned this in trying to make the server auto-go away after a bit ;)
[08:42] <mvo> Chipaca: heh, ok
[08:42] <Chipaca> so there'll be a branch about that sometime today, maybe :)
[08:44] <mvo> Chipaca: cool
[08:44] <Chipaca> we're also not doing that in tasks' tomb, but that's ok because there aren't cancelable tasks just yet
[09:01] <JamesTait> Good morning all; happy Monday, and happy World Arthritis Day! 😃
[09:13] <ogra_> ouch
[09:33] <Chipaca> wah, http.Server's Serve() calls out to private methods; i can't reimplement it tomb-friendly without reimplementing the guts of http :-(
[10:29] <Chipaca> pitti: o/
[10:30] <Chipaca> pitti: how much do you know about systemd's socket activation? :)
[10:30] <Chipaca> pitti: looking for a way to tell systemd to shut it down after inactivity
[10:30] <Chipaca> pitti: or lacking that, looking for a way to tell systemd it's shutting down due to inactivity
[10:31] <Chipaca> pitti: i've tried doing sd_notify(0, "STOPPING=1") but that still seems to get clients connecting after
[10:40] <pitti> Chipaca: not much, I'm afraid; sd_notify(3) looks like STOPPING=1, but do you actually shut down the service afterwards?
[10:40] <Chipaca> yep
[10:40] <pitti> Chipaca: you can't tell if a service is inactive from teh outside, the process itself needs to do that
[10:40] <Chipaca> sd_notify doesn't seem to make any difference
[10:41] <pitti> Chipaca: maybe it gets restarted immediately due to new clietns connecting?
[10:41] <Chipaca> yes
[10:41] <pitti> Chipaca: i. e. you might have stopped the .service, but not the corresponding .socket
[10:41] <Chipaca> and then it starts starting
[10:41] <Chipaca> pitti: i'm testing exactly that
[10:41] <Chipaca> that is: i'm trying to make sure that if the server decides to go away *just* as a new client connects, things still work
[10:57] <gberginc> can anyone help me get my demo snappy app that depends on a small shared library run?
[10:58] <gberginc> shared lib only has one function and my main app only calls that function
[10:58] <gberginc> all is packed into a snap
[11:04] <gberginc> the contents of the package can be seen at http://pastebin.com/4MA60S6r
[11:04] <gberginc> (well, the structure, that is)
[11:10] <biezpal> gberginc, you should define "LD_LIBRARY_PATH" variable to make library "shared" :)
[11:12] <gberginc> sorry, biezpal, I am completely new to Snappy - where should I add this? on my host I have specified LD_LIBRARY_PATH before building the app
[11:14] <biezpal> I mean, run "export LD_LIBRARY_PATH=/apps/heyho/current/lib/x86_64-linux-gnu" in Snappy with your app installed on
[11:14] <biezpal> and try to run your app after this, this should help
[11:14] <ogra_> you shouldnt need that
[11:15] <ogra_> the wrapper that executes the snap binary will set it automatically
[11:15] <ogra_> you just need to put your lib in the right place in your snap
[11:16] <biezpal> ogra_, is it already implemented?
[11:17] <ogra_> lib/x86_64-linux-gnu/ for amd64 and lib/arm-linux-gnueabihf/ for arm
[11:17] <ogra_> biezpal, since forever :)
[11:18] <biezpal> ogra_, few month ago we requested this feature)
[11:18] <biezpal> btw, where can we get changelogs?
[11:19] <gberginc> I have the lib in that folder but it doesn't seem to work
[11:19] <gberginc> I may have some other problems though :)
[11:20] <gberginc> because even after setting LD_LIBRARY_PATH it doesn't work; I'll look into
[11:31] <Chipaca> ogra_: um... you sure the LD_LIBRARY_PATH thing is done?
[11:31] <Chipaca> ogra_: it's not done by ubuntu-core-launcher, and it's not done by snappy
[11:32] <Chipaca> ogra_: i think it used to be done by the precursor of snapcraft, but i'm not sure
[11:33] <biezpal> :D
[11:33] <Chipaca> so AFAIK you still have to do it yourself
[11:34] <Chipaca> gberginc: if you share the snap itself, i can help, probably
[11:35] <gberginc> after setting LD_LIBRARY_PATH I see this in ldd
[11:35] <gberginc> (amd64)ubuntu@localhost:/apps/heyho.sideload/current$ ldd bin/main
[11:35] <gberginc>         linux-vdso.so.1 =>  (0x00007ffdf3fda000)
[11:35] <gberginc>         libmylib.so => /apps/heyho.sideload/current/lib/x86_64-linux-gnu/libmylib.so (0x00007fa3a3019000)
[11:35] <gberginc>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa3a2c4f000)
[11:35] <gberginc>         /lib64/ld-linux-x86-64.so.2 (0x00007fa3a321b000)
[11:35] <gberginc> but it still fails to start
[11:35] <gberginc> let me create a repo with the app
[11:35] <gberginc> ^ Chipaca
[11:35] <Chipaca> gberginc: how are you starting it, and what error do you get
[11:37] <ogra_> Chipaca, hmm ? ubuntu-core-launcher should do it since quite a while
[11:37] <Chipaca> ogra_: set LD_LIBRARY_PATH? nope
[11:37] <ogra_> yes
[11:37] <Chipaca> john@fogey:~/canonical/ubuntu-core-launcher$ grep -r LD_LIBRAR
[11:37] <Chipaca> john@fogey:~/canonical/ubuntu-core-launcher$
[11:38] <ogra_> now thats weird, i definitely remember apparmor chnges after this landed
[11:38] <ogra_> well, but then yes, you need a wrapper
[11:39] <Chipaca> gberginc: fwiw just the .snap would probably be enough to point you in the right direction, don't need to see the source itself
[11:39] <gberginc> Chipaca: ok, I'll share the snap
[11:41] <gberginc> Chipaca: http://k00.fr/2w2gp
[11:48] <biezpal> (amd64)ubuntu@management:~$ /apps/heyho.sideload/current/bin/main
[11:48] <biezpal> Hello from librarycos(0) = 1.000000
[11:48] <biezpal> (amd64)ubuntu@management:~$ /apps/heyho.sideload/current/bin/hoho
[11:48] <biezpal> Heyhohoho!
[11:49] <Chipaca> $ heyho.main
[11:49] <Chipaca> Hello from librarycos(0) = 1.000000
[11:49] <Chipaca> biezpal: don't call it directly, that's not contained!
[11:49] <Chipaca> biezpal: use the /apps/bin/* wrappers
[11:50] <Chipaca> gberginc: so
[11:50] <Chipaca> gberginc: move main to main.real
[11:50] <Chipaca> gberginc: and make "main" a script that does: #!/bin/sh
[11:50] <Chipaca> LD_LIBRARY_PATH=$SNAP_APP_PATH/lib/x86_64-linux-gnu $SNAP_APP_PATH/bin/main.real
[11:51] <Chipaca> (if you're packaging more than one architecture, $SNAPP_ARCH can help)
[11:51]  * Chipaca wonders, not for the first time, why there isn't a SNAP_ variable for the multiarch string thing
[11:59] <gberginc> great, thanks Chipaca!
[12:10] <gberginc> Chipaca: it works!
[12:10] <Chipaca> *shocking*
[12:10] <gberginc> for me, yes :D
[12:11] <gberginc> I'll now try openfoam to see how easy it would be to make a framework/app out of it
[12:49] <olli> gm
[13:15] <jdstrand> ogra_: hey, I'm not working right now, but I was wondering how to force a module load with snappy config. I know about the 'modprobe' option, but that edits a file in /etc/modprobe.d. I think I need a file in /etc/modules-load.d to be edited, unless there is something I can put in modprobe.d
[13:15] <jdstrand> but I can't seem to find it
[13:16] <jdstrand> what I specifically need it iptable_filter and ip6table_filter to be loaded, since they don't autload from within a snap
[13:16] <ogra_> heh, i didnt even know abouot /etc/modules-load.d ... is that the same as /etc/modules ?
[13:16] <ogra_> (just broken down into single files)
[13:16] <jdstrand> yes
[13:16] <ogra_> Chipaca, ^^^ can we add that to snappy config for ubuntu-core ?
[13:17] <jdstrand> otherwise firewall snaps aren't going to work :)
[13:17] <ogra_> jdstrand, same game as always ... needs adding to writable paths in ubuntu-core-config and a function in snappy for snappy config
[13:17] <Chipaca> what's the difference between modprobe.d and modules-load.d?
[13:18] <jdstrand> both have man pages
[13:18] <ogra_> modprobe.d definest module parameters
[13:18] <jdstrand> the first adjusts options when loading
[13:18] <jdstrand> the second forces load on boot
[13:18] <Chipaca> oooh, haven't been told to rtfm in ages
[13:18]  * Chipaca rtfm's
[13:19] <jdstrand> this is trying to deal with this bug: https://bugs.launchpad.net/snappy/+bug/1496419
[13:19]  * ogra_ adds an ubuntu-core-config task
[13:20] <jdstrand> cool, thanks
[13:20] <jdstrand> one of these days, I'll have a ufw snap in the store
[13:20] <ogra_> yay
[13:21] <ogra_> then i could actually snappify my firewall !
[13:21]  * ogra_ already has a ufw firewall in use here ... but deb based 
[13:21] <jdstrand> yeah, me too
[13:22]  * davmor2 pictures ogra_'s home slowly turning into rasp pi2's 
[13:22] <jdstrand> I really want to create a little 'router snap' for my soekris
[13:22] <Chipaca> ogra_: where does ubuntu-core-config come into the picture, btw?
[13:23] <ogra_> Chipaca, it defines the writable paths on the image
[13:23] <Chipaca> ah
[13:23] <ogra_> davmor2, nah, for real stuff i dont use RPis :)
[13:24] <davmor2> ogra_: oh sorry Beagle Board blacks is it ;)
[13:24] <ogra_> http://www.amazon.de/gp/product/B00JR6X0ZK
[13:24] <ogra_> plain x86
[13:26] <davmor2> ogra_: nice
[13:26] <jdstrand> ogra_, Chipaca: so we need that writable path but also a 'modules-load' option in snappy config ubuntu-core. guessing that would just be a list that create a file in /etc/modules-load.d/ubuntu-core.conf that has one module per line
[13:27] <ogra_> jdstrand, yeah, that sounds correct
[13:27] <ogra_> by default just an empty file
[13:27]  * jdstrand nods
[13:28] <Chipaca> how many modules would it be, worst case?
[13:28] <Chipaca> because making it a bunch of files would be easier :)
[13:28] <jdstrand> in my case, 2
[13:28] <jdstrand> :)
[13:28] <jdstrand> or any firewall snap
[13:29] <Chipaca> i mean, /etc/modules-load.d/ubuntu-core-$module for every module you want
[13:29] <jdstrand> I don't know what other modules don't autoload when under confinement
[13:29] <ogra_> well
[13:29] <ogra_> might not only be an autoload thing but simply some adjustment to the default image
[13:29] <jdstrand> that seems weird when comparing it to modprobe
[13:30] <jdstrand> Chipaca: ^
[13:30] <jdstrand> modprobe creates one file
[13:30] <ogra_> i can imagine that you might want to force load modules that wouldnt autoload when doing a certain oem project
[13:30] <jdstrand> ogra_: I had that feeling too, but I couldn't come up with an example
[13:30] <davmor2> jdstrand, ogra_: actually I'm surprised that ufw isn't in the base image it is way more pleasant to use that iptable :)
[13:31] <ogra_> davmor2, bot not everyone needs a firewall builtin into his drone :)
[13:31] <jdstrand> it wasn't considered minimal enough
[13:32] <davmor2> ogra_: but iptables is which is the actual firewall, ufw just makes your eyes bleed less using it :P
[13:33] <ogra_> well, a snappy install should essentially only be systemd, the snappy binary, a shell and the glue to make these three boot a system
[13:33] <ogra_> as minimal as possible
[13:33] <ogra_> sadly we're kind of moving away from that a little recently
[13:34] <Chipaca> we are?
[13:34] <ogra_> yeah, definitely
[13:34] <Chipaca> aww
[13:34] <ogra_> so many seed additions recently :/
[13:34] <davmor2> ogra_: but iptable is part of the kernel right so if you have the kernel installed it's there isn't it?
[13:34] <Chipaca> i'm still wanting to nuke python out of there
[13:34] <ogra_> davmor2, not the userspace
[13:34] <Chipaca> iptables the userspace things are quite large, even
[13:35] <davmor2> ogra_: grrrr ogra2 keeps getting priority over ogra_   fair enough wasn't sure if it was a separate thing or not nice to know though :)
[13:36] <Chipaca> ogra2 isn't an async ogra_ ?
[13:45] <ogra_> Chipaca, nah, its my snappy test setup for the bip snap in longterm testing :)
[13:46]  * Chipaca reads "yes, yes it is"
[13:46] <ogra_> haha
[13:48] <longsleep> Chipaca: nuke python2 or python3 - but please keep a python there so snaps do not have to ship python for simple scripts and stuff
[13:49] <Chipaca> longsleep: https://github.com/micropython/micropython :D
[13:49] <longsleep> mhm - i am not sure i like that
[13:50]  * longsleep prefers to have /usr/bin/python 
[13:50] <ogra_> we will definitely get rid of python at some point
[13:50] <ogra_> thats like saying "we need nodejs in the image so snaps dont need to ship it"
[13:51] <longsleep> well, python has been standard on linuxes for centuries - i am not sure if node qualifies as comparison
[13:51] <Chipaca> ogra_: not node! v8, clearly
[13:51] <davmor2> Chipaca: isn't the system-image-cli stuff written in py3?
[13:51] <Chipaca> longsleep: so has X
[13:51] <Chipaca> davmor2: yes. But that's already on the chopping block.
[13:52] <longsleep> but whatever, in my case i would need a python framework to avoid having 30 snaps each shipping python for scripting
[13:52] <Chipaca> davmor2: apparmor-click is also py3
[13:52] <longsleep> to me, removing python is the same as removing /bin/sh
[13:52] <longsleep> or /bin/bash for that matter
[13:53] <Chipaca> oh, i agree. bash should also go >:D
[13:54] <jdstrand> I'm not saying python shouldn't go, but fyi, it adds something in the neighborhood of 40M to a snap
[13:54] <jdstrand> (if using it with snapcraft, for example)
[13:54] <Chipaca> here's the thing
[13:54] <Chipaca> right now, it's in a weird state
[13:54] <longsleep> yes - i mean that would be fine if there is a framework
[13:54] <Chipaca> where we don't *promise* it'll be there
[13:55] <Chipaca> but people still depend on it
[13:55] <longsleep> true, but this is the same as with sed, awk, sh, grep
[13:55] <Chipaca> so, i think we should do two things, in order, if/when we have infinite engineering resources
[13:55] <davmor2> Chipaca: Python Roulette
[13:55] <Chipaca> or what you say
[13:56] <ogra_> bash needs to die on the snappy image :)
[13:56] <Chipaca> basically, handwavy make it possible to use a "python framework" (which isn't possible right now)
[13:56] <Chipaca> and then remove everything not *strictly* essential from the core
[13:56] <longsleep> that sounds good to me
[13:56] <jdstrand> I don't think python should be a framework
[13:57] <Chipaca> framework is wrong, hence the handwavy bit
[13:57] <jdstrand> that isn't what frameworks are for. that are explicitly not for a substitute for libraries
[13:57] <Chipaca> frameworks can't depend on things, and are for controlling access to shared resources, nothing else
[13:57] <longsleep> isnt a framework something snaps can share or rely on?
[13:57] <Chipaca> longsleep: no
[13:57] <longsleep> ah
[13:57] <jdstrand> with this sorta is, cause the interpreter is versioned
[13:57] <Chipaca> longsleep: also, frameworks can't depend on things
[13:57]  * jdstrand nods to handwavy bit
[13:58] <Chipaca> longsleep: so you couldn't make a framework that depended on the "pthon" "framework" ""
[13:58]  * Chipaca adds more ""s in there
[13:58] <beuno> also, you don't need all of python
[13:58]  * Chipaca also adds an y
[13:58] <beuno> so surely snapcraft can improve
[13:58] <longsleep> Chipaca: i see, so how to solve that?
[13:58] <beuno> and only bring in the bits you need
[13:58] <Chipaca> longsleep: today, carry on as you were
[13:58] <Chipaca> later, we'll see
[13:59] <Chipaca> longsleep: this is long-term after-lunch-break-chat stuff
[13:59] <Chipaca> beuno: hola :)
[13:59] <beuno> o/ Chipaca
[13:59] <longsleep> Chipaca: i see :) but is later also to remove one of the pythons? Right now there is 2 and 3 isn't it?
[14:00] <Chipaca> longsleep: no, only 3
[14:00] <Chipaca> wait
[14:00] <longsleep> Chipaca: oh 2 went away then already?
[14:00] <Chipaca> 2 is also on there!
[14:00] <Chipaca> what?
[14:00] <Chipaca> i thought we'd got rid of 2
[14:00] <longsleep> thats what i mean :)
[14:00] <Chipaca> :-(((
[14:00] <longsleep> well i did not check for a while
[14:00] <longsleep> maybe it is gone now
[14:00] <beuno> Chipaca, it used to be there because of cloud-init
[14:01] <Chipaca> ahhhh
[14:01] <Chipaca> 15.04 still has it
[14:01] <Chipaca> wily does not
[14:01] <Chipaca> phewww
[14:01] <beuno> right
[14:01] <longsleep> ah ok
[14:01] <Chipaca> longsleep: rolling --> awesomeness
[14:01] <longsleep> but 15.04 is what anyone should use now right?
[14:01] <Chipaca> also, much breakage, all the time
[14:01] <Chipaca> longsleep: only if you like things that don't break all the time
[14:02]  * longsleep did not check on rolling since June or something
[14:02] <beuno> longsleep, rolling is slowly becoming 16.04
[14:02] <beuno> sometimes, not slowly and not backwards compatible
[14:03] <longsleep> Chipaca: so you would agree saying that python3 will be in 16.04 - or is 16.04 after lunch break stuff?
[14:03] <beuno> if you want to stay close to the LTS and can tolerate some breakage, I'd follow rolling
[14:03] <beuno> longsleep, we don't know
[14:03] <beuno> if we can, I think we'll try and release 16.04 without Python
[14:03] <Chipaca> 16.04 is 3× too far into the future for humble little me to guess at
[14:03] <beuno> everyone benefits from a smaller image
[14:03] <longsleep> beuno: Ok fair enough, but i suggest you think about sharing python with multiple snaps before removing it
[14:03] <beuno> longsleep, absolutely
[14:03] <Chipaca> longsleep: yeh, in what i said above there was an ordering
[14:03] <beuno> we need the same for node, java, etc
[14:04] <Chipaca> qt
[14:04] <beuno> so it's a general problem to solve
[14:04] <Chipaca> /o\ qt
[14:04] <longsleep> Ok sounds good to me, as long as i can avoid adding python to all of my snaps
[14:04] <Chipaca> hah!
[14:04] <Chipaca> we've got python3.4 and 3.5 in wily
[14:05] <Chipaca> instead
[14:05] <longsleep> hehe
[14:05] <beuno> what's 40mb among friends?
[14:05] <Chipaca> probably a bug tho, i guess in the transition to 3.5 we forgot to update something
[14:05] <Chipaca> ogra_: ^?
[14:05]  * Chipaca puts it on the floor and runs
[14:05] <longsleep> but can you agree in saying "python2 is dead" - use python3 or is there still some movement to resurrect python 2?
[14:05] <ogra_> i'm pretty sure we only seed one
[14:06] <ogra_> must be some dep that pulls in the other
[14:06] <beuno> longsleep, no chance py2 is coming back
[14:06] <longsleep> beuno: ok good thats what i wanted to hear :)
[14:06] <Chipaca> longsleep: python2 is dead. Long live python3.
[14:07] <longsleep> btw, python3 does still not support ipv6 listeners in the standard library .. totally sucks
[14:07] <ogra_> heh
[14:07] <ogra_> we dont seed any python
[14:08] <beuno> ogra_, python seeds us?
[14:08] <ogra_> some package deps seem to pul both of them in
[14:08] <ogra_> ah, wait
[14:08] <ogra_> we do seed python3-pycurl
[14:08] <ogra_> booo
[14:10] <Chipaca> longsleep: python3 does support ipv6 in the standard library, afaik, fwiw, etc
[14:13] <longsleep> Chipaca: yes but only for clients, the socketserver implementations do not
[14:13] <Chipaca> longsleep: http://pastebin.ubuntu.com/12763435/
[14:13] <Chipaca> longsleep: lies
[14:13] <Chipaca> you just need to set address_family to ipv6
[14:13] <longsleep> then ipv4 does not work
[14:14] <Chipaca> ah, yes it sucks you can't easily do both
[14:14] <Chipaca> more subclassing is needed
[14:14] <longsleep> yes that is what i mean sorry
[14:14] <longsleep> my rant was not precise enough :)
[14:15] <Chipaca> longsleep: but, http://code.activestate.com/recipes/578504-server-supporting-ipv4-and-ipv6/
[14:15] <Chipaca> that is a lot longer than it needs to be, also :)
[14:15] <longsleep> sure custom class is always possible
[14:15] <longsleep> i nowadays just use a simple go server instead
[14:16] <Chipaca> yes... yes... embrace that feeling of compiled speed
[14:17] <longsleep> Chipaca: i noticed that when implementing a workaround for bug #1480404
[14:18] <longsleep> the snap now runs a redirecting web server to https, just a simple python script but that cannot do dual stack
[14:34]  * ogra_ always uses a 50 line shell script for webservers :P
[14:35] <ogra_> just some bi-directional nc wrapping is enough for everyone !
[14:36] <longsleep> mhm that includes argument parsing with GET and HEAD support?
[14:36] <ogra_> sure
[14:36] <longsleep> i mean the python script i have currently has 74 lines
[14:37] <ogra_> http://paste.ubuntu.com/12763576/
[14:38] <longsleep> ogra_: ok nice, here is what i use http://paste.ubuntu.com/12763590/
[14:38] <ogra_> misses curly brackets evereywhere :P
[14:39] <longsleep> yeah
[14:39]  * ogra_ grins evil
[14:39] <longsleep> we could do it with node - plenty curly there
[14:39] <ogra_> haha, yeah
[14:44] <Chipaca> ogra_: what're the []'s around \r\n for?
[14:45] <Chipaca> ogra_: in tr -d '[\r\n]'
[14:45] <ogra_> it removes linefeeds and returns
[14:45] <Chipaca> yes
[14:45] <Chipaca> but what are the []s for
[14:46] <Chipaca> works without 'em
[14:46] <Chipaca> afaict
[14:46] <ogra_> i think thats how it arrives in encoded stings
[14:46] <ogra_> (that code is like 2 years old ... i dont remember anymore)
[14:51] <jdstrand> ogra_: hey, fyi, lp:~jdstrand/+junk/ufw-snap. see the readme.md file. to create a snap: make clean ; make snap. you'll need to adjust /etc/modules-load.d/something.conf to include iptable_filter and ip6table_filter until the feature is implemented in snappy config
[14:52] <jdstrand> ogra_: it is only very lightly tested and I'm heading out for the rest of the day (US holiday), but it is there if you want to play with it
[14:52] <ogra_> jdstrand, no snapcraft ?
[14:53] <jdstrand> no, snapcraft doesn't handle --root with setup.py right yet
[14:53] <jdstrand> serguisens knows about it
[14:53] <ogra_> ah, python
[14:53] <jdstrand> it is nice having ufw on my snappy system though :)
[14:54]  * jdstrand heads out
[15:07] <jdstrand> ogra_: oh, if you are interested in trying it out and find a bug and feel like filing it, feel free to file it at lp:ufw