[07:38] <pitti> Good morning
[07:39] <didrocks> good morning
[07:39] <pitti> didrocks: o/
[07:39] <didrocks> :)
[08:53] <chrisccoulson> good morning everyone
[09:05] <rickspencer3> hiya tseliot
[09:05] <rickspencer3> good morning
[09:05] <tseliot> good morning rickspencer3
[10:46] <didrocks> jcastro: I must rename ubuntu-netbook-remix-default-settings in launchpad to ubuntu-netbook-default-settings (and make some kind of indirection for people using < lucid). Are you in charge or do I just open a request on LP?
[10:48] <asac> imo there should just be a single project: ubuntu-netbook
[10:48] <asac> with subtrees etc. :)
[10:48] <asac> rather than creating one project for each package
[10:48] <asac> which will cause these kind of issues if you rename a package
[10:49] <asac> just my 2c
[10:49] <asac> (if this is about a LP project at all)
[11:07] <seb128> hey asac
[11:07] <seb128> asac, did you read my question yesterday?
[11:07] <asac> no
[11:07] <seb128> asac, I'm failing to get libgjs working with libmozjs
[11:08] <asac> hmm
[11:08] <seb128> it's in no way a priority
[11:08] <seb128> but help would be welcome
[11:08] <asac> do we need libgjs?
[11:08] <seb128> it's a depends for gnome-shell
[11:08] <asac> cant we get rid of all this ;)?
[11:08] <asac> yeah. they shouldnt use javascript. we have no engine
[11:08] <asac> that is suitable for main
[11:08] <seb128> $ ldd /usr/lib/libgjs-dbus.so | grep libmozjs
[11:08] <seb128> 	libmozjs.so => not found
[11:08] <seb128> 	libmozjs.so => /usr/lib/xulrunner-1.9.1.7/libmozjs.so (0x00267000)
[11:08] <seb128> I don't get why it's there twice
[11:09] <seb128> and why it find one and not the other one
[11:09] <asac> someone has to tell them that javascript is a bad situation
[11:09] <asac> seb128: we had exactly that before
[11:09] <asac> do you remember where that was?
[11:09] <seb128> I tried to rebuild using as-needed
[11:09] <asac> right
[11:09] <seb128> but that seems to not do the trick this time
[11:09] <seb128> dunno why
[11:09] <seb128> and the same source works in karmic
[11:09] <asac> thats using rpath?
[11:09] <asac> or LD_LIBRARY_PATH?
[11:10] <seb128> I'm a bit puzzled
[11:10] <seb128> LD
[11:10] <seb128> well using /usr/lib/xulrunner-1.9.1.7 works
[11:10] <asac> what doesnt work then?
[11:11] <seb128> try running gjs
[11:11] <asac> i dont have lucid yet
[11:11] <seb128> gnome-shelll does some LD_LIBRARY_PATH trick
[11:11] <seb128> but gjs doesn't
[11:11] <seb128> you are on karmic?
[11:11] <seb128> can you run ldd /usr/lib/libgjs-dbus.so | grep libmozjs
[11:12] <seb128> you need to install gjs
[11:12] <asac> i have gjs but not the dbus module
[11:12] <asac> gjs
[11:12] <asac> gjs>
[11:12] <seb128> no gjs-gi?
[11:12] <asac> export LD_LIBRARY_PATH=/usr/lib/xulrunner-1.9.1.7/
[11:12] <seb128> it works with LD hack
[11:13] <asac> you need to write a wrapper for gjs if that is supposed to work oob
[11:13] <seb128> but that should not required
[11:13] <seb128> +be
[11:13] <asac> hmm
[11:13] <asac> why wouldnt it be required?
[11:13] <seb128> I hate this thing
[11:13] <seb128> can't we make it a proper lib?
[11:13] <asac> yes, for universe
[11:13] <asac> but not main
[11:13] <seb128> it's not in main
[11:13] <seb128> it's in universe
[11:13] <asac> but at some point folks want it in main
[11:13] <seb128> we will not use gnome-shell this cycle
[11:14] <asac> thats clearly going to happen
[11:14] <asac> we have to communicate to upstream, that libmozjs isnt allowed to be used in the distro
[11:14] <asac> they need to do something else
[11:14] <asac> before everything is lost and even more move to libmozjs
[11:15] <seb128> I've better things to do that fight over that with them
[11:15] <seb128> I just want gnome-shell in ubuntu to be nice to them
[11:15] <asac> yes, but if its nice, they dont see that there is a problem
[11:16] <asac> same attiude as the coucdb folks. they say, if its a problem someone else will fix it. but the fact that we adopted it sucks much.
[11:16] <asac> anyway, i will check how easy it is to build it standalone
[11:16] <asac> will take some time
[11:18] <seb128> ok thanks
[11:18] <seb128> I've to go for lunch sorry...
[11:18] <seb128> bbl
[11:25] <pitti> kenvandine, njpatel: wrt. 71_add_gio_extension.patch
[11:25] <chrisccoulson> asac / seb128 - joss started a discussion on the gnome desktop-devel list last year, but it didn't really go anywhere: http://mail.gnome.org/archives/desktop-devel-list/2009-September/msg00121.html
[11:25] <chrisccoulson> you might be interested in taking a look
[11:26] <pitti> kenvandine: could that become a proper diff -u, and get a standard patch tag header? (upstream link, etc.)
[11:28] <milanbv> would any of you apply a patch to the GDM package?
[11:29] <milanbv> I've finally got approval for patch at Bug 393854, but I can't commit it myself
[11:31] <chrisccoulson> milanbv - it would be good to get an opinion from someone on the security team (eg, kees), or someone like slangasek before any of us commit it
[11:31] <chrisccoulson> ah
[11:31] <chrisccoulson> i misread your second comment there ;)
[11:32] <milanbv> chrisccoulson: yeah, kees just agreed yesterday ;-)
[11:33] <chrisccoulson> did you discuss it on IRC? i can't see any comments on the bug report
[11:34] <milanbv> on #ubuntu-devel
[11:34] <milanbv> (so that you can't check what I'm pretending...)
[11:34] <chrisccoulson> thanks :)
[11:35] <chrisccoulson> if he's happy with it, then i can commit it when i finish work if nobody else beats me to it
[11:35] <milanbv> nice, thanks
[11:35] <chrisccoulson> but we're frozen for A2 at the moment anyway (although, i haven't checked my inbox for a release announcement yet, so that might not be the case any more)
[11:36] <milanbv> no hurry, I'd just like somebody to do it before the release
[11:36] <milanbv> (final release)
[12:05] <TeTeT> asac: do you know if network-manager 8.1 will make it into Lucid? Or will it stay the same version as in Karmic?
[12:11] <asac> TeTeT: it will be 0.8 final most likels
[12:11] <asac> we have a prerelease version
[12:11] <asac> first step is rc2 ... which we will try to get to karmic as an SRU as well
[12:12] <asac> TeTeT: upstream hasnt even released 0.8 final ;)
[12:12] <asac> so given the pace i nthe past its unlikely that there will be a 0.8.1
[12:13] <TeTeT> asac: ok, thanks a lot :)
[12:14] <TeTeT> asac: any chance the latest nm will get a PPA, so they can copy a working package from there?
[12:14] <asac> TeTeT: did you read my comment on the pppoe bug? i gave a timeline/plan there
[12:15] <TeTeT> asac: need to re-read it then, escaped me
[12:15] <asac> no problem. last comment ;)
[12:18] <TeTeT> asac: was this bug 483773?
[12:28] <asac> no
[12:28] <asac> ;)
[12:28] <asac> one minute
[12:28] <asac> TeTeT: bug 432205
[12:34] <TeTeT> asac: I wasn't subscribed to that one
[12:36] <pitti> davidbarth: https://edge.launchpad.net/ubuntu/lucid/+milestones
[12:38] <asac> TeTeT: ok. thought that was your main concern ;)
[12:39] <asac> TeTeT: if you need to be up-to-date on our NM roadmap in future, i can try to keep you in the loop. just wasnt aware that you rely on this
[12:39] <TeTeT> asac: I actually never did, but nowadays I seem to get a NM question a day. I even subscribed to the upstream mailing list ...
[12:40] <TeTeT> asac: not that it would mean anything ...
[12:40] <pitti> asac: do you still need the alpha2/final mobile reports on piware.de or can I take down the cronjobs? (I'll archive the .db and output just in case, but I'd like people to move to the new WI tracker on macaroni)
[12:49] <asac> pitti: i would like the alpha2 state to be frozen right when alpha2 release is done. then we can move elsewhere
[12:49] <asac> (but keep the graph and the last state)
[12:49] <asac> if thats posisble
[12:50] <asac> where is the new macaronis service=
[12:50] <asac> ?
[13:13] <pitti> asac: right, I did a complete backup of the scripts, databases, and output
[13:13] <pitti> asac: I'll keep the alpha-2 reports for a while, but I'd like to remove the lucid/ ones (since they are out of date and imprecise)
[13:13] <asac> pitti: where can i find the new tracker?
[13:13] <pitti> asac: and above all I'd like to kill the cronjobs
[13:13] <pitti> asac: you don't read your platform@ mail? :-)
[13:13] <asac> guess i missed a mail in the thread
[13:13] <pitti> asac: http://macaroni.ubuntu.com/~pitti/workitems/
[13:14] <asac> i dont read all mails in threads i considered done :)
[13:15] <asac> pitti: ok, what about the full cycle one?
[13:15] <pitti> asac: the names without the milestone
[13:15] <pitti> asac: likewise, all-* are the ones for entire ubuntu, particular milestone
[13:15] <pitti> and all milestones/all teams == all.html
[13:16] <pitti> it has the full combinatorial explosion
[13:16] <pitti> (they're dead cheap to generate now)
[13:16] <asac> pitti: ok. just confusing that they dont have canonical- as prefix
[13:16] <pitti> it's not a hardcoded prefix anyway
[13:17] <asac> oh sorry
[13:17] <asac> good
[13:17] <pitti> it's LPTEAMNAME-MILESTONENAME
[13:17] <asac> so our trendline got reset?
[13:17] <pitti> asac: yes, I didn't write a full DB migration script
[13:17] <pitti> asac: but of course I'm fine to adjust the trend line start for you if you want
[13:18] <asac> yeah. lets try to use the value where the current one ended
[13:18] <pitti> (not that the old start would be too meaningful with the 2 weeks of holidays, etc., but I'm happy to add support for this)
[13:18] <asac> thtas odd
[13:18] <asac> there are far less items
[13:18] <asac> http://piware.de/workitems/mobile/lucid/report.html
[13:18] <asac> here it was 130
[13:18] <asac> and we were behind
[13:18] <asac> now 130 would mean we are ahead
[13:19] <asac> http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile.html
[13:19] <asac> any clue what specs didnt get picked up?
[13:20] <pitti> asac: it's a different count now
[13:20] <pitti> now it's counting WIs from members of your team
[13:20] <asac> hmm
[13:20] <huats_> hello guys !
[13:20] <pitti> before it was counting WIs from all specs of your team, even if they were assigned to a different team
[13:20] <asac> we want to have our community specs there too
[13:20] <pitti> I'll change it to cover both
[13:21] <asac> its basically one spec: liquid
[13:21] <pitti> that will come back, yes
[13:21] <asac> problem is that we cannot really plan how far we are behind based on our progress before
[13:21] <pitti> will work on this next week, when the sprint is done
[13:21] <asac> i wanted to kill stuff until we hit the line
[13:22] <asac> cant the other cronjob still run?
[13:22] <asac> or is that completely f***ed?
[13:22] <pitti> that was my original question
[13:22] <pitti> it can still run
[13:22] <asac> just the full cycle
[13:22] <asac> one
[13:22] <asac> good
[13:22] <pitti> but I can't change anything in the code any more
[13:22] <pitti> yeah
[13:22] <asac> thats fine. i would then use the full cycle one from there and the milestones ones from the new
[13:23] <asac> just need liquid in the new spec list
[13:23] <pitti> asac: the old alpha-2 report is probably uninteresting now, I figure?
[13:23] <asac> cool. thanks
[13:23] <pitti> asac: I think from next week on the charts shold be correct, too
[13:23] <asac> pitti: just need a final snapshot for later communication
[13:23] <asac> for alpha-2
[13:23] <pitti> asac: I won't remove the html pages
[13:23] <asac> e.g. the html page basically
[13:23] <asac> ok good
[13:23] <pitti> just stop the alpha-2 cron job
[13:23] <asac> then its all good
[13:23] <asac> yeah
[13:23] <asac> we are close enough there
[13:23] <pitti> alpha-2 is today, so it doesn't make sense to let it run
[13:23] <asac> and today is release day
[13:23] <asac> ;)
[13:24] <pitti> the new alpha-2 report will continue to be generated, so you can look at that for stragglers
[13:24] <asac> hmm. what does that mean? does the trendline go below zero there?
[13:25] <pitti> no, of course not
[13:25] <asac> currently the new alpha-2 is empty
[13:25] <asac> oh ok
[13:25] <pitti> asac: I meant WIs which were scheduled for alpha-2, which you didn't get to
[13:25]  * pitti yays at http://macaroni.ubuntu.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-2.html
[13:25] <asac> i think: just let it run. i will adapt to the new approach if the full new one is still there
[13:25] <asac> err full old one
[13:25] <pitti> asac: http://macaroni.ubuntu.com/~pitti/workitems/canonical-mobile-lucid-alpha-2.html isn't though
[13:26] <asac> one item blueprints are good ;)
[13:30] <tseliot> pitti: I think you left the proprietary improments blueprint out of that page
[13:31] <vuntz> pedro_: yo?
[13:32] <pedro_> vuntz, hey, saw my message?
[13:39] <pitti> tseliot: it shouldn't be there; https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-proprietary-drivers is targetted to alpha-3
[13:39] <pitti> tseliot: it's on http://macaroni.ubuntu.com/~pitti/workitems/canonical-desktop-team-lucid-alpha-3.html
[13:39] <tseliot> pitti: aah, ok
[13:44] <seb128> rodrigo__, stop suggesting upstream to do things which will break our lts ;-)
[13:44] <rodrigo__> seb128, what have I suggested?
[13:44] <seb128> landing the new g-c-c design
[13:44] <seb128> cf my comments on #c-c
[13:45] <rodrigo__> seb128, oh, would that break our lts if it lands in time for 2.30?
[13:45] <seb128> it's quite some changes
[13:45] <seb128> by experience it takes time to find and fix issues on rewrites
[13:45] <seb128> it's better to have one cycle to sort things
[13:45] <seb128> rather than rushing
[13:46] <rodrigo__> you're right in that it's a bit late in the cycle, I guess
[13:46] <seb128> I'm maybe too much on the conservative side
[13:46] <seb128> but breakages over cycles learnt me to do be prudent with such changes ;-)
[13:46] <rodrigo__> well, I asked thos if it was going to land master, it should be now or just wait
[13:46] <rodrigo__> and yeah, seems it's not ready
[13:47] <seb128> seems they are still discussion how to do it
[13:47] <seb128> it seems a bit risky
[13:47] <seb128> let's see what they decide
[13:48] <seb128> upstream should decide on what they think is best, not on what distro will do...
[13:48] <seb128> but we might go back to 2.28 if they do land that
[13:48] <seb128> depends on how well it works I guess
[13:48] <seb128> hey mclasen
[13:49] <mclasen> hmm?
[13:49] <seb128> mclasen, did you read my question yesterday?
[13:49] <mclasen> saw it go by
[13:49] <seb128> mclasen, some people were asking about the tooltip work you did and if those would go upstream this cycle
[13:49] <seb128> is there anything blocking them?
[13:49] <mclasen> they would if I had time to finish them up
[13:50] <seb128> oh ok
[13:50] <seb128> the comment suggested you considered the round corner change ready
[13:50] <seb128> thanks
[13:50] <mclasen> need to figure out if there's a way to let theme engines do all the drawing
[13:50] <mclasen> and still have the shape match the drawing
[13:51] <mclasen> which is a little complicated
[13:51] <seb128> ok
[13:51] <seb128> what is the schedule now for 2.20 btw?
[13:51] <seb128> I guess those changes will be for next cycle now?
[13:51] <mclasen> I said 'early january'... but too late now :-(
[13:51] <vuntz> pedro_: sorry, I was writing a mail. I was wondering if it'd be possible to analyze the stack traces you get from crashes before forwarding them upstream
[13:52] <seb128> vuntz, hello
[13:52] <mclasen> seb128: right now I am operating in 'maybe I have some time next week' mode...
[13:52] <seb128> vuntz, what sort of analyze do you want to do?
[13:52] <vuntz> pedro_: I quickly looked at a few of them, and most of them are like "hrm, yeah, I can't do anything about that. I need more details, or it should be run again with --sync, or I need ways to reproduce"
[13:52] <pedro_> vuntz, we do that, but what kind of analyze do you want?
[13:53] <seb128> vuntz, deciding on how much clue a debugged stacktrace will give to the hacker is not easy
[13:53] <vuntz> pedro_: well a gnome-panel crash with only symbols in gdk/gtk+ is generally a bad sign, for example, since it's really hard to debug with just this
[13:53] <vuntz> (of course, this is not always true)
[13:53] <seb128> vuntz, we default to sending debug ones and let the maintainer decide on if it's useful or not
[13:53] <vuntz> seb128: yeah, I know
[13:53] <seb128> I think it's a fair choice
[13:53] <seb128> you can close in one click if you think it's not useful
[13:54] <seb128> but it's better than having bug triagers deciding a stracktrace is not useful when it would be maybe for somebody
[13:54] <pedro_> vuntz, well if there's specific requirements for the gnome-panel we can ask those before submitting them there
[13:54] <vuntz> seb128: I usually feel bad about closing bugs with a stack trace, without understanding why there was a crash
[13:55] <seb128> and I feel bad about closing those downstream without knowing if it would be useful to upstream or not...
[13:55] <vuntz> pedro_, seb128: what would generally help is making it possible to install packages were the applets are not in-process, and then ask the reporter to reproduce
[13:55] <seb128> but if you have good metrics we can use
[13:55] <vuntz> (unless the stack trace makes it obvious where the crashes is)
[13:56] <vuntz> eg, I would guess most of the stack traces with no useful symbols crashing gnome-panel might actually be notification area issues
[13:56] <seb128> the things with crashes is that often they are not reproducable
[13:56] <seb128> especially for gnome-panel
[13:56] <seb128> 90% of those are "I was not going anything special and it crashed"
[13:56] <vuntz> seb128: package applets out-of-process during the development cycle, then? :-)
[13:56] <seb128> I can do that for sure
[13:56] <seb128> I will do it with the 2.29 update
[13:56] <vuntz> I understand it's not easy
[13:57] <seb128> I'm fine changing build options
[13:57] <vuntz> just trying to figure out how the best way for upstream and downstream here
[13:57] <seb128> I just know that asking submitters to install something and reproduce doesn't work in 95% of the cases
[13:57] <vuntz> yeah
[13:57] <vuntz> true
[13:57] <seb128> if you think the build change would lead to better stacktrace I'm all for it
[13:58] <seb128> I don't get why there is no notification area symbol there though
[13:58] <seb128> if it crashes in the notification-area code
[13:58] <seb128> hey tedg
[13:59] <seb128> vuntz, btw what part of the sourcecode does the applet loading?
[13:59] <seb128> the applets rather
[13:59] <seb128> ie where should I put marked for "start loading <applet>"
[13:59] <seb128> "done loading <applet>"
[13:59] <seb128> markers
[13:59] <vuntz> seb128: panel-applet-frame.c
[13:59] <seb128> thanks
[14:00] <seb128> vuntz, any clue with those crashes have no gnome-panel symbols btw?
[14:00] <vuntz> seb128: well, I have a few bugs upstream that are crashes of the out-of-process notification area, and this is in gtk/gtk only
[14:00] <seb128> changing the build mode will lead to the applet crash rather than gnome-panel
[14:00] <vuntz> in this case, my guess is that's it's related to some change that was done about transparency
[14:00] <seb128> but will probably not solve the stracktrace issue
[14:01] <seb128> ie those will still have no symbols
[14:01] <seb128> you will just know what process crashes
[14:01] <vuntz> seb128: yeah, but knowing that it's the notification area and not gnome-panel+clock+notification area+... is better
[14:01] <seb128> makes sense
[14:02] <seb128> vuntz, quick question for you, what pygame version has opensuse?
[14:02] <seb128> your current unstable
[14:04] <vuntz> seb128: 1.9.0, apparently
[14:05] <seb128> vuntz, ok, thanks
[14:05] <chrisccoulson> pedro_ has been busy today ;)
[14:05] <chrisccoulson> i just checked my inbox
[14:06] <pedro_> well i have less isos to test , so more time to triage :-P
[14:06] <tedg> Good morning vuntz
[14:09] <vish> seb128: hi... i didnt understand your response on Bug 437532 .. :(
[14:09] <seb128> tedg, I said hey and your reply to vuntz!
[14:09] <seb128> bug #437532
[14:09] <tedg> seb128: Heh, sorry.  Not through my first cup of coffee, I can't tell Frenchmen apart yet :)
[14:09]  * vish wonders what's up with bot
[14:09] <seb128> vish, nautilus uses an application indicator now
[14:09] <vish> seb128: https://bugs.launchpad.net/bugs/437532 :)
[14:10] <seb128> vish, the applet does the icon rendering
[14:10] <seb128> and it's supposed to append something to the name in an automatic way
[14:10] <seb128> and check for that
[14:10] <seb128> this way we don't need any app change
[14:10] <vish> seb128: so is the icon not needed? i'm a bit confused :(
[14:10] <seb128> it's done transparantly applet side
[14:10] <seb128> tedg, ^ can you confirm that's done yet?
[14:10] <seb128> tedg, the "use monochrome icons"
[14:11] <seb128> or "custom indicator theme"
[14:11] <seb128> or whatever it's called
[14:11] <tedg> seb128: No, we're not appending anything on the icon name yet.
[14:11] <seb128> tedg, but you will?
[14:11] <tedg> seb128: We should, but there aren't any done by the art team so I wasn't up on it :)
[14:11] <seb128> tedg, or do we need to patch applications?
[14:11] <tedg> Yes, we will.
[14:11] <vish> tedg: hi.. we've been adding monochrome icons to humanity using the -symbolic names , how are we supposed to do it?
[14:12] <tedg> vish: Uhm, sure.  The only thing I'm a bit worried about is that we probably won't have time to do all the stuff we wanted to do with the "symbolic" suffix like we discussed at UDS.  I'm curious if we should reserve that suffix until we can do the whole enchilada.
[14:13] <tedg> vish: But, honestly.  As long as you use a consistent name, a script can change them all pretty quickly :)
[14:13] <vish> tedg: ah , cool :)
[14:14] <vuntz> tedg: hola. I just replied to your mail :-)
[14:16] <tedg> vuntz: Thank you!
[14:23] <seb128> vish, you can close the bug
[14:23] <vish> seb128: ok..
[14:23] <vish> seb128: but seems tedg mentioned above apps need patch^?
[14:23] <vish> [19:41] <seb128> tedg, or do we need to patch applications?
[14:23] <vish> [19:41] <tedg> Yes, we will.
[14:24] <tedg> vish: Sorry, no I was saying that we will handle it on the indicator side.
[14:24] <tedg> vish: We need to fix those, not the apps.
[14:24] <vish> tedg: ah , thanks :)
[14:24]  * vish closing bug
[14:43] <pitti> seb128: alias dreb='debuild -us -uc -nc'
[14:54] <seb128> asac, heh, I don't want to be responsive for those libs ;-)
[14:54] <seb128> I've enough to do
[14:54] <seb128> I just want the gvfs backend to build
[14:54] <seb128> I'm also not sure how to fix the shlibs warnings
[14:55] <seb128> it uses --as-needed
[14:55] <seb128> is there anything else to add?
[14:57] <chrisccoulson> pitti - is there anything to fix in g-p-m for bug 432598? g-p-m doesn't provide an interface for initiating suspend/hibernate any more, so don't these checks need to go in to the session applet instead?
[14:58] <asac> seb128: good question. i dont see those libs being linked directly in the log
[14:58] <asac> seb128: but symbol gcry_control used by debian/libiphone0/usr/lib/libiphone.so.0.0.0 found in none of the libraries.
[14:58] <asac> that looks odd
[14:58] <asac> i think its ok if you fix the ABI tracking stuff and subscribe team to bugs ;)
[14:59] <asac> and checkout that symbol
[15:00] <seb128> ok
[15:00] <seb128> I like shlibs better that .symbols
[15:00] <seb128> but let's see ;-)
[15:00] <asac> symbols is better
[15:00] <asac> :)
[15:00] <asac> hehe
[15:00] <seb128> it's slower
[15:00] <seb128> the symbol lookup things is ridiculously slow
[15:00] <asac> anyway, even shlibs stuff isnt in place from what i can tell
[15:00] <asac> at least not explicitly
[15:01] <seb128> right
[15:01] <seb128> thanks for review
[15:01] <seb128> I will fix those
[15:01] <asac> good.
[15:01] <asac> cant the desktop-team as a whole just take responsibility?
[15:01] <asac> even if that is just: hunt down anyone using libiphone in main to commit to support that ;)
[15:01] <asac> i really think if you subscribe to bugs you are already responsible :-P
[15:02] <asac> do you know if usbmuxd is run as root?
[15:03] <asac> ok updated bug with shortlist discussedhere
[15:05] <asac> how do we remove a debconf template from cache? i though there was a debconf command/function to clean
[15:05] <seb128> asac, no it doesn't
[15:05] <seb128> run as usbmux
[15:06] <asac> thanks
[15:06] <seb128> it's also not running all time
[15:06] <seb128> just when a device is detected
[15:26] <cyphermox> asac, re fontconfig, bug 490326, I have the debdiffs up in the same place as before
[15:33] <asac> did you update your bzr branch?
[15:33] <asac> cyphermox: ?
[15:33] <asac> http://bazaar.launchpad.net/~mathieu-tl/ubuntu/lucid/fontconfig/merge-to-2.8.0-2.lp490326
[15:34] <cyphermox> i created a new one
[15:34] <cyphermox> http://bazaar.launchpad.net/~mathieu-tl/ubuntu/lucid/fontconfig/merge-to-2.8.0-2.lp490326.take2
[15:34] <asac> dont like two commits ;)
[15:34] <asac> you
[15:34] <cyphermox> not for merges. is that wrong?
[15:35] <asac> yes, i alread have that branch
[15:35] <asac> so you can easily commit another commit ... anyway, pulling now
[15:35] <itorrey> djsiegel: I have the Renkoo theme on my list of things to hit tomorrow. I'll just take a stab at the colors and you guys can tweak as needed.
[15:35] <asac> cyphermox: also its easier to see that the comments have been addressed as i just need to check a tiny commit diff
[15:35] <cyphermox> sorry ;)
[15:36] <asac> now i have to review everything again
[15:36] <cyphermox> well not necessarily
[15:36] <asac> np
[15:36] <asac> i know about ways to work around
[15:36] <cyphermox> i haven't destroyed the branch, I can always push to it again with these changes
[15:36] <asac> but i need the other branch for that
[15:36] <asac> or have to do a length online diff
[15:39] <didrocks> jcastro: I don't get a "mutter" project in LP, can you register it, please?
[15:41] <asac> so ... what to do to remove debconf templates from systems if the package stops shipping them? anyone?
[15:41] <jcastro> didrocks: sure
[15:42] <asac> ok found it
[15:42] <asac> cyphermox: db_purge
[15:42] <asac> http://www.fifi.org/doc/debconf-doc/tutorial.html
[15:42] <asac> if you want add that for upgrades from versions below the new one
[15:42] <cyphermox> ok
[15:42] <jcastro> didrocks: done
[15:53] <didrocks> jcastro: thanks :)
[16:08] <didrocks> jcastro: I don't know if you received that: I must rename ubuntu-netbook-remix-default-settings in launchpad to  ubuntu-netbook-default-settings (and make some kind of indirection for people using < lucid). Are you in  charge or do I just open a request on LP?
[16:09] <jcastro> hmm, I don't know how to do that, #launchpad can help you
[16:09] <didrocks> ok, I'll
[16:09] <didrocks> thanks
[16:10] <tseliot> rickspencer3: ping
[16:11] <rickspencer3> hi tseliot
[16:12]  * rickspencer3 tseliot ug, I'm sorry, I am not quite available atm
[16:12] <tseliot> rickspencer3: no problem
[16:21] <pitti> chrisccoulson: I heared that you're on the g-p-m 2.29.1 update?
[16:21] <chrisccoulson> pitti - i am
[16:21] <pitti> chrisccoulson: I need to touch the package to fix a bug and also disable unconditional hal triggering
[16:21] <pitti> chrisccoulson: so I thought perhaps we could update the package and disable the notify patch for now
[16:21] <chrisccoulson> pitti - feel free to do that, i'll just merge in the changes to my local branch later
[16:22] <chrisccoulson> pitti - i don't mind, but i'm at work at the moment (and my branch is at home)
[16:22] <pitti> chrisccoulson: did you already spend a lot of effort on the local branch? wrt. refreshing the other patches, etc?
[16:22] <chrisccoulson> pitti - i spent some effort on it, although not a huge amount
[16:25] <chrisccoulson> pitti - sorry, i was hoping to have the update finished by now, but i keep getting distracted by other tasks ;)
[16:28] <djsiegel> ok asac, can we have a catch-up about some of the UNE changes?
[16:28] <djsiegel> As far as dropping apps and replacing them with web apps goes?
[16:28] <asac> djsiegel: yes
[16:29] <asac> djsiegel: how long are you on today?
[16:29] <seb128> chrisccoulson, you can claim the g-s-d update in exchange if you want something ;-è)
[16:29] <seb128> ;-)
[16:29] <chrisccoulson> seb128 - yeah, i can do that
[16:29] <seb128> thanks
[16:30] <pitti> chrisccoulson: re; nevermind, no reason to waste effort; I'll just work in the upstream git branch for this
[16:31] <chrisccoulson> it seems g-s-d has grown a new status icon for keyboard stuff
[16:31] <chrisccoulson> more application indicator porting ;)
[16:32] <seb128> yeah
[16:32] <seb128> tedg, ^
[16:32] <chrisccoulson> i can probably work on that
[16:32] <chrisccoulson> although, the status icon class is part of libgnomekbd, so it might be best to do the work there
[16:32] <tedg> Man.  They keep popping up everywhere!
[16:32]  * pitti does mor hal invocation squishing
[16:33] <pitti> "more"
[16:33] <jcastro> chrisccoulson: I've started to file placeholder bugs for a-i work in bugzilla and in lp, feel free to claim them!
[16:34] <chrisccoulson> jcastro - will do :)
[16:34] <chrisccoulson> although i need to be careful not to over-commit myself ;)
[16:34] <jcastro> seb128: I got a mail from the gbrainy maintainer saying that if we have any questions/issues to contact him.
[16:34] <seb128> jcastro, if you open the nautilus one I will add my patch there
[16:34] <jcastro> seb128: on it.
[16:34] <seb128> jcastro, ok, can you please forward that info to robert_ancell too?
[16:34] <seb128> he's our "games guy"
[16:34] <jcastro> yep I was planning to, I saw he registered the lp page
[16:34] <seb128> he's gnome-games upstream too
[16:34] <seb128> ;-)
[16:34] <seb128> thanks
[16:35] <jcastro> oh, is jclinton not doing -games anymore?
[16:36] <seb128> they are several
[16:36] <seb128> enough games there to keep some people busy
[16:36] <seb128> ;-)
[16:36] <jcastro> I had never heard of gbrainy until yesterday
[16:36] <jcastro> it's pretty fun
[16:36] <chrisccoulson> we don't want too many games, otherwise nobody will ever get any work done ;)
[16:37] <seb128> yeah
[16:37] <jcastro> thank the maker we didn't put tetrinet on there, we'd be doomed.
[16:37] <chrisccoulson> jcastro - i tried gbrainy at 4am
[16:37] <chrisccoulson> its probably best to try it when more alert ;)
[16:48] <chrisccoulson> right, home time
[16:50] <seb128> jcastro, why did you reopen the indicator bug for rhythmbox?
[16:51] <jcastro> seb128: I wanted to keep it open until the patch is submitted upstream. I talked to Ken about it, do you think there's a better way to do that?
[16:51] <seb128> no
[16:51] <seb128> but it sucks to keep it open
[16:51] <seb128> it still shows on our todolist
[16:52] <seb128> why isn't the upstream tasks good enough for you?
[16:52] <jcastro> because if it's not open I get the feeling it will be forgotten about.
[16:53] <seb128> jcastro, when can't you attach the current patch there?
[16:53] <jcastro> I would rather keep them open until the patch is submitted upstream. The patches will be assigned to the DX team in the future anyway right?
[16:53] <seb128> jcastro, it still shows in the rhythmbox bug list
[16:53]  * Amaranth waves
[16:53] <jcastro> seb128: it was but then we found a crasher so bratsche is looking at it
[16:54] <seb128> and on the tagged indicator buglist
[16:54] <seb128> I'm not sure how to track that but keeping fixed bugs open is not great either
[16:54] <jcastro> I am open to suggestions, I just think that if we close them when we upload to the distro people might forget to push them upstream.
[16:55] <Amaranth> Launchpad needs tasks management :)
[16:55] <jcastro> and the goal for a-i patches is for them to be pushed and accepted upstream so I think in this case the bug isn't fixed until it's been sent up.
[16:56] <seb128> jcastro, that's why things should not be uploaded before being sent
[16:56] <seb128> this way it give motivation to people to send their things upstream too...
[16:56] <jcastro> hmm, that's a good idea.
[16:57]  * jcastro adds to the page
[17:01] <kenvandine> jcastro, i think the ubuntu bug for it should be "Fix Released" and the upstream bug in LP left open
[17:02] <jcastro> ok fine fine.
[17:02] <kenvandine> since it is fixed in the distro, which is what the ubuntu bug is about
[17:02]  * kenvandine thought that is what you meant on IM :)
[17:02] <kenvandine> or leave the bug against a-i open
[17:02] <jcastro> but if we end up with a patch rotting in lp and people want to kill me you will come help. :p
[17:02] <kenvandine> hehe
[17:03]  * kenvandine thinks there should be a part of the upstream report that lists every patch in every package... and link to the upstream bug... or a reason it isn't submitted upstream :)
[17:04] <cassidy> ++
[17:04] <kenvandine> :)
[17:04] <kenvandine> jcastro, see even upstream likes that idea
[17:04]  * kenvandine enjoys creating more work for jcastro
[17:04] <kenvandine> :-D
[17:05] <jcastro> Don't worry, the lp team should be landing a +patches view this month
[17:06] <kenvandine> awesome
[17:28] <pitti> lool: https://code.edge.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master
[17:31] <pitti> chrisccoulson: ok, I pushed my patch to the g-p-m bzr without updating to the new version; it's unintrusive, thus shouldn't cause you any trouble (I did it against upstream git head, backports without issue)
[17:31] <chrisccoulson> pitti - thanks, i'll try and get back on to that later
[17:31] <chrisccoulson> has A2 been released yet?
[17:32] <chrisccoulson> (i havent gone through all my mails)
[17:32] <chrisccoulson> ah
[17:32] <chrisccoulson> the topic on #ubuntu-devel would suggest not
[17:33] <pitti> no, but the .isos are pretty much final
[17:39] <jcastro> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=606987
[17:39] <jcastro> seb128: I've linked it to the lp nautilus bug
[17:41] <chrisccoulson> jcastro - OOI, how receptive have the upstream guys been to all these requests on the gnome bugzilla so far?
[17:42] <jcastro> chrisccoulson: the ones who have responded to me have asked how it fits into the bigger gnome picture, so yesterday Ted posted a mail to gnome d-d-l asking for feedback
[17:42] <chrisccoulson> jcastro - ah, cool. i've not seen ted's mail yet
[17:42] <chrisccoulson> i really need to work my way through my inbox ;)
[17:44] <seb128> jcastro, thanks
[18:45]  * asac almost uploaded in the freeze
[18:57] <cyphermox> asac, can you take a look at my branch for fontconfig again?
[18:58] <asac> cyphermox: one more time?
[18:58] <asac> third revision?
[18:59] <cyphermox> no
[18:59] <cyphermox> the same this time :)
[19:38] <fta> in lucid, rhythmbox lost its tray icon :(
[19:38] <chrisccoulson> fta - do you have the indicator-applet on your panel?
[19:38] <chrisccoulson> it should use the new application indicator
[19:38] <fta> yes
[19:38] <chrisccoulson> i don't think the fallback works yet
[19:38] <chrisccoulson> ah
[19:39] <fta> i have your xchat applet too, but it doesn't do anything for me :S
[19:39] <fta> hm, is it yours?
[19:40] <fta> or ken's?
[19:40] <chrisccoulson> is that the xchat-indicator that kenvandine worked on?
[19:40] <fta> ok
[19:40] <chrisccoulson> it seems to be working ok here, but you need to explicitly enable the plugin
[19:40] <fta> yes, it's the one
[19:40] <chrisccoulson> it's disabled by default when you install it
[19:41] <kenvandine> the plugin can't enable itself
[19:41] <fta> i use xchat, not xchat-gnome. it's listed, but i don't know what else to expect from it
[19:41] <kenvandine> fta, do you have the message indicator ?
[19:41] <kenvandine> the applet i mean?
[19:41] <fta> i have Indicator Applet
[19:41] <kenvandine> ok
[19:42] <kenvandine> do you have an entry in it for xchat?
[19:42] <chrisccoulson> kenvandine - is there any way of changing the default config to enable the plugin by default?
[19:42] <kenvandine> chrisccoulson, yeah... in xchat
[19:42] <chrisccoulson> it seems silly to have to enable it manually after installing it
[19:42] <kenvandine> chrisccoulson, if we get my plugin into main... i will make it a recommends and enable it by default :)
[19:43] <chrisccoulson> kenvandine - awesome :)
[19:43] <kenvandine> i wish the plugin could tell xchat to load itself :)
[19:43] <kenvandine> but i guess that would be evil
[19:43] <kenvandine> fta, ?
[19:44] <fta> kenvandine, http://www.sofaraway.org/ubuntu/tmp/indicator-applet.png
[19:44] <kenvandine> fta, ok... that is good
[19:44] <kenvandine> means the plugin is actually loaded
[19:44] <kenvandine> fta, so you don't get messages when you are highlighted?
[19:44] <fta> what is it supposed to do?
[19:44] <fta> nope
[19:45] <kenvandine> http://blogs.gnome.org/kenvandine/
[19:45] <kenvandine> that is what it should look like when you have messages you haven't seen
[19:45] <kenvandine> so if i highlight you in a channel you don't have focused
[19:45] <kenvandine> you should see something in the indicator
[19:45] <kenvandine> or if i PM you
[19:45] <kenvandine> see something now?
[19:45] <fta> also note that rhythmbox is no longer in the systray (which is my initial complain ;))
[19:46] <kenvandine> yeah... i know
[19:46] <kenvandine> libappindicator with fallback support will be uploaded today
[19:46] <fta> yep, it worked, i see kenvandine 0m
[19:46] <kenvandine> ok
[19:46] <kenvandine> :)
[19:46] <kenvandine> that's what it does :)
[19:46] <fta> excellent
[19:47] <fta> does it jump to the proper place too? i mean, scroll up if more stuff arrived since?
[19:47] <kenvandine> no
[19:47] <kenvandine> the plugin interface doesn't really provide that
[19:48] <kenvandine> it would require hacking xchat directly :)
[19:48] <kenvandine> and i really want to keep this within the bounds of a proper plugin :)
[19:48] <kenvandine> fta, note i haven't tested it much with xchat
[19:48] <kenvandine> fta, so please report bugs :)
[19:48] <fta> sure
[19:48] <kenvandine> thx
[19:49] <fta> hm, rhythmbox crashed
[19:49] <fta> tried to touch the plugins
[19:51] <kenvandine> known bug... will be fixed soon
[19:51] <kenvandine> well if you disable and enable the status icon
[19:51] <kenvandine> it crashes
[19:51] <kenvandine> bratsche is fixing it
[19:52] <fta> ok, good
[19:54] <fta> i have a patch for an evolution bug preventing me from using it for work, would you (anyone) consider it?
[19:54] <fta> gnome 585577
[19:56] <fta> i've been using it for months in karmic, but lost it with the upgrade to lucid
[19:57] <jcastro> kenvandine: should I file a bug about reverting tomboy back?
[20:20] <asac> my mother updated hardy today and now if she clicks on the shutdown button, her gnome-panel crashes :)
[20:20] <asac> anyone did any SRU or something in that direction?
[20:20] <asac> hmm. is there a list of what was pushed to -updated -security in a chronological form?
[20:20] <asac> updates
[20:23] <asac> something feels really broken with gnome or so
[20:23] <asac> (firefox:6342): GnomeUI-WARNING **: While connecting to session manager:
[20:23] <asac> Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.
[20:23] <asac> thtas on hardy
[20:23] <bryyce> o_O
[20:23] <asac> besides having zero length .xsession-errors
[20:23] <asac> bryyce: did you roll an X update ;)?
[20:23] <bryyce> nope
[20:23] <asac> or are you off the hook
[20:23] <asac> ok lucky you ;)
[20:23] <bryyce> not to hardy anyway
[20:23] <asac> really felt bad
[20:24] <asac> she upgrades every few days. todays upgrade busted a bunch of things :)
[20:24] <bryyce> besides, sounds more like a dbus or gnome-*-daemon type of an issue
[20:24] <asac> of course she cannot really remember what got updated
[20:24] <bryyce> asac, what's in /var/log/dpkg.log ?
[20:24] <kenvandine> jcastro, please do
[20:24] <asac> bryyce: hey, dont ask too much
[20:24] <jcastro> kenvandine: whom do I assign it to? Just the desktop team?
[20:24] <bryyce> lol
[20:24] <kenvandine> me
[20:24] <asac> i already talked to her like 2h on phone now
[20:24] <jcastro> ok
[20:24] <asac> :)
[20:24] <kenvandine> thx
[20:24] <bryyce> asac, okay:  "Did you try rebooting?"
[20:25] <asac> yes, multiple times, thats when she found that the shutdown button started to crash the gnome-panel
[20:25] <asac> you click on it-> boom -> gnome-panel doesnt even come back
[20:25] <asac> sounds bad
[20:25] <asac> pitti: did you push something gnome related to -updates in the last two days?
[20:26] <asac> where can i find that? are those going to changes mailing list? /me checks
[20:26] <asac> hmm only see -proposed
[20:26] <bryyce> asac, also don't rule out that the updates were fine but just triggered the issue in a round about way (like running out of disk space)
[20:28] <bryyce> asac, another case I've run into in supporting other people's systems is an incomplete upgrade which left some package un-reconfigured
[20:28] <asac> hmm ... good point
[20:28] <asac> .xsession-errors feels bad
[20:28] <asac> we checked that upgrade
[20:28] <asac> all up to date
[20:28] <asac> we even reinstalled a few packages through synaptic (that was really bad) :)
[20:29] <asac> but good point i should have checked disk space
[20:29] <bryyce> asac, we really need a remote administration feature in ubuntu so we can better support our moms :-)
[20:29] <asac> will do that tomorrow ;)
[20:29] <asac> yeah ;)
[20:29] <asac> thats actually something i wanted to do before i started to work here for ubuntu :)
[20:29] <asac> come up with a great support thing ;)
[20:35] <kees> bryyce: the stuff under system/preferences/"remote desktop" works great for me for mom-support
[20:37] <bryyce> kees, ah ok I'll have to try that out some time
[20:37] <bryyce> kees, fortunately most of the problems I've had to troubleshoot have been of the "is it plugged in" variety
[20:38] <kenvandine> bryyce, have her "share desktop" in empathy :)
[21:35] <fta> i have desktop sounds disabled, yet, they are there.
[21:36] <fta> and something just started to emit a click sound every 5 sec
[21:36] <fta> weird
[21:37] <fta> oops, it's chromium
[21:40] <fta> yet, xchat and all gtk textfields have sounds
[22:28] <geser> I've upgraded my desktop from karmic to lucid. everything worked well, except that my desktop wallpaper doesn't span my both monitors anymore. I've tried to set it again with gnome-desktop-properties but I couldn't find a setting that made it span again.
[22:30] <geser> Any idea how I get it cover both monitors again (with only one occurance of the wallpaper)
[22:30] <geser> ?
[23:13] <bryyce> geser, which video driver?
[23:13] <geser> radeon
[23:14] <bryyce> hm
[23:14] <geser> the X setup seems to be ok, I've a desktop spaning both monitors but not the wallpaper
[23:14] <geser> dimensions:    3200x1200 pixels (from xdpyinfo)
[23:15] <geser> and I've also a wallpaper in that dimension
[23:15] <bryyce> geser, maybe it's a new gnome desktop "feature"
[23:18] <bryyce> geser, sounds like maybe a seb128 question.  Might check in the relevant gnome packages on launchpad if there's already a bug and if not open a new one
[23:18] <bryyce> geser, my thought had been if you were using a proprietary driver maybe xinerama kicked in, but for -radeon that doesn't work, and sounds like you correctly verified your X environment is right
[23:18] <bryyce> so I'd probably start reviewing the changelog and bug reports for gnome-panel or whatever sets up the wallpaper
[23:18] <bryyce> geser, I hope it gets fixed!  That's one that'll affect me too once I update my own desktop
[23:19] <mclasen> you can make it span by setting it to tiled
[23:21] <geser> I tried the different "styles" but none does what I want
[23:22] <geser> "tile" cuts of a part and repeats the wallpaper again
[23:26] <geser> http://www.bienia.de/tmp/Screenshot.png, that's "Tile"
[23:30] <mclasen> to use tile as a workaround to get a stretched background back, you have to pick an image of the right size...
[23:31] <geser> that wallpaper is of the right size (3200x1200) as I used it with karmic where it worked
[23:31] <geser> it broke with my update to lucid
[23:32] <geser> looks like a fix for https://bugzilla.gnome.org/show_bug.cgi?id=147808 broke it
[23:34] <mclasen> the behaviour on multi-monitor setups was changed to a more useful one
[23:36] <geser> but broke an other valid configuration
[23:36] <bryyce> geser, ah the current bug for the issue is https://bugzilla.gnome.org/show_bug.cgi?id=603551
[23:37] <bryyce> yeah agreed the "fix" just shifted breakage from one use case to another
[23:37] <bryyce> should have been made a configuration setting
[23:39] <mclasen> according to the 'you can never drop a broken feature' school of thought, yes...
[23:41] <asac> https://bugzilla.gnome.org/show_bug.cgi?id=598231
[23:41] <geser> a better fix would be to be able to select a wallpaper per monitor (additionally)
[23:41] <asac> anyone knows a metacity developer who could look at that patch?
[23:42] <geser> currently I can't use my old wallpaper and I don't know yet if I manage to find a wallpaper that looks on a 1280x1024 and 1920x1200 right