=== mclasen_ is now known as mclasen_afk === bjf is now known as bjf[afk] === zyga is now known as zyga-gone [01:28] RAOF, hey, around at all? === mclasen_afk is now known as mclasen [01:28] rickspencer3: Yup. What's up? [01:29] well, someone asked me to join a call tomorrow morning ... [01:29] and it just occurred to me that they are probably concerned about ... [01:29] how will Ubuntu work in VMs in a Wayland world? [01:30] And they'd be asking a very good question. [01:30] RAOF, does wayland mean that VM vendors will have to simulate 3d hardware so the kernel thinks it do DRI? [01:30] * rickspencer3 exposes obvious gross ignorance [01:30] No. Wayland is not dependent on dri per-se. [01:31] hmmp [01:31] It *is* dependent on some interprocess buffer communication. That can be done with shared memory (and, indeed, I think there are working patches using shared memory). [01:32] The question would really be: does the Unity-Wayland compositor support a running without GL. [01:33] Because Wayland isn't a display manager in the same way that X is a display manager. [01:33] RAOF, GL being the API? [01:33] Yeah. [01:33] wayland definitely depends on EGL, which in turn is implemented by mesa, which itself talks to kernel GPU apis [01:33] http://www.spinics.net/lists/linux-virtualization/msg11819.html is a useful post [01:33] * rickspencer3 looks [01:33] walters: Not if you're using the shared memory patches. [01:33] apparently mesa pure software rendering is getting better too [01:34] walters: There's a shared-memory compositor that doesn't require anything fancy. [01:34] in any case, VM vendors will have to have some implementation of the GL API that works? [01:34] No. [01:35] Not if Unity-Wayland has a shared-memory non-GL compositor codepath. [01:35] i don't know what you mean by shared memory here [01:35] rickspencer3: In the X world, the display server, window manager, panel, and compositor can all be separate processes. In the Wayland world, “Wayland” is a library that the combined compositor/panel/window-manager/compositor process links to to provide a display server. [01:36] wayland definitely hard depends on EGL in git as is today [01:36] anyways i have to go, nite all [01:36] walters: Yes, it does. However, there are patches to remove those, and pass blobs of /dev/shm around as buffers rather than EGL images. [01:36] RAOF, right, but I thought the rub was that Wayland uses the 3d capabilities built into kernels now [01:37] and without 3d hardware, those capabilities would be missing [01:37] (this is why I presumed DRI was involved) [01:37] rickspencer3: At the moment, in trunk, it does. There's no hard requirement for that to be the case, though. [01:38] right, so you are saying that it's possible that Wayland could have what amounts to a 2d implementation if 3d capabilities are not available in the kernel [01:38] Right. [01:38] Indeed, patches to that effect exist. [01:38] but would it not also be possible for VM vendor to let the VM actually use the existing 3d hardware? [01:39] But it's a bit misleading to say “Wayland could have a 2d implementation…”. Because what's *really* important is the compositor, which is something that other people develop. [01:39] (The current compositor in wayland git is just a demo) [01:39] you mean the wayland compisitor could use an API that is not a 3d API? [01:39] *A* wayland compositor could indeed use an API that's not a 3D API. [01:40] * rickspencer3 drums fingers [01:40] There will be multiple Wayland compositors; a Unity compositor, a GNOME compositor, a KDE compositor… each of these will implement the Wayland protocol. [01:40] (Presumably by linking with libwayland) [01:40] right right right [01:40] but does not libwayland use 3d graphics directly? [01:40] I thought that was kind of the point [01:40] No. [01:41] It's designed around passing references to some “buffer” thing. [01:41] The kernel drm provides a nice 32bit integer handle for buffers, so it's a natural fit, but it doesn't *have* to be a drm buffer. [01:43] libwayland itself doesn't do any drawing; that's the job of the compositor. So libwayland doesn't necessarily need to know what a buffer is, just how to pass references to them around. [01:43] RAOF, but it's the compositor that is written to talk to DRM, not wayland itself? [01:44] I see, so Wayland is more like an arbiter of graphics buffers that works at the behest of a compisitor? [01:44] Right. [01:45] so a GUI toolkit, for example, knows how to talk to Wayland, which in turn knows how to ask the active compistor to draw? [01:45] Right. If you're using the current demo compositor, what's happening is that a “buffer” is currently an EGL image, which is essentially a small wrapper around a DRM buffer. It hands these out to clients, and the compositor uses GL (or GLES, I forget if that's been done yet) to composit these EGL buffers. [01:46] The GUI toolkit knows how to talk to Wayland. From Wayland it gets a buffer. The GUI toolkit knows how to draw to these buffers, and then tell Wayland “hey, I've updated this buffer, kindly display it”. [01:46] One of the principles of Wayland is that clients are in charge of their drawing. Wayland has no drawing APIs. [01:46] and then Wayland says, "he compositor, update the image" [01:47] and the compisitor maybe or may not use 3d hardware, depending on how it was written? [01:47] Right. [01:47] Now, I'm not *entirely* sure how this will work in a world where your compositor may use 3D or not depending on hardware support. [01:48] so for Unity-Wayland, support for non 3d capable hardware is tbd [01:48] Because that will change what “buffer” means, and that means clients will need to know. [01:48] well, I would assume it would be a totally different compositor [01:49] Right. But the *client* needs to know how to draw to a buffer. And if the different compositor provides *different* buffers… [01:49] the client being a gui toolkit for example? [01:49] How does the client (a) tell between the different types of buffers, and (b) know how to draw the right way? [01:49] Yeah. [01:50] The client will be something using GTK, Qt, Cairo, GL, etc... [01:50] but that would imply a toolkit needs to be ported per compositor implementation [01:50] wouldn [01:50] t the client *be* GTK, Qt, etc...? [01:50] Indeed it would. Which is why I'm not sure what's happening here. [01:51] so, there would need to be a limited number of compositors, or at least buffer types that compositors use [01:51] because I don't see toolkits being too useful if their very core rendering code needs to be massively specialized per compositor [01:51] It's also possible that I've misunderstood some of this, and this problem doesn't in fact arise. [01:52] well, it's ok, I'm a dope and it's out of scope [01:52] :) [01:52] I think my takeaway message will be "we don't know, but this is still all far off, so don't worry too much" [01:52] I don't think it's entirely accurate to call GTK the client - the applications are the clients, they just use GTK or Qt or whatever to make their lives easier. [01:52] That's an excellent take away message :) [01:53] surely GTK is the client [01:53] I write an application with GTK, GTK will handle drawing [01:53] but I guess GTK isn't a running process [01:53] So, I'd say that in my current session I have a bunch of X clients - compiz, smuxi, evolution, firefox. [01:54] right, I see what you're saying [01:54] You can also use multiple toolkits in a single app - See any clutter app, for example; that's using GTK and GL(ES). [01:54] so each application is using GTK as a library to handle writing to the buffers that Wayland gives it [01:55] but, conceptually, it's GTK, not your app, that knows how to use X, or in the future Wayland [01:55] Right. Almost all applications don't actually care about drawing per-se. They care about having a button marked ‘Awesome’ which causes your mail to combusst. [01:56] And those which do want to do something more than just drawing pre-formed GTK widgets get a Cairo context from GTK and draw to that using Cairo ☺ [01:56] well, that's *after* they use a goocanvas [01:57] Not necessarily - GTK will give you a cairo context for whatever you like. That's how Do gets drawn. [01:58] You can also do funky stuff with otherwise standard GTK widgets that way. [01:59] RAOF, yeah, but goo canvas is sick easy [01:59] * RAOF hasn't touched goo canvas at all. [02:00] well, it lets you stuff VML into it, essentially [02:00] Ah. Higher level fun! [02:00] that's what I'm saying, if you don't have a standard widget that does what you want, you party with goo canvas [02:01] then when that stops doing what you need, you get a cairo context from *that* [02:01] Aaaaaaaah. Yes, makes sense. [02:01] RAOF, thanks for your time [02:01] I appreciate you educating me more about Wayland [02:02] No problem. It's interesting stuff. [02:02] I'm still skeptical that toolkits will have to be rewritten per wayland compositor [02:02] but that's probably just a sign of how much more I don't understand about it [02:03] later dude, have a good day [02:03] You too! [03:41] RAOF: All the client really needs to know is what format the compositor expects data in the buffer to be (RGBA, BGRA, etc) [03:41] RAOF: Actually I imagine those would be the only two formats [03:42] Amaranth: But it's not passing the contents of the buffer; it's passing a reference to the buffer. You're going to need to do different things to render to a drm buffer than you are to some piece of /dev/shm [03:43] If it were passing the contents of the buffer, certianly. I don't think that's what it does, though. [03:43] RAOF: Does the client actually have to use its own code for that though? I thought there was a wayland API [03:44] * RAOF goes and has a look. [03:44] If not that's the obvious answer [03:45] All the client needs is an API to say "render this buffer" or "render this data" [03:46] So if the client uses GL and tells it to render a buffer the compositor can take a shortcut but if the client says render this data the compositor loads it in to a texture first [03:46] And etc if the compositor is using software rendering [03:47] hmm, actually... [03:47] So, currently the demo clients use clients/window.c as their utility code, and it #ifdefs between GL and shm surfaces. [03:48] Forget all that, but the only thing wayland is going to give a client is an EGL handle or a chunk of /dev/shm so they just need a way to tell the difference [03:48] A way to query the server [03:49] Although how do you run a GL app when you have an shm-based server? [03:50] You'd need and EGL extension, I think. [03:51] No matter what you're going to be reading data from VRAM every frame [03:51] So that's going to suck [03:51] I suppose you could just say "you can't do that" [03:52] But writing a 2D compiz/unity in wayland world is going to be a pain [03:53] I guess if you're compositor has fallen back to shm buffers it probably means that GL just won't work, so you don't need to care ☺ [03:53] Until you get a guy who thinks shm is faster/cleaner/uses less memory or something [03:57] And, well, they get to use software rendering for everything. [04:37] Amaranth: If you're interested, wayland *clients* currently have two options when attaching a buffer to a window: they can attach a named drm buffer (having previously created & named it via the magic of libdrm), or they can attach a shm buffer and feed the data over an fd. === almaisan-away is now known as al-maisan [08:27] hey [08:27] Hi seb128 , hows it goin' ? [08:31] hey cdbs, I'm fine thank you [08:31] cdbs, how are you? [08:31] fine, but busy in boring non-ubuntu work :( [08:32] robert_ancell, hey [08:37] seb128, kenvandine , the cause for the appindicator missing custom icon was that there was no indicator applet on the panel [08:37] ... [08:37] so you had the fallback to the notification area? [08:37] joaopinto, sorry for not thinking about that [08:38] no, it must be the appindicator code doing it, I have no code for the notification area, somehow it places the icon/menu on the panel [08:38] with a proper icon for theme base icons, and missing for custom [08:39] right, as said you use the fallback [08:39] the appindicator library does that [08:39] ah, ok :) [08:39] if they is no indicator support it fallbacks to a notification icon [08:39] there is probably a bug in the fallback case [08:39] that's not something we test much since all ubuntu install have indicator support [08:39] but feel free to open a bug on indicator-application [08:40] ok I will [08:40] thanks [08:40] libappindicator1 ? [08:41] a bug against indicator-application ? [08:42] joaopinto, https://edge.launchpad.net/indicator-application/+filebug [09:14] seb128, do you have any idea why the following code behaves different when executed from a appindicator menu vs the tray context menu: http://pastebin.ubuntu.com/544346/ [09:14] when launched from the indicator the dialog does not respond to the close window action [09:15] joaopinto, hum, no [09:18] :( let's see if adding a closing signal handler helps [09:31] uff, gtk.main_quit() does not quit either [09:32] does it works as standalone code? [09:35] yes, I am migrating from tray to appindicator [09:36] I am still showing the notification area in parallel, and the function call works as expected [09:36] try asking on #ayatana [09:36] The delete_event is received in both cases, but with the indicator the dialog is not destroyed [09:36] it's the upstream channel for what dx does [09:36] they probably know better than the desktop team [09:57] mvo, good morning [09:58] mvo, when I suggested that "Show Residual Settings" command for things you've removed but not purged, is that actually technically possible? Or is there no way to tell what settings are left behind after you've removed a package? [09:59] mpt, it's possible I guess [10:00] since you can dpkg -L those [10:00] so the info is on disk [10:01] seb128, not after removing the package... [10:01] dpkg -L takes a package name argument [10:01] What I'm looking for is, "Show the list of packages that I removed in the past but didn't purge" [10:02] "... and that left files behind as a result" [10:02] mpt, dpkg -l | grep ^rc [10:02] then dpkg -L [10:02] on one of those [10:02] joaopinto, if the package is still configured which is what mpt is asking for it works [10:04] right, the info is still available from /var/lib/dpkg/info/package.list [10:04] ah [10:04] I don't have one of those [10:04] mpt: what seb128 said, its possible to get this data, dpkg keeps them in the db [10:05] excellent [10:05] thanks seb128 [10:05] you're welcome [10:09] morning [10:10] mvo, oh, cool, I love what happens in trunk when I search for "abbieword" [10:11] mpt: yeah, me too, I think its a really cool feature [10:13] mvo, maybe the spelling suggestions should show if there's a close match even when there are matches for what you did type. E.g. if I type "movida" it's very likely that I want Moovida, not deskbar-applet or dwm. [10:14] mpt: yeah, glatzor suggested that yesterday too, I will add it [10:17] In that case, we need to work out consistent presentation for three possibilities: (a) there are matches but no spelling suggestion; (b) there's a spelling suggestion but no matches (so therefore there are other suggestions); (c) there's both a spelling suggestion and matches. [10:19] mpt: indeed, the next thing is there will be suggestions that are not useful. movida->moovida is a good one, but we will probably have "apt" -> "app" and similar cases, especially for short words [10:19] mpt: we could simply lmit the suggestions (if there are hits) for 3 letter words as they will most likley result in overlay broad ones [10:20] mpt: maybe even for 4 letters, that probably requires a bit of tweaking. the algorithm will look for a maximum of matches, but that is not always what we want [10:21] mvo, maybe show a suggestion if (number of results for the suggestion) >= N * (number of results for the current string) [10:22] Hm, that wouldn't fix the apt->app case though probably [10:22] that would be valid for apt -> app too [10:22] I don't see why deskbar-applet or dwm are showing up as results for "movida" in the first place [10:24] Their data doesn't contain that string [10:32] mpt: odd, I just tried that and it does not show them for me [10:32] it suggests moovida [10:32] And it has a "Hide 2 technical items" link that does nothing except flash the window [10:33] search term was "movida" [10:33] ? [10:36] mvo, http://people.canonical.com/~mpt/movida.ogv [10:38] mpt: maverick or natty? [10:38] Maverick [10:39] * mvo scratches head [10:49] Riddell, there? [10:50] hi seb128 [10:50] Riddell, hey, do you think you can review and bin NEW gobject-introspection for me? [10:50] the binary need to be promoted directly [10:50] let me look [10:52] Riddell, thanks [10:54] accepted! [10:56] Riddell, thanks [11:36] robert_ancell: around? [11:37] ari-tczew, not likely, he stopped his work day for 5 hours or so [11:37] ok [11:37] what do you need? just ask on the channel in case? [11:37] seb128: sponsorship [11:38] subscribe ubuntu-sponsors? [11:38] if that's for ubuntu [11:38] or is that for a ppa upload? [11:38] or ping the patch pilot [11:38] seb128: I'd like to be sponsored specially by robert_ancell [11:39] is there any reason? [11:39] but anyway your call, that will have to wait tomorrow then [11:39] drop him an email or subscribe him to the bug [11:40] seb128: I subscribed yesterday [11:40] seb128: I'm collecting a sponsored uploads to get endorsements in future [11:41] and I choiced robert_ancell. I've talked with him about it, don't worry [11:41] ok [11:41] well you don't need uploads only by a specific sponsor [11:42] seb128: how another way do you want build an endorsement? [11:42] you can just keep track of things that got sponsored and ask different endorsements [11:42] well most people get endorsement of at least 3 sponsors [11:42] seb128: I have 2. [11:42] not sure you win by limiting those [11:42] it just show that you don't want to work with the community but just specific people [11:42] seb128: for MOTU app I collected 9 endorsements :P [11:43] which is a bit weird [11:43] seb128: hmm, it's not like you got it [11:43] if I have a problem, I'm talking with community [11:45] ari-tczew, ok, alright [11:45] I was just pointing that having different sponsors usually doesn't hurt [11:46] seb128: and I have different sponsors ;) [11:46] I guess it's more about not spreading the sponsored uploads across to many sponsors, as some sponsors won't have an opinion about endorsments with too few sponsored uploads [11:46] maybe do you want me to do some merges and sponsor it? [11:47] geser: +1. that's what I wanted to tell seb128 [11:48] ari-tczew, no that's fine, if robert_ancell is taking care of your uploads that works for me ;-) [11:48] I'm not asking for extra work ;-) [11:59] Riddell, there is another rounds of gir binaries in NEW if you feel like reviewing those as well [12:10] seb128: ok [12:42] Riddell, thanks [12:49] seb128: accepted [12:50] Riddell, thank you! [12:50] bug 691069 should be fixed I think [12:50] Launchpad bug 691069 in gstreamer0.10 (Ubuntu) "copyright-without-copyright-notice (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/691069 [12:50] seb128: how come these gir files aren't just put into the -dev packages? [12:50] Riddell, they are runtime [12:52] Riddell, the .gir which are used at build are in the libdev binaries [12:52] Riddell, the gir1... content is what is used at runtime from python or js [12:53] so it could go in the library, but debian decided to not do that because the gir abi is breaking at different times from the soname [12:53] it wouldn't work well for transitions [12:53] like now only the gir format changes, the lib abi didn't [12:54] right, makes sense === njpatel is now known as njpatel_ [14:12] mterry - i've not uploaded the ffox 4 compatible version of ubufox yet ;) [14:12] (i just saw your bug report) [14:13] it's still waiting on review by asac ;) [14:13] GNOME Menu's are broken :( [14:13] chrisccoulson, I figured it was something simple like that. But I didn't see any other bug reports, so thought maybe I was unique [14:13] Unity + GNOME3 PPA [14:14] mterry, there is another bug report too, but reported for a different problem caused by the lack of ubufox [14:16] bcurtiswx, maybe bug 690717? [14:16] Launchpad bug 690717 in unity (Ubuntu) "clicking for menus makes the unity bar/menu bar dissappear (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/690717 [14:16] weird that people start getting that [14:16] neither compiz or unity changed [14:17] htorque, do you get it all the time? [14:17] or does restarting compiz fix it? [14:17] seb128, yes [14:17] it happens with all menus, even right clicking on the desktop doesn't show a menu, although it is there.. if i click in the area where it _should_ be then I get something to show up or happen [14:17] seb128, wait [14:17] htorque, does it happen in a GNOME session? [14:17] bcurtiswx, does it happen with any application? [14:18] seb128, compiz start seems to fix it [14:18] *restart [14:18] k, same thing njpatel_ was discussing earlier [14:18] i'll try a restart [14:18] it's weird still because compiz didn't change recently [14:18] I'm wondering if that could be the gtk update from yesterday [14:19] is that limited to gtk softwares? [14:19] or is firefox or qt doing the same? [14:19] seb128, yes messing with compiz does "fix" it.. it shows menu's but now any window will appear on top of them [14:20] seb128, menu's do not show in firefox because the menu's are hidden behind it [14:20] ok, so it's not gtk specific [14:20] still would be nice to test something in qt [14:20] just to be sure [14:22] seb128, so based on recent gtk3 theming discoveries, it wouldn't a good idea to make the new gwibber client gtk3 only, right? [14:22] kenvandine, not before we sort the gtk3 question at the sprint [14:22] ok [14:22] thought so [14:22] i rewrote gwibber-preferences last night :) [14:22] oh, cool, this is being discussed :-) I had to go back to classical desktop [14:23] kenvandine, in gtk3? [14:23] hggdh, you as well? [14:23] no, but vala [14:23] but had considered using some stuff that was gtk3 only [14:23] but i'll avoid that [14:23] seb128: aye (no mouse button working on menus/dropdowns) [14:24] seb128, not seeing it in a GNOME session (w/o compiz) [14:24] also using gsettings now, instead of gconf [14:25] htorque, and with compiz? [14:25] htorque, hggdh: what did you guys upgrade when that started? [14:27] seb128: not sure, this was (I think two days ago -- I had done some upgrades during the last two days, and only yesterday evening I reloaded [14:27] seb128: will look at the dpkg history [14:28] hggdh, what was 2 days ago? [14:28] htorque, when did that start for you? [14:28] seb128: two days ago I started updating without reloading (busy). Yesterday, after the last updates I rebooted, and found it) [14:28] seb128, not exactly sure, i guess it start yesterday morning-ish (i'm gmt -1) [14:29] *started [14:29] htorque, before 3pm your time? [14:29] htorque, can you check if you updated gtk before or after it started? [14:30] htorque, i'll have a look [14:31] seb128: which pieces of gtk are you looking for? [14:32] hggdh, libgtk2.0-0 === zyga is now known as zyga-food [14:33] seb128, compiz (w/o running the unity plugin obviously) and classic session seem fine [14:33] seb128: when I updated it (yeasterday @20:50 CST) I already had the issue [14:33] seb128: could you look on bug 552718. it wasn't fixed upstream [14:33] Launchpad bug 552718 in webkit (Ubuntu) (and 1 other project) "typo in enable XSS auditor (affects: 1) (heat: 13)" [Low,Fix committed] https://launchpad.net/bugs/552718 [14:34] htorque, yeah, i updated gtk yesterday, i'm just not sure when i saw this the first time [14:34] classical desktop with compiz is fine [14:34] kenvandine: what do you know about the new python-couchdb package? [14:34] I'm merging webkit right now and I'm going this patch [14:34] (include) [14:34] seb128, metacity shows menu's fine [14:34] seb128, ^^ (oops) [14:34] dobey, not much, i haven't touched it in quite a while [14:34] dobey, but i have been expecting an update to sponsor [14:34] hggdh, htorque: do you guys use some ppa or non official source? [14:34] from chad [14:34] kenvandine: ok [14:35] ari-tczew, it has been commited upstream see the url on the bug [14:35] ari-tczew, you are welcome to include the patch in the update you do [14:35] seb128: then I don't know how it could be committed upstream, 1.2.5 doesn't have this change [14:36] seb128, only banshee daily, chromium daily, darktable unstable [14:36] it's likely not in the 1.2 serie but in trunk [14:36] htorque, ok [14:36] seb128, http://paste.ubuntu.com/544449/ if that helps at all [14:36] htorque, do you get the issue every time using unity? [14:36] bcurtiswx, ^ same for you [14:37] seb128, yes, every session start. and once i get the context menu on the desktop, it's fixed for the rest of the session [14:37] if that's the case can you try to downgrade gtk to the version from last week? [14:37] seb128, yes sir [14:37] just to rule that out [14:37] seb128, which packages would that be? [14:37] https://launchpad.net/ubuntu/+source/gtk+2.0/2.23.2-0ubuntu2 [14:37] seb128, on it :) [14:37] basically libgtk2.0-0 [14:37] you can probably just downgrade it [14:38] dpkg might not like it but it will not crash, just force it, restart your session and upgrade again to make dpkg happy [14:38] dpkg will probably want you to downgrade some of the others binaries [14:38] but that's not required [14:38] htorque, thanks === njpatel_ is now known as njpatel [14:39] kenvandine, how busy are you? [14:39] depends on what you need? [14:39] seb128: the only ppas I have do not impact here (ubuntu fonts, and another internal one) [14:40] :-D [14:40] kenvandine, can you handle the dx stack gir1.0 to gir1.2 renames [14:40] sure [14:40] kenvandine, don't bother testing locally or waiting for the current build [14:40] kenvandine, just rename gir1.0 to gir1.2 in the control and rules [14:40] the .install [14:40] ok, so package renames [14:40] then add a Conflicts: gir1.0... [14:40] kenvandine, I'm uploading the bottom stack, just did gdk-pixbuf, gtk next [14:41] ok, is there one you have done already? [14:41] ok [14:41] kenvandine, I'm doing the GNOME stack [14:41] just do dx [14:41] dbusmenu, libindicate, json-glib [14:41] json-glib isn't dx :) [14:41] well I just added it [14:41] i can do it [14:41] be nice or I add another one :p [14:41] appindicator too [14:41] thanks ;-) [14:41] will do [14:41] I'm trying to get that through today [14:42] tomorrow is unity update day [14:42] seb128, btw after the compiz --replace the menu's show fine and stay above all other windows [14:43] seb128, downgrading libgtk alone didn't help, will try the rest [14:46] im gonna reboot and test the workaround of compiz --replace after a fresh reboot.. brb [14:48] Yes, workaround confirmed. No menu's on reboot, with a compiz --replace the menu's work as expected. [14:49] bcurtiswx, ok thanks [14:50] seb128, the downgrade didn't change a thing :-/ [14:50] ok, thanks [14:50] that rules out gtk [14:50] which is what I wanted to check [14:51] is there a command in terminal to search previous natty only versions of compiz ? [14:51] * joaopinto would like to have a working Unity for Christmas [14:52] seb128, will downgrade compiz to glibmainloop3-0ubuntu1 (i upgraded to -0ubuntu3 yesterday morning) [14:53]