[02:45] hm [02:45] what to do for the last ~2 hours of work on a friday afternoon [02:50] mwhudson: pawn? [02:50] mwhudson: land that bzr-git change I did for you [02:50] oh right yeah [02:51] I need a teddy bear [02:51] for a bzr patch. [02:52] lifeless: i can try [02:52] I want to make commitfromnews also set --fixed [02:53] this means a hook to run after the commit message is set by the user [02:53] rather than at generation time [02:53] that makes sense i guess [02:53] one could imagine something similar involving debian/changelog [02:53] right [02:54] in fact commitfromnews could look at debian/changelog if wanted [02:54] or bzr-builddeb can supply the changelog entries as a template [02:54] $whatever [02:54] so the questions are [02:54] i think it already does [02:54] should the message be editable at this point (by the hook) [02:54] e.g. [02:55] it could look for a [02:55] ----bugs---- [02:55] lp:1234 [02:55] deb:456 [02:55] --endbugs-- [02:55] region, strip that from the commit and turn it into properties [02:55] commitfromnews and others could put this in the template [02:56] and a user can then correct it if desired [02:56] or should the message be immutable [02:57] you could put that --bugs-- stuff after the "-- the part of the message after this marker will be ignored --" i gues [02:57] mwhudson: sadly no [02:57] although that might lead to people not reading it [02:57] mwhudson: because it gets stripped off early [02:57] oh right, i guess the hook probably wouldn't see it then? [02:57] heh [02:58] 'tada' :P === jamalta-afk is now known as jamalta [02:59] I think the constraints are: [02:59] - humans can correct the heuristics [02:59] - not -too- ugly if the plugin to do bug handling is missing/disabled for some reason [02:59] any feedback [03:00] lifeless: another constraint might be: allowing a way for a gui to be more tasteful in handling this [03:01] so the msg template does have a commit object passed in [03:02] I was thinking to have all the plugins that find bugs tell the commit object [03:02] and the callback in builtins.py (this is really ugly) [03:03] add the visibilty stuff [03:03] so a gui could do better [03:03] there is so much code in builtins.py that doesn't belong there. [03:03] yes [03:04] lifeless: i think what you first suggested sounds good enough to be worth trying to use for a while [03:04] argh, lenovo please please please provide more visibilty [03:05] 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] a) CLI case [03:06] 1) message templates provide a template and also call into the commit to say 'possibly fixes X' [03:06] 2) CLI UI layer says 'template += list of bugs fixed' [03:07] 3) CLI UI layer strips out list of bugs fixed and adds them as really fixed to the commit [03:07] done [03:07] b) GUI cas [03:07] 1) same [03:07] 2) GUI shows additional widget; easy. [03:07] CLI with commit -m - what happens here? [03:08] template doesn't run, no prompt, fail. [03:08] take 3) [03:08] rather than message templates use a Commit hook to scan for bug status, which can look at: [03:08] - the diff [03:09] - commit message [03:09] - $whatever [03:09] so the CLI case calls this hook after getting the message template from the user [03:09] adds it to the template [03:09] then parses the result back out again [03:10] cli with -m, shows the commit editor when the detected candidate bug list != supplied bug list from the command line [03:10] and doesn't show the commit message itself [03:11] so 'commit message' here means either 'template or final commit message depending on whether the user has supplied it or not' [03:25] mwhudson: so sounds plausible? [03:26] * mwhudson rubs eyes, reads again [03:26] lifeless: yeah, i think so [03:38] this seems too complex [03:38] take 4 [03:40] what I specifically want is 'bzr commit' -> editor -> adds --fixes for me [03:41] with, also specific, the ability to correct mistakes [03:41] the easiest thing is to not do this when -m is supplied [03:42] i think not worrying over much about what happens whem -m is supplied makes sense [03:42] that binds it to the UI [03:42] which as a heuristic, is appropriate. [03:43] lifeless: nudge re: code snippet [03:43] oh right [03:43] uhm committing patches right [03:48] * mwhudson leaves the cafe [03:48] probably back on line for a bit later [03:53] http://pastebin.org/110384 [03:53] thumper: & [03:54] lifeless: ta [03:54] my fault if it works, yours if it fails [03:55] lifeless: does bzrlib have any context managers yet for handling locks? [03:55] there was a branch [03:55] dunno if its landed [03:55] we write to 2.4 still though [03:55] so we can't use or even really test them. [03:56] lifeless: I was considering targetting 2.6+ for my work so I can use them :) [04:00] thumper: note that the approach I use is a bit fugly [04:01] you could check Merge3Merger to see how the regular merge code detects conflicts [04:01] but the class I use is the one you should use [04:01] lifeless: thanks [04:18] * thumper EODs [04:20] jtv: Morning. [04:21] wgrant: afternoon! [04:21] That too. [04:21] So, I had a look at the hanging problem this morning. [04:21] twisted.web.xmlrpc.Proxy.callRemote is hanging when you attempt to run build() [04:22] 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] Fixing the latter makes it dispatch. [04:23] But it gets aborted on the next scan cycle, since TTBB doesn't have a build, and doesn't override verifySlaveBuildID. [04:23] 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] wgrant: my apologies for my silence; I was looking at a different workspace [04:30] Where are we using IBranch.url? [04:30] 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] jtv: TTBJ.dispatchBuildToSlave [04:31] Er, TTBB, I guess. [04:31] OMG [04:31] and through sheer coincidence it comes out as a http URL that does work for the slave? weird [04:32] .url comes out as None, which causes the hang. [04:32] .composePublicURL comes out an an HTTP URL which works perfectlyt. [04:32] But I was seeing the proper URL in my BranchJob!? [04:33] Yes, that's why I wrote the damn thing. This is galling. My compliments on finding it! [04:33] The URL isn't contained in the brnachjob... [04:33] It just references a branch ID. [04:34] the json_data is {'branch_url': 'http:....'} [04:35] 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] ah [04:35] Is the one with the URL the translations job? [04:35] I haven't actually checked the type enum... [04:35] they're both translations jobs, of different kinds :-) [04:35] IIRC RosettaUploadJob has a type 3 or 4. Mine has type 6. [04:36] Ahh. [04:36] So the BranchJob row has a URL, but dispatchBuildToSlave then inaccurately recalculates it? [04:38] I guess! [04:38] I think dispatchBuildToSlave should just use BranchJob.json_data [04:39] Well, I think it's called metadata or something [04:39] I don't see why you precalculate the URL. [04:39] One very stupid practical reason is that it makes it a lot easier to see what's going on in psql! [04:40] shh. [04:40] Well, when I'm not second-guessing it and replacing perfectly good json data with the wrong dict. [04:40] Hmm. [04:40] 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] I don't think that's going to work. [04:40] No, that wouldn't [04:41] You're talking about the upload to the translations import queue? [04:41] That's what the comments suggest. [04:41] * jtv looks [04:46] wgrant: I'm looking at the version I merged into my local branch, but don't see it there [04:47] wgrant: oh, you're looking at the branch for bug 507680? [04:47] Bug #507680: Upload buildfarm-generated templates [04:49] I'll add a note to the bug [04:51] jtv: Yeah, that one. [04:52] Wow, thanks for spotting that. It's obscene how much we've come to rely on you. [04:53] Heh. === jamalta is now known as jamalta-afk [06:08] hi henninge! [06:10] Hi jtv! ;) [06:11] jtv: thanks for the comment. [06:11] henninge: ah, you saw that :) [06:12] I had already gotten the feeling that I had something wrong in my thinking therer. [06:12] It looks like you're very close. [06:12] another thing: don't call tarfiles "zipfile," or confusion and the possible collapse of civilization will ensue. [06:12] Dispatching all works, so you just have to get the tarball out of the slave now. [06:12] (there's a builtin module called zipfile, and we use it elsewhere in our code) [06:12] Okay, I may be exaggerating a tiny bit [06:12] jtv: talking to me? [06:12] ;) [06:13] henninge: yes. Okay, I may be understating the "tiny bit" of my exaggeration. [06:13] yes, right. [06:14] jtv: how do I get the tarball from the slave to the master? [06:14] grawr, I hate how my mouse pointer moves because my hands are near the touchpad while I'm typing [06:14] 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] Check System->Preferences->Mouse->Touchpad, the "Disable touchpad while typing" checkbox. [06:14] wgrant: this is karmic, but I think I disabled it by hand [06:15] yes, it'd be nice if that actually worked, wouldn't it :) [06:15] henninge: I see you have code to produce a tarball. You'll need to add that into the returned filemap somehow. [06:15] henninge: see my comment... that part is already done [06:15] henninge: The other slaves do that by looking at a changes file. [06:16] ah, right, you do need to put it in filemaps [06:16] Once it's in there, it's trivial to get to it from the master code. [06:16] henninge: IIRC I hard-coded a path for the tarball [06:17] ah yes, "translation-templates.tar.gz" [06:17] feel free to change that; it's just a placeholder [06:17] See gatherResults in the Debian and SourcePackageRecipeBuildManagers. [06:17] I suspect that you'll need to copy your file into the filecache, and then call addWaitingFile. [06:22] wgrant: yes, saw that codenow . I'll look deeper into it to find out exactly. [06:22] jtv: I saved the world! ;) [06:22] i.e. renamed zipfile to tarball [06:23] millions sigh in relief [06:23] \o/ \o/ \o/ [06:23] henninge: nice way to end the week :) [06:23] lol [06:23] saving the world [06:23] Heh. [06:23] Morning al-maisan. [06:23] al-maisan: yes, feels so good [06:23] okay, who's going to put al-maisan on the quotes page? [06:23] Moin al-maisan! [06:23] Good morning henninge, jtv and wgrant :) [06:23] :) [06:24] Oh yes, good afternoon wgrant! [06:25] 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] jtv: Why would it be building but not BUILDING? [06:25] CLEANUP is still called during BUILDING. [06:25] wgrant: this may be a cleanup after failure [06:26] At which point alreadyfailed should be True, but the status should still be BUILDING, IIRC. [06:26] (as in my case it probably is) [06:26] unless the failure happened in a different state... [06:26] In what other state would it fail? [06:28] You shouldn't be setting builderstatus yourself at all, I don't think. [06:28] pretty much anything at this stage [06:28] * henninge gets breakfast [06:29] Oh, are you talking about the case where iterate_CLEANUP throws it to BUILDERFAIL, then calls buildComplete? [06:29] Wait what. [06:29] * jtv looks again [06:29] Oh, right. [06:30] Are you aware of the difference between builderstatus and buildstatus? [06:30] It's very confusing if you forget that they are separate. [06:30] iterate_CLEANUP will set the buildstatus to OK or BUILDERFAIL. [06:30] wait, you're talking about build status the database field? I don't see a connection [06:30] But the builderstatus should remain BUILDING until buildComplete sets it to WAITING. [06:30] No, the slave property. [06:31] now _that_ is confusing :) [06:31] Yes! [06:31] So the slave returns something like (BuilderStatus.WAITING, BuildStatus.OK) [06:31] Or (BuilderStatus.WAITING, BuildStatus.BUILDERFAIL) [06:31] ok [06:32] Is the initial non-BUILDING thing you brought up actually appearing in practice? [06:32] So BuilderStatus.BUILDING should start as soon as the builder accepts a job? [06:32] wgrant: yes, that's why I'm bringing it up. [06:32] I think so, yes. [06:33] IDLE -> BUILDING -> WAITING -> IDLE -> ... is the normal path. [06:33] Any of the other states are probably buggy and won't work properly. [06:34] (although the translations job handles ABORTING much much better than binary builds) === jtv1 is now known as jtv [06:38] jtv: So, got any more info on the odd failure? [06:40] 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] And the FSM goes through INIT-UNPACK-CLEANUP [06:40] jtv: Ahaha, so it was ABORTING after all. [06:41] And to some extent, recovering which is also cool. [06:41] Yeah, that doesn't work for binary builds. [06:41] But yours isn't horrible so it might work better. [06:43] Oh, I missed today's Hacker Minute [06:44] Hm? [06:45] 13:37 [06:46] Ah. [06:46] 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] And of course one Catalan hacker who somehow knows I used to live in his town, and we find a common acquaintance. [06:47] This world is insane. Run by someone with a sense of humour. [06:47] Haha. [06:47] Still, that flight to Wellington takes the cake. [06:48] I was thinking of that, yes. [06:48] Quite incredible. [06:48] Funny... it looks as if I'm expected to generate an id consisting of "buildid-buildqueueid" where "buildid" is ignored. [06:49] Not ignored. [06:49] It's compared down the bottom. [06:49] But I wrote that method, and I expect you to override it. [06:49] Since you don't have a build. [06:50] (it used to be prettier, but then we got more job types) [06:51] override verifySlaveBuildID? Right ho. [06:52] Right. [06:52] I just said 'pass' in my version, but you can probably do slightly better than that. [06:52] 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] The latter is generic. [06:53] It's entirely up to the BuildFarmJobBehaviour to decide the slave build ID string. [06:53] So it might not contain the buildqueue ID, but it probably does. [06:54] True, but a helper seems useful (also means you don't need to look up the utility) [06:54] Indeed. [06:55] Also, I see some workarounds in the slave for parts of the interface that don't quite make sense for you. [06:55] Remember that you can refactor it too... [06:59] otp with hardcore Windows dev [06:59] "you didn't hear this from me, but I'm thinking of switching to Ubuntu Server" [06:59] Haha. [06:59] Good to know. [07:00] "I didn't realize that Ubuntu had a Server edition" [07:04] Ouch, he really wants to do it all by mouse. [07:05] Good day :) [07:06] hi noodles775 [07:06] Hi jtv [07:07] Morning noodles775. [07:08] Hi William. [07:09] jtv: thanks for the explanation about your objections to the with statement. [07:11] noodles775: I didn't _want_ to write a novel, but given that it wasn't yet completely clear... :-) [07:11] jtv: no, it was exactly what I was interested to know. [07:12] "This Ubuntu website is amazing! Very easy, it's listing all the advantages and features and technologies... fucking wow!" [07:14] He's considering jumping ship from Windows 7, mainly because of licensing cost [07:14] Wow. [07:14] noodles775: you came in in the middle of this... I'm otp with a hardcore windows dev [07:14] Ah, I was wondering what the context was. [07:16] 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] 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] Bug #536700: Present other build types in a PPA context [07:19] And feel free to simply edit the description where necessary of course. [07:19] 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] noodles775: Is the source for that image around somewhere. [07:22] ? [07:22] I want to shuffle it around a bit. [07:22] wgrant: one tick, I'll upload the .dot file that I used. [07:23] 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] Ah :( [07:24] wgrant: http://people.canonical.com/~michaeln/tmp/launchpad_dev.dot [07:25] I then ran that through `dot -Tpng -o build-related.png launchpad_dev.dot` [07:26] I wonder why it is laying it out so badly. [07:27] 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] (although it might be better on Lucid, that was on Karmic). [07:28] Odd. Dia has been just about unchanged for many years, and is reasonably reliable for me. [07:28] * wgrant tries. [07:28] (and dot normally does a better job than it has this time) [07:29] 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] Ah. [07:30] Yeah, I guess it could be pretty huge otherwise. [07:30] I generated a png of the complete schema just for fun... it was 22mb, and looked very scary ;) [07:31] Heh. [07:44] noodles775: Dia gets very very slow with the entire scheme, but it hasn't crashed yet. [07:45] Great. [07:57] good morning [08:05] wgrant: Unfortunately, dot is pretty bad at laying out stuff like ORM diagrams. Its designed for other stuff. [08:17] stub: So it seems :( [08:19] kfogel: Oops. Pushing removal now. [08:20] wgrant: ah, great. I'm still up; I'll pqm-submit it afterwards. [08:20] kfogel: Thanks. [08:23] wgrant: you've tested your latest at /Draft, right? [08:25] kfogel: Except for the comment removal, I believe so. let me try again, just in case. [08:25] wgrant: I believe this fixes bug 436957; do you concur? [08:25] Bug #436957: Contributions script gets confused with db-stable=>devel merge [08:25] kfogel: Ah, so there is a bug! [08:26] And I even filed it. [08:26] yes, it does fix it. [08:26] wgrant: ok, listing in PQM msg [08:26] wgrant: can you link your branch to the bug please/ [08:26] ? [08:27] kfogel: Done. [08:29] wgrant: arrrgh. how to make pqm submit your branch instead of ~kfogel/launchpad/community-contributions-fixes (which doesn't exist). [08:29] sigh [08:29] * kfogel growls at bzr pqm-submit [08:30] It does exist, though. [08:30] Or at least yours popped up too when i searched for my branch. [08:31] wgrant: well, I could push to my own area and then land that, but it seems so silly. [08:31] I want to land *yours*. [08:32] wgrant: hunh. THe "--public-location" option seems to have done it. I wouldn't have expected that to work. [08:32] 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] 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] Thanks for the review and landing! [08:33] Night. [08:44] 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] jtv: See SoyuzTestPublisher. [08:45] jtv: yeah, the SoyuzTestPublisher is what we usually use. [08:45] Also see noodles' blog post. [08:45] it's in lib/lp/soyuz/tests/test_publishing [08:45] cool, thanks [09:03] stub: I wondered about indices. I guess we'll see. [09:03] Thanks. [09:15] Morning === jelmer_ is now known as jelmer === noodles785 is now known as noodles775 [11:03] Morning, all. [11:08] morning === matsubara-afk is now known as matsubara === salgado-afk is now known as salgado === mrevell is now known as mrevell-lunch [13:21] intellectronica, it turns out that renaming attributes is difficult. [13:21] intellectronica, thank heavens for our test suite [13:22] jml: right. feel free to rename them only in the api if it turns out too difficult to change them internally === mrevell-lunch is now known as mrevell [13:43] intellectronica, it's been easy enough, I just missed a couple of places. [13:49] cool [14:11] Has anyone done anything about the buildbot failure? [14:18] 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] gary_poster, I'm working on the devel one right now. [14:19] rockstar: awesome thanks [14:19] 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] adeuring, intellectronica, gmb, allenap -- is someone looking into our failure gary_poster mentions above? ^^ [14:20] oh, I see rockstar says he is. [14:20] rockstar, thanks! [14:20] rockstar: sorry, I was going to but got distracted ... [14:20] * henninge hides in shame [14:21] deryck, can I get you to review the fix? [14:23] rockstar, sure. === jamalta-afk is now known as jamalta [14:26] 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] gary_poster: do we have /var/tmp/librarian.log [14:28] flacoste: no [14:29] gary_poster: there isn't much to do beside restarting, without that file we have no idea what went wrong [14:29] gary_poster: is that a first? [14:29] flacoste: to my knowledge, yes [14:30] 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] deryck: no, I haven't looked yet [14:32] adeuring, no need now, rockstar is on it. sorry for the mass ping. [14:33] deryck, https://code.edge.launchpad.net/~rockstar/launchpad/testfix/+merge/21243 [14:33] * rockstar waits for diff [14:33] deryck, diff is there. [14:35] rockstar, r=me. Thanks! [14:35] * deryck curses at page tests [15:04] good news! [15:05] x [15:05] subunit output is now in zope.testing on trunk [15:05] I can delete my horrible hack once they release. [15:07] gary_poster, so, the devel testfix is in and should make buildbot green there again. [15:08] rockstar: Awesome, thanks. I forced db-devel, so we should now be out of testfix [15:36] 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. === salgado is now known as salgado-lunch [15:47] intellectronica, Good point! I'll change it in this branch; no harm doing that. [15:47] mrevell: lovely, thanks === matsubara is now known as matsubara-lunch === beuno is now known as beuno-lunch [16:29] 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] gmb: So, success = (error_type IS NULL)? Perhaps a column for the OOPS number? [16:32] gmb: Might need an index on bug_watch, but I guess that's up to stub. [16:33] 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] gmb: Maybe it is indexed. [16:34] allenap: Ah, no, I'm misreading the output of \d. [16:35] allenap: It probably should be indexed; I'll add one. === deryck is now known as deryck[lunch] === matsubara-lunch is now known as matsubara === salgado-lunch is now known as salgado [17:28] I have tried to putt the launchpad opent to all the computer in my network but I have get the following message [17:28]