[03:22] <pitti> Good morning
[03:22] <pitti> xnox: thanks, will review today
[03:23] <Unit193> Howdy.
[08:48] <mardy> Chipaca: hi! The libraries for Online Accounts are libaccounts-qt > libaccounts-glib (for enumerating account)
[08:49] <mardy> Chipaca: for performing the authentication, libsignon-qt5 and libsignon-glib
[08:49] <Chipaca> mardy: hi! and those allow me to oauth-sign a url?
[08:49]  * Chipaca looks it up
[08:49] <mardy> Chipaca: the OAuth 1.0a signature? Nope, they just get you the token
[08:50] <Chipaca> mardy: they give you the token? excellent
[08:50] <Chipaca> (i can do the signing myself :) )
[08:50] <mardy> Chipaca: however, if you are after UbuntuOne, I've some bad news
[08:50] <Chipaca> mardy: tell me more
[08:50] <Chipaca> mardy: specifically, i need the u1 token
[08:50] <mardy> Chipaca: the U1 account plugin is not using Online Accounts for OAuth, it's just using it for storing the password
[08:51] <mardy> Chipaca: maybe it also stores the token, I'm not sure
[08:51] <mardy> Chipaca: you'd better talk to the U1 guys, to know what they store in the account
[08:51] <Chipaca> the "password" should be a dict that includes the token, or a string in a known format
[08:51] <Chipaca> mardy: will do
[08:51] <mardy> Chipaca: yes, that's possible
[08:52] <Chipaca> mardy: where can i find the api docs of libaccounts-glib?
[08:53] <Chipaca> is this the google one that's on code.google.com?
[08:53] <Chipaca> libaccounts-glib-doc
[10:22] <michagogo> Chipaca, mardy: there's also the *tiny* little detail that U1 is going away next week...
[10:23] <cjwatson> Only some parts of U1 are going away, not including the SSO parts
[10:25] <michagogo> Ah, didn't know the Ubuntu SSO was considered part of U1
[10:30] <darkxst> michagogo, SSO was moved into U1 a while ago
[10:36] <cjwatson> michagogo: Well, my point is that account handling (SSO or not) doesn't go away just because file services are shutting down
[10:37] <michagogo> cjwatson: of course
[10:37] <michagogo> I just didn't know that SSO had been rebranded as part of U1
[10:37] <michagogo> And I've been hearing about "U1 is going away", so...
[11:04] <rbasak> Is /usr/share/distro-info/ubuntu.csv OK for other packages to read directly, or should they go via the distro-info command?
[11:04] <rbasak> I ask because juju reads ubuntu.csv directly.
[11:21] <pitti> Laney: thanks! Jenkins Fixed - utopic-adt-friends 20
[11:21] <Laney> pitti: always a good mail to get ;)
[11:22] <pitti> Laney: while I have you in the mood for autopkgtests: would you mind ignoring the "kazoo" test failure? (blocking python-defaults)
[11:22] <pitti> it almost always fails on i386
[11:23] <pitti> i. e. horribly flaky test
[11:23] <pitti> I already retried it like 5 times
[11:23] <Laney> pitti: could do, have you analysed it at all?
[11:23] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-kazoo/ARCH=i386,label=adt/13/console
[11:23] <pitti> Laney: not really; ^ gets a ton of "connection refused" errors
[11:23] <Laney> okay
[11:23] <Laney> well, looks like zul added them originally
[11:24] <pitti> (no idea what kazoo actually is)
[11:24] <Laney> perhaps he would like to take a look :)
[11:24] <pitti> the test seems to be an ubuntu specifism
[11:24] <pitti> it's not in debian
[11:24] <Laney> will skip for now
[11:24] <pitti> zul: that'd be nice, yes
[11:24] <pitti> (and while you are at it, the flaky nut test :) )
[11:25]  * Laney coughs
[11:29] <siretart> infinity: (or anyone else from the release team): What do you guys think about starting the libav10 transition in utopic now? https://release.debian.org/transitions/html/libav10.html
[11:30] <siretart> TBH, I don't think that many of the remaining packages will get actually fixed, but rather removed from testing for now
[11:31] <siretart> visp and jitsi havve pending NMUs, and that's it
[11:31] <siretart> Logan_: ^^
[12:14] <zbenjamin> tedg: ping
[12:23] <Chipaca> michagogo: U1 *files* is going away next week.
[12:23] <michagogo> Chipaca: Thanks, I got that now.
[12:23] <Chipaca> michagogo: ah, i see you've already been browbeat over it
[12:23] <Chipaca> sorry to belabour
[12:24] <cjwatson> I had been rather hoping to educate rather than browbeat :-)
[12:24] <cjwatson> Maybe "clarify"
[12:27] <michagogo> cjwatson: no worries :-)
[12:27] <michagogo> Is U1 just cloud and logon?
[12:27] <michagogo> Or, just logon now?
[12:27] <michagogo> Or do other things also happen under the name?
[12:27] <cjwatson> There's at least U1DB as well
[12:28] <cjwatson> https://one.ubuntu.com/help/faq/what-is-happening-and-when/ mentions several continuing services, though not all of those are part of U1 (e.g. Launchpad and Landscape aren't)
[12:29]  * michagogo googles U1DB and Ubuntu Pay
[12:45] <mvo> pitti: hm, shouldn't apport-cli -c /var/crash/_usr_bin_unity8.1001.crash give me a url or something? it prints a "." and exists for me only
[12:45] <davmor2> mvo: I've seen that too
[12:46] <mvo> davmor2: I really want to report this crash :)
[12:46] <davmor2> mvo: you can do it manually :)
[12:46] <pitti> mvo: is that on trusty?
[12:47] <mvo> pitti: utopic
[12:47] <mvo> from today
[12:47] <pitti> mvo: err, irrelevant, we didn't enable LP yet in utopic
[12:47] <pitti> mvo: yes, we currently only report to errors.u.c. (which you don't really "see")
[12:47] <pitti> mvo: if you want to enable LP bugs, comment out this in /etc/apport/crashdb.conf:
[12:47] <pitti> 'problem_types': ['Bug', 'Package'],
[12:48] <mvo> pitti: thanks! that helps. now it reports that the file is corrupted :/ (EOFError('Compressed file ended before the end-of-stream marker was reached',)). oh well
[12:49] <davmor2> mvo: sadtrombone.com
[13:09] <shadeslayer> jono: ping
[13:10] <shadeslayer> jono: any news on the donations report?
[13:17] <Chipaca> xnox: ping
[13:18] <xnox> Chipaca: hi!
[13:18] <Chipaca> xnox: hi! i'm looking at libnih, wondering how to go from lp:libnih to ./configure && make, and your name comes up a lot in debian/changelog :)
[13:19] <jono> shadeslayer, mhall119 is releasing it
[13:19] <xnox> Chipaca: lp:libnih is stale and no longer in use.
[13:19] <Chipaca> xnox: oh! where is libnih living now?
[13:19] <xnox> Chipaca: best bet to start from lp:ubuntu/libnih -> apt-get build-dep libnih; autoreconf -f -i; ./configure; make
[13:20] <Chipaca> xnox: seriously it's only maintained in ubuntu:libnih?
[13:20] <Chipaca> ok...
[13:20] <shadeslayer> jono: cool :)
[13:20] <xnox> Chipaca: libnih has multiple forks at the moment =) there is https://github.com/keybuk/libnih then there is mine work, and ubuntu & debian are diverged a bit.
[13:20] <Chipaca> xnox: that sounds ideal :-/
[13:21] <Chipaca> goes well with the lib's name, though
[13:21] <xnox> Chipaca: it's very stable, thus needs no maintainance. there is only like ~8-10 patches difference between ubuntu and keybuk's upstream
[13:21] <apachelogger> lol
[13:21] <Chipaca> xnox: I might be about to introduce another patch :D
[13:21] <xnox> Chipaca: best bet bzr branch lp:ubuntu/libnih; apt-get build-dep libnih; autoreconf -f -i; ./configure; make
[13:22] <Chipaca> xnox: yup, done that, thanks
[13:22] <xnox> Chipaca: well, i will most likely to be reviewing it for inclusion and i did forward all patches to keybuk.
[13:22] <Chipaca> xnox: i was missing the -f -i
[13:23] <Chipaca> xnox: how do i run the tests?
[13:24] <xnox> Chipaca: make check
[13:24] <Chipaca> ok
[13:24]  * mvo wonders if it would be worth adding a HACKING file to libnih with the paste of this irc conversation
[13:25] <xnox> Chipaca: the tests, are excessive =)
[13:25] <xnox> mvo: it's all covered in upstart cookbook =)
[13:25] <Laney> needs moar autogen.sh
[13:25] <Chipaca> mvo: there is a HACKING file
[13:25] <Chipaca> mvo: it is not illuminating :)
[13:25] <xnox> Chipaca: illumination quick how-to to libnih is in http://people.canonical.com/~jhunt/presentations/uds-r/2012-10-31/upstart-development.pdf
[13:25] <Chipaca> it is very good, mind you. Exactly what I need. Except for this conversation.
[13:26] <mvo> xnox: maybe the HACKING file should point to the cookbook then :) ?
[13:26] <xnox> Chipaca: and http://upstart.ubuntu.com/cookbook/#nih
[13:26] <Chipaca> um. to be honest, if you point me to the upstart cookbook when all i want to use is a bit of libnih, i'll run away screaming
[13:27] <xnox> Chipaca: i've also tried to publish docs at http://libnih.la/ but they are incomplete.
[13:27] <xnox> Chipaca: best to read code comments, as all functions methods etc. are documented extensively.
[13:27] <Chipaca> I found the libnih.la docs, they were good enough for my use :)
[13:27] <xnox> =))))))))))))))))
[13:27] <Chipaca> (wrapping libnih-dbus to use it from push)
[13:28] <xnox> nice.
[13:28] <xnox> I love that .la is country domain for Laos, they market it as ".la means local to Los Angeles"
[13:28] <xnox> but i want to start the trend for library docs instead =)
[13:29] <Laney> somalia is better :)
[13:29]  * Laney looks for .dll
[13:29] <Chipaca> this is for use from go, so .la ftw
[13:29] <ogra_> heh
[13:29]  * Chipaca runs away
[13:29] <xnox> Laney: ha, somalia does look good!
[13:30] <ogra_> we should have the next sprint there
[13:30] <ogra_> :)
[13:33] <xnox> ogra_: nah, Tokyo =))))) and get Sony to sponsor us =)
[13:35] <ogra_> xnox, oh, i wouldnt mind that !!!
[14:13] <hallyn> is there a definitive (per-release?) list of install preseed keys that work? i.e. passwd/make-user Boolean true\npasswd/username string ubuntu\n (plus pwd) seems to be ignored...
[14:14] <cjwatson> hallyn: That's just bad syntax, not bad keys
[14:14] <cjwatson> d-i passwd/make-user boolean true
[14:14] <cjwatson> d-i passwd/username string ubuntu
[14:15] <cjwatson> The installation guide has details on the useful settings
[14:15] <hallyn> cjwatson: yes i have that
[14:16] <hallyn> full preseed:  http://paste.ubuntu.com/7501590/
[14:17] <cjwatson> To debug anything I'd need to see the installer syslog, preferably from an installation with DEBCONF_DEBUG=developer so that I get a full debconf trace
[14:17] <hallyn> cjwatson: where do i set that?  kernel command line?
[14:17] <cjwatson> yes
[14:18] <hallyn> cjwatson: thanks, i'll get that at some point and if it's not obvious to me i'll get back to you.  hopefully it'll be obvious to me :)
[14:19] <hallyn> actually i'll just restart this install.
[14:20] <hallyn> logs will be in newly installed host under /var/log/intaller.log or somesuch?
[14:20] <cjwatson> hallyn: /var/log/installer/syslog
[14:20] <cjwatson> hallyn: (note that this is a trace in a similar way that strace is a trace, that is it will include confidential information such as passwords)
[14:21] <hallyn> s'ok, password is usually 'none' or 'ubuntu' as these are firealled test installs :)
[14:21] <hallyn> thanks cjwatson
[14:47] <nobuto_> Could someone in SRU team take a look at bug 1309885 ?
[14:48] <nobuto_> ^ it looks like ready to be released to me, but it stalls in SRU process.
[14:58] <hallyn> cjwatson: hm, http://paste.ubuntu.com/7501714/  what is GET vs METAGET
[14:59] <cjwatson> man debconf-devel
[14:59] <hallyn> thx
[15:00]  * hallyn goes to manpages.ubuntu.com for that one
[15:04] <cjwatson> hallyn: This seems to be a partial log and is missing some important parts
[15:04] <cjwatson> So I can't debug it
[15:04] <cjwatson> In particular it's missing the bit where the preseed file is applied
[15:11] <hallyn> sorry thought that was the important parts, uploading the whole thing,
[15:11] <hallyn> http://paste.ubuntu.com/7501768/
[16:39] <jodh> bdmurray: dude, you *rock*! (bug 1068060)
[16:41] <bdmurray> jodh: fix released actually ;-)
[16:54] <xnox> doko: some of the gcc-4.9 build-failures are of the pattern of generating undefined references in c++ code. of strange nature, e.g. desctructor having undefined reference to it's class....
[16:54] <xnox> http://paste.ubuntu.com/7502150/
[16:55] <xnox> what's going on?
[16:59] <ogra_> xnox, happy to have you in the diskspace warning meeting next week :)
[16:59] <ogra_> if you want to
[17:01] <xnox> ogra_: we have tried like 4 or 5 times to get "plymouth on mir" session no stop and notify user early in the boot that e.g. battery is critically low, or disk space is full.
[17:01] <xnox> ogra_: but we have never managed to have that session.
[17:01] <xnox> ogra_: any idea what's the bootsplash story is?
[17:02] <ogra_> xnox, i think that plan is on ice for now
[17:02] <xnox> (as in current state)
[17:02] <xnox> ogra_: so, i cannot have any graphics as root & read-only ?
[17:02] <ogra_> xnox, we will use the unity-system-compositor splash
[17:02] <ogra_> which will land with the split greeter mterry is working on
[17:02] <xnox> ogra_: can that start as root & read-only?!
[17:02] <xnox> mterry: i guess ^
[17:02] <ogra_> it runs as root but only after the container
[17:03] <mterry> ogra_, no, the splash will land separately now
[17:03] <ogra_> (a bit late, i know, but thats the current plan)
[17:03] <ogra_> mterry, ugh
[17:03] <ogra_> why is that ?
[17:03] <mterry> ogra_, to reduce the amount of design signoff needed for the split landing
[17:04] <ogra_> hmpf
[17:04] <ogra_> we need it to work on low-battery mode and various other bits :
[17:04] <ogra_> :(
[17:04] <mterry> bbl
[17:05] <ogra_> xnox, as for readonly ... yeah, it only needs to be able to create a socket in /tmp
[17:07] <ogra_> xnox, for the low diskspace issue i think we should port what we have on desktop already (if thats not hard bound to nautilus or so) and have a popup if you are at something like 98% for $HOME though
[17:07] <ogra_> that shouldnt need any splash screen implementation
[17:08] <xnox> ogra_: sockets should not use /tmp
[17:08] <ogra_> tell that to the Mir people :)
[17:08] <xnox> nor predictable names.
[17:08] <ogra_> not my socket
[17:09] <ogra_> root@ubuntu-phablet:~# ls -l /tmp/mir_socket
[17:09] <ogra_> srwxrwxrwx 1 root root 0 May 22 13:20 /tmp/mir_socket
[17:09] <mdeslaur> gah!
[17:09] <ogra_> should probably not be 666
[17:09] <ogra_> :)
[17:09]  * mdeslaur prepares tar and feathers
[17:09] <ogra_> but please in #ubuntu-mir
[17:09] <xnox> mdeslaur: thanks.... =)
[17:10] <ogra_> i'm just the messenger
[17:10] <xnox> mdeslaur: i think i had a bug filed saying that "linux abstract sockets" should be used instead.
[17:10] <xnox> mdeslaur: e.g. like upstart.
[17:10] <ogra_> i thinnk you even started a mail discussion, no ?
[17:10] <ogra_> (unless i was subscribed to the bug i seem to remember that)
[17:11] <xnox> mdeslaur: ogra_: https://code.launchpad.net/~afrantzis/mir/abstract-host-connection/+merge/216290 ?!
[17:11] <ogra_> xnox, merged into mir/devel
[17:11] <xnox> or maybe that's unrelated.
[17:11] <ogra_> not trunk
[17:11] <ogra_> they use staging branches
[17:12] <ogra_> so it might land at some point when devel gets synced
[17:12] <xnox> ogra_: https://bugs.launchpad.net/mir/+bug/1299101/comments/4
[17:12] <ogra_> mdeslaur, we need to go through the udev rules next week too ... since we just import the android permissions in there
[17:13] <mdeslaur> ogra_: that would be good, yes
[17:13] <mdeslaur> xnox: do you have a link to the bug you filed?
[17:13] <xnox> mdeslaur: i don't see it fixed. THere was https://lists.launchpad.net/ubuntu-phone/msg06672.html and https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1285215 but it was worked around with removing stale file.
[17:14] <xnox> mdeslaur: cause mir itself doesn't remove stale file socket before trying to bind....
[17:14] <xnox> mdeslaur: so i don't think there is any bug. Can you please file something critical?
[17:14] <xnox> mdeslaur: cause clearly, my voice was not heard at the time.
[17:15] <mdeslaur> jdstrand: since you have a phone to look at, could you please file a bug for /tmp/mir_socket?
[17:15]  * ogra_ hopes that the mir team is at least there next week
[17:16] <ogra_> kgunn, ^^ are you guys at the sprint next week ?
[17:16] <jdstrand> I thought there was a bug about that
[17:17] <kgunn> ogra_: we will be there....
[17:17] <jdstrand> and that it was fixed
[17:17] <kgunn> yes...thot it was fixed also
[17:17] <ogra_> kgunn, awesome :)
[17:17] <ogra_> kgunn, it is in the devel branch
[17:17] <ogra_> likely not landed yet
[17:17] <xnox> doko: actually it looks like a real under-linkage.
[17:18] <kgunn> ogra_: true...
[17:18] <kgunn> hmm...thot it got promoted
[17:18]  * kgunn goes to dig
[17:18] <ogra_> and we're not in a hurry :)
[17:19] <ogra_> (semi TRAINCON-0 atm ... so dont sweat it ... )
[17:26] <jdstrand> interestingly, the 1.1 apparmor policy doesn't allow access to /tmp/mir_socket
[17:26] <jdstrand> this was bug #1236912
[17:28] <jdstrand> apps seem to be functioning fine without it. I wonder if I should remove the rule for /{,var/}run/user/*/mir_socket
[17:28] <jdstrand> kgunn: thoughts? ^
[17:29] <kgunn> jdstrand: we do still use that for the system compositor and all our demo apps where the server runs as root
[17:30] <jdstrand> but apps themselves don't actually need it?
[17:31] <jdstrand> clearly not, but I'd like confirmation before I remove it
[17:32] <jdstrand> kgunn: ^
[17:32] <kgunn> ogra_: cmiiw, but looks like we released into utopic at r1573...see https://code.launchpad.net/~mir-team/mir/utopic r1185
[17:32] <kgunn> and that branch above you mentioned was at r1568
[17:32] <kgunn> on devel
[17:33] <kgunn> jdstrand: right...apps running on unity8 in touch as mir clients, would not need /tmp/mir_socket
[17:33] <ogra_> kgunn, hmm, i still see /tmp/mir_socket on image 43
[17:33] <ogra_> kgunn, but mir 0.1.9 is installed
[17:34] <kgunn> ogra_: see my converstation with jdstrand
[17:34] <ogra_> was that only for the session Mir instead of unity-system-compositor ?
[17:34] <kgunn> right
[17:34] <ogra_> ah
[17:34]  * ogra_ sees the backlog :)
[17:35] <kgunn> and i do know that we fully clean up stale sockets for all "handle-able" shutdowns, sigstops etc...but crashes may be a diff matter
[17:35] <jdstrand> ogra_: would native GL applications on Mir need it? eg, a gl game?
[17:35] <jdstrand> sorry, kgunn ^
[17:35]  * jdstrand has a note in the policy about that
[17:35] <kgunn> jdstrand: only in test instance, like where we run our demo code...(hang on)
[17:35] <ogra_> yeah ... i wouldnt be able to answer how native EGL apps would run with Mir
[17:36] <ogra_> :)
[17:36] <ogra_> i would expect actual native apps to link directly with libGLES or so though
[17:36] <kgunn> jdstrand: see the "running mir natively" section of http://unity.ubuntu.com/mir/using_mir_on_pc.html
[17:36] <ogra_> and not care about Mir at all
[17:37] <kgunn> jdstrand: oh i think i get what you mean...
[17:38] <kgunn> jdstrand: duh, yeah...so any "native mir" client will need to have a socket
[17:38] <jdstrand> right
[17:38] <kgunn> in the case of unity8 we're hiding that behind platform-api is my guess
[17:38] <jdstrand> ok, so I'll keep that
[17:38] <kgunn> all those sockets will be in some <something>/usr/ dir
[17:38] <ogra_> kgunn, but if i i.e. port an android gamme that natively uses GLES to ubuntu, would i have to involve Mir at all ? thats handled on the lib level, no ?
[17:39] <ogra_> (or SDL games )
[17:39] <kgunn> ogra_: is your android port to Qt? or native mir ?
[17:39] <jdstrand> kgunn: you said mir_socket was moved out of /tmp, did it go to XDG_RUNTIME_DIR like the bug suggests?
[17:40] <ogra_> kgunn, well, something like openarena for example ... would that have to be integrated with Mir at all ?
[17:40] <kgunn> jdstrand: for the session server yes...so there are 2 mir server, 1 is the "systemcompositor" which is at root, owned by the unity-system-compositor
[17:40] <jdstrand> I can confirm the existence of /tmp/mir_socketand the non-existence of /run/user/32011/mir_socket on r43
[17:40] <kgunn> the second server, is the unity8 owned server for the session
[17:41] <kgunn> ogra_: so SDL is a layer that would "take care" of the socket in that case, and for openarena...that runs on X...so xmir layer takes care of that
[17:42] <kgunn> ogra_: only in the instance where there is no abstraction layer between the app and the mir client api would there need to be awareness of a mir socket
[17:42] <jdstrand> an SDL game would still need the access since the lib would be in process
[17:42] <ogra_> i think openarena directly uses GL/GLES calls even on X
[17:42] <kgunn> ogra_: GL/GLES is kinda unrelated to the socket on mir...
[17:42] <jdstrand> the developer may not have to know about it, but the process would
[17:42] <kgunn> yes jdstrand right
[17:42] <ogra_> <- not a GLES guy ... just curious
[17:43] <kgunn> ogra_: no worries :)
[17:43] <kgunn> i know..gfx guys are weird
[17:43] <ogra_> haha
[17:44] <jdstrand> kgunn: so, was this change supposed to be in r43? I have 0.1.9+14.10.20140430.1-0ubuntu1 installed but still see /tmp/mir_socket
[17:44] <jdstrand> (this is on mako)
[17:44] <ogra_> jdstrand, the change was only for the session socket
[17:44] <jdstrand> but the session socket isn't in /run/user/32011 either
[17:44] <ogra_> se in $XDG_RUNTIME_DIR, there is another socket
[17:44] <jdstrand> or is it abstract now?
[17:45] <ogra_> or at least should be
[17:45] <jdstrand> nope
[17:45] <jdstrand> not with r43 in the emulator
[17:45] <ogra_> root@ubuntu-phablet:~# ls -l /run/user/32011/mir_socket
[17:45] <ogra_> srwxrwxr-x 1 phablet phablet 0 May 22 13:20 /run/user/32011/mir_socket
[17:45] <ogra_> thats what i have on 39
[17:46] <ogra_> not really abstract
[17:46] <jdstrand> no
[17:46] <jdstrand> weird, I don't have it on the emulator
[17:46] <ogra_> i wonder why you wouldnt have it on the emulator
[17:46] <ogra_> rsalveti, ??
[17:46] <kgunn> jdstrand: ogra_ ...feeling like i may not be doing the greatest in answering, can we move to #ubuntu-mir ?
[17:46]  * rsalveti reading
[17:47] <ogra_> probably because it uses GLES forwarding ... not sure why that would affect the session socket though
[17:49] <rsalveti> ogra_: you should have it on the emulator as well
[17:49] <rsalveti> make sure it's the same image
[17:49] <rsalveti> ogra_: and the gl game shouldn't need to know mir, libsdl would need to talk mir though
[17:50] <rsalveti> let me download latest image on the emulator and check
[17:51] <jdstrand> oh, haha
[17:51] <jdstrand> rsalveti: nm
[17:51] <jdstrand> unity8 wasn't running here
[17:51] <jdstrand> ok, so session socket missing mystery solved
[17:53] <ogra_> rsalveti, well, i'm on 39 looking at flo
[17:53] <ogra_> lets move to the mir channel though
[17:54] <ogra_> rsalveti, right, thats what i thought, GL/GLES games just link directly and bypass the display-server
[17:54] <ogra_> thats the amount of hlaf knowledge i collected over the years :)
[17:54] <ogra_> (why dont we have an openarena click package yet btw ? :P)
[17:55] <rsalveti> right, but we need to change libsdl to support mir
[17:55] <rsalveti> not sure if that was done already
[17:56] <ogra_> it was apparently
[17:56] <ogra_> a while ago
[17:57] <ogra_> there were even demos on G+
[17:57] <ogra_> iirc bregma forwarded something
[17:57] <ogra_> (proper upstreamed even)
[18:04] <rsalveti> ogra_: cool, then it should be fine :-)
[18:07] <dobey> infinity: hi. i need to bump the version again to replace the current package in -proposed right?
[18:50] <bregma> just FYI, libSDL2 (not SDl 1.2) works on native Mir out of the box in Ubuntu 14.04 and later...  the lib needs to know what the native window system is to get an EGL context, so if it the app does its own GLX calls it won't work on Mir but if it relies on SDL, it'll be fine
[18:50] <bregma> it needs the environment variable for the socket defined, just like X needs DISPLAY defined
[18:50] <bregma> and if it's libSDL1.2, no joy anyway
[18:51] <ogra_> yeah, we have a guy who wants to experiment with it ... slvn was the nick i think
[18:51] <ogra_> he didnt get far because upstart-app-launch was broken though ... LD_LIBRARY_PATH didnt get set properly so he couldnt ship the lib
[18:52] <ogra_> (that was fixed today ... looking forward to see some SDL fancyness in click apps)
[19:34] <smoser> hey all. i'm just thinking what woudl be the easiest / most preferred way to block net-device-added events from bringing up networking until after cloud-init-local had run.
[19:35] <smoser> those are emitted by udev, and consumed by network-interface.conf
[19:39] <dobey> infinity: ping
[20:28] <dobey> hmm :-/
[23:46] <infinity> dobey: Sorry, I've been out sick all day.  Yes, you need to bump the version.