[02:45] <mwhudson> hm
[02:45] <mwhudson> what to do for the last ~2 hours of work on a friday afternoon
[02:50] <lifeless> mwhudson: pawn?
[02:50] <lifeless> mwhudson: land that bzr-git change I did for you
[02:50] <mwhudson> oh right yeah
[02:51] <lifeless> I need a teddy bear
[02:51] <lifeless> for a bzr patch.
[02:52] <mwhudson> lifeless: i can try
[02:52] <lifeless> I want to make commitfromnews also set --fixed
[02:53] <lifeless> this means a hook to run after the commit message is set by the user
[02:53] <lifeless> rather than at generation time
[02:53] <mwhudson> that makes sense i guess
[02:53] <mwhudson> one could imagine something similar involving debian/changelog
[02:53] <lifeless> right
[02:54] <lifeless> in fact commitfromnews could look at debian/changelog if wanted
[02:54] <lifeless> or bzr-builddeb can supply the changelog entries as a template
[02:54] <lifeless> $whatever
[02:54] <lifeless> so the questions are
[02:54] <mwhudson> i think it already does
[02:54] <lifeless> should the message be editable at this point (by the hook)
[02:54] <lifeless> e.g.
[02:55] <lifeless> it could look for a
[02:55] <lifeless> ----bugs----
[02:55] <lifeless> lp:1234
[02:55] <lifeless> deb:456
[02:55] <lifeless> --endbugs--
[02:55] <lifeless> region, strip that from the commit and turn it into properties
[02:55] <lifeless> commitfromnews and others could put this in the template
[02:56] <lifeless> and a user can then correct it if desired
[02:56] <lifeless> or should the message be immutable
[02:57] <mwhudson> you could put that --bugs-- stuff after the "-- the part of the message after this marker will be ignored --" i gues
[02:57] <lifeless> mwhudson: sadly no
[02:57] <mwhudson> although that might lead to people not reading it
[02:57] <lifeless> mwhudson: because it gets stripped off early
[02:57] <mwhudson> oh right, i guess the hook probably wouldn't see it then?
[02:57] <mwhudson> heh
[02:58] <lifeless> 'tada' :P
[02:59] <lifeless> I think the constraints are:
[02:59] <lifeless>  - humans can correct the heuristics
[02:59] <lifeless>  - not -too- ugly if the plugin to do bug handling is missing/disabled for some reason
[02:59] <lifeless> any feedback
[03:00] <mwhudson> lifeless: another constraint might be: allowing a way for a gui to be more tasteful in handling this
[03:01] <lifeless> so the msg template does have a commit object passed in
[03:02] <lifeless> I was thinking to have all the plugins that find bugs tell the commit object
[03:02] <lifeless> and the callback in builtins.py (this is really ugly)
[03:03] <lifeless> add the visibilty stuff
[03:03] <lifeless> so a gui could do better
[03:03] <lifeless> there is so much code in builtins.py that doesn't belong there.
[03:03] <mwhudson> yes
[03:04] <mwhudson> lifeless: i think what you first suggested sounds good enough to be worth trying to use for a while
[03:04] <lifeless> argh, lenovo please please please provide more visibilty
[03:05] <mwhudson> lifeless: the part that's unsettling is making the commit-message-as-edited into some semi structured thing
[03:05]  * lifeless tries a summary:
[03:06] <lifeless> a) CLI case
[03:06] <lifeless> 1) message templates provide a template and also call into the commit to say 'possibly fixes X'
[03:06] <lifeless> 2) CLI UI layer says 'template += list of bugs fixed'
[03:07] <lifeless> 3) CLI UI layer strips out list of bugs fixed and adds them as really fixed to the commit
[03:07] <lifeless> done
[03:07] <lifeless> b) GUI cas
[03:07] <lifeless> 1) same
[03:07] <lifeless> 2) GUI shows additional widget; easy.
[03:07] <lifeless> CLI with commit -m - what happens here?
[03:08] <lifeless> template doesn't run, no prompt, fail.
[03:08] <lifeless> take 3)
[03:08] <lifeless> rather than message templates use a Commit hook to scan for bug status, which can look at:
[03:08] <lifeless>  - the diff
[03:09] <lifeless>  - commit message
[03:09] <lifeless>  - $whatever
[03:09] <lifeless> so the CLI case calls this hook after getting the message template from the user
[03:09] <lifeless> adds it to the template
[03:09] <lifeless> then parses the result back out again
[03:10] <lifeless> cli with -m, shows the commit editor when the detected candidate bug list != supplied bug list from the command line
[03:10] <lifeless> and doesn't show the commit message itself
[03:11] <lifeless> so 'commit message' here means either 'template or final commit message depending on whether the user has supplied it or not'
[03:25] <lifeless> mwhudson: so sounds plausible?
[03:26]  * mwhudson rubs eyes, reads again
[03:26] <mwhudson> lifeless: yeah, i think so
[03:38] <lifeless> this seems too complex
[03:38] <lifeless> take 4
[03:40] <lifeless> what I specifically want is 'bzr commit' -> editor -> adds --fixes for me
[03:41] <lifeless> with, also specific, the ability to correct mistakes
[03:41] <lifeless> the easiest thing is to not do this when -m is supplied
[03:42] <mwhudson> i think not worrying over much about what happens whem -m is supplied makes sense
[03:42] <lifeless> that binds it to the UI
[03:42] <lifeless> which as a heuristic, is appropriate.
[03:43] <thumper> lifeless: nudge re: code snippet
[03:43] <lifeless> oh right
[03:43] <lifeless> uhm committing patches right
[03:48]  * mwhudson leaves the cafe
[03:48] <mwhudson> probably back on line for a bit later
[03:53] <lifeless> http://pastebin.org/110384
[03:53] <lifeless> thumper: &
[03:54] <thumper> lifeless: ta
[03:54] <lifeless> my fault if it works, yours if it fails
[03:55] <thumper> lifeless: does bzrlib have any context managers yet for handling locks?
[03:55] <lifeless> there was a branch
[03:55] <lifeless> dunno if its landed
[03:55] <lifeless> we write to 2.4 still though
[03:55] <lifeless> so we can't use or even really test them.
[03:56] <thumper> lifeless: I was considering targetting 2.6+ for my work so I can use them :)
[04:00] <lifeless> thumper: note that the approach I use is a bit fugly
[04:01] <lifeless> you could check Merge3Merger to see how the regular merge code detects conflicts
[04:01] <lifeless> but the class I use is the one you should use
[04:01] <thumper> lifeless: thanks
[04:18]  * thumper EODs
[04:20] <wgrant> jtv: Morning.
[04:21] <jtv> wgrant: afternoon!
[04:21] <wgrant> That too.
[04:21] <wgrant> So, I had a look at the hanging problem this morning.
[04:21] <wgrant> twisted.web.xmlrpc.Proxy.callRemote is hanging when you attempt to run build()
[04:22] <wgrant> There are two bugs here: 1) It hangs when you give it the extra_args dict with None as a value. I don't know why this is. 2) You are using IBranch.url, which is None, when you in fact mean IBranch.composePublicURL().
[04:22] <wgrant> Fixing the latter makes it dispatch.
[04:23] <wgrant> But it gets aborted on the next scan cycle, since TTBB doesn't have a build, and doesn't override verifySlaveBuildID.
[04:23] <wgrant> Once you override that properly, it gets dispatched and finishes fine, although the slave seems to just return filenames rather than a tarball right now.
[04:29] <jtv> wgrant: my apologies for my silence; I was looking at a different workspace
[04:30] <jtv> Where are we using IBranch.url?
[04:30] <jtv> I specifically wrote IBranch.composePublicURL for this... it'd be an embarrassing oversight if I then neglected to use it in creating the job parameters.
[04:30] <wgrant> jtv: TTBJ.dispatchBuildToSlave
[04:31] <wgrant> Er, TTBB, I guess.
[04:31] <jtv> OMG
[04:31] <jtv> and through sheer coincidence it comes out as a http URL that does work for the slave?  weird
[04:32] <wgrant> .url comes out as None, which causes the hang.
[04:32] <wgrant> .composePublicURL comes out an an HTTP URL which works perfectlyt.
[04:32] <jtv> But I was seeing the proper URL in my BranchJob!?
[04:33] <jtv> Yes, that's why I wrote the damn thing.  This is galling.  My compliments on finding it!
[04:33] <wgrant> The URL isn't contained in the brnachjob...
[04:33] <wgrant> It just references a branch ID.
[04:34] <jtv> the json_data is {'branch_url': 'http:....'}
[04:35] <wgrant> jtv: I appear to have two branch jobs for each scan. One has a URL, and one has from_revision_id/force_translations_upload.
[04:35] <jtv> ah
[04:35] <wgrant> Is the one with the URL the translations job?
[04:35] <wgrant> I haven't actually checked the type enum...
[04:35] <jtv> they're both translations jobs, of different kinds :-)
[04:35] <jtv> IIRC RosettaUploadJob has a type 3 or 4.  Mine has type 6.
[04:36] <wgrant> Ahh.
[04:36] <wgrant> So the BranchJob row has a URL, but dispatchBuildToSlave then inaccurately recalculates it?
[04:38] <jtv> I guess!
[04:38] <jtv> I think dispatchBuildToSlave should just use BranchJob.json_data
[04:39] <jtv> Well, I think it's called metadata or something
[04:39] <wgrant> I don't see why you precalculate the URL.
[04:39] <jtv> One very stupid practical reason is that it makes it a lot easier to see what's going on in psql!
[04:40] <wgrant> shh.
[04:40] <jtv> Well, when I'm not second-guessing it and replacing perfectly good json data with the wrong dict.
[04:40] <wgrant> Hmm.
[04:40] <wgrant> Henning's latest branch (lp:~henninge/launchpad/bug-507680-upload-templates) seems like it's attempting to do the upload from the slave.
[04:40] <wgrant> I don't think that's going to work.
[04:40] <jtv> No, that wouldn't
[04:41] <jtv> You're talking about the upload to the translations import queue?
[04:41] <wgrant> That's what the comments suggest.
[04:41]  * jtv looks
[04:46] <jtv> wgrant: I'm looking at the version I merged into my local branch, but don't see it there
[04:47] <jtv> wgrant: oh, you're looking at the branch for bug 507680?
[04:47] <mup> Bug #507680: Upload buildfarm-generated templates <wellington> <Launchpad Translations:In Progress by henninge> <https://launchpad.net/bugs/507680>
[04:49] <jtv> I'll add a note to the bug
[04:51] <wgrant> jtv: Yeah, that one.
[04:52] <jtv> Wow, thanks for spotting that.  It's obscene how much we've come to rely on you.
[04:53] <wgrant> Heh.
[06:08] <jtv> hi henninge!
[06:10] <henninge> Hi jtv! ;)
[06:11] <henninge> jtv: thanks for the comment.
[06:11] <jtv> henninge: ah, you saw that :)
[06:12] <henninge> I had already gotten the feeling that I had something wrong in my thinking therer.
[06:12] <wgrant> It looks like you're very close.
[06:12] <jtv> another thing: don't call tarfiles "zipfile," or confusion and the possible collapse of civilization will ensue.
[06:12] <wgrant> Dispatching all works, so you just have to get the tarball out of the slave now.
[06:12] <jtv> (there's a builtin module called zipfile, and we use it elsewhere in our code)
[06:12] <jtv> Okay, I may be exaggerating a tiny bit
[06:12] <henninge> jtv: talking to me?
[06:12] <henninge> ;)
[06:13] <jtv> henninge: yes.  Okay, I may be understating the "tiny bit" of my exaggeration.
[06:13] <henninge> yes, right.
[06:14] <henninge> jtv: how do I get the tarball from the slave to the master?
[06:14] <jtv> grawr, I hate how my mouse pointer moves because my hands are near the touchpad while I'm typing
[06:14] <wgrant> jtv: Karmic and above should disable that by default.
[06:14]  * henninge was going to look at other builder's code but might as well ask ... ;)
[06:14] <wgrant> Check System->Preferences->Mouse->Touchpad, the "Disable touchpad while typing" checkbox.
[06:14] <jtv> wgrant: this is karmic, but I think I disabled it by hand
[06:15] <jtv> yes, it'd be nice if that actually worked, wouldn't it  :)
[06:15] <wgrant> henninge: I see you have code to produce a tarball. You'll need to add that into the returned filemap somehow.
[06:15] <jtv> henninge: see my comment... that part is already done
[06:15] <wgrant> henninge: The other slaves do that by looking at a changes file.
[06:16] <jtv> ah, right, you do need to put it in filemaps
[06:16] <wgrant> Once it's in there, it's trivial to get to it from the master code.
[06:16] <jtv> henninge: IIRC I hard-coded a path for the tarball
[06:17] <jtv> ah yes, "translation-templates.tar.gz"
[06:17] <jtv> feel free to change that; it's just a placeholder
[06:17] <wgrant> See gatherResults in the Debian and SourcePackageRecipeBuildManagers.
[06:17] <wgrant> I suspect that you'll need to copy your file into the filecache, and then call addWaitingFile.
[06:22] <henninge> wgrant: yes, saw that codenow . I'll look deeper into it to find out exactly.
[06:22] <henninge> jtv: I saved the world! ;)
[06:22] <henninge> i.e. renamed zipfile to tarball
[06:23] <jtv> millions sigh in relief
[06:23] <jtv> \o/  \o/  \o/
[06:23] <al-maisan> henninge: nice way to end the week :)
[06:23] <jtv> lol
[06:23] <al-maisan> saving the world
[06:23] <wgrant> Heh.
[06:23] <wgrant> Morning al-maisan.
[06:23] <henninge> al-maisan: yes, feels so good
[06:23] <jtv> okay, who's going to put al-maisan on the quotes page?
[06:23] <henninge> Moin al-maisan!
[06:23] <al-maisan> Good morning henninge, jtv and wgrant :)
[06:23] <jtv> :)
[06:24] <henninge> Oh yes, good afternoon wgrant!
[06:25] <jtv> wgrant: in the slave, iterate_CLEANUP calls buildComplete regardless of success, but it turns out buildComplete expects to be coming from a BUILDING state.
[06:25] <wgrant> jtv: Why would it be building but not BUILDING?
[06:25] <wgrant> CLEANUP is still called during BUILDING.
[06:25] <jtv> wgrant: this may be a cleanup after failure
[06:26] <wgrant> At which point alreadyfailed should be True, but the status should still be BUILDING, IIRC.
[06:26] <jtv> (as in my case it probably is)
[06:26] <jtv> unless the failure happened in a different state...
[06:26] <wgrant> In what other state would it fail?
[06:28] <wgrant> You shouldn't be setting builderstatus yourself at all, I don't think.
[06:28] <jtv> pretty much anything at this stage
[06:28]  * henninge gets breakfast
[06:29] <wgrant> Oh, are you talking about the case where iterate_CLEANUP throws it to BUILDERFAIL, then calls buildComplete?
[06:29] <wgrant> Wait what.
[06:29]  * jtv looks again
[06:29] <wgrant> Oh, right.
[06:30] <wgrant> Are you aware of the difference between builderstatus and buildstatus?
[06:30] <wgrant> It's very confusing if you forget that they are separate.
[06:30] <wgrant> iterate_CLEANUP will set the buildstatus to OK or BUILDERFAIL.
[06:30] <jtv> wait, you're talking about build status the database field?  I don't see a connection
[06:30] <wgrant> But the builderstatus should remain BUILDING until buildComplete sets it to WAITING.
[06:30] <wgrant> No, the slave property.
[06:31] <jtv> now _that_ is confusing :)
[06:31] <wgrant> Yes!
[06:31] <wgrant> So the slave returns something like (BuilderStatus.WAITING, BuildStatus.OK)
[06:31] <wgrant> Or (BuilderStatus.WAITING, BuildStatus.BUILDERFAIL)
[06:31] <jtv> ok
[06:32] <wgrant> Is the initial non-BUILDING thing you brought up actually appearing in practice?
[06:32] <jtv> So BuilderStatus.BUILDING should start as soon as the builder accepts a job?
[06:32] <jtv> wgrant: yes, that's why I'm bringing it up.
[06:32] <wgrant> I think so, yes.
[06:33] <wgrant> IDLE -> BUILDING -> WAITING -> IDLE -> ... is the normal path.
[06:33] <wgrant> Any of the other states are probably buggy and won't work properly.
[06:34] <wgrant> (although the translations job handles ABORTING much much better than binary builds)
[06:38] <wgrant> jtv: So, got any more info on the odd failure?
[06:40] <jtv> wgrant: yup!  tiny innocuous little line: 2010-03-12 13:38:33+0700 [-] Builder 'bob' rescued from 'bf-test-14': 'Malformed build ID'
[06:40] <jtv> And the FSM goes through INIT-UNPACK-CLEANUP
[06:40] <wgrant> jtv: Ahaha, so it was ABORTING after all.
[06:41] <jtv> And to some extent, recovering which is also cool.
[06:41] <wgrant> Yeah, that doesn't work for binary builds.
[06:41] <wgrant> But yours isn't horrible so it might work better.
[06:43] <jtv> Oh, I missed today's Hacker Minute
[06:44] <wgrant> Hm?
[06:45] <jtv> 13:37
[06:46] <wgrant> Ah.
[06:46] <jtv> Then again, last night I finally attended the fortnightly hacker get-together again.  Finally saw James Clark again, which was so much fun after all those years.
[06:47] <jtv> And of course one Catalan hacker who somehow knows I used to live in his town, and we find a common acquaintance.
[06:47] <jtv> This world is insane.  Run by someone with a sense of humour.
[06:47] <wgrant> Haha.
[06:47] <jtv> Still, that flight to Wellington takes the cake.
[06:48] <wgrant> I was thinking of that, yes.
[06:48] <wgrant> Quite incredible.
[06:48] <jtv> Funny... it looks as if I'm expected to generate an id consisting of "buildid-buildqueueid" where "buildid" is ignored.
[06:49] <wgrant> Not ignored.
[06:49] <wgrant> It's compared down the bottom.
[06:49] <wgrant> But I wrote that method, and I expect you to override it.
[06:49] <wgrant> Since you don't have a build.
[06:50] <wgrant> (it used to be prettier, but then we got more job types)
[06:51] <jtv> override verifySlaveBuildID?  Right ho.
[06:52] <wgrant> Right.
[06:52] <wgrant> I just said 'pass' in my version, but you can probably do slightly better than that.
[06:52] <jtv> Makes it a bit dual-purpose though, so maybe I should break that method in twain—"verify that the id makes sense for this job type" and "verify that this BuildQueue object exists."
[06:52] <jtv> The latter is generic.
[06:53] <wgrant> It's entirely up to the BuildFarmJobBehaviour to decide the slave build ID string.
[06:53] <wgrant> So it might not contain the buildqueue ID, but it probably does.
[06:54] <jtv> True, but a helper seems useful (also means you don't need to look up the utility)
[06:54] <wgrant> Indeed.
[06:55] <wgrant> Also, I see some workarounds in the slave for parts of the interface that don't quite make sense for you.
[06:55] <wgrant> Remember that you can refactor it too...
[06:59] <jtv> otp with hardcore Windows dev
[06:59] <jtv> "you didn't hear this from me, but I'm thinking of switching to Ubuntu Server"
[06:59] <wgrant> Haha.
[06:59] <wgrant> Good to know.
[07:00] <jtv> "I didn't realize that Ubuntu had a Server edition"
[07:04] <jtv> Ouch, he really wants to do it all by mouse.
[07:05] <noodles775> Good day :)
[07:06] <jtv> hi noodles775
[07:06] <noodles775> Hi jtv
[07:07] <wgrant> Morning noodles775.
[07:08] <noodles775> Hi William.
[07:09] <noodles775> jtv: thanks for the explanation about your objections to the with statement.
[07:11] <jtv> noodles775: I didn't _want_ to write a novel, but given that it wasn't yet completely clear...  :-)
[07:11] <noodles775> jtv: no, it was exactly what I was interested to know.
[07:12] <jtv> "This Ubuntu website is amazing!  Very easy, it's listing all the advantages and features and technologies... fucking wow!"
[07:14] <jtv> He's considering jumping ship from Windows 7, mainly because of licensing cost
[07:14] <wgrant> Wow.
[07:14] <jtv> noodles775: you came in in the middle of this...  I'm otp with a hardcore windows dev
[07:14] <noodles775> Ah, I was wondering what the context was.
[07:16] <noodles775> jtv: and regarding the benefit of switching back afterwards (back on the context manager), I was thinking whether it could be something re-usable for other tests, where in the setup code you need to switch db users to set something up and then switch back.
[07:17] <noodles775> wgrant: if you've time, can you add your thoughts/disagreements/clarifications to bug 536700 (I added a png of the current db tables with some notes).
[07:17] <mup> Bug #536700: Present other build types in a PPA context <wellington> <Soyuz:Triaged> <https://launchpad.net/bugs/536700>
[07:19] <noodles775> And feel free to simply edit the description where necessary of course.
[07:19] <jtv> noodles775: might be, yes, but a proper switch back may involve a commit; plus switching back and forth in a test is probably an indicator that you're doing too much in one test.  So I don't particularly feel like doing work to encourage it.  :)
[07:21] <wgrant> noodles775: Is the source for that image around somewhere.
[07:22] <wgrant> ?
[07:22] <wgrant> I want to shuffle it around a bit.
[07:22] <noodles775> wgrant: one tick, I'll upload the .dot file that I used.
[07:23] <noodles775> The only way I could produce it was to use postgres_autodoc to generate the source for *all* tables, and then edit the file removing all the other tables/relns...
[07:23] <wgrant> Ah :(
[07:24] <noodles775> wgrant: http://people.canonical.com/~michaeln/tmp/launchpad_dev.dot
[07:25] <noodles775> I then ran that through `dot -Tpng -o build-related.png launchpad_dev.dot`
[07:26] <wgrant> I wonder why it is laying it out so badly.
[07:27] <noodles775> Yeah, I used dia once before for the recipe tables, which allows you to lay it out of course, but it was a pain as it crashed every few minutes, hence trying dot this time.
[07:28] <noodles775> (although it might be better on Lucid, that was on Karmic).
[07:28] <wgrant> Odd. Dia has been just about unchanged for many years, and is reasonably reliable for me.
[07:28]  * wgrant tries.
[07:28] <wgrant> (and dot normally does a better job than it has this time)
[07:29] <noodles775> wgrant: I think it was more to do with the size of the file... it may have been that once I manually deleted all the other tables it was stable, I can't remember.
[07:30] <wgrant> Ah.
[07:30] <wgrant> Yeah, I guess it could be pretty huge otherwise.
[07:30] <noodles775> I generated a png of the complete schema just for fun... it was 22mb, and looked very scary ;)
[07:31] <wgrant> Heh.
[07:44] <wgrant> noodles775: Dia gets very very slow with the entire scheme, but it hasn't crashed yet.
[07:45] <noodles775> Great.
[07:57] <adeuring> good morning
[08:05] <stub> wgrant: Unfortunately, dot is pretty bad at laying out stuff like ORM diagrams. Its designed for other stuff.
[08:17] <wgrant> stub: So it seems :(
[08:19] <wgrant> kfogel: Oops. Pushing removal now.
[08:20] <kfogel> wgrant: ah, great.  I'm still up; I'll pqm-submit it afterwards.
[08:20] <wgrant> kfogel: Thanks.
[08:23] <kfogel> wgrant: you've tested your latest at /Draft, right?
[08:25] <wgrant> kfogel: Except for the comment removal, I believe so. let me try again, just in case.
[08:25] <kfogel> wgrant: I believe this fixes bug 436957; do you concur?
[08:25] <mup> Bug #436957: Contributions script gets confused with db-stable=>devel merge <Launchpad Foundations:Triaged by kfogel> <https://launchpad.net/bugs/436957>
[08:25] <wgrant> kfogel: Ah, so there is a bug!
[08:26] <wgrant> And I even filed it.
[08:26] <wgrant> yes, it does fix it.
[08:26] <kfogel> wgrant: ok, listing in PQM msg
[08:26] <kfogel> wgrant: can you link your branch to the bug please/
[08:26] <kfogel> ?
[08:27] <wgrant> kfogel: Done.
[08:29] <kfogel> wgrant: arrrgh.  how to make pqm submit your branch instead of ~kfogel/launchpad/community-contributions-fixes (which doesn't exist).
[08:29] <kfogel> sigh
[08:29]  * kfogel growls at bzr pqm-submit
[08:30] <wgrant> It does exist, though.
[08:30] <wgrant> Or at least yours popped up too when i searched for my branch.
[08:31] <kfogel> wgrant: well, I could push to my own area and then land that, but it seems so silly.
[08:31] <kfogel> I want to land *yours*.
[08:32] <kfogel> wgrant: hunh.  THe "--public-location" option seems to have done it.  I wouldn't have expected that to work.
[08:32] <kfogel> bzr pqm-submit -m "[r=kfogel][ui=none][bug=436957] In the community-contributions.py script, snarf contributors from both devel and db-devel branches, and fix a sorting bug." --public-location=lp:~wgrant/launchpad/community-contributions-fixes/
[08:33] <kfogel> wgrant: okay, it's in the Now Playing queue.  I'm off to bed.  Thank you SO much for fixing these long-standing problems!
[08:33] <wgrant> Thanks for the review and landing!
[08:33] <wgrant> Night.
[08:44] <jtv> wgrant, noodles775: I'd like to make some Build and BuildQueue objects for my tests... do you happen to have any handy makeBuild[Queue] functions lying around that I could move into the factory?
[08:45] <wgrant> jtv: See SoyuzTestPublisher.
[08:45] <noodles775> jtv: yeah, the SoyuzTestPublisher is what we usually use.
[08:45] <wgrant> Also see noodles' blog post.
[08:45] <noodles775> it's in lib/lp/soyuz/tests/test_publishing
[08:45] <jtv> cool, thanks
[09:03] <wgrant> stub: I wondered about indices. I guess we'll see.
[09:03] <wgrant> Thanks.
[09:15] <mrevell_> Morning
[11:03] <deryck> Morning, all.
[11:08] <jml> morning
[13:21] <jml> intellectronica, it turns out that renaming attributes is difficult.
[13:21] <jml> intellectronica, thank heavens for our test suite
[13:22] <intellectronica> jml: right. feel free to rename them only in the api if it turns out too difficult to change them internally
[13:43] <jml> intellectronica, it's been easy enough, I just missed a couple of places.
[13:49] <intellectronica> cool
[14:11] <rockstar> Has anyone done anything about the buildbot failure?
[14:18] <gary_poster> rockstar: apparently not.  I'll own the db-devel failure, since it is the librarian.  Hopefully someone else can step up for the devel failure in malone.
[14:18] <rockstar> gary_poster, I'm working on the devel one right now.
[14:19] <gary_poster> rockstar: awesome thanks
[14:19] <rockstar> henninge, the buildbot failure email came to you 2 hours ago. Why did you not at least reply to the list with the causation?
[14:19] <deryck> adeuring, intellectronica, gmb, allenap -- is someone looking into our failure gary_poster mentions above? ^^
[14:20] <deryck> oh, I see rockstar says he is.
[14:20] <deryck> rockstar, thanks!
[14:20] <henninge> rockstar: sorry, I was going to but got distracted ...
[14:20]  * henninge hides in shame
[14:21] <rockstar> deryck, can I get you to review the fix?
[14:23] <deryck> rockstar, sure.
[14:26] <gary_poster> flacoste: I know zero about the librarian, and we have a seemingly spurious failure on db-devel because of it (https://lpbuildbot.canonical.com/builders/db_lp/builds/591/steps/shell_7/logs/summary).  Who knows the librarian right now?  You and stub?  ...I think I'm going to force db-devel right now but should not let this lie.
[14:27] <flacoste> gary_poster: do we have /var/tmp/librarian.log
[14:28] <gary_poster> flacoste: no
[14:29] <flacoste> gary_poster: there isn't much to do beside restarting, without that file we have no idea what went wrong
[14:29] <flacoste> gary_poster: is that a first?
[14:29] <gary_poster> flacoste: to my knowledge, yes
[14:30] <gary_poster> something to do in the abstract: contemplate buildbot slaves sending files if there are failues.  But that's wasted work, since we are moving the slaves to the DC
[14:30] <adeuring> deryck: no, I haven't looked yet
[14:32] <deryck> adeuring, no need now, rockstar is on it.  sorry for the mass ping.
[14:33] <rockstar> deryck, https://code.edge.launchpad.net/~rockstar/launchpad/testfix/+merge/21243
[14:33]  * rockstar waits for diff
[14:33] <rockstar> deryck, diff is there.
[14:35] <deryck> rockstar, r=me.  Thanks!
[14:35]  * deryck curses at page tests
[15:04] <jml> good news!
[15:05] <adiroiban> x
[15:05] <jml> subunit output is now in zope.testing on trunk
[15:05] <jml> I can delete my horrible hack once they release.
[15:07] <rockstar> gary_poster, so, the devel testfix is in and should make buildbot green there again.
[15:08] <gary_poster> rockstar: Awesome, thanks.  I forced db-devel, so we should now be out of testfix
[15:36] <intellectronica> mrevell: we shouldn't use bug.reporter@gmail.com in our text if we don't own this address. we should use example.com. we can change that in another branch, though.
[15:47] <mrevell> intellectronica, Good point! I'll change it in this branch; no harm doing that.
[15:47] <intellectronica> mrevell: lovely, thanks
[16:29] <gmb> allenap: Does this look sane? I went with BugWatchActivity rather than *History; it seemed to lead to nicer column names. http://pastebin.ubuntu.com/394114/
[16:31] <allenap> gmb: So, success = (error_type IS NULL)? Perhaps a column for the OOPS number?
[16:32] <allenap> gmb: Might need an index on bug_watch, but I guess that's up to stub.
[16:33] <gmb> allenap: Yes, that's how I see us working out success. OOPS number is a good idea. Isn't bug_watch indexed by default, being an FK?
[16:34] <allenap> gmb: Maybe it is indexed.
[16:34] <gmb> allenap: Ah, no, I'm misreading the output of \d.
[16:35] <gmb> allenap: It probably should be indexed; I'll add one.
[17:28] <Breaking_Pitt> I have tried to putt the launchpad opent to all the computer in my network but I have get the following message
[17:28] <Breaking_Pitt>  The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
[17:29] <Breaking_Pitt> following this info https://dev.launchpad.net/Running/RemoteAccess
[17:29] <Breaking_Pitt> some advice about what can cause this?
[17:33] <bjf> if launchpad is telling me "This bug report was marked for expiration 164 days ago." then why hasn't it "expired", what does "expire" mean?
[18:04] <jml> bjf, "expire" means "automatically set to Invalid", I think.
[18:04] <bjf> jml, ok, but nothing seems to be "automatically" setting the bugs to Invalid
[18:08] <deryck> bjf, jml -- yes, expired means set to invalid.  This is currently disabled, so the messages are incorrect.
[18:08] <deryck> we're doing work soon (likely this month) to renable it with an EXPIRED status.
[18:17] <bjf> if I were so inclined, can I hack on launchpad on lucid (the web page says Hardy, Jaunty and Karmic)?
[19:07] <maxb> bjf: it's less well supported
[19:08] <maxb> which is to say, yes, but expect things to break
[19:08] <maxb> much like lucid itself, I guess :-)
[19:08] <maxb> https://dev.launchpad.net/Running/Lucid
[19:16] <jml> also, the Canonical Launchpad folk are switching to lucid on the beta, so it'll probably get better quickly
[20:11] <deryck> Later on, everyone.... have nice weekend.
[21:39] <sinzui> gary_poster: ping
[21:39] <gary_poster> sinzui: pong.
[21:40] <sinzui> gary_poster: bug 538207 may require a bandaid or a team of people to fix. Or we can rollback one of salgado's landings
[21:40] <mup> Bug #538207: Opps calling view/isRedirectInhibited from non-launchpadview <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/538207>
[21:40] <gary_poster> sinzui: I was just looking at that one actually.
[21:41] <gary_poster> sinzui: so lp.registry.browser.teammembership.TeamMembershipEditView does not inherit from LaunchpadView?  I was just about to go there in my investigation of what was going on
[21:41] <sinzui> I favor fixing the views (I am certain I can fix the registry ones), but I think we have views that are defined in ZCML only, so they will never have the needed attribute
[21:42] <gary_poster> sinzui: you mean without a view class.  Right.
[21:42] <sinzui> gary_poster: yes, that is what I mean
[21:44] <gary_poster> sinzui: what do you think of this instead:
[21:44] <sinzui>  ‏‎gary_poster: we would also have to fix this bug too bug 433074
[21:44] <mup> Bug #433074: Remove launchpad-addform.pt and launchpad-editform.pt <tech-debt> <Launchpad Registry:Triaged> <https://launchpad.net/bugs/433074>
[21:44] <gary_poster> move isRedirectInhibited to the request
[21:44] <gary_poster> change that template to say request/isRedirectInhibited
[21:44] <gary_poster> and move on
[21:44] <sinzui> gary_poster: ah...You are thinking much more clearly than myself
[21:45] <sinzui> We do get to fix a lot of tech-debt if we refuse to inline the python
[21:46] <gary_poster> sinzui: ok, seems like you like that idea.  I don't know how critical this is.  What do you think?  Is this a drop everything and do it now, or do it early next week?  Without your adjustment, I will schedule for Monday
[21:47] <sinzui> This is not critical yet, collin disable the redirect to complete his task
[21:47] <gary_poster> true
[21:47] <gary_poster> ok thank you sinzui.  I'll follow up on bug
[21:48] <sinzui> We should fix it next week. I was concern that if we did want everything to descend from LPVIew, that we need to get several people involved
[21:48] <gary_poster> understood, cool
[21:55] <wgrant> gary_poster: Bug #529348 hasn't been fixed yet, has it? (re. #launchpad)
[21:55] <gary_poster> wgrant: it is waiting for an RC.  I
[21:56] <gary_poster> will land the branch on devel when it goes into production
[21:56] <gary_poster> (so as not to call attention to it)
[21:56] <wgrant> Hm, OK, so there is something else going on.
[21:56] <wgrant> Yep.
[21:56] <gary_poster> hm, not on #launchpad, looking
[21:57] <wgrant> gary_poster: c_korn is getting an Unexpected Form Data error on what appears to be all LP forms.
[22:00] <gary_poster> that's more than a little bit weird, yes, wgrant
[22:01] <wgrant> I don't think UFDs return an OOPS number, though they do give a traceback if you're in ~launchpad. :(
[22:03] <gary_poster> ah, wgrant. :-(
[22:56] <gary_poster> sinzui: I unintentionally stomped on you for https://bugs.edge.launchpad.net/launchpad-foundations/+bug/538236
[22:56] <mup> Bug #538236: UnexpectedFormData submitting answers comment <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/538236>
[22:57] <sinzui> stomp away
[22:58] <gary_poster> sinzui, I was going to change this bug to say that we don't give adequate feedback for UnexpectedFormErrors.  I agree that user was missing REFERER.  However, there's no way for user or us to know that.  You agree?
[22:59] <sinzui> yes. I agree
[22:59] <gary_poster> cool thanks
[23:08] <wgrant> gary_poster: Simple solution being the adapter?
[23:49] <peitschie> hi everyone :)
[23:55] <gary_poster> wgrant: yes, the adapter to the AssertionError, as opposed to the adapter to something like a PublicAssertionError
[23:56] <wgrant> Hm, OK.
[23:56] <peitschie> hey... i was wondering if anyone knows who is best to talk to about getting a patch into the python launchpad integration source?
[23:57] <wgrant> peitschie: python-launchpad-integration, or python-launchpadlib?
[23:57] <peitschie> wgrant: the first :)
[23:58] <wgrant> peitschie: I believe that's in Ubuntu's domain, not Launchpad's.
[23:59] <peitschie> wgrant: ahh.  you wouldn't happen to have the room for them handy by any chance would you?  Thanks by the way :)
[23:59] <wgrant> peitschie: #ubuntu-bugs might be able to help.