[00:02] <desrt> bumpy beta!
[00:04] <robert_ancell> desrt, problems?
[00:05] <desrt> my unity experience is not a happy one :)
[00:13]  * desrt wants a beta gnome-shell to match his beta unity
[00:13] <desrt> keep things more interesting :)
[00:15] <robert_ancell> desrt, what happened with that?  Did we end up getting close enough to deliver gnome-shell 3.4?
[00:15] <desrt> robert_ancell: i think it will happen if ricotz or jbicha steps up :)
[00:16] <robert_ancell> I'm not sure how much further they can step up.  They're already stepped up to the max
[00:16] <robert_ancell> Go the upstepping!
[00:17] <jbicha> robert_ancell: seb128 doesn't think it's a great idea but bug 941617 looks more like a yes than a no at the moment
[00:17] <ubot2`> Launchpad bug 941617 in clutter-1.0 "FFe: Update clutter/cogl to 1.9" [Wishlist,In progress] https://launchpad.net/bugs/941617
[00:17] <desrt> oh.  that.
[00:17]  * desrt forgot about 'that.'
[00:17] <robert_ancell> damn
[00:17] <jbicha> haha
[00:19]  * desrt suffers rage issues
[00:19] <jbicha> well if you guys want to weigh in on the bug....
[00:21]  * desrt unrages
[00:21] <desrt> so.  i was getting really really annoyed because fedora was partitioning my disk very stupidly
[00:22] <desrt> now i discover that it's actually just GPT
[00:22] <desrt> fascinating.
[00:22] <robert_ancell> micahg, hey, I see you're dropping quadrapassel from xubuntu - any feedback on it?
[00:22] <micahg> robert_ancell: done for beta 1 :)
[00:23] <robert_ancell> micahg, dropped because size / dependencies / problems / reducing default apps ?
[00:24] <robert_ancell>  / better replacement
[00:24] <micahg> robert_ancell: we were the only image carrying clutter, I figured if Ubuntu didn't want to support it for LTS why should Xubuntu :)
[00:24] <micahg> so, we dropped quadrapassel and were done with it
[00:24] <robert_ancell> jbicha, seb128 is always ruining our fun :)
[00:24] <robert_ancell> ok
[00:26] <jbicha> robert_ancell: :)
[00:26]  * desrt injects some love into the bug
[02:22] <kenvandine> robert_ancell, we'll get clutter for 12.10 :)
[02:22] <kenvandine> we can't hold out any longer, seb128 won't ruin the fun anymore :-D
[03:40] <robert_ancell> RAOF, can I get you to type 'who' from a gnome-terminal and see if it gives any output?
[03:40] <RAOF> You can, and it says “chris    pts/2        2012-03-01 08:39 (:0)”
[03:40] <desrt> desrt@moonpix:~$ who
[03:40] <desrt> desrt@moonpix:~$
[03:40] <desrt> :(
[03:40] <RAOF> In case it matters, this is from a byobu-tmux session.
[03:41] <RAOF> desrt: You are nobody.  NOBODY!
[03:41] <RAOF> :)
[03:41] <robert_ancell> RAOF, how brave are you feeling, want to try a new lightdm?
[03:42] <RAOF> Eh, sure.
[03:42] <RAOF> What's the rub?
[03:42] <robert_ancell> it seems to work for me now, but I'm not sure what's changed
[03:42] <robert_ancell> well, I do know I made a big change to the way PAM works, but I have no idea if that should have fixed things
[03:43] <RAOF> HAH!
[03:43] <RAOF> That is tremendously reassuring ;)
[03:45] <robert_ancell> it's the magic of PAM :)
[03:46] <RAOF> So, where's the magic button?
[03:46] <robert_ancell> RAOF, I'm just updating the branch
[03:50] <robert_ancell> RAOF, ok, can you bzr-buildpackage lp:~ubuntu-desktop/lightdm/ubuntu and install the .debs
[03:51] <RAOF> Hey, that's cool.  I didn't know bzr-buildpackage did that!
[03:55] <robert_ancell> that was accidental if you are actually literally running 'bzr-buildpackage lp:~ubuntu-desktop/lightdm/ubuntu'.  'Cause I'm running it now and also had no idea that would work
[03:57] <robert_ancell> hmm, whatever it's doing it seems slower that bzr branch lp:~ubuntu-desktop/lightdm/ubuntu lightdm-ubuntu; cd lightdm-ubuntu; bzr-buildpackge
[04:05] <RAOF> ...and I should actually install the build-deps.
[04:07] <robert_ancell> RAOF, oh yeah, that too
[04:13] <robert_ancell> RAOF, computer on fire yet?
[04:14] <RAOF> JUst finished building.
[04:22] <RAOF> robert_ancell: Nothing seems to have caught fire.
[04:23] <RAOF> robert_ancell: Anything I should particularly check?
[04:23] <robert_ancell> RAOF, I like the sound of that.  the who/w thing in particular
[04:23] <robert_ancell> (I take it you restarted lightdm?)
[04:25] <RAOF> I logged out and logged in again.
[04:25] <RAOF> That's enough to restart lightdm, or do I need to ask upstart to kindly kill it?
[04:27] <robert_ancell> RAOF, you do need to upstart it or you'll be running the older version
[04:28] <RAOF> Yeah, nothing caught fire.
[04:32] <robert_ancell> RAOF, and who says...
[04:35] <RAOF>   chris    pts/2        2012-03-01 15:35 (:0)
[04:35] <RAOF> (And also “chris    tty1         2012-03-01 15:15”, but that's my VT login)
[04:38] <desrt> RAOF: fancy quotes!
[04:38] <RAOF> To differentiate between console quotes and actual quotes!
[04:39] <robert_ancell> RAOF, ok, so it seems to be fixed for you too.  magic
[04:40] <RAOF> Do not extrapolate from an X maintainer's hardware.  It's magic ☺
[04:49] <pitti> Good morning
[05:14]  * BigWhale opens one eye.
[05:14] <BigWhale> Arrr.
[05:15] <TheMuso> Morning pitti.
[05:15] <pitti> hey TheMuso, how are you?
[05:19] <TheMuso> pitti: Not too bad thanks, yourself?
[05:19] <pitti> quite fine, thanks
[06:01] <pitti> tkamppeter_: the debian and ubuntu buildds and a local cups build all reproduce the "[cups-deviced] PID 13706 (usb) crashed on signal 11!"
[06:01] <pitti> tkamppeter_: I wonder what's different on your system so that you don't get it..
[06:33] <didrocks> good morning
[06:45] <pitti> bonjour didrocks
[06:46] <didrocks> guten morgen pitti!
[06:48] <pitti> if anyone could help testing this morning's new desktops/alternates, that woudl be highly appreciated; we are running a bit tight on time here
[06:51]  * didrocks tries to deal with the unity stuff (release blocked on important bugs right now) and then will try to be on that
[07:06] <bschaefer> :w
[07:06] <bschaefer> opps
[07:07] <glatzor> morning pitti
[07:17] <pitti> hey glatzor, wie geths?
[07:44] <glatzor> pitti, pretty fine! and yourself?
[07:44] <pitti> glatzor: gut, danke! looking forward to getting b1 behind  us :)
[07:47] <SpamapS> What exactly is compiz using 20% of my CPU for?
[07:47] <SpamapS> clint     2625 20.2  4.0 1817004 163176 ?      Rl   Feb28 419:44 compiz
[07:47] <SpamapS> I'd think displaying 2 maximized terminals wouldn't really use any of compiz's time
[07:50] <pitti> I have between 5 and 8 % CPU here
[07:51] <SpamapS> Mine has been > 10 all day...
[07:51] <SpamapS> at this point my laptop's fan is always on
[07:52] <SpamapS> weird, closing chrome, which was not visible.. dropped it considerably
[07:52] <SpamapS> I guess its because compiz shows screenshots in the super-W "thingy"... ?
[07:53] <didrocks> hey, minimized application are not minimized, but restacked behind
[07:55] <pitti> I have kvm running on another (non-visible) desktop, I guess that's it
[07:55] <SpamapS> Yeah, closing everything except the terminals has *almost* let the fan go off.
[08:02] <glatzor> pitti, just a short question: could you imagine any problems running a dbus daemon, e.g. aptdaemon, with a higher nice level? I think about calling os.nice(5) in aptdaemon to avoid slowing down old systems. or even using psutil.Process.set_ionice(psutil.IOPRIO_CLASS_IDLE)
[08:03] <glatzor> morning mvo!
[08:04] <pitti> glatzor: I'm sure that'll help quite a bit; the only drawback that comes to my mind is that UIs might see increased response times, so perhaps some timeouts need to be adjusted
[08:04] <pitti> glatzor: but it should generally be fine
[08:04] <mvo> hey glatzor, good morning!
[08:06] <glatzor> pitti, is it already to late in the cycle for an MIR of python-psutil?
[08:06] <mvo> glatzor: I ran into a odd issue the other day with pkcompat installed and runing "bzr get lp:update-manager; cd update-manager/DistUpgrade/;sudo ./dist-upgrade.py" I got locking errors from what appears to be aptdaemons pkcompat that emited some changed signals and locked the cache while doing that - does that sound plausible?
[08:06] <pitti> glatzor: sounds small and harmless
[08:06] <pitti> hey mvo
[08:06] <mvo> hey pi
[08:06] <mvo> hey pitti
[08:12] <glatzor> mvo, I will have a look.
[08:12] <mvo> a!
[08:12] <mvo> ta!
[08:16] <tkamppeter_> pitti, hi
[08:18] <tkamppeter> pitti, it looks like that the usb backend segfaulted on you during device detection. It can depend on the printers you have connected andd their IDs. I have several HP printers connected and no USB->Parallel adapters. What do you have connected?
[08:21] <tkamppeter> pitti, in bug 938640, comment #9 a user has a problem with a USB->Parallel adapter making the usb backend of Precise's CUPS crashing with a "Memory fault". What is this? What is the difference to a segfault?
[08:21] <ubot2`> Launchpad bug 938640 in cups "canon bj-200 has stopped printing" [Undecided,Incomplete] https://launchpad.net/bugs/938640
[08:23] <pitti> tkamppeter: I don't know, it doesn't sound like a standard strerror() message?
[08:26] <tkamppeter> pitti, the usb backend executable and the CUPS libraries do not contain the string "Memory Fault". It must come from the system.
[08:36] <didrocks> pitti: on http://iso.qa.ubuntu.com/qatracker/milestones/208/builds/12793/testcases/443/results
[08:36] <didrocks> pitti: I get a blank ubiquity startup screen
[08:37] <didrocks> (language choice, but nothing else)
[08:37] <didrocks> wasn't the case for you?
[08:37] <pitti> hm, could be that it was, but I assumed with the language choice that'd be normal?
[08:38] <didrocks> pitti: not even if I select "english"
[08:38] <pitti> but I do remember reading "you can read the release notes"
[08:38] <didrocks> pitti: and I had the translation in normal install
[08:38] <didrocks> hum, reproduced twice here
[08:38] <pitti> and reading that note in German, too
[08:38] <didrocks> ok, I'll open a bug
[08:38] <pitti> thanks
[08:38] <pitti> didrocks: jibel is also testing images now, FYI, so please have a look at the ISO tracker
[08:39] <didrocks> pitti: well, I have to switch back to unity soon, but trying to give some hand as much as I can :)
[08:41] <jibel> didrocks, do you mean the 1rst screen with the choice try or install ubuntu ?
[08:41] <jibel> didrocks, bonjour
[08:41] <didrocks> jibel: yeah, this one
[08:41] <didrocks> jibel: salut
[08:42] <didrocks> jibel: if you select the language on first screen (before casper is run)
[08:42] <pitti> didrocks: oh, _that_ one, gfxboot
[08:42] <pitti> didrocks: I tried it for OEM, but in English there
[08:42] <didrocks> yeah, the gfxboot
[08:42] <jibel> didrocks, ok, trying now
[08:43] <pitti> didrocks: I get gfxboot translations on both i386 and amd64
[08:43] <didrocks> bug #943844
[08:43] <ubot2`> Launchpad bug 943844 in ubiquity "No welcoming message if language != english" [Undecided,New] https://launchpad.net/bugs/943844
[08:43] <jibel> didrocks, did you select french on that screen ?
[08:43] <didrocks> pitti: I mean, select deutch there
[08:43] <pitti> so do you mean gfxboot or ubiquity?
[08:43] <didrocks> pitti: and "install"
[08:43] <didrocks> let ubiquity loading
[08:43] <didrocks> and you will see no "try or install" in ubiquity
[08:43] <pitti> didrocks: no, that's not a bug
[08:43] <didrocks> jibel: yeah, I selected French here
[08:44] <didrocks> ah?
[08:44] <pitti> didrocks: as on the gfxboot screen you already choose between live and install
[08:44] <didrocks> it's weird, no link for release info?
[08:44] <pitti> well, that should be there
[08:44] <didrocks> nothing on the right side
[08:44] <pitti> but on the initial ubiquity dialog where it asks for the language
[08:44] <pitti> but you should't get the install/live chooser
[08:44] <jibel> didrocks, are you on a wireless connection ?
[08:44] <jibel> didrocks, without connection no olink
[08:44] <didrocks> jibel: no connection on that one
[08:44] <didrocks> hum, ok, so it just looks "weird"
[08:44] <pitti> ah, that'd be it then
[08:45] <didrocks> I think at last one line will be needed at some point :)
[08:45] <didrocks> but ok, makes sense
[08:45] <jibel> *phew*
[08:46] <didrocks> Sorry for the false alarm, explaining it on the bug report
[08:46] <jibel> didrocks, no heart attack today please
[08:46] <didrocks> jibel: well, advocate that it looks weird to the user still :)
[08:47] <didrocks> jibel: but will try to keep your heart safe!
[08:47] <jibel> didrocks, I agree an empty screen is weird but not b1-critical
[08:48] <didrocks> jibel: agreed :)
[08:49] <seb128> hey
[08:49] <didrocks> salut seb128
[08:49] <tkamppeter> pitti, I have searched the system for the string "Memory error" now and it appears nowhere, not in any library and not in the kernel. Can it be a weird en_GB translation for segfault?
[08:50] <seb128> lut didrocks, la forme ?
[08:50] <pitti> tkamppeter: or perhaps "out of memory"
[08:50] <didrocks> seb128: ça va ;) pas sûr qu'on release, mais ça va :)
[08:50] <didrocks> et toi ?
[08:50] <pitti> bonjour seb128
[08:50] <seb128> hey pitti, wie gehts?
[08:50] <seb128> didrocks, ca va
[08:50] <pitti> tkamppeter: if the reporter can reproduce, strace should say more clearly what the problem is
[08:50] <seb128> watched France beat Germany for once yesterday ;-)
[08:50] <pitti> seb128: gut, danke!
[08:51]  * seb128 hugs mvo pitti
[08:51] <pitti> seb128: oh? I thought the European championship was in summer
[08:51]  * pitti hugs seb128
[08:51] <seb128> pitti, it was an amical game (not sure they call it that in english)
[08:51] <seb128> pitti, i.e just a friendly out of competition game
[08:51] <pitti> seb128: and ubiquity beat us 1:0 as well, we needed a late-night respin
[08:51] <seb128> :-(
[08:51] <pitti> seb128: ah, I see
[08:52] <pitti> seb128: we call it "Freundschaftsspiel", quite the same
[08:52] <seb128> pitti, seems it's "friendly game" in english
[08:53] <pitti> as opposed to the really hostile ones during the EC or WC :)
[08:53] <seb128> ;-)
[08:53] <pitti> seb128: no Sedanne this time?
[08:53] <seb128> pitti, respin sucks, I was looking forward an unfreeze!
[08:53] <seb128> pitti, no Zidane no ;-)
[08:53] <pitti> so was I
[08:54] <pitti> seb128: could you do a quick test for me?
[08:54] <pitti> seb128: I assume you don't have "libreoffice" installed (i. e. the metapackage)?
[08:54] <seb128> no I don't
[08:54] <seb128> yes I can do testing
[08:54] <pitti> seb128: can you please try "apport-bug libreoffice"?
[08:57] <seb128> pitti,
[08:57] <seb128> Gtk-WARNING **: GtkLabel 0x9e86678: widget tried to gtk_widget_get_width inside  GtkWidget     ::get_width implementation. Should just invoke GTK_WIDGET_GET_CLASS(widget)->get_width directly rather than using gtk_widget_get_width
[08:57] <seb128> Segmentation fault (core dumped)
[09:08] <glatzor> mvo, the problem seems to be that aptdaemon registers the cache update and emits the UpdatesChanged signal. Afterwards unity tries to get the available updates and aptdaemon locks the cache
[09:09] <rickspencer3> pitti, Riddell what's the word on the street for beta 1?
[09:09] <Riddell> rickspencer3: I'm fighting with the script to get it published
[09:09] <Riddell> rickspencer3: more testing is needed, we had respins late last night
[09:09] <rickspencer3> oh
[09:10] <rickspencer3> Riddell,  may I ask what the respins were for?
[09:10] <seb128> glatzor, mvo: hey
[09:10] <Riddell> rickspencer3: bug 940908 bug 942560
[09:10] <ubot2`> Launchpad bug 940908 in casper "Keyboard layout, oem-config not set on persistent USB image" [High,Fix released] https://launchpad.net/bugs/940908
[09:10] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Fix released] https://launchpad.net/bugs/942560
[09:11] <glatzor> morning seb128 !
[09:11] <Riddell> ubuntu desktop needs testing, lubuntu and edubuntu too, kubuntu is fine
[09:11] <seb128> glatzor, how are you?
[09:11] <glatzor> mvo, I could add a larger delay in the UpdatesChanged signal.
[09:11] <tkamppeter> pitti, about your CUPS segfault which you talked about initially today. Which devices do you have on USB? Can you run "sudo /usr/lib/cups/backend/usb", can you strace?
[09:12] <glatzor> seb128, I am fine! yorself?
[09:12] <seb128> glatzor, I'm good thanks
[09:12] <glatzor> yourself
[09:12] <seb128> glatzor, do you have any clue why the code in http://git.gnome.org/browse/gnome-control-center/tree/panels/info/cc-info-panel.c doesn't seem to work with aptdaemon?
[09:13] <mvo> glatzor: yeah, that sounds reasonable - or could it be done without the cache locks as its just a calculation?
[09:13] <seb128> glatzor, it's always displaying "Checking for Updates"
[09:14] <seb128> glatzor, is GetUpdates supposed to work on precise?
[09:14] <pitti> tkamppeter: that works; it only seems to crash sometimes in the test suite
[09:20] <Riddell> ubuntu-desktop team: more testing needed! http://iso.qa.ubuntu.com/qatracker/milestones/208/builds
[09:21] <glatzor> mvo, pitti, how much delay would be acceptable for an update check after a package operation or cache update is performed
[09:21] <glatzor> mvo, pitti so if you run "apt-get update". How long should unity take to show you "updatesavailable"? currently it is 5 seconds
[09:22] <pitti> glatzor: IMHO, anything up to an hour
[09:22] <glatzor> mvo, pitti could we raise this to a minte?
[09:22] <glatzor> minute
[09:22] <pitti> usually apt-get update is cron'ed
[09:22] <mvo> glatzor: sounds ok to me - I will also check the release upgrade if its giving up the lock too early for no good reason
[09:22] <pitti> for urgent security updates an hour seems appropriate to me
[09:23] <glatzor> pitti, but I don't want aptdaemon to sit an hour just waiting for sending the updates changed signal :)
[09:23] <pitti> glatzor: I mean from a purely visual POV
[09:23] <pitti> (what your question was, about "unity"
[09:24] <pitti> glatzor: in other words, 30 seconds or a minute doesn't matter for that at all
[09:24] <glatzor> pitti, unity nowadays just listens to the UpdatesChanged signal on the pk interface
[09:24] <glatzor> (additionally a check is performed some time after login)
[09:30] <seb128> glatzor, did you see my question before btw?
[09:39] <robert_ancell> seb128, hey
[09:39] <seb128> robert_ancell, hey, how are you?
[09:39] <seb128> robert_ancell, doing late hacking recently!
[09:39] <pitti> hey robert_ancell
[09:39] <robert_ancell> seb128, good.  I got lightdm to work, can you smoke test it?
[09:39] <robert_ancell> pitti, hello
[09:39] <seb128> robert_ancell, ok, it's un the packaging vcs?
[09:39] <robert_ancell> not up late today, just left computer on to wait you guys to come online
[09:39] <robert_ancell> seb128, yup
[09:40] <robert_ancell> it works for me and RAOF
[09:40] <seb128> robert_ancell, I'm on it
[09:41] <robert_ancell> pitti, we're still in freeze right?
[09:41] <seb128> robert_ancell, yes, but you can upload anyway
[09:42] <seb128> somebody will flush the queue when we unfreeze
[09:42] <pitti> robert_ancell: what seb128 said
[09:42] <robert_ancell> seb128, right.  So I think it's good to go, I just want a second opinion before pushing it to the archive
[09:43] <robert_ancell> seb128, also, if you see anyone who has had PAM issues during your hours let them know to try it
[09:43] <seb128> robert_ancell, ok
[09:43] <seb128> robert_ancell, I've it installed, brb, testing it
[09:46] <glatzor> mvo, hm. aptdaemon is quite fast in reclaiming the lock after dist-upgrade temporarily released it :)
[09:48] <glatzor> mvo, should we use a special lock to indicate that a dist-upgrade is currently running? if update-manager or software-center is opened in the meantime we could show a warning and disable all actions
[09:48] <glatzor> mvo, aptdaemon could also avoid sending updateschanged signals
[09:49] <mvo> glatzor: I think that does make sense, or it could simply keep the lock for the entire lifetime of the operation (which it actually should do already :/)
[09:51] <chrisccoulson> good morning everyone
[09:52] <tkamppeter> pitti, try to get a way to have a reproducable segfault of the usb backend, otherwise we cannot fix it.
[09:52] <seb128> re
[09:53] <seb128> robert_ancell, ok, all good from what I can test her
[09:53] <seb128> here
[09:53] <pitti> tkamppeter: right; I re-enabled the test suite in the build, and it failed now: https://launchpadlibrarian.net/94856878/buildlog_ubuntu-precise-i386.cups_1.5.2-5pitti_FAILEDTOBUILD.txt.gz
[09:53] <robert_ancell> seb128, phew - you were gone a while and I was getting worried...
[09:53] <seb128> robert_ancell, i.e local logins, ecryptfs, guest session
[09:53] <pitti> tkamppeter: it seems to consistently happen on builders, but only sometimes locally; anyway, I'll try to reproduce it locally later
[09:53] <robert_ancell> seb128, ok, I'll just push it to the archive then
[09:53] <seb128> robert_ancell, sorry, I did a round of logout, login and different accounts type checks
[09:54] <robert_ancell> seb128, nah, that's good ;)
[09:54] <seb128> robert_ancell, you can push to the ppa as well if you want some extra testing during the day in case
[09:54] <seb128> you can dput the same version to both
[09:54] <robert_ancell> seb128, save version number?
[09:54] <seb128> yes
[09:55] <seb128> or add a ~ppa1 or something if you want but that's not needed since that's the same content
[09:56] <robert_ancell> seb128, done, cya tomorrow
[09:56] <seb128> robert_ancell, 'night
[09:56] <glatzor> mvo, you have to release the lock shortly before dpkg is called
[09:56] <glatzor> :/
[09:57] <seb128> glatzor, hey again, sorry I had to restart and I didn't see if you responded to my gnome-control-center question before
[09:57] <glatzor> sorry seb128, I missed your question by accidentially closing my xchat window
[09:57] <seb128> glatzor, lol, no worry
[09:58] <seb128> glatzor, if you have some minutes could you look at http://git.gnome.org/browse/gnome-control-center/tree/panels/info/cc-info-panel.c and tell me if that's supposed to work with aptdaemon?
[09:58] <seb128> glatzor, the button always displays "Checking for Updates"
[09:58] <mvo> glatzor: yeah
[09:59] <seb128> glatzor, see refresh_updates() and on_pk_get_tid_ready()
[09:59] <seb128> glatzor, is "GetUpdates" supposed to work with the aptdaemon compat layer?
[09:59] <dupondje> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/943881 if somebody could have a look :)
[09:59] <ubot2`> Launchpad bug 943881 in libreoffice "Unable to print to password protected (cups) printer" [Undecided,New]
[10:00] <seb128> dupondje, it's probably for Sweetshark or tkamppeter
[10:02] <glatzor> seb128, it should work. But why isn't the packagekit-glib client not used? you don't need to operate on the dbus level. there is a nice high level api for packagekit
[10:03] <seb128> glatzor, dunno, it's code from GNOME
[10:03] <glatzor> seb128, http://paste.ubuntu.com/863168/
[10:06] <rodrigo_> hi
[10:06] <rodrigo_> I can't make gnome-shell being used when using automatic login
[10:07] <rodrigo_> I guess the choice is stored/used by lightdm?
[10:09] <seb128> rodrigo_, hey, automatic login with what login manager? what version do you use?
[10:09] <rodrigo_> seb128, fresh 11.10 install, lightdm
[10:10] <seb128> rodrigo_, it was fixed in a SRU, so I guess: update
[10:10] <rodrigo_> ah ok
[10:10] <rodrigo_> thanks
[10:10] <pitti> didrocks: are you happy with the "HUD" release note on https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview, or want to improve it?
[10:10] <pitti> hey rodrigo_
[10:10] <rodrigo_> hi pitti
[10:10] <didrocks> pitti: i'm just about to edit it
[10:11] <rodrigo_> so, how are you all doing for this cycle?
[10:11] <rodrigo_> anything exciting?
[10:11] <rodrigo_> (I'm not using precise)
[10:12] <pitti> rodrigo_: quality, kwality, Q'hal-ity
[10:12] <rodrigo_> good
[10:13] <glatzor> seb128, but it doesn't seem to work: it doesn't catch the Finished signal. I will have a look at it
[10:14] <didrocks> pitti: done
[10:15] <pitti> didrocks: c'est beaucoup, merci!
[10:16] <pitti> "c'est bon" probably better?
[10:16] <seb128> glatzor, thanks
[10:17] <glatzor> seb128, the panel if doesn't work with packagekitd :)
[10:18] <seb128> glatzor, ok, I will bug richard about it
[10:28] <glatzor> seb128, it is a bug in the panel
[10:29] <glatzor> seb128, self->priv->updates_state isn't unset to UPDATES_NOT_AVAILABLE if there aren't any updates
[10:29] <glatzor> seb128, it keeps the CHECKING_UPDATES state
[10:31] <seb128> oh
[10:31] <seb128> glatzor, thanks!
[10:32] <glatzor> seb128, line 1776 in on_pk_transaction_signal should set the state away from CHECKING_UPDATES if it isn't yet switched to UPDATES_AVAILABLE
[10:32] <rye> ugh after g-s-d crash it got restarted and now I have 3 syndaemons
[10:36] <seb128> rye, bug #868400
[10:36] <ubot2`> Launchpad bug 868400 in gnome-settings-daemon "Synaptics touchpad stops working - two syndaemon instances running" [Medium,Confirmed] https://launchpad.net/bugs/868400
[10:36] <seb128> rye, known issue
[10:36] <seb128> glatzor, excellent, thanks
[10:38] <seb128> rye, btw did you ping to didrocks earlier? do you get the firefox altgr focus thing happening with compiz r3025 really? I only get it with the staging ppa version here
[10:39] <rye> seb128, well, it is happening currently now
[10:39] <seb128> rye, what compiz version do you use?
[10:39] <rye> seb128, 1:0.9.7.0~bzr3025-0ubuntu1~ppa1 - from unity-team/ppa
[10:39] <rye> updated yesterday
[10:41] <chrisccoulson> hmmmm, does lkcl deliberately try to p*ss everyone off, every time he posts to a mailing list?
[10:43] <didrocks> seb128: rye: can you comment on the bug?
[10:44] <didrocks> rye: do you have the time to try this combination:
[10:44] <didrocks> - unity from precise (5.4)
[10:44] <didrocks> - compiz from this ppa?
[10:44] <didrocks> to try to decipher if it's compiz or unity
[10:47] <rye> didrocks, sure, will reboot now to check whether i am still experiencing this on current packages and then will swap unity/compiz
[10:47] <rye> brb
[10:47] <seb128> chrisccoulson, lkcl?
[10:49] <didrocks> rye: thanks :)
[10:50] <glatzor> mvo, the problem with pkcompat and dist-upgrade only exists if you still have got the packagekit config files arround
[10:50] <glatzor> mvo /etc/apt/apt.conf.d/20packagekit isn't (yet) shipped with aptdaemon
[10:50] <chrisccoulson> seb128, lkcl is an annoying troll
[10:50] <chrisccoulson> or, at least i think he's just a troll ;)
[10:51] <seb128> chrisccoulson, on what lists?
[10:51] <chrisccoulson> seb128, http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/ef5e559992e2d158
[10:51] <chrisccoulson> he's posted on our lists before as well though
[10:51] <seb128> oh, mozilla lists, not lists I read ;-)
[10:52] <glatzor> pitti, mvo: packagekit drops an an apt.conf.d snippet which calls the StateHasChanged method of PackageKit to notfiy the daemon about finished package operations (installs/cache updates) which have been done with non-packagekit tools, e.g. apt-get or dist-upgrade.py
[10:52] <seb128> chrisccoulson, is reading that another way to waste 15 minutes of my life I will not get back? ;-)
[10:53] <chrisccoulson> seb128, yeah, don't read it
[10:53] <chrisccoulson> he's posted on our lists before as well, eg, https://lists.ubuntu.com/archives/ubuntu-devel/2011-August/034011.html
[10:53] <seb128> chrisccoulson, oh, I probably didn't read that one either, I need motivation to read emails which are over a screen long ;-)
[10:53] <chrisccoulson> heh
[10:54] <chrisccoulson> you need to be stupid to read anything from lkcl too. i keep telling the mozilla guys that they should just ignore him
[10:54] <glatzor> pitti, mvo: Should I ship the file also in aptdaemon.pkcompat or would a packagekit-common package be a better solution? There is also the packagekit dbus config which is currenlty replicated in aptdaemon
[10:55] <pitti> glatzor: conffile-wise a -common would indeed better, but duplicating it for now should work as long as they are identical
[10:56] <rye> didrocks, i come back with quite an interesting story
[10:56] <rye> didrocks, so, upon reboot i stopped having this problem
[10:57] <rye> didrocks, then i recallled that the first time i noticed this was when i was using plain US language keyboard without dead keys and/or compose (after i noticed the bug I added the US international with AltGr dead keys.
[10:58] <rye> didrocks, so I added the plain English(US) version and it stopped working in current set of package, what's your default english layout?
[10:59] <rye> hm
[10:59] <didrocks> rye: I don't have an english layout here
[10:59] <didrocks> french one, and never experienced the issue
[10:59] <didrocks> seb did, but only with a newer compiz than yours
[11:00] <didrocks> this story is confusing :)
[11:00] <didrocks> seb128: you are using the OSS alternative as well?
[11:00] <rye> didrocks, but now i see it does not switch focus somewhere else when i press AltGr in a layout that has compose key
[11:01] <didrocks> rye: maybe not a regression after all
[11:01] <seb128> didrocks, yes
[11:01]  * didrocks is puzzled
[11:01] <rye> so, now I only have to find a way to reproduce this issue with a keyboard layout having compose key
[11:02] <didrocks> rye: yeah, and please anotate the bug report with your findings
[11:02] <seb128> didrocks, well "alternative",
[11:02] <seb128> $ gsettings get org.gnome.libgnomekbd.keyboard layouts
[11:02] <seb128> ['fr\toss', 'de']
[11:02] <seb128> didrocks, ^
[11:03] <didrocks> ['fr\toss', 'fr']
[11:03] <didrocks> yeah, it's the same here then
[11:03] <didrocks> oss is alternative in the display IIRC
[11:03] <seb128> but I don't get it now
[11:03] <rye> well, at the moment what is definitely broken is pressing alt to reveal the menu in gtk3 apps - before upgrade to ppa versions the menus worked in gtk3 apps but were failing for gtk2 ones
[11:03] <seb128> it doesn't happen all the time
[11:03] <seb128> rye, known issue
[11:04] <didrocks> rye: alt to reveal gtk3 app is another issue :)
[11:04] <rye> didrocks, i can haz a bug # to subscribe? I lost the one for gtk2 :(
[11:05] <didrocks> rye: bug #943194
[11:05] <ubot2`> Launchpad bug 943194 in unity-distro-priority "[regression] Pressing alt doesn't show the menu title bar in top panel" [High,Fix committed] https://launchpad.net/bugs/943194
[11:05] <didrocks> rye: we won't release with this regression 5.6 anyway
[11:06] <rye> ah, i have already marked this as affected
[11:07] <rye> so, /me goes to try reproducing the bug with compose, thank you for bearing with me :)
[11:09] <didrocks> rye: thank to *you* for testing the latest crack ;)
[11:23] <davidcalle> didrocks, quick update on the vala Rbox scope : it's almost finished, and the lens keeps the Banshee one too.
[11:24] <glatzor> mvo, pitti have you seen the latest org.freedesktop.policykit.imply addition to polkit? it would allow removing the corresponding code from aptdaemon (AptDaemon._check_alternative_auth which makes installing from new repo/buying easier). Is it too late in the cycle?
[11:26] <didrocks> davidcalle: thanks, I was just thinking about it this morning!
[11:26] <didrocks> davidcalle: do you think we can have a release for, let's say, start of next week?
[11:27] <davidcalle> didrocks, should be fine, but I don't know if the cover art will be ready.
[11:30] <didrocks> davidcalle: ok, keep me in touch :)
[11:30] <davidcalle> didrocks, ok
[11:31] <pitti> glatzor: needs an FFE at this point, I think; is that released yet?
[11:39] <glatzor> pitti: polkit 0.103
[11:39] <pitti> glatzor: ah, we have 0.104
[11:39] <glatzor> it was released back in december '11
[11:40] <glatzor> pitti, so I will delay the switch to the next cycle. the current solution is already working since a year :)
[11:41] <glatzor> mvo, pitti seb128 see you! have a nice day.
[11:42] <seb128> glatzor, thanks, you as well!
[11:45] <glatzor> mvo, aptdaemon rev 774 should improve the situation for dist-upgrade.py a little bit
[11:47] <mvo> thanks a bunch glatzor
[11:47]  * mvo hugs glatzor
[11:50] <seb128> pitti, btw did I miss a follow up on the apport-bug libreoffice stuff?
[11:50] <seb128> pitti, I told you it was segfaulting here, did you need another info?
[11:50] <Sweetshark> pitti: reping wrt to openoffice transitional on chinstrap. did you have a look?
[11:53] <pitti> seb128: oh, I didn't get that
[11:53] <pitti> seb128: cheers
[11:53] <pitti> Sweetshark: ah, will do
[11:55] <pitti> Sweetshark: uploaded, thanks!
[11:58] <seb128> pitti, doh
[11:58] <seb128> $ apport-bug libreoffice
[11:58] <seb128> [xcb] Unknown request in queue while dequeuing
[11:58] <seb128> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[11:58] <seb128> [xcb] Aborting, sorry about that.
[11:58] <seb128> python: ../../src/xcb_io.c :178 : dequeue_pending_request:  L'assertion « !xcb_xlib_unknown_req_in_deq » a échoué.
[11:58] <seb128>  
[11:58] <seb128> pitti, that's a different one though
[11:58] <pitti> seb128: right, I get either bug 943661 or bug 901675
[11:58] <ubot2`> Launchpad bug 943661 in apport "apport-gtk crashed with SIGSEGV in get_gsubgpos_table()" [Medium,Triaged] https://launchpad.net/bugs/943661
[11:58] <ubot2`> Launchpad bug 901675 in apport "apport-gtk assert failure: python: ../../src/xcb_io.c:273: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed." [High,In progress] https://launchpad.net/bugs/901675
[11:58] <seb128> Pango:ERROR:/build/buildd/pango1.0-1.29.5/./pango/pango-layout.c:3801:pango_layout_check_lines: assertion failed: (!layout->log_attrs)
[11:58] <pitti> seb128: sweet, so this reproduces pretty well then
[11:58] <pitti> I spent an hour writing test cases which exercise the whole UI, and they reproduce this nwo
[11:59] <pitti> funny to see the windows fly around you
[11:59] <pitti> seb128: and no ev to whine to :/
[12:00] <seb128> yeah :(
[12:00]  * pitti goes to untangle the threads-in-threads mess that the whoopsie merge introduced
[12:01] <didrocks> Sweetshark: I guess you didn't open a bug at the end for the new libroffice in -proposed breaking bamf/unity. The good news is that it's now handled :)
[12:02] <pitti> didrocks, Sweetshark: bug 943192 and/or bug 842566 ?
[12:02] <ubot2`> Launchpad bug 943192 in bamf "libreoffice integration will break with new LO in oneiric-proposed" [Undecided,Fix released] https://launchpad.net/bugs/943192
[12:02] <ubot2`> Launchpad bug 842566 in bamf "Libreoffice and unity integration broken." [High,Fix released] https://launchpad.net/bugs/842566
[12:03] <didrocks> pitti: the SRU candidate closes bug #943192
[12:03] <pitti> fine
[12:04] <mvo> glatzor: did you had a chance to look at lp:~mvo/aptdaemon/admin-group-fix?
[12:04] <mvo> meh, too late
[12:04] <Sweetshark> didrocks: nah, sorry
[12:04] <dupondje> heh they close my bug on libreoffice because I need to use apport-bug ... :) right it crashes guys :D
[12:04] <didrocks> Sweetshark: no worry :)
[12:05] <pitti> dupondje: call it on a package which is actually installed, like libreoffice-gtk
[12:06] <pitti> dupondje: I bet you don't have "libreoffice" installed (it's not by default)
[12:06] <dupondje> aha k :)
[12:21] <ricotz> didrocks, Sweetshark, hi, this bamf/unity issue is probably true for natty now too
[12:22] <didrocks> ricotz: want to do the backport? :)
[12:22] <ricotz> didrocks, i guess doing the LO backport was enough from my side ;)
[13:00] <zzecool> smspillaz: can you please take a look at this one https://bugs.launchpad.net/ubuntu/+source/unity/+bug/943941
[13:00] <ubot2`> Launchpad bug 943941 in unity "GRID plugin very inconsistent and erratic behavior " [Undecided,New]
[13:00] <zzecool> very strange bug
[13:16] <smspillaz> zzecool: sure, when I have time, although I may not be around in the next 3 weeks
[13:17] <zzecool> ;o
[13:26] <jml> in this bright and shiny multi-arch world, what's the right way to install Skype on my 64bit laptop?
[13:41] <Sweetshark> pitti: http://packages.debian.org/source/sid/zemberek-ooo would it still be possible to sync that to universe? see also bug 801839.
[13:41] <ubot2`> Launchpad bug 801839 in libreoffice "Turkish spell checker for LibreOffice" [Undecided,Confirmed] https://launchpad.net/bugs/801839
[13:44] <pitti> Sweetshark: yes, that's no problem
[13:45] <pitti> Sweetshark: can you please file a sync request bug and subscribe ubuntu-release?
[13:49] <Sweetshark> pitti: cant we use bug 801839 for that?
[13:49] <ubot2`> Launchpad bug 801839 in libreoffice "Turkish spell checker for LibreOffice" [Undecided,Confirmed] https://launchpad.net/bugs/801839
[14:13] <desrt> seb128: hey
[14:13] <seb128> desrt, hey, how are you?
[14:13] <desrt> acceptably well
[14:13] <desrt> seb128: dbusmenu searching is working in a somewhat simple way at this point
[14:14] <desrt> all that's missing is indicators
[14:14] <seb128> "somewhat simple way"?
[14:14] <desrt> it may be an appropriate time to start doing builds of my branch in a PPA
[14:14] <seb128> what is "simple" there
[14:14] <desrt> seb128: it's not quite at feature parity with the existing code, but quite testable
[14:14] <seb128> you mean the ranking etc?
[14:14] <desrt> it doesn't do things like fail to report disabled items, etc.
[14:14] <desrt> no.  ranking is working.
[14:14] <seb128> ok, good
[14:15] <seb128> I was wondering if you changed the ranking logic and why ;-)
[14:15] <desrt> no
[14:15] <desrt> that stuff is black magic
[14:15]  * desrt didn't dare :)
[14:15] <seb128> hehe
[14:15] <desrt> particularly with the changes made for french, etc.
[14:15] <seb128> desrt, where is it? I will start by giving it a round on my box and let you know how it goes
[14:15] <desrt> https://code.launchpad.net/~desrt/indicator-appmenu/hud-rewrite-wip
[14:16] <seb128> thanks
[14:16] <desrt> thanks to you
[14:17] <desrt> m_conley: good morning :)
[14:21] <seb128> desrt, hum, there is a merge conflict in src/hud-search.c (for info) when trying to merge your branch on trunk
[14:22] <desrt> i'd recommend against merging :)
[14:23] <seb128> automake: cannot open < gtk-doc.make: Aucun fichier ou dossier de ce type
[14:23] <seb128> autoreconf: automake failed with exit status: 1
[14:23] <seb128> some days I hate autotools
[14:23] <desrt> huh
[14:23] <desrt> the gnome-autogen is supposed to take care of that
[14:23] <desrt> let me check
[14:23] <seb128> desrt, the packaging tools run autoreconf
[14:23] <seb128> not gnome-autogen
[14:23] <desrt> oh.  ya.  sucks, then.
[14:23] <desrt> run the autogen.sh.  that's why it's there :p
[14:24] <seb128> I hate that GNOME doesn't work with standard tools :-(
[14:24] <kenvandine> desrt, i've started doing that more lately
[14:24] <desrt> seb128: autogen.sh is an absolutely pervasive convention
[14:24] <kenvandine> at least for things that i have daily builds on LP for
[14:24] <seb128> desrt, autoreconf ought to work and work almost everywhere
[14:24] <kenvandine> override_dh_autoreconf:
[14:24] <kenvandine>         NOCONFIGURE=1 dh_autoreconf ./autogen.sh
[14:24] <desrt> seb128: even the automake developers don't like autoreconf
[14:25] <desrt> seb128: for example ,the integration of libtoolize into autoreconf was largely considered to be a mistake
[14:25] <desrt> it's a bad fit
[14:25] <desrt> for the same reason that gtkdocize would be
[14:25] <seb128> we need build systems for human being, where is robert_ancell?!
[14:25] <desrt> i'll agree on that point :)
[14:25] <seb128> (building)
[14:25] <pitti> Sweetshark: yes, we can use that
[14:27] <seb128> desrt, detail but the POTFILES.in needs an update (built break on .pot update, another packaging thing)
[14:27] <desrt> ah.  right.
[14:27] <desrt> it would :)
[14:28] <seb128> desrt, 3 of 16 tests failed
[14:28] <seb128> I guess I can ignore that as well?
[14:28] <desrt> oh.  i didn't know it had tests :)
[14:28] <kenvandine> seb128, robert_ancell has a branch for gwibber using bake, which had a great side effect
[14:29] <seb128> kenvandine, which one?
[14:29] <kenvandine> he found some problems in my makefiles :)
[14:29] <desrt> seb128: let me push fixes for these problems
[14:29] <seb128> hehe
[14:29] <seb128> desrt, that's fine, I workarounded locally
[14:29] <kenvandine> bake discovered things like missing po files from LINGUAS file
[14:29] <kenvandine> etc
[14:29] <seb128> ok, it's built, victory :p
[14:29] <kenvandine> i had several merge proposals from him, it was great :)
[14:30]  * kenvandine has yet to look at his bake branch though
[14:33] <seb128> desrt, hum, is it supposed to work with unity?
[14:33] <desrt> yes
[14:33] <desrt> judging by your question, i assume it doesn't :)
[14:34] <seb128> desrt, I'm trying in a fresh guest session, hud-service is running but unity hud spins and lists nothing
[14:34] <desrt> interesting.
[14:34] <seb128> tried with nautilus typing "list" to switch to list view
[14:34] <seb128> then with gedit "pref"
[14:34] <seb128> it spins for 5 seconds and stop
[14:34] <seb128> nothing listed
[14:34] <desrt> seb128: can you open a terminal and run the hud-service from there?
[14:34] <desrt> see what it says?
[14:35]  * desrt was able to get it working in unity just fine
[14:35]  * desrt joins you in unity for a while :)
[14:36] <seb128> desrt, doh, sorry
[14:36] <seb128> desrt, the running one was my user one
[14:36] <desrt> seb128: if you were in a guest session there should have been a new copy dbus activated
[14:36] <seb128> desrt, http://pastebin.ubuntu.com/863498/
[14:36] <desrt> unless your guest session was old
[14:36] <seb128> let me get debug symbols
[14:37] <desrt> seb128: do you have the fixed bamf package?
[14:37] <seb128> ii  bamfdaemon                                0.2.110+bzr452ubuntu0+407                    Window matching library - daemon
[14:37] <seb128> desrt, I've r452
[14:37] <desrt> yes.  that should do it.
[14:38] <desrt> interesting.
[14:38] <seb128> desrt, https://launchpadlibrarian.net/94691917/bamf_0.2.110%2Bbzr451ubuntu0%2B407_0.2.110%2Bbzr452ubuntu0%2B407.diff.gz
[14:38] <didrocks> (and it's really rev 452 if someone is asking :))
[14:38] <seb128> that's the most recent commit in that binary
[14:38] <seb128> didrocks, yeah, thanks for fixing that ;-)
[14:38] <didrocks> seb128: yw, shhhhh :p
[14:38] <desrt> weird.  it's working here
[14:38] <desrt> funny thing is, i *don't* have the new bamf :)
[14:38] <seb128> desrt, I'm french :p
[14:39] <seb128> dunno if that can make a difference
[14:39] <desrt> seb128: shouldn't.  i didn't touch that part.
[14:39] <desrt> so when you search it crashes with that trace you showed me?
[14:39] <seb128> desrt, no, it segfault on start
[14:40] <seb128> I didn't use the hud, just ran the service
[14:40] <desrt> it segfaults on startup with a backtrace in bamfmatcher?
[14:40] <seb128> yes
[14:40] <desrt> that code should only ever be reached when the default window is changing...
[14:40] <desrt> s/default/focus/
[14:40] <desrt> just to be clear; you run hud-service?
[14:40] <seb128> desrt, sorry, it segfault on alt-tab
[14:40] <desrt> okay.  more interesting, then :)
[14:42] <seb128> desrt, http://pastebin.ubuntu.com/863516/
[14:42] <seb128> desrt, getting debug symbols
[14:42] <desrt> seb128: that '???' would be quite helpful to know
[14:42] <seb128> I figured so :p
[14:42] <desrt> oh
[14:42] <desrt> i found it
[14:42] <desrt> i'm surprised this didn't hit me already
[14:43] <desrt> you're on 32, right?
[14:43] <seb128> desrt, http://pastebin.ubuntu.com/863518/
[14:43] <seb128> desrt, yes
[14:43] <desrt> seb128: i already found it :)
[14:43] <seb128> desrt, well just so you can confirm it's what you found ;-)
[14:43] <desrt> and your backtrace lies :p
[14:44] <desrt> (or i have to assume so, because what i found must surely be causing it, and it's not in that function)
[14:44] <seb128> http://pastebin.ubuntu.com/863518/
[14:44] <desrt> try pulling
[14:44] <seb128> it's not that one?
[14:44] <seb128> ok
[14:44] <desrt> seb128: i think there's some inlining going on
[14:44] <seb128> I hate compilers :p
[14:44] <desrt> sorry for the bump.  that was really dumb.
[14:44] <desrt> hopefully you do not find more :p
[14:48] <seb128> desrt, it's a bit better
[14:48] <seb128> desrt, http://pastebin.ubuntu.com/863525/
[14:48] <didrocks> desrt: he's sneaky, he always find crashes :)
[14:48] <didrocks> finds*
[14:48] <seb128> desrt, it runs now, I can use it, but after using nautilus to do "list" and then "icône" it segfaulted
[14:48]  * desrt needs 32bit
[14:48] <seb128> desrt, let me get dbusmenu symbols
[14:49] <desrt> seb128: probably not required
[14:49] <desrt> it's obvious what should be there
[14:49] <seb128> desrt, let me know if you need infos, it's trivial to trigger
[14:49] <seb128> I got it twice already
[14:50] <desrt> i honestly guessed on the signature for this signal
[14:50] <desrt> becuase the documentation was broken
[14:50] <desrt> so that could be the problem
[14:50] <desrt> although i don't know why it would work for amd64 in that case
[14:50] <desrt> tedg: can you fix the dbusmenu-glib docs? :)
[14:51] <desrt> seb128: yup.  this is exactly the problem.
[14:51] <desrt> this signal handler should have an extra 'int' parameter that i dropped
[14:51] <desrt> adding it now
[14:52] <seb128> desrt, btw your hud is an order of magnitude slower to list results that the one in precise
[14:52] <seb128> like it takes a good second and is jerky to get results
[14:52] <seb128> where the precise one is smooth to use
[14:52] <desrt> seb128: i'm surprised you get results at all with that crash
[14:53] <desrt> seb128: pushed again
[14:55] <desrt> seb128: the performance thing also confuses me
[14:56] <seb128> desrt, no, I'm not getting a thinkpad! ;-)
[14:56] <desrt> seb128: well, it's good feedback
[14:56] <desrt> because i'm doing strictly less work than was being done before
[14:57] <desrt> so now i have to wonder what is wrong :)
[14:57] <mandel> pitti, the code I wrote for bug #933729 has been approved but since I have not heard from you I'll like to double check if it is fine to merge it
[14:57] <ubot2`> Launchpad bug 933729 in ubuntu-sso-client "[UIFe] Provide a dialog so that a user can accept SSL certificates" [Medium,In progress] https://launchpad.net/bugs/933729
[14:57] <desrt> seb128: it's when you are searching that it's slow, or when you are switching windows?
[14:59] <tedg> desrt, I don't see where the docs are wrong?  We're talking about child-added, no?
[14:59] <desrt> tedg: the signals don't end up in the docs
[14:59] <seb128> desrt, the segfault is fixed indeed,when doing researches
[14:59] <desrt> probaly because you're not doing the gobject runtime checking stuff in the docs build
[14:59] <pitti> mandel: hm, I thought I already approved the dialog
[15:00] <tedg> desrt, Hmm, okay.  But, the docs that are there are fine?
[15:00] <Sweetshark> pitti: bug is syncified
[15:00] <desrt> tedg: so i'm going off what's installed in the -docs package in precise right now, for example
[15:00] <pitti> mandel: but left some dropping that it's better to not have a warning dialog if there is an SSL verification failure
[15:00] <desrt> tedg: go to the page for DbusmenuMenuitem
[15:00] <desrt> you know how at the top, under the synopsis you usually see the class hierarchy thing?
[15:00] <mandel> pitti, yes, I replied to that and wanted to be sure.. better safe than sorry
[15:01] <desrt> GObject
[15:01] <desrt> +- DbusmenuClient
[15:01] <desrt> that thing
[15:01] <desrt> and then the list of properties and signals
[15:01] <desrt> that's what's missing
[15:01] <mandel> pitti, I'm also talking with gnome to see if we can handle that better from a gnome point of view rather than trusting u1 :)
[15:01] <tedg> desrt, Ah, hmm...
[15:02] <desrt> the most important part of that is documentation of the arguments to signal handlers
[15:02] <mandel> pitti, I'll approve it then and hopefully we will have something nicer upstream and will throw that code away..
[15:03] <seb128> desrt, http://ubuntuone.com/3aWdGHp1C42Ysuv6AKGkkz
[15:03] <mhr3> desrt, speaking about docs, do you know who to push for https://bugzilla.gnome.org/show_bug.cgi?id=662424 ?
[15:03] <ubot2`> Gnome bug 662424 in general "Class hierarchy about interfaces not generated by default" [Normal,New]
[15:03] <tedg> desrt, Because there's no type checking of signals... good thing we're not making that mistake on new APIs!  Doh!  GVariant!  ;-)
[15:03] <desrt> seb128: you're concerned by the delay while typing?
[15:04] <seb128> desrt, no, by the visible reordering in the result after I'm done typing
[15:04] <desrt> tedg: use of g_variant_new and g_variant_get is optional :)
[15:04] <desrt> seb128: right.
[15:04] <desrt> i don't get that on my supercomputer
[15:05] <desrt> but i actually don't understand why the regression in performance
[15:05] <desrt> i have an idea about it, though
[15:05] <desrt> i'm going to add some profiling
[15:05] <desrt> seb128: thanks for the help
[15:08] <seb128> desrt, http://ubuntuone.com/7lMpaAopqUL8At23Us8l9J
[15:08] <tedg> desrt, Hmm, it's doing the scan and just generating an entirely empty signals file... not sure why.
[15:08] <seb128> desrt, that's with the current precise version if you want to compare
[15:09] <seb128> desrt, it feels smooth, where the new version has like a lag where you can stuff being reordered
[15:09] <desrt> seb128: so my theory is that i am doing more queries than are required
[15:09] <seb128> desrt, not sure it's easy to notice on the video but I can feel it for sure
[15:09] <desrt> let me check that theory
[15:10] <seb128> desrt, yw for the help, I can easy test, just ask me to pull updates when you want testing ;-)
[15:12] <desrt> seb128: so i can get the same effect as you
[15:12] <desrt> but only on very long search strings
[15:12] <seb128> desrt, your thinkpad is probably beefier than my i5 dell ;-)
[15:13] <desrt> so one possible cause of slowness is my interaction with the distance measuring algorithm
[15:13] <desrt> i'm doing a lot of strdup there
[15:13] <desrt> tedg: do you want to start helping?
[15:14] <mhr3> tedg, do you have all *_get_type functions in your .types file?
[15:16] <desrt> oh.
[15:16] <desrt> now i know the different
[15:16] <desrt> seb128: you're using it installed.  i'm using it uninstalled
[15:17] <desrt> therefore ted's behaviour-modifying code is in effect :p
[15:17] <desrt> jesus christ!
[15:17] <desrt> tedg: you're insand!
[15:17] <desrt> *insane
[15:18] <desrt> tedg: you have these macros in use all over your distance-checking code: ADD_PENALTY
[15:18] <desrt> which are defined as so
[15:18] <desrt> #define ADD_PENALTY         get_settings_uint(get_settings(), "add-penalty",        10)
[15:18] <desrt> get_settings() is iterating over all the list of installed schemas on the system
[15:18] <desrt> so every time you access that macro (or any ones line it) from your algorithm (which is like... many times per item searched) you are iterating all of the gsettings schemas on the system
[15:19] <seb128> that's ok, gsettings is performant :p
[15:19] <desrt> not THAT performant
[15:19] <desrt> and the problem isn't in gsettings
[15:19] <desrt> it's in repeatedly doing a string-list-search in the settings_schema_exists() function
[15:20] <desrt> seb128: let me try a tweak....
[15:20] <seb128> yeah, I was just trolling, ignore me ;-)
[15:20] <seb128> desrt, how come the non installed version doesn't use the distance checking?
[15:21] <desrt> seb128: because it can't find the schema
[15:21] <seb128> oh ok, you don't have it installed at all
[15:21] <desrt> seb128: pull and test that
[15:21] <desrt> seb128: you're right.  i do have it installed, so it should not be much difference
[15:22] <desrt> probably it's just my fancy i7, then :)
[15:22] <desrt> seb128: i just pushed a test change.  please check it out
[15:22] <seb128> desrt, smooth \o/
[15:22] <desrt> tedg: *smack*
[15:23] <seb128> desrt, well it was not that slow in precise, so it means you exerce that code path over the old version?
[15:23] <desrt> seb128: anyway... i still have some ideas for more performance improvements
[15:23] <desrt> seb128: i'm not sure why the old version was not slow as well
[15:23] <seb128> maybe it was buggy and not hitting that code ;-)
[15:23] <desrt> tedg: did you introduce this gsettings abuse recently?
[15:23] <desrt> ie: not in the distro yet?
[15:24] <seb128> desrt, no
[15:24] <seb128> desrt, I was running trunk before your version
[15:24] <desrt> odd.
[15:24] <desrt> i wonder if trunk already fixed it, then :)
[15:25] <desrt> to be honest, i'm surprised that it was as fast as it is
[15:25] <desrt> (both versions)
[15:26]  * desrt did not imagine "number of gsettings schemas installed on the system" to affect the algorithmic complexity of the most important algorithm in the hud :)
[15:26] <didrocks> it's to ensure that all your code is as fast as it can
[15:27] <didrocks> then, when you will get the most of possible optimization
[15:27] <didrocks> we will remove the sleep ()
[15:27] <didrocks> (hidden, of couse ;))
[15:31] <desrt> seb128: anyway... there is still substantial room for performance improvements here
[15:31] <desrt> seb128: indicators should be along soon....
[15:31] <desrt> tedg: it's my plan to split out handling of the application and system indicators into two separate classes, btw
[15:31] <desrt> tedg: since they're really handled in absolutely different ways
[15:32] <desrt> (one with dbus name watches and one with a service quite like the appmenu registrar)
[15:32] <seb128> desrt, ok, I will give another try later, I'm set for testing it, just need to pull, make and cp ;-)
[15:32] <desrt> seb128: thanks for the help so far
[15:32] <seb128> time for some sport, nice weather outside let's go running, I will be back in an hour or so
[15:32] <seb128> desrt, yw!
[15:32] <desrt> seb128: EXERCISE
[15:32] <desrt> you french people...
[15:33] <seb128> desrt, THANKS
[15:33] <seb128> ;-)
[15:33]  * desrt decides to go ride a streetcar
[15:37] <agateau> hey, any apparmor expert around? bug #939126 is being painful for kde telepathy (and I know nothing about apparmor :/)
[15:37] <ubot2`> Launchpad bug 939126 in telepathy-mission-control-5 "AppArmor profile does not allow creating of ~/.cache/dconf" [Undecided,New] https://launchpad.net/bugs/939126
[15:41] <mdeslaur> jdstrand: ^
[15:41] <tedg> desrt, Uhm, okay... I don't disagree, but seems like something that should happen next cycle, not after beta freeze.
[15:42] <jdstrand> agateau: ack. I'll prepare an upload for after beta 1 (there is already a pending telepathy-mission-control-5 that should go through
[15:44] <agateau> jdstrand: great, thanks!
[15:59]  * cyphermox will be out of a few hours: dentist appointment
[16:00] <pitti> good night everyone! have to run out now
[16:08] <cyphermox> night pitti
[16:19] <desrt> tedg: it seems like a relatively minor change compared to the rest of what's on the branch, honestly...
[16:20] <desrt> tedg: did oyu get a chance to look at the branch yet?
[16:21] <tedg> desrt, Yes, but we're measured by diff size after FF... so minimizing that is always good.  Which makes me a little bit concerned, for instance, about entirely rewriting the dbusmenu collector instead of messaging it.
[16:22] <tedg> massage
[16:22] <desrt> tedg: i could see your point there
[16:22] <desrt> tedg: the two main problems are impedence mismatches
[16:22] <desrt> but we could try harder to overcome them
[16:23] <desrt> 1) you have one instance of the dbusmenu collector that has an internal hashtable of dbusmenu clients.  we'd need to move to a system where we have many collectors, each one corresponding to an endpoint
[16:24] <desrt> 2) you rip through the dbusmenu structure on every single search, constructing items for search results
[16:24] <desrt> whereas the new code builds the items in advance
[16:24] <tedg> I'm saying that things can't, or shouldn't change, but we need to take into account release cycles as well.  This is the beauty of time-based releases :-)
[16:24] <tedg> I'm not saying...
[16:25]  * tedg needs to type a bit better today.
[16:28] <desrt> tedg: so what of your plans to move the hud-service into the panel service via the appmenu indicator?
[16:28] <desrt> that's a pretty major change
[16:28] <desrt> but we still need to do that...
[16:29] <tedg> desrt, Well, yes, and I'm worried about that... but, it was a smaller change when the only thing hud-service did was get a name and instantiate an object ;-)
[16:29] <desrt> it may be low in terms of diff count (probably mostly build system changes, in fact) but in terms of the architecture it's actually quite huge
[16:29] <desrt> tedg: smaller in lines of diff, yes
[16:30] <desrt> in terms of impact?  definitely not.
[16:31] <tedg> Well, the question was then whether the backends could be consolidated.  And I'm not sure that's entirely worthwhile for dbusmenu at this point.  Too much change.
[16:31] <tedg> So we'd end up with two copies in the same process... which sucks, but isn't the end of the world.
[16:32] <desrt> i think i agree with your reasoning
[16:32] <desrt> but it means more work for me now
[16:33] <desrt> tedg: so for both dbusmenu and gmenumodel the biggest advantage will come from being able to share the clients
[16:33] <desrt> and that hasn't changed with what i've done
[16:34] <desrt> merging the processes would be convenient, but disruptive
[16:34] <desrt> which is why i was surprised you hadn't done it already if it was your plan for LTS
[16:34] <tedg> desrt, Sure, but for instance, GMenuModel could share clients and Dbusmenu could not for a cycle.
[16:34] <desrt> tedg: hmm
[16:35] <desrt> tedg: so i'm a big fan of memory managed operating systems with preemptive multitasking
[16:35] <desrt> if i screw something up in the hud service rewrite, the hud service crashes
[16:35] <tedg> But, we could, for instance, just hack GMenuModel in indicator-appmenu.so and avoid the integration issue.  Which is looking attractive.
[16:35] <desrt> it doesn't take the entire panel service with it
[16:35] <tedg> Exactly.  I agree.
[16:36] <tedg> And dbus-activation restarts it transparently :-)
[16:36] <desrt> exactly
[16:36] <desrt> okay.
[16:36] <desrt> so let's just do this new plan, then
[16:36] <desrt> and make the argument for the hud changes along these lines:
[16:36] <desrt> the patch is really big, but
[16:36] <desrt> a) it's well-documented
[16:37] <desrt> b) it's in a separate process, so even if things go very wrong, it's isolated
[16:37] <desrt> c) it's relatively self-contained functionality that can easily be tested
[16:39] <tedg> desrt, We can also put it in a PPA and do a call for testing.
[17:38] <didrocks> have a good night everyone, /me goes to do a bzr talk
[18:15] <dobey> hi bryceh
[18:18] <bryceh> hi dobey
[18:21] <dobey> bryceh: do you know who is upstream for libpixman? i am hitting a very weird memory corruption issue inside it. http://pastebin.ubuntu.com/863846/ installing some more debug packages right now and trying to get a more lengthy backtrace
[18:28] <bryceh> dobey, yeah Søren Sandmann works on it mostly.  I think bugs can be filed at bugs.freedesktop.org.
[18:28] <bryceh> dobey, mailing list seems active too - http://lists.freedesktop.org/archives/pixman/2012-February/thread.html
[18:28] <dobey> ah ok
[18:52] <Sweetshark> pitti: I have a new libreoffice upload on chinstrap for sponsoring. I will test verify some issues with it tomorrow, but then it is ready to go.
[18:53] <Sweetshark> (unless didrocks wants to upload again to be able to say nice things about me on application)
[21:57] <seb128> RAOF, hey
[21:57] <RAOF> seb128: Good morning!
[21:57] <seb128> RAOF, good evening! ;-)
[21:57] <seb128> how are you?
[21:58] <RAOF> A little bit tired from the morning's running, but recovering ;)
[21:58] <seb128> ;-)
[21:58] <seb128> RAOF, so that g-s-d issue the other day I blamed on the barrier, I blame it again on you :p
[21:58] <seb128> RAOF, rye just got it
[21:59] <seb128> RAOF, I think the g-s-d stuff it's a red-herring, it hits that bug because xorg goes away under its feet
[21:59] <RAOF> The
[21:59]  * rye is here
[21:59] <RAOF> Quite possibly.
[21:59] <RAOF> I don't suppose there's an apport backtrace?
[21:59] <seb128> RAOF, no ... http://paste.ubuntu.com/864207/ is a log
[22:00] <seb128> it's weird, I wonder what does those
[22:00] <RAOF> 'cause my xserver hasn't crashed, outside of my own stupidity, for quite some time :)
[22:00] <seb128> ******************* START ********************************
[22:00] <seb128> Frame: ...
[22:00] <seb128> Frame: ...
[22:00] <seb128> it's a weird format
[22:00] <seb128> but you can see that other stuff hit the same error than gsd Mar  1 23:46:04 delorean pulseaudio[6711]: [pulseaudio] client-conf-x11.c: xcb_connection_has_error() returned true
[22:01] <seb128> RAOF, where it gets weird is that rye says that xorg just exited 0
[22:01] <seb128> well maybe not 0
 seb128, yes, the server unloaded everything and went away politely
 [  7400.340] Server terminated successfully (0). Closing log file.
[22:01] <seb128> RAOF, how can that happen? any clue?
[22:01] <seb128> oh
[22:01] <RAOF> That happens when something tells the X server to stop, and it does.
[22:01] <seb128> I'm being stupid
[22:01] <seb128> that would be because gnome-session exited
[22:02] <seb128> RAOF, back on my side :p
[22:02] <RAOF> :P
[22:02] <seb128> now I wonder what does this "******************* START ********************************" and prevent apport to catch the gnome-session issue
[22:02] <rye> my $DISPLAY changed to :1.0, why?
[22:03] <rye> and by the way, having Xorg logs contain the actual date/time and not the offset from start may be a bit helpful :)
[22:03] <seb128> gnome-session/gdm-signal-handler.c:                syslog (LOG_CRIT, "******************* START ********************************");
[22:03] <seb128> crap, gnome-session is the one preventing apport
[22:03] <seb128> rye, do you hit the bug often ?
[22:03] <seb128> putting a gdb on gnome-session in a vt might be useful if you do ;-)
[22:03] <rye> seb128, today - first time
[22:04] <seb128> with gnome-session-dbgsym installed
[22:04] <seb128> ok :-(
[22:06] <rye> seb128, actually g-s-d crash report was generated a second after these gnome-session lines appeared in syslog
[22:06] <seb128> rye, right, I'm sure it's just a side effect of the session closing under its feet
[22:06] <seb128> rye, but thanks that's valuable info
[22:07] <RAOF> rye: I actually find having precisely the same timestamps as dmesg extremely valuable :)
[22:07] <rye> gnome-session/gdm-signal-handler.c:
[22:07] <seb128> rye, <seb128> gnome-session/gdm-signal-handler.c:                syslog (LOG_CRIT, "******************* START ********************************");
[22:08] <seb128> rye, said that 4 minutes ago ;-)
[22:08] <rye> seb128, yeah, sorry :)
[22:10] <seb128> RAOF, do you have any time today to look at the gtk2-sharp ftfbs?
[22:10] <seb128> RAOF, it should be easy, seems like a missing -l... somewhere
[22:10] <seb128> likely a pkg-config call missing a lib
[22:10] <RAOF> Yeah, it should be easy.  I'll do that right now.
[22:10] <seb128> RAOF, I uploaded it to drop the gtk2 grip patch and I got ftbfs emails in return :p
[22:11] <RAOF> Oh, the gtk2 grip patch has gone away?
[22:11] <seb128> RAOF, yes
[22:11] <RAOF> gtk2 will no longer have grips unless explicitly asked for?  Yay!
[22:11] <seb128> ;-)
[22:12] <seb128> RAOF, when designed asked to drop it I didn't argue ;-)
[22:13] <RAOF> :)
[22:13] <seb128> it's going to solve some annoying issue with libreoffice and other applications
[22:14] <rye> seb128, do you want me to update the bug report with this "backtrace" ?
[22:15] <seb128> rye, please do
[22:15] <desrt> seb128: i've added appindicator support and pushed
[22:16] <desrt> a dbusmenu bug is currently ruining my day quite a lot
[22:16] <desrt> the existing hud service is affected by it, but not quite as badly
[22:17] <seb128> desrt, src/hud-service.c:287: undefined reference to `hud_app_indicator_source_new'
[22:17] <seb128> ?
[22:17] <desrt> seb128: blame maintainer mode
[22:17] <seb128> ok :p
[22:17] <desrt> seb128: autogen again should fix that
[22:21] <seb128> desrt, it's only hud-service which changed right?
[22:21] <seb128> i.e just copying that binary should be enough?
[22:21] <desrt> yes.
[22:21] <desrt> i'm limiting my changes to that, for sake of sanity
[22:22] <seb128> desrt, doesn't work :-(
[22:22] <desrt> yuck
[22:22] <desrt> in what way is it failing?
[22:22] <seb128> it doesn't list anything from remmina or bluetooh-applet menus
[22:22] <seb128> I've tried with "Blue", nothing listed
[22:23] <desrt> seb128: prefixing is broken, rmeember
[22:23] <seb128> desrt, yes, the bluetooth indicator has "Bluetooth Settings..."
[22:23] <seb128> it's an entry
[22:23] <seb128> not the title
[22:23] <desrt> hum.  and that's not working?
[22:23] <seb128> no
[22:23] <desrt> can it find network names from the nm-applet?
[22:24] <desrt> that's what i tested locally
[22:26] <seb128> desrt, no
[22:26] <TheMuso> /c/c
[22:26] <desrt> you're sure you restarted it?
[22:27] <seb128> desrt, weird, it works after restarting the service
[22:27] <seb128> desrt, I try in new session
[22:28] <seb128> desrt, would it pick up indicators starting after it?
[22:28] <seb128> desrt, seems racy on session login
[22:28] <desrt> seb128: i bet you were accidentally running the old one from before i added the support :p
[22:28] <desrt> seb128: ah yes..  indeed.
[22:28] <seb128> desrt, no, I tried restarting the session 3 times
[22:28] <desrt> this is the exact problem i'm discussing with ted
[22:28] <desrt> why does the hud service get activated at login, though?
[22:28] <seb128> desrt, it doesn't work on fresh sessions, it works if the hud is restarted after indicators are loaded
[22:28] <seb128> desrt, dbus activation by unity?
[22:28] <desrt> seb128: afaik, should only happen when a query is done
[22:29] <seb128> ok, dunno then
[22:29] <desrt> tedg: is it expected that unity should activate the hud service on login?
[22:29] <desrt> seb128: anyway.. the race thing is a known issue
[22:29] <tedg> desrt, No, it doesn't.
[22:29] <seb128> desrt, ok, it works then ;-)
[22:29] <desrt> seb128: the hud-service-starts-on-login thing is a bug, apparently
[22:31] <seb128> desrt, ok, well that's what was leading to the appindicators not working for me
[22:31] <seb128> I will report it later
[22:31] <desrt> same here, unfortunately
[22:31] <seb128> desrt, otherwise I confirm it works if started later
[22:32] <desrt> so the major features are done
[22:32] <desrt> i have 6 outstanding items
[22:33] <seb128> desrt, does that include the bug we just discussed?
[22:33] <desrt> prefixing the indicator names, disabled/hidden items, about-to-show, understanding the advanced dbusmenu attributes some indicators use, bringing back usage tracking and getting to the bottom of this strange race
[22:33] <seb128> or 6 items and bugs?
[22:33] <seb128> sounds about right
[22:33] <desrt> sounds doable by monday
[22:34] <seb128> great
[22:38] <desrt> http://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal
[22:38] <desrt> this is awesome
[22:39] <desrt> you know you're doing something write if someone writes a petition against you :p
[22:39] <desrt> *right
[22:42] <jbicha> desrt: https://plus.google.com/115547683951727699051/posts/LAHHLsz8RTv
[22:42] <desrt> the original one is funnier :)
[22:43] <jbicha> https://plus.google.com/115547683951727699051
[22:43] <desrt> particularly because i'm not sure if it was intended to be funny or not
[22:43] <desrt> and i suspect not
[22:43] <desrt> which, of course, makes it even funnnier
[22:43] <jbicha> oops, this link: https://plus.google.com/115547683951727699051/posts/A1Uc39BB7CC
[22:45] <seb128> jbicha, hey
[22:46] <seb128> jbicha, I looked at g-c-c,gnome-bluetooth
[22:46] <seb128> jbicha, the issue is not Bsymbolic, dunno what it is
[22:46] <seb128> jbicha, the soname and api changes seems a bit of work also, the lib has quite some rdepends, did you check if they need lot of changes?
[22:47] <seb128> jbicha, not sure it's worth it, is there anything great in the new version? seems mostly api cleaning and dbus-glib ->gdbus
[22:47] <jbicha> seb128: I don't even have bluetooth on this computer so it doesn't matter much to me
[22:47] <seb128> ok
[22:48] <seb128> I might look at it again tomorrow or next week
[22:48] <seb128> but it seems work over what it's worth to me
[22:48] <seb128> especially that I've no clue about the gobject property stuff
[22:52] <seb128> robert_ancell, hey
[22:52] <seb128> robert_ancell, who works for me as well btw (just as a piece of info)
[22:55] <robert_ancell> seb128, cool
[22:55] <robert_ancell> seb128, yeah, *no idea* why this would have fixed it, but I'll be happy if it has...
[22:55] <seb128> yeah, me neither...
[23:17] <desrt> seb128: can you do another test for me?
[23:17] <seb128> desrt, yes
[23:17] <desrt> the race problem should be gone now
[23:17] <desrt> hopefully...
[23:26] <seb128> desrt, no, sorry...
[23:27] <desrt> :(
[23:27] <seb128> still the same, new sessions don't list those
[23:27] <seb128> restarting the service does
[23:27] <desrt> very odd.
[23:27] <desrt> try this:
[23:27] <desrt> killall nm-applet; nm-applet
[23:27] <desrt> then search for networks
[23:30] <desrt> seb128: i think i'm going to need to start doing what you're doing
[23:30] <desrt> to test properly
[23:31] <seb128> desrt, it works when doing that
[23:31] <seb128> so maybe that bug is different
[23:31] <desrt> seb128: so that's an improvement, at least
[23:31] <seb128> well no sorry
[23:31] <seb128> it's stucked at session start
[23:31] <seb128> if I restart the service it works
[23:31] <seb128> then if I stop indicator restart them it's picking the changes in all cases
[23:32] <desrt> huh
[23:32] <desrt> what if you restart the unity panel service without restarting the hud?
[23:32] <desrt> maybe that's the one that's off...
[23:33]  * desrt was noticing some odd behaviour there
[23:33] <seb128> desrt, no difference
[23:34] <desrt> as in, restarting the unity panel service causes the appindicators to not be visible?
[23:34] <seb128> sorry, I tried a new session, got the issue, restarted the panel, still buggy
[23:34] <desrt> right.  that sounds correct.
[23:34] <desrt> so i think the problem is this:
[23:34] <desrt> hudappindicatorsource-WARNING **: GetApplications returned an error: Timeout was reached
[23:35] <desrt> is that in your xsession-errors?
[23:38] <seb128> desrt, http://pastebin.ubuntu.com/864307/
[23:38] <seb128> that's my .xsession-errors
[23:38] <seb128> not there
[23:38] <desrt> no GetApplications complaint
[23:39] <desrt> i wonder why i see that problem here...
[23:39] <seb128> desrt, ignore the nmapplet error, it's a guest session and it doesn't work here
[23:40] <seb128> desrt, btw same issue if I start a gnome classic session and run "unity" there
[23:40] <desrt> i think i found the problem
[23:40] <desrt> GLib-GIO-WARNING **: Type of return value is incorrect, got `()', expected `(a(sisossssss))'
[23:40] <seb128> so it's not strictly session race
[23:40] <desrt> indicator-application bug
[23:41] <seb128> desrt, I don't see that here?
[23:42] <desrt> seb128: i think i may be seeing a different bug than you because i'm in gnome-shell and there are no indicators running :)
[23:42] <desrt> either way i'd like to figure it out
[23:42] <seb128> desrt, did you try to start a guest session?
[23:42] <desrt> no.
[23:42] <desrt> i don't have it installed in /usr
[23:43] <seb128> you should, at least to see if you confirm
[23:43] <desrt> shame ted has gone for the night
[23:43] <seb128> install it in /usr/local?
[23:43] <seb128> then rm /usr/local
[23:43] <desrt> there's a very obvious gvariant bug in indicator-application
[23:43] <desrt> seb128: nah.  i can just copy it into /usr
[23:43] <desrt> it's only one file
[23:43] <seb128> desrt, ok
[23:44] <desrt> okay.  guesting it up
[23:45] <desrt> yup.  i have the problem as well
[23:46] <desrt> i'm sure i'll be able to track this down
[23:46] <seb128> desrt, ok, I'm off for the night then
[23:46] <desrt> i should go home as well
[23:46] <desrt> thanks for the help today
[23:46] <seb128> desrt, have a good evening!
[23:46] <seb128> you're welcome
[23:46] <desrt> ta
[23:46] <seb128> see you tomorrow ;-)
[23:46] <desrt> for sure