[00:37] <asac> kees: is the hardening depends only fulfillable in lucid?
[00:37] <asac> curious, when was that package added?
[00:40] <kees> asac: hardening-wrapper?  it's existed in probably intrepid.
[00:41] <kees> actually, hardy.
[00:42] <asac> good
[00:42] <asac> kees: does it hurt if it ends up being used in hardy?
[00:42] <asac> for firefox 3.6
[00:42] <kees> it shouldn't no.
[00:42] <asac> good ;)
[00:43] <kees> heh, cool
[00:43] <asac> so this will sink down i guess
[00:43] <kees> ?
[00:43] <asac> well, we are working on the firefox 3.6 update
[00:44] <asac> since it has allmost new sysdepends its atm the same for all releases
[00:44] <asac> s/new/no/
[00:44] <asac> not tomorrow ;)
[00:44]  * asac tries to prevent panic ;)
[00:45] <asac> for now i asked because we have the branch in daily ppa for hardy-lucid
[00:45] <kees> heh
[00:45] <kees> asac: it _should_ build for hardy.  I'm looking through the changes since the 1.11 (hardy) version of hardening-wrapper.
[00:46] <asac> kees: we will see soon in daily ppa
[00:46] <asac> i was more scared if it might break runtime behaviour in case it just builds
[00:46] <kees> I don't want to change the version of hardening-wrapper in hardy, so if things go wrong, we can just not enable DEB_BUILD_HARDENING=1 in the rules for that build.
[00:50] <asac> true
[00:56] <asac> kees: guess we should do the same for tbird 3?
[00:56] <asac> its basically the same stub binary
[01:04] <kees> asac: yeah.  anything built from xulrunner should do it.  mostly I'm just trying to uber-harden firefox itself, since it's the #1 vulnerability target.
[01:10] <asac> right
[02:03] <kees> RAOFLOOD :)
[02:03] <RAOF> :(
[02:04] <RAOF> On the up side, once the new gjs is built gnome-shell will finally build on Lucid.
[02:04] <kees> cool!
[02:05] <RAOF> Mozilla libraries are such a pain in the neck!
[02:10] <kees> heh
[02:15] <kees> asac: where should I be watching for the PIE build?  https://code.launchpad.net/~mozillateam/firefox/firefox-3.6.head ?
[02:53] <TheMuso> nhrm ok, we have latest ardour in lucid. Seems it was a sync.,
[03:00] <TheMuso> woops wrong channel.
[07:50] <didrocks> good morning
[08:19] <pitti> good morning
[08:21] <pitti> bryce_: why did you move the alpha-3 items from desktop-lucid-xorg-triaging-diagnosis back to alpha-2? alpha 2 is done and shouldn't get new WIs
[08:21] <didrocks> Guten Tag pitti
[08:23] <pitti> bryce_: I put it back, I assume it was just a glitch
[08:23] <pitti> bonjour didrocks!
[08:30] <seb128> hey there
[08:33] <pitti> hey seb128, bonjour
[08:34] <seb128> hey pitti, guten tag!
[08:34] <seb128> how are you?
[08:35] <didrocks> hello seb128 :)
[08:36] <seb128> hey didrocks
[09:04] <chrisccoulson> good morning everyone
[09:04] <seb128> hey chrisccoulson
[09:04] <didrocks> hello chrisccoulson
[09:05] <seb128> pitti, do you think you could get bootcharts from yesterday and today on your mini or laptop config?
[09:05] <pitti> hey chrisccoulson
[09:05] <seb128> didrocks, ^ or you?
[09:05] <seb128> or somebody who isn't me
[09:05] <seb128> I would like to check how the session change worked
[09:05] <didrocks> seb128: I have a hd, do you want one explicitely on ssd?
[09:05] <chrisccoulson> hey seb128 pitti didrocks
[09:05] <seb128> but my boxes have too much tweaking
[09:05] <pitti> seb128: I dist-upgraded last night, but I can downgrade the panel first
[09:05] <chrisccoulson> how are you all today?
[09:05] <seb128> I'm not sure what part is local and what is in lucid now
[09:05] <pitti> seb128: sure, will do that now
[09:05] <seb128> pitti, no, today's chart should be enough
[09:06] <pitti> seb128: sure, will generate one
[09:06] <didrocks> pitti: do you want a second one?
[09:06] <didrocks> opus
[09:06] <seb128> let see if it does what we want
[09:06] <didrocks> seb128: ^
[09:06] <seb128> didrocks, if you want sure, thanks
[09:06] <seb128> chrisccoulson, good thanks, you?
[09:07] <chrisccoulson> seb128 - yeah, not too bad. just having my first coffee of the day
[09:07] <seb128> hum, coffee!
[09:08] <chrisccoulson> seb128 - i'm just wondering whether this gtk commit should go in to karmic: http://git.gnome.org/browse/gtk+/commit/?id=0748cf563d0d0d03001a62589f13be16a8ec06c1
[09:08] <chrisccoulson> i think that the problem it fixes might be the cause of some panel crashers
[09:09] <chrisccoulson> it fixes the issue we had with the screensaver crashing a while back
[09:09] <seb128> chrisccoulson, do you have any lp bug number matching it?
[09:09] <seb128> chrisccoulson, I'm fine backporting it
[09:10] <seb128> robert_ancell pointed another change worth backporting too
[09:10] <chrisccoulson> seb128 - bug 463168 and bug 510453 look like the same issue
[09:10] <seb128> thanks
[09:11] <seb128> it's a bit of a shame
[09:11] <seb128> we have gtk 2.18.3 in karmic
[09:11] <seb128> and current stable serie has 2.18.6
[09:11] <seb128> and quite some bugs in csw has been fixed there
[09:12] <seb128> but every update has quite some changes and we don't manage to get those going
[09:12] <chrisccoulson> i could do with the reporters providing a good backtrace, just to be sure, but I suspect it is probably the same issue that caused bug 446395 too, which i added a workaround for in gnome-screensaver
[09:12] <chrisccoulson> 2.18.6 might even have that change in
[09:13] <seb128> we will not realistic update now
[09:13] <seb128> realistically
[09:14] <seb128> there some hundred commits between our version and current
[09:14] <chrisccoulson> yeah, that's quite a lot of commits to review
[09:15] <seb128> http://git.gnome.org/browse/gtk+/log/?h=gtk-2-18
[09:15] <seb128> the commit you pointed is in 2.18.5...
[09:16] <seb128> bug #461912
[09:16] <seb128> that seems the same issue
[09:17] <pitti> didrocks, njpatel_: building clutter bzr head fails with
[09:17] <pitti> bar-view.vala:69: error: implicit declaration of function ‘ctk_effect_set_margin’
[09:17] <pitti> didrocks, njpatel_: I suppose this needs some new clutk API?
[09:19] <njpatel_> didrocks, pitti: You mean Clutk + Unity from lp:clutk and lp:unity?
[09:19] <pitti> probably, yes
[09:20] <didrocks> pitti: seems that it needs. There will be a new release of clutk today. Not sure that njpatel_ took it into account (no new clutter needed)
[09:22] <pitti> hm, in fact not
[09:22] <pitti> grep -r set_margin .
[09:22] <pitti> -> no result in lp:clutk
[09:24] <seb128> chrisccoulson, http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-18&id=f2fffaad71c012d110ad79a1f15afdb81c580d2f
[09:24] <chrisccoulson> seb128 - i'm not sure that bug 461912 is the same issue, as that one crashes with SIGSEGV. i could be wrong though
[09:24] <seb128> chrisccoulson, this one might lead to some of the crashes too
[09:25] <seb128> chrisccoulson, that's the one I was having on lucid
[09:25] <seb128> chrisccoulson, well, http://bugzilla.gnome.org/603652
[09:26] <njpatel_> didrocks, pitti: I'm not sure wtf is going on, but I promise it'll be fixed for today's releases
[09:26] <pitti> njpatel: ok, no worries; I was just curious
[09:26] <didrocks> njpatel: ping me if you need a new clutter version too
[09:26] <njpatel> pitti, it seems like some of the commits weren't pushed
[09:27] <njpatel> didrocks, pitti no rush for new clutter version atm -- can wait 'till or after platform sprint -- I'm sure they'll be integration issues
[09:35] <chrisccoulson> seb128 - do you still see these crashes on lucid now?
[09:35] <seb128> chrisccoulson, no
[09:35] <pitti> seb128: http://people.canonical.com/~pitti/bootcharts/ the two daniel* ones
[09:35] <chrisccoulson> thats good to know :)
[09:35] <pitti> seb128: I think it worked as intended
[09:36] <pitti> seb128: just seems that the -11 kernel has some regression to stall early boot by some 5 secs
[09:36] <didrocks> hum, strange, I don't get any bootchart log on my dell, probaly something to set
[09:36] <pitti> didrocks: it's not installed by default
[09:37] <seb128> pitti, yes, thanks
[09:37] <pitti> bootchart and pybootchartgui
[09:37] <didrocks> pitti: I've installed them
[09:37] <pitti> didrocks: and waited long enough?
[09:37] <didrocks> pitti: maybe not, let me look again
[09:37] <didrocks> ok, got them now
[09:37] <pitti> takes about a mintue after the desktop is ready
[09:37]  * seb128 mark the wi as done
[09:38] <didrocks> oh ok, I wasn't aware than making the png was so long :)
[09:38] <didrocks> is there any kind of hook signal when the pictures are ready to upload them automatically somewhere?
[09:38] <seb128> are inotify?
[09:38] <seb128> gvfs-monitor if you want
[09:39] <seb128> gvfs-monitor-dir
[09:39] <didrocks> I'll pick inotify as I'm not used to gvfs-monitor :)
[09:42] <seb128> didrocks, well gvfs-monitor-dir is a command
[09:42] <pitti> gvfs-monitor-dir /tmp/
[09:42] <pitti> touch /tmp/foo
[09:43] <didrocks> seb128: pitti: thanks, I'll have a look at that :)
[09:43] <didrocks> seb128: http://people.canonical.com/~didrocks/mini10v-20100121-1.png
[09:44] <seb128> urg
[09:44] <seb128> hdd?
[09:44] <pitti> didrocks: you need to reboot, that was an ureadahead profiling run
[09:44] <didrocks> seb128: yes, cf ^
[09:44] <didrocks> ok, rebooting
[09:49] <didrocks> ok, ureadahead seems to be active this time: http://people.canonical.com/~didrocks/mini10v-20100121-2.png
[09:53] <seb128> right
[10:06] <pitti> hm, so moving wncksyncdaemon to the start of the desktop chain doesn't help
[10:07] <seb128> we are cpu bounded for most of login anyway
[10:07] <seb128> we need to do less, shuffling will not bring us a lot
[10:08] <pitti> there's a slight CPU drop right at the start, though
[10:08] <pitti> and wncksyncdaemon is a solid CPU block at the very end now
[10:08] <pitti> now I get a very compact block
[10:08] <pitti> OTOH, the difference between two identical boots was already about a second
[10:08] <pitti> so it could just get lost in the noise
[10:09] <seb128> what is wkcnsync using so much cpu for?
[10:09] <pitti> reading all the .desktop files
[10:09] <pitti> it's from the cache, of course (I hope, will check)
[10:09] <pitti> but still takes a lot of time
[10:09] <seb128> shouldn't that be much quicker with the cache?
[10:09] <seb128> well
[10:10] <seb128> I don't see that busy cpu bar on gnome-panel
[10:10] <didrocks> pitti: wncksyncdaemon is started by liblauncher on demand, right? How did you changed the starting point? (adding a .desktop?)
[10:10] <pitti> perhaps it could only be launched when the first real app gets started
[10:10] <seb128> and the menu applet does read those as well
[10:10] <pitti> didrocks: dbus-send in Xsession.d
[10:10] <didrocks> pitti: ok, thanks :)
[10:10] <pitti> seb128: I'll trace it to verify that it's using the cache
[10:11] <seb128> thanks
[10:12] <pitti> jeez, it's indeed reading the .desktop files
[10:12]  * pitti adds a work item
[10:12] <seb128> yes, confirmed there
[10:12] <pitti> and all the .mo files
[10:13] <pitti> and the themes pngs?!?
[10:13] <pitti> ok, that smells like a good piece of work for the morning
[10:14] <seb128> pitti, mo and png is expected
[10:14] <seb128> hum
[10:15] <seb128> I don't confirm the png thing
[10:15] <pitti> it's just access() for the pngs
[10:15] <seb128> right
[10:15] <pitti> it shouldn't try to open() all the .mo files, though
[10:15] <pitti> the gnome-menus cache has them readily translated
[10:16] <seb128> well, it's not using the cache
[10:16] <pitti> right
[10:16] <pitti> seb128 | pitti, mo and png is expected
[10:16] <pitti> ^ why? (except for not using the cache?)
[10:16] <seb128> well, every apps look for translations at start time no?
[10:17] <seb128> the png I though you were saying the icon cache loading
[10:17] <seb128> pitti, strace -e open gmenu-simple-editor 2>&1 | grep locale
[10:17] <seb128> pitti, same issue
[10:17] <pitti> seb128: but those are for translating the .desktop files, not just for translating itself
[10:17] <pitti> also, wncksyncdaemon shouldn't need translations in the first place
[10:19] <seb128> oh right, I see what you mean
[10:19] <seb128> but doesn't the gettext changes we have mean you get a gettext call when trying to get the Name= for a .desktop entry?
[10:19] <pitti> the cache is per-locale
[10:19] <seb128> ok
[10:19] <seb128> so it's all down to "not using the cache"
[10:22] <didrocks> seb128: regarding bug #509182. There are two ways of fixing it: the quick and dirty one which is "if session_name is xxxx, don't record in dmrc". A better way (to my mind), is to see if the .desktop comment contains "failsafe". It just include more code changes. What do you prefer (I guess we can upstream the second one)?
[10:23] <seb128> didrocks, second one seems better
[10:24] <didrocks> ok, more structure changes, let's go (currently only the session name is sent by dbus, I have to do the same for comment) :)
[10:25] <seb128> does anybody get regular wncksync apport crash notifications?
[10:26] <seb128> regular = every few boots
[10:26] <didrocks> I don't boot enough to get them, maybe
[10:27] <pitti> njpatel: right now, windowmatcher.c loads and parses all the desktop files manually, thus circumventing the gnome-menus cache; would it be enough to only look at desktop files which actually belong to applications, i. e. which you can see in the App menu?
[10:28] <seb128> njpatel, which ones are those?
[10:28] <seb128> ups
[10:28] <seb128> pitti, ^
[10:28] <njpatel> pitti, yes it would, and it's something on DBO's plate
[10:28] <njpatel> pitti, hopefully something we can get before platform sprint
[10:28] <pitti> njpatel: I'm happy to work on this right now
[10:29] <njpatel> pitti, Oh, sweet :)
[10:29] <njpatel> pitti, using gnome-menus should work fine
[10:29] <pitti> njpatel: I'd like to either (1) rewrite it using gnome-menus get_tree(), or (2) directly look for the gnome-menus cache and read the cache if it's there
[10:30] <pitti> depending on whether or not we want to introduce a gnome-menus dependency or rather rely on the format of the gnome-menus cache
[10:30] <pitti> the former seems cleaner to me
[10:31] <njpatel> pitti, gnome-menus is better in my opinion (we already have  a dep elsewhere, so it's not such a bad thing) -- We'd need to read applications.menu and settings.menu
[10:31] <njpatel> *better in my opinion too
[10:31]  * pitti agrees
[10:32] <njpatel> pitti, are you going to work on this directly?
[10:32] <pitti> njpatel: well, in a branch/MP
[10:32] <njpatel> pitti, sure, the "directly" was not necessary :)
[10:32] <njpatel> pitti, that's awesome, let me/DBO know if you need any help with that
[10:33] <pitti> njpatel: sure; unlike unity itself, this is stuff that I actually understand, so I'm happy to help out
[10:33] <njpatel> pitti, lol, I'm sure you'd understand Unity too :) Clutter is a lot like Gtk
[10:35] <njpatel> Um, is the need to reload iwlagn model (intel wireless) necessary every other day? Or, better put, is it a known problem?
[10:35] <njpatel> s/model/module
[11:00] <vish> chrisccoulson: hi... has the gnome-screensaver's legacy inhibit patch been removed?
[11:00] <chrisccoulson> vish - yes, it caused a regression
[11:00] <vish> hmm. :(
[11:01] <chrisccoulson> vish - it's been removed in karmic completely, but replaced with something else in lucid
[11:01] <chrisccoulson> but that doesn't work properly yet due to a Xorg bug
[11:01] <vish> chrisccoulson: ah.. k.. i tried with vlc it doesnt work.. maybe xorg then :s
[11:02]  * vish likes the new software center treeview stuff mvo has done :)
[11:05] <seb128> chrisccoulson, http://launchpadlibrarian.net/38183183/gtksru.debdiff
[11:06] <seb128> chrisccoulson, http://launchpadlibrarian.net/38183183/gtksru.debdiff, just uploaded
[11:06] <seb128> chrisccoulson, it should fix some of those crash issues
[11:07] <seb128> the pixmap leak leading to xorg crashing when playing cards seems an annoying issue
[11:07] <seb128> the pixmap leak leading to xorg crashing when playing cards seems an annoying issue
[11:07] <seb128> ups
[11:07] <seb128> hey pedro_
[11:08] <pedro_> salut seb128!
[11:08] <chrisccoulson> seb128 - looks good. hopefully it will fix some of these panel crashes anyway
[11:08] <seb128> gnome-panel crashing is not too much of an issue usually
[11:08] <seb128> it just respawn
[11:09] <tseliot> seb128: what's the command to update the gnome menu?
[11:11] <seb128> tseliot, how update?
[11:11] <tseliot> seb128: if I put a desktop file in /usr/share/applications/ and I want it to show up in the menu
[11:11] <seb128> tseliot, the menu cache on disk you mean? update-gnome-menus-cache
[11:11] <seb128> tseliot, but there should be a trigger for that
[11:12] <seb128> tseliot, the gnome-panel menu uses inotify and will refresh
[11:12] <seb128> tseliot, no need to do anything
[11:12] <tseliot> ok
[11:12] <seb128> do you get some issue?
[11:13] <tseliot> yes, the nvidia-settings icon wasn't in the menu
[11:13] <didrocks> seb128: sometime, it didn't refreshed. I got the same experience on karmic, even when touching .desktop file
[11:14] <seb128> there is a known race bug though
[11:14] <seb128> things using TryExec
[11:14] <seb128> the desktop getting unpacked before the binary sometime
[11:14] <seb128> and gnome-menus goes "hum, the tryexec binary is not there, the menu entry is broken"
[11:14] <pitti> didrocks, njpatel_: just to confirm, ~canonical-dx-team/wncksync/trunk/ is the real upstream for wncksync, yes? it's not ~anjali?
[11:15] <tseliot> seb128: no TryExec here
[11:15] <seb128> ok so I don't know
[11:15] <seb128> patches are welcome
[11:15] <didrocks> pitti: for me, yes, but I prefer I prefer njpatel_ to confirm :)
[11:15] <seb128> ;-)
[11:15] <tseliot> :-)
[11:15] <njpatel_> pitti, didrocks: that has the latest code, yes
[11:15] <pitti> perfect, thanks
[11:23] <pitti> njpatel_: tests/alt-tabber is nice!
[11:23] <njpatel_> Heh, an abandoned experiment I think
[11:23] <seb128> mvo, btw there is a patch in launchpad on s-c for using a stock gtkentry one rather than a sexy widget
[11:24] <pitti> good for testing that I didn't break anything, though
[11:24] <seb128> mvo, dunno if you have seen it, I ran accross the bug yesterday
[11:24] <njpatel_> definitely
[11:25] <pitti> create_desktop_file_table(): real 4,21784 (precision: 1e-09) cpu 0,162763 (precision: 1e-09)
[11:25] <pitti> so, that's definitively too much (that's with cold cache)
[11:25] <seb128> it's on your laptop right?
[11:25] <pitti> right
[11:27] <mvo> seb128: thanks, i check after lunch
[11:27] <seb128> mvo, bug #506811
[11:27] <seb128> for reference
[11:28] <seb128> mvo, enjoy lunch!
[11:37] <njpatel> didrocks, https://edge.launchpad.net/clutk/0.3/0.3.8 & https://edge.launchpad.net/unity/0.1/0.1.8
[11:37] <didrocks> njpatel: hehe, I was already monitoring :)
[11:48] <LLStarks> hi
[11:48] <TeTeT> asac: I've got an open question from a customer on modemmanager, see question 98187, https://answers.edge.launchpad.net/ubuntu/+source/network-manager/+question/98187
[11:49] <LLStarks> certain prompts are being randomly italicized
[11:49] <LLStarks> http://img193.imageshack.us/img193/5424/italicsupdating.png
[11:59] <asac> TeTeT: have to check with dan on that
[12:03] <gnomefreak> problem = if you remove "FUSA" from panel and try to add it back on you lose your gnome-panels  what is the app i file a bug against?
[12:28] <TeTeT> asac: ok
[12:33] <TeTeT> asac: another query on nm: according to  http://wiki.ubuntuusers.de/NetworkManager/Dispatcher  I can have a script for pre-up, up, down, post-down. Is this really true? THe customer made a test and found only pre-up and post-down to be working?
[12:34] <asac> TeTeT: the customer is right
[12:35] <asac> pre-up post-down? i thought it was flipped: e.g. post-up and pre-down ;)
[12:35] <TeTeT> asac: quite possible
[12:35] <asac> if oyu need the details i can check. but its definitly true that not all four are available
[12:35] <TeTeT> asac: no need for details, I write them that the doc is wrong
[12:36] <asac> yes
[12:36] <asac> whatever they find its a feature
[12:36] <asac> ;)
[12:38] <TeTeT> asac: he he
[12:39] <pitti> create_desktop_file_table(): real 1,07993 (precision: 1e-09) cpu 0,0911074 (precision: 1e-09)
[12:39] <pitti> now, much better
[12:39] <seb128> waouh!
[12:39]  * seb128 hugs pitti
[12:39] <pitti> 4.2 -> 1.6 secs
[12:39]  * pitti commits and pulls branch to the netbook
[12:39] <pitti> erm, 1.08 secs, I mean
[12:45] <seb128> njpatel, ^ see
[12:46] <njpatel> pitti, awesome!
[12:52] <pitti> trunk: cold cache: 0.453 (real), 0.29 (cpu)    hot cache: 0.17 (real), 0.16 (cpu)
[12:52] <pitti> speedup: cold cache: 0.19 (real), 0.13 (cpu)   hot cache: 0.09 (real), 0.08 (cpu)
[12:53] <pitti> ok, that's something
[12:53] <seb128> on what config?
[12:53] <seb128> the mini ssd?
[12:53] <pitti> yes, on the mini 10
[12:53] <pitti> njpatel: do you think the delay is small enough to call create_desktop_file_table() on demand?
[12:53] <pitti> it would mean to introduce a 0.3 s latency to the unity bar for the first app you start
[12:54] <pitti> not sure whether that's worth it
[12:54] <njpatel> pitti, I think it could be acceptable to call it the first time we actually need it
[12:54] <pitti> it might be a dirty trick if we need some more 0.3 secs in the end
[12:54] <seb128> I would tend to say that trading login speed for user action reactivity is not a good deal
[12:54] <pitti> I'll do some experiments, but won't commit that lazy thing for now
[12:54] <njpatel> pitti, seeing as startup-applications start at the end of the startup cycle
[12:55] <seb128> having things apparently loaded but slugish really sucks for the user experience
[12:55] <pitti> oh, and my numbers above were with -O0 -g
[12:55] <pitti> seb128: *nod*, that's why I'm asking; it wouldn't delay the app itself, just the display of it in the unity bar
[12:57] <huats_> hello everyone !
[12:58] <didrocks> hey huats_ o/
[12:58] <huats_> hey didrocks
[13:03] <seb128> hi huats_
[13:11] <pitti> seb128: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100121-unity-wncksynccache.png -> won half a second
[13:11] <pitti> \o/
[13:11] <pitti> I'll hammer on this some more after lunch
[13:12] <seb128> pitti, you rock!
[13:20]  * didrocks hugs pitti
[13:36] <tjaalton> hmm there's no way to get gdm display the username field on start? now I need to click on "other" first
[13:45] <seb128> tjaalton, there is a bug open about that
[13:46] <tjaalton> seb128: ok, I'm going through them now and will subscribe
[13:47] <seb128> tjaalton, bug #463029?
[13:47] <tjaalton> seb128: yep, that's it, thanks
[13:48] <seb128> np
[13:51] <tseliot> james_w: is there some script which updates bzr branches for ubuntu packages after we upload new revisions? (e.g. lp:ubuntu/nvidia-graphics-drivers)
[14:03] <njpatel> seb128, how do I find out which packages are available for ARM in lucid?
[14:06] <seb128> njpatel, get the ftp index for the arch?
[14:07] <seb128> njpatel, ie use http://ports.ubuntu.com/dists/lucid/main/binary-armel/?
[14:08] <seb128> njpatel, I've no good reply otherwise...everything should be available there
[14:08] <seb128> njpatel, do you look for some specific information?
[14:08] <seb128> hey tedg
[14:08] <njpatel> seb128, yeah, if gir1.0-clutter-gtk-0.10 is available on armel
[14:08] <tedg> Good morning seb128
[14:08] <njpatel> seb128, oh, I didn't think of ftp, thanks
[14:08] <njpatel> tedg, morning dude
[14:08] <tedg> Today is release day!  It's like Christmas with less crying.
[14:09] <seb128> njpatel, that's easier
[14:09] <tedg> Good morning njpatel
[14:09] <seb128> njpatel, check https://edge.launchpad.net/ubuntu/+source/clutter-gtk/0.10.2-0ubuntu4
[14:09] <seb128> it "failed to upload" on armel
[14:09] <njpatel> seb128, oh, of course...thank you :)
[14:10] <seb128> urg
[14:10] <seb128> wrong source
[14:10] <seb128> njpatel, https://edge.launchpad.net/ubuntu/+source/clutter-gtk-0.10/0.10.2-1ubuntu1
[14:10] <seb128> "subprocess.CalledProcessError: Command '['../libtool', '--mode=link', '--tag=CC', '--silent', 'gcc', '-o', '/build/buildd/clutter-gtk-0.10-0.10.2/clutter-gtk/tmp-introspectayUFt_/GtkClutter-0.10', '-g', '-O2', '-g', '-Wall', '-O2', '-L.', '-lclutter-gtk-0.10', '-pthread', '-Wl,--export-dynamic', '-lgio-2.0', '-lgirepository-1.0', '-lgobject-2.0', '-lgmodule-2.0', '-lgthread-2.0', '-lrt', '-lffi', '-lglib-2.0', '/build/buildd/clutter-gtk-0.1
[14:10] <seb128> 0-0.10.2/clutter-gtk/tmp-introspectayUFt_/GtkClutter-0.10.o']' returned non-zero exit status 1"
[14:10] <seb128> njpatel, I'm retrying now, let's see
[14:11] <njpatel> seb128, I wish we switched of introspection building -- it's such a pile of crap
[14:11] <njpatel> (I like the idea, it just fails so easily)
[14:11]  * njpatel is just venting and knows that other projects need the gir files
[14:11] <seb128> njpatel, why do you care about knowing if it built on armel then? ;-)
[14:12] <njpatel> seb128, clutk also has introspection building -- so fails when we don't have clutter's gir files
[14:12]  * tedg thinks njpatel needs to take the American attitude and tell those projects to fend for themselves!
[14:12] <seb128> tedg, your new indicator refuses to fail
[14:13] <seb128> the only thing i get in logs in assertion icons[0] != '\0' failed
[14:13] <tedg> seb128: :(  Uhg, I hate fixing things that I don't know what caused them.
[14:13] <njpatel> tedg, are you sure that wouldn't be taking over the projects, draining their resources and then leaving them to fend for themselves? ;-)
[14:13] <tedg> seb128: Yes, I need to fix that.
[14:13] <tedg> njpatel: Heh, the UK did that first, they got the patent.  See Africa ;)
[14:14] <njpatel> tedg, :)
[14:16] <njpatel> interesting -- I removed #ubuntu from my xchat favourites, thinking I could save a few polar bears in the power it must take for xchat to update it -- but it keeps coming back when I start xchat
[14:16]  * vish pokes njpatel ...  [whispers upload evolution-indicator for lucid]
[14:17]  * njpatel hides
[14:18] <njpatel> vish, I'm using it on lucid right now -- is there an issue? (Apart from maildir errors, which I'll fix for A3)
[14:19] <vish> njpatel: the pop3 accounts fix .. let me grab the bug#
[14:19] <njpatel> vish, has that not landed in Lucid?
[14:20] <vish> njpatel: nope > Bug #436755 :(
[14:21] <njpatel> evolution-indicator:
[14:21] <njpatel>   Installed: 0.2.4-0ubuntu6
[14:21] <njpatel> vish, 0.2.4 should contain the fix, but I'll add it to the TODO, it may be broken again
[14:22] <vish> njpatel: thanks.. :) [seems broken]
[14:24] <seb128> njpatel, no it doesn't
[14:24] <seb128> njpatel, sorry it does
[14:24] <seb128> or not
[14:24] <seb128> http://launchpadlibrarian.net/36899885/evolution-indicator_0.2.4-0ubuntu2_0.2.4-0ubuntu5.diff.gz
[14:24] <vish> njpatel: the menu shows the account names , instead of just "Inbox" ...[iirc it was the workaround you mentioned working in karmic]
[14:24] <seb128> njpatel, I bet somebody forget to bzr add the file
[14:25] <seb128> njpatel, I will fix that
[14:25] <njpatel> seb128, okay, thanks -- I'll make a proper release of evo-indicator too, if that helps
[14:25] <seb128> would be nice
[14:26] <seb128> njpatel, https://edge.launchpad.net/ubuntu/+source/clutter-gtk-0.10/0.10.2-1ubuntu1/+build/1441322
[14:26] <seb128> njpatel, the gir built on armel now
[14:26] <njpatel> seb128, wow, thank you :)
[14:26] <seb128> you're welcome
[14:39] <njpatel> seb128, could you do what you did for arm ,but for sparc & ia64? (same package) :)
[14:41] <pitti> njpatel: ok, sent a merge request
[14:42] <seb128> njpatel, I did retry the sparc build before too
[14:42] <njpatel> pitti, great, thanks -- will get Dbo to remove
[14:42] <njpatel> s/remove/review
[14:42] <seb128> njpatel, let me look if the ia64 failed I didn't see that
[14:43] <njpatel> seb128, oh, okay, I'll wait then, thanks
[14:43] <seb128> ia64 is depwait
[14:44] <seb128> I bet something else failed
[14:44]  * seb128 looks for gir-repository-dev
[14:45] <seb128> njpatel, retried gir-repository on ia64
[14:45] <seb128> njpatel, that should unblock it if the build works
[14:45] <njpatel> seb128, great, thanks again
[14:46] <seb128> njpatel, you're welcome
[14:49] <pitti> didrocks: you noticed that clutk is depwaiting on libglew1.5-dev ?
[14:49] <didrocks> pitti: right, I'm trying to finish something on gdm first
[14:49] <pitti> didrocks: sure, just wanted to know whether you're aware (since depwaits don't get mailed)
[14:53] <didrocks> pitti: btw, I don't understand why it's dep waiting (E: Couldn't find package libglew1.5-dev
[14:54] <didrocks> no version referred and rmadison told me we have it in lucid
[14:54] <didrocks> oh maybe in universe
[14:54] <didrocks> right, that's it
[14:54] <pitti> right, needs an MIR
[14:54] <didrocks> ok, let's keep MIR reports for the end of the day  :)
[14:55] <seb128> can we promote it and deal with paperwork later?
[14:55] <pitti> didrocks: sure; I built it from bzr for now
[14:55] <seb128> to get things moving
[14:55] <seb128> I'm eager to test weekly updates
[14:55] <pitti> seb128: we need a tracking bug at least
[14:55] <seb128> didrocks, can you open one?
[14:56] <didrocks> seb128: doing it right now
[14:56] <seb128> thanks
[14:57] <pitti> didrocks: nevermind
[14:57] <pitti> didrocks: it was in main until jaunty
[14:57] <pitti> and looks fine in PTS
[14:57] <pitti> promoted
[14:58] <didrocks> bug #510680
[14:58] <didrocks> thanks pitti
[14:59] <ubott2> Launchpad bug 510680 in glew "[MIR] Main Inclusion Request on glew" [Undecided,In progress] https://launchpad.net/bugs/510680
[15:00] <pitti> (closed)
[15:00] <didrocks> that was fast (:
[15:04] <rickspencer3> canonical-desktoppers ...
[15:05] <rickspencer3> my last email about objectives should have said objectives need to be "logged", not "done"
[15:05] <rickspencer3> moving up completion of objectives would be a bit harsh considering they aren't in the system
[15:05]  * rickspencer3 disables ability to send email before 7am
[15:05] <seb128> ok
[15:05] <seb128> lol
[15:05] <seb128> tedg, I got the me menu empty now, nothing in the logs...
[15:06] <seb128> tedg, the 2 indicator logs in .cache
[15:06] <tedg> seb128: Is there a service running?
[15:06] <tedg> (the me service in particular)
[15:08] <seb128> tedg, sorry I managed to crash things and I'm not in the buggy state anymore
[15:08] <seb128> tedg, but the chart shows it didn't run normally on boot
[15:08] <seb128> it run for 1 second and stopped
[15:09] <seb128> dunno if it crashed or exited for a reason or something
[15:09] <seb128> on normal chart it's started and keep running
[15:09] <seb128> on this one the bar is a one second one
[15:09] <seb128> and it's not restart before end of login
[15:11] <seb128> didrocks, where is your une gnome-panel config?
[15:12] <didrocks> seb128: my last changes aren't put, you can pull my branch from lp:ubuntu/ubuntu-netbook-default-settings
[15:12] <seb128> didrocks, not the new one, just the gnome-panel une config
[15:12] <seb128> the one I got at the sprint
[15:12] <seb128> one bar, set of applets, etc
[15:13] <didrocks> seb128: cf #distro
[15:20] <tedg> seb128: 1 second is an odd time.  I don't think that we have any 1 second timeouts.  Hmm.
[15:20] <tedg> seb128: Can you show me the boot chart?
[15:23] <seb128> tedg, http://people.canonical.com/~seb128/bootchart/seb-dellmini-lucid-20100121-ted.png
[15:23] <seb128> tedg, it's quite to the bottom between notify-osd and gconf lines
[15:23] <tedg> seb128: <snif> This is the very first time someone has named a boot chart after me <snif> <snif>  I'm so touched  :)
[15:23] <seb128> lol
[15:23] <tedg> seb128: Thanks!
[15:24] <seb128> np
[15:28] <rickspencer3> tedg, sorry, but it's named after the moth in Bone
[15:29]  * tedg gets out his "enemies" list to add a name...  ;)
[15:30]  * tedg wonders if you can measure the success of a President based on how many jokes make it into common folklore about their Presidency.
[15:33] <mvo> does anyone has idea where  ImportError: PyGI support not enabled comes from?
[15:33] <tedg> mvo: PyGI is the Python GObject introspection stuff, right?
[15:34] <mvo> not sure I see it in my pygtk stuff in lucid
[15:34] <mvo> e.g. https://bugs.edge.launchpad.net/ubuntu/+source/software-center/+bug/509115
[15:34] <mvo> but multiple others
[15:35] <tedg> mvo: Sorry, that's the extent of my Python knowledge.  In C the compiler tells us this stuff :)
[15:35] <mvo> heh :)
[15:36] <seb128> mvo, do you get the issue too?
[15:36] <mvo> yes
[15:36] <mvo> not always, but often
[15:37] <seb128> how?
[15:37] <mvo> it seems to be happening at random when I import stuff, give me a sec I see if I can still reproduce it
[15:44] <mvo> seb128: just clicking around in software-center triggers it for me, let me try and see if I get a better way
[15:45] <seb128> mvo,  bug #507106
[15:46] <mvo> yes, that is a odd one
[15:46] <seb128> mvo, the error comes from pygobject
[15:46] <seb128> we do built it without pygi
[15:46] <seb128> but I'm not sure how that can run into that error on normal use...
[15:50] <mvo> seb128: could it be a side-effect from using webkit?
[15:51] <seb128> mvo, I don't understand enough of the issue to say
[15:52] <mvo> ok
[15:52] <seb128> having a testcase would be nice though
[15:59] <tedg> seb128: I think this will fix your issue: https://code.launchpad.net/~ted/libindicator/watch-fail-restart/+merge/17823
[16:00] <seb128> tedg, will that be in today's update?
[16:00] <desrt> hi kids
[16:00] <seb128> tedg, how did you figure what was wrong? why isn't any error logged?
[16:00] <seb128> hey desrt
[16:00] <tedg> seb128: Hopefully, need to ping someone for a review.
[16:00] <tedg> Howdy desrt
[16:00] <desrt> the texan identifies himself
[16:01] <tedg> seb128: I think that what's happening is that the "Watch" is sent before the dbus interface comes up.
[16:01] <tedg> seb128: So it's basically a race condition, a very improbable one, but a race condition.
[16:01] <desrt> tedg: looks like there are still a lot of core design questions flying around about dbusmenu
[16:01] <seb128> on the chart the indicator is there stlightly before the dbus-daemon bar
[16:02] <seb128> desrt, do you feel better this week btw?
[16:02] <desrt> much much
[16:02] <seb128> good ;-)
[16:02] <desrt> still a bit stuffy but it usually takes a couple of weeks to get completely over that
[16:02] <desrt> plus, it's still frickin' cold out
[16:02] <tedg> desrt: ? I'm not sure about core design issues, but it's evolving.  There's issues with NotificationStatus stuff, but I consider that different :)
[16:02] <pitti> hey desrt *hug* nice to hear that you feel better
[16:02] <tedg> seb128: I'm not sure that we can trust the accuracy of the graphic to that level of detail :)
[16:02] <desrt> pitti: i hear you had an interesting panel patch....
[16:02] <seb128> tedg, right ;-)
[16:03] <pitti> desrt: I do?
[16:03] <desrt> menu caching
[16:03] <seb128> desrt, gnome-menus
[16:03] <pitti> ah
[16:03] <desrt> oh.
[16:03] <pitti> desrt: yes, I discussed that with vuntz
[16:03] <desrt> uh.  "i love gnome menus"?
[16:03] <seb128> lol
[16:03] <pitti> desrt: but before he accepts it he wants it to use gvariant
[16:03] <seb128> untz untz untz!
[16:03] <desrt> pitti: ya.  i heard that.
[16:03] <desrt> just wanted you to know that i'm here if you have questions or need help
[16:04] <pitti> desrt: I'd love to port it to gvariant
[16:04] <desrt> gvariant suddenly became a bit of a moving target :(
[16:04] <pitti> desrt: my main question is whether it's realistic that it'll land in glib soon
[16:04] <desrt> mclasen is saying that he wants some API changes before accepting it
[16:04] <desrt> so sorry about that
[16:04] <pitti> oh
[16:04] <desrt> but the flavour will remain largely unchanged
[16:04] <desrt> most changes are to details of the typesystem
[16:05] <desrt> ie: it's safe to write code against the current API but expect some small tweaks to be required soon
[16:05] <desrt> but yes.  i'd say it's realistic to assume it will merge this cycle
[16:05] <desrt> particularly because of mclasen's renewed interest in it
[16:06] <desrt> also: rob taylor just told me to increase my hours per week and dedicate the extra hours to working on GVariant/dconf
[16:06] <desrt> (since i was working entirely on non-related projects before)
[16:07] <desrt> also: seb mentioned that you were considering vendor-patching GVariant into glib... and that scares me enough to make me want to work to make sure it doesn't happen :)
[16:09] <seb128> desrt, lol
[16:10] <seb128> desrt, good thing ;-)
[16:10] <seb128> the GNOME3 for next cycle seems to becoming really short
[16:10] <seb128> if we want all the new techs for GNOME3
[16:10] <desrt> ya.  of course :)
[16:10] <seb128> ie dconf...
[16:10] <desrt> who knows.  maybe it gets bumped again :p
[16:10] <desrt> thing is...
[16:10] <desrt> dconf wants to use gdbus now.  a lot.
[16:10] <seb128> mvo, <svdlinden> seb128: ok, I see why
[16:10] <desrt> but davidz is not having time to work on that now
[16:10] <seb128> mvo, about your bug
[16:10] <mvo> oh
[16:11] <mvo> nice
[16:11] <seb128> ;-)
[16:11] <desrt> everyone who is doing all the cool new work is, unfortunately, having "other work" to do
[16:11] <mvo> I saw it now at least in 5 different bugreport with a bunch of dupes each
[16:12] <seb128> mvo, seb128: that's triggered when an enum or a flag is being used, right?
[16:13] <mvo> well, possible
 ok
[16:13] <seb128>  will fix that
[16:13] <seb128> mvo, ^ let's see
[16:13] <seb128> mvo, I will backport to lucid when it's there
[16:13] <mvo> seb128: nice, send him virtual *THANKS* from me
[16:14] <jcastro> mvo: I sent you a mail about apt-daemon, do you happen to know what it uses the notification-area for?
[16:15] <seb128> mvo, the review thing in s-c is pretty cool btw
[16:18] <mvo> jcastro: right, sorry that I have not responded. it has a build-in set of gtk widgets and helps that use it to dipslay progress
[16:18] <mvo> jcastro: we don't use that by default though
[16:18] <mvo> seb128: yeah, I like it too
[16:19] <jcastro> mvo: that's what I suspected, I couldn't actually find the functionality at all
[16:19] <seb128> mvo, do you put random rating?
[16:19] <seb128> mvo, or where do you get the datas from?
[16:19] <mvo> seb128: no, its based on popcon currently
[16:19] <seb128> nice
[16:20] <seb128> do you plan to get reviews for lucid?
[16:20] <mvo> once we have review data, that is going to be replaced of course
[16:20] <mvo> well :)
[16:20] <seb128> or you just put to label to have an idea how it looks?
[16:20] <mvo> the client is ready
[16:20] <seb128> you rock ;-)
[16:20] <mvo> we need a server
[16:20] <pitti> seb128, asac: the gnome-settings-daemon "xsettings" plugin calls xrdb, which is pretty expensive: it delays the entire desktop startup by some 0.3 seconds
[16:20] <seb128> you just need to do a launchpad rotation now ;-)
[16:20] <seb128> pitti, right, I already discussed that with chrisccoulson
[16:20] <pitti> seb128, asac: it queries for Xft.* resource settings, but we don't have any
[16:21] <pitti> in /etc anyway
[16:21] <seb128> pitti, we do
[16:21] <seb128> well it builds the file on the fly
[16:21] <pitti> I checked that the other xrdb calls in Xsession.d/ and the g-s-d xrdb plugin are harmless
[16:21] <seb128> the xrdb option is off by default
[16:22] <chrisccoulson> hey
[16:22] <bittin> hi
[16:22] <pitti> oh, right, this invocation _sets_ X resources
[16:22] <mvo> seb128: or I just use launchpadbugs as the store backend (bug #505983)
[16:22] <seb128> pitti,
[16:22] <seb128>         g_string_append_printf (add_string,
[16:22] <seb128>                                 "Xft.antialias: %d\n",
[16:22] <seb128>                                 settings->antialias);
[16:22] <pitti> seb128, chrisccoulson: ah, so you discussed that already? what was the result?
[16:22] <seb128> etc
[16:22] <seb128> pitti, that those calls are required for openoffice to look correct
[16:23] <pitti> seb128: right, it sets those; I disabled xrdb (chmod 0) and see no obvious difference, though; does it only apply to non-GNOME progs?
[16:23] <pitti> ah
[16:23] <seb128> we didn't come to a "how to fix that"
[16:23] <seb128> pitti, see 40_xres_lcddefault.patch
[16:23] <chrisccoulson> is it actually blocking the session from loading? if it is, then we can probably fix that, but i didn't think that the xsettings plugin blocked on waiting for xrdb to finish
[16:24] <seb128> pitti, that one was added previous cycle by asac to fix openoffice issues
[16:24] <seb128> LP#271283
[16:24] <pitti> indeed, document font in OO.o looks slightly weird
[16:25] <pitti> chrisccoulson: apparently: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100121-unity-wncksynccache.png
[16:25] <pitti> chrisccoulson: the rest only starts once the plugin is done
[16:26] <pitti> well, it might be a red herring
[16:26] <njpatel> seb128, https://edge.launchpad.net/evolution-indicator/0.2.0/0.2.6
[16:26] <seb128> njpatel, thanks
[16:26] <seb128> pitti, it does there too IIRC
[16:31] <pitti> seb128, chrisccoulson, asac: hm; couldn't we move that xrdb call into /usr/lib/openoffice/program/soffice ? (it's just a shell script)
[16:32] <chrisccoulson> is it definately only openoffice which requires it?
[16:32] <seb128> pitti, we need to get the values from gconf and it's not openoffice specific
[16:32] <chrisccoulson> i'm slightly confused why it blocks the whole session though. i just had a look at the code and i can't see why it would
[16:33] <seb128> but I guess we don't have so many applications using non standard toolkits
[16:33] <pitti> I don't know; I just know that the desktop itself looks just fine, and OO.o's menus etc. do as well
[16:33] <seb128> chrisccoulson: doesn't it wait for the xsettings to be done to register?
[16:33] <pitti> xsettings does a lot more
[16:33] <pitti> liek setting the theme, etc.
[16:33] <rickspencer3> stormy_, hi!
[16:33] <pitti> if you chmod 0 the plugin, you don't have anything regarding themes, fonts, etc.
[16:33] <pitti> so it does make sense for g-s-d to block on it
[16:34] <pitti> (on the plugin, not on xrdb in particular)
[16:34] <seb128> right
[16:34] <chrisccoulson> seb128 - yeah, it sets the theme and stuff up before progressing, but xrdb is spawned asynchronously so that it doesn't block anything else from loading
[16:34] <seb128> I would expect to the xsettings in the list of things to do before acking the session registration
[16:34] <chrisccoulson> (or thats how i think it's meant to work)
[16:34] <chrisccoulson> yeah, the xsettings stuff is done before the rest of the session starts loading
[16:34] <seb128> well maybe it just hammers cpu enough to create the delay
[16:35] <mvo> seb128: patch for libsexy removal on software-center looks great, but I need a contributor agreement before I can accept it :(
[16:35] <seb128> oh come on
[16:35] <pitti> chrisccoulson: it does spawn async, but it sets a callback (child_watch_cb) and apparently waits for it to finish
[16:35] <mvo> seb128: I know, I don't like it myself, but I asked and was told "even for one line diffs"
[16:35] <pitti> mvo: really? but isn't that only an issue of copyright?
[16:36] <pitti> if a patch doesn't add a (c) line, why do we need to bother?
[16:36] <mvo> pitti: oh? well, if that is so then I should be fine :)
[16:36] <pitti> mvo: well, IANAL
[16:36] <pitti> and I heard different opinions about it
[16:36] <chrisccoulson> pitti - i'm not sure it waits. g-s-d should enter the main loop after spawning xrdb, which means it will have forked already, so the rest of the session should start loading
[16:37] <chrisccoulson> pitti - i wonder if the write() to the pipe blocks?
[16:37] <chrisccoulson> after spawning xrdb
[16:38] <chrisccoulson> if so, then that's easy to fix. we just defer the write until the main loop (or defer spawning xrdb entirely until the main loop)
[16:42] <tseliot> pitti: it looks like udev loads the wrong nvidia module and this doesn't work: http://pastebin.ubuntu.com/360148/
[16:43] <tseliot> any ideas?
[16:43] <tseliot> otherwise we could try this patch: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/udev/current/SOURCES/udev-146-coldplug.patch?revision=417228&view=markup
[16:43] <pitti> oh, I didn't know it was possible to specify more than one module name with blacklist
[16:44] <tseliot> did I?
[16:44] <tseliot> oh
[16:44]  * tseliot is too tired
[16:44] <pitti> blacklist nouveau nvidia-173 nvidia-96
[16:44] <tseliot> ok
[16:44] <pitti> tseliot: man modprobe.conf doesn't mention that possibility
[16:44] <pitti> perhaps try with single arguments?
[16:44] <tseliot> yes, I did it correctly when I tested the 1st time
[16:44] <tseliot> and it worked
[16:45] <tseliot> but now it wasn't working any more
[16:45] <pitti> well, mod probing is sheer luck if more than one matches, AFAIK
[16:45] <tseliot> obviously because of this ;)
[16:45] <tseliot> yes, I know
[16:46] <pitti> chrisccoulson: like put the entire xft_settings_set_xresources() method in a g_idle_add() ?
[16:47] <chrisccoulson> pitti - yeah, that's what i was thinking
[16:48] <pitti> chrisccoulson: I'll turn that into a work item for now, if you guys think that we need to keep it in g-s-d in the first place
[16:48] <pitti> (it seems an odd place to be to me -- what do other DEs do?)
[16:49] <pitti> i. e. if it affects OO.o, why shouldn't OO.o do it? (wouldn't it look wrong in Xubuntu/KDE?)
[16:49] <seb128> pitti, where would you put it?
[16:49] <seb128> pitti, because it's not openoffice specific
[16:49] <seb128> it happens to other software using the same toolkit
[16:49] <seb128> or emacs
[16:49] <seb128> etc
[16:49] <pitti> ok
[16:49] <pitti> so every DE needs to implement this?
[16:50] <seb128> right
[16:50] <pitti> (sorry for stupid questions)
[16:50] <seb128> or put an Xsession.d script
[16:50] <seb128> or don't care the few legacy apps looking bad
[16:50] <seb128> + openoffice
[16:54] <pitti> thanks for the heads-up; added a WI for this
[16:55] <seb128> pitti, thanks, I had it on https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/StartupSpeed
[16:55] <seb128> but I did use the whiteboard by then
[16:55] <seb128> pitti, cf https://bugzilla.gnome.org/show_bug.cgi?id=586276
[16:56] <didrocks> well, restarting to see if my gdm changes work
[16:56] <seb128> pitti, that has a patch to do similar work without using xrdb
[16:56] <seb128> did*n't* use
[16:58] <pitti> sweet, I'll try that
[17:00] <pitti> seb128: it's not a patch, but it shows how to do it
[17:00] <seb128> pitti, ok, I don't remember details I looked at that in early december
[17:01] <seb128> pitti, but the idle callback is probably good enough for now
[17:07] <didrocks> seb128: any idea how to activate the debug traces for gdm?
[17:08] <seb128> custom.conf key?
[17:09] <seb128> or drop patch 26
[17:09] <didrocks> seb128: ok, and then, it'll be on /var/log/gdm, right?
[17:09] <seb128> syslog
[17:09] <seb128> common/gdm-settings-keys.h:#define GDM_KEY_DEBUG "debug/Enable"
[17:09] <seb128> so debug section enable key
[17:09] <seb128> in the config
[17:11] <mvo> seb128: looks like current gtk+ does not clear some internal markup when used with gtk_label_set_markup() first (via glade) and then with _set_text() - bug #508220
[17:11] <didrocks> seb128: thanks :)
[17:11] <seb128> np
[17:12] <seb128> mvo, could you open an upstream bug?
[17:14] <pitti> seb128: I actually think it'd be easier to just do with proper X calls
[17:14] <pitti> and faster, too
[17:16] <seb128> ok
[17:18] <mvo> seb128: will do (tomorrow)
[17:23] <seb128> mvo, thanks
[17:23] <seb128> mvo, pygobject fix uploaded, please test the update tomorrow morning and let me know if it works
[17:23] <seb128> mvo, I didn't find a reliable way to trigger the crash so I'm not sure how it works
[17:24] <mvo> seb128: nice, many thanks. I will instlal it and keep my eyes open
[17:24] <mvo> (and close a gazillion bugs in s-c ;)
[17:24]  * mvo hugs seb128
[17:24] <seb128> I've closed the ones I found
[17:24]  * seb128 hugs mvo
[17:37] <didrocks> seb128: that was a trap. Dropping the debug patch remove all gtkentry items for me :)
[17:39] <seb128> ?
[17:39] <seb128> the patch just workaround the unstable version check
[17:41] <didrocks> strange, I tried it again and same issue.
[17:42] <didrocks> well, I'm using the custom.conf key now :)
[17:44] <Nafai> question regarding the porting to app-indicators for Transmission.  Even though app-indicators has fall-back to GtkStatusIcon, since this is hoping to go upstream, should I do some #ifdefs and continue to support the old GtkStatusIcon stuff for when this is compiled without the app-indicators library?
[17:45] <seb128> yes
[17:46] <Nafai> thanks, just making sure
[17:58] <MacSlow> bryce_, any idea why I don't have any Xorg working with latest updates?
[18:15] <pitti> works here, hmm
[18:31] <asac> pitti: chrisccoulson: ccheney: the xrdb patch was added because firefox didnt understand any other way to antialias
[18:31] <asac> err ooo ;)
[18:31] <pitti> asac: right, we settled it in the meantime
[18:32] <pitti> I rewrote it to use Xlib calls instead of calling xrdb, and updating your patch accordingly
[18:32] <asac> ok
[18:32] <asac> there was a problem with that from what i remember
[18:32] <asac> but dont remember the details
[18:32] <pitti> hm, seems to work fine here
[18:32] <asac> i think it just was that the api was quite bad
[18:32] <pitti> xrdb -remove
[18:32] <pitti> run g-s-d with my patch
[18:33] <pitti> $ xprop -root|grep RESOURCE_MANAGER
[18:33] <pitti> RESOURCE_MANAGER(STRING) = "Xcursor.size:\t18\nXcursor.theme:\tHuman\nXcursor.theme_core:\ttrue\nXft.antialias:\t1\nXft.dpi:\t96\nXft.hinting:\thintslight\nXft.rgba:\trgb\n"
[18:33] <pitti> asac: the API isn't that nice, indeed
[18:33] <pitti> but oh well, I'd kill for those .3 seconds :-P
[18:34] <asac> how many lines of xlib code did that take ;)?
[18:34] <pitti>  gsd-xsettings-manager.c |  160 ++++++++++++++++++------------------------------
[18:35] <pitti>  1 file changed, 61 insertions(+), 99 deletions(-)
[18:35] <pitti> it's actually a net win
[18:35] <pitti> since I could remove all the code to handle the spawning, stdin feeding, etc.
[18:35] <asac> you dont have your patch at hand?
[18:35] <pitti> I'll test it some more and send it to upstream then
[18:35] <asac> ;)
[18:35] <asac> yeah. definitly upstream that
[18:35] <rickspencer3> hi smithj
[18:35] <smithj> rickspencer3: hey
[18:35] <pitti> the patch looks nasty, diff messing up
[18:36] <asac> often git diff is better ;)
[18:36] <pitti> asac: http://paste.ubuntu.com/360196/
[18:36] <pitti> asac: that was git diff..
[18:36] <pitti> that's the new code
[18:39] <kees> asac: you added build-glitch to firefox-3.6.head but not PIE?
[18:40] <asac> kees: yes, thats planned. your branches still get merged. micahg will do it when he gets on again afaik
[18:41] <kees> asac: okay, cool.  did it turn out that build-glitch was actually needed then?
[18:41] <asac> and since you didnt add it in your firefox branch, it was needed anyway
[18:41] <asac> kees: its odd, but yes. our xulrunner dailies were happy, but after moving to firefox all-static it failed
[18:41] <asac> and thunderbird 3.1 also failed for a while
[18:41] <asac> with this
[18:41] <asac> for a few days
[18:41] <kees> yeah, I'm not really sure where it's coming from.  :(
[18:42] <asac> i think it was the last dash update that killed it
[18:42] <asac> at least we associated the tbird 3.1 failures with that when they first popped up
[18:42] <kees> asac: what do you mean by "and since you didnt add it in your firefox branch, it was needed anyway" ?
[18:42] <asac> kees: you only added that build-glich to xulrunner ... which was the right thing to do ;)
[18:42] <kees> ah, okay
[18:42] <asac> but now i moved everything to firefox, so i needed that patch
[18:43] <asac> :)
[18:43] <asac> pitti: yes, that code looks ... unfamiliar ;)
[18:43] <asac> hehe
[18:43] <asac> have you tried changing the aliasing settings multiple time?
[18:43] <kees> asac: would it help for me to create a branch of firefox-3.6.head for micahg to pull from?
[18:44] <asac> kees: no. he will do that. if not, i will pull it before the 3.6 final upload to lucid
[18:44] <asac> so really soon ;)
[18:44] <kees> okay, cool
[18:45] <kees> I just wanted to get it tested so it doesn't run up against and deadlines, since I only tested it on ff3.5
[18:46] <asac> yeah. i will at least start the build before uploading ;)
[18:53] <jcastro> Riddell: was there a bug for the jockey/kdebindings/sip thing?
[18:53] <Riddell> jcastro: I'm not sure
[18:54] <Riddell> probably is for whatever the problem is in jockey which sip is blocking
[18:56] <jcastro> if you run into it please lmk?
[19:28] <didrocks> at last, my patch work :)
[19:29] <didrocks> just a silly wrong naming in the signal *ggggg*
[19:33] <chrisccoulson> hmmmm, i can't get lucid to boot in virtualbox now :-/
[19:36] <pitti> re
[19:36] <pitti> asac: as in, start it twice and check that the resource property doesn't have dupes? yes
[19:41] <pitti> meh, it got smaller, but two other plugins are also calling xrdb -- /me goes for some cut'n'paste
[20:11] <didrocks> have a good evening
[20:32] <pitti> asac: ah, I found a much easier method now, too
[20:32] <asac> pitti: which one
[20:32] <asac> ?
[20:33] <pitti> asac: not use the DB, but just append to the string; it still works fine
[20:33] <asac> right. but oyu need to remove the previous one, right?
[20:33] <pitti> right, you get the current one, append new stuff, and set the new property
[20:34] <asac> on update you dont need to remove it first?
[20:34] <pitti> "it" == ?
[20:34] <pitti> the RESOURCE_MANAGER xprop?
[20:34] <asac> the previous resource value
[20:34] <pitti> "The XSetTextProperty function replaces the existing specified property for the named window..."
[20:36] <asac> pitti: if you check xrdb -query ... does that agree with what you set?
[20:36] <pitti> yes, that and xprop -root|grep RESOURCE_MANAGER
[20:36] <asac> i remember that there is the xprop and the real xresource (in xrdb -query) ... and some apps dont even look at the xprop of window
[20:36] <asac> ok
[20:36] <asac> the tricky part wsa the xrdb part
[20:37] <asac> that one needed to get wiped completely to change a value ... but well, if all is fine, then i am happy :)
[20:37] <pitti> I'll enable the xrdb plugin and play around with an ~/.Xresources
[20:37] <asac> yes. i remember that the xresources was the nasty part and there was no sane api to update values
[21:20] <rickspencer3> Nafai hey ... any idea why re.findall would just never return on a python thread in a gtk app?
[21:39] <TheMuso> rickspencer3: You'll be pleased to hear that recent lucid updates, whether it be the --1 kernel, or something else, have resolved the random resets. I ran lucid yesterday with no issues, and all looks good this morning. Phew.
[21:40] <TheMuso> s-1/-11/
[21:40] <rickspencer3> TheMuso, great news
[21:41] <TheMuso> rickspencer3: Indeed.
[23:07] <Nafai> darn, missed a question from rick
[23:11] <fagan> Nafai: what was the question?
 Nafai hey ...any idea why re.findall would just never return on a python thread in a gtk app?"
[23:13] <Nafai> Off hand, I'm not sure
[23:19] <fagan> Oh I thought you had one for him, I suppose you could chat with him tomorrow
[23:31] <Nafai> Yeah :)