=== psharmor is now known as KD0MKB === KD0MKB is now known as psharmor === psharmor is now known as KD0MKB [01:26] desrt, not sure if i'm chasing a red herring here, but what seems to happen in the test which hangs here is: [01:26] 1) Main thread creates a main loop [01:26] 2) Main thread starts another thread [01:26] 3) Main thread runs its main loop [01:27] 4) Second thread runs and then quits the first threads main loop [01:27] but what happens here is the second thread calls g_main_loop_quit on the first threads main loop before the first thread starts running it [01:27] at least that's what i think happens here ;) [01:28] chrisccoulson: so that's unsupported [01:29] you can only call g_main_loop_quit() and expect it to work if you know g_main_loop_run() has already started [01:29] i'm just going to try and verify that by making the second thread sleep for a little while [01:29] chrisccoulson: what test are you looking at? [01:30] uhh [01:30] well isn't that as plain as day [01:30] desrt, http://git.gnome.org/browse/glib/tree/gio/tests/gdbus-threading.c#n229 [01:30] chrisccoulson: you're right. this is a VERY obvious bug [01:30] heh :-) [01:30] i wonder if that's repeated throughout the gdbus tests? :/ [01:30] probably... [01:30] i'll talk to david tomorrow about it [01:30] thanks for the digging :) [01:31] heh, no problem :) [01:31] i wonder why this only seems to be hit with older kernel versions [01:34] yeah, i'm still a bit confused by that [01:34] i'm just going to try a sleep in there just to make sure there's not something else happening [01:37] desrt, ok, a 1 second delay in the second thread fixes it :) [01:38] so that seems fairly conclusive for that particular test [01:38] chrisccoulson: and 1 second delay in the first thread, no doubt, causes it to go to 100% failing [01:38] it was failing 100% before here, but i can try that to make sure it's still 100% failing :) [01:40] glad to know that it's just poorly written tests and not actual bugs :) [01:41] heh [01:46] right, i should probably sleep for a bit now. i'll take a look at some of the other hangs tomorrow just to make sure that they're similar issues :) [01:49] chrisccoulson: funny thing is, i don't think this mainloop needs to exist at all [01:49] chrisccoulson: i'm going to try replacing it with a condition variable [01:50] chrisccoulson: goodnight [01:56] chrisccoulson: if you're still here, i have a patch for you to test [01:59] chrisccoulson: and, indeed, this problem looks quite pervasive. once we clean it up, i suspect we'll see an end to gdbus test hangs :) === KD0MKB is now known as psharmor [05:21] good morning [06:33] Warghafl. "Technology doesn't work for Chris" day is becoming tiresome. [06:36] * micahg wonders if Garfield hates Wednesdays down under === abhinav_ is now known as abhinav- [09:13] morning === vuntz is now known as santonic === santonic is now known as vuntz === mpt_ is now known as mpt [09:25] morning mvo and chr1sccoulson [09:25] hey rodrigo_, how are you? [09:25] glatzor: guten Morgen [09:25] hi pitti [09:26] chr1sccoulson, could you please test aptdaemon trunk, It could have been a race of several simulate calls to the same transaction. this should be fixed in trunk [09:26] morning pitti! [09:26] morning rodrigo_ [09:26] hi glatzor [09:26] rodrigo_, you are still working on installing language packs using the packagekit interface? [09:26] glatzor, yes [09:27] hey glatzor! how is it going? [09:27] mvo, fine! thanks, yourself? [09:28] hi glatzor, will try that in a bit [09:28] thanks! [09:29] rodrigo_, do you already have got any prototype? [09:29] rodrigo_, you want to use InstallResources of the session interface and providing a corresponding WhatProvides type on the system service? [09:29] glatzor, I have an implementation, almost done [09:29] glatzor: good, thanks! [09:30] glatzor, only using WhatProvides [09:30] rodrigo_, the implementation only affects the packagekit daemon, but not the backends right? [09:31] glatzor, the backends also [09:31] rodrigo_, do you have got a public branch? [09:31] glatzor, not yet [09:32] glatzor, will be public soon [09:33] rodrigo_, you have written the implementation for aptcc? [09:33] rodrigo_: btw, do you already have an API to call for giving you the list of packages for a particular language, or just an API that does that by itself? [09:34] glatzor, not yet [09:34] pitti, yes, just WhatProvides("locale", "es") [09:34] rodrigo_: and that returns a list of packages? [09:34] rodrigo_, since I landed the apt backend again, I could assist you. since we also need to get the stuff into aptdaemon [09:35] rodrigo_: that's in PK or aptdaemon? [09:35] ... API [09:35] (I figure it will actually be aptdaemon in either case) [09:35] pitti, yes [09:35] rodrigo_: ok, while logically correct, that didn't answer it for me fully :) [09:36] rodrigo_: is that a new PK API, or an aptdaemon specific API? [09:36] pitti, PK API, implemented in all backends [09:36] ah, nice [09:36] rodrigo_: so in the aptdaemon PK shim that's the place where we could land the replacement for check-language-support? [09:37] pitti, yes [09:37] cool, thanks! [09:37] rodrigo_, how do you get the corresponding packages? [09:37] glatzor, check-lamg-support [09:39] rodrigo_, so do you plan to mote check-lang-support to a separate python module? it is currently part of language-selector, right? [09:40] glatzor: yes, that's my plan [09:40] glatzor: rather, I want to reimplement it [09:40] yes, part of language-selector [09:40] glatzor: I only want to keep /usr/share/language-selector/data/pkg_depends [09:40] glatzor: and reimplemnt the horribly complicated l-s code with a simple script which just parses pkg_depends and gives you the matches [09:41] glatzor: in an aptdaemon environment, where you (presumaby) have a current apt Cache object already this should be really fast [09:41] but for now we could just call the script, of course [09:41] unfortunately I don't have time to work on this in December, have my hands full with the stable+1 stuff [09:41] I can resume this in Jan [09:41] pitti, I'll try to do it [09:41] * pitti is fixing upgarde bugs like mad [09:44] pitti, I could also have a look at it [09:45] glatzor: if you want, that'd be great [09:45] glatzor: having this in aptdaemon will probably also make it easy to install missing langpacks if you install an additional application [09:45] glatzor: like you install a KDE app on GNOME, it should pull in language-pack-kde-XX [09:45] it's the same logic and pkg_depends data [09:47] pitti, I would set a new project python-languagesupport that could be reused by packagekit apt backend and aptdaemon [09:47] set up [09:47] glatzor: that, or we re-use language-selector [09:48] pitti, the guy of language selector should go away? [09:48] glatzor: I guess the API could allow passing an apt.Cache object which it uses if not None [09:48] gui [09:48] also fine [09:48] glatzor: for efficiency [09:48] glatzor: yes, the GNOME one anyway; Kubuntu might still want to keep it [09:48] glatzor, but apt pk backend is in C, not sure it can call a python module [09:49] rodrigo_, the aptcc backend is writtin c++. but I revived the apt backend some weeks ago [09:49] glatzor, ah ok [09:49] hey [09:50] rodrigo_, this allows to push changes (e.g. new roles) to packagekit and also providing an implementation in a backend [09:50] sorry I'm late(r that usual) today ;-) [09:50] morning seb128 [09:50] hi seb128 [09:50] hey glatzor, rodrigo_ [09:50] how are you? [09:51] hi seb128 [09:51] hey chrisccoulson, how are you? [09:51] did you sleep this night? ;-) [09:51] seb128, yeah, good thanks. a bit tired [09:52] late night last night ;) [09:52] got to the bottom of your glib hangs though! [09:52] hehe [09:52] oh? [09:52] did you talk about it with desrt or other upstreams? what is it?! [09:52] seb128, did you see desrt's comments on the bug report? [09:52] no, going through my mails now, looking [09:52] the tests are racy by design ;) [09:53] so it's not our kernel? [09:53] it doesn't look like it [10:02] chrisccoulson, did you try his patch? [10:05] seb128, not yet, but it will fix it for that specific test. we proved quite conclusively that the second thread runs to completion before the first thread runs its main loop :) [10:06] but it seems there are buggy cases in other tests too [10:06] chrisccoulson, yeah, and there are only 2 buggy tests [10:06] well we ever had hangs in only 2 tests [10:06] so it's half the job done :p [10:07] pitti, hey [10:08] hey seb128 [10:08] pitti, how are you? [10:08] seb128: cursing at upgrades :) [10:08] pitti, how much did I break the world with the new gtk2,3 and glib? [10:08] seb128: not at all so far, if you don't count the massive armel buildd lag and thus having uninstallable armel desktops for half a day :) (not your fault) [10:08] pitti, ok, good ;-) [10:09] well, I haven't restarted my session after this morning's dist-upgrade [10:09] (*nnng* hours of dist-upgrades in kvm running) [10:09] ok, well runtime should be fine [10:09] pitti, do you get bug #408903 on your laptop? [10:09] Launchpad bug 408903 in linux "Thinkpad T400s, T410s, T410, T510 & W510 microphone mute button does not work" [Low,Confirmed] https://launchpad.net/bugs/408903 [10:10] pitti, recent comment suggest the x220 get the bug as well [10:10] pitti, do you think that's something worth targetting for this cycle? [10:11] seb128: hm, I don't know; I wasn't aware that I had a mic mute button [10:11] pitti, don't bother, I noticed because he got a few "I get that bug too" comments today but reading the backlog it's really a side feature and even windows doesn't support it without a special driver [10:11] so seems like rather a feature request than an easy bug fix [10:11] closing the tab ;-) [10:11] seb128: I'm happy to have a look at the bug, if we can easily fix it in the udev keymaps [10:12] but wouldn't spend too much time on it [10:12] pitti, see comment #30 [10:12] pitti, they suggest a small udev "script" [10:12] but that seems rather an hack that a proper fix [10:12] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=6e3b1694a4dea049591af1f089adce327bf6a542 [10:12] right, it's a hack [10:13] #define KEY_MICMUTE 248 /* Mute / unmute the microphone */ [10:13] but this exists now [10:13] so we should update udev to actually use it [10:13] that was added only fairly recently, though (linux 3.0) [10:13] right, time to debug the next glib test hang :) [10:13] chrisccoulson, bug #904114 is yours! [10:13] Launchpad bug 904114 in gnome-control-center "Facebook game "Heroes of Neverwinter" crash" [Undecided,New] https://launchpad.net/bugs/904114 [10:13] seb128: bug assigned to me, thanks for pointing out [10:13] chrisccoulson, why do people keep assigning your bugs to GNOME :p [10:13] pitti, thanks! [10:14] seb128, it's ok. it's a flash plugin crash, which means i'll just close it anyway :) [10:16] chrisccoulson, well I reassigned to firefox so feel free to do it ;-) [10:23] lol [10:24] users... one complain that he added '000C' chars in a source file to make the printer jump pages and that gedit render them as a square with the hex code and print that square rather than jumping pages as it should [10:24] oh, gedit isn't feeding in a new screen page? [10:24] we should so totally fix that [10:24] quick, teach gedit about pages! [10:25] ;-) [10:26] pitti, well it's also not sending it the printer but printing the hex code square glyph on the page, which is what the guy complain about (he said it's ok for screen rendering to not respect the page jump, how nice of him) ;-) [10:26] YAFIYGI *shrug* [10:40] Hey pitti! Care to sponsor a colord upload to Debian? :) [10:41] RAOF: sure! toss me the .dsc? [10:41] RAOF, hey [10:41] You can grab it from alioth git if you like, or I can find somewhere to stash the .dsc. [10:41] seb128: Hey, ho! [10:41] RAOF, how are you? thanks for doing the update ;-) [10:42] RAOF: git sounds fine [10:42] seb128: I'm a bit frustrated; today has been plagued with crazily broken computers. Laptops which no longer POST, laptops which boot fine until I try and connect them to the network, laptops which hard lock every hour or so… [10:43] urg [10:43] seb128, https://hg.mozilla.org/mozilla-central/rev/596e3eca4196 [10:43] that fixes the thunderbird cursor bug :) [10:44] pitti: http://anonscm.debian.org/git/collab-maint/colord.git/ - you'll need to uscan down the tarball, because pristine-tar doesn't handle xz. [10:44] chrisccoulson, \o/ (that seems hackish) [10:44] seb128, it's no worse than how it worked before ;) [10:44] chrisccoulson, the mozilla products code scares me in many ways :p [10:44] (ie, xcursor mapping a hash of mozilla's bitmap to an animated cursor) [10:45] seb128: No problem on the colord update; it's something that I should have done anyway. :) [10:45] seb128, it wasn't mozilla who decided to do it like that. they just created a bitmap cursor because X didn't have a standard cursor for what they wanted [10:45] then someone decided it would be a good idea to map the bitmap to a themed pointer ;) [10:47] RAOF: uh, no pristine-tar branch in there? [10:47] RAOF: how do you build it? [10:47] pitti: uscan --download-current-version? [10:47] RAOF: I only see "master", "ubuntu", and "upstream" branches [10:48] chrisccoulson, I see ;-) [10:48] RAOF: ah, you don't use git-buildpackage? [10:48] RAOF: ok [10:48] pitti: pristine-tar still doesn't understand xz, so I can't have a pristine-tar branch. [10:48] chrisccoulson, so it's going to be fixed in tb 10 or will you backport that before? [10:48] RAOF: err, what? we use that for upower and friends [10:48] Unless pristine-tar has suddenly grown the ability to import .tar.xz. [10:48] Oh, it *has* grown the ability to import .tar.xz? [10:48] well, not "suddenly", but it wasn't too long ago indeed [10:48] * RAOF adds a pristine-tar branch to colord. [10:49] seb128, we'll backport it [10:49] seb128, http://vektor-sigma.livejournal.com/1137.html [10:49] there's the history of it btw ;) [10:49] \o/ [10:49] pristine-tar: successfully generated /home/martin/debian/pkg-utopia/build-area/upower_0.9.14.orig.tar.xz [10:49] RAOF: ^ [10:49] I thought it always supported it, but without doing any pristine-tar magic [10:49] i.e. look at the size of the .delta [10:49] Last time I tried it threw up its hands and exploded. [10:49] Laney: ah, heh [10:50] Laney: so yes, cheating, but at least the tools work :) [10:50] indeed [10:52] pitti: Have a pristine-tar branch. [10:53] RAOF: ah, did it the old uscan/debuild -S way now, but thanks! good for next time [10:53] one thing that git-buildpackage could really learn from bzr-builddeb is "bd-do" [10:54] isn't that a merge mode thing? [10:54] yes [10:54] but incredibly handy for doing Debian uploads [10:54] Really? I only ever use that with non-full-source branches, and all my git branches are full source. [10:54] not seen git-buildpackage used in merge mode [10:54] bzr bd-do, then dchroot, dpkg-buildpackage [10:54] anyway, not a biggie [10:54] I just don't have all the git/bzr stuff in my unstable dchroot [10:55] RAOF: tl;dr: uploaded [10:55] I have export-dir in my ~/.gbp.conf and then git-buildpackage -S; cd ../build-area; sbuild -d unstable ... [10:55] right [10:56] you can run into occasional differences when building the source package though, indeed (I suppose that's your point) [10:57] RAOF: btw, you should move the gir to Section: introspection [11:02] pitti: Certainly; queued for next upload. [11:08] seb128: in fact, for the micmute thing, we already have the keymap in precise [11:08] so I closed the udev task [11:09] pitti, ok, so it's already fixed? [11:09] seb128: well, at least the keymap; no idea whether gnome-settings-daemon actually reacts to KEY_MICMUTE [11:09] (and whether X.org translates KEY_MICMUTE into an XF86_somethinglikemicmute event [11:11] RAOF: hah, what the override disparity says :) [11:41] seb128, hey, hmm, when i am trying to do merge proposals they arent picked up ;) [11:42] ricotz, where? [11:42] the missing dependency for glib [11:43] this got fixed, but without the proper version [11:43] ricotz, yeah, I forgot about it in the glib upload screwups I did [11:44] i.e uploaded to the archive instead of the ppa, the tests hangs, etc [11:44] ricotz, I did think about it after getting to bed and seems like infinity fixed it during the night his way [11:44] ricotz, sorry about that [11:45] seb128, alright, but still it should be libpcre3-dev (>= 8.11) [11:46] I wonder why version doesn't pick your merge request btw [11:47] ricotz, ok, I will fix that with the next upload [11:50] seb128, ok === MacSlow is now known as MacSlow|lunch [12:16] seb128, you're supposed to have global menus in Unity 2d, right? [12:20] hello everyone! [12:21] rickspencer3, yes [12:21] hey nessita, how are you? [12:21] thanks seb128 [12:21] hola nessita [12:21] seb128: pretty good, you? [12:21] hola rickspencer3 :-) [12:21] nessita, I'm good thanks ;-) [12:25] sponsoring question: if a given person started a package sponsorship and requested some fixes, once I pushed those, shall I wait for that same person to review them again, or could I ask to the patch pilot of the day to re-review? [12:28] nessita: I would ask the person if he wants to re-review again (I doubt many reviewers subscribe to branches they review to get notified of updates) [12:29] nessita, doesn't hurt to ping again the first sponsor but it doesn't hurt to ping the patch pilot of the day either [12:30] nessita, I personally tend to comment on quite some stuff when I'm piloting but often don't subscribe or follow up later [12:30] seb128, geser: nice, thanks :-) [12:30] nessita, what do you need sponsored? [12:31] seb128: https://code.launchpad.net/~nataliabidart/ubuntu/precise/magicicada/magicicada-0.4.1/+merge/84558 I specially was interested in something that the first sponsor mentioned, regarding the debian/compat version. I used 7 because the doc said so, but apparently is not the latest [12:32] nessita, that guide is outdated, micahg is right on the review, man debhelper and look for compat [12:33] nessita, that's the canonical reference [12:33] nessita, current "stable" is 8 and there is a devel 9 [12:33] seb128: ok, so should I migrate to 8 then, right? [12:33] nessita, yes [12:34] seb128: ok, I will change that and push [12:37] is it safe to dist-upgrade to precise now? [12:37] micahg, btw kov (debian webkit maintainer and part of upstream) say they don't plan to drop gtk2 support yet [12:37] (lready did it on my laptop, but want to do it on my desktop now) [12:37] rodrigo_, should be yes [12:38] seb128, ok, thanks [12:38] yw [12:38] seb128: what did you mean by the canonical reference? the packaging guide (http://developer.ubuntu.com/packaging/html/debian-dir-overview.html), under Aditional Resources, is pointing to look the http://www.debian.org/doc/maint-guide/dother.en.html for further info, so I'm a little confused [12:39] nessita, well, those are packaging guide, not developer references documentation [12:39] nessita, they get outdated, nobody promise that the guide is always covering the most recent revision of the specs [12:40] seb128: right, I understand. So, what is the canonical reference you mentioned? I'd love to read that [12:40] nessita, debhelper is where the compat level are implemented [12:40] nessita, "man debhelper" [12:41] seb128, i havent looked into it, but what is up with the conflict of libgail-common with libgnome2-0? [12:41] nessita, see COMPATABILITY LEVELS there [12:41] seb128: ah, so by "canonical reference" you meant the man pages ;-) (I did not got that part) [12:41] nessita, yeah sorry [12:42] ricotz, it's coming from Debian to ensure libgnome is upgraded to a multiarch version [12:44] ok, i see [12:44] ricotz, so I guess somebody should merge libgnome on Debian [12:44] ricotz, is that creating any issue? [12:44] do we still have anything standard using libgnome? [12:45] seb128, the libgnome2 mono bindings using it [12:45] well I didn't notice there but tomboy doesn't depend on that [12:45] so maybe banshee is suffering [12:45] ricotz, do you want to merge libgnome? ;-) I can sponsor it! [12:46] seb128, hmm, system setting has two ways to start it here in my brandnew precise install ... one from the little gear menu on the top right, the other from the launcher ... if i start it from the launcher there seems to be a huge gap between the single rows (like 400px white space between each row) while when starting from the menu it looks fine [12:46] ogra_, no, the spacing is buggy and random between launches [12:46] any idea why that is ? [12:46] seb128, i guess the goal would be to get in sync here [12:46] ah [12:46] ogra_, nothing to do with the location, it's a bug with the new gtk, will be fixed in the next version [12:46] funny, seems to be reliable here [12:47] seb128, i will take a look [12:47] ricotz, we probably can't since it has some gconf keys for default applications (though that's being deprecated) [12:48] ogra_, well for me it doesn't depend of the location, using the session menu I got the lot of spacing 3 times and that a compacted grid with the titles screwed on the next try [12:49] ogra_, well anyway that is fixed with the daily gtk build, I just didn't manage to figure which one of the 150 commits fixed it and I didn't want to spend time on that [12:49] ogra_, so it will be buggy until the next update [12:49] it's only cosmetic the search works and you can scroll down after the white space [12:49] it is proper (with some grabage between the lines) when i use it from the menu ... and its reliable broken from the launcher [12:49] though the system i use has very slow IO (arm) [12:50] so the different time it takes to start might have some influence [12:50] ogra_, could be racy, anyway what I said, it's not important enough that I want to figure what commit to backport rather than to wait for the next tarball (due next week) [12:50] but if its known i'll just wait and not add another bug :) [12:50] ricotz, thanks === MacSlow|lunch is now known as MacSlow [13:06] hmm, but thatz doesnt solve my initial issue actually [13:06] hi pitti, I set up the schedule for language pack exports and builds yesterday, as per https://dev.launchpad.net/Translations/LanguagePackSchedule - would you mind double-checking the cron tab for the builds to make sure everything is ok? [13:06] where the heck do i configure font sizes etc ... its not in appearance anymore [13:07] ogra_, in the a11y panel [13:07] using the zoom [13:07] oh my [13:07] how intuitive :P [13:08] yeah... [13:08] erm ... [13:08] well not the zoom but you have a text combo [13:08] right big small and normal [13:08] not what i was after [13:09] yeah, no other choice in GNOME3 [13:09] oh my [13:09] you can always use gnome-tweak-tools or ubuntu-tweaks [13:12] or dconf-editor i guess [13:12] dpm: thanks, it looks fine (already ponged this morning) [13:13] pitti, ah, cool, I hadn't seen the reply, sorry [13:16] * rodrigo_ lunch [13:28] hum [13:28] bug #904239 is weird [13:28] Launchpad bug 904239 in nautilus "nautilos can not open. Could not register the application: Method `DescribeAll' returned type `(a(savbav))', but expected `(a{s(bgav)})'" [Undecided,Confirmed] https://launchpad.net/bugs/904239 [13:28] did anyone see a similar issue? I wonder what could lead to that [13:30] * Sweetshark just loves how his box aways need 2-4 boot attempts to get a desktop because of this degraded RAID mess. [13:31] urg [13:31] Sweetshark, btw I assigned you a libreoffice bug ;-) [13:32] seb128: keep in line behind the rest of the >700 open bugs ;) [13:32] Sweetshark, well that one is adding 2 mimetypes to the libreoffice-impress.desktop, should be trivial [13:32] i.e it's a one liner [13:32] seb128: k [13:32] Sweetshark, the desktop doesn't claim supporting the slideshow types [13:33] Sweetshark, bug #904212 [13:33] Launchpad bug 904212 in libreoffice "File-roller is associated with .ppsx files instead of LibreOffice Impress" [Low,Confirmed] https://launchpad.net/bugs/904212 [13:33] Sweetshark, I've added the details in a comment [13:35] seb128: yes, looks simple enough. I am usually rather reluctant with having assigned bugs that I have not started on yet, but this one qualifies ;) [13:35] Sweetshark, thanks ;-) [13:44] seb128, http://people.ubuntu.com/~ricotz/libgnome/ , but i guess you like a branch more === om26er_ is now known as om26er [13:45] ricotz, vcs is better but I can deal with a source if required ;-) [13:46] take the source ;) [13:46] is there an autoimport? [13:47] ricotz, ok, I will use the source [13:47] i mean on launchpad for source uploads which arent in a branch yet [13:47] ricotz, well we use debian dir only ~ubuntu-desktop/libgnome/ubuntu [13:47] one sec [13:47] oh, my, the gdbus/codegen-peer-to-peer test hang is another really obvious threading bug [13:48] desrt ^^ [13:48] will comment on the bug ;) [13:48] seb128, i will push one [13:48] ricotz, thanks [13:48] ricotz, btw desrt and chrisccoulson debugged,are debugging the gdbus test hangs [13:48] ricotz, they are not kernel bugs but bugs in the test ;-) [13:48] chrisccoulson, way to go! ;-) [13:49] seb128, oh, interesting [13:49] ricotz, I got the is people to get a stacktrace and debug output from a stucked build yesterday and opened a bug, desrt and chrisccoulson picked from there ;-) [13:50] nice! [13:50] chrisccoulson, btw did you manage to get the hang in your karmic vm environment at the end? [13:50] seb128, i'm using a hardy vm and a precise pbuilder [13:50] it seems to be working quite well for debugging these issues :) [13:50] lol [13:51] seb128, lp:~ricotz/libgnome/ubuntu [13:51] s/pbuilder/chroot/ [13:51] ricotz, thanks [13:52] seb128, but this is probably the more intersting diff http://people.ubuntu.com/~ricotz/libgnome/libgnome-debian.debdiff [13:53] seb128, https://bugzilla.gnome.org/show_bug.cgi?id=666129#c9 [13:53] ricotz, thanks, look good, I will change banshee to rhythmbox since that's we use [13:53] Gnome bug 666129 in build "the testsuit is hanging in gdbus tests" [Normal,New] [13:53] that's a really silly bug ;) [13:53] lol [13:53] indeed [13:54] 1 more to go now :) [13:54] it took quite a while to actually reproduce this one today for some reason. not sure what changed since yesterday ;) [13:55] wow [13:55] the sound-settings window is like 4000px high here [13:56] (which is a bit unfortunate on a 1024x600 screen) [13:56] right, the new gtk screen the geometry calculation in the control center in some way [13:56]