[00:01] http://pastebin.com/22DZ5hNS [00:02] pcjc2: so that uses __eq__ [00:02] it will match u'' == '' [00:02] the string is different [00:02] to whit: [00:02] >>> a="(EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = Bug.id AND BugTag.tag = 'bob'))" [00:02] >>> b="(EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = bug.id AND BugTag.tag = 'fred') AND NOT EXISTS (SELECT TRUE FROM BugTag WHERE BugTag.bug = bug.id AND BugTag.tag = 'bob'))" [00:02] >>> a==b [00:03] False [00:03] note the 'bug.id' vs 'Bug.id' [00:03] * pcjc2 explodes [00:03] I pasted both strings in my texteditor and did a search to compare [00:03] and it highlighted both [00:03] * pcjc2 goes back to using a REAL editor like gvim ... screw gedit [00:04] sorry for the noise [00:04] no probs! [00:06] * pcjc2 feels stupid [00:06] its not the most helpful assertion [00:07] Should I be matching WHERE BugTag.bug = Bug.id [00:07] OR WHERE BugTag.bug = BugTask.bug ?? [00:07] Either should work, but the old query was BugTask.bug IN [00:13] depends what we want to correlate on [00:13] Bug.id is a smaller set than BugTask.bug [00:14] 1 bug to many bugtasks [00:18] looks like we'll need a losa to fix the build. we'll have to wait until the release is done. [00:20] fooding downstairs === mbarnett changed the topic of #launchpad-dev to: Launchpad Development Channel | New starters: huwshimi | 11.01 Release Week 4 | PQM is open | RM: jcsackett | firefighting: build is broken | Get the code: https://dev.launchpad.net/Getting [00:59] wgrant: btw, I've landed a rollback for r12181. I guess another thing to do would have been to delete the date_finished assertions in test_uploadprocessor, but I was a bit rushed at the time and not fully certain. [01:01] jml: Were there test failures? [01:02] wgrant: yeah. sorry to bring bad news. [01:02] jml, crusher of hope [01:02] thwarter of desire [01:02] jml: *sigh* [01:03] Self-reviewed *and* untested. [01:03] yeah. it's a pain, and worse for being easily avoidable. [01:04] I want to upgrade Twisted, so I need a working devel in order to do a sane ec2 test run. [01:04] anyway, I guess that can be the work of tomorrow [01:09] I'm signing off [01:09] Night. [01:09] g'night all [01:09] Thanks for reverting that. [01:13] np. [01:27] Project devel build (352): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/352/ [01:27] * Launchpad Patch Queue Manager: [r=mars][ui=none][bug=664828] Fixed timeout when deactivating a [01:27] member of a team. [01:27] * Launchpad Patch Queue Manager: [r=jml][ui=none][no-qa] Upgrade to testtools 0.9.8 final [01:40] lifeless: Patch is available for the tags issue, but haven't done any testing on it locally (other than proving test-suite now runs for the handful of test you identified) [01:40] https://code.launchpad.net/~pcjc2/launchpad/fix-tag-search-bug-501945/+merge/46075 [01:52] lifeless: When PQM runs the test-suite,... does it use that opportunity to benchmark Launchpad? [01:52] It occurred to me that one could take a snapshot of a fairly large testing database, grab a load of "typical" queries from a day in the life of Launchpad.. and make some kind of performance metric for code-changes [01:53] Would probably have to be read only queries unless there was a way to roll-back a big DB snapshot after testing [01:53] no [01:54] in fact for lp we don't run the test suite in pqm; we do that in a CI tool (currently buildbot) post-landing [01:54] the live db (which you need for perf evaluation) is 250GB [01:54] thought it would be a problem ;) [01:54] My HDD is only 500GB [01:54] yeah [01:54] I guess perf could be made from a set of read-only queries on the live DB [01:54] it won't fit on my laptop, thats for sure [01:55] but data changes of course - so hard to remain consistent. [01:55] yeah [01:55] we have comprehensive performance data anyhow [01:55] Perhaps that doesn't matter though... bad perf is bad perf, caused by increased DB size, or whatever [01:55] Ok - that is good [01:55] we trace all requests and generate page render times, broken down by page, url, what have you [01:55] Was just wondering if changes like the bug tags one would get noticed [01:55] well, that bug will be closed [01:56] we'll have some less backend data [01:56] howevewr [01:56] I suspect its < 10 pages a day hitting that bug (perhaps much less) [01:56] and we have 4000000 page renders a day [01:56] https://devpad.canonical.com/openid/+login [01:57] Authorization is required to access https://devpad.canonical.com/~stub/ppr/lpnet/latest-daily-timeout-candidates.html [01:57] yup, internal only atm [01:57] shame [01:57] we're going to get a sanitised extract [01:57] but we have confidential project names of our customers exposed in the raw report [02:04] Btw.. were the concerns about git (as regards possible integration with LP) documented somewhere? [02:09] I suspect not [02:09] I mean [02:09] we do mirror git into LP [02:10] and I think it would be fairly sane to publish bzr branches into git automatically [02:10] I'm not at all sure about speaking git for writes [02:10] (that has confused some people in our project already) [02:10] on purely technical limits [02:10] let alone the room for confusion [02:11] we already have git repositories in various places, so something distributed would be nice to support [02:11] It doesn't really matter to us that launchpad mirrors through bzr in order to get at things like translations etc.. [02:11] But it would be nice if we could hide that fact as an "admin only" detail, rather than have users think we use bzr [02:12] I should file a feature request for adding more comments on the "code" page of a project. We'd love to add some notes to https://code.launchpad.net/geda [02:13] please do [02:13] that would be nice [02:13] I'm going to bed shortly - I'll try and find time tomorrow to have a think about a) how our lives could be made less confusing w.r.t code on LP, and b) What wishlist we might have for git integration [02:14] I do love the ease with which you can push personal branches to launchpad with bzr [02:14] The code review workflow is lovely too. I wish we had the same for git [02:15] what keeps you on git ? [02:15] it was not _that_ long ago that we moved to it, and we find it serves almost all our needs [02:15] what I mean is [02:15] if you like everything else about lp [02:15] and you want to avoid confusing your users [02:16] The one area it could be better is that some users used to CVS / SVN just don't know how to "cvs up" with git [02:16] one option is to migrate to bzr [02:16] that is of course an option ;) [02:16] (where you can bzr up :P) [02:16] indeed [02:16] I'm totally cool with you staying on git, of course [02:16] just curious about how you perceive it all [02:17] I'd bet that bzr can do almost all of what we want, but it is one more thing to learn. I expect to learn it in due course though. [02:17] I find git more polished and pleasing to use than bzr though [02:17] faster - more obvious what is going on under the hood. Nice paged output with colours by default ;) (No doubt all options I've yet to find in bzr) [02:18] With bzr, I still get the uneasy feeling that I don't know where my data is [02:19] With git, I know where the data is (when unpacked), where the reflogs are, where to find the internals of stgit, how to manually fixup most problems one might encounter [02:19] (Thank-you very much ext4 + OS crash for the 0-length files in the repository's store) [02:20] heh [02:20] yeah, ext4 is not happy making [02:20] using it now, but its habit of truncating files is not nice [02:21] I recall there was a technical reason for the decision, but it is a shame they had to make it [02:21] it doesn't actually truncate [02:21] rather it saves the directory before saving the file inode [02:21] pcjc2: there are technical *arguments*... calling it a reason is a stretch in the opinion of quite a few people :) [02:22] irritating behaviour whatever the cause. I recalled it was something to do with ensuring consistency [02:23] its all about performance [02:23] delayed allocatio [02:23] n [02:23] http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/ [02:23] and yes [02:24] one of the problems is the black and white way the problem is framed [02:24] most apps *don't* care about 'on disk', but they do care about 'ordered in this way' [02:24] its better for battery life to care about the second point [02:24] ignore the negative comments abut Ubuntu in that blog post [02:26] bzr should probably just fsync files (or whatever exactly is needed) on ext4 bydefault [02:27] It was a git repository I got corrupted, but I imagine both might benefit from fsync around critical changes === danilo_ is now known as danilos [03:06] goodnight [03:26] Storm is too lazy :( [03:30] wgrant: in what way? [03:31] thumper: Applying @cachedproperty to a method that returns a resultset does nothing. [03:33] heh [03:58] * thumper EODs [05:40] * huwshimi is heading off [05:52] I'm guessing there are no reviewers around? [05:52] thumper: ? [06:13] Project devel build (353): STILL FAILING in 4 hr 26 min: https://hudson.wedontsleep.org/job/devel/353/ [06:13] Launchpad Patch Queue Manager: [r=benji][ui=none][bug=701613] update keyring to 0.5.1 [06:15] Project devel build (354): STILL FAILING in 2 min 33 sec: https://hudson.wedontsleep.org/job/devel/354/ [06:15] * Launchpad Patch Queue Manager: [r=lifeless][ui=none][bug=702170][no-qa] Fix yui deps to list the [06:15] current yui files. [06:15] * Launchpad Patch Queue Manager: [r=gmb][ui=none][no-qa] Adds more logging to the request_daily_build [06:15] script. [06:15] * Launchpad Patch Queue Manager: [r=gmb][ui=sinzui][bug=700864] Show a warning to the user if the [06:15] daily build won't happen due to PPA upload permission problems. [06:15] * Launchpad Patch Queue Manager: [rs=jml][ui=none][rollback=12181] Rollback r12181, [06:15] which introduced test failures. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [08:39] good morning [08:43] jtv: Morning. [08:43] wgrant: morning… or… late afternoon? [08:43] jtv: One of those. [08:43] Or others. [08:44] jtv: Bug 702228 [08:44] rosetta-export-queue is broken. [08:44] Arrr [08:44] _mup_: bug 1234 [08:44] :( [08:44] bad _mup_ [08:45] I guess I didn't make the display of current backlog on the export page prominent enough. [08:45] jtv: It is hanging on one export. [08:46] Firefox, too. [08:46] natty firefox, IIRC. [08:46] Yeah. [08:46] Do we know though that this isn't a stale lock file after the rollout? [08:47] jtv: It was processing firefox before the rollout. [08:47] And is processing firefox again after the rollout. [08:48] Looks to me as if the bug report may be completely unrelated to what we're actually seeing. [08:49] The backlog is 16 hours. [08:50] 2011-01-13 07:16:16 DEBUG Exporting objects for Данило Шеган, related to template firefox in Ubuntu Natty package "firefox" [08:50] It did it again an hour ago. [08:50] This is an ongoing problem. [08:50] But one unrelated to the complaint of "it don't work for 2 day," which is more likely to be an email problem or something. [08:51] Ah, true. [08:53] What has me curious is why the backlog is listed as about 16 hours, when rollout was scheduled about 10 hours ago. [08:53] Surely we didn't stop the script 6 hours prior to rollout? [08:54] It's possible that this is unrelated to rollout, but given how close to rollout it happened, one would suspect a connection. [08:56] jtv: Indeed. [08:58] jtv: Except that rollout prep didn't start for another 4 hours, AFAICT. [09:00] Right. It actually seems to have happened just before rollout. Not 2 days before, not immediately after. [09:01] Which also means that we didn't cause this in db-devel. [09:39] stub: could you have a look at this schema patch: http://paste.ubuntu.com/553532/ ? [09:40] stub: this breaks "make schema" when the test DBs are populated [09:49] adeuring: How does it break? It might be you need to use $$ quoting instead of single quotes for the function body, and the function should go in trusted.sql. [09:49] stub: IntegrityError: new row for relation "message" violates check constraint "message__must_have_chunks" [09:50] I wouldn't add this constraint anyway, as it is only checked at insert time [09:50] stub: my main point: do you think the patch itself is reasonable? If not there is not need to dive into the samledata iusse ;) [09:50] Sounds like some of our messages in sampledata don't have chunks. [09:50] stub: exactly [09:51] and this causes several headaches [09:51] Don't add the constraint would be my preference. [09:51] we don't know why this happens, so I thought that postgres could guard it [09:51] Constraints are good to provide guarantees, but in this case it cannot provide a guarantee [09:52] stub: well, the contraint will cause exepctions [09:52] If we want to guarantee this, a trigger is a better option [09:52] if we'll get these empty messages again [09:52] stub: how would you use a trigger here? [09:53] We would create a trigger on INSERT and UPDATE that fails if there are no messagechunk rows for this message. [09:54] stub: ok, makes sense. [10:13] (16:53:48) stub: We would create a trigger on INSERT and UPDATE that fails if there are no messagechunk rows for this message. [10:13] (16:54:51) stub: I guess it is pretty much the same as the CHECK constraint [10:13] (16:56:19) stub: 'SELECT TRUE FROM MessageChunk WHERE message=$1 LIMIT 1' reads nicer to me and I think more likely to get a nice plan. [10:13] (16:58:38) stub: adeuring: Have you looked at the contents of Message.raw for these empty messages? [10:13] 17:00 [10:13] (17:02:21) stub: adeuring: IIRC it is actually valid to have a Message with no MessageChunks - eg. an email that is just headers and no body. I don't see any use for these though even if they are technically valid so don't mind guarding against them if we need to. [10:13] (17:09:05) stub: adeuring: https://launchpadlibrarian.net/42717149/UYhI9QHAcptcDE1jt64zhivlP6.msg is the last one in the system, which looks like an email imported from debbugs [10:13] (17:09:42) stub: adeuring: And it is an email with no body - just headers [10:15] stub: ah, that's interesting. Seems that i need to check again what to do with empty messages [10:19] stub: strictly speaking, tis mail is _not_ empty: There are four empty lines after the headers, so a body content of '\n\n\n' [10:19] so that mail _should_ have a MessageChunk record [10:19] adeuring: So check out or email_to_message helper - we are likely deliberately stripping leading and trailing whitespace. [10:20] stub: right === al-maisan is now known as almaisan-away === matsubara-afk is now known as matsubara === almaisan-away is now known as al-maisan === Ursinha-afk is now known as Ursinha [11:21] stub: it's a bit awkward to slap a SlaveOnlyDatabasePolicy around just the right parts of the export procedure… would a SlaveDatabasePolicy around the whole thing be as valid? AFAIK we never ask for the master unless we really need the master. [11:23] If that leaves cursor() on the master, I could just eliminate the call. [11:59] Project devel build (355): STILL FAILING in 4 hr 47 min: https://hudson.wedontsleep.org/job/devel/355/ [12:03] Morning, all. === mrevell is now known as mrevell-luncheon [12:29] deryck: I think it'd be a good idea to make you an admin on ~malone-alpha so that you can approve new members. Any objections? [12:33] deryck: Also, do you have the slightest clue what's going on here: https://bugs.launchpad.net/launchpad/+bug/702022/+attachment/1792482/+files/out-2.ogv [12:33] <_mup_> Bug #702022: Once a project is modified you can no longer modify the status < https://launchpad.net/bugs/702022 > [12:38] can someone remind me where our QA tagging guide lives please? [12:40] ah nm [12:41] gmb: sure, make me an admin. looking at the other now. [12:45] Ta] [12:46] jtv: Sounds fine [12:47] gmb: yeah, I've seen that before, but don't recall exactly the work around. it's something to do with renaming projects and permissions after that. [12:49] deryck: Damn. Maybe sinzui, oracle of Registry, will know more. === al-maisan is now known as almaisan-away [12:56] gmb: it's something to do with because the "-old" team is inactive. [12:56] Ah. [12:57] deryck: So, if they reactivate that the problem might go away? [12:57] gmb: indeed, it might [12:57] I'll update the bug. [13:02] deryck, gmb: The top task is a deactivated project. [13:02] Nothing to do with a team. [13:02] I thought we hid those or something. [13:03] wgrant: Yeah, I s/team/project/'d before updating the bug. [13:03] Ah, great. [13:03] deryck, wgrant: I reactivated the -old project too, to speed things along. Hurrah for limited admin permissions. === mrevell-luncheon is now known as mrevell [13:03] Heh. [13:06] allenap: ISTR you looked into why archived debian bugs weren't synced correctly... Did you ever get anywhere with that? [13:07] I ask because of https://bugs.launchpad.net/launchpad/+bug/702332. [13:07] <_mup_> Bug #702332: debbugs #605391 not able to correctly update information < https://launchpad.net/bugs/702332 > [13:32] gmb: I started investigating with mthaddon... it might have been a problem with the archive not syncing properly. [13:34] allenap: Yeah; I came to the conclusion that because old archived stuff only sticks around for so long, we might not have a copy of it. [13:35] gmb: I think that archived debbugs get moved into a separate database. Do you remember the bug that triggered http://twitter.com/grahambinns/status/18060932747886592? [13:35] We should/are syncing both, but perhaps there is a problem. [13:37] Hah, no. [13:38] allenap: Yeah, I thought we were syncing both, and I seem to have got the idea that stuff gets deleted from the archive, too, which is clearly nonsense. [13:38] (Having just re-read the same page that gave me that idea I can now see that I was just getting fuddled) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara is now known as matsubara-lunch === Ursinha is now known as Ursinha-lunch [14:50] sinzui, thanks a lot for that sample. i'm sooo close to having something working [14:51] the only problem now is that the top-level collections are showing up twice: once as collections and once as entries [14:51] they're not being filtered out properly [14:52] my diff: http://pastebin.ubuntu.com/553622/ [14:54] i think i probably just converted the last bit incorrectly [14:55] leonardr: are they twice in the toc or twice in the content [14:56] sinzui: both. that makes me think i didn't look carefully at the last two "if test"s [14:56] give me a minute [14:58] sinzui: i think this is the problem. $master_top_level_collections isn't a list of ids, it's a list of tags [14:58] so $master_top_level_collections[contains(., $id)] always fails [14:58] does that make any sense? [14:59] i took out this code because it didn't seem to do anything: [14:59] select="$master-top-level-objects" /> [15:01] leonardr: id does make sense. We can either revise the master code to work with the master set to get ids from the tags, or we define a id version of the variable [15:02] sinzui: let's define another variable since it's used twice [15:02] what does it look like? [15:02] mrevell: hi [15:02] jml, Hi [15:02] mrevell: am stuck in a plenary atm [15:05] mrevell: do you want to have a call today? [15:06] jml, I'll be seeing you all day every day next week, so I'm happy to skip it. :) [15:06] mrevell: ok, cool. :) [15:07] wuuuuu Dallas! [15:07] hehe, you've been there so long now I bet you're picking up the accent. [15:07] not quite [15:07] I do have pick-up truck envy though [15:08] I want a pick-up truck so big that it's not legal to drive it within signatories of the Geneva convention [15:08] haha [15:09] leonardr: maybe this? [15:09] http://pastebin.ubuntu.com/553629/ [15:12] so, how do I upgrade my ui ? [15:12] I pulled in dists [15:12] ran bin/buildout [15:15] * jml tries upgrading Twisted === Ursinha-lunch is now known as Ursinha [15:16] jml: Didn't we just do that? [15:16] StevenK: we upgraded for 10.1, and then we applied a recent patch from trunk to fix a particular bug [15:16] jml: Or was that just discussing 10.2, but not doing it [15:16] StevenK: but 10.2 was released toward the end of last year, so it's time for an upgrade [15:17] wgrant: still awake? [15:17] StevenK: I tried upgrading to 10.2 yesterday, but got blocked on test failures introduced into the build by other branches. [15:17] lifeless: It's 0217, so I seriously doubt it [15:17] StevenK: there is always hope [15:17] so, how do I upgrade my yui ? [15:28] lifeless: would you have any idea why Storm would throw an IndexError when I call is_empty on a ResultSet? [15:31] hmmm actually it's the stuff in ftests/pgsql.py [15:37] bigjools: not offhand [15:38] lifeless: http://pastebin.ubuntu.com/553640/ [15:38] I think I'll be filing a bug [15:42] sinzui: i don't understand this error from the code you just sent me [15:42] XPath error : Invalid type [15:42] xmlXPathCompiledEval: 1 objects left on the stack. [15:42] clearly there's something wrong with the substring-after call, but i don't see it [15:43] I do not understand it either. I will re-read what I wrote === matsubara-lunch is now known as matsubara [15:45] sinzui: if it helps, i get the same error replacing the xpath expression with a random string [15:45] select="substring-after('foo', '#')" [15:49] leonardr: okay. I reproduced the error. [15:52] leonardr: looks like the problem is not in the new variable bug in how we use it. [15:52] ok [15:53] not($master_top_level_collection_ids[contains(., $id)]) is wrong? [16:01] allenap, benji, Edwin-afk: can you QA your bugs, I'd like to make a nodowntime release later today [16:01] Sure. [16:01] flacoste: will do [16:01] thx [16:04] working on it [16:06] leonardr: I suspect we are getting a null string. Maybe we have an item in the xml where there is not string after # [16:07] sinzui: there is a param with an empty wadl:link [16:07] resource_type_link in the top-level [16:07] okay I will look into that === deryck is now known as deryck[lunch] [16:15] benji: keyring problems all seem sorted for me, thanks! [16:15] yay [16:16] sinzui: i'm going to move this stylesheet to launchpad while i'm at it. do you have an opinion where in the tree it should go? [16:20] leonardr: I am not sure. I would think lib/lp/services/api if we intend to migrate api generation code to a single location [16:25] Project devel build (356): STILL FAILING in 4 hr 25 min: https://hudson.wedontsleep.org/job/devel/356/ [16:25] Launchpad Patch Queue Manager: [r=benji, [16:25] edwin-grubbs][ui=none][bug=620868] Allow the viewing and editing of [16:25] recipes with invalid recipe text. [16:25] leonardr: I was mistaken that I could use substring-after to create create a node set. We are not getting the correct type back. I will make an alternate suggestions [16:25] gmb: hi [16:26] gmb: why is bug 380362 wontfix? - found it chasing a newly reporting 'bug not found' error in debbugs [16:26] <_mup_> Bug #380362: Launchpad couldn't import several bugs from Debian Bug tracker. < https://launchpad.net/bugs/380362 > [16:29] Project db-devel build (264): FAILURE in 4 hr 46 min: https://hudson.wedontsleep.org/job/db-devel/264/ [16:30] lifeless: Because of some confusion a while back. allenap and I think there might be a problem syncing archived bug reports. I'll re-open the bug now. [16:31] gmb: bug 702332 [16:31] <_mup_> Bug #702332: debbugs bug watch not updating an archived debbug (#605391) < https://launchpad.net/bugs/702332 > [16:31] gmb: may be a dupe [16:31] hi lifeless, where are you hanging out today? [16:31] bzr room atm [16:32] lifeless: It is a dupe. allenap and I were discussing it just today, actually, but I hadn't got round to finding this bug and duping the new one. Will do it now, thanks. === beuno is now known as beuno-lunch === benji is now known as benji-lunch [16:59] leonardr: I think this solves the issue: http://pastebin.ubuntu.com/553663/ [17:01] * leonardr shall check [17:12] sinzui: looking good [17:12] fab [17:13] leonardr: jcsackett is reviewing today and he knows xslt. Is there a chance you can get your branch into review? [17:13] jcsackett *sort of* knows xslt. :-P [17:13] sinzui: yes, i just need a minute to do a diff of the stylesheet. i'm moving it into launchpad so the whole thing willl show up in the diff === gary_poster is now known as gary-lunch === deryck[lunch] is now known as deryck [17:28] sinzui: is utilities/migrater still needed in trunk? [17:30] jml: i think that will still be useful for as long as there are things to move from /canonical to /lp, yes? [17:31] jcsackett: I guess. I'm just mildly inconvenienced when file-ownership.txt shows up in my greps. [17:31] so it's no big deal [17:31] jml: if you're grepping across the launchpad tree, you might look at utilities/migrater/find.py [17:32] jcsackett: you're going to have to work harder than that to get me to abandon bzr grep. [17:32] jml: I regenerate my own each time. file-ownership is vestigial === almaisan-away is now known as al-maisan [17:32] jml: fair. wasn't trying to get you to abandon. i just find it a useful tool. :-) [17:38] flacoste: hi [17:38] flacoste: there are something like 10/15 rt's in the lp/bzr queue with pri 0 which AIUI means 'unset' - I'm wondering if you could drive that to 0? [on the same basis we drive NEW to zero] === al-maisan is now known as almaisan-away [17:49] OSError: [Errno 2] No such file or directory: './lib/canonical/launchpad/icing/yui/dom/dom-style-ie-min.js' [17:49] just got that on 'make schema' [17:49] anyone know what's up with that? [17:50] jml: lifeless filed a bug about that [17:50] * jml looks [17:52] ahh. rm -rf lazr-js/build === benji-lunch is now known as benji === beuno-lunch is now known as beuno [18:08] can someone please run "./bin/test -cvvt distribution-mirror.txt" for me? [18:08] I wonder if this is a natty thing. [18:11] jml: doing a make schema [18:11] then I'll try for thee [18:11] lifeless: thanks [18:13] lifeless: i can do that yes [18:14] also [18:14] my current working hypothesis is that Python is broken in natty [18:15] * jml gets on to that [18:17] 2.6 or 2.7 :p [18:20] 2.7 [18:20] but I think it's actually bzr being broken in Python 2.7, which is more plausible [18:24] the test failed for me [18:25] /home/robertc/launchpad/lp-branches/working/lib/canonical/librarian/testing/server.py:120: DeprecationWarning: Attempt to start Tachandler with an existing instance (21693) running in /var/tmp/fatsam.test/librarian.pid. [18:25] + url = librarian.remoteAddFile( [18:25] + AttributeError: 'thread._local' object has no attribute 'interaction' [18:25] + ERROR Error while sending mail from bounces@canonical.com to david.allouche@canonical.com. [18:25] + Traceback (most recent call last): [18:25] + File "/home/robertc/launchpad/lp-sourcedeps/eggs/zope.sendmail-3.7.1-py2.6.egg/zope/sendmail/queue.py", line 261, in run [18:25] + raise error, msg [18:25] + error: [Errno 111] Connection refused [18:30] hmm [18:30] I get completely different failures [18:30] but! [18:30] the stack traces show that it's using python 2.7 [18:31] which means that buildout is somehow using system standard python rather than a hard-coded python 2.6 [18:31] gary-lunch: does that sound plausible? ^ === gary-lunch is now known as gary === gary is now known as gary_poster [18:33] * gary_poster has a call noe, jml...um [18:33] gary_poster: don't worry. I'll keep poking around. [18:33] ok thanks, will ping [18:36] jml, yes, that's what our Makefile does. It was because of Hardy/Lucid transition. Can specify 2.6 now [18:37] gary_poster: just set PYTHON to python2.6 in the Makefile? [18:37] jml, prob [18:37] ok [18:37] will give it a try [18:37] gary_poster: thanks. [18:47] yeah. that does it. [19:07] Lifeless, did you get a chance to review my patch? Would like to see it on staging so I can QA the changes [19:11] thumper: if you could QA the two bugs you landed, i'd like to do a nodowntime release later today [19:33] pcjc2: hi [19:33] pcjc2: been flat out; best way to get it reviewed is to pop into #launchpad-reviews and ask for a reviewer [19:33] it looked ok to me to the extent I had looked at it [19:33] ok, - will do, sorry for assigning you directly [19:34] no worries [19:34]