[00:35] <chrisccoulson> RAOF, thanks for looking at bug 903973 :)
[00:35] <ubot2`> Launchpad bug 903973 in xorg-server "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,In progress] https://launchpad.net/bugs/903973
[00:36] <RAOF> chrisccoulson: I'm a bit surprised that Peter didn't apply your patch as written; *everything* that calls dixLookupWindow seems to be broken.
[00:37] <chrisccoulson> RAOF, yeah, i did wonder that at the time, but never thought to argue about it :)
[00:37] <chrisccoulson> and then i'd forgotten about the whole issue until seb asked me to look at this bug today
[00:38] <RAOF> :)
[00:38]  * RAOF builds his patched server
[00:38] <RAOF> It's non-trivial to reproduce that problem, isn't it.
[00:42] <chrisccoulson> RAOF, yeah, i can't reproduce it here on my machine. when we had similar issues before, it was always at session start
[00:42] <RAOF> Yeah.  I won't bother whipping up testing packages; I'll just submit the patches to the list.
[00:43] <chrisccoulson> but i'd imagine that the trigger is rapidly creating and destroying a window, and then creating a pixmap straight afterwards
[00:43] <chrisccoulson> with multiple keyboard layouts enabled
[00:43] <RAOF> Yeah, such as might occur during startup.
[00:43] <chrisccoulson> yep :)
[00:43] <RAOF> Technically it could happen at pretty much any time; yay for asynchonous protocol!
[00:43] <chrisccoulson> heh
[01:01] <cyphermox> yo.
[01:58] <smspillaz> robert_ancell: poke
[01:59] <robert_ancell> smspillaz, hey
[01:59] <smspillaz> robert_ancell: hi
[01:59] <smspillaz> robert_ancell: I think you forgot to check in a file to xig
[01:59] <smspillaz> make[2]: *** No rule to make target `hello.c', needed by `hello-hello.o'. Stop.
[02:00] <robert_ancell> hello hello!
[02:00] <smspillaz> :)
[02:00] <smspillaz> sorry about the immcounicado for a while, got pulled off into another direction with the google test stuff. but I have a standalone window manager module thats mostly working now
[02:00] <smspillaz> so I'm going to start adding xig tests for it
[02:01] <robert_ancell> nice
[02:02] <smspillaz> but ... first I need to be able to compile the thing ;-)
[02:04] <robert_ancell> smspillaz, pushed
[02:04] <robert_ancell> pushing..
[02:04] <smspillaz> :)
[02:04] <robert_ancell> now pushed
[02:08] <smspillaz> thanks, all works now
[02:15] <smspillaz> robert_ancell: was xig-version.h removed ?
[02:16] <smspillaz> hmm, perhaps its not installed
[02:16] <smspillaz> hang on
[02:18] <smspillaz> robert_ancell: yeah, you need to add xig/xig-version.h to libxig_0include_HEADERS in xig/src/Makefile.am
[02:18] <robert_ancell> whoops
[02:19] <smspillaz> I can propose a branch if you want
[02:19] <robert_ancell> smspillaz, just pushed a fix
[02:19] <smspillaz> ok
[02:19] <robert_ancell> thanks
[02:19] <smspillaz> robert_ancell: also, I guess xig_remove_client_set_log_messages has changed ?
[02:19] <smspillaz> err
[02:19] <smspillaz> *remote client
[02:20] <robert_ancell> smspillaz, yes, there are signals for the messages, and you connect up the logger class if you want to log them
[02:20] <smspillaz> ok
[02:20]  * smspillaz adjusts test-runner.c for that then
[03:54] <smspillaz> robert_ancell: hmm. has some stuff changed recently in xig? I seem to be getting libX11 assertion failures about the loss of event sequencing
[03:54] <smspillaz> I can have a look into whats going on if you want
[03:54] <robert_ancell> smspillaz, nothing should have changed drastically - can you send me a test case?
[03:56] <smspillaz> robert_ancell: run compiz on it :)
[03:56] <smspillaz> I can see if there's a particular thing that's triggering the bug though .. I'll run with XSynchronize
[04:00] <cyphermox> oh, bluez, how I love you...
[04:13] <smspillaz> robert_ancell: hmm, well, it seems to get a SIGPIPE every time it tries to send a PropertyNotify
[04:18] <smspillaz> robert_ancell: maybe I can bisect to see what was causing the problem? I don't know the xig code that well
[04:19] <robert_ancell> smspillaz, worth trying - does it definitely work with the older version?
[04:20] <smspillaz> there were problems with the older version too, but I'm not sure if they were the same ones really
[04:49] <smspillaz> robert_ancell: hmm, it seems like a commit that broke the build was introduced at 136, so I can't bisect :(
[04:50] <robert_ancell> ugh
[06:47] <pitti> Good morning
[06:54] <bryceh_> pitti, feeling better yet?
[06:54] <pitti> slightly, thanks
[07:05] <didrocks> good morning
[07:08] <TheMuso> Morning pitti, didrocks.
[07:15] <pitti> hey TheMuso, happy new year! how are you?
[07:15] <pitti> bonjour didrocks
[07:16] <didrocks> good morning TheMuso, happy new year!
[07:16] <didrocks> guten morgen pitti. Are you feeling better today?
[07:16] <pitti> didrocks: quite a bit better, thanks
[07:17] <TheMuso> pitti: Well thanks, not sure if I feel frefreshed or not after my break, probably because I have to travel barely 4 days after I get back from my break. :)
[07:17] <rickspencer3> good morning pitti, didrocks
[07:17] <rickspencer3> good evening TheMuso
[07:18] <pitti> bonjour rickspencer3, ca va?
[07:18] <rickspencer3> ça va bien, et toi
[07:18] <rickspencer3> ?
[07:18] <TheMuso> Hey rickspencer3.
[07:18] <TheMuso> Anyway, bbl.
[07:18] <pitti> rickspencer3: Je suis encore froid, mais c'est mieux
[07:19] <rickspencer3> pitti, ah tu est enhrume encore? je comprendre
[07:20] <rickspencer3> je suis content que tu vas mauvais
[07:20] <pitti> rickspencer3: ^ at this point both google translate and me give up :)
[07:20] <rickspencer3> lol
[07:20] <rickspencer3> pitti, you were quite comprensible
[07:22] <rickspencer3> hmmm
[07:23] <rickspencer3> maybe in the future we should organize sprints with 2 sites, one in Australia and one in NA/Europe so people like TheMuso and robert_ancel and RAOF, etc... don't get quite so hard in the teeth
[07:26] <TheMuso> rickspencer3: I don't want special treatment, but I am not a fan of traveling, the flying in particular. I enjoy the events/getting together with everyone during the week, but its the travel itself that gets me down.
[07:27] <TheMuso> But, thats part of the job.
[07:27] <TheMuso> Really afk now.
[07:27] <pitti> TheMuso: good night!
[07:29] <smspillaz> rickspencer3: ahem
[07:29] <smspillaz> rickspencer3: 30 hours wooooooooooooooooooooooooo!
[07:29] <smspillaz> rickspencer3: I think its quite awesome that we get to travel so much
[07:30] <didrocks> bonjour rickspencer3 :)
[07:30] <smspillaz> hey didrocks
[07:30] <didrocks> 08:20:07 rickspencer3 | je suis content que tu vas mauvais
[07:30] <didrocks> pitti: I won't like that if I were you :)
[07:30] <didrocks> hey smspillaz
[07:31] <pitti> didrocks: sounds like "I'm happy that you are wrong" or so?
[07:31] <didrocks> exactly :)
[07:31] <pitti> if "content" is the same as in English
[07:31] <pitti> ah, rickspencer3 meant froid -> enrhume ?
[07:32] <didrocks> (it's "j'ai pris froid", but understandable)
[07:32] <didrocks> you "take" the cold (for no good reason ;))
[07:33] <pitti> je ne parlez pas francais!
[07:33] <pitti> Deutsch ist viel einfacher
[07:33] <pitti> anyway, off to killing more useless stuff during boot; next up: notify-osd
[07:33] <didrocks> well, you really don't want to challenge the German that I have :)
[08:12] <Sweetshark> good morning everyone!
[08:12] <Sweetshark> pitti: apropos deutsch http://nabble.documentfoundation.org/Introducing-Grande-Latte-td3632391.html
[08:13] <pitti> :)
[08:13] <pitti> hey Sweetshark, guten Morgen
[09:03] <rickspencer3> hey pitti I'm not surprised that my terrible French broke Google Translate for you, sorry ;)
[09:16] <seb128> hey
[09:16] <pitti> bonjour seb128
[09:16] <seb128> hey pitti, how are you? getting over the cold?
[09:17] <pitti> seb128: quite fine, thanks! still congested nose and some coughing, but feeling a lot better
[09:17]  * pitti is this --><-- close to killing notify-osd at boot :)
[09:18] <pitti> meh, lots of packages failing to build now due to deprecated GTK stuff (VBox and the like)
[09:18] <pitti> (nautilus)
[09:18] <pitti> for indicator-sound I reported a bug upstream and build without -Werror
[09:18] <pitti> pondering to do the same for nautilus
[09:19] <seb128> released versions shouldn't use G*_DISABLE_DEPRECATED or Werror
[09:19] <seb128> or we keep running into such issues :-(
[09:19] <pitti> it's the nautilus that's in bzr, i. e. in current precise
[09:19] <pitti> upstream trunk actually builds fine ;)
[09:20] <seb128> right, I exepect they updated the new serie for the new glib and gtk
[09:20] <seb128> pitti, we should just drop the disable deprected for precise, or at least we should disable them even if we fix the issue or we will keep playing catchup on deprecation with every gtk update
[09:21] <seb128> but weird, I built nautilus yesterday here and I've the new glib and gtk installed
[09:21] <pitti> hm, maybe I mislooked, hang on
[09:22] <pitti> (need to change something in the backporting of the trunk patch)
[09:22] <didrocks> salut seb128, ça va?
[09:23] <seb128> didrocks, lut, très bien, et toi ?
[09:23] <didrocks> seb128: ça va bien :)
[09:24] <pitti> seb128: sorry, just read it wrongly, builds fine
[09:24] <pitti> indicator-sound was real, I dropped the -Werror in our package there
[09:26] <seb128> pitti, right, I had that discussion with dx before
[09:30] <seb128> pitti, note that GNOME doesn't start nautilus with their session, but still a bug and something they can fix ;-)
[09:30] <pitti> seb128: right; my patch is working, sending to upstream and applying in our package
[09:30] <pitti> with these two, notify-osd is gone in both lightdm and the session
[09:30] <seb128> great
[09:35] <pitti> so, that's gsd-printer and notify-osd, next to kill: gnome-screensaver :)
[09:36] <pitti> although we could win a lot more by killing this weird "compiz" process; it eats CPU for breakfast!!11!
[09:37] <bryceh_> pitti, +1
[09:37] <chrisccoulson> good morning everyone
[09:38] <seb128> hey chrisccoulson, bryceh_
[09:38] <seb128> how are you?
[09:38] <bryceh_> heya seb128
[09:38] <chrisccoulson> woohoo, no more gconf dependency in upstream firefox builds: https://hg.mozilla.org/integration/mozilla-inbound/rev/04244dc1f498 :)
[09:38] <chrisccoulson> seb128, yeah, good thanks. how are you?
[09:38] <pitti> hey chrisccoulson
[09:38] <pitti> chrisccoulson: \o/
[09:39] <bryceh_> seb128, I'm fine.  Family is a bunch of sickies though.
[09:39] <didrocks> pitti: you start notify-osd only on demand then? (just curious)
[09:39] <pitti> chrisccoulson: dropping gtk2 _and_ gconf? rad!
[09:39] <pitti> didrocks: yes, as it's meant to be
[09:39] <seb128> chrisccoulson, I'm good thanks ;-)
[09:39] <seb128> chrisccoulson, no gconf \o/
[09:39] <didrocks> pitti: nice! :)
[09:39] <pitti> didrocks: but indicator-sound and nautilus queried the server caps right at startup; I changed that to lazy init
[09:39] <didrocks> ah ok ;)
[09:40] <pitti> screensaver's autostart .desktop has X-GNOME-Autostart-Delay=5
[09:40] <pitti> but it's started at the very beginning, presumably triggered through dbus
[09:41] <seb128> right, that's likely
[09:41] <pitti> it would probably be okay to start it 10 or 20 seconds into the session
[09:41] <bryceh_> seb128, maybe I'm providing the ubuflu shipment this year 8-}
[09:41] <seb128> bryceh_, what I was thinking!
[09:41] <pitti> bryceh_: argh, you too? mine should be gone right in time for Budapest
[09:42] <seb128> well I'm just out of a cold so with some luck I will not get another one
[09:42] <pitti> no hugs for bryceh_ this time!
[09:42] <bryceh_> pitti, no I'm well at the moment.  but both kids and wife have it.
[09:42] <chrisccoulson> oh, bingo! i know why the firefox IPC tests are failing now
[09:42] <pitti> seb128: if only there weren't ~ 250 different kinds of cold viruses..
[09:42] <seb128> let's see if my body has built enough defences to avoid getting something else ;-)
[09:42] <chrisccoulson> the child process quits with "Maximum number of clients reached"
[09:42] <bryceh_> pitti, no kidding.
[09:42] <seb128> pitti, yeah, people coming from around the world doesn't help :-(
[09:42] <chrisccoulson> now i need to figure out what's stealing all my X connections!
[09:42] <pitti> with 2 colds a year it takes a lifetime to get immune against the more common half
[09:43] <bryceh_> fortunately what my kids have seems to be relatively mild; they've still been bouncing off the walls when not busy coughing.
[09:43] <seb128> hehe
[09:44] <bryceh_> on a separate topic, my mother upgraded herself from natty to oneiric and discovered unity
[09:44] <bryceh_> so today involved giving my mother some unity lessons
[09:44] <seb128> still not simple enough? ;-)
[09:44] <seb128> or just "how to work better with it"?
[09:45] <pitti> hm, wikipedia says "more than 200 known viruses"; I thought I read a more exact number somewhere
[09:46] <bryceh_> seb128, half and half.
[09:46] <seb128> pitti, too many to be well covered in any case :-(
[09:47] <seb128> bryceh_, was the experience mostly positive? what did she like,dislike?
[09:47] <bryceh_> seb128, main issue was she likes this ancient windows card game, which requires wine to run, and the gnome-panel icon I'd made for her didn't survive the upgrade
[09:47] <bryceh_> so got to learn how to make custom launchers :-)
[09:48] <seb128> that should be fixed this cycle with some luck
[09:48] <seb128> design recommended that we package and ship https://launchpad.net/unity-launcher-editor by default
[09:49] <pitti> seb128: at least, the older we get the fewer colds we should get
[09:49] <seb128> pitti, indeed
[09:50] <bryceh_> seb128, she had trouble figuring out how to close programs (since the window decorations get hidden), and had trouble finding how to launch programs.  So most of the tutoring was for how to do those two things.
[09:51] <bryceh_> seb128, her first computer was my Commodore 64, so to her this was just yet another UI to have to learn, I think she was neutral on it over all
[09:52] <bryceh_> seb128, oh, the one regression that she definitely disliked was losing the picture slideshow screensaver.  I had her set up with pics of my kids which she adores, so she definitely misses that.
[09:52] <seb128> yeah, the screensaver stuff is unfortunate
[09:53] <bryceh_> but I figure it should be trivial to write a little slideshow tool to workaround that
[09:53] <pitti> ok, it's g-s-d's libpower.so
[09:56] <pitti> looks fixable
[09:58] <chrisccoulson> pitti - libpower.so starting notify-osd?
[09:58] <pitti> chrisccoulson: no, gnome-screensaver
[09:58] <chrisccoulson> ah, ok
[09:58] <pitti> chrisccoulson: notify-osd is already fixed
[09:58] <chrisccoulson> cool
[09:58] <chrisccoulson> pitti - the power plugin could probably do with some of the notification related fixes we used to carry in gnome-power-manager
[09:59] <chrisccoulson> (particularly with regards to notification priority and duration)
[09:59] <chrisccoulson> i could probably fix those though
[09:59] <pitti> is there something particular which works the wrong way ATM?
[09:59] <pitti> I seldomly see the "low battery" stuff
[10:00] <chrisccoulson> pitti - yeah, the critical notification appears as the fallback dialog (complete with "Ok" and "Cancel" button)
[10:03] <chrisccoulson> bryceh_, is there any way to find out what's using up all of my X connections in https://launchpadlibrarian.net/89118807/buildlog_ubuntu-lucid-amd64.firefox-trunk_12.0~a1~hg20120103r83671-0ubuntu1~umd1~test_BUILDING.txt.gz ?
[10:03] <chrisccoulson> (i'm using xvfb)
[10:05] <bryceh_> chrisccoulson, hmm, interesting.  There are several tools... let's see.  xrestop tells how many clients there are
[10:06] <bryceh_> wmctrl -l will give you a list of windows
[10:07] <chrisccoulson> bryceh_, thanks
[10:08] <bryceh_> yeah I'd try those first.  beyond that not sure, but the info is there in the server for querying
[10:09] <bryceh_> chrisccoulson, xtrace also can be handy if you have a suspicion what specific client may be at fault
[10:10] <chrisccoulson> bryceh_, yeah, i'm not sure yet. i'm just seeing "Maximum number of clients reached\n(<unknown>:22600): Gtk-WARNING **: cannot open display: :99" on the first test which requires an X connection
[10:12] <bryceh_> chrisccoulson, intriguing.  Well, I'd guess a particular client has a flaw that causes it to iteratively make connections until it's used them all up
[10:12] <bryceh_> I think there's only like 127 or 255 permitted, it's not too difficult to exhaust them
[10:13] <bryceh_> chrisccoulson, a test suite which opens a connection per test and is sloppy at closing them could do it
[10:25] <chrisccoulson> bryceh_, oh, does Xvfb not do any access control? :/
[10:26] <bryceh_> chrisccoulson, it may not, it's fairly primitive
[10:26] <chrisccoulson> i wonder if something else on the builder connects to it ;)
[10:26] <chrisccoulson> the problem is only reproducible on the builders
[10:27] <bryceh_> another factor is the builders are running an older release
[10:28] <bryceh_> chrisccoulson, but I would not think anything outside the test suite could possibly want to connect to your xvfb instance
[10:30] <chrisccoulson> yeah, probably. i'm just trying to think why i can't reproduce it anywhere else ;)
[10:34] <bryceh_> chrisccoulson, there were a few changes we put in for xorg-server (2:1.10.4-1ubuntu1), such as a dependency on xauth; possibly those changes are not present in the buildd's
[10:34] <seb128> pitti, what would you think about making dh_translations use config.h before configure.ac?
[10:35] <seb128> pitti, to get the gettext domain
[10:36] <seb128> pitti, the issue I come from is gdk-pixbuf which uses "GETTEXT_DOMAIN="$PACKAGE"" in its configure.ac
[10:36] <seb128> pitti, so domain=$PACKAGE and it calls intltool-update -d $PACKAGE
[10:36] <seb128> pitti, the config.h has the correct domain
[10:37] <seb128> (not sure I'm clear)
[10:37] <bryceh_> chrisccoulson, actually the xauth dependency appears to be introduced in maverick.  Still, I think the buildd's are on lucid and I'm not sure whether we backported that.  If you're testing locally on a different ubuntu release than the buildd's that could explain it.
[10:39] <pitti> seb128: sounds fine to me; config.h also has GETTEXT_DOMAIN? or is it called differently there?
[10:41] <seb128> pitti, configure.ac use AC_DEFINE(GETTEXT_PACKAGE) often, so it does land in the config.h
[10:42] <seb128> pitti, it's needed for the makefiles to be able to use -DGETTEXT_PACKAGE for the setlocale() etc
[10:42] <seb128> pitti, I will open a bug and a merge request for it today
[10:42] <seb128> pitti, danke
[10:42] <pitti> seb128: thanks
[11:19] <pitti> seb128: I wonder if we need to autostart gnome-screensaver at all -- do you know what triggers it on timeout? gnome-session or is that g-s itself?
[11:19] <pitti> I now fixed g-s-d's power plugin, but that only does the screen locking when upower goes to sleep
[11:19] <seb128> pitti, well upstream autostart it because they don't have the dbus service IIRC
[11:19] <pitti> (but that dbus-activates)
[11:19] <seb128> that's something we distro add
[11:20] <pitti> oh, really? that's surprising indeed
[11:20] <seb128> pitti, I think it's gnome-session or gnome-settings-daemon which triggers it
[11:20] <pitti> not g-s-d
[11:20] <seb128> pitti, http://git.gnome.org/browse/gnome-screensaver/commit/?id=3365eec74643773d8d5aa92901b39bdc9496e19b
[11:21] <pitti> ah
[11:21] <pitti> hm, it doesn't hurt, thuogh
[11:21] <seb128> pitti, I think mdeslaur didn't like that
[11:21] <pitti> if g-s crashes, then the .service file would at least bring it back on suspend, etc.
[11:21] <seb128> so we still dbus activate it to increase the chance to not run in a "locking doesn't lock"
[11:21] <pitti> *nod*
[11:22] <pitti> seb128: do you mind if we bump the autostart delay from 5 to 20 secs?
[11:22] <seb128> pitti, well gnome-session is supposed to respawn stuff if they use X-GNOME-AutoRestart=true, that would perhaps be enough
[11:22] <seb128> pitti, not at all
[11:22] <seb128> go for it
[11:23] <pitti> seb128: hm, I can killall gnome-screensaver here and it doesn't come back automatically
[11:23] <pitti> that's how I test the g-s-d fix
[11:23] <seb128> pitti, right because /etc/xdg/autostart/gnome-screensaver.desktop doesn't have that line "X-GNOME-AutoRestart=true"
[11:23] <seb128> which seems a bug to me
[11:23] <pitti> a quick grep of g-s shows that it seems to do the timeout itself
[11:23] <pitti> so we do need to start it
[11:24] <pitti> seb128: well, at least it gets activated on suspend
[11:24] <seb128> pitti, you should ask vuntz in case he's around
[11:24] <seb128> or maybe chrisccoulson knows what is tracking the idle time to call gnome-screensaver
[11:24] <seb128> but I think it's gnome-session itself
[11:25] <pitti> easy enough to try
[11:25] <pitti> I set it to 30 secs, kill it, and check what happens :)
[11:39] <pitti> seb128: so, g-s handles the timeout itself, so it needs to be running
[11:39] <pitti> seb128: ctrl+alt+l works when it's not running, so it seems g-s or g-s-d spawns it then
[11:40] <pitti> seb128: but /etc/xdg/autostart/gnome-screensaver.desktop doesn't seem to work right now, it never gets run
[11:40] <seb128> pitti, right, g-s-d handles the keybindings
[11:40] <pitti> NoDisplay=true
[11:40] <pitti> ^ does that disable autostarting?
[11:40] <seb128> that's ok, that means "don't list it in gnome-session-properties"
[11:40] <seb128> oh
[11:40] <pitti> hm, I wonder what keeps it from starting then
[11:40] <seb128> OnlyShowIn=GNOME;
[11:41] <seb128> you need to add Unity;
[11:41] <pitti> ooh, needs UNity
[11:41] <pitti> willdo
[11:41] <seb128> danke ;-)
[11:41] <seb128> add the "X-GNOME-AutoRestart=true" as well if you want
[11:41] <seb128> that should make gnome-session respawn it
[11:41] <pitti> hm, do we want this?
[11:42] <seb128> it's probably not needed with the dbus service
[11:42] <seb128> it will respawn it
[11:42] <pitti> and if someone kills it, it might be deliberate
[11:43] <pitti> working around movie players which don't inhibit it, and the like
[11:43] <seb128> or it might segfault in which case you get screen locking not working in the upstream case
[11:43] <seb128> but yeah, with the dbus service we don't have that issue
[11:43] <seb128> so NOTUBUNTU
[11:44] <pitti> screensaver-be-gone \o/
[11:45] <seb128> lol
[11:46] <pitti> adding "Unity" does the trick
[12:00] <seb128> pitti, https://code.launchpad.net/~seb128/pkgbinarymangler/smallfixes/+merge/87602
[12:00] <pitti> RAOF: do we really need to start colord at boot? would it be possible to add a gsettings check to only launch it if you actually configured anything?
[12:01] <pitti> seb128: could you swap it around and try config.h first? and then use the if (!$domain && ... schema?
[12:02] <pitti> fits better into the existing code, and avoids reading multiple files
[12:02] <seb128> pitti, not really since config.h doesn't have the "use intltool" info
[12:02] <pitti> ah, of course
[12:02] <seb128> pitti, and ups, I've a small fix to do
[12:02] <seb128> so don't merge that please
[12:03] <pitti> seb128: looks fine otherwise, so please go ahead and merge yourself with a changelog
[12:03] <seb128> pitti, ok thanks
[12:03] <pitti> seb128: what's still wrong, OOI?
[12:03] <seb128> pitti, small error in the config.h regexp
[12:04] <seb128> the format is not exactly the configure.ac one
[12:04] <seb128> just fixing that ;-)
[12:04] <pitti> ah, ok
[12:07]  * Sweetshark install half a million build deps on porter-dchroot
[12:08] <pitti> Sweetshark: nice that we can now :)
[12:10] <Sweetshark> pitti: should I test the beta2 on the porters first, or would you upload for precise as-is (with risk of breaking on ppc/armel)?
[12:10] <pitti> Sweetshark: for such a major upgrade I'd test it on a porter machine first
[12:10] <pitti> I wouldn't do it for every single upload, but with that many changes it's likely that something goes wrong
[12:11] <pitti> Sweetshark: I would worry less about powerpc, just armel
[12:11] <pitti> Sweetshark: does that need any new MIRs?
[12:13] <Sweetshark> pitti: not as of now, I am just using --with-system-foo when something crops up.
[12:14] <Sweetshark> pitti: I filed one MIR, doko didnt like it as is => should be discussed at sprint maybe.
[12:15] <Sweetshark> pitti: s/--with-system-/-without-system-.
[12:15] <Sweetshark> pitti: so a) it builds now b) if we decide to mir, we can switch.
[12:16] <pitti> Sweetshark: sounds good
[12:18] <Sweetshark> porter-ppc is hugged with building LO-beta
[12:20] <seb128> pitti, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/pkgbinarymangler/precise/revision/231
[12:20] <seb128> that being done -> lunch ;-)
[12:20] <pitti> ah, the #define
[12:21] <pitti> seb128: nice! please go ahead and upload
[12:24]  * Sweetshark install 310 additional build deps on armel
[12:25] <ricotz> Sweetshark, hi
[12:26] <Sweetshark> ricotz: re-hi ;)
[12:26] <ricotz> Sweetshark, do you know if the libreoffice postgresgl plugin is meant for 9.0?
[12:27] <ricotz> Sweetshark, i built the 3.4.4 precise package on lucid and needed to disable this plugin
[12:27] <Sweetshark> ricotz: you mean the postgres backend for base?
[12:27] <pitti> 9.0? should be 9.1 for precise/oneiric and 8.4 for older releases
[12:28] <Sweetshark> ricotz: it requires the >9.0 headers of postgres, yes.
[12:28] <ricotz> oh, ok, wasnt really sure about the version number, but it wouldnt build against 8.4
[12:28] <ricotz> Sweetshark, ok
[12:29] <Sweetshark> ricotz: wait for 3.5.0 and all is shiny.
[12:29] <Sweetshark> ricotz: 3.5.0. should be a lot better than 3.4.0 for various reasons ;)
[12:29] <ricotz> Sweetshark, this means it will build against 8.4 again?
[12:29] <Sweetshark> ricotz: um, no.
[12:30] <ricotz> Sweetshark, ok, so i will keep it disabled then
[12:30] <ricotz> Sweetshark, yeah of course i am looking forward for a new feature release :P
[12:30] <Sweetshark> ricotz: I meant it will be enabled in the default package for 3.5.0/precise as it is in there upstream and we have 9.0 on precise.
[12:31] <tkamppeter> pitti, hi
[12:31] <pitti> tkamppeter: hello, gesundes neues Jahr! Enjoyed your vacation?
[12:32] <ricotz> Sweetshark, of course that is fine, i just wanted to be sure about the needed versions, maybe you can push a bump for 9.0 to packaging git
[12:32] <tkamppeter> pitti, was great, also a successful New Year for you!
[12:32] <pitti> thanks
[13:18] <mpt> mvo, hi, I'm working on the OS upgrade design again. If updates for your machine's current Ubuntu version are available, and a new Ubuntu version is available too, is there any reason for people to install the updates before they do the upgrade?
[13:19] <mvo> mpt: yes, sometimes we have updates that fix issues that happen during the upgrade otherwise, its not happening that often, but it does happen from time to time, i.e. updating a old app so that it does not misbehave during the upgrade
[13:20] <mvo> or to provide a feature during the upgrade
[13:21] <mpt> mvo, is there a way of telling which updates fall into that category and which don't?
[13:23] <mvo> mpt: unfortunately not at this point and I don't have any hard data currently except for "we did need it in the past" :(
[13:24] <mpt> mvo, then should the OS upgrade process automatically install all available updates first?
[13:25] <mvo> mpt: that would be a good idea or even better we flag the updates we really need and only install them (more work though)
[13:27] <mpt> mvo, what if upgrading requires first installing an update to update-manager itself? Is it smart enough to relaunch itself?
[13:28] <mvo> mpt: yes
[13:29] <mvo> mpt: hm, mostly, the release upgrader is, u-m itself is not
[13:29] <mpt> mvo, ah, I didn't realize that was a separate process
[13:30] <mvo> mpt: u-m just downloads the release-upgrader and verifies it, from that point on this part takes over
[13:30] <mpt> mvo, so is there anything tricky that would prevent USC from downloading and running release-upgrader, instead of update-manager doing it?
[13:31] <mvo> mpt: no, I can't think of anything, we would "just" have to shuffle some code around
[13:32] <mvo> mpt: what makes it tricky is that it does not get any real testing except for when the release is done
[13:32] <mpt> ok
[13:33] <mvo> i.e. we release it into unstable, but because you never release upgrade from unstable to something its sitting there until unsable becomes stable and then the next unstable becomes availalbe
[13:39] <mpt> thanks for those answers mvo
[13:41] <mvo> mpt: cheers, your welcome
[14:06] <mhr3> seb128, do you know anyone's been playing with systemtap for debugging on ubuntu?
[14:06] <pitti> chrisccoulson: both firefox and tbird grw by 1.3 MB each between 9.0 and 10.0 -- any chance this can be squeeze again a bit?
[14:06]  * pitti investigating our current oversizedness
[14:07] <seb128> mhr3, desrt was looking at it, dunno about "on ubuntu", do you have ubuntu specific questions?
[14:07] <chrisccoulson> pitti - bug 894166 :)
[14:07] <ubot2`> Launchpad bug 894166 in firefox "Make hyphenation work with system hyphenation patterns" [High,Triaged] https://launchpad.net/bugs/894166
[14:07] <pitti> chrisccoulson: ah, thanks!
[14:07] <chrisccoulson> i might need some input on how to make that work correctly though
[14:07] <seb128> pitti, did you see the pad notes?
[14:08] <seb128> evince-common (Δ 1.4 MB - 3.2.0-0ubuntu1: 0.5 MB   3.2.1-0ubuntu2: 1.8 MB) due to adding /usr/share/gnome/help/evince/C/figures/synctex_screencast.ogv
[14:08] <seb128> thunderbird (Δ 0.9 MB - 7.0.1+build1+nobinonly-0ubuntu1: 18.7 MB   8.0+build1-0ubuntu1: 19.6 MB)
[14:08] <pitti> seb128: I thought it was me who added the evince one in the first place :)
[14:08] <seb128> pitti, the first one should be easy to fix by just not shipping the video, though that feels a bit wrong, but I don't see a better way, and synctex demo is not that useful
[14:08] <pitti> I agree
[14:09] <seb128> pitti, ok, the pad is not good to put names with lines :p
[14:09] <seb128> pitti, I was mentioning it in case ;-)
[14:09] <pitti> yeah, I actually forgot about it
[14:09] <pitti> seb128: I can drop the file, I'll check how the help behaves
[14:09] <pitti> ok?
[14:09] <mhr3> seb128, i was wondering how does it work generally as well as if ubuntu has some packages to help with it... like there are some static probes and glib has support for them, but dunno if one needs to compile glib with that or what...
[14:10] <seb128> mhr3, we need to compile glib with it, we looked at it at the rally before UDS with desrt but it didn't play well with multiarch iirc
[14:10] <seb128> mhr3, could be a topic for next week...
[14:10] <seb128> pitti, sure, I think I tried that some weeks ago, the help just skip the video so it's not an issue
[14:11] <pitti> since oneiric, firefox and tbird each grew by 2.6 MB
[14:11] <pitti> we have 6.2 MB package growth, plus 10 MB from new packages
[14:12] <seb128> lucky that we dropped the mono stack ;-)
[14:12] <pitti> that's already included in the 10 MB balance, though
[14:12] <seb128> urg
[14:12] <pitti> removed: 78.3 MB, added: 88.7 MB
[14:12] <seb128> that's less nice
[14:12] <pitti> (most of that are new library/kernel ABIs)
[14:13] <seb128> does that include extra langpacks?
[14:13] <pitti> no
[14:13] <seb128> 90mbs seems quite a lot for new libraries
[14:13] <seb128> wth?
[14:14] <pitti> seb128: no, I mean e. g. linux-headers-3.0.0-12 got dropped, and linux-headers-3.2.0-7-generic got added
[14:14] <mhr3> seb128, ok, good to know, thx
[14:14] <seb128> ok
[14:14] <pitti> seb128: it should really be in "changed", but the script isn't clever enough to match packages with different names
[14:14] <seb128> yeah, gotcha now ;-)
[14:14] <pitti> seb128: python 3.2 adds 5.9 MB, the other 4.1 is from a bunch of smaller stuff
[14:15] <seb128> well, so it's mostly chrisccoulson's fault
[14:15] <seb128> it would be nice if we could drop a webkitgtk from the cd
[14:15] <pitti> yes, that's what I'm yearning for
[14:15] <seb128> or gtkmm2 (but that's blocked on gparted which doesn't seem actively maintained)
[14:16] <pitti> libicu44 7.0 MB -> libicu48 (8.1 MB) doesn't help much either
[14:21] <chrisccoulson> gah, i really wish i could reproduce this test hang on anything other than a PPA :/
[15:05] <mpt> mvo, <https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-improve-upgrade-experience> refers to a dialog that has "Don't Upgrade" and "Ask Me Later" buttons. How can I invoke this dialog?
[15:11] <mvo> mpt: if you are on oneiric you can run "/usr/lib/update-manager/check-new-release-gtk -d" to trigger it
[15:12] <mpt> huh
[15:13] <mpt> mvo, it's like a polished version of the update-manager -cd -> click "Upgrade" dialog
[15:14] <mvo> mpt: yes, one of your colleges speced it, its html, we could display more interessting stuff in there if we had any
[15:14] <mpt> except that the "Release Notes" link opens a page showing *exactly the same text*, just unformatted :-)
[15:14] <mvo> mpt: there is a bug open for that (maybe even fixed, not sure if that got a SRU or not)
[15:23] <BigWhale> Greetings.
[15:34] <seb128> didrocks, joining the pygobject hater club and reassigning bugs to it? ;-)
[15:34] <didrocks> seb128: completly! :)
[15:35] <didrocks> but shhhh, you will make mvo upset again :)
[15:36]  * mvo grabs a chair so that he can throw it
[15:37] <didrocks> ;)
[15:40] <mvo> didrocks: which is your one?
[15:41] <mvo> for me threading is complettely broken, if I init threads it crashes on close, if I don't it hangs when trying to start a thread, its just not cool
[15:41] <pitti> mvo: gtk.init() already initializes threads these days, hmm
[15:42] <didrocks> mvo: just a crasher creating a new object
[15:42] <mvo> right, thats what I thought too, I have no idea why its not working, but I use spawn_async() now, much more reliable for me
[15:49] <seb128> mvo, blame it on desrt ;-)
[15:50] <seb128> you can poke him directly next week
[15:54] <chrisccoulson> seb128, aren't you meant to be doing the poking? ;)
[15:54] <seb128> chrisccoulson, oh wait, I've some for you!
[15:54] <Sweetshark> meh, porter-armel deadlocked itself and I cant kill the process.
[15:55] <seb128> chrisccoulson, ;-)
[15:55] <seb128> Sweetshark, talk to lamont I guess?
[15:55] <chrisccoulson> seb128, i can't wait! :)
[15:56] <seb128> chrisccoulson, you will not leave the rally until the tb indicator behaves ;-)
[15:56] <Sweetshark> seb128: well, I just killed the whole dchroot, which kinda "solved" it for me ...
[15:56] <chrisccoulson> seb128, and we have overlay scrollbars?
[15:56] <chrisccoulson> :)
[15:56] <seb128> Sweetshark, ok...
[15:56] <chrisccoulson> i think i'm going to be stuck in budapest forever!
[15:57] <seb128> chrisccoulson, nobody is bothering me about the scrollbars, but since you mentioned it, did you have a look to that? or did you manage to use your holidays to not work? ;-)
[15:57] <Sweetshark> chrisccoulson: we will fight our way out!
[15:57] <BigWhale> dobey, are you around? I'd bug you with some Gtk stuff.
[15:57] <BigWhale> Or anyone fluent in that :>
[15:57] <mvo> seb128: I get a *segfault* from GtkImage.set_from_pixbuf(pb) currently, this used to work before my upgrade this morning
[15:57] <chrisccoulson> hmmm, i wish the builders were faster. i need to wait over an hour before my test fails again: https://launchpad.net/~chrisccoulson/+archive/mozilla-test/+build/3070682
[15:58] <seb128> mvo, what did you upgrade? stacktrace?
[15:58] <dobey> BigWhale: busy atm
[15:58] <seb128> mvo, was pygobject or gtk in that update?
[15:58] <seb128> dobey, hey
[15:58] <dobey> hi seb
[15:58] <Sweetshark> chrisccoulson: ha! just _one_ hour?
[15:58] <mvo> seb128: my test fails now bt show s gtk_image_cleear() crashes - I don't know what got updated, it was a whole bunch. sorry for not being more specific I know that its not helpful
[15:58] <chrisccoulson> seb128, i did pretty much no work at all over the holiday, except for https://bugzilla.mozilla.org/show_bug.cgi?id=713827
[15:59] <ubot2`> Mozilla bug 713827 in General "dlopen() gconf library in mozgnome component" [Normal,New: ]
[15:59] <seb128> dobey, do you request specific sponsoring from kenvandine for a reason? I started sponsoring the u1 stuff and stopped since I noticed you didn't request for sponsoring but just for review from ken
[15:59] <BigWhale> dobey, ok .. I'll be busy a bit later, I'll send you a question and answer whenever you feel like it... :)
[15:59] <seb128> chrisccoulson, good! ;-)
[15:59] <mvo> seb128: I will dig into it, its just spoiling the fun if both threading and that crash my testsuite (that runs fine on oneiric I should add)
[15:59] <seb128> mvo, lol
[15:59] <mvo> I'm sure its a refcount problem of some sort
[16:00] <mvo> (well, not sure, but I would bet it is)
[16:00] <seb128> mvo, will be another annotation issue at the end I'm sure, so you can complain about how buggy is the gobject stack :p
[16:01] <dobey> seb128: he told me to set him as reviewer, because of the whole confusion with the "distro readiness" stuff
[16:01] <seb128> dobey, ok, I will check with him
[16:01] <seb128> or we can sort it next week
[16:01] <seb128> dobey, thanks
[16:01] <mvo> new gir1.2-gtk3.0 was in the upgrade fwiw
[16:01] <seb128> kenvandine, ^ u1 should be sponsored only by you?
[16:01] <seb128> mvo, not a surprise ;-)
[16:02] <kenvandine> seb128, nah... feel free to :)
[16:02] <dobey> seb128: you can sponsor them if you want.
[16:02] <mvo> aren't you supposed to like … defend it or something?
[16:02] <seb128> kenvandine, dobey: ok thanks
[16:02] <seb128> mvo, well I'm sure you misuse gtk and blame it wrongly
[16:02] <dobey> seb128: pitti put something on the desktop team agenda for budapest, to discuss the situation :)
[16:03] <seb128> mvo, I'm just not surprise that you use the "gtk was in the upgrade" card ;-)
[16:03] <dobey> i won't be in budapest though
[16:03] <mvo> seb128: aha, that sounds more like the seb I know
[16:03] <seb128> mvo, ;-)
[16:06] <seb128> mvo, http://git.gnome.org/browse/gtk+/commit/gtk/gtkimage.c?id=f085dde830d72b8cd0c804593631a944e9dbf45d
[16:06] <seb128> mvo, I bet that's bug in that refactoring
[16:06] <BigWhale> kenvandine, Kazam is a screen recorder I am working on ...
[16:06] <BigWhale> :>
[16:07] <BigWhale> sorry for the lag
[16:07] <BigWhale> :))
[16:09] <mvo> seb128: yeah, I will try to get a small testcase, but its currently a bit anoying, my test code is fine of course
[16:12] <seb128> mvo, thanks, sorry about the issues
[16:26] <mvo> seb128: I have a call now :/ If you have a debug build of gtk it would be nice if you could run "bzr get lp:software-center; cd software-center/test; python gtk3/test_views.py" - crashes for me, maybe you get a useful backtrace
[16:27] <seb128> mvo, let me try
[16:27] <jono> kenvandine, are you aware of Gwibber crashing in Precise right now?
[16:27] <kenvandine> jono, no...
[16:27] <pitti> good night everyone!
[16:27] <seb128> 'night pitti
[16:27] <jono> kenvandine, it is segfaulting
[16:27] <jono> it loads fine but when I click the Mentions icon it segfaults
[16:27] <kenvandine> well wtf
[16:27] <BigWhale> kenvandine, quickly, blame it on the GI! ;)
[16:28] <kenvandine> it hasn't changed...
[16:28] <kenvandine> jono i just reproduced it
[16:28]  * kenvandine hasn't run gwibber in a couple days :)
[16:28] <dobey> isn't the UI in vala anyway, which doesn't use the GI typelibs? :)
[16:28] <kenvandine> dobey, it is fun to blame GI :)
[16:28] <seb128> kenvandine, gtk changed (cf mvo's issues with a gtkimage in s-c) and could perhaps be the gtkspell transition?
[16:29] <kenvandine> probably gtkimage
 seb128: I get a *segfault* from GtkImage.set_from_pixbuf(pb) currently, this used to work before my upgrade this morning
[16:29] <seb128> kenvandine, ^
[16:29] <seb128> kenvandine, same thing?
[16:29] <didrocks> good night pitti :)
[16:29] <kenvandine> likely
[16:29] <dobey> kenvandine: well, if it was in python, i could see it being GI's fault
[16:29] <dobey> anywya, must get food
[16:29] <seb128> kenvandine, ok, "great" :p
[16:29] <seb128> kenvandine, will if you confirm or get a small testcase let me know
[16:30] <kenvandine> stacktrace shows it is gtk_image_set_from_pixbuf
[16:31] <seb128> \o/
[16:31] <seb128> we have a winner: gtk
[16:31] <seb128> well at least it's not pygobject to debug
[16:31] <kenvandine> indeed
[16:34] <kenvandine> http://paste.ubuntu.com/793902/
[16:34] <kenvandine> seb128, ^^
[16:35] <seb128> thanks
[16:35] <kenvandine> looks like that refactoring was it
[16:35]  * kenvandine goes to get more coffee
[16:38] <seb128> kenvandine, right, http://git.gnome.org/browse/gtk+/commit/gtk/gtkimage.c?id=f085dde830d72b8cd0c804593631a944e9dbf45d
[16:39] <mterry_> kenvandine, btw, I updated that deja-dup branch
[16:41] <kenvandine> mterry_, saw it, i will get to it real soon :)
[16:41]  * kenvandine is fighting with LP atm :(
[16:41] <mterry_> kenvandine, no worries, it's not urgent  :)
[16:45] <kenvandine> mterry_, i tried running the tests last night and everything was failing, but didn't have time to figure out why
[16:45] <mterry_> kenvandine, the "make test" tests?  yeah, ldtp is broken right now.  But this branch's test is part of the new "make check" suite which doesn't use ldtp, and is thus 10000 times as robust
[16:47] <kenvandine> mterry_, so i shouldn't use make test?
[16:47] <kenvandine> every test fails :)
[16:47] <mterry_> kenvandine, um, certainly not right now.  And not for this branch, since "make check" will test the new thing
[16:48] <mterry_> kenvandine, in future, I'd still like it to be part of the distro acceptance tests and all that.  It's good integration testing.  But ldtp in precise is broken (fixed upstream)
[16:48] <kenvandine> ok, so i should use make check?
[16:49] <mterry_> kenvandine, yeah
[16:49] <kenvandine> ** WARNING **: common.vala:153: Success didn't match; expected 1, got 0
[16:49] <kenvandine> anyway to get more verbose output?
[16:49] <mterry_> yeah, setting DEJA_DUP_DEBUG=1 and passing --verbose will both give you more info
[16:50]  * mterry_ ran make check fine...
[16:50] <bil21al> kenvandine: hello here is a bug for you which is affecting many peoples have a look
[16:50] <bil21al> https://bugs.launchpad.net/empathy/+bug/902430
[16:51] <ubot2`> bil21al: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/902430)
[16:51] <BigWhale> dobey, I owe you a beer. Remind me on the next UDS I manage to attend. :))
[16:51] <kenvandine> mterry_, /backup/bad_hostname is what is failing
[16:52] <mterry_> kenvandine, that's not even a part of that branch.  Let me make a fresh checkout and try again.  maybe I've done something locally that isn't represented in trunk
[16:52] <kenvandine> yeah
[16:56] <didrocks> mterry_: hey, btw, I'm not sure anymore of my deja-dup encryption password. I don't find any token in seahorse, where are you storing this valuable info? :)
[16:58] <mterry_> didrocks, I send it plaintext to the NSA now.   Seemed simpler
[16:58] <mterry_> didrocks, naw, in seahorse
[16:58] <didrocks> mterry_: ah, it's why I've been contacted! :)
[16:59] <didrocks> mterry_: what should I look at ?
[16:59] <kenvandine> bil21al, weird crash, it is failing to spawn empathy-accounts?
[17:01] <kenvandine> the crash is coming from g_spawn_async_with_pipes()
[17:02] <mterry_> didrocks, "Déjà Dup backup passphrase"
[17:02] <mterry_> kenvandine, ah, I know that one
[17:03] <mterry_> kenvandine, fixed it yesterday in glib
[17:03] <didrocks> mterry_: but but, doctor, I have none! That means that my data are not encrypted? (I was sure to choose the option)
[17:03] <mterry_> let me get a bug link
[17:03] <kenvandine> mterry_, cool, thx!
[17:03] <didrocks> not that i don't trust my own server 2m30 from me :)
[17:03] <mterry_> kenvandine, bug 901388 (with upstream link)
[17:03] <ubot2`> Launchpad bug 901388 in glib2.0 "deja-dup-monitor crashed with SIGSEGV in child_setup(), g_spawn_async_with_pipes()" [Medium,Confirmed] https://launchpad.net/bugs/901388
[17:05] <mterry_> didrocks, um, either it's not encrypted or you didn't choose to have deja-dup remember your password
[17:05] <mterry_> didrocks, check the files in the backup location.  Do they end in ".gz" or ".gpg" ?
[17:07] <didrocks> mterry_: they end up with .gpg
[17:07] <didrocks> mterry_: and deja-dup continue backuping everyday
[17:07] <kenvandine> bil21al, i marked both our bug and the upstream as dupes of the one mterry_ mentioned
[17:08] <didrocks> so it should have the key somewhere :)
[17:09] <mterry_> didrocks, seahorse is the only place DD checks...
[17:09] <mterry_> didrocks, you sure you don't have two keyrings, one of which you have to unlock first to see its entries in seahorse?
[17:11] <didrocks> mterry_: hum, I don't from what I know, I need to go (giving an ubuntu conference tonight), let's see that together at the rally, shall we?
[17:11] <mterry_> didrocks, sure
[17:11] <didrocks> good night everyone!
[17:11] <mterry_> gn!
[17:11] <kenvandine> mterry_, so i dropped the bad_hostname test to get further, but now it fails at the next test
[17:11] <kenvandine> ** WARNING **: common.vala:119: Mockscript file still exists
[17:12] <mterry_> :-/
[17:12] <kenvandine> is that a file that might be left around?
[17:12] <kenvandine> where would it be?
[17:12] <kenvandine> maybe the failure didn't cleanup or something
[17:12] <mterry_> kenvandine, that means that the mock duplicity program didn't process all the instructions the test told it too
[17:12] <mterry_> kenvandine, that's a legit test failure.  Which I'm not getting.   Hold on, still trying to clean room a test run
[17:12] <kenvandine> ok
[17:19] <kenvandine> dobey, you still need libubuntuone and ubuntuone-installer sponsored right?
[17:21] <dobey> did seb do them?
[17:21] <dobey> kenvandine: i do, and ubuntuone-client-gnome it looks like as well
[17:21] <dobey> BigWhale: heh
[17:23] <kenvandine> dobey, seb128 sponsored that one this morning
[17:23] <kenvandine> seb128, have you looked at the others yet?
[17:24] <dobey> oh, ok; i haven't gotten the e-mail from launchpad on it
[17:24]  * kenvandine double checks
[17:25] <dobey> ah it was uploaded, ok
[17:25] <kenvandine> yup :)
[17:25] <dobey> so just those other 2 then
[17:26] <kenvandine> dobey, ok... let me just make sure seb128 isn't already working on them
[17:26] <seb128> kenvandine, I'm not, I stopped after the first one because it was specifically assigned to you and not in the queue
[17:26] <seb128> so I wanted to check if there is a reason
[17:26] <seb128> but I can do them if you want
[17:26] <kenvandine> seb128, ok, i'll do them
[17:28] <seb128> kenvandine, ok, thanks
[17:36] <BigWhale> It stopped working ... *bursts into tears*
[17:57] <kenvandine> Riddell, any plans to update qt4 to 4.8 in precise?
[18:03] <mterry_> kenvandine, can *you* try a fresh checkout?  Works for me here..
[18:03] <kenvandine> sure
[18:11] <Riddell> kenvandine: yes if only kde would stop making releases so I would have some time.  it's all ready in bzr I just need to test build and upload
[18:11] <Riddell> kenvandine: but I think the xinput stuff is remove for now until ported to 4.8
[18:11] <kenvandine> Riddell, cool... includes a bug fix i need :)
[18:12] <Riddell> hopefully tomorrow else monday (when you'll all be busy in the spa anyway)
[18:13] <kenvandine> hehe
[18:19] <chrisccoulson> if i cancel a PPA build that's in progress, will i get to see the build log?
[18:20] <chrisccoulson> i don't want to wait for https://launchpad.net/~chrisccoulson/+archive/mozilla-test/+build/3070682 to finish, as it's already gone past the bit i'm interested in
[18:20] <chrisccoulson> but i don't want to lose the log if i cancel it :)
[18:22] <seb128> chrisccoulson, try asking lamont or somebody from #is
[18:36] <seb128> kenvandine, mvo: what do you do with those gtkimages?
[18:37] <seb128> they are new GtkImages from files,pixbuf,stock icons...?
[18:37] <seb128> or things you free, reuse, reassing?
[18:37] <kenvandine> free and reuse i think
[18:42] <dobey> uh, no you don't free/reuse GtkImage
[18:43] <dobey> seb128, kenvandine: what are you doing with GtkImage that you would want to free/reuse it?
[18:44] <seb128> dobey, I don't want to do anything, i'm trying to debug why s-c tests and gwibber segfault with the new gtk
[18:44] <kenvandine> dobey i think it is where we display the avatars
[18:44] <seb128> dobey, trying to write a testcase, but a simple use of gtk_image_set_from_pixbuf() has no issue
[18:44] <dobey> seb128: oh; backtrace?
[18:44] <kenvandine> and the tile widgets (parent of the gtk_image) is reused
[18:44] <seb128> so it's something they do
[18:44] <seb128> dobey, http://paste.ubuntu.com/793902/
[18:45] <dobey> oh, hrmm
[18:45] <seb128> basically gtk has
[18:45] <seb128> gtk_image_set_from_pixbuf (GtkImage  *image,
[18:45] <seb128> ...
[18:45] <seb128> gtk_image_clear (image);
[18:46] <seb128> hum, I'm getting confused
[18:46] <seb128> valgrind says
[18:46] <seb128> ==19905==    by 0x5A202C4: gtk_image_get_storage_type (gtkimage.c:981)
[18:46] <seb128> ==19905==    by 0x5A20AE8: gtk_image_clear (gtkimage.c:1336)
[18:46] <seb128> ==19905==    by 0x5A216D2: gtk_image_set_from_pixbuf (gtkimage.c:764)
[18:47] <seb128> gtk_image_reset (GtkImage *image)
[18:47] <seb128> ...
[18:47] <seb128>   storage_type = gtk_image_get_storage_type (image);
[18:47] <seb128> that's where it segfaults for s-c and image->priv is NULL
[18:48] <seb128> somehow gtk_image_clear is called on a already cleared icon it seems?
[18:48] <dobey> ugh, it's taking 2x as long to scp this iso to a laptop, than it did to download it to my workstation across the vast expanse of the internet
[18:49] <dobey> seb128: well that shouldn't matter; you can create an empty GtkImage, then call set_from_pixbuf on it just fine
[18:50] <seb128> how do you create an empty image?
[18:50] <dobey> image = gtk_image_new();
[18:51] <seb128> hum
[18:51] <mvo> seb128: I load_icon() to get a pixbuf and later use gtk_image_set_from_pixbuf(pb) two times with the same pixbuf from the icon-cache, I created a test-case, but that does not segfault :/
[18:51] <seb128> the stacktrace is gtk_image_set_from_pixbuf() -> gtk_image_clear() -> gtk_image_get_storage_type()
[18:51] <mvo> but my real app does
[18:52] <seb128> where the get_storage_type tries to read image->private->something with image->private == NULL
[18:52] <dobey> is there a bug filed with a full stack trace that got retraced by apport?
[18:52] <seb128> not yet
[18:52] <seb128> but s-c it's an issue in a testcase
[18:52] <seb128> gwibber is vala
[18:52] <dobey> right
[18:52] <dobey> well, gwibber would be fine
[18:53] <seb128> bug #911619
[18:53] <dobey> i can figure out the generated C in my head easily enough
[18:53] <seb128> bug #911910
[18:53] <dobey> slow bot eh
[18:53] <seb128> bug #911619
[18:54] <seb128> dobey, they were private, I opened that one
[18:54] <seb128> dobey, https://launchpadlibrarian.net/89034243/Stacktrace.txt
[18:54] <seb128> ok, need to go for dinner but I will be back in a bit
[18:54] <dobey> oh right
[18:55] <kenvandine> mterry_, i get the same failure with a fresh checkout of trunk
[18:55] <kenvandine> without merging that branch
[18:55] <dobey> looks like memory corruption probably
[18:55]  * kenvandine needs to eat... bbiab
[18:57] <kenvandine> mterry_, fresh checkout, ./autogen.sh && make && make -C tests check
[19:04] <chrisccoulson> does dbus-launch connect to X?
[19:04] <dobey> apparently yes
[19:04] <chrisccoulson> ah
[19:04] <kenvandine> yes
[19:04] <kenvandine> annoying
[19:04] <chrisccoulson> that's why my firefox tests are failing!
[19:05] <chrisccoulson> something is triggering a bazillion or so session buses
[19:05] <dobey> ugh, something is using dbus-launch?
[19:05] <chrisccoulson> dobey, yeah, i think gdbus actually calls dbus-launch if there isn't a bus?
[19:05] <chrisccoulson> clearly  i need to run my tests inside dbus-launch
[19:05] <dobey> ah , yes it does
[19:06] <dobey> no you don't
[19:06] <dobey> you need to create your own session bus and kill it when done
[19:06] <dobey> i'm not sure how that dbus-test-runner deals with it
[19:07] <dobey> chrisccoulson: also, you want to have any code that talks to the system bus, talk to your "fake" session bus instead
[19:09] <chrisccoulson> dobey, thanks. i'll have a play around and see if i can get it to work properly :)
[19:10] <dobey> chrisccoulson: i'm not sure what you're testing exactly, but if the dbus using tests are in a python unit test structure, you probably want to use ubuntuone-dev-tools for them; otherwise you probably want to use ted's dbus-test-runner thing
[19:11] <kenvandine> dbus-test-runner is pretty useful
[19:12] <chrisccoulson> dobey, it's actually firefox xpcshell tests. some of the tests spawn a content process (ie, basically firefox) to test all the IPC bits, and there is something in there which uses dbus (although, we're not specifically testing that)
[19:15] <dobey> ah
[19:15] <chrisccoulson> i guess there's plenty of things in the platform that use a session bus (eg, gio)
[19:16] <dobey> yeah
[19:28] <seb128> dobey, no sure it's a corruption, the same codes worked before the gtk update
[19:28] <seb128> codes: gwibber and s-c
[19:29] <dobey> hmm
[19:30] <kenvandine> that refactoring was exactly the same code path
[19:30] <seb128> mvo, I blame your code, I can't get a testcase to have issues :p
[19:30] <seb128> kenvandine, same for you :p
[19:30] <kenvandine> :)
[19:30] <dobey> what is the new version of gtk that got uploaded?
[19:30] <seb128> dobey, 3.3.4 to 3.3.6
[19:30] <kenvandine> dobey, http://git.gnome.org/browse/gtk+/commit/gtk/gtkimage.c?id=f085dde830d72b8cd0c804593631a944e9dbf45d
[19:31] <kenvandine> that is the commit that looks suspicious
[19:31] <seb128> the helper which got added in http://git.gnome.org/browse/gtk+/commit/?id=b5d8d2c4a8cf2255cd16ba4e33365cc61c39a164
[19:31] <dobey> ooh, yes
[19:32] <kenvandine> wow it is going to be a pita to get rid of the gtk deprecations in gwibber now
[19:32] <kenvandine> so many hbox and vbox
[19:32] <kenvandine> might be a good project for the plane :)
[19:33] <seb128> kenvandine, don't be lazy and don't replace them by gtk_box, go for gtkgrid ;-)
[19:33] <kenvandine> we'll see :)
[19:34] <kenvandine> number of args changed and i have to call set_homogenous on all of them
[19:34] <dobey> you are so lucky
[19:34] <kenvandine> might not be much different to go with gtk_grid
[19:34] <kenvandine> i haven't looked at that
[19:34] <dobey> you don't have to keep new gwibber working on lucid.
[19:34] <kenvandine> dobey, indeed :)
[19:35]  * kenvandine merges the pygi tests for gwibber... feels good!
[19:35] <kenvandine> gwibber now has equal test coverage for python and vala :)
[19:36] <kenvandine> which still has a long way to go... but at least we can ensure that everything works with python and vala going forward
[19:36] <BigWhale> I'm starting to get desperate, I've posted a question on askubuntu ... :>
[19:36] <BigWhale> kenvandine, congratz!
[19:37] <kenvandine> BigWhale, feel free to write some tests :)
[19:38] <BigWhale> kenvandine, Now I'm working on getting Kazam into 12.04 :)
[19:39] <kenvandine> make sure you have lots of tests :)
[19:39] <BigWhale> now there are none... :/ is this now a requirement? or just a recommendation?
[19:41] <kenvandine> a very strong recommendation
[19:41] <kenvandine> we are all about testing now :)
[19:42] <seb128> kenvandine, mvo: I can't get gtk_image to run into issues in test cases, dunno about your issues, a testcase would help for sure
[19:42] <dobey> man, oneiric live dvd is slow
[19:42] <kenvandine> seb128, post your test case and i'll try to make it break :)
[19:43] <seb128> kenvandine, well my testcase is a stupid one, it's basically
[19:43] <seb128> 	pixbuf = gdk_pixbuf_new_from_file(argv[1], &err);
[19:43] <seb128> 	display->myImage = gtk_image_new ();
[19:43] <seb128>     gtk_image_clear(display->myImage);
[19:43] <seb128> 	gtk_image_set_from_pixbuf(display->myImage, pixbuf);
[19:44] <kenvandine> i am not using new_from_file
[19:44] <seb128> well ignore the display structure, I reused some other code as a base
[19:44] <seb128> kenvandine, what do you use?
[19:44] <kenvandine> stream i think
[19:44]  * kenvandine checks
[19:44] <seb128> kenvandine, well it's the pixbuf which is built from file, the issue is with gtk_image_set_from_pixbuf() from what mvo and you said
[19:44] <kenvandine> yeah
[19:45] <seb128> so I don't think how we get the pixbuf matters
[19:45] <kenvandine> just saying that is the only thing that stood out as different
[19:45] <seb128> especially that the segfault happens because priv->image (i.e the GtkImage) is NULL
[19:45] <seb128> ups, image->priv I mean
[19:47] <seb128> ie. the GtkImage seems uninitialized, which leads to a segfault when gtk_image_set_from_pixbuf() checks the storage type
[19:48] <mvo> seb128: that sounds plausible \o/
[19:48] <seb128> kenvandine, mvo: do you guys reset the GtkImage your own way or something?
[19:48] <mvo> no, but GI might
[19:48] <seb128> like try to set the pointer to NULL or something
[19:48] <mvo> ohhh
[19:48] <kenvandine> i think i do set it to NULL
[19:49] <mvo> I don't, but I'm sure its Gtk.Image() vs Gtk.Image.new() again
[19:49] <seb128> ok
[19:49] <kenvandine> yeah, i only create a new one when the tile is created
[19:50] <kenvandine> and i set it to null when i change the data in the tile
[19:50] <seb128> ok
[19:50] <dobey> mvo: that's definitely not the issue for gwibber at least
[19:50] <dobey> kenvandine: you set the GtkImage to NULL?
[19:51] <mvo> hrm, no its not the issue for me either
[19:51] <mvo> I don't do anything fance with it in python afaict
[19:51] <mvo> I just tested .new() vs () but same behavior
[19:51] <dobey> mvo: can you give me a URL to the code?
[19:52] <kenvandine> oh, no i don't set that to null
[19:52] <mvo> dobey: sure, bzr get lp:software-center; cd softwarecenter/test; python gtk3/test_views.py" should make it crash
[19:52] <kenvandine> i set_from_icon_name on each re-use of the tile
[19:52] <kenvandine> then after the pixbuf is loaded i set the gtk.image to use it
[19:53] <kenvandine> looks like behind the scenes gtk is doing a reset on it in the process
[19:54] <kenvandine> seb128, try that in your test case
[19:54] <kenvandine> cicon.set_from_icon_name ("stock_person", Gtk.IconSize.DIALOG);
[19:54] <kenvandine> then set_from_pixbuf
[19:54] <kenvandine> well that is vala, but you know what i mean :)
[19:55] <dobey> mvo: which test crashes? all of them?
[19:56] <seb128> kenvandine, tried that
[19:56] <seb128> 	image = gtk_image_new ();
[19:56] <seb128>     gtk_image_set_from_icon_name (image, "stock_left", 32);
[19:56] <seb128> 	gtk_image_set_from_pixbuf(image, pixbuf);
[19:56] <seb128> still no segfault or error
[19:57] <mvo> dobey: its test_appdetails I think, but it does not crash when run isolated, just when run with the other tests (which is odd in itself). the actual line that crashes is appdetails.py:1185
[19:57] <mvo> dobey: self.icon.set_from_pixbuf(pb)
[19:58] <mvo> *urgh*
[19:58] <mvo> hold on a sec
[19:59] <mvo> aha, no, its a 96px totem icon
[19:59] <mvo> it gets it two times, then crashes when it sets it the second time
[20:03] <dobey> hmm; the software-center code looks odd, but i don't see why it would cause that crash
[20:03] <dobey> mvo: and the app itself doesn't crash, only the tests?
[20:06] <mvo> dobey: that is actually a good question, I can't make it crash by using the app itself
[20:06] <mvo> dobey: from clicking around a bit
[20:06] <mvo> dobey: I mean, trying to do the same stuff that the test is doing does not crash it
[20:07] <seb128> race?
[20:07] <dobey> well in s-c case, it sounds like an isolation issue in tests
[20:08] <dobey> perhaps creating a race condition where the object gets destroyed in the middle of setting the icon
[20:08] <dobey> which would make sense
[20:08]  * mvo looks at this
[20:08] <dobey> since the tests seem to want to do asynchronous things, but doesn't synchronize and block
[20:11] <dobey> i'm not even quite sure how those tests never had any problems :)
[20:11] <dobey> oh, i see
[20:14] <dobey> seb128, mvo: yeah, i'd say it's a race, and you got lucky before, with it
[20:15] <mvo> dobey: thanks for your help, I will keep searching tomorrow, its getting late in my timezone
[20:15] <seb128> dobey, race between what and what?
[20:16] <dobey> seb128: well, the test adds a 300ms timeout which destroys the window (which would in turn, destroy everything in it)
[20:17] <mvo> I will set that to 3000 tomorrow to see if its that or something else
[20:17] <seb128> mvo, have a good evening
[20:17]  * mvo waves and vanishes for the night
[20:17] <seb128> let's resume that tomorrow
[20:17] <mvo> yeah
[20:17] <dobey> night mvo
[20:18] <mvo> night!
[20:18] <dobey> those tests are not very good unit tests indeed; they are like testing your icepick works, by standing on a frozen lake with a thin sheet of ice, and slamming it down between your feet :)
[20:19] <seb128> lol
[20:19] <seb128> kenvandine, well, if the tests are buggy it let you on your own for gwibber with likely a bug in gwibber
[20:19] <dobey> i'd say there is probably a similar race in gwibber
[20:20] <seb128> what I don't get is that if that's an use after free, why didn't it segfault before?
[20:20] <kenvandine> i confirmed the crash isn't in gtk 3.3.4 with current gwibber
[20:20] <dobey> but i don't know where exactly that code is at in gwibber so i can't look at it in see
[20:20] <seb128> oh, and why isn't valgrind catching that it has been freed?
[20:20] <kenvandine> stream-view-tile.vala
[20:21] <dobey> seb128: that code didn't exist before, so it couldn't segfault
[20:21] <dobey> seb128: before, there was no NULL pointer to try and poke at
[20:21] <seb128> dobey, right, but it's still an use of object after free
[20:22] <dobey> seb128: i don't think so. you don't free ints :)
[20:22] <dobey> and if pixbuf was null before, it would just set it anew
[20:22] <dobey> plus, the code change probably introduced timing changes
[20:22] <seb128> hum, right
[20:23] <dobey> which could exacerbate a race condition
[20:24] <dobey> heh, and indeed
[20:24] <kenvandine> oh interesting
[20:24] <seb128> kenvandine, I've been tested with http://pastebin.ubuntu.com/794167/
[20:24] <seb128> if you want a C trivial base
[20:24] <dobey> gwibber is doing async vala
[20:24] <kenvandine> in gwibber, it is only segfaulting in a place where it is setting the Gtk.Image back to the original image
[20:24] <seb128> but I don't think it's going to be very useful
[20:25] <seb128> kenvandine, "back to the orginal image"?
[20:26] <dobey> so i am even more inclined to suggest this is a race in gwibber as well
[20:27] <kenvandine> oh, nm it happens either way
[20:27] <kenvandine> i have a try/except in there
[20:27] <kenvandine> it tries to set it with set_from_pixbuf
[20:27] <kenvandine> if that fails it sets it with set_from_icon_name
[20:27] <kenvandine> i am getting the crash in both
[20:27] <dobey> well, assuming it doesn't segfault :)
[20:30] <kenvandine> #0  _gtk_icon_helper_get_storage_type (self=0x0) at /build/buildd/gtk+3.0-3.3.6/./gtk/gtkiconhelper.c:482
[20:30] <kenvandine> #1  0x00007ffff7899335 in gtk_image_reset (image=0x1ce5110) at /build/buildd/gtk+3.0-3.3.6/./gtk/gtkimage.c:1336
[20:30] <kenvandine> #2  gtk_image_clear (image=0x1ce5110) at /build/buildd/gtk+3.0-3.3.6/./gtk/gtkimage.c:1392
[20:30] <kenvandine> it isn't null in gtk_image_reset
[20:30] <kenvandine> but it is null in _gtk_icon_helper_get_storage_type
[20:30] <dobey> kenvandine: i think the problem is that the variable is going out of scope, while you're inside the async method
[20:30] <kenvandine> perhaps
[20:31] <dobey> kenvandine: self=0x0 isn't the GtkImage
[20:31] <kenvandine> for gwibber it is very consistent
[20:31] <kenvandine> oh it isn't?
[20:31] <dobey> kenvandine: it's the GtkIconHelper
[20:31] <kenvandine> ah
[20:31] <dobey> which becomes NULL before the GtkImage that contains it :)
[20:31] <seb128> I wonder what makes the helper being NULL
[20:32] <dobey> the image is getting destroyed
[20:32] <kenvandine> it's clearly happening in gtk, i don't think i can work around it in gwibber
[20:32] <dobey> at least, afaict, that's the only way this crash can happen
[20:33] <seb128> or something in gtk reset it
[20:33] <dobey> is if the image gets destroyed *while* a call to set_from_whatever is happening
[20:33] <seb128> like when doing gtk_image_clear or something
[20:33] <dobey> image_clear doesn't destroy the icon helper though
[20:33] <seb128> kenvandine, you are sure you don't access the image after having its ref to 0?
[20:34] <kenvandine> yes
[20:34] <dobey> well he can't
[20:34] <dobey> otherwise it would crash earlier :)
[20:34] <seb128> dobey, right, that's what I'm trying to do, figure what reset the helper
[20:34] <seb128> it's not gtk_image_clear indeed
[20:34] <seb128> but something must be doing it ;-)
[20:34] <kenvandine> the crash happens when i change the image
[20:34] <mterry_> What's the state of metacity in Ubuntu now?  I see it's on the manifest, what does it get used for?
[20:34] <dobey> afaict, the variable he's using for the icon, is going out of scope
[20:34] <dobey> and vala destroys it
[20:34] <kenvandine> mterry_, unity-2d
[20:35] <mterry_> kenvandine, hrm
[20:36] <mterry_> kenvandine, still no idea why make check fails for you, btw
[20:36] <mterry_> kenvandine, maybe can look at this at the rally
[20:36] <kenvandine> mterry_, i tried in a pristine VM too
[20:36] <kenvandine> so not just my machine :)
[20:36] <seb128> dobey, "he's using", who is he? gwibber or gtk?
[20:36] <mterry_> kenvandine, pristine precise VM?  maybe I'll try that
[20:36] <kenvandine> mterry_, yeah
[20:36] <kenvandine> fresh install from monday
[20:36] <kenvandine> so pretty clean
[20:37] <dobey> seb128: kenvandine
[20:37] <dobey> seb128: so gwibber
[20:37] <chrisccoulson> gah, 44 minute wait for my build
[20:37] <seb128> ok
[20:37] <seb128> chrisccoulson, get a beer and some dinner ;-)
[20:37] <dobey> gtk isn't written in vala and doesn't automagic dereference stuff :)
[20:37] <kenvandine> dobey, so maybe vala
[20:38] <chrisccoulson> and only one of the current PPA builds is mine!
[20:38] <chrisccoulson> i'm shocked ;)
[20:38] <kenvandine> maybe i need to do a destroy and new each time i want to use it?
[20:38] <kenvandine> re-using these tiles is a pita
[20:38] <chrisccoulson> oh
[20:38] <chrisccoulson> 2, actually
[20:38] <kenvandine> i really need to ditch that in the smooth scrolling branch ;-)
[20:39] <dobey> kenvandine: i think it's your code that is just broken :)
[20:39] <kenvandine> worked fine before :)
[20:39] <kenvandine> doesn't mean it isn't broken :)
[20:39] <dobey> kenvandine: no, and i am seeing some other bad code in this file :)
[20:39] <kenvandine> there is lots of uglyness
[20:40] <dobey> no you don't need to destroy/new each time
[20:40] <dobey> private = new Gtk.Image.from_icon_name ("status_lock", Gtk.IconSize.MENU);
[20:40] <kenvandine> mostly with to make reuse of the tile widget work
[20:40] <dobey> yeah; private is a reserved word. i'm surprised vala doesn't error on that one
[20:40] <kenvandine> oh... whoops :)
[20:40] <kenvandine> that isn't related though
[20:41] <dobey> all you need to do to re-use a widget is maintain a reference to it somewhere
[20:41] <kenvandine> lines 770 and 780 is where the crashes are
[20:41] <dobey> right
[20:41] <dobey> but it isn't necessarily where the problem is
[20:41] <kenvandine> right
[20:43] <seb128> kenvandine, well, it could be gtk which is buggy but we didn't get other bugs about that yet and other stuff use pixbuf, so it's not obvious bug in normal use...
[20:43] <dobey> i'm pretty sure this is a gwibber bug
[20:43] <dobey> and this code is looking more complex than it probably need be
[20:44] <dobey> which doesn't help trying to debug it :)
[20:48] <kenvandine> dobey, if i comment out the setting of the image in load_avatar_async it doesn't crash, which helps prove it is the async crap triggering it
[20:48] <kenvandine> it still resets the image on every tile change, and that doesn't crash it
[20:49] <kenvandine> maybe a tile is getting reset before an async operation is finished
[20:49] <kenvandine> and it isn't getting cancelled
[20:50] <kenvandine> not sure why the gtk change would expose a bug like that... you would think it would have been crashing all along
[20:50] <seb128> well as dobey said nothing what trying to access the structure of the object before
[20:50] <kenvandine> true
[20:51] <dobey> right, it's different code which exposes a problem, and gtk+ itself doesn't know to cancel your async call
[20:51] <seb128> gtk_image_clear does try to access the storage type in the new code
[20:51] <kenvandine> we keep track of those and remove them on resetting the tile
[20:52] <BigWhale> Can someone please run this code on Pangolin and tell me if main window is transparent: http://pastebin.com/04ayrNrv
[20:52] <kenvandine> we iterate over all the pending jobs and remove them
[20:53] <seb128> BigWhale, no, it's grey
[20:53] <BigWhale> seb128, thanks...
[20:53] <BigWhale> altho, I don't like the anwers :>
[20:57] <kenvandine> dobey, oh... we aren't actually cancelling the async operation
[20:57] <dobey> kenvandine: right
[20:57] <kenvandine> on resetting the tile we should probably call cancellable.cancel ()
[20:58] <dobey> probably
[20:58] <dobey> though i don't know if it will solve the crash
[21:00] <kenvandine> dobey, it seems too
[21:01] <kenvandine> that and removing line 780
[21:01] <kenvandine> which is redundant anyway
[21:01] <kenvandine> that would reset it when it gets cancelled
[21:01] <dobey> cool
[21:02] <kenvandine> i am pretty surprised this didn't cause a problem before
[21:03] <kenvandine> even though nothing tried using that... i would think it would in gwibber
[21:03]  * kenvandine uploads distro patch :)
[21:04] <seb128> kenvandine, \o/
[21:16] <dobey> kenvandine: well, everything was ints before; so it probably wouldn't have crashed, but i am surprised that /something/ didn't at least look weird
[21:16] <kenvandine> dobey, right
[21:16] <kenvandine> dobey, mind doing a quick merge proposal review for me?
[21:16] <chrisccoulson> i though that if "2 finger scrolling" was enabled in the touchpad settings of control center, that it should fall back to "edge scrolling" if the touchpad doesn't support it?
[21:16] <dobey> kenvandine: url?
[21:17] <chrisccoulson> at least, that's what used to happen, seeing as we set 2-finger scrolling by default
[21:17] <seb128> chrisccoulson, seems like a question for cnd
[21:17] <kenvandine> https://code.launchpad.net/~ken-vandine/gwibber/cancel_async_ops/+merge/87680
[21:17] <kenvandine> dobey, thx
[21:18] <chrisccoulson> seb128, thanks
[21:23] <dobey> kenvandine: done
[21:29] <kenvandine> dobey, thx
[21:29] <dobey> sure :)
[21:29] <kenvandine> the debug message caused tons of noise and was useless
[21:29] <kenvandine> i should have just removed it :)
[21:30] <kenvandine> it cancels on every position change
[21:31] <dobey> remove it then :P
[22:06] <RAOF> pitti: colord is dbus-activated; cupsd is what pulls it up at boot.  Failing that, the color plugin of gnome-settings-daemon would pull it up during login.
[23:30] <BigWhale> ZOMG! It works!
[23:49] <broder> cyphermox: do you have any plans for an oneiric NM sru any time soon? bug #882432 seems like a good candidate for one
[23:49] <ubot2`> Launchpad bug 882432 in network-manager "network-manager crashes when trying to configure 802.1x TLS network" [Undecided,Confirmed] https://launchpad.net/bugs/882432
[23:49] <broder> (i'm already patching in the fix for my use case, so i don't need the sru, but i'm also happy to put one together if you're interested)
[23:50] <RAOF> Aah, sweet hybrid graphics.  Nothing prevents the entirely unconnected radeon card from claiming fb0 :)
[23:55] <TheMuso> RAOF: Let me guess! You cannot turn hybrid graphics off for the machine in question.
[23:56] <chrisccoulson> bryce, fixed http://bazaar.launchpad.net/~mozillateam/firefox/firefox-trunk.head/revision/1091 ;)
[23:56] <chrisccoulson> (i figured out where all those connections were going)
[23:56] <RAOF> TheMuso: I can, but not in the bios.  vga_switcheroo works once everything's up, and X (mysteriously) always comes up on the intel.
[23:56] <TheMuso> Right.
[23:57] <RAOF> Oh, hah.  Not mysteriously at all.
[23:57] <RAOF> The intel is the bios-set primary.
[23:57] <TheMuso> Ah.
[23:57] <bryce> chrisccoulson, sweet
[23:57] <chrisccoulson> it was pretty simple in the end :)
[23:57] <bryce> chrisccoulson, so what turned out to be the culprit?  I saw you mentioned dbus-launcher earlier?
[23:57] <chrisccoulson> bryce, yeah, there were tonnes of them running at the point that it started to fail
[23:58] <bryce> was each test case starting one up or something?
[23:58] <chrisccoulson> bryce, probably not all, but in this particular case, we are using one display instance for around 1100 xpcshell tests
[23:58] <chrisccoulson> and each test runs in a new shell
[23:59] <chrisccoulson> so the buses just accumulate until it runs out of connections :)