[00:14] mterry, ping [00:15] robru, yo [00:15] mterry, do you have a sec to help me with more vala async voodoo? [00:16] robru, sure [00:16] mterry, ok, so I've got a number of methods that look like this: http://paste.ubuntu.com/1595270/ [00:17] 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] 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] robru, begin can't do that [00:18] robru, begin as you see exits quick. There's no current syntactic sugar for doing what you want. [00:18] robru, you need to make a new GLib.MainLoop() [00:18] robru, and run it, and exit it in the callback [00:19] or rather .quit() it in the callback [00:19] mterry, what are the implications of having a bunch of mainloops happening concurrently? will they interfere with each other in any way? [00:19] and .run() it after the .begin() call [00:19] robru, no [00:20] robru, shouldn't be any problems with nested loops [00:20] 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] 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] robru, but I don't think MainLoops are expensive [00:22] mterry, ok [00:22] 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] http://bazaar.launchpad.net/~super-friends/friends/trunk/view/head:/friends/utils/authentication.py#L45 [00:23] robru, ah, that's actual blocking. I don't like doing that [00:23] (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] 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] robru, I vote MainLoop, but if you can afford to real block, sleep is fine [00:25] mterry, ok, I'll try to figure out mainloops ;-) [00:25] robru, I see, there, real blocking was a feature not a bug :) [00:26] * mterry has to go [00:26] mterry, ok great, thanks [05:59] Good morning [05:59] pitti: word. [06:00] desrt: bonjour, comment est FOSDEM? [06:01] ĝi ne ekis ankoraŭ [06:08] desrt: right, I mean the GNOME hackfest [06:08] ah. bona [06:08] hodiaŭ estas la fina tago [06:09] ĉu vi venos hodiaŭ aŭ morgaŭ? [06:21] desrt: ^ heh, I can decipher that without gtranslate :) [06:22] desrt: je vais arriver à demain [06:22] pitti: that's the point! [06:29] does totem work in raring for most? I haven't figured what's causing bug #1103747 [06:29] Launchpad bug 1103747 in totem (Ubuntu) "Totem could not startup." [Undecided,Confirmed] https://launchpad.net/bugs/1103747 [06:31] Mirv: yeah, since glibc 2.17 it works perfectly here [06:40] I thought so, given the low visibility in LP [06:40] but interesting: libgstclutter.so is blacklisted for me... [06:41] I wonder what's doing that and where [07:16] updated the bug a bit but didn't find anything useful [07:28] good morning [08:15] 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] good night all! [08:15] robru: goodnight === Ursinha is now known as Ursinha-afk === vrruiz_ is now known as rvr_ [10:38] ah, crap @ https://bugzilla.mozilla.org/show_bug.cgi?id=836050 [10:38] Mozilla bug 836050 in DOM "Make Element::GetAttr/HasAttr/AttrValueIs non-virtual" [Normal,Resolved: fixed] [10:38] that's the end of our addon now ;) [10:40] how come? [10:41] Laney, these functions aren't exposed. the only reason we ever managed to use them is because they were virtual [10:41] which sucks [10:42] the reality is, binary addons are dead [10:42] and this is pretty much the final nail in the coffin [10:42] which means i need to urgently finish off my reimplementation of this, else we'll be shipping an update without a menubar ;) === Ursinha-afk is now known as Ursinha [11:43] Mirv: confirmed, it broke today [11:43] (totem) [11:44] it just takes ages to start === ricotz__ is now known as ricotz [11:51] lovely, lightdm lost fat ! [11:52] thats impressive ... 27MB less [11:59] 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 === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [12:58] * ogra is impressed, so my idling desktop on the nexus7 is down from 640M to 357 here [12:58] according to htop at least [13:37] does anybody else get "WARNING **: Couldn't register with accessibility bus:" warnings and long hangs for each and every program now? [13:58] 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] nice ! thanks [13:59] 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] hehe [14:15] pitti, no such issue here [14:16] pitti, you have at-spi-core2 installed I guess? [14:17] oh, no, I don't [14:17] oh, at-spi2-core; I do have that [14:20] seb128: FYI, finally tracked down the weird gvfs autopkgtest failure, uploaded a fix [14:20] pitti, great === Quintasan_ is now known as Quintasan === Ursinha-afk is now known as Ursinha [14:46] ogra, the meeting is in 1h15 right? [14:47] hum, I'm pretty sure it is ;-) [14:47] in any case I'm off an hour for exercice, will be back on time for it === Ursinha is now known as Ursinha-afk === jbicha is now known as Guest65975 === Guest65975 is now known as jbicha_ [15:02] pitti: I see that message but it doesn't seem to noticeably delay startup [15:18] 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] Laney: ok, then maybe I just need to restart my session [15:18] lool: no it's blocked on kernel headers being broken [15:19] I haven't looked back to see if those were fixed yesterday though [15:19] it was still being discussed on LKML not long ago so I assumed it wasn't patched anywhere yet [15:19] I would really rather not upload connman with a ugly hack to make it work [15:21] 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] gtk 3 already built an moved to raring [15:22] why the hell is it uninstallable in a buildd? [15:23] I already retried the build [15:23] oh, now http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html is full of it [15:23] it wasn't yet when I retried [15:24] cyphermox: sorry for interrupting your leave; thanks for the pointers! [15:25] so what broke -proposed so hard? [15:25] skew from libxkbcommon it seems [15:25] lool: ah, I'm still looking at IRC for the next hour or so [15:25] cyphermox: Kernel headers > is that a case of headers not being in linux-libc-dev? [15:26] cyphermox: Worst case, we can copy a header from linux until this is sorted out? [15:26] nah, it's some incompatibility between the headers in the kernel and what's in libc [15:26] err, wait [15:26] cyphermox: do you have a link to that? [15:26] lool: I did patch it locally in my bzr branch [15:26] ah great [15:26] why does libgtk-3-0 have such a tight dep on libxkbcommon0? [15:26] http://bazaar.launchpad.net/~mathieu-tl/connman/1.10/view/head:/debian/patches/fix_build_with_kernel_3.8.0.patch [15:27] looking [15:27] Laney: yeah, that seems a bit excessively tight [15:27] -V? [15:27] 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] $ cat /var/lib/dpkg/info/libxkbcommon0.shlibs [15:27] libxkbcommon 0 libxkbcommon0 (= 0.2.0-0ubuntu1) [15:27] Laney: ^ seems so [15:28] # Keep a close eye on the shlibs for the time being: [15:28] override_dh_makeshlibs: revision=$(shell dpkg-parsechangelog|grep ^Version:|sed 's/Version: //') [15:28] override_dh_makeshlibs: dh_makeshlibs -V "libxkbcommon0 (= $(revision))" [15:28] at least libxkbcommon is "valid candidate", so it should hopefully clear itself up now [15:28] 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] no it won't [15:29] it's a transition [15:29] bdrung: ^^^^^^ [15:29] seems to only be gtk and weston though [15:30] tjaalton: do you know if that shlibs condition can be relaxed now that libxkbcommon is considered more stable? [15:30] lool: ack, I'll just run it through sbuild one last time here to be sure it builds properly [15:31] cyphermox: we don't even have the command-line tools in the current Ubuntu packages, do we? [15:31] no [15:31] but it's in my package [15:31] 0.78 -> 1.10 is definitely a great win; the linux header thing is really minor in comparison [15:33] tjaalton: (also, I don't see the recent Ubuntu changes in git; would be nice to have them there IMO) [15:33] Laney: oh indeed, we'll need to rebuild gtk3 against it, sorry [15:33] Laney: care to add a block to libxkbcommon? [15:34] Laney: this shouldn't migrate to raring as it is, it'll make everything uninstalalble [15:34] Laney: too bad that britney doesn't pick that up [15:34] pitti: britney does pick it up [15:34] pitti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is generally the more interesting file [15:34] lool: there is also a patch in bts that would be nice to have [15:34] _excuses is just package-local checks [15:34] Laney: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate" [15:35] Laney: oh, ok; so it will not go in? [15:35] that means something like "valid to pass to the second stage" [15:35] indeed - see libxkbcommon there [15:35] Laney: so "skipped" means "thumbs down"_ [15:35] _ [15:35] eek, kbd lazout [15:35] ? [15:35] yeah [15:36] then the i386:... is all the packages that get made uninstallable [15:36] ok, thanks [15:36] I'd like tjaalton to comment on whether we can just use standard -V nowadays [15:36] 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] so that we can future proof this [15:37] 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] cyphermox: are we still using https://code.launchpad.net/~connman-maintainers/connman/ubuntu.head ? [15:37] not sure I can write to that [15:37] lool: nah [15:38] I based on debian's 1.0 [15:38] (BTW the old Ubuntu changelog entries seem to be gone; not sure if it's on purpose) [15:38] I'll include the patch in BTS (via uploading / merging this with debian and uploading to unstable with some help) [15:38] err [15:38] I must have forgotten to add them back [15:39] lool: it's not quite meant as a merge though, more like a sync with additional changes :) [15:39] 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] 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] I was just double-checkig [15:40] yeah, that's what I did [15:40] 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] yes [15:41] there is some code that works for gtk2/ gnome-panel [15:41] it's not amazing, only works in xfce and the like, but it helps out [15:41] we really need a proper indicator to be written [15:41] it's a good start while an indicator doesn't exist [15:41] yes [15:42] we could even push it as far as having the same hack as nm-applet [15:42] https://github.com/tbursztyka/connman-ui [15:42] yes, possibly [15:42] I can package that on monday [15:42] (unless it's needed earlier [15:43] cyphermox: it's not critically urgent to get the UI [15:43] let's chat about it on Monday === Ursinha-afk is now known as Ursinha [15:44] sure [15:44] lool: connman 1.10 uploaded. [15:45] 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] cyphermox: thanks a lot [15:45] cyphermox: and have a good week end [15:46] you too [15:51] seb128, 17:30 paris time :) [15:52] ogra: does today image actually work for bluetooth now? [15:52] well, i havent re-installed since a while, it works fine here though [15:52] ok [15:52] I could pair but not send a file from my phoen to the N7 [15:52] Laney: ah, thanks [15:53] could be the android side being buggy [15:53] maybe the n7 doesn't have the gnome file sharing bits? [15:53] cyphermox, http://cdimage.ubuntu.com/daily-preinstalled/20130201/raring-preinstalled-desktop-armhf+nexus7.manifest shows "brcm-patchram-plus-nexus7 0.1.1" [15:53] great [15:53] yesterday's didn't have it [15:53] i can connect my kbd and a headset here [15:53] it just doesnt survive suspend [15:55] aye [15:55] ok so we'll need to figure out what's up with suspend [15:57] ogra, 17:30 ... trying to trick me 30min late? ;-) [15:57] heh, was it earlier ? [15:57] * ogra is confused [15:58] ogra, isn't the time 17:00? [15:58] ogra, I though it was on the hour, not half past [15:59] yeah, you are reight 16:00 UTC [15:59] hehe [15:59] you did try to trick me in being late! [15:59] now ... so to say [15:59] no, i'm just a bit confused, too many vet. visits this week [16:03] Laney: oh.. yes it can be relaxed. and the latest merge/sync is in git [16:03] the one I did anyway [16:05] seb128: where is the meeting? [16:07] attente, #ubuntu-meeting [16:11] Laney: yeah, we should relax the shlibs condition for libxkbcommon. i will do that. [16:11] Laney: so, should I upload a new libxkbcommon dropping it? [16:11] bdrung: please don't === mlankhorst is now known as ml2fosdem [16:13] tjaalton: why not drop the shlibs condition and add a symbols file? [16:14] bdrung: I've dropped it locally already [16:14] updating the branch atm [16:14] tjaalton: so you wanted to stop me because you are working at it? [16:14] bdrung: yes :) [16:14] okay :) [16:15] tjaalton: will you add a symbols file? [16:15] good idea, didn't do that yet.. [16:16] tjaalton: and please use 3.0 (quilt) source format or get the direct source changes converted to a patch [16:16] bdrung: it's pkg-xorg, 3.0 is a no-no [16:17] why? [16:17] ask jcristau [16:17] or don't [16:17] :) [16:17] then please specify version 1.0 in debian/source/format [16:18] yeah [16:18] this will make clear that there were made a decision [16:25] tjaalton: cool, then please upload gtk and weston once you've done that [16:26] seb128: your staged gtk changes drop a symbol without updating the file [16:26] I'll update both wayland & weston too (1.0.4) [16:26] did you make sure nothing uses it ... [16:27] 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] 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] someone uploaded libxkbcommon-0.2.0-0u2 already? [16:36] or since jan 9th [16:36] *after [16:38] yes, that's what alerted us to this [16:39] 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] bug :) [16:43] Laney: ok, uploaded -0u3 [16:43] great [16:43] I'll upload gtk; you do w* [16:44] yeah [16:44] was about to ask someone else to take care of gtk :) === m_conley_away is now known as m_conley === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === mpt_ is now known as mpt === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:07] cyphermox, ping === sabdfl_ is now known as sabdfl [21:22] 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] oh, weird, there we go: http://packages.ubuntu.com/source/lucid/network-manager === Ursinha is now known as Ursinha-afk === m_conley is now known as m_conley_away [22:20] robru: pong [22:20] yeah, that sounds about right [22:20] cyphermox, oh hey, yeah ;-) [22:20] anything specific you're wondering about network-manager? [22:21] cyphermox, ok, well, basically what I'm needing is to just receive a signal whenever the network is connected or disconnected. [22:21] ah [22:21] 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] in C or python? [22:21] cyphermox, was hoping to simplify it ;-) [22:21] cyphermox, the new code will be vala actually. [22:21] C then :) [22:22] cyphermox, :-P [22:22] cyphermox, I'm not writing any C :-P [22:22] there are two aspects there [22:22] do you really need to support before 0.8? [22:22] cyphermox, just using d-feet I see there's the StateChanged signal [22:23] 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] yeah [22:24] you're not likely to ship new things to pre-oneiric [22:25] robru: so the real difference is mostly that state is now split from NM_STATE_CONNECTED into _LOCAL, _SITE, and _GLOBAL [22:26] cyphermox, does that mean what it sounds like it means? [22:27] robru: I don't know? [22:28] it's three similarly name state enum types rather than just one [22:28] or perhaps more simply: http://projects.gnome.org/NetworkManager/developers/api/09/spec.html#org.freedesktop.NetworkManager [22:28] cyphermox, but, like, _GLOBAL refers to the internet, _SITE refers to the local LAN, and _LOCAL refers to the loopback device, right? [22:28] see the StateChanged signal [22:28] kind of [22:29] but you'll want to deal with all three the same way for now [22:29] that only really makes much of a difference on IPv6 [22:29] and there's further reasons why we don't differenciate (e.g. connectivity checking, which we don't do quite yet) [22:30] cyphermox, our current implementation looks like this: http://bazaar.launchpad.net/~super-friends/friends/trunk/view/head:/friends/service/connection.py [22:32] yeah looks about right [23:40] 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] bdrung, go for it