[00:24] how do you get freenode chat in empathy? [01:11] pitti: Thanks for that synaptic invocation code, however I am dealing with C++ which means I will have to do a little more fiddling to get the same functionality, and since its a universe package, I am more enclined to simply disable the install functionality of paprefs. [01:47] how does xsplash work? [01:47] does it require gdm? [02:09] trip0: Gdm loads xsplash via dbus when gdm starts, then the session script loads xsplash when the user logs in using gdm. [02:09] trip0: I think thats how it works anyway. [02:12] TheMuso: so [login-manager] needs to start xsplash via dbus [02:12] is xsplash a deamon or somthing? [02:12] daemon* [02:29] trip0: Not sure. I think gnome-session signals it to be killed over dbus though. [03:25] keybuk: Here’s an untested implementation. It probably breaks your system and leaks memory, but it’s a start. Hey, at least it compiles without warnings. :-P http://heh.fi/patches/mountall/ === ecanto is now known as edson [03:26] keybuk: I’ll have a better capability to test mountall patches as soon as i can get my system to run *some* version of mountall. ;-) [03:26] keybuk: As in, boot using it [06:03] good morning [06:07] * slangasek waves [06:07] hiya slangasek [06:11] hello, mister Holbach, mister Langasek [06:12] Señor Wirzenius? [06:12] Como estas? :) [06:12] que? :) [06:21] * poningru provides a flower for dholbach to wear [06:51] could i get some ubuntu python maintainers to look at bug 392355? [06:51] Launchpad bug 392355 in bzr "C extensions placed in wrong directory on karmic" [High,Confirmed] https://launchpad.net/bugs/392355 [06:51] it seems to fairly seriously break programs that build compiled extensions on karmic [07:25] * YokoZar has been waiting for python2.6 binary to be in sync with source package version so he can update ia32-libs all day now... [07:27] https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.2-0ubuntu4/+build/1188649 [07:27] Missing build dependencies: libreadline6-dev [07:28] YokoZar: ^ [07:28] Hmm yeah...should that take all day? [07:28] Since the depend needs to finish first [07:28] the build depends is missing [07:29] Does that mean the build depends is being rebuilt? [07:29] aha [07:29] https://edge.launchpad.net/ubuntu/+source/readline6 [07:29] it's in universe [07:29] python2.6 is obviously in main [07:30] not sure that requires a MIR [07:30] but it's something the archive admins should look into [07:30] Good morning [07:30] hopefully we won't have 2 readline versions in main for karmic [07:30] hi pitti [07:31] TheMuso: OOI, how is it harder in C++? Anyway, I'm fine with just disabling it [07:33] So this is basically a chain of 5 blockers that lead me to readline6 now: Some patches to wine (failing to build) --> needs ia32-libs update --> needs new python2.6 --> needs libreadline6-dev --> needs an MIR [07:35] YokoZar: just needs a MIR bug, not a full wiki page; it's just a new version after all [07:35] Ahh ok [07:35] Poke doko for me he caused this ;) [07:41] pitti: OTOH, does this mean we're stuck with two versions of readline on the CDs now, or is someone taking responsible for transitioning us to readline6? [07:41] heh, "taking responsible" [07:41] slangasek: wine isn't on the CD? [07:41] no but python2.6 is [07:41] pitti: readline6 needs an MIR because of python2.6; everything else uses readline6 [07:41] ah, I see [07:41] 5 [07:41] The only thing this has to do with Wine is that python2.6 failing to build is blocking ia32-libs [07:41] $ apt-cache rdepends libreadline5|wc -l [07:42] 325 [07:42] we might not finish that in karmic.. [07:42] yep - so why do we want to start it, I wonder [07:42] it's an extra 150 kB, so it won't kill us, but perhaps it's possible to build python2.6 with libreadline5? [07:43] the change was made in an Ubuntu point revision - so yes, it should be possible [07:43] right, in http://launchpadlibrarian.net/30822021/python2.6_2.6.2-0ubuntu3_2.6.2-0ubuntu4.diff.gz [07:44] that pulled in new upstream code [07:44] ah, hmm [07:44] mvo: morning! [07:44] but nothing that seems to check the version of libreadline [07:44] hey slangasek [07:44] mvo: does it alarm you if I greet you eagerly? :-) [07:45] We could just try an upload with the older version and see if it still works ;) [07:45] slangasek: it does :P [07:45] slangasek: so yes, should be possible [07:45] mvo: do you think you could take a look at https://launchpad.net/ubuntu/+source/vips/7.18.1-1ubuntu3/+build/1207710 ? regression introduced by the zlib1g change, only affects !64-bit archs :/ [07:45] slangasek has a pile of work for mvo I bet [07:45] slangasek: startling even [07:45] * slangasek grins [07:45] slangasek: *weh* sure, I have a look [07:46] mvo: in the future I will try to greet you eagerly when I'm not asking you to do work [07:46] to put you more at ease [07:46] (and lull you into a trap) [07:46] :) [07:47] * mvo makes a pot of tea and attacks the zlib problem [07:47] mvo, over here [07:47] i was just going to ask you about https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.2-0ubuntu4/+build/1188649 [07:47] * mvo waves to YokoZar [07:48] slangasek: I'll change python2.6 [07:48] pitti: ok [07:48] pitti: so you take care of the above build-failure? [07:49] (or is there another python2.6 change in the works) [07:49] mvo: it's in depwait [07:49] mvo: or what do you mean? [07:49] pitti: it seems that libreadline6-dev is in universe [07:49] mvo: right, that's what we just discussed, I'll change it back to 5 [07:50] pitti: thanks, I missed the earlier part of the discussion (joined too late) [07:50] poolie: ^--- pitti deals with it :) [07:50] * pitti hugs mvo [07:50] * pitti hugs poolie, too [07:50] * mvo hugs pitti [07:50] poolie: you wrote an awesome VCS, you deserve some help :-P [07:51] pitti: thanks ;) Nice to have the german crew working on this through the night [07:51] "night"? [07:51] I already slept in, until 8:30.. [07:51] Yes, real time is where I live. [07:52] :) [07:52] thanks pitti [07:53] i don't desperately need it fixed but i'd like if someone could at least triage it [07:58] slangasek: what do you think of including some of the various thumbnailers that are stuck in universe onto the CD? [07:58] eh? [07:58] I think this is late in the cycle to be proposing new features to squeeze onto the CD [07:59] Well one I proposed at UDS (gnome-exe-thumbnailer) [07:59] but when I was making it I found gnome-raw-thumbnailer (gives thumbnails of digital camera raw files) and two other minor ones [08:06] pitti, mvo, so how about https://launchpad.net/bugs/392355 (sorry to nag) [08:06] Ubuntu bug 392355 in bzr "C extensions placed in wrong directory on karmic" [High,Confirmed] [08:08] YokoZar: installing gnome-exe-thumbnailer pulls in 600K of installed packages onto my system when I try to install it; this really should have been seeded earlier in the cycle, IMHO [08:09] YokoZar: you can file a bug against ubuntu-meta and/or start a discussion on ubuntu-devel -- either of those is better than trying to persuade me personally to seed it :) [08:09] How about I give up in despair and come to the next UDS with a petition to switch to memory sticks and DVDs ;) [08:10] poolie: no problem, its more a doko type question, but I can have a look too. I probably need a bit (because I need to compare old/new python-defaults) [08:10] cool, thankyou [08:11] oh, I reassigned it to python2.6 on the assumption that it was probably a problem with the code there [08:11] if it belongs on python-defaults after all, feel free to reassign it back ... [08:13] Does ubuntu have anything like a build/test farm for different arches that developers can get shell access to? I seem to remember Debian having something like this [08:15] Canonical has porter machines that employees can access; unfortunately there are no porter machines open to the Ubuntu community [08:17] slangasek: thanks === enrico_ is now known as enrico [08:22] slangasek: hm, python2.6 is FTBFS [08:22] make[1]: *** No rule to make target `libpython2.6.so', needed by `python'. Stop. [08:22] but nothing that points to the libreadline change.. [08:22] yuck? [08:22] so I better not upload this [08:22] if you insist :-) [08:23] * pitti uploads to his PPA to check whether it's some local issue === tkamppeter_ is now known as tkamppeter === pochu_ is now known as pochu [09:20] hm, the new gdm greeter in karmic does not have any (visible?) way to invoke failsafe sessions [09:20] gnome-session: Fatal IO error 11 (Resurssi ei tilapäisesti ole käytettävissä) on X server :0.0. [09:20] that's ... intriguing [09:21] liw: choose a user, then choose xterm session? [09:21] pitti, how do I choose xterm session? [09:21] liw: in the session chooser in the bottom bar [09:22] I haven't got one [09:22] liw: did you choose a user first? [09:23] er, sorry, mea culpa [09:23] (that was confusing to me) [09:23] anyway, the real problem is that my SO's account can't log in [09:25] this has been going on for a few days, but I've only had time to look at it now === dholbach_ is now known as dholbach === Ng_ is now known as Ng [09:30] hm, I created another account, and it, too, fails to log in via gdm [09:33] hi liw [09:33] thanks for looking at it cjwatson [09:33] hi poolie [09:34] hi pitti, good morning. Thanks for copying the listed jaunty langpacks to -updates. May I ask you to also copy the 'es' language pack? The Spanish guys did some last minute testing and posted a message on the list (http://tinyurl.com/m87dto), but they didn't CC you. It would be quite good to have it in -updates, since that particular one solves quite a lot of bugs (sorry for not getting the list of languages all at once) [09:35] dpm: done [09:35] pitti: thanks! [09:48] does anyone else have a problem with logging in with accounts other than their own? (easy to test: create new account with 'adduser tomjon' and then switch user to it) [09:49] bug #426159 is the one I reported about this [09:49] Launchpad bug 426159 in gnome-session "Cannot log in via gdm" [Undecided,New] https://launchpad.net/bugs/426159 [09:51] no issue there to log with different accounts [09:51] and gnome-session didn't change for a while I doubt it's due to it [09:51] look into your Xorg.n.log? [09:52] the .xsession-errors has lot of display not available errors, could be xorg crashing for you [09:54] why would it crash for tomjon but not liw? [09:55] liw: it doesn't like tomjon [09:56] does it crash for tomjon if you try to start that session first? [09:56] it could be a "second xorg session is crashing" sort of issue [09:56] seb128, I did not have another session open when logging into tomjon [09:56] ok so I don't know [09:56] would be useful to have gnome-session debug log [09:57] do you get the issue if you run gnome-session? [09:57] how do I get a gnome-session debug log? how do I run gnome-session? [10:00] slangasek: so, the problem with the zlib stuff is that off64_t is not defined on 32bit machines unless USE_LARGEFILE64 is used. I can add a #if _FILE_OFFSET_BITS ==64 && !defined(_LARGEFILE64_SOURCE) #define off64_t off_t #endif #endif - also I have to say that I don't really like this, its getting ugly and this messing around is not to my liking [10:01] liw, start a non GNOME session either by selecting the debug one in gdm or using startx [10:01] liw, and run gnome-session --debug [10:08] seb128, attached to bug [10:08] looking [10:09] seb128, and it got reassigned to xorg-server [10:09] right, chrishcoulson seems to think the same thing than me [10:10] liw, when you run gnome-session by hand does it start normally? [10:11] liw, do you use compiz for your normal user? [10:11] seb128, nope, it dies before anything shows up (like panels), in a few seconds [10:11] liw, can you start the debug session and just run compiz there? [10:12] I would say that compiz makes your xorg crash [10:12] you might not be using it with your normal configured session? [10:12] seb128, I use metacity with my account liw, not compiz; compiz won't start on this machine [10:12] well the gnome-session log shows that it tries starting [10:12] I'll see what starting it manually does [10:12] thanks [10:13] if that crashes xorg you know what the difference and the issue is [10:14] it's dead. dead I tell you. dead, dead, dead. dead as a 3D accelerated dodo. [10:14] i.e., X crashes after running compiz manually from tomjon's xterm session [10:16] liw, ok, so it's an xorg bug, adding the Xorg.0.log to the bug would be useful [10:16] look to /var/crash too if there is a .crash about it [10:16] compiz does some capability detection on start but that should not crash xorg [10:17] removing compiz does not prevent the problem, though [10:17] how removing it? [10:18] you can run gconf-editor and change /desktop/gnome/session/required_components/windowmanager [10:18] cjwatson: could you please double check http://paste.ubuntu.com/267107/ ? it fixes a ftbfs for 32bit plattforms where off64_t is not always defined (I'm not too happy about it, but I don't see a really cleaner way - testing #if __off64_t_defined would be possible but even more ugly) [10:18] I removed the compiz package [10:18] it's gnome-wm by default which tries to be clever but you can set any wm you want there [10:19] oh, but there's a million compiz packages [10:20] there, removing all of them fixed it [10:21] cjwatson: alternatively we can just revert my upload and see what upstream comes up with [10:22] liw, still add your xorg infos to the bug it should not crash [10:22] seb128, I already did [10:22] ok [10:29] mvo: I guess you should at least at !defined(off64_t) to it, so that zlib.h can be included twice [10:29] add even [10:31] mvo: I think I'd prefer it if we had a zlib_off64_t define which is defined to off_t [_FILE_OFFSET_BITS=64] or off64_t [_LARGEFILE64_SOURCE], rather than scribbling over off64_t itself [10:32] mvo: seems less likely to cause failures elsewhere [10:32] mvo: (adjust name of zlib_off64_t to whatever seems locally suitable, of course) [10:32] cjwatson: yeah, that makes sense, I create a new diff now [10:32] sistpoty|work: thanks [10:32] the problem with #define off64_t is that off64_t is actually a typedef elsewhere [10:32] and so it seems likely that you'd create weirdness ... [10:34] cjwatson: agreed, I did test, but of course not all cases, so being careful is better [10:46] cjwatson: does http://paste.ubuntu.com/267126/ look ok? [10:47] would it be simpler to just #include sys/types.h or whatever defines off*_t? or is that harmful from namespace pollution reasons? [10:48] oh, no, I misunderstood the probelm [10:48] mvo: yeah, that's what I was thinking and looks better to me [10:49] cjwatson: great, thanks a lot for your review [10:51] btw: just curious why does it happen at all on 32bit? from a quick look at features.h and unistd.h off64_t should be defined in the _LARGEFILE64_SOURCE case? [11:15] geser: you've got it the wrong way round; it happens on 32-bit and when _FILE_OFFSET_BITS=64 but *not* _LARGEFILE64_SOURCE [11:16] _FILE_OFFSET_BITS=64 means "just make everything 64-bit, don't bother with the separate *64 versions of things" [11:21] ah [11:31] Is there a way to do a touch in a patch? [11:31] lool: not that I know of; but you could patch the file to just have a newline or so? [11:32] Yeah, I was looking for something a bit more elegant but that will do [11:33] thanks === MacSlow is now known as MacSlow|lunch [12:30] pitti: Well not harder, just got to do things differently. [12:51] the PPA system hates me, it keeps giving my builds scores like "4" and says it'll build in 27 weeks [12:52] Keybuk: you need to pay, and get a private PPA with automatic natural scores :) [12:52] I thought 4 was the special score auto-assigned to rebuild archives? [12:52] Daviey: fortunately being a TB member means I can fiddle the scores myself ;) [12:53] Keybuk: Buy a new shiny bladecenter full of neat bl460c g6 blades with plenty of ram, those are speedy. ;) [12:53] maswan: ?! on my salary !! [12:53] Keybuk: hah [12:53] (also, gives incentive to someone else to fix the issues I've found so far ;) ) === MacSlow|lunch is now known as MacSlow [13:12] seb128: did you request a sync, or should i? [13:12] neither of those, I will sync it today I was waiting for the binary to be on the mirrors === zul_ is now known as zul [13:17] ah. okay then [13:23] hyperair, hey. So, how about fixing another translation problem today huh? :) gdebi is ready and waiting :P [13:24] ready to what? [13:32] TomaszD: maybe next week [13:33] seb128, to get fixed ;) [13:33] hyperair, ok [13:33] if nobody has already fixed it by then =) [13:33] out of curiosity, what's wrong with gdebi? [13:34] hyperair, not really sure, seems to be that there are similar symptoms to nautilus-share [13:34] but not much else I can tell [13:40] it's probably a one-liner change [13:40] lemme test this out [13:42] TomaszD: as i thought. a one-liner change. [13:42] TomaszD: today's your lucky day. i got gdebi fixed =) [13:43] hyperair, awesome! thanks! [13:43] is there a bug for this? [13:44] hyperair, https://bugs.launchpad.net/ubuntu-translations/+bug/425812 [13:44] Ubuntu bug 425812 in gdebi "gdebi does not use translations at all" [Undecided,New] [13:44] hyperair, I'm curious, was that a POTFILES.in breakage? [13:44] TomaszD: no. not at all. [13:45] TomaszD: gtkbuilder is a screwed thing when it comes to translations. =\ [13:45] well it's a good thing the whole GNOME project isn't moving to... well shit [13:45] seb128: if i'm going to have to manually set_translation_domain for every gtk builder object i have, i believe gtkbuilder is the one at fault. [13:46] right [13:46] how did you fix the nautilus-share one? [13:46] by setting the translation domain [13:46] the same thing goes for gdebi [13:46] i poked around totem's code and found that it also does the gtk_builder_set_translation_domain function [13:47] slangasek: system-config-printer's udev-configure-printer hook - does that *need* to be a udev hook? [13:47] slangasek: or, to phrase the question better [13:47] it's weird, other software work fine without that [13:47] ie update-manager, alacarte [13:47] does that binary do anything which could affect the configuration of the device in such a way that other applications or tools using that device should wait for it to be complete? [13:47] seb128: seriously? [13:48] well I just looked to alacarte and it only does the gettext domain call [13:48] same for update-manager [13:48] hmm [13:48] how strange, eh.. [13:48] nowhere else? [13:48] at all? [13:48] I think things coming from nautilus are special because nautilus change the gettext domain [13:48] seb128, neither update-manager nor alacarte work fine [13:48] but standalone applications should just work [13:48] alacarte is also broken [13:48] I just checked [13:49] TomaszD, categories are translated there [13:49] seb128, yes, but "Menus", "Items", all the buttons are not [13:49] seb128: make sure you look at the parts that are *only* specified in the .ui file, not parts which are modified by the app [13:49] right [13:49] seb128: nautilus-share and gdebi's issues were like that. [13:49] and i don't think gdebi has any change of translation domains [13:49] right [13:49] by the way, glade worked perfectly wrt translation domains [13:49] update-manager has the same problem really, it was just mudded slightly because the template wasn't regenerated [13:50] I'm wondering if pygtk is not broken [13:50] TomaszD, that has nothing to do with templates [13:50] maybe a test app would be good.. [13:50] I know, but the old strings which were translated a long time ago don't show up as translated seb128 [13:50] TomaszD, and? [13:50] so that leads me to believe that there is an additional problem, ie. gtkbuilder one [13:51] well C softwares are not broken [13:51] let's try gtkmm [13:51] alright, I thought update-manager was a python application, not a C app [13:52] it is a python application [13:52] ok, so it was just a general comment about C apps [13:52] ? [13:52] yours [13:52] nevermind :) [13:52] I say I didn't notice an issue with C softwares [13:52] so I would blame pygtk rather than gtk [13:52] right, that's what I was trying clumsily to refer to [13:54] what else is there using gtkbuilder, I believe computer-janitor and usbcreator need looking into as well === marjomercado is now known as marjo [13:57] TomaszD, er, what? what's up with c-j? [13:58] liw, sorry I'm losing track of my bug mail, it would seem you have fixed the issue [13:58] :) [13:58] ok [13:58] doesn't seem a gtk issue in any case, ld preloading the jaunty version does no difference [13:59] liw, but! if this app is using gtkbuilder, you might want to look at the hints about about this "gtk_builder_set_translation_domain" thing [13:59] *above about [14:00] I don't want to read through lots of backlog, please summarize [14:00] liw, "...i'm going to have to manually set_translation_domain for every gtk builder object i have..." [14:01] liw, might be a bug somewhere, but this seems to be a good workaround [14:01] that's not what he wrote exactly [14:01] and I would rather focus on finding the pygtk issue than workarounding every software [14:02] that's reasonable, but there is no guarantee of finding the issue, and shipping with untranslatable apps isn't a nice prospect, at least that's how I see it [14:05] if it can't be fixed in pygtk, then file bugs, but please wait with that until pygtk is deemed unfixable for karmic [14:05] sure, I'll try to remember that [14:07] thanks [14:10] TomaszD, why wouldn't it be fixable, there is months before karmic [14:10] I think it's a matter of debugging for one hour or so [14:12] seb128, you know, I'm freaking out because the release of GNOME is near (I'm an upstream translator), I'm probably influenced by that [14:13] TomaszD, we will have 2.28.1 in karmic [14:13] seb128, well that's a relief [14:14] TomaszD, http://bugzilla.gnome.org/show_bug.cgi?id=574520 [14:14] Gnome bug 574520 in documentation "gtk.Builder translations fail" [Normal,New] [14:18] cjwatson: Bug #425922 looks like something in your domain to me. Would you agree? [14:18] Launchpad bug 425922 in eucalyptus "Eucalyptus component registration process is manual " [Medium,Triaged] https://launchpad.net/bugs/425922 [14:20] seb128, so it's not a bug, it's just a specific way of handling translations? [14:21] soren: yes, probably [14:21] cjwatson: Would you mind terribly if I reassigned bugs about the avahi magic in Eucalyptus to you? [14:22] TomaszD, not sure yet [14:22] ok [14:23] ogra__, could you push your tomboy changes to bzr? [14:23] soren: ok by me [14:24] seb128, is that really needed ? they should hit debian today with a new upstream [14:24] ogra: what? updating bzr when you upload a package maintained in bzr? yes [14:24] ok [14:24] the reason I ask it's because rodrigo ask us about it [14:24] ok [14:24] it seems to block him in online service changes [14:25] will do before end of my day [14:25] heh [14:25] rodrigo is waiting on it now [14:25] it's blocking him to do changes [14:25] i'm in meetings [14:25] *shrug* [14:25] if you don't do it properly please don't change desktop packages and ask for sponsoring next time [14:26] we will fix this one now [14:26] i'm on it [14:26] ok thanks [14:26] cjwatson: Cool, will do. [14:28] DktrKranz: Hey! kupfer-ping! Is it viable to update c10 in ubu karmic with a spanish translation file (complete). And should I make a c10.1 release or is c10-2 by you to prefer? [14:33] seb128: gtkmm fails as well [14:33] I'm a bit puzzled by that [14:33] the jaunty gtk makes no difference [14:34] see for yourself: http://dl.getdropbox.com/u/169656/testgtkbuilder-0.1.tar.gz [14:35] i've only added pl.po translating "button" to "bla" for testing purposes, but you can copy it over to your locale and update LINGUAS to test [14:35] seb128, pushed [14:35] seb128: ^^ [14:35] ogra: thanks [14:36] there will be improvements for flash in karmic? [14:36] hyperair, ok === mbiebl_ is now known as mbiebl [14:37] seb128, do i need to do the full FFe paperwork for an upstream update to one of f-spot's deps? [14:38] directhex, which one? [14:38] seb128, flickrnet [14:38] directhex, no such source in karmic [14:39] seb128: libflickrnet [14:45] directhex, Laney: synced [14:45] you beaut [14:45] now we need to untransition f-spot [14:46] s/un// [14:46] Laney, what changes are there other than that? can it just be synced too? [14:46] no, there's some patch from lool that we didn't apply in sid [14:46] Laney, like direct sync from debian or do we have other changes? [14:46] ok [14:46] the gnome-screensaver fixes he did I didn't apply [14:47] I though that had been sent to debian too [14:47] I guess next round then [14:47] yeah I thought I'd wait for upstream [14:47] but there's no reason we couldn't apply them in patches/ [14:47] but it's been uploaded to sid anyway so we need to merge [14:49] oh, those changes didn't get uploaded to Karmic... we could just sync if they aren't critical [14:49] seb128: what do you think? [14:50] let's sync and see if it builds? ;-) [14:50] it will build just fine, but lool wanted to avoid the gnome-screensaver build dep [14:50] sync+possible ubuntu1 sounds good to me [14:51] did debian add this one? [14:51] in this case "debian" is Laney [14:51] yeah, and its what is in 0ubuntu1 now [14:51] ok [14:51] directhex, I know but he's not uploader, the sponsor might do changes [14:51] * Laney doesn't know how important avoiding the build dep is [14:52] the build-dep is already in karmic so that will not change a lot [14:52] and it's minor, it's just to make the buildd work easier [14:52] ok then [14:52] Laney: It's ok if it gets dropped in the end :) [14:52] lool: It was applied upstream wasn't it? [14:52] this stuff was merged upstream so just use the new configure flags when the new upstream release supports it [14:53] Yes [14:53] will do then [14:53] thanks [15:03] engla: -2 [15:04] hey. ok [15:09] engla: btw, did you contact upstream asking to integrate it? [15:11] engla: c11 is out, I guess ulrik will release 12 soon, and I'll update it in Debian when that happens. [15:12] DktrKranz: Pardon the missed introduction! ; I'm ulrik [15:12] engla: whoops :) [15:12] I should have said, hi, it's me [15:13] Keybuk: I asked you before about D-Bus. Apparently there is a default timeout value which can be overriden when doing a call - do you happen to know where that is defined? [15:13] * DktrKranz kicks himself for not using /whois [15:14]