[00:00] <rickspencer3> RAOF, robert_ancell, tremolux, TheMuso, shall we go ahead?
[00:00] <TheMuso> sure
[00:00] <tremolux> ready
[00:00] <RAOF_> Yes.
[00:00] <rickspencer3> RAOF, we'll start with you, since you are first on the list
[00:01] <rickspencer3> RAOF did you get any kind of projection for WI through put?
[00:01] <RAOF_> I only had 4 WI in Lucid, and they took ~1.5 weeks.  That's not really enough data to project from, I think.
[00:02] <rickspencer3> so, like 3 per week
[00:02] <rickspencer3> RAOF_ didrocks came up with 5 for himself, so shall we estimate 4 for you to start, maybe?
[00:02] <RAOF_> That seems reasonable.
[00:03] <rickspencer3> so that's 24 total for A2
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-video-bugs-in-the-kms-world
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-easy-wayland-testing
[00:03] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-gpu-freeze-reports
[00:04] <rickspencer3> RAOF are those all of your blueprints for maverick?
[00:04] <robert_ancell> rickspencer3, how are you getting that list?
[00:04] <rickspencer3> they seem to have work items, and to be less than 24
[00:04] <rickspencer3> robert_ancell, go here:
[00:04] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/maverick?searchtext=desktop-maverick
[00:04] <rickspencer3> and sort by assignee
[00:04] <robert_ancell> and manually count work items?
[00:04] <rickspencer3> pretty much, yeah
[00:05] <RAOF_> Yep, those are all of them.
[00:05] <rickspencer3> RAOF, do you see any reason not to target them all for A2?
[00:05] <RAOF_> Oh, no, missed one.
[00:05] <rickspencer3> basically get them all done by June 24th?
[00:05] <rickspencer3> can you paste me a link to the one I missed?
[00:06] <RAOF_> Yeah, grabbing it.
[00:06] <rickspencer3> oops, there are only 5 weeks now
[00:06] <rickspencer3> so 20 work items total
[00:06] <RAOF_> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-rootless-x
[00:06] <rickspencer3> so the first 4 brings you to 17
[00:07] <RAOF_> This bumps it to 23
[00:07] <rickspencer3> RAOF lots of work items there, so maybe target rootless x to A3?
[00:07] <rickspencer3> https://wiki.ubuntu.com/MaverickReleaseSchedule
[00:07] <rickspencer3> or do you feel that it *must* be done for maverick?
[00:08] <RAOF_> No.  It's a nice-to-have.
[00:08] <rickspencer3> ok
[00:08] <rickspencer3> I'm targeting the first 4 to A2, the rootless x one to A3
[00:08] <rickspencer3> sound ok?
[00:08] <RAOF_> The other work items are mostly about getting good bugs and being able to deal with them - that's more imporltant.
[00:08] <RAOF_> I'm fine with that.
[00:09] <rickspencer3> sweet
[00:09] <rickspencer3> next is tremolux
[00:09] <tremolux> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-software-center-front-end
[00:09] <rickspencer3> tremolux, were you able to calculate a WI throughput?
[00:10] <tremolux> it's going to be a little complicated for my case
[00:10] <tremolux> because we have community folks who are likely to grab some things
[00:10] <rickspencer3> how does 4 per week sound as an estimate?
[00:10] <tremolux> yes, that seems fine, 4-5 or so
[00:10] <rickspencer3> yeah, that can increase productivity
[00:11] <tremolux> so I have 17 here for alpha-2
[00:11] <rickspencer3> tremolux, I think you'll have a tad less maintainer work than other folks, at least to start
[00:11] <tremolux> yep
[00:11] <rickspencer3> so maybe 5 is a good number
[00:11] <rickspencer3> so 17 is just right
[00:11] <rickspencer3> I only see one blueprint currently targeted for you:
[00:11] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-software-center-front-end
[00:11] <tremolux> yep, but I will likely have some work items on other blueprints
[00:12] <tremolux> https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-opportunistic-apps-stable-release
[00:12] <tremolux> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-software-center-dynamic-appview
[00:12] <tremolux> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-software-center-dynamic-testing-improvements
[00:12] <tremolux> https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-oneconf
[00:12] <rickspencer3> does this have all the buy something and cool apps work items?
[00:12] <tremolux> these bad boys
[00:12] <rickspencer3> aha
[00:12] <tremolux> no, this doesn't
[00:12] <rickspencer3> so across those 5 blueprints, you have a total of 17 work items right now?
[00:13] <tremolux> I think about 20, not counting the ones that I have past a-2
[00:13] <rickspencer3> ok
[00:14] <rickspencer3> we need to pick for A2
[00:14] <tremolux> oh, do we have the buy apps blueprint? not yet, right?
[00:14] <rickspencer3> tremolux, correct, not yet, you are blocking on me to work out how to track LP work items
[00:14] <rickspencer3> so those need to be, for sure, in A2
[00:14] <tremolux> right, definitely
[00:14] <rickspencer3> how many did you have from that one?
[00:15] <rickspencer3> I see the work items, but I don't see which are for you
[00:15] <tremolux> yes, I think I have "any UI work"
[00:15] <rickspencer3> heh
[00:16] <rickspencer3> ok, so I see there is a lot of work here, and the work items have been identified
[00:16] <rickspencer3> but the 20 that you will sign up for in A2 haven't been called out yet
[00:16] <rickspencer3> we'll have to take care of that tomorrow
[00:17] <rickspencer3> tremolux, can you look through all of these specs, and see which ones you think you need to pick off for A2, including the "ghost spec" for buy something?
[00:17] <tremolux> yes, it's a little tricky because mvo and I dynamically divide up work historically
[00:17] <rickspencer3> ah
[00:17] <rickspencer3> hmmm
[00:17] <tremolux> we grab from a bucket  :)
[00:17] <tremolux> but we don't have to do that
[00:17] <rickspencer3> I see
[00:17] <rickspencer3> well ... we shouldn't bust a functional work flow
[00:17] <tremolux> it's fine to sign up, much better for tracking
[00:17] <rickspencer3> let's do both
[00:17] <tremolux> ok
[00:17] <rickspencer3> sign up for say 15
[00:18] <tremolux> that sounds good
[00:18] <rickspencer3> maybe not 15, but the number that 1. should be done in A2 and 2. are very UIish, so most likely you will do
[00:18] <rickspencer3> however, I do need to know between you, what you are committed to delivering in A2
[00:19] <rickspencer3> even if many of the work items are unassigned
[00:19] <tremolux> yep
[00:19] <rickspencer3> tremolux, do you think you have enough information to identify the A2 work items tomorrow?
[00:19] <tremolux> yes, I already made a cut for my spec
[00:20] <rickspencer3> I'm concerned I'm not being clear
[00:20] <rickspencer3> ok, it sounds good, then
[00:20] <rickspencer3> the blueprint certainly have a lot of analysis in them
[00:20] <tremolux> and tomorrow I'll work with mvo to 1. pare my list if necessary and 2. add items for me in the other specs
[00:20] <rickspencer3> sounds great
[00:20] <rickspencer3> rock
[00:20] <tremolux> cool
[00:20] <rickspencer3> any other concerns, etc...?
[00:21] <tremolux> nope!  sorry everyone for the diversion from the noob
[00:21] <tremolux> :)
[00:21] <rickspencer3> software center is a bfd for Maverick!
[00:21] <rickspencer3> welcome to the team :)
[00:21] <rickspencer3> tremolux, tbh, we're all noobs at this ;)
[00:21] <tremolux> haha, thanks!  \o/
[00:21] <rickspencer3> next on the list is TheMuso
[00:22] <rickspencer3> TheMuso, have you calculated a WI throughput?
[00:22] <TheMuso> rickspencer3: No, I haven't. You know me and graphs, and given the fact I didn't really have much in the way or work items last cycle, and that I don't have many this cycle, its not exactly that easy to do so.
[00:22] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-gnome3-accessibility-readiness
[00:23] <rickspencer3> TheMuso, that's fine
[00:23] <rickspencer3> we all have different jobs
[00:23] <TheMuso> rickspencer3: That spec has turned out to be more informational
[00:23] <rickspencer3> that's why the system is flexible
[00:23] <rickspencer3> TheMuso, I see some things there that could be turned in WIs
[00:24]  * TheMuso looks again...
[00:24] <rickspencer3> TheMuso, let's talk more next week
[00:24] <TheMuso> ...and doesn't see things that could be WIs.
[00:24] <rickspencer3> let me think
[00:25] <rickspencer3> I'd like to see some commitments to technical progress in both accessibility and sound
[00:25] <rickspencer3> but I think we need to discuss more
[00:25] <rickspencer3> sound ok?
[00:25] <TheMuso> Well other than getting the bits from upstream, there is not much else that could be a work item.
[00:26] <TheMuso> and since we are starting to be more conservative with things...
[00:26] <rickspencer3> that sounds like you are planning just to integrate upstream bits this cycle
[00:26] <TheMuso> but ok sounds reasonable
[00:26] <rickspencer3> which is good and important
[00:26] <rickspencer3> but I'd like to see us go beyond that
[00:27] <rickspencer3> robert_ancell, were you able to calculate a WI throughput estimate?
[00:28] <robert_ancell> I don't think I have enough data from the last cycle, I'm thinking the 20-25 team estimate sounds about right
[00:29] <rickspencer3> cool
[00:29] <rickspencer3> robert_ancell, I only see this one blueprint for you:
[00:29] <rickspencer3> https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-shotwell
[00:29] <rickspencer3> are there others that haven't been accepted yet?
[00:29] <robert_ancell> I'll be doing a large chunk of work on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-gnome
[00:29] <rickspencer3> I seem to recall some change mail from your blueprints
[00:29] <rickspencer3> aha
[00:29] <rickspencer3> of course
[00:30] <rickspencer3> erk
[00:30] <robert_ancell> all the new things I planned seb removed from the maverick schedule
[00:30] <rickspencer3> looks like lots of tough ones
[00:30] <rickspencer3> robert_ancell, right ... that didn't mean you were banned from doing those
[00:30] <robert_ancell> I was also signed up to getting PyGI working (foundations blueprint) but it doesn't seem to be on the Maverick schedule
[00:30] <rickspencer3> just, not to commit to them
[00:30] <robert_ancell> Also https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-shotwell
[00:30] <rickspencer3> PyGI is not on the schedule!!
[00:31] <rickspencer3> robert_ancell, I think shotwell maybe end up more maintainer work than expected
[00:31] <rickspencer3> how many work items do you have in A2 total?
[00:31] <robert_ancell> I don't have a lot of work items for these, as not sure how to divide, e.g. for GNOME should I make "Package 2.31.1", "Package 2.31.2" to break it up?
[00:31] <rickspencer3> I'm wondering if you are feeling like you could do more?
[00:32] <robert_ancell> based on comitted work, yes
[00:32] <rickspencer3> robert_ancell, do you feel like the current plan has you under-utilized?
[00:32] <rickspencer3> if so, we should consider bringing back one of your other blueprints
[00:33] <robert_ancell> sure, we should discuss priorities
[00:33] <rickspencer3> for this stuff:  for GNOME should I make "Package 2.31.1
[00:33] <rickspencer3> I think I wouldn't make work items, per se
[00:33] <rickspencer3> that sounds more like regular maintainer work
[00:34] <robert_ancell> they do represent chunks of work, so not sure if that's worth tracking or not
[00:34] <rickspencer3> well ... if it's recurring and rote, it's probably worth accounting for, as in it will take up time, but not work tracking
[00:34] <rickspencer3> if that makes sense
[00:35] <robert_ancell> acounting != work tracking?
[00:35] <rickspencer3> no
[00:35] <rickspencer3> like I could assume you are going to do 20 hours per week of maintainer work on gnome, for example (made up number)
[00:36] <rickspencer3> so I would account for that by knowing that you only have 20 more hours a week to work
[00:36] <rickspencer3> but I would track the flow of maintainer work
[00:36] <rickspencer3> it will just get done
[00:36] <robert_ancell> ok
[00:37] <rickspencer3> robert_ancell, I hate to think of  you not having awesome projects that you are motivated to work on
[00:37] <robert_ancell> just to run back, "PyGI is not on the schedule", was that a statement of suprise or "it's not supposed to be on the schedule"
[00:37] <rickspencer3> well, it was a statement of surprise
[00:38] <rickspencer3> I would have thought it was a bit tricky to land and make it work
[00:38] <rickspencer3> but maybe not
[00:38] <rickspencer3> I know this is totally vague, btw
[00:38] <robert_ancell> ok, shall we discuss after the meeting which project to put on schedule
[00:38] <rickspencer3> well first, what do you think?
[00:39] <rickspencer3> does it need to be tracked, etc...?
[00:39] <robert_ancell> Color management is the interesting one I'd like to try
[00:39] <rickspencer3> hmmm
[00:39] <robert_ancell> which I know you want to talk about anyway :)
[00:39] <rickspencer3> ok
[00:40] <rickspencer3> robert_ancell, are doing the PyGI work specifically yourself, or are there other people involved?
[00:40] <rickspencer3> I ask, because I care about this a lot for certain developer experience stuff we are workign on
[00:40] <rickspencer3> like the easy and fun telepathy API
[00:40] <robert_ancell> rickspencer3, I'm doing the packaging (I've done some work this week, but it's not working)
[00:41] <rickspencer3> ah
[00:41] <robert_ancell> so it should be working by default in Maverick asap
[00:41] <robert_ancell> (but expected to still have all the usual bugs)
[00:41] <rickspencer3> who is responsible for getting it working?
[00:41] <rickspencer3> are you the maintainer?
[00:41] <robert_ancell> no
[00:41] <rickspencer3> foundations?
[00:42] <robert_ancell> not sure, I think that's upstream.  The meeting was more about making it available so people are prepared for when the old bindings start to stop being maintiained
[00:42] <rickspencer3> hmmm
[00:42] <rickspencer3> I would like someone in Ubuntu to be on point for making sure this goes smoothly
[00:42] <tremolux> robert_ancell: do you know, is Barry working on this?
[00:43] <robert_ancell> tremolux, I don't know, I'm looking for blueprint now
[00:43] <rickspencer3> I am so happy to have robert_ancell back on the team!
[00:43] <tremolux> robert_ancell rocked OEM!
[00:43] <robert_ancell> I think it is, https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-python-versions but it doesn't seem to have the items yet.  Maybe no-one copied them from the gobby doc
[00:44] <rickspencer3> robert_ancell, I suggest that you work on color management (or what you prefer) but don't target it to the release
[00:44] <robert_ancell> rickspencer3, ok, can do
[00:44] <rickspencer3> so we don't appear committed to delivering it
[00:44] <rickspencer3> then you can pull a Simple Scan
[00:44] <robert_ancell> hehe :)
[00:44] <desrt> robert_ancell: hey
[00:44] <rickspencer3> deliver such awesome software that everyone wants to ship it!
[00:44] <robert_ancell> desrt, hey
[00:44] <desrt> robert_ancell: seb was wondering if you had some free time to make some packages
[00:45] <robert_ancell> desrt, ok, talk after meeting
[00:45] <RAOF_> robert_ancell: Feel free to pour some colour-management work this way if you need to :)
[00:45] <desrt> ah.  didn't realise.  sorry. :)
[00:46] <rickspencer3> desrt is always welcome to our meetings! :)
[00:46] <rickspencer3> robert_ancell, I think we are done, actually
[00:46] <robert_ancell> ok, I feel like I'm hogging the meeting, anything I should do to track things?
[00:46] <robert_ancell> oh ok
[00:46] <rickspencer3> well ... just get your work items cleaned up on your blueprints
[00:47] <rickspencer3> I'll look at the burndown chart on Monday and make sure nothing seems amiss
[00:47] <robert_ancell> rickspencer3, ok, I just don't have any really, let me know if there's a good way to break up the items
[00:48] <rickspencer3> hmmm, you ended up with no spec work?
[00:48] <rickspencer3> just maintenance?
[00:48] <robert_ancell> rickspencer3, just no items, so I have two I put on Shotwell "Package 0.6" and "Package 0.7" but I just put them to have some items on this
[00:48] <rickspencer3> basically, you are the new seb128 ;)
[00:49] <robert_ancell> GNOME I have two that seb retro added (update GLIB, GTK+)
[00:49] <rickspencer3> yeah, like you ended up with a large maintenance surface area
[00:49] <robert_ancell> PyGI should have one
[00:49] <rickspencer3> which makes sense
[00:49] <rickspencer3> but I don't want you to be bored
[00:49] <robert_ancell> I always have side projects :)
[00:49] <rickspencer3> so I guess having a blueprint on the side makes sense
[00:50] <rickspencer3> looking at your areas, you have a lot of responsibility for maverick!
[00:50] <rickspencer3> alright, so let's finish up here
[00:50] <rickspencer3> RAOF, TheMuso, tremolux, robert_ancell - thanks for your time and effort planning out maverick!
[00:50] <rickspencer3> please note that we have HR review stuff due by Tuesday!
[00:51] <tremolux> fun times  :)
[00:51] <TheMuso> np
[00:51] <rickspencer3> don't forget to invite peer reviews and such
[00:52] <rickspencer3> any questions, comments, etc...?
[00:52] <TheMuso> rickspencer3: no questinos, but if you have a minute, I'd like to talk about your thoughts re technical progress for sound/a11y that you mentioned earlier.
[00:52] <tremolux> not me
[00:52] <TheMuso> questions
[00:52] <rickspencer3> TheMuso, sure
[00:53] <tremolux> ok, thanks all, I enjoyed my first desktop meeting, Eastern Edition (tm)
[00:53]  * tremolux goes to make sure the kids didn't eat all the dinner
[00:53] <robert_ancell> desrt, ok, so anything special to note about glib/dconf?
[00:55] <desrt> ya.  you should add a small vendor patch to dconf
[00:55] <desrt> also: you'll need a post-install hook
[00:56] <desrt> the patch you should add is the one at the head of the 'master' upstream
[00:56] <rickspencer3> tremolux, they are not usually this organized ;)
[00:56] <desrt> totally silly mistake on my part
[00:56] <desrt> the post-install hook is the one that runs gio-querymodules
[00:57] <robert_ancell> desrt, any dconf/gconf interactions to worry about? (guessing no)
[00:57] <desrt> nope
[00:57] <robert_ancell> did seb128 give any hints on packaging naming?  I'm guessing gnome-dconf from the last discussion
[00:58] <desrt> that's a dreadful name
[00:58] <desrt> like, really really bad
[00:58] <robert_ancell> and you would recommend...
[00:59] <desrt> hmm.
[00:59] <desrt> well, i like 'dconf'
[00:59] <robert_ancell> because libdconf doesn't sound right.
[00:59] <robert_ancell> Sorry, dconf is taken
[00:59] <desrt> it's difficult
[00:59] <robert_ancell> but it's also not really gnome specific
[00:59] <desrt> really, the various binary packages will all have different names anyway
[00:59] <desrt> unlikely to have one called 'dconf'
[00:59] <desrt> the source package name is the trouble
[01:00] <desrt> yes.  indeed.
[01:00] <desrt> would it be very strange to call the source package 'dconf-source'?
[01:00] <robert_ancell> TheMuso, ^ ?
[01:00] <desrt> with binary package names like 'dconf-gsettings' 'dconf-tools' etc
[01:00] <desrt> 'libdconf'
[01:01] <robert_ancell> dconf-config? or something like that, i.e. "name"-"class"
[01:01] <robert_ancell> dconf-settings?
[01:01] <robert_ancell> dconf-registry?
[01:01] <desrt> d-conf?
[01:01] <robert_ancell> aha
[01:01] <desrt> you're going to have to repackage 'dconf' in universe i guess
[01:02] <desrt> because it tries to install /usr/bin/dconf.  i'll be using that.
[01:02] <robert_ancell> why couldn't you have done a debian package name check before choosing the name!! :)
[01:02] <TheMuso> gnome-dconf?
[01:02] <desrt> no.
[01:02] <TheMuso> orca is gnome-orca after all.
[01:03] <desrt> it's not gnome-specific
[01:03] <TheMuso> ah ok
[01:03] <robert_ancell> we can't change the binary name
[01:03] <robert_ancell> (of the existing dconf)
[01:03] <desrt> epiphany got renamed to epiphany-game
[01:04] <desrt> let the record show what happens when i run 'dconf'
[01:04] <desrt> /usr/bin/dconf:3: DeprecationWarning: The popen2 module is deprecated.  Use the subprocess module.
[01:04] <desrt>   import os, sys, glob, re, shutil, getopt, popen2, time, fnmatch
[01:04] <desrt> /usr/bin/dconf:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead
[01:04] <desrt>   import difflib, smtplib, gzip, md5, sha
[01:05] <desrt> /usr/bin/dconf:5: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[01:05] <desrt>   import difflib, smtplib, gzip, md5, sha
[01:05] <desrt> Traceback (most recent call last):
[01:05] <desrt>   File "/usr/bin/dconf", line 481, in <module>
[01:05] <desrt>     main()
[01:05] <TheMuso> lovely
[01:05] <robert_ancell> who would I talk to about renaming it?
[01:05] <desrt> popcon says 150 people are using it
[01:06] <desrt> i'm not sure?
[01:06] <desrt> i don't know what happened for epiphany
[01:06] <TheMuso> I guess in Debian is the best place to do this properly right, or is this a package that is only in Ubuntu?
[01:06] <desrt> it's from debian
[01:06] <desrt> http://qa.debian.org/popcon.php?package=dconf
[01:06] <TheMuso> right
[01:07] <desrt> about 400 times as many people are using gconf
[01:08] <robert_ancell> so I don't know what the process here is, what are the chances of filing a bug in debian and anything being done?  Guess I need to ask the Debian GNOME guys what their dconf plans are
[01:08] <desrt> ah.  only 7 people are marked as having dconf installed/used recently
[01:08] <TheMuso> wow
[01:08] <desrt> how much do you want to bet that they all thought that they were getting my software? :p
[01:10] <desrt> huh.  according to popcon, 99.79% of all debian users are using popcon
[01:10]  * desrt suspicious
[01:10] <Amaranth> epiphany didn't get their name
[01:10] <Amaranth> They got epiphany-browser instead
[01:10] <Amaranth> Heck, did git get their name yet?
[01:10] <desrt> alternatives?
[01:10] <desrt> yes.  git is git.
[01:11] <desrt> er.
[01:11] <desrt> Amaranth: we're talking about /usr/bin/ binary names, not packagers
[01:11] <Amaranth> ah
[01:11] <desrt> the epiphany-browser package installs /usr/bin/epiphany
[01:12] <chrisccoulson> the existing dconf in the archive really should just be removed, it hasn't been updated for over 2 years now
[01:12] <desrt> chrisccoulson: that's what i was getting at with my 'spews about deprecations then crashes'
[01:12] <chrisccoulson> desrt - i agree, and i hate cruft anyway ;)
[01:12] <desrt> robert_ancell: maybe you should wait
[01:13] <chrisccoulson> ok, i will check to make sure nothing is build-depending on it and ask an archive admin to remove and blacklist it
[01:13] <desrt> are you a DD?
[01:13] <robert_ancell> no
[01:13] <chrisccoulson> i'm not either
[01:13] <robert_ancell> I'll get the packaging working and get seb to check this out, he's more on the pulse of Debian
[01:13] <desrt> you should fairly familiar with the ways of debian :p
[01:13] <desrt> *sound
[01:14] <desrt> it's too hot in here.  my brain is melting.
[01:14] <chrisccoulson> heh
[01:35] <rickspencer3> good night all!
[01:36] <rickspencer3> I'll be back on Monday (will check in tomorrow prolly)
[04:40] <nigelb> Isn't assinging to desktop team out?
[04:40] <nigelb> I believe we dont do that anymore
[05:01] <lifeless> RAOF_: ping
[05:01] <RAOF_> lifeless: Pong.
[05:02] <lifeless> RAOF_: whats a good pci express video card to buy [good == linux love] these days
[05:02] <lifeless> poolie is stranded at a computer shop
[05:02] <lifeless> and has a fried card
[05:02] <RAOF_> What's he need it for?
[05:02] <lifeless> bzr dev
[05:02] <lifeless> explicitly not games
[05:02] <RAOF_> Buy the cheapest ATI card money can buy.
[05:02] <lifeless> thanks
[05:02] <RAOF_> That should be ~$50
[05:03] <lifeless> and the free driver will likely run it ?
[05:03] <lifeless> or the binary blob is tolerable ?
[05:03] <RAOF_> Free driver works fine on the box next to me; that has a video card chosen by this algorithm.  The blob also works.
[05:04] <lifeless> RAOF_: hd4350 ring any bells ?
[05:04] <RAOF_> That's possibly what I've got in the box next to me.
[05:04] <RAOF_> I'll check.
[05:05] <lifeless> now thats service; poolie says 'thanks very much'
[05:07] <lifeless> RAOF_: so what did lspci say ?
[05:07] <RAOF_> Yup.  Radeon DH 4350 is what I've got.
[05:07] <lifeless> awesome
[05:07] <lifeless> poolie reckons its a typo :)
[05:08] <lifeless> DH<->HD
[05:08] <RAOF_> It is :)
[05:11] <lifeless> poolie is very grateful
[05:12] <RAOF_> No problem!
[06:20] <RAOF> Yay sbuild-on-tmpfs-overlay!
[06:48] <fagan> good morning desktoppers
[07:46] <pitti> Good morning
[08:03] <didrocks> good morning pitti, fagan
[08:04] <fagan> morning didrocks
[08:05] <pitti> hey didrocks, fagan
[08:05] <fagan> hey pitti
[09:00] <seb128> hey there
[09:01] <didrocks> salut seb128, bien dormi?
[09:01] <seb128> lut didrocks
[09:01] <seb128> nickel, et toi?
[09:03] <pitti> bonjour seb128
[09:03] <seb128> hey pitti
[09:03] <seb128> how are you?
[09:03] <pitti> c'est bien, merci! et toi?
[09:04] <didrocks> seb128: très bien, merci ;)
[09:06] <seb128> pitti, gut danke
[09:07] <nigelb> so many languages :)
[09:29] <dpm> heya pitti, good morning, I'm moving all helper scripts related to Ubuntu Translations to a central location. We've got one to retrieve the URLs from translation imports. ArneGoetje told me it was you who wrote it, so I've added a license header and added you as the original author before publishing it. Before I push it, does that look ok to you (well, the license header, copyright assignment and such)? -> http://pastebin.ubuntu.com/437184/
[09:39] <pitti> dpm: no, I don't think I wrote this :) just leave you as the author then, it doesn't matter much; The copyright should be (C) 2010 Canonical Ltd., if you wrote it during paid hours
[09:40] <pitti> dpm: btw, if you are looking for a home for it, langpack-o-matic might not be the worst one
[09:53] <didrocks> james_w: hey, who should we ping when an debian branch is out of date? (are they still target testing?)
[09:57] <didrocks> james_w: the sid branch is uptodate, just lp:debian/package points to testing
[10:00] <james_w> didrocks: that's launchpad's decision, I'm not entirely sure what the consequences of changing it would be
[10:02] <didrocks> james_w: no pb, since we can branch from sid. I was just surprized at first :)
[10:02] <james_w> yeah
[10:02] <james_w> I would prefer it was the other way, but as I said, I'm not sure what would rely on it pointing to testing
[10:04] <didrocks> ok, thanks james_w :)
[10:05] <james_w> didrocks: perhaps you could file a bug against launchpad?
[10:05] <james_w> we can discuss it there
[10:05] <james_w> otherwise we will just never know
[10:05] <didrocks> james_w: "launchpad" itself is the right target task?
[10:06] <james_w> launchpad-registry I think
[10:06] <james_w> but launchpad is always fine
[10:06] <didrocks> ok, filling it and subscribing you, ok?
[10:11] <dpm> pitti, ah, ok, I'll credit ArneGoetje as the author then. I'm going to put it in the ubuntu-translations project, where we've got a home for such tools
[10:13] <pitti> nice
[10:18] <seb128> what is the standard way to run autotools at build time?
[10:26] <pitti> seb128: I'd call autoreconf -vi
[10:26] <seb128> pitti, in which changelog target?
[10:26] <pitti> oh, and then rm -rf autom4te.cache/ please
[10:27] <seb128> robert-ancell did that
[10:27] <seb128> common-configure-arch common-configure-indep::
[10:27] <seb128> 	autoreconf -f -i -s
[10:27] <pitti> hmm; I think "build" should depend on configure
[10:27] <pitti> or configure, yes
[10:27] <pitti> and configure should depend on configure.ac
[10:27] <pitti> that won't yet catch Makefile.am modifications, though
[10:27] <seb128> I'm wondering if we should try to use the cdbs autotools-vars.mk
[10:28] <pitti> seb128: cdbs has builtin support foor that
[10:28] <pitti> "for"
[10:28] <seb128> I know we had discussion in the past about the cdbs way to do it though
[10:28] <seb128> they don't use autoreconf
[10:28] <seb128> but run autoconf, automake, etc
[10:28] <pitti> DEB_AUTO_UPDATE_AUTOCONF, DEB_AUTO_UPDATE_AUTOHEADER, and so on
[10:28] <seb128> which is less smart than autoreconf
[10:30] <asac> i had a patch for AUTORECONF at some point ... guess that was list in battle though
[10:30] <asac> lost
[10:36] <seb128> asac, if you find it somewhere let me know ;-)
[10:40] <didrocks> seb128: I just had a look at the evolution-exchange and the only real diff we have is: http://paste.ubuntu.com/437209/ you described as "don't use a Debian specific directory". Do we keep that? I'm not sure to understand the reason?
[10:40] <didrocks> (well, the diff is ubuntu - debian, should be the contrary no -xxx for us)
[10:40] <seb128> didrocks, it's about matching the directory used by evolution I think
[10:41] <seb128> you would need to drop the evolution change too
[10:41] <didrocks> seb128: I remember to do the same in evolution (we also remove -xxx), but I have no clue why :)
[10:41] <seb128> and make sure you rebuild everything using this dir
[10:41] <DASPRiD> didrocks, no pr0ns for us? :/
[10:41] <seb128> because I don't see the reason to have a distro change there
[10:42] <didrocks> seb128: ok, I was thinking you made the change in first place, but didn't have the time to have a look at it. I can try to sync and rebuild evolution without it
[10:42] <seb128> it's another case of debian maintainer doing changes for the sake of doing changes and not being compatible with upstream
[10:42] <seb128> didrocks, no, I mean what debian is doing is wrong
[10:42] <seb128> why that directory needs to be changed?
[10:42] <didrocks> seb128: oh ok, understood now
[10:42] <didrocks> seb128: so, let's keep that
[10:43] <seb128> but feel free to open a bug on the bts, maybe the new debian maintainers for it can sort that
[10:43] <didrocks> made sense to not change upstream, especially for side effects because of hard-coded path :)
[10:43] <seb128> either it has a sense and should be taken upstream or has none and should be dropped from debian
[10:43] <didrocks> sure, I'll do that in the same round
[10:43] <seb128> thanks
[10:43] <didrocks> thanks for the explanation :)
[10:43] <seb128> yw ;-)
[10:43] <seb128> hey chrisccoulson
[10:43] <didrocks> good morning chrisccoulson
[10:44] <pitti> hey chrisccoulson
[10:44] <chrisccoulson> hi seb128 didrocks pitti
[10:44] <chrisccoulson> how are you all?
[10:45] <pitti> good, thanks!
[10:45] <seb128> good, thanks, what about you?
[10:45] <DASPRiD> very good, thanks
[10:46] <zyga> hello, anyone seen mvo today?
[10:46] <chrisccoulson> yeah, i'm good too thanks. a little bit tired though
[10:47] <seb128> zyga, not yet
[10:48] <seb128> he might be on swap day or something
[10:48] <seb128> chrisccoulson, working too much?
[10:48] <chrisccoulson> seb128 - i've had a couple of late nights this week ;)
[10:49] <seb128> don't overwork yourself too much ;-)
[11:30] <Bacta> So which of you knuckle heads violated my laptops UI?
[11:30] <pitti> !coc | Bacta
[11:30] <ubot2> Bacta: The Ubuntu Code of Conduct is a community etiquette document to which we ask all Ubuntu users to adhere, and can be found at http://www.ubuntu.com/community/conduct/ .  For information on how to electronically sign the CoC, see https://help.ubuntu.com/community/SigningCodeofConduct .
[11:31] <Bacta> coc?
[11:31] <Bacta> No I don't care about that, I'm just curious about why my window controls were moved to the left
[11:31] <Bacta> It took an hour to fix
[12:00] <dpm> hi seb128, I've got two WI on the desktop-translations roundtable we had (https://blueprints.edge.launchpad.net/ubuntu/+spec/community-m-desktop-translations-roundtable). I'm not sure that's the best place to put them and make them appear in the burn-down chart. Do you have any existing blueprint for Desktop where I could move them to?
[12:00] <seb128> dpm, they should show up on our list if they are assigned to people in our team
[12:01] <dpm> seb128, even if it's a community-m-desktop-* blueprint?
[12:01] <seb128> yes
[12:02] <seb128> dpm, I've set the maverick serie goal for it
[12:02] <seb128> let's see how next WIs refresh goes
[12:02] <dpm> seb128, ok, thanks, I'll keep an eye on it, then
[12:35] <pitti> seb128: btw, let me know when I should flush the desktop ones, so that we have a clean start
[12:45] <seb128> pitti, we shouldn't be far from it now, is it easy to do for you?
[12:46] <seb128> pitti, ie if you can do it now that would be nice, I might ask you again on tuesday after the meeting though
[12:49] <geser> pitti (or any other core-dev): https://code.edge.launchpad.net/~geser/ubuntu/maverick/gir-repository/dont_build_gtk_gir/+merge/25762 is ready for sponsoring. It re-adds a drop Ubuntu delta to gir-repository (don't build gtk gir) which is needed as else the build fails to upload.
[12:49] <seb128> geser, hi
[12:49] <seb128> geser, the build didn't fail due to that though
[12:50] <seb128> I've it on my list of things to look at
[12:50] <geser> seb128: Hi, the give-back a few minutes ago did
[12:50] <seb128> weird
[12:50] <seb128> do you know why the previous one failed earlier?
[12:50] <geser> https://edge.launchpad.net/ubuntu/+source/gir-repository/0.6.5-6/+build/1736972
[12:51] <geser> seb128: the first one failed because it didn't detect libsoup (the log didn't tell why) and as a building it in my pbuilder (to check why) succeed I asked in #ubuntu-devel for a give-back (which pitti did)
[12:52] <seb128> ok, weird
[12:52] <seb128> I would like to know why the detection failed where the packages got installed
[12:53] <seb128> geser, I will sponsor your change for now, I had something similar but wanted to debug the other issue before upload, but since this one seems to have went away now...
[12:58] <geser> seb128: the problem might have been due to zlib1g-dev as the old one didn't have a .pc file and I've seen some builds checking for gnutls failing due to this (and libsoup2.4-dev depends on libgnutls-dev)
[12:58] <seb128> geser, hum, that makes sense, thanks
[12:59] <seb128> geser, I'm uploaded your change
[12:59] <geser> thanks
[12:59] <seb128> not sure if I should push the diff or let the autoimport deal with it though
[12:59] <seb128> thank you for fixing the issue
[13:06] <james_w> push!
[13:06] <seb128> james_w, I've bad experience with that
[13:06] <james_w> really?
[13:06] <seb128> I managed to make autoimport stop for some sources
[13:06] <seb128> which means you get outdated imports if the next person just upload
[13:07] <james_w> ah, well that's a bug
[13:07] <james_w> we should fix it, not work around it
[13:07] <seb128> and I've no clue how to fix those
[13:07] <chrisccoulson> seb128 - i should probably be disabling csd in firefox at some point shouldn't i? (i think it had issues last cycle)
[13:07] <seb128> ie to make autoimport work again
[13:07] <james_w> seb128: report a bug and I will look at it
[13:08] <seb128> chrisccoulson, right, I will upload csd to maverick today
[13:08] <didrocks> oh Friday cracky day so? :)
[13:08] <chrisccoulson> seb128 - ok, i will get that disabled in firefox too
[13:09] <seb128> didrocks, it's maverick, whoever is crazy enough to run it deserve the crack breakage ;-)
[13:09] <chrisccoulson> lol
[13:09] <didrocks> seb128: heh :-)
[13:10] <seb128> I'm doing my merges on lucid without installing
[13:10] <seb128> it should tell you a bit about maverick state ;-)
[13:10] <chrisccoulson> i see tracker no longer builds on maverick
[13:11] <seb128> james_w, bug against what?
[13:11] <seb128> james_w, I'm not even sure if that's not my who acted dump there
[13:11] <seb128> i.e is the autoimport supposed to update things when the bzr and archive are different?
[13:12] <james_w> seb128: bug against 'udd', or anything I'm subscribed to really :-)
[13:12] <james_w> seb128: I don't understand your other statements
[13:13] <seb128> james_w, I've commited things manually to the bzr
[13:13] <seb128> then did uploads without commiting
[13:13] <seb128> is the autoimport supposed to work on those cases?
[13:13] <james_w> yes
[13:13] <seb128> or the fact to manually commit put you in manual mode?
[13:13] <seb128> james_w, lp:ubuntu/libgnome-desktop
[13:13] <seb128> ups
[13:13] <pitti> seb128: yes, I can do it now (sorry, was off for lunch)
[13:13] <james_w> when you commit and push as well as upload it will check that what you uploaded is the same as what is committed
[13:14] <james_w> however, that's the most fragile part of the code
[13:14] <seb128> james_w, I mean lp:ubuntu/libgnome-keyring
[13:14] <james_w> but I need to know when it happens so that I can make it more robust
[13:14] <seb128> is the one I screwed
[13:14] <pitti> seb128: thanks for sponsoring gir
[13:14] <seb128> pitti, you're welcome, thank you for dealing with the workitems tracker ;-)
[13:14] <james_w> seb128: that's odd, I'll have a look thanks
[13:15] <seb128> james_w, do you want a bug? against udd? thanks for looking to it!
[13:15] <seb128> james_w, I'm sure I did something stupid but I don't know what and how to fix it
[13:17] <james_w> seb128: no, I think you just triggered a bug, so thanks!
[13:18] <seb128> james_w, thank you ;-)
[13:20] <pitti> seb128: flushed, copied back, reports regenerating now
[13:20] <seb128> pitti, you rock, thanks
[13:21] <james_w> seb128: ah, do you happen to remember how you did http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/libgnome-keyring/maverick/revision/5 ?
[13:21] <james_w> do you just drop the new .orig.tar.gz in to the parent dir, and then dch -v whatever?
[13:23] <seb128> james_w, bug #583770
[13:23] <ubot2> Launchpad bug 583770 in udd "lp:ubuntu/libgnome-keyring ubuntu auto-import is broken (affects: 1)" [Undecided,New] https://launchpad.net/bugs/583770
[13:23] <james_w> thanks
[13:24] <seb128> james_w, I'm not sure what I did exactly there, I think I mixed workflow for debian dir only in the vcs against source import
[13:24] <james_w> ok
[13:24] <seb128> ie I worked once in the directory as it was a debian dir only
[13:24] <james_w> do you know about "bzr merge-upstream"?
[13:24] <seb128> I managed to revert upstream changes in the diff.gz
[13:24] <seb128> yes, I use it for dx update
[13:25] <james_w> great
[13:25] <seb128> I just think I got confused between this one and screwed an update
[13:25] <pitti> seb128: http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team.html
[13:25] <james_w> it's a shame it doesn't currently work for debian-only, then you could use it for everything and avoid that
[13:25] <seb128> ie I did checkout the import and worked on it later as it was another desktop debian only dir
[13:25] <seb128> then I realized I reverted changes in the diff.gz
[13:25] <seb128> and did another upload
[13:25] <james_w> ah, ok
[13:25] <seb128> but the auto-import didn't cope with it
[13:26] <james_w> I need to think for a minute to see if we can handle this, but I may have to cause it to re-import those uploads so that they contain the pristine-tar data
[13:26] <seb128> feel free to overwrite the whole thing with auto imports
[13:26] <seb128> the few commits I did were broken anyway
[13:27] <seb128> I will do better with the next upload :-)
[13:27] <james_w> seb128: thanks, I'll think over lunch anyway
[13:27] <james_w> thanks for helping to improve the system :-)
[13:28] <seb128> ;-)
[13:30] <seb128> pitti, https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa?field.series_filter=karmic
[13:30] <seb128> should that one be cleaned?
[13:30] <seb128> what about the gdm one on https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa
[13:30] <pitti> seb128: atasmart is in proposed now, so it can go
[13:30] <pitti> seb128: gdm> same
[13:31] <seb128> pitti, ok, cleaning those
[13:31] <seb128> thanks
[13:36] <desrt> good morning everyone
[13:36] <seb128> hello desrt
[13:36] <desrt> pitti: i see you just can't bring yourself to leave this place :)
[13:36] <pitti> desrt: I just love this place too much :)
[13:37] <desrt> seb128: i was talking yesterday with robert and chris.  chris, particularly, thinks that dconf should drop from universe/debian
[13:37] <seb128> pitti, the trendline seems to need an update for the new schedule
[13:37] <seb128> ie 10.10.10
[13:37] <seb128> ups no
[13:37] <pitti> seb128: that requires fixing the milestones in LP
[13:37] <didrocks> good morning desrt
[13:37] <desrt> seb128: based on the fact that it hasn't been packaged in 2 years, has approximately 7 active users on popcon and when you start it up it spews a tonne of deprecation warnings then crashes
[13:37] <desrt> didrocks: hey
[13:37] <seb128> pitti, seems I mistead the legend
[13:37] <desrt> seb128: they wanted to defer to you to talk to the debian guys, though
[13:38] <seb128> desrt, chrisccoulson?
[13:38] <desrt> seb128: yes
[13:38] <seb128> I'm not interested by talking to the debian guys
[13:38] <seb128> I think we should not hijack an existing namepsace
[13:38] <desrt> 00:12 < chrisccoulson> the existing dconf in the archive really should just be  removed, it hasn't been updated for over 2 years now
[13:38] <seb128> namespace
[13:38] <desrt> 00:13 < chrisccoulson> ok, i will check to make sure nothing is build-depending  on it and ask an archive admin to remove and blacklist it
[13:39] <desrt> 00:13 < robert_ancell> I'll get the packaging working and get seb to check this  out, he's more on the pulse of Debian
[13:39] <chrisccoulson> yeah, i haven't done that yet. seb128 - what do you think?
[13:39] <seb128> you can try
[13:39] <seb128> I'm not interested to try
[13:39] <seb128> I think it's wrong
[13:39] <seb128> it will lead to issues
[13:39] <james_w> you can remove dconf, but for Debian at least, you have to wait a release cycle until you can take the name
[13:39] <pitti> will the binary packages really conflict?
[13:39] <desrt> if you think it's wrong then probably we should just not do it, then
[13:39] <seb128> having 2 differents things using the same namespace leads to issues
[13:40] <pitti> isn't it all just libraries?
[13:40] <desrt> pitti: the binary packages will not
[13:40] <desrt> pitti: it's more about the source package name
[13:40] <desrt> i suggested we just call the new source package 'dconf-source' or something
[13:40] <seb128> I would be fine renaming both
[13:40] <pitti> desrtconf?
[13:40] <seb128> to avoid apt-get source dconf giving the wrong one
[13:40] <desrt> pitti: sure :p
[13:40] <chrisccoulson> is the name an issue? i thought the main issue is that the current dconf ships conflicting binaries
[13:40] <desrt> seb128: ya.  that's the other issue.
[13:40] <seb128> I'm a bit reluctant to reuse a name for something different
[13:41] <desrt> seb128: i have a sneaking suspicion that the 7 people on popcon who installed dconf recently thought that they were getting my dconf :p
[13:41] <desrt> chrisccoulson: oh right.  that too.
[13:41] <desrt> seb128: dconf will have /usr/bin/dconf
[13:41] <seb128> it does?
[13:42] <desrt> same story as epiphany here, i guess?
[13:42] <seb128> sucks
[13:42] <chrisccoulson> so, we could work around the name (wasn't "d-conf" suggested yesterday?), but the conflicting binaries is more difficult
[13:42] <pitti> desrt: oh, is that a gconftool-like thing?
[13:42] <desrt> pitti: ya
[13:42] <desrt> pitti: with interface like the current 'gsettings' and 'gdbus' tools (ie: git-inspired)
[13:42] <desrt> dconf get ...
[13:42] <desrt> dconf set ...
[13:44] <desrt> rumour has it that 'gdbus' will be installed as '/usr/bin/dbus' soon
[13:44] <desrt> looks like there's no problem there, fortunately
[13:45] <pitti> /usr/bin/gdbus I hope?
[13:45] <desrt> nah.  just 'dbus'
[13:45] <desrt> by request of dbus maintainers
[13:45] <seb128> we should maybe drop current dconf and use the namespace for the new one
[13:45] <chrisccoulson> that's what i thought. the current dconf hasn't been touched since august 2007
[13:45] <desrt> seb128: is it possible that we drop the current package and use a different name for the packages at least for now?
[13:46] <desrt> like 'desrtconf' or whatever
[13:46] <chrisccoulson> i'm not sure anybody would miss it ;)
[13:46] <desrt> then in a year or two, we rename the source package?
[13:46] <desrt> just to avoid the trouble you were concerned about...
[13:46] <seb128> I think it's not so much of an issue for sources
[13:46] <pitti> I'm all for dropping dconf, the only downside that I see that this would prevent us from being able to keep the new dconf in sync with debian
[13:46] <seb128> would be an issue for binaries
[13:47] <seb128> i.e like epiphany
[13:47] <Laney> sounds like something to coordinate with debian
[13:47] <seb128> you use the game
[13:47] <seb128> and then get the browser and no game after updaging
[13:47] <seb128> upgrading
[13:47] <desrt> heh
[13:47] <seb128> Laney, right, cf backlog
[13:47] <desrt> this presupposes that you use the game
[13:47] <desrt> nobody does that :p
[13:47] <seb128> lol
[13:47] <chrisccoulson> that's why firefox has all the transitional packages, to handle upgrades where binary package names change ;)
[13:47] <desrt> (except people who were trying to install the browser...)
[13:47] <pitti> would it be so bad to call it d-conf in both D and U for now?
[13:47] <seb128> chrisccoulson, well it stays firefox for those
[13:48] <desrt> pitti: aww.  i liked the desrtconf name :)
[13:48] <chrisccoulson> seb128 - it does now
[13:48] <seb128> chrisccoulson, I mean all the variants are still the firefox browser
[13:48] <seb128> you didn't hijack a game names firefox
[13:48] <chrisccoulson> ah, yeah, true
[13:48] <pitti> desrt: you could also call it d#conf or d♭conf :)
[13:50] <chrisccoulson> or ɟuoɔp
[13:50] <desrt> chrisccoulson: WIN
[13:51] <ccheney> hi
[13:53] <mclasen> desrt: talking about names...is ca.desrt.dconf the final busname ?
[13:53] <desrt> mclasen: this is difficult.
[13:53] <desrt> obvious alternatives being org.gnome org.freedesktop and org.gtk
[13:53] <desrt> all of them having politics attached
[13:54] <desrt> totally doesn't matter as far as i'm concerned
[13:54] <desrt> and it's very easy to change in the future
[13:54] <desrt> the dbus API is private
[13:55] <seb128> chrisccoulson, could you open a debian bug on dconf?
[13:55] <seb128> asking for a rename or get it cleaned
[13:55] <chrisccoulson> seb128 - ok, will do
[13:56] <seb128> chrisccoulson, thanks
[13:59] <desrt> thanks, guys
[13:59] <desrt> probably much less confusing this way, in the long run
[14:35] <didrocks> seb128: do you know if this is still valid (http://paste.ubuntu.com/437340/)? Debian doesn't have it
[14:36] <seb128> didrocks, do we still build out of the srcdit?
[14:36] <seb128> srcdir
[14:36] <seb128> didrocks, or said differently, do we have a po/*.pot after build
[14:37] <seb128> didrocks, debian doesn't need it, it's for rosetta import
[14:37] <didrocks> seb128: I see nothing in that regard in debian/rules, I guess there is no other file when you can change srcdir?
[14:37] <didrocks> seb128: I'll have a testbuild without it and see
[14:37] <seb128> didrocks, ok, thanks
[14:37] <seb128> didrocks, I think it used to build 2 variants
[14:38] <seb128> one hildon one and a normal one
[14:38] <seb128> or something
[14:38] <seb128> so it was building out of the srcdir
[14:38] <seb128> it might not apply now
[14:38] <didrocks> seb128: you're welcome, I'll have a look at debian/rules for the version you added that to see how it was described in debian/rules
[14:38] <seb128> try without it and see if the pot is there
[14:40] <didrocks> ok, I see how it was on debian/rules, with two binary packages and two builds. No we don't have that. I'll confirm by a build
[14:40] <seb128> cool
[14:53] <momelod> Greetings channel
[14:53] <momelod> Im trying to setup a wireless internet stick I got from my cellular provider.
[14:54] <momelod> I have defined a connections in NetworkManager->edit connections->mobile broadband
[14:54] <momelod> but how do i launch it? when i click on network manager I dont see it listed as an available connection..
[15:02] <didrocks> momelod: this is a developer channel, for support, please see on #ubuntu
[15:11] <momelod> thanks
[15:28] <Amaranth> seb128: So I was thinking of taking advantage of the multiple tarball support of 3.0 source packages and putting compiz, compiz-plugins-main, and compiz-plugins-extra in one source package
[15:29] <Amaranth> seb128: Then we can more easily make sure they are updated at the same time and partition groups of plugins however we want (used vs unused, for example)
[15:53] <ccheney> grr, BOA called claiming i hadn't paid my mortgage, they screwed up their records and can see it themselves when i called in :-(
[15:55]  * kenvandine imports 22728 photos into shotwell
[15:55] <kenvandine> lets see how long this takes
[15:56] <ccheney> heh my iphone is giving itself gsm interference noise
[15:57] <LaserJock> didrocks (whenever you get a chance): was there any work done on porting netbook-launcher to liblauncher 0.3?
[15:57] <LaserJock> kenvandine: are you using Lucid's shotwell?
[15:57] <kenvandine> yes
[15:59] <kenvandine> looks like it will take a while, it appears to preview every photo on import
[15:59] <kenvandine> using a ton of CPU, but it is remarkable how low the memory usage is
[16:00] <kenvandine> 34m RSS and 236% cpu usage
[16:10] <dobey> kenvandine: 236% cpu?
[16:10] <kenvandine> hehe... yeah
[16:10] <dobey> kenvandine: have you like, perfected quantum computing?
[16:10] <kenvandine> impressive huh?
[16:11] <dobey> your cpu is actually in 3 different dimensions, and it's using 100% in 2 of them, and 36% in the third? :)
[16:11] <kenvandine> apparently
[16:12] <kenvandine> this is going to take a while...
[16:12] <dobey> heh
[16:13] <didrocks> LaserJock: not from what I know. I'll upload it next week to maverick, maybe the right time to port that?
[16:20] <seb128> Amaranth, hum, not sure, the plan was to get in sync with debian
[16:20] <seb128> didrocks, hum, alacarte, why did you drop the properties change?
[16:20] <didrocks> seb128: ooppss, miss it so, will reupload
[16:21] <seb128> didrocks, thanks
[16:21] <didrocks> seb128: I tried the review with bzr merge-package maybe I miss something in the workflow
[16:21] <didrocks> sorry about that
[16:21] <seb128> no worry
[16:21] <Amaranth> seb128: The guy I'm pretty sure handles compiz in Debian had the same idea but wanted to wait to figure out git submodules first
[16:21] <Amaranth> Which I assuming means rolling his own orig.tar.gz
[16:21] <Amaranth> s/I/I'm/
[16:27] <Amaranth> seb128: Debian still ships compiz-gtk, I don't think getting in sync is a good idea unless it involves them making changes to get more in line with our packaging of compiz
[16:28] <LaserJock> didrocks: you're doing a new netbook-launcher or liblauncher upload next week?
[16:28] <seb128> Amaranth, well if it works for them it should work for us?
[16:28] <LaserJock> didrocks: the porting might take me a while to do, at least it wasn't trivial when I looked during lucid
[16:28] <seb128> Amaranth, really is that we have nobody maintaining compiz and we do a poor job at it
[16:28] <didrocks> LaserJock: not sure about next week, I have already tons of things on my plate right now. If you want to do it, I'll happily sponsors you
[16:28] <seb128> Amaranth, we would win to share work with debian
[16:28] <Amaranth> The packaging side is almost no work
[16:29] <Amaranth> The bug triage is the work and unless we drop all of our patches that isn't going to change
[16:29] <seb128> dealing with bugs is the work
[16:29] <LaserJock> didrocks: well, do you have anything already planned for non-unity maverick uploads? I don't know what the current status is
[16:29] <seb128> they seem to do a better job that us to it recently
[16:30] <LaserJock> didrocks: I'm happy to start hacking away on porting it
[16:30] <didrocks> LaserJock: not right now, uploading unity to maverick will take me a long time already
[16:30] <LaserJock> didrocks: ok, I just didn't want to duplicate or miss work you're planning on
[16:33] <Amaranth> seb128: So you want to drop our patches and just sync from Debian?
[16:33] <didrocks> LaserJock: no pb, just keep me in touch :)
[16:33] <LaserJock> didrocks: k, will do
[16:33] <seb128> Amaranth, I want to investigate whether it would be doable and a good idea
[16:33] <seb128> Amaranth, or at least be back in sync for all the side packages, ccsm, -gconf, etc
[16:42] <Amaranth> seb128: I'm fine with getting back in sync with Debian for the side packages, we don't patch them or anything
[16:43] <Amaranth> seb128: But we modify compiz quite a bit
[16:43] <seb128> ok
[16:43] <seb128> thanks for the feedback
[16:43] <Amaranth> Although since development seems to be moving to mutter I suppose we don't need to modify it to start faster, it's already 10x faster than mutter for that
[16:45] <seb128> Amaranth, not my experience there
[17:16] <seb128> chrisccoulson, I uploaded gtk csd in maverick
[17:17] <seb128> chrisccoulson, you might want to upload firefox to get decoration back for it
[17:19]  * kenvandine heads out to lunch, bbiab
[17:56] <chrisccoulson> seb128 - thanks, i will disable that in firefox later then
[18:02] <pitti> good night everyone, have a nice weekend!
[18:02] <didrocks> enjoy your weekend pitti!
[18:45] <didrocks> kenvandine: do you know of any documentation about the batch_update() method in desktopcouch?
[18:46] <kenvandine> i don't
[18:47] <didrocks> ok, worth a try :)
[18:52] <kenvandine> didrocks, my ultimate source is #ubuntuone :)
[18:53] <didrocks> kenvandine: sure, I'll delegate that for next week though :)
[19:00] <cjohnston> kenvandine: any further thoughts on bug 580067?
[19:00] <ubot2> Launchpad bug 580067 in gwibber "twitter fails to download messages, sometimes (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/580067
[19:01] <kenvandine> cjohnston, ryan was going to look at it... he was very interested in it
[19:01] <kenvandine> he is at google I/O though...
[19:01] <cjohnston> ahh
[19:02] <kenvandine> he has some suspicions, and has been looking for someone that could repro it
[19:02] <kenvandine> so glad you found it :)
[19:03] <cjohnston> I am able to reproduce it daily.. heh   without any effort on my part
[19:03] <cjohnston> I'm glad I don't live by twitter
[19:18] <kenvandine> cjohnston, ryan thinks it might be something related to the way we compute the last message we downloaded
[19:18] <cjohnston> hmm//
[19:18] <kenvandine> so it fails to fetch more messages because it is trying to get messages that doesn't exist
[19:18] <cjohnston> gotcha
[19:19] <kenvandine> which he had suspected was a bug before you found this, but could never prove it
[19:19] <cjohnston> well.. then i guess we should hope that is what it is
[19:19] <kenvandine> yeah :)
[19:19] <kenvandine> i'll bug him about it
[19:19] <cjohnston> lol
[19:20] <cjohnston> you know where to find me
[19:53] <jcastro> kenvandine: http://sjoerd.luon.net/posts/2010/05/telepathy_and_vp8/
[19:53] <jcastro> YEAH!
[20:04] <kenvandine> jcastro, woot!
[20:55] <ccheney> Riddell, ping
[20:56] <ccheney> Riddell, i just saw that kubuntu-desktop doesn't pull in ttf-liberation, which is not so good
[20:56] <ccheney> Riddell, openoffice.org defaults to 'Times New Roman' which is not metric compatible with that, but due to not having any metric compatible fonts on the disk it ends up using it anyway
[20:57] <ccheney> er sorry
[20:58] <ccheney> Riddell, i meant the above to say since ttf-liberation is not installed which is metric compatible with 'Times New Roman' then it falls back to 'Times' which then falls back to 'Nimbus Roman No9 L' which is the font not metric compatible with 'Times New Roman'
[20:58] <ccheney> Riddell, it appears ubuntu, xubuntu, lubuntu all pull ttf-liberation in directly probably due to the metric issue
[21:00] <ccheney> Riddell, it might be a good idea to pull it in for 10.04.1 as well due to problems working with documents on kubuntu due to that (if allowable)
[21:01] <ccheney> Riddell, i haven't gotten any bugs reports about this issue afaik but saw it when testing another bug under kubuntu
[21:02] <ccheney> Riddell, if you would like i can file a bug about kubuntu-meta
[21:02] <ccheney> s/about/against
[22:51] <ccheney> hmm example-content is also missing from kubuntu