=== lifeless_ is now known as lifeless === elmo_ [~james@george.kkhotels.co.uk] has joined #launchpad === stu1 [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad === kiko is now known as kiko-afk === justdave_ [~dave@24.247.63.44.gha.mi.chartermi.net] has joined #launchpad === justdave_ is now known as justdave === kiko-afk is now known as kiko [04:13] !alindeman:*! Hi all .. It appears that one of our main rotation servers has dropped off the Internet ... We've pulled it from rotation and are working to mitigate further problems ... Sorry for any inconvenience and thanks for using Freenode! === BradB|away [~bradb@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #launchpad [06:08] ok, anyone know what this error means? [06:08] /home/dave/Source/Warthogs/launchpad/launchpad/lib/sqlobject/main.py:231: UserWarning: I tried to set the property "labels", but it was already set, as a method. Methods have significantly different semantics than properties, and this may be a sign of a bug in your code. [06:14] it seems that one class defined in :231 already has a method defined called labels() [06:14] it may be that this is only described in the interface.. === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #launchpad [06:24] yeah, but sqlobject isn't mine, so Apparently I"m talking to it wrong somewhere. [06:24] except I'm not calling it directly, just trying to load a couple objects from canonical.launchpad.database [06:25] and malone/browser.py is still importing them from there [06:26] although I get the same error loading browser, too [06:26] maybe it's a red herring and I should just ignore it. :) [06:28] it's triggering when importing? [06:38] justdave: I think it was Carlos, Daf or Spiv who had that error last night. [06:39] yeah, triggers when importing [06:39] seems to be only a warning though, it keeps going [06:40] The sqlobject subclass needs fixing (sqlobject is setting magic variables, I think because of some join attributes. It needs to be told to use names that don't conflict). [06:40] Yer.. it was spiv. I'd stick it in Bugzilla or check the IRC logs from about 12 hours ago. [06:46] ok, looks like it mostly still works... [06:46] it wasn't passing tests, but that appears to be because urllib doesn't follow redirects [06:46] and it was pulling bugs from bugzilla.mozilla.org as part of the test suite [06:47] which recently started enforcing https :) [06:47] I suppose I should teach it to test for redirects, cuz that might bite us again in the future, too. [06:48] one last error from the test suite that I'm not sure on... [06:48] File "/usr/lib/python2.3/doctest.py", line 790, in rundoc [06:48] for tag, kind, homecls, value in _classify_class_attrs(object): [06:48] File "/usr/lib/python2.3/inspect.py", line 211, in classify_class_attrs [06:48] obj = getattr(cls, name) [06:48] AttributeError: __provides__ [06:49] is that the test suite complaining about that labels warning? [06:49] that's the only error it's giving now. === daf [daf@muse.19inch.net] has joined #launchpad [07:12] if I want to set a datestamp field to CURRENT_TIME how do I do that in sqlobject to get it to actually run the "CURRENT_TIME" as SQL instead of using it as a string value? [07:13] or does it know that automatically for a timedate field? [07:16] justdave: look at SourceSource.certify* [07:16] it does that [07:18] where do I find that? (found SourceSource, but don't see certify in there) [07:19] grep -rin certify * comes up empty on lib/canonical [07:20] not sure.. [07:20] its moved a lot :0 [07:20] you could try enable as a search instead [07:20] if mark hasn't merged his update [07:21] ok, think I found it [07:22] justdave: canonical/database/contstants.py [07:22] yep, just assigns 'NOW' to it [07:22] easy enough :) [07:22] justdave: Its important to make sure you store the UTC timestamp [07:23] justdave: 'NOW' stores local time. [07:24] 'NOW AT TIMEZONE UTC' ? [07:27] there's bunches of places in SourceSource that just do 'NOW' [07:27] watches = BugWatch.select( [07:27] "(lastchecked < (current_time - interval 23 hours))") [07:28] current_time in there is going to pull local time, too, isn't it? [07:30] yup. and every one is a bug :-) [07:30] (although I just set the production database to UTC time so it isn't a major one any more) [07:31] For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's timezone parameter, and is converted to UTC [07:31] using the offset for the timezone zone. [07:31] Our columns are timestamp-without-timezone [07:32] ok [07:32] was going to say, if they were with timezone, then it probably wouldn't matter [07:55] launchpad_test=> select timestamp 'now'; [07:55] timestamp [07:55] --------------------------- [07:55] 2004-10-07 01:53:58.90839 [07:55] launchpad_test=> select timestamp 'now' at time zone 'UTC'; [07:55] timezone [07:55] ------------------------------- [07:55] 2004-10-06 21:54:21.685953-04 [07:56] that's taking 'now' at my local time, pretending it's UTC, and converting it back to my local time. [07:56] something doesn't look right. [07:57] Mmm... more reason not to futz with timezones ;-) [08:00] watches = BugWatch.select( [08:00] "(lastchecked < (now() - interval '23 hours'))") [08:00] that doesn't return a list I can iterate through? [08:00] File "./check-watches.py", line 36, in main [08:00] for watch in watches: [08:00] File "/home/dave/Source/Warthogs/launchpad/launchpad/lib/sqlobject/main.py", line 1242, in __iter__ [08:00] return conn.iterSelect(self) [08:00] AttributeError: 'ConnectionDescriptor' object has no attribute 'iterSelect' [08:01] Looks like the SQLObject 0.6 upgrade has bitten you [08:02] nice. :) How do I fix it? [08:03] Are you using initZopeless? [08:04] doh. that would probably help. Not even initializing the database connection. [08:04] I'm surprised it didn't crash more spectacularly than that [08:05] Thats lucky - apart from that I don't know about using SQLObject outside of Zope ;) [08:07] ok, added the initZopeless and now it works :) [08:13] justdave: From a command prompt can you please run 'createland -d launchpad_test plpgsql' and tell me if you get an error? === stub is sampling how other developers have their postgresql setup [08:13] Erm .... 'createlang, not createland [08:14] dave@ibook [2:14 ~ 2] tcsh> createlang -d launchpad_test plpgsql [08:14] createlang: language installation failed: ERROR: permission denied for language c [08:15] Thats two out of two :-( === stub goes back to the drawing board [08:49] gah. bugzilla.gnome.org is running too old a version of bugzilla to have the rdf buglists :( [08:49] that throws a kink in things [09:26] justdave: Would it be simpler to upgrade them than work around it? [09:35] no [09:35] I already worked around it :) [09:37] turns out they actually do have rdf buglists in the version they're running, it's just using a different url syntax to get to it. [09:38] so it's making two lookups now, first one to check the version number, second using the appropriate syntax for that version to grab the bug data [09:39] we might want to store that in the BugTracker table... [09:40] I can still poll for it, but it would be pointless to poll for the version number every time I look up a bug... it won't change that often, so polling that only the first time and remembering from then on (for that day anyway) when looking up other bugs might be nice [09:56] ok, caching it in the script now. class constructor lets me pass in a version, if you pass one it uses it, if you don't, it probes. If I don't have it cached, I don't pass one, then I cache the one it finds for next time. === SteveEgg is now known as SteveA [10:04] hmm, urllib sucks. === justdave starts using urllib2 [10:05] urllib won't tell me if I got a 404 === debonzi [~debonzi@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === Kinnison [~dsilvers@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:09] Morning === BradB|away is now known as BradB [10:10] stub: So is it easy to rename a table? === elmo_ [~james@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === cprov [~cprov@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:31] justdave: once we're up and running, i'm happy for you to spend part of your time getting the big bugzilla instances into good shape for interoperability with malone [10:31] stub: can we go ahead with that production system update shortly? [10:32] sabdfl: so, how did it all go after I crashed? Is it ready for stub and I to test & move into production ? [10:32] lifeless: yes, i believe so, i need to make sure that i have a version that does eveything i need, then hand it over to you for your own testing [10:32] i still don't know how to test your stuff [10:33] sabdfl: sure [10:33] buildbot testing for the sql interface is largely done by make check [10:33] there are a couple of bits that I still check by hand - by running up the staging instance. [10:34] sabdfl: ok. updating my copy now [10:35] sabdfl: nicole had success yesterday, the results you can see in http://192.168.1.26:8085/++skin++Debug/doap/projects/ [10:35] sabdfl: do you ahve a version that does what you need at the moment ? [10:37] cprov: that's really awesome! [10:38] sabdfl: yep [10:38] stub, spiv, did we get sourceforgeproject and freshmeatproject added to project and product? [10:38] cprov: nice! [10:38] no [10:38] ok, that obviously won't make today's cut then :-) [10:39] cprov: any way to make the table in the middle use more space? [10:39] cprov: horizontal space that is [10:40] I don't have the email around either - was it just those two columns? what datatype? what constraints? [10:41] Kinnison: yes, I'll take note . === stub can put it in now - provided the columns allow nulls it shouldn't affect anything [10:42] Kinnison: you also can navigate from project/product til sourcepackage and see the very low performance in sourcepackage data "fetch information" === Kinnison grins [10:47] Kinnison: btw, you can have the DB dump in http://192.168.2.26/ to compare the performance, what do you think ? [10:48] cprov: performance for what? [10:52] sabdfl: ximian will be the big one (if we have anything from them that we need to track?). they're still running 2.10 [10:52] apache is on 2.14.2, and they have hardware problems preventing them from upgrading, supposedly [10:52] justdave: they've also done a ton of customization i think [10:53] yes, they have [10:55] I just submitted the working check-watches.py script to pqm [10:55] cron it at will :) [10:55] it has output currently though [10:56] (lists off the bugs as it checks them) [10:56] ok, will be useful for debugging === justdave is strongly considering going to sleep soon [11:03] ok, just got the success message back from pqm [11:09] stub, lifeless: pqm message on the wire with version that works for me [11:10] lifeless: this version is a lot smarter about having different people logging in than what was running previously [11:10] please can we make sure this code is available only over https, and only with a username and password [11:11] even though not all pages require a login for zope, elmo, can we enforce this at the front end? [11:11] or do we listen to a unique port without ssl? [11:13] [for the benefit of those not at mark's:] they're proxypassed through https, with basic auth [11:13] justdave: are you running launchpad on your dev box? [11:13] elmo_: thanks, that's good enough for me [11:15] sabdfl: yep [11:16] justdave: if you update to the latest version once my patch is in, you should be able to: [11:16] (a) create project, and product [11:16] (b) register a bug tracker for that project [11:16] that way the bug tracker is associated with the project [11:17] can we associate a bugtracker with products optionally? [11:17] Apache Foundation has two bugtrackers, and some of the products are on each [11:18] we can associate both trackers with the apache project [11:18] that would work [11:18] and in the shortdesc makeit clear which one works [11:19] if the distinction is straightforward, put it in the tracker title, like "Apache Web Projects Bug Tracker" vs "Apache Java Bug Tracker" [11:19] that's what whill show up in the dropdown listboxen === BradB ponders infestation while mering [11:21] merging, even [11:22] They have both Bugzilla and JIRA, and it's basically the product-manager's preference which to use, so there's no clear line between what type of projects use which tracker. [11:23] although in general the java-based projects tend to use JIRA (because it's written in Java, and the java zealots all hate perl ;) [11:26] stub: renaming tables... [11:26] stub: What's the SQL to do it? [11:26] alter table foo rename to bar; [11:26] Does that rejiggle foreign keys etc? [11:27] '\h alter table' if you want [11:27] Yes - foreign keys are jigged [11:27] coolie === Kinnison writes a big fookoff chunk of SQL to rename sourcepackageupload to sourcepackagepublishing; add buildpublishing and point packagepublishing at the new buildpublishing table [11:28] primary key sequence will need some lovin, but I can do that. [11:28] Do you want new stuff to be 'create table' and then a pile of alter table commands [11:28] or do you want a create table with all the contraints etc built in? [11:28] one create table is fine [11:28] cool [11:28] (and preferred) === BradB notes buginfestation has a concatenated PK, shudders [11:32] stub - i'd like the scriptlet that does the table rename also to rename primary_id_seq as well [11:32] BradB: that's a bug, please fix [11:32] BradB: also, i think we may want to get rid of "CodeRelease" [11:33] and have two infestations - one of a sourcepackagerelease and one of a productrelease [11:33] I'll have to email the list to be clear here, because Kinnison mentioned having designed tables in the same way. So here goes. [11:33] this is fairly deep surgery on the glue that binds doap and soyuz, can we discuss? [11:34] Kinnison: policy is to give every table an int primary key [11:34] named id [11:34] CREATE TABLE Foo ( [11:34] id serial PRIMARY KEY, [11:34] ... [11:34] ); [11:34] sabdfl: then sourcepackageupload fails this policy [11:34] Kinnison: quite possibly [11:34] i though't i'd caught all of them before handing over to stub [11:35] doesn't seem to be === Kinnison ponders the SQL to correct this and will incorporate it into this change I'm writing [11:35] Kinnison: let's keep those changes separate [11:35] okay [11:36] Kinnison: a primary key fix like that requires no approval from me and can go straight in via stub [11:37] Kinnison: There have already been patches to fix those issues. It involves creating a sequence, creating a new 'id' column, setting the default of the new column to be retrieved from the sequence, dropping the existing primary key and recreating the constraint as a unique, creating a unique index for the new primary key [11:37] stub: yeah; I've got most of the way now [11:37] So just email me the screwed tables so I don't forget and I'll get on it this evening or tomorrow :) === Kinnison nods === justdave is now known as justdave_zzz [11:39] (and the update command to populate the new id column...) [11:40] stub, Kinnison, for this one, because its a standard problem with a standard fix, just let stub know which table needs fixing [11:40] rather than let each dev figure out how to fix it [11:40] sabdfl: Okay; but it needs to go hand-in-hand with renaming the table [11:41] Kinnison: ok, fair nuff [11:41] sabdfl: If that's okay; then I'll punt it to stub now [11:41] ok [11:41] stub: personal mail or launchpad@ [11:42] lifeless: test looking ok? [11:42] np. When do you need it by? [11:42] stub: ideally I could do with it quite soon because I have a bunch of other related changes which we'll need for lucille [11:43] ok - I'll do it after rollout tonight along with your other outstanding (lucilleconfig) [11:44] thanks [11:46] sabdfl: Okay, so source packages can be infested and products can be infested. Let's 1. drop coderelease (unless something else uses it), 2. add an infestation_type column to buginfestation, and 3. make infestation inflate to either a sourcepackage or a product, depending on infestation_type. [11:55] Is infestationtype necessary? It would be implicit depending on which of the product or the sourcepackage columns is not NULL [11:56] There wouldn't be a column for each of those. [11:58] sabdfl: been waiting for you to say you were finished. [11:58] are you finished ? [12:01] lifeless said so a while back [12:03] BradB: i'd rather have separate infestations [12:03] polymorphic tables have bitten us in the past [12:03] we usually end up undoing them [12:04] so productinfestation [12:04] packageinfestation [12:04] hmm... [12:04] bugproductinfestation [12:04] bugpackageinfestation [12:04] lifeless: how does it look? [12:04] for you? [12:05] stub: what do you think of separating the infestations? [12:05] I'd prefer seperate ones [12:06] ok, let me talk through it with bradb here and we'll send a proposal [12:19] sabdfl: I have the SQL for the new buildpublishing table and the alters for sourcepackagepublishing and packagepublishing now. Do you want to check them; or should I send them to launchpad@ for you to see there? [12:19] agreed on separate tables, bradb will send stub the sql [12:19] ta. [12:20] Can someone send me the product-scraping columns too if they have that email lying around? I think I've nuked it. [12:20] sabdfl: what caused this: [12:20] * [12:20] * Module zope.tales.tales, line 109, in __init__ [12:20] self._next = i.next() [12:20] * Module canonical.launchpad.database.project, line 53, in bugtrackers [12:20] for bugtracker in self._bugtrackers: [12:20] AttributeError: 'Project' object has no attribute '_bugtrackers' [12:21] oh bah, new fun [12:21] File "/home/robertc/source/canonical/buildbot/launchpad/lib/zope/configuration/fields.py", line 197, in fromUnicode [12:21] raise InvalidToken("%s in %s" % (v, u)) [12:21] zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/home/robertc/source/canonical/buildbot/launchpad/site.zcml", line 5.2-5.33 [12:21] ZopeXMLConfigurationError: File "/home/robertc/source/canonical/buildbot/launchpad/lib/canonical/configure.zcml", line 17.2-17.36 [12:21] ZopeXMLConfigurationError: File "/home/robertc/source/canonical/buildbot/launchpad/lib/canonical/lp/configure.zcml", line 32.2-37.8 [12:21] ConfigurationError: ('Invalid value for', 'factory', "Couldn't import canonical.lp.tales, No module named icelso in canonical.lp.tales.RequestAPI") [12:22] make: *** [run] Error 1 [12:22] Test upgrade of a production mirror worked with no surprises [12:22] the database ? [12:23] yer [12:23] but not a launchpad instance :[ [12:24] can you copy an upgraded production dump into the 'buttress' postgresql database on chinstrap ? [12:24] Can I nuke the existing contents? [12:25] yes [12:27] lifeless: 'sec [12:27] lifeless: my code has: [12:27] _bugtrackers = RelatedJoin('BugTracker', joinColumn='project', [12:27] otherColumn='bugtracker', [12:27] intermediateTable='ProjectBugTracker') [12:28] just above that. do you? [12:28] which file ? [12:28] There's a bug in SQLObject 0.6 here, I think :( [12:28] in lib/canonical/launchpad/database/project.py [12:28] If you add joinMethodName='_bugtrackers' to that RelatedJoin, it should fix it (but doing so shouldn't be necessary) [12:28] sabdfl: yes. [12:29] I'm trying to find a fix for that atm. [12:29] spiv: it's working fine in my copy [12:29] spiv: on the money honey [12:29] sabdfl: Have you upgraded your SQLObject since lifeless imported 0.6? :) [12:29] spiv: that'll be the _poTemplatesJoin thing too [12:30] spiv: i believe so [12:30] how do i check? [12:30] lifeless: Yeah, I expect so. And also the two UserWarnings when it starts. [12:30] tla tree-version sourcecode/sqlobject [12:30] sabdfl: cd sourcecode/sqlobject; tla tree-version [12:30] Or lifeless's way :) [12:30] rocketfuel@canonical.com/sqlobject--test--0.5.1 [12:31] bollocks [12:31] i have the following script which runs regularly [12:31] sabdfl: this was an exception, it was an upstream release change. [12:31] cd ~/projects/ubuntu [12:31] tla cat-config configs/canonical.com/launchpad/development | xargs -n 2 tla update -d [12:31] why doesn't that pick it up? [12:32] sabdfl: did you update your config as per my email ? [12:32] lifeless: run ~stub/buttress-dump.sql - I don't have postgresql access on chinstrap atm. [12:32] lifeless: i should not have to [12:33] seriously, if a change like that to a piece of code which i *only use* cannot be done by admins and automatically routed, then it is a bug [12:33] sabdfl: I'll accept that. [12:34] ok, traversal problem: [12:34] * Module zope.app.traversing.adapters, line 52, in traverse [12:34] raise NotFoundError(subject, name) [12:34] __traceback_info__: (, 'sourcesources', [] ) [12:34] NotFoundError: (, 'sourcesources') [12:34] http://localhost:8085/++skin++Debug/doap/projects/do-not-use-info-imports/unassigned [12:34] is where I went to get that [12:35] lifeless: how do i fix it? can i simply put 0.6 in place of 0.5.1? [12:35] lifeless: does the same thing happen when we update to a more recent vesion of zope? [12:35] for your dists tree, you just star merge. [12:36] that will propogate the code to your sqlobject, although it won't change the tree-version, *it will give you 0.6* [12:36] for zope, we're still in the same branch, because we've been tracking the same line of development. [12:36] i think it's the same bug [12:36] because sourcesources is constructed the same way _bugtrackers is [12:37] star merge from? [12:37] sabdfl: I sent out an email with all this in it. Is it ok if I point you at that ? [12:37] ok [12:37] please fix it so this stuff happens silently from now on. [12:38] when we switch to sqlobject 0.7, it should just happen, for everybody [12:38] same for zope updates [12:38] if we get everyone one raw, I'll guarantee that happily. [12:38] s/one/on/ [12:39] what was that demo user again ? [12:39] foo.bar@canonical.com [12:40] got it [12:41] sabdfl: looks good so far, testing buildbot now. [12:42] (this is with those sqlobject bug fixes.) [12:45] I think I've got a possible fix for the SQLObject bug... just testing. [12:49] spiv: any thoughts on this: [12:49] psycopg.ProgrammingError: ERROR: relation "importersourcesource" does not exist [12:50] oh. [12:50] sabdfl: around ? [12:52] ImporterSourceSource deriving from SourceSource breaks the queries. [12:54] lifeless: sec, i'm updateing to sqlobject 0.6 [12:55] holy crap there are a lot of patches to dists that i never had [12:59] lifeless: go ahead [01:00] is there any reason you didn't move the methods on SourceSource into the database module? [01:00] because thats broken buildbot. [01:00] SQLObject uses the class name in the queries it makes. [01:00] lifeless: there were several different SourceSource classes [01:01] ok, there was only one derived from SQLObject though. [01:01] lifeless: You can set the table name for SQLObject explicitly. [01:01] _table = 'SourceSource' [01:02] happier thanks [01:02] sabdfl: forget it [01:02] in my copy of class SourceSource: [01:02] class SourceSource(SQLBase): [01:02] """SourceSource table""" [01:02] implements (ISourceSource) [01:02] _table = 'SourceSource' [01:02] _columns = [ [01:02] StringCol('name', dbName='name', notNull=True), [01:02] sabdfl: its all good now, no problem. [01:02] StringCol('title', dbName='title', notNull=True), [01:02] ... [01:03] what was the problem? [01:03] the derived class needed _table='SourceSource' added [01:03] lifeless: why do you need a derived class? we are getting rid of those [01:03] sabdfl: eventually, I don't, but there was one left half-reorganised. [01:04] I just need it to keep working :) [01:04] where, i would rather fix it properly [01:04] lifeless: no, that's what got us into this state [01:04] infoImporter.py in lib/canonical/arch [01:04] nobody know what depends on what, or where it might be hidden [01:05] lifeless: please move those methods to SourceSource [01:05] btw - for your "research" list, it might be interesting to look at advanced ways of dealing with code that moves between files [01:06] jesus [01:06] ? [01:06] infoImporter subclasses SourceSource [01:06] then reassigns "SourceSource" to be the subclass [01:06] nice [01:06] don't blame me - did not do that crack. [01:07] moving them to SourceSource now. [01:07] so somene reading code in there might have NO idea that they were not dealing with a SourceSource [01:12] ok I'm good. [01:12] I've sent a merge up with what I needed. [01:12] lifeless: ping when you get the success message [01:12] and I'll tag off a new production config after dinner (which is now 2 hours later due to various*, so am starving) [01:13] stub: do you have a fix for the RelatedJoin ? [01:13] oh right, I haven't included the RelatedJoin fixes, I didn't want to conflict with you. [01:13] They only affect the front end though. [01:14] I no nuh-thing! [01:15] I'm slowly homing in on the Join bug. [01:15] (it also affects MultipleJoin) [01:15] sorry, meant spiv :-) [01:15] spiv, is there a workaround i can commit? [01:16] sabdfl: Set joinMethodName everywhere. [01:16] i.e. foo = RelatedJoin(...) -> foo = RelatedJoin(..., joinMethodName='foo') [01:16] so MultipleJoin(... joinMethodName=.. ah ok [01:17] that will only take a few minutes for me to do, but it then makes the code brittle to attribute renaming [01:17] think you'll have a proper fix shortly? [01:17] Another 30min, I think, yeah, there's a surpirsing number of layers of indirection to follow. [01:18] hmm... there are a lot of MultipleJoin's [01:18] of curse [01:18] RelatedJoin is not very common at this point [01:18] but fixing all of both would take too long [01:21] Ah-hah! [01:21] I've foundd *something*,, it might not be this bug, but it's certainly a bug ;) [01:22] Ok, I want to hurt somebody now, but at least I have a fix... [01:23] And the test to show that it works, presumably. ;) [01:23] Hah. [01:23] BradB: It's called "launchpad" ;) [01:24] BradB: It should be pretty easy to write a test for. [01:24] BradB: So easy, in fact, that there's no excuse for it to have not been done yet, so no excuse for it being broken by a stupid mistake. [01:25] [01:25] BradB: Yes, I will write a test for it. [01:25] spiv: Not everyone using SQLObject uses Launchpad. :) [01:25] cool [01:25] (Ian actually committed a patch on the off-chance it might fix it, according to the mailing list, without any testing manual or automated!) [01:26] (it didn't fix it) [01:28] Ok, andrew.bennetts@canonical.com/sqlobject--joinMethodName-fix--0.6 [01:29] Currently it only has the fix, unit test is in the works. [01:29] The fix itself is a one-liner, btw: [01:29]