[00:01] maybe it's just xchat [00:02] nope, link in empathy opened in firefox too [00:11] Sarvatt: bug 670128 [00:12] Launchpad bug 670128 in xdg-utils (Fedora) (and 4 other projects) "gnome-open uses firefox while it's not the preferred browser (affects: 2) (dups: 1) (heat: 16)" [Unknown,Unknown] https://launchpad.net/bugs/670128 [00:13] micahg: thanks a ton! [00:13] Sarvatt: np [00:36] it's all a conspiracy! [00:36] i'm just trying to make everybody use firefox really [00:36] :) [00:36] (j/k) [00:37] TheMuso: Is there someone being Ubuntu-audio this cycle, or is it just you? From memory, Daniel Chen wasn't going to be available much this cycle? I'm just patch-piloting bug #486154, and it looks like it needs a bit of system-integration. [00:37] make it talk to google encrypted sync and I'll think about switching back :) [00:37] Launchpad bug 486154 in pulseaudio (Ubuntu) (and 3 other projects) "System beep broken in Karmic despite heroic efforts to fix it (affects: 24) (dups: 1) (heat: 146)" [Undecided,Invalid] https://launchpad.net/bugs/486154 [00:38] * micahg didn't want to say anything about that chrisccoulson ;) [00:38] Sarvatt, how does it compare to firefox sync (weave)? That's totally encrypted on the server [00:38] RAOF: Unfortunately thats somewhat of a mess, as so many people have conflicting thoughts as to what should produce event sounds etc. [00:39] (ie, the data is only ever decrypted on your local machine) [00:39] and is all stored encrypted [00:39] RAOF: As for audio this cycle, well I am not entirely sure. I think rodrigo_ is helping out some, and I am spending a little time on bits and pieces here and there, usually package updates, but thats about as far as I know. [00:40] RAOF: IMO PC speaker stuff is disabled and should stay that way, and libcanberra is responsible for sound events. [00:40] chrisccoulson: I got too used to the chromium one since I was using a netbook primarily for years and needed the screen real estate and have it syncing a ton of pc's, digging around for some way to import stuff into firefox to try it out now [00:41] So the correct way to proceed would be to teach libcanberra to optionally use the PC speaker, and teach compiz to use libcanberra? [00:41] RAOF: Don't know, and don't care personally. :p but seriously, I'd say thats probably the best bet. [00:41] not being able to save certificate exceptions in chromium is annoying me enough to try switching back [00:41] The PC speaker is a gradually vanishing piece of kit. [00:42] Once more new hardware uses EFI, there will be much less need for it, so far as I know. [00:43] ...it also doesn't help that upstrea alsa also decided to implement PC speaker emulation in hda, something which I disagree with, adn we have turned off in Ubuntu anyway. [00:54] RAOF_: Do you need me to repeat what I said earlier re that bug? [01:10] TheMuso: Yeah, please. The last thing I got before everything blew up was “IMO PC speaker stuff is disabled and should stay that way, and libcanberra is responsible for sound events.” [01:10] ok [01:11] RAOF: Don't know, and don't care personally. :p but seriously, I'd say thats probably the best bet. [01:11] The PC speaker is a gradually vanishing piece of kit. [01:12] ...it also doesn't help that upstrea alsa also decided to implement PC speaker emulation in hda, something which I disagree with, adn we have turned off in Ubuntu anyway. [01:12] Heh. [01:13] It looks like we'll have (a small subset of) users who want to use the PC speaker for the forseeable future, so we should probably at least point them in the right direction :). [01:15] TheMuso, you have seen bug 642888 also? [01:15] Launchpad bug 642888 in at-spi (Ubuntu) "system bell no beep (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/642888 === RAOF_ is now known as RAOF [01:15] RAOF_: as long as they don't expect to play back their oggs through the pc speaker :) [01:16] charlie-tca: Not read it completely. [01:16] I will have a look in a while. [03:15] pitti - https://launchpad.net/ubuntu/+source/couchdb/1.0.1-0ubuntu4 \o/ [03:15] should win some space once robert updates yelp ;) [03:15] hi robert_ancell! [03:16] chrisccoulson, yay! [03:45] chrisccoulson: wooo!! [03:45] chrisccoulson: that happened fast [03:46] chrisccoulson: does that mean we have a spidermonkey package, that you've talked with the mozilla guys re abi stability, the works? [04:00] Chipaca, not yet. the current solution is purely to save space on the CD really [04:01] chrisccoulson: I've been trying to get in touch with you, but things have been a bit crazy for me. You want me to follow up on the conversation with mozilla, or can you do that? [04:01] chrisccoulson: (this is re statik's email) [04:02] i don't mind really. the only thing i'm a bit concerned about is that we might be getting confused between API and ABI stability. mozilla say they can provide API stability (which is mostly true already, except for the 1.9.2 => 2.0 transition i just did), but it is ABI stability that's the real problem [04:03] i need to do another couch upload in the morning, i just noticed a couple of oversights with the port :( [04:03] it's been a pain to port it, because none of the API changes seem to be documented anywhere [04:03] chrisccoulson: right [04:04] chrisccoulson: I've just pointed the couchdb people at the bug anyway (i mean, at https://bugs.launchpad.net/bugs/681209) [04:04] Launchpad bug 681209 in couchdb (Ubuntu) "Port to Spidermonkey 2.0 (affects: 1) (heat: 8)" [Undecided,Fix released] [04:04] thanks [04:04] i need to make sure to set rsval on any native function that returns successfully. that wasn't required before, but is now [04:04] will fix that in the morning now though [04:05] according to http://web.archiveorange.com/archive/v/yxPWTYypjFr1Bkh0C9lQ [04:06] is a broken .desktop file (wrong gettext domain) worth SRUing? [04:06] hyperair, it depends if somebody wants to work on it ;) [04:06] i'd imagine so [04:07] alright [04:07] i was just wondering if i should upload =) [04:07] yeah, just do it. it seems trivial enough [04:09] okay [04:09] pitti, can you get clutter-gtk-1.0 out of the new queue? I figure it doesn't need a MIR because it's just the newer version of clutter-gtk-0.10? [04:14] chrisccoulson: does "I don't mind" mean you'll do it, or that you'd rather I did? (sorry to go back on that, but I need to be sure) [04:15] Chipaca, i'll read through the e-mail again when i get up, i'm just about to go and get some sleep now (it's 4.15am here now ;)) [04:15] maaaaaan [04:16] my brain chiming "low battery" and it's only 1.15 here [04:16] heh :) [04:16] i normally stay up late, but tonight is later than most [04:16] chrisccoulson: go! sleep! rest! I'll chase you tomorrow or day after [04:16] thanks :) [06:44] chrisccoulson, hey [07:01] Good morning [07:02] kenvandine: trouble with the new go-introspection? [07:03] chrisccoulson: cool! [07:03] robert_ancell: good morning [07:04] robert_ancell: clutter-gtk-1.0> looking [07:04] pitti, hey [07:05] robert_ancell: how are you doing? [07:05] pitti, good. I worked out how to use the bzr branch for gtk-vnc [07:06] robert_ancell: why do we version the source in the first place? we need several APIs in parallel? [07:06] good morning all [07:06] pitti, thanks a lot for getting the issue with the langpacks cronjob sorted yesterday! [07:06] hey dpm [07:06] pitti, I don't know, I just renamed it because it's not 0.10 anymore. I guess in theory they could keep supporting the old version, but it doesn't sound likely [07:07] dpm: the lucid one had another crash and needed fixing/handholding, but I started the maverick one from cron out of line, and it seems that went okay [07:07] robert_ancell: so perhaps the source should eventually just be named clutter-gtk? [07:07] pitti, well, but what do we do if they make a 2.0 series in the future and we want to keep the 1.0? [07:07] pitti, ok, thanks for letting me know [07:08] robert_ancell: isn't that true for pretty much any library? anyway, if that's more likely to happen for clutter, then it's fine [07:08] robert_ancell: looks fine to me, accepted [07:08] pitti, I don't know, I hope we'll stay 1.0 for a while :) [07:27] robert_ancell: wow, there are still upstream releases for gnome-vfs? [07:27] apparently! [07:39] Well, running around an oval in the rain was less annoying than I expected. [07:54] mvo: good morning [07:54] mvo: FYI, I collected and tagged the bugs for the performance problems with compressed indexes, and I'll disable them by default for now [07:54] good morning [07:54] mvo: it's easy enough to enable locally to work on the bugs [07:54] bonjour didrocks, ca va? [07:55] thanks pitti [07:55] Guten Morgen pitti! Yeah, very well, thanks :) and you? [07:55] (and good morning!) [07:55] mvo: but that was useful for seeing where the problems are [07:55] hey mvo ;) [07:55] hey didrocks [07:55] pitti: indeed [07:55] mvo: for synaptic and xapian-index it's pretty clear to me -- they seem to iterate through all package records, which is slower [07:56] mvo: I'm not quite sure why "Building dependency tree..." takes 1:30 hours for an UEC build, but I'll investigate that later [07:56] yeah, synaptic does it iirc to check for the support status [07:56] did you managed to reproduce it locally? [07:56] it would seem to me that building depepdency trees can be done entirely out of pkgcache.bin [07:57] mvo: the slow synaptic scrolling and slow update-apt-xapian-index, yes [07:57] I didn't try to reproduce the UEC build thingy [07:59] ok [07:59] hum, why c-f-m-p ftbfs and it compiled fine yesterday here… [08:09] chrisccoulson, micahg: do you know why firefox-branding exploded so much in size since maverick? [08:09] firefox-branding (Δ 3.0 MB - 3.6.10+build1+nobinonly-0ubuntu3: 0.2 MB 4.0~b7+nobinonly-0ubuntu3: 3.3 MB) [08:09] * micahg thought that was empty now :-/ [08:10] chrisccoulson, micahg: seems this /usr/lib/firefox-4.0b7/omni.jar is new? [08:10] oh, right [08:10] yes [08:11] pitti: the branding is now with the JavaScript files in one container to improve start time [08:11] pitti: the good news is we can drop xulrunner though as chrisccoulson created mozjs again [08:11] so it was moved from firefox? [08:12] micahg: ok, if that's deliberate, that's fine; I just wanted to make sure it wasn't accidental [08:12] \o/ [08:12] we got down from 30 to 17 MB oversized now [08:12] (i386 alternate; amd64 is worse) [08:12] pitti: yes, it's deliberate and shouldn't increase the total between the two packages much [08:12] micahg: thanks for checking [08:12] so with RAOF's mesa fix and dropping xulrunner we should just about get back into the home zone [08:13] pitti: oh, I guess it is about 3MB larger now, but I think that might be due to the new stuff in 4.0 [08:13] and for the rest, lots of package rebuilds to shrink/drop changelogs and PNGs [08:14] any chance that bug gets fixed in maverick? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/662946 [08:14] Launchpad bug 662946 in linux (Ubuntu) (and 1 other project) "linux kernel 2.6.35 slows down the whole system because of kslowdxxx processes (affects: 34) (dups: 2) (heat: 194)" [Undecided,Confirmed] [08:14] we now have unity, nux, zeitgeist, and GTK3 on the CDs, plus a couple of duplicated libraries due to ABI bumps, and two pythons, so we should be fine in the end [08:15] maverick's kernel is simply unusable here [08:15] Zdra: wrong channel, I'm afraid -- try #ubuntu-kernel? [08:15] pitti: so between dropping most of xulrunner and the increase in Firefox, there's a net savings of 4.5MB [08:15] micahg: nice! [08:15] pitti, ah, didn't know that channel, thanks :) [08:15] on i386 at least [08:16] micahg: I think we're going to get a second webkit version as a replacaement for xulrunner, which will add back ~ 5 [08:16] so overall it should be roughly even [08:16] pitti: for yelp? [08:16] micahg: right [08:17] pitti: why a second version? [08:17] micahg: I'm not sure, it was mentioned yesterday [08:35] didrocks: I'm curious: if unity is "just" a compiz plugin, and we don't have a separate session type, how do we make panel and nautilus start/not start depending on whether we're running unity? [08:35] pitti: nautilus will always be there [08:35] pitti: panel as gnome-panel registered as a required component is an issue [08:36] pitti: remember my email I forwarded to you? :) [08:36] ah, ok; I'll look into that now [08:36] nobody answered btw… :/ [08:36] pitti: basically, I have another idea of workaround [08:36] pitti: but not "ideal, flipping-less solution" [08:36] I'll implement one tomorrow for A1 in any case… [08:37] today is new compiz + new unity + fixing a lot of stuff :) === almaisan-away is now known as al-maisan [08:42] didrocks: so the main problem is that we only know very late whether we can run unity in the first place, right? [08:42] i. e. not already when gnome-session starts [08:43] didrocks: I wonder if there's some way to do "virtual" required components [08:43] i. e. unity would "provide" a panel, and so does gnome-panel [08:43] or xfce4-panel for that matter [08:45] didrocks: it seems to me that the most robust approach is to have compiz start gnome-panel if it doesn't start unity; we can't do that before or in a different place without these "start and kill" stuff, which would be a hideous waste [08:45] i. e. gnome-session would need to start gnome-panel if we don't use compiz, and compiz would start gnome-panel when needed [08:46] I'm aware that this would require some ubuntu specific hacks, but we need the hacks somewhere anyway [08:46] so we can just as well put them into the place where it would be most robust [08:46] and efficient [08:48] pitti: sorry, will get back to you in a bit, still testing unity things :) [08:49] didrocks: don't worry, take your time [08:50] didrocks: running unity now :) [08:52] (for 30 seconds, and already feeling pain) [08:54] ok back :) [08:54] pitti: so, yeah, unity is runned as the last compiz plugin, very late in the session startup [08:54] so, gnome-session has almost finished launching the panel at this point [08:55] pitti: let me see when gnome-session starts the panel, if it's before or after the windowmanager [08:56] didrocks: is there any chance we can make the "can run unity" detection much earlier? [08:56] pitti: no, there are mutiples detections, but the unity detection is only part as the unity constructor [08:56] didrocks: if we only start gnome-panel after basically everything else is ready, startup will be really slow for non-unity sessions [08:57] that was my point… [08:57] didrocks: right, I wonder if we can pull that out and stuff it into gnome-session [08:57] and we loose the autorespawn [08:57] with a design where you have 90% of your desktop already started before you even figure out what you want to start in the first place, we can only lose [08:58] totally agree [08:58] so, there is this solution of start gnome-panel and then remove it as a required component with my patch [08:58] and kill it [08:58] but it makes gnome-panel appearing every time [08:58] until unity starts [08:58] we can do that at first start [08:59] and seeing if unity start -> change the gconf key for later boot [08:59] but of course, we will have the issue of resetting that in case of driver change, blablabla… [08:59] didrocks: and starting gnome-panel is ridiculously expensive [08:59] right [09:00] IMHO we should separate the hw detection and run it very early [09:00] e. g. in gnome-wm for now [09:01] then this could start metacity, compiz and gnome-panel, or compiz --with unity [09:02] pitti: not designed and won't we designed like that, I'm afraid… [09:02] why? [09:02] it's not even alpha-1.. [09:03] dbarth: is there a particular reason why unity needs to detect the hardware caps so late in the game (what is essentially the wrong end of the desktop startup chain)? [09:05] pitti: because compiz now has a detection/bailer plugin and for instance, it's the opengl plugin which bails when it can't works [09:05] work* [09:05] same for unity [09:06] hey [09:06] salut seb128 [09:06] didrocks: ok, then I guess we need to go back to starting gnome-panel from compiz if unity plugin is not enabled [09:06] lut didrocks [09:06] ca va ? [09:06] seb128: ça va, journée chargée aujourd'hui je pense :) [09:06] which will really make startup time suck for the panel, but oh well [09:06] hey seb128 [09:07] pitti: right, but it's only if we can run compiz, but not gnome-panel [09:07] pitti, guten tag! [09:07] didrocks: so gnome-session can run panel or not depending on whether it's running compiz or not? [09:08] pitti: if we launch the "windowmanager" phase before, right [09:08] ah, right [09:08] didrocks: I guess there are only few cases where compiz works, but not unity? [09:09] pitti: yeah, it will be even less as unity will try to run in a degraded mode [09:09] but in that case, we loose the autorespawn… [09:09] and that's what annoy me :) [09:11] didrocks: [09:11] I have hacked yesterday afternoon on that, and I have a way to tell [09:11] "gnome-session, please remove this App as a required_component" through [09:11] dbus. [09:11] didrocks: does addition work as well? [09:11] then gnome-panel could register itself for autospawning at gnome-session [09:13] pitti: I think I mentionned it later in my mail, the issue is that when starting gnome-panel from the command line I couldn't set an id to it [09:13] pitti: so, it can't match with the /App property where I reset autorestart to true [09:14] and I tried hard to set an id to it :) --sm-client-id doesn't seem to work and I couldn't find enough doc about it [09:15] didrocks: I don't understand -- doesn't gnome-session provide an ID for it already? [09:15] we certainly don't need to worry about autorespawn if we start gnome-panel from the command line? [09:16] pitti: why? if it crashes and compiz doesn't? [09:16] (in fact, I'd love if it would _not_ autorespawn when I start it from a command line, but that's just me as a developer..) [09:16] pitti: no, because when you restart it, you have a new /Client on dbus [09:16] didrocks: oh, you mean "from the command line" -> "if compiz starts it"? [09:16] with an empty id [09:16] pitti: right, it's basically what I do in compiz as of today [09:17] hm, I'm afraid I don't know about the gnome-session IDs to give a hint here [09:18] didrocks: so for the general startup, we patch gnome-session to ignore gnome-panel if it runs compiz? [09:19] by way of compiz calling through that new dbus API of your's to dynamically remove stuff from required_components? [09:19] pitti: not yet, but that's basically what I did for the UNE session [09:19] (and assuming that compiz/window manager phase starts earlier than panel) [09:19] * vuntz won't enter the discussion here, but thinks this sounds completely crazy ;-) [09:19] vuntz: it is.. [09:19] vuntz: bonjour, BTW [09:19] pitti: so, we discussed with vuntz [09:19] the idea is to make some "profiles" at start [09:19] pitti: just chatted with didrocks, he'll repeat the design that is planned upstream [09:19] lut vuntz [09:19] hey :-) [09:20] vuntz: seems this is basically trying to squeeze three different session types into one.. [09:20] so, detection module as part of gnome-session [09:20] seems gnome-session is just not made to deal with that you want to do didrocks [09:20] we will either need to improve it [09:21] seb128: well, not what "I" want… just what's implemented in compiz/unity [09:21] .. or hack the heck out of it? [09:21] or to move to other system [09:21] like upstart session services handling [09:23] seb128: I try to see what we can do with the current system for natty :) [09:23] morning [09:23] didrocks, I'm not sure why we need to register gnome-panel [09:23] rodrigo_, hey [09:24] seb128: autorestart? [09:24] well, gnome-panel is not crashing a lot… [09:24] that was part of my mail [09:24] hey rodrigo_ [09:24] well, start gnome-panel for the session [09:24] and hack the .dmrc [09:24] so next login is in GNOME 2d [09:24] hum, not a bad idea… [09:24] you just don't get autorespawn for one session this way [09:24] (eww) [09:25] then, we need to hook something for users having installed nvidia proprieraty driver… [09:25] well, prop* driver :) [09:25] well make jockey change the .dmrc [09:26] pitti | (eww)² :) [09:26] seb128: you mean all of them? [09:26] for users with encrypted home directories which aren't logged in? [09:26] etc. [09:26] pitti, no, the current user one [09:27] but why bother with all this dynamic detection if we are going to have to write a static config anyway? [09:27] I think the usecase is people installing nvidia after install [09:27] so only one user will have loged in with one session [09:27] I don't think we should aim to deal with corner cases [09:27] we also have multi-graphics cards computers and laptops these days, where you can switch [09:28] ok, let's get to the basis [09:28] you want to run the autodetection at each login? [09:29] it's runned at each login right now. It's runned for years in the opengl plugin [09:29] ok [09:29] run* [09:29] so what you need is just a way to tell gnome-session "start this .desktop and respect the autorestart key" [09:30] it has the code for dealing with those, it read the autostart directory at session start [09:30] we just need an api to give him extra ones after the start from dbus [09:30] seems it should be easy to add [09:30] you would start gnome-panel this way [09:30] the same way we start the keyring and others services [09:30] vino, etc [09:31] seb128: yeah, it's a way to tell him too start a desktop file [09:31] but gnome-session would start the panel always, right? [09:31] better than the autorestart hack [09:31] rodrigo_, no, unity has its own panel [09:31] rodrigo_: right now, because of the gconf key I mentionned in my mail :) [09:31] right, I mean the upstream gnome-session [09:32] it reads things it needs to start from gconf [09:32] ok [09:32] well that an desktop files in the xdg autostart dir [09:32] didrocks, I don't see what is difficult and why you want to add required components in a dynamic way [09:33] just make compiz make that dbus call to gnome-session to run the gnome-panel autostart? [09:33] vuntz, and what are the plans for gnome-session to start gnome-shell or the 2.x session? how it's going to do that? [09:33] rodrigo_: that's the plan I told to didrocks [09:33] seb128: well, I have to see how hard or not it is to tell gnome-session "starts this desktop file" [09:33] vuntz, ah, ok, reading the backlog [09:34] vuntz, where did you tell him that? [09:34] seb128: #gnomefr [09:34] vuntz, can you copy or summarize in english there? [09:34] didrocks, ^ [09:34] or you ;-) [09:34] ah, yes, a summary please :) [09:34] I prefer to review didrocks's patch and let didrocks summarize :-) [09:34] :) [09:34] ok [09:35] vuntz, is there a way now to tell gnome-session during a session to start a service with autorespawn on? [09:35] seb128: I summarize already, isn't it? [09:35] let me backlog [09:35] didrocks, I might have joined after then [09:35] or it was in middle of unity thinking [09:35] 10:19:51 didrocks | the idea is to make some "profiles" at start [09:35] but the short story is: a profile is a .desktop file (instead of being gconf keys); it contains a key to launch a helper that helps decide if the profile ca nbe used (eg: do we have 3d?), and it can contain a fallback to another profile [09:36] 10:20:07 didrocks | so, detection module as part of gnome-session [09:36] and deciding which profile we want to choose depending on the detection module [09:36] seb128: not sure about this. Probably not, I guess. But if we do this, that'd be part of the GtkApplication stuff, I guess [09:39] so, gnome-session just spawns the helper, and if it quits with an error, it spawns the fallback? [09:39] rodrigo_: kind of [09:39] (not sure you can say "spawn the fallback" since the fallback is a profile, but yeah) [09:40] ok, so we would have three profiles [09:40] one for compiz + unity [09:40] well, right, it would spawn the helper for the fallback profile [09:40] then compiz + gnome-panel and metacity + gnome-panel (or whatever + gnome-panel) [09:40] rodrigo_: well, it would discard the current profile, and consider the fallback one [09:40] ok [09:40] not sure how that can play with people having different window manager, vuntz? ^^ [09:40] the detection code is in compiz atm though? [09:41] seb128: yes, all the detection is done in compiz, that's one of the blocker [09:41] didrocks: use gnome-wm [09:41] seb128: just tweak compiz to have some test option. Like "compiz --can-i-work-here" === al-maisan is now known as almaisan-away [09:54] hmm, http://launchpadlibrarian.net/59571483/buildlog_ubuntu-natty-i386.libubuntuone_0.3.8-0ubuntu2_FAILEDTOBUILD.txt.gz <- should I just run a 'make distclean' before doing the python builds??? [09:57] Good morning! I have some questions about bug #676972 and the procedure of things. MSN in Pidgin is currently broken because MS changed their SSL certificates. Updates have been released for natty and maverick, but older versions (ie Lucid) are still broken. Upstream released 2.7.7 to fix the issue, but not all these fixes are in the natty and maverick updates. I wonder what's the next step? [09:57] Launchpad bug 676972 in pidgin (Ubuntu Maverick) (and 2 other projects) "pidgin does not connect to msn, certificate error (affects: 43) (dups: 3) (heat: 176)" [Undecided,Fix released] https://launchpad.net/bugs/676972 === warp11 is now known as warp10 [10:03] ok [10:03] back on gsd gcc 2.32, it's better [10:05] seb128, what problems did you find on g-s-d? [10:06] it seems to not apply the same configs that the old one [10:06] gdm was on a blue and grey theme [10:06] rather than using the ubuntu one [10:06] the desktop had a weird hinting [10:06] but the gtk theme was correct at least [10:07] the new g-c-c is acting weirdly with geometry and placement handling [10:07] every time you open a panel it jumps on screen to another position, weird [10:07] New g-c-c means GNOME 3 unstable g-c-c? [10:08] yes [10:08] the one in the ppa [10:19] seb128, any idea about http://launchpadlibrarian.net/59571483/buildlog_ubuntu-natty-i386.libubuntuone_0.3.8-0ubuntu2_FAILEDTOBUILD.txt.gz <- do I really need to add a 'make distclean'?? [10:21] rodrigo_, hum, it's weird [10:21] you should not, the changelog doesn't suggest you changed anything that should trigger build issues [10:21] it is again with the 'several python versions' thing, it seems [10:22] seb128, no, changed nothing [10:22] could be yes [10:22] I was thinking the same [10:31] wow, the new evo is much quicker [10:35] seb128: rodrigo_: do one of you have a gnome3 stack to test there? [10:35] didrocks, yes [10:35] didrocks, test what? [10:35] rodrigo_: can you change the wallpaper cache patch to that (it's 02_… http://bugzilla-attachments.gnome.org/attachment.cgi?id=174700) [10:36] rodrigo_: and confirm you get a .cache/wallpaper/num- file? [10:36] didrocks, yes [10:36] rodrigo_: thanks :) [10:40] kklimonda, there? [10:43] didrocks, \o/ [10:43] you got your patch to land after 6 months ;-) [10:43] seb128: yeah, just discussed it this morning \o/ [10:44] seb128: stop staring at #commits :) [10:44] lol [10:44] * didrocks wonders if seb128 has some hilight on desktop team members name as well to spy them on channels :) [10:44] I don't stare, I barely glance over it every now and then ;-) [10:45] it's just that less than 1 min after the commits, sounds weird :p [10:46] didrocks, btw, just finished building evo-couchdb with latest evo/eds, and it works, so submitting a branch in a minute, after I test your patch [10:46] rodrigo_: nice! [10:47] didrocks: please apply prodding to the appropriate people about banshee ;-) [10:47] morning btw [10:47] morning Laney [10:47] Laney: all is ready? MIR and default plugins? [10:48] yep [10:48] i will admit that i haven't tested in a clean vm though [10:48] that's what users are for right ;) [10:48] well, let's hope that the build in main is working [10:49] Laney: can you post here the MIR bugs # [10:49] bug 607291 bug 607304 [10:49]