[03:10] <GreatOldOne> ^ya HPL reference
[03:12] <RAOF> So, what aspect of our shell of peaceful reality do you want to shatter today?
[03:15] <GreatOldOne> hey RAOF
[03:15] <GreatOldOne> just waiting for the stars to be right so I can go home
[03:17] <RAOF> Mm, a little Miles Davis goes very nicely with checking maintainerscript changes for sanity.
[03:17] <GreatOldOne> so what?
[03:21] <RAOF> So I think everyone should be forced to listen to Miles Davis while inspecting their maintainer scripts. :)
[03:22] <TheMuso> heh
[03:22] <TheMuso> RAOF: How was your long weekend? Or did you not get that in Tassy?
[03:23] <RAOF> We got the long weekend, yeah.
[03:23] <RAOF> It's only WA that doesn't get the Queens Birthday :)
[03:24] <TheMuso> Ah.
[03:24] <RAOF> It was pretty good.  Did a bit of running up Mount Wellington, released Do 0.8.5 and the associated plugins, did a bit of gardening (both of Do bugs and of the physical garden) and capped it off with a little light hacking.
[03:24] <TheMuso> Nice.
[03:24] <TheMuso> Twas a little too wet to get outdoors for most of the weekend here, which is a pitty. Got some walking in though which is good.
[03:25] <TheMuso> Anyway.
[03:25]  * TheMuso -> lunch
[03:26] <RAOF> Have deliciousness!
[03:57] <TheMuso> That I certainly did.
[05:00] <TheMuso> Hrm I have been kicked out of X and back to the login screen twice today.
[05:00] <RAOF> Awkward.  Got logs to go with that?
[05:01] <TheMuso> Probably, I'd need to look. Nothing in /var/crash though.
[05:01] <TheMuso> brb
[05:03] <TheMuso> back
[05:03] <TheMuso> So would I be looking in the X logs then?
[05:04] <RAOF> Yeah, as a quick check.  /var/log/Xorg.0.log.old.
[05:05] <TheMuso> ok
[05:07] <TheMuso> Nothing real obvious, but at the end of that file, I get this.
[05:07]  * TheMuso pastebins.
[05:07] <TheMuso> http://paste.ubuntu.com/626321/
[05:10] <TheMuso> Other than that, nothing stands out.
[05:14] <RAOF> TheMuso: Looks like a standard shutdown; the meat (if there is indeed any) would be further up.
[05:18] <TheMuso> HRM OK.
[05:19] <RAOF> It's why apport doesn't always catch X server crashes; the server registers a SEGV handler and does some graceful shutdown (and our patch generally then gets it to re-emit the SEGV, so that apport can collect, but for some reason doesn't always work).
[05:20] <TheMuso> Right.
[05:20] <TheMuso> Will have a look again should it occur again.
[05:57] <pitti> Good morning
[05:57] <pitti> GunnarHj: hm, no idea; the patches apply fine here, it builds great
[05:58] <pitti> GunnarHj: how did you build? I use "bzr bd -- -b"
[05:59] <GunnarHj> pitti: Good morning!
[05:59] <pitti> hey GunnarHj, how are you?
[05:59] <GunnarHj> pitti: Me too.
[06:00] <GunnarHj> I'm fine, thank you.
[06:01] <GunnarHj> pitti: or... I use bzr builddeb ... you did not mean what you wrote literally, right?
[06:01] <cnd> pitti, I've got a question about gtk library versioning
[06:02] <cnd> we've got a library called libgrip currently at version 0.1 for gtk2
[06:02] <cnd> we're looking to abi bump it for gtk3 and for other changes
[06:02] <pitti> GunnarHj: I did; "bd" is a convenience alias for builddeb
[06:02] <cnd> the package in ubuntu is called libgrip-0.1-0
[06:03] <pitti> cnd: apparently there are no reverse dependencies right now, so this should be rather easy?
[06:03] <cnd> correct
[06:03] <cnd> I just want to be sure we follow the correct protocol for version bumps with abi bumps
[06:04] <GunnarHj> pitti: Ok, I'll try that, then. If I don't make it work, I'll save the log.
[06:04] <cnd> the biggest thing that is throwing me is the version string in the package name itself
[06:04] <cnd> which seems to be a gtk thing from what I gather
[06:04] <pitti> cnd: no, it's not at all related to gtk
[06:04] <cnd> oh, ok
[06:05] <pitti> it's pretty standard practice if you want to maintain multiple series in parallel for a long time
[06:05] <pitti> most libraries don't have a version string, just a SONAME
[06:05] <cnd> yeah
[06:05] <pitti> i. e.  libgrip.so.1 in libgrip1 package
[06:05] <cnd> we don't plan to maintain the 0.1 version
[06:05] <cnd> but I would think we should still bump it to 0.2
[06:05] <pitti> then do that
[06:05] <cnd> so libgrip-0.1-0?
[06:06] <pitti> cnd: do you ever plan to support two major series for a year or so?
[06:06] <cnd> no plans at this time :)
[06:06] <pitti> cnd: unless you have a good reason for this version in the name, I'd just call it libgrip really
[06:06] <pitti> and bump the soname if you switch to gtk3
[06:06] <cnd> ok
[06:06] <TheMuso> pitti: Do you know what is going to be done about gksu, given that upstream hasn't seen any attention since 2009? I ask because I am working on a11y settings atm, which lead me to discover gksu still uses GTK2 and gconf...
[06:07] <cnd> so go to libgrip1
[06:07] <pitti> cnd: or libgrip0
[06:07] <pitti> cnd: but 0 might confuse people, and it's not like we are short on natural numbers, so might as well use 1 :)
[06:08] <pitti> TheMuso: not much going on right now; I hope at some point we can get rid of the remaining handful of rdepends, and just use PK everywhere
[06:08] <cnd> yeah
[06:08] <cnd> ok, thanks pitti!
[06:08] <pitti> TheMuso: also much better for a consistent UI
[06:08] <TheMuso> pitti: Likely for this cycle?
[06:09] <pitti> TheMuso: most probably not yet
[06:09] <pitti> TheMuso: do we need it to use gtk3 for a11y?
[06:11] <TheMuso> pitti: No, we shouldn't need to.
[06:11] <TheMuso> pitti: I am doing some accessibility profile settings migration to gsettings, and was checking to see whether gksu's settings were in gsettings. Since they are not, then thats fine.
[06:16] <TheMuso> Ok, is it not possible to change the mouse theme from the GNOME 3 UI any more?
[06:18] <pitti> TheMuso: gnome-tweak-tool might allow it
[06:18] <pitti> TheMuso: all the theme settings etc. moved there
[06:19] <RAOF> Does gnome-tweak-tool actually work yet?
[06:19] <pitti> no idea, I never used it so far
[06:19] <RAOF> I think it still depends on gnome-shell.
[06:19] <TheMuso> pitti: Right, rather big fail IMO.
[06:20] <TheMuso> RAOF: I am about to test it, as I want to change my mouse cursor theme.
[06:21] <TheMuso> ...and no GUI comes up, but I get the following in a console:
[06:21] <TheMuso> GLib-GIO-ERROR **: Settings schema 'org.gnome.shell.clock' is not installed
[06:21] <TheMuso> Trace/breakpoint trap
[06:21] <TheMuso> So I think it wants something from gnome-shell to be present before it will work.
[06:22]  * TheMuso takes the direct approach and tweaks gsettings by hand.
[06:31] <RAOF> Yeah, that's totally the way to go.
[06:32] <TheMuso> RAOF: Totally.
[06:33] <TheMuso> Ok gnome-shell installed to get gnome-tweaktool working.
[06:33] <TheMuso> ...and gnome-tweaktool's interface totally fails a11y wise. :S
[06:33]  * TheMuso sighs.
[06:36] <TheMuso> And gnome tweaktool doesn't even have what I am looking for.
[06:42] <TheMuso> Oh wonderful. My mouse theme changes have taken after logging in again, but only for GTK2 apps.
[06:43] <TheMuso> Even then it doesn't appear to be 100% consistant.
[06:56] <ricotz> mterry, hello
[06:58] <TheMuso> I suspect Michael is asleep at the moment, given how late it is in most of the US.
[06:58] <ricotz> mterry, will it be possible to have bamf-gtk2/gtk3 in parallel?
[06:58] <didrocks> good morning
[06:59] <TheMuso> Good morning didrocks.
[07:03] <didrocks> hey TheMuso, how are you?
[07:06] <pitti> hey didrocks
[07:06] <didrocks> guten morgen pitti, how was your week-end?
[07:06] <TheMuso> didrocks: Not too bad thanks. Yourself?
[07:06] <pitti> very nice; a friend of mine got married, so we went to Berlin
[07:06] <pitti> yesterday we spent with gardening and some cleaning
[07:06] <didrocks> TheMuso: I'm fine thanks ;)
[07:07] <didrocks> pitti: oh nice, so party and relaxing in the same week-end :)
[07:25] <broder> does anybody know of example code on how to use a struct as the key to a GHashTable? i'm mostly trying to figure out how best to write a hash function to combine the hashes of the struct's members
[07:39] <pitti> broder: does GHashTable even care about the key type? I thought you just need to supply an appropriate hash_func
[07:39] <broder> right - i was trying to figure out what such a hash function would look like
[07:39] <pitti> which then would just need to xor the individual struct member's hashes together?
[07:40] <broder> hmm...yeah, i guess that could work
[07:40] <pitti> I don't have an example ready either
[07:40] <broder> i'm going to go and think harder about my data structures before i write too much code
[07:40] <pitti> but someting like g_int_hash(mystruct.int_field) ^ g_str_hash(mystruct.str_field) ^ ... should work
[07:41] <pitti> broder: for combining existing hashes there's nothign better than xorg
[07:41] <pitti> erk, "xor"
[07:41] <pitti> autofingers..
[07:41] <broder> haha :)
[09:02] <seb128> hi desktopers
[09:02] <pitti> bonjour seb128
[09:02] <rodrigo_> morning
[09:02] <seb128> hey pitti rodrigo_
[09:02] <seb128> how are you?
[09:02] <seb128> pitti, it's meeting reminder day!
[09:02] <pitti> seb128: oh, thanks!
[09:02] <seb128> ;-)
[09:03] <didrocks> salut seb128
[09:03] <didrocks> hey rodrigo_
[09:03] <seb128> lut didrocks
[09:03]  * didrocks refrained himself for the two last hours to tell pitti about the meeting to let seb128 have the joy to tell it :)
[09:03] <seb128> ;-)
[09:03] <seb128> didrocks, ca va ?
[09:04] <seb128> did everybody have a nice w.e?
[09:04] <rodrigo_> seb128, yes, good one, and you?
[09:05] <pitti> seb128: was indeed nice; we went to Berlin again, a friend of us got married
[09:05] <pitti> hey rodrigo_
[09:05] <rodrigo_> hi pitti
[09:05] <seb128> quite nice as well, weather was not that great half of the w.e (rainy at times) but still relaxing
[09:05] <seb128> pitti, nice! ;-)
[09:05] <didrocks> seb128: ça va bien! Nice week-end with a wedding in Paris from Julie's cousin. Then, quieter Sunday and Monday :) Yours?
[09:06] <seb128> didrocks, nothing fancy, family gathering on sunday and otherwise just tv, some reading, some shopping, some relaxing
[09:06] <didrocks> nice :-)
[09:06] <didrocks> get some rest is a nice activity as well :)
[09:13] <rodrigo_> didrocks, :)
[09:14] <pitti> didrocks: hm, seems latest weechat forgot about the smart join/part filter?
[09:14] <pitti> for you as well?
[09:14]  * pitti now gets spammed with these
[09:14] <didrocks> pitti: I didn't restart since today's update (didn't update since last friday)
[09:15] <seb128> rodrigo_, pitti: ok, so I checked the old libs rdepends on friday afternoon, tomboy is the only thing keeping libgnome, libgnomeui, libbonobo, libbonoboui, libgnomecanvas on the CD
[09:16] <didrocks> pitti: hum, no update for a while? you didn't get that in the previous weeks?
[09:16] <pitti> not that I remember
[09:17] <didrocks> 0.3.5-1 is working fine for smart filtering still there
[09:17]  * pitti re-sets the filter config, let's see
[09:17] <rodrigo_> seb128, right, no answer from alan mcgovern about the status of the gsettings bindings, btw
[09:18] <rodrigo_> will talk to sandy later, when he wakes up, to see if there's something we can do
[09:18] <seb128> rodrigo_, ok thanks
[09:18] <seb128> I'm close to suggest that we drop tomboy from the CD at least until that is sorted
[09:18] <pitti> WFM
[09:19] <rodrigo_> yes
[09:19] <seb128> rodrigo_, let's wait for you to check with sandy, then I will send an email to the ubuntu-desktop list about it
[09:20] <rodrigo_> ok
[09:38] <ricotz> hello everyone
[09:39] <ricotz> seb128, hello :), you probably want to have a look at the cheese build failure https://launchpadlibrarian.net/73496829/buildlog_ubuntu-natty-amd64.cheese_3.0.0-0ubuntu1~natty1_FAILEDTOBUILD.txt.gz
[09:39] <seb128> hey ricotz
[09:39] <seb128> ricotz, how can it try to build when half the build-depends need promotion?
[09:40] <ricotz> seb128, it is a ppa build, but the symbols file wasnt updated
[09:40] <seb128> ricotz, that's not what is breaking the build
[09:40] <seb128> ricotz, the version which got uploaded was basically the gnome3 ppa one
[09:40] <seb128> ricotz, what breaks the build is that libclutter-dev in the serie you use doesn't depends on the gir
[09:42] <seb128> which is probably an issue in oneiric as well, will be fixed when somebody merges clutte
[09:42] <seb128> clutter
[09:42] <ricotz> seb128, hmm, are we looking at the same thing
[09:43] <chrisccoulson> good morning everyone
[09:43] <didrocks> good morning chrisccoulson!
[09:43] <chrisccoulson> hey didrocks, how are you?
[09:43] <didrocks> chrisccoulson: I'm fine, thanks, and you? :) not feeling lonely yesterday?
[09:44] <chrisccoulson> didrocks, heh, it was pretty dull in here yesterday ;)
[09:44] <seb128> hey chrisccoulson
[09:44] <chrisccoulson> hi seb128, how are you?
[09:44] <seb128> quite fine! what about you?
[09:45] <seb128> ricotz, yes, your build fails with "dh_girepository: Could not find Clutter-1.0.typelib dependency"
[09:45] <didrocks> chrisccoulson: dull? do you lack of things to work on? :-p
[09:45] <chrisccoulson> i've got plenty of things to work on ;)
[09:45] <ricotz> seb128, sorry, got sidetracked by the symbols check
[09:45] <seb128> ricotz, which means gir1.2-clutter-1.0 is not installed
[09:45] <chrisccoulson> seb128, yeah, good thanks. just getting ready to upload the final, final firefox 5 beta
[09:45] <ricotz> seb128, right
[09:46] <seb128> ricotz, either add the gir to the build-depends or fix clutter
[09:46] <seb128> I will fix clutter in oneiric
[09:46] <ricotz> i see, either way the symbols file needs some love too ;)
[09:47] <seb128> right
[09:48] <seb128> well cheese is not going to build for a while anyway
[09:48] <seb128> it will need quite some libs promotion or to be demoted to universe
[09:48] <seb128> I would lean toward the second option but the ubiquity guys planned to use it
[09:48] <seb128> or, I should check with cassidy as well
[09:48] <seb128> somebody told me they planned to use it as well this cycle
[09:49] <cassidy> seb128, yep?
[09:49] <seb128> cassidy, do you plan to use libcheese-gtk?
[09:49] <seb128> cassidy, is that going to be optionnal? short story is that we don't want libcheese in the default installation
[09:51] <cassidy> seb128, we do, it's optional so far (only used to create an avatar) but will probably become a hard dep soon (used to detect if there is a camera plugged in)
[09:51] <seb128> hum ok, so we will need to patch that you
[09:51] <seb128> you->out
[09:52] <seb128> cassidy, if you keep it optional or find another way to detect a camera than pulling the clutter stack with gesture libraries in that would be nice
[09:52] <pitti> cassidy: hm, libudev is enough to detect cameras
[09:53] <cassidy> is there a libcheese and libcheese-gtk ?
[09:53] <pitti> or checking /dev/v4l/*
[09:53] <cassidy> pitti, well yeah, but libcheese already does it for us with a nice API
[09:54] <pitti> if you use other functionality from libcheese, then that makes sense; just for cam detection it's very heavy, though
[09:55] <cassidy> we use the avatar selector widget yeah
[09:55] <cassidy> I don't mind having this one optional
[09:55] <cassidy> but the camera detection is important enough to be in core, I think
[09:55] <ricotz> currently both libs are in libcheese-gtk, but splitting them might solve this dependency issue and not pulling clutter in
[09:55] <cassidy> yeah
[09:56] <cassidy> tbh, pulling Clutter is not an issue to us as it's needed by GNOME 3 anyway
[09:57] <seb128> cassidy, right, the question is somewhat also to know if you consider empathy as a GNOME3 component or as an IM client you want used out of GNOME3
[09:58] <seb128> either way is fine and is your decision, I'm just pointing that by adding some depends you might create issues for some of your other users
[09:59] <cassidy> I consider it as a core part of GNOME 3, but I'm trying to avoid as much as possible to make life harder for others
[09:59] <cassidy> so yeah, please do continue to raise such issue to me
[09:59] <seb128> ok, great ;-)
[09:59] <seb128> libcheese depends on clutter-gst
[09:59] <cassidy> but, in this case, I think the right answer is splitting libcheese-gtk
[09:59] <seb128> the non gtk lib
[09:59] <cassidy> humm the new call UI will use clutter-gst as well actually
[10:00] <cassidy> that's the only way to do video overlapping
[10:00] <cassidy> so we will depend on clutter at some point for sure
[10:00] <seb128> hum
[10:00] <seb128> what does it mean for people who don't have the video drivers to use clutter?
[10:00] <seb128> empathy will just bug on them?
[10:01] <cassidy> the old VoIP (empathy-av) will still around for a while I think
[10:01] <cassidy> so it could be used with the fallback mode probably
[10:01] <seb128> ok, so maybe the solution for us is to keep using that
[10:01] <cassidy> but you won't have all the new shiny features then :(
[10:01] <seb128> it seems crazy that an im client requires working gl :-(
[10:01] <seb128> especially with clutter
[10:02] <seb128> there are still lot of users having issue with clutter and arm etc is not making that any better
[10:03] <cassidy> well that's the price if we want to move forward
[10:03] <RAOF> I wonder how performant llvmpipe would be as a software rasteriser for clutter.  It's apparently nearly good enough to do gnome-shell.  Although obviously not on arm.
[10:03] <dpm> hey jibel, good morning. Do you know who's maintaining the ISO tracker nowadays?
[10:03] <cassidy> i was afraid of that as well but it doesn't seem to bad with the shell from what I've seen
[10:03] <seb128> cassidy, not sure that's "forward"
[10:03] <seb128> users running an im client or skype or whatever want working im, sound and video
[10:04] <seb128> they don't want clutter 3d effects
[10:04] <cassidy> I'm talking about 3d effects; but if you want, say, a fullscreen mode with your preview on top, you need video overlapping
[10:04] <seb128> I don't think any im client on other platforms do crazy things, you don't wait from those fancyness but reliability
[10:05] <cassidy> how are you going to handle totem 3.2 btw?
[10:05] <jibel> dpm, Hey, I do. anything I can help with ?
[10:05] <cassidy> it will depend on clutter-gst too I think
[10:05] <RAOF> You should be able to do simple overlays with just Xv, right?  Almost everything has more than one Xv port.
[10:05] <seb128> cassidy, we might stay on 3.0, or at least we need to think about it
[10:05] <cassidy> :(
[10:05] <RAOF> You can't easily do the nice OSD effects that totem's doing, but if you just want PiP then Xv should handle it?
[10:06] <seb128> cassidy, we are already hitting quite some CD space issues and clutter has a very poor reliability story on quite some hardware
[10:06] <cassidy> tbh, GNOME is moving forward to Clutter. If you want to continue using it you'll have to ship it at some point
[10:06] <dpm> jibel, I'm helping the kernel team to set up an ISO tracker so that they can roll out their custom ISOs, and I've got a few questions on that, do you have a minute?
[10:06] <cassidy> (I'm not a clutter fanboy or anything)
[10:08] <cassidy> and GNOME 3 will push clutter / 3D support forward, so I'm sure it will continue to improve
[10:08] <seb128> cassidy, right, which is something we need to think about, but we don't use that many GNOME components that will require clutter
[10:09] <seb128> cassidy, right, I was sort of trying to avoid getting it in before the coming lts
[10:09] <seb128> we have CD space issues and will keep having those until we drop gtk2 from the CD and clutter is still not great from the feedback we got
[10:10] <cassidy> seb128, the libcheese dep may stay optional for now. I don't know when the new call UI will happen (3.2 or 3.4) but for this one we'll certainly need clutter-gst
[10:10] <seb128> cassidy, ok thanks, that let us some time to think about it
[10:11] <seb128> well clutter and clutter-gst should be ok I guess
[10:11] <cassidy> but, tbh, I think you'll have to ship clutter at some point anyway
[10:11] <seb128> what made me stop with cheese is that it brings clutter-gesture and some gesture libs as well
[10:11] <cassidy> a better split of libcheese would be good, for sure
[10:12] <seb128> cassidy, thanks
[10:13] <jibel> dpm, not now I'm on a sprint, around noon utc ?
[10:13] <dpm> jibel, sounds good, let's talk later on then, thanks!
[10:39] <pitti> bah, today's dailies grew by 10 MB, all oversized again :/
[10:42] <seb128> pitti, is that python3?
[10:42] <pitti> 2011-06-14 06:54:40     cjwatson        [00:25:30] pitti: so, live-build seems to have saved a couple of megaby
[10:42] <pitti> tes, but it's obscured by (a) libegl1-mesa (b) python3.2 and (c) mono 2.10 (as warned by directhex) having eate
[10:42] <pitti> n a chunk of space between them
[10:43] <seb128> can we drop python2.6?
[10:43] <seb128> to make it for 3.2?
[10:43] <pitti> that's the plan, yes
[10:44] <pitti> and I suppose libegl1-mesa is what RAOF meant with the LLVM drivers? or is that something different?
[10:44] <cjwatson> when I looked last night, EGL was a bit over a megabyte, python3.2 was something like 6MB, and I assume Mono ate another 5MB or so but didn't check
[10:44] <pitti> oh, doesn't seem to be the llvm bit
[11:27] <didrocks> need to logout/login to test accessibility, brb
[11:32] <RAOF> pitti: No; libegl1-mesa is a new dependency of cairo.
[11:33] <RAOF> pitti: Mesa llvm bit is blocked on bug #790204
[11:33] <ubot2> Launchpad bug 790204 in llvm-2.9 "[MIR] libllvm-2.9" [Undecided,New] https://launchpad.net/bugs/790204
[11:37] <didrocks> tseliot, RAOF, bryce: is there a known issue with the new X and the nvidia driver?
[11:37] <didrocks> I had to switch back to vesa here
[11:38] <tseliot> didrocks: in oneiric?
[11:38] <RAOF> Does the nvidia driver build against linux 3.0?
[11:38] <didrocks> right
[11:38] <tseliot> RAOF: yes, that's the problem
[11:38] <didrocks> RAOF: didn't check, no postinst or trigger error from what I saw
[11:38] <tseliot> RAOF: actually it's not supposed to even try to build the module
[11:38] <didrocks> hum, we should put a breaks: then to avoid people upgrading maybe?
[11:39] <ricotz> it builds after some patching
[11:39] <ricotz> at least 275.x didnt try 270.x
[11:39] <tseliot> didrocks: I have to update nvidia and fglrx to get them to work with anything newer than 2.6.38
[11:39] <RAOF> I don't think we've done that in the past, but it might not be a bad idea.
[11:40] <RAOF> The trick would be in the maintenance of the Breaks: list.
[11:40] <didrocks> tseliot: do yoyu think it can be done shortly or is it better to breaks: to avoid people getting no interface on upgrade?
[11:40] <tseliot> didrocks: yes, I can do it today
[11:40] <didrocks> tseliot: nice, thanks :)
[11:40] <didrocks> let's have a day in the fallback mode then
[11:40] <didrocks> :)
[11:40] <tseliot> I was going to work on it today anyway :)
[11:40] <RAOF> didrocks: It doesn't fall back to vesa automatically for you?
[11:40] <didrocks> RAOF: no, I got no screen
[11:40] <ricotz> tseliot, the edgers-packages includes a small patch which might work for 270 too
[11:41] <didrocks> RAOF: had to change xorg.conf myself
[11:41] <tseliot> ricotz: ah, nice, I'll have a look at the patch and update it if necessary
[11:41] <RAOF> Oh, you had an xorg.conf?  We shouldn't be writing one of those now.
[11:41] <tseliot> right, Jockey doesn't even write one anymore
[11:41] <didrocks> RAOF: I need one for my double screen config (written by nvidia)
[11:41] <tseliot> oh
[11:41] <didrocks> nvidia-settings
[11:41] <tseliot> right
[11:41] <RAOF> Ah.  Yes.  That will break.
[11:42] <didrocks> so yeah, for those users, no safety net :)
[11:42] <tseliot> no failsafe-x?
[11:42]  * RAOF wonders how hard it would be for X to fallback properly there.
[11:42] <didrocks> well, if there was one, I didn't get it after 2 boots
[11:43] <RAOF> Harumph.
[11:45] <RAOF> tseliot: Incidentally, a multiarch'd mesa that will (should!) actually build is now building in http://tinyurl.com/4xmz7oj
[11:45] <tseliot> RAOF: excellent! Thanks a lot
[11:46]  * tseliot -> lunch
[11:56] <didrocks> TheMuso: is orca currently working in oneiric? I can activate it (and hear the voice), but any GNOME application started even after the activation doesn't seem to integrate
[11:59] <chrisccoulson> didrocks, do you have libgnome-3-common and libatk-adaptor installed?
[11:59] <chrisccoulson> i hit a similar issue yesterday, and needed to install those :)
[11:59] <chrisccoulson> urgh
[11:59] <chrisccoulson> libgail-3-common, even ;)
[12:00] <didrocks> chrisccoulson: indeed, none of those are installed! seems a missing dep then? Installing now, thanks :)
[12:00] <chrisccoulson> didrocks, TheMuso is aware of that already
[12:00] <didrocks> ok, nice :)
[12:01] <didrocks> ah, nice, working even without restarting any app
[12:02] <didrocks> thanks a lot chrisccoulson! :)
[12:11] <chrisccoulson> pitti, we're pretty close to dropping xulrunner from the archive now - https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-mozilla-rapid-release-maintenance ;)
[12:13] <cjwatson> fta: I think I found my problem with xvfb-run; the X server gets confused if run under fakeroot
[12:13] <cjwatson> so 'env -u LD_PRELOAD xvfb-run ...' seems to improve matters
[12:48] <didrocks> chrisccoulson: btw, you regularly run a11y support?
[12:48] <chrisccoulson> didrocks, not normally. i just wanted to test something yesterday
[12:48] <didrocks> chrisccoulson: ok, nice coincidence then! Thanks again :)
[12:49] <seb128> seems like some desktopers were working yesterday ;-)
[12:50] <didrocks> seb128: it seems those guys were missing having a royal wedding or something like that :)
[12:52] <chrisccoulson> lol
[12:52] <chrisccoulson> you can have our royal family if you like ;)
[12:52] <RAOF> seb128: What are we going to do about cairo/gl?  Do you have any plans?
[12:53] <seb128> didrocks, pitti: isn't the gnome-icon-theme, unity issue fixed?
[12:53] <seb128> RAOF, no plan, I just told bryce that we were going to run the gl backend off for natty to fix nvidia and that we would turn it on again which is what we did
[12:54] <didrocks> seb128: there is no debugging about why it doesn't load even if the Humanity theme is loaded for some
[12:54] <seb128> RAOF, if nothing happens this cycle I guess we will have the same discussion about turning gl off again at beta time
[12:54] <didrocks> seb128: there is a fix unity upstream last Thursday which was the day planned for the dx SRU which didn't come
[12:55] <didrocks> I think I won't wait for the SRU and just cherry-pick the fix for now
[12:55] <seb128> didrocks, well seems that gnome-icon-theme should be fixed anyway which is why i included pitti in the ping
[12:55] <didrocks> seb128: hum, it should get the icon, right
[12:55] <didrocks> and not relying on Humanity to have it
[12:55] <seb128> well the icon should be in the standard binary
[12:55] <seb128> right
[12:56] <didrocks> so either way, I can fix it today or wait for pitti :)
[12:56] <seb128> well, pitti should fix the icon theme split and dx should roll a tarball for the sru with the fix
[12:57] <seb128> oneiric can get an unity update when they roll it
[12:57] <seb128> njpatel, how is the coming SRU going? ;-)
[12:58] <didrocks> let's see, anyway, you will be in charge of it as I won't be there this week
[12:58] <didrocks> I'm sure you will love chasing people for test cases :-)
[13:00] <seb128> lol
[13:07] <mterry> ricotz, yes, it's possible to have bamf2/bamf3 installed in parallel
[13:09]  * didrocks tests rebooting on the older kernel
[13:09] <didrocks> brb
[13:11] <rodrigo_> ok, lunch time, bbl
[13:14] <pitti> seb128, didrocks: sorry, what icon is missing? or what package is crashing?
[13:15] <didrocks> pitti: unity is crashing
[13:15] <didrocks> for the icon, one sec
[13:16] <didrocks> pitti: text-x-preview
[13:16] <seb128> pitti, bug #794556
[13:16] <ubot2> Launchpad bug 794556 in unity "Unable to load icon text-x-preview at size 48 in a loop" [Undecided,Confirmed] https://launchpad.net/bugs/794556
[13:17] <pitti> thanks; hm, I wonder why I don't get a crash
[13:17] <pitti> ah, I apparently installed g-i-t-full last week for testing something else, and forgot to purge
[13:17] <didrocks> pitti: do you force the Humanity icon theme?
[13:17] <pitti> restarting my session
[13:17] <didrocks> oh ok :)
[13:17] <pitti> didrocks: "foroce"?
[13:17] <pitti> "force"
[13:18] <didrocks> pitti: Humanity seems to have it, but if you select a different theme which doesn't inherit from it, you don't get this icon
[13:19] <pitti> didrocks: ah, how do you select the theme?
[13:19] <pitti> didrocks: that's why gnome-tweak-tool has a dependency to gnome-icon-theme-full
[13:20] <jibel> dpm, ping
[13:20] <seb128> pitti, the issue seems to be that if g-s-d has any issue and goes down you get screwed
[13:20] <didrocks> pitti: maybe that comes from migration? I don't know, but people seems to trigger it after the default upgrade experience
[13:20] <pitti> ah, I see
[13:20] <didrocks> oh yeah, g-s-d crashing of course!
[13:20] <pitti> so the question is, does that really only affect this one icon, or isn't it just going to crash on the next missing one
[13:21] <pitti> in the latter case, it would basically mean "we need to ship the full g-i-t anyway", and add back the 5.8 MB
[13:21] <seb128> pitti, which is somewhat an unity issue (and they have it fix commited)
[13:21] <didrocks> pitti: no, this is the fallback icon
[13:21] <pitti> moving one icon to g-i-t is not a problem at all, of course
[13:21] <didrocks> pitti: but there was no protection in unity and we try to load the fallback icon with the same function
[13:21] <dpm> jibel, pong. Want to do a quick 5-10 min mumble?
[13:22] <didrocks> pitti: so, the fallback icon not being there, it tried to look for the fallback icon again :)
[13:24]  * pitti scratches head about "The icon theme is set to ubuntu-mono-dark, and indeed the ubuntu-mono package does not have a text-x-preview icon; however, switching to an icon theme where this is present, like Humanity, does not resolve the issue."
[13:24] <pitti> /usr/share/icons/ubuntu-mono-light/index.theme has Inherits=Humanity,gnome,hicolor, so it should use humanity's
[13:25] <didrocks> pitti: right, and I tried to ping ev about it, but he didn't have time to debug
[13:25] <seb128> didrocks, pitti: seems like it's down to an unity fix commited bug
[13:25] <seb128> then we can try to debug other issues if any remains
[13:26] <didrocks> seb128: well, the unity fixes just fixes the "don't go in a dead loop if we don't find the fallback icon"
[13:26] <Daviey> Hmm, is GDM poorly for anyone else atm?
[13:26] <pitti> so want me to move the icon?
[13:26] <ricotz> mterry, that would be nice -- i thought that bamfdaemon would be linked against either libbamf0 or libbamf3 which make it difficult -- is there a package yet?
[13:26] <seb128> Daviey, you mean? no background or theme?
[13:26] <Daviey> seb128: no starty :/
[13:27] <Daviey> http://pb.daviey.com/K02M/raw/
[13:27] <seb128> dunno, we switched to lightdm recently which I'm using
[13:27] <didrocks> pitti: I would say so, anyway. I'll have a tomboy note to check that if we don't find an icon, the Humanity fallback icon is taken
[13:27]  * Daviey swithces
[13:27] <mterry> ricotz, no, I don't think there's an upstream release yet.  Let me check how bamfdaemon was handled.  I believe it is just linked against libbamf3 and that's it.  But that doesn't prevent libbamf0 from being around
[13:27] <pitti> Daviey: uh, X.org crashing?
[13:28] <didrocks> I'm not sure how ev choosed the Humanity/ubuntu-mono theme with GNOME3, hence I want to wait a little on debugging
[13:28] <seb128> Daviey, using nvidia? didrocks had issue with nvidia today
[13:28] <ricotz> mterry, i think the packaging has binary depends
[13:28] <Daviey> seb128: yup!
[13:29] <Daviey> pitti: yes
[13:29] <didrocks> Daviey: restart on the older kernel
[13:29] <didrocks> do you have a xorg.conf?
[13:29] <Daviey> didrocks: I believe i do
[13:29] <Daviey> Will try an older kernel
[13:29] <didrocks> Daviey: yeah, so either switch to vesa and restart gdm and restart on an older kernel
[13:29] <ricotz> mterry, but perhaps this can be relaxed
[13:29] <Daviey> didrocks: thanks
[13:30] <didrocks> yw :)
[13:30] <mterry> ricotz, well, bamfdaemon would just link against libbamf3 and that's that.  But libbamf0 can still be on the system and useful.  It can still talk over dbus to a bamfdaemon written in scheme or qt or whatever
[13:31] <ricotz> mterry, right
[13:34] <pitti> didrocks: fix uploaded; thanks!
[13:34] <Daviey> didrocks: Did you see a bug tracking this nvidia issue with linux-3.0 ?
[13:37] <didrocks> pitti: thanks to you :)
[13:37] <didrocks> Daviey: no, tseliot told that he would work on this today
[13:37] <Daviey> super! thanks.
[13:38] <tseliot> :)
[13:40] <ricotz> mterry, libbamf0 binary-depends on bamfdaemon which breaks a parallel install, so the dependency needs to be switched first to make bamfdaemon depend on libbamf0 -- not sure why it is done this way
[13:42] <mterry> ricotz, I don't see the problem.  libbamf0 x.x and libbamf-3-0 x.x will both depend on bamfdaemon x.x.  Shouldn't be a conflict
[13:42] <ricotz> mterry, the packaging contains "bamfdaemon (= ${binary:Version})" in libbamf0
[13:43] <mterry> ricotz, agreed.  Is there some ramification I'm missing of that?  Sorry for being dense
[13:43] <ricotz> didrocks, hi, is there a reason for doing it this way ^
[13:46] <mterry> ricotz, oh...  are you thinking bamf3 and bamf0 would be different source packages?  They'll be built from the same source
[13:46] <seb128> pitti, shouldn't you update the replaces: version if you move icons between binaries?
[13:46] <ricotz> mterry, without switching the deps, you can leave libbamf0 installed -- or should the bamf package build both flavours
[13:46] <didrocks> ricotz: the library needs the daemon
[13:46] <pitti> seb128: Replaces: gnome-icon-theme-full (<< ${binary:Version})
[13:46] <didrocks> so libbamf0 and libbamf3 needs to dep on the daemon
[13:46] <pitti> seb128:  :)
[13:46] <didrocks> nothing to change
[13:46] <mterry> ricotz, right, it will build both flavors
[13:47] <seb128> pitti, ok, I was too lazy to do a checkout, I just read the changelog ;-)
[13:47] <seb128> pitti, in the previous upload you mentioned updating the replaces so I was checking ;-)
[13:47]  * didrocks really on a break now :)
[13:47] <pitti> seb128: right, originally I only had them one way around, there I did them in the opposite direction as well; now we can freely move them around without further Replaces: updates
[13:48] <seb128> pitti, ok, makes sense ;-)
[13:48] <ricotz> mterry, ok, so there is no need to make some fixing first if libbamf0 will be replaced
[13:48] <tseliot> pitti: we don't support dist-upgrades from non-consecutive releases, right? If so, I'll remove the transitional packages in nvidia
[13:49] <mterry> ricotz, replaced by what?  It's not going away.  gtk2 apps will still want to use bamf
[13:49] <ricotz> mterry, i mean by a newer version ;)
[13:49] <mterry> ricotz, :) ah.  no, shouldn't be a problem
[13:50] <didrocks> ricotz: so, there is nothing wrong with the dep on the daemon
[13:50] <seb128> tseliot, we support lts to lts and any version to the next one
[13:50] <tseliot> seb128: ok, it should be fine to remove the transitional packages then
[13:52] <ricotz> didrocks, seems fine since the lib depends on the running dbus service
[13:52] <didrocks> ricotz: yeah, that was the intend :)
[13:52] <ricotz> just looked a bit weird ;)
[13:55] <didrocks> why weird? it's really a dep on the lib to work :)
[14:00] <cyphermox> good morning
[14:01] <njpatel> seb128, didrocks we can do SRU tomorrow?
[14:01] <didrocks> njpatel: FYI, I'm not there until EOW
[14:01] <njpatel> at least for nux/unity
[14:01] <seb128> njpatel, didrocks is only there today but I guess I can try to cover for him
[14:01] <didrocks> so deal that with seb128 if he has time to do it
[14:01] <njpatel> didrocks, so, wrt, should i wait for you or do it with seb128?
[14:02] <njpatel> right, okay, let's try tomorrow but no biggie
[14:02] <seb128> njpatel, I think I should be able to handle an unity update ;-)
[14:02] <didrocks> seb128: don't break my branches :)
[14:03] <seb128> didrocks, yeah, let's talk about that ;-)
[14:23] <kenvandine> njpatel, nice work on the tabbar :)
[14:24] <njpatel> kenvandine, heh, thanks, going to pull out more stuff into sub-classes of TabBarItem tonight
[14:24] <njpatel> basically so we don't need that info in the stream view, allowing for a bit more flexibility in the way we present things
[14:24] <kenvandine> cool, i merged what you have
[14:25] <njpatel> kenvandine, had a question, though. Is it the "gwibber thing" to always have the text box visible, or could we hide it behind a button?
[14:25] <kenvandine> gwibber thing?
[14:25] <kenvandine> you mean preferred?
[14:25] <njpatel> kenvandine, like, is that one of the things people like, i mean
[14:25] <njpatel> kenvandine, yeah, sorry :)
[14:26] <kenvandine> when i tried to hide it by default some people said it wasn't discoverable
[14:26] <kenvandine> i kind of like it hidden though
[14:26] <njpatel> kenvandine, was it behind a button or behind the checkbox option inthe menu?
[14:26] <kenvandine> button
[14:26] <njpatel> wow, I must have missed that revision :)
[14:26] <kenvandine> it never made it to trunk
[14:27] <kenvandine> ryan was one of the people that didn't like it
[14:27] <kenvandine> however, a nice compromise would be a single line entry that expanded automatically
[14:27] <njpatel> okay, I'll play around a bit, though I think hiding it behind a button makes sleeker
[14:27] <njpatel> indeed
[14:27] <kenvandine> i was thinking single line entry with no account icons
[14:28] <kenvandine> and when the entry got focus, expand it to show the icons or some way to enable/disable
[14:28] <njpatel> right
[14:28] <kenvandine> but i am ok with a button too
[14:28] <njpatel> cool, I'll play around a bit and see what feels right, will push a few branches if nothing else so you can test
[14:28] <kenvandine> awesome
[14:33] <kenvandine> njpatel, seems all the tile resizing issues are fixed too, thx!
[14:34] <njpatel> yep, that should be better, though need to fix the calculation a bit so we always fill in the last space
[14:34] <njpatel> though that shouldn't be too hard to do
[15:07] <didrocks> logout/login. brb
[15:12] <seb128> rodrigo_, could you check on bug #788710?
[15:12] <ubot2> Launchpad bug 788710 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in exit()" [Medium,Confirmed] https://launchpad.net/bugs/788710
[15:14] <rodrigo_> seb128, yes
[15:16] <kinouchou> ello didrocks, seb128 and fredp
[15:17] <didrocks> hey kinouchou
[15:18] <seb128> lut kinouchou
[15:18] <seb128> rodrigo_, thanks
[15:35] <hrw> hi
[15:35] <hrw> how many of users are expected to use empathy with sip? 2% or less?
[15:40] <pitti> sip == ♥!
[15:44] <hrw> bug 797228
[15:44] <ubot2> Launchpad bug 797228 in empathy "Lack of SIP support after installation" [Undecided,New] https://launchpad.net/bugs/797228
[15:45] <hrw> pitti: SIP in empathy != ♥! rather
[15:45] <hrw> it takes time to find out which package you need to install to get it working
[15:47] <pitti> hrw: sofiasip? yes, it's not installed by default
[15:47] <hrw> and I wonder how many users are able to find it
[16:05] <cyphermox> seb128: mclasen: just tried 2.28.9 to make sure the issue with g_hash_table_foreach in nm-applet wasn't fixed, but no cake. the problem is, even compiling with --disable-debug as IIUC would disable the new checks for hash tables doesn't work
[16:06] <seb128> cyphermox, 2.29.8 you mean?
[16:06] <mclasen> cyphermox: a testcase is needed to make this a glib issue
[16:06] <cyphermox> right :)
[16:08] <bcurtiswx> hi
[16:09] <jibel> rodrigo_, ls -l /usr/lib/gnome-settings-daemon-3.0/ pasted, do you need something else ?
[16:14] <bcurtiswx> empathy 3.1.2 has a couple new features empathy-call (new call handler) which would require telepathy-farstream.  tp-logger supports calls now, which requires it to be built with call support.  empathy can now use libcheese (and your webcam) to create your avatar.  Do we want to ship empathy with those features?
[16:21] <rodrigo_> jibel, ok, looking
[16:24] <rodrigo_> jibel, hmm, can you please check which package does the gtk-modules belong to (dpkg -S /usr/lib/gnome-settings-daemon-3.0/gtk-modules) and what is in there?
[16:25] <pitti> jasoncwarner, Sweetshark, bryceh, chrisccoulson, didrocks, tremolux, Riddell, kenvandine, cyphermox, mterry, rodrigo_, seb128, tkamppeter, pedro_: meeting in 5 mins
[16:25] <tkamppeter> hi
[16:25] <jibel> rodrigo_, libatk-adaptor
[16:25] <mterry> w00t
[16:25] <rodrigo_> jibel, hmm
[16:25] <kenvandine> woot
[16:26] <cyphermox> ok
[16:26] <rodrigo_> jibel, can you please remove the package and see if you can replicate the bug without it?
[16:26]  * pedro_ waves
[16:26] <rodrigo_> pitti, almost ready :-)
[16:27] <pedro_> is the calendar showing the meeting at 16:30 utc for anybody else?
[16:27] <pedro_> calendar = fridge
[16:28] <seb128> can't say, I'm not using the fridge
[16:28] <charlie-tca1> pedro_: desktop team? yes, 16:30 UTC
[16:28] <seb128> it's 15:30utc
[16:28] <bcurtiswx> isn't it 15:30 UTC
[16:28] <seb128> it shifted with DST to stay on the same european, us time
[16:28] <pedro_> http://ubuntu-news.org/calendars/ <-
[16:29] <jibel> rodrigo_, it is not its fault. hggdh get the same crash without this package installed
[16:29] <seb128> the fridge didn't get updated I guess
[16:29] <pedro_> its saying 16:30 UTC, i'll contact the fridge folks to update it
[16:29] <seb128> jibel, when did that start?
[16:29] <seb128> pedro_, thanks
[16:29] <jibel> rodrigo_, lets continue after the meeting
[16:29] <rodrigo_> pedro_, yes, for me it shows it one hour late also
[16:29] <jibel> seb128, something like 2 weeks ago
[16:30] <seb128> ok, so not the recent gconf thing rodrigo fixes
[16:30] <seb128> es->ed
[16:30] <pitti> DING DING DING
[16:30] <seb128> hey!
[16:30] <pitti> https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-06-14
[16:30] <pitti> welcome everyone
[16:31] <pitti> jasoncwarner, Sweetshark, bryceh, chrisccoulson, didrocks, tremolux, Riddell, kenvandine, cyphermox, mterry, rodrigo_, seb128, tkamppeter, pedro_: meeting now
[16:31] <cyphermox> o/
[16:31] <rodrigo_> o/
[16:31] <didrocks> hey
[16:31] <mterry> \o
[16:31] <chrisccoulson> \o
[16:31] <kenvandine> \o
[16:31] <pedro_> o/
[16:31] <Sweetshark> o/
[16:31] <pitti> hm, nobody on the southern hemisphere doing /o ?
[16:31] <rodrigo_> :)
[16:31] <bcurtiswx> blame the volcano..
[16:32] <Sweetshark> at least no germans lifting the right arm.
[16:32] <tremolux> heyo
[16:32] <pitti> so, let's dive in with the partner update
[16:32] <kenvandine> woot
[16:32] <pitti> kenvandine, anything of news?
[16:33] <kenvandine> from dx all i have is gtk2shim thing we talked about last week, it is landing this week
[16:33] <pitti> oh, nice!
[16:33] <pitti> to recap, that'll make GTK 3 themes work with GTK2
[16:33] <kenvandine> yes
[16:33] <pitti> not the existing GTK2 theme with GTK3, right?
[16:33] <mterry> We have a GTK 3 theme?
[16:33] <pitti> that would have been my next q :)
[16:33] <kenvandine> mterry, no... don't get seb128 going :)
[16:34] <seb128> no we don't
[16:34] <mterry> :)
[16:34] <seb128> grrrrrrrr
[16:34] <seb128> ;-)
[16:34] <kenvandine> :)
[16:34] <pitti> kenvandine: how do they test that then, with adwaita?
[16:34] <kenvandine> moving onto U1
[16:34] <kenvandine> pitti, don't know... i'll find out thursday :)
[16:34] <seb128> pitti, dx...testing... no, those don't fit ;-)
[16:34] <kenvandine> U1 is working on this new shim thing that will pull U1 from a ppa, supposedly all of this was agreed to with the release team at UDS
[16:34] <kenvandine> seb128, lol
[16:35] <pitti> kenvandine: for stables? not... exactly
[16:35] <kenvandine> yes... i have asked them to double check everyone is OK with it
[16:35] <kenvandine> i wish i had been in that session
[16:35] <pitti> we discussed ways how to do intrusive U1 SRUs for stables, with new libraries (in private paths, etc.)
[16:36] <pitti> the "external PPA" option came up, but that won't work for shipping anything you like, as you would break other desktop stuff just the same way
[16:36] <pitti> except that a lot fewer people would actually test it
[16:36] <kenvandine> pitti, right, that was what freaked me out
[16:36] <kenvandine> they said Chipaca is circling back with the rt to confirm everyone is happy
[16:37] <kenvandine> so i assume plans will change
[16:37] <pitti> so we discarded that option
[16:37] <pitti> and said that the best course would be to bundle new libraries if they are required, and provide their own translations (at least temporary) in the .deb if they want to introduce new strings, until the langpacks catch up
[16:37] <kenvandine> pitti, i'll make sure everyone is happy with whatever solution they end up with before it gets uploaded
[16:38] <pitti> I don't see what a separate PPA woudl actually achieve, aside from circumventing our SRU/QA processes
[16:38] <kenvandine> pitti, right... :/
[16:38] <kenvandine> that is all i have
[16:38] <pitti> kenvandine: if you can follow up with them again, that'd be appreciated; they certainly shouldn't waste work on implementing such a "enable PPA" feature in the GUI
[16:39] <pitti> kenvandine: thanks! would you mind adding this to the wiki?
[16:39] <kenvandine> pitti, yeah... i got stuck in the pile of people with edit locks :)
[16:40] <pitti> kenvandine: thanks
[16:40] <pitti> didrocks: nice progress on unity! anything to discuss there, or with Qt?
[16:41] <didrocks> not really, I expect having a lot more info at the Qt contributor summit this week (so, don't expect me very online while travelling, from tomorrow until Saturday evening)
[16:42] <didrocks> really happy that the Qt bug is now workarounded and that Nokia people will work on it :)
[16:42] <didrocks> also, I didn't note on the wiki but we just released a new unity-2d
[16:42] <didrocks> (and I adapted my unify tool to unity-2d)
[16:42] <didrocks> that's it from me, all is written in the wiki
[16:43] <pitti> merci beaucoup
[16:43] <didrocks> if there is an unity SRU coming this week, seb128 will handle it
[16:43] <didrocks> mais de rien :)
[16:43] <pitti> tremolux: anything to discuss for s-c?
[16:43] <pitti> any news wrt. the qt and/or gtk3 ports?
[16:43] <pitti> or will we keep the gtk2 one for oneiric?
[16:44] <tremolux> I think we will still try for gtk3, but there is uncertainty because of the upcoming design changes
[16:44] <tremolux> but I don't want to rule it out
[16:44] <pitti> nice progress on desktop-o-software-center-ui!
[16:44] <tremolux> it may actually make it easier, depending on how much we actually need to reimplement
[16:45] <tremolux> ah, thx :)
[16:45] <pitti> ok, makes sense
[16:45] <pitti> thanks!
[16:45] <tremolux> sorry I can't be more conclusive at this point
[16:47] <pitti> no problem
[16:47] <pitti> so, some ramblings from me
[16:47] <pitti> first, CD space
[16:47] <pitti> we changed to live-builder, which actually won us some 5 MB
[16:47] <pitti> sad thing is that python3.2, the new mono, and libegl-mesa ate it all up, plus added some extra 10 MB, so that we are again oversized
[16:48] <pitti> I'd welcome some help with figuring out what changed in mono
[16:48] <pitti> python3.2 is "known", and the plan is to compensate it by dropping py 2.6 support from python-* packages
[16:49] <pitti> libegl-mesa is also "known", although of course it would be nice to not have both egl and gl on the CD, but that might not be realistic
[16:49] <pitti> chrisccoulson: ^ bad news for TB, I guess :/
[16:49] <achiang> tedg: ping, #691953 doesn't seem to have been fixed properly
[16:49] <didrocks> probably a stupid idea, but do we avoid already shipping in the live the *.pyc file? Would that win a little?
[16:49] <chrisccoulson> pitti - yeah :/
[16:49]  * mterry needs to get deja-dup on the CD before all space savings are spoken for
[16:50] <seb128> we might need to get clutter on the CD as well
[16:50] <seb128> oh and accountsservice when the mir is approved
[16:50] <pitti> didrocks: it would probably do, yes; do we actually have them there?
[16:50] <didrocks> pitti: not sure, I just synced the iso, just need to start it to check
[16:50] <pitti> grep '\.pyc' /var/lib/dpkg/info/*.list
[16:50] <pitti> the only hit is libglib2.0-dev.list, for gdbus-codegen
[16:50] <pitti> which looks like a bug
[16:51] <didrocks> pitti: will try and if there, will estimate the size
[16:51] <pitti> didrocks: merci
[16:51] <didrocks> hum, they aren't listed as it's in a trigger anyway
[16:51] <pitti> didrocks: it might be done at postinst time?
[16:51] <didrocks> yeah
[16:51] <seb128> it is yes
[16:51] <pitti> didrocks: right; I meant, if they would be shipped in the .debs, we can't just rm them; but like that we could
[16:51] <rodrigo_> accountsservice is small, afaik, but yes, will take up some space
[16:51] <didrocks> will check :)
[16:52] <pitti> rodrigo_: 67 kB, trivial,
[16:52] <seb128> clutter isn't trivial
[16:52] <pitti> *nod* :/
[16:52] <pitti> yay more libraries
[16:52] <pitti> but if we actually drop tomboy, then we could also drop gbrainy
[16:53] <pitti> and clutter, TB, and llvm (which we didn't even add yet) would fit
[16:53] <pitti> due to dropping mono
[16:53] <seb128> pitti, well that doesn't get ride of mono if we don't switch back to rhythmbox
[16:53] <tedg> achiang, What does it do?
[16:54] <seb128> we are in a meeting guys, can you move to ayatana? ;-)
[16:54] <achiang> oh, sorry
[16:54] <tedg> Oh, sorry
[16:54] <pitti> seb128: ah, I keep forgetting about banshee, right
[16:55] <pitti> anyway, this was mostly an FYI; if someone wants to look into the mono growth, you earned yourself a beer at the sprint :)
[16:55] <pitti> should be some 5 MB
[16:55] <pitti> so, over to work items
[16:56] <pitti> http://people.canonical.com/~platform/workitems/oneiric/canonical-desktop-team-oneiric-alpha-2.html doesn't look too happy
[16:56] <pitti> desktop-o-default-email-client didn't make any progress so far
[16:56] <pitti> chrisccoulson: is that just a matter of updating the WIs, or is this stuck upstream, or stuck at us getting space for it?
[16:56] <pitti> although the UI design/new features certainly aren't blocked
[16:57] <mterry> pitti, how come some beta-1 tasks show in that list?
[16:57]  * pitti will parallelize independent specs a bit to speed up the meeting, let's try that
[16:57] <chrisccoulson> pitti - i've been pretty busy with other stuff atm (like firefox 5 and dropping xulrunner)
[16:57] <pitti> kenvandine: desktop-o-gwibber-gtk3 also is at 0% still; does this need postponing?
[16:57] <kenvandine> i need to update it
[16:57] <kenvandine> it is progressing very nicely
[16:58] <seb128> mterry, like?
[16:58] <pitti> chrisccoulson: understood
[16:58] <chrisccoulson> pitti - some of those can be closed off fairly quickly though
[16:58] <pitti> chrisccoulson: I'm just asking because a lot of the WIs aren't actually your's
[16:58] <mterry> seb128, "Do an accessibility sweep" for deja-dup
[16:58] <mterry> I must have specified the beta badly in the blueprinmt
[16:58] <chrisccoulson> ie, i already have a fairly good idea on what to do with lightning now
[16:59] <chrisccoulson> i have a pretty good idea about how we're handling extension upgrades too
[16:59] <pitti> mterry: that's because it's not oneiric-beta-1, but ubuntu-11.10-beta-1
[16:59] <chrisccoulson> that seems to be the bulk of mine
[16:59] <mterry> ugg, thanks pitti
[16:59] <seb128> mterry, the blueprint milestone is alpha2 too
[16:59] <pitti> mterry: and it doesn't try to recognize unknown milestones, it just adds them to the default spec milestone (which is a2)
[16:59] <seb128> pitti, can you have items after the spec milestone?
[16:59] <pitti> seb128: yes
[16:59] <pitti> the spec milestone is just the default
[16:59] <seb128> ok, great ;-)
[16:59] <pitti> but you need to spel it crrorectyl :)
[17:00] <pitti> chrisccoulson: ok, thanks; so it seems a whole lot of them will be closed in one go :)
[17:01] <chrisccoulson> pitti - yeah. there seems like a lot, but there's not much work in most of those
[17:01]  * pitti feels a bit relieved :)
[17:01] <pitti> mterry: desktop-o-deja-dup-default is the third-biggest
[17:02] <mterry> pitti, blocked on MIR
[17:02] <pitti> but we just covered that
[17:02] <mterry> didrocks, got MIR cycles?
[17:02] <pitti> i. e. some WIs aren't for a2
[17:02] <mterry> that too
[17:02] <pitti> so the remaining ones are trivial, once the MIRs get approved
[17:02] <pitti> so that's all fine
[17:02] <didrocks> mterry: not really, already have done a lot recently, and I won't be there until eow, after, it should be ok :)
[17:02] <mterry> didrocks, np, I'll bug doko
[17:02] <seb128> speaking about mir, rodrigo_ how is the accountsservice one going? it's blocking the gdm update
[17:03] <pitti> https://launchpad.net/ubuntu/+spec/desktop-o-accessibility-ubiquity is a huge one, but should be handled in the Eastern edition
[17:03] <pitti> TheMuso: ^
[17:03] <rodrigo_> seb128, got part of it done, will finish it today or tomorrow, I hope
[17:03] <pitti> a-s needs some code fixes
[17:03] <seb128> rodrigo_, ok thanks, feel free to update the bug with upstream bug numbers if you get some
[17:03] <rodrigo_> yes
[17:04] <seb128> thanks
[17:04] <didrocks> rodrigo_: and reassign me to it, please :)
[17:04] <rodrigo_> didrocks, ok, will do
[17:05] <didrocks> thanks
[17:05] <pitti> and finally, https://launchpad.net/ubuntu/+spec/desktop-o-libreoffice-packaging is still at 0% as well
[17:05] <pitti> Sweetshark: ^ is this blocked on an actual upstream release of 3.4.0/3.3.3?
[17:05] <Sweetshark> yes, actually some of the packaging is already ongoing, but there wont be release before debian.
[17:06] <Sweetshark> it seems like 3.4.0 will soon see a debian release (I saw a changelog entry commit today)
[17:07] <pitti> Sweetshark: do you think it's realistic for a2 (i. e. by start of July), or sohuld we move it?
[17:07] <Sweetshark> 3.3.3 isnt released yet upstream, but hasnt seen much activity since 3.3.2 (for LO that is), so should not be too problematic.
[17:08] <Sweetshark> we will have some 3.4.0 and 3.3.3 release by start of July.
[17:08] <pitti> ok, thanks for the heads-up
[17:08] <pitti> that's it from me
[17:08] <seb128> will 3.4 stop using gnome-vfs in that -gnome binary? ;-)
[17:09] <seb128> pitti, I've some topics I would like to discuss
[17:09] <pitti> seb128: go ahead
[17:09] <seb128> first, indicator on GTK3
[17:10] <seb128> is that moving?
[17:10] <seb128> out of creating issues like that gtk2, gtk3 mixed symbols bug you reassigned today that's something we should start landing and testing
[17:10] <seb128> kenvandine, mterry:^ where do we stand?
[17:10] <seb128> can we distro patch mterry's work and dual build even if dx is behind?
[17:10] <mterry> Most indicators are ported (datetime is only exception I can remember)
[17:10] <mterry> They don't have upstream releases yet
[17:11] <mterry> So thus aren't packaged
[17:11] <seb128> do we need some? if we do what is blocking them?
[17:11] <kenvandine> seb128, perhaps
[17:11] <seb128> kenvandine, I will not take perhaps as an answer :p
[17:11] <kenvandine> seb128, we should be getting releases for some of them this thursday
[17:11] <kenvandine> so depending on what doesn't get released, i'll look at distro patching
[17:11] <mterry> seb128, we can distro patch anything!  :)
[17:11] <kenvandine> and talk to ted about those
[17:12] <kenvandine> mterry, yeah, that is what we do!
[17:12] <Sweetshark> seb128: I will check for that gnome-vfs stuff when I get around to it.
[17:12] <kenvandine> :-D
[17:12] <seb128> kenvandine, it doesn't need to be you doing the work
[17:12] <seb128> Sweetshark, thanks
[17:12] <mterry> I'm actively working on datetime, but it's a bit more involved
[17:12] <kenvandine> seb128, i'll figure out what is left standing after thursdays uploads
[17:12] <seb128> mterry, right, I wouldn't stop on dx, they have their schedule and don't care much about oneiric
[17:12] <mterry> Needs a new widget from GTK 3.1.4 which just got into oneiric
[17:12] <seb128> we might still be sitting there in a month if we wait on them
[17:12] <seb128> kenvandine, ok, thanks
[17:13] <seb128> let's wait on thursday and start distro patching after that
[17:13] <kenvandine> seb128, tedg's goal is to have them all in oneiric with gtk3 builds by the sprint
[17:13] <seb128> mterry, ^ works for you?
[17:13] <seb128> kenvandine, great
[17:13]  * kenvandine is going to install oneiric on tedg's laptop when he isn't looking in dublin
[17:13] <mterry> seb128, in terms of finishing datetime?  sure
[17:13] <kenvandine> someone buy him beer to distract him
[17:14] <seb128> ;-)
[17:14] <seb128> mterry, well, no need to finish, but starting to land the dual build libs, etc in the next week
[17:14] <seb128> ok
[17:14] <seb128> that was my topic1
[17:15] <seb128> on a side note I just uploaded gtk+ 3.1.6 in the ubuntu-desktop ppa if somebody needs it
[17:15] <seb128> there is some theming issue, gnome-standard-themes need to be updated with it, I will start testing that soon
[17:15] <pitti> seb128: the theming issue is introduced in 3.1.6, not in 3.1.4 yet?
[17:15] <pitti> (i. e. that's why ppa, not oneiric?)
[17:15]  * tedg has never been happier to not like beer... and starts researching BIOS locking in EFI.
[17:15] <seb128> there is some new deprecations in that version
[17:15] <seb128> pitti, right
[17:16] <seb128> i.e GtkHBox GtkVBox got deprecated in favor of GtkBox
[17:16] <kenvandine> tedg, ;-D
[17:16] <seb128> I will send an email to the list about those
[17:16] <seb128> glib deprecated G_CONST_RETURN as well
[17:17] <seb128> (you should just use "const" instead)
[17:17] <kenvandine> seb128, did you update the ~ubuntu-desktop branch for gtk3?
[17:17] <seb128> kenvandine, not pushed yet, I'm still working on it
[17:17] <seb128> kenvandine, but after the end of the meeting I will do it
[17:17] <kenvandine> ok, i did push that patch cimi wanted there right?
[17:17] <seb128> I did delete it
[17:17] <seb128> it's in the new version
[17:17] <kenvandine> ok
[17:17] <seb128> I told you to not bother :p
[17:17] <seb128> anyway
[17:17] <kenvandine> i was just wanting to check that :)
[17:18] <seb128> topic 3
[17:18] <kenvandine> seb128, yeah... he really wanted it
[17:18] <seb128> cheese won dependency on clutter, clutter-gst, clutter-gesture, mx
[17:18] <seb128> totem git switched from gst to clutter-gst for its video rendering
[17:18] <seb128> so we will need to figure how well clutter-gst works for us
[17:19] <seb128> and to make space on the CD for those
[17:19] <seb128> that's just an note so people know about it and can raise concern if they have any
[17:19] <seb128> we should probably figure how to test how well that stack work for i.e video rendering on the platform and video drivers we support
[17:19] <kenvandine> seb128, i thought cheese got removed from the CD?
[17:20] <kenvandine> seb128, empathy can now use libcheese to take avatar photos
[17:20] <seb128> kenvandine, ubiquity will bring it back in, they plan to use libcheese-gtk to get your picture
[17:20] <kenvandine> ah
[17:20] <seb128> empathy as well
[17:20] <kenvandine> so i guess we can enable that :)
[17:20] <seb128> they plan to use libcheese also for camera detection and maybe some other things
[17:20] <kenvandine> bcurtiswx and i were just discussing that
[17:20] <seb128> well, I'm still not sold on bringing clutter on the CD :p
[17:20] <seb128> but yeah we will likely need it
[17:20] <kenvandine> hehe
[17:21] <pitti> libcheese itself is tiny
[17:21] <pitti> but clutter is rather big
[17:21] <kenvandine> i hope libcheese doesn't suck in clutter
[17:21] <seb128> it does
[17:21] <kenvandine> sigh
[17:21] <seb128> it brings in libclutter-gst and libclutter
[17:21] <pitti> will the next cheese introduce a clutter dependency to libcheese-gtk18 itself, or "just" to the apps?
[17:21] <seb128> pitti, the lib
[17:21] <pitti> ok, just answered
[17:21] <kenvandine> pitti, fun times...
[17:22] <seb128> indeed :-(
[17:22] <kenvandine> poor chrisccoulson
[17:22] <seb128> ok
[17:22] <seb128> another sort of items
[17:22] <pitti> poor CDs
[17:22] <kenvandine> the universe is fighting against TB
[17:22] <rodrigo_> :)
[17:22] <pitti> we never ever drop libraries, it seems :/
[17:22] <hrw> bye
[17:22] <seb128> I suggested to drop tomboy out of the CD at least until it's ported to recent apis
[17:22] <pitti> +1
[17:22] <rodrigo_> how much space that would save?
[17:22] <seb128> it's the only thing keeping libgnome libgnomeui libbonobo libbonoboui libgnomevancas on the CD
[17:23] <seb128> rodrigo_, like 1mb, but it would allow to drop that stack of old libraries from the CD
[17:23] <seb128> which is my main driver right now
[17:23] <seb128> it's easy to reinstall and users upgrading will still get it
[17:23] <rodrigo_> ok, not much, but yes, we should get rid of those libs
[17:23] <seb128> we can bring it back later if it switches to gsettings
[17:24] <pitti> it also uses the libndesk-dbus stuff which banshee doesn't, so perhaps more
[17:24] <seb128> but seeing that we have no binding near to land for that
[17:24] <seb128> ok
[17:24] <seb128> let's make it a team meeting decision?
[17:24] <seb128> is somebody against dropping tomboy from the CD for now?
[17:24] <kenvandine> +1
[17:24] <seb128> I will email the lists about it
[17:24] <rodrigo_> not me
[17:24] <pitti> and banshee, while we are at it *cough*
[17:25] <dobey> pitti: +1
[17:25] <pitti> no, let's discuss that more thoroughly
[17:25] <seb128> pitti, well, once we are there we can argue switching back to rhythmbox to claim the mono space
[17:25] <seb128> rb is already on GTK3 as well which is another win ;-)
[17:25] <pitti> it's got the same problem, not ported to gtk3 etc.
[17:25] <seb128> but yeah, another topic
[17:25] <pitti> which rb is
[17:25] <pitti> right
[17:25] <pitti> we can also announce it well
[17:25] <seb128> ok, nobody objected for tomboy
[17:25] <dobey> then fixing libu1 will be an easier task for me :)
[17:25] <pitti> "the default music player is now much faster to start, and uses less RAM"
[17:26] <seb128> ;-)
[17:26] <seb128> ok
[17:26] <seb128> that was it from me
[17:26] <seb128> sorry for all the extra topics
[17:26] <pitti> ok, thanks everyone! I need to run out now, bbl
[17:27] <pitti> seb128: no worries, thanks for covering them
[17:27] <seb128> thanks
[17:27] <tremolux> good day all!
[17:27] <ricotz> what is up with transmission which would need a new libevent
[17:28] <didrocks> thanks everyone :)
[17:28] <seb128> ricotz, if you figure tell us, I've been trying to ping kklimonda^ about it from some weeks but didn't get a reply
[17:28] <ricotz> seb128, i made a new sync request and saw the expired old one later
[17:29] <ricotz> it seems he built the stack in a ppa which worked quite well except 4 packages
[17:29] <ricotz> so just syncing it in this early stage might be worth it and figure out the res
[17:29] <ricotz> t
[17:30] <ricotz> https://bugs.edge.launchpad.net/ubuntu/+source/libevent/+bug/701471
[17:30] <seb128> ricotz, right, I didn't follow on the libevent transition, I just know if was late previous cycle to do it
[17:30] <ubot2> Ubuntu bug 701471 in libevent "Sync libevent 2.0.10 from Debian experimental" [Wishlist,Expired]
[17:30] <ricotz> https://bugs.launchpad.net/ubuntu/+source/libevent/+bug/796187
[17:30] <ubot2> Ubuntu bug 796187 in libevent "Sync libevent 2.0.10-stable-1 (main) from Debian experimental (main)" [Undecided,New]
[17:30] <seb128> that's probably a topic for the ubuntu-devel list though
[17:31] <ricotz> seb128, and this doesnt look that bad: https://launchpad.net/~kklimonda/+archive/libevent2
[17:31] <seb128> well I still would like to check with kklimonda^
[17:31] <ricotz> yeah, sure
[17:38] <kklimonda^> ricotz, seb128: libevent transition should be pretty safe, at least for main packages - I think other than transmission only memcached uses it, and it has been tested "in the wild". Unfortunately, as seb128 has noticed I'm recently not a very reliable person to work with - too much things happening left me with no room to work on "random" stuff.
[17:39] <seb128> kklimonda^, ricotz: could one of you drop an email to ubuntu-devel maybe about that? just to know if somebody has an issue doing the update
[17:39] <seb128> do you know if Debian plans to land it to unstable?
[17:39] <seb128> why is it still in experimental?
[17:42] <kklimonda^> seb128: they didn't finish the transition, three packages FTBFS (or they did when I tried rebuilding them before natty release). I know that debian maintainer has been interested in doing the transition too, I guess it's a problem of not enough hands to do that.
[17:43] <seb128> kklimonda^, ok
[17:44] <seb128> kenvandine, gtk3 update pushed to the vcs but not uploaded yet
[17:48] <rodrigo_> ok, going out for a bit, later all
[18:02] <achiang> seb128: i'm looking for pointers on how to modify the help displayed by yelp; do you have any pointers? specifically, i want to add a new link to a PDF on disk...
[18:03] <seb128> achiang, no I don't sorry, I didn't look much at the new format, maybe try emailing robert_ancell about it?
[18:03] <achiang> seb128: ok, thanks. i will email robert_ancell (i only asked since i saw your name in the changelog, but i guess that was pretty minor)
[18:04] <achiang> seb128: ps, i'm hacking on a lucid branch, not anything recent
[18:04] <seb128> achiang, the startpage layout was an ubuntu patch back then
[18:04] <micahg> achiang: j1mc might be able to help with that, he's a docs guy
[18:05] <achiang> seb128: got it
[18:05] <seb128> ok
[18:06] <achiang> micahg: good tip, any clue where he might hang out?
[18:06] <seb128> kenvandine, do you need the new gtk in oneiric for anything? I think it's ready for upload but I will run it for a bit still before uploading
[18:06] <micahg> seb128: would it be possible to drop the gnome-panel recommends from alacarte? it's pulling in a lot of GNOME stuff in xubuntu, debian 603013 partially addresses this
[18:06] <ubot2> Debian bug 603013 in alacarte "alacarte: spurious dependency on gnome-menus" [Normal,Open] http://bugs.debian.org/603013
[18:06] <micahg> achiang: maybe #ubuntu-docs?
[18:07] <achiang> micahg: duh. :) thanks
[18:07] <seb128> micahg,
[18:07] <seb128>   * Reintroduce gnome-panel recommendation, it’s actually needed for
[18:07] <seb128>     gnome-desktop-item-edit. Closes: #592639.
[18:07] <seb128> in the changelog
[18:07] <seb128> debian bug #592639.
[18:07] <ubot2> Debian bug 592639 in alacarte "alacarte: IImpossible to open Properties dialogue of any entry, or new menu, new entry." [Important,Fixed] http://bugs.debian.org/592639
[18:07] <seb128> micahg, seems like the recommends is right, should almost be a depends?
[18:08] <seb128> micahg, seed gmenu-simple-editor and drop alacarte from xubuntu I guess?
[18:09] <micahg> seb128: shouldn't the depends/recommends be the other way then gnome-panel recommends/depends alacarte?
[18:09] <seb128> ?
[18:09] <seb128> micahg, the alacarte buttons are calling a gnome-panel binary
[18:09] <micahg> gnome-desktop-item-edit is in gnome-panel, not alacarte
[18:10] <seb128> so alacarte depends on gnome-panel because it needs that binary
[18:10] <micahg> oh :(
[18:10] <seb128> right
[18:10] <micahg> seb128: ok, thanks for the recommendation, I'll propose that instead
[18:10] <seb128> you're welcome
[18:12] <micahg> seb128: I can't find that package, do we not have it?
[18:12] <seb128> it's a gnome-menus binary
[18:13] <micahg> ah, ok, small and minimal depends
[18:22] <micahg> is there a plan to update the rhythmbox u1 store?  it seems to be blocking the upgrade of RB on oneiric
[18:30] <kenvandine> seb128, i think just for the scrollbars
[18:37] <seb128> micahg, uninstall u1
[18:38] <seb128> dobey said they don't want to deal with having 2 versions of gtk so they are staying on the same one as the default player which is still on gtk2 where rb is on gtk3
[18:38] <micahg> seb128: so, shouldn't the package be dropped from the archive then?
[18:39] <dobey> we will update the u1 store
[18:39] <micahg> or are you waiting on the to see what happens re cd spce
[18:39] <dobey> banshee upstream is committed to moving to gtk3, but i don't know what the status is right now
[18:39] <seb128> dobey, it's likely that we will have both on different gtk version by oneiric
[18:39] <dobey> but i'm happy to swtich back to rb as default :)
[18:39] <seb128> dobey, you should have 2 version of libuntuone
[18:40] <seb128> one for gtk2 and one for gtk3
[18:40] <seb128> or dual build the lib or something
[18:40] <dobey> the lib should compile on both already, afaik. i don't know of anything specifically that wouldn't work. but it's still very early and i'd rather avoid doing a lot of work for something and throwing it away in a month
[18:41] <seb128> well dual building a lib is like an hour work
[18:41] <seb128> it's not a lot of work ;-)
[18:42] <seb128> but fair enough, you can do that in a month if still required
[18:42] <dobey> well if you guys make the decision to drop banshee for rb, and get rid of mono from the CD, then it would also be wasted work :)
[19:48] <seb128> cyphermox, oh, well done on the n-m bug ;-)
[19:49] <cyphermox> seb128: meh
[19:49] <cyphermox> took far too long
[19:49] <cyphermox> plus I looked at the piece of code they changed at least twice, thinking it could be the issue, but the logic seemed sound :P
[19:50] <cyphermox> anyway, thanks.
[19:50] <cyphermox> I'm testing it now, seems to work, so I'll upload in a minute
[19:58] <pitti> good night everyone!
[20:00] <tremolux> 'night pitti
[20:01] <seb128> 'night pitti
[21:40] <chrisccoulson> does "apt-get upgrade" pull in new recommeds?
[21:41] <chrisccoulson> pitti - bug 797051 - someone without translations after upgrading :(
[21:41] <ubot2> Launchpad bug 797051 in firefox "firefox no longer localised after enabling -proposed" [Undecided,Incomplete] https://launchpad.net/bugs/797051
[22:39] <lifeless> bryce: your wish is my screen-grab https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/785497
[22:39] <ubot2> Ubuntu bug 785497 in xserver-xorg-video-intel "remnants of window getting left behind when apps quit" [Undecided,New]
[22:50] <bryce> lifeless, bit more background in the description couldn't hurt.  when's it occur, how repeatable, when did it start, etc. etc.
[22:50] <bryce> what stuff have you tested so far, etc.
[22:50] <lifeless> bryce: I can't trigger it, it just happens
[22:52] <bryce> lifeless, 100% of the time?
[22:52] <lifeless> bryce: no
[22:52] <lifeless> sporadic
[22:54] <bryce> lifeless, anything else you can provide?  bug's non-actionable right now I'm afraid
[22:54] <lifeless> more screenshots ?
[22:54] <bryce> sure
[22:54] <lifeless> there -may- be a correlation with uxterm
[22:55] <lifeless> I haven't been terribly rigorous with my data gathering
[22:55] <bryce> I can upstream it... but to be honest most bugs like this that are just described as "random screen corruption" don't tend to go anywhere
[22:55] <lifeless> it -always- seems to be the borders of the windows
[22:55] <bryce> ok
[22:56] <lifeless> specifically I think its the bit that metacity(?) makes into a white-black-white bounding box when you hit alt-tab
[22:56] <bryce> you could also try describing what happens after.  E.g. some of these bugs you move a window and it redraws.  Other times the corruption is "permanent" or "mostly permanent", or goes away on vt switch
[22:57] <lifeless> dropping a window on top of the remnants replaces them and then its fine for a while
[22:57] <bryce> there was one (which I've reproduced) which would correct itself if metacity was restarted (thinking that one might be a metacity bug...  I can't seem to find it in Launchpad anymore though)
[23:00] <bryce> aha, https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/654768
[23:00] <ubot2> Ubuntu bug 654768 in xorg-server "compositor produces artefacts starting in maverick" [High,Confirmed]
[23:01] <bryce> different issue, but might be worth checking if restarting metacity makes it go away
[23:02] <bryce> lifeless, also you should indicate whether or not you've tested with a different wm like compiz and if so, whether you could reproduce it there.  At this point we can't tell whether it's a driver issue or bug in the window manager
[23:02] <lifeless> actually, am I on oni? I'm not Its natty.
[23:02]  * lifeless headdesks
[23:02] <lifeless> every time I said o* read n*
[23:02] <bryce> if it only affects window borders, that sounds like it could be wm-specific.  hard to say though, could be some driver bug underneath
[23:03] <lifeless> whats another 2d wm ?
[23:03] <bryce> compiz
[23:04] <bryce> like, um... compiz --replace I think
[23:04] <lifeless> ok
[23:04] <lifeless> and to switch back ?
[23:04] <bryce> metacity --replace I believe
[23:04] <bryce> if I'm wrong, someone on this channel will correct me, I'm sure
[23:05] <bryce> lifeless, or other thing to try would be to kill metacity and let it restart (or manually restart it).
[23:06] <lifeless> heh
[23:06] <bryce> if that does not clear the corruption, then it's definitely an X bug.  If it does clear it, it may still be an X bug underneath but maybe metacity's wrong.
[23:07] <lifeless> so compiz has wedged my UI
[23:07] <lifeless> I'm just going to try and get metacity back now :)
[23:08] <lifeless> right, back
[23:08] <lifeless> ok, will kill and restart metacity next time it happens
[23:08] <bryce> alright
[23:09] <bryce> lifeless, toss your .xsession-errors on the bug report on the off chance there's a relevant error message.
[23:12] <lifeless> uploading now
[23:12] <bryce> lifeless, ok quick question now for you...
[23:13] <bryce> lifeless, on https://dev.launchpad.net/LEP/DerivativeDistributions the first item under Constraints...  whereabouts in process is that item?  does it have an eta yet?
[23:13] <bryce> "Ability to sync packages from the parent series, some auto, some manual, optionally rebuilding them "
[23:19] <lifeless> well
[23:19] <lifeless> we're a few weeks away from derived distros
[23:19] <lifeless> so not long now
[23:22] <bryce> lifeless, ok thanks
[23:23] <bryce> lifeless, I assume after it's started it'll be a few months for implementation before it goes live?
[23:25] <lifeless> bryce: I was talking until it goes live
[23:31] <bryce> lifeless, ah, excellent