[00:02] It'd be neat :) [00:14] charlie-tca: have you looked to see what edubuntu is doing? I think they only replace the wallpaper but it's at least something [01:07] jbicha: why does everyone except Unity have to make these things happen by little bits? There really should be a way for any of us to have a custom greeter, instead of just Ubuntu. [01:11] Wasn't that what robert_ancell was saying? You'd make xubuntu-greeter, and the xubuntu-desktop package would install that, and the postinst would frob lightdm-set-defaults? [01:13] That's what I asked for. Hopefully we can make that happen now [01:23] can a debian pacakge conflict with something that it provides? I want to make lightdm-gtk-greeter-config-ubuntu provide lightdm-gtk-greeter-config but not allow any other configuration variant to be installed at the same time [01:24] robert_ancell: yes [01:24] robert_ancell: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts [01:25] charlie-tca, RAOF, micahg: does this look like it might solve the problem? http://paste.ubuntu.com/692688/ [01:25] micahg: ?? [01:26] robert_ancell: It wants a Replaces: too, right? [01:26] robert_ancell: you need a replaces as well, that only lets one at a time be installed (like a mail daemon) as opposed to like the display managers [01:27] The replaces always confuses me, shouldn't the conflicts be sufficient? [01:27] robert_ancell: thank you for your efforts [01:27] I guess it replaces the existing one? [01:27] robert_ancell: replaces allows one package to replace a file in another package [01:27] charlie-tca, np, I hate dpkg :) [01:27] No; Conflicts tells apt to balk at installing it, Conflics+Replaces has special semantics. [01:27] (As does Replaces+Breaks) [01:28] Should this fundamentally be a debconf option? [01:28] Like the x-display-manager doodad? [01:28] RAOF, no, because the GTK greeter can't know how many configurations are out there [01:29] it's like installing gnome-settings-daemon and it asking you "Are you using this with Unity or GNOME or both?" [01:29] robert_ancell: I'd suggest a file like default.conf in a .d which says which one is in use [01:29] Well, the gtk greeter could grow a capability, like what micahg suggested. [01:30] then a debconf option can write to that file [01:30] conflicts/replaces on a configuration file might get weird; I'm not sure. [01:30] But you might start to fight dpkg's conffile handling. [01:32] micahg, do you mean the greeter loads /etc/lightdm/lightdm-gtk-greeter.conf.d? [01:32] It would be that the postinst scans /etc/lightdm/lightdm-gtk-greeter.conf.d and presents each of the included files as a possible default, then sets that one. [01:33] robert_ancell: it could load whatever greeter that /etc/lightdm/lightdm-gtk-greeter.conf.d/default.conf says to [01:33] or do whatever gdm/lightdm does for its alternatives [01:33] micahg, that's adding layers on layers. Why doesn't it just load it's one configuration, and a higher level decides what that should be? [01:34] robert_ancell: how does lightdm register as the default dm? [01:34] You could do that with alternatives; the GL packages do it that way, to provide their appropriate ld.so.conf (among other things). [01:35] That's also how plymouth themes work, IIRC. [01:35] (Although with plymouth I don't think you're alternitivesing a conffile) [01:36] micahg, there's a difference between the daemon (lightdm) and the greeters (lightdm-gtk-greeter). The daemon needs to register with the system to ensure it's the only one on startup, but the greeters are just like applications [01:36] robert_ancell: I understand, but we can reuse the same principle [01:36] only allow one at a time to be primary [01:37] and give users an easy way to switch between them [01:41] that would absolve the need for extra layers [01:56] ok, I can confirm having the two packages works with dpkg conffiles behaviour [02:10] charlie-tca, does bug 845549 make sense? [02:10] Launchpad bug 845549 in lightdm "Do not ship /etc/lightdm/lightdm-gtk-greeter.conf" [High,Fix committed] https://launchpad.net/bugs/845549 [02:16] RAOF: question, were we planning to merge in my xserver patch this week ? [02:17] smspillaz: It's in the xserver git tree. Does it want to be in before or after beta 2? [02:17] preferably before since it fixes a fairly important bug [02:17] (ie: The next upload will have it. When would you like it ?) [02:17] Got a LP handle on that? [02:17] sure, hang on [02:18] Hm: Qt says ?ConfigureWindow window=0x02400010 values={width=65535 height=65535}?. This is unlikely to end well. [02:18] https://bugs.launchpad.net/ubuntu/+source/unity/+bug/847967 [02:18] Ubuntu bug 847967 in unity "A minimized window 'remains' behind on the desktop if /apps/compiz-1/plugins/unityshell/screen0/options/show_minimized_windows is set to true" [High,In progress] [02:18] RAOF: sounds like a stupid application [02:19] RAOF: interestingly enough, we should be able to handle that case in compiz now (if the server doesn't BadAlloc) [02:19] smspillaz: That's bug It's bug #805303 [02:19] Launchpad bug 805303 in xorg-server "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed with the default qt4 gui" [Critical,Confirmed] https://launchpad.net/bugs/805303 [02:19] except that I haven't had any luck convincing distro to turn support for windows > max texture size on [02:19] The server, would you believe it, doesn't particularly like RENDER requests against that window :) [02:19] wow [02:20] yeah I did notice problems with vlc the other day [02:20] smspillaz: Doesn't unity break compiz's max texture size support anyway? [02:20] RAOF: sort of [02:20] RAOF: you can still have windows > mts, but not a screen size > mts [02:20] because we didn't get time to implement multiple textures for the framebuffer object [02:21] maybe we can do it as part of this week's bugs [02:21] By "Screen size" you mean "Size of a single RandR display", right? [02:21] robert_ancell: yes, it makes sense to me. Thank you very much. [02:21] RAOF: no, DefaultScreen (dpy)->width/height :) [02:22] smspillaz: So, when you say ?sort of?, what you *actually* mean is ?yes, absolutely? :P [02:23] Although I guess there may sometimes be a use for a window bigger than the total area of your displays. [02:23] RAOF: nope, I meant sort of [02:23] RAOF: you can have *windows* larger than your maximum texture size [02:23] the total output on your screen will be limited to your max texture size [02:24] however, the plugin which provides support for this is off by default [02:25] Correct me if I'm wrong, but the current ?Unity sort of breaks this? means that having multiple displays, where one axis is > max_texture_size, will still catastrophically fail. Right? [02:25] yes, correct [02:26] Turning on that plugin before that's fixed doesn't really seem like a huge win :) [02:26] next cycle we'll make it so that nux's framebuffer objects support binding over multiple textures [02:26] RAOF: well, if some stupid client decides to create a huge window that doesn't hit a BadAlloc then it will work [02:26] What will currently happen? [02:27] They'll get a blank app window? [02:27] compiz fails to bind the texture and you get a white window [02:27] I guess that's something that'd be good to be avoided. [02:27] oh and the decorator will crash since it pixmap type decorations which exceed your maximum texture size are not supported so it will try to switch to the legacy reparenting mode [02:28] except that the legacy mode is ... essentially unmainted [02:28] *unmaintained [02:29] RAOF: also, I found out that xorg-devel is suprisingly higher traffic than I thought [02:29] Hah! Yes.e [02:30] RAOF: I get the impression that you are still somewhere where typing is an inconvenience [02:30] No; I'm just bouncing IRC around the world. [02:31] RAOF: oh, still in the states ? [02:31] No, just using a different IRC bouncer. [02:31] ah ok [02:31] RAOF: anyways, just came in to poke you about that xserver patch [02:31] :) [02:31] Wow. Is a 65535x65535x32bpp pixmap *really* 16 GB? [02:32] RAOF: 16 GiB more likely [02:32] Well, yeah. [02:33] smspillaz: Ok. I'll finish testing the xserver upload, add that bug reference, and upload. [02:33] scwheeeeeeeet [02:33] * smspillaz watches the number of bug reports about "OMG INVISIBLE WINDOWS" skyrocket down [02:33] RAOF: oh for testing purposes [02:34] RAOF: if you have unity compiled from source [02:34] if you run unity/tests/test-input-remover/test-input-remover [02:34] if it complains about a BadValue [02:34] then its not working [02:34] Thanks for that! [02:34] * RAOF goes to compile unity from source, and run that against the old xserver. [02:34] well, a BadValue [02:34] then it will hang [02:34] RAOF: err [02:35] RAOF: so you may want to just run the test independently [02:35] compiling unity takes a very long time [02:35] longer than the X server [02:35] so just go into tests/test-input-remover/ [02:35] Fortunately, dual-core sandybridge i5 + a reasonably fresh ccache ;) [02:35] and then mkdir build ; cd build ; cmake .. ; make ./test-input-remover [02:35] Although that sounds easier :) [02:35] RAOF: I'm going to fix that at the sprint [02:36] err UDS [02:37] RAOF: ... you don't want to know the crazy thing I am doing to fix that bug btw :/ [02:38] in order to avoid abi breaks in compiz ... I'm fixing the server [02:38] yeah [02:38] we're awesome like that [02:38] It *sounds* like your XShaping the window away, and then lying to the clients about it? [02:38] RAOF: sort of [02:38] RAOF: we XShape the input away but disable event generation while we're doing it, since we listen for XShape events ourselves [02:39] but then core needs to know when the XShaping actually happened so that it will update the parent window shape correctly if the client resizes itself while hidden [02:39] so we tell core about the XShaping and ignore any events that come from send_event on our side [02:42] Oh, right. And that's when the client can find out about the XShape change if it wants to. [02:42] well [02:42] it gets the notification twice' [02:43] but its the same notification, so meh [02:43] xsendevent is really dangerous though [02:43] its only ever safe to send events with values that come directly from the x server itself [02:44] I wrote about it on my big braindump on window stacking (http://smspillaz.wordpress.com/2011/09/18/braindump-how-to-get-window-stacking-right/) [02:44] This is one of many pieces of the X server I'm blissfully unaware of. [02:44] RAOF: like many other things, XSendEvent is a hack [02:44] the server does no checks whatsoever except on the event type and client message format [02:45] you can send *whatever you like* to a client [02:45] for example, you can send a DestroyNotify to a client saying one of its windows was destroyed [02:45] and the client will probably not know any better [02:46] RAOF: even if a client specifically requested not to receive certain events, you can send them anyways [02:46] Fun! [02:47] and the client will still get them [02:47] What could possibly go wrong! [02:47] anyways, I need to study for this class [02:47] RAOF: so much possible breakage :/ [02:49] apparantly java is being stupid again: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/843530 [02:49] Ubuntu bug 843530 in compiz "java6 popup window buttons are obscured in compiz" [Undecided,Confirmed] [02:57] Yay! [03:10] hey robert_ancell ... any luck deciphering what is going on with the lag in Unity-greeter? [03:11] * jasoncwarner_ so curious what it could be! :) [03:11] jasoncwarner_, one of the bug reporters seems to have some indication it might be xrandr related [03:11] jasoncwarner_, I'll make you a package with gnome-settings-daemon disabled and let's see if that makes a difference [03:15] robert_ancell: ah...ok...send it and I'll give it a shot [03:17] Huh. Does this only happen on Intel systems? Keith was saying that there's a known-regression in the VGA probing which makes it hugely pessimistic (and where the 1sec stop in X server startup comes from). [03:18] jasoncwarner_, ok, sent [03:19] RAOF, people are mentioning intel [03:19] RAOF, have you ever seen the problem? [03:19] Yes. [03:19] RAOF, can you run your X magic on it to see what the greeter is doing to X? [03:19] Also, it seems to correlate with the high Xserver CPU usage during the bootchart. [03:20] robert_ancell: Where can I insert my shim? [03:20] RAOF, set display-setup-script in SeatDefaults [03:21] I'm not 100% sure it's working in the current version, but it's worth trying. It definitely works on the next version [03:21] Actually, I could probably just replate /usr/sbin/unity-greeter with a nice little script? [03:22] RAOF, yes, that would do it [03:23] RAOF, or edit /usr/share/xgreeters/unity-greeter.deskto [03:23] RAOF, or edit /usr/share/xgreeters/unity-greeter.desktop [03:23] robert_ancell: got it...be back in a few after testing... [03:23] RAOF: what system did you see it on? [03:24] Sarvatt: Everyone's favourite GM45! [03:24] I'm not sure about the sandybridge. [03:24] oh ok, was going to be confused if you said the e6420 because thats fine here [03:24] so yet another lenovo to the mix [03:29] hey robert_ancell [03:29] http://paste.ubuntu.com/692730/ [03:30] this was noticeably better, actually...there were still moments where input locked for a split second, but overall experience was quite a bit smoother [03:31] jasoncwarner_, yeah, that looks like it. So it's something that gnome-settings-daemon is doing, possibly the xrandr interaction with X? [03:31] this is a *lot* better: [+0.74s] DEBUG: user-list.vala:1248: Rendered first frame [03:32] gnome-settings-daemon *does* have a tendency to probe xrandr multiple times; if it's blocking waiting for that, and VGA probe is taking ~1sec, then that could be our candidate. [03:42] robert_ancell: do we lose anything by not having g-s-d starting up there? or did you make it start threaded or something? [03:43] jasoncwarner_, it's already started in the background (it's another process). we need it for all the power management, X settings etc [03:44] RAOF, the unity-greeter logs just seem to show really slow response times from the X server - could g-s-d be blocking the X server with these requests? [03:52] Good morning [03:52] tremolux: thanks, will sponsor them [03:52] pitti: hey! thanks :) [03:53] cyphermox: I have no idea what DUID is, I was hoping that cjwatson could review this (as he dealt with IPv6 a bit) [03:53] pitti: it's tzdata season ;) [03:55] tremolux: indeed, and we skipped a few, too [03:57] Morning pitti. [04:00] good morning [04:03] morning pitti [04:03] hey TheMuso, hey jasoncwarner_ [04:03] how was the weekend? [04:04] jasoncwarner_: pretty nice, but a bit trying as well - lots of sightseeing, museums, etc. with my in-laws :) [04:09] RAOF: do you plan to update gnome-color-manager from 3.1.2 to 3.1.91? [04:09] jbicha: do you want to update gnome-shell, or shall I look into this? [04:09] * pitti grabs anjuta for now [04:12] RAOF: ah right, I noted on the pad: it needs colord 0.1.12, do we want that in oneiric? [04:15] pitti: gshell needs caribou [04:16] ah [04:16] it doesn't require caribout to actually work, just that it's installed :-) [04:29] pitti: If something needs colord 0.1.12 I can do that; it's pretty bugfixy. [04:29] It's pretty much ready to go for Debian already. [04:33] RAOF: the new g-color-mgr does, yes [04:33] robert_ancell: Oh, hey! Unity-greeter does some fallback detection now? [04:34] RAOF, no? [04:34] robert_ancell: Then why is it (a) authenticating as a DRI2 client, and (b) grabbing the list of GL extensions supported? [04:35] RAOF, oh, it runs the nux tester in the background to save time when logging in [04:36] Ah, ok. [04:39] TheMuso: for bug 836798, would it be possible to somehow make at-spi and at-spi2 coexist? [04:39] Launchpad bug 836798 in at-spi2-atk "natty to oneiric upgrade failed: Could not perform immediate configuration on 'python-pyatspi2'" [High,Confirmed] https://launchpad.net/bugs/836798 [04:39] TheMuso: I guess porting the remaining at-spi apps to 2 is not viable for oneiric, or is it? [04:41] pitti: Not viable no. Most of the at-spi v1 and v2 stacks are co-installable, we just need a way to remove at-spi v1 off eople's systems unless they use apps that are not part of the default install. [04:42] TheMuso: the cleanup can't be enforced with a Breaks:/Conflicts: while we still have rdepends [04:43] but cleaning up doesn't matter so much, update-manager will deal with that once they go to universe [04:43] TheMuso: but I thought the two packages shared a file? [04:43] pitti: Right, I see that now, so we're going to have to remove all breaks/confclits from at-spi2-core and libatk-adaptor, and remove at-spi v1 another way [04:43] pitti: pyatspi is the only package that shares a file. [04:43] TheMuso: right, so we need to solve that one [04:44] And pyatspi's API has not changed. [04:44] so orca for example can use pyatspi for v1 or v2. [04:44] TheMuso: can you work on that today/tomorrow, so that we can get working upgrades to b2? [04:44] oh, nice [04:44] pitti: Yes I can upload fixes today for those. [04:44] But the issue of old at-spi on user's systems still remains. [04:44] TheMuso: see above: once they go to universe, u-m will clean them up [04:45] oh ok [04:45] but as they are (or will be) co-installable anyway, having them on the system sohuldn't break anything? [04:45] So its only at-spi2-atk that needs to be fixed, will do that now. [04:46] TheMuso: do libatk-adaptor and at-spi share any files, like /usr/lib/gtk-[23].0/modules/libatk-bridge.so ? [04:47] but if they are compatible, then I guess libatk-adaptor can just replaces: at-spi, and then the new one will be used [04:47] pitti: Oh yes of course. libatk-adaptor and at-spi share /usr/lib/gtk-2.0/modules/libatk-bridge.so [04:49] TheMuso: that was my question -- if libatk-adaptor takes over that one, will at-spi still work? [04:49] pitti: no [04:50] TheMuso: does the file name need to be exactly that? or could it be called libatk-bridge-2.so? [04:50] pitti: It could be called something else, but then we would need to add extra code to unity to support 2 different modules./ [04:50] And gnome-shell/clutter as well. [04:51] * pitti checks rdepends of at-spi: gok, dasher, python-pyatspi, and python-strongwind [04:52] TheMuso: i. e. mainly gok and dasher; do either of these have GNOME 3 versions or replacements? [04:54] pitti: gok is no longer maintained and is replaced by Caribou, however I don't think thats packaged yet., [04:54] As for dasher, its still maintained, but I am not sure if it has any code upstrea to support at-spi v2 yet. [04:54] it's being packaged, but not yet in oneiric [04:54] ok [04:54] TheMuso: could we change gok and dasher to look for /usr/lib/gtk-2.0/modules/libatk-bridge-atspi.so instead? [04:55] TheMuso: and rename the module in the old at-spi package? [04:55] TheMuso: then the breaks:/replaces can become versioned [04:55] pitti: Its not up to those apps to load the atk module. The atk module is usually dealt with by gtk itself [04:55] either via GTK_MODULES env variable or gnome-settings-daemon taking care of it these days [04:55] TheMuso: oh, I thought you said you needed to change unity/shell etc. to look for a changed name [04:56] pitti: Yes, because unity and gnome-shell do not use GTK for some of their bits, i.e unity uses nux/compiz, and shell uses clutter. [04:56] So they have to load the module manually. [04:56] TheMuso: so if we rename the old module instead, would that be any simpler? [04:57] I don't think so, because we would still need code in shell/unity to support the different module name, because if a user still wants to use gok/dasher, they need to use the entire older stack. [05:00] RAOF, robert_ancell: i've seen symptoms in the past where an xrandr doing an actual probe will cause the entire UI to hang [05:01] primarily on intel systems, though occasionally on other drivers [05:01] TheMuso: hm; so it seems to me we need to push for caribou to get into oneiric, and we need to drop dasher? [05:02] pitti: I don't know about dahser, I believe people still use it... [05:02] as the stacks seem to be fundamentally not co-installable then [05:02] dasher [05:02] Or, we could disable dasher's at-spi support, because afaik its an optional extra. [05:02] right, but unless we can find a way to make them co-installable, there's not much point having rdepends to the old one [05:03] ah, if it's still useful with that, sure [05:04] * TheMuso checks that to be sure [05:05] robert_ancell: http://paste.ubuntu.com/692763 is available for your ponderance, if you wish. It's a unity-greeter with xtrace running with CLOCK_MONOTONIC timestamps. http://paste.ubuntu.com/692764 is the accompanying Xorg.0.log; it looks a lot like the ~500ms stutters in X protocol timestamps correspond to the EDID probing in the Xorg.0.log, but unity-greeter (or anything it spawns) does not seem to be doing a lot of XRandR calls. [05:29] pitti: Ok got a build of dasher here with at-spi disabled. [05:29] So dasher can still be used sans at-spi. [05:30] ping RAOF [05:30] DBO: Pong [05:30] this week [05:30] the nvidia bug [05:30] must die [05:30] do you have *any* theories on how we might accomplish this task? [05:31] Didn't you have an incantation like ?recreate all the FBOs? to make it work? [05:32] Failing anything else, you *could* check for the existence of the NV-GLX extension and just /restart Unity/ when recieving the "resumed" signal! [05:33] That's totally ugly, but better than the alternative. [05:34] And has the advantage of not messing things up for !nvidia. [05:35] TheMuso: nice! so do we have a plan now? drop the breaks: to fix upgrades for b2, and finish the caribou packaging to get a gok replacement? [05:35] jbicha: ^ does that seem realistic? [05:36] good morning [05:36] DBO: Would I be correct in assuming that it'd be a huge pain in the arse to tear down your GL context on resume and rebuild it? :) [05:36] bonjour didrocks, ca va? had a nice weekend? [05:36] RAOF, yes [05:37] I did rejigger the FBO's on resume [05:37] no help [05:37] guten morgen pitti. I'm fine thanks. Was the week-end with all monuments opened to the public, so some nice walk in the city (and too much great Lyon's food ;)). And you? [05:37] DBO: Oh, that's right. That _used_ to work, but now doesn't? [05:37] actually we're not sure what happened [05:37] didrocks, how did you weekend go? [05:39] do people depend on gok instead of onboard? because caribou standalone tries to place the keyboard next to text input [05:39] pitti: SOunds good to me, and I'll upload dasher sans at-spi support. [05:39] DBO: was nice, thanks, how was yours? (you shouldn't be working, still on week-end for you BTW :p) [05:39] which doesn't work for Firefox or full-screen terminals so caribou may be a bit rough [05:40] jbicha: Well we already use onboard as the primary OSK. [05:40] didrocks, I want to know how the compiz testing went for you :) [05:40] So I tink only people who really need it will use it. [05:41] didrocks: heh, similar; we had our parents as guests since Thursday, so we did long city/sightseeing/museum tours [05:41] DBO: I was sure you had done some experimentation on how to make things work :/ [05:41] DBO: I didn't get any weird stacking issue (but I didn't get a lot of issues before). I didn't take latest c-p-m though [05:41] brb, breakfast [05:41] TheMuso: right, I was just wondering if gok was popular or if people were more or less content with onboard [05:42] RAOF, I did [05:42] jbicha: TO be honest, I haven't heard either way, but I know onboard is used. [05:42] RAOF, I was sure recreating them worked last cycle [05:42] it doesn't this time [05:42] Haven't heard anyone using gok recently [05:42] thats all I know [05:42] didrocks, so PPA today? [05:43] DBO: yeah, I saw some new branches proposed for merging though by smspillaz, is there a new tarball needed? [05:43] you should ask him I guess [05:44] pitti: yes, gok has been abandoned upstream so we could drop it & hope that caribou starts working again [05:54] didrocks: DBO no new tarball needed [05:54] that's just other stuff I was hacking around with [05:54] smspillaz, excellent [05:54] didrocks, roll that shit up :) [05:54] smspillaz: I heard about the new c-p-m is needed for a change in the animation plugin, is that true? [05:55] yes [05:55] smspillaz: FYI, we rollbacked the ABI number change you did as it wasn't needed and we don't want free ABI bump at this stage [05:55] didrocks: no problem [05:56] smspillaz: I guess robert carr checked that, but can I have your +1 as well that the window ws switcher change is in the new c-p-m as well? [05:56] smspillaz: (and finally, cherry on the top, can I get the latest rev commit id from where you make dist? I didn't get them and I prefer that than a date for versionning the package) [05:57] didrocks, thank you sir for your efforts today [05:57] goodnight :) [05:57] didrocks: from cpm or core ? [05:57] DBO: yw! have a good night :) [05:57] smspillaz: both :-) [05:58] ok [05:58] smspillaz: Is your unity fix for 847967 in the archive? [05:58] smspillaz: (and +1 on cpm containing the ws switcher change?) [05:59] RAOF: yes [06:00] smspillaz: if so, please change the bug status to fix released for every components [06:00] smspillaz: Why is the bug not set to ?Fix Released? then, and why does it not appear to work? [06:00] RAOF: it doesn't work ? [06:00] that's nice [06:01] RAOF: does the test result in a BadValue ? [06:01] smspillaz: test-input-remover works fine; unity still really hates minimising. [06:01] :/ [06:01] RAOF: is this with the version you've compiled ? [06:01] since it works fine here [06:02] smspillaz: This is with the version of unity that's in the archive. [06:02] *shrug* ok, maybe it isn't in the archive [06:02] Which is why I first asked "is the fix for unity in the archive" :) [06:02] didrocks: when was unity last updated ? [06:02] smspillaz: as usually, Thursday evening [06:02] Because there's not much point fixing the X server for beta2 if unity isn't fixed. [06:02] RAOF: can you try compiling unity from source and see if you still get the problem ? [06:02] smspillaz: can I get the revisions please and the confirmation I'm asking? [06:03] didrocks: yes yes, just give me a minute [06:03] (if the bug status was changed when the fix has been in, we would know for sure if it's in the archive or not…) [06:04] :) [06:04] right, it's more a matter of, I can't remember when I actually merged in the fix for that [06:04] RAOF: can you compile from source and check? I need to know whether it's broken or not in the archive [06:05] smspillaz: hence why I remind everyone for the past 10 month to set the bug as "fix committed" once merging it [06:05] if it's broken, well then painful times ahead for me [06:05] smspillaz: Yup. Building now. [06:05] thanks [06:06] didrocks: I need to resync the cpm branch, once that's done I'll get you the revids [06:06] smspillaz: ok thanks, and please check that the tarball have the ws switcher change [06:07] didrocks: did they not have it last time ? [06:07] smspillaz: not sure what is "last time", just a question if the latest tarball you rolled on Thursday evening contains the ws switcher changed we distro-patch in ubuntu [06:08] didrocks: yes, it contains it [06:08] RAOF: smspillaz: easier than recompiling unity, looking at the trunk: http://paste.ubuntu.com/692796/ [06:09] this is since last release [06:09] smspillaz: thanks for the info! [06:09] seems the smspillaz's branch is indeed released [06:09] great [06:09] RAOF: which windows does it not work with ? [06:10] smspillaz: gedit [06:10] ok [06:10] I'll recompile my x server and see what's happening then [06:11] since it got clobbered by the last dist-upgrade I did [06:11] Or, rather more specifically, *maximised* windows. [06:11] TheMuso: sorry, rejecting at-spi2-atk; the Replaces: is still necessary, otherwise dpkg will break on the file conflict [06:11] TheMuso: can you please reupload? [06:11] pitti: whoops of course, thanks. [06:12] smspillaz: Hm, there also sometimes seems to be some visual corruption left behind; fragments of the minimize animation. [06:13] smspillaz, RAOF: is the unity task in bug 847967 still relevant? [06:13] Launchpad bug 847967 in unity "A minimized window 'remains' behind on the desktop if /apps/compiz-1/plugins/unityshell/screen0/options/show_minimized_windows is set to true" [High,In progress] https://launchpad.net/bugs/847967 [06:13] or is it exclusively an X.org workaround? [06:13] pitti: This is exactly what we're talking about now :) [06:13] ah, sorry [06:13] There's a mandatory xorg workaround, but Unity also needs a fix. [06:13] I wonder if we should get this into b2 and accept now [06:13] i. e. more testing vs. regression potential [06:13] Yeah. [06:13] RAOF: it really seems like this branch wasn't merged :/ [06:14] the change looks like a workaround, and it's not obvious to me that it wouldn't break other software? [06:14] RAOF: are you compiling from source ? [06:14] pitti: no, it wont [06:14] It's a pretty simple patch, been reviewed upstream, and shouldn't result in changing client-visible protocol. [06:14] smspillaz: Yup, I've just built from source. [06:15] i. e. it essentially disables the 8th bit of the event type; this is kind of a protocol change? [06:15] That bit is set by XSendEvent. [06:16] Well, I it *does* change the client-visible protocol. I guess some software *might* rely on the fact that using XSendEvent for some event types will cause an XError, but I can't imagine why :) [06:16] So it's a protocol change in that requests which should succeed and previously generated an XError now succeed. [06:16] RAOF: great, it broke again, gosh this thing is fragile [06:17] That's just what we want to hear at beta-2! [06:17] who said that minimized window thumbnailing was easy [06:18] Ah. Would I be correct in assuming that having minimised windows when starting unity is still a bad idea? [06:18] ok, so it s broken for me because dpkg epic failed at configuring my server :/ [06:18] * smspillaz grabs the source again and recompiles [06:19] Or, rather, would I be correct in assuming that you are fully cognisant of the fact that starting unity while there are minimised windows results in those windows being entirely inaccessible? [06:19] RAOF: that should work fine [06:20]