[00:08]  * StevenK nails _mup_ to the channel.
[00:18] <wgrant> cjwatson: That looks good.
[00:19] <wgrant> cjwatson: indices look as expected.
[00:20] <cjwatson> great.  where should I look on mawson?
[00:23] <cjwatson> ah, deribuntu/baleful by the looks of things
[00:24] <wgrant> cjwatson: Oh, forgot you had access to mawson.
[00:25] <cjwatson> agreed, that looks cromulent to me
[00:25] <wgrant> cjwatson: Indeed, that's the one I tried. As we don't have any oneiric on there at the moment.
[00:25] <cjwatson> admittedly only a single package but should be fine
[00:25] <cjwatson> I think I whined a few years back until I got it
[00:25] <cjwatson> I wonder why Translations-en is only uncompressed + gzip
[00:26] <cjwatson> maybe should add bzip2 versions at some point, but we'll see how things look in production
[00:26] <cjwatson> ah, need to set Translation::Compress for that
[00:26] <cjwatson> OK.  I think this is good though.  Shall I tell lamont to roll that out to production?
[00:27] <wgrant> I can throw in a few more packages if you want, but I think this seems to work.
[00:27] <wgrant> Please do.
[00:27] <wgrant> Even if it does happen to break on prod, it's going to be pretty obvious within two hours.
[00:28] <cjwatson> I'm fine with that.  I'll be watching shortly after I flick the switch anyway
[00:31] <wgrant> Yep.
[00:31] <cjwatson> RTificated
[00:32] <wgrant> Ah, you exposed it through the API?
[00:32] <wgrant> Handy.
[00:35] <cjwatson> Yup.  You suggested that. :-)
[00:41] <lifeless> wgrant: you're rolling back the db-devel patch ?
[00:41] <lifeless> wgrant: what revno is being reverted?
[00:41] <wgrant> lifeless: Yes, just checking up on what qa-tagger is going to do.
[00:41] <wgrant> 10978
[00:47] <lifeless> mail sent about it
[00:47] <wgrant> Thanks.
[00:47] <wgrant> There seems to be a lot of inclarity over how things work now.
[00:52] <lifeless> wgrant: feel free to update the docs everytime someone is confused ;)
[01:15] <poolie> wgrant, is there any more of a traceback for https://bugs.launchpad.net/launchpad/+bug/847485 ?
[01:15] <_mup_> Bug #847485: process-mail.py crashing with Unicode logging errors <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/847485 >
[01:16] <poolie> it might have been my change that provoked it
[01:27] <wgrant> poolie: There isn't.
[01:27] <wgrant> poolie: I was hoping maintenance squads would intervene on Monday.
[01:27] <wgrant> But nobody did :(
[01:27] <poolie> that's strange
[01:28] <poolie> that there is just a one entry traceback
[01:28] <wgrant> Rather.
[03:21] <StevenK> Hah, it has changed
[03:21] <StevenK> PircBot 1.4.6 Java IRC Bot versus PircBotX 1.5, a fork of PircBot, the Java IRC bot
[03:23] <lifeless> what has changed ?
[03:23] <StevenK> I upgraded Jenkins and then updated all of the plugins
[03:24] <wgrant> StevenK: Is canonistack letting you in yet?
[03:24] <StevenK> No
[03:41] <nigelb> wgrant: BAH! I didn't know :(
[03:42] <wgrant> nigelb: 'tis rolled back and I stopped it getting onto staging, no harm done.
[03:42] <nigelb> Sorry!
[03:42] <nigelb> StevenK: As I said the other day, I don' know how to QA it.
[03:43] <wgrant> nigelb: It's pretty difficult to QA it directly.
[03:43] <wgrant> So I poked around a bit and said it was qa-ok.
[03:44] <lifeless> nigelb: I've tweaked https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess
[03:44] <wgrant> Thanks lifeless.
[03:45] <lifeless> nigelb: can you tell me if step 6 is clear enough to you?
[03:45] <nigelb> lifeless: Reading
[03:45] <nigelb> It is :-)
[03:46] <nigelb> wallyworld: I tweaked the javascript unit testing and mockio pages after a few hours of headdesk. There were small typos in the code for both.
[03:47] <nigelb> wgrant: Ah, is that why I don't have a success mail? :)
[03:47] <wallyworld> nigelb: hopefully your head doesn't hurt too much :-) is it ready for a formal review?
[03:47] <nigelb> No, not yet :)
[03:47] <nigelb> I want to write more testss
[03:48] <wallyworld> more tests = good :-)
[04:34] <StevenK> wallyworld!
[04:35] <StevenK> wallyworld: Your presence is *required*
[04:35] <nigelb> That is not good :P
[04:35] <wallyworld> StevenK: hello!
[04:35] <StevenK> wallyworld: Can you log into Jenkins using SSO -- check the box for team membership and see if you get buttons on the right hand side
[04:35] <StevenK> nigelb: ^
[04:36] <StevenK> nigelb: You shouldn't get the box and no buttons, but you should be able to log in
[04:36] <nigelb> we dont sleep dot org?
[04:36] <wallyworld> StevenK: i forgot the url
[04:36] <nigelb> https://lpci.wedontsleep.org
[04:36] <StevenK> That's it
[04:37] <wallyworld> ok, i can see a jenkins console
[04:37] <nigelb> What box am I looking for?
[04:38] <StevenK> wallyworld: So it says "wallyworld | log out" on the top right?
[04:38] <wallyworld> StevenK: yes
[04:38] <StevenK> wallyworld: Are there two icons on the far right of devel and db-devel that say "Schedule a build" when you hover on them?
[04:39]  * wallyworld looks
[04:39] <wallyworld> yes
[04:39] <StevenK> wallyworld: Excellent, thanks
[04:39] <wallyworld> np
[04:39] <StevenK> nigelb: Are you logged in?
[04:39] <nigelb> StevenK: http://people.ubuntu.com/~nigelbabu/jenkins.png
[04:40] <StevenK> Excellent
[04:40] <StevenK> Thanks
[04:40] <nigelb> Did you write java code for this?
[04:40] <wgrant> StevenK: You might want to get it authorized to get launchpad membership by default.
[04:40] <nigelb> If so, respect.
[04:40] <StevenK> Doesn't that require an RT?
[04:40] <StevenK> nigelb: I did not
[04:41] <nigelb> It requires an RT
[04:41] <nigelb> and probably grabbing stuart
[04:42] <nigelb> g26
[04:49] <wgrant> A LOSA may be able to JFDI for you. May not require ISD intervention these days.
[04:51] <poolie> wgrant, lifeless, is it ok if i send up my bug 643223 branch to ec2?
[04:51] <_mup_> Bug #643223: should accept dkim based on from address and signing address belonging to the same person <dkim> <lp-foundations> <mail> <Launchpad itself:In Progress by mbp> < https://launchpad.net/bugs/643223 >
[04:52] <wgrant> poolie: Sure.
[04:53] <jtv> Reviewer wanted: https://code.launchpad.net/~jtv/launchpad/katie-and-gina-are-bad-bad-girls/+merge/75472
[04:55] <wgrant> jtv: I can't review right now, but FWIW the katie celebrity is unrelated to gina.
[04:56] <jtv> But is it related to katie.py?
[04:56] <wgrant> Well, related only in that the celebrity represents katie for historical reasons, and gina's katie module was used to talk to katie.
[04:56] <wgrant> gina's katie.py is not katie.
[04:56] <wgrant> katie is part of dak.
[04:56] <wgrant> gina's katie.py reads dak's DB.
[04:57] <jtv> *cry*
[04:58] <wgrant> Yes
[04:59] <jtv> Oh well, it's not a concern for my branch then.
[04:59] <jtv> That's something: Katie will at least mean Katie, not frontend for Dak.
[05:03] <poolie> where should a script for developer-only use go
[05:03] <poolie> specifically process-one-mail
[05:03] <poolie> in scripts? utilities?
[05:03] <poolie> well, perhaps losas will find it useful, but it's not for production
[05:04] <wgrant> utilities, probably.
[05:04] <wgrant> But maybe scripts...
[05:05] <poolie> well, i'll leave it, someone can move it
[05:05] <poolie> no one complained in review
[05:32] <poolie> hm, what would be a clean way to let this hook into sendmail() so that what's going to be sent is instead printed
[05:32] <poolie> i can easily imagine how to do it by, eg, monkeypatching, or adding a new configuration option
[05:33] <poolie> i guess config is done for the special during-testing code, so perhaps i should do the equivalent?
[05:36] <wgrant> poolie: It's... not config.
[05:37] <StevenK> wallyworld!
[05:37] <wallyworld> yo
[05:37] <wallyworld> you rang
[05:37] <wgrant> poolie: lib/lp/services/mail/sendmail.py, search for isZopeless.
[05:37] <wgrant> poolie: That's the right part of the code.
[05:37] <wgrant> poolie: You can see how it handles testing there.
[05:37] <StevenK> wallyworld: var co = new Y.lp.app.confirmoverlay.ConfirmationOverlay({
[05:37] <wgrant> poolie: (you may need to consult a medical professional afterwards)
[05:37] <poolie> i do
[05:38] <poolie> the simplest thing that would possibly work is just to stick another variable on config
[05:38] <StevenK> Sigh, never mind, I see the error
[05:38] <StevenK> It's confirmationoverlay
[05:38] <wallyworld> excellent! pleased to help
[05:38] <poolie> the results are awesome though
[05:38] <wallyworld> :-)
[05:38] <StevenK> wallyworld: JS has the 77 char limit?
[05:38] <wallyworld> StevenK: sadly yes
[05:38] <wallyworld> imho, in 2011, 78 chars is mental
[05:39] <wallyworld> with wide screen monitors etc
[05:39] <wallyworld> should be at least 120
[05:39] <StevenK> wallyworld: http://pastebin.ubuntu.com/689734/
[05:39] <StevenK> wallyworld: Suggestions how to break that up?
[05:39]  * wallyworld looks
[05:39]  * StevenK would like to say "Where's my hammer?" in a Jeremy Clarkson voice.
[05:39] <wallyworld> StevenK: var ns = Y.lp.app.confirmationoverlay;
[05:40] <wallyworld> var overlay = new ns.ConfoimationOverlay()
[05:40] <wallyworld> or something like that
[05:40] <wallyworld> where ns is short for namespace
[05:41] <StevenK> Obviously
[05:41] <StevenK> :-)
[05:41] <StevenK> wallyworld: Where is your cape? :-P
[05:41] <wallyworld> in the wash, it;s dirty :-)
[05:41] <StevenK> From overuse, I bet
[05:41] <wallyworld> you don't want to know :-)
[05:42] <wallyworld> the Wonder Woman costume is also dirty :-P
[05:43]  * StevenK scratches his own eyes out
[05:43] <StevenK> CAN NOT UNSEE
[05:44] <StevenK> Can I tell Firebug to jump to a line number in a JS file?
[05:45] <wallyworld> StevenK: not sure. i usually just search for the loc
[05:45] <StevenK> Oh, look, it has search
[05:45] <wallyworld> you can type pretty well with no eyes :-)
[05:45] <StevenK> I installed a screen reader, duh
[05:46] <StevenK> And I don't need to look at the keyboard
[05:46] <StevenK> wallyworld: Can haz mumble?
[05:46] <wallyworld> StevenK: ok. just a sec. gotta plug in mic
[05:51] <nigelb> jtv: katie and gina are bad girls? BWAHAHA
[05:51] <jtv> Bad, bad girls.
[05:53] <nigelb> *now* I know why lifeless had included "Don't be cute" with names for services :P
[05:56] <lifeless> not to mention e.g. roomba
[05:58] <nigelb> There is a part of launchpad called roomba?
[05:58] <nigelb> Does it suck? :P
[05:58] <lifeless> there was
[06:00] <wgrant> That's news to me.
[06:00] <wgrant> What was it?
[06:00] <wgrant> librarian-gc?
[06:01] <lifeless> import related
[06:01] <lifeless> see circa 2006
[06:01] <lifeless> there was another, named after one of the other automatic vaccums
[06:01] <lifeless> we've done some terrible things
[06:02] <nigelb> what's the origin of "gina"?
[06:02] <lifeless> dak
[06:02] <lifeless> ish
[06:02] <wgrant> Yeah, it's following the dak naming scheme.
[06:02] <wgrant> I forget who exactly it is named after.
[06:03] <wgrant> I think dak's source says...
[06:03] <nigelb> What is dak again?
[06:03] <nigelb> VCS?
[06:03] <wgrant> dak is Debian's archive software.
[06:04] <wgrant> Like Soyuz, except even more of a trainwreck :P
[06:04] <nigelb> heh
[06:05] <wgrant> Blah, elmo deleted README.names in 2006.
[06:05] <wgrant> Bad elmo.
[06:05] <nigelb> heh
[06:06] <wgrant> "Gina (Gershon)" is listed as a future name. 18 months after gina was written :(
[06:18] <StevenK> wgrant: Land demolish-unused-tables-3-db!
[06:20] <wgrant> StevenK: Can't.
[06:20] <wgrant> StevenK: -2 is not deployed to loganberry/ackee yet.
[06:20] <wgrant> And can't be, because garbo-frequently isn't alive yet.
[06:20] <wgrant> Because puppet.
[06:22] <nigelb> What is the "correct" way to split long javascript strings?
[06:23] <nigelb> long strings in javascript rather.
[06:23] <lifeless> nigelb: 'don't' ?
[06:24] <nigelb> oh, lines of length 268 in js is okay?
[06:25] <lifeless> well depends what you mean
[06:26] <lifeless> js source code? no, our normal rules apply.
[06:26] <lifeless> js sent to the browser? see the various compressors out there.
[06:26] <nigelb> https://code.launchpad.net/%7Enigelbabu/launchpad/bug-title-849121/+merge/75267 (line 189)
[06:26] <nigelb> Its a test
[06:27] <nigelb> (also, why I can't I href to those lines :/)
[07:09] <mrevell> Good morning 'padders
[07:10] <rvba> Morning all, morning mrevell.
[07:10] <nigelb> Morning mrevell / rvba :)
[07:10] <rvba> Hey nigelb.
[07:10] <mrevell> Salut rvba! Qu'est-ce qu'i ce pass en France? (/me realises how much he's forgotten)
[07:11] <nigelb> rvba: Reviewing today? I *may* be able to get you something
[07:11] <mrevell> Namaste nigelb ... I might as well try and do a bad job of greeting everyone in something approaching their local manner :)
[07:11] <nigelb> mrevell: Haha
[07:11] <mrevell> heh
[07:12] <rvba> mrevell: Not so bad actually ;). Well, the rugby cup is on. Oh, and the economy is collapsing.
[07:12] <rvba> nigelb: Okay.
[07:12] <poolie> hello rvba
[07:12] <mrevell> rvba, The first one helps us forget the second.
[07:12] <rvba> True ;)
[07:12] <mrevell> heh
[07:12] <rvba> poolie: Hi!
[07:13] <poolie> could someone read https://code.launchpad.net/~mbp/launchpad/mail-script/+merge/75488 for me?
[07:13] <poolie> it's pretty small
[07:14] <rvba> poolie: I can do that but will have to wait a bit for Gavin to double check that my review is ok.
[07:14] <poolie> that's fine, and it would be appreciated
[07:15] <rvba> Okay then, I'm on it.
[07:39] <rvba> poolie: review done.  I'll ping Gavin (my mentor) when he logs in to double check what is actually my first review on lp ;).
[07:45] <poolie> awesome
[07:55] <adeuring> good morning
[07:58] <allenap> rvba, poolie: I'll do that now.
[08:01] <jtv> henninge: while you're still here, are you free for a pre-imp call in an hour or so?  For old time's sake.  ☺
[08:01] <henninge> jtv: yes, please! ;)
[08:01] <jtv> \o/
[08:01] <henninge> jtv: just ping me
[08:01] <jtv> Will do.
[08:01] <jtv> Tu'ich!
[08:04] <poolie> thanks allenap
[09:07] <jtv> henninge: ping :)
[09:07] <jtv> henninge: can I find you on mumble somewhere?
[09:07] <henninge> jtv: In the orange room. Gimme 2 mins.
[09:07] <jtv> OK
[09:30] <jml> jtv: hello. I've made the fix you required. What happens next?
[09:31] <jtv> jml: otp, but if that's fixed, I'll approve right now
[09:31] <jml> jtv: thanks. could you also land it please? I don't have commit access.
[09:31] <jtv> !
[09:31] <jtv> OK
[09:36] <nigelb> How do I get make lint to 'see' files?
[09:36] <nigelb> I commited something before linting and now make lint doesn't see it.
[09:40] <jtv> nigelb: I'll explain in a moment, hang on
[09:41] <jtv> nigelb: moment has passed.  “make lint” looks for files to check in stages:
[09:41] <jtv> If any files have uncommitted changes, it assumes you want to check those.
[09:41] <jtv> If no files have uncommitted changes, it looks for changes compared to the parent branch, and if there are any, assumes you want to check those.
[09:41] <jtv> If it doesn't find any changes at all, it checks everything.
[09:42] <jtv> nigelb: so try running it right after a commit.
[09:42] <nigelb> okay :)
[09:42] <nigelb> I did the hack of making whitespace changes
[09:42] <nigelb> so it found those :D
[09:43] <rvba> nigelb: You probably also can shelve your current changes for a moment.
[09:43] <nigelb> Lint seems to think i should use [09:44] <wgrant> It's right. == is almost never what you want. It does type coersion.
[09:44] <nigelb> Dear god.
[09:44] <nigelb> That's what its been doing all this while.
[09:44] <nigelb> Also, <3 YUI tests now.
[09:45] <nigelb> Easy to run 'em.
[09:49]  * nigelb curses lint.
[09:55] <nigelb> Erm, help. I have this huge string in a line of javascript (for a test), how do I split it?
[09:55] <nigelb> 'foo' + 'bar' + 'baz'?
[09:55] <jml> nigelb: think so.
[09:55] <nigelb> jml: Thanks.
[09:55] <nigelb> its going to end up looking ugly :P
[10:00] <rvba> nigelb: if the string is big but not huge, you can use the 'array trick' (see lib/lp/soyuz/javascript/tests/archivesubscribers_index.js)
[10:00] <rvba> nigelb: if the string is really huge and is html code, the right place for this is the .html file associated with the js test code.
[10:01] <rvba> nigelb: for an example of that, bzr grep derivedtd-template.
[10:02] <nigelb> let me check out the array trick :-)
[10:03] <nigelb> Oh, the array trick is *neat*
[10:10] <nigelb> rvba: Can I add https://code.launchpad.net/~nigelbabu/launchpad/bug-title-849121/+merge/75267 to your list? :)
[10:10] <rvba> nigelb: Sure.
[10:11] <nigelb> Yay for a branch where I knew most of what I wanted to do :-)
[10:36] <jml> jtv: any idea when that branch is going to land? I don't actually know the landing process.
[10:37] <jtv> jml: I'm having some trouble landing it myself.
[10:38] <jtv> jml: it looks like “bin/ec2 land” won't do it; wants a GPG key I don't have.  Do we have anyone who's more familiar with the project?
[10:38] <jml> jtv: benji, I think.
[10:39] <wgrant> which project?
[10:39] <wgrant> launchpadlib?
[10:39] <jml> wgrant: yes.
[10:39] <jml> personally, I would like to have landing and release processes for launchpadlib & other lazr projects in the source trees
[10:39] <jml> (because guess what I'm going to ask for after landing things?)
[10:39] <wgrant> https://dev.launchpad.net/HackingLazrLibraries
[10:40] <wgrant> It's not PQM-managed, let alone supported by ec2test :)
[10:40] <jml> ahh, thanks.
[10:43] <jml> https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520
[10:54] <jtv> jml: how do I run the tests?
[10:55] <jml> jtv: buildout, then ./bin/test
[10:55] <jtv> Thanks.
[10:55] <jtv> How do I get buildout?
[10:57] <jml> jtv: it's documented here: <https://dev.launchpad.net/HackingLazrLibraries>. Essentially, 'python bootstrap.py' and then './bin/buildout'.
[10:58] <jml> I find the dev wiki hard to read. I think it's the grey text.
[10:59] <jtv> It's also a lot of work just to run tests.
[10:59] <jtv> “a non-system Python, or a virtualenv executable that does not include site-packages, is highly recommended, and may be required”
[11:02] <jtv> “Download error: [Errno -2] Name or service not known -- Some packages may not be found!”
[11:03] <jtv> May be normal.
[11:05] <wgrant> jml: There's a bug for that.
[11:05] <jml> wgrant: yeah. I might have filed it.
[11:05] <jml> jtv: that's the glory of buildout. If it's any consolation, it's even more work just to run the tests for Launchpad itself.
[11:06] <jml> jtv: that's not normal.
[11:06] <jtv> Well, the tests ran.
[11:06] <wgrant> Did they pass too?
[11:06] <wgrant> jml: Bug #666143 is for the blog, which is a similar theme.
[11:06] <_mup_> Bug #666143: Launchpad blog uses grey text <css> <lp-web> <Launchpad itself:Won't Fix> <Launchpad Blog WordPress Theme:Triaged> < https://launchpad.net/bugs/666143 >
[11:06] <wgrant> Hah, closed.
[11:06] <jtv> wgrant: yes
[11:07] <wgrant> Oops, still open for the theme.
[11:08] <jtv> jml: landed.
[11:09] <jml> jtv: thanks!
[11:09] <jml> jtv: could I trouble you to review the hacking documentation branch I just put up? https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520
[11:09] <jml> jtv: it's waffer thin
[11:09] <jtv> jml: not tonight, sorry.
[11:09] <jml> jtv: no worries. thanks.
[11:09] <jml> rvba: could I trouble you to review this branch? https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520 I'd land it myself sans review if I had commit access.
[11:14] <rvba> jml: Sure. I'll take care of it after lunch.
[11:21] <jml> rvba: thanks.
[11:24] <nigelb> wgrant: How do I turn on feature flags?
[11:24] <nigelb> You told me a while back and now I forget :/
[11:24] <wgrant> nigelb: https://launchpad.dev/+feature-rules
[11:24] <nigelb> Thanks!
[11:27] <nigelb> Now I need to figure out which was the feature Julian and I were confused about.
[11:29] <nigelb> What's priority?
[11:30] <nigelb> (in the context of feature flags)
[11:32] <wgrant> nigelb: The highest priority matching rule wins.
[11:32] <wgrant> So, say I have 'default' and 'pageid:Person:+index' rules for a particular flag.
[11:32] <nigelb> what's wrong with this line?
[11:32] <nigelb> (code.incremental_diffs.enabled, default$, 1, true)
[11:32] <wgrant> default$?
[11:32] <wgrant> What's that %?
[11:33] <wgrant> $
[11:33] <nigelb> from the https://launchpad.dev/+feature-info page.
[11:33] <nigelb> default$ 	
[11:33] <nigelb> The default scope.  Always active.
[11:33] <wgrant> Ah, that's a bit confusing.
[11:33] <wgrant> That describes the regular expression that is used to match the scope in the rule.
[11:34] <wgrant> so the rule would be something like 'code.incremental_diffs.enabled default 1 true'
[11:34] <nigelb> GAH
[11:35] <nigelb> On each line: (flag, scope, priority, value),
[11:35] <nigelb> How confusing.
[11:35] <jelmer> rvba: hi, can I add a small merge proposal to your queue?
[11:39] <rvba> jelmer: Yes you can ;). You'll be number 3. (I'm working on number 1)
[11:40] <jelmer> rvba: thanks!
[11:40] <rvba> np
[11:45] <jkakar> jml: You merged it!  AWESOME! :)
[11:46] <jml> jkakar: :D
[11:46] <jkakar> jml: Man, that feels so good... that's the longest living branch I've ever had. :)
[11:46] <jkakar> Thanks for picking it up and getting it landed, much appreciated.
[11:47] <nigelb> what do I do to see a diff in an MP for local codehosting
[11:47] <jml> jkakar: my pleasure
[11:47] <jml> jkakar: I know the feeling. I personally resent every unlanded branch I have.
[11:49] <jkakar> jml: Yep, me too. :)
[11:53] <wgrant> nigelb: 'make sync_branches' should scan the branches and generate requested MP diffs.
[11:54] <nigelb> wgrant: I just realized that branch didn't have contnet.
[11:54] <nigelb> This means I have to setup local codehostign to fix a bug I can't even see! :P
[11:55] <wgrant> Heh.
[11:55] <wgrant> make run_codehosting
[11:56] <wgrant> Add http://paste.ubuntu.com/689936/ to your ~/.ssh/config
[11:56] <G> or the make run all option (it's run_all right?)
[11:56] <wgrant> utilities/make-lp-user nigelb
[11:56] <wgrant> bzr push lp://dev/~nigelb/+junk/something
[11:56] <wgrant> G: Or that, yeah.
[11:57] <G> https://dev.launchpad.net/Code/HowToUseCodehostingLocally describes it all
[11:57] <nigelb> I did see that.
[11:58] <nigelb> But I was trying to figure out the effort of fixing a bug I can't see :p
[11:58] <nigelb> (I still can't see it, until I go through all the hoops!)
[12:00] <nigelb> wgrant: heh, a bug you filled seems to be a dup of one I filed
[12:01]  * nigelb marks
[12:01] <nigelb> bug 847556 vs bug 847682
[12:01] <_mup_> Bug #847556: Person picker in the MP ignored the fact that I filled out a review type <Launchpad itself:Triaged> < https://launchpad.net/bugs/847556 >
[12:01] <_mup_> Bug #847682: Can no longer set review type in "Request another review" person picker <disclosure> <person-picker> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/847682 >
[12:01] <wgrant> ni	Bah, sorry.
[12:02] <wgrant> Why does irssi do that...
[12:02] <nigelb> I'm duping mine to yours
[12:02] <G> wgrant: too quick w/ the tab & typing and latency I find
[12:03] <nigelb> wgrant: You're is marked higher than the one I field :D
[12:03] <nigelb> *filed
[12:03] <wgrant> G: Yeah, irssi is currently running on a slow ARMv5 machine which is also a file+print+mail server, so the load sometimes gets a bit high and it lags.
[12:03] <lifeless> nigelb: generally we dup onto the lower bug #
[12:03] <wgrant> G: And about 18 months ago it started interpreting tabs literally during high lag.
[12:04] <wgrant> It's annoyinfuriating.
[12:04] <wgrant> Haha
[12:04] <wgrant> There we go again.
[12:04] <nigelb> His is marked critical, mine is low.
[12:04] <nigelb> and has the right tags :)
[12:04] <wgrant> How did that get marked low :/
[12:04] <G> lifeless: an unnamed bug tracker & project I used to work with had the policy, dupe to the 'best' bug :)
[12:05] <nigelb> That's my policy most of the time :)
[12:05] <lifeless> wgrant: irssi and tabs with lag... thats been like that for many many years
[12:05] <wgrant> lifeless: Hm. Only noticed it in the last couple.
[12:05] <wgrant> Odd.
[12:06] <G> yeah, it used to happen a lot on my Linode
[12:06] <lifeless> wgrant: its the paste detection heuristic
[12:06] <wgrant> Perhaps load has just increased too much.
[12:06] <wgrant> May need to offload some stuff to a pandaboard.
[12:06] <nigelb> wgrant: ARM macine? Your phone? :P
[12:06] <wgrant> But they are no good for routers and fileservers :(
[12:06] <lifeless> wgrant: http://irssi.org/about under 'paste detection'
[12:07] <G> wgrant: they aren't what a pity
[12:07] <lifeless> wgrant: its retarded but upstream consider it a feature
[12:08] <wgrant> lifeless: That is indeed reasonably retarded.
[12:08] <lifeless> if you have less text than the multi-line threshold, and faster-text than the input buffer heuristic, what you see happening will happen
[12:08] <nigelb> GAH. I have just wondered why patches have an edit sprite. Despite me adding them.
[12:08] <G> lifeless: can't you turn off?  (I thought you could)
[12:08] <lifeless> http://irssi.org/documentation/settings paste_detect_time = 5msecs
[12:08] <lifeless> Irssi will detect pastes when your input has less than this much time between lines.
[12:09] <lifeless> except its a lie
[12:09] <lifeless> its not line based ;)
[12:09] <G> ahh you can yeah
[12:09] <wgrant> paste_detect_time = pleasedie
[12:09] <nigelb> heh
[12:09] <lifeless> and/or paste_detect_keycount = 5
[12:09] <nigelb> wgrant: alternatively, set your irssi as a bouncer :)
[12:09] <lifeless> I think its the latter for the tab breakage
[12:10] <lifeless> note the special special special docs about it on that page
[12:13] <G> wgrant: I guess the other solution is to write a script to detect it happening ;)
[12:14] <lifeless> night all
[12:15] <G> lifeless: have a good one
[12:15] <nigelb> night lifeless
[12:16] <wgrant> Night lifeless.
[12:16] <nigelb> Is bug 845339 already?
[12:16] <_mup_> Bug #845339: Incorrect sorting on "Last Modified" or "Last Commit" in Code page <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/845339 >
[12:17] <nigelb> Not able to reproduce it in production
[12:17] <wgrant> nigelb: It depends on the browser.
[12:17] <nigelb> Firefox 8 works.
[12:19] <nigelb> Ohyes. Chrome.
[12:20] <wgrant> Still reproducible there?
[12:20] <nigelb> yup
[12:21] <nigelb> Hrm, everyone has taken jtv's email to heart! :-)
[12:23] <nigelb> rvba: Hi, I didn't understand the first bit
[12:26] <rvba> nigelb: I think you should keep the logic that was in place before your change and create the list of the invalid bugs like it was done before instead of building it like you do now.
[12:26] <rvba> nigelb: invalid = set(bugs) - set(bug_ids)
[12:26] <nigelb> I can't do that anymore
[12:26] <nigelb> since I don't get bugids
[12:26] <nigelb> I get bugtask objects instead
[12:27] <nigelb> so, doing that means looping through the list again.
[12:27]  * rvba checks again.
[12:29] <nigelb> (interestingly, that logic was written by me as well)
[12:30] <rvba> nigelb: why do you need to deal with bugtasks instead of bugs?
[12:30] <nigelb> rvba: to get the bug title
[12:30] <nigelb> earlier I was just getting bug ID
[12:31] <rvba> I see.
[12:46] <rvba> nigelb: I guess I'll let you get aways with this if you add a comment saying that we're left with the invalid bugs before the second loop ;)
[12:46] <rvba> s/aways/away/
[12:46] <nigelb> rvba: heh, okay :)
[12:47] <nigelb> I hope I didn't make your eyes bleed with that JSON ;)
[12:47] <nigelb> s/bleed/bleed too much/g
[12:47] <rvba> my eysdqsd sqdd sf.
[12:47] <rvba> (I can't see the keyboard anymore)
[12:48] <nigelb> haha
[12:48] <rvba> ;)
[12:58] <rvba> Hi jcsackett!
[12:58] <jcsackett> good morning, rvba. :-)
[12:58] <jcsackett> or good afternoon, in your tz.
[12:59] <rvba> Afternoon, right, good morning to you ;)
[13:01] <jcsackett> timezones are too much to deal with on low levels of coffee. :-)
[13:01] <rvba> hehe
[13:03] <rvba> jcsackett: LP seems to have a problem generating diffs atm.
[13:03] <StevenK> merge-proposal-jobs failed to run
[13:03] <jcsackett> StevenK: someone on maintenance looking at that?
[13:03] <soren> This has been a fascination of mine for a while.. It would seem natural that inhabitants of a country that spans 6 timezones were able to deal with timezones literally in their sleep :)
[13:03] <jcsackett> or does it just appear to be one off death?
[13:05] <wgrant> jcsackett, rvba: See #-ops
[13:05] <jcsackett> wgrant: looking in it now.
[13:06] <G> soren: it's my hope that we ditch TZs all together ;)
[13:06] <jml> soren: they are funny timezones though
[13:06] <jml> soren: I mean, they call their west coast timezone, "Pacific time", as if the great big blue wobbly thing outside their windows stretched only a mile out from the coastline
[13:10] <jml> hey, I just learnt a thing about source package publishing
[13:10] <jml> which is that SPPH.sourceFileUrls() will give you some interesting stuff that's not the same for every package.
[13:11] <james_w> that's links to the .dsc .orig.tar.gz etc?
[13:11] <james_w> or whatever makes up that package?
[13:12] <jml> james_w: yeah. sometimes there's a .debian.tar.gz (e.g. w/ gtk+2.0-0), other times just a diff.
[13:12] <james_w> yeah
[13:13] <james_w> the easy way of reliably getting it is the slow one
[13:13] <james_w> fetch them all and call dpkg-source -x passing the .dsc file with them all in the same dir
[13:13] <james_w> then grab the debian/ dir from the resulting directory
[13:13] <jml> james_w: *awesome*
[13:14] <james_w> you could write something 90% that extracts what you want from the debian.tar.gz or the diff.gz
[13:14] <james_w> but if you want 100% that's the easy way to do it
[13:14] <jml> james_w: I want 100%. Have too many other 90% things in this. They multiply and get smaller pretty quickly.
[13:15] <james_w> yeah
[13:16] <james_w> actually, I'm not experienced with it, but just looking in debian.tar.gz if one is there may be 100% for that subset
[13:16] <james_w> and if there is no diff.gz then there is only one tarball to look in, so that's 100%
[13:16] <james_w> so it's only the diff.gz case that is a bit tricky
[13:16] <james_w> but given that maybe just coding one thing is the easiest for now
[13:17] <jml> +1
[13:18] <jml> james_w: did you not have to solve this for the udd importer?
[13:18] <james_w> jml, we need the whole thing for that
[13:18] <james_w> so I never looked for optimizations
[13:18] <james_w> but yeah, it has code to download the files and extract them
[13:18] <james_w> maybe split across two different places
[13:19] <jml> heh
[13:21] <james_w> import_package.py:dget
[13:22] <james_w> import_dsc.py:SourceExtractor and subclasses in bzr-builddeb
[13:22] <james_w> it doesn't use that API you mention
[13:22] <james_w> and I'm not sure if it's going to be directly applicable to what you want
[13:22] <james_w> the extraction probably does more than you need
[13:23] <nigelb> rvba: I'm fairly sure I updated that MP with the changes you requested. I suspect something broke with diff generation, so you can't review it for a bit anyway.
[13:24] <rvba> nigelb: indeed, wgrant is working on it.
[13:24] <wgrant> Well, I'd prefer to drop it on abentley or a maintenance person :)
[13:24] <wgrant> s/a/another/
[13:25] <rvba> nigelb: I'll grab the branch directly.
[13:25] <nigelb> \o/
[13:25] <jml> james_w: thanks.
[13:28] <nigelb> wgrant: do you have a quick minute to point me in the right direction for bug 843415?
[13:28] <_mup_> Bug #843415: Can't assign people on bugs that affect many projects <regression> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/843415 >
[13:28] <wgrant> nigelb: Do you feel like optiming all of lazr-js?
[13:28] <wgrant> optimising
[13:28] <nigelb> :/
[13:28] <nigelb> I thought it was a simple bug.
[13:28] <wgrant> Well, you could "fix" it by adding an assignee edit link.
[13:29] <nigelb> Yeah, that's what I was looking to fix.
[13:29] <cjwatson> wgrant: would you have time to review https://code.launchpad.net/~cjwatson/launchpad/bzip2-translations/+merge/75547 ?
[13:29] <nigelb> I'm at bugtask-tasks-and-nominations-table-row.pt and can't find anything relevant.
[13:29] <cjwatson> is indeed trivial.
[13:30] <cjwatson> jml: 'man dpkg-source' for the various source package format
[13:30] <cjwatson> s
[13:30] <jml> cjwatson: thanks.
[13:31] <jml> cjwatson: this learning thing is fun
[13:32] <cjwatson> james_w: sadly I'm fairly sure there's a non-zereo number of packages where the tarball has some debian/ bits in it and the diff just mildly patches them.  You're probably right in the case of debian.tar.gz
[13:32] <danilos> matsubara, hi, I've put up a MP for review for oops-tools, I hope you can take that
[13:33] <wgrant> cjwatson: Hm, difficult.
[13:33] <wgrant> Want me to land it?
[13:33] <cjwatson> wgrant: difficult?
[13:34] <nigelb> Probably because diff thing isn't working.
[13:34] <wgrant> Yeah, diffs are broken at the moment.
[13:34] <wgrant> But loggerhead worked.
[13:34] <wgrant> To see the whole one line of non-test diff.
[13:35] <cjwatson> Ah, my sarcasm detector was broken I think.
[13:35] <cjwatson> wgrant: yes please, landing would be good
[13:37] <cjwatson> james_w: indeed, on checking, dpkg-source removes any debian/ directory it finds in the upstream tarball before unpacking debian.tar.gz
[13:37] <cjwatson> which is a much better design than we used to have
[13:37] <jml> rvba, allenap: would one of you please land that branch? I don't have commit access. (https://code.launchpad.net/~jml/launchpadlib/hacking-documentation/+merge/75520)
[13:38] <allenap> jml: Okay, I'll give it a go.
[13:38] <jml> allenap: thanks.
[13:44] <rvba> nigelb: re-reviewed. I've a few more nitpicks but I've asked Gavin to do that final check anyway. After that we'll be good to land.
[13:45] <nigelb> rvba: cool! Thanks :)
[13:45] <rvba> Welcome.
[13:56] <matsubara> danilos, will do. thanks!
[14:00] <matsubara> danilos, I didn't get any email about it yet.
[14:01] <matsubara> oh, just read the backlog. diffs are broken...
[14:31] <wgrant> cjwatson: That branch has been in ec2 for a little while now.
[14:47] <cjwatson> wgrant: great, thanks
[14:56] <jml> LP mail is slow today.
[15:34] <nigelb> rvba: Anything else I need to do?
[15:34] <nigelb> Just wait for allenap? :)
[15:34] <allenap> nigelb: I'm looking at it now.
[15:35] <nigelb> AH!
[15:35] <jelmer> hi jcsackett, can I add a branch to your queue?
[15:35] <nigelb> allenap: I just pushed the last set of changes.
[15:35] <allenap> Okay.
[15:38] <jcsackett> jelmer: you can indeed.
[15:39] <jelmer> jcsackett: thanks :) the MP is at https://code.launchpad.net/~jelmer/launchpad/follow-http-redirects/+merge/75561
[15:39] <jcsackett> i'll start reviewing it in just a moment. :-)
[15:53] <matsubara> danilos, replied
[15:59] <nigelb> diffs still broken?
[16:00] <rvba> nigelb: apparently yes.
[16:00] <nigelb> Ouch.
[16:03] <nigelb> If I visit https://code.launchpad.net/lp-production-configs, for which I don't have permission, Launchpad tells me - "Launchpad Production Configs has 0 active branches."
[16:03] <nigelb> But the very next line is "There were 5 commits by 3 people in the last month. "
[16:03] <nigelb> Pretty much makes the first line a lie. Is this known?
[16:04] <jcsackett> jelmer: quick question; i see this code apparently captures too many redirections, but i see no tests for that. is it tested elsewhere?
[16:04] <jelmer> jcsackett: do_catching_redirects will raise TooManyRedirections in that case
[16:05] <jcsackett> jelmer: that's what i see, but i don't see a test making sure everything works as expeced (e.g. i do see a test for forbidden conditions).
[16:05] <jelmer> jcsackett: ah, yeah, that's true - it's indeed only tested in bzr itself
[16:05] <jml> jkakar: hi
[16:06] <jelmer> jcsackett: would you like me to add a test for that in lp as well?
[16:06] <jcsackett> jelmer: i think it would probably be appropriate, since the lp buildbot doesn't check the bzr tests, to my knowledge.
[16:06] <jcsackett> (and given that my understanding is those also take several hours, that's a very good things. :-P)
[16:07] <jelmer> it's not that bad actually, I think it was just 10 minutes on an 8 core machine :)
[16:08] <jelmer> anyway, I'll have a look at adding a test
[16:09] <jcsackett> jelmer: cool. i've marked the MP as Needs Fixing so i'll remember to take another look. aside from the test, this looks good, so i'll be happy to approve once that's addressed. :-)
[16:10] <jcsackett> nigelb: regarding the lying code page, i'm checking if there's a bug now. we have several related to the disclosure work that are about confusing messages like that.
[16:10] <jml> jkakar: so now I'm trying to use the launchpadlib testing that just got in.
[16:10] <jml> nigelb: known bug. It's filed somewhere.
[16:10] <nigelb> jcsackett: I just filed one, feel free to dup it if there's another
[16:10] <jcsackett> will do. :-)
[16:10] <jml> jkakar: I'm confused as to how to assign collections.
[16:13] <jml> jkakar: and by how the code is supposed to work in that case.
[16:13] <nigelb> jml: Its fun to catch LP lying :)
[16:13] <jml> jkakar: I want to have lp.distributions['ubuntu'] return something useful.
[16:14] <jcsackett> nigelb: can't find any dupes of it, so i've triaged your bug and tagged it with disclosure. concievably it will be addressed as part of our work.
[16:15] <nigelb> cool!
[16:15] <rvba> nigelb: jcsackett seems related to 656941.
[16:16] <rvba> Not the exact same location.
[16:17] <jcsackett> rvba: no, but close enough one could be made a dupe of the other and the summary updated. but i do sort of wonder why that bug wasn't added to the disclosure tag ...
[16:18] <nigelb> I wonder if its simple enough to check if the value of branches is 0 and based on that hide the next sentence.
[16:18] <rvba> nigelb: This won't be sufficent to fix the bug completely I think.
[16:18] <rvba> sufficient*
[16:19] <nigelb> Ah right. Public and private.
[16:19] <nigelb> Tricky!
[16:22] <rvba> nigelb: I'll be off soon.  I'm off tomorrow but I think allenap will be delighted to give you a hand to land your branch when it's fixed.
[16:23] <nigelb> rvba: Ah, thanks again for all the nitpick ;-)
[16:23] <rvba> You're welcome nigelb.
[16:23] <nigelb> Like jtv said in his email, its probably sad when there isn't nitpick :)
[16:23] <jcsackett> nigelb: that depends entirely on how long one reviewer's queue is. :-P
[16:24] <nigelb> heh
[16:32] <nigelb> allenap: Woah. I just learned a lot of Javascript! Thanks :-)
[16:34] <allenap> nigelb: Hehe, cool. Btw, I like the change; it's a neat feature.
[16:36] <nigelb> allenap: It was easier than all the changes I made too. I touched this code before, so I knew what I was doing most of the time :-)
[16:43] <jelmer> jcsackett: I've added a test for the too many redirections issue
[16:44]  * jcsackett goes to look
[16:44] <sinzui> nigelb, you and I are thinking about the issue in the same way. The template already uses the convention of checking the count. The bad chunk violates the rule
[16:44] <sinzui> nigelb, you are now subscribed to the master bug
[16:45] <sinzui> I think you could fix this in a few minutes
[16:46] <jcsackett> jelmer: r=me.
[16:46] <jelmer> jcsackett: thanks!
[16:48] <nigelb> sinzui: But that's only a partial fix.
[16:49] <nigelb> It would fail in the event of a project with public and privuate branches (is that possible?)
[16:50] <nigelb> sinzui: Oh wait. My concerns depends on how private branches work. I don't know :-)
[16:54] <sinzui> nigelb, we show private bug stats in all bug stats because it is too expensive to separate them
[16:55] <sinzui> nigelb, We know something is amiss on the page because of the contradictory statement, and we can see in the template that other parts avoid contradictory statements. only the block we see is misbehaving
[16:57] <nigelb> sinzui: Ah. So, this should be a good fix because its expensive for the "better" fix?
[16:57] <nigelb> I'll take it to go ;-)
[16:57] <sinzui> yes. if there is one public branch, we do want to show data
[16:58] <sinzui> also note that there are now three reported bugs about this issue now, and all are about the one chunk of text, so I believe the hard fix is overkill. Someone has to prove the data is exposed elsewhere to justify a deeper fix
[17:01] <nigelb> heh :)
[17:01] <nigelb> Because this is very apparent. The other situation less so.
[17:03] <nigelb> allenap: Y.Lang.hasOwnProperty isn't working :(
[17:03] <nigelb> (javascript tests++)
[18:00] <nigelb> Any JavaScript / YUI person around for some debugging help?
[18:50] <allenap> nigelb: var a = {fred: 123}; a.hasOwnProperty("fred") // true
[18:50] <allenap> It's part of JavaScript rather than YUI.
[18:55] <nigelb> Oh.
[18:55] <nigelb> allenap: that helps! Thanks
[19:03] <m4n1sh> sinzui: is lp-release-manager-tools mature enough as per your expectations?
[19:05] <nigelb> sinzui: That bug sounds way too easy. Want me add tests as well? :-)
[19:07] <sinzui> m4n1sh, thy are for me
[19:11] <nigelb> allenap: Pushed. Do you have time for another review of that MP?
[19:11] <allenap> nigelb: Sure :)
[19:17] <allenap> nigelb: Looks good. One *tiny* thing:
[19:17] <allenap> bugs_ids = set([int(link[len('/bugs/'):]) for link in links])
[19:17] <nigelb> Sure
[19:17] <allenap> The outermost [] braces are not needed.
[19:17] <nigelb> ah
[19:17] <nigelb> since its a set anyway.
[19:17] <nigelb> Right!
[19:18] <allenap> nigelb: I'll land it as it is; it's not worth changing.
[19:18] <allenap> Unless you're very keen :)
[19:19] <nigelb> allenap: wait, doing set(1,2,3) gives me a traceback in python shell.
[19:20] <allenap> nigelb: That does, but try set(i for i in 1,2,3), which is equivalent to set((i for i in 1,2,3)), i.e. set() gets passed a generator.
[19:20] <nigelb> ah
[19:21] <nigelb> SyntaxError: Generator expression must be parenthesized if not sole argument
[19:22] <allenap> Grr, sorry, let me try again!
[19:23] <allenap> set(i for i in (1,2,3)), which is equivalent to set((i for i in (1,2,3)))
[19:23] <nigelb> aha!
[19:34] <nigelb> allenap: Ah, you landed it? :)
[19:34] <sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/private-bug-5/+merge/75614
[19:35] <allenap> nigelb: Well, it's in ec2, but if you have another change I can restart it, no problem.
[19:35] <nigelb> nah, let it go :-)
[19:45] <jcsackett> sinzui: sure.
[19:45] <sinzui> thank you
[19:46] <jcsackett> sinzui: this appears to be a big diff. lemme finish poking at one thing first and then i'll get into it. :-)
[19:47] <sinzui> jcsackett, yes. it is larger than anticipated since I updated some supporting classes. I think you will find the implementation is often trivial, though I wanted better tests than what I started with
[19:48] <sinzui> jcsackett, oh yes, I neglected to mention I wrote a test for every class before I made my change...that double the change size
[19:49] <nigelb> sinzui: I'm assigining that bug to myself.
[19:49] <sinzui> nigelb, thanks you very much
[19:53] <jcsackett> sinzui: dig, that'll help me sort the diff out, thanks. :-)
[20:20] <nigelb> sinzui: Hey, do you have a minute for a bit of UI help?
[20:20] <nigelb> I tried fixing bug 806660. It ended up looking very ugly with too much whitespace.
[20:20] <_mup_> Bug #806660: "Add a new address" in e-mail settings does the wrong thing when pressing Enter <easy> <ui> <Launchpad itself:Triaged by nigelbabu> < https://launchpad.net/bugs/806660 >
[20:20] <benji> has anyone seen something like this when trying to run the LP tests? OperationalError: FATAL:  role "benji" does not exist
[20:21] <benji> This is on a brand new oneiric install
[20:39] <sinzui> nigelb, are you splitting the forms or adding a keypress handler?
[20:40] <nigelb> I tried splitting the forms.
[20:40] <nigelb> Its not a pretty approach for the UI.
[20:44] <sinzui> nigelb, I wonder if we can hack the add button to have accesskey="Enter"
[20:45] <nigelb> Hrm, I didn't think of that. That should be easier for sure.
[20:45] <nigelb> The last time I tried it in JS, there was an issue with IE.
[20:45] <sinzui> nigelb, of when something is entered, the other two buttons are deactivated, so the browser will choose the only active button
[20:45] <nigelb> Oh.
[20:45] <nigelb> deactivate the otheres on focus?
[20:46] <nigelb> and activate it back when focus is lost for the text box?
[20:46] <sinzui> nigelb, We may not need hacks. I looked at the template
[20:47] <nigelb> oh.
[20:48] <sinzui> The template is doing the actual layout, explicitly stating which chunk of the for to render. I think we want to call the form twice, each time only rendering the blocks we want
[20:49] <nigelb> Didn't parse that :-)
[20:52] <sinzui> nigelb, something like this: http://pastebin.ubuntu.com/690315/
[20:54] <sinzui> nigelb, I think the table elements need reconciliation in my paste. We only want to render the add field and button in the second call of the form.
[20:54] <nigelb> sinzui: heh, that's very close to what I did
[20:54] <nigelb> Let me see if yours renders better than the mess I made
[20:59] <jcsackett> sinzui: took a bit to read through all the tests, but r=me.
[21:00] <sinzui> jcsackett, thank you for your patience
[21:02] <jcsackett> sinzui: thank you for yours, given the time. :-)
[21:05] <nigelb> sinzui: that didn't work.
[21:05] <nigelb> one form cannot be inside another form.
[21:06] <nigelb> actually, ignore me.
[21:06] <nigelb> I was running the wrong launchpad.
[21:34] <bac> lifeless: ping
[21:55] <lifeless> bac: hi
[21:56] <bac> hi lifeless ... i've been looking at your branch for bug 759467
[21:56] <_mup_> Bug #759467: incomplete-with-response searches require complex searches <Launchpad itself:Triaged by lifeless> < https://launchpad.net/bugs/759467 >
[21:56] <lifeless> bac: cool
[21:56] <bac> lifeless: i'm unsure of your intentions, though.  do you want someone to pick it up or do you plan to fix and land it?
[21:56] <bac> it has considerable bit rot due to the BugSummary work
[21:57] <lifeless> bac: I don't have the cycles to pick it up myself for a few weeks
[21:57] <lifeless> need to get the SOA stuff rolling or risk blocking red
[21:57] <bac> right
[21:57] <lifeless> I would -love- it if someone else picks it up
[21:57] <lifeless> if noone does, it still needs doing and I have the most context on the problem so would indeed pick it up eventually
[21:58] <lifeless> if you're in a position to pick it up, I would love that.
[21:58] <bac> as you said in my MP, the escalated bug i worked on really needs this in place to properly proceed
[21:58] <bac> lifeless: i may need to pick your brain a bit to get through all of the conflicts caused by BugSummary
[22:00] <bac> for instance, would BugSummary.status be the real db status with INCOMPLETE_WITH*_RESPONSE or the visible one?
[22:01] <lifeless> bac: it would transition
[22:01] <lifeless> so 2 stages
[22:01] <lifeless> stage one, we start querying for both the current semi-status + date, *and* the actual explicit status
[22:02] <lifeless> on bugsummary and bug queries
[22:02] <lifeless> we also start *writing* explicit status at this point
[22:02] <lifeless> then we do a garbo job to rewrite every bugtask's status from the semi-status+date into an explicit status
[22:03] <lifeless> lastly we drop the garbo job, and the querying of both the semi status +date
[22:03] <lifeless> so bugsummary.status in stage one will be mixed, until the garbo job has migrated all the rows of bugtask across
[22:03] <lifeless> one sec
[22:04] <lifeless> back
[22:05] <lifeless> the contents of the bugsummary table don't need to be explicitly updated: as the garbo updates bugtask rows, the triggers will auto-update bugsummary for us.
[22:05] <bac> so for writing, the db procedures will simply need to start using BugTask._status rather than BugTask.status
[22:05]  * lifeless refreshes his memory
[22:05] <bac> _status is real, what is in the db
[22:05] <bac> status is the model view showing INCOMPLETE
[22:05] <lifeless> yes
[22:06] <lifeless> ideally we would migrate all the model code to be explicit too, but thats got lots of complicated bits from what I could see
[22:06] <lifeless> and the performance / clarity wins are all db-side.
[22:07] <lifeless> righto, so my branch has all the stage one stuff *except* making queries on bugsummary also include the two new enums
[22:07] <jcsackett> can anyone think of a reason why responses from answers.launchpad.dev is substantially slower than from launchpad.dev?
[22:08] <lifeless> jcsackett: nope :)
[22:08] <jcsackett> i'm running in a vm setup for remote access per the wiki; can't figure out why subdomains are *so* much slower.
[22:08] <jcsackett> lifeless: well damn. :-P
[22:09] <bac> lifeless: ok, i think i have a shove in the right direction
[22:09] <bac> jcsackett: i run with that configurationa and haven't seen such a thing
[22:09] <lifeless> bac: I've just re-read the branch and yeah, I think that that is all thats missing (modulo surprises)
[22:10] <jcsackett> bac: yeah, i've run this way before (new vm, but everything is roughly the same) and haven't seen this either. very perplexed.
[22:10] <lifeless> for clarity 'all that is missing is teaching bugsummary queries that want INCOMPLETE to want INCOMPLETE + INCOMPLETE_WITH_RESPONSE + INCOMPLETE_WITHOUT_RESPONSE'
[22:10] <lifeless> (unless they really want to be narrower anyway, in which case INCOMPLETE + one of the others)
[22:11] <bac> lifeless: right, plus resolving all of the conflicts towards using BugSummary not BugTask in queries
[22:20] <lifeless> bac: yes, though they should be mainly just take trunk's side
[22:21] <lifeless> bac: I think you'll find, if you diff .BASE.THIS that the local changes are all INCOMPLETE -> INCOMPLETE + ... ,or status -> _status
[22:24] <lifeless> flacoste: I think you win on the 'find oldest regression to date'
[23:24] <poolie> hi all