[05:09] <pitti> Good morning
[05:12] <cyphermox> morning pitti
[05:13] <cyphermox> good night :)
[05:17] <pitti> cyphermox: sleep well!
[05:32] <rickspencer3> pitti, what's the word on the street for Beta 2?
[05:33] <pitti> rickspencer3: lots of fixes got wrapped into last night's rebuild; so now we're waiting for tests
[05:33] <rickspencer3> pitti, were all the fixes for bugs found in testing?
[05:34] <pitti> rickspencer3: yes, looks like it
[05:34] <rickspencer3> interesting
[05:34] <pitti> many were in armel, maas (brand new on server), ltsp, etc.
[05:34] <rickspencer3> ok, thanks pitti
[05:35] <pitti> and some in ubiquity itself
[05:45] <didrocks> good morning
[05:46] <pitti> hey didrocks
[05:46] <pitti> TheMuso: good morning, how are you?
[05:47] <pitti> TheMuso: still online by any chance?
[05:47] <TheMuso> pitti: Just. What can I do for you?
[05:47] <didrocks> guten morgen pitti!
[05:48] <pitti> TheMuso: it seems a lucid->precise upgrade is rather insistant on keeping at-spi instead of replacing it with libatk-adaptor
[05:48] <pitti> TheMuso: so my question is, would it be technically correct to say that libatk-adaptor provides: at-spi?
[05:48] <TheMuso> Interesting. I haven't seen any bugs filed as such...
[05:48] <pitti> TheMuso: i. e. do they provide the same functionality and perhaps APIs?
[05:48] <pitti> TheMuso: I just filed bug 966845
[05:48] <ubot2> Launchpad bug 966845 in update-manager "lucid->precise upgrade wants to remove ubuntu-desktop" [High,In progress] https://launchpad.net/bugs/966845
[05:49] <TheMuso> pitti: It provides the same functionality in that it is a GTK module so that GTK a11y is exposed via dbus to at-spi2.
[05:49] <pitti> TheMuso: it's detected by the auto-dist-upgrade tester
[05:49] <TheMuso> at-spi also provides a GTK module for atk to do the same thing.
[05:49] <TheMuso> s/atk/gtk./
[05:49] <pitti> TheMuso: before it didn't get that far because of other upgrade path failures which we fixed until yesterday
[05:49] <TheMuso> SO yes, same functionality, no in terms of API, as the only binary code in there is a GTK module.
[05:49] <TheMuso> Right.
[05:50] <TheMuso> So yes, I guess we can set up libatk-adaptor to provide at-spi.
[05:50] <pitti> TheMuso: there are still programs in precise which depend on at-spi, such as gok
[05:50]  * TheMuso nods,.
[05:50] <pitti> TheMuso: would these break if the real at-spi  suddenly disappears?
[05:50] <TheMuso> Yes, since they use CORBA.
[05:51] <pitti> TheMuso: looks like the other rdepends are just python-pyatspi
[05:51] <TheMuso> Right.
[05:52] <pitti> which has a versioned dependency, and thus won't strictly be broken by a Provides:
[05:52] <TheMuso> Right.
[05:52] <pitti> TheMuso: does gok have a replacement which works with the at-spi2 stack?
[05:52] <TheMuso> pitti: The only replacement I know of is still under development and not yet recommended for general use.
[05:53] <TheMuso> karibu or some such, can't remember how its spelt atm.
[05:53] <pitti> hm, it's also holding back python-pyatspi2 in favor of keeping python-pyatspi
[05:53] <pitti> TheMuso: caribou, yes
[05:53] <TheMuso> right, not far off the mark. :)
[05:54] <pitti> TheMuso: so, that puts us in a difficult position -- we need at-spi2 for most stuff, but we need to keep at-spi for gok, but you can't install them at the same time
[05:54] <TheMuso> pitti: Well python-pyatspi2 does provide python-pyatspi in a technical sense, as afaik the API is exactly the same.
[05:54] <pitti> TheMuso: oh, that helps indeed
[05:54] <TheMuso> pitti: Right. IMO we dump gok completely.
[05:55] <TheMuso> We still support lucid on teh desktop for another year, and hopefully by then, caribou will be good enough for general use.
[05:56] <pitti> TheMuso: ah, so would you mind filing a removal bug for gok? better if it comes from someone who actually knows this
[05:57] <TheMuso> pitti: Can do that tomorrow, unless you feel its time critical, in which case I can do it now.
[05:57] <pitti> ah, gok has always been in universe
[05:57] <pitti> TheMuso: nah, that's fine
[05:59] <TheMuso> Ok will take care of that tomorrow, and will get patches ready for the at-spi2 packages, we are currently synced with debian in terms of the at-spi2 stack, so will get the changes included there also.
[05:59] <pitti> TheMuso: ok, I'll do an upload with the two new Provides: then, if it's alright with you?
[05:59] <TheMuso> oh sure go ahead.
[06:00] <rickspencer3> TheMuso, hey, someone reported some accessibility related bugs yesterday, is there a way I should tag them or such so that the accessibility team sees them?
[06:00] <pitti> TheMuso: oh, if you want to do that in Debian, then please do that
[06:00] <TheMuso> rickspencer3: Are they filed against the appropriate packages?
[06:00] <TheMuso> pitti: Feel free to upload, but I'll get them into debian too.
[06:00] <TheMuso> rickspencer3: tag them a11y as well.
[06:00] <rickspencer3> TheMuso, I believe they are filed correctly
[06:00] <TheMuso> searching for bugs with the a11y tag will show all a11y bugs.
[06:01] <TheMuso> rickspencer3: Ok.
[06:01] <rickspencer3> thanks TheMuso, I'll add the tags
[06:01] <TheMuso> np
[06:01] <pitti> TheMuso: there ought to be a 2.4.0 upgrade anyway, corresponding to the GNOME 3.4 release?
[06:01] <TheMuso> pitti: There is, its in debian, my plan was to sync it post beta.
[06:01] <pitti> nice
[06:01] <TheMuso> s/was/is/
[06:02] <pitti> TheMuso: ok, so if you are fine with this, I'll assign that bug to you?
[06:02] <pitti> can't  upload now anyway due to the freeze
[06:02] <TheMuso> Sure, np.
[06:02] <pitti> I added a summary to the bug
[06:02] <pitti> TheMuso: done, thanks
[06:02] <pitti> TheMuso: and good night!
[06:16] <pitti> didrocks: so it seems that unity workaround reset quite a bit more than just the plugin list? this morning I re-instated launcher autohide, keybindings, FFM, etc.
[06:16] <didrocks> pitti: in fact, it can be a side effect
[06:16] <pitti> anyway, as long as it also covered the important bit, good enough
[06:17] <didrocks> pitti: meaning, the side effect will be to reset everything you changed since the last time you changed the session
[06:17] <pitti> ah
[06:17] <didrocks> (to another compiz session)
[06:17] <didrocks> compiz is doing that:
[06:17] <didrocks> -> you reset the plugin list in /apps/compiz-1
[06:17] <didrocks> if you do nothing, then, nothing load
[06:17] <didrocks> (because you don't have a plugin list)
[06:18] <didrocks> so, you need to force "switching to a new profile"
[06:18] <didrocks> -> I set the "foo" profile
[06:18] <didrocks> then, compiz load
[06:18] <didrocks> see that the current profile should be unity
[06:18] <pitti> ah, settings are per-profile
[06:18] <didrocks> and copy /apps/compizconfig-1/profiles/unity back to /apps/compiz-1
[06:18] <didrocks> (so, you didn't get the copy of /apps/compiz-1 to /apps/compizconfig-1/profiles/unity before)
[06:19] <didrocks> that's why you can loose those settings
[06:19] <didrocks> in case you didn't know, the gconf backend is funny:
[06:19] <didrocks> let's say, you are on an existing profile "default" and go to the profile "unity"
[06:19] <pitti> keeps me trained where to change stuff :)
[06:20] <didrocks> is takes /apps/compiz-1, copy all keys to /apps/compizconfig-1/profiles/default
[06:20] <didrocks> then take /apps/compizconfig-1/profiles/unity and copy it back to /apps/compiz-1
[06:20] <didrocks> and finally set a *!schema!* in /apps/compizconfig-1/ to current_profile -> unity
[06:20] <didrocks> do not wonder why you have a lot of writings on profile change :)
[07:37] <chrisccoulson> good morning
[07:46] <didrocks> hey chrisccoulson, how are you?
[07:47] <chrisccoulson> hi didrocks, i'm good thanks. how are you?
[07:47] <didrocks> tkamppeter: I assigned you bug #857663 for reviewing as you are probably the best person to look if the backport of the fix is needed/correct :)
[07:47] <ubot2> Launchpad bug 857663 in cups "cups crashes on SIGHUP if printer classes are defined" [Undecided,New] https://launchpad.net/bugs/857663
[07:47] <didrocks> I'm fine thanks ;)
[07:51] <glatzor> hello mvo
[07:52] <glatzor> mvo, I am currently working on an lp#899001
[07:53] <glatzor> mvo, it seems that there is a bug in python-apt detecting multi arch. apt_pkg.config.value_list["APT::Architectures"] returns an empty list. Also the option is set if apt-config dump is called
[07:53] <mvo> glatzor: its a bug in apt
[07:53] <mvo> glatzor: there is a apt_pkg.get_architectures() call that you can use
[07:53] <mvo> glatzor: that will return the native arch first and the foreign ones as the subsequent ones
[07:54] <mvo> glatzor: alternatively you could skip packages with ":" in the apt cache in the first search pass
[07:58] <pitti> hey mvo, guten MOrgen
[08:00] <mvo> hey pitti, guten morgen
[08:05] <seb128> hey
[08:07] <pitti> a Seb!
[08:07] <pitti> *hug*
[08:07] <seb128> hey pitti, wie geht's?
[08:07] <pitti> gut, danke!
[08:08] <pitti> we could use some help with testing current ISOs (respun last night), so if anyone feels like it..
[08:11] <Sweetshark> Goooood morning!
[08:11] <seb128> pitti, I might have a try later on by my installs are not useful usually they are on the most tested ones (i.e i386 desktop CD)
[08:12] <pitti> hey Sweetshark
[08:12] <seb128> I don't have the bandwith and disk space to store dvd images
[08:12] <pitti> seb128: we only have 1/6 tests for desktop i386 ATM
[08:12] <seb128> pitti, ok, will do some extra ones for it then
[08:13]  * pitti downloads the amd64 DVD
[08:13] <pitti> yeah, but at least 1.5 GB is a lot better than the 4.5 we used to have
[08:15] <glatzor> mvo, please see bug 966916/
[08:15] <ubot2> Launchpad bug 966916 in python-apt "Doesn't detect multi arch setups correctly" [Undecided,New] https://launchpad.net/bugs/966916
[08:15] <glatzor> mvo, please see bug 966916
[08:15] <Sweetshark> pitti: to reiterate from yesterday: to simulate a "do-release-upgrade -d" with a ppa as close as possible, do a) add the ppa b) manually tweak the apt sources to precise c) apt-get dist-upgrade
[08:15] <Sweetshark> right?
[08:15] <pitti> Sweetshark: sounds about right
[08:15] <pitti> Sweetshark: mvo might know how to include the PPA in a do-release-upgrade run
[08:15] <mvo> glatzor: oh, awsome
[08:18] <mvo> Sweetshark: you can add [Sources]\nAllowThirdParty=True to /etc/update-manager/release-upgrades.d/foo.cfg
[08:18] <Sweetshark> mvo: cool thanks!
[08:19] <Sweetshark> mvo: I like that better than an "almost, but not quite like" dist-upgrade to see if I killed the bug.
[08:19] <mvo> glatzor: commited
[08:23] <mvo> glatzor: so that means that now cache["apt:amd64"] works as well
[09:00] <trijntje> ping pitti, could you take a look at bug 957746 ?
[09:00] <ubot2> Launchpad bug 957746 in ubuntu-defaults-builder "ubuntu-defaults-builder: setting language does not take effect" [Undecided,New] https://launchpad.net/bugs/957746
[09:01] <pitti> trijntje: probably a bug in gfxboot or otherwise, but I can reproduce locally and check with Colin
[09:03] <Sweetshark> jibel, pitti: bug 916291 just changed to "Fix commited"
[09:03] <ubot2> Launchpad bug 916291 in libreoffice "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [Critical,Fix committed] https://launchpad.net/bugs/916291
[09:03] <pitti> \o/
[09:03] <pitti> thanks Sweetshark
[09:03]  * Sweetshark takes a deep breath.
[09:03] <pitti> Sweetshark: so again, if you want to upload now, please upload to precise-proposed
[09:03] <pitti> then it can already build now
[09:03] <Sweetshark> jibel: testing most appreciated.
[09:04] <pitti> the auto upgrade tests will test it as soon as it's in the archive
[09:04] <Sweetshark> pitti: k, I wonder if we should wait for 3.5.2 though. rc2 is already tagged.
[09:05] <pitti> Sweetshark: if it's more than two days away, I'd say upload it now
[09:05] <Sweetshark> OTOH there is nothing like a bit of good old builder hugging ...
[09:05] <pitti> it breaks pretty much every oneiric upgrade
[09:06] <Sweetshark> pitti: it might be. and if we want to have exactly the same tarballs as debian there might be another day of delay just for that.
[09:07] <Sweetshark> jibel: Could you give that bugfix a testrun? instructions are in the bug.
[09:08] <trijntje> pitti: thanks! The easiest way is probably to build the example package, since the bug also occurs there
[09:09] <jibel> Sweetshark, sure, I can do that this afternoon
[09:09] <jibel> ... if there is no respin of Beta 2 :)
[09:09] <Sweetshark> pitti: btw who do I need to take hostage on UDS to get more discspace on the ppas? LibreOffice fails on a lot of those bc of that. Thats also something that is driving ricotz nuts, I guess.
[09:10] <Sweetshark> jibel: thanks a lot, that is awesome.
[09:10]  * Sweetshark goes hunting for more dupes of 916291.
[09:11] <pitti> Sweetshark: hm, RT ticket I'd sayy
[09:11] <Sweetshark> pitti: omg!1!!
[09:14] <Sweetshark> pitti: fwiw I already talked to some guys on IRC (lamont for example IIRC), but all I got was unhelpful 'make your package smaller' replies -- or at least the problem isnt fixed. Thats were the evil hostage-taking plan for UDS comes from.
[09:15] <pitti> heh
[09:15] <pitti> perhaps try bribing them with beer first?
[09:16]  * Sweetshark likes the fact that the libreoffice bug list is lead by two 'critical/fix commited' bugs.
[09:16] <Sweetshark> pitti: we are talking libreoffice here. needs stronger booze.
[09:46] <Sweetshark> pitti: Ok, I wait until jibel confirms the fix this afternoon and will put a build in proposed then.
[09:46] <pitti> Sweetshark: cool, thanks
[09:47] <BigWhale> pitti, thanks for the resolution of this https://bugzilla.gnome.org/show_bug.cgi?id=672030
[09:47] <ubot2> Gnome bug 672030 in libgnome-desktop "gnome-settings-daemon always prevents suspend on macbookpro5,3" [Normal,Resolved: notgnome]
[09:47] <pitti> BigWhale: not uploaded yet, but in bzr
[09:47] <pitti> de rien!
[09:47] <BigWhale> pitti, I was about to do some testing and writing patches today. I guess not. :)
[10:00] <dholbach> did anyone of you have any problems with having multiple keyboard layouts on the same machine and switching between them?
[10:00] <pitti> I have three, and switching works fine
[10:01] <pitti> (us, de, us Dvorak)
[10:01] <dholbach> hum, ok - are there any g/dconf keys I could reset to try setting it up from scratch to see if I can get it back to working?
[10:02] <pitti> gsettings reset org.gnome.libgnomekbd.keyboard layouts
[10:02] <pitti> dholbach: control-center's keyboard capplet controls this, might be easier there
[10:02] <pitti> org.gnome.libgnomekbd.keyboard layouts ['us', 'de\tnodeadkeys', 'us\tdvorak']
[10:02] <pitti> that's how it looks like for me; what is it for you?
[10:03] <dholbach> alrightie - I'll let you know if I can get it back to work - it's my girlfriend's laptop: Norwegian and German I think
[10:03] <pitti> dholbach: xprop -root _XKB_RULES_NAMES
[10:03] <pitti> dholbach: that's what's actually in the X server
[10:04] <pitti> it shoudl be a combination of that gsetting and /etc/default/keyboard
[10:05] <dholbach> pitti, how do I update /etc/default/keyboard? manually?
[10:05] <pitti> dholbach: there might be some dpkg-reconfigure thing, but usually it's set by the installer
[10:05] <pitti> we don't have an "apply system-wide" button for that yet
[10:05] <dholbach> ah ok
[10:06] <dholbach> _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "no", "", ""      --    but in /etc/default/keyboard it's XKBLAYOUT="de"
[10:07] <dholbach> the norwegian layout does not seem to work at all
[10:07] <pitti> what does gsettings say?
[10:09] <dholbach> pitti, layouts [], model , options []
[10:09] <dholbach> all empty
[10:10] <pitti> dholbach: hm, did you choose the layout in lightdm perhaps?
[10:10] <dholbach> I can't quite remember - my girlfriend seems to have a tried a number of options
[10:10] <pitti> dholbach: env | pastebinit -
[10:11] <dholbach> http://paste.ubuntu.com/903661
[10:12] <pitti> hm, no layout there
[10:12] <pitti> so it looks something picks it from the locale, or some other magic method I'm not aware of
[10:12] <dholbach> in the keyboard capplet there is just "Norwegian" now
[10:18] <tkamppeter> didrocks, thanks. I think the fix should be done and should not cause problems. It is a backport from newer versions of CUPS and later releases of Ubuntu never caused the same complaint. Also it seems that the CUPS features of printer classes is broken by the bug. I recommend to issue an SRU for CUPS on Lucid.
[10:19] <didrocks> tkamppeter: can you handle it, please? :)
[10:19] <glatzor> mvo, could you please have a look at https://code.launchpad.net/~aptdaemon-developers/sessioninstaller/multiarch/+merge/99693
[10:20] <glatzor> mvo, furthermore I have added some sanity checks to InstallPackageNames (introducing a new error dialog - which would require a string freeze exception)
[10:21] <glatzor> mvo, you can find those in trunk
[10:26] <dholbach> pitti, I can't get it to work - I readded the layout, added a new one, removed it again and now it shows ["no"] as layouts, still it's the German layout
[10:27] <dholbach> I could try editing /etc/default/keyboard
[10:27] <pitti> dholbach: what does xprop say?
[10:27] <dholbach> "evdev", "pc105", "no", "", ""
[10:29] <pitti> hm, that's about everythign you can ask from settings-daemon
[10:30] <dholbach> ok, I'll update etc/default/keyboard and restart and see what happens
[10:31] <pitti> dholbach: at this point I'm afraid you need to bother the X.org guys :/ no idea
[10:31] <pitti> dholbach: what does "doesn't work" mean exactly? i. e. what kind of breakage?
[10:31] <dholbach> it is the German layout it's using
[10:31] <dholbach> not the Norwegian one
[10:33] <dholbach> ok, I'll go and ask in #ubuntu-x
[10:40] <tkamppeter> didrocks, no problem.
[10:40] <seb128> dholbach, does it work if you set fr and de?
[10:40] <seb128> dholbach, i.e is that no specific?
[10:40] <didrocks> tkamppeter: thanks :)
[10:42] <dholbach> seb128, do I need to restart my session for it to have an effect? it seems like changing it does have no effect at all
[10:42] <dholbach> → french does not work
[10:42] <seb128> dholbach, how do you change it?
[10:43] <seb128> indicator menu? keybinding?
[10:43] <dholbach> in the keyboard capplet
[10:43] <seb128> dholbach, hum, can you try with the indicator?
[10:44] <dholbach> seb128, no effect
[10:44] <seb128> dholbach, does "setkxbmap no" works?
[10:45] <dholbach> hum
[10:45] <dholbach> where do I get the command from?
[10:46] <dholbach> x11-xkb-utils is installed
[10:46] <dholbach> hum hum
[10:47] <dholbach> nevermind
[10:47] <dholbach> seb128, that makes it work
[10:47] <dholbach> let me restart the session to see if it sticks
[10:47] <dholbach> and then readd German to see if switching between the two works
[10:48] <dholbach> no, after restarting the session the setting is gone again
[10:52] <seb128> dholbach, right, setkxbmap is only for the running session, it doesn't change any setting
[10:52] <seb128> but it suggests the issue is not xorg
[10:52] <dholbach> aha
[10:52] <seb128> it's g-s-d
[10:52] <seb128> I've a similar bug on my session in fact
[10:52] <seb128> but I never bothered debugging it
[10:52] <seb128> the keymap is always french
[10:52] <seb128> whatever i pick in the indicator
[10:52] <dholbach> is there any way how I can clear out whatever old settings there is to "start from scratch" and see if I can reproduce the issue?
[10:53] <dholbach> :-/
[10:54] <seb128> dholbach, try to gsettings reset org.gnome.libgnomekbd.keyboard
[10:55] <seb128> hum
[10:56] <seb128> hum
[10:56] <seb128> no, ctrl-W doesn't delete words in xchat-gnome :p
[10:56] <seb128> dholbach, reset-recursively rather
[10:56] <seb128> gsettings reset-recursively org.gnome.libgnomekbd.keyboard
[10:56] <dholbach> alright
[10:56] <seb128> gsettings reset-recursively org.gnome.libgnomekbd.desktop
[10:56] <seb128> could be useful as well
[10:57] <ritz> seb128, I believe, gtk does have emac binding support
[10:57] <seb128> ritz, right
[10:58] <dholbach> seb128, no dice :/
[10:59] <dholbach> interestingly enough lightdm still shows "no" in the upper right corner and the capplet still lists "Norwegian"
[10:59] <seb128> dholbach, reset org.gnome.desktop.a11y.keyboard maybe
[10:59] <seb128> org.gnome.settings-daemon.plugins.keyboard
[11:00] <seb128> trying all the keyboard stuff :p
[11:01] <dholbach> nope, still doesn't work
[11:02] <seb128> dunno then
[11:02] <seb128> g-s-d is a piece of crap :p
[11:05] <ogra_> seb128, ++
[11:12] <dholbach> ok, so it seems whatever I change changes XKB_RULES_NAMES and updates dconf keys accordingly - it just has no effect on the actual keymap being used
[11:12] <dholbach> it sticks to German (for whatever reason)
[11:13] <dholbach> if I file a bug about that, where do I file it?
[11:13] <dholbach> seb128, pitti: ^
[11:13] <dholbach> it annoys my girlfriend to no end :)
[11:15] <dholbach> seb128, ^ just imagine you would have to use a German keyboard all the time :-P
[11:21] <chrisccoulson> heh, i'm sure if seb128 had his way, we would ship with only support for french keyboard layout ;)
[11:22] <dholbach> I'll file it on g-s-d for now and reassign if necessary
[11:23] <seb128> dholbach, ok
[11:24] <seb128> dholbach, you can probably add an autostart which do the setxkbmap call if she only wants to use no
[11:24] <seb128> dholbach, as a workaround
[11:25] <dholbach> yes
[11:25] <dholbach> seb128, pitti: any info missing on https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/967034?
[11:25] <ubot2> Launchpad bug 967034 in gnome-settings-daemon "Updating keymap information does have no effect" [Undecided,New]
[11:26] <seb128> dholbach, no, as said I've the bug on my account so I can probably get the infos I need, debug it there
[11:26] <dholbach> ok
[11:26] <seb128> out of the fact that keyboard stuff are harder than they should and I've little clue about them to debug ;-)
[11:29] <dholbach> thanks everyone for helping debug it
[11:30] <dholbach> I added an autostart bit for now
[11:57] <pitti> re
[11:58] <seb128> pitti, wb
[11:58] <pitti> dholbach: thanks, looks complete enough to reproduce
[11:58] <pitti> seb128: FYI, please don't restart the retracer again, I just got it to fail on the bug I want to fix
[11:59] <seb128> pitti, ok
[12:01] <rodrigo_> hi
[12:02] <rodrigo_> in the last few days, when updating from http://es.archive.ubuntu.com/ubuntu/ oneiric-updates/main, I get packages that are not signed
[12:02] <rodrigo_> has the .es server been hacked?
[12:02] <rodrigo_> or just missing signatures? :D
[12:26] <trijntje> pitti: Am I using the wrong commands to build the image? I describe the commands I use in the original bug description of bug 957746
[12:26] <ubot2> Launchpad bug 957746 in ubuntu-defaults-builder "ubuntu-defaults-builder: setting language does not take effect" [Undecided,New] https://launchpad.net/bugs/957746
[12:27] <pitti> trijntje: that's what I'm using as well; currently building an image for -nl
[12:28] <pitti> trijntje: and will then follow up to the bug
[12:28] <pitti> trijntje: did you check the language in gfxboot?
[12:28] <pitti> trijntje: and the locale?
[12:28] <pitti> (locale in the live session, I mean)
[12:28] <pitti> trijntje: and did you install the nl langpacks, too?
[12:31] <trijntje> pitti: I did check the language in the live environment in the 'language selector'
[12:31] <trijntje> I don't know what 'gfxboot' is so I didnt check that.
[12:32] <pitti> trijntje: if you press a key at the very beginning, when you see the "human = keyboard" graphic
[12:33] <pitti> trijntje: all ubuntu-defaults-image can do is to set the default there, and from there it'll be taken to the live system
[12:33] <pitti> trijntje: my NL cd finished building, and it's correct in gfxboot
[12:34] <pitti> and the live system is in Dutch
[12:35] <trijntje> pitti: I use unetbootin to put the iso on a usb, since vbox keeps crashing here. Could that be the cause?
[12:37] <pitti> trijntje: followed up to the bug
[12:37] <pitti> trijntje: that shouldn't be it really, as long as it boots
[12:37] <pitti> I just used kvm -m 1024 -vga std -cdrom binary-hybrid.iso
[12:38] <Riddell> no images listed for testing http://iso.qa.ubuntu.com/qatracker/milestones/210/builds/14369/downloads
[12:49] <trijntje> pitti: It looks like the problem is caused by unetbootin, when I use the kvm command you provided I do get a localised live environment
[13:47]  * mterry waves good morning to this unusually quiet channel!  :)
[13:50] <cyphermox> hey mterry
[13:51] <seb128> hey mterry, cyphermox!
[13:52] <seb128> mterry, do you miss the noise? ;-)
[13:52] <seb128> or rather the vibrant activity of desktopers arguing over bugs ;-)
[13:53] <mterry> :)
[13:53] <mterry> Just wanted to make sure some disaster didn't befall Europe or something while I wasn't paying attention
[13:54] <pitti> quiet == good; being stuck for two hours in dissecting nested EBRs from the bug that seb128 handed me :)
[13:55] <kenvandine> it has been very quiet :)
[13:56] <seb128> pitti, no need to thanks me, it's my please :p
[13:56] <seb128> hey kenvandine
[13:57] <jibel> Sweetshark, I finished the upgrade test with the ppa enabled
[13:57] <jibel> Sweetshark, not only the system upgraded successfully to Precise but libreoffice even starts when I click on the launcher ;)
[13:57] <Sweetshark> jibel: soo ... did it work?
[13:57] <jibel> Sweetshark, congrats!
[13:57] <pitti> \o/
[13:57] <pitti> jibel: merci
[13:57] <Sweetshark> \o/ \o/
[13:57] <pitti> Sweetshark: upload! upload! upload!
[13:57] <Sweetshark> jibel: big thanks indeed!
[13:58] <Sweetshark> pitti: hrhr
[13:58] <pitti> look at all these empty builders yearning for something to do
[14:18] <seb128> ricotz, there?
[14:19] <seb128> desrt, do you run gnome-keyring 3.4 (the gnome3 ppa version)?
[14:19] <desrt> i have gnome3 ppa, yes
[14:20] <seb128> desrt, can you run seahorse for me and see if you have the expender sign showing up next to the login keyring?
[14:21] <desrt> seb128: it seems that it just shows that keyring by default
[14:21] <seb128> desrt, is there an expender in the name column?
[14:21] <desrt> no
[14:21] <seb128> desrt, can you change themes and back?
[14:21] <desrt> on the view menu there is a new option 'by keyring'
[14:21] <desrt> that cause a sidebar to pop up
[14:21] <seb128> desrt, pick anything, an a11y theme if you want
[14:22] <seb128> desrt, then back to the one you use
[14:22] <seb128> desrt, does it make an expender sign be displayed?
[14:22] <desrt> no..
[14:22] <seb128> ok :-(
[14:22] <desrt> on a call right now.  we'll talk in a bit.
[14:23] <seb128> desrt, ok, ping me back
[14:28] <seb128> desrt, unping, I managed to run the new seahorse with some dpkg-deb -x and LD_LIBRARY_PATH, they list all items in a flat list
[14:28] <dupondje> Empathy removes profiles that are not supported? Cause telepathy-haze was removed, installed it again, but MSN accounts are gone :(
[14:29] <seb128> desrt, it doesn't help me for bug #963862
[14:29] <ubot2> Launchpad bug 963862 in seahorse "The keyring "login" doesn't display any keys or saved passwords." [High,Confirmed] https://launchpad.net/bugs/963862
[14:30] <seb128> i.e https://launchpadlibrarian.net/98029912/seahorse.png should have ">" in the column
[14:30] <seb128> that broke between gtk 3.3.18 and .20, the expender is only shown after a theme change
[14:30] <desrt> seb128: off
[14:31] <desrt> seb128: http://imgur.com/wdiya
[14:31] <seb128> desrt, yeah, doesn't help me, but thanks
[14:32] <desrt> seb128: upgrade to new seahorse :D
[14:32] <seb128> desrt, https://launchpadlibrarian.net/98029912/seahorse.png should have a > next to keyring
[14:32] <mdeslaur> ugh, seahorse is a mess in precise :(
[14:32] <desrt> seb128: ya.. i downgraded and was able to see your problem
[14:32] <seb128> desrt, well, still gtk 18 -> 20 broke working software so I want to figure if that's a gtk regression there
[14:33] <desrt> seb128: probably is... but keep in mind "lortie's law"
[14:33] <desrt> benjamin has been being rather aggressive about that lately
[14:33] <seb128> desrt, you should also run the last version of everything? :-)
[14:33] <desrt> seb128: hum?
[14:33] <seb128> desrt, "lortie's law"
[14:33] <desrt> no
[14:33] <seb128> "if you are not running the last version it's your fault" ;-)
[14:34] <desrt> how did he word it...
[14:34] <desrt> " 'it used to not crash' is no excuse "
[14:34] <desrt> he came up with it after i pushed that change to glib that caused all gtk programs to crash
[14:34] <desrt> and refused to revert it
[14:34] <desrt> ie: if you (as a user of my library) are doing stupid things, then i won't hesitate to break you with changes to my library
[14:35] <seb128> desrt, right, which is why I'm trying to figure now if seahorse was doing something stupid
[14:38] <desrt> seb128: is there a reason you didn't upgrade seahorse?
[14:39] <seb128> desrt, it depends on the new gnome-keyring
[14:39] <desrt> ah
[14:39] <desrt> dare i ask...? :)
[14:39] <desrt> i only mention it because the new UI actually looks really nice
[14:39] <seb128> desrt, it was separate in several sources and stefw admitted the fallback mode could be broken since there was quite some refactoring and he mostly tested shell integration
[14:40] <seb128> desrt, if you ask why we didn't update gnome-keyring
[14:40] <desrt> right... gcr came in this cycle
[14:40] <seb128> desrt, i.e seemed like work with regression potential for no real win
[14:40] <desrt> makes sense
[14:40] <desrt> it's _really_ late now, in any case
[14:40] <desrt> pitti would have a heart attack :)
[14:40] <pitti> well, there were several actual regressions, and a major rewrite
[14:40] <seb128> yeah, and this expender bug is not worth the update :p
[14:41] <seb128> especially that it could well be a gtk issue
[14:41] <pitti> so, mostly LTS conservatism
[14:41]  * desrt has always _always_ been on the other side of that argument
[14:43] <pitti> yay, 3.4 released \o/
[14:44] <dupondje> damn, still can't maximize remmina desktops on seconds screen in unity :(
[14:44] <dupondje> to bad
[14:44] <desrt> 'apt-get install valac' -> you end up with valac-0.14
[14:44] <desrt> we should fix that now that 0.16.0 is out?
[14:46] <desrt> pitti: seems that you touched it last
[14:47] <pitti> if we test that all reverse build deps actually build and work with 0.16, sure
[14:47] <desrt> 'valac' has rdeps? :(
[14:48] <desrt> huh.  it does have a few.
[14:49] <seb128> desrt, well "reverse *build* deps" for sure
[14:49] <seb128> desrt, everything which checks for valac in its configure
[14:49] <desrt> seb128: you'd expect dependencies on specific vala packages, though
[14:49] <desrt> like valac-0.14 or 0.16 explicitly
[14:49] <seb128> desrt, that doesn't work when configure checks for "valac"
[14:49] <seb128> which most do
[14:50] <desrt> ya.  that's actually a bit of a disaster
[14:50] <desrt> because if you want to build both a valac-0.14 program and a valac-0.16 one, you're in trouble
[14:50] <seb128> tell me, I keep changing alternatives :p
[14:50] <pitti> most packages do build on valac-X.Y
[14:51] <desrt> seb128: correct fix there i guess is to set VALAC environment variable before calling configure
[14:51] <pitti> but many don't, for example activity-log-manager, colord, simple-scan, etc.
[14:51] <desrt> ie: tweak the packaging
[14:51] <desrt> really automake should be clever enough to see if a package is requesting version 0.16 it should try 'valac-0.16' first
[14:52] <mbiebl> or even better, valac doesn't break existing sources with each new release :-)
[14:53] <desrt> that's not really possible
[14:55] <pitti> it's still a relatively young language, so in some cases breaking old weird stuff is certainly acceptable IMHO
[14:55] <mbiebl> desrt: build-depening on valac-$ver is painful though
[14:55] <mbiebl> as you have to touch a lot of packages each new release
[14:56] <mbiebl> pitti: nod, especially the dbus-glib → gdbus switch
[14:56] <mbiebl> but most of the software I tested with 0.14 compiled fine against 0.16
[14:57] <pitti> yeah, the 0.10 -> 0.12 switch seemed much rougher
[14:58] <tkamppeter> pitti, didrocks, I have prepared an SRU for bug 857663. Please approve it.
[14:58] <mbiebl> you are going to ship with 4 different vala versions in precise?
[14:58] <ubot2> Launchpad bug 857663 in cups "cups crashes on SIGHUP if printer classes are defined" [High,Fix committed] https://launchpad.net/bugs/857663
[14:58] <didrocks> tkamppeter: I'm not in the SRU team :)
[14:59] <pitti> tkamppeter: thanks! will have a look at the queue, just not right now
[15:40] <seb128> desrt, it is a gtk bug :p
[15:40] <desrt> figures
[15:40] <desrt> seb128: got a patch?
[15:41] <seb128> desrt, Company knows what's wrong and is doing one as we write
[15:41] <seb128> desrt, cf #gtk+
[15:41] <seb128> desrt, he said it's quite obvious now that I pointed the commit and a description of the issue
[15:41] <desrt> great
[15:41] <desrt> maybe we'll have a .0.1 or a .1 soon
[15:42] <seb128> desrt, yeah, it's not a blocker bug and we should get .1 in precise
[15:42] <seb128> desrt, though I'm not sure we will get gtk .1 before SRU
[15:42] <desrt> too bad.  was hoping for the last-minute gnome-keyring bump :)
[15:42] <desrt> seb128: SRU?  you mean freeze?
[15:42] <desrt> oh.  i understand.
[15:43] <seb128> desrt, GNOME 3.4.1 is 4 days after the hard freeze, it should be ok to wave in obvious bug fixes but gtk tends to not be "obvious" to test
[15:47] <seb128> Trevinho, hey
[15:47] <Trevinho> hi seb128
[15:48] <seb128> Trevinho, I reassigned bug #967197 to unity, could be bamf ... do you know if that's a known issue? I noticed here as well that pinning things to the launcher tend to make bamf unhappy (they stop showing as running and to be listed in alt-tab)
[15:48] <ubot2> Launchpad bug 967197 in unity "Gedit Unity Launcher Inconsistency " [Undecided,New] https://launchpad.net/bugs/967197
[15:48] <seb128> Trevinho, i.e https://launchpadlibrarian.net/98681056/hiddeninlauncher.png
[15:49]  * Trevinho looking
[15:51] <seb128> pitti, https://mail.gnome.org/archives/desktop-devel-list/2012-March/msg00092.html
[15:51] <pitti> seb128: yep, saw; thanks
[15:51] <seb128> pitti, not sure if,where I should forward it
[15:53] <seb128> pitti, I guess .1 makes it challenging to sneak it, same as this cycle
[15:53] <seb128> i.e ideally one week earlier would work better for us
[15:56] <Trevinho> seb128: I've tried, but I can't reproduce it here...
[15:56] <Trevinho> can you?
[15:56] <Trevinho> anyway it looks like it could be a bamf / unity interaction issue
[15:57] <seb128> Trevinho, I need to try but I don't want to screw my session now
[15:57] <seb128> tr
[15:57] <seb128> Trevinho, but it happens regularly here, at least I had it often when pinning a .local custom desktop I made
[15:57] <seb128> let me try in a guest session
[16:00] <pitti> good night everyone!
[16:02] <seb128> 'night pitti
[16:02] <seb128> Trevinho, ok, got it
[16:03] <seb128> Trevinho, I did a bit of playing with running gedit from the dash, right click on it to lock it, close it, run it again from the dash, close it, unpin
[16:03] <seb128> not sure in what order it took like 5 cycles or pin,unpin,run,close
[16:03] <seb128> Trevinho, I had gdb attached to bamf it didn't exit
[16:03] <seb128> Trevinho, is there any other info that would be useful?
[16:03] <Trevinho> seb128: maybe it could just be an unity isssue btw
[16:04] <Trevinho> seb128: if you can check with d-feet or mdbus2 or something like that if the application is on the bamf bus...
[16:04] <seb128> Trevinho, can I check on d-feet the bamf status?
[16:04] <seb128> ok
[16:04] <Trevinho> i.e. you have to ensure that one of the opened applications is nautilus
[16:05] <Trevinho> s/nautilus/gedit/
[16:06] <seb128> Trevinho, so yeah, it has an application group on d-feet
[16:06] <seb128> with is-running = 1
[16:07] <seb128> the name, .desktop are correct
[16:07] <seb128> so unity side bug?
[16:07] <Trevinho> mh, ok... so I'm thinking that maybe we're ignoring it on unity due to a missing object-parameter unsetting
[16:07] <Trevinho> seb128: yes, it could... Or libbamf, but it looks more unity related
[16:08] <seb128> Trevinho, is there any extra info I can provide? I can get those bugs relatively easily so I could run a debug version with printfs or something if required
[16:10] <Trevinho> seb128: I was looking at it...
[16:10] <seb128> Trevinho, ok, no hurry, if you feel like fixing it and need info just ping me
[16:10] <seb128> no need to be today ;-)
[16:12] <Trevinho> seb128: if you want to try, just grep the unity src for "unity-seen" and disable the related checks...
[16:12] <Trevinho> Then maybe you'll have duplicated icons, but at least we can see if they are there or not..
[16:13] <seb128> ok, I will give that a try
[16:13] <seb128> thanks, I will let you know how it goes
[16:29] <BigWhale> Greetings everyone
[17:03] <didrocks> have a good evening everyone!
[20:27]  * slangasek waves
[20:28] <seb128> hey slangasek
[20:28] <seb128> desrt, there?
[20:28] <slangasek> ok, so assuming 15 bookmarks is a reasonable number to have, what else could explain why firefox is eating my CPU whenever the hud looks at it?
[20:28] <seb128> we got bugs like bug #965493
[20:28] <ubot2> Launchpad bug 965493 in unity "cpu race between nautilus, hud- and unity-service" [High,Triaged] https://launchpad.net/bugs/965493
[20:28] <chrisccoulson> slangasek, i can't answer that until i actually see what it's doing :)
[20:29] <slangasek> chrisccoulson: you want a backtrace of FF then, I guess?
[20:29] <seb128> so maybe it's similar
[20:29] <chrisccoulson> yes please
[20:29] <slangasek> chrisccoulson: would a large number of windows perhaps contribute to this?
[20:29] <slangasek> I know I'm atypical in that I keep lots of windows open with fairly few tabs in each
[20:29] <slangasek> ok, let's see - how do I trigger hud-service to run again?
[20:29] <seb128> slangasek, it does it alone as soon as you focus something
[20:30] <seb128> or hit tab
[20:30] <slangasek> not consistently for me
[20:30] <seb128> well something = firefox
[20:30] <seb128> otherwise you need to open the hud ui, i.e tap alt
[20:30] <slangasek> yes, none of these things consistently cause the CPU spin
[20:30] <slangasek> i.e., if hud-service starts at all on window focus or tapalt, it does its thing quickly and exits again
[20:31] <seb128> which suggests it's not the bookmarks bug, that's a constant one
[20:31] <seb128> I think it's similar to the bug I pointed before
[20:31] <seb128> it seems there are some cases which create activity loops or something
[20:31] <slangasek> bug #965493?
[20:31] <ubot2> Launchpad bug 965493 in unity "cpu race between nautilus, hud- and unity-service" [High,Triaged] https://launchpad.net/bugs/965493
[20:31] <seb128> that's why I wanted desrt around, but seems he's not there
[20:31] <seb128> slangasek, yes
[20:31] <slangasek> ok
[20:31] <seb128> I saw a few similar looking bugs
[20:32] <slangasek> I'll wait until I reproduce it by accident again
[20:32] <slangasek> shouldn't have to wait more than 10 minutes
[20:32] <seb128> desrt, ^ when you are around can you give some hints on what infos would be useful to debug hud spinning cpu bugs?
[20:32] <seb128> desrt, seems we got a few of those, slangasek gets one (under unity-2d, maybe 2d is misbehaving somewhat)
[20:33] <seb128> slangasek, but did you try 3d recently to see how wakeups are there? they should have improvements quite a bit in 5.8 (current precise version)
[20:33] <slangasek> no, haven't tried
[20:34] <seb128> ok
[20:35] <slangasek> chrisccoulson: what style of backtrace would you like?  'thread apply all bt full' is a bit daunting to cut and paste :)
[20:36] <chrisccoulson> slangasek, yeah, i should only need the main thread
[20:40] <slangasek> chrisccoulson: ok, backtrace sent to the bug
[20:42] <chrisccoulson> slangasek, that shows exactly the same problem as bug 801699 (ie, dbusmenu_menuitem_find_id is slow to find menuitems)
[20:42] <ubot2> Launchpad bug 801699 in dbusmenu "DBus menu is very slow when using large menu" [Medium,Triaged] https://launchpad.net/bugs/801699
[20:43] <slangasek> ok, but that doesn't really explain why I'm seeing it worse than most people, yes?
[20:43] <slangasek> I mean, this isn't a trivial slowdown
[20:44] <slangasek> this is firefox hammering the CPU at 100% until I kill hud-service
[20:44] <chrisccoulson> slangasek, oh, people who see the problem at all will see it pretty bad
[20:44] <slangasek> why am I in the "at all" set? :-)
[20:45] <chrisccoulson> slangasek, it should only happen with large menus though, and the trace there suggests that there are menus nested at least 4 levels deep
[20:45] <chrisccoulson> are you sure you don't have lots of bookmarks? :)
[20:45] <chrisccoulson> perhaps you could look at the output of dbus-menu-dumper from libdbusmenu-tools?
[20:46] <slangasek> well, I don't have a lot of bookmarks *that I've created*
[20:47] <slangasek> I do have a nested menu of Bookmarks Toolbar -> Smart Bookmarks -> Most Visited -> stuff
[20:47] <slangasek> is that part of the default bookmark set these days?  Should I consider axing it?
[20:48] <chrisccoulson> slangasek, yeah, those have gone now. are there a lot of entries in there?
[20:48] <slangasek> sure
[20:48] <chrisccoulson> oh, hang on
[20:48] <chrisccoulson> i might be thinking of the wrong ones
[20:48] <chrisccoulson> hmmm
[20:49] <chrisccoulson> i have Most Visited, but it doesn't have many entries in it
[20:52] <slangasek> so I've nuked the 'smart bookmarks' now since I don't use it
[20:53] <slangasek> however, this seems to have resulted in all of my submenus being unavailable :-)
[21:58] <cyphermox> seb128: took a while, but I got the indicator patch fixed for vino
[21:59] <seb128> cyphermox, great!