[06:57] <pitti> Good morning
[06:58] <pitti> tlyu: hello
[06:58] <pitti> tlyu: oops, sorry; tab completion error
[07:16] <SpamapS> pitti: hey, got a second to answer a question about upower?
[07:22] <pitti> SpamapS: sure, what's up?
[07:23] <SpamapS> pitti: so, on my macbook pro 5,1 I used to be able to suspend, but now I can't..
[07:23] <SpamapS> pitti: upower --dump shows can-suspend: no
[07:24] <pitti> SpamapS: what changed between "then" and "now"? dist-upgrade?
[07:24] <SpamapS> pitti: I see your name come up on a lot of upower bugs and comments, so I'm hoping you have some advice for me as to where to start looking
[07:24] <SpamapS> pitti: no, I installed laptop-mode-tools is all I can think of
[07:24] <dholbach> good morning!
[07:24] <pitti> SpamapS: it conflicts with pm-utils
[07:25] <pitti> hey dholbach
[07:26] <dholbach> hey pitti
[07:27] <SpamapS> pitti: so, upon removing laptop-mode-tools, I needed to also re-install pm-utils, and that should enable suspend again?
[07:27] <pitti> SpamapS: you can't install both at the same time, they conflict
[07:28] <pitti> SpamapS: pm-utils already does most of the useful stuff of pm-utils
[07:28] <pitti> sorry, of l-m-t
[07:29] <SpamapS> well and with l-m-t installed, I just can't suspend at all. :(
[07:31] <SpamapS> pitti: so, I just removed l-m-t and installed pm-utils again.. should I reboot to get upowerd to find pm-utils again?
[07:32] <SpamapS> pitti: thanks for taking a look btw.
[07:32] <SpamapS> This seems like a bug report worthy problem.. l-m-t shouldn't totally disable suspend.. :-P
[07:34] <pitti> SpamapS: reboot shouldn't be necessary
[07:35] <pitti> SpamapS: well, l-m-t should be removed completely, and remaining useful functionality integrated into pm-utils really
[07:37] <SpamapS> pitti: upower --dump still shows can-suspend: no
[07:37] <pitti> SpamapS: try "sudo killall upowerd"
[07:37] <SpamapS> yaaaaay
[07:37] <SpamapS> I was afraid to do that..
[07:38] <SpamapS> it can be downright dangerous
[07:39] <SpamapS> I installed laptop-mode-tools thinking it would be helpful on my vacation to have better battery life through aggressive techniques that it uses..
[07:39] <SpamapS> then I closed the lid, threw the laptop in my backpack, and went to the airport...
[07:39] <SpamapS> as I was in line for security I noticed my back getting HOT
[07:39] <SpamapS> the case of the MBP nearly burned my hand
[07:40] <SpamapS> pitti: thanks for the tips. I'll file a bug report against laptop-mode-tools now
[07:40] <pitti> SpamapS: "stop existing"? :-)
[07:41] <micahg> SpamapS: I had a similar problem at UDS
[07:46] <SpamapS> bug 638307 seems to already be there. :p
[07:47] <SpamapS> pitti: I think the proper fix for that bug is probably to just remove it.
[07:49] <SpamapS> micahg: btw, it was a pleasure meeting you at UDS.. I don't think we've had a chance to chat since then. :)
[07:50] <micahg> SpamapS: indeed, what TZ are you in BTW?
[07:54] <SpamapS> micahg: pacific
[07:55] <SpamapS> micahg: but I just got back from HI timezone. :)
[07:55] <micahg> SpamapS: ah, ok
[07:57]  * SpamapS finishes updating the mactel help page that led him astray to l-m-t in the first place
[10:15] <mpt> pitti, hi, do you know why the work items tracker might be showing only 2 items for me this cycle when I actually have 16 or so?
[10:16] <mpt> (Not that I'm complaining about lack of work or anything)
[10:16] <doko> Riddell, ScottK: jbrown is looking to fix qt this week.
[10:17] <pitti> mpt: where do you see that?
[10:17] <mpt> pitti, <http://people.canonical.com/~platform/workitems/natty/all.html> says "mpt		2	0	0	0	0	0%"
[10:18] <mpt> pitti, it doesn't include the 3 items for me on <https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-donations-for-free-software-through-software-center> for example
[10:18] <pitti> mpt: that's because this spec isn't targetted for natty
[10:19] <pitti> apparently it was added much after UDS (Jason and I went through the UDS specs and targetted everything)
[10:19] <pitti> mpt: added to natty now
 is from before UDS but doesn't look targeted either
[10:20] <pitti> mpt: this needs urgent drafting and review, though
[10:20] <pitti> mpt: btw, it is named "desktop", but stuart is from the u1 team, isn't he?
[10:20] <Chipzz> mpt: why are you adding <> around your links?
[10:20] <pitti> mpt: it doesn't have any people assigned
[10:21] <Chipzz> makes it harder to copy/paste them ;)
[10:21] <pitti> mpt: we don't want to plan this for natty unless we actually have someone to work on it -- do you know if someone is?
[10:21] <mpt> pitti, there are assignees for all of the work items.
[10:21] <mpt> I can't set the assignee for the bp as a whole because I didn't register it.
[10:22] <pitti> mpt: is that ready for review?
[10:22] <mpt> I don't know what that means.
[10:22] <pitti> mpt: updated that one, too
[10:22] <pitti> mpt: status is "new"
[10:22] <mpt> thank you
[10:23] <pitti> mpt: by now, the desktop specs should be drafted by the drafter, and set to "pending approval" or "review"
[10:23] <pitti> (our team deadline was last Tuesday, but it's still fine to add to the pot)
[10:23] <mpt> I thought we stopped "drafting" specifications a couple of years ago
[10:23] <mpt> since we started using the work item tracker instead
[10:23] <pitti> mpt: the wiki pages, yes; but we still use the status, and it now means that the whiteboard and work items are "ready"
[10:24] <mpt> So I need to find the person who registered each one and ask them nicely to set the status to "Pending Approval"
[10:24] <mpt> and then find someone else and ask them nicely to approve it
[10:25] <mpt> thanks pitti, sorry for the trouble
[10:26] <pitti> mpt: I can do that for you, just wanted to know if you or Scott are still working on drafting
[10:26] <pitti> (done)
[10:26] <mpt> No, it's complete, we both know what we need to do
[10:27] <pitti> good
[10:39] <mpt> Chipzz, I've done that since about 1999 because it disambiguates where the URL ends and punctuation around it begins.
[10:39] <Chipzz> mpt: actually I think it creates the very problem you're trying to avoid :)
[10:39] <mpt> Most IRC clients have "Copy Link" or similar menu items.
[10:39] <Chipzz> but that's just my 2c
[10:40] <Chipzz> to say more, I would say it makes the very problem you're trying to avoid *worse*
[10:43] <geser> pitti: do you know if any "decision" about postgresql-9.0 in natty got made?
[10:44] <pitti> geser: wasn't discussed yet
[10:45] <geser> do you know when it's going to get discussed? (so I know when to ask about an update)
[10:47] <pitti> geser: main problem is that all packaged extensions are still 8.4
[10:47] <pitti> and we don't have anyone in Ubuntu who deals with them
[10:48] <pitti> we could stick with 8.4 until Debian squeeze releases
[10:49] <geser> in that case "postgresql-debversion" should probably only build for 8.4, right? it currently wants to build for 9.0 too
[10:50] <pitti> geser: how many packages does this affect?
[10:50] <pitti> if there's a significant number of Debian packages building for 9.0, we could just switch
[10:50] <geser> till now I've only spotted postgresql-debversion in the FTBFS list
[10:50] <sebner> didrocks: /here in natty compiz quite crashes pretty often when doing a lot of scrolling in Ooo.(?!), have you heard of such a weird thing before? Couldn't find a bug about it yet
[10:51] <didrocks> sebner: not that one. Can you please get a backtrace, file a bug and subscribe smspillaz, please?
[10:56] <sebner> didrocks: aye
[10:56] <geser> pitti: looks like postgresql-debversion is the only package for 9.0 (couldn't find another in Debian either)
[10:57] <Riddell> doko: who's jbrown?
[10:57] <didrocks> sebner: thanks :)
[10:57] <doko> Riddell: see #linaro
[11:06] <cjwatson> mpt: better to just ensure there's whitespace around the URL, IME
[11:07] <cjwatson> (not that it's all that desperately important)
[11:07] <ScottK> doko: Thanks (re Qt).
[11:07] <mpt> cjwatson, that means following punctuation sometimes ends up on a separate line when it should not.
[11:09] <cjwatson> *shrug*
[11:10] <cjwatson> you could use a non-breaking space, or reword.
[11:10] <cjwatson> I used to do the <> thing too, then discovered it didn't really work well in practice so stopped
[11:17] <JanC> the <> delimiters are actually recommended practice in the URL/URI RFCs (and they work fine in XChat)
[11:18] <JanC> but whitespace works too
[11:20] <cjwatson> I know, but they rely too heavily on people having just the right word selection algorithm in their terminal
[11:20] <cjwatson> communication is best when it's convenient for other people, after all
[11:22] <pitti> ebroder: FYI, we should stop the un-perl-ification for now; this requires some discussion with the Debian perl maintainers first
[11:28] <apw> cjwatson, fyi it looks like the live CDs boot at least on amd64
[11:28] <sebner> didrocks: meh, that's all I get: http://pastebin.com/sDBTvj6c , when debugging in gdb the screen freezes so I have to kill compiz manually and therefore get no real backtrace :( Any suggestion? (don't do debugging that often)
[11:28] <cjwatson> apw: oh good.
[11:29] <didrocks> sebner: run it on tty1 with gdb compiz | tee log
[11:29] <didrocks> sebner: then: run --replace
[11:29] <didrocks> (of course export DISPLAY=:<your_display/screen> first :))
[11:30]  * cjwatson discovers that his peak sustained merge performance is around 16 packages per hour
[11:30] <didrocks> waow :)
[11:30] <apw> cjwatson, that sounds like a lot to me
[11:31] <cjwatson> otavio did a big pile of translation uploads to d-i, so most of those were fairly easy, but hence "peak"
[11:35] <sebner> didrocks: I'll try :)
[11:35] <Chipzz> cjwatson: rock :)
[11:37] <Chipzz> cjwatson: out of curiosity, what does that number look like in more normal cicrumstances? :)
[11:38] <pitti> doko: --as-needed by default> cool!
[11:41] <pitti> cjwatson: bzr FTW :)
[11:42] <cjwatson> Chipzz: not sure, maybe more like half a dozen or so
[11:44] <Chipzz> pitti: as much as I applaud that (and I do), won't that cause like *tons* of FTBFS'es?
[11:45] <pitti> Chipzz: how so?
[11:45] <pitti> how is revision control related to testing and building packages?
[11:45] <Chipzz> pitti: I meant the --as-needed
[11:46] <pitti> Chipzz: presumably it will; OTOH a lot of packages explicitly enable that in debian/rules or patches right now
[11:47] <Chipzz> pitti: there's the matter of "what's a lot" though. :) If hundreds of packages use it now, that is indeed a lot, but still a rather small fraction of the whole archive?
[11:47] <pitti> Chipzz: well, let's see how much it breaks
[11:47] <pitti> Chipzz: I've seen a few packages failing with --as-needed, but most just work
[11:48] <Chipzz> but anyway don't get me wrong, this is something I applaud big time :)
[11:48] <cjwatson> Chipzz: yes, it causes a decent number, hence doing it at the start of a release cycle
[11:48] <cjwatson> not insuperably enormous though
[11:49] <Chipzz> cjwatson: with the possibility of rolling it back if too much breaks I presume?
[11:50] <cjwatson> they're generally simple to fix, too
[11:50] <cjwatson> Chipzz: well, it's just a switchable default so I suppose so, but I don't think it will be necessary
[11:51] <cjwatson> there'd been a mass-bug-filing campaign about this in Debian for quite a while before we changed the default
[11:51] <Chipzz> cjwatson: ah k, that changes things
[11:51] <Chipzz> did doko do a test-rebuild of the whole archive though?
[11:52] <Chipzz> (isn't that what's usually done when introducing such pervasive changes? :))
[11:53] <cjwatson> I don't recall, you'd have to ask him.  I trust him to have a good understanding of how much it was going to break, and it doesn't worry me
[11:54] <cjwatson> bug 673073 worries me more because the resulting build failures are harder to fix
[11:55] <Chipzz> right, but that has a different cause though :)
[11:57] <doko> Chipzz: no, a lot of the failures are already fixed upstream (Fedora already has this change).
[11:58] <doko> Chipzz: about the build failures, yes, need to be fixed. please subscribe me to bug reports
[11:58] <cjwatson> Chipzz: I know it has a different cause; my point is that in general causes of hard build failures are more worrying than causes of easy build failures
[11:58] <cjwatson> and I don't think we should agonise too much about the latter early in the release cycle
[12:03] <sebner> didrocks: this ok? bug #675506
[12:04] <didrocks> sebner: well, extra points if you can install the -dbgsym package and get debug symbols :)
[12:05] <sebner> didrocks: I thought so but couldn't find a compiz-dbg package?!
[12:06] <didrocks> sebner: there are -dbgsym in the ddebs repo: http://ddebs.ubuntu.com/pool/main/c/compiz/
[12:06] <didrocks> sebner: more info at https://wiki.ubuntu.com/DebuggingProgramCrash (they are generated automatically)
[12:07] <didrocks> sebner: so, *compiz*/*glib* dbgsym should be enough already
[12:07] <ogra_ac> lool, why is bug 587632 set back to inprogress ? do you know of someone working on it ?
[12:09] <lool> ogra_ac: I think I documented that Dave was working on it back then
[12:09] <lool> ogra_ac: See the earlier activity in the bug by him
[12:09] <ogra_ac> oh, i see the order of comments is out of sync due to cjwatson fixing the LP janitor inbetween
[12:10] <apw> cjwatson, also booted i386 live natty, also seems to work
[12:10] <ogra_ac> lool, yeah, i was confused by the manual close after dave worked on it
[12:10] <ogra_ac> seems the marm can go andd i should just update the patch
[12:11] <lool> ogra_ac: In any case it was wrong to have it Fix Released
[12:11] <ogra_ac> lool, yes
[12:16] <didrocks> ogra_ac: hey
[12:16] <didrocks> ogra_ac: did you see your WI to port the part for armel in the netbook seed to the desktop one?
[12:16] <ogra_ac> didrocks, nope, not yet, i'll take a look
[12:17] <didrocks> ogra_ac: ok, I'll take care about the netbook != armel part. This should be done for A1 so that we can kill the netbook seed and iso
[12:18] <didrocks> (apart if you see that you still want just one for armel)
[12:18] <ogra_ac> didrocks, we will likely needs something "non GL-ish"
[12:18] <ogra_ac> *need
[12:19] <ogra_ac> since 80% of the arm HW wont have free drivers we can just ship
[12:19] <didrocks> ogra_ac: right, but that's not related to having a netbook seed or not
[12:19] <didrocks> ogra_ac: it's either, editing the desktop seed and adding [!armel] and [armel]
[12:19] <ogra_ac> well, as i understand it for x86 the fallback will be a plain desktop
[12:21] <sebner> didrocks: done, thanks for your help!
[12:21] <didrocks> ogra_ac: yes, so that should work for you as well. It's not related to the seed stuff
[12:21] <didrocks> sebner: great!
[12:21] <ogra_ac> didrocks, we would like to have a 2D netbook UI for netbook images
[12:22] <ogra_ac> while that will work with !armel/armel it will be a lot more work to maintain i suspect
[12:22] <ogra_ac> and we will likely also have some arches where we will have to provide plain desktop images
[12:22] <ogra_ac> how do you plan to do a preselection ?
[12:23] <ogra_ac> if you have all sessions in the same image
[12:23] <ogra_ac> (note that we neeeed to select the session at build time on the preinstalled images, no preseeding available)
[12:23] <didrocks> ogra_ac: we will kill the netbook image for i386 and others at least, as the selection is only "do you have brasero or cheese"
[12:24] <didrocks> ogra_ac: please look at the blueprint: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-bringing-desktop-and-netbook-image-closer
[12:24] <ogra_ac> yes, i'm looking at that since you pinged me
[12:25] <didrocks> ogra_ac: why do you want a preselection? if unity can't run, it will fallback to the traditional GNOME ui
[12:25] <ogra_ac> right, what about armel netbook users that dont have GL drivers installed by default ?
[12:26] <didrocks> ogra_ac: well, unity and compiz won't be able to run on them, so compiz will fallback to metacity with gnome-panel
[12:26] <didrocks> ogra_ac: this is specified at https://blueprints.launchpad.net/ubuntu/+spec/other-dx-n-unity-compiz
[12:27] <ogra_ac> right, we want to have a solution for 2D as we always did
[12:27] <ogra_ac> didrocks, see PM
[12:35] <didrocks> cjwatson: is it possible to keep the netbook seed right now, rename it armel and only have an armel build image from it?
[12:38] <cjwatson> I guess, but I'd rather you didn't rename it - it's confusing to have seeds named after architectures, IMO
[12:39] <didrocks> cjwatson: but if we don't rename it, can there be some confusion that there is no more "UNE" but still a netbook seed?
[12:39] <didrocks> if you can just ensure for now that we only build armel from it, it will be a start :)
[12:45] <cjwatson> pitti: I just ran across bug 674632 - the suggested patch works for me
[12:46] <cjwatson> didrocks: seeds aren't particularly user-visible, so I doubt there would be much confusion
[12:47] <ogra_ac> its rather about the amount of extra maintenance not about user confusion
[12:55] <didrocks> cjwatson: sounds the safest way then, agreed
[12:59] <pitti> cjwatson: oh, didn't see that it got filed; I fixed it this morning, closing
[12:59] <cjwatson> thanks
[13:14]  * pitti o_O: dbus-python (0.83.1-1) UNRELEASED; urgency=low
[13:15] <pitti> was this a fake sync/upload?
[13:18] <cjwatson> pitti: no.  the Debian maintainer appears to have hacked about with their .changes file before upload - the package in Debian really is like that.
[13:19] <pitti> ah, thans
[13:39] <ScottK> doko: Was #675240 intentional?  If so, I'll close the bug.
[14:14] <cjwatson> SpamapS: I suggest that https://wiki.ubuntu.com/ServerTeam/Specs/Natty/UpstartServerEnhancements ought to mention the plymouth interworking that's in a work item on the corresponding LP page
[14:17] <geser> is there a connection between the "core" package set and packages in main or is it pure coincidental that almost all packages from "core" are in main?
[14:17] <cjwatson> core should be a strict subset of main, aside from temporary desynchronisation
[14:18] <cjwatson> issues
[14:19] <geser> is "ruby1.9.1" such an issue? (it's have always been in universe as far as LP tells)
[14:19] <doko> ScottK: yes, let's see if we get the qt fix this week, else I'll revert the gcc change temporarily
[14:20] <ScottK> doko: OK.  A warning would have been nice as that affected work I was trying to do over the weekend.
[14:22] <doko> ScottK: well, I didn't expect that something like this wasn't yet fixed, even in header files
[14:22] <ScottK> OK.
[14:22] <diwic> is "a USB device" or "an USB device"?
[14:22] <diwic> s/is/is it
[14:23] <cjwatson> geser: good question ...
[14:24] <geser> cjwatson: I noticed it while working on adding packageset information to the FTBFS page (I'm also wondering why gimp is in the ubuntu-server packageset)
[14:24] <cjwatson> geser: ah, yes.  you can see it in http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - currently scheduled for either (a) promotion to main following MIR or (b) developer deciding that it's not needed and removing it
[14:24] <cjwatson> geser: packagesets tend to correspond more to the view of main that would result if all of component-mismatches were applied
[14:27] <geser> so packages get sometimes added to packagesets before their MIR bug gets processed?
[14:27] <cjwatson> yes
[14:28] <cjwatson> largely because the process of main/universe promotion/demotion and packageset movement aren't yet integrated
[14:28] <cjwatson> which in turn is because the first is done on cocoplum inside sudo -u lp_archive, and the second is a launchpadlib operation ...
[14:29] <cjwatson> if somebody made the first of those into a launchpadlib operation, it would be possible to integrate the two processes
[14:30] <geser> just curious: do you know why "gimp" is in the "ubuntu-*server*" packageset?
[14:30] <cjwatson> the best way to find this out is to look at germinate output
[14:31] <cjwatson> it's basically loads of build-depends
[14:31] <cjwatson> e.g. gutenprint (in print-server) build-depends: libgimp2.0-dev
[14:32] <geser> ah
[14:41] <cjwatson> ebroder: your gfxpayload-blacklist branch looks good enough to me that I'm just going to merge it and then play around with it ...
[14:41] <cjwatson> ebroder: have you sent all the grub-extras changes upstream?  I saw the enum_pci fix
[14:41] <cjwatson> ebroder: also worth noting that PCI enumeration broke a couple of machines late in the maverick cycle, so we're going to have to figure out what's up there
[14:42] <cjwatson> but of course explicitly setting GRUB_GFXPAYLOAD_LINUX is a workaround for that
[14:56] <cjwatson> jibel: are you intending to draft other-qa-n-testing-different-architectures?
[15:02] <seiflotfy> hey guys
[15:14] <ebroder> cjwatson: I sent the bitop and enum_pci changes upstream. The only other change in my branch should be backporting to the 1.98 version of the extras
[15:22] <cjwatson> ebroder: right - planning to switch to 1.99 in the natty cycle anyway
[15:23] <jcastro> charlie-tca: if you have time can you confirm the fix in the PPA here so we can roll it out? https://bugs.launchpad.net/ubuntu/+source/tomboy/+bug/627744
[15:24] <charlie-tca>  sure.
[15:24] <SpamapS> cjwatson: re plymouth<->upstart WI interworking on https://wiki.ubuntu.com/ServerTeam/Specs/Natty/UpstartServerEnhancements: ack, will add mention.
[15:40] <SpamapS> cjwatson: spec updated. Thanks for the heads up.
[15:41] <cjwatson> SpamapS: no problem.  helps that I've mostly done it :)
[15:44] <cjwatson> Keybuk: could you moderate my mail to upstart-devel?  the plymouth guys are being slow about moderation - I probably should've ensured I was subscribed before sending it
[15:48] <pitti> lool: hey! would you mind if I did an nss-mdns NMU to Debian to drop the unnecessary Perl dependency?
[15:49] <SpamapS> cjwatson: cool! I thought for some reason that upstart didn't already publish these things on dbus. Are you saying you added both sides, or just the plymouth bits?
[15:50] <cjwatson> SpamapS: I needed to extend upstart slightly - patches on code.launchpad.net pending review
[15:50] <cjwatson> (not very much though)
[15:51] <cjwatson> SpamapS: http://paste.ubuntu.com/532400/ mbox with plymouth patch, pending mailing list moderation
[15:51] <pitti> lool: (just submitted a bug report with patch to BTS, still waiting for it to land)
[15:52] <cjwatson> the other thing I forgot to mention in that mail is that some job descriptions probably need to be tidied up a bit, particularly tasks (where prefixing with "Starting " didn't seem to produce what I felt were good results, given that they often already started with a verb)
[15:53] <mvo> pitti: still on the campagne to get rid of perl ;) ?
[15:53] <pitti> mvo: some easy parts of it anyway
[15:53] <pitti> mvo: for the more hairy ones I'm currently discussing with the Debian perl team
[15:54] <mvo> :)
[15:55] <cjwatson> grammatically my gut feel is that service descriptions should be the name of the service in lower case, only starting with an initial capital if the service name is always written that way; and task descriptions should be a phrase describing what the task does, normally starting with a progressive verb with an initial capital ("Doing")
[15:56] <cjwatson> we can figure out translatability later, but I don't think this should impede it
[15:56] <cjwatson> (plymouth-upstart-bridge currently prints " * %s" for tasks and either " * Starting %s" or " * Stopping %s" for services)
[16:08] <Keybuk> cjwatson: sure
[16:10] <Keybuk> approved
[16:17] <ari-tczew> cjwatson: did you merge around 30-40 packages today? awesome number!
[16:19] <cjwatson> ari-tczew: sounds about right :) discovered my peak throughput is about 16/hour
[16:19] <cjwatson> has to be fairly easy to manage that though
[16:20] <cjwatson> I mean the merge has to be easy
[16:21] <ari-tczew> congrats anyway
[16:21] <cjwatson> ta
[16:59] <smoser> cjwatson, around ?
[16:59] <cjwatson> hi
[16:59] <smoser> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/671097 . could you review that and possibly sponsor ?
[16:59] <cjwatson> sure.
[17:00] <smoser> i believe the changes were easier than we originally had thought
[17:11] <bdrung> how can i check which uploads rights a person have?
[17:13] <Laney> bdrung: from lp:ubuntu-archive-tools use edit_acl.py -p lpid [-S series] query
[17:14] <bdrung> Laney: i get "Unauthorized: Expired token"
[17:15] <cjwatson> reauthorise then; it shouldn't require any particular privileges
[17:15] <cjwatson> I probably ought to change how that works since for querying the anonymous login should work
[17:16] <bdrung> cjwatson: how do i reauthorise?
[17:16] <cjwatson> I think the credentials live under ~/.launchpadlib/ somewhere
[17:18] <cjwatson> that's odd, if I log in anonymously then I can't see ArchivePermissions, but can see the package list
[17:18] <cjwatson> guess that plan won't work then
[17:19] <cjwatson> geser: I think "PS?" on the ftbfs page would be clearer if it said "Set?"
[17:25] <Keybuk> what I *really* want is some kind of minion who watches me write stuff on the whiteboard, and turns it into C for me
[17:25] <Keybuk> a bit like the DX team do
[17:25] <Keybuk> ;-)
[17:26] <Keybuk> (damnit, njpatel left :p)
[17:30] <apachelogger> Keybuk: you are not alone with that desire... ;)
[17:30] <cjwatson> heh, I find it easier to write code than to describe it sometimes :)
[17:55] <bdmurray> cjwatson: How could I determine the names of packagesets for natty using the Launchpad api?
[17:59] <cjwatson> bdmurray: iterate over launchpad.packagesets
[17:59] <cjwatson> bdmurray: (also see edit_acl.py in lp:ubuntu-archive-tools)
[18:01] <ebroder> Can I talk any core-devs into sponsoring SRUs for bug #601732? It's proving to be a small but persistent thorn in my side
[18:02] <cjwatson> smoser: can you please rebase your branch on lp:~ubuntu-core-dev/ubuntu/lucid/grub2/lucid?  unfortunately the one you used has no common ancestor with the one I'm actually working on
[18:03] <cjwatson> (out for a while)
[18:03] <smoser> cjwatson, ah. sure. i branched from lp:ubuntu/lucid/grub2
[18:03] <smoser> i wish there was a solution for that.
[18:03] <bdmurray> cjwatson: great thanks!
[18:05] <smoser> i find the fact that lp:ubuntu/<dist>/package is the most obvious and easiest thing to branch, but quite likely not the thing that someone wants you to use.
[18:05] <smoser> s/.$/ to be a pain/
[18:06] <cjwatson> I should probably push those branches over the top of the imported ones
[18:09] <smoser> yeah, but that ends up having issues sometimes
[18:09] <smoser> i'm pushing over the top of lp:~smoser/ubuntu/lucid/grub2/lucid-uec-kernel-upgrades/ right now
[18:14] <cjwatson> issues> it's ok as long as you keep copies
[18:16] <smoser> cjwatson, well, the issues i run into were in the branch importer winning as it (being a machine) was in the end more persistant than me. second was that i really dislike storing of .pc/ in a branch.
[18:17] <cjwatson> then you repush :) if you have the latest upload tagged it won't touch it
[18:23] <lool> pitti: nss-mdns > sure; thanks!
[18:23] <lool> pitti: Happy if you NMU it as well
[18:24] <cjwatson> chrisccoulson: are you planning to merge xulrunner-1.9.2 1.9.2.12 into natty?  I noticed it was newer in maverick-updates
[18:25] <cjwatson> chrisccoulson: actually - I see that the version in natty was copied from maverick-security (probably by me), so I'll copy this new version too
[18:25] <cjwatson> so disregard that
[18:26] <chrisccoulson> thanks. yeah, we need to pocket copy them from maverick for now, as it doesn't work with the new toolchain
[18:26] <cjwatson> righto
[18:26] <cjwatson> done
[18:26] <chrisccoulson> thanks
[18:34] <cjwatson> smoser: BTW, I can't upload this until bug 581760 has been verified
[18:35] <cjwatson> I'll see if I can find a machine to do that on tomorrow
[18:35] <smoser> but you're good with the approach ?
[18:35] <cjwatson> yes, I merged it
[18:35] <cjwatson> cyphermox: are you still intending to draft packageselection-n-network-stack?
[18:36] <cyphermox> cjwatson, what do you mean?
[18:37] <cjwatson> cyphermox: it doesn't have a properly-written wiki page based on SpecTemplate
[18:37] <cjwatson> it only has work items
[18:37] <cjwatson> specs are generally expected to be written up in prose as well
[18:38] <cyphermox> cjwatson, I've honestly never used wiki pages for Specs
[18:38] <cjwatson> it's been Ubuntu standard since forever
[18:39] <cjwatson> that's what the drafter slot in the LP blueprint page means - "person who'll write this up"
[18:40] <cyphermox> well sure, let's write it up
[18:41] <cyphermox> looking at the template now
[18:41] <cjwatson> thanks
[18:41] <cjwatson> I'm just going through all the sessions I attended and either writing them up or making sure the designated drafter's going to do it
[18:45] <cyphermox> I won't look at it now, I'm finishing up on something, but will get to it today
[19:48] <charlie-tca> jcastro: verified the fix for bug 627744 in -proposed now gives me the note names
[19:49] <jcastro> charlie-tca: woo hoo
[19:49] <jcastro> kenvandine: ^
[19:53] <smoser> kees, around ?
[19:54] <charlie-tca> jcastro: we will need that fix in Natty too.
[21:38] <G> hallyn: ping still around?
[21:39] <hallyn> G: here
[21:40] <G> hallyn: comment #8 for #589063 still applies
[21:41] <G> hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/589063 btw
[21:42] <hallyn> G: ok, thanks.  so what we would need is either input fromsomeone 'who knows', or lots and lots of testing?
[21:42] <G> hallyn: I kinda gave up on the SRU because I never got any response
[21:43] <hallyn> i'll try to take a closer look at it
[21:43] <G> hallyn: well that was just to cover my backside ;)
[21:43] <G> hallyn: there seem to be a couple of people that are using my PPA package w/o problems
[21:43] <hallyn> G: but, your patch doesn't apply against the original source, so waht is in the ppa?
[21:44] <G> hallyn: and there were very few BIOS changes between whats in Lucid now and whats in Maverick
[21:44] <hallyn> is it a heavily patched qemu, or precisely lucid's qemu + your patch?
[21:44] <G> hallyn: qemu-kvm has nothing to do w/ it
[21:44] <G> hallyn: I marked it as confirmed for the seabios package which is totally seperat
[21:44] <hallyn> oh?  then that woudl be why i was confused :)
[21:45] <hallyn> lol
[21:45] <hallyn> now i see
[21:45] <hallyn> G: if you can get even one of those ppl using your ppa to comment that it fixes it for them, i'll request the sru
[21:45] <G> qemu tarball does include prebuilt seabios, but they are thrown away at compile time
[21:45] <G> hallyn: Troy did
[21:45] <hallyn> right - i was looking at hw/acpi.c in qemu and wondering how ti compared :)
[21:45] <G> hallyn: #9
[21:46] <hallyn> ok, good enough for me.  I'll write up the SRU prose tomorrow.  (or you can if you want)
[21:46] <G> hallyn: I originally just attached the debdiff and forgot to attach the patch on it's own
[21:46] <G> hallyn: you can, as I said I gave up
[21:46] <hallyn> G: and you promise youcan still boot 1 cpu and 8 cpu linux guests with it?
[21:47] <G> hallyn: I seem to be able to boot 1 CPU guests for sure
[21:47] <G> haven't really tried 8 but I'm sure it works
[21:47] <hallyn> I'll inquire in the bug, to make sure
[21:47] <hallyn> G: thanks!
[21:47] <G> hallyn: the other option is to completely backport 0.6.0 or seabios
[21:48] <G> *for
[21:48] <G> which from Maverick we know works
[21:48] <hallyn> G: I'd feel irresponsible doing that
[21:49] <hallyn> Don't get me wrong, i'd *like* to do that for both seabios and gpxe
[21:49] <hallyn> but don't feel i can
[21:49] <G> hallyn: yeah, based on the git history it seems a bit over the top
[21:49] <G> I'd have to double check but it was one of the first changes after what we are using in Lucid now, and there wasn't another bios change for a while
[21:50] <hallyn> hm,
[21:50] <hallyn> zul: around?
[21:52] <hallyn> G: you say it is fixed in maverick right?
[21:52] <G> hallyn: definately
[21:52] <hallyn> (dunno why i'm asking, i know i've done 16 cpus in maverick in win2008...)
[21:52] <hallyn> thanks - then i'm going to mark fix committed,
[21:52] <hallyn> bc otherwise we can't proceed with an sru :)
[21:52] <G> hallyn: I even asked a friend at Red Hat to test it
[21:55] <G> hallyn: fwiw: https://lists.ubuntu.com/archives/ubuntu-server/2010-August/004585.html
[21:59] <hallyn> G: and did it slip through the cracks from there, or wsa it nacked?
[21:59] <G> hallyn: never responded to
[21:59] <G> hallyn: and I've never seen an SRU e-mail since
[22:01] <hallyn> G: yeah, i don't know what happened to the SRU mentions at server meetings.  And sorry that bug shouldnt' have sat so long.