[12:06] <bradb> but kiko doesn't appear to believe me when i say my next landing (unless attach-while-commenting squeaks in before) is going to take a hacksaw to this unfortunate situation
[12:09] <bradb> (I didn't mention that there are also one-radio-button subscribe forms too. :)
[12:35] <kiko> me
[12:35] <kiko> me
[12:35] <kiko> what's me?
[12:37] <bradb> you're a non-believer
[12:38] <bradb> i have another patch in about 1 min. just testing one more path.
[12:38] <bradb> (because afaics, the subscriptions stuff isn't really page tested either. but maybe i'm missing something.)
[12:40] <bradb> kiko: https://chinstrap.ubuntu.com/~dsilvers/paste/file4uu7Y8.html
[12:41] <kiko> +
[12:41] <kiko> +    def _handleUnsubscribeOtherUser(self, user):
[12:41] <kiko> +        # Handle unsubscribing someone other than the current user.
[12:41] <kiko> +        if user == self.user:
[12:41] <kiko> +            return
[12:41] <kiko> this should be an assert
[12:41] <kiko> and never a return
[12:42] <kiko> I don't see a strong case for _isSubscriptionRequest or _handleUnsubscribe (I'd just unroll that if clause into handleSubscriptionRequest) but I can let that go
[12:43] <bradb>         assert user != self.user, (
[12:43] <bradb>             "Expected a user other than the currently logged-in user.")
[12:43] <kiko> the message is optional, but ok
[12:44] <bradb> kiko: The case for _isSR is to make a long if statement easy to read. The case of _handleUnsubscribe is to abstract away the details, and be consistent with _handleSubscribe
[12:44] <kiko> I don't see a big advantage to those, but sure
[12:47] <bradb> asserts without some kind of error message are, btw, mean
[12:48] <bradb> giving somebody at least some kind of description of the unexpected condition is better than giving them no description
[12:50] <kiko> bradb, that assert will never happen
[12:50] <kiko> in particular if the code is well-tested
[12:53] <bradb> kiko: if it *truely* would never happen, then it should be removed. :) but it might happen, somehow, some day.
[12:54] <kiko> truly you mean? :-P
[12:54] <kiko> english-speakers
[12:54] <kiko> r=kiko I guess
[12:54] <bradb> i've hit my hair-splitting quoting for today!
[12:55] <bradb> thanks
[12:55] <bradb> see, i can't even spell quota!
[02:17] <jjesse> don't know if anyone is there that can do this, but i need to edit to the spec for edgy-docs to answer what has been whiteboarded https://launchpad.net/distros/ubuntu/+spec/kubuntu-edgy-docs
[02:22] <Keybuk> jjesse: what's your launchpad id?
[02:22] <jjesse> jjesse
[02:23] <jjesse> matt zimmerman posted stuff on the whiteboard section i would like to ansewr
[02:23] <Keybuk> answer by editing the summary?
[02:23] <Keybuk> you should be able to edit it now
[02:25] <jjesse> Keybuk: will do thanks
[02:26] <jjesse> thanks i am able to edit it
[02:28] <jjesse> is there a time out when you are editing a spec like on the wiki?
[02:28] <jjesse> i'm a little slow on dial up :(
[02:30] <Keybuk> hit preview every 15 mins or so
[02:31] <jjesse> i know on the wiki, just wondering on the launchpad page?
[05:38] <OgMaciel> is there a bug with the code of conduct page by any chance?
[05:41] <OgMaciel> ouch
[05:42] <OgMaciel> 3 crashes in a row
[05:42] <OgMaciel> but at least the new CoC is signed
[05:58] <stub> OgMaciel: If you mean OOPS pages, they are bugs. We get them collated daily and opened as Malone bugs so we will get to them if they are not already being dealt with.
[06:04] <OgMaciel> stub: I meant the code of conduct crashing X
[06:04] <OgMaciel> stub: know anything about it?
[06:05] <stub> When signing it? I don't know anything about that.
[06:06] <OgMaciel> try it
[06:06] <OgMaciel> just clicking on the link on the left hand side crashes X
[06:06] <OgMaciel> and I know of many people who've experienced it
[06:11] <stub> OgMaciel: I just went through the whole procedure with no problems.
[06:12] <OgMaciel> hummmmmm
[06:12] <OgMaciel> I click on it and it crashes
[06:12] <OgMaciel> X that is
[06:12] <OgMaciel> am using epiphany
[06:12] <stub> The download link? Or the sign it link?
[06:12] <OgMaciel> the link right on your personal LP page
[06:13] <OgMaciel> I can't rover it b/c it will crash X
[06:13] <stub> The rollover crashes X?
[06:13] <stub> Sounds like you need to report a bug in Ubuntu's epiphany
[06:13] <OgMaciel> lemme check if there's something there
[06:14] <stub> And probably X too, since an application shouldn't be able to crash X
[06:14] <OgMaciel> not rovering
[06:14] <OgMaciel> clicking on it
[06:14] <OgMaciel> here I go
[06:19] <OgMaciel> stub: ouch
[06:20] <OgMaciel> stub: firefox completely hangs the system
[06:21] <stub> The page I think you are loading has a bug in that it is very, very wide if you have signed codes of conduct. That might be causing the crash.
[06:22] <stub> Triggering the X and/or Epiphany bug
[06:22] <OgMaciel> hummm
[06:22] <OgMaciel> I do have signed CoC
[06:22] <stub> The page I'm thinking of is https://launchpad.net/people/stub/+codesofconduct (but you probably don't want to click that ;) )
[06:23] <OgMaciel> hehehe
[06:23] <OgMaciel> yup
[06:23] <OgMaciel> and epiphany will prompt you if you want to recover the pages you were looking at, which will cause you to crash again
[07:35] <stub> 12:23:19~/src/pytz $ bzr push --remember sftp://bazaar.launchpad.net/~stub/pytz/devel
[07:35] <stub> bzr: ERROR: Parent directory of sftp://bazaar.launchpad.net/~stub/pytz/devel does not exist.
[07:35] <stub> spiv: Known issue? I was just testing ddaa's instructions
[07:49] <ajmitch> stub: no --create-prefix?
[07:50] <SteveA> morning
[07:50] <stub> Not in the draft doc, no. I'll tell ddaa
[07:50] <SteveA> jamesh: ping
[07:51] <spiv> stub: yeah, what ajmitch said.
[07:51] <spiv> stub: It's like any other SFTP server; if the parent directory isn't there, bzr isn't going to create it for you.
[07:52] <spiv> stub (unless you use --create-prefix)
[07:53] <spiv> stub: Although bug #36889 is about maybe changing that behaviour.
[07:53] <Ubugtu> Malone bug 36889 in launchpad-bazaar "sftp server does not allow pushing to new product" [Medium,Confirmed]  http://launchpad.net/bugs/36889
[07:54] <stub> spiv: Perhaps it should. Requiring an option is only really required when you are pushing to a filesystem with a flexible namespace and you don't want to accidentally create directories in the wrong spot. The supermirror has an inflexible directory structure.
[07:54] <stub> Maybe ;)
[07:54] <spiv> stub: Yeah.  I can see the argument, but I'm not totally convinced.
[07:55] <spiv> Not least because it makes more work for me ;)
[08:10] <SteveA> why doesn't bzr do --create-prefix by default ?
[08:11] <SteveA> it is harmless if you add it by mistake, and causes errors or causes you to have to know about it if you omit it when you need it.
[08:11] <spiv> If the parent directory doesn't exist, it's moderately likely you typoed the URL.
[08:12] <spiv> (although not so much in the supermirror case, I guess...)
[08:12] <SteveA> it's equally likely you typoed the URL in other circumstances not caught by this
[08:12] <SteveA> i don't see why this case should be singled out
[08:12] <spiv> Probably worth asking on #bzr
[08:18] <stub> Pushing bzr at this point might be a mistake - until the smart server exists, people are going to give up waiting for sftp pushes to complete creating bad first impressions and a 'bzr sucks' meme.
[08:19] <SteveA> jamesh: ping
[08:23] <spiv> stub: knit format?  That sounds even slower than is normal.
[08:27] <stub> Yup. Knit.
[08:27] <stub> 116 revisions
[08:29] <spiv> Weird.  I guess I just don't have a good feel for normal times for anything that's not in rocketfuel.
[08:35] <stub> There are about 16 files under revision control and about 1400 files in .bzr. This was a branch that was imported from sourceforge cvs to baz, then converted from baz to bzr weave, then converted from bzr weave to knits.
[08:45] <jamesh> SteveA: pong
[08:46] <SteveA> hi james
[08:46] <SteveA> did you talk with matt about the meeting scheduler?
[08:48] <jamesh> no I haven't.  I'll do so now
[08:48] <SteveA> i shall be surprised in matt is still around
[08:49] <jamesh> I'll stick around tonight then and catch him when he wakes up
[08:49] <jamesh> and email some of the details
[08:49] <SteveA> that will be at about 4am or later
[08:49] <SteveA> i have a suggestion
[08:50] <SteveA> ah, matt is around after all
[08:50] <jamesh> yeah, I messaged him
[08:53] <SteveA> jamesh: okay.  we should go throught the system.
[08:54] <SteveA> jamesh: let's do a skype call
[08:54] <jamesh> okay
[09:13] <sivang> morning folks
[09:14] <carlos> morning
[09:15] <sivang> hey carlos , 'sup?
[09:16] <carlos> sivang: hi ;-)
[10:46] <ddaa> spiv: ping
[10:53] <malcc> Is it the individual developer's job to check when deployments happen and move bugs from Fix Committed to Fix Released, or is it part of the release process?
[10:53] <ddaa> yes
[10:55] <malcc> ddaa: Well I'm glad the answer isn't "No the magic pixies do it" but I was kinda hoping someone would tell me which of those two options it is :)
[10:56] <ddaa> as I understand it, it is the individual developer's job to move bugs to Fix Released as part of the release process :)
[10:56] <malcc> ddaa: Thanks.
[10:56] <ddaa> it is my opinion that either my understanding or the process is broken
[10:56] <malcc> ddaa: By "part of the process" I meant the release muggins had to do it, which is why I saw them as distinct options
[10:57] <ddaa> I'd be interested on a second opinion on whichever is the most broken
[10:57] <malcc> ddaa: Yes, having been super-careful to include exactly which bugs my merges fixed, I expected whoever decided to deploy that revision to update the bugs
[10:58] <ddaa> "the release muggins" == stub, or did I miss something?
[11:00] <malcc> ddaa: Yes, I just meant whomever is landed with doing the releases, I wasn't sure this was always just the one person
[11:02] <ddaa> it's usually stub, except on the april 1st when we ask seb128 to rollout launchpad and stub to package gnome.
[11:04] <sivang> ddaa: I don't think that could happen even onf april 1st ;-)
[11:04] <ddaa> might be fun to watch nonetheless
[11:06] <lifeless_> Kinnison: whats up ?
[11:07] <lifeless_> meh
[11:07] <Kinnison> lifeless: Hmm?
[11:07] <lifeless> kiko-zzz: whats up ?
[11:07] <lifeless> Kinnison: kiko pung moi
[11:07] <lifeless> and my tab completion works too enthusiastically
[11:08] <Kinnison> But I doubt that's why kiko pung you
[11:08] <malcc> I suspect this was yesterday's need for a delete from the production db?
[11:11] <SteveA> lifeless: https://launchpad.canonical.com/PQMCommitMessages
[11:11] <SteveA> what product should I register that spec against?
[11:14] <lifeless> pqm
[11:14] <lifeless> (the ui changes you want require changes in pqm no matter hwat)
[11:15] <lifeless> its probable that some of what you want will need to be implemented in the post commit plugin hook, but more likely that that hook will be utterly useless for what you want and we'll need to do it all in pqm.
[11:17] <SteveA> ok.  in that case, i should move the spec onto some bzr-related wiki
[11:17] <SteveA> as it is not public where it is now
[11:17] <SteveA> can you suggest a good home for it?
[11:17] <lifeless> well
[11:18] <SteveA> actually... i'm inclined to register it as a launchpad spec
[11:18] <lifeless> pqm is developed in house and then pushed - I still go to mark for ok on things that were not written by community members
[11:18] <SteveA> so that it can be prioritized along with other launchpad work
[11:18] <lifeless> (if its written by someone in the community it is clearly immediately public)
[11:18] <SteveA> as we want it to improve the launchpad processes
[11:18] <lifeless> so this spec can live whereever its most likely to trigger the work being done
[11:18] <SteveA> ok
[11:36] <lifeless> ddaa: your branch has conflicts (arch_scm)
[11:36] <lifeless> ddaa: I will et a reviewer onto it soon, but you need to fix those asap
[11:38] <SteveA> jamesh: did the merge of your scheduler views get rejected by pqm?
[11:53] <jamesh> SteveA: looks like it merged successfully as rev 3684
[11:53] <SteveA> strange, i don't seem to have a message from pqm about it
[11:54] <jamesh> I just pulled rocketfuel-built and did a "bzr log"
[11:56] <lifeless> kiko mailed the lp list about fuckage in the commits list
[11:56] <lifeless> which karl is looking into
[11:56] <lifeless> except its a pqm config issue, fixing.
[11:57] <lifeless> fixed
[12:03] <Znarl> lifeless : It's not a problem with lists?
[12:03] <ddaa> lifeless: all spurious conflicts
[12:03] <ddaa> fixed
[12:04] <ddaa> mesh merging does not quite cut the mustard yet, I'm afraid :(
[12:04] <lifeless> Znarl: I have no reason to believe it is a problem with the lists
[12:04] <lifeless> Znarl: and reason to believe it was a config issue with pqm
[12:07] <Znarl> lifeless : ok, thank you for letting me know.
[12:10] <lifeless> Znarl: heh, sorry I should have done so.
[12:10] <lifeless> Znarl: I did mail the lp list ;)
[12:35] <ddaa> duh?
[12:36] <ddaa> looks like pqm is seriously intoxicated
[12:36] <ddaa> lifeless: https://pqm.canonical.com/
[12:37] <ddaa> is it my branch with a newline in the pqm message?
[12:41] <ddaa> lifeless: what do you say need to be done to publish new importd branches as knit? Just rollout the new sourcecode/bzr from rocketfuel?
[12:43] <doko> jamesh: ping
[12:43] <jamesh> doko: pong
[12:43] <lifeless> it should be that simple
[12:45] <lifeless> probably
[12:46] <lifeless> ddaa: nuked it
[12:46] <ddaa> meh!
[12:51] <ddaa> lifeless: I'm going to tell everybody there's an easter egg in pqm, when using a commit message with a newline, until that's fixed :->
[12:53] <looksaus> ddaa, ?
[12:54] <lifeless> ddaa: be my guest. I can add an easter egg fo ryou. Shall we say 'ddaas jobs run after *everyone elses* no matter the submit order?'
[12:54] <ddaa> power abuse!
[12:56] <ddaa> looksaus: ?
[12:57] <looksaus> ddaa, just wondering if you were out here, sorry
[12:58] <looksaus> I'm setting up this repo based on your hints from yesterday
[01:09] <Znarl> SteveA : Ping?
[01:11] <Znarl> I need an account disabled on Launchpad urgently.  Can someone help?
[01:12] <Keybuk> zope.security.interfaces.ForbiddenAttribute: ('getAllSourceReleasesByStatus', <DistroRelease at 0x2aaab14deb90>)
[01:19] <matsubara> good morning!
[01:20] <looksaus> ddaa, sorry for bothering you, but...
[01:21] <looksaus> I am the registrant behind https://launchpad.net/products/support.points.map
[01:22] <looksaus> is there a way to change the registrant of this project to https://launchpad.net/people/mapdevs
[01:22] <ddaa> "Change Maintainer"
[01:22] <looksaus> I'm asking _stupid_ questions here
[01:23] <ddaa> looksaus: but feel free to ask other people, I'm not the source of all answers here
[01:23] <fabbione> kiko-zzz, SteveA: ping?
[01:23] <looksaus> https://launchpad.net/products/support.points.map/+reassign
[01:24] <looksaus> gets me a "Sorry, you don't have permission to access this page."
[01:24] <looksaus> even if I'm logged in as the registrant
[01:24] <lifeless> Znarl: I can
[01:24] <ddaa> looksaus: indeed
[01:24] <lifeless> Znarl: whowhatwherewhen
[01:25] <ddaa> looksaus: can you file a bug, please?
[01:25] <looksaus> ok
[01:25] <ddaa> the other option is "ask a launchpad admin to do it"
[01:25] <ddaa> but I do not have launchpad admin privs
[01:25] <looksaus> anyone in this channel who has?
[01:25] <lifeless> what do you need done?
[01:26] <looksaus> reassign https://launchpad.net/products/support.points.map maintainership to
[01:26] <looksaus> https://launchpad.net/people/mapdevs
[01:27] <looksaus> lifeless, you have admin access?
[01:28] <lifeless> Znarl: I've reset the vandals password, but I recall some issues here
[01:28] <lifeless> spiv: ping
[01:28] <lifeless> spiv did the moin integration, maybe he remembers better than I do
[01:29] <Znarl> lifeless : heno has disabled his user account in wikiconfig too.
[01:29] <matsubara> looksaus: send a gpg signed email to matsubara@async.com.br (signed with the gpg key you have on LP), clearly requesting that and I'll make sure some admin will transfer it.
[01:29] <lifeless> Znarl: he can go through password reset
[01:29] <lifeless> so this is temporary only
[01:29] <looksaus> matsubara, thank you!
[01:29] <lifeless> is someone in contact with the fool ?
[01:30] <Znarl> lifeless : We can't disable his account?
[01:30] <lifeless> we have no 'force off and keep it off' button at the moment
[01:31] <lifeless> even if we did, he could always sign up again
[01:31] <matsubara> looksaus: it's already done. no need to bother with the gpg email.
[01:31] <looksaus> matsubara, thx!!
[01:32] <looksaus> would you still like me to file the bug?
[01:32] <Znarl> lifeless : I see, this is a problem.  
[01:32] <matsubara> there's a bug already. bug 41639
[01:32] <Ubugtu> Malone bug 41639 in launchpad "Product owner should be able to reassign ownership to another user." [Medium,Confirmed]  http://launchpad.net/bugs/41639
[01:32] <spiv> ddaa: pong
[01:32] <looksaus> ok, thx
[01:32] <spiv> lifeless: pong
[01:33] <SteveA> Znarl: pong
[01:33] <lifeless> spiv: knocking vandals off the wikis
[01:33] <spiv> Znarl: talk to stub, there's a bug about account deactivation.
[01:33] <spiv> s/a bug/a bug open/
[01:33] <lifeless> yeah, but no flag yet :
[01:33] <Znarl> SteveA : We've had a user deface wiki.ubuntu.com, but it seems we can't disable his account?  Only reset his password?
[01:33] <SteveA> fabbione: pong
[01:34] <fabbione> SteveA: phone call?
[01:34] <fabbione> (it's urgent)
[01:35] <SteveA> spiv: quick hack -- have a ban list for the authserver
[01:35] <lifeless> I think we need something in place, so that stub and I dont need to poke at the db every 15 minutes until he gives up
[01:36] <Znarl> lifeless : I've firewalled his IP too, so that should slow him down.
[01:36] <lifeless> https://launchpad.net/people/eraslan1986 is the person in the gui
[01:36] <spiv> SteveA: Looks like firewalling the IP is a quicker hack ;)
[01:37] <lifeless> one hotmail address
[01:38] <lifeless> no hits in google for it.
[01:38] <lifeless> Znarl: if you want to prevent him changing is password, block outbound emails to it
[01:39] <Znarl> lifeless : I'll email his ISP and hope they respond.  I think thats the best way to handle it long term.
[01:39] <lifeless> perhaps we should stup up moin-in-bzr
[01:39] <lifeless> so that vandalism is dealth with by 'uncommit'
[01:40] <ddaa> hasn't this idea been in the air for, like, three years?
[01:42] <SteveA> Kinnison: i just had a call with fabio
[01:42] <Kinnison> SteveA: aye?
[01:43] <SteveA> Kinnison: i want to review the diff.  i'm going to produce a diff on chinstrap.
[01:43] <SteveA> however, i want to point out that the launchpad-repo thing combined with the current pending-reviews system is a problem
[01:43] <Kinnison> SteveA: *nod*
[01:43] <SteveA> can you resolve that by renaming launchapd-repo to be launchpad ?
[01:43] <Kinnison> SteveA: I know, jamesh and I worked out how to solve it
[01:43] <SteveA> what is the resolution, and when will it happen?
[01:43] <Kinnison> I have a symlink so my branches are launchpad-repo/launchpad/thing
[01:44] <Kinnison> and the script will pick up the fix on the next cycle in 15 minutes
[01:44] <lifeless> why not just rename launchpad-repo to launchpad ?
[01:44] <Kinnison> because launchpad/ is all my non-repod branches
[01:44] <Kinnison> I'll clean it up in time
[01:44] <Kinnison> but we have a functional workaround
[01:44] <Kinnison> I just forgot to change the url on the page before now
[01:44] <Kinnison> lifeless: I didn't know that
[01:45] <SteveA> i'm branching from you right now
[01:45] <SteveA> so please don't rename just this second
[01:45] <Kinnison> SteveA: I won't
[01:45] <spiv> Yeah, I have a "launchpad" directory with a repo locally that contains old standalone branches mixed with ones that share the repo, and it works fine.
[01:46] <Kinnison> noted
[01:55] <SteveA> meeting in 5 mins
[01:56] <SteveA> lifeless: i want bzr to be able to do a diff from a branch that has no working tree
[02:00] <SteveA> lifeless: stevea@chinstrap:~/temptree/47770$ bzr diff -r/home/warthogs/archives/rocketfuel-built/launchpad  > diff.txt
[02:00] <SteveA> bzr: ERROR: No namespace registered for string: '/home/warthogs/archives/rocketfuel-built/launchpad'
[02:00] <SteveA> cryptic error
[02:00] <kiko-zzz> morning
[02:00] <SteveA> i just want to get a diff
[02:00] <kiko> it's that time of the year
[02:00] <SteveA> LAUNCHPAD DEVELOPMENT MEETING
[02:01] <Kinnison> I am here!
[02:01] <SteveA> good $local-time-description and welcome to today's launchpad development meeting
[02:01] <stub> yer
[02:01] <SteveA> who is here?
[02:01] <bradb> me
[02:01] <BjornT> me
[02:01] <lifeless> SteveA: -r branch:/...
[02:01] <malcc> me
[02:01] <lifeless> lalala
[02:01] <jamesh> me
[02:01] <spiv> me
[02:01] <salgado> here
[02:02] <Kinnison> My cat is absent
[02:02] <kiko> me
[02:02] <SteveA> lifeless: the bzr help diff docs don't say that, and the error is cryptic.
[02:02] <matsubara> me
[02:02] <ddaa> me
[02:02] <SteveA> lifeless: but thanks for the info
[02:02] <carlos> me
[02:02] <lifeless> SteveA: its the same info I gave you tuesday ;)
[02:03] <SteveA> lifeless: which i forgot the details of, so looked in  bzr help diff
[02:03] <cprov> me
[02:03] <lifeless> SteveA: baz had the usage pattern you are trying to use, bzr does not currently.
[02:03] <SteveA> i recall you said use bzr -r
[02:03] <SteveA> which i tried this time
[02:03] <SteveA> you didn't tell me to use branch: last time
[02:03] <SteveA> which was the missing part this time
[02:03] <lifeless> yup, I told you ancestor:
[02:03] <lifeless> which was what you wanted that time AFAICT
[02:03] <kiko> what does this have to do with the meeting!
[02:03] <lifeless> anyhow, meeting time
[02:03] <SteveA> == Agenda ==
[02:03] <SteveA>  * Roll call
[02:03] <SteveA>  * Agenda
[02:03] <SteveA>  * Next meeting
[02:03] <SteveA>  * Activity reports
[02:03] <SteveA>  * Actions from last meeting
[02:03] <SteveA>  * Launchpad oops milestone report
[02:03] <SteveA>  * Outstanding sysadmin requests
[02:04] <SteveA>  * Production and staging (stub)
[02:04] <SteveA> ----
[02:04] <SteveA>  * Reviewer voip calls (steve)
[02:04] <SteveA>  * Soyuz status (soyuz team)
[02:04] <SteveA>  * Sprint schedule, book tickets (steve, kiko)
[02:04] <SteveA>  * (other items)
[02:04] <SteveA> ----
[02:04] <SteveA>  * Keep, Bag, Change
[02:04] <SteveA>  * Three sentences
[02:04] <SteveA> kiko: EVERYTHING!
[02:04] <SteveA> 
[02:04] <SteveA>  * Next meeting
[02:04] <SteveA> various people will be in paris
[02:04] <SteveA> but let's have a meeting anyway
[02:04] <SteveA> thursday 22 june
[02:04] <SteveA> any comments?
[02:04] <SteveA> ok, thanks.
[02:04] <SteveA> (mpt is at meetings in montreal)
[02:05] <SteveA>  * Activity reports
[02:05] <kiko> me
[02:05] <SteveA> who's up to date, and who isn't
[02:05] <lifeless> godlike
[02:05] <SteveA> not up to date
[02:05] <BjornT> i'm up to date
[02:05] <matsubara> up to date
[02:05] <salgado> up to date
[02:05] <Kinnison> I am up to date, having had a small gap last week.
[02:05] <carlos> not up to date
[02:05] <jamesh> not up to date
[02:05] <ddaa> up to date
[02:05] <malcc> I'm up to date following a lame summary
[02:05] <flacoste> up to date
[02:05] <bradb> print canned_response['activity_reports'] 
[02:05] <bradb> up to date
[02:05] <spiv> I'm up to date
[02:05] <cprov> up to date (sending yesterdays)
[02:06] <stub> Up to date
[02:06] <SteveA>  * Actions from last meeting
[02:06] <SteveA>  * Kinnison to send out activity report info that he has recorded but not sent.
[02:06] <SteveA>  * SteveA to write up braindump spec of how we want pqm to output stuff
[02:06] <SteveA> https://launchpad.net/products/launchpad/+spec/pqm-commit-messages
[02:06] <SteveA> done
[02:06] <SteveA>  * BjornT to get bug filed in zope collector about __unicode__ of request
[02:06] <BjornT> done
[02:06] <SteveA>  * Matsubara and Stuart to talk on skype about QA and production.
[02:06] <matsubara> not done
[02:07] <Kinnison> hence I said "with small gap" above
[02:07] <SteveA>  * Malcolm, Celso and Daniel to have a soyuz conf call.
[02:07] <Kinnison> Not done
[02:07] <SteveA>  * Carlos to file a bug or mail the list about canonical.supermirrorsftp.tests. creation on test runs.
[02:07] <carlos> done
[02:07] <SteveA> so, MeetingActions:
[02:07] <carlos> and spiv fixed it already
[02:07] <kiko> SteveA, carlos: and fixed by spiv yesterday
[02:07] <carlos> kiko: ;-)
[02:07] <SteveA> MeetingAction:   * Matsubara and Stuart to talk on skype about QA and production.
[02:07] <SteveA> MeetingAction:  Malcolm, Celso and Daniel to have a soyuz conf call.  (after paris probably)
[02:08] <Kinnison> Seems odd to have a confcall after we've spent a week face2face
[02:08] <SteveA>  * Launchpad oops milestone report
[02:08] <SteveA> with a meeting action:
[02:08] <SteveA>  * Do we have any OOPS reports without python source lines in them?  If not, then the issue was probably .pyc files as James proposed.
[02:08] <matsubara> SteveA: nope.
[02:08] <SteveA> Kinnison: i want to get people into the habit of having conf calls
[02:08] <Kinnison> SteveA: I see, okay
[02:09] <SteveA> and, there will undoubtedly be issues left over
[02:09] <SteveA> matsubara: please go ahead with your report
[02:09] <matsubara> SteveA: it seems to be solved already. If it appears again I'll shout. :)
[02:09] <matsubara> We're seeing lots of KeyErrors on the +mirror/$mirror page. According to salgado that was caused by a removal of a dbschema item. That's bug 49159, how's going?
[02:09] <Ubugtu> Malone bug 49159 in launchpad "Removal o dbschema item causing a OOPS at +mirror" [High,Confirmed]  http://launchpad.net/bugs/49159
[02:09] <kiko> Kinnison, au contraire I think you guys have a lot to talk about (and coordinate)
[02:09] <salgado> matsubara, one of them is fixed already. we need to check if there's any remaining ones on other distros
[02:10] <salgado> and fix them. I'll talk with stub about that after the meeting
[02:10] <matsubara> salgado: ok, thanks, could you update the bug with after that?
[02:11] <matsubara> There's a IndexError on a calendar page. I was unable to reproduce, but there's a bug reported to it bug 30316, assigned to jamesh. How's it going? Do you want me to take over on that?
[02:11] <Ubugtu> Malone bug 30316 in launchpad-cal "Calendar event triggering IndexError." [Medium,Confirmed]  http://launchpad.net/bugs/30316
[02:12] <jamesh> I haven't looked into it
[02:12] <SteveA> matsubara: please take over on that
[02:12] <matsubara> SteveA: ok.
[02:12] <matsubara> btw, jamesh what about landing steve's patch to tickcount?
[02:13] <jamesh> matsubara: I've got a branch set up with a makefile and some simple tests (at jamesh/tickcount/devel).  I'll talk with lifeless about getting it into rocketfuel
[02:14] <SteveA> we don't want it in rocketfuel
[02:14] <SteveA> it should be put into a public branch, licenced under the python licence, copyright canonical 2006
[02:14] <SteveA> and then packaged by lifeless
[02:14] <lifeless> packaged as a deb
[02:14] <lifeless> I'll do that
[02:15] <jamesh> Okay.  I'll add copyright headers to the files then.
[02:15] <jamesh> I suppose we can host the branch on bazaar.launchpad.net now
[02:15] <jamesh> (as a public location)
[02:16] <spiv> That's a very good spot for it.
[02:16] <spiv> The more we dogfood that the better :)
[02:16] <matsubara> sounds like a good plan.
[02:17] <matsubara> The +builds page times out occasionally. I re-opened bug https://launchpad.net/products/launchpad/+bug/43802. Sometimes this page times out because of repetitive queries (OOPS-162A728) and sometimes seems to be a table lock (https://lists.ubuntu.com/mailman/private/launchpad/2006-June/009661.html). cprov, kiko can you take care of that?
[02:17] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/162A728
[02:17] <jamesh> for branches like this, would it make sense to make them owned by the launchpad team?
[02:17] <kiko> matsubara, I looked at it yesterday. I really am confused by that one -- the queries run fast when done on the database at a random time
[02:17] <kiko> matsubara, it seems to be table contention caused by the build scanner running perhaps?
[02:17] <kiko> matsubara, I don't know how to avoid that. lower transaction isolation?
[02:18] <kiko> stub, those timeouts seem to occur because of concurrency with scripts that process builds. any hints?
[02:19] <stub> If the scripts are locking up resources, the only thing we can do is optimize the scripts.
[02:19] <matsubara> kiko: and what about the repetitive queries?
[02:19] <stub> (if they are locking stuff, it indicates updates being made so we can't even offload them to a replica database)
[02:19] <cprov> kiko: it's indeed very weird, we can check it again 
[02:20] <kiko> matsubara, hmmm, the count() queries you mean?
[02:20] <cprov> kiko: the IN() hack seem to not work for some attributes
[02:20] <matsubara> kiko: no, the same queries on bug 43802
[02:20] <kiko> cprov, odd.
[02:20] <stub> And if we can't fix the scripts, the Launchpad reports could be made from a readonly copy of the data (best done automatically for all GET requests using a replica database. But that is longer term)
[02:21] <kiko> stub, hmmm. 
[02:22] <cprov> kiko: the query 345 should be fetching everithing needed from BQ, don't know why the repeated queries were issues 
[02:22] <kiko> I'll look into it cprov 
[02:23] <kiko> just remind me of it
[02:23] <matsubara> kiko: I'll. :)
[02:23] <kiko> thanks
[02:23] <matsubara> And finally, a note to everyone, I created the launchpad-support-tracker product. If you find any bugs related to the support tracker, please assign/report against that product. I've been moving the bugs I could find to it. I'm done here. Thanks everyone
[02:24] <SteveA> what do you think about calling the launchpad support tool "wonderbar"
[02:24] <SteveA> ?
[02:24] <SteveA> i'd go for wonderbra, but that's already trademarked
[02:24] <stub> Sounds like a dildo
[02:25] <kiko> wth is wonderbar?
[02:25] <bradb> heh
[02:25] <jamesh> kiko: something that provides support
[02:25] <kiko> you guys are nuts
[02:25] <flacoste> do you want to imply the support area is like a bar?
[02:26] <malcc> Bot malcc raised ExcessivelyPoorPun exception at line 1222 in malcc.launchpadmeeting.py
[02:26] <lifeless> clearly launchbra is the thing to go for
[02:26] <matsubara> I'd rather call it something like sos, as someone else suggested on launchpad-users
[02:26] <SteveA> stub: i think your stock response to any suggestion is "it sounds like a dildo"
[02:26] <carlos> :-P
[02:26] <stub> SteveA: No, normally it is *you* sound like a dildo
[02:26] <SteveA> stub: kind of.  i'm battery powered
[02:27] <SteveA> matsubara: anything else for the oops report?
[02:27] <ddaa> BTW, any suggestion to change the name of The Bazaar?
[02:27] <matsubara> nope, I'm done, thanks
[02:27] <SteveA> cool
[02:27] <SteveA> thanks matsubara 
[02:27] <SteveA>  * Outstanding sysadmin requests
[02:27] <SteveA> 6
[02:27] <SteveA> 5
[02:27] <SteveA> 4
[02:27] <SteveA> 3
[02:27] <SteveA> 2
[02:27] <SteveA> 1
[02:27] <SteveA> cool
[02:27] <ddaa> ho
[02:27] <SteveA>  * Production and staging (stub)
[02:27] <ddaa> remembered one
[02:27] <stub> Nothing interesting happening with staging except that David is soliciting feedback from one of his new pages.
[02:27] <stub> We are now back to four app servers as I believe the bug chewing up all the resources on Gandwana has now been fixed and that fix landed.
[02:27] <stub> There will be a minor production update tonight, cherry picking some of James' work if I can work out the relevant revision number.
[02:28] <ddaa> rt 11412
[02:28] <jdub> hey dudes
[02:28] <jdub> attempting to sign up for summit
[02:28] <jdub> OOPS-166B378
[02:28] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/166B378
[02:28] <ddaa> stub: yeah, branch-scanner is back in line
[02:29] <cprov> stub: did you do the build deletion we requested yesterday ? if not see priv 
[02:29] <SteveA> jamesh: what is the revision number for stub?
[02:29] <ddaa> back to its old wasteful self, instead of the new preposterously underperforming self
[02:29] <stub> cprov: You requested a build deletion?
[02:29] <jamesh> stub: rev 3684 contains the changes in question
[02:29] <SteveA> jdub: it will be 10 mins before we can see the oops here
[02:29] <stub> jamesh: Ta
[02:30] <SteveA> ddaa: what is rt 11412 about?
[02:30] <SteveA>  * Reviewer voip calls (steve)
[02:30] <cprov> stub: yes, to lifeless or someone else with postgres in prod (informal IRC request, though)
[02:30] <ddaa> clean-up in import ssh key usage
[02:30] <carlos> SteveA: sorry, I missed the pending admin requests... #10992 is still pending and would be helpful to debug OO.org language packs
[02:30] <ddaa> * importd ssh key
[02:31] <kiko> I've had a few at least
[02:31] <ddaa> about galapagos and neumayer not being supposed to use the same private key to connect to escudero
[02:31] <SteveA> quick poll: who has had a call with a reviewer or a reviewee.  write "had call" or "not had call"
[02:31] <carlos> SteveA: it's to give me access to drescher
[02:31] <SteveA> had call
[02:31] <bradb> had call
[02:31] <BjornT> had call
[02:31] <carlos> had call
[02:31] <kiko> had call
[02:31] <spiv> SteveA: since last meeting?
[02:31] <stub> not had call
[02:31] <SteveA> spiv: at all
[02:31] <bradb> (and a couple questions about calls)
[02:31] <matsubara> not had call
[02:31] <salgado> had call
[02:31] <spiv> had call
[02:31] <malcc> not had call
[02:31] <jamesh> not had call
[02:31] <flacoste> not had call
[02:31] <lifeless> not had call
[02:31] <ddaa> call?
[02:32] <Kinnison> not had call
[02:32] <kiko> cprov and I have had various meetings though
[02:32] <SteveA> malcc, Kinnison: you guys should have regular voip or phone calls
[02:33] <bradb> skype isn't supported on ppc, AFAIK. how can us lowly ppc users get the most from conf calling without a voip client? any other voip solutions that people know about on ppc that can work?
[02:33] <cprov> not had call (a proper one)
[02:33] <matsubara> hmm if that counts, I'm always asking salgado for design tips
[02:33] <Kinnison> bradb: ekiga
[02:33] <stub> I will have a call with someone re: test runner updates to optimize Librarian startup/shutdown. SteveA or lifeless probably.
[02:33] <spiv> jamesh: you've had calls
[02:33] <SteveA> bradb: i've used skype with you before
[02:33] <bradb> SteveA: yeah, on mac :)
[02:33] <SteveA>  * Sprint schedule, book tickets (steve, kiko)
[02:33] <bradb> at the office, i have only ppc linux
[02:33] <kiko> book tickes!
[02:33] <jamesh> spiv: ah.  I have had calls but not since last meeting
[02:33] <Kinnison> bradb: mol?
[02:33] <SteveA> https://chinstrap.warthogs.hbd.com/~dsilvers/paste/file2FAwdY.html
[02:34] <carlos> bradb: gizmoproject or wengo would work, both use SIP protocol
[02:34] <Kinnison> sprint schedule?
[02:34] <Kinnison> there's more after paris?
[02:34] <SteveA> Kinnison: see what i just pasted
[02:34] <kiko> Kinnison, what planet have you been on?
[02:34] <kiko> read your mailing list or be surprised
[02:34] <SteveA> everyone, read https://chinstrap.warthogs.hbd.com/~dsilvers/paste/file2FAwdY.html  now
[02:34] <ddaa> Who's Danilo?
[02:35] <SteveA> and take note of where you need to be when
[02:35] <SteveA> ddaa: someone we're talking to about working with carlos
[02:35] <Kinnison> kiko: I didn't scroll far enough down that mail, I see now
[02:35] <jamesh> jdub: you said you were leaving the sprint on 2005-06-24, which is before 2006-06-19 (it is a bug that you got an oops though)
[02:35] <SteveA>  * Keep, Bag, Change
[02:36] <SteveA> 10
[02:36] <SteveA> 9
[02:36] <SteveA> 8
[02:36] <SteveA> 7
[02:36] <SteveA> 6
[02:36] <SteveA> 5
[02:36] <SteveA> 4
[02:36] <SteveA> 3
[02:36] <kiko> keep: emails to mailing lists -- losing them is distressing!
[02:36] <SteveA> 2
[02:36] <SteveA> 1
[02:36] <SteveA> 0
[02:36] <SteveA> thank you
[02:36] <ddaa> KEEP: the good feedback on the launchpad blog draft, thank you all
[02:36] <ddaa> BAG: permission-related bugs (e.g. has to be admin to change product maintainer)
[02:36] <SteveA> the agenda is basically the same each week
[02:36] <bradb> change: the policy on pre-imp voice calls to "make a point to make a few calls a week"
[02:36] <kiko> ddaa, I thought that bug was because something on the bzr side of things doesn't like this sort of change?
[02:36] <SteveA> so you can prepare things like keep bag change and three sentences in advance
[02:37] <SteveA> and paste them into the channel when the topic is announced
[02:37] <jdub> jamesh: ...? starting at: 2005-06-18 05:05, finishing at: 2005-06-24 12:20
[02:37] <SteveA> this keeps us moving along
[02:37] <ddaa> kiko: not changing maintainer
[02:37] <jamesh> jdub: look at the years
[02:37] <kiko> ddaa, what I just said?
[02:37] <jdub> oh
[02:37] <jdub> jamesh: thanks :)
[02:37] <ddaa> kiko: name changes break it
[02:37] <SteveA> the channel is about the get very noisy
[02:37] <kiko> ddaa, only?
[02:37] <SteveA>  * Three sentences
[02:38] <ddaa> and project-product-series associations
[02:38] <kiko> matsubara, did you know this?
[02:38] <SteveA> Khaaaaaaaan!
[02:38] <stub> DONE: Shipit constraints
[02:38] <stub> TODO: Shipi constraints, test runner speed improvements (librarian)
[02:38] <stub> BLOCKED: No
[02:38] <malcc> DONE: More process-upload tidying work
[02:38] <malcc> TODO: Landing that, and starting to tidy nascentupload
[02:38] <malcc> BLOCKED: No
[02:38] <carlos> DONE: bug #35631 migration script and reviewer answer handling, PoMsgSetPage final review and merge, bug #40550, bug #49599 debug, preimplementation call with Steve about bug #40550
[02:38] <carlos> TODO: Finish #35631 migration data fix, #40550 and Ubuntu Conference
[02:38] <carlos> BLOCKED: No
[02:38] <Ubugtu> Malone bug 35631 in rosetta "Karma handling on Rosetta is broken" [High,In progress]  http://launchpad.net/bugs/35631
[02:38] <Ubugtu> Malone bug 40550 in rosetta "Further filtering options for the Queue" [Medium,In progress]  http://launchpad.net/bugs/40550
[02:38] <cprov> DONE: publisher fixes, queue-ui, redesigning publisher (integrating code in content classed)
[02:38] <salgado> DONE: Lots of shipit changes; Fixed permissions for mirrors with the addition of Distribution.mirror_admins; Some code review and other trivial fixes
[02:38] <salgado> TODO: Land the permission fix for mirrors; Fix some timeouts and other trivialities on shipit; Code review and any other important bugs that show up
[02:38] <salgado> BLOCKED: No
[02:38] <cprov> TODO: mode publisher integration, fix top-level script, Paris Conf
[02:38] <cprov> BLOCKED: none
[02:38] <Ubugtu> Malone bug 49599 in rosetta "Import will fail if there are two lines together in a single line" [High,Confirmed]  http://launchpad.net/bugs/49599
[02:38] <Ubugtu> Malone bug 40550 in rosetta "Further filtering options for the Queue" [Medium,In progress]  http://launchpad.net/bugs/40550
[02:38] <BjornT> DONE: fixed bug 32282 (reduce long comments). reviews. fixed a few small bugs.
[02:38] <ddaa> DONE: back from bzr sprint, various (production fixes, merges, vcs imports, travel details, blog draft, etc.)
[02:38] <ddaa> TODO: more various (expenses, launchpad blog, cscvs review fixes)
[02:38] <ddaa> BLOCKED: no
[02:38] <Ubugtu> Malone bug 32282 in malone "Try to reduce of the amount of LONG comments" [Medium,In progress]  http://launchpad.net/bugs/32282
[02:38] <BjornT> TODO: work on host-based publication. paris summit.
[02:38] <SteveA> DONE: management, review calls, hacking
[02:38] <SteveA> TODO: UI tweaks, virtual host stuff with bjorn, special features controls, menus landing
[02:38] <SteveA> BLOCKED: no
[02:38] <BjornT> BLOCKED: no
[02:38] <bradb> DONE: Fixed various bugs. Polished off xmlrpc filebug API.
[02:38] <bradb> TODO: Hopefully rollout filebug xmlrpc on mawson for pre-testing. Get some way through release bug managmement. Pair program with Francis. Paris. More refactoring and PEP 8 blitzkrieg. pr0n.
[02:38] <bradb> BLOCKED: xmlrpc fixes (BjornT. AIUI, it's being worked on today and tomorrow). Decision on separate BugNomination table (kiko), but meanwhile I can do UI mockups.
[02:38] <Kinnison> DONE: Review DiskPool and begin to prepare tests for it, setAccepted() extra checks branch got to review, assisted TeamSpeak, various soyuz debugging.
[02:38] <Kinnison> TODO: review response for setAccepted() branch, get bug 47770 sorted, carry on with DiskPool stuff, Goto Paris
[02:38] <Ubugtu> Malone bug 47770 in launchpad-publisher ""raw-dist-upgrade" target does not support pockets" [Medium,In progress]  http://launchpad.net/bugs/47770
[02:38] <Kinnison> BLOCKED: None
[02:38] <jamesh> DONE: code reviews, get tickcount module ready for distribution, bzrsync work
[02:38] <jamesh> TODO: code reviews, bzrsync work
[02:38] <jamesh> BLOCKED: no
[02:38] <kiko> DONE: landing my de-XXX-ification branches and some perf fixes, lots of code reviews and coding support, in particular for soyuz and malone, assistance to new team members, sprint setup
[02:38] <matsubara> DONE: oops report analysis, fixed bug on teammembership, helping user over
[02:38] <matsubara> IRC, fixed bug on broken traversal on bug web links, triage
[02:38] <matsubara> TODO: more oops fixes, more triage
[02:38] <matsubara> BLOCKED: no
[02:38] <kiko> TODO: more of the same I suspect, and release a launchpad report
[02:39] <SteveA> bradb: are you actually blocked on xmlrpc stuff that bjorn is doing? 
[02:39] <bradb> SteveA: yes
[02:39] <carlos> SteveA: jordi is busy atm, will give you his sentences later
[02:39] <kiko> BLOCKED: well, the emails lost to the mailing list were sad
[02:39] <SteveA> bradb: please explain how
[02:39] <kiko> because I will suffer when producing said reports
[02:39] <SteveA> kiko: did we lose any emails?
[02:39] <kiko> yes.
[02:39] <SteveA> ah, from pqm
[02:39] <bradb> SteveA: it prevents me from deploying xmlrpc on mawson
[02:39] <spiv> DONE: supermirror bugs
[02:39] <spiv> TODO: supermirror bugs, remove magic from make check
[02:39] <spiv> BLOCKED: no
[02:39] <SteveA> bradb: please explain
[02:39] <lifeless> DONE: bzr sprinty stuff, performance analysis
[02:39] <lifeless> BLOCKED: nope
[02:39] <lifeless> TODO: much
[02:40] <jordi> DONE: email of various stuff, bug filing, xaralx setup
[02:40] <jordi> TODO: weed out templates that we should not have available, more emailing
[02:40] <jordi> BLOCKED: no
[02:40] <BjornT> bradb: it shouldn't stop you from deploying it on mawson. it works except for the error handling in the xmlrpc client.
[02:40] <ddaa> xaralx? sounds like an spam-advertised medication...
[02:40] <bradb> SteveA: BjornT says there's a bug that causes an exception to be raised, instead of the proper Fault being returned, so error handling would be broken. and there's some deeper problem in the server that BjornT would have to explain.
[02:40] <jordi> ddaa: lol
[02:40] <SteveA> bradb: why does this block you?
[02:41] <bradb> BjornT: oh, i was of the understanding that there was a server bug that would prevent the xmlrpc from working properly for me. i'm also somewhat uncomfortable with releasing untested code.
[02:41] <SteveA> i don't see how this blocks you from deploying xmlrpc on mawson
[02:41] <SteveA> what untested code that you have written are you concerned about?
[02:41] <kiko> it can't properly be tested but the mawson run is just a POC
[02:41] <SteveA> POC?
[02:41] <spiv> proof of concept
[02:41] <kiko> proof of concept
[02:41] <lifeless> proof of crap
[02:41] <SteveA> thanks
[02:42] <kiko> lifeless, mhaaaa
[02:42] <bradb> SteveA: i currently have only view tests, not actual xmlrpc tests for my xmlrpc code.
[02:42] <SteveA> i was thinking neil young songs
[02:42] <kiko> the crazy horse
[02:42] <SteveA> bradb: that's fine, and in line with our current standards
[02:42] <bradb> but it sounds like i can deploy it today, if mawson is otherwise free
[02:42] <flacoste> DONE: familiarize myself with Launchpad policies, procedures, support tracker code, met some members of the team
[02:42] <SteveA> so, bradb, you are not blocked
[02:42] <flacoste> BLOCKED: no
[02:42] <flacoste> TODO: fix some support-tracker bugs
[02:42] <kiko> https://launchpad.net/distros/ubuntu/edgy/+builds
[02:43] <kiko> I love how the title of that page says
[02:43] <kiko> The Edgy Eft builds
[02:43] <bradb> i will talk to salgado or whomever about rolling it out on mawson today
[02:43] <SteveA> cool
[02:43] <kiko> I would even stick an exclamation mark to that!
[02:43] <kiko> The Edgy Eft builds!
[02:43] <kiko> of course it is not actually building
[02:43] <SteveA> okay.  we're almost done
[02:43] <SteveA> any blockages not dealt with?
[02:43] <kiko> I have to send some mail to mark about xmlrpc and DRBT
[02:44] <SteveA> what is DRBT?
[02:44] <kiko> distro release bug blah
[02:44] <SteveA> it looks like the lithuanian verb "to work"
[02:44] <kiko> I use the acryonyms when my elbows hurt
[02:44] <kiko> or when it doesn't matter anyway!
[02:44] <SteveA> you need to eat more
[02:44] <SteveA> then you won't have elbows
[02:45] <bradb> heh
[02:45] <SteveA> okay that's all folks.  there's time for some other general questions after the meeting
[02:45] <SteveA> MEETING ENDS
[02:45] <SteveA> thank you
[02:45] <kiko> okay
[02:45] <kiko> I AM ON PUBLIC HOLIDAY
[02:45] <SteveA> no way
[02:45] <kiko> emergencies ring my cellphone but don't expect anything but crying and panting
[02:45] <kiko> Kinnison, I looked at your patch and it is thumbs-down!
[02:45] <SteveA> kiko: is it public holiday tomorrow too?
[02:46] <ddaa> kiko: too late, you are on a public holiday!
[02:46] <kiko> SteveA, no!
[02:46] <SteveA> kiko: i am looking at that patch also, and have talked with kinnison about some refactoring of it
[02:46] <kiko> SteveA, ah, okay. have you seen my email?
[02:46] <SteveA> no
[02:46] <kiko> I am concerned that soyuz is peppered with band-aids like that
[02:46] <kiko> SteveA, do a grep for pocketsuffix in canonical/archivepublisher
[02:46] <jamesh> SteveA: re: using the Python license for tickcount, is there a particular text to use?  The license file in Python is 4 separate licenses concatenated, and the one for new code is pretty specific to Python + PSF
[02:46] <kiko> and count how many times we do the distrorelease + suffix operation
[02:47] <Kinnison> kiko: and then think back to Australia where I argued against pockets
[02:47] <fabbione> kiko: i need something working...
[02:47] <Kinnison> kiko: *sigh*
[02:47] <kiko> fabbione, please don't pressure untested code into production.
[02:47] <kiko> fabbione, it only means you will pay the price later.
[02:47] <SteveA> there's a communication issue here
[02:47] <kiko> or rather, WE ALL pay the price
[02:47] <fabbione> kiko: ok.. let me explain... 
[02:47] <SteveA> kiko: although you're on vacation, i'd like a brief phone call to set policy on this
[02:48] <kiko> SteveA, now or never, but read my email first.
[02:48] <SteveA> fabbione: i'll talk with kiko and daniel
[02:48] <fabbione> SteveA: ok
[02:48] <SteveA> kiko: read already
[02:48] <kiko> please then
[02:48] <SteveA> ok, i call now
[02:48] <kiko> you call now!1! you call now!
[02:48] <kiko-afk> my keyboard needs a rest
[02:49] <SteveA> don't type with your elbows so much
[02:49] <fabbione> bradb: please you miss some background here...
[02:49] <bradb> i'm not talking about your case. i'm talking about mine.
[02:49] <fabbione> ok
[02:52] <bradb> speaking of which, this makes me so want keywords to tag refactoring bugs!
[02:56] <sven-tek> i used the merge accounts function, but now i dont have access to the wikiname i had in the removed account. any solution?
[02:56] <bradb> salgado: ^^
[02:57] <Kinnison> stub: can you come to ##soyuz1.0 for a sec?
[02:58] <salgado> sven-tek, so, you're trying to register the wikiname of the removed account on your current one?
[03:00] <Keybuk> E: gcc-3.3 is trying to override libgcc1_1:4.1.1-2ubuntu3 without -f/--force.
[03:00] <Keybuk> eh?
[03:01] <Keybuk> did that library move packages?
[03:02] <fabbione> that'd be gcc-4.1 ?
[03:02] <Keybuk> sync-source can't cope with that then
[03:04] <doko> Keybuk: where do you see this error message?
[03:05] <Keybuk> sync-source's output
[03:05] <Keybuk> we didn't change it in dapper, but it's changed in unstable
[03:11] <sivang> crappy net connection again, /me read the backlog
[03:14] <sven-tek> salgado, yes
[03:15] <salgado> sven-tek, and then what do you get when you try to register it?
[03:16] <sven-tek> Is allready registered by ... . Where ... is my old WikiName. I can not log in to the ... Account because it is removed.
[03:18] <salgado> sven-tek, what are the names of the removed account and the remaining one?
[03:19] <sven-tek> my remaining account has the wikiname "Sven Jaborek", which should be replaced by "SvenJaborek"
[03:24] <salgado> sven-tek, actually, I need the launchpad names. the name of the remaining account should be in the message you get when trying to register the wikiname
[03:25] <salgado> and the name of the remaining account is the bit that comes after /people/ on your launchpad home page
[03:26] <SteveA> Kinnison: phone or skype call please
[03:27] <Kinnison> SteveA: +44 161 248 8066
[03:30] <Keybuk> SteveA: surely VoIP is better than Skype? :p
[03:45] <salgado> stub, around?
[03:47] <stub> salgado: Yup
[03:47] <salgado> stub, I have a trivial db patch; can you review it for me?
[03:48] <stub> k
[03:48] <salgado> stub, https://chinstrap.ubuntu.com/~dsilvers/paste/fileriNOhQ.html
[03:48] <stub> salgado: It should be mirror_admin, not mirror_admins
[03:49] <Keybuk> it's very disconcerting having two "the office"s
[03:49] <salgado> stub, hmmm. I think you're right. I used that because we already have distribution.members, though
[03:50] <stub> salgado: That can be rationalized because it will always be a team, as that column was an Ubuntu specific hack IIRC
[03:50] <salgado> I was expecting this one to always be a team too. but it probably won't 
[03:51] <salgado> I'll change it to mirror_admin
[03:51] <stub> And 'member' is a euphamism for 'penis'
[03:53] <salgado> stub, apart from that, does it look okay?
[03:53] <stub> salgado: Looks fine apart from the column name. approved as patch-40-63-0.sql
[03:54] <salgado> cool. thanks!
[03:54] <Keybuk> stub: in australian, every word is a euphemism for "penis"
[03:55] <stub> Yer, but some words also double as euphemisms for other stuff too.
[03:55] <sivang> Keybuk: heh
[03:55] <spiv> "stub", eh? ;)
[03:55] <lifeless> ;)
[03:55] <SteveA> put that euphamism away
[03:56] <Kinnison> umm, eww
[03:56] <SteveA> you never know where it's been
[03:56] <sivang> HEHE
[03:57] <SteveA> Kinnison is obsessed with 
[03:57] <SteveA> Kinnison is obscessed with dict
[03:58] <SteveA> cprov-away: ping when you're back
[03:58] <Kamping_Kaiser> lol Keybuk 
[03:58] <cprov-away> SteveA: ping
[03:59] <salgado> SteveA, what about some code review while you wait for cprov?
[03:59] <salgado> dammit!
[03:59] <cprov-away> salgado: sorry, I'm still trying to be away 
[04:00] <lifeless> Keybuk: skype has about 2OOM better nat traversallogic than sip
[04:01] <Keybuk> lifeless: yes, but it has exactly the 0 of the ability to connect from something other than a proprietary skype connection of sip
[04:01] <Keybuk> and sip traverses my nat here just fine
[04:01] <lifeless> Keybuk: do you have siproxd or the sip iptables module ?
[04:01] <Keybuk> neither
[04:02] <Keybuk> asterisk just went "oh, that's behind a NAT is it?"
[04:02] <lifeless> ah, talking to asterisk should be fine, you might have less joy talking to a peer 
[04:04] <Keybuk> asterisk in those circumstances seems to do the right thing
[04:04] <Keybuk> and if not, you can always use IAX or STUN, etc.
[04:05] <Keybuk> I successfully had two ekigas behind two NATs talking to each other
[04:07] <lifeless> IAX should always be good AIUI.
[04:07] <lifeless> STUN is not a solution to NAT, its merely a bandaid for *some* cases.
[04:08] <lifeless> with STUN you still end up with sip handhsaking and a 4-port 2-stream RTP setup
[04:09] <lifeless> and thats the crux of the problem : rather than ports A & B, one per client, and udp flowing bidirectionally, you get 2 ports at either end, one for in, one for out, and two unidierctional streams
[04:21] <Keybuk> it's still less evil than Skype :P
[04:21] <Keybuk> who don't even offer a connect to their network from outside
[04:23] <jamesh> Keybuk: sure they do: the PSTN
[04:24] <lifeless> Keybuk: its a different evil.
[04:24] <lifeless> myself, I dont like skype
[04:25] <Keybuk> I was quite impressed how easy asterisk is to set up once you figure out the basics
[04:28] <jamesh> lifeless: btw, I think I got Ekiga working through siproxd finally, after fixing the siproxd 64-bit issues and using the new version of Ekiga (not in dapper)
[04:30] <lifeless> awesome
[04:30] <lifeless> spiv: are you still around ?
[04:50] <seb128> hey
[04:50] <seb128> is the milestone setting supposed to be to a different place now?
[04:50] <seb128> or I just need a group membership I don't have atm to have it?
[04:57] <spiv> lifeless: yeah
[04:59] <lifeless> this import thing
[04:59] <spiv> lifeless: on the bzr list?
[04:59] <lifeless> yeah
[04:59] <spiv> Ah, I see I have new mail on the subject
[05:01] <spiv> I skimmed the docs on import stuff and didn't see the rules for the order of looking for .so vs. .py anywhere, but I could easily have missed something.
[05:01] <spiv> The docs for the imp module do say they'll search in the order returned by imp.get_suffixes() (which obviously varies by platform, e.g. for .so vs. .pyd)
[05:02] <lifeless> right
[05:03] <salgado> seb128, I can see the milestone dropdown widget right beside the importance one, so I guess you're lacking permissions
[05:03] <lifeless> I'm not too keen on a dead checken for every C extension
[05:03] <LarstiQ> and I suppose is different for non CPython 
[05:03] <seb128> salgado: ok, thank you
[05:03] <seb128> need to ping mdz about it then :p
[05:03] <salgado> I guess so. :)
[05:03] <lifeless> LarstiQ: if its not C python, then C extensions are fairly irrelevant :)
[05:03] <spiv> lifeless: think of it as an encouragement to avoid making more C extensions than necessary ;)
[05:04] <lifeless> spiv: so far we look likely to need 2 - readdir.d_type and fchmod
[05:05] <LarstiQ> lifeless: you may have a point there :)
[05:06] <lifeless> spiv: also, more files to import == 4 more stats on startup/first use
[05:06] <lifeless> spiv: loading one .so/.py pair = 1 stat if the .so is there, 4 if its not.
[05:07] <lifeless> loading a .py and then a .so with fallback to .py is 5 if the .so is there, 16 if its not.
[05:07] <spiv> How many nano-seconds for a stat that's already in cache?
[05:07] <lifeless> unfortunately most folk will not run bzr from hot cache all the time
[05:08] <lifeless> if they were, I would not even mention that
[05:08] <spiv> Well, I'd expect with most filesystems that once a stat has occurred in a directory, another stat in that directory is likely to hit cache.
[05:08] <spiv> (with directories the size of the directories in the bzr source tree)
[05:09] <lifeless> actually, I underestimated the stat count
[05:09] <spiv> I am wildly hand-waving here, though.
[05:09] <lifeless> because it will proceed to search the sys path after it misses the .so
[05:09] <lifeless> in the form you suggested.
[05:10] <lifeless> unless we use the fully qualified name for the import I guess
[05:10] <spiv> I should have suggested "from bzrlib._c_foo import *" rather than "from _c_foo import *".
[05:10] <spiv> Right.
[05:10] <SteveA> always use FQNs for imports
[05:10] <lifeless> SteveA: I do
[05:10] <spiv> (I was thinking that, but should have been more explicit in my email)
[05:10] <SteveA> although very recent pythons and very ancient python have better support for relative imports 
[05:12] <spiv> lifeless: So, I think while the number of C extensions is low and the impact (both in terms of extra load time and extra dead chickens) is negligible, you should use "try: from bzrlib._c_foo import *\nexcept ImportError: from bzrlib_py_foo import *".  Long-term, perhaps you can get what you want with the new sys.path_hooks stuff described in PEP 302, although I haven't looked into that closely.
[05:12] <lifeless> I dont think so, it did not seem terribly reelvant here
[05:13] <lifeless> spiv: the other issue I forgot to put in my email is the surety thing from running the whole test suite not just the interface conformance tests for these modukes.
[05:13] <lifeless> theres a much greater risk of things slipping through here with the complete change in language.
[05:14] <lifeless> oh, and guaranteeing the tests run with the C extensions without breaking users without them running --selftest.
[05:14] <spiv> Well, I think you could have an import hook that would know that "bzrlib.foo" and "bzrlib.bar" may have C implementations in a directory over here (if they are built), otherwise load the .py/.pyc/.pyo as normal.
[05:14] <lifeless> this is something that requires non trivial handwaving to get more correct than I have it now, IMNSHO
[05:15] <spiv> EPARSE
[05:16] <spiv> I appreciate the point about testing all combinations adequately.
[05:16] <lifeless> there are mutually conflicting requirements here
[05:16] <lifeless> you can sort them out with enough glue code and options to the test suite.
[05:17] <lifeless> If *someone else* wants to write that, I'm happy
[05:17] <lifeless> but its largely valueless code: its not functionallty better at preventing bugs getting past PQM, and it will take time to write and test. 
[05:18] <spiv> Although this strikes me as just a more extreme version of the issue you have with say SFTP transports vs. local transports.  Again, it's a reason to keep the scope of your C extensions as tight as possible.
[05:18] <lifeless> its qualitatively different.
[05:18] <lifeless> we consider transports plugins - if you have the support for the transport, it should work and test, if you don't, its fine.
[05:20] <lifeless> this stuff is mandatory - it /must/ work and /must be tested/ on PQM.
[05:20] <lifeless> I had the SFTP tests as mandatory at one point, in case you think they should be considered mandatory ;)
[05:20] <spiv> The interface is "import bzrlib.foo", and is what absolutely all callers go through, except the test suite, which can explicitly choose "import bzrlib._c_foo" or "import bzrlib._py_foo" as appropriate.  I don't think there's any real risk of bugs here -- code that imports _xxx modules will stick out like a sore thumb.
[05:21] <lifeless> that wasn't a bug I was concerned about
[05:21] <spiv> Then I'm not understanding your concern.
[05:21] <spiv> (which given it's past 1am isn't so surprising :)
[05:22] <spiv> FWIW, if you stick with your current approach, I think that can be workable.
[05:23] <spiv> I'd have a test that ensures that the module load order is what you expect, in case a future revision of python changes it unexpectedly.
[05:23] <spiv> (or find an actual guarantee of that behaviour in some docs...)
[05:23] <lifeless> well, I'd like to find someone to give a guarantee before merging this
[05:23] <lifeless> rather than having something ship that will eventually break
[05:23] <lifeless> anyhow, go to bed :)
[05:24] <spiv> For explicit testing of the pure-python version you *could* muck about with execfile or import helpers to force loading of the pure python file.
[05:24] <spiv> But then you're heading into the "writing glue for no real benefit" territory again :)
[05:31] <lifeless> spiv: I've tried to write this out longhand in a new mail
[05:43] <zakame> hi all
[05:44] <zakame> erm is LP down? I couldn't seem to update the satuts for malone 49839
[05:44] <Ubugtu> Malone bug 49839 in nbd "please sync 2.8.3-2 from Debian" [Unknown,Unknown]  http://launchpad.net/bugs/49839
[05:45] <zakame> hmm I could get to my LP page, weird
[05:55] <flacoste> Montreal office is going to lunc
[06:04] <spiv> lifeless: fwiw, the only docs I can find say that the search order is defined by what imp.get_suffixes() returns, but no docs say anything about what that will be.
[06:05] <spiv> lifeless: the current implemenation clearly puts dynamically loaded C modules before pure python ones (regardless of platform), and it looks like that's always been the case, but afaict it's not defined behaviour.
[06:06] <lifeless> spiv: go... to..... bed.........
[06:06] <lifeless> (but thanks)
[06:06] <spiv> But I doubt it will change before python 3; it would be a gratuitous backwards compatibility.  So it's something you could perhaps rely on, but definitely take care if you do!
[07:31] <lifeless> later all, off to eat and then -> hotel
[07:32] <lifeless> SteveA: if needed, I will be at the hotel in 1.5 hours probably, can happily get wifi there if needed, if something urgent comes up again
[07:33] <carlos> later
[07:34] <jordi> SteveA: ping?
[07:35] <SteveA> jordi: hi
[07:35] <SteveA> lifeless: thanks
[07:37] <jordi> SteveA: I had an email half written, so I just fired it off
[07:38] <ddaa> yay, finished the blog article
[07:46] <jordi> SteveA: I gotta go, see ya later
[08:14] <py2elg> list
[08:27] <Keybuk> elmo: librarian.stagining.ubuntu.com.  ?
[08:30] <jbailey> How do I mark a specification as private?
[08:31] <jbailey> Jane said that Canonicalish bofs in Montreal were handled in some way that obscured what they were but still allowed them to be scheduled.
[08:31] <jbailey> I'm trying to set one up, but I'm not clear on how the obscuring happens.
[08:39] <SteveA> they were public in the launchpad spec tracker, but hosted on a private wiki site
[08:42] <jbailey> Ah, okay.  Should I register them against the distro still, or is there a Canonical object that I should use instead?
[08:44] <salgado> does anybody know where's the code for the import fascist?
[08:44] <salgado> duh. found it already
[08:47] <Keybuk> cprov-away: publisher back to auto
[08:48] <cprov-away> Keybuk: okay, will see its next run
[08:48] <Keybuk> there were no problems with the big run
[08:50] <jordi> SteveA: any news?
[09:11] <SteveA> jordi: what kind of news?
[09:14] <jbailey> jordi: By the sounds of the cheering outside the window, it sounds like a good game. =)
[09:24] <matsubara> bradb: ping
[09:24] <bradb> matsubara: pong
[09:25] <matsubara> bradb: bug 49891, assigning to you, ok?
[09:25] <Ubugtu> Malone bug 49891 in malone "+editstatus of a bug crashes when you're not logged in." [Medium,Confirmed]  http://launchpad.net/bugs/49891
[09:25] <bradb> matsubara: yes please!
[09:25] <matsubara> bradb: I also added a test case to it.
[09:26] <bradb> matsubara: nice work!
[09:27] <cprov-away> maybe it was too much for p-a ->  -> http://librarian.launchpad.net/3056425/A6oTrV7FlRueCxQPbXXds7aaEuL.txt (ERROR:  could not serialize access due to concurrent update). trying again
[09:29] <cprov-away> carlos: ping
[09:37] <salgado>     raise ValueError, "unknown url type: %s" % self.__original
[09:37] <salgado> ValueError: unknown url type:
[09:37] <salgado> has anybody ever seen this when running a new-style pagetest?
[09:40] <BjornT> salgado: haven't seen it before, can you paste the full traceback?
[09:41] <salgado> sure
[09:41] <salgado> https://chinstrap.ubuntu.com/~dsilvers/paste/fileCMjwZT.html
[09:44] <salgado> url seems to be an empty string
[09:45] <BjornT> can you paste full test as well, up to the part that triggers the error?
[09:46] <salgado> this one is easy: https://chinstrap.ubuntu.com/~dsilvers/paste/file9Y9qMr.html
[09:52] <BjornT> salgado: hmm, nothing obvious comes to mind what could be wrong, and that test passes for me.  did you change anything on that page you are testing?
[09:58] <salgado> BjornT, no, I didn't change anything on that page. 
[09:58] <salgado> hmmm. /me updates his sourcecode/
[10:00] <matsubara> bradb, BjornT could you take a look at this OOPS-165C140? I don't understand why it's crashing.
[10:00] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/165C140
[10:01] <salgado> BjornT, these are the only changes I have that are not in rocketfuel: https://chinstrap.ubuntu.com/~dsilvers/paste/fileRY40mY.html
[10:07] <BjornT> salgado: oops, i ran a python source file instead of the actual tests... now it fails for me as well.
[10:09] <bradb> matsubara: strange. both +editstatus and +viewstatus work
[10:11] <matsubara> bradb: on production? I tried here and it crashes for me. https://launchpad.net/products/cfengine/+bug/6624/+editstatus
[10:11] <Ubugtu> Malone bug 6624 in cfengine "Segmentation Fault " [Unknown,Unknown]  
[10:11] <bradb> matsubara: https://launchpad.net/distros/ubuntu/+source/cfengine/+bug/6624/+editstatus
[10:11] <Ubugtu> Malone bug 6624 in cfengine "Segmentation Fault " [Unknown,Unknown]  
[10:12] <matsubara> it crashed for me.
[10:12] <matsubara> OOPS-166B1442
[10:12] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/166B1442
[10:13] <matsubara> hmm it crashed when I wasn't logged in.
[10:13] <matsubara> which could be the other bug.
[10:14] <matsubara> but if you visit https://launchpad.net/products/cfengine/+bug/6624 
[10:14] <Ubugtu> Malone bug 6624 in cfengine "Segmentation Fault " [Unknown,Unknown]  
[10:14] <matsubara> it crashes even when I'm logged in.
[10:17] <bradb> so far, i'm only seeing it crash two conditions are true: 1. I'm logged in and 2. I'm viewing the bug page
[10:18] <bradb> s/two/when two/
[10:20] <bradb> OOPS-165A2401
[10:20] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/165A2401
[10:21] <matsubara> bradb: for me it crashes: https://launchpad.net/products/cfengine/+bug/6624/ (OOPS-166D1583) and here https://launchpad.net/products/cfengine/+bug/6624/+editstatus (OOPS-166B1465)
[10:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/166D1583
[10:21] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/166B1465
[10:21] <Ubugtu> Malone bug 6624 in cfengine "Segmentation Fault " [Unknown,Unknown]  
[10:22] <matsubara> bradb: but https://launchpad.net/products/cfengine/+bug/6624/+viewstatus works fine
[10:22] <Ubugtu> Malone bug 6624 in cfengine "Segmentation Fault " [Unknown,Unknown]  
[10:23] <BjornT> salgado: the error seem to be caused by the empty action in the form. it seems to work if you set it to request/URL
[10:23] <bradb> bug 49891 is easy to fix. but this other view/importance_widget exception is less obvious.
[10:23] <Ubugtu> Malone bug 49891 in malone "+editstatus of a bug crashes when you're not logged in." [Medium,Confirmed]  http://launchpad.net/bugs/49891
[10:24] <salgado> BjornT, weird. I have other page with an empty action and the pagetest for it works just fine. :/
[10:26] <salgado> s/other/another
[10:26] <matsubara> bradb: indeed, I was trying to understand it so I can report it correctly. I guess I'll report anyway and add more info to the description later.
[10:27] <BjornT> salgado: hmm, strange. please file a bug about it, including the name of the passing test which tests a page containing an empty form action.
[10:30] <bradb> matsubara: are there any other bugs with the same problem as 6624?
[10:31] <matsubara> bradb: according to today's report yes. bugs 20062 and 34606
[10:31] <Ubugtu> Malone bug 20062 in linux "Keyboard non-responsive when using kernel 2.6.12 (breezy)" [Unknown,Unknown]  http://launchpad.net/bugs/20062
[10:31] <Ubugtu> Malone bug 34606 in Nexenta OS "Administrator root password readable in cleartext on Breezy" [Unknown,Unknown]  http://launchpad.net/bugs/34606
[10:31] <matsubara> I reported bug 49899
[10:31] <Ubugtu> Malone bug 49899 in malone "Lookup error on bug page" [High,Confirmed]  http://launchpad.net/bugs/49899
[10:33] <BjornT> matsubara, bradb: i think it's because the cfengine (upstream) is editable. it still has Unknown as the value, though, and that causes the importance widget to crash, since the value isn't found in the vocabulary.
[10:33] <BjornT> (it's editable since no bug watch is linked to it)
[10:34] <matsubara> BjornT: thanks, I'll add that to the bug.
[10:35] <BjornT> the best solution is probably to write a migration script, which resets all Unknown values to the default values if there is no bugwatch linked to the task.
[10:35] <bradb> BjornT: but Unknown is in the vocab
[10:36] <BjornT> is it?
[10:36] <bradb> BjornT: and viewstatus uses widgets too, and they work fine
[10:37] <bradb> BjornT: and none of us can edit that task's Importance anyway
[10:37] <salgado> BjornT, I changed the action but it's still failing. https://chinstrap.ubuntu.com/~dsilvers/paste/filem1StEx.html
[10:38] <BjornT> bradb: it's not in the vocabulary, and the display widgets don't care if it's in some vocabulary or not.
[10:39] <bradb> BjornT: 
[10:39] <bradb>     UNKNOWN = Item(999, """
[10:39] <bradb>         Unknown
[10:39] <bradb>         The severity of this bug task is unknown.
[10:39] <bradb>         """)
[10:39] <bradb> that's in BugTaskImportance
[10:39] <BjornT> bradb: that's the dbschema, not the vocabulary
[10:41] <bradb> ewph, that is nasty
[10:42] <salgado> BjornT, nevermind about the last failure. I know what's causing it. (not that I know how to fix it yet, but anyway)
[10:51] <Yannig> Hello everybody :)
[10:58] <mdke> hey jordi, I've noticed quite a lot of Chinese (Hong Kong) translations for docs... apparently that's just the same as normal Chinese, do you know otherwise? I don't really want to go through validating another set of translations for a docs upload unless it's definitely a valid language
[10:59] <bradb> BjornT: there seems to be another problem too. none of us should have perms to edit Importance on that bug, on any task.
[10:59] <bradb> but somehow, it seems specifically that this page errors:
[10:59] <bradb> https://launchpad.net/products/cfengine/+bug/6624/+editstatus
[10:59] <Ubugtu> Malone bug 6624 in cfengine "Segmentation Fault " [Unknown,Unknown]  
[10:59] <bradb> editing importance requires launchpad.Edit on the IProduct
[11:00] <bradb> but there is no launchpad.Edit defined for IProduct
[11:00] <bradb> so, with:
[11:00] <bradb> class IProduct(IHasOwner, IBugTarget, ISpecificationTarget,
[11:00] <bradb>                IHasSecurityContact, ITicketTarget):
[11:00] <bradb> which interface does it check launchpad.Edit against?
[11:25] <mdke> jordi: also es_PR and es_ES are cropping up alongside es, any idea what they are?
[11:59] <bradb> SteveA: ping
[12:02] <SteveA> bradb: come on man, what kind of time do you call this? ;-)
[12:03] <bradb> SteveA: time for best practices clarification!
[12:03] <SteveA> i think that time is *tomorrow*
[12:03] <bradb> SteveA: anyone logged in to #launchpad is vulnerable!
[12:03] <bradb> ok :P
[12:04] <SteveA> i'm only here for the entertainment
[12:05] <bradb> get up on the table and dance!