[01:18] losa ping, i'd like help qa'ing bug 855150 [01:18] <_mup_> Bug #855150: excessive translation import template mails (also poor phrasing)

< https://launchpad.net/bugs/855150 > [01:18] wgrant, lifeless, wallyworld, can you help me work out how to qa it at all? [01:18] i'm not sure manual qa would have a good tradeoff in this case [01:19] since there is a fairly good unit test, and the dependencies for it (branches, mail) are a little annoying on qas [01:19] I was not a minute away from asking you about that. [01:20] poolie: You can't do it with a manual upload? [01:20] poolie: how can I help you? [01:20] Without branches? [01:20] hloeung, i'm just trying to work that out [01:21] hloeung, can you tell me how i'd find out if the poimport cron job runs on qas? [01:21] wgrant, ok i'll upload a tarball and we'll see [01:30] poolie: I've checked and it seems there isn't any poimport cron jobs for QAStaging [01:31] could you run rosetta-poimport for me please? [01:32] poolie: sure! [01:35] poolie: https://pastebin.canonical.com/53423/ [01:36] That looks like success. [01:36] There's an email about the error, but nothing about the successes. [01:37] hloeung, also send-bug-notificatinos? [01:40] poolie: done [02:05] wgrant, unless you can think of anything else i'm going to say that's qa-ok [02:06] poolie: It looks fine to me. [03:40] Lifelrss: Back yet? [04:00] Does Y.Assert have a isNotNull ? [04:01] Y.Lang.isValue? [04:01] false for null/undefined, true for everything else. [04:01] Except possibly NaN. That might be false as well. [04:02] I forget. [04:02] This is for a test, mind. [04:02] Y.AssertTrue(Y.Lang.isValue()); ? [04:03] wallyworld: ^ ? [04:04] StevenK: if you are checking that variable xxx is not null and not defined, that will work [04:04] but you don't need the isTrue [04:04] assrtTrue [04:05] or maybe you do [04:05] it's in a test, so yes i think [04:06] there is also isNumber, isBoolean etc [04:06] It's a node [04:07] ah, right, then isValue i think is what you want [04:07] solves the == vs === problem [04:11] wallyworld: Are you on top of your two QA items? [04:11] wgrant: nope, finishing off something else [04:11] Hrm, I wonder why I havent got email from the landing last evening :| [04:12] wallyworld: Any ETA on the QA? I'd like to deploy in the next hourish, before sending it off to the downtime hosts tonight. [04:13] * wallyworld sighs. i was hoping not to have to context switch :-( [04:13] * wallyworld looks at bugs again [04:13] It doesn't look like it should take long :) [04:14] wgrant: Which revision were you planning? [04:14] 14041 [04:14] Send it out to ndt+librarian2 ASAP, then ftpmaster/ppa/librarian1 tonight if nothing blows up. [04:15] Poor mizuho. It will be 150 revisions behind after that NDT. [04:15] I'd been putting off librarian1 updates until it was HA, but that could still be weeks away, given what happened on Thursday :/ [04:16] * StevenK wonders if there is any update with galapagos [04:16] It's only been down for more than a month :) [04:16] It makes https://devpad.canonical.com/~wgrant/production-revnos ugly :( [04:16] * wallyworld stabs qas. qa would be so much easier without the timeout errors [04:17] wallyworld: Indeed :( [04:17] wgrant: You should generate pretty HTML :-P [04:18] StevenK: The script to generate it is, er, slightly unpleasant, due to the format of the input. [04:18] carob:~wgrant/bin/parse-revnos.py, if you have a strong stomach. [04:19] Yes, that is disgusting [04:19] Perl! [04:21] wgrant: Will you add forster in, or that can be done after? [04:21] StevenK: forster/crowberry can be done without downtime later. [04:21] StevenK: I dedicate this one to you :D https://twitter.com/#!/DEVOPS_BORAT/status/117613205576089601 [04:22] But since spm is not here, I shall not ask too much of hloeung :) [04:22] Speaking of Perl. [04:23] wgrant: I can try do those too if you like [04:23] Best Practical appears to have the bzr colocated branch syntax, and are now importing even more RT code into LP :( [04:23] "Source of Oracle is tell me latest version of PostgreSQL can be able download from mysql.com." [04:23] lol [04:23] hloeung: I know codehosting is a pain... [04:26] Forgive me, Unity. I did not mean to offend you by closing Empathy. [04:27] Hah [04:27] I am disappoint. wc -l of my diff is 235 [04:29] wgrant: done [04:30] wallyworld: Thanks! [04:46] Can haz review? https://code.launchpad.net/~stevenk/launchpad/private-bug-unsubscribe-confirm-2/+merge/77091 [04:46] StevenK: i'll grab it [04:48] Awesomeness. [04:48] Or something. [04:49] My two garbo populators are doing nothing on prod [04:50] Continiously blocked by postgres or archivepublisher transactions [04:50] Not continuously. [04:50] But often. [04:50] I'm not sure why they're making no progress. [04:50] I'm trying to figure that out [04:52] so for archivepublisher... we should fix that ;) [04:52] We should. [04:52] It's probably process-death-row. [04:53] Which is now taking 1.5 hours instead of 8 minutes. [04:53] And yes, there's a lot of stuff that should be fixed. [04:53] But we cannot fix them. [04:53] There are no resources to fix them. [04:53] wgrant: i spoke with flacoste and sinzui about security / privacy and implementation [04:54] wgrant: I can give you a summary if you haven't had one already; the next step is for one of us to nab mrevell and run some questions by him [04:54] lifeless: I was about to ask if you wanted to talk about that. I discovered another larger issue overnight. [04:54] Discussed it with sinzui in the standup, and we have no idea how to solve it. [04:55] Apart from going back to 2004 and hitting people who suggest multitask bugs :) [04:55] lifeless: I've not had a summary of the discussions you had, however. [04:56] process-death-row would make sense [04:56] It'll be far more obvious tomorrow. [04:56] If it isn't p-d-r, it's backups, and if its not those two it's replication lag [04:56] Because they'll be using custom DB users. [05:01] lifeless: So, a summary would be nice :) [05:03] StevenK: done, with comments :-) [05:04] StevenK: What if I try to unsubscribe the team that confers visibility? [05:05] wgrant: skype ? [05:44] cinerama, https://bugs.launchpad.net/launchpad/+bug/860273 [05:44] <_mup_> Bug #860273: private ppa 'technical details' incorrect for admins

< https://launchpad.net/bugs/860273 > === vila is now known as babune === babune is now known as vila === almaisan-away is now known as al-maisan [07:29] good morning [07:40] mrevell: Can you think of a better title than "Customise visible information" [07:43] huwshimi, "show/hide"? [07:43] (8 letters) [07:44] lifeless, i'm going to write a braindump pre-lep for ssh oauth and git to get it off my brane [07:44] sure [07:46] poolie: It's for choosing what bug info will appear in the list (the link opens a popup) [07:47] edit result/report columns [07:49] lifeless: Without using the word columns? [07:49] I also don't want it to sound like it will be filtering anything [07:49] tricky [07:49] visible properties? [07:50] put a disclosure triangle next to the column headings? [07:50] huwshimi: so we're editing more than columns ? [07:50] lifeless: This mockup doesn't have columns [07:50] huwshimi: or we're avoiding the word column ? [07:50] huwshimi: the search result doesn't ? [07:52] lifeless: it's just for a normal listing of bugs (except that the bugs are not being displayed in columns) [07:52] fields ? [07:52] dare i ask how are they being displayed? [07:52] poolie: In a list [07:52] views, properties, attributes, fields - easy to hand synonyms [07:53] mm [07:53] i guess what i'm getting at is, perhaps we can do without text and just show the things that are available [07:53] perhaps not [07:54] huwshimi: this is the solution for arbitrary things being included yes ? I like poolies suggestion of showing a single row 'sample' and letting folk drag/drop to-from it [07:55] or perhaps show a sample with greyed out fields for things not being shown and clicking on them enables that field [07:59] ok, that will have to do for today. Night all [07:59] nn === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 261 - 0:[#########]:256 [09:59] teal is sinzui, wally, wgrant, stevenk and [09:59] ? [09:59] lifeless: jcsackett [09:59] thanks [10:02] * wallyworld wishes were were the purple team [10:02] we were [10:09] wallyworld: could be arranged [10:11] itym maroon [10:12] For a suffient bribe? [10:12] *sufficient [10:13] bigjools: YOu sound right out of Godfather there :P [10:13] bigjools: python-oops-twisted 0.0.2 is in trunk, I'm going to cut a release in a minute [10:13] bigjools: ok, when you are out here i'll see what i can do [10:13] bigjools: I couldn't reproduce that wtf thing, so I've asked for you to gather some info [10:14] ok [10:14] bigjools: it may be something like 'something somewhere using cStringIO [10:14] I'll reproduce [10:14] bigjools: I also added support for filtered oopses [10:14] cool [10:15] bigjools: if its filtered it now won't call the fallback at all; if its not published it forwards the event unaltered. [10:15] lifeless: generally I want both [10:16] stub: ReadOnlyLaunchpadDatabasePolicy is only for full-on read-only mode, right? Wasn't there also some policy to get read-only transactions, but on the master store? [10:17] We need to get object modifications in buildd-master under control so we know when we're committing what. [10:20] bigjools: is that endorsing my change or asking for something different ? [10:21] lifeless: it sounds ok, if it's not you can be sure I'll let you know, or fix it :) [10:21] \o/ [10:21] The filtering is so that if you e.g. ratelimit, the fallback doesn't end up not being ratelimited. [10:21] the publishing is the case you identified yesterday [10:22] tarball on pypi now [10:22] bigjools: I need to chase a few other things; can you add it to the download cache yourself? [10:23] lifeless: excellent, I can sure [10:24] jtv: I don't recall a policy for only read-only transactions on the master store. [10:24] :( There's @read_transaction, but that still gives you a regular transaction (it just aborts it). [10:24] (And actually it should probably abort even on failure) [10:25] jtv: What are you trying to do? Might be best to write a context manager that does 'set transaction_read_only to true' (or whatever it is) if necessary and resets on exit. [10:25] Yeah. [10:26] I'm trying to make sure that builders and builds do not get modified except from specific, well-bracketed pieces of code. [10:26] jtv: I think the only place we set transaction to read only mode is in the test harness so 'slave' connections fail writes. [10:27] Then I suppose I could try to promote whatever we have there to something production-usable. [10:27] jtv: We can remove access to them entirely except via stored procedures? [10:27] That may be taking it a bit too far; the code does rely on having the ORM. [10:28] I'm not sure how far down into various class hierarchies the object changes go. [10:28] jtv: So various db users need write access to the tables, but you want to ensure modifications only happen in certain code paths. [10:29] Yes, I think that's right. [10:29] The latter part is definitely right. [10:29] The logic you are enforcing is too complex to do this in the Storm database classes? Or are you scared of people bypassing the ORM? [10:30] No, not particularly worried about people bypassing the ORM. Just don't know how to do it in Storm. [10:30] This *might* mean we need a service that is responsible for making the modifications, and everything else just gets SELECT access to the tables. [10:30] That may already be the case. The immediate problem is that that single service is complex and twisted. [10:31] jtv: properties? [10:31] Yes, so maybe easiest and best in the long run to split it into bits. [10:31] jtv: and/or validators? [10:31] lifeless: oops_twisted is not installing [10:31] We have examples for enforcing some stuff like this at the Storm level... [10:31] error: Setup script exited with error: package directory './oops_twisted' does not exist [10:31] lifeless: that's approaching it from the wrong end. The code is already there, and complex; I want to get a handle on what it's already doing. [10:32] lifeless: and bootstrapping doesn't work on a new checkout so I can't debug [10:32] stub: right now it's too many small bits. That's part of the problem, in a way. [10:32] bigjools: wow thats one messed up tarball [10:32] So as the first step I want database changes explicit, and then I want to use that to make sure no unrelated changes go into the same transaction. [10:32] bigjools: Have I mentioned my... disdain for setuptools? [10:33] lifeless: :( [10:34] stub: although to achieve that, the transactions may well get chopped into smaller bits. But first we need to be very sure that we understand their boundaries. [10:34] Anyone know why we are emitting long poll specific events on object creation/deletion instead of general events any service can listen for? [10:34] bigjools: new tarball up [10:34] lifeless: 0.0.3? [10:35] bigjools: 0.0.2 [10:35] bigjools: it had 0 downloads ;) [10:35] lifeless: tut tut [10:35] I downloaded it [10:35] bigjools: EPIC SHRUG [10:35] lifeless: You are the bane of packagers everywhere :) [10:35] how will I know I have the fixed one? [10:35] bigjools: specifically, because it was barfing on build, you can't have an egg for it, so it won't hit the failure mode of not updating for someone [10:36] bigjools: if it was building brokenly, it would be different [10:36] lifeless: fancy updating the lp code too? :) [10:36] bigjools: not a code problem [10:36] why is bootstrapping buggered? [10:36] bigjools: bad MANIFEST file [10:36] bigjools: so the 0.0.2 tarball file had no contents beyond setup.py [10:37] lol [10:37] README, PKG-INFO and an oops_wsgi directory. [10:37] totally epically fucked [10:37] BTW electrician in the house, I may lose connectivity [10:37] * stub wonders if Storm has a facility for putting a store into read only mode. [10:37] stub: blast. I thought you were referring to knowledge of such a thing earlier. [10:38] stub: If it did, would we have *_ro? :) [10:38] gah Makefiles [10:39] stub: Can't we just use SET TRANSACTUION READ ONLY? [10:39] s/U// [10:39] wgrant: We create all the _ro users such as their default transaction mode is read only [10:39] So the test harness stuff is not applicable here [10:40] But 'with read_only(store):' is little effort [10:42] store.execute('show transaction_read_only').get_one()[0] for the current value, store.execute('set transaction_read_only = true') to set it... [10:42] I could extend the @read_transaction we have now, provided we only use it in fresh transations. [10:43] jtv: if it aborts at the end, it would be a fail to use it for anything that wasn't a fresh transaction [10:43] Unless it stacks or something [10:43] Exactly. [10:44] Stacking it could be risky given its retry behaviour. [10:45] . [10:46] Librarian uses it in one place. Unfortunately the code seems to have celebrate obscurity, but it doesn't look as if it has fresh connections. [10:46] lifeless: still seeing both bugs with latest oops_twisted [10:46] It also uses twisted's deferToThread; allenap, one thing I wondered about there is that storms are not supposed to be thread-safe. Is that all taken care of? [10:46] bigjools: you've updated your versions.cfg ? [10:46] lifeless: I am not using LP [10:47] this is txlongpoll [10:47] bigjools: sure, but its a buildout project too right ? [10:47] lifeless: yeeesssss [10:47] bigjools: so it has its own versions.cfg, right ? [10:47] nope [10:48] that's an LP thing [10:48] DigestSearchResource... another one of those ancient, under-documented classes that used to make our lives a living hell. I'm sure it'll be clear to someone out there, but not to me. :( [10:48] jtv: stores are retrieved through zstorm, which hands out a store specific to the thread. You would have to go out of your way to hand your store to another thread. [10:49] lifeless: I have rebuilt my entire egg from scratch, and oops_twisted 0.0.2 is in dists [10:49] since I specified that in setup.py ;) [10:49] stub: does twisted keep a worker thread with a dedicated store for this kind of thing? [10:50] meep. Well, you may want one ;) [10:50] so that you don't get new releases of $stuff without warning. [10:50] bigjools: anyhow, run buildout with -v or something and confirm that you have 0.0.2 in use. Or check your sys.path etc [10:50] bigjools: you can specify versions in setup.py ? [10:50] jtv: I don't know about twisted worker threads. I just know that when you request a store, you get a store for the current thread and not a store used by some other thread. [10:50] Getting required 'oops-twisted>=0.0.2' [10:50] lifeless: of course you can [10:50] bigjools: anyhow, I believe you. So put a breakpoint in the 0.0.2 code and see what happes [10:51] stub: ah, so it's on-demand. I think that means this is safe, thanks. [10:51] jtv: Each bit of code that is passed to deferToThread() needs to get its own store. [10:51] And does it? :) [10:51] jtv: I don't know about the librarian... [10:51] Apparently it gets its own store on demand, so that sounds like it's alright. [10:52] bigjools: in the 'if ids:' if block at the end of log.py [10:52] allenap: Yeah, never mind the librarian. This bit of code is probably from the days when we thought that cryptic code was better because it was By And For Geeks(tm). [10:52] ok, re-rinning === al-maisan is now known as almaisan-away [10:52] bigjools: lather, rin, repeat. [10:53] jtv: FUGU [10:53] $ dict fugu [10:53] jtv: like FUBU [10:53] mmm noms [10:53] fugu [10:53] n : delicacy highly prized in Japan but highly dangerous [10:53] Why are we emitting LongPoll specific events rather than generic events on Storm lifecycle that any process can subscribe to? [10:53] allenap: ^ [10:54] bigjools: thank you, that helps. I think the other one was fgbg. === almaisan-away is now known as al-maisan [10:55] Just wondering if there is a reason, or if services that listen for new rows to be created in the database are going to be listening for misnamed events [10:55] stub: I don't understand. The longpoll code subscribes to the generic events and then re-emits them via Rabbit. [10:55] oh... I thought I saw us explicitly emitting LongPollSomething events on Storm object creation and deletion, rather than StormSomething events. [10:56] Which might just be naming [10:57] lifeless: http://pastebin.ubuntu.com/697804/ [10:57] stub: not taking the risk on @read_transaction; I can't be sure what games people play with it. A "with" sounds good. I'll also need one that gives a temporary exemption. [10:58] stub: There are subscription handlers for (Storm, IObject{Created,Modified,Deleted}Event) so far, so it does rely on code to explicitly emit those lifecycle events. We can add more subscription handlers for other events later, this just fits our needs so far and should fit a lot of other situations. [10:58] jtv: I don't know the details of your problem, but a pair of context managers that can be nested would be nice and potentially useful elsewhere. [10:59] stub: yup. By "would be nice" by the way I do not mean that I expect you to do it; I'll whip something up and if you're interested, let you know when I think it's in a reviewable shape. [10:59] allenap: As long as we don't end up emitting 3 specific messages per row updates when 1 general one would do and can be routed with rabbit. [11:01] stub: That will be the case. By default no lifecycle events are emitted for Storm stuff; it needs to be done explicitly. [11:01] cool [11:02] Might be able to use this for real time karma updates... [11:02] Yeah :) [11:03] Still needs the daily job if we want degradation though so not a major win unless we decide on a new design [11:05] allenap: Originally I was thinking of hooking up zope.event, but I didn't know about the Storm event model back then and I don't think we gain anything by hooking zope.event up in addition. [11:05] (Maybe Storm should be using zope.event :) ) [11:08] jtv: I'm happy to review it. It should be maybe 10 lines plus boilerplate? [11:09] stub: I'm more worried about design than I am about the code. Who commits when. [11:12] jtv: I worry that we spend too much time working around a flawed design rather than rewriting - some of this stuff has been a problem for years and most people are too scared to mess with it. I certainly don't know enough to know if the existing design can be rescued or needs to be replaced. [11:12] stub: That comes up a lot nowadays... [11:12] But buildd-manager was rewritten like 2 years ago. [11:12] My fingers ache to do it again, but realistically... [11:13] See the "read-only transactions" part as a way of getting a grip on what the existing design really does. [11:13] Once we have that under control, we'll have a much better idea of our options. [11:14] stub: This does rely on zope.event, but there are no automagically emitted events as Storm objects change state. Storm model instances do have EventSystem which can be used to track changes at a very fine-grained level, but I think piping those out over a message queue would be like a fire hose. [11:14] allenap: Isn't that why we have this high performance messaging system ;-) [11:15] It can handle a zajillion messages per whatsit! [11:15] stub: We have yet to see if it's high performance :) [11:15] allenap: I also considered database triggers emitting events... [11:15] (In practice I hear it's often more like 0.6 zajillion per whatsit.) [11:16] stub: Oh, in that case, I think we should hook into sys.settrace(). [11:16] You win [11:16] Unless I suggest.... ptrace! [11:16] Dammit! [11:18] On a sidenote, I see that raw_connect defaults to SERIALIZABLE. I thought it was READ COMMITTED nowadays. Will we go REPEATABLE READ with 9.1, or upgrade to the new SERIALIZABLE? [11:19] gmb, hi, got time for a short review? https://code.launchpad.net/~danilo/launchpad/bug-847485/+merge/77142 [11:20] danilos: Hi, sure. [11:20] wgrant was talking about serializable/read committed by default the other day. Scripts should be defaulting to read committed since they almost certainly won't handle serialization exceptions. [11:20] Yes, I thought we made them default to read committed some 3 or 4 years ago. So surprising to see this in raw_connect. [11:20] And one day I'll read the docs and learn what the difference between repeatable read and serializable is [11:21] jtv: oh, 9.1 adds explicit repeatable read ? [11:21] jtv: So, I've been far too deep in this stuff lately... === al-maisan is now known as almaisan-away [11:21] jtv: Is raw connect what scripts use or what the appserver eventually relies on for its connection? [11:21] lifeless: did you see my debugger results? [11:21] lifeless: sort of. It's the new name for the existing "serializable." [11:21] jtv: and there is a new serializable ? [11:21] bigjools: no [11:21] jtv: initZopeless, may it rest in peace, override the default to read_committed. [11:21] s/override/overrode/ [11:22] jtv: All scripts called that, so scripts ended up read_committed. [11:22] its more serializable than the old serializable I hear [11:22] lifeless: yes. Turned out there was a purely optimistic implementation for true SQL serializability for MVCC databases. [11:22] jtv: While the appserver didn't, so ended up with the default in the config file: serializable. [11:22] lifeless: http://pastebin.ubuntu.com/697804/ [11:22] wgrant: thanks for explaining that. [11:22] lifeless: the report dict has no "type" entry [11:22] jtv: Scripts now override this explicitly. [11:22] I say "SQL serializable" because there's been great confusion over it. [11:22] jtv: Rather than it being hidden in the default of one of initZopeless' arguments. [11:23] The standard describes two symptoms that you don't want in transaction isolation: "phantom reads" and, er, another thing. [11:23] One is basically "you've seen a row in this transaction, you read it again, and now it's changed." [11:23] bigjools: ok, new bug :) - what does the original event have in it ? (first line of that function, print event) [11:23] The other is, if I recall correctly, rows not suddenly appearing in or disappearing from the results of your query. [11:24] SQL described the isolation levels in terms of the exclusion of these two symptoms, and said that neither can happen in SERIALIZABLE. [11:24] So that's what postgres implemented. [11:24] lifeless: http://pastebin.ubuntu.com/697815/ [11:24] It didn't have the changing rows, so two of the lesser isolation levels (read uncommitted & repeatable read) were utterly meaningless in postgres. [11:24] Instead you always got one of the better isolation levels. [11:25] But then it turned out that what SQL said about phantom reads etc. in SERIALIZABLE was descriptive, not definitive. [11:25] lifeless: different problem, *same* bug :) [11:25] which is the sort of behavior ODBC encoded in its api (you get the isolation you requested or better) [11:25] The *definition* of SERIALIZABLE is that the result must be as if no two transactions overlapped in time. [11:25] bigjools: same top level symptom agreed. [11:26] And so postgres 9.1 has an optimistic technique to guarantee serializability, at the cost of more serialization failures obviously. [11:26] bigjools: what has me confused here though is how the type key is missing [11:26] But no new locks, which is incredibly cool in itself. [11:27] REPEATABLE READ in postgres actually guarantees more than it does in SQL, but it was the next step down for the old, dishonoured SERIALIZABLE implementation. [11:27] At this point I have no idea if the appserver would benefit or suffer from the new isolation level. Scripts will remain with read committed by default. [11:28] bigjools: you've got a tb_text and a time, which means emit didn't crash [11:28] bigjools: can you print config.on_create [11:29] I suspect we need to instrument our transaction retry handling to see what sort of genuine overhead we get with the extra protection [11:29] Might be useful to know at any rate. [11:29] Yup [11:29] lifeless: what scope? [11:29] it's not in that func [11:29] bigjools: self.conf [11:29] bah [11:29] FWIW the only paradoxes that the existing "serializable" leaves us open to involve cross-table consistency. [11:29] ah [11:29] self.config [11:30] lifeless: you want the function or it's invocation? [11:30] its [11:30] its a list of functions, I hope [11:30] self.config.on_create [11:30] 2011-09-27 12:30:01+0100 [-] (Pdb) [, , , , ] [11:30] ok, so we need to look at whats going on with emit [11:31] line 58 [11:31] it should branch into the 'if 'failure' in eventDict: block [11:31] and before we call [11:31] report = self.config.create(context) [11:32] our context should have an exc_info key with a (type, value, tb) tuple in it [11:32] lifeless: I think you need to re-create this locally [11:33] bigjools: yeah, probably. [11:33] it's not hard [11:33] bigjools: I have tomorrow off [11:33] bigjools: for baby stuff, but I'll see what I can do [11:33] I'm in hospital later :p [11:33] bigjools: can you shoot me a mail with 'do this you daft bugger and it should break for you' instructions ? [11:33] yarp [11:34] defensive programming says we should tolerate the type etc being missing [11:34]