[12:37] <spiv> lifeless: Hmm, ok.
[12:37] <spiv> carlos: I'm very rarely around at 5am :)
[12:50] <lifeless> spiv: that would be muchly appreciated
[01:09] <carlos> spiv: yeah, I thought it after pinging you :-P
[01:35] <dilys> Merge to devel/launchpad/: [r=spiv]  Fixed the filtering form submission and added the missing tests. (r3107: Carlos Perell Marn)
[01:45] <carlos> see you tomorrow!
[03:00] <mpt_> Goooooooooooooooooood afternoon Launchpadders!
[05:06] <jamesh> stub: I think the value of oops_root_url in the production configs is wrong
[05:06] <jamesh> stub: missing a slash at the end.
[05:06] <stub> jamesh: Yes - I didn't get around to the cherry pick I needed yesterday
[05:18] <stub> spiv, jamesh: I've tracked down a bug (at least from our point of view) in SQLObject and I think identified the bits that need changing. Details are in the launchpad@ mailing list. I don't suppose either of you know if 'foo is 0' or 'foo is false' are valid under mySQL? It looks like sqlbuilder.py is attempting to generate platform agnostic SQL so fixing this for PostgreSQL will likely break mySQL.
[05:22] <spiv> stub: I don't know much about mysql
[05:28] <jamesh> stub: I've only ever seen "IS" used to compare against NULL
[05:28] <jamesh> stub: surely Postgres can tell that "=" and "IS" are equivalent for a non-NULL column though, right?
[05:30] <stub> jamesh: The case we noticed this was a NULLable column. It uses three state logic (approved, not approved or pending)
[05:31] <spiv> stub: SQLObject is a bit of a mess here.  sqlbuilder will figure out that "column==None" should be "column IS NULL", but a selectBy(column=None) produces "column = NULL".
[05:31] <spiv> And doesn't seem to have any special casing for booleans, as you've noticed.
[05:32] <stub> jamesh: I doubt the planner would bother anyway with detecting NOT NULL columns in this case. It needs to be generic, and in many cases there won't be a physical column there.
[05:32] <stub> spiv: current SVN has the same behavior
[05:36] <spiv> stub: Well, at least SVN appears to make Foo.selectBy(bar=None) emit "bar IS NULL" now.
[05:37] <spiv> But again, only for None.
[05:38] <stub> spiv: Can you see anyway of making sqlbuilder generate database-backend specific code? ie. fixing this so it only has an effect if you are talking to a PostgreSQL backend? I could patch it now I think, but it would mean we have effectively forked.
[05:38] <spiv> We've already got a painful amount of divergence from upstream :(
[05:39] <stub> (__eq__ and __neq__ of sqlbuilder.SQLExpression)
[05:39] <lifeless> jamesh: do you know how to get urllib2 to make a HEAD request ?
[05:40] <jamesh> lifeless: no.  You might have to go down to httplib
[05:40] <lifeless> jamesh: just found that 'transport.has' in bzr is doing 'get' :[
[05:40] <jamesh> lifeless: actually, if you subclass urllib2.Request, you could ...
[05:40] <spiv> stub: Well, the place in sqlbuilder to hook db-specific stuff is in __sqlrepr__ methods
[05:41] <jamesh> override the get_method() method
[05:41] <lifeless> jamesh: thanks
[05:41] <lifeless> looks like pycurl transport is better already, so I'm going to ignore it :)
[05:43] <spiv> stub: So, there's two parts, I think.
[05:44] <spiv> stub: converters.py has this atm:
[05:44] <spiv> def BoolConverter(value, db):
[05:44] <spiv>     if db in ('postgres',):
[05:44] <spiv>         if value:
[05:44] <spiv>             return "'t'"
[05:44] <spiv>         else:
[05:44] <spiv>             return "'f'"
[05:44] <spiv>     else:
[05:44] <spiv> Which judging from your post to launchpad@ is suboptimal.
[05:44] <stub> spiv: Yes - that is the other part. But that can be done specifically for postgresql.
[05:45] <stub> spiv: If I update sqlbuilder however, I don't see a way of doing it without breaking other backends. Which is fine for us, but means it can't be fixed upstream.
[05:45] <stub> (without refactoring everything - urgh)
[05:46] <spiv> I *think* we can do it by hacking SQLOp.__sqlrepr__
[05:47] <spiv> With a nasty check for "if db == 'postgres' and self.op == '=' and isinstance(self.expr2, bool):"
[05:48] <stub> Ahh...
[05:48] <spiv> Which is hardly elegant.
[05:48] <spiv> But should only change behaviour for postgres.
[05:48] <stub> I don't see how that expression is relevant when talking about SQLObject :-)
[05:48] <stub> hardly elegant would be an improvement :)
[05:48] <spiv> And hope no-one is silly enough to want "False==Table.q.column" to work as well as "Table.q.column==False"... ;)
[05:50] <spiv> Or, just change the shipit code to not use sqlbuilder ;)
[05:51] <spiv> And again, this doesn't help selectBy at all :(
[05:51] <stub> This will bite us elsewhere too - we have other boolean flags :)
[05:51] <stub> Is upstream selectBy using the same sqlbuilder hooks now?
[05:52] <jamesh> spiv: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-08/B724 <- from queries #24 - #1286 look like they should have been done as a single query.  Have you seen this behaviour from sqlobject before?
[05:52] <spiv> stub: No, not at all.
[05:52] <spiv> stub: selectBy invokes self.dbconn._SO_columnClause or some such on the **kwargs.
[05:52] <spiv> The definition of which includes this gem:
[05:53] <spiv>         ops = {None: "IS"}
[05:54] <spiv> Anyway, the short answer is the logic that makes "Foo.q.column==NULL" produce "column IS NULL" is totally seperate to the logic that makes Foo.selectBy(column=NULL) produce the same (in current SVN).
[05:56] <spiv> stub: Sure it wouldn't be easier to just remove all boolean columns from our schema? ;)
[05:57] <stub> Maybe easier to rewrite SQLObject sanely
[06:00] <spiv> jamesh: Yes, unfortunately.
[06:02] <spiv> jamesh: I can't quite remember why it does that, I'll see if I can figure it out.
[06:03] <jamesh> spiv: from playing around a bit, it sounds like a lazyColumns query
[06:07] <spiv> jamesh: That would do it, but we aren't using that feature to the best of my knowledge.
[06:07] <jamesh> spiv: bugger.  I think it is caused by a bug I just noticed in my __nonzero__ implementation a few minutes ago
[06:07] <spiv> jamesh: Ouch.
[06:07] <jamesh> I've submitted the merge request
[06:07] <dilys> Merge to test/launchpad/sourcecode/sqlobject/: [trivial]  make SelectResults.__nonzero__() correctly handle self.ops['end'] ==None (r44: James Henstridge)
[06:08] <jamesh> there it goes
[06:08] <spiv> What's the 10-second summary?
[06:09] <jamesh> spiv: the __nonzero__ implementation tries to do a select query that will return minimal data to determine if any results would be returned
[06:10] <jamesh> it has to do some special stuff to handle offset queries, and I was assuming that SelectResults.ops['end']  would be unset if no end interval was set
[06:11] <jamesh> instead it seems to be set to None, so the query returns a lot more rows
[06:11] <spiv> Ah.
[06:11] <jamesh> I think it is filling the cache with a lot of SQLObject instances for those rows which only have their ID set
[06:12] <jamesh> (that's just a guess though)
[06:13] <spiv> Sounds plausible... so long as the behaviour is correct, it shouldn't matter.
[06:18] <jamesh> anyway, it should get the limit correct now
[08:18] <dilys> Merge to devel/launchpad/: [trivial]  queued user database permissions (r3108: Stuart Bishop)
[08:37] <Mithrandir> hmm; it looks like my specs page has a lot of specs which I've never seen before.. a bunch of LP specs. https://launchpad.net/people/tfheen/+specs has such specs as "Publishing morgue" and I can't understand why it's listed on my list of specs?
[08:37] <dilys> Merge to devel/launchpad/: [trivial]  more suggested changes to analyse-error-reports.py script (r3109)
[08:43] <jamesh> hmm
[08:43] <jamesh> Mithrandir: there's a dodgy query in there
[08:43] <jamesh> thanks for pointing it out
[08:44] <Mithrandir> do you want a bug about it?
[08:45] <jamesh> I'll just point it out on the mailing list
[08:45] <jamesh> stub: with the query you did for Person.specifications, I think the two subqueries are incorrect
[08:45] <Mithrandir> ok, coolie, thanks.
[08:46] <jamesh> stub: they select SpecificationFeedback.id and SpecificationSubscription.id respectively, when they should be selecting ....specification
[08:47] <stub> yet the tests passed. yay.
[08:52] <carlos> morning
[08:55] <mpt> hi carlos
[08:55] <mpt> SteveA, ping
[09:05] <jamesh> stub: I regenerated the oops summary reports to try and group timeout errors a bit better (trying to ignore integer and string constant differences in SQL queries)
[09:05] <jamesh> what do you think?
[09:07] <SteveA> mpt: hello
[09:10] <SteveA> stub: since the proper rollout, have you picked any patches for shipit?
[09:11] <stub> jamesh: where are the reports?
[09:11] <stub> SteveA: There is one going in now
[09:12] <SteveA> stub: okay.  think it will be done in 20 mins?
[09:12] <stub> 20 mins the tests will have finished running, then the rollout. So 30/40 mins.
[09:12] <stub> (assuming tests still pass)
[09:14] <mpt> SteveA, got time for a call?
[09:14] <jamesh> stub: https://chinstrap.ubuntu.com/~jamesh/oops-summaries/2006-02-08.html <- it's linked in the mail to the list
[09:14] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/summaries
[09:14] <mpt> Ubugtu, pardon?
[09:14] <SteveA> spiv: i'd love to rewrite sqlobject sometime... or at least refactor the selection of Converters to use multiadapters on database-type and data-type
[09:15] <SteveA> mpt: sure.  in 10 mins?
[09:15] <mpt> ok
[09:16] <stub> oops ubugtu did it again
[09:16] <stub> oops-a-daisy
[09:16] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/a
[09:18] <SteveA> we could give seveas a better regex
[09:18] <stub> jamesh: That looks really good
[09:19] <SteveA> jamesh: excellent report!
[09:19] <SteveA> mpt: how about some CSS styling love for it?
[09:19] <SteveA> oh, and some portlets too.  gotta have portlets
[09:20] <jamesh> I could move the whole report into a portlet
[09:20] <stub> jamesh: A minor tweak would be to collapse \$INT, (\s\$INT,)* \$INT   to     $INT [...]  $INT
[09:21] <stub> (second and third last hard timeouts are really the same)
[09:23] <SteveA> what does this $INT stuff mean?
[09:23] <stub> arbitrary integer
[09:23] <jamesh> some string of digits
[09:24] <stub> The oops will have the real values, but it lets james group queries nicely
[09:24] <SteveA> oh i see
[09:24] <SteveA> so, collapsing it is only for display
[09:24] <SteveA> not for sorting
[09:24] <jamesh> well, it does affect the sorting
[09:25] <jamesh> if it causes two groups of oops reports to collapse into one, the higher count might put it further towards the top
[09:25] <SteveA> or should i say "grouping"
[09:27] <stub> Sooo.... the test suite isn't passing on our production branch :-/
[09:27] <stub> I might have to roll out HEAD
[09:27] <stub> :-(
[09:27] <mpt> We could give Launchpad a better regex too, I just reported a bug on that
[09:27] <SteveA> launchpad a better regex for what?
[09:28] <SteveA> for DPOT?
[09:28] <jamesh> 771 occurrences of AttributeError: 'POMsgSetView' object has no attribute 'context' yesterday
[09:28] <stub> jamesh: That might be due to cherry picks
[09:28] <stub> (One of the errors I'm seeing running the test suite)
[09:28] <SteveA> so... tests don't pass on production, but do pass on HEAD
[09:28] <SteveA> any database changes since?
[09:29] <stub> I don't think so
[09:29] <stub> nope
[09:30] <SteveA> i reckon moving from errors to no errors is a good bet
[09:32] <carlos> jamesh: I saw that error and requested stub to cherrypick some code that rewrites that class and indirectly fixes it
[09:32] <SteveA> gah
[09:32] <stub> carlos: Can't cherry pick it due to conflicts
[09:32] <carlos> but I don't understand how is that we got that error if last production updated didn't have any change there (at least from me)
[09:32] <carlos> stub: oh
[09:33] <carlos> stub: give me the production branch and I will fix them for you
[09:33] <stub> carlos: production branch is broken - the test suite doesn't pass. I'm moving it to HEAD, which will include your patch
[09:33] <carlos> ok
[09:37] <SteveA> stub: would you let marilize know when the new code is running?
[09:41] <Kamion> stub: thanks for that grant - source accepts as lp_archive@drescher work now
[09:41] <stub> np
[09:43] <SteveA> BjornT: note that we're losing "priority" from malone soon
[09:43] <SteveA> while keeping severity, and renaming it "importance"
[09:44] <BjornT> oh yeah, i remember that now.
[09:49] <mpt> SteveA, back
[09:53] <SteveA> mpt: waiting for you to tall
[09:53] <SteveA> mpt: waiting for you to call
[09:54] <mpt> SteveA, "call refused"
[09:54] <SteveA> how odd
[09:58] <stub> Kinnison: Any idea what the current status of GIna running on prat is supposed to be?
[09:59] <SteveA> mpt: more router problems?
[09:59] <mpt> SteveA, no, my connection's fine
[10:12] <ddaa> oooooh man
[10:12] <ddaa> oooooooh man
[10:12] <ddaa> A guy
[10:12] <ddaa> called, apparently, Pacman
[10:12] <ddaa> sent a mail to bazaar@lists.canonical.com
[10:13] <ddaa> with subject Ubuntu
[10:13] <ddaa> saying:
[10:13] <ddaa> > If this software is free why is there a guy on ebay selling copy after copy of this software? Here is a link to one of his Auctions he has lots more!
[10:13] <ddaa> > http://cgi.ebay.com/WHY-PAY-300-for-OPERATING-SYSTEM-TRY-OUR-NEW-OS_W0QQitemZ7217957922QQcategoryZ41881QQrdZ1QQcmdZViewItem
[10:13] <ddaa> It should be illegal to be so stupid.
[10:15] <stub> We have to sell some copies or else it will be impossible to pirate it. And if it doesn't get pirated, we lose out on the 3133t users 
[10:15] <ddaa> BTW, the ebay announce would probably be illegal in many countries for lying advertisment...
[10:16] <ddaa> since it's prominently displaying artwork that's not part of the package
[10:18] <jamesh> ddaa: the "We are the copyright owner of this product." is probably the main problem with that auction
[10:19] <ddaa> oh, that too... but after spending the alloted half a second thinking about it I assumed it was a meant to mean something else...
[10:20] <jamesh> at least they don't say "shipping: 6-8 weeks", then use shipit to fulfill the order
[10:20] <ddaa> I think this copyright claim might be worth escalating to the business folks
[10:23] <jsgotangco> it also happens in ebay.ph
[10:24] <jsgotangco> i asked about it too but marlize said we don't have power over what happens to a cd when it arrives to the one who ordered it
[10:26] <jsgotangco> oh copyright
[10:26] <jamesh> jsgotangco: the problem I was pointing out was them claiming copyright
[10:26] <jsgotangco> yeah
[10:26] <jamesh> reselling the CDs isn't an issue
[10:26] <jsgotangco> "our"
[10:26] <jamesh> or pressing their own and selling them
[10:26] <jsgotangco> yeah that's pretty bad
[10:28] <jamesh> also, a number of the screenshots are obviously swiped from the internet rather than being their own
[10:29] <mdke> maybe just write to ebay and let them know the copyright notice is wrong
[10:39] <ddaa> I've told cvd on #canonical about the auction.
[10:40] <mdz> Kinnison: ping?
[10:40] <ddaa> And replied a very polite and informative email to the helpful idiot that posted to the bazaar mailing list in the first place.
[10:40] <mdz> Kinnison: the last few messages on dapper-changes have some very unusual headers
[10:41] <Kamion> mdz: I already filed https://launchpad.net/products/launchpad-upload-and-queue/+bug/30938 about that
[10:41] <Ubugtu> malone bug 30938 in launchpad-upload-and-queue "manual source accepts from new result in bizarre mails" [Normal,Unconfirmed]  
[10:42] <mdz> ah, so that's what was different about them
[10:42] <Kamion> I probably should have tried just one and then waited to ensure the mails were sane
[10:43] <Kamion> it seems to take a dreadfully long time for builds to be kicked off after source upload
[10:43] <Kamion> source accept rather
[10:43] <Kamion> language-support-te was accepted before 09:00, but there are still no builds recorded on https://launchpad.net/distros/ubuntu/+source/language-support-te/1:6.04+20060208
[10:44] <Kamion> I would expect it to have at least hit needs-build after the 09:00 publisher+sequencer run finished
[10:47] <lucas> is there a way to get a machine-readable version of https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs ?
[10:49] <stub> lucas: Not yet. We want an XML-RPC interface for that sort of thing and RSS feeds but it hasn't been implemented yet
[10:50] <lucas> ok
[10:57] <Kamion> ah, language-support-te builds showed up at last
[10:57] <Kamion> not quite sure what soyuz was doing in the meantime ...
[10:57] <SteveA> mpt: shall we continue on irc?
[10:58] <dholbach> hello
[10:58] <SteveA> dholbach: dude!
[10:58] <dholbach> malone/bugtrackers/ubuntu-bugzilla/<nr> seems to be oopsing
[10:58] <dholbach> Did somebody complain already? :-)
[10:58] <SteveA> got an oops code for me?
[10:59] <dholbach> oops-40c305
[10:59] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/40c305
[10:59] <SteveA> thanks Ubugtu 
[10:59] <SteveA> dholbach: will have to wait a couple of minutes for it to be rsynced
[11:00] <dholbach> Ok.
[11:00] <SteveA> jamesh: suggestion for oops page -- if it can't find the oops, include a single redirect to retry after the 0 or 5 minute (and a bit) time, when the rsync will be done
[11:02] <SteveA> lucas: hello
[11:02] <SteveA> lucas: https://launchpad.net/distros/ubuntu/+source/flashplugin-nonfree/+bugs-text
[11:04] <SteveA> lucas: https://launchpad.net/bugs/3204/+text   for an individual bug
[11:04] <Ubugtu> malone bug 3204 in flashplugin-nonfree "Font missing after breezy upgrade !" [Normal,Fix released]  
[11:05] <lucas> SteveA: where is it documented ?
[11:05] <SteveA> lucas: it's a brand new feature, so it isn't well documented.  There is a spec about it, though.
[11:05] <lucas> ok
[11:06] <SteveA> but i think the feature has progressed beyond the spec
[11:06] <lucas> any plan to output Yaml or XML instead ?
[11:06] <SteveA> eventually
[11:06] <SteveA> but, this rfc-822 stuff is easy to parse
[11:06] <lucas> (yaml is very easy from python)
[11:06] <SteveA> rfc822 is easy
[11:06] <SteveA> talk with Seveas about the code he wrote for ubugtu
[11:06] <lucas> yeah, but yaml is easier :-)
[11:07] <SteveA> i can't argue with that
[11:07] <daf> Python YAML support has been buggy in my experience
[11:07] <jamesh> dholbach: I'll look into it
[11:07] <SteveA> jamesh: i can't see that oops report from dholbach, oddly 
[11:07] <daf> but it's been a while since I've used it
[11:08] <jamesh> SteveA: it is a case sensitivity issue.  I should fix the oops script to upper case what people give it
[11:08] <SteveA> oka
[11:08] <dholbach> try the link from http://bugzilla.ubuntu.com/11200 for example.
[11:08] <SteveA> got it
[11:08] <dholbach> Oh, sorry.
[11:09] <Kinnison> stub: gina should never be running on prat again (well, unless we decide to import debian)
[11:09] <SteveA> dholbach: this is jamesh's area, so as he said, he'll look into it
[11:09] <pitti> hi guys
[11:09] <SteveA> hello pitti 
[11:09] <pitti> https://launchpad.net/distros/ubuntu/+source/flex/+bug/30940
[11:10] <pitti> Sorry, you don't have permission to access this page. 
[11:10] <SteveA> what's up?
[11:10] <Kinnison> mdz: I'll look into the headers
[11:10] <pitti> this was a security bug just filed
[11:10] <pitti> and I'm logged in
[11:10] <pitti> SteveA: any idea whether this changed recently?
[11:10] <pitti> IIRC I could see security bugs a while ago
[11:10] <jamesh> pitti: you (or a team you are a member of) needs to be subscribed to the bug
[11:11] <SteveA> who is 
[11:11] <SteveA> mirko@pittschaft.net  ?
[11:11] <pitti> jamesh: dooglus just filed that bug, but do people explicitly have to subscribe the security team?
[11:11] <SteveA> pitti: you can see it now
[11:11] <SteveA> but i am concerned that mirko@pittschaft.net has the launchpad name 'pitti'
[11:11] <SteveA> i almost subscribed that person to the bug instead of you!
[11:11] <pitti> oouch
[11:12] <Kamion> https://launchpad.net/people/pitti is pitti
[11:12] <pitti> https://launchpad.ubuntu.com/people/pitti <- me
[11:12] <pitti> right
[11:12] <SteveA> interesting
[11:12] <SteveA> i wonder why launchpad told me that mirko@pittschaft.net was pitti...
[11:13] <Kamion> https://launchpad.net/people/mirko-pittschaft -> display name: "pitti"
[11:13] <SteveA> BjornT: can you help answer pitti's question?
[11:13] <mdz> Kinnison: kamion filed a bug about it already, see slightly below that
[11:13] <SteveA> thanks Kamion 
[11:13] <SteveA> i'll bring this up with salgado
[11:13] <pitti> jamesh: so, do people explicitly need to sub the security team? or will that happen automatically usually?
[11:14] <pitti> SteveA: ok, thanks Steve for handling that
[11:14] <Kinnison> mdz: thanks, Got that now
[11:14] <BjornT> pitti: at the moment people need to subscribe the security team explicitly, yes
[11:14] <pitti> BjornT: ok, good to know for the future
[11:15] <SteveA> BjornT: any plans to change that so that the security team for a distro is automatically subscribed to private bugs?
[11:15] <SteveA> or something like that?
[11:15] <BjornT> pitti: there are plans to have security teams subscribed automatically, i'll see if i can find a bug or spec that specifies it
[11:15] <pitti> that's a team I recently created
[11:15] <SteveA> we should ask bradb about it later today
[11:15] <SteveA> pitti: i don't think we have code to do this yet, but we'll check with brad later
[11:16] <pitti> ok, for now I assume that dooglus just subscribed 'pitti', which just caught the wrong person
[11:16] <SteveA> pitti: no, dooglus didn't subscribe anyone
[11:16] <SteveA> he just assumed it would work
[11:16] <dooglus> I didn't subscribe anyone.
 it told me I have to 'manually CC it' to the people I want to be able to see it.
 that's why I asked who should see it
[11:17] <SteveA> (which is a good assumption).  it is ithat almost subscribed the wrong person
[11:17] <pitti> ah, ok
[11:17] <BjornT> pitti, SteveA: https://wiki.launchpad.canonical.com/SecurityTeams, check with bradb about the status of it
[11:17] <dooglus> I didn't assume it would work, either.  I went to #ubuntu-devel asking who I needed to subscribe
[11:17] <dholbach> Can somebody confirm, that Ubuntu bug 11200 wasn't moved over to Launchpad? At least, I can't find in searches.
[11:17] <Ubugtu> malone bug 11200 in linux-source-2.6.15 "Therm modules fail to load on 1st gen powerbook G4" [Normal,Rejected]  http://launchpad.net/bugs/11200
[11:17] <pitti> dooglus: thanks for being a test guinea pig :)
[11:17] <SteveA> dooglus: okay.  i would have assumed it would work :-)  and been wrong.
[11:17] <dooglus> I would never assume that anything to do with launchpad would 'just work' ;)
[11:18] <pitti> dooglus: harsh
[11:18] <dooglus> just kidding
[11:18] <pitti> (me too)
[11:18] <jamesh> dholbach: all better
[11:18] <dholbach> jamesh: Woohoo! :)
[11:18] <dholbach> Thanks.
[11:19] <dooglus> TimeOut.  I have been unable to process your humor.  Please report this failure in the form of a joke, which I will also fail to process.  Code (435234).  Thank you.
[11:19] <jamesh> gargh.  It recreated a bugs.gnome.org bugtracker :(
[11:20] <SteveA> mpt: can you put a .css in your public_html on chinstrap, and ask jamesh to point the oops summaries at it.
[11:20] <SteveA> then you can tweak the css independently.
[11:21] <mpt> oh, ok
[11:21] <SteveA> i mean, an empty css file, or one containing just the css that james is currently using
[11:21] <daf> jamesh: is there a way to find out how many bug watches pointing to Ubuntu bugs were created before the migration?
[11:21] <jamesh> dholbach: for future reference, the URL of bugzilla.gnome.org is not bugs.gnome.org
[11:22] <mpt> ... how do I put a file on chinstrap?
[11:22] <SteveA> jamesh: do you think we need aliases for bugtrackers?
[11:22] <SteveA> mpt: ssh
[11:22] <SteveA> mpt: scp, rather
[11:22] <jamesh> daf: there is a creation date in the BugWatch table
[11:23] <jamesh> mpt: open a nautilus window, and choose "Connect to Server" from the file menu
[11:23] <mpt> SteveA, why wouldn't this CSS belong in the Launchpad tree?
[11:23] <daf> jamesh: perhaps we can ask Stuart to find this out so we know how many bugs might not have been imported
[11:23] <SteveA> mpt: because i want it to work right away
[11:23] <mpt> ok
[11:24] <SteveA> james can sort it out in the launchpad tree afterwards
[11:24] <jamesh> SteveA: aliases might be useful (especially if we start to automatically create bug watches from text more
[11:25] <dooglus> the bug I raised and set to be 'hidden' now tells me "This bug has not yet been reported in malone (upstream). Do you want to report it?".  is that asking me if I want to 'unhide' it?  Or what is it really meaning?
[11:25] <stub> Kinnison: ok. I guess prat can be handed back to elmo then.
[11:26] <jamesh> SteveA: of course, having multiple URLs for a bug tracker isn't that great from the other end either.  We ended up configuring http://bugs.gnome.org/ to redirect to bugzilla.g.o because of cookie issues
[11:26] <SteveA> i see
[11:28] <Kinnison> stub: yes
[11:28] <dholbach> jamesh: erm, wouldn't that involve changing a HUGE load of bug watches?
[11:29] <Kamion> dooglus: it means that you looked at it from a URL that implied you were coming to it as a Malone bug, e.g. https://launchpad.net/products/malone/+bug/...
[11:29] <dooglus> Kamion: that's exactly what I did.  sorry!
[11:29] <daf> dooglus: no need to apologise
[11:29] <dooglus> Kamion: is there a URL I can use which implies I don't know what product or distro is it for?
[11:29] <jamesh> dholbach: nah.  I cleaned them up the majority after the migration
[11:29] <Kamion> dooglus: since Malone bugs can be on more than one entity - so if you come at it from a URL that implies a different entity then it wonders if you might want it filed there too
[11:29] <daf> dooglus: any suggestions on how we might improve the text you saw to make that clearer?
[11:30] <dooglus> just "show me bug 12345"
[11:30] <dholbach> jamesh: I see.
[11:30] <Kamion> dooglus: https://launchpad.net/bugs/...
[11:30] <daf> dooglus: /bugs/12345
[11:30] <jamesh> dholbach: the bugs I just imported referenced bugs.gnome.org again, so the duplicate bugtracker object got created again
[11:30] <Kamion> dooglus: (yes, the UI is odd, though)
[11:30] <dholbach> Ah, right.
[11:30] <dooglus> that re-writes the URL
[11:31] <dooglus> I want it to stay as "/bugs/12345" to I can easily remove the 12345 and put 23456 instead, without having to remove all that other stuff it's added to the URL
[11:32] <jamesh> dooglus: if you are using firefox, create a bookmark to "https://launchpad.net/bugs/%s", and set the keyword to "lpbug"
[11:32] <jamesh> dooglus: then you can just type "lpbug 1234" in the URL bar to go to the bug
[11:32] <dooglus> I think the "This bug has not yet been reported in malone" message was particularly confusing since it *has* been reported in malone (since malone is the system which holds all the bugs).  It just hasn't been reported *against* the malone *component* or some such.
[11:32] <mpt> jamesh, https://chinstrap.ubuntu.com/~mpt/oops.css
[11:33] <dooglus> jamesh: good idea
[11:34] <daf> dooglus: that's a good point
[11:34] <daf> dooglus: could you file a bug against malone saying so? :)
[11:34] <mpt> SteveA, when you've finished reviewing SimplifyingMalone and FixingProjects, https://wiki.launchpad.canonical.com/DuplicateBugHandling is ready
[11:37] <dooglus> daf: is malone an 'upstream product'?  I thought it was internal?
[11:37] <daf> malone is not free software, no
[11:37] <daf> but we track its bugs in Launchpad
[11:40] <ddaa> dooglus: in that specific case, "upstream" is a misnomer. But it's reasonable to expect that people filing bugs in malone know enough not to be confused by that.
[11:40] <ddaa> s/in/on/
[11:41] <jamesh> "upstream" only makes sense if you happen to be downstream of the upstream
[11:41] <daf> jamesh: exactly
[11:41] <dooglus> ddaa: I wouldn't make that assumption.  when malone crashes it tells you to raise a bug against malone...
[11:41] <SteveA> yeah
[11:41] <SteveA> dooglus: we're changing that, i think
[11:41] <dooglus> ddaa: that happens to everyone, doesn't it?  or is it picking me out for regular special treatment?
[11:41] <SteveA> there's a launchpad development meeting in 1 hour or so
[11:41] <daf> mpt: thoughts on the term "upstream"?
[11:41] <SteveA> and on the agenda is whether we should encourage people to file support requests rather than bugs
[11:42] <SteveA> about problems with launchpad
[11:42] <mpt> daf, before I started working on Launchpad, I'd never heard the term "upstream" used about software
[11:42] <SteveA> because often people really want to get on with using launchpad, and find a workaround
[11:42] <SteveA> and as a secondary thing, want to get the underlying problem fixed
[11:42] <daf> mpt: well, it's a term taken from Debian
[11:42] <SteveA> what do you think about this, dooglus ?
[11:42] <daf> mpt: it's Debian/Ubuntu jargon
[11:42] <mpt> daf, the question is not so much whether it's good or bad, as whether there's a better way of putting it
[11:43] <daf> mpt: true -- my question should have been "can you think of a better way to put it?"
[11:43] <ddaa> SteveA: last time I checked, the request tracker was essentially unusable.
[11:43] <ddaa> for lack of email notifications
[11:43] <SteveA> ddaa: and the reson for this is...
[11:43] <SteveA> ddaa: that we don't use it!
[11:44] <mpt> nah, e-mail notifications are the chicken AND the egg
[11:44] <SteveA> ddaa: but, do bring this up in the meeting
[11:44] <ddaa> I actually suggested using it as part of the rcs import workflow at some point.
[11:44] <daf> dooglus: no, it's not singling you out
[11:44] <daf> dooglus: Launchpad is very egalitarian about OOPSing on people
[11:44] <ddaa> SteveA: but, like all the rest, it fell through the cracks as I was called to some fire or other.
[11:45] <dooglus> another thing:  is it by design that malone fails to respect leading whitespace in bug reports, and sometimes even line-breaks?
[11:46] <daf> there's a bug about that, I think
[11:46] <dooglus> I've seen it join lines together where I know I've hit return...
[11:46] <dooglus> there is?  I've not seen it.
[11:47] <mpt> yes, that's the "oh, this must be hard-wrapped e-mail" bug
[11:47] <mpt> That assumption should just be ripped out, really
[11:48] <dooglus> it's #3002 perhaps
[11:48] <mpt> bug 3002
[11:48] <Ubugtu> malone bug 3002 in malone "malone mess comments formating" [Normal,Confirmed]  http://launchpad.net/bugs/3002
[11:48] <mpt> that's one of them
[11:49] <mpt> daf, perhaps we should (1) special-case products that belong to the Launchpad product group to never use "upstream", and (2) only use "upstream" elsewhere where we really need to for disambiguation purposes
[11:50] <dooglus> https://launchpad.net/distros/ubuntu/+sources/evolution/+bug/3001 is an OOPS.  it doesn't tell me to report it.  should I ignore it?
[11:50] <Ubugtu> malone bug 3001 in evolution "evolution crashed at click "send" email" [Normal,Unconfirmed]  
[11:50] <daf> mpt: bug targets are currently formatted as either "$product (upstream)", "$package ($distribution)" or "$distribution"
[11:51] <daf> mpt: what would replace "upstream" in the first case?
[11:51] <mpt> dooglus, it's a Not Found
[11:51] <mpt> dooglus, because of the way the database works, some numbers don't have bugs
[11:51] <carlos> Kinnison: hi, around?
[11:51] <Kinnison> carlos: hi
[11:52] <carlos> Kinnison: I'm working on the tests
[11:52] <dooglus> mpt: it says 'OOPS' in big red letters...  and it's link from https://launchpad.net/products/malone/+bug/3002
[11:52] <Ubugtu> malone bug 3002 in malone "malone mess comments formating" [Normal,Confirmed]  
[11:52] <mpt> daf, nothing at all
[11:52] <carlos> Kinnison: I asked pitti for a pmount build with the translation tarball 
[11:52] <dooglus> (the other link on that page is also a not found)
[11:52] <carlos> Kinnison: how could I do to validate pitti's gpg key?
[11:52] <mpt> dooglus, uh oh
[11:52] <mpt> stuuuuuuuuuuuuuuuuuub
[11:53] <daf> mpt: fair enough :)
[11:53] <Kinnison> carlos: I'm not sure quite what you mean
[11:53] <dooglus> mpt: looks like he's written /sources/ instead of /source/
[11:53] <jamesh> dooglus: the URLs got changed slightly since then :(
[11:53] <carlos> Kinnison: when I do the upload, I get:
[11:53] <carlos> raise UploadError("GPG verification of %s failed: %s" % (filename,
[11:53] <carlos>     UploadError: GPG verification of pmount_0.9.7-2ubuntu2_amd64.changes failed: Invocation of op_verify: No data: GPGME (7,58)
[11:53] <mpt> dooglus, ah, that's why the description has been changed, to update the URLs
[11:53] <dooglus> the two URLs appear in the initial report, and in the 1st comment.  the initial report has correct URLs and the 1st comment has 404s
[11:53] <daf> dooglus: did it give you an OOPS code?
[11:54] <Kinnison> carlos: Is this in the test harness?
[11:54] <dooglus> OOPS-40D348 and OOPS-40D350
[11:54] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/40D348
[11:54] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/40D350
[11:54] <mpt> dooglus, the 1st comment is an earlier version of the description (that will be much clearer when https://wiki.launchpad.canonical.com/BugHistory is implemented)
[11:54] <carlos> Kinnison: so I suppose I need to add pitti's public gpg key
[11:54] <daf> oh
[11:54] <Kinnison> carlos:  you need to add the relevant key to the gpgkey sampledata
[11:54] <carlos> Kinnison:  distroreleasequeue.txt
[11:54] <Kinnison> carlos: also you need to add his key to the zeca test dirs
[11:54] <daf> mpt: we should probably make +sources redirect to +source
[11:54] <Kinnison> zeca is our keyserver which gets fired up during the test suite
[11:55] <dooglus> there's no time stamp on the initial report?  only on the comments?
[11:55] <daf> dooglus: there is, and it's displayed on the left hand side
[11:55] <jamesh> daf: ideally +sources/whatever/goes/here to +source/whatever/goes/here too
[11:55] <dooglus> First reported:
[11:55] <dooglus> 2005-10-09, you mean?
[11:55] <jamesh> I don't know if our current nav stuff does that
[11:55] <daf> jamesh: right, that's what I'm thinking
[11:55] <carlos> ok, I think I know how to do the first step. For the second step... I suppose we have something like the standard .gnupg directory in any place of the source tree, right?
[11:56] <mpt> jamesh, no, *ideally* +sources/whatever/goes/here is the actual URL ;-)
[11:56] <dooglus> daf: that's just a date; comments have times and initial reports have just dates?
[11:56] <daf> dooglus: that's just a matter of formatting
[11:56] <jamesh> mpt: ideally we want one URL for each unique resource
[11:56] <daf> dooglus: I can see why you'd want to see the time also
[11:57] <jamesh> mpt: nicer for caching (if we ever handle that right0
[11:57] <Kinnison> carlos: The first step simply involves you adding the relevant row to the gpgkey sample data, should be fairly easy, just use gpg --verify <changesfile> to get the keyid of the key, then gpg --keyserver keyserver.ubuntu.com --recv-keys <keyid> to fetch it locally and gpg --fingerprint <keyid> to get its fingerprint
[11:57] <dooglus> daf: mostly just for consistancy.  an initial report is much like a comment really - it has a subject, date, time, author - why not format it the same way?  I wouldn't expect to have to look in the left hand side for that information.
[11:57] <Kinnison> carlos: In order to add it to zeca, look in lib/canonical/zeca/ftests/keys/
[11:57] <carlos> ok
[11:57] <Kinnison> carlos: For example, 0x20687895.get in there is what zeca returns for my gpg key
[11:58] <daf> dooglus: the initial report is included in the comment flow, but only sometimes (yes, I know)
[11:58] <mpt> jamesh, then you get to the problem of defining a unique resource ... for example the bug pages for two tasks are 99% the same
[11:58] <dooglus> daf: I always thought the left hand side was there to make the interesting middle third of the screen too narrow to fit useful logfile output into for laptop users.
[11:58] <Kinnison> carlos: If you need more help on this, cprov wrote zeca and may be of more use
[11:58] <daf> dooglus: haha
[11:58] <carlos> Kinnison: ok, thanks
[11:58] <carlos> I think that's enough
[11:58] <mpt> dooglus, I like your attitude
[11:58] <daf> dooglus: it's true that the left and right hand columns tend to be something of a blind spot
[11:58] <jamesh> mpt: but they're not the same
[11:58] <daf> mpt: I think we should stop using the initial report as a description
[11:59] <jamesh> carlos: you need symlinks for the subkey key IDs in zeca's keys directory
[11:59] <daf> mpt: it means you get two slightly-differently-worded things all too often
[11:59] <mpt> daf, what should we use as the description instead?
[11:59] <dooglus> daf: "latest bugs in malone"?  I ask you.  If that isn't someone just trying to waste the space that should be used for the bug we're currently dealing with...
[11:59] <carlos> jamesh: yeah, I saw it, thanks
[11:59] <daf> mpt: leave it blank to start with
[11:59] <dooglus> daf: what's the chance that the latest bug is of any interest to me?
[11:59] <daf> mpt: people can either add a proper description
[11:59] <daf> mpt: or let the comments speak for themselves
[11:59] <mpt> whoa, you're actually serious
[11:59] <jamesh> carlos: the PGP signature blob includes the key id of the signing key, which is not always the primary subkey
[12:00] <mpt> that's ... interesting
[12:00] <daf> mpt: and not make a half-arsed attempt at turning the intial report into a description
[12:00] <dooglus> can I maybe switch these side boxes off?
[12:00] <daf> mpt: it's weird when you edit a description bases on the initial report, and leave in first-person stuff
[12:00] <daf> mpt: it implies the reporter said things they didn't
[12:01] <daf> mpt: we can't stop reporters saying things in first person
[12:01] <carlos> jamesh: so I should use the primary one on zeca
[12:01] <daf> mpt: and we can't stop people who edit descriptions from doing a half-arsed job of it
[12:01] <mpt> dooglus, try a user style sheet with  #portal-column-one, #portal-column-two {display: none;}
[12:01] <Kinnison> jamesh: Surely he only needs the symlinks if he's trying to decrypt?
[12:01] <daf> mpt: </rant> :)
[12:02] <cprov> morning guys
[12:02] <mpt> hi cprov 
[12:02] <dooglus> mpt: I'd like to still see a list of duplicates of this bug though, for instance.  I just don't want to dedicate a whole 30% of my screen to it :)
[12:02] <cprov> mpt: hi mpt 
[12:02] <SteveA> jamesh: would you edit the latest daily oops summary to point at mpt's stylesheet please?
[12:02] <daf> mpt: (I've seen a couple of good examples -- I'll forward them to you if I find htem)
[12:02] <Seveas> Is the format of OOPS ids likely to change? It is now \d+[A-Z] \d+ (I assume day-of-year, year-since-2006, oops-id) 
[12:02] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/id
[12:02] <Seveas> Ubugtu, shaddap
[12:03] <mpt> daf, if the description looks like it's all the reporter's work, that's a presentation problem IMO
[12:03] <SteveA> Seveas: day since jan 1 2006, application-server-letter-id, oops-id
[12:03] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/id
[12:03] <daf> mpt: how can we stop them from being misleading, though?
[12:03] <Kinnison> Ubugtu: learn to recognise what a real oops id looks like, or give up talking about them
[12:03] <SteveA> Seveas: so, always numbers, letter, numbers.  it might be numbers, letters, numbers in the future
[12:03] <daf> Kinnison: my oops linkification code has the same bug :)
[12:04] <Seveas> Kinnison, that's what I'm trying to do, the regex is has now is clearly suboptimal :)
[12:04] <Kinnison> daf: Clearly you also suck :-)
[12:04] <Kinnison> Seveas: coolio
[12:04] <daf> some older oops IDs are only letters-numbers
[12:04] <daf> Kinnison: clearly :)
[12:04] <SteveA> Kinnison: i asked for ubugtu to give urls for oopses to help out launchpad developers, despite it being not directly useful for Seveas or other people on this channel.
[12:04] <carlos> hmmm
[12:04] <SteveA> Kinnison: Seveas agreed to do it, and he's been improving it as we go.
[12:04] <Seveas> @reload Bugtracker
[12:04] <daf> Seveas: I'm planning to use \d*[abcd] \d+
[12:04] <carlos> pitti didn't sign the .changes file
[12:04] <Kinnison> ubugtu is very helpful
[12:05] <Kinnison> daf: that won't work
[12:05] <carlos> grr, I didn't see it
[12:05] <mpt> SteveA, I'd like to change the way displayWidth="whatever" is handled in ZCML -- is that an upstream Zope problem?
[12:05] <daf> Kinnison: why not?
[12:05] <carlos> cprov: so, my needs just changed
[12:05] <Kinnison> daf: Consider that the ftpmaster stuff uses U
[12:05] <Kinnison> daf: and staging uses S
[12:05] <daf> good point
[12:05] <carlos> cprov: I think it's enough if I use one of the testing keys we already have to sign that .changes file
[12:05] <Seveas> I now use OOPS-\d*[a-z] \d+
[12:06] <jamesh> SteveA: done
[12:06] <Seveas> that should keep most false triggers out
[12:06] <Kinnison> carlos: if you want me to re-sign them, mail me the .dsc and .changes and I'll do it
[12:06] <carlos> cprov: like Foo Bar
[12:06] <Kinnison> carlos: my key is already in the test set
[12:06] <jamesh> nice red headings
[12:06] <cprov> carlos: good, it'd be easier for you
[12:06] <dooglus> Seveas: case independant?
[12:06] <carlos> Kinnison: ok, thanks
[12:06] <SteveA> thanks jamesh 
[12:07] <Seveas> yeah, there's no way to do without since I can only control the regex, not the options
[12:07] <SteveA> daf: oops ids will grow more than [abcd]  in the future
[12:07] <dooglus> OOPS-40A385
[12:07] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/40A385
[12:07] <SteveA> daf: and may have a few letters, not just one
[12:07] <SteveA> daf: and may be reported in upper or lower case
[12:07] <carlos> Kinnison: sent
[12:08] <daf> SteveA: it's already case-insensitive
[12:08] <daf> SteveA: I'll extend the regex now
[12:08] <SteveA> ok, thank you
[12:08] <daf> SteveA: and add a test case for the false positives we're getting
[12:10] <SteveA> mpt: on the oops report, i think we don't need a lot of the bullet-points in the body of the report.
[12:10] <daf> dooglus: bug 30959
[12:10] <Ubugtu> malone bug 30959 in launchpad "+sources/something should redirect to +source/somethingo" [Normal,Unconfirmed]  http://launchpad.net/bugs/30959
[12:12] <daf> mpt: nag: update LaunchpadGoodlification for February
[12:12] <niemeyer> Heyho!
[12:12] <dooglus> daf: it's not right that I can edit the description and it looks like you did it...
[12:13] <mpt> daf, it's not the middle of the month yet
[12:13] <daf> dooglus: agreed
[12:13] <daf> mpt: ok, it doesn't say when in the month you do it
[12:13] <mpt> daf, iirc the Google Dance happens around the beginning of the month, so I try to avoid that
[12:13] <dooglus> daf: is there any way to tell the difference between an initial report which has since been edited and the 1st comment to an un-edited report?
[12:13] <daf> ah, I see
[12:14] <daf> dooglus: if the initial report has been edited, the original version appears underneath
[12:14] <Kinnison> carlos: replied
[12:14] <dooglus> daf: yes, but it looks exactly like a comment, doesn't it?
[12:14] <daf> dooglus: the edited description is formatted slightly differently
[12:14] <mpt> dooglus, as I said, that will be fixed once https://wiki.launchpad.canonical.com/BugHistory is implemented.
[12:14] <dooglus> oh, ok
[12:15] <carlos> Kinnison: cool, thanks!
[12:15] <Kinnison> carlos: no problem
[12:17] <dooglus> daf: how is it formatted differently?  ( https://launchpad.net/products/launchpad/+bug/30959 )
[12:17] <Ubugtu> malone bug 30959 in launchpad "+sources/something should redirect to +source/something" [Normal,Unconfirmed]  
[12:18] <daf> dooglus: the first instance is the description
[12:18] <daf> dooglus: the second is my initial report
[12:18] <daf> dooglus: the third is your comment
[12:18] <daf> dooglus: confusing, isn't it?
[12:18] <daf> the description defaults to the initial report
[12:18] <dooglus> daf: can you see any difference in formatting between the initial report and the comment?
[12:18] <daf> no
[12:18] <daf> they are formatted exactly the same
[12:19] <dooglus> daf: and can you see my first comment?
[12:19] <mpt> In the time you two took to have this conversation, daf could have implemented 5% of BugHistory
[12:19] <dooglus> daf: (comment 2) is the 2nd comment I added
[12:19] <daf> but the initial report and the comment are formatted differently to the description
[12:19] <daf> no, I can't see the first comment
[12:19] <dooglus> daf: I think it was silently deleted
[12:19] <dooglus> daf: possibly because it was an exact copy of the edited description
[12:21] <daf> carlos: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-08/D409
[12:21] <daf> carlos: do we have an open bug on this?
[12:22] <carlos> daf: yes
[12:22] <carlos> daf: and it's waiting for a production update
[12:22] <carlos> daf: https://launchpad.net/malone/bugs/3176
[12:22] <daf> what's the bug #?
[12:22] <Ubugtu> malone bug 3176 in launchpad "Error when trying to save AbiWord pt-BR translations" [Normal,Fix committed]  
[12:22] <daf> thanks
[12:24] <daf> carlos: https://chinstrap.ubuntu.com/~jamesh/oops.cgi/2006-02-09/B311
[12:27] <carlos> daf: that submit does not come from one of our forms
[12:27] <daf> are you sure?
[12:27] <carlos> SUBMIT	Save & Continue
[12:27] <daf> HTTP_REFERERhttps://launchpad.net/distros/ubuntu/dapper/+source/knetworkconf/+pots/knetworkconfmodule/sv/+translate
[12:28] <carlos> I changed it long ago...
[12:28] <carlos> oh, I didn't see the REFERER...
[12:28] <daf> hmm, what does it say now?
[12:28] <carlos> submit_translations
[12:29] <daf> ?
[12:29] <carlos> anyway... I'm not sure now if that change was done before my merge last week of PoMsgSetPage 
[12:29] <daf> oh, I see
[12:29] <daf> the input name, not hte value
[12:30] <carlos> daf: right, sorry
[12:31] <carlos> daf: anyway, the update that stuart is going to install on production changes a lot the translation form and adds more tests too
[12:31] <daf> cool
[12:31] <carlos> daf: so I'm sure that if that's a bug, it's fixed 
[12:31] <SteveA> jamesh: one thing i would find useful on the OOPS summary is the HTTP method for the URLs.  so, maybe GET https://launchpad.net/foo/bar
[12:32] <SteveA> if the header is in a <span> then mpt can tweak the colour or size
[12:32] <daf> REQUEST_METHOD GET
[12:32] <daf> what's the "-C"?
[12:32] <SteveA> daf: it is a bug in zope
[12:32] <daf> ah :)
[12:32] <SteveA> in fact, in python
[12:32] <SteveA> to do with how the cgi lib picks up environment variables
[12:33] <SteveA> the -C is ultimately from the command line
[12:33] <daf> carlos: #3176 seems to have about a million duplicates
[12:33] <carlos> daf: yeah
[12:33] <carlos> that's why I requested a cherry pick
[12:33] <carlos> instead of wait until next Tuesday
[12:33] <daf> good idea :)
[12:34] <carlos> daf: the problem is that I don't understand how is that we got that error now if last Tuesday update didn't have any patch from me...
[12:34] <daf> strange
[12:44] <carlos> cprov, Kinnison: I'm getting another error: pmount_0.9.7-2ubuntu2_amd64.deb: Unknown architecture: 'amd64'.
[12:45] <Kinnison> Meeting in 15 minutes.
[12:45] <Kinnison> carlos: Hmm
[12:45] <carlos> where should I add amd64 as a valid architecture?
[12:45] <jamesh> That Dino Solon A. Agcambot guy seems to make a habbit of reporting the same bug 10 times slightly differently each time he does so
[12:45] <Ubugtu> malone bug 10 in malone "It says "displaying matching bugs 1 to 8 of 8", but there is 9" [Normal,Rejected]  http://launchpad.net/bugs/10
[12:45] <Kinnison> carlos:  you need to add the relevant distroarchrelease to the sampledata
[12:45] <carlos> ok
[12:45] <cprov> carlos: yes, add a new distroarchrelease
[12:46] <mpt> We are so totally unprepared for spam
[12:48] <carlos> Kinnison: hmmm, the build is for dapper and we don't have it either with our sampledata...
[12:48] <carlos> Kinnison: If I change the files by hand to be i386 and hoary, would you sign them again? will that work?
[12:50] <Kinnison> carlos: I can't guarantee it won't break horribly. better to add dapper and dapper/amd64 to the sampledata
[12:50] <carlos> ok
[12:50] <Kinnison> carlos: or even better, add them within the test only
[12:50] <daf> Kinnison++
[12:55] <mpt> meeting in five minutes?
[12:56] <daf> yes
[12:58] <jbailey> heehee.  you said "meeting"
[12:58] <jamesh> jeff has come to mock us
[12:58] <jbailey> jamesh: Hey, only the best for the best ;)
[12:59] <SteveA> MEETING TIME!
[12:59] <SteveA> welcome to the launchpad development meeting
[12:59] <SteveA> who is here today?
[12:59] <daf> me
[12:59] <mpt> here
[01:00] <salgado> me
[01:00] <ddaa> here
[01:00] <stub> here
[01:00] <jamesh> me
[01:00] <BjornT> me
[01:00] <cprov> me
[01:00] <Kinnison> me
[01:00] <jbailey> me
[01:00] <SteveA> jbailey: welcome
[01:00] <SteveA> iwj: welcome
[01:01] <SteveA> lifeless: here?
[01:01] <SteveA> kiko-zzz: ?
[01:01] <matsubara> here
[01:01] <gneuman> here
[01:01] <iwj> Hi.
[01:01] <carlos> here
[01:01] <SteveA> hi bradb 
[01:01] <spiv> here
[01:01] <SteveA> let's go
[01:01] <bradb> hi, here
[01:01] <SteveA> == Agenda ==
[01:01] <ddaa> 7 here, 7 me, 2 hi
[01:01] <SteveA>  * Roll call
[01:01] <SteveA>  * Agenda
[01:01] <SteveA>  * Next meeting
[01:01] <SteveA>  * Activity reports
[01:01] <SteveA>  * Items from last meeting
[01:01] <SteveA>  * Launchpad oops milestone report
[01:01] <SteveA>  * Production / staging (stub)
[01:01] <SteveA>  * Any details about the developer summit in May? (AndrewBennetts)
[01:01] <SteveA>  * Stopping tests after the first error. (AndrewBennetts)
[01:01] <SteveA>  * Emphasizing support requests rather than bugs on Launchpad (JeffBailey)
[01:01] <SteveA>  * Ian Jackson's upstream bugs use-case. (SteveAlexander)
[01:01] <SteveA>  * Keep, Bag, Change
[01:01] <SteveA>  * Three sentences
[01:02] <SteveA> 
[01:02] <SteveA> lifeless sends apologies
[01:02] <SteveA> next meeting -- same time next week?
[01:02] <SteveA> any objections?
[01:02] <SteveA> 4
[01:02] <SteveA> 3
[01:02] <SteveA> 2
[01:02] <SteveA> 1
[01:02] <jbailey> swap me and Ian please?
[01:02] <jbailey> (If ian's okay)
[01:02] <iwj> NP.
[01:02] <jbailey> I'm still waking up and writing.
[01:02] <SteveA> hmm, Kinnison would you replace the channel topic please?
[01:03] <SteveA> it seems to have gone missing
[01:03] <SteveA> jbailey: ok
[01:03] <SteveA>  * Activity reports
[01:03] <stub> Up to date
[01:03] <mpt> up to date
[01:03] <matsubara> up to date
[01:03] <Kinnison> Up to date
[01:03] <BjornT> up to date
[01:03] <cprov> up to date
[01:03] <gneuman> up  to date
[01:03] <ddaa> up to date
[01:03] <daf> up to date
[01:03] <niemeyer> up to date
[01:03] <spiv> up to date (well, it's in the mail...)
[01:04] <carlos> I'm three days behind
[01:04] <salgado> I missed some days last week, but I'm back on track since monday
[01:04] <jamesh> not up to date
[01:04] <bradb> I'm sending two right now, which'll put me up to date
[01:04] <daf> kiko-zzz: wake up
[01:04] <SteveA> cprov: would you call kiko to see if he is coming?
[01:04] <daf> jblack: ping
[01:05] <SteveA> daf: jblack is at a conference, i think
[01:05] <salgado> daf, he's coming
[01:05] <cprov> SteveA: yes, will do
[01:05] <SteveA> not a bad show overall on activity reports.
[01:05] <kiko-zzz> ahoy
[01:05] <SteveA> thanks launchpad developers!
[01:05] <SteveA>  * Items from last meeting
[01:05] <kiko> I am up to date
[01:05] <SteveA> : Kiko to talk to James (?) about dependency packages
[01:05] <kiko> sorry for being late, was assisting a kid who was run over by a car
[01:05] <SteveA> wow
[01:06] <SteveA> tell us about it later, maybe
[01:06] <SteveA> Dafydd to try and make old meeting actions distinct from new ones in meeting summaries
[01:06] <kiko> I didn't do that, but I can
[01:06] <SteveA> kiko: also, there has been mail traffic with mdz and jblack on the subject
[01:06] <SteveA> daf: ?
[01:06] <daf> SteveA: I tried that with last week's summary
[01:06] <SteveA> Steve to work out a doc about how we act on oops reports
[01:06] <daf> SteveA: what do you think?
[01:06] <kiko> I'm aware
[01:06] <mdz> SteveA: fwiw, I am not going to be able to follow up on that
[01:06] <mdz> launchpad-dependencies is in need of delegation
[01:06] <SteveA> daf: i'll tell you later, but the MeetingAgenda page is good and up to date, so that you for that
[01:07] <SteveA> mdz: okay, thanks. noted
[01:07] <niemeyer> SteveA: That's cool
[01:07] <niemeyer> (the doc about oops)
[01:07] <SteveA> daf and matsubara have been working on the oops report process.  jamesh has been supporting with better report summaries
[01:07] <SteveA> daf: please point people at the wiki page that everyone should read, to know how things work
[01:07] <kiko> I have done some work on that too
[01:07] <SteveA> Steve to check how asterisk stuff is going 
[01:07] <daf> https://wiki.launchpad.canonical.com/LaunchpadBugTriage
[01:07] <matsubara> https://wiki.launchpad.canonical.com/LaunchpadBugTriage
[01:08] <iwj> (I've just replied to Bjorn on lp-users.)
[01:08] <SteveA> kiko did some work on that too, analyzing some top timeouts and OOPSes
[01:08] <SteveA> thanks kiko
[01:09] <kiko> I have spent some time explaining the process of debugging errors and timeouts using the oops logs to matsubara
[01:09] <SteveA> on asterisk, latest news is that it should happen shortly after the DC move (that is on saturday), but is waiting on getting a quote from some supplier
[01:09] <kiko> he'll be writing tests and patches for some today
[01:09] <SteveA> kiko: can we get some of these explanations added to the wiki?
[01:09] <SteveA> James B to help Daniel diagnose his bzr problem
[01:09] <Kinnison> We talked
[01:09] <SteveA> Jordi to send spreadsheet to Steve
[01:09] <Kinnison> and decided that it may be an already fixed problem because I was using an old bzr
[01:09] <SteveA> jordi: ?
[01:10] <SteveA> with jordi's answer (answer when you read this), that concludes items from last week's meeting
[01:10] <kiko> SteveA, it was kinda haphazard but I could try. the patch I sent you is essential, though.
[01:10] <SteveA>  * Launchpad oops milestone report
[01:10] <SteveA> kiko: okay, noted
[01:10] <SteveA> daf, matsubara
[01:11] <matsubara> SteveA: I've been working on finding/reporting all the top 20 hardtimeouts and programming errors. 
[01:11] <daf> ok, matsubara and I have been assigning OOPS bugs to the new "oopS" milestone
[01:11] <daf> for now, we're only considering hard timeouts and programming errors
[01:11] <SteveA> daf: can we see them in your scrape.py output?
[01:11] <matsubara> I'll take care of some of the programming errors in this afternoon.
[01:11] <carlos> SteveA: jordi told me that he's a bit busy at the other job he has so I'm not sure if he will be able to attend this meeting. Let me call him
[01:11] <daf> I've set up a new page to keep track of these bugs
[01:12] <daf> https://chinstrap.warthogs.hbd.com/~daf/bugs/oops.py
[01:12] <SteveA> carlos: it's okay
[01:12] <SteveA> carlos: we'll catch up with jordi later
[01:12] <carlos> ok
[01:12] <daf> these bugs will also be included in the weeky Bug Report Report
[01:12] <SteveA> daf: do we expect to see more bugs added to this milestone?
[01:13] <daf> absolutely
[01:13] <daf> we're just getting started
[01:13] <jamesh> the daily oops report summaries should categorise the timeouts better now (by replacing string and integer constants in the exception value), which might affect what the top 20 timeouts are for a day
[01:13] <SteveA> ok
[01:13] <SteveA> jamesh: great
[01:13] <daf> jamesh: that's excellent news
[01:13] <daf> jamesh: thank you
[01:13] <jamesh> the web reports linked in the last two mailings have been updated
[01:13] <SteveA> as a general rule, i think we should prioritize bugs on these oops milestones higher than other bugs, or new features
[01:14] <SteveA> what do you think kiko ?
[01:14] <kiko> that sounds reasonable
[01:14] <kiko> we should really try to get crashes down to zero
[01:14] <daf> that's the aim of the game
[01:14] <SteveA> okay.  we'll have a more full OOPS session in next week's meeting, when daf and matsubara have done more work on the bugs to be filed, and fixing some of them
[01:15] <SteveA> meanwhile, we'll follow up on urgent OOPS fixing on the launchpad mailing list
[01:15] <SteveA> any further comments?
[01:15] <SteveA> (we have a full agenda today, so i want to keep moving along...)
[01:15] <SteveA>  * Production / staging (stub)
[01:15] <stub> Might want to ignore tomorrows oops report - the update from earlier today will fix a number of the issues
[01:16] <stub> Staging is happily having daily code updates. I'll restart the regular database syncs too if Daniel and Celso no longer need it.
[01:16] <stub> Production systems were all updated to HEAD today after I discovered the production branch we were using did not pass its test suite.
[01:16] <stub> Elmo has announced some downtime on the weekend for data centre work - see the emails in the launchpad and launchpad-users mailing lists for details.
[01:16] <stub> mizuho (the Librarian server) has successfully undergone updates, and I believe Znarl and elmo are now more confident about the hardware.
[01:16] <stub> We are no longer using prat (temporary gina) and macaroni (old librarian) - I've emailed rt@ ensuring elmo and Znarl are aware.
[01:16] <stub> About half of our servers have the launchpad-dependancies package installed. I've emailed rt@ requesting installation on the others I'm aware of.
[01:16] <carlos> stub: oh, we had already the production update with HEAD?
[01:17] <stub> carlos: yes. About two hours ago I think.
[01:17] <carlos> daf: that's the explanation for https://launchpad.net/products/rosetta/+bug/30952
[01:17] <Ubugtu> malone bug 30952 in rosetta "An OOPS in launchpad while trying to translate knetworkconf. OOPS-40B311 is the reference name." [Normal,Fix committed]  
[01:17] <SteveA> meeting action: stevea to find someone to maintain the launchpad-dependences packages
[01:17] <carlos> daf: the user got the form with the old code and the submit was handled by the new one
[01:18] <daf> carlos: aha -- Fix Released?
[01:18] <carlos> daf: no, Rejected ;-)
[01:18] <SteveA> daf, carlos: please focus on the meeting
[01:18] <carlos> sorry
[01:18] <SteveA>  * Any details about the developer summit in May? (AndrewBennetts)
[01:18] <kiko> SteveA and I are going to do some planning on that
[01:18] <kiko> I have some ideas and so does he
[01:18] <spiv> Right.  I'm just curious to know if there's any news on that front.
[01:19] <SteveA> you mean may, spiv, not march, right?
[01:19] <kiko> steve will spend the week before the sprint in brazil
[01:19] <spiv> SteveA: Right.
[01:19] <carlos> Should we start getting our plane tickets?
[01:19] <kiko> oh
[01:19] <spiv> The whole-compnay one.
[01:19] <kiko> may?
[01:19] <SteveA> things about may are still being discussed by the management team and others
[01:19] <kiko> I see.
[01:19] <SteveA> no news there yet
[01:19] <spiv> I seem to recall May was the proposed timeframe at UBZ.
[01:19] <SteveA> carlos: for march, please do get your plane tickets
[01:19] <SteveA> meeting action: steve to set up wiki page for march meeting
[01:19] <carlos> ok
[01:20] <SteveA>  * Stopping tests after the first error. (AndrewBennetts)
[01:20] <spiv> You can now do "python test.py --stop-on-first-failure ...".  It stops the test suite as soon as a test fails.
[01:20] <spiv> This can obviously be much faster than a full run, depending on how broken your branch is ;)
[01:20] <stub> We have a march meeting?
[01:20] <spiv> Possibly we should make PQM use this, to give up on bad merges faster, but PQM seems faster these days anyway.
[01:20] <SteveA> stub: you're not invited :-p
[01:20] <stub> :-)
[01:20] <SteveA> although, if you want to come, talk to me later
[01:20] <spiv> That's all.  Enjoy! :)
[01:20] <stub> Unless you are visiting sunny Bangkok
[01:20] <jbailey> spiv: In my experience, it's handy to know what else is failing on projects for automated test builds if it's quick enough.
[01:20] <kiko> spiv, I wouldn't do that. it's useful to have PQM help
[01:21] <kiko> as a full testing service ;)
[01:21] <spiv> jbailey, kiko: I agree.
[01:21] <SteveA> although a grepper for pqm debug output would help
[01:21] <spiv> Although PQM can take commands like "debug"
[01:21] <SteveA> to quickly view the first failure
[01:21] <SteveA> btw, i need to talk with lifeless about re-enabling a lot of tests that aren't running with pqm at pressent
[01:21] <spiv> So potentially a "debug" merge attempt would run the full suite anyway.  But at the moment, I don't think there's really enough of an issue.
[01:21] <Kinnison> spiv: will this stop mid-doctest?
[01:21] <SteveA> this will slow down pqm runs compared to where they are now
[01:21] <SteveA> but will give us better QA for the wider launchpad systems
[01:21] <ddaa> bah, first failure is often not the most interesting one because tests are ordered essentially at random (lexically I think)
[01:22] <spiv> Kinnison: Hmm.  I don't think so, but I'd have to check.
[01:22] <SteveA> spiv:  is --stop-on-first-failure documented on the developer wiki pages?
[01:22] <SteveA> spiv: please talk with daf about that
[01:22] <SteveA> i want to move on
[01:22] <spiv> meeting action: spiv to document --stop-on-first-failure on the wiki, talk with daf
[01:22] <Kinnison> spiv: also, if you're taking suggestions -- it'd be really nice to be able to see where in a doctest you are, E.g. by getting it to spew what it's running in some specific --debug-doctest mode or something
[01:22] <SteveA>  * Ian Jackson's upstream bugs use-case. (SteveAlexander)
[01:23] <SteveA> quick poll... who is subscribed to launchpad-users here?
[01:23] <SteveA> me
[01:23] <spiv> me
[01:23] <Kinnison> me
[01:23] <ddaa> me
[01:23] <BjornT> me
[01:23] <carlos> me
[01:23] <salgado> me
[01:23] <spiv> Kinnison: interesting idea.  File a bug :)
[01:23] <matsubara> me
[01:23] <kiko> me
[01:23] <Kinnison> spiv: against products/launchpad or somewhere more specific?
[01:23] <mpt> me
[01:24] <daf> me
[01:24] <spiv> Kinnison: products/launchpad I guess
[01:24] <mpt> iwj, this is your five minutes of fame
[01:24] <Kinnison> spiv: okay
[01:24] <iwj> mpt: :-).
[01:24] <bradb> me
[01:24] <ddaa> You are all different people!
[01:24] <daf> I'm not
[01:24] <sivang> me
[01:24] <lucas> me
[01:24] <stub> me
[01:24] <niemeyer> I'm not
[01:24] <gneuman> n
[01:24] <SteveA> okay, cool
[01:25] <ddaa> daf: so are you, or are you not subscribed to the mailing list?
[01:25] <SteveA> so, ian jackson (iwj) sent a detailed email to launchpad-users
[01:25] <daf> ddaa: I'm not a different person
[01:25] <SteveA> describing a particular way that he would like to use malone in launchpad
[01:25] <SteveA> today or yesterday, bjorn responded, and there has been a discussion
[01:25] <Kinnison> spiv: bug 30964
[01:25] <Ubugtu> malone bug 30964 in launchpad "doctest debug output would be handy" [Normal,Unconfirmed]  http://launchpad.net/bugs/30964
[01:26] <SteveA> i'd like to encourage people to use launchpad-users.  launchpad developers do read it and respond on the list.
[01:26] <SteveA> iwj: are you happy with how the discussion is progressing?
[01:26] <iwj> stevea: You're preaching to the choir, I think.
[01:26] <iwj> Yes, I think so.
[01:26] <SteveA> we will now join our voices in psalm number 65536
[01:27] <SteveA> okay
[01:27] <SteveA>  * Emphasizing support requests rather than bugs on Launchpad (JeffBailey)
[01:27] <jbailey> Support Tracker vs. Bugs
[01:27] <jbailey> [01:27] <jbailey> .
[01:27] <jbailey> Over the course of a conversation with Steve and a few other folks, the support tracker has shown up.  The question is one of dealing with users and what we expect.  The problem as I see it is that we're conditioned to be succinct and offer solutions in bugs reports.  ("The best bug report contains a patch" type of thing.)
[01:27] <jbailey> .
[01:27] <jbailey> In a support request, I imagine that people are more free to describe what they're trying for, what they did without worrying about the underlying system.  There are then two resolutions to a support request, which can happen simultaniously.  1) A quick fix workaround can be offered ("The data you want is FOO, or can also be found at ...") 2) It can spawn a number of bugs that actually talk about the system in terms that the
[01:27] <jbailey>  programmers think in - tweaks to SQL tables, etc.
[01:27] <jbailey> .
[01:27] <jbailey> The last point to this is that this lets us start dogfooding (Mmmm...  vegan dogfood /me makes homer noises.) the support tracker.

[01:28] <mpt> I agree with what ddaa's about to say
[01:28] <bradb> me too, I think
[01:29] <kiko> I think jbailey's approach is spot-on
[01:29] <daf> jbailey++
[01:29] <mpt> ... that we can't reasonably be expected to use the support tracker while it doesn't know how to e-mail us
[01:29] <ddaa> mpt: don't eat babies
[01:29] <mpt> Apart from that, I like the idea
[01:29] <sivang> what is dogfooding all about anyways? :)
[01:29] <daf> sivang: using the work we produce
[01:29] <mpt> sivang, "eating your own dogfood" = using your own product
[01:29] <jbailey> sivang: ESRism meaning using your own product.
[01:30] <sivang> :-)
[01:30] <sivang> thanks all
[01:30] <ddaa> Last time I used the support tracker I found it unusable for lack of email notifications.
[01:30] <stub> Queries people want me to go over can go through as support requests
[01:30] <sivang> ddaa++
[01:30] <daf> making (a) the support tracker support email and (b) it really easy to file bugs from support requests would make this much more practical, I think
[01:30] <BjornT> email interface for the support tracker is on its way, jamesh any chance of getting my branch reviewed soon?
[01:31] <ddaa> all the other problem we'll surely find can be fixed later, but email notification is a prerequisite for any serious use of the tool.
[01:31] <kiko> BjornT, it's been in review for ages, hasn't it?
[01:31] <kiko> daf, you could plausibly implement b)
[01:31] <jamesh> BjornT: yes.  I'll do it first thing in the morning.  Sorry for the delays
[01:31] <BjornT> kiko: yeah, and i haven't cared enough to nag people enough...
[01:31] <mpt> Since January 3rd
[01:31] <kiko> this is a good discussion then
[01:31] <kiko> lifeless -- a branch has been up for over a month with no review?
[01:31] <sivang> daf: how do you make it easy to file bugs other then bugs against nothing specific from the support tracker? that is, we cannot expect the user to know ...or can we?
[01:32] <SteveA> kiko: lifeless isn't here
[01:32] <kiko> I ask myself how this hasn't come up in a reviewer meeting
[01:32] <SteveA> kiko: use email for that.
[01:32] <kiko> he can see the backlog
[01:32] <SteveA> meeting action: stevea or kiko to mail lifeless about review queue and bjorn's branch
[01:32] <daf> sivang: I mean, if a support request indicates a bug, I want to be able to turn it into a bug
[01:32] <jbailey> kiko: You're clearly an imposter.  The real kiko always tells me that irc isn't good enough ;)
[01:32] <kiko> jbailey, I am emailing him already, but he does read backlog
[01:33] <SteveA> so, to summarize
[01:33] <sivang> daf: ah , yes, that makes much sense.
[01:33] <SteveA> we'll make a few improvements to the issue tracker
[01:33] <SteveA> such as landing bjorn's email branch for it
[01:33] <SteveA> and look at making it easy to file bugs from an issue
[01:34] <SteveA> and then, when those things are in production, look at switching emphasis from bugs to issues for launchpad
[01:34] <kiko> right
[01:34] <SteveA> it will be a fairly high priority for bjorn to get these things landed
[01:34] <jbailey> SteveA: Is there a "not-sooner-than" time, after which I should look again?
[01:34] <daf> good plan
[01:34] <kiko> I imagine we could change the text in the system error and help pages?
[01:34] <SteveA> mpt: please talk about the changes you made to oops page templates
[01:34] <mpt> ok
[01:35] <SteveA> item for next meeting: check progress of issue tracker readyness next meeting
[01:35] <SteveA> jbailey: ^^^^
[01:35] <jbailey> SteveA: Tx.
[01:35] <mpt> I've just put up a branch for review that no longer mentions the possibility of reporting bugs in the error pages
[01:35] <mpt> I think that's the right thing to do now that the Oops summaries are going
[01:35] <mpt> because they're a much more reliable guide as to which crashers are biting people most often
[01:36] <SteveA> mpt: does the text state clearly that because we have an OOPS, that launchpad developers will be made aware of the problem?
[01:36] <kiko> mpt, SteveA: I think people need an outlet to explain their problem and ask for a solution or a workaround
[01:36] <SteveA> mpt: we still have the issue that people are going to be in the middle of some task, which they can't complete.  where do they turn to for support?
[01:36] <kiko> so I agree with that SteveA's driving at
[01:36] <mpt> SteveA: "We've recorded what happened, and we'll fix it as soon as possible."
[01:36] <kiko> no, that's unacceptable.
[01:36] <mpt> kiko, right, that was my one concern
[01:36] <jbailey> mpt: My problem with the older system was that it left me feeling disconnected from the process.  At least with filing a bug, I could feel good that it got looked at.
[01:36] <kiko> however
[01:37] <kiko> we could use the support tracker in lieu of the bug tracker for this
[01:37] <mpt> So, the pages should link to the support tracker
[01:37] <kiko> and it would likely work well
[01:37] <kiko> yes
[01:37] <mpt> all righty, that's easily done
[01:37] <SteveA> ok
[01:37] <SteveA> tvarka!
[01:37] <SteveA>  * Keep, Bag, Change
[01:38] <ddaa> BAG: buildbot, it can't even pass its test suite anymore and what's left cries bloody deprecation all over the place.
[01:38] <SteveA> ...for people to announce their keep bag change items
[01:38] <kiko> ddaa, hadn't you and spiv a plan for this?
[01:38] <SteveA> ddaa: Change: make pqm run buildbot tests!
[01:38] <Kinnison> KEEP: The high level of high quality reports from the disto team about soyuz
[01:39] <ddaa> kiko: spiv has some changes, I asked him to try merging them.
[01:39] <spiv> ddaa, kiko: I have a patch that fixes that, but it's blocked by a PQM/bzr bug
[01:39] <spiv> It's in lifeless' hands.
[01:39] <kiko> spiv, well FFS. 
[01:40] <SteveA> meeting action: spiv to mail lifeless, cc list, about making progress on that
[01:40] <kiko> ah
[01:40] <kiko> CHANGE: spiv to take up lifeless' story branch
[01:40] <SteveA> 30s well and truly up
[01:40] <SteveA>  * Three sentences
[01:40] <spiv> kiko: Yep.
[01:41] <SteveA> go ahead!
[01:41] <kiko> CHANGE: stop PQM accepting empty merges
[01:41] <bradb> kiko++
[01:41] <salgado> DONE: MirrorManagement, cronscript to flag expired memberships, code review, fixed some random bugs
[01:41] <salgado> TODO: finish MirrorManagement, code review, any other urgent trivialities that show up daily
[01:41] <salgado> BLOCKED: No
[01:41] <ddaa> DONE: Bzr/Launcpad doc, RCS imports bzr transition planning
[01:41] <ddaa> TODO: RCS imports transition planning, merge Bzr/Launchpad doc, merge various pending branches
[01:41] <ddaa> BLOCKED: no
[01:41] <matsubara> DONE: lots of bug triage, meetings with stevea and daf, fixed needs info bug not appearing on reports, fixed a bug on bugtracker name field validator.
[01:41] <matsubara> TODO: fix bugs from oops reports, bug triage, paperwork for passport renewal. 
[01:41] <matsubara> BLOCKED: No
[01:41] <stub> DONE: Serialization & deadlock exception handling
[01:41] <stub> TODO: Finalize serialization exception handling, SQLObject boolean fix
[01:41] <stub> BLOCKED: SteveA to look at Z3.2 resource handling
[01:41] <SteveA> lifeless DONE: branch-formats on the final steps to land. Many design discussions w/mpool making 0.8 features concrete.
[01:41] <SteveA> lifeless TODO: PQM updates, production cherrypicking.
[01:41] <SteveA> lifeless BLOCKED: Z3 update [week ???] 
[01:41] <bradb> DONE: Landed bug contact reports. Fixed bug preventing bug contacts with no email (i.e. some teams) from being set. Advanced search design fest; collected user feedback. Moved bug batch list size into a config file.
[01:41] <BjornT> DONE: work on bug watches improvements, and some general discussions about that . looked at a few bugs, and how to fix them.
[01:41] <bradb> TODO: Land the new layout in +assignedbugs too, to make iwj's life somewhat easier. Help perf tweak bug list batches. Implement the advanced search.
[01:41] <BjornT> TODO: continue bug watches improvements. look at the state of support tracker, and see what needs to be done short them.
[01:41] <cprov> DONE: bug fixing and reviewing codeline for Soyuz
[01:41] <bradb> BLOCKED: No.
[01:41] <cprov> TODO: merge Soyuz codeline in RF asap
[01:41] <cprov> BLOCKED: none
[01:41] <BjornT> BLOCKED: no
[01:41] <kiko> DONE: soyuz sprint, reports, oops analysis, etc etc
[01:41] <jamesh> DONE: get oops summary reports working well, SelectResults.__len__ removal, address some bugzilla migration issues, XML-RPC stuff for updating branch status
[01:41] <jamesh> TODO: XML-RPC branch status code, other supermirror related stuff with ddaa
[01:41] <jamesh> BLOCKED: no
[01:41] <mpt> DONE: Malone spec work, a little bugfixing
[01:41] <mpt> TODO: get completed specs approved, page headers, MaloneFrontPages spec
[01:41] <mpt> BLOCKED: Reviews of SimplifyingMalone, FixingProjects, MaloneSearch
[01:41] <gneuman> DONE: adjustments on small bugs
[01:41] <kiko> TODO: more of the same
[01:41] <kiko> BLOCKED: no
[01:42] <Kinnison> DONE: Large amounts of fixes to soyuz, helping cprov with the branch review
[01:42] <sivang> NO CHANGE
[01:42] <gneuman> TODO: more fixes and get new bugs
[01:42] <SteveA> meeting action: steve to mail lifeless about getting pqm to stop accepting empty merges
[01:42] <gneuman> BLOCKED: no
[01:42] <Kinnison> TODO: pocketed uploads and approval process for -updates
[01:42] <Kinnison> BLOCKED: Not currently
[01:42] <cprov> correcting myself: BLOCKED: need a dedicated reviewer for Soyuz codeline (it needs merge ASAP)
[01:42] <carlos> DONE: PoMsgSetPage branch merged (needs a second stage to finish the spec), #29814, added permissions to admins/rosetta experts to edit translations, dapper translation imports
[01:42] <Kinnison> kiko: Could you review that branch for us? You know it well by now
[01:43] <daf> DONE: bug text pages, bug triage, oops handling documentation, oops linkification, meeting summary, bug triage tools
[01:43] <spiv> DONE: Reviews, fix buildbot only to be thwarted by pqm, stop paramiko from causing gc.garbage warnings to spew all over the test suite, merge stop-on-first-failure and gpg-rdf branches, polish SFTP.
[01:43] <daf> TODO: meeting summary, people and users document, land optional-branch-title, finish malone search changes
[01:43] <spiv> TODO: Sort out Twisted-for-sftp-in-rocketfuel.
[01:43] <daf> BLOCKED: no
[01:43] <spiv> BLOCKED: No
[01:43] <mpt> bradb, "advanced search design fest"?
[01:43] <SteveA> DONE: OOPS and Bug process guidence, various management, pair-programmingn with carlos, review of docs and discussion with ddaa, various other...
[01:43] <SteveA> TODO: Zope 3 stuff for stub
[01:43] <SteveA> BLOCKED: no
[01:43] <cprov> Kinnison: kiko: yes, it would be very handy atm
[01:43] <kiko> Kinnison, hmmm, maybe I could be the second pair of eyes. I still think somebody that doesn't know the code should look at it
[01:43] <ddaa> actually, BLOCKED: mysterious librarian failure when merging importd2br branch
[01:43] <Kinnison> kiko: right, perhaps salgado could take a break from MM to look?
[01:43] <carlos> TODO: dapper translation imports, implement POMsgSetPage second stage to finish the spec, finish AJAX implementation for suggestions and #1681
[01:43] <carlos> BLOCKED: no
[01:44] <SteveA> who will review cprov's code?
[01:44] <spiv> ddaa: Hmm, that's probably my department
[01:44] <kiko> Kinnison, I think MM is close. I will talk to him
[01:44] <kiko> SteveA, salgado and I I guess.
[01:44] <kiko>   [trivial]  more suggested changes to analyse-error-reports.py script
[01:44] <kiko> whoever landed that
[01:44] <kiko> landed an empty merge
[01:44] <kiko> PQM doesn't tell me who landed it
[01:44] <bradb> mpt: I made some prototypes (this http://flickr.com/photos/84096161@N00/97201142/ being the final one), like I did for the bug contact reports design fest. I showed them to users, and recorded their feedback.
[01:44] <SteveA> meeting action: spiv to work with ddaa on librarian issue in importd2bzr
[01:44] <jamesh> kiko: looks like I forgot to push my branch first
[01:45] <kiko> jamesh, that's cool, but I want PQM to stop accepting those.
[01:45] <SteveA> okay
[01:45] <SteveA> we're just about done
[01:45] <SteveA> kiko: there's a meeting action for it
[01:45] <mpt> bradb, ok
[01:45] <kiko> whee!
[01:45] <SteveA> MEETING ENDS
[01:45] <sivang> bradb: looks good
[01:45] <SteveA> thanks for being here.
[01:45] <ddaa> jamesh: after he branch status stuff, it would be nice if you could have a look at the importd error reporting system I outlined in email a couple of days ago. But SteveA will tell you in time, the focus might change before you get ther.
[01:45] <spiv> Another on-time meeting.  Thanks Steve!
[01:46] <iwj> I would like to talk to someone about wiring AutomatedTesting into the build infrastructure.  At the moment I need to do requirements capture from the relevant LP and sysadmin types.  Who should I start with ?
[01:46] <mpt> bradb, that prototype is pretty sweet
[01:47] <ddaa> iwj: Kinnison would be a good bet, since he's the buildd mastermind.
[01:47] <bradb> mpt: thanks. it received unanimously positive response from the Ubuntu devs too.
[01:47] <SteveA> iwj: ideally, you'd arrange to meet with Kinnison in person.  But that depends if Kinnison can do this as part of his distro team secondment
[01:47] <SteveA> iwj: otherwise, kiko i think.
[01:47] <SteveA> or maybe cprov-afk 
[01:48] <daf> bradb: looks very nice
[01:48] <kiko> iwj, wouldn't that be a good task for Kinnison as a feature goal as distro guy?
[01:48] <iwj> SteveA: I'll see if I can catch Kinnison.  I think this probably counts as distro team secondment but I'll see what he says.
[01:48] <iwj> Thanks.
[01:48] <Kinnison> iwj: Carlton tonight?
[01:48] <iwj> Ah, hello.
[01:48] <iwj> Sure.
[01:48] <Kinnison> we'll cover it then
[01:48] <Kinnison> :-)
[01:48] <iwj> I'll be there in time to order my dinner :-).
[01:49] <mpt> bradb, have you had time to read through <https://wiki.launchpad.canonical.com/MaloneSearch>?
[01:51] <sivang> iwj: have you not still uploaded the modified mawk to the/a repo?
[01:51] <bradb> mpt: I've only skimmed it, really, because I don't think there'll be time to implement that stuff before, say, London. (Though, at a glance, it looks like some really cool stuff.)
[01:51] <mpt> bradb, the nice thing is it covers pretty much everything *except* the advanced search form :-)
[01:51] <bradb> heh
[01:53] <iwj> sivang: Yes, it should be in dapper by now, and the bug is in the Debian BTS.
[01:54] <iwj> TBH I didn't check that it built but since I just added some files that the build doesn't even touch ... [goes to check] 
[01:55] <iwj> 1.3.3-11ubuntu1, yes.
[01:56] <sivang> cool, I'll glance at it.
[02:02] <sivang> iwj: you're logged as Diziet in -devel ? why two differnt nicks?
[02:04] <kiko> carlos, are your revisions landed then?
[02:04] <carlos> kiko: landed and on production
[02:04] <kiko> great
[02:04] <carlos> well, I still have one review pending
[02:05] <carlos> it's the one for #29814
[02:07] <kiko> daf, look at my last comment in bug 3176, add a test and a fix and rs=kiko :)
[02:07] <Ubugtu> malone bug 3176 in rosetta "Error when trying to save AbiWord pt-BR translations" [Normal,Fix released]  http://launchpad.net/bugs/3176
[02:10] <daf> kiko: bug #30919
[02:10] <Ubugtu> malone bug 30919 in launchpad "The string "OOPS code" should not auto-linkified" [Normal,In progress]  http://launchpad.net/bugs/30919
[02:20] <salgado> bradb, around?
[02:20] <bradb> salgado: yeah
[02:20] <mpt> AttributeError: type object 'SourcePackagePublishing' has no attribute 'selectFirst'
[02:21] <salgado> bradb, what happened with that fix you had for the advanced search on the +bugs page?
[02:21] <salgado> mpt, update the trees inside the sourcecode/ directory of your launchpad tree
[02:22] <bradb> salgado: It's sort of dead. I can't get the darn thing by pqm without disabling a test, which is evil. I can try re-fixing it again today, in the hopes that I'll be able to land it.
[02:24] <mpt> salgado, "bzr merge ../rocketfuel/launchpad/sourcecode/" says "Nothing to do."
[02:25] <daf> rsync -a ../rocketfuel/launchpad/sourcecode sourcecode
[02:26] <mpt> daf, not rsync -a --delete ?
[02:26] <kiko> mpt, link your sourcecode trees into prebuilt.
[02:27] <kiko> that makes this problem go away for good
[02:27] <kiko> sh utilities/link-external-sourcecode.sh ~/rocketfuel-built/launchpad
[02:27] <daf> mpt: sure, --delete
[02:27] <daf> I just cp -al ../rf-built/launchpad launchpad/branch-name each time
[02:29] <spiv> ddaa: Tell me about this librarian failure with importd2bar
[02:29] <spiv> Er, importd2bzr
[02:29] <mpt> ok, that seems to be doing useful stuff
[02:30] <salgado> bradb, ouch, that's bad. what's the failing test? does it fail on your box too?
[02:30] <mpt> Thanks salgado, kiko, and daf
[02:30] <mpt> any moment now, my branch on PendingReviews will actually work...
[02:30] <spiv> ddaa: Or mail me if you prefer
[02:34] <bradb> salgado: If failed only with pqm, not locally (that's what made it so hard to debug.) It's been a few days now, but it was one of the doctests, like bugtask.txt or something.
[02:35] <salgado> bradb, that's weird. did you merge from pqm after you got the failure?
[02:35] <bradb> salgado: Yep.
[02:38] <ddaa> spiv: there's not terribly much to say about it
[02:39] <ddaa> I got weird failures when I tried to merge my branch, and my local tests were inconclusive to reproduce the problem.
[02:39] <ddaa> I'll try again, it will be less painful now that I have my real laptop back.
[02:40] <iwj> sivang: I'm too lazy to get a better IRC client, so I run two copies of it.
[02:40] <sivang> iwj: heh
[02:43] <kiko> salgado, did you see stub's Re: shipit query mail?
[02:44] <salgado> kiko, the one which he said he added an index?
[02:44] <kiko> yes. 
[02:44] <kiko> did he fix the query, or was he implying we should?
[02:44] <kiko> stub the mystery man
[02:45] <salgado> well, that query is generated by sqlobject, IIRC
[02:45] <kiko> = 'f'?
[02:45] <kiko> that is surprising
[02:45] <salgado> kiko, he said that in his email
[02:45] <salgado> he said that sqlobject does that
[02:46] <salgado>         q = AND(ShippingRequest.q.cancelled==False,
[02:46] <salgado>                 ShippingRequest.q.approved==None)
[02:46] <salgado>         results = ShippingRequest.select(q, orderBy='daterequested', limit=1)
[02:46] <stub> SQLObject needs a fix. I've talked to spiv and it looks doable. I'll be looking at it tomorrow.
[02:46] <salgado> that's the query
[02:46] <kiko> I see.
[02:46] <spiv> ddaa: Fair enough.  Fire me an email about it if it persists.
[02:46] <kiko> cool, thanks stub 
[02:46] <salgado> thanks stub!
[02:57] <kiko> matsubara, can you test your PQM account?
[03:00] <mpt> ok, that's still not working
[03:01] <kiko> mpt, did you link the external sourcecode?
[03:01] <mpt> kiko, yes
[03:01] <kiko> tell me what ls -l sourcecode/ looks like in a privmsg
[03:03] <matsubara> kiko: i'll try it in a few minutes.
[03:18] <mpt__> It's going to take me a while to get used to the lesser stuff Launchpad prints when starting up
[03:18] <mpt__> I keep thinking it's not ready yet
[03:24] <daf> we should disable trebuchet
[03:25] <lifeless> meh, cant sleep
[03:25] <lifeless> kiko, bjorns branch did come up in the review meetings, and early this week I transferred to salgados queue to review
[03:25] <lifeless> so that I would not be blocking bjorn
[03:26] <kiko> salgado is a bad option
[03:26] <kiko> he has cprov's branch to review and he is very busy
[03:26] <lifeless> spiv: I have not yet fully isolated the bzr during make check_merge so its not corrected yet
[03:26] <salgado> actually I already started reviewing cprov's branch
[03:27] <salgado> err
[03:27] <salgado> BjornT's branch
[03:27] <kiko> bjorn's branch? really?
[03:27] <lifeless> kiko: I'm not a mind reader, I can't tell that people are too busy unless the wiki page says so or I get an email to that effect
[03:27] <salgado> it's small, wouldn't take long
[03:27] <kiko> lifeless, you can talk to people during the review meetings, though
[03:27] <lifeless> kiko: you think?
[03:27] <salgado> but there's two branches of him there
[03:27] <kiko> I find it surprising that the branch was left lingering for a month, just that
[03:28] <lifeless> kiko: last review meeting as it happens, I had ESTEVE and did something he considered higher priority
[03:28] <lifeless> so I did not run the meeting
[03:28] <kiko> I see
[03:28] <kiko> well, let's try and get this done this week, it's a feature I crave
[03:28] <daf> the date on the branch should be a warning sign
[03:29] <lifeless> kiko: also, if reviewers are busy, the process says they should bounce it back to general/my reallocation queue
[03:29] <daf> perhaps the pending page can show branches over 2 weeks old in red
[03:29] <kiko> daf, that sounds like a good idea
[03:29] <daf> (except it already does that for baz branches)
[03:29] <lifeless> kiko: which is extremely small amount of work to do
[03:29] <kiko> lifeless, you're right about that
[03:29] <kiko> chide thy reviewers
[03:29] <salgado> well, I wasn't aware of this new branch that I was just told I'll have to review
[03:29] <salgado> and it's not in my queue
[03:30] <lifeless> kiko: well, I'm responding to you telling me salgado was a bad choice
[03:30] <lifeless> salgado:  sftp://chinstrap/home/warthogs/archives/bjorn/launchpad/SupportTrackerTweaks
[03:30] <salgado> so I assumed I could review both of BjornT's branch
[03:30] <lifeless>     *
[03:30] <lifeless> thats the one we are talking about ?
[03:30] <daf> ddaa: remind me, what's stopping the merge-approved importd2bzr branch from being merged?
[03:30] <salgado> yes, this is the one I already started
[03:30] <lifeless> great
[03:30] <ddaa> daf: mysterious test failures
[03:30] <kiko> great
[03:30] <daf> ddaa: suck
[03:30] <ddaa> daf: I have to run the tests locally, and forward whatever I find to spiv
[03:31] <daf> Kinnison: buildd-fixes is in "unkown" state on the pending branch summary
[03:31] <daf> Kinnison: it has a date of 11-09
[03:31] <lifeless> kiko: also, side but related issue, I'm in the middle of a sprint to get bzr 0.8 locked down
[03:31] <kiko> lifeless, I know you're busy, just let me complain :)
[03:31] <lifeless> and thats taking all my time, which sucks as I'm not getting to do things I really like, like making lp test enhancements
[03:31] <ddaa> daf: pqm seriously hates me, every branch I've tried to merge in the past branch has failed because of strange problems...
[03:31] <ddaa> * in the past month
[03:31] <daf> ddaa: ouch :(
[03:32] <daf> lifeless: your story branch doesn't have a date on it
[03:32] <lifeless> daf: yah, copy past borkage
[03:32] <ddaa> hey lifeless
[03:32] <daf> pls fix kthx
[03:33] <daf> salgado: sqlobject/2/smallfixes -- date of 07-22?
[03:33] <ddaa> something bothering me about stale sftp locks and centralised importd branch publishing
[03:33] <salgado> daf, that branch depends on having pylib packaged and available in Ubuntu
[03:33] <ddaa> lifeless: I've found that stale sftp locks are rare but do happen in importd
[03:33] <salgado> and working
[03:33] <daf> salgado: ah, I see
[03:34] <lifeless> ddaa: yup
[03:34] <ddaa> and I've been wondering whether we coud find a way to automatically break them
[03:34] <daf> salgado: is somebody working on that?
[03:34] <salgado> daf, right now it's available but not working. in dapper it's working
[03:34] <ddaa> lifeless: in normal operation, that should be safe
[03:34] <daf> salgado: can we ask one of the distro team to do a backport?
[03:34] <salgado> daf, yes, I was.
[03:34] <lifeless> ddaa: see the branch locking mk2 thread in bazaar-ng@
[03:34] <ddaa> lifeless: but I already observed buildbot running the same job twice at once in the past, so normal operation is not enough
[03:34] <salgado> daf, maybe
[03:34] <salgado> doko, around?
[03:34] <ddaa> lifeless: something new?
[03:35] <lifeless> ddaa: stale lock detection and cleanup facilities
[03:35] <lifeless> a implementable spec
[03:35] <daf> kiko: what do you think about these baz branches on the review page?
[03:35] <daf> kiko: should we get people to import them into bzr or just drop them?
[03:35] <doko> salgado: yes
[03:35] <kiko> what is baz?
[03:35] <daf> baz-the-fork-of-tla
[03:35] <kiko> yes, I think they should be converted to bzr and die
[03:36] <lifeless> daf: if you could heckle the folk that have not converted those branches. *cough mpt*
[03:36] <lifeless> daf: that would be great
[03:36] <daf> lifeless: the procedure is documented, isn't it?
[03:36] <lifeless> daf: yes
[03:36] <daf> somebody needs to take over debonzi's branch
[03:36] <salgado> doko, was that newer version of the codespeak-lib package accepted?
[03:36] <daf> SteveA: please convert your launchpad-unittest-authentication branch to bzr
[03:37] <daf> mpt__: oi
[03:37] <ddaa> lifeless: why do you always say "extant" instead of "existant", is that a nzism?
[03:37] <doko> salgado: http://qa.debian.org/developer.php?package=codespeak-lib&comaint=yes
[03:37] <daf> extant != existant
[03:37] <lifeless> ddaa: because I mean extant ?
[03:38] <ddaa> ha okay
[03:38] <kiko> that might be a good reason
[03:38] <ddaa> never seen that word used anywhere else...
[03:38] <lifeless> http://www.m-w.com/dictionary/extant
[03:38] <lifeless> meaning 2a
[03:39] <mpt__> daf, hmm?
[03:39] <ddaa> actually existent
[03:39] <lifeless> there is no word existant
[03:39] <daf> mpt__: mpt@c.c/launchpad--menus--0509
[03:39] <salgado> doko, I thought I had mailed you a 0.7-svn20050721-3 with some bugfixes, haven't I?
[03:39] <SteveA> daf: no need.
[03:39] <mpt__> afaik, extant has more of an emphasis on "still remaining"
[03:39] <ddaa> http://www.m-w.com/cgi-bin/dictionary/existent
[03:39] <ddaa> meaning 2
[03:39] <SteveA> daf: this is fixed upstream
[03:40] <doko> salgado: oops, I see, uploading it now
[03:40] <daf> SteveA: ok, then please remove it from the pending reviews page
[03:40] <salgado> doko, great. thanks
[03:40] <SteveA> daf: done
[03:40] <daf> mpt__: yes, I think of it as "still applicable"
[03:40] <daf> SteveA: thanks
[03:42] <mpt__> daf, yes, sorry, that's been way down my priority list
[03:42] <daf> mpt__: ok, but the longer you leave it the more work it will be to salvage it, I think
[03:42] <mpt__> true
[03:42] <lifeless> ddaa: in that thread I used it because it emphasises the clients we cant force to upgrade
[03:43] <lifeless> ddaa: not that I said 'existing' in the paragraph above where no emphasis was needed
[03:44] <lifeless> kiko: have you filed a bug on empty merge commits in pqm ?
[03:44] <kiko> lifeless, I first wanted to see whether you (and others) thought it was a good idea, but I can if you say so
[03:45] <lifeless> I think it will prevent noise in the system
[03:45] <kiko> salgado, does it make sense to get the mirrors for ubuntu entered in production?
[03:45] <kiko> lifeless, okay. I will do so now
[03:45] <lifeless> and if done as an option we can always change our mind
[03:45] <lifeless> with pqm, we have occasional community contributors
[03:45] <lifeless> theres a bunch of folk (not just Kinnison) using it outside canonical
[03:46] <lifeless> so, bugs good, because theres a change someone else will write a patch :)
[03:46] <kiko> I see
[03:46] <kiko> bug 30972
[03:46] <Ubugtu> malone bug 30972 in pqm "PQM should reject empty merge requests" [Normal,Unconfirmed]  http://launchpad.net/bugs/30972
[03:46] <daf> mpt__: we were going to talk about overlap between WhyTheSmegAmIHere and LaunchpadPeopleAndUsers
[03:49] <mpt__> yes
[03:50] <mpt__> but it's 3.50am
[03:50] <mpt__> but, but, but
[03:50] <mpt> So basically
[03:51] <mpt> We need an obvious way of saying "this person doesn't use Launchpad"
[03:51] <mpt> where that is defined by either
[03:51] <mpt> (1) having never used Launchpad
[03:51] <SteveA> daf, mpt: arrange a time tomorrow.
[03:51] <carlos> mpt: hi, before you leave... could you add to your TODO list a fast review of the translation form to fix the layout problems it has? I fixed some of the problems as you told me but there are something else that I'm not able to fix
[03:51] <SteveA> carlos: sent mpt an email
[03:51] <mpt> (2) having clicked some button somewhere saying "Launchpad and I will never meet again"
[03:51] <carlos> sure
[03:52] <mpt> hooray, tests pass
[03:52] <SteveA> mpt: i thnk you should arrange a time with daf, and stop for the day.  no sense pushing it into the late hours over this spec
[03:52] <daf> mpt: I agree with Steve
[03:52] <daf> mpt: let's talk when I get up tomorrow
[03:52] <mpt> ok
[03:53] <mpt> it's nearly there
[03:53] <salgado> kiko, no, I think it's better to wait until the prober lands
[03:54] <kiko> wouldn't the prober benefit from existing data? but okay.
[03:54] <ddaa> lifeless: I think that design would be adequate with the hostname, timestamp and pid stored in the lock.
[03:54] <salgado> pqm seems to be processing one of daf's branch for more than one hour now. is it possible that something is wrong?
[03:55] <kiko> has daf gotten an answer back?
[03:55] <daf> no, he hasn't
[03:55] <daf> kill it
[03:55] <kiko> well
[03:55] <kiko> have lifeless investigate where it is
[03:55] <ddaa> lifeless: importd would need an utility function to retrieve the lock data and check whether the hostname is the current hostname, and the pid does not name an existing process. If that's true, then the lock can be safely broken.
[03:56] <lifeless> cron is disabled
[03:56] <kiko> carlos, did your recent permissions landing make the problem of not being a launchpad admin go away?
[03:56] <lifeless> stub must be doing maintenance
[03:56] <carlos> kiko: that branch is not yet reviewed so it's not merged
[03:56] <kiko> carlos, but the code is there? great
[03:56] <salgado> lifeless, can we have a package from dapper installed on pqm's box?
[03:57] <carlos> kiko: not all the permission problems are fixed
[03:57] <kiko> okay
[03:57] <daf> lifeless: the cron that launchpad pqm or the one that kills it if it's hung?
[03:57] <carlos> but I'm on it
[03:57] <lifeless> salgado: mail me, and canonical RT.
[03:57] <carlos> kiko: The one that landed into production is the one that fixed the 147 .po files that were stalled on the import queue
[03:57] <lifeless> salgado: or mail canonical RT, then forward me the ticket number and I'll confirm it for elmo
[03:58] <carlos> kiko: we talked about that issue, not sure if you remember it
[03:58] <kiko> hoho
[03:58] <lifeless> salgado: be sure to include why we need it, as its running dapper
[03:58] <lifeless> salgado: and what the impact of that will be on production boxes which also need to have it installed presumably
[03:58] <salgado> lifeless, good, I'll do it once the package is uploaded
[03:58] <carlos> kiko: so the error log should be smaller now
[03:58] <salgado> lifeless, we don't need it in production, I think. we only need it to run sqlobject's tests
[03:59] <daf> salgado: awesome
[03:59] <salgado> lifeless, I want it so we can run sqlobject's tests on a commit hook
[04:00] <daf> mpt: sweet dreams
[04:01] <salgado> doko, is that new version going to be propagated to dapper automatically?
[04:02] <doko> no, after UVF updates from unstable are not done automatically. please ask elmo for a sync (giving the package name and version)
[04:02] <lifeless> salgado: you sure?
[04:02] <salgado> doko, okay, I'll do it. thanks. :)
[04:02] <Kamion> in general only those permitted to upload may ask for syncs
[04:02] <salgado> that means I can't
[04:02] <Kamion> or s/may/should/ anyway; if somebody else asks we need to think harder
[04:03] <Kamion> on the basis that an uploader could just have uploaded something equivalent anyway
[04:03] <salgado> lifeless, you mean, if I'm sure we don't need that on production boxes?
[04:04] <salgado> Kamion, right, that makes sense
[04:04] <lifeless> salgado: yes
[04:04] <lifeless> salgado: dapper is irrelevant anyway
[04:05] <lifeless> salgado: elmo will have to rebuild the package, so if its not in dapper, just give him the location of the source package he can use
[04:05] <salgado> lifeless, I don't think we need. what do you think?
[04:05] <lifeless> salgado: I dont even know what the package is, so  ???
[04:05] <daf> salgado said that it's only needed to run SQLObject tests
[04:05] <lifeless> daf: yes, I saw that
[04:05] <lifeless> daf: does not mean I believe it
[04:05] <salgado> lifeless, python-codespeak-lib, which contains py.test
[04:06] <lifeless> ah, yes, I'm aware of that project
[04:06] <daf> lifeless: you could have said "I don't believe it" :)
[04:06] <lifeless> salgado: we can also stash a copy of that in rf
[04:06] <lifeless> salgado: if it is moving sufficiently fast that its a problem for the admins, but I'd rather we try to get the package installed
[04:06] <salgado> lifeless, I discussed that with Steve and we preferred the option of packaging it
[04:07] <salgado> I don't recall why we choose that, but anyway, it's now packaged
[04:07] <lifeless> policy, ease of install for developers who aren't changing it
[04:08] <salgado> probably
[04:12] <ddaa> lifeless: are those arch-style locks meant to be used for local-fs access as well?
[04:12] <lifeless> yes
[04:13] <ddaa> atexit is your friend, I guess...
[04:13] <lifeless> ?!
[04:13] <ddaa> so locks are released when process is killed by SIGTERM
[04:13] <lifeless> finally
[04:13] <ddaa> or SIGQUIT
[04:13] <ddaa> finally works for SIGINT
[04:13] <lifeless> no, we definately do not want global lock registration
[04:14] <ddaa> I do not think it works for harsher signals.
[04:21] <ddaa> lifeless: yup, sigterm is not caught by finally
[04:21] <lifeless> so, if some one logs out while a lock is held it becomes stale.
[04:21] <lifeless> we'll live with that I think
[04:22] <ddaa> if a system is rebooted while a daemon is holding a lock, it becomes stale
[04:22] <ddaa> sigterm and exit handlers are there for a reason
[04:22] <ddaa> anyway, I don't want to fight over that
[04:23] <daf> bradb: suggestion: Malone shouldn't suggest assigning to milestones with a date in the past
[04:23] <ddaa> also, sigterm is the default for "kill" so people use it a lot to kill runaway processes
[04:23] <daf> bradb: s/suggest/allow/
[04:24] <lifeless> ddaa: well we have stale lock detection.
[04:24] <ddaa> only heuristically, it can only be reliably in controlled environments
[04:24] <bradb> daf: Can you please file those suggestions as bug reports? Otherwise we'll lose track of good ideas.
[04:24] <daf> bradb: will do
[04:24] <bradb> thanks
[04:24] <lifeless> ddaa: yes, and within a single system which is your example, that is quite controlled
[04:25] <ddaa> whatever, I'll just way for users to start having broken locks because they killed a process that was taking too long
[04:25] <ddaa> or eating too much cpu, or too much ram
[04:26] <daf> bradb: #30973
[04:27] <lifeless> ddaa: thats what they get right now on remote branches
[04:27] <bradb> God I hate rsync's slash vs. no-slash distinction. Clearly this tool was written by a non-human.
[04:27] <ddaa> lifeless: yes, it can be better
[04:27] <daf> bradb: it's not only annoying, but dangerous
[04:27] <bradb> indeed
[04:27] <lifeless> ddaa: I don't think that that a python defect is a good reason to add a bare except - which is what atexit is essentially
[04:27] <daf> it's a really bad UI
[04:28] <ddaa> lifeless: I think that releasing a lock when a process is dying is something good to do. That's why bzr uses kernel level locks for local fs access at the moment.
[04:28] <ddaa> it's not like releasing a lock is going to corrupt data anymore than it currently might be
[04:29] <ddaa> anyway discussion over, we're not going to agree
[04:29] <lifeless> ddaa: actually thats not why bzr uses kernel locks
[04:29] <bradb> daf: In fact, the only real accident I've ever had with software development was an episode with slash vs. no-slash and --delete.
[04:30] <bradb> But I know I'm not the only one.
[04:30] <ddaa> lifeless: oh really, for what reason then? (genuinely curious). In any case that's a useful side effect worth preserving.
[04:31] <bradb> Of course, it would have been a complete non-issue if said client had been using version control or backups, but bah, who needs THAT?
[04:32] <ddaa> bradb: people that do not make mistakes are not the ones who assume they do not make mistakes. Right?
[04:32] <lifeless> ddaa: essentially because they were handy and reinventing arch locks at that point wasn't productive
[04:33] <lifeless> it didn't have a vfs when it started
[04:33] <ddaa> okay, makes sense
[04:33] <ddaa> bug 1
[04:33] <bradb> ddaa: Indeed. There are those who never make a mistake, and then the rest of us! :P
[04:33] <Ubugtu> malone bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,Confirmed]  http://launchpad.net/bugs/1
[04:40] <lifeless> night all, trying sleep again
[04:40] <lifeless> 2:30am :[
[04:41] <kiko> night lifeless 
[04:41] <lifeless> in case its not clear, chase stub re pqm, as he disabled it I dont want to trod on him
[04:41] <lifeless> in case there is something important pending
[04:41] <lifeless> I will chase him tomorrow if its still disabled
[04:46] <Kinnison> daf: I should remove it, it's irrelebant
[04:50] <daf> Kinnison: ta
[04:51] <Kinnison> daf: the work was subsumed into the soyuz branch
[04:51] <Kinnison> daf: and then almost certainly refactored beyond recognition :-)
[05:07] <daf> lifeless: what's happening about PQM?
[05:08] <daf> oh, he went back to bed
[05:08] <daf> kiko: can we poke it?
[05:09] <salgado> daf, <lifeless> in case its not clear, chase stub re pqm, as he disabled it I dont want to trod on him
[05:09] <SteveA> daf: elmo, karl, stu and lifeless are the people who can poke at pqm
[05:09] <SteveA> daf: if stub disabled it, then we just have to wait until tomorrow when stub is around.
[05:10] <SteveA> daf: i was just talking about this with kiko, and there is something i want to ask you about...
[06:01] <daf> salgado: I'm looking at bug #29655
[06:01] <Ubugtu> malone bug 29655 in launchpad "selecting ValidAssignee times out" [Normal,Unconfirmed]  http://launchpad.net/bugs/29655
[06:01] <daf> salgado: do you think it has been fixed?
[06:01] <kiko-afk> daf, quite possibly, close and let the reporter reopen?
[06:02] <daf> good idea
[06:02] <kiko-afk> bradb, you know, you could use your package bug contact report as a template for a project bug report. 
[06:02] <daf> sivang: ^^^
[06:02] <kiko-afk> have you considered that?
[06:02] <bradb> kiko-afk: Yeah.
[06:02] <bradb> kiko-afk: I got the idea vaguely from the discussions with SteveA in .lt.
[06:02] <sivang> daf: I'm here
[06:03] <bradb> (i.e. the discussions we had about project bug reports.)
[06:03] <kiko-afk> bradb, I'd pay a pound of flesh for a report on launchpad counts
[06:03] <daf> sivang: see my last comment on the bug
[06:03] <daf> kiko-afk: isn't that what I posted to LP last night?
[06:04] <kiko-afk> daf, online, for the project, auto-generated, but yes
[06:04] <bradb> kiko-afk: At least daf's reports should get you a bit of what you need. Meanwhile Ubuntu devs are suffering hard on the 20 bugs per page and non-tabular listings, which is why I put focus on those areas atm.
[06:04] <sivang> daf: I see, well, it was timeing out for me every time I tried to search for a Scott or a Keybuk
[06:06] <Kinnison> kiko-afk: can I get you to cast your eyes over: https://chinstrap.ubuntu.com/~dsilvers/paste/filepHl1Ix.html
[06:07] <Kinnison> kiko-afk: It's my proposed patch to allow -updates uploads to soyuz
[06:08] <daf> kiko-afk: maybe half a pound of flesh then?
[06:08] <kiko-afk> Kinnison, I don't like that there are two ifs: in nascentupload.py
[06:08] <kiko-afk> Kinnison, see if you can centralize the decision.
[06:08] <kiko-afk> I like the general design of the solution
[06:08] <Kinnison> kiko-afk: I'll look at it, but I'm not sure I can, the separation is the separation of the process of accepting, from the decision of which mails to send
[06:09] <Kinnison> kiko-afk: but I'll see if there's a sane way to combine the decisions
[06:09] <kiko-afk> those actions should probably be linked together..
[06:09] <Kinnison> They're linked via the transaction, but I don't think they can be linked more directly than that
[06:10] <kiko-afk> I don't like the extra ifs in uploadpolicy either
[06:10] <sivang> daf: cool, I can't reproduce it either. seems it's working alright!
[06:10] <daf> sivang: great!
[06:10] <daf> sivang: I think it's salgado's work that's done iot
[06:11] <Kinnison> kiko-afk: I'd far prefer those to be a table, but I wasn't sure how to do it neatly
[06:11] <daf> kiko-afk: do you know if we spoke to the admins about bug 30680?
[06:11] <Ubugtu> malone bug 30680 in launchpad "presenting SSL client certificate from unknown CA prevents connect to https://launchpad.net" [Normal,Unconfirmed]  http://launchpad.net/bugs/30680
[06:11] <sivang> daf: yes, he also gave an elaborate explenation on the bug body itself which gave me an idea what was wrong and how it had been fixed, I think. (by narrowing the people vocabelury)
[06:12] <daf> cool
[06:13] <sivang> daf: how can I reject a test bug I've just opened to test that?
[06:13] <daf> sivang: mark it Rejected?
[06:14] <daf> actually, I can see it would not be obvious how to do that
[06:14] <Kinnison> kiko-afk: https://chinstrap.ubuntu.com/~dsilvers/paste/fileQUVTwF.html
[06:14] <sivang> daf: ah right, I looked for more of a "closed" operation
[06:14] <Kinnison> kiko-afk: I've tidied the ifs in the upload policy a bit
[06:14] <sivang> s/closed/close/
[06:14] <Kinnison> kiko-afk: is that better or worse?
[06:14] <kiko-afk> it is much better
[06:14] <kiko-afk> however
[06:14] <kiko-afk> there is the central problem of band-aiding three ifs to implement this
[06:15] <kiko-afk> which weakens the original strong design that you had
[06:15] <Kinnison> That goes away once we have the embargo stuff finished
[06:15] <Kinnison> it becomes "if release and open or non-release and closed => permit"
[06:15] <kiko-afk> we should not have ifs at all if you get my meaning
[06:15] <daf> kiko-afk: do you know if we spoke to the admins about bug 30680?
[06:15] <Ubugtu> malone bug 30680 in launchpad "presenting SSL client certificate from unknown CA prevents connect to https://launchpad.net" [Normal,Unconfirmed]  http://launchpad.net/bugs/30680
[06:15] <kiko-afk> the design of the code should avoid having ifs
[06:15] <Kinnison> kiko-afk: Well, we have to have some ifs, since the idea is to make sure we're happy to allow an upload
[06:16] <kiko-afk> the object structure should take care of it
[06:16] <daf> kiko-afk: you mean you want all the lofic in c.l.scripts?
[06:16] <Kinnison> kiko-afk: I'm confused about how the object structure can make a decision without an if statement
[06:16] <kiko-afk> daf, no, rather that I think the object design should account for it
[06:17] <kiko-afk> Kinnison, well, think about how the existence of upload policy potentially avoids many ifs in your code
[06:17] <kiko-afk> now it could be factored even better
[06:17] <daf> kiko-afk: dude, did you see my question?
[06:17] <kiko-afk> so that you asked upload policy to do things
[06:17] <kiko-afk> instead of asking it if you could do things
[06:17] <daf> kiko-afk: (the one I asked twice)
[06:17] <kiko-afk> anyway
[06:17] <ddaa> I knew I had a CHANGE item... darn, forgot about it.
[06:17] <kiko-afk> I noticed it daf
[06:18] <daf> aha
[06:18] <kiko-afk> I am thinking
[06:18] <daf> ok :)
[06:18] <kiko-afk> launchpad.net has a valid ssl cert for me
[06:18] <daf> that's not the issue at all
[06:18] <Kinnison> kiko-afk: I'm really really confused now
[06:18] <Kinnison> kiko-afk: can you give me an example of how you'd rather I did it?
[06:18] <daf> kiko-afk: it's about the client presenting a certificate
[06:18] <kiko-afk> Kinnison, never mind. I'll take time in london to explain this to you further
[06:19] <kiko-afk> Kinnison, just make sure a bug is filed on it
[06:19] <daf> kiko-afk: and Launchpad rejecting it instead of ignoring it
[06:19] <kiko-afk> oh
[06:19] <kiko-afk> I didn't read "client" there
[06:19] <Kinnison> kiko-afk: Okay, thanks, hopefully I'm just being dense and it'll be obvious once we sit down together
[06:20] <kiko-afk> it's an interesting thing, we'll look into it together Kinnison 
[06:20] <daf> kiko-afk: Steve seemed to think it might be an Apache config issue
[06:20] <Kinnison> kiko-afk: bug 30983
[06:20] <Ubugtu> malone bug 30983 in launchpad-upload-and-queue "upload policy engine needs simplification" [Normal,Unconfirmed]  http://launchpad.net/bugs/30983
[06:21] <kiko-afk> Kinnison, fine by me -- mark the ifs with XXXs
[06:21] <Kinnison> kiko-afk: *nod*
[06:21] <kiko-afk> daf, it most likely is
[06:22] <Kinnison>         # XXX: dsilvers: 20060209: This is way too hairy/complex. bug#30983
[06:22] <kiko-afk> Kinnison, not only that -- it is also fragile. if you update the if in one place you need to remember to update it in 3 locations.
[06:23] <Kinnison> Well, this decision is entirely self-contained in the one method
[06:23] <Kinnison> I think you've conflated the issue of the hairiness of InsecureUploadPolicy.policySpecificChecks() with NascentUpload's calling of self.policy.autoApprove()
[06:23] <Kinnison> the diff may not have enough context for you to see this
[06:24] <kiko-afk> no, I am concerned that multiple ifs were added to account for this
[06:24] <kiko-afk> but again, it is a design issue
[06:24] <kiko-afk> and we can talk about it later
[06:30] <daf> is our openpgp stuff actively maintained?
[06:31] <kiko-afk> do you mean gpgme?
[06:31] <daf> I mean our code that handles keys
[06:31] <daf> in Launchpad
[06:31] <kiko-afk> the answer should be yes
[06:32] <daf> who's maintaining it?
[06:32] <kiko-afk> jamesh last looked at it
[06:33] <daf> I'm wondering who to prod about #30277, #30276, #3052
[06:33] <kiko-afk> if you don't say bug Ubugtu can't help us
[06:33] <kiko-afk> bug 30277
[06:33] <Ubugtu> malone bug 30277 in launchpad "launchpad recommends generating a new key but shouldn't" [Normal,Unconfirmed]  http://launchpad.net/bugs/30277
[06:33] <kiko-afk> bug 30276
[06:33] <Ubugtu> malone bug 30276 in launchpad "launchpad claims a key is expired when it's not" [Normal,Unconfirmed]  http://launchpad.net/bugs/30276
[06:33] <kiko-afk> bug 3052
[06:33] <Ubugtu> malone bug 3052 in launchpad "GPG upload of newly-changed key fails because we cache the old key" [Normal,Confirmed]  http://launchpad.net/bugs/3052
[06:33] <kiko-afk> all jamesh material.
[06:34] <daf> ok, I'll assign him for now
[06:35] <daf> kiko-afk: do you know how the @ubuntu.com aliases work?
[06:36] <daf> (re bug 28671)
[06:36] <kiko-afk> yes
[06:36] <kiko-afk> there is a script that creates the alias entries
[06:36] <daf> I said bug! I said it!
[06:36] <daf> Ubugtu: you don't love me
[06:36] <kiko-afk> bug 28671
[06:36] <Ubugtu> malone bug 28671 in launchpad "Ubuntero can not change @ubuntu.com destination e-mail address" [Normal,Unconfirmed]  http://launchpad.net/bugs/28671
[06:36] <kiko-afk> daf, that is a salgado bug
[06:36] <kiko-afk> it involves the creation of a "forwarding email" address
[06:36] <kiko-afk> and having ubuntu.com redirect to t
[06:37] <toby> hi
[06:37] <daf> kiko-afk: why?
[06:37] <kiko-afk> I need to skip out for a bit, daf, but will brb
[06:37] <daf> ok
[06:37] <toby> awesome, half op
[06:37] <daf> hello toby 
[06:37] <kiko-afk> daf, will you be in in 30 minutes?
[06:37] <daf> yar
[06:37] <kiko-afk> hey toby 
[06:37] <toby> hi
[06:37] <kiko-afk> so will I. see you then
[06:37] <daf> salgado: yo
[06:38] <toby> how long will it take if i ask for the cd to be posted to uk?
[06:38] <kiko-afk> usually 2-4 weeks
[06:38] <toby> oh cool the site says 4-6
[06:38] <kiko-afk> the UK is usually fast
[06:39] <toby> yey
[06:39] <kiko-afk> brazil is terrible
[06:39] <toby> can i run irc server on it?
[06:39] <daf> on Ubuntu?
[06:39] <toby> yeah
[06:39] <Kinnison> toby: whereabouts in the UK are you?
[06:39] <daf> certainly
[06:39] <toby> midlands
[06:39] <toby> gd
[06:39] <Kinnison> Should be pretty fast delivery then
[06:39] <toby> yey
[06:40] <daf> Kinnison: where do we ship them from?
[06:40] <Kinnison> daf: somewhere else entirely, another country iirc
[06:40] <Kinnison> daf: but outer-hebrides might take a while to get to :-)
[06:40] <daf> heh
[06:40] <daf> I have a feeling it's Holland
[06:40] <Kinnison> plausible
[06:41] <LarstiQ> daf: I very much doubt that, or at least, not when I ordered them
[06:41] <salgado> hey daf
[06:41] <daf> hey
[06:42] <daf> about bug 28671
[06:42] <Ubugtu> malone bug 28671 in launchpad "Ubuntero can not change @ubuntu.com destination e-mail address" [Normal,Unconfirmed]  http://launchpad.net/bugs/28671
[06:42] <daf> kiko thinks this needs a new "forwarding" type of address
[06:42] <daf> but that's to stop people making their @ubuntu.com addresses preferred yes?
[06:43] <Kinnison> We need the forwarding address so that we don't automatically forward ubuntu.com to the preferred address
[06:43] <Kinnison> entirely because for many people their ubuntu.com address should be their preferred one
[06:43] <Kinnison> e.g. the distro team
[06:44] <daf> "we don't automatically forward ubuntu.com to the preferred address"
[06:44] <daf> oh, I see
[06:44] <daf> displayed address vs. contact address might be better terms
[06:45] <Kinnison> Hmm
[06:45] <Kinnison> Or else we need a specific column for their ubuntu.com forwarding address
[06:45] <Kinnison> which would seem nasty when we have this multi-address magic already
[06:45] <daf> yeah
[06:45] <toby> why cant i just get 1 pc cd?
[06:46] <Kinnison> toby: because it's way uneconomical to ship
[06:47] <daf> I suppose you could make a custom request
[06:47] <Kinnison> toby: If you really just one one PC CD, I could probably rustle one up from downstairs and pop it in the post to you
[06:47] <toby> k
[06:47] <Kinnison> toby: but then again you may as well download it and burn a CD yourself if you only want one
[06:47] <toby> are all the options free?
[06:47] <Kinnison> yes, we don't charge for shipit
[06:47] <toby> cool
[06:49] <toby> k req
[06:49] <toby> requested
[06:50] <daf> salgado: anyhow, is this something you're going to be working on?
[06:50] <daf> salgado: can I confirm it?
[06:51] <salgado> daf, sure, that's really a bug. but I don't think I'll have time for it soon
[06:51] <daf> no worries
[06:51] <daf> just trying to get the untriaged bug count down
[06:54] <salgado> ah, right
[06:54] <salgado> hmmm. almost 16h, must be time to have some lunch
[06:55] <daf> salgado-lunch: you mean 18h
[06:58] <cprov> carlos: or daf: could you help me with a rosetta test failure -> https://chinstrap.ubuntu.com/~dsilvers/paste/fileVCaVJG.html
[06:58] <carlos> let me check it...
[06:59] <carlos> cprov: and you don't get anything else before that error?
[06:59] <daf> that's weird
[07:00] <cprov> carlos: nop ... test suite noise , I suppose
[07:01] <carlos> seems like the 'CLOSED' mode to do translations is not set for your tests...
[07:01] <carlos> cprov: have you changed anything related to sqlobject or caching?
[07:01] <daf> cprov: did you "make -C database/schema" recently?
[07:02] <carlos> daf: I think I didn't change anything related to schema or sampledata... but it's good to check that
[07:02] <carlos> daf: btw, 'make schema' from the top directory works too
[07:02] <cprov> carlos: nothing unusual, got new sqlobject last week (selectFirst) is there anything newer ?
[07:02] <daf> carlos: cool, I didn't know that
[07:02] <carlos> cprov: don't think so
[07:03] <carlos> daf: I discovered it this week
[07:03] <cprov> carlos: schema is up, as I used 'make check'
[07:03] <daf> very odd
[07:03] <carlos> cprov: would you try the make schema command, just in case...
[07:03] <cprov> carlos: sure
[07:04] <carlos> cprov: also, could you run the test alone? ./test.py -vvv --test=pofile.txt
[07:05] <cprov> carlos: the point is, if you're sure about the code and the test output is weird, I can try clever things like re-merge rf from our local rf copy and so on
[07:05] <carlos> cprov: it should not fail
[07:05] <carlos> that test was added recently to rocketfuel
[07:06] <carlos> and I know why it fails, but not what causes that error
[07:06] <cprov> carlos: running it alone fails too (after make schema), as expected
[07:07] <carlos> cprov: ok
[07:07] <carlos> if you want to check somethings, on line #197
[07:08] <carlos> we set the restrictions that seems it's missing your test run
[07:08] <carlos> try to check that you are not having caching issues
[07:08] <cprov> carlos:     >>> product.translationpermission = TranslationPermission.CLOSED (#197)
[07:08] <cprov> carlos: pofile.txt
[07:08] <carlos> right
[07:09] <cprov> carlos: I see, that's why it shoudl return False on canEdit()
[07:09] <carlos> the first error you get is because the code is getting TranslationPermission.OPEN there
[07:09] <carlos> instead of the CLOSED one
[07:09] <carlos> right
[07:10] <carlos> cprov: what did you change on your branch?
[07:10] <cprov> carlos: ehe, you don't wonna know (16K lines) it's the soyuz codeline
[07:11] <carlos> so it doesn't change anything related to team members
[07:11] <cprov> carlos: what do you think could affect your test ?  maybe a remaining logged context ?
[07:11] <carlos> it's the other thing that I can think on causing such errors
[07:12] <cprov> maybe kept you as admin member .. right, let me check
[07:12] <carlos> cprov: could be...
[07:12] <carlos> cprov: did you removed me from the admin team on sample data?
[07:14] <daf> whoa!
[07:14] <daf> https://launchpad.net/products/0.38
[07:14] <daf> https://launchpad.net/products/0.39
[07:15] <cprov> carlos: no unfortunatelly bzr did weird stuff on merge, I think
[07:15] <carlos> daf: who registered them?
[07:15] <daf> https://launchpad.net/people/dimitris-kalamaras
[07:15] <carlos> cprov: so it's a half done merge?
[07:18] <cprov> carlos: don't know yet, I simply see you as admins member and that's is the problem
[07:18] <carlos> cprov: oh, I didn't know we were removed from the sample data too... that's going to break many tests...
[07:19] <cprov> carlos: don't screw up ;) i said you are a member of admins in the sampledata
 carlos: don't know yet, I simply see you as admins member and that's is the problem
[07:20] <cprov> carlos: so, diffing with my RF-build tree it looks correct
[07:20] <carlos> then, what's the problem? ;-)
[07:20] <cprov> carlos: yes, I suppose as admin you can do CLOSED translations, is that true ?
[07:21] <carlos> yes
[07:21] <carlos> and as a Rosetta Expert
[07:21] <carlos> but my account is used only to set the CLOSED mode nothing more
[07:22] <cprov> carlos: uhm .. didn't get it, right
[07:24] <cprov> carlos:  no_priv and valentina got True instead of False from canEdit() what does it means for you ?:
[07:25] <carlos> cprov: as I said, it means that canEditTranslations get the OPEN mode instead of CLOSED
[07:25] <carlos> either that or someone added Valentina and no_priv to rosetta_experts/admins team
[07:26] <carlos> check that first, the value you have and add a pdb.set_trace call inside the _can_edit_translations function at lib/canonical/launchpad/database/pofile.py
[07:27] <carlos> that would tell you why you get TRUE instead of FALSE
[07:27] <cprov> carlos: it'll need to wait a while (20 min) need to do the soyuz rollout now
[07:27] <carlos> ok
[07:28] <carlos> I need to leave for a while too so it's not a problem for me
[07:28] <carlos> ping me when you know why it returns True and I will try to figure what's going on
[07:28] <carlos> also, a push of your branch would be a good idea
[07:28] <carlos> just in case I can reproduce the error here
[07:29] <cprov> carlos: already there `uploader-tests`
[07:30] <carlos> oh, I have that branch already. I'm working on it
[07:30] <carlos> I will merge it when I back and will take a look
[07:33] <cprov> carlos: thanks dude !
[07:41] <Kinnison> see you lot tomorrow
[07:46] <ddaa> grah... the publishing of bzr imports makes my head blow...
[07:46] <ddaa> when you look at it really closely there's an incredible number of annoying details, loose ends, and interrelated design choices...
[07:47] <ddaa> it's like a fractal onion
[07:48] <ddaa> not only it has layers, but it has infinite dark corners, and each layer has sublayers
[07:59] <LarstiQ> ddaa: you make me want to cook
[07:59] <LarstiQ> and I was just done with that
[08:02] <dilys> Merge to devel/launchpad/: [rs=kiko]  30919 in launchpad The (r3110: Dafydd Harries)
[08:02] <kiko> wow that took a long time
[08:02] <daf> yeah
[08:02] <kiko> daf, I talked to elmo about bug 30680
[08:02] <Ubugtu> malone bug 30680 in launchpad "presenting SSL client certificate from unknown CA prevents connect to https://launchpad.net" [Normal,Unconfirmed]  http://launchpad.net/bugs/30680
[08:03] <kiko> he seems to have said he knows how to fix it
[08:03] <daf> yay
[08:03] <daf> is he going to? :P
[08:04] <kiko> that is anoher matter
[08:04] <daf> elmo: ?
[08:05] <kiko> in launchpad the
[08:05] <kiko> wtf is that?
[08:05] <daf> it's a typo
[08:06] <daf> I didn't realised I'd sumitted it
[08:06] <daf> and submitted one straight after with the right title
[08:06] <daf> Seveas: I'm going to add a new duplicate-of field to the text pages
[08:10] <daf> bradb: I have this pattern
[08:11] <daf> bradb: I go to a bug
[08:11] <daf> bradb: I think of something to say
[08:11] <daf> bradb: I type it in the comment box
[08:11] <daf> bradb: I then realise I also want to change the status
[08:11] <daf> bradb: I copy the comment I wrote to the clipboard
[08:11] <daf> bradb: load the editstatus page
[08:12] <daf> bradb: paste the comment, change the status, submit
[08:14] <bradb> daf: In your ideal world, how would that workflow be made better?
[08:14] <daf> bradb: I'm not sure
[08:15] <daf> bradb: I was hoping it might be a useful data point
[08:16] <bradb> daf: You seem to be reinforcing another user's point of view:
[08:16] <bradb> WHY CAN'T I FIX THE BUG FROM THE SCREEN WITH ALL THE COMMENTS ON IT, AND WHY CAN'T I VIEW OTHER BUGS IN THE SAME THING FROM THE SAME SCREEN. GNARGH!
[08:16] <bradb> -- Scott James Remnant, 2005-09-16
[08:16] <bradb> https://wiki.launchpad.canonical.com/MatthewPaulThomas/DesignProblems
[08:16] <daf> :)
[08:17] <bradb> also, bug 28574
[08:17] <Ubugtu> malone bug 28574 in malone "+editstatus and +edit should be one page" [Normal,Confirmed]  http://launchpad.net/bugs/28574
[08:22] <LarstiQ> while I wouldn't word it as strongly as Scott, yes!
[08:22] <bradb> daf: If you want to ensure your data point doesn't get forgotten you might want to a. comment on that bug or b. file a new bug (because this is slightly different, though a symptom of the same underlying UI issue). If you file a new one, we could also add it to the DesignProblems document.
[08:23] <dilys> Merge to devel/launchpad/: [rs=kiko]  fix #30919: the string "OOPS code" should not be linkified (r3111)
[08:24] <bradb> Come to think of it, bug 1328 should be in that document too.
[08:24] <Ubugtu> malone bug 1328 in malone "Can't add a comment while editing title/description/confidentiality" [Normal,Confirmed]  http://launchpad.net/bugs/1328
[08:29] <bradb> LarstiQ: FWIW, I don't mind, *ahem*, "strongly worded" feedback on Malone, because if users are that annoyed about something, there's almost surely a seriously good reason to do something about it sooner rather than later.
[08:30] <LarstiQ> bradb: I'll keep it in mind when I get annoyed at malone again
[08:30] <bradb> absolutely
[08:32] <daf> bradb: apart from Bazaar, which upstreams do you know of using Malone?
[08:32] <daf> (and Launchpad, of course)
[08:33] <LarstiQ> daf: upstream from an lp or ubuntu pov?
[08:33] <daf> let me rephrase
[08:33] <daf> how many products?
[08:33] <bradb> daf: bazaar is the only major one that I know of. Launchpad should be able to answer this question, but I guess it kind of doesn't atm.
[08:34] <LarstiQ> daf: anewt isn't big, but it is using malone
[08:34] <daf> LarstiQ: cool, thanks
[08:34] <bradb> According to https://launchpad.net/products there are 249 that have bugs reported.
[08:34] <daf> aha
[08:35] <daf> perhaps I can ask stub to give me the 20 with the most bugs
[08:36] <bradb> I imagine the distro team could tell you more too.
[08:44] <dilys> Merge to devel/launchpad/: [trivial]  Fix broken query in Person.specifications (r3112: Stuart Bishop)
[09:18] <siretart> do get bugs in malone get closed via upload mentioning the bugno in the changelog?
[09:18] <dilys> Merge to devel/launchpad/: [trivial]  fix #29743 (clarify the purpose of +registeredbranches) (r3113: David Allouche)
[09:23] <bradb> siretart: not yet, but not that dapper is running on Soyuz, it might be possible with relatively little effort
[09:23] <bradb> s/not that/now that/
[09:24] <siretart> bradb: because I see so many bugs having the relevant changelog in the last message
[09:24] <siretart> I was wondering if maintainers are doing this themselves or if launchpad does this for them
[09:24] <bradb> Launchpad's not doing it yet, to be sure.
[09:25] <siretart> okay. thanks
[09:40] <dilys> Merge to devel/launchpad/: [trivial]  include dup information in text pages (r3114)
[09:41] <cprov> night guys
[10:02] <dilys> Merge to devel/launchpad/: [trivial]  Fix https://launchpad.net/products/launchpad/+bug/30821 (Trying to merge an old Launchpad account into my new one led to an oops), another regression caused by untested code and the removal of SelectResults.__len__() (r3115: Guilherme Salgado)
[10:20] <cogumbreiro> lo all
[10:21] <cogumbreiro> can I ask questions about rosetta here?
[10:24] <cogumbreiro> when I try to upload a pot file I get this error: OOPS-40A801.
[10:24] <Ubugtu> https://chinstrap.ubuntu.com/~jamesh/oops.cgi/40A801
[10:24] <cogumbreiro> does anyone know why it happens?
[10:24] <gneuman> cogumbreiro 
[10:24] <gneuman> hold on
[10:24] <cogumbreiro> gneuman, yes?
[10:24] <cogumbreiro> ok then
[10:24] <cogumbreiro> I will
[10:25] <dilys> Merge to devel/launchpad/: [trivial]  Fix bug # 29548, remove pointless sourcepackage-buildlog page, it was confusing and superseded by +builds page. (r3116: Celso Providelo)
[10:26] <gneuman> sorry, its unavailable yet
[10:26] <gneuman> maybe in 5 min
[10:36] <gneuman> cogumbreiro matsubara is having alook at it
[10:37] <matsubara> bug 1982
[10:38] <matsubara> cogumbreiro: what was the file that you're trying to upload?
[10:42] <gneuman> night all
[10:48] <dilys> Merge to devel/launchpad/: [trivial]  increase bug list batch size to 50 on staging (r3117: Brad Bollenbach)
[11:05] <cogumbreiro> matsubara, I tried uploading a pot file and a tar.bz2 file
[11:05] <cogumbreiro> matsubara, i can send it to ur email
[11:06] <matsubara> don't need
[11:06] <cogumbreiro> kk
[11:06] <matsubara> cogumbreiro: you've run into a know problem. 
[11:06] <cogumbreiro> oh
[11:06] <matsubara> s/know/known/
[11:07] <matsubara> as a workaround I suggest you to try to upload a tar.gz file and check if it works
[11:07] <matsubara> also there's already a bug reported for that, no need to report it again.
[11:08] <matsubara> have you reported it on Malone?
[11:09] <cogumbreiro> no i didn't
[11:10] <dilys> Merge to devel/launchpad/: [trivial]  include dup information in text pages (r3118: Dafydd Harries)
[11:10] <matsubara> ok, thanks for helping. try the workaround and see if it works for you.
[11:11] <matsubara> I appended the OOPS id you informed to the original bug. It's bug 1982, but it's marked as a private bug and you'll not be able to see it. :-(
[11:20] <cogumbreiro> i will do it in a sec
[11:35] <dilys> Merge to devel/launchpad/: [trivial]  Add the recipient's email address to shipit exports and add a test for it, fix https://launchpad.net/products/malone/+bug/30979 and another test for it. (r3119: Guilherme Salgado)