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