[01:21] <DBO> sooo I need another release of bamf
[01:21] <DBO> yay
[01:39] <RAOF> DBO:  Do you test external monitor support on netbooks?  How much of a performance penalty is going over the max gl texture size expected to exact?
[01:39] <RAOF> Because today's empyrical testing suggests the answer is "at least one order of magnitude" :)
[01:40] <DBO> RAOF, going over the max gl texture size should just break it
[01:40] <DBO> period
[01:40] <DBO> it shouldn't run
[01:40] <RAOF> Well, then!  Rejoice!  It runs.
[01:40] <DBO> how?
[01:41] <RAOF> At roughly 30seconds per frame, but it runs.
[01:41] <DBO> seriously how?
[01:42] <RAOF> Dunno.  Any way for me to get unity to tell me?
[01:42] <DBO> Im baffled
[01:42] <DBO> you sure glxinfo says you exceeded it?
[01:42] <RAOF> It complains a bunch about windows unmappable to textures, but displays everything correctly.
[01:43] <RAOF> GL_MAX_TEXTURE_SIZE= 2048, a 1920x1200 monitor + a 1024x600 monitor.  Stacked one above the other it works fast, stacked one next to the other it's interestingly slow.
[01:44] <DBO> RAOF, it must be falling back to copy mode
[01:44] <DBO> which is SLOW
[01:44] <DBO> so yes
[01:44] <DBO> exceeding max texture size is bad
[01:44] <DBO> very bad
[01:45] <RAOF> Yes.
[01:45] <DBO> is your desktop rendering?
[01:46] <RAOF> I'm not sure, let me check...
[01:46] <RAOF> (I'm obviously not IRCing on the netbook, or you'd see a 1 minute latency on anything I typed :))
[01:46] <DBO> RAOF, you have dual monitors set up?
[01:47] <DBO> lp:~unity-team/unity/unity.alt-tab-follow-monitor
[01:47] <DBO> can you confirm that branch makes alt-tab follow monitors for you
[01:47] <DBO> I am concerned it wont work right on xrandr systems
[01:48] <Sarvatt> RAOF: whys that a surprise? 1900 pixels < 2048, 2944 > 2048. meanwhile 8 year old netbook gpu's suck but they are supposed to be certified with ubuntu
[01:51] <DBO> having australians in the company is incredibly helpful
[01:51] <DBO> I can force them to test my work when my coworkers are off hours
[01:52] <RAOF> Sarvatt: I'm surprised that it *works*
[01:52] <RAOF> Or, rather, works at all.
[01:53] <RAOF> "Works" might be overselling it somewhat.
[01:53] <DBO> RAOF, seriously though, can you confirm the fix on xrandr systems?
[01:53] <Sarvatt> yeah i915 started falling back to unaccelerated mid maverick
[01:53] <DBO> (I only got nvidia)
[01:53] <RAOF> Yeah, I will.
[01:53] <DBO> Sarvatt, is that it?
[01:53] <DBO> its using software rendering
[01:53] <Sarvatt> you can get 4096x4096 but anything over 2048x2048 is completely unaccelerated
[01:54] <Sarvatt> too slow to be usable :(
[01:54] <DBO> Sarvatt, does that apply to ATI as well?
[01:54] <RAOF> Especially on the poor little atom netbook.
[01:54] <Sarvatt> nope depending on how far back you're going
[01:54] <Sarvatt> the atom gpu's are 8 years old
[01:54] <Sarvatt> i mean like r500+ can do 4096x4096 fine
[01:54] <DBO> no I mean
[01:54] <Sarvatt> anything in the past 5-6 years is fine
[01:54] <DBO> do they have a "fallback" size
[01:54] <Sarvatt> not that i know of
[01:54] <DBO> okay
[01:55] <DBO> ATI HD2600 is getting similar crap performance reports
[01:55] <DBO> with dual monitor
[01:55] <DBO> fglrx is fast with it
[01:59] <Sarvatt> thats really odd outside of ati being slow with web browser scrolling in general because of EXA, they dont have anything like intels gen3 unaccelerated once you go past 2048x2048 that i know of
[02:00] <DBO> I am going to get more feedback on it today from the reporter
[02:01] <DBO> but we shall see
[02:04] <RAOF> DBO: Does that branch require a newer nux?
[02:04] <DBO> RAOF, yes
[02:05] <Sarvatt> the alternative on intel was not working at all >2048x2048 like lucid and before, 4096x4096 works on the netbooks with a 2D session at least acceptably.. we have a crapload of machines that cant be certified with ubuntu because compiz works like crap with an external monitor plugged in with gnome defaulting to rightof even though its a hardware limitation and would work ok above or below
[02:06] <DBO> I am thinking of methods of rendering it top/bottom
[02:06] <DBO> but having the layout be left/right
[02:06] <DBO> Im not sure its possible sadly
[02:07] <RAOF> DBO: I just need to pull nux trunk?
[02:07] <DBO> RAOF, yes
[02:08] <DBO> once desktop team told us so long as old unity works on newer nux, and it doesn't matter if newer unity doesn't work on older nux
[02:08] <DBO> a whole new world of fucking around opened up
[02:11] <RAOF> Sweet.  A whole new world of C++ compiling opens up.
[02:11] <DBO> YEP!
[02:12] <RAOF> Man, I hope that core is retracable.  32 frames of ?? leading into HandleEvent.
[02:13] <DBO> wewt
[02:15] <Sarvatt> RAOF: incoming http://sarvatt.com/downloads/gdb.txt
[02:17] <DBO> Sarvatt, how did you do that?
[02:17] <DBO> Sarvatt, that is REALLY old?
[02:17] <Sarvatt> yeah REALLY old
[02:18]  * smspillaz only sees capital letters
[02:19] <smspillaz> Sarvatt: we have a plugin to get around the max texture size limitations
[02:19] <smspillaz> Sarvatt: it's called 'Copy To Texture'
[02:19] <DBO> mesa kinda does that for you now smspillaz
[02:19] <smspillaz> DBO: realy ?
[02:19] <DBO> on intel yeah
[02:20] <RAOF> For sufficiently loose values of ?kinda?.
[02:20] <DBO> yes
[02:20] <smspillaz> DBO: it creates multiple textures with correclty offset tex-coord matrices and vertex lists ?
[02:20] <smspillaz> errrrrrrrrrrrrrrrrrrr
[02:20]  * smspillaz thinks that functionality is on the wrong layer
[02:21] <DBO> it boosts the max texture size from 2048 to 4096
[02:21] <desrt> smspillaz: weird.  your comment reminded me of a random half-dream thought i had while waking up this morning
[02:21] <DBO> at the cost of performance
[02:21] <smspillaz> DBO: ok, that's not a real solution
[02:21] <Sarvatt> sorry that was just an example of me going, how much bigger could this possibly get once i get debug symbols installed? and having it be 2.8mb of repeating info a long time ago :)
[02:21] <desrt> smspillaz: which is that the UN classified capslock as a crime against humanity
[02:21] <RAOF> No.  It falls back to software rendering, providing an astounding 30 sec/frame performance.
[02:21] <smspillaz> desrt: +1
[02:21] <DBO> desrt, +1
[02:21] <smspillaz> DBO: ok, I don't call that 'mesa doing it for you'
[02:21] <RAOF> Bah!
[02:22] <DBO> smspillaz, I only mean to say, it doesn't crash
[02:22] <smspillaz> DBO: I call that 'don't ever let mesa do that'
[02:22] <smspillaz> DBO: it didn't crash before
[02:22] <smspillaz> DBO: you just get a white texture
[02:22] <smspillaz> or rather
[02:22] <smspillaz> you don't get a texture at all
[02:22] <RAOF> DBO: I think that ?works? on my xrandr system.  Is it really meant to pop up the alt-tab switcher on the display with currently focused window?
[02:22] <DBO> well now you do
[02:22] <smspillaz> it only crashed because we had a distro patch which would assert and fall back to metacity whenever a texture failed to bind
[02:23] <DBO> RAOF, or where you mouse is kind of yes
[02:23] <smspillaz> DBO: it doesn't crash, I tried it just now
[02:23] <DBO> RAOF, its supposed to follow your workflow in general yeah...
[02:23] <smspillaz> DBO: make a test app that creates a 10,000x10,0000 window
[02:23] <smspillaz> it won't crash
[02:23] <DBO> smspillaz, cheeze it
[02:23] <smspillaz> DBO: ???
[02:24] <smspillaz> RAOF: DBO: Sarvatt: in any case, we should enable copytex by default. There's not reason not to have it and it only kicks in whenever tfp fails
[02:24] <Sarvatt> slow > white texture, but its still not usable and quite a lot of netbooks aren't getting shipped with ubuntu because of it. almost wish falling back to metacity was still an option because that would have passed certification :)
[02:24] <smspillaz> why not just enable copytex ?
[02:25] <smspillaz> it's much faster than software mode and you don't get white textures
[02:25] <RAOF> DBO: In that case, it doesn't seem to work.  It seems to pop up on the display with the currently focused window, and I find that pretty awkward.
[02:25] <smspillaz> the only thing is that if you create huge windows they will get nontransparent decorations
[02:25] <RAOF> DBO: Is there any way that you could just pop it up on *all* connected displays?
[02:26] <smspillaz> and support for window-based decorations is a little flaky at the moment
[02:26] <DBO> RAOF, how would you prefer it to work other than what you just said
[02:26] <Sarvatt> is that done automatically? as it is now if you plug in an external monitor in unity its "unusably" slow according to the people doing the certification
[02:26] <smspillaz> but with P it should be better
[02:26] <smspillaz> Sarvatt: no, at the moment it probably just falls back to software mode
[02:26] <RAOF> DBO: I'd prefer it to appear on the display the mouse is on; that's generally where my focus is.
[02:27] <DBO> smspillaz, how do I get the display where the mouse is in compiz?
[02:27] <smspillaz> DBO: screen->outputForPoint (CompPoint (pointerX, pointerY));
[02:28] <smspillaz> or something like that
[02:28] <smspillaz> RAOF: the old alt-tab did it based on what window currently has focus
[02:28] <DBO> so I have to first query the mouse position
[02:28] <smspillaz> DBO: no, you don't
[02:28] <RAOF> smspillaz: And I hated that, too :)
[02:28] <smspillaz> it will be updated enough to guaruntee that its in the right spot
[02:28] <smspillaz> DBO: it updates every time you enter a window
[02:29] <smspillaz> RAOF: IMO, having it where the cursor is doesn't make much sense. maybe it should be based on timestamps
[02:29] <smspillaz> eg, when you move the cursor, its timestamp is the most up to date the cursor takes priority
[02:29] <RAOF> Frankly, I think it should be on *all* connected displays.
[02:30] <RAOF> It's a desktop-wide action.
[02:30] <smspillaz> otherwise the thing with the last updated  _NET_USER_TIME takes priority
[02:30] <RAOF> That would also work, yes.
[02:30] <RAOF> Probably.
[02:30] <RAOF> :)
[02:30] <DBO> RAOF, hold on a moment
[02:31] <smspillaz> RAOF: the context switch is already massive enough when you hit alt-tab since the thing is huge
[02:32] <DBO> RAOF, okay pull
[02:32] <RAOF> :(.  A retraced backtrace nets us exactly 3/68 frames that aren't ??
[02:33]  * smspillaz goes back to his uni assignment
[02:33] <smspillaz> due in ..... 6 hours
[02:34] <DBO> RAOF, once you test and confirm it works for you
[02:34] <DBO> please leave a comment here https://code.launchpad.net/~unity-team/unity/unity.alt-tab-follow-monitor/+merge/76667
[02:35] <RAOF> Just an "it works"?
[02:36] <DBO> yes
[02:36] <DBO> provided
[02:36] <DBO> it works
[02:42] <RAOF> Ah!  *That's* what the assert is.compiz: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr<T>::operator->() const [with T = UnityFBO]: Assertion `px != 0' failed.
[02:43] <smspillaz> RAOF: backtrace ?
[02:43] <RAOF> smspillaz: I'll try to get you one that's not 63 frames of ??
[02:45] <RAOF> DBO: Comment left.
[02:46] <DBO> RAOF, sexellent
[02:46] <DBO> brb
[02:46] <DBO> smspillaz, wanna +1 the review (its free karma)
[02:48] <smspillaz> done
[02:50] <smspillaz> gosh
[02:50] <smspillaz> it seems like subscribing to the wayland mailing list you get the same flamewars again and again and again
[02:50] <smspillaz> Client Side * sucks!
[02:50] <smspillaz> No it doesn't!
[02:50] <smspillaz> Yes it does!@
[02:50] <smspillaz> X sucks!
[02:50] <smspillaz> Yeah X sucks!
[02:50] <DBO> join a different side each time
[02:50] <smspillaz> So lets Client Side *!
[02:51] <smspillaz> No!
[02:51] <smspillaz> DBO: its gotten to the point of
[02:51] <smspillaz> every single time someone makes a wild assertion
[02:51] <smspillaz> I have to put "disclaimer, I don't claim that this is better, but this is *actually* the way * works"
[02:52] <RAOF> The thing that I don't get in the CSD flamewars is that X *in no way* mandates server-side decorations.
[02:52] <bryceh> boo flamers
[02:53] <bryceh> need a procmail rule that only passes through emails from people whose address actually appears in the wayland git tree
[02:53] <smspillaz> RAOF: indeed, except that people in the 90s very quickly realized that doing them server side was the only way to Stop The Madness [tm]
[02:54] <smspillaz> of course, doing them server side created more madness
[02:54] <smspillaz> arguable server side decorations is the whole reason why we have the entire ICCCM Section 4 today
[02:54] <smspillaz> RAOF: bryceh oh, I was going to ask you
[02:54] <smspillaz> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/856043
[02:54] <ubot2> Ubuntu bug 856043 in compiz "compiz crashed with SIGSEGV in _XFreeEventCookies() (dup-of: 851472)" [Undecided,New]
[02:54] <ubot2> Ubuntu bug 851472 in compiz "compiz crashed with SIGSEGV in _XFreeEventCookies()" [Critical,Confirmed]
[02:54] <smspillaz> we seem to be getting a lot of those
[02:55] <smspillaz> and the crash happens when we call XNextEvent
[02:55] <jbicha> free cookies! :)
[02:55] <DBO> I hope they are thin mints
[02:55] <smspillaz> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/851472
[02:55] <bryceh> hmm
[02:55] <smspillaz>  _XFreeEventCookies (dpy=0x855810) at ../../src/XlibInt.c:780
[02:55] <smspillaz>  XNextEvent (dpy=0x855810, event=0x7fffa408d510) at ../../src/NextEvent.c:47
[02:55] <smspillaz>  PrivateScreen::processEvents (this=0x8404a0) at /build/buildd/compiz-0.9.5.94+bzr2803/src/screen.cpp:636
[02:56] <smspillaz> I haven't been able to reproduce this particular one myself yet
[02:56] <smspillaz> but if someone's been able to reproduce that I can single-step through Xlib
[02:56] <DBO> smspillaz, do we know when this first started happening?
[02:57] <smspillaz> September 18
[02:58] <bryceh> xtrace might tell what's going on with X
[02:59] <bryceh> bbl
[03:30] <broder> RAOF: does it make sense for there to be a "does anybody have a problem if i set the resolution to this?" "yes, i have a problem if you set the resolution to this!" protocol?
[03:30] <broder> to avoid some of these texture size issues?
[03:35] <RAOF> I don't know.  It sounds moderately complicated.
[03:36] <RAOF> And it's fundamentally still a work-around; compositors *can* handle those resolutions, but don't.
[03:36] <broder> but they can't handle them well
[03:36] <broder> i'd rather not have gnome-desktop extend the external display i plug into my dinky, 8-year-old netbook if it's going to cause my performance to suck
[03:38] <broder> i would be similar to QueryEndSession/EndSession in gnome-session
[03:38] <broder> *it
[03:53] <RAOF> Well, there's no reason for your performance to suck; it's possible for the compositor to break the textures up into <= max texture size chunks.  We just don't have that enabled or tested.
[04:00] <smspillaz> RAOF: you only have to enable one plugin ...
[04:00] <smspillaz> and I've tested it
[04:00] <smspillaz> it works fine
[04:00] <smspillaz> RAOF: the only case it won't work right now is because we redirect paint into an fbo for unity
[04:00] <smspillaz> and this is not broken up
[04:02] <RAOF> Yeah, but "you testing it" is not the same as "tested on all the many and varied crazy hardware that Ubuntu runs on".
[04:02] <smspillaz> it should work the same everywhere
[04:02] <smspillaz> next cycle then
[04:02] <RAOF> We should totally enable that out of the gate in P.
[04:03] <RAOF> Well, and make sure that Unity works with it, too ?
[04:09] <smspillaz> RAOF: we need a framebuffer object implementation that supports buffers > max texture size
[04:09] <smspillaz> really, the only way I see this working is if I re-wrote the paint system
[04:09] <smspillaz> and made it so that buffers were inserted at points
[04:10] <smspillaz> so that they can control if, eg, a window must be painted multiple times
[04:10] <smspillaz> I plan to do that anyways, but probably not for P
[04:10] <smspillaz> what will likely end up happening is that some applications is going to misbehave once again and screw up stacking
[04:10] <smspillaz> and then there is going to be a huge emergency where everyone blame me for their problems again
[04:11] <smspillaz> and I end up being a social outcast etc etc etc
[04:11] <smspillaz> and then don't get to work on making the paint system awesome
[04:11] <smspillaz> "c'est la vie"
[04:13] <RAOF> The life of a window manager author.
[04:15] <RAOF> Alright.  Now that I've got debugging symbols for everything under the sun, let's see if I can't get a useful backtrace out of that xrandr crash.
[04:16] <lifeless> heh
[04:16] <lifeless> gl
[04:16] <lifeless> RAOF: btw
[04:17] <lifeless> RAOF: someone commented on my adding of xrandr to xvfb, that it has regressed in oneiric; did someone drop all the patches perhaps ?
[04:27] <jasoncwarner_> hey...anyone having sound problems lately? my seems to "go away" and I have to reboot to get it back.
[04:29] <TheMuso> jasoncwarner_: What do you mean by go away?
[04:29] <jbicha> is file-roller broken for y'all also? when I enter a subfolder and return to the previous folder, the folders start multiplying
[04:29] <TheMuso> Bearing in mind that I use audio all day, and haven't had a problem.
[04:30] <jasoncwarner_> TheMuso: one minute sound is working and then, not there hte next
[04:30] <jasoncwarner_> haven't noticed exactly when it goes away
[04:30] <TheMuso> jasoncwarner_: Is it reliably reproduceable?
[04:30] <jasoncwarner_> but all indications are that it is working except there is no sound
[04:30] <jasoncwarner_> TheMuso: don't know how to do it exactly, still looking
[04:30] <TheMuso> Ok, I'd check dmesg and syslog when it happens.
[04:30] <jbicha> http://img29.imageshack.us/img29/2576/sharedcolortargets0010p.png
[04:31] <TheMuso> And if you can come up with a reliable way of reproducing, please file a bug, and follow the steps at https://wiki.ubuntu.com/PulseAudio/Log.
[04:35] <RAOF> lifeless: Looks like that did indeed get dropped.
[05:02] <lifeless> RAOF: what should I do ?
[05:05] <RAOF> I think we might want to evaluate whether xvfb is the best tool for what we're after; it's basically just a headless environment to run tests in, yes?
[05:06] <lifeless> yes, used by various dx projects and lp
[05:06] <lifeless> I know upstream are insane and not taking patches
[05:06] <RAOF> One of the things in a talk at XDC was a desire to remove everything but the xfree86 DDX, on the basis that it actually does everything all the others do too.
[05:07] <RAOF> Can we run a regular xfree86 server, loading the dummy video and dummy input drivers?
[05:07] <lifeless> if you wrap it in xvfb-run, we can do anything you want
[05:07] <lifeless> at this point, *AFAIK*, the screen-capture aspect of xvfb-run is not used by 'us'
[05:08] <lifeless> *xvfb-run-or-similar*
[05:08] <RAOF> Ok.  So, I think the answer there is that I should work out how to make that happen.
[05:10] <lifeless> ok
[05:10] <lifeless> with bated breath I wait
[05:11] <RAOF> DBO: Are you in the market for a compiz backtrace?
[05:11] <RAOF> Mmm, overloaded operator ->
[05:28] <smspillaz> RAOF: DBO is asleep. send it this way
[05:31] <RAOF> smspillaz: http://paste.ubuntu.com/695462/
[05:33] <RAOF> It seems that it's possible for paintOutput to be called after Refresh () and before Relayout() has had a chance to actually set up the fbos for the output.
[05:33] <RAOF> With hilarious consequences!
[05:35] <didrocks> good morning
[05:36] <smspillaz> RAOF: that's a fun race condition
[05:36] <RAOF> Indeed.
[05:36] <RAOF> Good morning didrocks
[05:36] <smspillaz> we should probably only trash the fbos on Relayout then
[05:36] <RAOF> Ah, but what about hotplug?
[05:36] <didrocks> hey RAOF, how are you?
[05:37] <smspillaz> hi didrocks
[05:37] <RAOF> It's not so much that you've trashed the fbo.  The fbo hasn't yet been set up! :)
[05:37] <smspillaz> RAOF: relayout will get called
[05:37] <smspillaz> oh
[05:37] <smspillaz> right
[05:37] <smspillaz> yeah, because we're waiting on gtk to give us the new monitor geometry rather than compiz
[05:38] <smspillaz> (why does it even work like that)
[05:38] <smspillaz> RAOF: I think I'm going to start implementing an iron fist approach on unityshell
[05:38] <smspillaz> if you're a plugin start acting like one etc etc
[05:41] <didrocks> hey smspillaz
[05:43] <smspillaz> RAOF: ok, we'll find out in the 20 minutes this takes to build if this actually works
[05:43] <RAOF> smspillaz: Got a branch you'd like me to test?
[05:43] <smspillaz> kompiling
[06:03] <jasoncwarner_> smspillaz is awake! yay...
[06:04] <jasoncwarner_> smspillaz, I want to get a call about multi-monitor stuff with dbarth, RAOF and anyone else interested in fixing these bugs.
[06:04] <jasoncwarner_> smspillaz RAOF https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/830949
[06:04] <jasoncwarner_> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/813343
[06:04] <jasoncwarner_> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/830949
[06:04] <jasoncwarner_> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/813343
[06:04] <jasoncwarner_> https://bugs.launchpad.net/unity/+bug/815613
[06:04] <ubot2> Ubuntu bug 830949 in xserver-xorg-video-intel "[Intel N10 Graphics] Plugging in external monitor to VGA port makes both displays corrupted with thick slanted lines " [Critical,Invalid]
[06:04] <ubot2> Ubuntu bug 813343 in unity "nvidia drivers, second monitor covered by black" [High,Confirmed]
[06:04] <ubot2> Ubuntu bug 815613 in unity "[intel] When I plug in a second monitor, I get a black bar across the top of my screen and the second monitor is black except for the bar at the top." [High,Confirmed]
[06:05] <RAOF> At least for intel I've half-confirmed that bug.  It doesn't crash for me in the way described, but it does become unusably slow.
[06:06] <jasoncwarner_> RAOF: any idea on fix, by chance? I know I only gave this to you guys like 8 hours ago....
[06:07] <RAOF> "Don't do that"
[06:07] <RAOF> Well, don't do that for now.  For P try and ensure that compiz can shatter its textures/fbos.
[06:08] <RAOF> As smspillaz will undoubtedly chime in to say, compiz itself will handle that situation nicely, it just requires enabling a plugin.  Unity however has slightly higher demands.
[06:09] <RAOF> We *used* to crash out and start metacity instead, but that's not exactly a winner when running Unity. :)
[06:13] <jasoncwarner_> RAOF & smspillaz options for O, though? what can we do to make compiz/unity not, you know, completely barf in the multi-mon situation
[06:13] <RAOF> Well, it's only really an issue for netbooks.
[06:13] <RAOF> Now, if only netbooks weren't a focus area... :)
[06:14] <RAOF> By and large multi-monitor works just fine.  Modulo some bugs - smspillaz, how's that build going?
[06:15] <RAOF> jasoncwarner_: Probably the best thing to do for O would be to patch gnome-settings-daemon to not set up the displays in such a way that it breaks.
[06:18] <jasoncwarner_> RAOF: what kind of patch? like, what we g-s-d do? now allow certain resolution monitor configs?
[06:18] <RAOF> Exactly.=
[06:19] <RAOF> Refuse to automatically configure a desktop with a dimension > max texture size, and throw up a big warning for manual setting of that.
[06:19] <didrocks> jasoncwarner_: RAOF: I would tend to thing, we should to that in the display monitor capplet
[06:19] <didrocks> jasoncwarner_: RAOF: and same, if you use the nvidia blob driver, prevent it's usage
[06:19] <didrocks> the results if you do so are quite… interesting :)
[06:20] <RAOF> What happens with the blob?
[06:20] <RAOF> Does unity not notice the hotplug or something?
[06:20] <RAOF> didrocks: Anyway, it has to be done in g-s-d rather than the capplet because g-s-d's xrandr plugin will automatically set up a new display on hotplug.
[06:21] <jasoncwarner_> RAOF: can we get that information (dimension > max texture size ) and basically say 'this computer can handle these resolutions" and , ash didier say, only show them what they have that unity can handle (for now)
[06:21] <RAOF> That information is very easy to get, yes.
[06:21] <didrocks> really? nux people were telling it wasn't available?
[06:21] <didrocks> since natty
[06:22] <RAOF> Max texture size?
[06:22] <bryceh> glxinfo reports max texture size for  instance
[06:22] <bryceh> xrandr tells you all about available resolutions
[06:22] <bryceh> fwiw, the issue that this needs handled in g-s-d has been known for  years; I can probably dig up the bug report about it
[06:24] <jasoncwarner_> So, RAOF bryceh didrocks and smspillaz , what I'm hearing is that we can create a workaround in g-s-d (and maybe display capplet) for Unity not doing what it should...and that might get us through O?
[06:25] <jasoncwarner_> but
[06:25] <jasoncwarner_> (assuming the above is correct)
[06:25] <RAOF> Pretty much, yes.  I'm not sure what's happening with the nvidia blob, though.
[06:25] <jasoncwarner_> it still doesn't fix compiz/unity...
[06:25] <jasoncwarner_> which we would need to do
[06:26] <jasoncwarner_> Ok...do we have a bug for the g-s-d work around yet? want to add that to release-manager checklist
[06:26] <jasoncwarner_> and, didrocks...might want to add the above to your didier tag list
[06:26] <RAOF> The compiz stuff is already done - the Copy to Texture plugin handles the compiz end.
[06:27] <didrocks> jasoncwarner_: yeah, IIRC, the black screen with nvidia is already on, let me checkc and ensure
[06:27] <RAOF> The problem is that Unity uses fbos, which don't have an equivalent plugin.
[06:28] <jbicha> didrocks: good morning, bug 856884 is annoying for users who use Unity & other desktops
[06:28] <ubot2> Launchpad bug 856884 in unity "Running unity --reset breaks metacity keyboard shortcut defaults" [Undecided,Confirmed] https://launchpad.net/bugs/856884
[06:28] <didrocks> jbicha: is it still the case since beta 2?
[06:29] <didrocks> jbicha: i guess I fixed it
[06:29] <bryceh> jasoncwarner_, not spotting the g-s-d bug on this; I'm sure there was one tho
[06:29] <jbicha> didrocks: no, it's still the case as of right now
[06:29] <bryceh> maybe it got expired
[06:30] <didrocks> jbicha: so, if you unity --reset, can you confirm ctrl + alt + T still works in compiz now?
[06:30] <jasoncwarner_> bryceh or RAOF could you file a new bug for g-s-d so I can get it on kates checklist?
[06:30] <RAOF> I'll file one.
[06:30] <jbicha> didrocks: yes, but the bug is about the other 3 keyboard shortcuts that unity --reset breaks :)
[06:30] <jasoncwarner_> RAOF: awesome, thank you!
[06:31] <bryceh> bug 555641 maybe?
[06:31] <ubot2> Launchpad bug 555641 in compiz "MASTER: max texture size prevents compiz from running (dup-of: 824099)" [Undecided,Confirmed] https://launchpad.net/bugs/555641
[06:31] <ubot2> Launchpad bug 824099 in compiz "[~30 systems] Plugging in external monitor to VGA port makes both displays corrupted with thick slanted lines" [Critical,Invalid] https://launchpad.net/bugs/824099
[06:32] <RAOF> bryceh: Yeah, I'll resurrect that into a g-s-d bug.
[06:32] <didrocks> jasoncwarner_: it's not unity --reset, it's compiz not being nice
[06:33] <jbicha> didrocks: I've been frustrated by the bug for several weeks, your patch finally helped me realize what was creating the ~/.gconf/metacity stuff
[06:33] <bryceh> RAOF, yep sounds good
[06:33] <jbicha> I didn't expect unity --reset to _add_ stuff
[06:33] <didrocks> jbicha: it's not that simple
[06:33] <didrocks> jbicha: basically, unity --reset reset all compiz gconf value, isn't it?
[06:34] <didrocks> jbicha: and those keys are magically bound to metacity one by the gnome-compat plugin
[06:34] <didrocks> so it then updates the metacity ones
[06:34] <didrocks> not something I can fix easily then, as the default aren't the same between session (as unity provides those keys)
[06:34] <bryceh> RAOF, there's a compiz patch in comment #8; dunno if it's relevant
[06:35] <didrocks> jbicha: I guess I can change the setting for Meta + D
[06:35] <jasoncwarner_> RAOF: when you have new bug #, let me know so I can get that kate...thanks!
[06:35] <jbicha> it's doing it wrong, it should read what the defaults really are (maybe the gsettings thing will fix it)
[06:35] <bryceh> Travis said, "Ideally Xorg would sort this out though which I believe is the point of the 'shatter' work."
[06:35] <didrocks> jbicha: want to make a compiz patch? :)
[06:35] <didrocks> jbicha: I'm afraid it won't, hence the fact that smspillaz should be aware about it now ;)
[06:35] <bryceh> jasoncwarner_, maybe that shatter stuff is what dbarth's thinking about
[06:36] <jbicha> didrocks: I can try copying what you did
[06:36] <RAOF> Yup.  Either Xorg, or compiz, or both.
[06:36] <didrocks> jbicha: won't work for other keys, they will conflict with unity keys
[06:36] <didrocks> and prevent unity to start
[06:36] <bryceh> jasoncwarner_, unfortunately X.org Shatter is so heavily delayed I doubt it'll ever exist
[06:36] <didrocks> are you using unity --reset that often?
[06:36] <jasoncwarner_> bryceh RAOF not up on my 'shatter' these days...
[06:36] <jasoncwarner_> ah, so not exactly a solution?
[06:37] <didrocks> I shouldn't have added this option I guess :)
[06:37] <jbicha> didrocks: I always run the dev releases, so yes it happens, quite a few users mess with ccsm too & I've been recommending unity --reset
[06:37] <didrocks> jbicha: it's really hackish FYI :-)
[06:37] <RAOF> bryceh: IIUC you get it for "free" with airlied's hybrid graphics support work.
[06:37] <didrocks> jbicha: so, I have an idea
[06:37] <jbicha> I don't understand why patching the keys will break unity, I delete my ~/.gconf/metacity and things work fine
[06:37] <bryceh> RAOF, hmm, mayhbe
[06:38] <didrocks> jbicha: again, we don't set those keys directlly
[06:38] <didrocks> jbicha: basically, when a key under ~/.gconf/compiz changes
[06:38] <RAOF> jasoncwarner_: I'm resurrecting bug 824099 to track this.
[06:38] <didrocks> there is gnomecompat which updates the corresponding metacity key
[06:38] <ubot2> Launchpad bug 824099 in gnome-settings-daemon "[~30 systems] Plugging in external monitor to VGA port makes both displays corrupted with thick slanted lines" [Undecided,New] https://launchpad.net/bugs/824099
[06:38] <didrocks> jbicha: ok until there?
[06:38] <jbicha> those keys are the metacity defaults, either from upstream or as packaged in the metacity ubuntu package
[06:39] <didrocks> wait for my explanation
[06:39] <didrocks> jbicha: are you ok about the compiz -> metacity change?
[06:41] <jbicha> the gnomecompat plugin does some crossover thing with metacity, I don't understand it much deeper than that
[06:41] <didrocks> basically, when a gconf compiz key changes, it updates the metacity one
[06:42] <didrocks> in the default for compiz, with the unity profile, the Alt + F1, Alt + F2 are dealt by unity, not by the shortcuts general settings
[06:42] <bryceh> jasoncwarner_, the original X.org shatter was proposed several years ago; there was some work done on it by redhat, but I haven't heard anything more about that in a long time.
[06:42] <didrocks> to the gconf compiz key  bound to those metacity shortcuts are set to "null" to avoid conflicts between compiz and unity
[06:42] <didrocks> so*
[06:43] <jbicha> so it's hacks on top of hacks?
[06:43] <bryceh> jasoncwarner_, the effort RAOF refers to is also by redhat, but is also similarly highly experimental and doesn't have an ETA afaik
[06:43] <didrocks> jbicha: it's just compiz not enabling two plugins having the same key
[06:43] <RAOF> XRandR 1.4 was going to support it, too.  Again, delayed.
[06:43] <didrocks> jbicha: so when you --reset (which isn't a core experience case normally), you reset all keys to default
[06:43] <jbicha> do we even need gnomecompat?
[06:43] <didrocks> and those 2 keys to defaults
[06:43] <bryceh> jasoncwarner_, it might be something we'd want to look at for 12.04 for hybrid graphics support, but even there it's probably >6 month effort
[06:44] <didrocks> jbicha: yeah, it's the only way to get the same number of worspaces, and the gnome session integration
[06:44] <didrocks> jbicha: it's also the only way to set the compiz key in g-c-c
[06:44] <bryceh> RAOF, hmm, can you find a reference to that about randr 1.4?  I hadn't heard that.
[06:44] <didrocks> so, what we can do is working this issue
[06:44] <didrocks> like, patching unity --reset to then set the metacity gconf key back
[06:44] <bryceh> randr 1.4 sounds a lot more feasible for possibly backporting than the stuff airlied's doing
[06:44] <didrocks> (which won't be picked by compiz, and so no compiz plugin conflict)
[06:44] <bryceh> we might even be able to persuade keithp to help
[06:45] <RAOF> bryceh: It was part of the per-crtc pixmap thing - that's basically shattering the framebuffer into monitor-sized chunks.
[06:45] <RAOF> The compositor would then only need to deal with textures as big as the biggest monitor, rather than as big as the combined framebuffer.
[06:46] <RAOF> Of course, I don't think xrandr 1.4 has gone anywhere since it got backed out from 1.11.
[06:47] <didrocks> jbicha: want to fix that?
[06:47] <bryceh> RAOF, yeah but it was pretty close at that point.  I can follow up with keith about it
[06:47] <jbicha> didrocks: would it be bad to just have unity --reset rm -rf ~/.gconf/apps/metacity/global_keybindings
[06:48] <didrocks> jbicha: urgh, don't do that!
[06:48] <RAOF> bryceh: And also check that my understanding is correct :)
[06:48] <didrocks> jbicha: this is bad for gconf, he never really supported touching those files manually
[06:48] <bryceh> RAOF, right :-)
[06:48] <didrocks> jbicha: better to reset using gconftool-2
[06:48] <didrocks> if those are null
[06:49] <RAOF> bryceh: That said, it'll require compiz changes to get working.  And if we're allowing compiz changes, it *might* just be easier to make those compiz changes anyway; compiz can work around xserver limitations.
[06:50] <jbicha> didrocks: ok same thing: gconftool-2 --recursive-unset /apps/metacity/global_keybindings
[06:51] <didrocks> jbicha: yeah, I think just run than in unity --reset
[06:51] <didrocks> jbicha: want to make a patch? I'll review it
[06:51] <bryceh> RAOF, true
[06:52] <bryceh> RAOF, I'm just trying to make sure we got all bases covered from the X perspective
[06:53] <jbicha> didrocks: you said that's in compiz?
[06:53] <RAOF> Sure.  If it'd make compiz's job easier, and is feasible, it'd be a good idea.
[06:53] <didrocks> jbicha: no, the unity "binary" is in unity itself
[06:54] <didrocks> jbicha: look at tools/unity.cmake
[06:54] <didrocks> jbicha: it's a small python script
[07:00] <bryceh> RAOF, jasoncwarner_ so is there an assignee for bug #824099?
[07:00] <ubot2> Launchpad bug 824099 in compiz "[~30 systems] Plugging in external monitor to VGA port makes both displays corrupted with thick slanted lines" [Critical,Invalid] https://launchpad.net/bugs/824099
[07:03] <RAOF> bryceh: Do you think the wording of 824099 sufficiently describes the problem, and our proposed solution?
[07:06] <bryceh> RAOF, yes that looks very good.  Might elaborate a bit on the second paragraph - why is unity particularly limited in this case?
[07:07] <bryceh> RAOF, there's (I think) 3 use cases we need to address:
[07:07] <RAOF> Might need to get smspillaz to elaborate on that bit; I'm not totally sure what the specific details are.
[07:07] <bryceh> 1.  Boot.   So compiz/unity needs to avoid starting up if the system's configured in this fashion
[07:08] <bryceh> 2.  Hotplugging another monitor (which I think the bug's description covers)
[07:09] <bryceh> mm, maybe just those two cases
[07:09] <bryceh> was going to say setting up the external monitor and restarting compiz, but that's basically a subcase of #1
[07:10] <jasoncwarner_> RAOF and bryceh so we'll track it via bug #824099 ? I'm cool with that...
[07:10] <bryceh> RAOF, for #1, does compiz already cover that well enough, or do you think we need another bug about that?
[07:10] <ubot2> Launchpad bug 824099 in gnome-settings-daemon "Max GL texture size can break multi-head" [High,Confirmed] https://launchpad.net/bugs/824099
[07:10] <jasoncwarner_> RAOF, are you able to handle the g-s-d portion of the fix?
[07:11] <didrocks> jbicha: looks good, did you try it to ensure we don't have unseen side effects?
[07:11] <rickspencer3> is anyone else seeing that notify-osd no longer shows the volume in the notification when changing volume via keyboard?
[07:11] <RAOF> bryceh: I think compiz already covers #1.
[07:11] <didrocks> jbicha: as compiz is ran after, I'm afraid that the key will still be overwritten, so maybe, that should be done afterwards
[07:11] <RAOF> jasoncwarner_: I think I can take the g-s-d portion, yes.
[07:11] <jasoncwarner_> rickspencer3: yeah, chrisccoulson was looking at that
[07:11] <didrocks> rickspencer3: yeah, it's known and under work
[07:11] <rickspencer3> chrisccoulson? not Dx?
[07:11] <jbicha> didrocks: no, do I have to build nux too?
[07:11] <rickspencer3> thanks didrocks
[07:11] <jasoncwarner_> rickspencer3: I thought it was fixed, though (though I'm on desktop ppa at the moment)
[07:12] <chrisccoulson> i uploaded a fix for that yesterday
[07:12] <rickspencer3> thanks chrisccoulson
[07:12] <didrocks> jbicha: no, just run make install for the tool/ directory
[07:12] <rickspencer3> I'll get it later today, I guess
[07:12] <rickspencer3> meh
[07:12]  * rickspencer3 dist-upgrades
[07:13] <chrisccoulson> yeah, it seems it was accepted yesterday - https://lists.ubuntu.com/archives/oneiric-changes/2011-September/010183.html
[07:13] <rickspencer3> didrocks, should I remove the desktop PPA before I upgrade?
[07:14] <didrocks> rickspencer3: no, the upgrade should be smooth from there
[07:14] <rickspencer3> thanks didrocks
[07:15] <didrocks> yw
[07:18] <jbicha> didrocks: I'm having trouble building just a directory, I'll try again after I sleep :)
[07:18] <jbicha> thanks for all the help
[07:18] <didrocks> jbicha: no hurry! do not hesitate to ping me if you need any help with cmake ;)
[07:18] <didrocks> jbicha: thanks you for looking at it :)
[07:21] <bryceh> RAOF, short of shatter, is there anything more that can be done on the compiz/unity side to improve the situation?  Or is the workaround the best we're going to do for the time being?
[07:22] <bryceh> like, any potentials on improving the performance of the compiz "shatter" workaround?
[07:24] <jasoncwarner_> hey RAOF bryceh and didrocks you all mentioned that g-s-d for the multi-mon stuff was the correct way, but as didrocks mentioned, should we patch monitor capplet to not allow to high monitor sizes as well? stop it on two fronts?
[07:25] <didrocks> I would say so, but I'm just not aware enough of all this resolution stuff :-) (but still, at least, we should blacklist the capplet for nvidia blog driver use)
[07:31] <rickspencer3> uh, how do I tell nautilus to open a file with mplayer?
[07:36] <RAOF> bryceh: I *think* the workaround is the minimum-risk path for the time being.  I don't know what the performance of compiz's shattering workaround is; it'd have to be better than the software fallbacks we currently get.
[07:37] <bryceh> RAOF, oh I thought the compiz shatter *was* the software fallback; no?
[07:39] <RAOF> I believe the current fallback is in mesa, to software rendering.
[07:39] <rodrigo_> morning
[07:39] <RAOF> We don't have copy-to-texture enabled by default; maybe I should fire up the netbook and check what influence that has.
[07:45] <didrocks> rickspencer3: right-click -> open with another application? (if it's not on the list of supported mimetypes for this extension)
[07:46] <rickspencer3> didrocks, right, so you used to be able to enter a command in that dialog
[07:46] <rickspencer3> I guess I'll have to make or change the mplayer desktop file for something :/
[07:46] <didrocks> rickspencer3: yeah, seems it's not listed (just installed it) indeed
[07:47] <didrocks> weird
[07:47] <rickspencer3> respin beta2!!!
[07:47] <rickspencer3> I'll start the incident report
[07:47] <rickspencer3> ;)
[07:48] <jasoncwarner_> RAOF bryceh smspillaz didrocks (anyone else listening about multimonitor). how does this sound for workaround
[07:48] <jasoncwarner_> 1. patch g-s-d to not allow unity to start with higher than max 3d resolution
[07:48] <didrocks> rickspencer3: heh!
[07:48] <jasoncwarner_> 2. patch monitor capplet to not allow someone to actively choose a resolution higher than max 3d reoslution when running unity
[07:48] <jasoncwarner_> ?
[07:49] <bryceh> RAOF, are you taking the action for doing both of those?  (I gather they both will require some hacking on gnome-desktop)  Or should someone else take #2?
[07:49] <RAOF> I think 1. would actually be a patch to unity_support_test; g-s-d doesn't actually determine whether Unity runs or not, right?
[07:49] <didrocks> jasoncwarner_: agreed on that :)
[07:49] <didrocks> RAOF: hum, but if resolution changes?
[07:49] <didrocks> RAOF: unity isn't restarted
[07:50] <bryceh> 1. patch g-s-d to not allow increasing resolution beyond max texture buffer size if unity is running
[07:50] <RAOF> What I expect to do for 1. is to ensure that g-s-d won't set a resolution that unity won't work at, rather than trying to stop unity from starting if the resolution is too high.
[07:50] <bryceh> 2. patch monitor capplet to not allow someone to actively choose a resolution higher than max 3d reoslution when running unity
[07:50] <RAOF> Right, that.
[07:50] <jasoncwarner_> right
[07:50] <jasoncwarner_> sorry..
[07:50] <jasoncwarner_> great
[07:50] <jasoncwarner_> tadpole
[07:51] <didrocks> yeah, with misreading the 1. agreed with bryceh and RAOF :)
[07:51] <jasoncwarner_> (was going a bad place...just skipped like 10 steps...moving on)
[07:51] <seb128> hey
[07:51] <jasoncwarner_> morning seb
[07:51] <RAOF> Hey seb!
[07:51] <didrocks> salut seb128
[07:51] <bryceh> hi seb128
[07:51] <jasoncwarner_> RAOF: could you update the bug with the plan?
[07:51] <seb128> hey didrocks bryceh jasoncwarner_
[07:51] <RAOF> I think that's already on there?  Clearly not sufficiently obvious ;)
[07:51] <seb128> what bug is that?
[07:52] <RAOF> bug 3824099
[07:52] <RAOF> Or, rather, bug #824099
[07:52] <seb128> that's an old one!
[07:52] <ubot2> Launchpad bug 824099 in gnome-settings-daemon "Max GL texture size can break multi-head" [High,Confirmed] https://launchpad.net/bugs/824099
[07:52] <seb128> or not ;-)
[07:52] <smspillaz> submitted a demotivational for my assignment
[07:52] <seb128> hum
[07:52] <smspillaz> feel like a bucket of win
[07:52] <bryceh> RAOF, yeah you got it right; maybe jason's wording is less jargonny :-)
[07:53] <seb128> is that bug old like the world?
[07:53] <RAOF> That bug is old like the world, yes.
[07:53] <seb128> like tseliot patched the capplets years ago for that
[07:53] <bryceh> seb128, right
[07:53] <seb128> but we dropped the patch since because the drivers were supposed to be good nowadays
[07:53] <seb128> *shrug*
[07:54] <chrisccoulson> hi seb128
[07:54] <rodrigo_> oh, cyphermox uploaded the new NM and NM-applet!
[07:54] <rodrigo_> hey seb128
[07:54] <RAOF> Well, the drivers work, but terribly slowly, since you're exceeding a hardware limit and falling back to software.
[07:55] <RAOF> This used to work well because compiz would crash, and spawn Metacity :)
[07:55] <micahg> hi seb128, thanks for sorting out seed yesterday
[07:55] <bryceh> RAOF, and Copy to Texture was considered a "real" solution, but doesn't work (yet) under unity?
[07:55] <RAOF> bryceh: That is my understanding, yes.
[07:56] <seb128> right, ok
[07:56] <seb128> hey chrisccoulson, rodrigo_, how are you?
[07:56] <seb128> micahg, you're welcome
[07:56] <chrisccoulson> seb128, yeah, good thanks
[07:56] <chrisccoulson> winding down day for me :P
[07:56] <seb128> hehe
[07:56] <seb128> do you still have anything to get done for Oneiric?
[07:57] <seb128> or anything we should watch for while you are away?
[07:57] <rodrigo_> chrisccoulson, :)
[07:57] <didrocks> seb128: no, wait 6PM to tell "oh chrisccoulson, there is a bug issue in firefox…"
[07:57] <rodrigo_> yeah
[07:57] <chrisccoulson> seb128, yeah. i've just remembered that i need to make firefox look in gsettings for the accessibility settings
[07:57] <seb128> didrocks, ;-)
[07:57]  * rodrigo_ prepares a ton of bug reports for 5:30
[07:57] <seb128> chrisccoulson, is tb contact syncing working?
[07:58] <chrisccoulson> seb128, thunderbird-couchdb is in source new :)
[07:58] <seb128> once we get thunderbird-couchdb out of NEW
[07:58] <chrisccoulson> if you feel like reviewing it :)
[07:58] <didrocks> rodrigo_: weak, 6 is better! :-)
[07:58] <seb128> should that be installed by default?
[07:58] <didrocks> hey rodrigo_
[07:58] <rodrigo_> didrocks, yeah, right
[07:58] <seb128> bah, I missed robert_ancell
[07:58] <seb128> why didn't we get new unity-greeter and lightdm
[08:02] <micahg> is anyone aware the new pitivi claims to want python-gst0.10 0.10.28?
[08:02] <rodrigo_> is the ca-certificates package fixed? is it safe to upgrade it?
[08:03] <micahg> rodrigo_: should be, yes
[08:03] <seb128> micahg, no, I will check with jbicha when he's there
[08:03] <rodrigo_> micahg, ok
[08:04] <micahg> seb128: ok, thanks, seems to be my only broke package ATM
[08:31] <rickspencer3> jasoncwarner_, so if someone who is having multi-mon issues simply chooses a lower resolution, their problems will go away?
[08:32] <jasoncwarner_> rickspencer3: I believe so, yes...as long as that resolution is supported in 3d configuration (which RAOF will only allow after he patches from above)
[08:32] <RAOF> Where their problems are caused by exceeding the max texture size, yes.
[08:33] <RAOF> There may be other problems (there's a race in Unity where monitor hotplug can crash compiz), but they're not caused by X :)
[08:33] <seb128> imho it would be a better experience to tell them to use unity-2d that to tell them they can't use their monitor
[08:34] <seb128> unity-2d is close enough from unity and you usually want to use your monitor resolution
[08:34] <RAOF> Yes.  That requires a logout though, doesn't it?
[08:34] <seb128> yes
[08:34] <seb128> but well rather than blocking those choices I would display a warning saying to relog in 2d
[08:34] <RAOF> So we can't really do that automatically when they plug in a monitor.
[08:34] <mvo> seb128, pitti: it appears that bug #854622 (and friends) are caused by the changelog sharing feature. see comment #8 in this bug. this is all a bit mysterious though
[08:34] <ubot2> Launchpad bug 854622 in update-manager "Could not install libglib2.0" [Undecided,New] https://launchpad.net/bugs/854622
[08:35] <seb128> mvo, hey, I've no real clue about the changelog sharing and pitti is off today
[08:35] <RAOF> seb128: You mean - block those choices *and* display a warning saying to relog in 2d, yes?  That's a fine plan.
[08:36] <seb128> RAOF, no, don't block those choices
[08:37] <seb128> RAOF, but if somebody picks one display a warning saying that it will slow down their session and that if they want to use the resolution then should use 2d rather
[08:37] <seb128> RAOF, ie the choices are just not available people will think Ubuntu is broken and that they can't use their monitor
[08:37] <seb128> we need in some way to explain why the choices are not available and what are the solution for people who want to use their native resolution
[08:38] <RAOF> I think we're on the same page.
[08:38] <seb128> ok, great ;-)
[08:38] <RAOF> I don't mean "not display those options at all", I mean "display those options, but when the user sets them tell them "whoops, you need to go to unity 2d to set this"".
[08:38] <seb128> +1
[08:38] <seb128> ;-)
[08:41] <mvo> seb128: ok, thanks. I mark it as high and target for oneiric to keep it on the radar
[08:41] <mvo> seb128: I don't have a clue about this feature either, but something really fishy is going on
[08:41] <RAOF> mvo: Oh - were I to guess, I'd suggest that pkgbinarymangler is selecting libglib2.0-data as the primary changelog package on i386 (where it's built) but not on amd64 (because it's not built there).  But I thought that there were checks for that.
[08:41] <seb128> mvo, well, it seems wrong that the lib binary got -data in its changelog
[08:42] <mvo> RAOF: ohhh, that is a interessting thought!
[08:43] <mvo> seb128: yeah, indeed
[08:45] <rodrigo_> do we have a "keyboard-layouts" icon?
[08:45] <rodrigo_> we are using the same icon for the region and language selector in g-c-c
[08:45] <rodrigo_> couldn't really find one that matches
[08:47] <seb128> rodrigo_, key_bindings.png would work I guess
[08:47] <rodrigo_> ok, looking
[08:48] <seb128> rodrigo_, or better, preferences-desktop-keyboard
[08:48] <rodrigo_> seb128, hmm, not sure it's good
[08:48] <rodrigo_> oh, looking that one
[08:48] <seb128> rodrigo_, eog /usr/share/icons/Humanity/apps/24/preferences-desktop-keyboard-shortcuts.svg
[08:49] <seb128> ups
[08:49] <rodrigo_> yes, that one's better
[08:49] <seb128> eog /usr/share/icons/Humanity/apps/24/preferences-desktop-keyboard.svg
[08:49] <seb128> rather
[08:49] <rodrigo_> yeah
[08:50] <rodrigo_> well, that's the same one as the keyboard panel
[08:50] <rodrigo_> so we need another one
[08:52] <seb128> rodrigo_, the keybinding one then?
[08:52] <seb128> it's not ideal but it's better than what we have...
[08:53] <rodrigo_> yes, I guess it's too late to create a new icon, so yes
[08:53] <rodrigo_> can't find a better one
[08:53] <seb128> especially that a new icon would only be in our theme
[08:53] <mvo> hrm, focus-follow mouse seems to act oddly with the latest unity -:/
[08:54] <seb128> so break if you change to the gnome icon theme
[08:55] <rodrigo_> seb128, yes
[09:03] <Sweetshark> hi all.
[09:05] <seb128> hey Sweetshark
[09:17] <seb128> didrocks, you probably noticed but there is a new sni-qt listed on version, is that something for Oneiric still?
[09:17] <didrocks> seb128: yes, it is, it's on my list for today
[09:17] <didrocks> seb128: minor fixes, but still good to know
[09:17] <seb128> didrocks, ok great, thanks
[09:17] <didrocks> I tried to convince agateau to do the packaging himself, but he's shy :)
[09:17] <seb128> didrocks, I put you for it on the etherpad
[09:18] <seb128> hehe
[09:18] <didrocks> seb128: sure, thanks!
[09:18] <seb128> thanks ;-)
[09:18] <didrocks> yw
[09:18]  * didrocks hopes a release team member will still be around, seems I made a booboo in the oneconf package if people have no .mo file
[09:25] <seb128> rodrigo_, is there a way to load a local g-c-c .so
[09:25] <seb128> like for debugging, I want to use the one from the build tree without having to install it
[09:25] <didrocks> seb128: oh, he didn't push 0.2.4
[09:26] <didrocks> 0.2.3 is basically the version we have today
[09:26] <seb128> didrocks, ok
[09:26] <didrocks> will wait on monday so that he release 0.2.4, he told me you would do it yesterday
[09:27] <seb128> those french people...
[09:28] <didrocks> yeah, not reliable :-)
[09:29]  * didrocks tries to use pitti's tool to build the French CD
[09:31] <seb128> where is the spanish?
[09:31] <seb128> rodrigo_, ola senior?
[09:32]  * didrocks is eager to try cross-building (building the amd64 flavor on my i386 as it's possible)
[09:32] <didrocks> but let's see if I get a fine i386 first :)
[09:35] <asac> hi guys! running stock oneiric ... wonder if there is any app included nowadays to take photos from my webcam or if i need to install cheese?
[09:36] <didrocks> there is none AFAIK
[09:37] <asac> ok. my best hope was shotwell ... seems it doesnt support taking photo from next to the import action
[09:37] <asac> didrocks: is cheese the best option?
[09:38] <seb128> asac, yes
[09:38] <seb128> asac, hey btw ;-)
[09:38] <seb128> asac, cheese is the best option
[09:39] <didrocks> pitivi can't do that, isn't it?
[09:39] <rodrigo_> seb128, sorry, was preparing a snack :)
[09:39] <seb128> didrocks, I don't think it does handle inputs
[09:39] <rodrigo_> seb128, g-c-c just looks at its own prefix, for lib/control-center-2-0/
[09:39] <didrocks> seb128: yeah, didn't try for a while but that's my bet
[09:40] <rodrigo_> seb128, so no, not possible
[09:40] <seb128> rodrigo_, so every time I want to debug a panel I need to install the .so over the system one?
[09:40] <seb128> it's ridiculous...
[09:40] <asac> seb128: cool
[09:40] <rodrigo_> seb128, yes, or use jhbuild/a local prefix
[09:41] <glatzor> mvo, rodrigo_ , a limited packagekit compaitibilty layer shouldn't be doable. It is just more or less about moving some bits from session-installer and the former apt backend of packagekit to aptdaemon. But will a dependency on python-packagekit :)
[09:41] <rodrigo_> seb128, install to /tmp or whatever
[09:41] <glatzor> should be doable
[09:41] <glatzor> :)
[09:41] <seb128> rodrigo_, we should add a command line option to let specify a .so :p
[09:41] <rodrigo_> :)
[09:42] <rodrigo_> glatzor, why would it have to depend on p-pk?
[09:42] <rodrigo_> ah, for the apt backend
[09:42] <rodrigo_> glatzor, but can't we just provide the PK bus API on top of aptdaemon? why would it need to depend on python-pk in that case?
[09:45] <rodrigo_> I think for P we'll have to implement compatibility dbus layers, for PK and systemd, which are being used more and more in GNOME
[09:45] <rodrigo_> instead of having to patch every app that uses them
[09:47] <glatzor> rodrigo_, because we would need the enums
[09:48] <rodrigo_> glatzor, what enums? the ones in the C API?
[09:49] <glatzor> rodrigo_, we could also hardcode them. e.g. we would have to emit Package signals which contain the security level of an upgrade - the level is a string which is defined in p-pk
[09:50] <rodrigo_> glatzor, right, so not a real need to depend, just we need a way to "share" those strings/enums, to avoid copy/paste errors
[09:50] <rodrigo_> glatzor, of course, this is P material, so maybe we should have a session at UDS?
[09:52] <glatzor> rodrigo_, mvo, indeed. I won't be at UDS. But perhaps I can join on IRC
[09:53] <rodrigo_> glatzor, oh ok, then we'll assign all tasks to you :)
[09:54] <rodrigo_> glatzor, on the other hand, is anything in PK missing for it to replace aptdaemon?
[09:56] <Sweetshark> seb128: any idea on https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836 ? To put it bluntly it seems that at least 75% of all reported Libreoffice crashes come from this single root cause, which is: encrypted swap is broken.
[09:56] <ubot2> Ubuntu bug 745836 in libreoffice "soffice.bin crashed with SIGSEGV in cppu::throwException()" [High,Confirmed]
[09:56] <glatzor> rodrigo_, right, the whole s-c integration.
[09:58] <rodrigo_> glatzor, hmm, s-c uses aptdaemon, right? so it could, if PK offered all it needs, use it instead, right?
[09:58] <rodrigo_> or what do you mean?
[09:59] <seb128> Sweetshark, not really...
[09:59] <seb128> Sweetshark, try asking on #ubuntu-devel maybe
[09:59] <seb128> Sweetshark, you might have somebody with an idea there
[10:00] <Sweetshark> chrisccoulson: bug 745836 might also be interesting to you. (Or anyone else who has reports of weird crash when the app was swapped out)
[10:00] <ubot2> Launchpad bug 745836 in libreoffice "soffice.bin crashed with SIGSEGV in cppu::throwException()" [High,Confirmed] https://launchpad.net/bugs/745836
[10:01] <glatzor> rodrigo_, That is the way free software works. But you would need to push a lot of features to PackageKit, chaining transactions, mupltiple authentication, licensekey handling, handling of failed installation, method to repair the system ...
[10:01] <rodrigo_> glatzor, ok, that's the answer to my 'what's missing' question :)
[10:02] <glatzor> rodrigo_, the whole purchase process is deeply integrated in aptdaemon
[10:04] <glatzor> rodrigo_, The InstallPackages method is not the main purpose of aptdaemon. But indeed PackageKit is catching up in some areas e.g. debconf handling, the next release will support config file conflicts questions.
[10:04] <Sweetshark> seb128: given that bug, I really want to have "encrypted swap/home" reported by apport too.
[10:04] <glatzor> rodrigo_, but there isn't yet a InstallPackageFile method
[10:05] <seb128> Sweetshark, should be an info easy to collect
[10:05] <rodrigo_> glatzor, ok, then we'd be fine with the compatibility layer for now, I guess
[10:05] <glatzor> rodrigo_, mvo It also seems that richard is moving away from the session bus interface to the native glib client - introducing PkTask which handles the transaction dance
[10:07] <rodrigo_> oh cool
[10:07] <mvo> hm, I always like the session bus interface
[10:08] <glatzor> rodrigo_, mvo me too.
[10:08] <glatzor> mvo, rodrigo_ oh guys, I have to leave for work. See you!
[10:08] <rodrigo_> well, PkTask would be a layer on top of it, or is the session interface going away?
[10:08] <rodrigo_> bye glatzor
[10:10] <mvo> see you glatzor
[10:11] <didrocks> X crashed on too many writing on disk :/
[10:13] <glatzor> rodrigo_, the session interface doesn't seem to go away but most new applications just use the glib client
[10:14] <glatzor> rodrigo_, at the time the session bus was introduced glib introspection wasn't available too
[10:16] <rodrigo_> glatzor, right
[10:29] <seb128> rodrigo_, http://pastebin.ubuntu.com/695561/
[10:29] <seb128> rodrigo_, could you tell me if that seems ok to you?
[10:31] <seb128> didrocks, ^
[10:31] <rodrigo_> seb128, looking
[10:31] <seb128> didrocks, the ubuntu session are "ubuntu" and "ubuntu-2d" right? and the XDG... name is Unity for both?
[10:31] <seb128> just checking, the patch seems to work fine there
[10:32] <chrisccoulson> yeah, i seem to have Unity for the XDG name here (in 2d)
[10:32] <seb128> chrisccoulson, thanks
[10:33] <didrocks> seb128: looks good for the sessions name, (pinging dbus to ensure we are in the session doesn't make sense I guess?)
[10:33] <seb128> chrisccoulson, $ gsettings get org.gnome.desktop.session session-name
[10:34] <didrocks> seb128: not sure for the XDG_CURRENT_DESKTOP, is it set by lightdm?
[10:34] <seb128> chrisccoulson, can you tell me what it gives?
[10:34] <rodrigo_> seb128, looks good to me, yes. I would use g_str_equal instead of g_strcmp0 though, but don't worry abnout that :-)
[10:34] <chrisccoulson> seb128, it says "ubuntu" here
[10:34] <seb128> rodrigo_, you are wrong :p
[10:34] <seb128> chrisccoulson, in 2d?
[10:34] <rodrigo_> :)
[10:34] <chrisccoulson> seb128, yeah
[10:34] <seb128> crap :-(
[10:34] <chrisccoulson> that doesn't sound right, does it?
[10:35] <seb128> rodrigo_, http://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-str-equal
[10:35] <seb128> "Note that this function is primarily meant as a hash table comparison function. For a general-purpose, NULL-safe string comparison function, see g_strcmp0(). "
[10:35] <rodrigo_> seb128, yeah, g_strcmp0 checks for NULL indeed
[10:35] <seb128> rodrigo_, I've been checking because I saw you used g_str_equal in your region panel patch
[10:40] <seb128> crap, that doesn't work
[10:41] <seb128> settings org.gnome.desktop.session session-name has no effect
[10:41] <seb128> vuntz, !!!
[10:42] <didrocks> seb128: what set XDG_CURRENT_DESKTOP ? instead of relying in nautilus on the dbus settings (but more exact to know if unity runs or not), I should probably rely on it
[10:42] <seb128> didrocks, no, session "org.gnome.desktop.session session-name" in gsettings doesn't change the session as it should
[10:44] <seb128> crap
[10:44] <seb128> ok, I will do it the debian way, hide that switch, it's just broken
[10:44] <didrocks> seb128: that doesn't answer on XDG_CURRENT_DESKTOP, is it linked to that? ::)
[10:45] <seb128> didrocks, lightdm does set it, I just copied what others did in gnome-control-center and gnome-screensaver
[10:45] <seb128> that seems to work fine
[10:46] <seb128> didrocks, chrisccoulson, vuntz: ok, the issue is that "org.gnome.desktop.session session-name" is only respected when there is no --session given to gnome-session
[10:46] <seb128> so it works for a "startx" login
[10:46] <didrocks> hum, /me grep -r in lightdm and didn't find it, looking
[10:46] <didrocks> seb128: meaning that all of those integration will be broken on gdm, better to still rely on dbus then…
[10:47] <seb128> didrocks, well I'm not sure what set XDG_CURRENT_DESKTOP, I though it was lightdm
[10:47] <seb128> we really a "is_unity_running()" api distro patched in glib or something :p
[10:47] <seb128> or gtk
[10:47] <didrocks> agreed
[10:47] <didrocks> or set that in the /usr/share/xsessions/*desktop file
[10:47] <seb128> I need to talk to desrt about it
[10:48] <seb128> if I distro patch that in glib he will track me down :p
[10:48] <didrocks> and he has good chance to find you! :-)
[10:48] <seb128> but we need to figure a proper way to get that info
[10:48] <seb128> ;-)
[10:48]  * didrocks still grep -r around :)
[10:49] <didrocks> ah, gnome-session
[10:49] <seb128> didrocks, https://bugzilla.gnome.org/show_bug.cgi?id=654041
[10:49] <ubot2> Gnome bug 654041 in general "Respect XDG_CURRENT_DESKTOP" [Normal,Resolved: fixed]
[10:50] <seb128> didrocks, seems gnome-session read it?
[10:50] <didrocks> hum, we have a distro-patch though
[10:50] <didrocks> debian/patches/52_xdg_current_desktop.patch
[10:50] <didrocks> quite lame to distro-patch our distro-patches .session files
[10:51] <didrocks> I guess I already have to refresh it because of that, but well :)
[10:51] <seb128> oh ok, distro patch in gnome-session
[10:52] <seb128> didrocks, so yeah, that should work with any login manager
[10:52] <seb128> so we can probably use that for GNOME and Unity, they both use gnome-session for all their sessions
[10:53] <didrocks> indeed
[10:55] <didrocks> seb128: I'll probably add the complex dbus call for nautilus on P then
[10:55] <didrocks> remove*
[10:57] <seb128> ok
[10:58] <seb128> vuntz, hello, how is "org.gnome.desktop.session session-name" supposed to interact with --session? ;-)
[11:00] <didrocks> seb128: it's the default session if no --session is set
[11:00] <didrocks> which I override to "ubuntu" for LTSP
[11:01] <seb128> didrocks, ok, so I fail to see how it can work even for gnome-shell
[11:02] <seb128> since all the gnome session we ship have a --session
[11:02] <seb128> i.e gnome-shell.desktop has "gnome-session --session=gnome"
[11:02] <didrocks> yeah, but is org.gnome.desktop.session session-name different?
[11:02] <seb128> it means the only case where the option can work is when you pick no session but startx
[11:02] <seb128> didrocks, different from what?
[11:02] <didrocks> is shouldn't gconf/gsettings shouldn't store states, isn't it?
[11:02] <didrocks> seb128: should still be ubuntu
[11:02] <seb128> didrocks, the "force fallback" switch in the info panel change the value of this key
[11:03] <seb128> that's how it "forces fallback"
[11:03] <didrocks> ah, interested :)
[11:03] <seb128> i.e it set the key to gnome-fallback
[11:03] <didrocks> yeah, I guess it doesn't work then
[11:03] <didrocks> (in ubuntu)
[11:03] <didrocks> because for the gnome-shell session
[11:03] <seb128> so my patch I just did was doing ubuntu,ubuntu-2d rather than gnome,gnome-fallback
[11:03] <didrocks> by defaut, the desktop key is Exec=gnome-session
[11:03] <didrocks> without --session
[11:03] <seb128> right
[11:03] <seb128> well I will just do what debian did
[11:04] <didrocks> seb128: the better way would be that to set the session in .dmrc
[11:04] <didrocks> wdyt?
[11:04] <seb128> "   * 90_force_fallback.patch: new patch. Disable the “forced fallback
[11:04] <seb128>      mode” switch, since we already provide a xsession file for it in
[11:04] <seb128>      gnome-session-fallback."
[11:04] <seb128> that's what Debian did
[11:04] <didrocks> (sorry, slowly catching up on that, didn't follow at all this discussion :))
[11:05] <seb128> didrocks, well, I'm leaning toward "just use the login screen selector to select your session"
[11:05] <didrocks> yeah, either that, or set the .dmrc
[11:05] <didrocks> but one place seems better IMHO
[11:05] <seb128> I don't fancy adding code to deal with dmrc :p
[11:05] <seb128> let's be consistent and use the login screen
[11:05] <didrocks> agreed
[11:05] <seb128> thanks ;-)
[11:05] <seb128> lunch time
[11:05] <seb128> bbl
[11:05] <didrocks> yw :-) thanks to you! Sorry for the time for catching up on the subject :)
[12:23] <seb128> rodrigo_, there?
[12:23] <seb128> or something else not under compiz
[12:23] <seb128> chrisccoulson, ? ;-)
[12:23] <rodrigo_> seb128, yes
[12:23] <chrisccoulson> hi seb128
[12:24] <seb128> could you try to open the removable media panel in system settings
[12:24] <chrisccoulson> yeah, done
[12:24] <seb128> click on "other media", close the dialog, click on "other media" again
[12:24] <seb128> does it work the second time or display a small empty dialog?
[12:24] <chrisccoulson> it works ok the second time
[12:24] <seb128> hum ok, thanks
[12:25] <seb128> chrisccoulson, oh
[12:25] <rodrigo_> seb128, yes, works ok both times
[12:25] <seb128> can you close it by the wm button
[12:25] <seb128> not by the close button
[12:25] <rodrigo_> seb128, it doesn't under compiz?
[12:25] <rodrigo_> ok
[12:25] <chrisccoulson> seb128, ah
[12:25] <rodrigo_> there's not, on gnome-shell
[12:25] <chrisccoulson> now it's broken ;)
[12:25] <seb128> rodrigo_, alt-f4?
[12:25] <chrisccoulson> so is that a bug that we can't blame compiz for?
[12:25] <seb128> chrisccoulson, seems so, thanks ;-)
[12:25] <rodrigo_> ah, but using atl-f4 indeed shows it's broken
[12:26] <chrisccoulson> dang
[12:26] <chrisccoulson> ;)
[12:26] <seb128> I will open a bug
[12:26] <seb128> thanks guys
[12:26] <seb128> well maybe I should check if that will still apply to trunk once they move that dialog in the info panel
[12:27] <rodrigo_> seb128, checking it now
[12:27] <seb128> rodrigo_, thanks
[12:28] <rodrigo_> seb128, happens the same, so assign the bug to me if you want
[12:28] <seb128> rodrigo_, ok, thanks
[12:29] <rodrigo_> ok, lunch now, bbl
[12:29] <seb128> well it's a very low priority issue
[12:29] <seb128> still a bug ;-)
[12:29] <seb128> rodrigo_, enjoy
[12:42] <cyphermox> seb128: hey
[12:43] <seb128> hey cyphermox, how are you?
[12:43] <cyphermox> not bad, doing the evo stuff now
[12:43] <seb128> great
[12:43] <cyphermox> rodrigo_ needs libnm-gtk, can you ack the network-manager-applet upload?
[12:44] <seb128> no, it's a release team call, try asking on #ubuntu-release
[12:44] <cyphermox> oh, sorry, thought you were :)
[12:44] <seb128> sorry, I'm archive admin but not release team ;-)
[12:44] <cyphermox> ah, that's my mistake then :)
[12:58] <Sweetshark> nice, bug 745836 just got kernelteamed.
[12:58] <ubot2> Launchpad bug 745836 in ecryptfs-utils "ecryptfs encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836
[12:59] <kirkland> that bug title is painfully inaccurate :-(
[13:00] <Sweetshark> kirkland: what would you like instead?
[13:00] <kirkland> Sweetshark: the swap is not encrypted by ecryptfs;  it's encrypted by the kernel's dmcrypt
[13:00] <kirkland> Sweetshark: it was configured by ecryptfs-setup-swap
[13:01] <kirkland> Sweetshark: which is merely a shell script that sets up swap for device mapper encryption
[13:02] <Sweetshark> kirkland: hmm, right. Ill remove "ecryptfs" from the title.
[13:13] <tseliot> cyphermox: do you plan on uploading the workaround attached in bug #856631 ? I solves the problem here
[13:13] <ubot2> Launchpad bug 856631 in pidgin "irc: periodic '/who' polling causes connection drops" [Undecided,New] https://launchpad.net/bugs/856631
[13:15] <cyphermox> tseliot: are you sure this is the right bug number or that I'm the one you want to ping? :)
[13:15] <cyphermox> that said, I certainly can upload that fix once I test it :)
[13:16] <tseliot> cyphermox: yes, that's bug. I use pidgin and I'm affected by that problem
[13:16] <tseliot> cyphermox: and thanks for your help :)
[13:17] <cyphermox> seb128: you mentioned a new e-d-s tarball yesterday; where would that be? it's not showing up on ftp.gnome.org (or at least I don't see it)
[13:17] <seb128> cyphermox, sorry, my mistake, it was in the 3.0 serie not 3.1 :-(
[13:17] <cyphermox> tseliot: sure, I'll get to it shortly (but it's after e-d-s/evo on my todo :)
[13:18] <cyphermox> seb128: ah ok :)
[13:18] <cyphermox> are we affected by that bug though?
[13:18] <tseliot> cyphermox: excellent, thanks again
[13:47] <rodrigo_> cyphermox, seb128: well, we are disabling the libnm-gtk stuff, so not really needed, just that if available, I'll remove the patch to disable it in g-c-c
[13:47] <cyphermox> rodrigo_: well, it's in queue now, pending approval by the release team
[13:48] <cyphermox> I had asked pitti about it before, he seemed okay with it once I explained the change
[13:48] <seb128> rodrigo_, bug #856824 is yours
[13:48] <ubot2> Launchpad bug 856824 in gnome-control-center "Gnome Control Center crashes if light-themes are not installed" [Undecided,Confirmed] https://launchpad.net/bugs/856824
[13:48] <seb128> cyphermox, try maybe pinging in #ubuntu-release
[13:48] <cyphermox> seb128: I had
[13:48] <rodrigo_> seb128, ok
[13:48] <cyphermox> well, didn't ping anyone, but I mentioned it :)
[13:48] <seb128> ok, let's wait for them then ;-)
[14:11] <seb128> slangasek, hey
[14:12] <seb128> slangasek, I've opened bug #857434 about the plymouth blocking the boot for 5 seconds issue, let me know if you need extra details
[14:12] <ubot2> Launchpad bug 857434 in plymouth "creates a 5 seconds delay in the boot" [Undecided,New] https://launchpad.net/bugs/857434
[14:13] <jbicha> seb128: here's a proposed desktop-extra list: http://paste.ubuntu.com/695657/
[14:15] <seb128> jbicha, hey
[14:15] <seb128> jbicha, some people were looking for you ;-)
[14:15] <jjardon> seb128: hi! Is it planned and update of the epiphany-browser package? (the new webapp feature is only available in 3.1.x versions)
[14:15] <seb128> jjardon, no
[14:15] <seb128> jjardon, hey ;-)
[14:16] <seb128> jjardon, epiphany 3.1 depends on an unstable webkit serie (1.5) and our security team doesn't feel like shipping an unstable webkit
[14:16] <seb128> jjardon, webkit-gtk really needs to get a schedule which is aligned with GNOME if GNOME depends on the current version :-(
[14:16] <seb128> jjardon, we will probably need to get those in the GNOME3 ppa or something
[14:17] <jbicha> seb128: I uploaded a new pitivi if that's what the problem was
[14:18] <jjardon> seb128: mmm, good to know. I'll talk with webkitgtk devels
[14:18] <seb128> jbicha, that work one of the two issue, the second one is that gnome-shell needs to be rebuilt for the clutter;cogl soname change but depwait on caribou
[14:18] <seb128> jjardon, thanks
[14:18] <seb128> jbicha, that work -> that was
[14:18] <seb128> jbicha, so right know gnome-shell is being removed if you dist-upgrade
[14:19] <seb128> jbicha, can we go back to patch the caribou requirement out to get it to build?
[14:19] <jbicha> I was waiting on bigon for caribou for gnome-shell as he wanted to fix/rearrange without needing a conflicts/replaces
[14:19] <seb128> jbicha, well, I doubt caribou will be in before monday, it would be nice to not let gnome-shell broken for the w.e
[14:19] <jbicha> that's too invasive, the first time wasn't too bad but it was a headache when I tried to rebase that patch
[14:20] <seb128> jbicha, it will first need to be uploaded, then to be reviewed
[14:20] <seb128> then to get a ffe
[14:20] <seb128> ok, so I guess we will live with a broken gnome-shell for some time
[14:20] <jbicha> the ffe was already granted: bug 845300 pitti uploaded the first time & would have uploaded yesterday
[14:20] <ubot2> Launchpad bug 845300 in Ubuntu Oneiric "[FFe] [needs-packaging] caribou" [High,Fix committed] https://launchpad.net/bugs/845300
[14:21] <bigon> fred peters suggest me somethng for caribou yesterday, I'll ahve a look
[14:21] <bigon> have
[14:21] <seb128> jbicha, ok, so let's see how it goes, it's usually hard to find archive admin on the w.e
[14:21] <bigon> this weeken
[14:21] <bigon> weekend
[14:21] <seb128> jbicha, thanks
[14:22] <seb128> jbicha, your desktop-extra set seems a good start, we shouldn't list things that are in the desktop set though, i.e gnome-utils
[14:22] <jbicha> bigon: thanks, the caribou thing happened at the same as the cogl transition which broke some things
[14:22] <seb128> jbicha, synaptic also is probably rather a mvo,packaging team component than a desktop one
[14:22] <davmor2> guys any idea why when I click on a date evolution tries to open?  I haven't installed evolution
[14:22] <seb128> jbicha, otherwise the list looks good
[14:23] <seb128> jbicha, we can discuss that next week during the team meeting
[14:23] <jbicha> seb128: ok I'll make those changes and mail to the desktop list
[14:23] <seb128> jbicha, yeah, mailing the list seems a good idea, thanks ;-)
[14:23] <seb128> davmor2, bug
[14:24] <davmor2> seb128: nm it looks like contacts sync pulled it in
[14:46] <jjardon> seb128: so the plan is to have 1.6 for GNOME 3.2
[14:47] <seb128> jjardon, ok, great, I doubt we will be able to change major series for webkit now though
[14:48] <seb128> jjardon, it's a bit suboptimal, they failed to their plan in previous cycles (i.e we ship 1.3 because 1.4 was not there for 3.0 in natty)
[14:48] <seb128> jjardon, and there was no 1.5 tarball for like 2 months this cycle so it didn't seem on track by then...
[14:48] <seb128> jjardon, well anyway I will check with pitti what we can do next week, thanks for checking with upstream
[14:49] <seb128> micahg, chrisccoulson, mdeslaur: ^ do you have any opinion on what webkitgtk serie would be best for Oneiric?
[14:49] <jjardon> seb128: I'll point this in the next r-t meeting. Definitevely we should improve this for the next cycle
[14:49] <seb128> well I doubt 1.4 to 1.6 will get a ffe now
[14:49] <seb128> jjardon, thanks
[14:51] <mdeslaur> seb128: honestly, I would like to stay with 1.4 so we don't ship a pre-release version again. That being said, we don't have a way of fixing the zillion security issues with webkitgtk as it is now, so I don't really know.
[14:52] <seb128> mdeslaur, well as said I doubt we can switch now anyway
[14:52] <seb128> the diff between those is probably far from trivial and webkit is used in quite some applications
[14:52] <seb128> including several desktop ones from the default installation
[14:53] <mdeslaur> it's kind of late to switch now, IMHO
[14:53] <cyphermox> why bother with webkitgtk when we have gtkhtml? :D
[14:53] <jjardon> seb128: those are using the pre-release version for some time now
[14:54]  * mdeslaur cries at so many default desktop applications exposing users to security issues
[14:57] <chrisccoulson> yeah, i'm glad i don't have to touch webkit ;)
[14:58] <seb128> jjardon, well the issue is that it's a non trivial diff, we sort of decided on the version to use at ff, we didn't do any testing of our softwares with 1.5
[14:59] <rodrigo_> hmm, I wonder if we don't add Adwaita to the list of themes in the Appearance panel
[15:00] <rodrigo_> s/if/why
[15:00] <rodrigo_> design decision, but still, I think it would make sense to offer it as a choice
[15:00] <seb128> rodrigo_, they would probably be fine with it knowing that it's not there by default anyway
[15:01] <chrisccoulson> rodrigo_, yeah, i'd like to be able to switch to adwaita when i use gnome-shell (without opening gnome-tweak-tool) :)
[15:01] <rodrigo_> yes, I guess they wanted the 4 themes we offer as choice, just because those are the only GTK3 ones installed by default
[15:01] <jjardon> seb128: the GNOME community already did some testing for you ;)
[15:01] <rodrigo_> chrisccoulson, I personally prefer Ambiance, much darker, which is what I like
[15:01] <rodrigo_> but yes, Adwaita should be in the list
[15:01] <rodrigo_> seb128, do you think we can add it this late?
[15:02] <jjardon> seb128: also Fedora
[15:02] <jbicha> rodrigo_: well it would only show if users have it installed, right?
[15:02] <rodrigo_> jbicha, yes, with my last change to the theme selector patch I just pushed to bzr
[15:03] <seb128> jjardon, not on ubiquity for example
[15:04] <seb128> or other ubuntu tools that use webkit
[15:04] <jjardon> xan_: Is there any api changes between 1.4 and 1.6?
[15:04] <xan_> no
[15:05] <jjardon> seb128: ^
[15:06] <jjardon> seb128: what are your concern? regression bugs?
[15:07] <seb128> jjardon, my concern is that it's 1 week from oneiric
[15:07] <seb128> we are hard frozen
[15:07] <seb128> it's hard to take non trivial changes and regression test them accross ubuntu in a week
[15:08] <seb128> even if in theory there is no change it could have bugs or we could have some application doing stupid stuff that used to work
[15:08] <seb128> i.e it's a risky change
[15:08] <seb128> I wish somebody would have raised that as an issue earlier than during hard freeze
[15:09] <seb128> I think we will just have to deal with webkit being 1.4 for Oneiric and get the new one in a ppa
[15:09] <seb128> and work better next cycle with webkitgtk guys to have a public schedule and regular tarballs
[15:09] <jbicha> I looked for a release schedule but couldn't find one, I agree with seb128 that it was unclear whether it would be ready
[15:10] <seb128> when we decided at feature freeze there was only one tarball in the 1.5 serie in months and it looked like it was going to not get there on time
[15:10] <xan_> we have said a bunch of times we are in sync with gnome
[15:10] <seb128> we did the reverse in natty, we went for 1.3 and got bitten by 1.4 not being on time
[15:10] <seb128> xan_, and you failed to roll regular tarball, and you failed to roll 1.4 in time for GNOME 3.0
[15:10] <rodrigo_> seb128, so, do you agree on adding Adwaita to the list of themes (only shown if it's installed)
[15:11] <xan_> I guess the message is not getting across, so I accept suggestions to improve it
[15:11] <seb128> rodrigo_, yes
[15:11] <rodrigo_> seb128, ok
[15:11] <xan_> seb128: 1.4.0 made it for GNOME 3.0 AFAIK
[15:11] <xan_> everyone is using it at least
[15:11] <slangasek> seb128: plymouth> is this a different machine than the one being put through daily testing by QA?
[15:11] <seb128> xan_, we shipped natty with 1.3.13 which was current when we hard froze natty
[15:12] <jjardon> kenvandine: some free time to roll a new package? https://launchpad.net/indicator-power/trunk/0.8
[15:12] <jbicha> xan_: https://lists.webkit.org/pipermail/webkit-gtk/2011-June/000594.html we of course shipped in April
[15:12] <xan_> jbicha: that's 1.4.2
[15:12] <slangasek> seb128: seems so, looks like it's a machine you have local access to... ok, will chase that bug, thanks
[15:12] <seb128> slangasek, sorry, was replying to xan
[15:13] <seb128> slangasek, the machine is my work laptop
[15:13] <seb128> slangasek, so I get do any testing you need
[15:13] <slangasek> seb128: ok, cool :)
[15:13] <seb128> slangasek, out of the "I don't want to reboot now because I don't want to stop what I'm doing" ;-)
[15:13] <seb128> slangasek, thanks for looking into it
[15:14] <xan_> jbicha: 1.4.0 was released on april 25th
[15:14] <kenvandine> jjardon, sure
[15:14] <jjardon> kenvandine: thanks!
[15:15] <jbicha> xan_: but that was the first announcement as stable to the mailing list
[15:15] <seb128> xan_, which was 3 weeks after GNOME3
[15:16] <seb128> xan_, we usually need the stack a bit earlier than GNOME since we hard freeze close from the new GNOME dates
[15:16] <seb128> xan_, so it means your schedule is one month late for us (or was for 1.4)
[15:16] <xan_> seb128: true, 3.0 was a busy cycle, we just delivered for it to be in the distros. Lots of development happened for 3.0.1 in many modules.
[15:17] <xan_> in any case, we try to be in sync with gnome, and we ourselves depend on webkitgtk+ so we'll ship it
[15:17] <seb128> xan_, ok, noted for next cycle
[15:17] <seb128> xan_, it would help if there was a public schedule somewhere we can refer to when we take our decision (even if it states that you will stick to GNOME) and to have regular tarballs during the cycle
[15:18] <seb128> xan_, it tooks months to get a 1.5.2 this cycle it seems, when we looked at 1.5 at our feature freeze current was style .1
[15:18] <slangasek> seb128: so are you referring to the 5 seconds between plymouthd startup and udev startup?
[15:18] <xan_> seb128: we do as many as we can, we are all very busy :)
[15:19] <seb128> slangasek, yes
[15:20] <seb128> xan_, right, and we ship on fixed dates and need a stable version so we have our constrains as well
[15:20] <seb128> xan_, 1.4 seemed to best choice when we looked at it for this cycle
[15:20] <xan_> seb128: I'm not really complaining
[15:20] <xan_> I was just asked to join and answer questions
[15:21] <xan_> if there's misunderstandings about our intentions it's good to clarify them and we can try to do a better job
[15:21] <seb128> xan_, ok, thanks for joining
[15:21] <slangasek> seb128: why is plymouth in your initramfs?
[15:21] <slangasek> (crypted swap?)
[15:22] <xan_> but in the end we can fail to do as many releases as we could or release exactly on time, we are only human...
[15:22] <xan_> (and releasing webkit is not trivial unfortunately)
[15:22] <seb128> xan_, I will note for next cycle that you really try to stick to GNOME schedule and that we should be fine updating
[15:22] <seb128> slangasek, euh, dunno, my user is an ecryptfs one
[15:22] <slangasek> seb128: right, ecryptfs turns on crypted swap.  ok
[15:22] <seb128> slangasek, but out of that I did nothing technical to my config
[15:22] <xan_> seb128: that sounds fair. If we screw up massively you won't be the only one complaining anyway
[15:23] <seb128> xan_, thanks
[15:23] <seb128> xan_, sorry it didn't work well this cycle, we will do better next one ;-)
[15:23] <xan_> seb128: we were particularly busy this cycle, hopefully the next one will go smoother
[15:24] <jjardon> Maybe It would be a good idea to have a special rule for external dependencies, to avoid situations like this.
[15:24] <seb128> xan_, and yeah, I understand people being busy, release being hard to get out etc, that's why we decided to be conservative since our shedule doesn't let lot of margin for slips
[15:24] <seb128> things is that we can trust GNOME tarballs to be on time
[15:24] <seb128> but it's harder for external depends, there is no promise there
[15:24] <xan_> seb128: one thing you can do is see what epiphany does, which I maintain
[15:25] <seb128> it's a best effort thing, and some bite us back in the past
[15:25] <xan_> if it depends on unstable webkit you can be sure a stable release will happen ;)
[15:25] <seb128> or not... see 1.4 ;-)
[15:25] <xan_> well, we released a couple of weeks later
[15:25] <xan_> but pushing 1.4 if you are already using 1.3.13 is a no-brainer IMHO
[15:25] <seb128> which was after we pressed our CDs
[15:26] <xan_> right, well
[15:26] <seb128> we don't like to press CDs with an unstable version of an important lib
[15:26] <xan_> I guess your schedule is extremely tight
[15:26] <seb128> it is
[15:26] <xan_> then I agree it's risky stuff
[15:26] <seb128> which was my point, we tend to be conservative because we have little time margins for slips
[15:26] <xan_> I guess I can try to be fanatic about releasing exactly on time
[15:27] <xan_> but you could also have some more buffer time for GNOME stuff :P
[15:27] <seb128> it would help to at least have a RC with GNOME RC ;-)
[15:27] <seb128> yeah, I'm trying to work on that for next cycle
[15:27] <xan_> well, we shipped 1.5.90 this time
[15:27] <xan_> :)
[15:27] <seb128> GNOME shifted a bit his cycle as well, we used to ship with .1
[15:27] <xan_> and I think we delivered in all the past cycles
[15:27] <xan_> 1.0.x and 1.2.x
[15:27] <seb128> ok
[15:28] <seb128> so seems we should try to follow you next cycle
[15:28] <seb128> and I will come complaining if things slip too much and we are in a difficult position :-)
[15:28] <xan_> please do
[15:28] <seb128> or complaining^W nicely ask for a tarball
[15:28] <seb128> thanks! ;-)
[15:28] <xan_> if someone asks nicely about really needing a tarball it's more likely to happen :)
[15:28] <jjardon> seb128: feel free to complain to the r-t also ;)
[15:29] <seb128> jjardon, I will do, though it's not really in r-t realm to tell webkit what to do since it's part of GNOME ;-)
[15:30] <seb128> it's always a bit difficult with external depends
[15:30] <jjardon> seb128: sure, but we can try to search a solution if the things are not working well
[15:30] <seb128> it's like cairo, should we follow 1.11. ;-)
[15:30] <xan_> I have to say that for an external dependency we are massively aligned with gnome in any case
[15:31] <xan_> so we are not the usual external dependency..
[15:31] <seb128> right, I was a bit unsure about that, it's good to read
[15:31] <jjardon> there are plans to divide external dependencies in several classes, Its not the same libxml2 than webkitgtk, for example
[15:32] <seb128> it's part our fault for not having somebody assigned to maintain webkit in Ubuntu
[15:32] <jjardon> we are going to discuss that for the next cycle
[15:32] <kenvandine> jjardon, i see you have a couple of bug fixes in trunk since 0.8, want to roll a 0.9 and get those in too?
[15:32] <seb128> so nobody with close contact with upstream or enough insight to have a good opinion on what to do
[15:33] <jjardon> kenvandine: oh, you are rigth. let me roll a 0.9 release
[15:33] <kenvandine> great
[15:33] <kenvandine> let me know when it is ready
[15:34] <slangasek> seb128: reassigned to the kernel ;)
[15:34] <seb128> slangasek, thanks ;-)
[15:34] <xan_> ok, see you
[15:38] <jbicha> kenvandine: there's no particular reason why gwibber still uses python-support, is there?
[15:39] <dobey> desrt: ping
[15:40] <kenvandine> jbicha, i don't think so
[15:41] <jjardon> kenvandine: https://launchpad.net/indicator-power/trunk/0.9 ;)
[15:41] <kenvandine> jjardon, thx
[15:42] <dobey> rodrigo_: feliz cumpleanos
[15:43] <didrocks> dobey: who is working on the ubuntu-sso-client this cycle?
[15:43] <jjardon> seb128: I'd like to have feedback about the external dependencies reorganization: https://mail.gnome.org/archives/release-team/2011-April/msg00232.html
[15:44] <dobey> didrocks: in what sense? i'm guessing you don't mean in terms of windows porting :)
[15:44] <didrocks> dobey: no, on the ubuntu version :)
[15:44] <jjardon> rodrigo_: feliz cumpleaños!!
[15:45] <rodrigo_> dobey, jjardon: gracias :)
[15:45] <seb128> jjardon, I like it mostly, it would just be nice to have a public list of what you consider being in each category, is that list somewhere?
[15:46] <rodrigo_> indeed, it's my birthday, so time to go out and get drunk :)
[15:46] <jjardon> seb128: no, we are still discussing it
[15:46] <dobey> didrocks: mostly nobody; is there a bug that needs fixed or something?
[15:46] <seb128> jjardon, also for 2. I would prefer something which encourage not depending on unstable series for those components since having a stable GNOME depending on an unstable library is not a good thing for anyone
[15:46] <didrocks> dobey: yeah, it seems to puzzle people, one sec, filing step to reproduce
[15:47] <jjardon> seb128: agree
[15:47] <rodrigo_> seb128, pitti, didrocks, chrisccoulson: if you feel like, please endorse me when you have time at https://wiki.ubuntu.com/RodrigoMoya/MOTUApplication
[15:47] <seb128> rodrigo_, oh right, will do
[15:47] <rodrigo_> as I said yesterday, I'll pay endorsements back with beer :)
[15:47] <seb128> ;-)
[15:48] <rodrigo_> oh jbicha already won 1 beer!
[15:48] <chrisccoulson> i was just about to suggest that ;)
[15:48] <jjardon> seb128: maybe we should depend on stable libraries in the end of the cycles
[15:48] <rodrigo_> thanks jbicha
[15:48] <chrisccoulson> -EPLEASEINSERTBEER :)
[15:48] <rodrigo_> :D
[15:49] <seb128> jjardon, what do you mean? you can't really go back, let's assume GNOME 3.1.1 started depending on cairo 1.11 or poppler 0.17
[15:49] <desrt> dobey: pong
[15:49] <rodrigo_> talking about beer, time for me to go pick one or 2, so have a good weekend all!
[15:49] <seb128> jjardon, what would you do now since those are still not close from a stable version?
[15:49] <jbicha> rodrigo_: lol, have a good weekend
[15:50] <seb128> rodrigo_, thanks, enjoy your w.e!
[15:50] <dobey> desrt: why does g_settings_set_strv() take a const gchar * const* if _get_strv() returns a gchar**?
[15:51] <jjardon> seb128: so you suggest that 2 dependencies should be always stable versions?
[15:51] <desrt> dobey: it's quite usual that functions return references to you but do not consume the ones that you pass to them
[15:51] <didrocks> dobey: does it make sense to you: bug #857514
[15:51] <ubot2> Launchpad bug 857514 in ubuntu-sso-client "/usr/lib/ubuntu-sso-client/ubuntu-sso-login shouldn't stop if a login dialog is shown" [Undecided,New] https://launchpad.net/bugs/857514
[15:51] <dobey> g_settings_set_strv(settings, key, g_settings_get_strv(settings, key)); -> compiler warning
[15:51] <desrt> dobey: as well it should be.  you just leaked memory.
[15:52] <desrt> dobey: g_settings_get_strv() is documented: Returns: a newly-allocated, NULL-terminated array of strings, the value that is stored at key in settings.
[15:52] <dobey> the memory leak is obviousl wrong there, but passing in a gchar** doesn't leak memory
[15:52] <dobey> and gcc doesn't warn about memory leaks (though would be awesome if it did)
[15:53] <desrt> dobey: so you're dealing with my second most-hated thing about C
[15:53] <desrt> dobey: use C++ :)
[15:53] <seb128> jjardon, yes
[15:53] <desrt> (seriously: if you compiled exactly that code with a C++ compiler, the warning would go away)
[15:53] <desrt> C++ understands that it's always safe to promote char** to const char * const *
[15:53] <desrt> but C does not
[15:53] <desrt> so you must cast
[15:53] <dobey> i want to use APIs that aren't designed to give me compiler warnings
[15:54] <desrt> dobey: use a cast
[15:54] <dobey> meh
[15:54] <seb128> jjardon, or at least that we require having a public schedule from those project stating they will have their next stable out on time
[15:54] <desrt> dobey: or construct an array of const char *
[15:54] <desrt> that's not so difficult to do...
[15:55] <desrt> dobey: or petition the ISO to fix this stupidity
[15:55] <desrt> dobey: casting 'char **' to 'const char **' is actually unsafe
[15:55] <dobey> didrocks: no, that doesn't make sense. it tracks pending requests afaik
[15:56] <jjardon> seb128: I think that would work: If some GNOME dev needs some unstable version of a external library, He has to request info about the plans to the library authors, and make a propossal to the r-t with the info later
[15:56] <desrt> dobey: but 'char **' to 'const char * const *' should really be automatic
[15:56] <seb128> jjardon, right
[15:56] <didrocks> dobey: can you test? I experienced it, and multiple people experienced it
[16:00] <didrocks> desrt: I have an easy way to test if you are on oneiric up to date
[16:07] <desrt> didrocks:  i am not :)
[16:09] <didrocks> argh dobey ^
[16:09] <didrocks> sorry desrt ;)
[16:10] <didrocks> too many d* here :)
[16:11] <seb128> cyphermox, did you upload evolution yet?
[16:11] <dobey> didrocks: my laptop is up to date
[16:13] <dobey> i need to get lunch though right now; add it to the bug :)
[16:15] <didrocks> dobey: done, I guess that's the easiest way to get it, I'll add a different test case as well
[16:16] <micahg> seb128: I think we should stick with 1.4.x for release, we can do rebuild testing and upgrade to 1.6.x post release if we have to
[16:17] <seb128> micahg, right
[16:17] <micahg> and I'll get natty fixed eventually...
[16:27] <cyphermox> seb128: I did
[16:28] <jbicha> kenvandine: gwibber wouldn't build for me http://paste.ubuntu.com/695718/
[16:30] <seb128> cyphermox, ok, I've looked at the vcs, there is quite some git_* still there, should they we cleaned?
[16:30] <seb128> cyphermox, you didn't push the update the to the vcs as well
[16:30] <didrocks> dobey: so, reproducer on comment #2, should give you more insight :)
[16:30] <cyphermox> no, not yet because it's still in the unapproved queue, thought it better to wait
[16:31] <seb128> cyphermox, no, it's usually better to not wait ;-)
[16:31] <kenvandine> jbicha, wrong valac version
[16:31] <kenvandine> jbicha, it needs 0.12
[16:31] <kenvandine> i should make the build smarter to detect valac-0.12 and use that
[16:32] <jbicha> kenvandine: ah, thanks
[16:32] <seb128> cyphermox, better to push whatever you do to avoid somebody else to commit other changes and have to rebase
[16:32] <kenvandine> jbicha, so to build locally, you need to update-alternatives --set valac /usr/bin/valac-0.12
[16:32] <kenvandine> something like that
[16:32] <cyphermox> pushed now
[16:32] <kenvandine> then if you want valac-0.14 to be the default, change it back after you are done building
[16:33] <kenvandine> sucks, i know
[16:34] <cyphermox> and yeah, we should drop those files. they're not listed in debian/patches/series though
[16:38] <mterry> kenvandine, deja-dup uses a modified version of PROG_VALAC that specifies 'valac-0.12' as the executable to help with that: http://bazaar.launchpad.net/~deja-dup-hackers/deja-dup/20/view/head:/acinclude.m4
[16:39] <kenvandine> mterry, awesome, thx!
[16:46] <seb128> cyphermox, thanks
[16:47] <seb128> cyphermox, yeah, seems like you added them a while back and forgot to bzr del them once they were dropped from the series
[16:51] <cyphermox> brb, lunch
[16:53] <seb128> cyphermox, enjoy!
[16:56] <didrocks> ok, time for week-end and some exercice, see you on Monday guys!
[16:59] <kenvandine> jbicha, ok, gwibber trunk will build now without updating alternatives
[17:04] <jbicha> kenvandine: I pushed the dh_python2 switch to the ubuntu-desktop branch
[17:09] <kenvandine> jbicha, thx, i'll look at it
[17:15] <seb128> jbicha, did you add the "ffe?" to the gthumb line in the etherpad?
[17:16] <jbicha> seb128: yes
[17:17] <seb128> jbicha, not sure but I assume we are on an unstable serie so we can as well get the current version from it
[17:18]  * kenvandine needs to get around to a gwibber 3.1.92 release this weekend... so behind
[17:21] <seb128> kenvandine, keep some capacity for next week, you have to maintain firefox, tb and deja-dup for a while
[17:21] <seb128> ;-)
[17:21]  * kenvandine hides under a big rock
[17:21] <kenvandine> :-D
[17:23] <seb128> oh, come on, mterry and chrisccoulson deserve some holidays and you stocked energy with yours ;-)
[17:23] <chrisccoulson> heh
[17:24] <mterry> :)
[17:28] <jbicha> seb128: I guess you're right, the fact that we shipped 2.13.1 in natty confused me
[17:29] <jbicha> seb128: what do you think about bug 839407? it's a regression from Natty, does it need a freeze exception to get back on the CD?
[17:29] <ubot2> Launchpad bug 839407 in gnome-utils "gnome-font-viewer missing in oneiric" [Undecided,Fix released] https://launchpad.net/bugs/839407
[17:30] <seb128> jbicha, check with pitti on monday, I'm not sure how useful it is to install fonts in an OS where you can't select the font to use...
[17:30] <seb128> "on an OS"
[17:30] <seb128> but I'm fine having it on the CD as well
[17:31] <seb128> i.e I don't really have a strong opinion either way, I don't think it's really that useful for most users but it's small and doesn't hurt to get
[17:35] <mterry> tedg, how are dbusmenu_menuitem_proxy objects created?
[17:36] <mterry> tedg, (I don't see the entry point to them from the rest of libdbusmenu)
[17:40] <tedg> mterry, They're created by the sound menu and the messaging menu.
[17:40] <tedg> mterry, They're the custom menuitems in those menus.
[17:41] <tedg> mterry, The app exports, the service then proxies and exports an integrated menu.
[17:41] <mterry> tedg, ok.  found a small leak there, but it's not the big one
[17:42] <tedg> mterry, Ah, cool.
[17:43]  * tedg is starting to realize that he doesn't have the bandwidth to have Qt installed on his machine... qt4-doc, 85M, seriously?
[18:05] <jbicha> seb128: are you able to push caribou into the new queue or do I need an AA even for that?
[18:12] <micahg> jbicha: seb128 is an AA :)
[18:15] <jbicha> micahg: cool, thanks
[18:15] <jbicha> seb128: I believe we're ready for caribou then
[18:17] <jbicha> but can core-dev add new source packages?
[18:18] <micahg> jbicha: MOTU and core-dev can upload a new source, an AA has to review it before it can hit the archive and build
[18:20] <jbicha> thanks
[18:48] <seb128> jbicha, do you need sponsoring?
[18:49] <jbicha> seb128: yes please https://code.launchpad.net/~jbicha/+junk/caribou
[18:59] <seb128> jbicha, sponsored, you can go on #ubuntu-release to point to the ffe bug and ask for it to get in ;-)
[19:09] <ricotz> cyphermox, hello :), i noticed a small problem with network-manager-applet -- libnm-gtk0 is missing a versioned conflict with the old nm-gnome package
[19:10] <cyphermox> ricotz:  good catch
[19:10] <ricotz> currently the update is a bit bumpy ;)
[19:10] <cyphermox> it has been released?
[19:10] <ricotz> it isnt accepted yet, so you can still replace it
[19:10] <cyphermox> ahah, yeah
[19:13] <cyphermox> I'm not familiar with that procedure quire so much; seb128, I just upload a new revision on top?
[19:14] <seb128> cyphermox: either that or reupload the same and ask for the previous one to be rejected
[19:14] <cyphermox> ok
[19:14] <cyphermox> can you reject it n-m-applet?
[19:14] <seb128> cyphermox: seems infinity is doing active review, you can maybe get him to ack the upload for you ;-)
[19:15] <seb128> cyphermox: rejected
[19:15] <cyphermox> thanks
[19:15] <seb128> yw
[19:57] <cyphermox> I hate netlink so much.
[20:22] <jbicha> seb128: does gnome-shell need to be manually pushed for depwait or will it rebuild automatically?
[20:22] <seb128> jbicha, the later one
[21:54] <slangasek> anyone here know when the new upstream version of lightdm is meant to be uploaded?  it's entangled a plymouth-shutdown-related fix that I had staged in bzr
[21:54] <slangasek> I don't think I want to push that to the archive without robert_ancell's sign-off :)