[00:14] <robru> mterry, ping
[00:15] <mterry> robru, yo
[00:15] <robru> mterry, do you have a sec to help me with more vala async voodoo?
[00:16] <mterry> robru, sure
[00:16] <robru> mterry, ok, so I've got a number of methods that look like this: http://paste.ubuntu.com/1595270/
[00:17] <robru> mterry, and what I'm trying to do there, is make the method behave *synchronously* even though it's built on top of an async API. so, eg, it needs to block the thread, in order to return the value from the callback
[00:18] <robru> mterry, but obviously it's not doing that. it calls the method successfully, then returns null immediately, and the callback gets called but not in time to return the value
[00:18] <mterry> robru, begin can't do that
[00:18] <mterry> robru, begin as you see exits quick.  There's no current syntactic sugar for doing what you want.
[00:18] <mterry> robru, you need to make a new GLib.MainLoop()
[00:18] <mterry> robru, and run it, and exit it in the callback
[00:19] <mterry> or rather .quit() it in the callback
[00:19] <robru> mterry, what are the implications of having a bunch of mainloops happening concurrently? will they interfere with each other in any way?
[00:19] <mterry> and .run() it after the .begin() call
[00:19] <mterry> robru, no
[00:20] <mterry> robru, shouldn't be any problems with nested loops
[00:20] <robru> mterry, ok, just that there's like a dozen of these, and we're expecting them to be running a lot. not sure if there's, eg, memory usage concerns with having dozens of mainloops going at the same time
[00:21] <mterry> robru, well, you don't have many options, unless you can afford to actually block (which it sounds like you can't).  You need a main loop to handle events while you wait.  And you can't exit the function
[00:21] <mterry> robru, but I don't think MainLoops are expensive
[00:22] <robru> mterry, ok
[00:22] <robru> mterry, just for example, I had a similar problem in python one time, and I handled with by calling time.sleep() inside of a while loop:
[00:22] <robru> http://bazaar.launchpad.net/~super-friends/friends/trunk/view/head:/friends/utils/authentication.py#L45
[00:23] <mterry> robru, ah, that's actual blocking.  I don't like doing that
[00:23] <robru> (in that case, mainloops weren't working for me, because we had some kind of bug where the callback wasn't getting called, so I needed a way to force a timeout. calling time.sleep() a fixed number of times was an easier way to be able to measure how long we've been waiitng, and then give up the wait.
[00:24] <robru> mterry, yeah, in that case we specifically needed to block that whole thread, because everything the thread was about to do hinged on getting the results back from that function -- so we just had to sit there and wait for the callback. it's a threaded app, so other threads were able to do their own thing -- only the one thread was blocked, not the whole app.
[00:24] <mterry> robru, I vote MainLoop, but if you can afford to real block, sleep is fine
[00:25] <robru> mterry, ok, I'll try to figure out mainloops ;-)
[00:25] <mterry> robru, I see, there, real blocking was a feature not a bug  :)
[00:26]  * mterry has to go
[00:26] <robru> mterry, ok great, thanks
[05:59] <pitti> Good morning
[05:59] <desrt> pitti: word.
[06:00] <pitti> desrt: bonjour, comment est FOSDEM?
[06:01] <desrt> ĝi ne ekis ankoraŭ
[06:08] <pitti> desrt: right, I mean the GNOME hackfest
[06:08] <desrt> ah.  bona
[06:08] <desrt> hodiaŭ estas la fina tago
[06:09] <desrt> ĉu vi venos hodiaŭ aŭ morgaŭ?
[06:21] <pitti> desrt: ^ heh, I can decipher that without gtranslate :)
[06:22] <pitti> desrt: je vais arriver à demain
[06:22] <desrt> pitti: that's the point!
[06:29] <Mirv> does totem work in raring for most? I haven't figured what's causing bug #1103747
[06:29] <ubot2> Launchpad bug 1103747 in totem (Ubuntu) "Totem could not startup." [Undecided,Confirmed] https://launchpad.net/bugs/1103747
[06:31] <pitti> Mirv: yeah, since glibc 2.17 it works perfectly here
[06:40] <Mirv> I thought so, given the low visibility in LP
[06:40] <Mirv> but interesting: libgstclutter.so is blacklisted for me...
[06:41] <Mirv> I wonder what's doing that and where
[07:16] <Mirv> updated the bug a bit but didn't find anything useful
[07:28] <jibel> good morning
[08:15] <robru> pitti, I just replied to your email, but now I am off to sleep! Hopefully that is not too overwhelming for you to read ;-)
[08:15] <robru> good night all!
[08:15] <pitti> robru: goodnight
[10:38] <chrisccoulson> ah, crap @ https://bugzilla.mozilla.org/show_bug.cgi?id=836050
[10:38] <ubot2> Mozilla bug 836050 in DOM "Make Element::GetAttr/HasAttr/AttrValueIs non-virtual" [Normal,Resolved: fixed]
[10:38] <chrisccoulson> that's the end of our addon now ;)
[10:40] <Laney> how come?
[10:41] <chrisccoulson> Laney, these functions aren't exposed. the only reason we ever managed to use them is because they were virtual
[10:41] <chrisccoulson> which sucks
[10:42] <chrisccoulson> the reality is, binary addons are dead
[10:42] <chrisccoulson> and this is pretty much the final nail in the coffin
[10:42] <chrisccoulson> which means i need to urgently finish off my reimplementation of this, else we'll be shipping an update without a menubar ;)
[11:43] <pitti> Mirv: confirmed, it broke today
[11:43] <pitti>  (totem)
[11:44] <pitti> it just takes ages to start
[11:51] <ogra> lovely, lightdm lost fat !
[11:52] <ogra> thats impressive ... 27MB less
[11:59] <Mirv> pitti: ok.. might be different from my problem, though. it does start immediately, pops up the error about missing gstclutter and closes when ok is pressed
[12:58]  * ogra is impressed, so my idling desktop on the nexus7 is down from 640M to 357 here 
[12:58] <ogra> according to htop at least
[13:37] <pitti> does anybody else get "WARNING **: Couldn't register with accessibility bus:" warnings and long hangs for each and every program now?
[13:58] <davmor2> ogra: there is a nice python app call statgrab that can give you a load of info on either a single app or everything running http://www.i-scream.org/libstatgrab/ will give you more info
[13:58] <ogra> nice ! thanks
[13:59] <davmor2> ogra: I found 3 memory leaks in USC using my script that made use of it.  Of course it took mvo about a month to find the cause but it has proved it's worth :)
[14:00] <ogra> hehe
[14:15] <seb128> pitti, no such issue here
[14:16] <seb128> pitti, you have at-spi-core2 installed I guess?
[14:17] <pitti> oh, no, I don't
[14:17] <pitti> oh, at-spi2-core; I do have that
[14:20] <pitti> seb128: FYI, finally tracked down the weird gvfs autopkgtest failure, uploaded a fix
[14:20] <seb128> pitti, great
[14:46] <seb128> ogra, the meeting is in 1h15 right?
[14:47] <seb128> hum, I'm pretty sure it is ;-)
[14:47] <seb128> in any case I'm off an hour for exercice, will be back on time for it
[15:02] <Laney> pitti: I see that message but it doesn't seem to noticeably delay startup
[15:18] <lool> stgraber: Ah, I see cyphermox is on leave today; would you know whether he intended to upload the latest connman release?  I remember he packaged it in bzr somewhere, but I'm not sure what's holding it back for raring, would you know?
[15:18] <pitti> Laney: ok, then maybe I just need to restart my session
[15:18] <cyphermox> lool: no it's blocked on kernel headers being broken
[15:19] <cyphermox> I haven't looked back to see if those were fixed yesterday though
[15:19] <cyphermox> it was still being discussed on LKML not long ago so I assumed it wasn't patched anywhere yet
[15:19] <cyphermox> I would really rather not upload connman with a ugly hack to make it work
[15:21] <cyphermox> lool: OTOH, it could still be uploaded, it will work it's just likely to break once the headers change again -- it's all in bzr at lp:~mathieu-tl/connman/1.10 I can upload that in a minute it you think we should have it now regardless
[15:22]  * pitti scratches head on https://launchpadlibrarian.net/130118936/buildlog_ubuntu-raring-i386.gvfs_1.15.2-0ubuntu3_FAILEDTOBUILD.txt.gz
[15:22] <pitti> gtk 3 already built an moved to raring
[15:22] <pitti> why the hell is it uninstallable in a buildd?
[15:23] <pitti> I already retried the build
[15:23] <pitti> oh, now http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html is full of it
[15:23] <pitti> it wasn't yet when I retried
[15:24] <lool> cyphermox: sorry for interrupting your leave; thanks for the pointers!
[15:25] <pitti> so what broke -proposed so hard?
[15:25] <Laney> skew from libxkbcommon it seems
[15:25] <cyphermox> lool: ah, I'm still looking at IRC for the next hour or so
[15:25] <lool> cyphermox: Kernel headers > is that a case of headers not being in linux-libc-dev?
[15:26] <lool> cyphermox: Worst case, we can copy a header from linux until this is sorted out?
[15:26] <cyphermox> nah, it's some incompatibility between the headers in the kernel and what's in libc
[15:26] <Laney> err, wait
[15:26] <lool> cyphermox: do you have a link to that?
[15:26] <cyphermox> lool: I did patch it locally in my bzr branch
[15:26] <lool> ah great
[15:26] <Laney> why does libgtk-3-0 have such a tight dep on libxkbcommon0?
[15:26] <cyphermox> http://bazaar.launchpad.net/~mathieu-tl/connman/1.10/view/head:/debian/patches/fix_build_with_kernel_3.8.0.patch
[15:27] <lool> looking
[15:27] <pitti> Laney: yeah, that seems a bit excessively tight
[15:27] <Laney> -V?
[15:27] <cyphermox> lool: I was hoping for the situation to be sorted quickly upstream and then being able to upload without this patch, but if you think we need it now, I can just upload
[15:27] <pitti> $ cat /var/lib/dpkg/info/libxkbcommon0.shlibs
[15:27] <pitti> libxkbcommon 0 libxkbcommon0 (= 0.2.0-0ubuntu1)
[15:27] <pitti> Laney: ^ seems so
[15:28] <Laney> # Keep a close eye on the shlibs for the time being:
[15:28] <Laney> override_dh_makeshlibs: revision=$(shell dpkg-parsechangelog|grep ^Version:|sed 's/Version: //')
[15:28] <Laney> override_dh_makeshlibs: dh_makeshlibs -V "libxkbcommon0 (= $(revision))"
[15:28] <pitti> at least libxkbcommon is "valid candidate", so it should hopefully clear itself up now
[15:28] <lool> cyphermox: Since you did the work, I think it would be nice to get it now; we can update it with a cleaner patch later
[15:28] <Laney> no it won't
[15:29] <Laney> it's a transition
[15:29] <Laney> bdrung: ^^^^^^
[15:29] <Laney> seems to only be gtk and weston though
[15:30] <Laney> tjaalton: do you know if that shlibs condition can be relaxed now that libxkbcommon is considered more stable?
[15:30] <cyphermox> lool: ack, I'll just run it through sbuild one last time here to be sure it builds properly
[15:31] <lool> cyphermox: we don't even have the command-line tools in the current Ubuntu packages, do we?
[15:31] <cyphermox> no
[15:31] <cyphermox> but it's in my package
[15:31] <lool> 0.78 -> 1.10 is definitely a great win; the linux header thing is really minor in comparison
[15:33] <Laney> tjaalton: (also, I don't see the recent Ubuntu changes in git; would be nice to have them there IMO)
[15:33] <pitti> Laney: oh indeed, we'll need to rebuild gtk3 against it, sorry
[15:33] <pitti> Laney: care to add a block to libxkbcommon?
[15:34] <pitti> Laney: this shouldn't migrate to raring as it is, it'll make everything uninstalalble
[15:34] <pitti> Laney: too bad that britney doesn't pick that up
[15:34] <Laney> pitti: britney does pick it up
[15:34] <Laney> pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is generally the more interesting file
[15:34] <cyphermox> lool: there is also a patch in bts that would be nice to have
[15:34] <Laney> _excuses is just package-local checks
[15:34] <pitti> Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate"
[15:35] <pitti> Laney: oh, ok; so it will not go in?
[15:35] <Laney> that means something like "valid to pass to the second stage"
[15:35] <Laney> indeed - see libxkbcommon there
[15:35] <pitti> Laney: so "skipped" means "thumbs down"_
[15:35] <pitti> _
[15:35] <pitti> eek, kbd lazout
[15:35] <pitti> ?
[15:35] <Laney> yeah
[15:36] <Laney> then the i386:... is all the packages that get made uninstallable
[15:36] <pitti> ok, thanks
[15:36] <Laney> I'd like tjaalton to comment on whether we can just use standard -V nowadays
[15:36] <lool> cyphermox: I guess you mean the upstream BTS rather than the Debian one as the latter doesn't seem to have any patch
[15:36] <Laney> so that we can future proof this
[15:37] <lool> cyphermox: if you like, I can include that patch if you point me at it; I dont want to make you work today
[15:37] <lool> cyphermox: are we still using https://code.launchpad.net/~connman-maintainers/connman/ubuntu.head ?
[15:37] <lool> not sure I can write to that
[15:37] <cyphermox> lool: nah
[15:38] <cyphermox> I based on debian's 1.0
[15:38] <lool> (BTW the old Ubuntu changelog entries seem to be gone; not sure if it's on purpose)
[15:38] <cyphermox> I'll include the patch in BTS (via uploading / merging this with debian and uploading to unstable with some help)
[15:38] <cyphermox> err
[15:38] <cyphermox> I must have forgotten to add them back
[15:39] <cyphermox> lool: it's not quite meant as a merge though, more like a sync with additional changes :)
[15:39] <lool> cyphermox: Ok; just let me know if I can help with anything on the Debian or Ubuntu side; I'd like Connman to be up-to-date in the archive as to allow for easier testing (no point in having a PPA if we can just push it to raring)
[15:40] <lool> cyphermox: That's fine; you can happily drop changelog entries if you've indeed started from Debian version and reapplied changes by hand
[15:40] <lool> I was just double-checkig
[15:40] <cyphermox> yeah, that's what I did
[15:40] <lool> cyphermox: I was thinking we should try to package some of the connman UIs since we don't have any indicator / applet for it
[15:41] <cyphermox> yes
[15:41] <cyphermox> there is some code that works for gtk2/ gnome-panel
[15:41] <cyphermox> it's not amazing, only works in xfce and the like, but it helps out
[15:41] <cyphermox> we really need a proper indicator to be written
[15:41] <lool> it's a good start while an indicator doesn't exist
[15:41] <cyphermox> yes
[15:42] <lool> we could even push it as far as having the same hack as nm-applet
[15:42] <cyphermox> https://github.com/tbursztyka/connman-ui
[15:42] <cyphermox> yes, possibly
[15:42] <cyphermox> I can package that on monday
[15:42] <cyphermox> (unless it's needed earlier
[15:43] <lool> cyphermox: it's not critically urgent to get the UI
[15:43] <lool> let's chat about it on Monday
[15:44] <cyphermox> sure
[15:44] <cyphermox> lool: connman 1.10 uploaded.
[15:45] <cyphermox> lool: if something doesn't work or people are unhappy, anyone feel free to fix things, I won't be available for the rest of the day
[15:45] <lool> cyphermox: thanks a lot
[15:45] <lool> cyphermox: and have a good week end
[15:46] <cyphermox> you too
[15:51] <ogra> seb128, 17:30 paris time :)
[15:52] <cyphermox> ogra: does today image actually work for bluetooth now?
[15:52] <ogra> well, i havent re-installed since a while, it works fine here though
[15:52] <cyphermox> ok
[15:52] <Laney> I could pair but not send a file from my phoen to the N7
[15:52] <cyphermox> Laney: ah, thanks
[15:53] <Laney> could be the android side being buggy
[15:53] <cyphermox> maybe the n7 doesn't have the gnome file sharing bits?
[15:53] <ogra> cyphermox, http://cdimage.ubuntu.com/daily-preinstalled/20130201/raring-preinstalled-desktop-armhf+nexus7.manifest shows "brcm-patchram-plus-nexus7	0.1.1"
[15:53] <cyphermox> great
[15:53] <cyphermox> yesterday's didn't have it
[15:53] <ogra> i can connect my kbd and a headset here
[15:53] <ogra> it just doesnt survive suspend
[15:55] <cyphermox> aye
[15:55] <cyphermox> ok so we'll need to figure out what's up with suspend
[15:57] <seb128> ogra, 17:30 ... trying to trick me 30min late? ;-)
[15:57] <ogra> heh, was it earlier ?
[15:57]  * ogra is confused
[15:58] <seb128> ogra, isn't the time 17:00?
[15:58] <seb128> ogra, I though it was on the hour, not half past
[15:59] <ogra> yeah, you are reight 16:00 UTC
[15:59] <seb128> hehe
[15:59] <seb128> you did try to trick me in being late!
[15:59] <ogra> now ... so to say
[15:59] <ogra> no, i'm just a bit confused, too many vet. visits this week
[16:03] <tjaalton> Laney: oh.. yes it can be relaxed. and the latest merge/sync is in git
[16:03] <tjaalton> the one I did anyway
[16:05] <attente> seb128: where is the meeting?
[16:07] <seb128> attente, #ubuntu-meeting
[16:11] <bdrung> Laney: yeah, we should relax the shlibs condition for libxkbcommon. i will do that.
[16:11] <tjaalton> Laney: so, should I upload a new libxkbcommon dropping it?
[16:11] <tjaalton> bdrung: please don't
[16:13] <bdrung> tjaalton: why not drop the shlibs condition and add a symbols file?
[16:14] <tjaalton> bdrung: I've dropped it locally already
[16:14] <tjaalton> updating the branch atm
[16:14] <bdrung> tjaalton: so you wanted to stop me because you are working at it?
[16:14] <tjaalton> bdrung: yes :)
[16:14] <bdrung> okay :)
[16:15] <bdrung> tjaalton: will you add a symbols file?
[16:15] <tjaalton> good idea, didn't do that yet..
[16:16] <bdrung> tjaalton: and please use 3.0 (quilt) source format or get the direct source changes converted to a patch
[16:16] <tjaalton> bdrung: it's pkg-xorg, 3.0 is a no-no
[16:17] <bdrung> why?
[16:17] <tjaalton> ask jcristau
[16:17] <tjaalton> or don't
[16:17] <tjaalton> :)
[16:17] <bdrung> then please specify version 1.0 in debian/source/format
[16:18] <tjaalton> yeah
[16:18] <bdrung> this will make clear that there were made a decision
[16:25] <Laney> tjaalton: cool, then please upload gtk and weston once you've done that
[16:26] <Laney> seb128: your staged gtk changes drop a symbol without updating the file
[16:26] <tjaalton> I'll update both wayland & weston too (1.0.4)
[16:26] <Laney> did you make sure nothing uses it ...
[16:27] <seb128> Laney, oh, sorry, and yes larsu had a workitems to investigate that, we added that patch/symbol for ido and it stopped using it
[16:27] <Laney> I wish for a codesearch.ubuntu.com (like codesearch.debian.net) in situations like this
[16:27]  * Laney wonders how hard that would be
[16:35] <tjaalton> someone uploaded libxkbcommon-0.2.0-0u2 already?
[16:36] <tjaalton> or since jan 9th
[16:36] <tjaalton> *after
[16:38] <Laney> yes, that's what alerted us to this
[16:39] <davmor2> ogra: on the n7 I'm just trying to setup online accounts and which ever I select for access I can't type in email and password for access :(  ie Facebook, Google, twitter.  All display the login creds but I can't type in them
[16:39] <ogra> bug :)
[16:43] <tjaalton> Laney: ok, uploaded -0u3
[16:43] <Laney> great
[16:43] <Laney> I'll upload gtk; you do w*
[16:44] <tjaalton> yeah
[16:44] <tjaalton> was about to ask someone else to take care of gtk :)
[21:07] <robru> cyphermox, ping
[21:22] <robru> hmmmm, packages.ubuntu.com only goes back as far as oneiric.... does anybody know how I might find out what version of a particular package shipped with lucid?
[21:23]  * robru puts on his Historian hat ;-)
[21:27] <robru> oh, weird, there we go: http://packages.ubuntu.com/source/lucid/network-manager
[22:20] <cyphermox> robru: pong
[22:20] <cyphermox> yeah, that sounds about right
[22:20] <robru> cyphermox, oh hey, yeah ;-)
[22:20] <cyphermox> anything specific you're wondering about network-manager?
[22:21] <robru> cyphermox, ok, well, basically what I'm needing is to just receive a signal whenever the network is connected or disconnected.
[22:21] <cyphermox> ah
[22:21] <robru> cyphermox, we already had some code for that, but it was really convoluted because it was trying to support 0.8 and 0.9 simultaneously ;-)
[22:21] <cyphermox> in C or python?
[22:21] <robru> cyphermox, was hoping to simplify it ;-)
[22:21] <robru> cyphermox, the new code will be vala actually.
[22:21] <cyphermox> C then :)
[22:22] <robru> cyphermox, :-P
[22:22] <robru> cyphermox, I'm not writing any C :-P
[22:22] <cyphermox> there are two aspects there
[22:22] <cyphermox> do you really need to support before 0.8?
[22:22] <robru> cyphermox, just using d-feet I see there's the StateChanged signal
[22:23] <robru> cyphermox, no, don't need to support 0.8 at all. it's just that the legacy gwibber code I inherited was already doing that. I was just trying to determine if it was feasible to toss it
[22:23] <cyphermox> yeah
[22:24] <cyphermox> you're not likely to ship new things to pre-oneiric
[22:25] <cyphermox> robru: so the real difference is mostly that state is now split from NM_STATE_CONNECTED into _LOCAL, _SITE, and _GLOBAL
[22:26] <robru> cyphermox, does that mean what it sounds like it means?
[22:27] <cyphermox> robru: I don't know?
[22:28] <cyphermox> it's three similarly name state enum types rather than just one
[22:28] <cyphermox> or perhaps more simply: http://projects.gnome.org/NetworkManager/developers/api/09/spec.html#org.freedesktop.NetworkManager
[22:28] <robru> cyphermox, but, like, _GLOBAL refers to the internet, _SITE refers to the local LAN, and _LOCAL refers to the loopback device, right?
[22:28] <cyphermox> see the StateChanged signal
[22:28] <cyphermox> kind of
[22:29] <cyphermox> but you'll want to deal with all three the same way for now
[22:29] <cyphermox> that only really makes much of a difference on IPv6
[22:29] <cyphermox> and there's further reasons why we don't differenciate (e.g. connectivity checking, which we don't do quite yet)
[22:30] <robru> cyphermox, our current implementation looks like this: http://bazaar.launchpad.net/~super-friends/friends/trunk/view/head:/friends/service/connection.py
[22:32] <cyphermox> yeah looks about right
[23:40] <bdrung> tjaalton, bryce: xkeyboard-config needs to be multiarchified. do you want to merge from Debian and add the multi-arch support or should i do that?
[23:58] <bryce> bdrung, go for it