| mwhudson | hm | 02:45 |
|---|---|---|
| mwhudson | what to do for the last ~2 hours of work on a friday afternoon | 02:45 |
| lifeless | mwhudson: pawn? | 02:50 |
| lifeless | mwhudson: land that bzr-git change I did for you | 02:50 |
| mwhudson | oh right yeah | 02:50 |
| lifeless | I need a teddy bear | 02:51 |
| lifeless | for a bzr patch. | 02:51 |
| mwhudson | lifeless: i can try | 02:52 |
| lifeless | I want to make commitfromnews also set --fixed | 02:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| lifeless | and a user can then correct it if desired | 02:56 |
| lifeless | or should the message be immutable | 02:56 |
| 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:57 |
| lifeless | 'tada' :P | 02:58 |
| === jamalta-afk is now known as jamalta | ||
| 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 | 02:59 |
| mwhudson | lifeless: another constraint might be: allowing a way for a gui to be more tasteful in handling this | 03:00 |
| lifeless | so the msg template does have a commit object passed in | 03:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 | |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| lifeless | so 'commit message' here means either 'template or final commit message depending on whether the user has supplied it or not' | 03:11 |
| lifeless | mwhudson: so sounds plausible? | 03:25 |
| * mwhudson rubs eyes, reads again | 03:26 | |
| mwhudson | lifeless: yeah, i think so | 03:26 |
| lifeless | this seems too complex | 03:38 |
| lifeless | take 4 | 03:38 |
| lifeless | what I specifically want is 'bzr commit' -> editor -> adds --fixes for me | 03:40 |
| 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:41 |
| 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:42 |
| thumper | lifeless: nudge re: code snippet | 03:43 |
| lifeless | oh right | 03:43 |
| lifeless | uhm committing patches right | 03:43 |
| * mwhudson leaves the cafe | 03:48 | |
| mwhudson | probably back on line for a bit later | 03:48 |
| lifeless | http://pastebin.org/110384 | 03:53 |
| lifeless | thumper: & | 03:53 |
| thumper | lifeless: ta | 03:54 |
| lifeless | my fault if it works, yours if it fails | 03:54 |
| 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:55 |
| thumper | lifeless: I was considering targetting 2.6+ for my work so I can use them :) | 03:56 |
| lifeless | thumper: note that the approach I use is a bit fugly | 04:00 |
| 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:01 |
| * thumper EODs | 04:18 | |
| wgrant | jtv: Morning. | 04:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| jtv | wgrant: my apologies for my silence; I was looking at a different workspace | 04:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| jtv | the json_data is {'branch_url': 'http:....'} | 04:34 |
| 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:35 |
| wgrant | Ahh. | 04:36 |
| wgrant | So the BranchJob row has a URL, but dispatchBuildToSlave then inaccurately recalculates it? | 04:36 |
| jtv | I guess! | 04:38 |
| jtv | I think dispatchBuildToSlave should just use BranchJob.json_data | 04:38 |
| 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:39 |
| 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:40 |
| 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:41 | |
| jtv | wgrant: I'm looking at the version I merged into my local branch, but don't see it there | 04:46 |
| 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:47 |
| jtv | I'll add a note to the bug | 04:49 |
| wgrant | jtv: Yeah, that one. | 04:51 |
| jtv | Wow, thanks for spotting that. It's obscene how much we've come to rely on you. | 04:52 |
| wgrant | Heh. | 04:53 |
| === jamalta is now known as jamalta-afk | ||
| jtv | hi henninge! | 06:08 |
| henninge | Hi jtv! ;) | 06:10 |
| henninge | jtv: thanks for the comment. | 06:11 |
| jtv | henninge: ah, you saw that :) | 06:11 |
| 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:12 |
| jtv | henninge: yes. Okay, I may be understating the "tiny bit" of my exaggeration. | 06:13 |
| henninge | yes, right. | 06:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:22 |
| 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:23 |
| henninge | Oh yes, good afternoon wgrant! | 06:24 |
| 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:25 |
| 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:26 |
| 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:28 | |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| wgrant | (although the translations job handles ABORTING much much better than binary builds) | 06:34 |
| === jtv1 is now known as jtv | ||
| wgrant | jtv: So, got any more info on the odd failure? | 06:38 |
| 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:40 |
| 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:41 |
| jtv | Oh, I missed today's Hacker Minute | 06:43 |
| wgrant | Hm? | 06:44 |
| jtv | 13:37 | 06:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| wgrant | (it used to be prettier, but then we got more job types) | 06:50 |
| jtv | override verifySlaveBuildID? Right ho. | 06:51 |
| 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:52 |
| 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:53 |
| jtv | True, but a helper seems useful (also means you don't need to look up the utility) | 06:54 |
| wgrant | Indeed. | 06:54 |
| 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:55 |
| 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. | 06:59 |
| jtv | "I didn't realize that Ubuntu had a Server edition" | 07:00 |
| jtv | Ouch, he really wants to do it all by mouse. | 07:04 |
| noodles775 | Good day :) | 07:05 |
| jtv | hi noodles775 | 07:06 |
| noodles775 | Hi jtv | 07:06 |
| wgrant | Morning noodles775. | 07:07 |
| noodles775 | Hi William. | 07:08 |
| noodles775 | jtv: thanks for the explanation about your objections to the with statement. | 07:09 |
| 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:11 |
| jtv | "This Ubuntu website is amazing! Very easy, it's listing all the advantages and features and technologies... fucking wow!" | 07:12 |
| 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:14 |
| 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:16 |
| 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:17 |
| 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:19 |
| wgrant | noodles775: Is the source for that image around somewhere. | 07:21 |
| 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:22 |
| 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:23 |
| noodles775 | wgrant: http://people.canonical.com/~michaeln/tmp/launchpad_dev.dot | 07:24 |
| noodles775 | I then ran that through `dot -Tpng -o build-related.png launchpad_dev.dot` | 07:25 |
| wgrant | I wonder why it is laying it out so badly. | 07:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| wgrant | Heh. | 07:31 |
| wgrant | noodles775: Dia gets very very slow with the entire scheme, but it hasn't crashed yet. | 07:44 |
| noodles775 | Great. | 07:45 |
| adeuring | good morning | 07:57 |
| stub | wgrant: Unfortunately, dot is pretty bad at laying out stuff like ORM diagrams. Its designed for other stuff. | 08:05 |
| wgrant | stub: So it seems :( | 08:17 |
| wgrant | kfogel: Oops. Pushing removal now. | 08:19 |
| kfogel | wgrant: ah, great. I'm still up; I'll pqm-submit it afterwards. | 08:20 |
| wgrant | kfogel: Thanks. | 08:20 |
| kfogel | wgrant: you've tested your latest at /Draft, right? | 08:23 |
| 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:25 |
| 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:26 |
| wgrant | kfogel: Done. | 08:27 |
| 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:29 | |
| wgrant | It does exist, though. | 08:30 |
| wgrant | Or at least yours popped up too when i searched for my branch. | 08:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:44 |
| 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 | 08:45 |
| wgrant | stub: I wondered about indices. I guess we'll see. | 09:03 |
| wgrant | Thanks. | 09:03 |
| mrevell_ | Morning | 09:15 |
| === jelmer_ is now known as jelmer | ||
| === noodles785 is now known as noodles775 | ||
| deryck | Morning, all. | 11:03 |
| jml | morning | 11:08 |
| === matsubara-afk is now known as matsubara | ||
| === salgado-afk is now known as salgado | ||
| === mrevell is now known as mrevell-lunch | ||
| jml | intellectronica, it turns out that renaming attributes is difficult. | 13:21 |
| jml | intellectronica, thank heavens for our test suite | 13:21 |
| intellectronica | jml: right. feel free to rename them only in the api if it turns out too difficult to change them internally | 13:22 |
| === mrevell-lunch is now known as mrevell | ||
| jml | intellectronica, it's been easy enough, I just missed a couple of places. | 13:43 |
| intellectronica | cool | 13:49 |
| rockstar | Has anyone done anything about the buildbot failure? | 14:11 |
| 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:18 |
| 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:19 |
| 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:20 | |
| rockstar | deryck, can I get you to review the fix? | 14:21 |
| deryck | rockstar, sure. | 14:23 |
| === jamalta-afk is now known as jamalta | ||
| 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:26 |
| flacoste | gary_poster: do we have /var/tmp/librarian.log | 14:27 |
| gary_poster | flacoste: no | 14:28 |
| 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:29 |
| 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:30 |
| deryck | adeuring, no need now, rockstar is on it. sorry for the mass ping. | 14:32 |
| 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:33 |
| deryck | rockstar, r=me. Thanks! | 14:35 |
| * deryck curses at page tests | 14:35 | |
| jml | good news! | 15:04 |
| 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:05 |
| rockstar | gary_poster, so, the devel testfix is in and should make buildbot green there again. | 15:07 |
| gary_poster | rockstar: Awesome, thanks. I forced db-devel, so we should now be out of testfix | 15:08 |
| 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:36 |
| === salgado is now known as salgado-lunch | ||
| mrevell | intellectronica, Good point! I'll change it in this branch; no harm doing that. | 15:47 |
| intellectronica | mrevell: lovely, thanks | 15:47 |
| === matsubara is now known as matsubara-lunch | ||
| === beuno is now known as beuno-lunch | ||
| 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:29 |
| allenap | gmb: So, success = (error_type IS NULL)? Perhaps a column for the OOPS number? | 16:31 |
| allenap | gmb: Might need an index on bug_watch, but I guess that's up to stub. | 16:32 |
| 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:33 |
| allenap | gmb: Maybe it is indexed. | 16:34 |
| gmb | allenap: Ah, no, I'm misreading the output of \d. | 16:34 |
| gmb | allenap: It probably should be indexed; I'll add one. | 16:35 |
| === deryck is now known as deryck[lunch] | ||
| === matsubara-lunch is now known as matsubara | ||
| === salgado-lunch is now known as salgado | ||
| 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:28 |
| Breaking_Pitt | following this info https://dev.launchpad.net/Running/RemoteAccess | 17:29 |
| Breaking_Pitt | some advice about what can cause this? | 17:29 |
| 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? | 17:33 |
| === beuno-lunch is now known as beuno | ||
| 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:04 |
| === deryck[lunch] is now known as deryck | ||
| 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:08 |
| bjf | if I were so inclined, can I hack on launchpad on lucid (the web page says Hardy, Jaunty and Karmic)? | 18:17 |
| === gary_poster is now known as gary-lunch | ||
| === kfogel is now known as jimb_intestines | ||
| === jimb_intestines is now known as kfogel | ||
| maxb | bjf: it's less well supported | 19:07 |
| 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:08 |
| === gary-lunch is now known as gary_poster | ||
| jml | also, the Canonical Launchpad folk are switching to lucid on the beta, so it'll probably get better quickly | 19:16 |
| === Ursinha-lunch is now known as Ursinha | ||
| deryck | Later on, everyone.... have nice weekend. | 20:11 |
| === jamalta is now known as jamalta-afk | ||
| === jamalta-afk is now known as jamalta | ||
| === matsubara is now known as matsubara-afk | ||
| === salgado is now known as salgado-afk | ||
| sinzui | gary_poster: ping | 21:39 |
| gary_poster | sinzui: pong. | 21:39 |
| 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:40 |
| 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:41 |
| gary_poster | sinzui: you mean without a view class. Right. | 21:42 |
| sinzui | gary_poster: yes, that is what I mean | 21:42 |
| 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:44 |
| sinzui | We do get to fix a lot of tech-debt if we refuse to inline the python | 21:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:55 |
| 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:56 |
| wgrant | gary_poster: c_korn is getting an Unexpected Form Data error on what appears to be all LP forms. | 21:57 |
| gary_poster | that's more than a little bit weird, yes, wgrant | 22:00 |
| wgrant | I don't think UFDs return an OOPS number, though they do give a traceback if you're in ~launchpad. :( | 22:01 |
| gary_poster | ah, wgrant. :-( | 22:03 |
| === jamalta is now known as jamalta-afk | ||
| 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:56 |
| sinzui | stomp away | 22:57 |
| 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:58 |
| sinzui | yes. I agree | 22:59 |
| gary_poster | cool thanks | 22:59 |
| wgrant | gary_poster: Simple solution being the adapter? | 23:08 |
| peitschie | hi everyone :) | 23:49 |
| gary_poster | wgrant: yes, the adapter to the AssertionError, as opposed to the adapter to something like a PublicAssertionError | 23:55 |
| 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:56 |
| wgrant | peitschie: python-launchpad-integration, or python-launchpadlib? | 23:57 |
| peitschie | wgrant: the first :) | 23:57 |
| wgrant | peitschie: I believe that's in Ubuntu's domain, not Launchpad's. | 23:58 |
| 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. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!