[01:26] <chrisccoulson> 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] <chrisccoulson> 1) Main thread creates a main loop
[01:26] <chrisccoulson> 2) Main thread starts another thread
[01:26] <chrisccoulson> 3) Main thread runs its main loop
[01:27] <chrisccoulson> 4) Second thread runs and then quits the first threads main loop
[01:27] <chrisccoulson> 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] <chrisccoulson> at least that's what i think happens here ;)
[01:28] <desrt> chrisccoulson: so that's unsupported
[01:29] <desrt> 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] <chrisccoulson> i'm just going to try and verify that by making the second thread sleep for a little while
[01:29] <desrt> chrisccoulson: what test are you looking at?
[01:30] <desrt> uhh
[01:30] <desrt> well isn't that as plain as day
[01:30] <chrisccoulson> desrt, http://git.gnome.org/browse/glib/tree/gio/tests/gdbus-threading.c#n229
[01:30] <desrt> chrisccoulson: you're right.  this is a VERY obvious bug
[01:30] <chrisccoulson> heh :-)
[01:30] <chrisccoulson> i wonder if that's repeated throughout the gdbus tests? :/
[01:30] <desrt> probably...
[01:30] <desrt> i'll talk to david tomorrow about it
[01:30] <desrt> thanks for the digging :)
[01:31] <chrisccoulson> heh, no problem :)
[01:31] <desrt> i wonder why this only seems to be hit with older kernel versions
[01:34] <chrisccoulson> yeah, i'm still a bit confused by that
[01:34] <chrisccoulson> i'm just going to try a sleep in there just to make sure there's not something else happening
[01:37] <chrisccoulson> desrt, ok, a 1 second delay in the second thread fixes it :)
[01:38] <chrisccoulson> so that seems fairly conclusive for that particular test
[01:38] <desrt> chrisccoulson: and 1 second delay in the first thread, no doubt, causes it to go to 100% failing
[01:38] <chrisccoulson> it was failing 100% before here, but i can try that to make sure it's still 100% failing :)
[01:40] <desrt> glad to know that it's just poorly written tests and not actual bugs :)
[01:41] <chrisccoulson> heh
[01:46] <chrisccoulson> 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] <desrt> chrisccoulson: funny thing is, i don't think this mainloop needs to exist at all
[01:49] <desrt> chrisccoulson: i'm going to try replacing it with a condition variable
[01:50] <desrt> chrisccoulson: goodnight
[01:56] <desrt> chrisccoulson: if you're still here, i have a patch for you to test
[01:59] <desrt> chrisccoulson: and, indeed, this problem looks quite pervasive.  once we clean it up, i suspect we'll see an end to gdbus test hangs :)
[05:21] <pitti> good morning
[06:33] <RAOF> Warghafl.  "Technology doesn't work for Chris" day is becoming tiresome.
[06:36]  * micahg wonders if Garfield hates Wednesdays down under
[09:13] <rodrigo_> morning
[09:25] <glatzor> morning mvo and chr1sccoulson
[09:25] <pitti> hey rodrigo_, how are you?
[09:25] <pitti> glatzor: guten Morgen
[09:25] <rodrigo_> hi pitti
[09:26] <glatzor> 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] <glatzor> morning pitti!
[09:26] <glatzor> morning rodrigo_
[09:26] <rodrigo_> hi glatzor
[09:26] <glatzor> rodrigo_, you are still working on installing language packs using the packagekit interface?
[09:26] <rodrigo_> glatzor, yes
[09:27] <mvo> hey glatzor! how is it going?
[09:27] <glatzor> mvo, fine! thanks, yourself?
[09:28] <chrisccoulson> hi glatzor, will try that in a bit
[09:28] <chrisccoulson> thanks!
[09:29] <glatzor> rodrigo_, do you already have got any prototype?
[09:29] <glatzor> rodrigo_, you want to use InstallResources of the session interface and providing a corresponding WhatProvides type on the system service?
[09:29] <rodrigo_> glatzor, I have an implementation, almost done
[09:29] <mvo> glatzor: good, thanks!
[09:30] <rodrigo_> glatzor, only using WhatProvides
[09:30] <glatzor> rodrigo_, the implementation only affects the packagekit daemon, but not the backends right?
[09:31] <rodrigo_> glatzor, the backends also
[09:31] <glatzor> rodrigo_, do you have got a public branch?
[09:31] <rodrigo_> glatzor, not yet
[09:32] <rodrigo_> glatzor, will be public soon
[09:33] <glatzor> rodrigo_, you have written the implementation for aptcc?
[09:33] <pitti> 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] <rodrigo_> glatzor, not yet
[09:34] <rodrigo_> pitti, yes, just WhatProvides("locale", "es")
[09:34] <pitti> rodrigo_: and that returns a list of packages?
[09:34] <glatzor> rodrigo_, since I landed the apt backend again, I could assist you. since we also need to get the stuff into aptdaemon
[09:35] <pitti> rodrigo_: that's in PK or aptdaemon?
[09:35] <pitti> ... API
[09:35] <pitti> (I figure it will actually be aptdaemon in either case)
[09:35] <rodrigo_> pitti, yes
[09:35] <pitti> rodrigo_: ok, while logically correct, that didn't answer it for me fully :)
[09:36] <pitti> rodrigo_: is that a new PK API, or an aptdaemon specific API?
[09:36] <rodrigo_> pitti, PK API, implemented in all backends
[09:36] <pitti> ah, nice
[09:36] <pitti> rodrigo_: so in the aptdaemon PK shim that's the place where we could land the replacement for check-language-support?
[09:37] <rodrigo_> pitti, yes
[09:37] <pitti> cool, thanks!
[09:37] <glatzor> rodrigo_, how do you get the corresponding packages?
[09:37] <rodrigo_> glatzor, check-lamg-support
[09:39] <glatzor> 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] <pitti> glatzor: yes, that's my plan
[09:40] <pitti> glatzor: rather, I want to reimplement it
[09:40] <rodrigo_> yes, part of language-selector
[09:40] <pitti> glatzor: I only want to keep /usr/share/language-selector/data/pkg_depends
[09:40] <pitti> 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] <pitti> glatzor: in an aptdaemon environment, where you (presumaby) have a current apt Cache object already this should be really fast
[09:41] <pitti> but for now we could just call the script, of course
[09:41] <pitti> unfortunately I don't have time to work on this in December, have my hands full with the stable+1 stuff
[09:41] <pitti> I can resume this in Jan
[09:41] <rodrigo_> pitti, I'll try to do it
[09:41]  * pitti is fixing upgarde bugs like mad
[09:44] <glatzor> pitti, I could also have a look at it
[09:45] <pitti> glatzor: if you want, that'd be great
[09:45] <pitti> glatzor: having this in aptdaemon will probably also make it easy to install missing langpacks if you install an additional application
[09:45] <pitti> glatzor: like you install a KDE app on GNOME, it should pull in language-pack-kde-XX
[09:45] <pitti> it's the same logic and pkg_depends data
[09:47] <glatzor> pitti, I would set a new project python-languagesupport that could be reused by packagekit apt backend and aptdaemon
[09:47] <glatzor> set up
[09:47] <pitti> glatzor: that, or we re-use language-selector
[09:48] <glatzor> pitti, the guy of language selector should go away?
[09:48] <pitti> glatzor: I guess the API could allow passing an apt.Cache object which it uses if not None
[09:48] <glatzor> gui
[09:48] <glatzor> also fine
[09:48] <pitti> glatzor: for efficiency
[09:48] <pitti> glatzor: yes, the GNOME one anyway; Kubuntu might still want to keep it
[09:48] <rodrigo_> glatzor, but apt pk backend is in C, not sure it can call a python module
[09:49] <glatzor> rodrigo_, the aptcc backend is writtin c++. but I revived the apt backend some weeks ago
[09:49] <rodrigo_> glatzor, ah ok
[09:49] <seb128> hey
[09:50] <glatzor> rodrigo_, this allows to push changes (e.g. new roles) to packagekit and also providing an implementation in a backend
[09:50] <seb128> sorry I'm late(r that usual) today ;-)
[09:50] <glatzor> morning seb128
[09:50] <rodrigo_> hi seb128
[09:50] <seb128> hey glatzor, rodrigo_
[09:50] <seb128> how are you?
[09:51] <chrisccoulson> hi seb128
[09:51] <seb128> hey chrisccoulson, how are you?
[09:51] <seb128> did you sleep this night? ;-)
[09:51] <chrisccoulson> seb128, yeah, good thanks. a bit tired
[09:52] <chrisccoulson> late night last night ;)
[09:52] <chrisccoulson> got to the bottom of your glib hangs though!
[09:52] <seb128> hehe
[09:52] <seb128> oh?
[09:52] <seb128> did you talk about it with desrt or other upstreams? what is it?!
[09:52] <chrisccoulson> seb128, did you see desrt's comments on the bug report?
[09:52] <seb128> no, going through my mails now, looking
[09:52] <chrisccoulson> the tests are racy by design ;)
[09:53] <seb128> so it's not our kernel?
[09:53] <chrisccoulson> it doesn't look like it
[10:02] <seb128> chrisccoulson, did you try his patch?
[10:05] <chrisccoulson> 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] <chrisccoulson> but it seems there are buggy cases in other tests too
[10:06] <seb128> chrisccoulson, yeah, and there are only 2 buggy tests
[10:06] <seb128> well we ever had hangs in only 2 tests
[10:06] <seb128> so it's half the job done :p
[10:07] <seb128> pitti, hey
[10:08] <pitti> hey seb128
[10:08] <seb128> pitti, how are you?
[10:08] <pitti> seb128: cursing at upgrades :)
[10:08] <seb128> pitti, how much did I break the world with the new gtk2,3 and glib?
[10:08] <pitti> 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] <seb128> pitti, ok, good ;-)
[10:09] <pitti> well, I haven't restarted my session after this morning's dist-upgrade
[10:09] <pitti> (*nnng* hours of dist-upgrades in kvm running)
[10:09] <seb128> ok, well runtime should be fine
[10:09] <seb128> pitti, do you get bug #408903 on your laptop?
[10:09] <ubot2> 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] <seb128> pitti, recent comment suggest the x220 get the bug as well
[10:10] <seb128> pitti, do you think that's something worth targetting for this cycle?
[10:11] <pitti> seb128: hm, I don't know; I wasn't aware that I had a mic mute button
[10:11] <seb128> 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] <seb128> so seems like rather a feature request than an easy bug fix
[10:11] <seb128> closing the tab ;-)
[10:11] <pitti> seb128: I'm happy to have a look at the bug, if we can easily fix it in the udev keymaps
[10:12] <pitti> but wouldn't spend too much time on it
[10:12] <seb128> pitti, see comment #30
[10:12] <seb128> pitti, they suggest a small udev "script"
[10:12] <seb128> but that seems rather an hack that a proper fix
[10:12] <pitti> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=6e3b1694a4dea049591af1f089adce327bf6a542
[10:12] <pitti> right, it's a hack
[10:13] <pitti> #define KEY_MICMUTE             248     /* Mute / unmute the microphone */
[10:13] <pitti> but this exists now
[10:13] <pitti> so we should update udev to actually use it
[10:13] <pitti> that was added only fairly recently, though (linux 3.0)
[10:13] <chrisccoulson> right, time to debug the next glib test hang :)
[10:13] <seb128> chrisccoulson, bug #904114 is yours!
[10:13] <ubot2> Launchpad bug 904114 in gnome-control-center "Facebook game "Heroes of Neverwinter" crash" [Undecided,New] https://launchpad.net/bugs/904114
[10:13] <pitti> seb128: bug assigned to me, thanks for pointing out
[10:13] <seb128> chrisccoulson, why do people keep assigning your bugs to GNOME :p
[10:13] <seb128> pitti, thanks!
[10:14] <chrisccoulson> seb128, it's ok. it's a flash plugin crash, which means i'll just close it anyway :)
[10:16] <seb128> chrisccoulson, well I reassigned to firefox so feel free to do it ;-)
[10:23] <seb128> lol
[10:24] <seb128> 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] <pitti> oh, gedit isn't feeding in a new screen page?
[10:24] <pitti> we should so totally fix that
[10:24] <pitti> quick, teach gedit about pages!
[10:25] <seb128> ;-)
[10:26] <seb128> 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] <pitti> YAFIYGI *shrug*
[10:40] <RAOF> Hey pitti!  Care to sponsor a colord upload to Debian? :)
[10:41] <pitti> RAOF: sure! toss me the .dsc?
[10:41] <seb128> RAOF, hey
[10:41] <RAOF> You can grab it from alioth git if you like, or I can find somewhere to stash the .dsc.
[10:41] <RAOF> seb128: Hey, ho!
[10:41] <seb128> RAOF, how are you? thanks for doing the update ;-)
[10:42] <pitti> RAOF: git sounds fine
[10:42] <RAOF> 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] <seb128> urg
[10:43] <chrisccoulson> seb128, https://hg.mozilla.org/mozilla-central/rev/596e3eca4196
[10:43] <chrisccoulson> that fixes the thunderbird cursor bug :)
[10:44] <RAOF> 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] <seb128> chrisccoulson, \o/ (that seems hackish)
[10:44] <chrisccoulson> seb128, it's no worse than how it worked before ;)
[10:44] <seb128> chrisccoulson, the mozilla products code scares me in many ways :p
[10:44] <chrisccoulson> (ie, xcursor mapping a hash of mozilla's bitmap to an animated cursor)
[10:45] <RAOF> seb128: No problem on the colord update; it's something that I should have done anyway. :)
[10:45] <chrisccoulson> 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] <chrisccoulson> then someone decided it would be a good idea to map the bitmap to a themed pointer ;)
[10:47] <pitti> RAOF: uh, no pristine-tar branch in there?
[10:47] <pitti> RAOF: how do you build it?
[10:47] <RAOF> pitti: uscan --download-current-version?
[10:47] <pitti> RAOF: I only see "master", "ubuntu", and "upstream" branches
[10:48] <seb128> chrisccoulson, I see ;-)
[10:48] <pitti> RAOF: ah, you don't use git-buildpackage?
[10:48] <pitti> RAOF: ok
[10:48] <RAOF> pitti: pristine-tar still doesn't understand xz, so I can't have a pristine-tar branch.
[10:48] <seb128> chrisccoulson, so it's going to be fixed in tb 10 or will you backport that before?
[10:48] <pitti> RAOF: err, what? we use that for upower and friends
[10:48] <RAOF> Unless pristine-tar has suddenly grown the ability to import .tar.xz.
[10:48] <RAOF> Oh, it *has* grown the ability to import .tar.xz?
[10:48] <pitti> well, not "suddenly", but it wasn't too long ago indeed
[10:48]  * RAOF adds a pristine-tar branch to colord.
[10:49] <chrisccoulson> seb128, we'll backport it
[10:49] <chrisccoulson> seb128, http://vektor-sigma.livejournal.com/1137.html
[10:49] <chrisccoulson> there's the history of it btw ;)
[10:49] <seb128> \o/
[10:49] <pitti> pristine-tar: successfully generated /home/martin/debian/pkg-utopia/build-area/upower_0.9.14.orig.tar.xz
[10:49] <pitti> RAOF: ^
[10:49] <Laney> I thought it always supported it, but without doing any pristine-tar magic
[10:49] <Laney> i.e. look at the size of the .delta
[10:49] <RAOF> Last time I tried it threw up its hands and exploded.
[10:49] <pitti> Laney: ah, heh
[10:50] <pitti> Laney: so yes, cheating, but at least the tools work :)
[10:50] <Laney> indeed
[10:52] <RAOF> pitti: Have a pristine-tar branch.
[10:53] <pitti> RAOF: ah, did it the old uscan/debuild -S way now, but thanks! good for next time
[10:53] <pitti> one thing that git-buildpackage could really learn from bzr-builddeb is "bd-do"
[10:54] <Laney> isn't that a merge mode thing?
[10:54] <pitti> yes
[10:54] <pitti> but incredibly handy for doing Debian uploads
[10:54] <RAOF> Really?  I only ever use that with non-full-source branches, and all my git branches are full source.
[10:54] <Laney> not seen git-buildpackage used in merge mode
[10:54] <pitti> bzr bd-do, then dchroot, dpkg-buildpackage
[10:54] <pitti> anyway, not a biggie
[10:54] <pitti> I just don't have all the git/bzr stuff in my unstable dchroot
[10:55] <pitti> RAOF: tl;dr: uploaded
[10:55] <Laney> I have export-dir in my ~/.gbp.conf and then git-buildpackage -S; cd ../build-area; sbuild -d unstable ...
[10:55] <pitti> right
[10:56] <Laney> you can run into occasional differences when building the source package though, indeed (I suppose that's your point)
[10:57] <pitti> RAOF: btw, you should move the gir to Section: introspection
[11:02] <RAOF> pitti: Certainly; queued for next upload.
[11:08] <pitti> seb128: in fact, for the micmute thing, we already have the keymap in precise
[11:08] <pitti> so I closed the udev task
[11:09] <seb128> pitti, ok, so it's already fixed?
[11:09] <pitti> seb128: well, at least the keymap; no idea whether gnome-settings-daemon actually reacts to KEY_MICMUTE
[11:09] <pitti> (and whether X.org translates KEY_MICMUTE into an XF86_somethinglikemicmute event
[11:11] <pitti> RAOF: hah, what the override disparity says :)
[11:41] <ricotz> seb128, hey, hmm, when i am trying to do merge proposals they arent picked up ;)
[11:42] <seb128> ricotz, where?
[11:42] <ricotz> the missing dependency for glib
[11:43] <ricotz> this got fixed, but without the proper version
[11:43] <seb128> ricotz, yeah, I forgot about it in the glib upload screwups I did
[11:44] <seb128> i.e uploaded to the archive instead of the ppa, the tests hangs, etc
[11:44] <seb128> ricotz, I did think about it after getting to bed and seems like infinity fixed it during the night his way
[11:44] <seb128> ricotz, sorry about that
[11:45] <ricotz> seb128, alright, but still it should be libpcre3-dev (>= 8.11)
[11:46] <seb128> I wonder why version doesn't pick your merge request btw
[11:47] <seb128> ricotz, ok, I will fix that with the next upload
[11:50] <ricotz> seb128, ok
[12:16] <rickspencer3> seb128, you're supposed to have global menus in Unity 2d, right?
[12:20] <nessita> hello everyone!
[12:21] <seb128> rickspencer3, yes
[12:21] <seb128> hey nessita, how are you?
[12:21] <rickspencer3> thanks seb128
[12:21] <rickspencer3> hola nessita
[12:21] <nessita> seb128: pretty good, you?
[12:21] <nessita> hola rickspencer3 :-)
[12:21] <seb128> nessita, I'm good thanks ;-)
[12:25] <nessita> 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] <geser> 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] <seb128> 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] <seb128> 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] <nessita> seb128, geser: nice, thanks :-)
[12:30] <seb128> nessita, what do you need sponsored?
[12:31] <nessita> 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] <seb128> nessita, that guide is outdated, micahg is right on the review, man debhelper and look for compat
[12:33] <seb128> nessita, that's the canonical reference
[12:33] <seb128> nessita, current "stable" is 8 and there is a devel 9
[12:33] <nessita> seb128: ok, so should I migrate to 8 then, right?
[12:33] <seb128> nessita, yes
[12:34] <nessita> seb128: ok, I will change that and push
[12:37] <rodrigo_> is it safe to dist-upgrade to precise now?
[12:37] <seb128> micahg, btw kov (debian webkit maintainer and part of upstream) say they don't plan to drop gtk2 support yet
[12:37] <rodrigo_> (lready did it on my laptop, but want to do it on my desktop now)
[12:37] <seb128> rodrigo_, should be yes
[12:38] <rodrigo_> seb128, ok, thanks
[12:38] <seb128> yw
[12:38] <nessita> 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] <seb128> nessita, well, those are packaging guide, not developer references documentation
[12:39] <seb128> nessita, they get outdated, nobody promise that the guide is always covering the most recent revision of the specs
[12:40] <nessita> seb128: right, I understand. So, what is the canonical reference you mentioned? I'd love to read that
[12:40] <seb128> nessita, debhelper is where the compat level are implemented
[12:40] <seb128> nessita, "man debhelper"
[12:41] <ricotz> seb128, i havent looked into it, but what is up with the conflict of libgail-common with libgnome2-0?
[12:41] <seb128> nessita, see COMPATABILITY LEVELS there
[12:41] <nessita> seb128: ah, so by "canonical reference" you meant the man pages ;-) (I did not got that part)
[12:41] <seb128> nessita, yeah sorry
[12:42] <seb128> ricotz, it's coming from Debian to ensure libgnome is upgraded to a multiarch version
[12:44] <ricotz> ok, i see
[12:44] <seb128> ricotz, so I guess somebody should merge libgnome on Debian
[12:44] <seb128> ricotz, is that creating any issue?
[12:44] <seb128> do we still have anything standard using libgnome?
[12:45] <ricotz> seb128, the libgnome2 mono bindings using it
[12:45] <seb128> well I didn't notice there but tomboy doesn't depend on that
[12:45] <ricotz> so maybe banshee is suffering
[12:45] <seb128> ricotz, do you want to merge libgnome? ;-) I can sponsor it!
[12:46] <ogra_> 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] <seb128> ogra_, no, the spacing is buggy and random between launches
[12:46] <ogra_> any idea why that is ?
[12:46] <ricotz> seb128, i guess the goal would be to get in sync here
[12:46] <ogra_> ah
[12:46] <seb128> ogra_, nothing to do with the location, it's a bug with the new gtk, will be fixed in the next version
[12:46] <ogra_> funny, seems to be reliable here
[12:47] <ricotz> seb128, i will take a look
[12:47] <seb128> ricotz, we probably can't since it has some gconf keys for default applications (though that's being deprecated)
[12:48] <seb128> 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] <seb128> 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] <seb128> ogra_, so it will be buggy until the next update
[12:49] <seb128> it's only cosmetic the search works and you can scroll down after the white space
[12:49] <ogra_> 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] <ogra_> though the system i use has very slow IO (arm)
[12:50] <ogra_> so the different time it takes to start might have some influence
[12:50] <seb128> 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] <ogra_> but if its known i'll just wait and not add another bug :)
[12:50] <seb128> ricotz, thanks
[13:06] <ogra_> hmm, but thatz doesnt solve my initial issue actually
[13:06] <dpm> 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] <ogra_> where the heck do i configure font sizes etc ... its not in appearance anymore
[13:07] <seb128> ogra_, in the a11y panel
[13:07] <seb128> using the zoom
[13:07] <ogra_> oh my
[13:07] <ogra_> how intuitive :P
[13:08] <seb128> yeah...
[13:08] <ogra_> erm ...
[13:08] <seb128> well not the zoom but you have a text combo
[13:08] <ogra_> right big small and normal
[13:08] <ogra_> not what i was after
[13:09] <seb128> yeah, no other choice in GNOME3
[13:09] <ogra_> oh my
[13:09] <seb128> you can always use gnome-tweak-tools or ubuntu-tweaks
[13:12] <ogra_> or dconf-editor i guess
[13:12] <pitti> dpm: thanks, it looks fine (already ponged this morning)
[13:13] <dpm> pitti, ah, cool, I hadn't seen the reply, sorry
[13:16]  * rodrigo_ lunch
[13:28] <seb128> hum
[13:28] <seb128> bug #904239 is weird
[13:28] <ubot2> 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] <seb128> 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] <seb128> urg
[13:31] <seb128> Sweetshark, btw I assigned you a libreoffice bug ;-)
[13:32] <Sweetshark> seb128: keep in line behind the rest of the >700 open bugs ;)
[13:32] <seb128> Sweetshark, well that one is adding 2 mimetypes to the libreoffice-impress.desktop, should be trivial
[13:32] <seb128> i.e it's a one liner
[13:32] <Sweetshark> seb128: k
[13:32] <seb128> Sweetshark, the desktop doesn't claim supporting the slideshow types
[13:33] <seb128> Sweetshark, bug #904212
[13:33] <ubot2> 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] <seb128> Sweetshark, I've added the details in a comment
[13:35] <Sweetshark> 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] <seb128> Sweetshark, thanks ;-)
[13:44] <ricotz> seb128, http://people.ubuntu.com/~ricotz/libgnome/ , but i guess you like a branch more
[13:45] <seb128> ricotz, vcs is better but I can deal with a source if required ;-)
[13:46] <ricotz> take the source ;)
[13:46] <ricotz> is there an autoimport?
[13:47] <seb128> ricotz, ok, I will use the source
[13:47] <ricotz> i mean on launchpad for source uploads which arent in a branch yet
[13:47] <seb128> ricotz, well we use debian dir only ~ubuntu-desktop/libgnome/ubuntu
[13:47] <ricotz> one sec
[13:47] <chrisccoulson> oh, my, the gdbus/codegen-peer-to-peer test hang is another really obvious threading bug
[13:48] <chrisccoulson> desrt ^^
[13:48] <chrisccoulson> will comment on the bug ;)
[13:48] <ricotz> seb128, i will push one
[13:48] <seb128> ricotz, thanks
[13:48] <seb128> ricotz, btw desrt and chrisccoulson debugged,are debugging the gdbus test hangs
[13:48] <seb128> ricotz, they are not kernel bugs but bugs in the test ;-)
[13:48] <seb128> chrisccoulson, way to go! ;-)
[13:49] <ricotz> seb128, oh, interesting
[13:49] <seb128> 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] <ricotz> nice!
[13:50] <seb128> chrisccoulson, btw did you manage to get the hang in your karmic vm environment at the end?
[13:50] <chrisccoulson> seb128, i'm using a hardy vm and a precise pbuilder
[13:50] <chrisccoulson> it seems to be working quite well for debugging these issues :)
[13:50] <seb128> lol
[13:51] <ricotz> seb128, lp:~ricotz/libgnome/ubuntu
[13:51] <chrisccoulson> s/pbuilder/chroot/
[13:51] <seb128> ricotz, thanks
[13:52] <ricotz> seb128, but this is probably the more intersting diff http://people.ubuntu.com/~ricotz/libgnome/libgnome-debian.debdiff
[13:53] <chrisccoulson> seb128, https://bugzilla.gnome.org/show_bug.cgi?id=666129#c9
[13:53] <seb128> ricotz, thanks, look good, I will change banshee to rhythmbox since that's we use
[13:53] <ubot2> Gnome bug 666129 in build "the testsuit is hanging in gdbus tests" [Normal,New]
[13:53] <chrisccoulson> that's a really silly bug ;)
[13:53] <seb128> lol
[13:53] <seb128> indeed
[13:54] <chrisccoulson> 1 more to go now :)
[13:54] <chrisccoulson> it took quite a while to actually reproduce this one today for some reason. not sure what changed since yesterday ;)
[13:55] <ogra_> wow
[13:55] <ogra_> the sound-settings window is like 4000px high here
[13:56] <ogra_> (which is a bit unfortunate on a 1024x600 screen)
[13:56] <seb128> right, the new gtk screen the geometry calculation in the control center in some way
[13:56] <chrisccoulson> yay, no hang now \o/
[13:57] <ogra_> hmm, must be way more than 4000
[13:57] <seb128> chrisccoulson, \o/, maybe you will get a patch reviewed by the GNOME guys and commited ;-)
[13:57] <ogra_> i'm alt+moving it since 5 min now
[13:58] <seb128> ogra_, stop rambling there ;-)
[13:58]  * ogra_ just wants to get to the sound test buttons :/
[13:58] <seb128> try closing it and running it again
[13:58] <ogra_> which i assume are still at the bottom
[13:58] <seb128> it's random
[13:58] <seb128> it's bound to work on another try
[13:58] <ogra_> ha! that worked
[13:59] <seb128> ;-)
[13:59] <ogra_> no sound test at the bottom ?
[13:59] <ogra_> ah, in the hw tab
[14:01] <ricotz> seb128, my wlan disconnected
[14:03] <seb128> ricotz, <seb128> ricotz, thanks, look good, I will change banshee to rhythmbox since that's we use
[14:03] <seb128> I just said that
[14:03] <ricotz> seb128, hmm, i  putting in rhythmbox
[14:04] <seb128> thanks
[14:04] <ricotz> yeah, just noticed that too
[14:04] <ricotz> seb128, ok, so go ahead and change it
[14:07] <seb128> ricotz, ok
[14:08] <ricotz> seb128, what is the number of the nautlis glib bug?
[14:08] <ogra> eryay
[14:08] <ricotz> *nautilus
[14:08] <chrisccoulson> oh, actually, the test we figured out yesterday that desrt has a patch for is the other one which was hanging on the buildd
[14:08] <chrisccoulson> i didn't think it was for some reason
[14:09] <chrisccoulson> which means we've figured out both of them then
[14:09] <chrisccoulson> unless there are any more which have hung in the past?
[14:09] <chrisccoulson> seb128^
[14:09] <ricotz> chr1sccoulson, great
[14:09] <ricotz> chrisccoulson, ^
[14:10] <desrt> chrisccoulson: oh wow
[14:10] <desrt> chrisccoulson: that bug is even more impressively bad than the mainloop one
[14:10] <chrisccoulson> desrt, did you see my comments on the bug?
[14:10] <chrisccoulson> heh :)
[14:10] <desrt> chrisccoulson: but i'm sure it's a bug due to the old kernel!
[14:12] <seb128> chrisccoulson, no, that were only those 2
[14:12] <seb128> desrt, hey
[14:12] <desrt> seb128: hey
[14:12] <seb128> desrt, our kernels are special GNOME haters ones ;-)
[14:12] <chrisccoulson> do our buildd's only have 1 core?
[14:12] <desrt> seb128: after some digging by ccc last night, we find out the cause of all of these deadlocks
[14:13] <seb128> ricotz, what nautilus glib? the signature thing?
[14:13] <desrt> realllllly poorly written code :)
[14:13] <seb128> bug #904239
[14:13] <ubot2> Launchpad bug 904239 in nautilus "nautilus 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
[14:13] <seb128> desrt, yeah, I've read the comments on the bug
[14:13] <seb128> ricotz, I blame it on desrt
[14:13] <seb128> he's turning linux into windows, making you restart after upgrades!
[14:14] <desrt> back in the day, i was invited by a bunch of internet hippies to an event in montreal
[14:14] <ricotz> seb128, ok
[14:14] <desrt> where we talked about how great it would be if we could restart the system and session dbus without logging out
[14:14] <seb128> ;-)
[14:14] <desrt> "we only need to patch all the programs!"
[14:15] <desrt> "it's free software.  we have the source.  we can do it!"
[14:15] <desrt> those were good days :)
[14:15] <seb128> we already patch all the program, add another one is nothing... ;-)
[14:15] <ricotz> seb128, i am seeing some nautilus crashes too, but they are most likely related to cairo-gl and nvidia
[14:15] <desrt> seb128: nah.  you weren't so bad back then :)
[14:15] <seb128> hehe
[14:15] <seb128> ricotz, right, that one is not a segfault
[14:16] <seb128> it's a signature mismatch between the running nautilus using the old glib and the "nautilus" command you run
[14:16] <desrt> seb128: so glib testcases fail on arm
[14:16] <desrt> why did you not hit the same issue?
[14:17] <desrt> seb128: is there some way that i could blame ogra for it?
[14:17] <ogra> desrt, for what ?
[14:18] <desrt> ogra: doing a testbuild of glib on arm and noticing some obvious failures
[14:18] <desrt> wondering why we didn't get reports about them already
[14:18] <ogra> what kinf of failures
[14:18] <ogra> *kind
[14:18] <desrt> unsigned char stuff
[14:18] <ogra> armhf or armel ?
[14:19] <desrt> armel, i'd guess
[14:19] <desrt> imx quickstart board
[14:19] <seb128> desrt, hum? it built across the board: https://launchpad.net/ubuntu/precise/+source/glib2.0/2.31.4.tested-0ubuntu3
[14:19] <ogra> yeah, for that we dont have hf builds unlike for anything else
[14:19] <desrt> ogra: does that impact the signedness of char?
[14:20] <ogra> the general arch impacts it
[14:20] <desrt> right.  arm has unsigned char by default, i guess?
[14:20] <ogra> but better talk to a toolchain guy about that :)
[14:22] <desrt> seb128: do the tests run on the arm builds?
[14:22] <seb128> desrt, well I'm glad that we went to the bottom of the hang issues after months of talking about it ;-)
[14:22] <seb128> desrt, yes, you can look at the build logs
[14:22] <seb128> click on the arch and then on "build log"
[14:23] <desrt> you build docs on ARM?
[14:23] <desrt> you poor bastards....
[14:24] <desrt> seb128: uhm...
[14:24] <desrt> from the log:
[14:24] <desrt>   /value/transform:                                                    **
[14:24] <desrt> ERROR:/build/buildd/glib2.0-2.31.4.tested/./gobject/tests/param.c:206:test_value_transform: assertion failed (g_value_get_char (&dest) == -124): (132 == -124)
[14:24] <desrt> FAIL
[14:24] <desrt> GTester: last random seed: R02Sd52a2da49c459c24ba7af5e200f06463
[14:24] <desrt> /bin/bash: line 1:  9925 Terminated              G_DEBUG=gc-friendly MALLOC_CHECK_=2 MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) ../../glib/gtester --verbose boxed enums param signals threadtests dynamictests binding properties reference ifaceproperties valuearray
[14:24] <desrt> make[5]: *** [test-nonrecursive] Error 143
[14:24] <desrt> this is the same failure that i found...
[14:24] <ogra> i dotn see any glib issue on http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html
[14:24] <ogra> and thats what we work with usually
[14:25] <desrt> each time that test runs, it's failing
[14:25] <desrt> on your builders....
[14:25] <chrisccoulson> we don't fail the build though
[14:25] <desrt> but for some reason it's not enough to stop the build
[14:25] <chrisccoulson> DEB_MAKE_CHECK_TARGET = -k check || true
[14:25] <chrisccoulson> that's why ;)
[14:25] <seb128> doh
[14:26] <ogra> heh
[14:26] <desrt> so we only find out about failures when they stall the entire build, then? :p
[14:26] <chrisccoulson> lol
[14:26] <seb128> desrt, seems so, but I can drop the || true
[14:26] <desrt> (admittedly, that does seem to be the majority case...)
[14:26] <desrt> seb128: cool
[14:26] <desrt> seb128: meanwhile i'll fix this failing test
[14:26] <desrt> it looks to be the only one
[14:26] <desrt> well.. there's another one
[14:27] <desrt> but only because of a hard time limit on the test that my poor slow ARM system doesn't manage to meet
[14:27] <desrt> ogra: you're off the hook.  looks like seb's fault :)
[14:27] <ogra> nah, itz gtk boog
[14:28] <seb128> desrt, the || true has been added at a time where we add some racy tests and the build would fail every second time
[14:28] <desrt> seb128: totally understandable
[14:28] <seb128> but I'm happy to take it out and see how it goes
[14:28] <desrt> particularly in light of the conversation we've been having this past day...
[14:28] <seb128> you will need to deal with stuff like arm being slow enough to timeout though :p
[14:28] <desrt> ya
[14:28] <desrt> i'm removing the one timeout i hit
[14:28] <desrt> or rather, doubling it
[14:28] <seb128> thanks
[14:29] <chrisccoulson> does anybody want to help fix some firefox test failures: http://goo.gl/MgPLf :-)
[14:29] <seb128> chrisccoulson, stop spamming the precise milestoned list!
[14:29] <seb128> ;-)
[14:29] <chrisccoulson> lol
[14:30] <seb128> kenvandine, hey
[14:30] <ogra> wow, firefox flies under armhf
[14:30] <kenvandine> hey seb128
[14:30] <ogra> lots better than on armel
[14:30] <seb128> kenvandine, how are you?
[14:30] <kenvandine> good
[14:31] <seb128> kenvandine, do you have time for your piloting today? (you are on the schedule but dunno how busy you are)
[14:31] <kenvandine> i was about to start :)
[14:31] <seb128> kenvandine, there are some desktopish patches on the sponsoring queue, I was wondering if you will get to them or if I should try to
[14:31] <seb128> kenvandine, ok, good, I will let them for you then
[14:31] <kenvandine> :)
[14:34] <desrt> ogra: so i've heard some bad news about the new transformer...
[14:35] <ogra> which one, the tegra3 one that is to come out soon ?
[14:35] <desrt> ya
[14:35] <chrisccoulson> might try and debug these firefox test hangs now :)
[14:35] <ogra> or the last gen of the tegra2 ones that are locked down in a silly way
[14:35] <desrt> ogra: the 'prime' with the tegra3
[14:35] <ogra> i havent seen a tegra3 one yet, whats so bad about it ?
[14:36] <desrt> they're rumoured to be locked down in all sorts of supercrytographic awful ways
[14:36] <ogra> ah, like the last gen of the tegra2 then
[14:36] <ogra> someone will crack it at some point :)
[14:36] <ogra> talk to lilstevie in #ubuntu-arm, he is the transformer expert
[14:37] <desrt> http://androidroot.mobi/2011/12/13/thoughts-on-android-tablet-security/
[14:38] <chrisccoulson> me gives hardy vm 4GB of memory :)
[15:40] <pitti> mterry_: hey Mike, how are yoU?
[15:40] <mterry_> pitti, good!  what's up?
[15:40] <pitti> mterry_: would you have some time to look into bug 898676 at some point? it's been on c-m for quite some time
[15:40] <ubot2> Launchpad bug 898676 in iw "[MIR] iw" [Undecided,New] https://launchpad.net/bugs/898676
[15:41] <pitti> mterry_sprinting: ah, right, still on the sprint
[15:41] <mterry_sprinting> pitti, I can get to it
[15:44] <dobey> desrt: does gnome-settings-daemon do the gconf->gsettings conversion magic? i thought there was separate script/binary that did that
[15:47] <seb128> dobey, gsettings-data-convert from gconf does it
[15:48] <seb128> it has an etc xdg autostart entry
[15:48] <dobey> seb128: then why would gnome-settings-daemon crash on a setting it doesn't even use?
[15:49] <dobey> and at that point, how do delete a setting that hasn't got a schema?
[15:49] <seb128> dobey, that is a good question, can you get a stacktrace of that g_error?
[15:50] <dobey> seb128: i'm looking at https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client-gnome/+bug/903483
[15:50] <ubot2> Launchpad bug 903483 in ubuntuone-client-gnome/trunk "gnome-settings-daemon crashed with signal 5 in g_object_newv()" [High,In progress]
[15:50] <seb128> dobey, I didn't understand either why the .convert would lead to gsd to segfault
[15:51] <seb128> dobey, talk to rodrigo_
[15:51] <seb128> it seems to be in the gconf->gsettings glue code
[15:52] <seb128> dobey, that code is supposed to write back stuff like the proxy value in gconf as well for legacy applications
[15:52] <rodrigo_> hmm
[15:52] <seb128> not sure why it's reading your .convert
[15:52] <dobey> ah
[15:52] <seb128> or how your non g-s-d key is hitting that code
[15:52] <rodrigo_> the gconf plugin reads the .convert file
[15:52] <rodrigo_> to know what to sync between gconf and gsettings
[15:52] <seb128> rodrigo_, to get the mapping?
[15:52] <seb128> ok, makes sense
[15:52] <dobey> rodrigo_: it syncs *evrything* ?
[15:52] <rodrigo_> yes
[15:52] <rodrigo_> dobey, only stuff that is in .convert files
[15:53] <rodrigo_> and only when the gsettings key's value changes
[15:53] <rodrigo_> so yes, if the schema is not installed, it will crash in g_settings_new
[15:54] <rodrigo_> so the bug is that the .convert file should be installed with the associated schemas
[15:54] <dobey> it is installed
[15:54] <dobey> the bug is that the .convert file was broken
[15:55] <pitti> good night everyone!
[15:55] <dobey> and new glib just aborts
[15:55] <dobey> gutenacht pitti
[15:55] <rodrigo_> dobey, ah, the schema name is wrong in the .convert file, indeed
[15:55] <rodrigo_> org.gnome.nautilus.nautlius.extensions.ubuntuone
[15:56] <dobey> yes; i don't even know how that happened exactly
[15:56] <seb128> 'night pitti
[15:56] <rodrigo_> bye pitti
[15:58] <chrisccoulson> seb128, the gtk+2.0 merge from debian introduced a breaks on libgnome2-0 which makes libgnome uninstallable now :(
[15:59] <chrisccoulson> +    - Add Breaks: libgnome2-0 (<< 2.32.1-2) to libgail-common to ensure
[15:59] <chrisccoulson> +      we have a recent enough version of libgnome2-0 which can read the
[15:59] <chrisccoulson> seb128, want to merge libgnome too, or shall i do that? ;)
[16:00] <chrisccoulson> hah, fantastic. i can't upload libgnome anyway!
[16:05] <seb128> chrisccoulson, ricotz did it, I just need to sponsor it
[16:05] <seb128> will do in a few minutes
[16:05] <chrisccoulson> seb128, oh, cool. thanks
[16:05] <seb128> I didn't notice because I don't have libgnome2-0 installed: p
[16:05] <chrisccoulson> seb128, i only noticed it because it gets installed by the firefox build, and i just realized that it's broken here ;)
[16:23] <seb128> chrisccoulson, ok, I'm on it, I got busy talking to design
[16:23] <ricotz> seb128, are you going to upload libgnome?
[16:24] <seb128> ricotz, yeah, that's what I was just telling to chrisccoulson, I got caught up in a design status update discussion
[16:25] <ricotz> seb128, ok
[16:34] <seb128> ricotz, done
[16:38] <ricotz> seb128, thanks
[16:38] <seb128> ricotz, thank you for doing the merge ;)
[16:39] <ricotz> seb128, btw this gzip bug is getting annoying :\
[16:40] <seb128> ricotz, indeed, did you hit it in a another source?
[16:40] <ricotz> could be remove compression of these ChangeLog files in glib?
[16:40] <seb128> is it buggy there as well?
[16:40] <ricotz> /usr/share/doc/libglib2.0-0/ChangeLog.pre-2-2.gz
[16:40] <ricotz> yes
[16:41] <seb128> :-(
[16:41] <seb128> do you have a bug report? nobody reported it yet
[16:41] <ricotz> seb128, i think there some connected to my ppa
[16:41] <ricotz> which are probably marked won't fix
[16:43] <seb128> hum ok
[16:43] <seb128> not sure we want to hack around in archive sources to accomodate ppas
[16:43] <seb128> it's only an issue for multiarch as well
[16:43] <seb128> not everybody is using multiarch ;)
[16:43] <ricotz> (meaning it happened with the last glib build again)
[16:44] <ricotz> right, you need to really use multiarch to hit it
[16:45] <ricotz> i saw it recently with a qt4 build and there were like 6 files having this problem
[17:13] <micahg> seb128: re webkitgtk + gtk2> that's good news, is that for the whole 1.8.x series?
[17:13] <seb128> micahg, yes
[17:13] <micahg> cool, thanks
[17:24] <chrisccoulson> desrt, are you ok with https://bugzilla.gnome.org/show_bug.cgi?id=666129#c10 ?
[17:24] <ubot2> Gnome bug 666129 in build "the testsuit is hanging in gdbus tests" [Normal,New]
[17:28] <desrt> chrisccoulson: david's code.  he gets final say.
[17:28] <chrisccoulson> ok :)
[17:44] <chrisccoulson> yay, my laptop is cooking :)
[17:44] <chrisccoulson> i'm building firefox in a VM now
[17:45] <seb128> chrisccoulson, because it's not slow enough on real hardware, you better slow it down through emulation? ;-)
[17:45] <chrisccoulson> seb128, test suite hangs ;)
[17:45] <chrisccoulson> you know the drill :)
[17:47]  * desrt gives chrisccoulson Sweetshark's laptop
[17:47] <chrisccoulson> yeah, i could do with something like that
[17:52] <chrisccoulson> hmmm, compiz has turned in to a big mass of glue inside my monitor again
[17:54] <desrt> chrisccoulson: don't worry.  that's how it looks inside of your text editor, as well :)
[17:57] <chrisccoulson> desrt, my text editor just crashed!
[17:57] <chrisccoulson> :(
[18:02] <desrt> chrisccoulson: is that better or worse than turning to stone? :)
[18:09] <chrisccoulson> hmmm, i wonder how hard it would be to parse the firefox build logs and automatically report bugs for test failures?
[18:09] <chrisccoulson> i could even have the script automatically assign those bugs to seb128!
[18:10] <seb128> chrisccoulson, I could poke you with questions on whether those are fixed yet for a full week :p
[18:10] <chrisccoulson> heh :)
[18:10] <chrisccoulson> brb, dinner time
[18:24] <kenvandine> yay... stacking problems!
[18:24] <kenvandine> seb128, i was testing out an onboard update in the sponsor queue... which triggered menus dropping down behind focused windows
[18:24] <kenvandine> haven't seen that bug in quite a while now!
[18:24] <seb128> yeah, me neither
[18:25] <kenvandine> the changelog mentions something about the compiz grid plugin
[18:25] <chrisccoulson> i have!
[18:26] <chrisccoulson> not very often though, but it does still happen occasionally
[18:26] <kenvandine> i triggered it twice quickly with the new onboard, but wasn't able to with the previous version
[18:26]  * kenvandine will hold off on sponsoring this and comments on the bug :)
[18:27] <kenvandine> i thought smspillaz had really nailed that bug
[18:28] <seb128> chrisccoulson, eat slower!
[18:28] <seb128> chrisccoulson, 15 minutes is not a proper dinner time ;-)
[18:29] <chrisccoulson> heh
[18:32] <chrisccoulson> seb128, is this change temporary? https://launchpad.net/ubuntu/+source/glib2.0/2.31.2-0ubuntu2
[18:32] <chrisccoulson> do we know how much stuff is broken?
[18:33] <seb128> chrisccoulson, doko estimated over an hundred for the armfh rebuilds
[18:33] <chrisccoulson> i just had to fix chromium because stuff moved between header files, and it seems like enforcing the single include might help with those issues in the future :)
[18:33] <chrisccoulson> oh, quite a bit then
[18:33] <seb128> right that's the point
[18:33] <seb128> they warn about it since 2.18, i.e years
[18:33] <chrisccoulson> did he have a list, or are we going to need to do a rebuild to find out?
[18:33] <chrisccoulson> it would probably be good to track that somewhere
[18:33] <seb128> but we have lot of crufts
[18:34] <chrisccoulson> yeah :)
[18:34] <seb128> chrisccoulson, right, doko said he can do a test rebuild with that reverted
[18:34] <seb128> but I didn't want to have it block the armfh port start
[18:34] <chrisccoulson> sure, that's ok. i was just wondering :)
[18:34] <seb128> we can probably re-enable it once that is over
[18:35] <seb128> so in short: it's temporary yes
[18:36] <chrisccoulson> i should probably grep the firefox source tree now, just to see if i need to fix that :)
[19:46] <seb128> kenvandine, \o/ updating ido, getting ride of red lines on version ;-)
[19:52] <kenvandine> woot
[20:09] <mterry_sprinting> Is there a command that lists build-depends for a package?
[20:09] <broder> in what context?
[20:10] <broder> there's apt-cache showsrc
[20:10] <mterry_sprinting> broder, ah, that could work, thanks
[20:13] <chrisccoulson> ok, so, my firefox hanging xpcshell test seems to be hung waiting for a child plugin-container process to exit, which apparently happened already, as it's a zombie
[20:13] <chrisccoulson> hmmm :/
[20:14] <micahg> chrisccoulson: isn't that the same symptom of our flash bug on 3.6?
[20:15] <dobey> chrisccoulson: zombies haven't exited this realm yet. they are stuck here, looking for food.
[20:15] <chrisccoulson> micahg, i'm not sure
[20:23] <asac> wow on an old hardy instll i see zillion of .metacity/sessions/*.ms files
[20:23] <asac> whats that? can i just delete them without loosing important stuff?
[21:10] <bil21al> which branch  or control the empathy's  theme?
[21:51] <chrisccoulson> gah
[21:52] <chrisccoulson> i think i've cracked the hanging IPC xpcshell tests
[21:52] <chrisccoulson> plugin-container needs an X display, and we don't give the xpcshell tests one
[21:52] <chrisccoulson> indeed
[21:52] <chrisccoulson> that works!
[21:53] <chrisccoulson> i caught the "Couldn't open display" from the plugin-container process in strace, which must get redirected somewhere else normally
[21:53] <chrisccoulson> helpful!
[22:00] <seb128> chrisccoulson, hiding the tests output, how useful ;-)
[22:06]  * kenvandine heads out for some exercise, bbl