[00:11] <chrisccoulson> seb128 - it seems that the issue with my FN+F8 keys not working on my laptop is a BIOS issue
[00:11] <chrisccoulson> and a deliberate one by dell ;)
[00:11] <chrisccoulson> so, you might want to remember that if you ever consider updating your BIOS
[00:13] <seb128> chrisccoulson, ok thanks
[00:14] <seb128> chrisccoulson, I read the comment this afternoon saying it was a win7 thing
[00:14] <chrisccoulson> seb128 - yeah, it sucks
[00:14] <chrisccoulson> i suppose i'll just have to put up with the keys not working, and complain to dell
[00:15] <chrisccoulson> they could have implemented the win 7 behaviour with a driver rather than screwing it up on all platforms really
[00:15] <seb128> yeah
[00:16] <mdeslaur> chrisccoulson: what did FN+F8 do?
[00:16] <chrisccoulson> mdeslaur, it switches video modes on most laptops
[00:16] <mdeslaur> chrisccoulson: ah! my thinkpad is FN+f7
[00:17] <mdeslaur> chrisccoulson: that used to be implemented in hardware on your laptop?
[00:17] <chrisccoulson> but dell have re-mapped that key combination in their newer BIOSes to produce the same scancodes as pressing Super+P
[00:17] <mdeslaur> ugh
[00:17] <mdeslaur> wth didn't they just do that with a driver
[00:18] <chrisccoulson> they use the new key combination in win 7 to open a display settings dialog rather than flipping video modes
[00:18] <chrisccoulson> it seems weird to change that in the BIOS though
[00:18] <mdeslaur> chrisccoulson: did they break winxp/vista by doing that?
[00:19] <mdeslaur> what a weird thing to do
[00:21] <chrisccoulson> mdeslaur, the new behaviour is specific to win 7
[00:21] <chrisccoulson> but https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/539477/comments/12 explains why it affects lucid too
[00:22] <mdeslaur> chrisccoulson: ah! that makes sense
[00:22] <mdeslaur> huh, interesting
[00:41] <chrisccoulson> is apport attaching crash files to bug reports now?
[00:46] <RAOF> chrisccoulson: I *think* so.
[00:46] <chrisccoulson> RAOF - ah, i wasn't aware of that. i've been deleting them ;)
[00:47] <chrisccoulson> thinking that users were attaching them manually...
[00:47] <RAOF> You mean .crash files?  No, those would be manual.  But I think apport is now actually attaching the files that it's meant to be attaching :)
[00:51] <chrisccoulson> RAOF - i was actually referring to the .crash files
[00:51] <chrisccoulson> it seems that those are now automatically added too
[00:52] <chrisccoulson> eg, bug 544687
[00:54] <RAOF> Hm.
[00:55] <RAOF> I wonder why apport is attaching that?
[00:55] <seb128> chrisccoulson, I doubt it does or that's a bug
[00:55] <seb128> that's not wanted for sure
[00:55] <chrisccoulson> seb128 - it's being added to all new crash reports today
[00:56] <seb128> it's a bug for pitti
[00:56] <chrisccoulson> ok, i'll ping him in the morning
[00:56] <chrisccoulson> (if he hasn't already seen the scrollback by then)
[06:44] <RAOF> Gah.  Evolution and firefox are fighting over which process should have the highest resident size.
[06:54] <pitti> Good morning
[07:21] <didrocks> good morning pitti
[07:21] <pitti> bonjour didrocks!
[07:21] <pitti> how are you this morning?
[07:23] <didrocks> pitti: I'm fine, thanks. Ready for a not so crazy day, I hope :)
[07:23] <didrocks> and you?
[07:27] <pitti> didrocks: still a bit tired, but alright; today I really feel my muscles :)
[07:28]  * pitti feels like a 70 year old
[07:29] <didrocks> due to yesterday Taekwondo?
[07:38] <pitti> didrocks: no, still from Sunday's training camp
[07:38] <pitti> I usually feel it most two days after
[07:38] <pitti> didrocks: (sorry, I'm not ignoring you, I just was stuck a bit in mutt)
[07:39] <didrocks> pitti: no pb, I'm back to gconftool's mess :)
[07:40] <pitti> didrocks: are you using fork(), setgid(), setuid() now?
[07:40] <didrocks> pitti: I'm trying to use Also note that modifying the environment from the child setup function may not have the intended effect, since it will get overridden by a non-NULL env argument to the g_spawn... functions.
[07:40] <didrocks> oupss, wrong paste :)
[07:40] <didrocks> I'm trying to use the definition of that ^ ;) (GSpawnChildSetupFunc)
[07:40] <didrocks> which is a parameter from g_spawn_…
[07:41] <didrocks> should do it, just have to find some code example
[07:45] <baptistemm> hello
[07:57] <didrocks> baptistemm: hey o/
[07:57] <baptistemm> salut didrocks
[07:58] <didrocks> pitti: ok, got it. Last thing to find is why gconftool-2 --direct -g /desktop/gnome/sound/event_sounds --config-source "xml:readwrite:/var/lib/gdm/.gconf" returns me a different value from gconftool-2 -g /desktop/gnome/sound/event_sounds even after shutting down the daemon (under the gdm user of course)
[08:02] <pitti> didrocks: oh, why do you have to specify --config-source explicitly?
[08:02] <didrocks> pitti: it's compulsory with --direct
[08:02] <pitti> didrocks: and if you have to, why don't you have to do it with -g as well?
[08:02] <pitti> didrocks: ah, I see
[08:02] <baptistemm> hi pitti
[08:02] <didrocks> I guess there is something in the gdm default path which could interfere
[08:03] <didrocks> ahah, we user .gconf.path to include defaults
[08:03] <didrocks> user*
[08:03] <didrocks> use*
[08:03] <didrocks> :)
[08:03] <didrocks> which has a higher priority than $(HOME)/.gconf
[08:14] <pitti> didrocks: that sounds like a bug?
[08:14] <pitti> (the priority)
[08:15] <didrocks> pitti: we put the mandatory and default in this path file. My guess is that we should rather use $(HOME)/.gconf.path.defaults and $(HOME)/.gconf.path.mandatory
[08:15] <didrocks> (see /usr/share/gconf/default.path)
[08:18] <pitti> didrocks: i. e. should /var/lib/gdm/.gconf.path have /var/lib/gdm/.gconf as well?
[08:19] <didrocks> pitti: we can either do that, or not using .gconf.path and split the values between $(HOME)/.gconf.path.defaults and $(HOME)/.gconf.path.mandatory
[08:19] <pitti> but both of those are shipped in .debs, thus they shouldn't be writable
[08:21] <didrocks> pitti: right, user/sysadmin shouldn't touch them
[08:21] <didrocks> pitti: so, I add at the right place /var/lib/gdm/.gconf to /var/lib/gdm/.gconf.path for you?
[08:22] <mvo> ccheney: hello! any news re OOo upload to fix #516727 ?
[08:22] <pitti> didrocks: "for me"? :-)
[08:22] <pitti> didrocks: I'm not that familiar with gconf source configuration, you know much more about it
[08:22] <didrocks> pitti: "in your opinion", that's a French bad translation :)
[08:22] <pitti> didrocks: but it sounds pplausible to me
[08:23] <didrocks> can do that, it's easy
[08:23] <pitti> /var/lib/gdm/.gconf should override /var/lib/.gconf.defaults
[08:23] <didrocks> right
[08:23] <didrocks> but not the mandatory settings
[08:23] <pitti> right
[08:25] <didrocks> ok, it's working ;) that was the last strange remaining thing \o/
[08:25] <didrocks> hey mvo
[08:25] <pitti> didrocks: sweet!
[08:25] <pitti> mvo: guten Morgen!
[08:28] <glatzor> morning Pitti and mvo
[08:28] <mvo> hey didrocks, pitti, glatzor
[08:28] <pitti> glatzor: hallo!
[08:28] <mvo> good morning
[08:32] <glatzor> mvo, I looked at the debconf forwarding issue once again
[08:33] <glatzor> mvo, see lp:~aptdaemon-developers/aptdaemon/fix-455861
[08:34] <glatzor> mvo, it is possible to delay a new connection attemp by just returning True from the accept_connection method. I lowered the priority of the accept_connection callback compared to the io handlers
[08:40] <mvo> glatzor: oh, cool! I check it out. I would really like to write a test-case for this, but I'm not sure how to simulate it properly
[08:40] <mvo> hey seb128! have you noticed that gnome-menus FTBFS ?
[08:42] <seb128> hello mvo, yes I got emails about that but I didn't look at it yet, I will do that today if you don't beat me to it
[08:42] <seb128> brb session restart after daily updates
[08:44] <RAOF> Good morning didrocks!
[08:45] <didrocks> RAOF: good morning!
[08:46] <seb128> re
[08:47] <seb128> mvo, did you look at the issue yet?
[08:47] <seb128> mvo, I uploaded your gtk patch yesterday btw
[08:47] <mvo> seb128: I think it may be a missing b-d
[08:48] <mvo> seb128: let me test-build w
[08:48] <seb128> mvo, don't bother, I will have a look now, I've some experience with gir builds by now
[08:48] <mvo> seb128: I have a test-version now running in pbuilder
[08:49] <mvo> seb128: it may just be a missing b-d on git1.0-glib-2.0
[08:49] <seb128> mvo, ok thank you!
[08:49] <seb128> pitti, hey
[08:49] <mvo> np, I let you know if it was it
[08:49] <mvo> seb128: I only care because it shows up in red in my upgrade test output ;)
[08:49] <seb128> pitti, did you made apport add .crash to bugs on purpose or is that a bug?
[08:49] <seb128> mvo, oh it does?
[08:49] <mvo> seb128: well, because gnome-menu is not build
[08:49] <seb128> mvo, the current version is not installable?
[08:50] <pitti> seb128: I saw the scrollback; I didn't, looks like a recent LP change; filed as bug 544843
[08:50] <mvo> seb128: its the fix you did with the file-overwrite
[08:50] <seb128> pitti, thank you!
[08:50] <pitti> de rien
[08:50] <seb128> mvo, oh right
[08:50] <mvo> seb128: that is in ubuntu3 but because of the ftbfs its not inthe archive yet
[08:50] <seb128> mvo, ok, let me know how test build goes, I will do an upload today anyway to fix another issue
[08:50] <mvo> seb128: (thanks for this btw and THANKS for the gtk patch !)
[08:50] <RAOF> didrocks: How's UNE going?  From the lucid-bugs wiki page it looks like it's going ok.  I've been busy (and will likely remain busy) with other things; do you need more help with UNE?
[08:50] <seb128> pitti, any objection to drop the icon translation from the cache? ie have the non translated value listed
[08:51] <mvo> seb128: ok, should I just commit to bzr then and wait for this upload? or upload anyway? (either way is fine for me)
[08:51] <pitti> seb128: no, not at all; I'm not even sure why we translate  it at all
[08:51] <seb128> mvo, thank YOU for the patch, I just reviewed and uploaded ;-)
[08:51] <seb128> pitti, ok good, I will fix that today
[08:51] <seb128> mvo, commit to bzr I will do some other changes in a few minutes
[08:51] <pitti> seb128: oh, thanks! (otherwise I can do it later today)
[08:51] <mvo> :) tiny tiny patch, need to buy beer for upstream to accept it
[08:51] <seb128> pitti, np
[08:51]  * pitti currently knee-deep in g-s-d keyboard code
[08:52] <seb128> pitti, good luck with that
[08:52] <mvo> brave man!
[08:52] <seb128> pitti, did you notice that usbmuxd + gvfs have upstream changes to fix the afc and gphoto double mount issue?
[08:52] <pitti> seb128: yes, I read it yesterday
[08:52] <pitti> I set the bug to "in progress" now, now high on my todo list
[08:53] <seb128> pitti, ok thanks
[08:55] <baptistemm> pitti, about apport API, do you know if usb_devices() fine works, because bug report (bug 544549 for instance) don't have it. Perhaps I'm not using it properly
[08:55] <mvo> seb128: commited (the gnome-menus fix)
[08:56] <pitti> baptistemm: this works fine here: python -c 'from apport.hookutils import *; print usb_devices()'
[08:56] <baptistemm> http://bazaar.launchpad.net/~bmillemathias/apport/bluez-support/annotate/head:/source_bluez.py
[08:56] <pitti> baptistemm: it's just a convenience wrapper for lsusb -v
[08:57] <baptistemm> ah so it doesn't attach the output automatically, I have to get the output and attach it
[08:57]  * seb128 hugs mvo
[08:57] <seb128> mvo, you rock, thanks!
[08:57] <didrocks> RAOF: I'm annoyed by one or two bugs that we should really fix, apart from that, the remaining one are just "good to fix", but not compulsory. So, it's mainly ok. But I'm busy with other things and also triage a big flow of UNE bugs report
[08:58] <seb128> RAOF, bryceh: is there an easy way to match gpu lock bugs to avoid filling duplicates?
[08:59] <seb128> ie to know if the lock bug I got is the same than one of those already opened
[08:59] <RAOF> seb128: It's not obvious , no.
[09:00] <RAOF> seb128: Part of the problem there is that the GPU dump we *get* is often that of a freshly-reset GPU
[09:00] <seb128> RAOF, also seems quite some of those are closed as false positives bugs, how do you detect if that's the case or a real issue?
[09:02] <RAOF> I haven't noticed a lot of bugs closed as false-positives, but there's an *awful* lot of bugs which are basically “Why are you presenting this error popup to me?"”
[09:03] <seb128> how do gpu locks look like usually?
[09:03] <seb128> basically what I did is suspend undocked and woke up docked with lid closed and external screen
[09:03] <seb128> which gives no active screen
[09:03] <seb128> at which point I did a switch to vt1 and back to vt7
[09:03] <seb128> which actives the display usually
[09:03] <seb128> and got the gdm screen
[09:04] <seb128> and after login I got a gpu lock apport bug and an xorg crash bug
[09:04] <seb128> I think the crash is what did send me back to gdm
[09:04] <RAOF> That's probably bug #535640; we've been duplicating a lot of gpu locks against that.
[09:04] <seb128> I'm not sure if the gpu lock bug is a real one and worth sending to launchpad
[09:05] <seb128> the crash is bug #447159
[09:05] <RAOF> Sarvatt's traced that back to a patch that we accidentally dropped in the .33 drm backport.
[09:06] <seb128> ah nice, so it's likely to be fixed before lucid?
[09:06] <RAOF> Yes.
[09:06] <seb128> good
[09:07] <seb128> did you ping any of the kernel team guys about it?
[09:07] <bryceh> yeah we're getting a lot more triggerings of the X freeze apport hook than we expected
[09:08] <seb128> I milestoned the crash I listed before btw
[09:08] <RAOF> Yes; smb's been pinged as our backup apw
[09:08] <seb128> it has over an hundred affected users
[09:08] <seb128> and is still happening on lucid
[09:08] <bryceh> at least, the good news is it's become tons easier for users to report these things compared with before
[09:09] <seb128> bryceh, RAOF: ok thanks
[09:09] <bryceh> indeed I've been wondering if we should shut off the apport hook, it's ruining our stats!  ;-)
[09:09] <RAOF> bryceh: Sarvatt & I have been bashing at that today; today's graph should look much better :)
[09:09] <seb128> well if you feel you collected enough bugs now you can probably turn it off
[09:09] <bryceh> RAOF, I think we need to figure out ways we can put in more heuristics so things automatically dupe
[09:09] <bryceh> RAOF, awesome
[09:10] <seb128> also you can make extra use of bug patterns to autoduplicate things
[09:10] <bryceh> seb128, yeah I think we'll discuss it at the desktop team meeting
[09:10] <Sarvatt> bryceh: can't think of how, i did over 40 there and its too random
[09:10] <RAOF> bryceh: Right.  That might work better with a .34 kernel, where we can guarantee that the gpu error log actually has the right state.
[09:10] <bryceh> Sarvatt, RAOF: Ooh, nice drop in the curve!  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
[09:11] <Sarvatt> the info i needed to dupe all of those was scattered in 6 or 7 different places
[09:11] <bryceh> Sarvatt, RAOF: well I'll leave it to your guys' judgment on if leaving the freeze apport hook might benefit us in gaining more interesting freeze bugs, or if at this point it just is gathering more and more dupes
[09:12] <bryceh> iirc we shut this stuff off at release anyway
[09:13] <RAOF> We might want to switch it off until the lid fix is back in; it seems that it requires nothing more than shutting the lid, which users do *all the time* :)
[09:14] <seb128> can you bug pattern this one in some way?
[09:15] <baptistemm> jcastro, ping me back when you're up, thanks :)
[09:15] <seb128> baptistemm, you should just ask your question so he can reply even if you are not there
[09:15] <RAOF> Possibly.  It'll be difficult to do something without false-positives.
[09:16] <bryceh> seb128, I suspect if we had enough understanding to craft a bug pattern, we'd know enough to amend the apport script to not file them in the first place
[09:16] <seb128> ok
[09:16] <RAOF> But I guess if the other option is to turn it off entirely, then hiding some bugs in false-positive duplicates wouldn't be too bad.
[09:17] <Sarvatt> oh man, opening your graph killed my system bryceh, lost a huge email I had typed up for kernel-team about drm bugs :( :(
[09:18] <RAOF> bryceh: We could possibly dupe based on the contents of IPEHR=0x01800020 in i915_error_state.
[09:18] <bryceh> Sarvatt, drat... sorry... hope your browser doesn't have a bug reading svg
[09:20] <glatzor> mvo, uh we have to be careful. debconf 1.5.29 breaks our forwarding
[09:20] <mvo> glatzor: uhh, how?
[09:20]  * RAOF → run
[09:20] <glatzor> mvo, it requires a read-write lock on the file based databases. which will fail for a non-root running debconf-communicate
[09:21] <seb128> RAOF, have fun, see you later
[09:21] <mvo> glatzor: sounds like we need to file a bug about that
[09:21] <mvo> glatzor: or at least get a --no-locking switch or something
[09:21] <glatzor> mvo, I was wondering why my debconf test scripts weren't working anymore on debian
[09:25] <Sarvatt> bryceh: I think they are a bad idea personally for most cases, *all* 965 reports were for the same hang, most Gxx ones were as well but the remaining ones didn't have enough info to consider it a dupe even though it had the same symptoms because they filed it after rebooting a few times. the 2 arrandale ones are upstreamable though
[09:26] <bryceh> Sarvatt, sorry, lost context.  "they" == svg graphs? bug patterns?
[09:27] <Sarvatt> in reference to <bryceh> [05:13:12] +Sarvatt, RAOF: well I'll leave it to your guys' judgment on if leaving the freeze apport hook might benefit us in gaining more interesting freeze bugs, or if at this point it just is gathering more and more dupes
[09:28] <Sarvatt> it did let us find that that patch was dropped from the kernel unknowingly though :)
[09:28] <bryceh> Sarvatt, ah you are in favor of turning the freeze handler off?
[09:30]  * bryceh waves to tseliot
[09:31] <seb128> mvo, bug #544890
[09:31] <seb128> mvo, not sure how,if you track those
[09:31] <mvo> glatzor: I would like to add  a "rebuild_apt_xapian_index" dbus handler into aptdaemon - or would you prefer to set this to a different daemon? ie apt-x-i itself or a s-c- daemon?
[09:31] <mvo> seb128: thanks, it seem to be pretty common
[09:31] <tseliot> hey bryceh
[09:31] <mvo> seb128: haha, that is a fun diff
[09:32] <seb128> mvo, that's the one I mentioned previous week, I got it on the mini which I use as a textbox, ie I'm sure I didn't change grub there
[09:32] <mvo> seb128: not sure about this one in particular, but grub conffiles
[09:32] <seb128> textbox -> testbox
[09:32] <mvo> seb128: ok
[09:32] <pitti> bryceh, Sarvatt: do you guys happen to know if this is valid?
[09:32] <pitti> (**) Option "xkb_layout" "us,de"
[09:32] <pitti> i. e. having multiple layouts in /etc/default/console-setup -> udev -> X
[09:32] <mvo> seb128: its odd, I do not see this one in my upgrade tests, but I suspect it might be something that d-i is doing to the file
[09:32]  * pitti tries to find out whether this is an udev rule, X, or libxklavier bug
[09:33] <seb128> mvo, context, I've 3 lucid installs on this machine
[09:33] <seb128> mvo, ie, I'm using the "make space and install lucid" ubiquity option
[09:33] <seb128> mvo, so it might do extra "detecting other oses and updating grub"
[09:33] <Sarvatt> sorry pitti, I'm not sure
[09:37] <Sarvatt> pitti: yep its valid
[09:37] <pitti> Sarvatt: xorg-server itself doesn't seem to parse it at all
[09:38] <glatzor> mvo, the post update script is not sufficient? Or do you want to replace it with a dbus call?
[09:38] <pitti> Sarvatt: out of interest, how did you determine that? reading libxkbsomething?
[09:39] <mvo> glatzor: I want to have a way in software-center to trigger a rebuild of the full apt-xapian-index if I notice that its outdated (apt cache and DB size do not match for example)
[09:39] <pitti> Sarvatt: I'm using http://paste.ubuntu.com/399784/ for testing
[09:40] <pitti> Sarvatt: (context: that's the format that the installer uses for non-latin keyboard layouts, since you always need a latin one for typing URLs, keyboard shortcuts, and the like)
[09:41] <glatzor> mvo, but which user should be allowed to rebuild the cache? allow all?
[09:43] <mvo> glatzor: my gut feeling is allow-admon without password
[09:44] <mvo> glatzor: admin group users, we could add a throttle to minimize abuse (e.g. not more often than every 5 min).
[09:44] <pitti> Sarvatt: oh, I know -- xkl_config_rec_get_from_server() just reads it from the root window property, and that seems ot be wrong:
[09:45] <pitti> _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "terminate:ctrl_alt_bksp,grp:shifts_toggle"
[09:45] <pitti> bryceh, Sarvatt: ^ do you know how this root prop is set?
[09:48] <bryceh> pitti, sorry no not offhand
[09:48] <pitti> it's still happening in an xterm session, so it's not g-s-d
[09:49] <pitti> bryceh: ok, thanks
[09:50] <pitti> ah, if I start raw X, it's correct
[09:50]  * pitti directs blame towards gdm
[09:50] <seb128> why does it always turns to be gdm being to blame? ;-)
[09:51] <pitti> it's the only thing between starting X and starting xterm which could modify _XKB_RULES_NAMES :)
[09:51] <seb128> right
[09:51] <seb128> just pointing it's too often buggy
[09:51] <pitti> tell me about it ..
[09:51] <seb128> it's just supposed to take your password and open your session
[09:52] <pitti> and both the backup property and the real property become wrong
[09:56] <seb128> mvo, btw the gtk patch you attached has an extra buggy hook to it
[09:56] <mvo> oh
[09:56] <mvo> what is buggy?
[09:56] <seb128> mvo, it includes the diff from an another change about single,double click
[09:56] <pitti> seb128: yeah, found the culprit in gdm
[09:56] <seb128> pitti, \o/
[09:57] <pitti> so it is a fix in gdm and g-s-d after all..
[09:57] <mvo> seb128: meh, I thought I had remove that, its part of out gtk package, i used that for the initial testing
[09:58] <seb128> mvo, it was in the diff there, the patch failed to apply and I started cursing you before noticing it was just the change being listed there :p
[09:58] <mvo> *lalala*
[09:58] <seb128> mvo, it's all good don't worry ;-)
[09:59] <mvo> I will upload a fixed diff (you talk about the upstream report, right?)
[09:59] <seb128> mvo, yes
[09:59] <seb128> chrisccoulson, hey
[09:59] <chrisccoulson> hey seb128, how are you?
[10:00] <seb128> chrisccoulson, good! what about you?
[10:00] <chrisccoulson> seb128 - i'm good, but quite tired this morning. my daughter kept waking last night
[10:00] <seb128> mvo, I suck
[10:01] <seb128> mvo, it was the launchpad patch apparently I just checked
[10:01] <seb128> mvo, ignore my comment ;-)
[10:01] <mvo> seb128: oh, ok :)
[10:01] <mvo> seb128: I will just delete it
[10:01] <seb128> chrisccoulson, oh, is she not feeling well or just not wanting to sleep?
[10:01] <mvo> seb128: what was the bugnumber again (sorry I suck at this)
[10:01] <seb128> mvo, do nothing that has been uploaded so it's all good
[10:01] <mvo> ok
[10:01] <chrisccoulson> seb128 - i think she just doesn't want to sleep ;)
[10:02] <seb128> chrisccoulson, I see, luck you ;-)
[10:02] <seb128> lucky
[10:02] <mvo> chrisccoulson: how old is she?
[10:02] <glatzor> mvo, would updating the package cache be to expensive?
[10:02] <chrisccoulson> mvo - she's 4 months old now
[10:02] <mvo> glatzor: how do you mean? update it on every apt-get update run?
[10:02] <pitti> hey chrisccoulson, good morningn
[10:02] <glatzor> mvo, right. running both actions
[10:02] <mvo> chrisccoulson: sweet :) and lots of sleepless nights I'm sure
[10:03] <mvo> glatzor: its relatively expensive, I would prefer not to do that every time on apt-get update
[10:03] <chrisccoulson> hey pitti - how are you?
[10:04] <pitti> chrisccoulson: I'm fine, thanks! just a bit frustrated how utterly broken our keyboard config stuff still is..
[10:04] <chrisccoulson> mvo - she's actually normally quite good through the night now. we put her to bed at about 8pm and she wakes normally at around 6am
[10:04] <mvo> glatzor: the use case is that a just added PPA (or other repository) has the meta-data available immediately. but for a normal apt-get update on stable that just changes a bunch of versions no re-indexing should be done
[10:04] <chrisccoulson> pitti - yeah, i was watching the bug mails yesterday
[10:04] <chrisccoulson> i see you're having fun ;)
[10:04] <mvo> glatzor: maybe I need to invstigate the "--update" hook in a-x-i again, that was added recently and if its not a big slowdown (it should not) then adding it on each apt-get update may be feasible
[10:04] <mvo> chrisccoulson: woah, impressive
[10:14] <glatzor> mvo, the bug is fixed in debconf svn.
[10:15] <mvo> cool
[10:21] <davmor2> Guys I have a weird issue involving gdm every third or fourth boot gdm isn't started.  This means that I have to log in and manually restart gdm from the cli and then it works fine for another 3-4 times
[10:34] <chrisccoulson> it's nice to see that the usual pre-release discussions have started up on the u-d-d mailing list now
[10:35] <chrisccoulson> "f Luicd ia a LTS...... Then I sgrongly urge a few exta betas and a delayed release date"
[10:35] <seb128> chrisccoulson, lol
[10:36] <chrisccoulson> he didn't even spell "Lucid" correctly
[10:36] <bryceh> chrisccoulson, amongst other words
[10:38] <chrisccoulson> heh ;)
[10:38] <chrisccoulson> yeah, those aren't typos from me ;)
[10:40] <bryceh> it amazes me when people recommend delaying release dates who I don't think have been at all involved with development
[10:41] <chrisccoulson> indeed - especially when they don't even back up their suggestion with concrete examples of problems
[10:41] <bryceh> my fingers wish to strangle
[10:41] <chrisccoulson> "i think you should delay the release just for the fun of it" ;)
[10:48] <bryceh> chrisccoulson, bikeshed painters
[10:53] <seb128> pitti, can you quickly review gnome-menus r62 and tell me if you are ok with it?
[10:53] <seb128> pitti, when you have a minute, no hurry
[11:38] <pitti> re
[11:38] <pitti> seb128: sorry, was off IRC, debugging gdm (fixed that part now \o/)
[11:38]  * pitti looks
[11:39] <pitti> seb128: looks great
[11:39] <didrocks> pitti: I've made the rebase, but still not pushed for gdm, I can push a "almost working version" now to avoid you doing the same in the bzr branch
[11:40] <pitti> didrocks: for now I'm working in upstream git
[11:40] <didrocks> pitti: oh oki, no pb so :)
[11:40] <pitti> didrocks: I want to work on g-s-d, and once the entire chain works, I'll commit to the packaging bzr
[11:41] <didrocks> pitti: ok :)
[11:42] <seb128> pitti, ok thanks
[12:02] <kenvandine> good morning everyone, i am going to be afk this morning... might be back in time for the meeting
[12:04]  * kenvandine waves
[12:05] <pitti> hey kenvandine
[12:11] <seb128> hey kenvandine
[12:35] <mvo> I guess this does not really belongs here, but my mom was pretty confused when I upgraded her system and the buttons where all on the wrong side. I guess she is not a target user or something, just as a data point
[12:36] <seb128> pitti, there?
[12:36] <pitti> hi seb128
[12:36] <seb128> mvo, hehe, same here
[12:37] <seb128> pitti, ok, so I just told didrocks that I think it's time to drop the gdmsetup change for this cycle
[12:37] <pitti> :(
[12:37] <seb128> pitti, http://paste.ubuntu.com/399813/
[12:37] <pitti> seb128: I thought it'd work now?
[12:37] <seb128> pitti, look at the current change
[12:38] <pitti> hm, I'd structure it more generically (not SetSoundEnabled(), but SetGconfValue())
[12:38] <seb128> pitti, it's rather that it start looking complicated and hackish
[12:38] <seb128> and it's still not working from gdm
[12:39] <seb128> (but working for a test program)
[12:39] <seb128> I'm wondering if we should keep spending time on that
[12:39] <seb128> or declare that gconf sucks to much for that and delay to next cycle now
[12:40] <pitti> we could just disable the startup sound from gdm entirely by default :-P
[12:40] <seb128> I suggested that to rickspencer3 during the meeting weeks ago
[12:40] <seb128> but he said "no change to the default experience"
[12:40] <didrocks> the scary things are stuff like that: // --shutdown take into account the resuid/resgid and HOME whereas --get --set take the euid/egid
[12:40] <didrocks> I took time to find and I guess the remaining bug in gdm we have should be related to that
[12:41] <pitti> didrocks: oh, g_spawn()'s child_setup_func looks interesting, that probably saves you the explicit fork()
[12:42] <pitti> didrocks: you should just use setgid() and setuid() there, FWIW
[12:42] <pitti> but anyway, setting all three in setresuid() shuold work as well
[12:42] <didrocks> pitti: right, at least, it was an experience that taught me that :)
[12:42] <pitti> it shouldn't be the cause of the bug
[12:42] <seb128> didrocks, it's weird that it works in your test program though
[12:42] <pitti> didrocks: it's nt something simple like not having a correct $PATH in the daemon or so, I figure?
[12:43] <didrocks> seb128: right, that's why I'm fighting since this morning on that. I really though it was a config issue somewhere or a typo
[12:43] <mvo> I wonder if we could make the button layout in metacity part of the theme, that would solve the problem nicely by just changing for this one speicifc theme
[12:43] <didrocks> pitti: no, the process is launched, the output ("value") is just empty, with a 0 return code
[12:44] <seb128> mvo, themes don't allow to do that
[12:44]  * mvo nods
[12:44] <seb128> what I want to do is patch the capplet to set the key
[12:44] <seb128> default being upstream one
[12:44] <seb128> add a key to the .index
[12:44] <didrocks> mvo: seb128: did you read: http://blogs.gnome.org/metacity/2010/03/21/theme-based-button-layouts/ on that?
[12:44] <mvo> seb128: cool idea
[12:44] <seb128> and make the capplet the gconf key
[12:44] <pitti> didrocks: wrap it in strace -o /tmp/trace -f ?
[12:44] <seb128> didrocks, oh no I didn't, when I asked upstream some weeks ago he said that was not possible to do from the theme
[12:45] <pitti> didrocks: so, how do _you_ feel about how we should go forward with this, since you're doing the work? Fix up for lucid, or postpone?
[12:45] <didrocks> seb128: not sure the metacity blog is syndicated to planet GNOME
[12:46] <didrocks> pitti: I agree that in any case it's hackish. Of course, this will be frustrating but sometimes we should maybe be wise and avoid such solution to not make the result unstable
[12:46] <pochu> didrocks: it's not. it's in news.gnome.org
[12:46] <pitti> didrocks: I'm asking because I don't want to say "let's drop this" and make you feel like you wasted hours on this in vain
[12:46] <seb128> didrocks, pitti: well if we can figure quickly was is wrong and land that soon it's maybe worth trying
[12:46] <didrocks> pitti: as I told to seb128, I spent a lot of time on that and it's some kind of rollback, but I can accept it, even if the work feels useless
[12:46] <pitti> it looks like 90% there now, after all
[12:46] <seb128> but I feel we are wasting days there
[12:47] <seb128> didrocks, let me have a quick other go to trying to figure what is wrong
[12:47] <pitti> seb128: they were already spent, though, so it depends on how much more effort it is to make it work
[12:48] <didrocks> seb128: ok, thanks :)
[12:48] <seb128> pitti, the issue is that you can't know that before have it solved
[12:48] <seb128> ie didrocks is fighting for that issue for almost a day now
[12:48] <seb128> it could take an extra hour or an extra week
[12:49] <pitti> we could give us a budget of two more hours; if it works by then, do it, if not, give up?
[12:50] <seb128> ok
[12:50] <seb128> didrocks, let's keep looking until meeting?
[12:50] <pitti> but I think it should be didrocks's call; if he wants to work on it, why not
[12:50] <seb128> and declare postponed if we don't get it to work by then?
[12:50] <didrocks> seb128: sure
[12:50] <seb128> pitti, right, agreed
[12:50] <didrocks> pitti: I agree with seb128's suggestion
[12:50] <pitti> sounds fine
[12:51]  * pitti grabs some lunch, need a break from gdm/gsd ..
[12:51] <seb128> pitti, enjoy
[12:51] <didrocks> pitti: enjoy, gdm is pretty loved those days :)
[13:46] <pitti> seb128: do you know what causes the keybaord layout indicator to be shown or hidden? is that gnome-panel? (it doesn't seem to be g-s-d)
[13:46] <seb128> pitti, it's g-s-d
[13:46] <seb128> pitti, it's displayed if n_layout > 1
[13:46] <pitti> hm, that should be in libgnomekbd/gkbd-indicator.h
[13:47] <pitti> g-s-d source does not match any "indic" (except *.po and *.ui)
[13:48] <pitti> seb128: I have a suspicion, I'm testing that now
[13:48] <seb128> pitti, show_hide_icon ()
[13:49] <seb128> pitti, in gsd-keyboard-xkb.c
[13:49] <seb128> in g-s-d
[13:49] <pitti> seb128: right, but I have two layouts
[13:49] <seb128>         if (g_slist_length (current_kbd_config.layouts_variants) > 1) {
[13:49] <pitti> and can toggle through them with both shift keys
[13:49] <seb128>                 if (icon == NULL) {
[13:49] <seb128>                         xkl_debug (150, "Creating new icon\n");
[13:49] <pitti> seb128: yes, I know, I have the code here
[13:49] <seb128> k
[13:49] <seb128> so I'm not sure to get the question ;-)
[13:50] <pitti> my suspicion is that it somehow checks the gconf key later on, not the actually configured values
[13:50] <seb128> you can set XKL_DEBUG=150
[13:50] <pitti> seb128: my Q was if there's code related to that in gnome-panel
[13:50] <seb128> to get libxklavier debug
[13:50] <seb128> pitti, no
[13:50] <pitti> seb128: ok, thanks
[13:50] <seb128> it's purely g-s-d libgnomekbd libxklavier
[13:50] <seb128> it's a notification area icon
[13:50] <seb128> gnome-panel is only the container
[13:52] <pitti> ah, seems it's not being called at all
[13:52] <pitti> ok, that gives me something, thanks
[14:03] <jcastro> baptistemm: looking for me?
[14:20] <baptistemm> jcastro, yeah, hello
[14:21] <baptistemm> jcastro, I wanted to grant me some power on bug report control
[14:21] <baptistemm> if possible of course
[14:21] <jcastro> heh, which upstream project are you with?
[14:23] <jcastro> oh, you're crevette?
[14:23] <baptistemm> I used to work on GNOME projects globally (I'm member of foundation, and my bz profile is https://bugzilla.gnome.org/page.cgi?id=describeuser.html&login=bmm80@free.fr) but at least I would like to have access to bluez gnome-bluetooth obex-data-server obexd
[14:23] <baptistemm> jcastro, yeah, this is my previous nick, you remember me :)
[14:24] <jcastro> ok you're in, only thing we ask is not to triage bugs outside your scope
[14:27]  * pitti finally declares victory over gdm's and g-s-d's keyboard settings
[14:27] <pitti> on a related note, how can you French guys type on a "fr" layout??
[14:27] <pitti> (I used that for testing..)
[14:28] <didrocks> pitti: we are just crazy, and you know it :)
[14:28] <pitti> I do!
[14:29] <baptistemm> jcastro, thanks a lot
[14:29] <baptistemm> pitti, and we have several Fr layout :)
[14:31] <ccheney> mvo: should already be in the archive now afaik
[14:36] <mvo> ccheney: cool, thanks!
[14:39] <pitti> didrocks: I'm done with gdm/g-s-d; seems you didn't commit anything to gdm recently?
[14:39] <pitti> oh, and seb128, did you touch gdm branch recently? it sill seems to be in the same broken state as yesterday
[14:40] <pitti> I'm fine to untangle it now
[14:40] <pitti> but maybe you just forgot to push, so I'll wait for your reply
[14:40] <seb128> pitti, no but didrocks might have
[14:41] <seb128> pitti, if you do upload gdm please drop 31-unify-power-strings.patch
[14:41] <pitti> okay
[14:41] <seb128> pitti, ups no
[14:41] <seb128> pitti, drop the shutdown change chunk
[14:41] <seb128> the sleep on needs to be kept
[14:41] <pitti> alright
[14:42] <didrocks> pitti: right, I have fixed it, but only locally
[14:42] <pitti> seb128: why not the sleep one as well?
[14:42] <didrocks> (the history mess)
[14:42] <pitti> didrocks: would you mind to push?
[14:42] <pitti> seb128: we reverted it in the session menu as well, didn't we?
[14:43] <nigelb> speaking of gpm, can one of comment on gnome bug 613509
[14:43] <nigelb> *can of you folks
[14:43] <didrocks> pitti: sure, but don't upload it yet because of the sound stuff
[14:43] <nigelb> gah, I give up correcting
[14:43] <pitti> didrocks: no, it has Robert's pending changes as well
[14:43] <pitti> didrocks: I was going to apply my keyboard fix and the string reversion (see above), and rebase the gdmsetup changes to a new UNRELEASED
[14:44] <pitti> didrocks: but if you already fixed history, no need for me to do it again
[14:45] <didrocks> pitti: pushed
[14:47] <pitti> didrocks: hm, r226 ("readd 2.29.92-0ubuntu2 commit") just adds an empty patch header to 28_plymouth_transition.patch, but not actually any code changes?
[14:48] <pitti> anyway, I'll compare with the archive version
[14:48] <pitti> didrocks: thanks
[14:48] <didrocks> pitti: hein? I made a diff and apply the patch. didn't check yet, let me have a look
[14:49] <pitti> didrocks: http://launchpadlibrarian.net/40883554/gdm_2.29.92-0ubuntu1_2.29.92-0ubuntu2.diff.gz
[14:49] <pitti> didrocks: don't worry, I'll sort it out
[14:49]  * pitti doesn't want to keep you from hacking on gdmsetup :)
[14:50] <didrocks> pitti: thanks. Maybe a rejection of other part, strange that the first stenza only was applied :)
[14:51] <tseliot> pitti: how difficult would it be to adapt jockey to function without accessing the archives in /etc/apt/? For example, to force it to use only the archives that I provide it, e.g. via the APT_OPTIONS env. variable
[14:55] <didrocks> pitti: seb128 found the issue with gdm
[14:55]  * didrocks hugs seb128
[14:55]  * pitti ^5s didrocks and seb128
[14:55] <tseliot> pitti: too difficult?
[14:56] <pitti> tseliot: hm, I'm not sure, but p-apt allows you to use a separate tree
[14:56] <pitti> tseliot: but I'm not just using python-apt in jockey, and it's not just /etc/; you also need /var/lib/apt, /var/cache/apt, etc.
[14:56] <pitti> tseliot: what do you want to do?
[14:57]  * seb128 hugs didrocks pitti ;-)
[14:58] <tseliot> pitti: (it's for oem stuff) I think it's meant to allow us to install packages from our own (local) packages pool (e.g. when we don't have an internet connection available)
[14:58] <tseliot> this question comes from my manager, to be honest
[14:58] <pitti> tseliot: wouldn't it be easier to just swap /etc/apt/sources.list for that time being?
[14:59] <pitti> tseliot: but well, I don't mind supporting $APT_OPTIONS, but I don't think I'll have time to implement it in the next week
[14:59] <pitti> tseliot: but I had expected OEM installs to have local apt sources anyway
[15:02] <pitti> didrocks: would you mind if I turn the gdm branch to match the official archive again (including history), and commit Rober's and your changes into a "gdmsetup" branch?
[15:02] <didrocks> pitti: sure
[15:02] <seb128> waouh
[15:03]  * seb128 hugs pitti for winning the keyboard battle
[15:03]  * pitti bows
[15:04] <tseliot> pitti: it seems that we already do as suggested but that slows down first boot quite a bit.  We'd like to cut that down to 1) set APT_OPTIONS to point exclusively at the on-disk pool 2) run jockey-text -e
[15:05] <pitti> tseliot: so, it might be possible to just specify an alternative location of sources.list ($APT_SOURCES_LIST or so, and poke that into python-apt)
[15:07] <tseliot> pitti: ok, I see. Thanks for your help
[15:07] <Laney> did bug 353112 regress?
[15:09] <seb128> Laney, --details?
[15:09] <Laney> I'm seeing that behaviour
[15:09] <Laney> pidgin quits if I close it
[15:09] <seb128> close it as click in the wm button to close the buddylist?
[15:10] <Laney> yes
[15:10] <Laney> let me try in guest session
[15:11] <seb128> I don't confirm there
[15:11] <seb128> is pidgin-libnotify installed for you?
[15:19] <pitti> seb128, didrocks: I fixed lp:~ubuntu-desktop/gdm/ubuntu/ ; please pull --overwrite your local branches
[15:19] <pitti> seb128, didrocks: I'm pushing the gdmsetup sound related ones to a branch: lp:~ubuntu-desktop/gdm/gdmsetup-sound (push still ongoing)
[15:19] <pitti> ... done
[15:19] <pitti> didrocks: so please work in lp:~ubuntu-desktop/gdm/gdmsetup-sound for now, and we'll keep the "ubuntu" one for real uploads
[15:19] <seb128> pitti, ok, thanks for cleaning that
[15:19] <pitti> and once it's ready, we merge it back into ubuntu
[15:19] <didrocks> pitti: perfect, thanks
[15:22] <aquarius> seb128, https://bugs.edge.launchpad.net/bugs/545158 is, i think, a rhythmbox bug (as filed by apport) which is actually being caused by the music store plugin -- but I can't see that bug to confirm or to reassign it
[15:22] <seb128> aquarius, that's because it has not been retraced yet
[15:22] <seb128> I'm wondering if the retracers are running
[15:23] <seb128> aquarius, let me have a look
[15:23] <aquarius> seb128, ah, OK. I'm more than happy for it to be reassigned to us :)
[15:24] <pitti> seb128: ok, to confirm, I'm supposed to keep Suspend->Sleep and drop Shut Down->Switch Off in gdm?
[15:25] <seb128> pitti, yes
[15:26] <bratsche> Morning, desktop lovers!
[15:30] <pitti> hey bratsche
[15:36] <tjaalton> huh, can't print a pdf file on lucid, claims client-error-document-format-not-supported
[15:39] <seb128> bratsche, hey
[15:45] <didrocks> hey bratsche
[15:46] <bratsche> How's it going?
[15:49] <didrocks> bratsche: fine, fighting beside a big amount of work, but apart from that, all is ok ;) thanks. You?
[16:12] <pitti> rickspencer3: any chance you could fix the cron script for https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-23/Scratch/BugList to prepend "Bug:" in front of the bug numbers?
[16:13] <rickspencer3> pitti, yes, but not before the meeting
[16:13] <pitti> rickspencer3: great, thanks
[16:13] <rickspencer3> pitti, I can add it to the command that copies as Moin
[16:15] <tseliot> pitti: as regards our discussion on uninstalling drivers when you disable them in Jockey
[16:16] <tseliot> pitti: this doesn't work too well with open source drivers as you have no way to keep the proprietary driver when switching to the open one
[16:16] <tseliot> because you can't install open drivers in jockey
[16:24] <pitti> tseliot: sure, but why does that hurt? it doesn't take so long to install a .deb, especially not if you already have it in the apt cache?
[16:24] <pitti> tseliot: I'm not entirely opposed to this, but I don't think that we should change working stuff now; we have too many other bugs to fix?
[16:25] <komputes> pitti: it's actually hitting me pretty hard: http://launchpadlibrarian.net/41684650/Screenshot.png
[16:25] <pitti> komputes: is that en_AU.UTF-8? :-)
[16:26] <komputes> pitti: i just installed nvidia drivers and moved the drive to another computer, that is standard english yep
[16:26] <jpds> komputes: Nice.
[16:26] <pitti> komputes: (I was just joking about upside down text)
[16:26] <komputes> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/544818
[16:26] <jcastro> komputes: that's fantastic
[16:26] <komputes> jpds: knew you'd like that fail ;)
[16:27] <komputes> everyone here is litterally flipping out ;)
[16:27] <tseliot> pitti: if you install Ubuntu on a usb key and you plug it in computers with different hardware (e.g. a laptop with intel, a desktop with nvidia, etc.) currently it's not very easy to switch between drivers without uninstalling them.
[16:27] <chrisccoulson> komputes - that definately isn't a gnome-session bug
[16:27] <komputes> "Ubuntu has done a complete design 360"
[16:28] <tseliot> chrisccoulson, pitti: in his case he didn't switch between nvidia and intel correctly (he only changed the xorg.conf) and ended up with Intel using Nvidia's libGL (hence the big mess)
[16:28] <komputes> chrisccoulson: no doubt, I'm about to test removing the driver as suggested by tseliot in another channel
[16:28] <komputes> s/removing/disabling/
[16:28] <chrisccoulson> tseliot, oh, ok ;)
[16:29] <pitti> tseliot: how would you go uninstall a driver then?
 komputes: sudo update-alternatives --config gl_conf
 sudo ldconfig
 sudo update-initramfs -u
 and reboot
[16:29] <komputes> or if you can see it (i.e. on the nvidia machine) use jockey to deactivate driver
[16:29] <tseliot> the purpose of those steps ^^ is to disable the driver (without uninstalling it)
[16:29] <komputes> pitti: ^
[16:29] <ccheney> komputes: the OOo for karmic is in the ppa now
[16:29] <pitti> tseliot: as I said, I think it's rather a corner case, but if you want to change it and test the hell out of it, then okay for me
[16:30] <pitti> tseliot: I was just suggesting that this isn't quite at the top of the things we shuold put our attention to at this stage
[16:30] <komputes> ccheney: cheers, thanks for the update
[16:30] <rickspencer3> team meeting
[16:30] <rickspencer3> !
[16:30] <chrisccoulson> wow, that time already?
[16:30] <Riddell> my favourite time of the week
[16:30] <komputes> was it delated 1h?
[16:30] <chrisccoulson> today has gone far too quickly
[16:30] <tseliot> pitti: I know what you mean, I'll think about. meeting time now
[16:30] <komputes> delayed meeting? wasn't it an hour ago?
[16:31] <pitti> no, 1630 UTC
[16:31] <pitti> for years now :)
[16:31] <rickspencer3> ArneGoetje, bryceh, ccheney, chrisccoulson, didrocks, kenvandine, Nafai, pedro_, pitti, seb128, tkamppeter, tseliot
[16:31] <seb128> there
[16:31] <ArneGoetje> o/
[16:31] <tseliot> o/
[16:31] <rickspencer3> good morning, afternoon, evening ;)
[16:31] <Nafai> o/
[16:31] <didrocks> o/
[16:31]  * kenvandine waves
[16:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-23/
[16:32] <rickspencer3> shall we?
[16:32] <rickspencer3> let's go ...
[16:32] <rickspencer3> First is actions from last meeting
[16:32] <rickspencer3> this is bona fide empty, there were no actions to carry from last meeting
[16:32] <rickspencer3> next is partner update
[16:32] <rickspencer3> kenvandine, ?
[16:32] <kenvandine> yeah
[16:33] <kenvandine> sorry i didn't get to update the wiki yet
[16:33] <rickspencer3> kenvandine, understood
[16:33] <rickspencer3> you had more important things to do
[16:33] <rickspencer3> anything to report?
[16:33] <kenvandine> u1music store is in public beta now!
[16:33] <kenvandine> woot
[16:33] <rickspencer3> !
[16:33] <tseliot> \o/
[16:33] <kenvandine> please make sure to test/report bugs
[16:33] <Riddell> I've found three bugs already :)
[16:33] <kenvandine> Riddell, great... i found like 10 the first hour i used it a few weeks ago
[16:33] <kenvandine> so that is progress :-p
[16:34] <rickspencer3> :P
[16:34] <rickspencer3> wfm
[16:34] <kenvandine> also
[16:34] <kenvandine> OLS has 3 ffe bugs out there
[16:34] <kenvandine> bug 525803
[16:34] <kenvandine> which i think is supposed to land today'ish
[16:34] <kenvandine> and bug 534707
[16:34] <kenvandine> and bug 526084
[16:35] <kenvandine> which are still in the works, i don't have status on those
[16:35] <kenvandine> we should have a bug fix for libu1 today as well, i need to check on that
[16:35] <kenvandine> on to DX, there is a ffe request for indicator-me
[16:36] <kenvandine> to disable the status entry when gwibber isn't available/configured
[16:36] <kenvandine> that is ready, just need approval
[16:36]  * kenvandine doesn't have the bug handy this sec
[16:36] <kenvandine> bug 520932
[16:37] <kenvandine> that is all i have
[16:37] <rickspencer3> kenvandine, bug 53470 sounds like it would slow down boot?
[16:37] <rickspencer3> oops
[16:37] <rickspencer3> kenvandine, bug 534707 sounds like it would slow down boot?
[16:37] <kenvandine> i think that is a lazy start
[16:37] <seb128> don't autostart that service, especially if it still takes some solid 15s of cpu use
[16:38] <pitti> I just commented on that
[16:38] <kenvandine> oh?
[16:38] <pitti> it should only autostart when you actually enable it, and with a solid delay
[16:38] <kenvandine> yeah
[16:39] <vish> seb128: hi.. regarding Bug 526560 , the option is not available now.. instead of it actually working
[16:39] <kenvandine> right now it seems like the only way to make it connect is u1sdtool -c
[16:39] <kenvandine> in a terminal
[16:39] <tkamppeter> hi
[16:39] <kenvandine> which is not cool!
[16:39] <seb128> vish, hi, we are in a meeting right now
[16:39] <kenvandine> ok, that is all i have
[16:39] <seb128> vish, let's talk on an another channel?
[16:39] <vish> seb128: oh , oops sry..
[16:40] <rickspencer3> seb128, pitti, kenvandine can I assume that there will be no increase to boot time and put this out of my mind?
[16:40] <kenvandine> yes
[16:40] <pitti> rickspencer3: you can be that I'll make sure of it :)
[16:40] <rickspencer3> lol
[16:40] <kenvandine> rickspencer3, anything to slow the boot will not be accepted
[16:40] <pitti> s/be/bet/
[16:40] <rickspencer3> fair enough
[16:40] <rickspencer3> ok
[16:40] <seb128> same here
[16:40] <pitti> rickspencer3: as I said, I just commented on the bug with a question and a suggestion
[16:40] <rickspencer3> thanks kenvandine
[16:40] <seb128> I so don't want that to run on my config
[16:40] <seb128> I will make sure it doesn't if you don't use it ;-)
[16:40] <rickspencer3> moving on
[16:41] <rickspencer3> Riddell, Kubuntu status?
[16:41] <Riddell>  * Beta release successful, hugs to keybuk and pitti and ev and cjwatson and the kubuntu community for helping lots there
[16:41] <Riddell>  * However it caused milestoned bug count to multiply 6 fold
[16:41] <Riddell>  * Good news is all the bugs seem fixable, we're already down to < 20
[16:41] <Riddell>  * most worrying is bug 448705   akonadi server doesn't start at login, solutions seem to involve changes to mysql package
[16:41] <Riddell>  * New logo needs deciding, I'll call a meeting of Kubuntu council and community.  Design team still owe us a "k"
[16:41] <rickspencer3> Riddell, could you please define "needs deciding"?
[16:42] <Riddell> rickspencer3: we came up with some options, we need to decide which to go with
[16:42] <rickspencer3> Riddell, who is "we" in this case?
[16:42] <pitti> Riddell: that sounds like a fun meeting; plan two hours :)
[16:42] <Riddell> Kubuntu people
[16:42] <Keybuk> Riddell: "k" - there you go
[16:42] <rickspencer3> Riddell, sorry, I am trying to understand if you are still blocked on the design team
[16:42] <Keybuk> or do you need a K ?
[16:43]  * rickspencer3 kicks Keybuk under table
[16:43] <Riddell> rickspencer3: we're blocked on them by needing a properly rendered "k" in the new font
[16:43] <tseliot> :-D
[16:43] <Keybuk> rickspencer3: the comedy only works if you know that I have the new Ubuntu font installed here
[16:43] <Keybuk> so that actually looked right <g>
[16:43] <Riddell> they're blocked on us deciding the logo we want
[16:43] <rickspencer3> heh
[16:43] <rickspencer3> comedy gold
[16:43] <rickspencer3> Riddell, should I be helping or is it getting sorted?
[16:44] <Riddell> rickspencer3: it's getting sorted
[16:44] <rickspencer3> k
[16:44] <rickspencer3> thanks Riddell
[16:44]  * rickspencer3 takes K and k from Keybuk
[16:44] <rickspencer3> moving on?
[16:44] <rickspencer3> bryceh, are you ready for the xorg update?
[16:44]  * rickspencer3 display k and K on top of monitor
[16:45] <rickspencer3> hmmm
[16:45] <rickspencer3> maybe in Eastern Edition
[16:46] <rickspencer3> ccheney, mozilla update?
[16:46]  * rickspencer3 tap tap tap
[16:46] <rickspencer3> is this thing on?
[16:46] <ccheney> i worked with asac on the patch and in the middle of getting the entry class rewritten
[16:47] <ccheney> was pulled off of it temporarily yesterday to get OOo updated as noted in the wiki
[16:47] <ccheney> but will be working on it again today
[16:47] <ccheney> we debugged the crashing in epiphany to the fact that callbacks were calling the wrong old functions and to fix it required redoing one of the classes that was backported
[16:49] <ccheney> OOo itself is in pretty good shape after the upload yesterday, i have two bugs still to fix and looking through the rest of the bug list to see if anything else major stands out
[16:49] <ccheney> openclipart can't be synced from Debian though due to what appears to be a bug in inkscape bug 529625
[16:50] <ccheney> inkscape causes the build log for even the current openclipart in lucid to go forever > 10GB anyway
[16:50] <ccheney> thats it for my status
[16:51] <rickspencer3> so in terms of mozilla, is this epiphany thing the last thing?
[16:51] <asac> rickspencer3: ccheney is working on hardy backport for epiphany
[16:51] <asac> the rest is here: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list
[16:51] <rickspencer3> k
[16:51] <asac> main for lucid is done (minus one package i think)
[16:52] <asac> we are ramping up getting as many universe things done by end of week
[16:52] <chrisccoulson> yeah, i think it's just packagekit now
[16:52] <asac> everything that didnt happen has to go
[16:52] <rickspencer3> ok
[16:52] <rickspencer3> so sounds on track
[16:52] <rickspencer3> this has been quite a project!
[16:52] <rickspencer3> shall we move on?
[16:52] <asac> heh
[16:53] <rickspencer3> before I turn the mic over to pitti, I wanted to bring up UDS just super briefly
[16:53] <rickspencer3> 1. you should have your flights booked
[16:53] <rickspencer3> if there is ambiguity about when to show up where, ping me out of channel
[16:53] <rickspencer3> 2. start thinking about blueprints
[16:53] <rickspencer3> I'll work with pitti and seb128 and assembling a list
[16:54] <rickspencer3> however, just think about it, focus should stay on Lucid
[16:54]  * rickspencer3 hands mic to pitti
[16:54]  * pitti clears throat
[16:54] <pitti> so, first a look at http://people.canonical.com/~pitti/workitems/canonical-desktop-team-ubuntu-10.04-beta-2.html
[16:54] <pitti> this looks fairly on track and harmless right now
[16:55] <pitti> I'm a bit more concerned about our progress wrt. bugs
[16:55] <pitti> we've been really great at squashing a lot of bugs last week, but the release critical ones (https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus) have been around for quite a while
[16:55] <pitti> so I'd like to discuss some of them in some detail in a bit
[16:56] <pitti> last week, seb128 introduced https://bugs.edge.launchpad.net/~canonical-desktop-team/+assignedbugs to us
[16:56] <pitti> (or rather, filled it up pretty well)
[16:56] <pitti> we got some done, but as another reminder, that's a good pool to take from if you run out of assigned RC bugs
[16:57] <dobey> hey pitti
[16:57] <pitti> in fact, https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-23/Scratch/BugList has a slightly better sorted RC bug list
[16:57] <pitti> par odre de mufti^W^W^W^WRick kindly asked us to try and get this down by 10 this week
[16:58] <pitti> and it seems poor chrisccoulson earned half of them
[16:58] <pitti> bug 512615
[16:58] <chrisccoulson> yay \o/
[16:58] <pitti> some thoughts about that
[16:58] <pitti> basically, we have built firefox with external cairo for years
[16:59] <pitti> is it really a trademark problem if we now just apply it to the local cairo copy in the firefox package?
[16:59] <pitti> asac is going to discuss it with upstream
[16:59] <asac> ack
[16:59] <pitti> but I wondered whether we can "just do" it for now
[16:59] <pitti> it should be a rather simple fix, and it keeps coming up
[16:59] <pitti> chrisccoulson: would that work?
[16:59] <asac> i dont care, just applying patches without getting approval might cause painful discussions
[17:00] <asac> laterone
[17:00] <chrisccoulson> i don't mind doing that if we all agree on that
[17:00] <chrisccoulson> i haven't seen the patch though ;)
[17:00] <asac> chrisccoulson: we can check that after meeting
[17:00] <pitti> asac: but we have shipped firefox with that patch (effectively) applied for many releases already?
[17:01] <asac> pitti: right. and using system-cairo was always something they disliked because they couldnt see all the patches.
[17:01] <asac> but yeah
[17:01] <asac> lets apply it and tell them: here is what we did ;)
[17:01] <pitti> asac: right, but it woulnd't change the status quo
[17:01] <pitti> and at least they can see it much better then
[17:02] <chrisccoulson> we're not the only distro with this issue are we
[17:02] <chrisccoulson> ?
[17:02] <pitti> it'd be very strange if we would be
[17:02] <asac> yeah. lets go for it. only problem i have with it, is that firefox updates system cairo regularly, so we dont really have much bake time for the rebase of this patch in security updates
[17:02] <asac> chrisccoulson: can you fire up fedora and try upstream build?
[17:03] <chrisccoulson> asac - yeah, will do that after the meeting
[17:03] <pitti> ok, thanks
[17:03] <pitti> another one I'd like to discuss is bug 532511
[17:03] <asac> mozilla claimed that part of the font problems is our problem
[17:03] <pitti> rickspencer3, chrisccoulson: do you know what our requirements for this are?
[17:03] <pitti> certainly the new theme should be the default for new installs/new users
[17:03] <pitti> but do we have requirements for upgrades?
[17:03] <chrisccoulson> pitti - my understanding is that new installs / upgrades should get the new colours
[17:04] <chrisccoulson> but i tried to implement it in a way which didn't override existing settings
[17:04] <pitti> i. e. if we'd change it to not switch to the new theme if the user has a custom configuration, is that feasible, or would it cause trouble with sabdfl/design team/etc?
[17:04] <asac> ack. i can confirm as a "custom profile" users, that i didnt get migrated to the new profile.
[17:04] <rickspencer3> pitti, this is for the terminal?
[17:04] <pitti> yes
[17:05] <rickspencer3> I got the new profile, it was called Ambiance
[17:05] <rickspencer3> and I had to switch to it
[17:05] <pitti> after upgrade, you suddenly have huge text, scroll bars, and bad colors, etc.
[17:05] <rickspencer3> I did not have that
[17:05] <chrisccoulson> pitti - it's difficult to do though. the only key i've really switched is the one for the default profile
[17:05] <chrisccoulson> and most users don't customize that
[17:05] <rickspencer3> I had a pretty purple, transparent background with white text
[17:05] <pitti> chrisccoulson: right, but we could stop doing that if the default profile has customizations?
[17:05] <chrisccoulson> pitti - i'd have to think about how we could implement that
[17:06] <pitti> anyway, let's discuss implementation after meeting, but I was interested in the requirements
[17:06] <pitti> right now it seems stuck
[17:06] <chrisccoulson> an alternative would be for me to figure out how we could make the veraious VteTerminal bits themable
[17:06] <seb128> seems we have higher issues to fix
[17:06] <rickspencer3> hold it
[17:06] <rickspencer3> I agree with seb128
[17:06] <pitti> and this is a straight violation of the "golden rule"
[17:06] <rickspencer3> let's do something easy here
[17:06] <pitti> rickspencer3: I disagree
[17:06] <pitti> we tramp over the user's configuration
[17:06] <rickspencer3> right
[17:06] <rickspencer3> which we should not do
[17:06] <pitti> and I'd like to have a pretty strong reason to do so
[17:06] <seb128> pitti, right, let's do not touch any upgrade
[17:06] <rickspencer3> but we shouldn't get all fancy in not doing it
[17:07] <rickspencer3> just install the new profile and let users switch to it if they want
[17:07] <pitti> rickspencer3: that'd work for me
[17:07] <seb128> +1
[17:07] <chrisccoulson> rickspencer3, it wouldn't be default on new installs either then
[17:07] <pitti> rickspencer3: that'd be within the requirements from Mark, etc.?
[17:07] <rickspencer3> pitti, I saw no requirement concerning this
[17:07] <pitti> chrisccoulson: that sounds like a SMOP, though
[17:07] <seb128> chrisccoulson, how so?
[17:08] <pitti> implementation -> after meeting
[17:08] <seb128> ok
[17:08] <chrisccoulson> seb128 - the issue is that we install the profile and set it as the default. if we don't set it as the default, then new installs won't get it either
[17:08] <pitti> so, everyone's fine with "new theme on new install and upgrade only on unmodified profile"?
[17:08] <seb128> yes
[17:08] <seb128> well
[17:08] <rickspencer3> chrisccoulson, why does that stomp on the users' current profiles and cause the ugly things in the bug report?
[17:09] <seb128> I wouldn't even bother about "only on", just don't touch upgrade
[17:09] <rickspencer3> my experience was nothing like described in the bug report
[17:09] <pitti> next one is bug 456468 -- this seems to be an utterly hard thing to fix
[17:09] <seb128> the issue with gconf is that's it's often not easy to know if you profile is the default one or not
[17:09] <seb128> pitti, I don't think we can do anything about that one without changing hardy and karmic
[17:09] <pitti> and I wondered if we can get away with ignoring it?
[17:09] <chrisccoulson> yes, i've no idea what to do about that bug
[17:09] <ccheney> seb128: and if it is the default one, the intent, the user likes the current default or just wants whatever is default
[17:10] <pitti> at that time, apt should have done all the packages, and it doesn't break ethernet at all (just wifi, probably)
[17:10] <seb128> right, I did get disconnected there
[17:10] <seb128> didn't
[17:10] <chrisccoulson> and it shouldn't break system connections
[17:11] <pitti> ok, so I'll downgrade it
[17:11] <chrisccoulson> perhaps we could make nm-applet more robust this cycle though to stop it from happening again next cycle
[17:12] <seb128> chrisccoulson, I did that with my lazy init change
[17:12] <pitti> ok, thanks
[17:12] <chrisccoulson> seb128 - does that stop this from happening?
[17:12] <seb128> chrisccoulson, btw any news of getting the nm-applet changes it?
[17:12] <chrisccoulson> even when the theme is updated
[17:12] <seb128> chrisccoulson, yes, it uses a gtk stock icon as fallbacj when it can't load other icons
[17:12] <chrisccoulson> seb128 - i proposed a merge last week
[17:12] <pitti> bug implementation discussion> after meeting
[17:12] <pitti> rickspencer3: I'm done with release status
[17:12] <chrisccoulson> i don't know if asac saw the merge request though
[17:13] <dobey> pitti: please ping me after you're all done with the meeting :)
[17:13] <seb128> chrisccoulson, ok, let's check with asac later
[17:13] <rickspencer3> pitti, I am concerned about the number of release blockers on our list
[17:13] <rickspencer3> does it seem about normal, high, low, for this part of the cycle?
[17:14] <pitti> looks fairly normal to me
[17:14] <rickspencer3> k
[17:14] <rickspencer3> tseliot, does bug 474917 impact Lucid?
[17:15] <seb128> rickspencer3, I think it's just because I spent time fishing issues out of launchpad and putting some on our list which we don't do usually
[17:15] <seb128> I think we don't have an higher number of issues
[17:15] <tseliot> rickspencer3: nope, and it should be closed
[17:15] <seb128> we put perhaps less effort usually to get those milestoned
[17:15] <pitti> but we have some fairly bad X regressions
[17:15] <rickspencer3> tseliot, it's in progress, could you please adjust to get it off the list
[17:15] <rickspencer3> pitti, yes, we will be discussing xorg in the Eastern Edition
[17:15] <chrisccoulson> i've got a bad kernel regression here ;)
[17:16] <pitti> rickspencer3, tseliot: this is a parsing bug; this bug was closed ages ago
[17:16] <rickspencer3> tseliot, can I confirm that you working on bug 540177
[17:16] <pitti> rickspencer3: fun, it affects bryceh's scripts as well
[17:16] <pitti> those also see this bug as in progress
[17:16] <tseliot> rickspencer3, pitti: ah, good to know
[17:16] <rickspencer3> pitti, ack
[17:16] <bryceh> hi
[17:17] <tseliot> rickspencer3: sure, it's just a matter of cleaning up my patch and waiting on Keybuk to upload his fix for plymouth (which he should do today)
[17:17] <rickspencer3> ok
[17:17] <rickspencer3> pitti, is it feasible to focus on the release blockers list, reduce it by say 10 bugs by eow?
[17:18] <pitti> that's what we should already be doing
[17:18] <rickspencer3> pitti, can we set a specific goal for certain bugs thoguh?
[17:18] <rickspencer3> or at least a numeric goal?
[17:18] <rickspencer3> for this week?
[17:18] <pitti> rickspencer3: bug 417009 should be fixed with latest OO.o, bug 460328 got fixed an hour ago, bug 474917 is invalid -- there, already 3 down :)
[17:18] <Keybuk> tseliot: within the next hour I expect
[17:19] <tseliot> Keybuk: very good
[17:19] <pitti> ccheney: hm, why is 417009 still open? I thought it was applied?
[17:19] <pitti> rickspencer3: down by 10 sounds fine
[17:19] <rickspencer3> ok
[17:19] <ccheney> pitti: it was applied but there is question as to whether the build works on arm
[17:19] <rickspencer3> thanks pitti
[17:19] <ccheney> pitti: once its finished actually building ncommander is going to test it and verify its good (aiui)
[17:19] <pitti> ccheney: ah, so you wait with closing until it did? makes sense, thanks
[17:20] <ccheney> pitti: yea the patches for that bug have been through many rounds
[17:20] <rickspencer3> pl
[17:20] <rickspencer3> ok, even
[17:20] <rickspencer3> any toher business?
[17:20]  * rickspencer3 shakes out finger
[17:20] <rickspencer3> s
[17:20] <rickspencer3> any other business
[17:20] <rickspencer3> ?
[17:21] <rickspencer3> ok
[17:21] <ccheney> if we have any inkscape experts looking at it would be nice, seems to have a lot of high heat crashers, which is also blocking openclipart :)
[17:21] <rickspencer3> Eastern Edition in 4.5 hours
[17:21] <rickspencer3> we'll get a good run down of xorg progress then, I htink
[17:22] <rickspencer3> ccheney, InkScape is crashy you say?
[17:22] <rickspencer3> are you looking for a specific action, or just just informational?
[17:23] <ccheney> rickspencer3: well fixing whatever is behind the failure to build openclipart is the most pressing for me, but after looking at its bug list the part about it being generally crashy is informational
[17:23] <ccheney> not sure if the solution would be to revert to the older version that used to work, or not
[17:23] <ccheney> some of the crasher bugs are from karmic timeframe so not sure about them
[17:23] <seb128> usually the way forward is to fix the crash not to downgrade
[17:24] <ccheney> yea
[17:25] <seb128> did you try to fix it?
[17:25] <ccheney> for unknown to me reasons most of the bugs are still marked private
[17:25] <ccheney> seb128: not yet, been too busy with other work to look into it
[17:25] <seb128> crashes are private until being reviewed and marked open by a triager
[17:25] <rickspencer3> will this block the release?
[17:25] <seb128> to avoid avoid passwords in a stacktrace going public or similar
[17:26] <rickspencer3> it seems that we need to find a bug report to stand in for the fix, and get that on the blocker list, and then get it fixed
[17:26] <ccheney> rickspencer3: no but users using clipart would be pretty annoyed since it is no longer installable in the archive, and we can't even rebuild the version in the archive due to the inkscape bug
[17:26] <bryceh> ccheney, we should be able to get fixes without too much trouble.  What are the top 2-3 bug #'s we need fixed?
[17:26] <rickspencer3> ccheney, could you drive this please ^
[17:26] <ccheney> rickspencer3: ok
[17:27] <rickspencer3> ACTION: ccheney to determine bugs in inkscape on critical path to building open clip art
[17:27] <rickspencer3> any other business?
[17:27] <bryceh> ccheney, unfortunately I've not had much time to spend on inkscape lately, but I know folks who can help
[17:27] <pitti> dobey: pong (I'll take a quick break now, but will answer scrollback)
[17:27] <rickspencer3> ok
[17:27] <ccheney> bryceh: the issue behind bug 516771 is the one affecting openclipart
[17:27] <rickspencer3> thanks all
[17:27] <rickspencer3> see you in Eastern Edition
[17:27] <didrocks> thanks everyone :)
[17:27] <bryceh> ccheney, *looking*
[17:27] <ArneGoetje> thanks
[17:27] <ccheney> bryceh: when building it shows this forever ** (inkscape:21087): WARNING **: helper-fns::helperfns_read_vector() Unable to convert ",0.8571428571428572,1,1" to number
[17:28] <ccheney> bryceh: it does that with both the old version in the archive and the one to sync from debian
[17:28] <bryceh> ccheney, hmm
[17:28] <ccheney> bryceh: there is an even newer version upstream that isn't in debian yet, if it is change in how inkscape works that might fix it but i haven't looked at it yet
[17:29] <chrisccoulson> pitti - did you see any scrollback from last night (about apport attaching crash files to bug reports)?
[17:29] <chrisccoulson> i forgot to ask you this morning
[17:29] <bryceh> ccheney, do you have a link to a full build log?
[17:29] <pitti> chrisccoulson: I saw it from scrollback, and reported an LP bug
[17:29] <chrisccoulson> pitti - thanks
[17:29] <ccheney> bryceh: i can regenerate one but it was 10GB when i killed it
[17:30] <dobey> pitti: just wondering if we need the same level of UI freeze exception to remove UI, or if we can just get away with an e-mail notifying of the chaange
[17:30] <seb128> asac: hey
[17:30] <ccheney> bryceh: probably could be killed after a few MB though since the older log was only ~ 1MB iirc
[17:30] <bryceh> ccheney, my bet is that there's something in the .svg files causing the warning
[17:30] <seb128> asac: can your get chrisccoulson's nm-applet merge request in lucid?
[17:30] <ccheney> bryceh: ok
[17:30] <bryceh> ccheney, it would be helpful to have a specific svg file which generates the warning, for testing
[17:30] <ccheney> bryceh: i'll generate a build and kill it as soon as that warning starts and get you the log
[17:31] <bryceh> ccheney, my bet is that some of the files were generated by something other than inkscape (illustrator maybe?) and has some svg that inkscape doesn't grok very well
[17:31] <bryceh> ccheney, if the issue is merely that it's generating that warning, well we can quell it if that solves the build problem
[17:31] <pitti> dobey: then you'd need to subscribe to the ubuntu-doc ML; I guess a bug report and subscribing ubuntu-doc is easier
[17:31] <ccheney> bryceh: ok
[17:31] <bryceh> ccheney, but if the build log shows there's also a legitimate error cropping up, that'll need a stronger fix
[17:31] <asac> seb128: yes. he can ping me directly too ;) (or did i ignore him on this?)
[17:32] <ccheney> bryceh: ok
[17:32] <asac> is that about the upgrading thing?
[17:32] <asac> e.g. missing resource?
[17:32] <seb128> asac: no, that one can't be fixed apparently
[17:32] <ccheney> bryceh: should have a log for you in a few min
[17:32] <bryceh> ccheney, ok
[17:32] <seb128> asac: it's old running code and pixbuf loader having libc versions mismatch after the update
[17:33] <chrisccoulson> asac - bug 460144
[17:33] <asac> seb128: why are pixbuf loaders loaded that late?
[17:33] <asac> shouldnt those be loaded first time an icon is loaded?
[17:34] <seb128> asac: they are unloaded until needed again apparently
[17:34] <asac> so i assume they get unloaded int he meantime ... why is that happening ;)
[17:34] <asac> thats bad
[17:34] <asac> really bad
[17:34] <asac> noone should do that ;)
[17:34] <seb128> lol
[17:34] <asac> really. that alwaysw will call for upgrade problems ;)
[17:34] <seb128> so it needs changes in the hardy and karmic versions
[17:34] <seb128> if you want to fix that
[17:34] <asac> yes. mvo wants to make a patch for that ;)
[17:35] <seb128> asac: right, sort of, the lazy init change for lucid has fallback stock icons though
[17:35] <seb128> asac: so after lucid it will display a fallback icon rather than exiting
[17:37] <asac> hmm. ok that doesnt help us now ;)
[17:38] <seb128> asac: right, better suggestions are welcome
[17:38] <seb128> asac: otherwise we will just have to do with that error on upgrade
[17:38] <seb128> downloads are done anyway so it doesn't break upgrades
[17:39] <asac> network is not going down?
[17:39] <seb128> only wifi
[17:39] <seb128> right that's an issue
[17:39] <mvo> well, it does break updates for stuff that requires network, like the mscorefonts (not sure that this is still relevant) or flashplugin-installer
[17:39] <seb128> but we are out of good ideas
[17:40] <seb128> would restart nm-applet work?
[17:40] <seb128> ie would it reconnect?
[17:40] <mvo> has someone actually looked at the code if the loaders are unloaded immediately or if there is some sort of timeout?
[17:40] <seb128> I didn't
[17:40] <mvo> I wonder if the idea to trigger theme changed signals at the start of the upgrade (or even periodically) would help
[17:41] <mvo> the other option is restarting I guess, but that gets messy quickly
[17:42] <ccheney> bryceh: the build log for the parts that worked even looks substantially different than when it was built during karmic cycle
[17:42] <bryceh> ccheney, I'd be interested in seeing a comparison, that might provide some clues
[17:42] <ccheney> bryceh: i'm seeing svg->png of 10524 x 16000 pixels which i can't find in the old build log
[17:43] <ccheney> bryceh: i don't know enough about the package to know if it was just less verbose before or if that is a bug itself
[17:43] <bryceh> yeah could be just different verbosities
[17:48] <ccheney> watching a build makes it go much slower, heh
[17:53] <bryceh> ccheney, heh
[17:55] <ccheney> my guess is that inkscape doesn't like something about one of the svg's and gets stuck in an infinite loop
[17:55]  * ccheney still waiting for it to find that file
[17:55] <ccheney> it just found it :)
[17:55] <davmor2> http://www.pcpro.co.uk/blogs/2010/03/23/ubuntu-10-4-beta-is-bloody-brilliant/
[17:56] <ccheney> bryceh: http://people.canonical.com/~ccheney/openclipart_0.18+dfsg-8_amd64.build
[17:57] <ccheney> bryceh: if i am reading the old build log right it processed it fine at that time
[17:57] <ccheney> http://launchpadlibrarian.net/26713663/buildlog_ubuntu-karmic-i386.openclipart_0.18%2Bdfsg-8_FULLYBUILT.txt.gz
[17:58] <bryceh> (inkscape:7011): Gdk-CRITICAL **: gdk_display_list_devices: assertion `GDK_IS_DISPLAY (display)' failed
[17:58] <bryceh> heh
[17:59] <bryceh> "Waaaaa where's X on this machine??"
[18:00] <bryceh> ccheney, well a plentitude of warnings in there and lots that could be cleaned up better, but looks like it didn't fail anywhere
[18:02] <bryceh> ccheney, btw openclipart also uses launchpad - https://bugs.edge.launchpad.net/openclipart
[18:02] <bryceh> ccheney, so if there are openclipart bugs in launchpad, should be pretty easy to upstream them
[18:04] <ccheney> bryceh: ok well i can let it run longer, but it grew to over 10GB logfile with those messages scrolling
[18:04] <ccheney> it may be that it just finds multiple files it is doing that for but i am not sure
[18:05] <ccheney> i killed it at 10GB not sure how much longer it would have continued
[18:05] <ccheney> bryceh: is that warning not just repeating forever? it doesn't seem to change
[18:05]  * bryceh lp's #545279
[18:07] <ccheney> that seems like a different issue than the never ending warning message though?
[18:07] <ccheney> the log shows 4 different helper-fns::helperfns_read_vector, then all the rest after that is the same number conversion
[18:08] <ccheney> i saw a number of the SP_PROP_CLIP_PATH in the file but they didn't loop infinitely
[18:08]  * bryceh lp's lp #545286
[18:09] <Keybuk> seb128: just once, I'd like the seahorse pgp dialog to appear *on top* of my windows
[18:09] <bryceh> ccheney, can you check if the build script which calls inkscape is using the -z, --without-gui flag?
[18:10] <ccheney> bryceh: ok will check
[18:10] <bryceh> ccheney, if not, then that should definitely be added.  That should quell the GDK_IS_DISPLAY failed warnings
[18:10] <bryceh> and possibly the quark asserts too
[18:11] <ccheney> bryceh: doesn't appear to
[18:12] <ccheney> http://pastebin.com/Qrm2RL48
[18:12] <ccheney> looks like debian builds the pngs directly in rules
[18:15] <bryceh> ccheney, ew
[18:15] <bryceh> ok getting called to lunch... bbiab
[18:15] <didrocks> diner time, bbl
[18:15] <bryceh> lp #545290
[18:15] <ccheney> bryceh: ok
[18:17] <ccheney> bryceh: not sure if those bugs are actually issues with openclipart itself or with the debian packaging of it
[18:17] <ccheney> bryceh: it looks like it is from debian though
[18:22] <ccheney> bryceh: oh and however this is happening it built on debian
[18:22] <ccheney> but as it is a single build there is no build log unfortunately :-\
[18:25]  * ccheney may try building the debian version of inkscape and see if that helps
[18:25] <asac> bryceh: how bad would you feel about this? http://pastebin.com/4bLjKSsP
[18:35] <jcastro> bryceh: am I reading this wrong or is your patch buglist waaaaay smaller than before?
[18:38] <bryceh> jcastro, well I've been working on it, but there's still a fair ways to go
[18:38] <jcastro> bryceh: are you using +patches now or your thing still?
[18:39] <seb128> kenvandine, there?
[18:40] <bryceh> asac, not bad at all.  Looks acceptable to me
[18:40] <bryceh> jcastro, still using my own thing; I found +patches was missing a lot of my patches when I looked at it a couple weeks ago.  Haven't looked again lately
[18:41] <bryceh> jcastro, how many is it showing now?  It should be 29
[18:41] <bryceh> actually it should be >29.  I omit some stuff from my report (like openchrome patches)
[18:42] <jcastro> which team?
[18:42] <jcastro> I am looking at ~ubuntu-x-swat
[18:42] <Keybuk> ah, I can't type into X again
[18:42] <Keybuk> I know what this means
[18:42]  * Keybuk types his passphrase
[18:44] <ccheney> bryceh: the -z didn't seem to help any with the infinite loop
[18:45] <seb128> Keybuk, are you sure you don't use gpg-agent?
[18:45] <Keybuk> how would I know
[18:45] <seb128> Keybuk, echo GPG_AGENT_INFO
[18:45] <seb128> ups
[18:45] <seb128> Keybuk, echo $GPG_AGENT_INFO
[18:45] <Keybuk> quest scott% echo $GPG_AGENT_INFO
[18:45] <Keybuk> /tmp/seahorse-zGscAV/S.gpg-agent:1349:1
[18:45] <Keybuk> iz seahorse
[18:45] <seb128> hum k
[18:45] <bryceh> ccheney, hmm I think bug #545290 is not in the debian build script, at least I don't see anything that's producing it.
[18:47] <bryceh> ccheney, ./office/telephone/mobile_phone_01.svg seems to be the wayward file
[18:47] <ccheney> bryceh: well ubuntu didn't modify openclipart from debian and not much of OOo so i think maybe its something done to the ubuntu specific changes in inkscape
[18:47] <ccheney> bryceh: yea saw that it worked fine with older inkscape in karmic, but not in lucid
[18:47] <bryceh> ccheney, try running inkscape --export-png=foo.png  ./office/telephone/mobile_phone_01.svg and see if you can repro it
[18:48] <ccheney> yea that causes it just by itself
[18:48] <bryceh> ok
[18:49] <bryceh> progress :-)
[18:50] <asac> bryceh: cool. i will double verify and give it to you. would be great to get this in
[18:51] <bryceh> ccheney, can you email me or post me that particular .svg file?
[18:52] <jcastro> bryceh: check out this wishful thinking! https://edge.launchpad.net/~ubuntu-x-swat/+patches
[18:52] <bryceh> jcastro, hah, well at least all the Fix Released ones are gone
[18:53] <bryceh> jcastro, that's not right though...  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/patches.html
[18:53] <bryceh> jcastro, and it could omit totem ;-)
[18:55] <bryceh> ccheney, anyway so looks from this like the .svg is invalid
[18:55] <jcastro> ok I'll have karl look at it, thanks for the info.
[18:55] <bryceh> sounds like it has coordinates or data that starts with a comma
[18:55] <bryceh> ",0.8571428571428572,1,1"
[18:56] <ccheney> bryceh: hmm looks like even debian version of inkscape doesn't work for me
[18:56] <ccheney> bryceh: yea
[18:56] <bryceh> I'm curious what the .svg even looks like
[18:56] <jcastro> bryceh: at the session do you remember about how many there were?
[18:56] <jcastro> bryceh: it would be nice to say "it's working! to lp guys"
[18:56] <bryceh> ccheney, yeah I'm pretty sure this is not a ubuntu-specific bug.  Looks like a badly formatted svg
[18:56] <bryceh> still, inkscape shouldn't generate endless warnings with such syntax
[18:57] <bryceh> jcastro, not offhand
[18:57] <bryceh> jcastro, I may not be a good example case though
[18:59] <bryceh> jcastro, my original list was maybe a hundred items or so, down to about a third now
[18:59]  * jcastro nods
[19:00] <bryceh> jcastro, I just make it a regular task to get 10% of the items off the list each week... ends up taking a modest hour or two per week, and the list gradually shrinks :-)
[19:03] <ccheney> bryceh: yea, i am going to do one more test with debian packages inside a debian chroot as the debian guy who built it isn't sure why it is happening in ubuntu but works for debian
[19:04] <bryceh> ccheney, you could also put the busted file in the debian rules to be excluded from processing as a workaround
[19:05] <mvo> pitti: do you know anything about why fglrx-modaliases is in restricted now? this causes depwait in update-manager
[19:05] <pitti> mvo: hm, that was certainly not on purpose
[19:05] <pitti> mvo: moved back to main
[19:06] <mvo> pitti: thanks
[19:06] <pitti> of course we just missed the publisher
[19:06] <ccheney> bryceh: yea once i look at what really happens with debian build i will likely do that
[19:06] <ccheney> bryceh: it might be a 64bit issue or something like that, not sure yet
[19:06] <bryceh> possibly
[19:06] <ccheney> bryceh: assuming it really does work on debian
[19:06] <bryceh> or some gcc optimization unique to us
[19:06] <bryceh> fwiw it's crapping on a g_strtod call
[19:07] <ccheney> ok
[19:07] <bryceh> you might try making a simple C test case that calls g_strtod(",0.8571428571428572,1,1") and see if the output of that differs on debian vs ubuntu
[19:08] <ccheney> ok, making a sid chroot now
[19:09] <bryceh> char *ptr; g_strtod(",0.8571428571428572,1,1", &ptr); if (&ptr) { g_warning("Foobar! Broken"); exit(1); }
[19:09] <bryceh> something like that
[19:09] <bryceh> oh I think I see why it's endlessly looping
[19:09] <ccheney> bryceh: oh?
[19:09] <bryceh> wait
[19:10] <bryceh> nevermind, I'm wrong
[19:10] <ccheney> ok
[19:11] <bryceh> but it looks like something in inkscape is going, "Convert this string to a number.  Oh it's not a number, hand back the non-numerical part.  There is stuff left in the string; ok go to 1."
[19:11] <bryceh> like maybe there's double commas or something
[19:12] <bryceh> ccheney, if you have the .svg on hand, grep for 0.85714285 and see what characters immediately precede that
[19:15] <ccheney>         <feFuncR amplitude="1" exponent="1" intercept="0" offset="0" slope="1" tableValues="0.6142857142857143,0.8571428571428572,1,1" type="table"/>
[19:15] <ccheney> it seems to be that
[19:20] <kenvandine> seb128, hey, what's up?
[19:21] <seb128> kenvandine, hello
[19:21] <kenvandine> bryceh, is there any known problems with resuming using the nvidia binary driver?
[19:21] <chrisccoulson> seb128 - i've got no idea what's going on with bug 543932
[19:21] <kenvandine> like X just not lighting up?
[19:21] <seb128> kenvandine, can you review the change on bug #476662, the submitter says your append change is buggy
[19:21] <seb128> chrisccoulson, me neither
[19:22] <kenvandine> seb128, i'll look
[19:22] <seb128> kenvandine, thanks
[19:23] <seb128> chrisccoulson, I added a new comment to suggest the bug setting might not be adapted, it seems only kees has the issue so far
[19:23] <bryceh> kenvandine, yeah being discussed on #ubuntu-x.  tseliot is handling nvidia so he's the guy to talk to about it
[19:23] <kenvandine> bryceh, ok, great... thx
[19:24] <bryceh> kenvandine, Sarvatt mentioned suspend/resume issues 1 out of 5 tries a bit earlier on #ubuntu-x, he might also have clue
[19:25] <kenvandine> ok, my wife's laptop seems to be suffering from it
[19:25] <kenvandine> looks like resume is complete, but the display never lights up
[19:25] <kenvandine> was fine in karmic, she kicked me off of it for now.. so can't debug until later, she *needed* to get to facebook :)
[19:27] <mvo> tedg: one of the upgrade feedback I got so far was/is that "Broadcast" does not mean anything to most people (including me). having a more meaningful word this in the applet would be nice
[19:28] <tedg> mvo: You are playing with fire :)
[19:29] <mvo> tedg: sorry, just passing on my feedback
[19:29] <tedg> mvo: The problem is that the only thing that really means something is "Twitter" which is copyrighted.
[19:29] <seb128> mvo, it's a sabdfl area you are stepping in ;-)
[19:29] <mvo> tedg: weeh, ok
[19:29] <seb128> mvo, just saying ;-)
[19:29] <mvo> the thing is that I just read a lot of the upgrae feedback I got so far
[19:30]  * seb128 hugs mvo
[19:30] <mvo> and this I saw along with the button ordering and moving shutdown away from system
[19:30] <seb128> mvo, please keep sharing feedback you read with us
[19:30] <mvo> but other than that it seems to be working remarkable well
[19:30] <mvo> (for a beta)
[19:30] <seb128> mvo, the system menu change is there for like 3 cycles now
[19:30] <tedg> mvo: I'm not disagreeing, I think that we just haven't found something better :(
[19:30] <mvo> seb128: hardy->lucid
[19:30] <seb128> mvo, do we have many hardy upgraders already?
[19:30] <mvo> seb128: is part of the feedback
[19:30] <mvo> seb128: not many
[19:30] <seb128> mvo, I would have though those would wait for after stable
[19:31] <tedg> mvo: We had "Microblogging" but that didn't really poll any better.
[19:31] <mvo> tedg: I was about to suggest that, at least I (or I assume most technical users) have a clue what it means
[19:31] <mvo> tedg: when I read "broadcast" first I though about abahi
[19:31] <mvo> avahi
[19:31] <mvo> or network broadcasts in general
[19:32] <mvo> but yeah, if twitter is copyrighted than I can see that its a pain to find a good word describing it :)
[19:32] <Nafai> I think about radio or tv when I think of broadcast
[19:32] <seb128> yeah, I think micro-blogging was easier to understand
[19:32] <tedg> mvo: Yeah, I can see that.  Is there a better translations in other languages?
[19:33] <mvo> not in german I think, but broadcast is really terible to translate AFAICS in german, it means "broadcast" in the tv/radio kind of sense, noone would get a different meaning
[19:33] <tedg> I wonder if we could argue in court that the name "twitter" has become generic ;)
[19:34]  * mvo actually wonders how "blog" is translated, but I guess just as "blog" :)
[19:35] <mvo> anyway, just wanted to mention it
[19:35] <tedg> Heh, we could just break it all down.  Texting-like-thing-from-your-computer :)
[19:45]  * mvo likes that
[19:47] <didrocks> pitti: seb128: ok, new version of clutter (and clutter-gtk and gtk itself) uploaded in the ubuntu-desktop ppa. I'm playing with it since half an hour and don't have any pitfall. Even more, UNE is pretty fast with new clutter too :)
[19:47] <seb128> didrocks, excellent!
[19:47] <seb128> didrocks, good work!
[19:47] <didrocks> should be built for tomorrow morning
[19:47] <didrocks> seb128: thanks :)
[19:47] <didrocks> seb128: I've directly uploaded pango and atk to ubuntu
[19:47] <seb128> I will new those when they are built
[19:47] <seb128> thanks
[19:47] <didrocks> the rest is in the ppa
[19:47] <didrocks> thanks
[19:48] <pitti> didrocks: great!
[19:48] <ccheney> bryceh: yea exactly the same problem on debian so will just work around the bug by skipping that file and see if it finishes
[19:48] <bryceh> ccheney, ok
[19:49] <bryceh> ccheney, probably worth filing a bug about the busted file too
[19:50] <ccheney> bryceh: yea, will file a bug about the problems i find including that one
[19:51] <bryceh> great
[19:53] <ccheney> bryceh: rene (debian) can now reproduce the issue as well apparently
[19:54] <pitti> seb128: time bzr get lp:ubuntu/gvfs -> 32 s
[19:54]  * bryceh nods
[19:54] <pitti> seb128: would you mind if we switch branches to lp:ubuntu/package one by one which are fast and up to date?
[19:55] <pitti> seb128: (I'd drop vcs-bzr and do a commit to the old branch to delete everything and add a README "use lp:ubuntu/package, Luke")
[19:55] <seb128> pitti, I was going to wait until+1 to not disrupt workflow
[19:55] <seb128> and have time to discuss at uds what we do with the bzr history etc
[19:55] <pitti> seb128: ok, understood
[19:55] <seb128> and maybe set some updated documentation on how we use it
[19:55] <seb128> but
[19:55] <seb128> if you want to do some go for it
[19:56] <seb128> we will call those testing ;-)
[19:56] <seb128> ie gvfs I doubt many people will touch
[19:56] <pitti> I touch it pretty often
[19:56] <seb128> right
[19:56] <pitti> seb128: I'd like to do the next upstream version update
[19:56] <seb128> I meant out of you and me
[19:56] <pitti> seb128: I'd commit to vetting/updating documentation for upgrading to a new upstream version
[19:56] <pitti> if we switch
[19:56] <seb128> ok, deal
[19:56] <pitti> but I'm interested in how it goes
[19:57] <seb128> I want your internet btw ;-)
[19:57] <seb128> real	2m41.141s
[19:57] <seb128> there
[19:57] <pitti> uh
[19:57] <pitti> 6 MBit here
[19:57] <seb128> 1M there
[19:58] <pitti> seb128: ok, let's perhaps not have too many of them for now then
[19:58]  * desrt plays a fun game, but it quickly turns frustrating
[19:58] <seb128> desrt, which one?
[19:58] <pitti> desrt: got a new vim plugin? :-)
[19:58] <seb128> pitti, well I will quickly have checkout of most GNOME sources so don't stop for me
[19:58] <desrt> the copy-dpkg.deb-into-a-chroot-and-try-to-install-it game
[19:59] <seb128> pitti, real	0m19.695s
[19:59] <seb128> pitti, that's apt-get source
[19:59] <seb128> just to compare
[19:59] <pitti> seb128: ok, let's do gvfs for now; we have a lot of other packages not in bzr, so it won't make too much of a difference
[19:59] <seb128> right
[19:59] <seb128> I'm interested in having some testcases too
[19:59] <desrt> there are some really silly dependencies -- some declared, some not
[19:59] <zyga> hello
[20:00] <desrt> like dpkg doesn't declare a dependency on perl, but it needs it
[20:00] <seb128> perl is in base
[20:00] <desrt> and you need libstdc++ to install lzma which is needed to install dpkg
[20:00] <desrt> base is just assumed?
[20:00] <seb128> yes
[20:00] <desrt> hmm.
[20:00] <desrt> i guess apt is in base too
[20:00] <seb128> it's what you should always have
[20:00] <pitti> seb128: ok, lp:~ubuntu-desktop/gvfs/ubuntu locked down; should be pretty obvious :)
[20:00]  * desrt is trying for ultra-minimal :)
[20:01] <seb128> pitti, "locked down"?
[20:01] <seb128> pitti, how do you do that? just deleted it?
[20:01] <seb128> pitti, which makes me think we should play cleaning old bzr
[20:01] <seb128> I had a look to the ubuntu-desktop list recently
[20:01] <pitti> seb128: http://bazaar.launchpad.net/%7Eubuntu-desktop/gvfs/ubuntu/revision/72
[20:01] <seb128> there is lot of cruft there
[20:01] <desrt> seb128: how do i find a list of 'base'?
[20:01] <pitti> how do you mean?
[20:01] <seb128> hehe
[20:02] <pitti> seb128: I think tla actually had a "lock" thing back then :)
 nobody can be told what base is.  they have to experience it for themselves.
[20:02] <seb128> pitti, https:/code.launchpad.net/~ubuntu-desktop
[20:02] <seb128> pitti, look to the list
[20:02]  * pitti fixes the prefix and looks
[20:03] <pitti> seb128: uh, I see what you mean
[20:04] <seb128> I've to go for dinner
[20:04] <seb128> desrt, sorry I don't know of hand, check on google ;-)
[20:04] <desrt> seb128: i'm just going to install a pbuilder and figure it out from there :p
[20:04] <seb128> or that
[20:05] <seb128> bbl
[20:05] <didrocks> locking is quite strict with pitti :)
[20:05] <desrt> ta
[20:05] <didrocks> seb128: enjoy your dinner :)
[20:06] <pitti> seb128: enjoy! I'm uploading gvfs now, and uploaded usbmuxd; would appreaciate feedback how it goes with your ipod
[20:08] <desrt> hmm.  pbuilder is really too much stuff.
[20:08] <pitti> seb128: FYI: bzr bd -- -b Just Works (TM), using pristine-tar
[20:08] <desrt> dbus, glib, gnupg.  bah.
[20:23] <ccheney> bryceh: actually i misunderstood rene, it worked for him on amd64 but he didn't build it in a chroot
[20:23] <ccheney> bryceh: so either something else in debian is helping him or its a kernel issue or some other weirdness
[20:24] <bryceh> yeah
[20:31] <ccheney> bryceh: the test printed broken
[20:31] <ccheney> bryceh: the test you gave me to try
[20:31] <bryceh> ccheney, *nod*
[20:31] <bryceh> ccheney, did you try under debian?
[20:47] <ccheney> bryceh: yea that was where i tried it
[20:47] <ccheney> bryceh: and for me it didn't work under debian in a chroot either
[20:48] <ccheney> it being building openclipart
[20:50] <zyga> how about we make the power off switch bright-orange instead of dark-red? orange is much more visible and fits the color scheme
[20:51] <ccheney> zyga: isn't it just black currently?
[20:51] <zyga> I just upgraded to latest packages and the power switch is red
[20:51] <ccheney> zyga: ah ok
[20:51] <zyga> (power switch on the right of the top panel)
[20:52] <ccheney> yea, i haven't logged out today
[20:52] <zyga> I think it's better than plain white/gray that it was before but orange is more visible
[20:53]  * zyga needs to reboot
[21:01] <pitti> good night everyone!
[21:06] <kenvandine> hey seb128... you got time for a quick package to sponsor?
[21:06] <seb128> kenvandine, yes
[21:06] <kenvandine> ~ubuntu-desktop/libubuntuone/ubuntu/
[21:06] <kenvandine> thx!
[21:07] <kenvandine> damn... rb plugin was rejected too..
[21:07] <kenvandine> seb128, mind sponsoring that too? it is a simple dep fix
[21:07] <kenvandine>  for none gnome users
[21:07] <seb128> ok
[21:07] <seb128> that's the one Riddell reported right?
[21:08] <kenvandine> nope
[21:08] <kenvandine> lp:~ubuntu-desktop/rhythmbox-ubuntuone-music-store/ubuntu
[21:08] <kenvandine> seb128, it might be a dupe though
[21:09] <seb128> yes it is ;-)
[21:09] <kenvandine> yeah, /me dupes it
[21:10] <kenvandine> ok, i gotta run for a bit.  bbl
[21:10] <kenvandine> seb128, thx!
[21:10] <seb128> kenvandine, np, see you
[21:18] <didrocks> time to take a shower and some rest too :)
[21:18] <didrocks> see you tomorrow!
[21:33] <TheMuso> Good morning.
[21:37] <bryceh> hi TheMuso
[21:37] <RAOF> Good morning.
[21:38] <rickspencer3> Good morning guys
[21:39] <RAOF> Goood morning.
[21:39] <rickspencer3> TheMuso, bryceh, RAOF, I've been too busy to update the wiki from the team meeting this morning
[21:39] <rickspencer3> I suppose I can paste in the IRC log though
[21:39] <rickspencer3> bryceh, are you going to go over xorg status in the Eastern Edition
[21:39] <rickspencer3> ?
[21:41] <bryceh> sure
[21:41] <bryceh> * A few tasks have been marked off https://wiki.ubuntu.com/X/Projects  Pretty good progress for first week, but we need to see more grey
[21:41] <bryceh> * I made a graph showing just "lucid bugs needing developer attention":  http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg  Ideally this curve should be going *down* but it's going *up* instead.
[21:41] <bryceh> * This means we're getting new bugs coming in faster than we are processing them.  We need to step it up a bit more.
[21:41] <bryceh> * I don't have a solid feel for the rate of upstreaming and fixing going on, but I sense we may be a lagging a bit.
[21:41] <bryceh> let me amend my point #2 above
[21:42] <bryceh> raof and sarvat really banged on -intel bugs last night and the curve *is* going down :-)
[21:42] <bryceh> so kudos due to them
[21:42] <bryceh> I'm still concerned with point #3, so wanted to raise an idea
[21:42] <bryceh> a lot of our new bug reports right now are coming from the X freeze handler for -intel
[21:43] <bryceh> I sort of wonder if we have captured "enough" bug reports on freeze issues, that we're in a case of diminishing returns and could turn it off at this point
[21:43] <rickspencer3> bryceh, nice, but I was thinking when the meeting starts in like 17 minutes :)
[21:43] <bryceh> might save some manpower from marking dupes, to focus on getting bugs upstreamed
[21:43] <bryceh> rickspencer3, oh did I slip the gun?
[21:43] <rickspencer3> lol
[21:43] <rickspencer3> a bit
[21:44] <bryceh> ok good, gives me time to update the status 8-)
[21:44] <rickspencer3> but I see  you are uber organized as always
[21:44] <rickspencer3> RAOF, TheMuso Eastern edition is in 16 minutes, right?
[21:44] <ccheney> bryceh: cool it was just that one file that was the problem :)
[21:44] <TheMuso> yep
[21:44] <rickspencer3> or did dst screw up my calendar?
[21:44] <RAOF> rickspencer3: Yup.
[21:44] <RAOF> rickspencer3: No, you're in the right timezone :)
[21:44] <bryceh> ccheney, excellent
[21:45] <bryceh> ccheney, it's probably some weird buggered up svg. still worth a bug report
[21:45]  * ccheney will sync merge the new version from debian and verify it still works and will be done with it :)
[21:45] <ccheney> bryceh: yea
[21:46] <ccheney> 1 rc bug down 3 to go :)
[21:57] <rickspencer3> anyone know what happened to the "don't play a sound with the gdm greeter" thing seb128 was working on?
[21:57] <rickspencer3> oops
[21:57] <rickspencer3> looks like it's not going too well
[22:00] <rickspencer3> TheMuso, bryceh, RAOF, robert_ancell, Eastern Edition?
[22:00] <bryceh> \o/
[22:00] <RAOF> :)
[22:00] <TheMuso> sure
[22:01] <rickspencer3> I haven't had time to update the wiki page, but I pasted in the irc log:
[22:01] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-23
[22:01] <seb128> rickspencer3, the gdm thing didrocks has it almost done, tomorrow should be ready for lucid
[22:01] <rickspencer3> seb128, oh great
[22:01] <rickspencer3> the irc logs suggested that you had punted it
[22:01] <robert_ancell> rickspencer3, yup
[22:02] <seb128> I helped didrocks to figure why his got was not working
[22:02] <seb128> his *code*
[22:02] <rickspencer3> seb128, I was thinking about writing a script to replace the current sound file, and supply a silent ogg with it
[22:02] <seb128> ie we have been debugging that today
[22:02] <rickspencer3> well ...
[22:03] <seb128> not a bad idea, you could have suggested it earlier ;-)
[22:03] <rickspencer3> between seb128, robert_ancell, and didrocks, Ubuntu will truly be the reservoir of GDM knowledge
[22:03] <seb128> we got it working though now so it should be ok
[22:03] <seb128> don't forget pitti
[22:03] <rickspencer3> pitti?
[22:03] <rickspencer3> I did not read the logs that far ;)
[22:03] <seb128> he has been fighting gdm to get multiple keyboard layouts working half of the day today
[22:03] <rickspencer3> oh yes
[22:03]  * rickspencer3 kicks GDM
[22:04] <TheMuso> rickspencer3: A good idea in theory the silent ogg file, but that makes packaging stuff messy.
[22:04] <rickspencer3> TheMuso, it would have been just a total ugly hack
[22:04] <TheMuso> rickspencer3: right
[22:04] <rickspencer3> not a feature or a product
[22:05] <rickspencer3> basically, I was envisioning wget + mv :)
[22:05] <TheMuso> eew
[22:09] <rickspencer3> TheMuso, hehe
[22:09] <rickspencer3> that's how I roll
[22:09] <rickspencer3> TheMuso, RAOF, robert_ancell, bryceh had a chance to look over the log?
[22:09] <RAOF> Just finished.
[22:09] <TheMuso> still looking...
[22:09] <rickspencer3> k
[22:10] <rickspencer3> take your time
[22:10] <bryceh> done
[22:10]  * TheMuso can't scan like you guys can
[22:10]  * rickspencer3 is updating the wiki as  you read
[22:10] <rickspencer3> TheMuso, right, and no rush
[22:10] <TheMuso> yep understood.
[22:10] <bryceh> TheMuso, I caught the tail end of the meeting when I got up this morning, so I'm cheating a bit ;-)
[22:10] <robert_ancell> done
[22:11] <rickspencer3> bryceh, can I ask you to paste your notes directly in teh wiki under == xorg update ==?
[22:11] <bryceh> rickspencer3, ok
[22:11] <rickspencer3> thanks
[22:13] <TheMuso> alright I got the gist of the log.
[22:13] <TheMuso> hopefully I haven't missed anything important whilst reading it.
[22:14] <rickspencer3> TheMuso, I'm sure all is well
[22:14] <TheMuso> ok so I'm done.
[22:14] <rickspencer3> how about if I tough on some high points before turning the mic over to bruce?
[22:14] <rickspencer3> uh
[22:14] <rickspencer3> bryceh, ?
[22:14] <TheMuso> lol
[22:14]  * RAOF didn't know bryce had moved to .au ;)
[22:14] <bryceh> sure
[22:14] <rickspencer3> it's the influence of all you ausies
[22:15] <bryceh> I like aussies :-)
[22:15] <rickspencer3> ok, so music store is out
[22:15] <rickspencer3> in beta
[22:15] <rickspencer3> there are bugs
[22:15] <robert_ancell> yay!
[22:15] <robert_ancell> (not for the bugs)
[22:15] <rickspencer3> OLS has the FFE exceptions
[22:15] <TheMuso> The widget used for web stuff in that is using webkit correct?
[22:15] <rickspencer3> they look doable
[22:15] <rickspencer3> TheMuso, I dunno
[22:15] <RAOF> TheMuso: Correct
[22:15] <TheMuso> ok
[22:15] <TheMuso> thanks RAOF.
[22:15] <rickspencer3> so basically, not accessible
[22:16] <rickspencer3> I think screen readers still can't traverse in there too well, right TheMuso?
[22:16] <TheMuso> rickspencer3: I'll check today, but some work has gone into webkit to fix stuff recently so I'll see how we go.
[22:16] <rickspencer3> that would be nice to know
[22:16] <rickspencer3> thank you for looking into that
[22:17] <rickspencer3> of course, the HTML is not rendered by us, so even if webkit works, no gauruntees
[22:17] <rickspencer3> moving on
[22:17] <rickspencer3> Kubuntu got their beta out despite last minute issues with Plymouth
[22:17] <rickspencer3> lots of work to work around this
[22:18] <rickspencer3> tseliot will fix or has fixed the issue for Kubuntu
[22:18] <TheMuso> Yay plymouth.
[22:18] <rickspencer3> (one of our release critical bugs)
[22:18] <RAOF> Yeah, it's been somewhat of a problem child.
[22:18] <rickspencer3> mozilla update ... looks like the Hardy epiphany backport is nearing completion
[22:18] <rickspencer3> the crasher was figured out by asac, but it means ccheney has lots of recoding to do
[22:19] <rickspencer3> UDS ...
[22:19] <rickspencer3> you should have booked travel by now
[22:19] <TheMuso> booked, will update wiki today.
[22:19] <rickspencer3> if there is any ambiguity about your dates, please ping me out of the channel
[22:19] <rickspencer3> thanks TheMuso
[22:19] <rickspencer3> start thinking about blueprints .. but don't start on them ;)
[22:20] <rickspencer3> stay focused on Lucid for now
[22:20] <rickspencer3> so we also discussed specific bugs and such in release status
[22:20] <rickspencer3> the top line for me is, I would like to see our release critical bugs significantly decrease this week
[22:20] <rickspencer3> get them down to like 10
[22:20] <rickspencer3> so if you have any assigned to you ....
[22:20] <rickspencer3> please fix them
[22:21] <rickspencer3> chriscoulson quit just in time
[22:21] <TheMuso> heh
[22:21] <rickspencer3> any questions before I turn it over to bryceh?
[22:21] <TheMuso> no
[22:21] <rickspencer3> RAOF?
[22:22] <RAOF> No, I'm good.
[22:22] <rickspencer3> ok
[22:22] <rickspencer3> bryceh?
[22:22] <bryceh> I've pasted in the status report into the wiki page
[22:22] <bryceh> https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-03-23
[22:22] <bryceh> briefly:
[22:23] <bryceh> -nouveau has some stability trouble
[22:23] <bryceh> -intel we're getting lots of bug reports but seems at it's usual level of stability
[22:23] <bryceh> -ati seems to be pretty good
[22:23] <rickspencer3> bryceh, it seems my mini 10v has been less stable after repeated suspends and resumes
[22:24] <rickspencer3> does this ring a bell?
[22:24] <seb128> my laptop freezes or crash every second resume there
[22:24] <seb128> i965, dell laptop
[22:24] <bryceh> yes, we have been getting a lot of X freeze reports on -intel
[22:24] <RAOF> If that's suspending by closing the lid, then I think we've got a good candidate to fix the crashes.
[22:24] <bryceh> in fact I want to talk about that a bit more
[22:25] <rickspencer3> ok
[22:25] <rickspencer3> go ahead
[22:25] <bryceh> regarding bug triaging work, we've got a lot of it to do.  I think we made some solid progress this last week
[22:25] <bryceh> in particular, the new x freeze handler is capturing a LOT of bug reports
[22:26] <bryceh> raof and sarvatt did some good hammering on that yesterday and got a lot of dupes done
[22:26] <rickspencer3> bryceh, so I see you are suggesting turning attention from triaging to fixing, am I reading that right?
[22:26] <bryceh> but I'm wondering if we should turn it off - we may already have more reports than we can deal with, and a lot of the new ones may just be dupes
[22:26] <rickspencer3> turn off apport, make what you think are fixes, turn it on again?
[22:26] <bryceh> rickspencer3, righto
[22:27] <rickspencer3> bryceh, if you think it's the right thing, I say "do it"
[22:27] <seb128> we will turn apport off soon for lucid anyway
[22:27] <Sarvatt> rickspencer3: I've been working with apw on the fix for that and I have sent him a fix that we have requested testing on, it fixes the hangs post resume and I have pushed it along upstream
[22:27] <bryceh> seb128, that's my thinking as well
[22:27] <rickspencer3> Sarvatt, thanks for the update
[22:27] <bryceh> I'd defer to raof and sarvatt though as they've been looking at these bugs more closely than me
[22:27] <bryceh> RAOF, Sarvatt, your feelings?
[22:27] <rickspencer3> Sarvatt, RAOF turn off apport for intel freezes?
[22:28] <RAOF> The X freeze bugs are often low-quality, too, partially because of technical flaws and partially because it's a crash report that pops up at some time when the users' not very interested.
[22:28] <Sarvatt> definite yay from me regarding turning it off
[22:28] <rickspencer3> +1, +1
[22:28] <RAOF> I think turning it off is a good idea.
[22:28] <RAOF> +1
[22:28] <bryceh> ok great, I'll make it so
[22:28] <seb128> +1
[22:28] <bryceh> RAOF, how are you doing with bug triaging and upstreaming?
[22:28] <rickspencer3> (oh, my +1s were for Sarvatt and RAOF, I don't think my opinion matters much here ;)
[22:29] <Sarvatt> sorry, was reproducing the lshw funky color problem and I narrowed it down to vga16fb being loaded causing it, haven't read all of the scrollback yet
[22:30] <bryceh> Sarvatt, yeah was looking at that one last week
[22:30] <bryceh> Sarvatt, do we need vga16fb loaded for any particular reason?
[22:30] <RAOF> bryceh: Nouveau's well in hand, at least the bugs that we get reported.  I'm less confident with -intel, but a bit more experience will help there.
[22:30] <Sarvatt> for the fallback splash screen when there is no KMS
[22:30] <bryceh> RAOF, have you been sending the nouveau bug reports upstream?  How's upstream been doing at giving useful feedback?
[22:31] <bryceh> Sarvatt, so maybe something should rmmod that if kms is on?
[22:31] <RAOF> bryceh: They've been going upstream.  Upstream's been giving some useful feedback on the bugtracker, and some in #nouveau, but I feel the need to poke them a bit to get things looked at.
[22:32] <bryceh> ok good
[22:32] <bryceh> well, miles better than -nv :-)
[22:32] <RAOF> One of the things I want to do today or tomorrow is to whip up a script to make mmiotracing easy, and point people at it.
[22:32] <bryceh> RAOF, good
[22:32] <RAOF> Now that the -17 kernel is a gogo.
[22:33] <RAOF> It should be easy to automate the kind of mmiotrace upstream wants, after the user has booted into rescue mode.
[22:34] <bryceh> RAOF, ok we can put that into failsafe-x or something :-)
[22:34] <RAOF> Heh.
[22:34] <bryceh> rickspencer3, ok done
[22:35] <rickspencer3> thanks bryceh
[22:35] <rickspencer3> much appreciated
[22:35] <RAOF> Would we want to do that, though?  mmiotrace is a bit of a niche case :)
[22:35] <bryceh> RAOF, yes
[22:35] <rickspencer3> bryceh, on sum, how do you think graphics quality will compare Lucid versus Karmic?
[22:37] <bryceh> rickspencer3, -intel - about the same.  -ati some performance regression.  nvidia some stability regressions
[22:37] <rickspencer3> so not as good
[22:37] <bryceh> that's if we shipped right now today
[22:37] <rickspencer3> ah
[22:37] <rickspencer3> so what about by April 29th?
[22:37] <bryceh> I have high hopes the next few weeks we can get fixes in to make it improved
[22:37] <rickspencer3> so you think maybe Lucid > Karmic?
[22:37] <bryceh> kms has been a tough seed to digest but we're working on it
[22:38] <Sarvatt> for the intel bugs, we have a few major issues at the moment. 915 through 945 mobile GPU's are hanging with a solid color after resume which I made a patch for to disable framebuffer compression and it will be in soon, DPMS off events that happen from screen blanking, closing the lid or suspend/resume are causing GPU hangs for *alot* of people and the fix for that was in 2.6.32-15 but (accidentally?) dropped in 2.6.32-16 and -17 and I've b
[22:38] <Sarvatt> een pinging the kernel people about it. On ATI we've spotted a few regressions since the 2.6.33 DRM was added in -16 such as flickering on specific chipsets that need to have the default module options quirked to work right. For nouveau I've also seen a few reports where a noaccel quirk would be helpful since it results in an unusable desktop without it.
[22:38] <bryceh> I'm confident by the time we release we can make Lucid an all around more solid experience
[22:40] <RAOF> It would be nice if the nouveau DDX would just bail if it detects that the GPU's locked; it seems like it should be possible.
[22:40] <bryceh> we've got a lot of patches on hand already.  We're also well organized and with better tools and processes than we've ever had at our disposal.  So I think we're going to rock out this next month.
[22:41] <bryceh> RAOF, yeah
[22:41] <bryceh> rickspencer3, over :-)
[22:41] <rickspencer3> kewl
[22:41] <rickspencer3> yeah, sorry, got distracted
[22:41] <rickspencer3> my xchat gnome was like a christmas lights display
[22:41] <rickspencer3> :(
[22:42] <rickspencer3> bryceh, great job this release
[22:42] <rickspencer3> nice to have a steady hand at the helm there
[22:42] <rickspencer3> !
[22:42] <bryceh> oh also, I should mention a lot of these bugs we're fretting about are actually kernel bugs
[22:42] <bryceh> so they involve locating and shepherding in kernel patches
[22:42] <Sarvatt> the *huge* majority of bugs against xserver-xorg-video-intel nouveau and ati are kernel bugs
[22:42] <bryceh> sarvatt's been doing great work at this, as he mentioned
[22:42] <rickspencer3> thanks Sarvatt!
[22:43] <RAOF> Thinking of sponsorship to UDS... :)
[22:43] <rickspencer3> what, huh?
[22:43] <rickspencer3> RAOF, good point
[22:44] <RAOF> Sarvatt: Are you available to come to UDS?  Has bryceh pinged you about that yet? :)
[22:44] <Sarvatt> I put in a request :)
[22:44]  * Sarvatt crosses fingers.
[22:44] <bryceh> yeah I sent names to rick.  rickspencer3 did you pass them along whereever they need to go?
[22:44] <rickspencer3> bryceh, sort of
[22:44] <rickspencer3> I couldn't use the system because of the dash in my lp user name
[22:44] <rickspencer3> but they fixed it today
[22:47] <bryceh> btw, I've been having some fun going through the new milestone report - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/milestone-bugs.html
[22:47] <bryceh> this includes both ones targeted to lucid and ones that were proposed for lucid
[22:48] <bryceh> it's amazing how many nominations are proposed for lucid, but no one actually tested that the bug still exists in lucid.  *boggle*
[22:48] <bryceh> I hope to have that report cleared to 0 by release
[22:48] <RAOF> :)
[22:49] <bryceh> one way or another ;-)
[22:49] <RAOF> Hm.  Is there some way we can get users a better 2d performance testing tool than gtkperf?
[22:50] <RAOF> There's that cairo-tracing work; is that easily accessible?  That would provide a more useful benchmark for people.
[22:50] <bryceh> RAOF, cairo has a really good set of tests
[22:50] <bryceh> yes, that's a really solid test suite
[22:50] <bryceh> cworth is also keen on helping with it, if we have troubles
[22:51] <RAOF> Ok.  So do we just need to advertise it more, or is it actually difficult to run?  What package is it in?
[22:51] <bryceh> for 3d... well I'm contemplating writing a script to auto-close any bug that mentions "glxgears" in its description ;-)
[22:51] <Sarvatt> its not packaged
[22:51] <RAOF> bryceh: Can we patch in --iacknowledgethistoolisnotabenchmark again? :)
[22:52] <bryceh> I recall it being really easy to run... so yeah just needs packaging I guess.  Would be sweet to have
[22:52] <bryceh> RAOF, heh.  In fact I stripped out reporting the fps calculation
[22:52] <bryceh> so now people have to divide in their head to get fps out of it.  Still they do this! :-/
[22:53] <Sarvatt> cairo-perf-trace has a seperate git repo of benchmarks to run thats close to 1GB that you need to grab too
[22:53] <bryceh> wow
[22:53] <RAOF> That's a lot of data.  How many benchmarks are in there?
[22:54] <Sarvatt> 19
[22:54] <bryceh> maybe it'd be best to package a minimal set, targeted at average users
[22:54] <RAOF> I guess it might not be that many; doesn't the test work by recording all the cairo requests & then replaying them?  That'd pull out a lot of data quickly :)
[22:54] <RAOF> And possibly give the option to download more
[22:54] <Sarvatt> that size i said was lzma compressed too.. :D
[22:54] <bryceh> testers that need the full suite are probably more likely to want to run from git anyway
[22:55] <RAOF> You might be able to collect tests into groups, too, based on what sort of performance they're testing?
[22:56] <Sarvatt> you need to mess with env variables while using it anyway, its easy to build, just clone cairo git make perf and clone cairo-traces in the perf directory
[22:56] <RAOF> That's already three big steps harder than gtkperf, which is what we'd like to replace :)
[22:58] <bryceh> I think we put rick to sleep
[22:58] <Sarvatt> there's always xrenderbenchmark - http://cgit.freedesktop.org/~aplattner/xrenderbenchmark/
[22:59] <bryceh> no I think cairoperf is the right way to go
[23:00] <bryceh> but set it up to kind of a minimal configuration
[23:00] <RAOF> It's not synthetic, so you can be confident that it's actually measuring things people care about.
[23:01] <Sarvatt> http://paste.ubuntu.com/400264/
[23:01] <Sarvatt> there's the sizes on the "short" benchmarks :D
[23:02] <RAOF> And those are lzma compressed?
[23:02] <Sarvatt> nope, have to extract to run them
[23:03] <RAOF> So they *are* compressed?
[23:03] <RAOF> Or that's the uncompressed size, because you need to have extracted them to run them?
[23:03] <Sarvatt> when you clone it yeah but thats the extracted sizes, 522MB for the condensed ones
[23:05] <RAOF> I don't think users will mind having big sizes for their benchmark suites.  Download size is I think more of a problem.
[23:43] <RAOF> crimsun: Is it possible at all to work around the crazy bad dB reporting for usb speakers?  It interacts *really* badly with the snapping to 100% that Sound Preferences does.
[23:46] <crimsun> RAOF: yes, it's possible, but you'll lose hot(un)plug via udev.
[23:46] <crimsun> it's documented at DebuggingSoundProblems/KarmicCaveats
[23:46] <RAOF> That's a pretty bad tradeoff for usb speakers :(
[23:46] <crimsun> go smack your usb speakers manufacturer
[23:47] <crimsun> that said, to some degree, it can be hacked around in the usbaudio driver, but that's pretty fragile