[05:07] <didrocks> good morning
[05:09] <Julian__> hello~
[05:48] <FloatingGoat> hi I love unity
[06:59] <thumper> FloatingGoat: cool, I like it too :)
[06:59] <thumper> hi didrocks
[06:59] <didrocks> hey thumper!
[07:14] <MacSlow> hey there everybody
[07:25] <didrocks> good morning MacSlow
[07:28] <MacSlow> salut didrocks
[08:03] <om26er> could someone point me to how to install unity somewhere local (from source)
[08:20] <JohanSJA> om26er: what distro you are on?
[08:20] <om26er> JohanSJA, Oneiric
[08:23] <JohanSJA> om26er: I am not sure about that, haven't tried that yet. But I guess Unity is installed by default. Or I maybe wrong?
[08:24] <om26er> JohanSJA, i want to test a bug fix from a patch, it is ofcourse installed
[08:25] <JohanSJA> om26er: then I couldn't help you on that. I am sure others can.
[08:25] <JohanSJA> :)
[08:26] <om26er> i applied the patch to source, did cmake now i dont want to 'sudo make install' as that would kind of make my install a little broken for further updates, won't it?
[08:58] <njpatel_> didrocks, bschaefer has put up a patch (branch) for xapian at https://bugs.launchpad.net/unity-2d/+bug/745243 which adds support to xapian for CJK!
[08:59] <didrocks> njpatel_: really! that's awesome :-)
[08:59] <njpatel_> didrocks, any chance we could get it into a ppa or ubuntu so we can test with unity-2d /cc Kaleo agateau
[08:59] <didrocks> njpatel_: sure, pushing that in the ubuntu-desktop ppa
[08:59] <njpatel_> didrocks, indeed, bschaefer has been working on it over the past month or so
[08:59] <njpatel_> didrocks, sweet!
[09:00] <didrocks> njpatel_: I can imagine, so xapian for application name searches, isn't it?
[09:00] <njpatel_> didrocks, yeah ,files/apps/software-centre stuff, it effects all our stuff
[09:00] <Kaleo> njpatel_: I'm up for the meeting :)
[09:00] <Kaleo> didrocks: CJK!!!!! YAY!
[09:01] <didrocks> njpatel_: files? how come? there is no zg patch?
[09:01] <njpatel_> Kaleo, could be reschedule for say tomorrow morning so we can go over the code I hope to push today?
[09:01] <bschaefer> njpatel: It was only for Xapian as of now. I havent looked at zg yet
[09:01] <njpatel_> Kaleo, also iv'e got food poisoning and am not feeling great atm :(
[09:02] <Kaleo> njpatel_: I will be in Millbank tomorrow
[09:03] <Kaleo> njpatel_: maybe you can come over? :)
[09:03] <Kaleo> njpatel_: if you are recovered..
[09:03] <Kaleo> njpatel_: I hope you get better soon
[09:04] <njpatel_> Kaleo, oh, good idea, I can try if I feel better ,definitely!
[09:04] <njpatel_> Kaleo, how long are you in millbank for?
[09:04] <njpatel_> well, in London
[09:05] <Kaleo> njpatel_: I will be there tomorrow and Thursday
[09:05] <njpatel_> Kaleo, okay, good to know
[09:05] <njpatel_> i can't do thurs so hopefully tomorrow
[09:05]  * njpatel_ hopes the pills start working soon
[09:05] <Kaleo> njpatel_: fingers crossed
[09:05] <didrocks> bschaefer: if you screw up my xapian database, I know where you live! :)
[09:06] <bschaefer> didrocks: That is far for you, but I tested it on a fresh Xapian branch so that should give you some comfort.
[09:07] <didrocks> bschaefer: never underestimate my anger :-)
[09:07] <njpatel_> hah
[09:07] <bschaefer> didrock: that's good advice haha
[09:07] <didrocks> see, njpatel_ knows about it ^ :-)
[09:08] <njpatel_> I do I do. Me bribes didrocks with more drinks at next UDS
[09:08] <njpatel_> er, /me*
[09:21] <om26er> didrocks, latest compiz update problem, starting compiz make xorg use 100cpu :/
[09:21] <didrocks> om26er: just at startup? I'm starting it here and have no issue
[09:22] <om26er> didrocks, yes session does not start at all, in unity-2d sessions starting compiz makes system unusable. switched to vt and top says xorg 102% cpu usage
[09:22] <om26er> *tty ;)
[09:23] <didrocks> om26er: hum… I imagine, you didn't make any partial upgrade?
[09:23] <didrocks> om26er: can I have the traces of the startup from the tty?
[09:23] <om26er> didrocks, dist-upgrade, it removed unity though
[09:24] <didrocks> om26er: seems you didn't wait for the new unity then, but that doesn't explain the 100% CPU :)
[09:26] <om26er> didrocks, i installed unity myself from debs (-0ubuntu5)
[09:26] <om26er> but the problem it seems is compiz
[09:27] <didrocks> om26er: you don't have any output from tty1?
[09:28] <om26er> didrocks, nothing bad I think, last line is starting unity-window-decorator
[09:28] <njpatel_> om26er, other things can make compiz use 100% CPU, any other programs hung or anything? for me banshee keeps doing that
[09:28] <didrocks> om26er: so, everything starting without any error, it "just" then try to draw something and hang at 100% of CPU
[09:32] <om26er> changed to gtk-window-decorator in ccsm as well, no change.
[09:33] <didrocks> hum… what can happen… smspillaz, any idea? ^
[09:33] <didrocks> om26er: here, I relaunch compiz numerous time, reboot and no issue :/
[09:35] <hicham> morning
[09:35] <didrocks> bschaefer: I get a undefined reerence with your patch
[09:35] <didrocks> hey hicham
[09:35] <hicham> hi didrocks
[09:36] <didrocks> bschaefer: I guess it's a missing LDADD
[09:37] <hicham> didrocks: when gsettings backend for compizconfig is planned ?
[09:37] <didrocks> bschaefer: if you want to have a look: http://paste.ubuntu.com/647139/
[09:38] <didrocks> hicham: there is something experimental ready, but should come in 2 weeks normally
[09:39] <hicham> didrocks: can you point me to it ?
[09:39] <didrocks> hicham: no need to package it right now, it's clearly not tested enough, should be somewhere in launchpad
[09:40] <didrocks> hicham: looking for "compiz gsettings" in launchpad just gave me the link: https://launchpad.net/compiz-compizconfig-gsettings/0.9.5
[09:40] <hicham> didrocks: i hope that it will be better than gconf :)
[09:40] <didrocks> still the issue on upgrade, but no insane copy anymore
[09:42] <bschaefer> didrocks: hmm that's weird,
[09:42] <bschaefer> didrocks: did you run the ./bootstrap in the main folder?
[09:43] <didrocks> bschaefer: no, I just took our current package, add your patch and build
[09:43] <didrocks> bschaefer: oh nevermind, surely my fault :)
[09:43] <didrocks> didn't run autoreconf
[09:44] <bschaefer> didrocks: ok, cause I was kinda worried since I hadn't seen that error before haha
[09:47] <om26er_> Kaleo, Hi! why is the unity-2d launcher tile background white?
[09:48] <didrocks> om26er_: heh, now you are forced to debug unity-2d? :)
[09:48] <didrocks> I would love someone else confirming the 100% CPU, really can't get it there
[09:49] <om26er_> didrocks, nah just something didnt look nice ;)
[09:49] <om26er_> didrocks, i am going to try it on my netbook and see if the issue happens there as well
[09:49] <hicham> I don't have 100 % CPU :)
[09:49] <didrocks> om26er_: oh, that would be nice! :)
[09:50] <Kaleo> om26er_: this is a bug in packaging that was fixed a few days back
[09:50] <didrocks> hicham: do you have the latest compiz? I don't think so ;-)
[09:50] <hicham> didrocks: I have 0.9.5.0
[09:50] <didrocks> hicham: oh ok! :-)
[09:50] <Kaleo> om26er_: https://bugs.launchpad.net/bugs/809205
[09:51] <didrocks> right, the pkgbinarymangler convert
[09:51] <om26er_> Kaleo, so i have to build to get the fix or is there a simpler workaround ?
[09:51] <didrocks> om26er_: you have to rebuild it, the images are corrupted
[09:52] <om26er_> aww :/
[09:52] <didrocks> om26er_: or wait for next release (next week)
[09:53] <Kaleo> om26er_: use the daily ppa
[09:53] <Kaleo> om26er_: https://launchpad.net/~unity-2d-team/+archive/unity-2d-daily
[09:53] <om26er_> Kaleo, thank you :-)
[09:53] <Kaleo> om26er_: you are welcome :)
[09:53] <Kaleo> om26er_: thanks for the bug reporting
[09:53] <Kaleo> !
[09:54] <om26er_> that ;-)
[09:55] <om26er_> didrocks, why is there no active unity daily ppa?
[10:00] <didrocks> om26er_: because nobody has the time to maintain them
[12:21] <meborc> Hi all. Anyone active at the moment?
[12:22] <meborc> As I was told, the current implementation of multiple monitors and top-bar and indicators is the "intended" way
[12:22] <meborc> meaning that I have top-bar and indicator area on both screens
[12:22] <meborc> this is a major showstopper for me
[12:23] <meborc> I use Ubuntu in an office environment and having bars on both screens hinders my productivity
[12:23] <meborc> I understand that a desicion has been made, BUT maybe there is a way to make an option in some obscure configuration file to allow disabling of the bar on the secondary screen
[12:24] <jjardon> mpt: Hello, Id like to suggest a change in the design of Power preferences in the GNOME control center: https://wiki.ubuntu.com/Power. I filled a bug to discuss this and the people seems to agree: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/812394 Could you take a look?
[12:24] <meborc> any ideas on the current situation with multiple monitors???
[12:24] <meborc> anyone?
[12:29] <mpt> JohnLea, hi, if you're around, can you remind me where that Suspend/Hibernate decision is documented?
[12:35] <mpt> jjardon, it wasn't my idea, so I'm the wrong person
[12:35] <mpt> ... to reconsider it
[12:36] <mpt> jjardon, especially since I haven't read any description of the evidence considered
[12:39] <jbicha> since we're talking about power, apparently the specification is for the power menu to always show instead of only when charging
[12:39] <jbicha> as in previous releases?
[13:10] <jjardon> tedg: just released a new indicator-power tarball with some fixes: https://launchpad.net/indicator-power/trunk/0.4
[13:13] <jjardon> kenvandine: if you have some free time ^ ;)
[13:13] <kenvandine> jjardon, will do!
[13:25] <jjardon> tedg: ping
[13:26] <tedg> jjardon, Hey, cool.
[13:26] <tedg> jjardon, I was thinking we should change the apport hook to pull the upower infor that pitti suggested.
[13:26] <tedg> info
[13:27] <jjardon> tedg: upower --dump ?
[13:27] <tedg> jjardon, Yes
[13:28] <jjardon> tedg: sure,  Should I fille a bug against apport?
[13:28] <tedg> jjardon, No, it's something each package can do.
[13:29] <tedg> jjardon, Each package can install a small Python script that gets executed when there are bugs in that package.
[13:29] <seb128> don't bother with packaging, get somebody from distro to do it
[13:29] <seb128> it's not worth for you to spend an hour to read about that, it's trivial for a packager to do
[13:29] <tedg> seb128, Yes, but we're talking about inserting an apport hook here.
[13:30] <seb128> well, seems it seems better to have a packager do it than to have jjardon spend an hour reading about packaging
[13:30] <tedg> seb128, I'm just about to convince k-e-n-v-a-n-d-i-n-e to do it, but be quiet, we're sneaking up on him.
[13:30] <seb128> ;-)
[13:31] <tedg> kenvandine, Would you mind adding a quick apport hook to indicator-power when you upload it to grab "upower --dump" on bugs please?
[13:32] <mpt> jjardon, I followed up on the bug report
[13:32] <seb128> tedg, should bug #812728 be assigned to ronoc?
[13:32] <seb128> tedg, the title needs to be updated, it basically the "the menu is not working" bug
[13:33] <tedg> seb128, Yeah, he's looking into it, but we can assign it.
[13:33] <tedg> seb128, I'll do it.
[13:33] <seb128> thanks
[13:33] <seb128> btw the indicator work in unity greeter and has a menu
[13:34] <seb128> so it's something in the unity session or with compiz...
[13:34] <tedg> seb128, Yeah, it works in the loader too.  He was going to start chasing down unity-panel-service.
[13:34] <mpt> jbicha, yes. https://wiki.ubuntu.com/Power#Power_settings
[13:35] <seb128> ok
[13:35] <kenvandine> tedg, will do
[13:35] <tedg> kenvandine, Thanks!
[13:35] <jjardon> mpt: thanks
[13:35] <mpt> jbicha, I didn't know the default was different in previous Ubuntu versions.
[13:35] <seb128> tedg, other bug noticed: the session indicator stopped turning red on restart required
[13:35] <tedg> seb128, Yeah, we're just reshuffling...  that'll get back.
[13:35] <seb128> ok
[13:36] <jbicha> mpt: the Gnome default is to always show when a battery is present, but Ubuntu has overridden that since apparently 2006
[13:36] <jbicha> to hide when the battery is fully charged
[13:36] <mpt> heh
[13:37] <mpt> jbicha, so you could say we've seen the error of our ways? :-)
[13:38] <jbicha> mpt: it's been this way so long, seeing a battery indicator when I'm fully charged worries me as I think I must have come unplugged
[13:39] <seb128> it's also a bit annoying when you use a docked laptop as a desktop config
[13:40] <seb128> but that's maybe because we don't have a "running on ac" icon
[14:10] <jo-erlend> I wonder if the battery indicator could have some sort of warning when you've been plugged into a power source for a long time, since that damages most batteries. Many users aren't aware of that, I think.
[14:12] <jo-erlend> just a thought.
[14:13] <jjardon> seb128: we have, a running on ac icon should be shown if you are in ac
[14:16] <seb128> jjardon, so it's buggy for me
[14:16] <seb128> jjardon, but I run 0.3, I will try again with 0.4 and let you know
[14:17] <seb128> jjardon, upower --dump says "on-battery: no" "is-docked: yes"
[14:19] <jjardon> seb128: yeah, Its a known bug in 0.3
[14:20] <jjardon> should be fixed in 0.4
[14:20] <seb128> ok
[14:21] <jjardon> mpt, tedg: upstream made insensitive any sleep actions the hardware cannot do: http://git.gnome.org/browse/gnome-control-center/commit/?id=4f08a32570490f837e7c6909b095d2b44f4c05ee
[14:23] <tedg> jjardon, That's a gain, but we also want the user to be able to set that value somehow.  As upower only gets that from the kernel, and the kernel doesn't always know.
[14:23] <tedg> jjardon, I wonder, with root, if we could actually set that.
[14:25] <jjardon> tedg: sorry, I do not understand, set what?
[14:30] <jjardon> tedg: libgnome-control-center doesnt exist anymore
[14:31] <jjardon> tedg: seems that datetime depend on it
[14:32] <tedg> jjardon, Yeah, I'm not sure what distro is doing there.  seb128?
[14:32] <seb128> what?
[14:32] <tedg> Are you back porting libgnome-control-center?
[14:33] <tedg> Can we just stay on a sane version that has the lib?
[14:34] <seb128> tedg, jjardon: the lib is not dropped, they dropped only the files to build with it right?
[14:34] <seb128> ie .pc and includes
[14:34] <seb128> we will distro patch those back in since that's what bastien suggested to do on d-d-l for distribution
[14:35] <jjardon> seb128: yeah
[14:35] <tedg> seb128, Okay, sounds good.
[14:35] <seb128> we need those for at least deja-dup and indicator-datetime
[14:35] <tedg> And I guess in the future we'll just have to build our own control center if we want to it be modular :-(
[14:35] <seb128> tedg, why?
[14:35] <jjardon> THis is  the commit: http://git.gnome.org/browse/gnome-control-center/commit/?id=606b6fd88d52268b4e7720e18035fe947df030cb
[14:36] <seb128> jjardon, we will revert that in Ubuntu yes
[14:36] <tedg> seb128, Because I'm guessing they'll continue to make it harder to be modular.
[14:36] <tedg> seb128, It's kinda their stated goal.
[14:37] <seb128> tedg, let's see when we get there, I think we can get away with reverting that commit for this cycle
[14:38] <tedg> seb128, Sure, for this cycle.  I was thinking further out.
[14:38] <seb128> well, let's see
[14:39] <jjardon> I'd say complain now in ddl if you think you should do it
[14:40] <tedg> jjardon, Because me complaining on DDL has worked in the past? ;-)
[14:41] <seb128> jjardon, there was an endless discussion about that already a month ago
[14:42] <smspillaz> ohai racarr
[14:42] <seb128> jjardon, in follow up of the backup feature email
[14:44] <mpt> jjardon, good. So it would be extremely useful to have data on how many false positives and false negatives that code has.
[14:48] <mpt> jjardon, is that something that never existed before, or is it something that the old gnome-power-manager did and got lost in the porting to g-c-c?
[14:48] <tedg> mpt, I think if you talk to OEM they'd say that it's not very accurate at all.
[14:49] <jjardon> mpt: they are using the new upower api: http://upower.freedesktop.org/docs/UPower-up-client.html#up-client-get-can-suspend
[14:49] <tedg> mpt, Though they're targeting "suspends 100 times" not "suspends once" which is what most enthusiasts calculate based on.
[14:50] <tedg> jjardon, That API has been there a while, we use it in the session menu currently.  If you disable your swap, suspend gets removed from the menu.
[14:50] <tedg> Sorry, hibernate.
[15:19] <jjardon> mpt:  you can never suspend if CanSuspend comes back FALSE
[15:20] <jjardon> but CanSuspend doesn't verify it works, so the kernel could stilll suck
[15:24] <jjardon> tedg: Could be posible to use the upstream datetime panel?
[15:27] <tedg> jjardon, I don't believe it had all the features we needed.
[15:28] <tedg> jjardon, But it was much further away in 2.32 than 3.0
[15:28] <tedg> jjardon, mterry did that work, so probably best to talk to him about his thoughts there.
[15:29] <mterry> jjardon, what's the question about the upstream datetime panel?
[15:29] <Trevinho> tedg: https://bugs.launchpad.net/libindicator/+bug/812933 ;)
[15:32] <jjardon> mterry: I wonder if we can use the upstream one.
[15:32] <tedg> Trevinho, I think there was some concern expressed by mpt on providing middle click to app indicators.
[15:32] <tedg> Trevinho, In that it was non-obvious and worried that app authors would hide important features there.
[15:34] <mterry> jjardon, it's difficult.  so there are a couple things we share in common (the map data itself, setting time and ntp use), but everything else (all the clock controls, our geonames lookup code, and the layout of controls itself) is different and non-upstreamable (I've asked about geonames, they weren't interested).  So we could have a giant patch to them or just keep our separate one
[15:35] <mterry> jjardon, so far it seems easier to just keep our separate one.  The map data is supposed to be split out into a separate library by GNOME at some point, so we can share that again
[15:35] <mterry> The other shared points (time/ntp) are just dbus calls to gnome-settings-daemon, so not worth bending over backwards to share
[15:36] <Trevinho> tedg: I know... However the main work has been done for indicator-sound, that is accepted for this
[15:37] <Trevinho> tedg: unfortunately as I've written there, we can't easily control the app authors via the APIs....
[15:37] <Trevinho> however for indicator-sound (and other "private" indicators) this should be fine
[15:39] <Trevinho> and for libappindicator based indicators... I don't think that we can't limit too much the authors... If something is badly designed by them ubuntu isn't affected directly.
[15:40] <Trevinho> However everything excluding indicator-application and libappindicator should be fine according what mpt wrote in bug #609860
[15:43] <tedg> Trevinho, Yeah, so I'd have to say I'm generally thumbs down about the app-indicator stuff.  I agree with mpt there.  I think it'll be too easy to abuse.
[15:43] <tedg> Trevinho, But let's try to land the others.  I'll try to review them today or tomorrow.
[15:45] <Trevinho> ok, thank you
[15:47] <Trevinho> tedg: about the indicator-messages, I thought about hide the notifications... However while it's easy (and I've done that) to disable the "active icon", we easly can't just hide the notificaitons menu items until libindicator doesn't allow to mark a new menu-item as "notification" or such
[15:47] <Trevinho> I thought about doing something like that, but I'd prefer not do do unwanted code :P
[15:48] <Trevinho> until it's approved...
[15:51] <tedg> Trevinho, Yeah, so we've talked about making that a menu item as well.  So that's definitely desired.  The key is that each app needs to have a toggle so that when it has a new alert that gets picked up.
[15:52] <tedg> Trevinho, So as long as it has a middle click *and* the menu item, I think it's reasonable.
[15:53] <tedg> Trevinho, I wonder if we could do that same thing with the appindicator API.  Provide a way to specify which menu item gets activated on middle click.  If you hide it, middle click gets disabled :-)
[15:53] <Trevinho> I thought to that too
[15:53] <Trevinho> tedg: but if you use complex menu items I don't know if you can do that too
[15:54] <tedg> Trevinho, We'd just send the "activate" signal, and they could do what they want with it.
[15:54] <Trevinho> for example, using ido menu items... If a sub-sub-sub item activates something that the middle click would run...
[15:54] <jjardon> mterry: I didnt mean to upstream code from Ubuntu panel, but use the upstream one instead. Is that possible?
[15:54] <tedg> Trevinho, I think it'd be the app author's job to figure out what happens in that case.  We'd send "activate" on that item.
[15:55] <Trevinho> That was my idea too, reading the concerns about this thing
[15:55] <mterry> jjardon, I understood.  I was explaining why we have such a large delta.  And we could either distro-patch that delta in or keep a separate panel.  Separate panel is less work in both short term and long term, so that's the plan of record
[15:55] <Trevinho> but I didn't try to implement that as I was not sure how it would have worked
[15:55] <Trevinho> I'll give a try to that so.
[15:56] <Trevinho> While about the indicator-messaging, do you agree with me that if an app flags a menu item with a "notification" mark, then that can be hidden when we do the "hide notification" thing (via menuitem or middle click)?
[15:57] <Trevinho> Or do you prefer another implementation...?
[15:58] <tedg> Trevinho, Yeah, so it needs to mark all the ones at that instant as seen.  Just so if a new one comes in (or that one gets updated) the alert is shown again.
[16:01] <Trevinho> tedg: yes, but the ones hidden shouldn't be shown again...
[16:01] <tedg> Trevinho, Unless they're updated.
[16:01] <Trevinho> of course
[16:01] <tedg> Trevinho, They should still be in the menu though.
[16:01] <Trevinho> Ok, I'll give a look to both things...
[16:01] <tedg> Trevinho, Just not lighting the top icon.
[16:01] <tedg> Trevinho, Cool, thanks!
[16:04] <Trevinho> tedg: oh... Wait... Maybe I've misunderstood what you meant... I would have marked (by the calling app) a menu item as "notification", so that indicator-messages was able to hide what was just a notification... Do you say instead that the indicator-messages should only inform the caller that it should hide his notifications and that the indicator will only change his icon (+ a11y text)?
[16:05] <jjardon> mterry: Are there bug reports / mailing list threads about trying to upstream some of the Ubuntu panel?
[16:07] <tedg> Trevinho, I think that the only user visible effect should be the panel icon changing.  Internally it's more complex.
[16:08] <mterry> jjardon, yeah, in gnomecc-list, the "Map Library" thread (active in Feb, April, May) http://mail.gnome.org/archives/gnomecc-list/
[16:08] <jjardon> mterry: thanks
[16:10] <Trevinho> tedg: that is easy to do and is already in my branch (https://code.launchpad.net/~3v1n0/indicator-messages/clear-notifications-on-secondary-activate), but that is not enough to me...
[16:10] <Trevinho> tedg: if an application has flagged one of its own menu items as "notification", then it's easy for us to hide them
[16:11] <Trevinho> maybe notifying the app too, but that is not directly needed
[16:11] <Trevinho> tedg: of course we need the application support, but that is something that can arrive,...
[16:11] <tedg> Trevinho, Then you end up in the situation where you can't undo.  For instance if there's a notification of a chat, how would you get to that chat window?  The items aren't bothering anyone, I think leaving them in the menu is fine.
[16:12] <Trevinho> (and default applications such as gwibber and empathy can easily adapt)
[16:12] <Trevinho> mhmh, I thought that that was up to the application
[16:13] <Trevinho> however if just hiding the active icon is enough, than it's already done
[16:13] <tedg> Trevinho, I think so.  Ah, cool.
[16:13] <tedg> Trevinho, I guess I need to make a menu item to do that as well.
[16:14] <Trevinho> Yes I'll do that
[16:14] <tedg> Trevinho, Cool
[16:14] <Trevinho> But i didn't introduce too many things as I thought that it was too simple :P
[16:19] <calberto> dbarth: hey!
[16:30] <Trevinho> tedg: do you want the menu-item to be in the indicator side or in the server side?
[16:36] <tedg> Trevinho, I think it'd have to be on the service side, otherwise you have to merge menus, ewww :-)
[16:41] <jono> didrocks, not sure if know, but Unity is not starting in Oneiric
[16:41] <jono> unity-panel-service is not found
[16:41] <didrocks> jono: did you make a full upgrade? do you have the latest unity with latest compiz,
[16:41] <didrocks> ?
[16:41] <jono> and some other files in /home/jono/.compiz are not found
[16:41] <jono> didrocks, I just did a dist-upgrade
[16:41] <andyrock> jorge around?
[16:41] <andyrock> jcastro, ^^^
[16:42] <tedg> jono, We've decided to cater more to advanced users.  You have to write it yourself on login.  Show you're 1337 enough.
[16:42] <jcastro> andyrock: hi!
[16:42] <didrocks> jono: can you try to run "unity" and post the output there?
[16:42] <jono> tedg, lol
[16:42] <jono> didrocks, I ran unity --reset -v and took a photo
[16:42] <andyrock> jcastro, this bug has been already solved in trunk https://bugs.launchpad.net/unity/+bug/750375
[16:43] <jono> didrocks, it said unity-panel-service: no process found
[16:43] <didrocks> jono: this one isn't important, what else?
[16:43] <jono> didrocks, and the following could not stat():
[16:43] <andyrock> jcastro, should we marks it as fixex-commit
[16:43] <andyrock> *fix-committed
[16:43] <jcastro> andyrock: ok, set!
[16:43] <andyrock> mark
[16:43] <jcastro> oh, I thought you were asking me to set it fix committed
[16:43] <didrocks> jono: seems you have some packages uninstalled, did you look at the package it wanted to remove?
[16:43] <jono>  /home/jono/.compiz-1/plugins/libcore.so
[16:43] <jono>  /home/jono/.compiz-1/plugins/libccp.so
[16:44] <jono>  /usr/lib/compiz/libcore.so
[16:44] <jono> thats it
[16:44] <didrocks> jono: hum, no unity should be enough to avoiding the noise of home one :)
[16:44] <didrocks> jono: ls -l /usr/lib/compiz/libcore.so ?
[16:44] <jono> didrocks, it didnt say anything was held back or removed
[16:44] <jono> jono@forge:~$ ls -l /usr/lib/compiz/libcore.so
[16:44] <jono> ls: cannot access /usr/lib/compiz/libcore.so: No such file or directory
[16:44] <didrocks> jono: weird, people here updated without any issue since this morning
[16:44] <andyrock> jcastro, i'm asking you if set it as fix-committed is good :)
[16:45] <didrocks> jono: can you go to tty1, unity 2>&1 > ~/log
[16:45] <didrocks> then, go to tty7
[16:45] <jcastro> andyrock: yes, setting it fixed committed is good
[16:45] <didrocks> once it's really stalled
[16:45] <didrocks> tty1, ctrl + C and pastebin the output?
[16:45] <jcastro> andyrock: though in bzr you can do bzr commit --fixes 123456 and it'll do all that for you
[16:46] <andyrock> jcastro, cool :) but i think jay solved it with his last commit
[16:46]  * jcastro nods
[16:47] <Trevinho> tedg: well, adding it in the indicator-side works well by the way... :P
[16:47] <Trevinho> tedg: And... I'd add it as the latest item...
[16:47] <Trevinho> (after a separator)
[16:49] <andyrock> jcastro, maybe remove it from unity-community-hackers? so the list of bug assigned to uch is cleaner
[16:50] <jcastro> andyrock: well, if I do it that way we can't keep track of which ones the team has fixed.
[16:50] <Trevinho> tedg: directly in the get_menu function I meant... However if you want a cleaner implementation I'll put it in the server...
[16:51] <jcastro> oh dumb, LP keeps committed bugs on the +assignedbugs list
[16:51] <jcastro> andyrock: oh, when they do a release and close it out it'll get removed
[16:51] <andyrock> jcastro, ok ok
[16:55] <jono> didrocks, http://pastebin.ubuntu.com/647453/
[16:55] <jono> sorry for the delay, my system got pretty wedged
[16:56] <didrocks> jono: hum, is it the end?
[16:56] <jono> didrocks, thats everything in the log file
[16:58] <API> didrocks, btw, I have tested last compiz, and it is working
[16:58] <API> I mean that NO_GAIL and NO_AT_BRIDGE stuff
[16:58] <API> thanks
[16:58] <API> although something weird, I suppose that it is general, if I open the dash, I can't close it pressing Esc
[16:59] <didrocks> API: nice! :-)
[16:59] <didrocks> jono is not so lucky
[16:59] <didrocks> API: hum, the dash was working well here, I'll have a look
[16:59] <jono> didrocks, any idea how I fix this?
[17:00] <didrocks> jono: I would love first to know what happens, it should show all plugin loading which you don't have apparently
[17:00] <didrocks> jono: apt-cache policy compiz-plugins-default
[17:00] <didrocks> jono: apt-cache policy unity
[17:00] <didrocks> jono: apt-cache policy compiz
[17:00] <didrocks> jono: apt-cache policy libcompizconfig0
[17:00] <didrocks> (just to ensure everything is installed)
[17:01] <didrocks> and the cherry on the top: apt-cache policy compizconfig-backend-gconf
[17:01] <didrocks> jono: you should have installed 0.9.5.0-0ubuntu1 for everything and 4.2.0-0ubuntu5 for unity
[17:02] <API> didrocks, btw, I think that the branch related to this bug  https://bugs.launchpad.net/unity/+bug/810033 was also integrated on last release
[17:02] <API> should I close is as Fix released?
[17:02] <didrocks> API: there was no unity release yet (Thursday is next), just ensure it's set to next milestone
[17:02] <jono> unity: 4.2.0-0ubuntu5
[17:03] <jono> compiz: 1:0.9.5.0-0ubuntu1
[17:03] <API> didrocks, ok thanks
[17:03] <jono> libcompizconfig0: 0.9.5.0-0ubuntu1
[17:03] <API> didrocks, but I can't edit the milestone on that bug
[17:03] <jono> compizconfig-backend-gconf: 0.9.5.0-0ubuntu1
[17:04] <jono> didrocks, looks like I am up to date
[17:04] <jono> didrocks, when you asked me to run the log command, Unity did reset correctly, but Unity 2d was running
[17:05] <didrocks> jono: indeed, can we have a look tomorrow? desrt will certainly kill me if he can't eat Lyon's food :-) at least you have unity-2d right now
[17:05] <jono> didrocks, of course :-)
[17:05] <jono> thanks, pal!
[17:05] <didrocks> jono: just ping me tomorrow morning, I'll do that first thing
[17:05] <jono> thanks didrocks!
[17:05] <jono> sorry for keeping you, I didn't realize
[17:05] <didrocks> (didn't hear about other case in 10 hours, so I'm quite confident ;))
[17:05] <didrocks> jono: no worry! :-)
[17:34] <andyrock> with unity in trunk launcher doesn't works well... mabye focus problem!
[17:35] <andyrock> know problem?
[17:49] <kenvandine> seb128, today't indicator-power release has a build depends on gnome-settings-daemon-dev 3.1.4
[17:49] <kenvandine> do you know when that is coming? i thought end of the month..
[17:49] <seb128> kenvandine, in 2 weeks
[17:50] <seb128> but we can try to talk to rodrigo about getting a snapshot or a tarball before that if needed
[17:50] <kenvandine> might be nice to be able to test that
[17:50] <seb128> would the new requirement be easy to distro patch out for now?
[17:51] <kenvandine> perhaps
[17:52] <kenvandine> i can look to see if the g-p-m code is still in there
[17:52] <kenvandine> it would be nice to test it with the new interface though
[17:52] <seb128> well g-s-d or g-p-m should be similar, it might just be a dbus service renaming?
[17:52] <seb128> right
[17:52] <seb128> well I guess you will not get g-s-d updated today
[17:52] <seb128> but maybe tomorrow
[17:52] <seb128> so if you want to push the new indicator today you could revert
[17:52] <kenvandine> no rush...
[17:53] <seb128> otherwise I will talk to rodrigo_ about it tomorrow
[17:53] <kenvandine> just noticed it depended on a yet to be released dep :)
[23:54] <RAOF> DBO: So, would you like a formal bug for ‘compiz alt-tab is unacceptably slow under CPU load’? :)
[23:55] <DBO> sure