[01:49] <sergiusens> elopio, I pushed an integration test
[01:50]  * sergiusens waves goodnight and calls it a day
[05:59] <dholbach> good morning
[06:56] <shuduo> kgunn: just want to update what i did yesterday and today. i finally made qt clock demo work with vm. the early error msg might be lead by network problem. I used command line to install mir.mvp-demo few times and got it installed at last. then I followed Darren Landoll's method to change mir-run and install qt clock demo and see it run perfect now.
[07:05] <fgimenez> good morning
[08:04] <Chipaca> oh, that's nice
[08:05] <mvo> hm?
[08:05] <Chipaca> fmt doesn't check the return value of its internal buffer handling
[08:05] <Chipaca> ie, do fmt.Println or fmt.Printf
[08:06] <clobrano> morning all :)
[08:06]  * Chipaca reads further
[08:07] <Chipaca> ah, it's not a bytes, but a []byte with their own implementation of write that never returns error
[08:07] <Chipaca> ok, fair enough
[08:09] <Chipaca> ooh, and bytes.Buffer's write also has “err is always nil”
[08:09]  * Chipaca throws away some ifs
[09:03] <JamesTait> Good morning all; happy Tuesday, and happy Brandied Fruit Day! 😃  🍒
[09:13] <Chipaca> jdstrand: ogra_: mvo: https://code.launchpad.net/~chipaca/snappy/config-modules/+merge/274987
[09:13] <Chipaca> jdstrand: ogra_: as it says in the branch, please do comment
[09:13] <Chipaca> looking for feedback
[10:08] <ogra_> Chipaca, why is potato a boolean ?
[10:09]  * ogra_ would expect a list instread ... 
[10:13] <Chipaca> ogra_: because you potato, or you no potato
[10:13] <Chipaca> :-p
[10:13] <Chipaca> ogra_: why a list?
[10:14] <Chipaca> (if you say the above with a pseudo-latvian accent, we could do the whole shtick)
[10:14] <ogra_> Chipaca, because for i.e. firewalling i have to load a bunch of modules having a list makes it a lot easier for the admin
[10:15] <ogra_> vs calling the same command over and over to load them all
[10:15]  * ogra_ commented on the MP
[10:16] <Chipaca> i'll reply in the mp for jamie's benefit
[10:18] <ogra_> ogra@anubis:~/datengrab/images$ ls /lib/modules/3.13.0-65-generic/kernel/net/netfilter/|wc -l
[10:18] <ogra_> 115
[10:19] <ogra_> there is a module for each and every sub-function of the firewall ...
[10:21] <Chipaca> ogra_: replied
[10:27] <ogra_> me too :)
[10:34] <Chipaca> ogra_: thanks!
[10:34] <Chipaca> i'll leave it un-topapproved so jamie can get a word in
[10:34] <ogra_> yep
[10:34] <Chipaca> @remindme 3h top-approve modules config
[10:34] <nothal_> Chipaca: No such command!
[10:34] <ogra_> needs the core-config change too anyway
[10:34] <Chipaca> yes
[10:37] <Chipaca> ogra_: no time like the present :-p
[11:06] <sergiusens> Chipaca, hey, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/maven/+merge/274964
[12:23] <sergiusens> mvo, if you don't mind https://code.launchpad.net/~sergiusens/snapcraft/1507814/+merge/275021 your input would be good
[12:30]  * Chipaca branches *all* the things
[12:36] <mvo> Chipaca: and I will start with the make it things instead of if a|b|c{
[12:39] <Chipaca> mvo: is that a reasonable thing to do this week?
[12:39] <Chipaca> i mean, me no likey, but deadlines
[12:40] <mvo> Chipaca: good point, you seemed to suffer so much during the reviews that it looked like a good idea
[12:40] <mvo> Chipaca: let me time box it
[12:40] <mvo> Chipaca: and at least outline it
[12:41] <Chipaca> mvo: ok. I made my suffering explicit just so you knew i wasn't ok with it being like that forever, not for you to fix it now :)
[12:41] <sergiusens> mvo, apt has a big ft warning saying it shouldn't be used when scripting; is that no longer the case?
[12:41] <sergiusens> s/ft/fat/
[12:42] <sergiusens> ah, apt install doesn't just search
[12:43] <mvo> sergiusens: oh, well, its  a bit of a cry-baby
[12:43] <mvo> sergiusens: but it should be ok, no plans for changes in the cli for 16.04
[12:45] <sergiusens> mvo, maybe a different MP? This doesn't look very nice http://paste.ubuntu.com/12876464/
[12:47] <mvo> sergiusens: hm, ok
[13:01] <sergiusens> mvo, there, fixed; maybe approve now :-)
[13:43] <sergiusens> mvo, now that the meeting is over, approve my MP :-)
[13:45] <mvo> sergiusens: sorry I misclicked and did not notice
[13:45] <mvo> sergiusens: this was never "needs-fixing"
[13:46] <sergiusens> mvo, ah, well I abide to what the reviewer told me or it would be just bureaucracy to ask for reviews :-D
[13:47] <elopio> ogra_: can you help me making sense of this? "Debian supports the runtime modification of the Device Tree which is a feature required by BeagleBone-IO"
[13:47] <elopio> that's the dtoverlay you enabled for rpi, right?
[13:49] <ogra_> elopio, where is that from ?
[13:49] <ogra_> oh, BBB
[13:49] <elopio> ogra_: https://github.com/julianduque/beaglebone-io
[13:49] <ogra_> well, thats a BBB feature
[13:50] <ogra_> i doubt the Pi can support it
[13:50] <ogra_> BBB does that through capemgr ... (which seems to have gotten a replacement in 4.2 that ppisati perhaps knows the name for :) )
[13:50] <tedg> ogra_: davidm was trying to make a library to have standard GPIO across boards.
[13:51] <tedg> ogra_: Focusing on the 96boards, but might be something useful.
[13:51] <elopio> ogra_: I'm not looking after pi support for it. I just want to run beaglebone-io on bbb. But U didn't understand that requirement.
[13:51] <elopio> I don't have a /sys/devices/bone_capemgr.*
[13:52] <elopio> s/U/I/
[13:56] <ogra_> elopio, right, thats a hack ... and it got replaced by some new mechanism in the mainline kernel afaik
[13:56] <ogra_> (capemgr is a hack i mean)
[13:57] <elopio> ogra_: ok. Let me give it a try.
[13:58] <ogra_> tedg, i wish him good luck with that :) (given that each and every board manages them different and in different layers of the system)
[14:01] <tedg> ogra_: Yeah, his goal was to align it with what users see on the board. i.e. on the header the first pin, because that could be any number of GPIO.
[14:01] <tbr> ogra_: cape manager is essentially back, now that it's mainline
[14:01] <ogra_> tbr, ah, then i dont get why we dont have it in our 4.2 kernel
[14:01] <tbr> check with rcn?
[14:01] <tbr> probably different api/incantations now
[14:02] <ogra_> ppisati, ^^^ ?
[14:03] <tbr> the official debian bbb images with 4.x kernel should support dynamical dtbo loading
[14:22] <ppisati> ogra_: nope, there's no cape manager in 4.2
[14:23] <ppisati> if they pulled it in 4.3+, i didn't notice that
[14:23] <ppisati> but i might have missed it
[14:24] <ogra_> ppisati, well, i wonder how to dynamically load dtbs then
[14:26] <ppisati> ogra_: i don't think there's any replacement fir that
[14:26] <ppisati> ogra_: my bet is tht they are running with a patched kernel
[14:26] <ogra_> well, see what tbr said above ... seems rcn-ee might know something here
[14:26] <ogra_> if we need a patch we're indeed screwed
[14:32] <ppisati> tbr: i don't see the capemanager in mainline, where is it?
[14:46] <tbr> ppisati: I'm not familiar with details, but I know overlays should work in 4.2 or 4.3. ask rcn-ee for details, he knows which patches he needs on top of which kernel version
[14:46] <tbr> or just look at the BBB scripts
[14:47] <ppisati> tbr: overlays are a way to change a single field in a DT node, cape manager builds on that
[14:47] <ppisati> tbr: and AFAICS, cape manager is not in mainline
[14:47] <tbr> ppisati: I didn't say that the 3.8.x kernel cape manager was 1:1 available in mainline now...
[14:49] <elopio> fgimenez: my only complaint about that waffle is that it's not free. Doesn't taiga give us something similar?
[14:49] <tbr> I do know though that rcn has been working on making things work in a *similar* fashion with his builds of mainline for BBB which seemed to have a fairly thin patchset (composition unknown)
[14:51] <fgimenez> elopio, mm it's free unless you use github enterprise https://waffle.io/pricing. maybe taiga also integrates with github, i'll take a look
[14:52] <elopio> fgimenez: gratis, no libre :)
[14:54] <fgimenez> elopio, yep :) iirc there was another project like this hosted in github itself, let me check
[15:00] <fgimenez> elopio, this one has an Apache License https://github.com/TWtablero/tablero, haven't tried it though
[15:00] <elopio> sergiusens: tedg: nexe creates a single file for nodejs projects. That seems like a nice shortcut :)
[15:00] <elopio> https://github.com/jaredallard/nexe
[15:02] <tedg> Seems like wrapping your JS in Python might be the definition of crazy :-)
[15:03] <tedg> Though certainly up for stealing code ideas.
[15:04] <davmor2> tedg: but if he wraps the python in bash it's ideal right?
[15:04] <tedg> I think it should *compile* the Python to Bash.
[15:06] <elopio> all the cool kids are compiling interpreted languages.
[15:46] <Rlyeh> Hi
[15:46] <Rlyeh> I cant run apps under docker :(
[15:47] <Rlyeh> This is my system information: http://paste.ubuntu.com/12877538/
[15:47] <Rlyeh> I cant start cgproxy, here is the status: http://paste.ubuntu.com/12877531/
[15:48] <Rlyeh> And this is my apps and their ports: http://paste.ubuntu.com/12877540/
[15:48] <Rlyeh> Docker cant run apps, why?
[15:49] <Rlyeh> How can I run apps under docker?
[15:50] <Chipaca> hmm, i don't remember who worked on the docker snap
[15:50] <ogra_> Rlyeh, you mean ther eis no owncloud running if you try to connet to it ?
[15:50] <ogra_> works fine here
[15:50] <Rlyeh> Yes
[15:50] <sergiusens> kickinz1|away, ^
[15:51] <Rlyeh> I'm in Iran, recently, docker applied some restriction for Iran and I cant login and pull images
[15:51] <Rlyeh> However owncloud is a local image
[15:51] <Rlyeh> But I cant run it
[15:51] <ogra_> no, the snap pulls from docker i think
[15:52] <ogra_> you should see info in syslog
[15:52] <ogra_> and it should tell you there if it cant startz
[15:52] <ogra_> *start
[15:52] <Rlyeh> Snappy downloaded the image, it was about 22MB
[15:52] <ogra_> thats only the env ... it then pulls the docker owncloud install on first startup i think
[15:53] <Rlyeh> OK, let me check the log...
[15:53] <ogra_> in any case, kickinz1|away is your man ... he m,aintains both packages
[15:54] <ogra_> theoretically snappy install docker and then snappy install owncloud should give you a working owncloud install though
[16:04] <ogra_> hmpf ...
[16:04] <ogra_> i think wer need to do something about our initrd ...
[16:05] <ogra_> booting with no root= arg set drops me into a shell ... while i would expect it to reboot on panic instead
[16:06] <ogra_> mvo, i'm wondering, does dropping to an initrd shell ever make sense in snappy ? i wonder if we should rewrite the panic() function for this to force a reboot instead
[16:08] <Guest42341> why am i on this channel??? wtf
[16:10] <mvo> ogra_: there is a open bug about this and pitti has some suggestions what we can do to make it do a reboot instead
[16:10] <Rlyeh> Ogra_, I didn't see anything wrong, but can you please check my log? http://paste.ubuntu.com/12877687/
[16:10] <ogra_> well, we just need to replace initrd's panic function
[16:10] <ogra_> Rlyeh, syslog, not dmesg
[16:10] <ogra_> dmes will only have kernel messages
[16:11] <ogra_> nothing from services usually
[16:11] <Rlyeh> By what command? syslog is not valid
[16:11] <ogra_> sudo less /var/log/syslog ?
[16:11] <ogra_> or some such
[16:25] <Rlyeh> oga_, you were right, the package was not pulled: http://paste.ubuntu.com/12877810/
[16:25] <Rlyeh> Damn it, why did they blocked Iran? :(
[16:37] <Chipaca> ogra_: do you recall offhand why we have pycurl on the image?
[16:38] <ogra_> i think that predates me
[16:38] <ogra_> but let me bet .,... zyga ?
[16:42] <ogra_> Chipaca, hmm, was snappy itself not initially python ?
[16:42] <Chipaca> yes
[16:42] <ogra_> could be a leftover from that
[16:42] <Chipaca> we've got pycurl, urllib3, and requests
[16:42] <ogra_> to download snaps
[16:43] <sergiusens> Chipaca, I know
[16:43] <sergiusens> Chipaca, system image
[16:43] <Chipaca> sergiusens: it uses all those?
[16:43] <ogra_> oh
[16:43] <sergiusens> Chipaca, it uses pycurl
[16:43] <Chipaca> ah, k
[16:43] <Chipaca> and requests?
[16:44] <sergiusens> Chipaca, is that directly seeded
[16:44] <Chipaca> dunno :)
[16:44] <ogra_> likely not
[16:44] <Chipaca> i just happened to ls /usr/lib/python*/dist-pacakges
[16:44] <Chipaca> and saw more than i was expecting
[16:44] <Chipaca> including jinja (!??)
[16:45] <sergiusens> Chipaca, urllib3 is a dep for requests; I don't think anyone is using urllib3 directly
[16:45] <Chipaca> ah, ok
[16:45] <sergiusens> we just need to figure out who uses requests :-)
[16:45] <sergiusens> ogra_, where is the package manifest for the latest build?
[16:46] <ogra_> just ubseed it and see what fails ;)
[16:46] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/wily-preinstalled-core-amd64.manifest
[16:46] <sergiusens> ogra_, it isn't directly seeded, is it?
[16:46] <ogra_> wily
[16:46] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-amd64.manifest
[16:46] <ogra_> vivid
[16:47] <sergiusens> Chipaca, ogra_ so cloud-init depends on python3-requests ;-)
[16:47] <ogra_> and no, i dont see it in the seeds
[16:47] <ogra_> oh man
[18:57] <mvo_> ogra_: I suspect there is something with the resize script, if I remove system-ab my system hangs forever in what appears to be the resize script. is there a way to enable debug mode, i.e. see what its doing?
[21:00] <kgunn> sergiusens: so y;day we were discussing how snapcraft shouldn't look outside it's proj directory for pulled libs...and i ran into something just want to chat thru
[21:00] <kgunn> so for mir, i got snapcraft to the point of actually compiling on my wily machine (where boost is installed on the system)
[21:01] <kgunn> so went to lxc for vivid, started there...didn't get past cmake...
[21:01] <kgunn> well, mir has a FindBoost.cmake that searches for boost based on $boostroot or some such, if it can't find it goes to /usr where it finds it...
[21:02] <kgunn> in this case, should i simply create a plugin extension specific to mir, to pass in a Boost_DIR=<dir>  as part of the cmake .. call ?
[21:03] <kgunn> also...kind of interesting that the cmake file went and looked for stuff outside the project dir, not sure how snapcraft would fight against that...
[21:08] <tedg> kgunn: We can't fight against it other than when you push it to LP it won't work.
[21:09] <tedg> kgunn: The cmake plugin has a parameter I believe for build flags, let me check.
[21:10] <kgunn> tedg: i mean that's not awful...but if i hadn't tried it in lxc, i wouldn't have realized
[21:10] <tedg> kgunn: Yeah, it's an array, configflags, those will get passed to cmake
[21:10] <tedg> I think we need to figure out a warning or something. Not sure how we'd implement it.
[21:10] <tedg> But yeah, I've had that problem.
[21:14] <gchristensen> Hi, is there documentation on making a snappy package for a docker image?
[21:32] <tedg> I think that kirkland wrote a blog post on that... let me look.
[21:32] <gchristensen> another thing is, is there a way to install ruby? :/ `search` isn't showing anything.
[21:34] <tedg> gchristensen: You wouldn't install ruby in the base system, it would be included in the application that uses it.
[21:35] <tedg> Ah, there it is. gchristensen: http://blog.dustinkirkland.com/2015/07/prime-time-docker-juju-and-snappy.html
[21:36] <gchristensen> ok, thank you for the help and information tedg. I don't think snappy is a good fit for this project, though.
[21:36] <gchristensen> cheers, good luck -- I look forward to checking it out again in a year or so.
[21:44] <sergiusens> tedg, kgunn the best way to circumvent that is to put snapcraft under apparmor and restrict access to /include and /usr/include ;-)
[21:45] <sergiusens> not the best way, just a quick way
[21:45] <tedg> Yeah, I figured that wouldn't be flexible enough. As we'd want the libc headers from there, for instance.
[21:45] <tedg> Perhaps if we could make it only give a warning or something like that.
[21:46] <sergiusens> right