| rockstar | Oh balls. jsbuild is icky. | 01:58 |
|---|---|---|
| james_w | is this a known problem, or an artefact of building bzr-builder itself? https://launchpadlibrarian.net/56778044/buildlog.txt.gz | 02:03 |
| mwhudson | Get:3 http://ppa.launchpad.net/dailydebs-team/bzr-builder/ubuntu/ maverick/main bzr-builder all 0.4+bzr104+0.0ubuntu45~maverick1 [32.7kB] | 02:05 |
| rockstar | james_w, yeah, it looks like bzr-builder is still not updated on the buildds... | 02:05 |
| rockstar | Le sigh. | 02:06 |
| mwhudson | vs the normal: | 02:06 |
| mwhudson | Get:1 http://archive.admin.canonical.com/ubuntu/ lucid-cat-lpbuildd/main bzr-builder 0.2+bzr78+0.0ubuntu44~0.IS.10.04 [25.9kB] | 02:06 |
| mwhudson | rockstar: i think it's because the ppa being built for has bzr-builder in it | 02:06 |
| james_w | that could well be it | 02:06 |
| lifeless | mars: hi | 02:12 |
| rockstar | mwhudson, I still think we need at least 0.3 on the builders themselves in order to use SAFE_INSTRUCTIONS. Isn't that right james_w? | 02:13 |
| james_w | I think so | 02:13 |
| mwhudson | rockstar: well s/on the builders themselves/in the internal repo/ | 02:17 |
| mwhudson | rockstar: as it looks like it's installed for each build | 02:17 |
| mwhudson | (it's not in the chroot) | 02:17 |
| mwhudson | i'm assuming its invoked inside the chroot? | 02:17 |
| rockstar | mwhudson, yeah, we haven't gotten that sorted out yet. There's an open RT about it, but it hasn't been addressed yet. | 02:18 |
| thumper | wallyworld___: ping | 02:52 |
| wallyworld___ | thumper: here | 02:52 |
| thumper | wallyworld___: skype? | 02:52 |
| poolie | jam1: how did you got with lp-serve? | 03:02 |
| mwhudson | hmm | 03:27 |
| mwhudson | when i try to authenticate against login.launchpad.net from a locally running webapp, https://login.launchpad.net/+openid seems to be served as text/plain | 03:28 |
| mwhudson | that's a bit off | 03:28 |
| mwhudson | *odd | 03:28 |
| wgrant | mwhudson: SSO has been playing up a bit this morning and last night. | 04:13 |
| wgrant | It seems to be reasonably happy. | 04:13 |
| === jamesh_ is now known as jamesh | ||
| === jam1 is now known as jam | ||
| === Ursinha-bbl is now known as Ursinha-afk | ||
| === almaisan-away is now known as al-maisan | ||
| SpamapS | I'm curious, how is launchpad librarian's backend handled? | 07:02 |
| wgrant | SpamapS: What do you want to know about it? | 07:17 |
| wgrant | AIUI it's just on a machine with lots of disk. | 07:17 |
| SpamapS | I just get timeouts quite a bit. | 07:17 |
| SpamapS | Wondering why. | 07:17 |
| wgrant | From the librarian? | 07:18 |
| SpamapS | yeah | 07:18 |
| wgrant | That's not something I've seen before. | 07:18 |
| SpamapS | I'm not alone, other bug triagers have experienced similar things | 07:18 |
| wgrant | Just now? | 07:18 |
| SpamapS | wgrant: no, they seem to come in spurts. | 07:42 |
| SpamapS | wgrant: the next time I experience it, I"ll bring it up more promptly in here | 07:42 |
| stub | SpamapS: If you have a launchpadlibrarian.net URL, then you are talking to the Librarian. If you have a launchpad.net URL, you are being proxied via Launchpad for security reasons and the timeout is happening there (open bug, feature landed that should fix it, but still waiting to be tested) | 08:00 |
| SpamapS | stub: very likely it was always on private bugs. Good to know its been noticed. :) | 08:01 |
| SpamapS | mostly just curious as I imagine the librarian has a lot of files. | 08:01 |
| wgrant | Not too many. We're not even at ID 57000000, and a lot of those have since been deleted. | 08:06 |
| persia | wgrant, Depends on your scale of reference. I don't think I have any machines with millions of files :) | 08:07 |
| stub | Its just a big tree of files, similar layout to any squid cache | 08:08 |
| stub | metadata about the files is all in PostgreSQL | 08:09 |
| adeuring | good morning | 08:39 |
| StevenK | wgrant: Have you seen anything like http://paste.ubuntu.com/503073/ ? | 09:01 |
| mrevell | Hey | 09:02 |
| wgrant | StevenK: No, but others have. Apparently a 'make clean' fixes it. | 09:04 |
| StevenK | wgrant: Interestingly, 'make clean; make' doesn't fix it. | 09:11 |
| wgrant | Odd. | 09:14 |
| bigjools | good morning | 09:14 |
| wgrant | Morning. | 09:15 |
| wgrant | Did the deletion work? | 09:15 |
| noodles775 | StevenK: did you try deleting relevant direcotries from /var/tmp/ | 09:16 |
| noodles775 | (and ensuring there are no librarian processes hanging around) | 09:16 |
| bigjools | wgrant: seems like it recovered some yes | 09:18 |
| wgrant | bigjools: But not half the archive? Excellent :) | 09:18 |
| StevenK | noodles775: There's no python processes related, and deleting everything from /var/tmp has no effect | 09:19 |
| noodles775 | hrm. | 09:19 |
| wgrant | make clean fixed it for gmb last night. | 09:19 |
| wgrant | I wonder why it didn't work here. | 09:19 |
| wgrant | How is buildd-manager looking? The queues have been disappointingly small today. | 09:21 |
| jelmer | wgrant: I seems to be doing alright so far. | 09:22 |
| wgrant | I'm not sure whether the tiny queues are because it's just so quick now. | 09:23 |
| wgrant | Or if they just mean that it hasn't really had much thrown at it. | 09:23 |
| StevenK | Wait until the first autosyncer for natty | 09:23 |
| wgrant | Heh. | 09:24 |
| bigjools | wgrant: I see ~280M saved | 09:25 |
| wgrant | bigjools: s/M/G/? | 09:26 |
| bigjools | wgrant, jelmer: the falloff rate for lots of queued jobs (we get a spike of ~180 jobs each night) is much faster now | 09:26 |
| bigjools | wgrant: it might be G, I think the graph is lying to me | 09:26 |
| wgrant | bigjools: Average build time should also have dropped by approximately an awful lot. | 09:27 |
| bigjools | yes | 09:27 |
| bigjools | it has | 09:27 |
| jml | ooh. do we have a graph for that too? | 09:27 |
| bigjools | I'll dig up stats later | 09:27 |
| bigjools | somewhere yes, build lag <blah> | 09:27 |
| wgrant | I will be interested to see all these pretty graphs in a couple of months. | 09:28 |
| bigjools | heh | 09:28 |
| jml | A someday/maybe of mine is to put all of the ones that are relevant to actually administrating Launchpad into Launchpad | 09:29 |
| jml | rather than the ones that are merely stats-gathering / popularity metrics | 09:29 |
| bigjools | is administrating some strange Australian word? | 09:31 |
| StevenK | Like 'setuping' | 09:31 |
| jml | bigjools: I've heard it often before, so perhaps yes. | 09:33 |
| poolie | 'administer launchpad' sounds a bit medical | 09:33 |
| poolie | perhaps appropirate | 09:33 |
| jml | bigjools: I guess I should say "ministering unto" now that I'm in the Old World | 09:33 |
| poolie | :) | 09:34 |
| bigjools | jml: it must have had some sort of attraction for you to come here? :) | 09:34 |
| wgrant | "administrating" is valid, but rather rare nowadays... | 09:42 |
| bigjools | it's not even in my dictionary | 09:42 |
| wgrant | Well, I may then have to make disparaging remarks about your dictionary. | 09:45 |
| jml | The Shorter doesn't have an entry for it, but it doesn't for many -ing words. | 09:47 |
| bigjools | http://dictionary.cambridge.org/spellcheck/british/?q=administrating | 09:47 |
| wgrant | Some sources seem to say that "administrate" was incorrectly formed from "administration", but others say that that is a common misconception. | 09:48 |
| * wgrant gives up. | 09:48 | |
| jml | Cambridge? Bah. What would that upstart little campus know about the English language! | 09:49 |
| bigjools | administrate is not there either :) | 09:49 |
| jml | I have to go out. Back in a bit. | 09:50 |
| bigjools | jml: quickly, is your b-m branch up to date? | 09:51 |
| poolie | losa ping? | 10:08 |
| mthaddon | poolie: hi | 10:08 |
| poolie | hi tom, could you help me briefly to validate the flag control panel? | 10:08 |
| poolie | <poolie> on https://edge.launchpad.net/+feature-rules | 10:08 |
| poolie | <poolie> please add a line to the end: | 10:08 |
| poolie | <poolie> "test_rule test_scope 0 on" | 10:08 |
| poolie | <poolie> without the quotes | 10:08 |
| mthaddon | as a new line? | 10:10 |
| poolie | yes | 10:10 |
| mthaddon | ok, done | 10:10 |
| poolie | no problems? | 10:11 |
| poolie | then delete it again, and we're done | 10:11 |
| poolie | thanks | 10:11 |
| poolie | you should now be able to use this to change feature flags, without needing raw sql | 10:11 |
| mthaddon | ok, done | 10:11 |
| wgrant | Sometimes we cannot build packages on Launchpad, because the build-server | 11:24 |
| wgrant | runs out of memory. We need at least 5-6GB Ram for more-less normal | 11:24 |
| wgrant | compilation. | 11:25 |
| wgrant | ^^ I am scared | 11:25 |
| jelmer | wgrant: what package is that? | 11:25 |
| wgrant | jelmer: yade (see launchpad-users) | 11:27 |
| wgrant | noodles775: Any progress on the log parser front? | 11:29 |
| jml | hello | 11:40 |
| jml | bigjools: yes. | 11:41 |
| bigjools | jml: I'll attack it more later today | 11:42 |
| jml | bigjools: cool. | 11:42 |
| jml | bigjools: my plan of attack for buildd-slavescanner.txt was to make a branch that killed it that would work w/ both our new branch & trunk | 12:04 |
| jml | bigjools: but I got fed up with the twisted/testtools thing. | 12:04 |
| bigjools | jml: yes, that's a pain. Did you say you could fix that? | 12:10 |
| jml | bigjools: Circumstances permitting, yes. | 12:10 |
| jml | bigjools: unfortunately, I haven't really had any time to hack since I got back. | 12:15 |
| bigjools | jml: me neither | 12:15 |
| bigjools | that will change this afternoon | 12:16 |
| jml | bigjools: I'm having a night in Friday, so maybe I'll get it done then. | 12:16 |
| bigjools | jml: BTW you'd think that my change to lp_sitecustomize.py would rarely cause a conflict - guess what.... ! | 12:16 |
| jml | :( | 12:17 |
| bigjools | easy to fix, I just thought it was funny | 12:17 |
| jml | yeah. | 12:19 |
| lifeless | jml: I can has review? https://code.edge.launchpad.net/~lifeless/launchpad/bug-627701/+merge/37094 | 12:24 |
| jml | lifeless: sure. looking now. | 12:25 |
| lifeless | jml: if its within cooee, could you just tweak and land; its a critical patch | 12:36 |
| lifeless | jml: I've now been up for 23 hours, so gnight ;) | 12:37 |
| jml | lifeless: g'night | 12:38 |
| === mrevell is now known as mrevell-lunch | ||
| bigjools | jml: I'd debugging that adaptation error we saw in the slave manager test, if you remember it? | 13:18 |
| jml | bigjools: I remember the fact of it, but not much else. | 13:19 |
| bigjools | jml: it's something that the @write_transaction is doing. BuildQueue.job gets nulled out :/ | 13:20 |
| bigjools | if I muck about with cache invalidation it works | 13:20 |
| jml | bigjools: ahh right. | 13:20 |
| bigjools | so I'm rather confused as to htf is does that | 13:21 |
| jml | a good place to start might be to do a timeline | 13:21 |
| jml | (or print a bunch of stuff, that always helps) | 13:21 |
| bigjools | what does "_get_sqlobject_store().reset()" do | 13:22 |
| jml | don't know. is it a storm store? | 13:23 |
| bigjools | yes | 13:23 |
| bigjools | oh, nm | 13:23 |
| bigjools | I thought that was screwing it but it's not | 13:23 |
| bigjools | jml: there's some *weird* stuff happening. Look at this diff: http://pastebin.ubuntu.com/503224/ | 13:31 |
| jml | bigjools: I see it. | 13:32 |
| bigjools | see the second print I added? | 13:32 |
| jml | indeed. | 13:32 |
| === mrevell-lunch is now known as mrevell | ||
| bigjools | when that's added, the code works, if I comment it out, I get the adaptation error | 13:32 |
| bigjools | double you tee eff | 13:32 |
| jml | that sounds transactional. | 13:33 |
| bigjools | yes | 13:33 |
| bigjools | cache problems | 13:33 |
| bigjools | see what's in the finally? | 13:33 |
| bigjools | I don't know why that's needed | 13:33 |
| bigjools | I suspect it's fucking with things | 13:33 |
| jml | bigjools: perhaps there are tests for sqlbase.py that explain why. | 13:34 |
| bigjools | darn, stub's gone | 13:34 |
| bigjools | right, if I comment out the reset() it also works | 13:35 |
| bigjools | perhaps the answer will present itself over lunch | 13:39 |
| jml | yeah | 13:39 |
| jml | another approach might be to make a minimal test that reproduces the problem... slowly cutting the extraneous crap away | 13:40 |
| sinzui | mrevell, I just remove users from the list in bounce/out-of-office cases. suspending is very hard to undo | 13:40 |
| sinzui | actually, now that the user is suspended, it is not possible to remove the user from the list of members :) | 13:41 |
| mrevell | sinzui: Damn. Okay, thanks, I was thinking that the problem would apply generally, hence the suspension. How do I remove someone from a mailing list? | 13:45 |
| sinzui | when he is not suspended, you visit his membership page from the members list of the team. You can remove him or make him an admin. | 13:46 |
| * sinzui looks for example | 13:46 | |
| sinzui | https://edge.launchpad.net/~launchpad-users/+member/matthew.revell | 13:47 |
| mrevell | Ah yes, thanks sinzui | 13:48 |
| sinzui | mrevell, because launchpad-users is a mega team, I usually hack the url instead of listing every member https://edge.launchpad.net/~launchpad-users/+members | 13:48 |
| mrevell | So, I think I see what you mean about it being hard to unsusepend him. | 13:50 |
| mrevell | doh | 13:50 |
| sinzui | jml: unification requires me to be very awake. I will think about both questions, neither are easy, though I personally think both are desirable | 13:51 |
| jml | sinzui: agreed. remember, we don't care about merging the namespaces yet, just stopping more clashes. | 13:51 |
| sinzui | right. teams with project names really confuse me when I am helping users who do not know what either is | 13:52 |
| mars | abentley, ping, have you seen spurious test suite failures like this before?: https://pastebin.canonical.com/37924/ | 14:30 |
| abentley | mars: I don't think so. | 14:30 |
| bigjools | gary_poster: hi, can I bother you with some questions about transactions and caches and some weird behaviour I'm seeing? | 14:37 |
| StevenK | mars: I have -- the Hudson instance reguarly has that failure | 14:39 |
| gary_poster | gmb or other malone person: help request: starting on https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/628755 , I click on "Also affects project" but then only see Apport on https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/628755/+choose-affected-product | 14:39 |
| _mup_ | Bug #628755: Impossible to log in in Launchpad using apport from a tty console with w3m <iso-testing> <Launchpad Foundations:Triaged> <apport (Ubuntu):Invalid> <w3m (Ubuntu):Confirmed> <w3m (Debian):Unknown> <https://launchpad.net/bugs/628755> | 14:39 |
| _mup_ | Bug #628755: Impossible to log in in Launchpad using apport from a tty console with w3m <iso-testing> <Launchpad Foundations:Triaged> <apport (Ubuntu):Invalid> <w3m (Ubuntu):Confirmed> <w3m (Debian):Unknown> <https://launchpad.net/bugs/628755> | 14:39 |
| wgrant | gary_poster: "Choose another project" | 14:40 |
| gary_poster | bigjools: on call but will ping | 14:40 |
| bigjools | gary_poster: ok, thanks | 14:40 |
| gary_poster | wgrant: ah, how weird. thanks | 14:40 |
| wgrant | gary_poster: Very strange UI there, yes.. | 14:41 |
| mars | abentley, benji has seen that failure three times in a row on EC2 with this branch: https://code.edge.launchpad.net/~benji/launchpad/wadl-refactoring/+merge/36452 | 14:50 |
| mars | abentley, it certainly looks spurious... unless the test starts up an external process for testing the API or something | 14:51 |
| abentley | mars: The worker could well be an external process. | 14:52 |
| bigjools | stub: I've got a problem with the @write_transaction decorator | 15:09 |
| bigjools | have you got time to help or is it too late there? | 15:10 |
| stub | That some twisted thingy? | 15:10 |
| bigjools | no | 15:10 |
| bigjools | it was in the librarian module | 15:10 |
| bigjools | but I moved it recently | 15:10 |
| stub | Librarian counts as 'some twisted thingy' :) | 15:10 |
| bigjools | anyway check out this diff http://pastebin.ubuntu.com/503278/ | 15:11 |
| bigjools | the decorator lives in lp.services.database | 15:11 |
| bigjools | it calls the code in the diff after the decorated function finishes | 15:11 |
| bigjools | the Librarian is more than twisted ... | 15:12 |
| bigjools | stub: the problem I am seeing is in some tests for the branch jml and I are working on for a fully async buildd-manager | 15:13 |
| bigjools | the decorated function returns a buildqueue vaguely atomically with that decorator | 15:13 |
| bigjools | it's supposed to have a "job" property, but that call to reset the store nullifies the property | 15:13 |
| bigjools | I can't for the life of me work out why | 15:14 |
| bigjools | if I comment out the reset, it DTRT | 15:14 |
| bigjools | also weirdly if I uncomment that "print ret.job" it also fixes it | 15:14 |
| bigjools | so I suspect some dodgy cache interaction here | 15:16 |
| stub | bigjools: I'd agree. Are you sure of the order your stacked decorators are being run? You can confirm the write_transaction decorator is committing before the reset_store_decorator is resetting the store? | 15:17 |
| stub | Not that I understand why you would want to do that... | 15:17 |
| bigjools | stub: I went through in pdb and it commit()s before the reset | 15:18 |
| bigjools | I've no idea why the reset is needed | 15:18 |
| bigjools | and how that could affect this | 15:18 |
| stub | Well, it is resetting the SQLObject store (likely the Master), so it is old SQLObject legacy code. | 15:19 |
| stub | reset_store seems to be there to support changing connection settings, such as the database user you are connected as. | 15:20 |
| bigjools | is it still really needed? | 15:21 |
| stub | I don't see why. | 15:23 |
| stub | I don't see why it was ever needed, but I never really liked this pattern anyway - the decorators always seemed to be a hack to support code written for autocommit system to sort of work with transactional systems. | 15:24 |
| bigjools | well, I am using it so that I get an automatic retry | 15:24 |
| stub | I'm not sure if there is some subtlety I'm not thinking of, or if the @reset_stores are there to work around some early Storm issue | 15:25 |
| bigjools | I'm hoping that gary_poster can weigh in when he's off the phone :) | 15:26 |
| gary_poster | really still on the phone ;-) | 15:27 |
| stub | bigjools: Suggest you read the docstring of Store.reset and weep | 15:27 |
| stub | bigjools: Looks like you have to throw away your objects after the .reset() is called | 15:28 |
| bigjools | :/ | 15:29 |
| bigjools | I wish that was an option | 15:30 |
| stub | I still don't see why you want the reset. Write another decorator that doesn't reset. | 15:30 |
| stub | The decorators are broken anyway as they only reset one of the Stores - not all of them. | 15:31 |
| bigjools | awesome | 15:32 |
| stub | read_transaction should use transaction.doom() too, which wouldn't have existed when it was written, to ensure that nothing in func() commits. | 15:33 |
| bigjools | weep | 15:34 |
| stub | That one isn't a bug, but would be additional protection | 15:34 |
| allenap | gmb, anyone: Do you know why the SourceForge bug tracker is disabled? | 15:34 |
| gmb | allenap: Because we can't sync with it. | 15:36 |
| gmb | So it was just chewing cycles and failing. | 15:36 |
| allenap | gmb: Did that change recently? | 15:38 |
| gmb | allenap: Nope, ages ago. The problem is that the SF templates changed but our SF ExternalBugTracker screen scrapes. | 15:39 |
| gmb | Hence, boom. | 15:39 |
| gmb | But we haven't been able to assign anyone to fix it. | 15:39 |
| bigjools | stub: ok cheers, I'll mull this one over | 15:40 |
| allenap | gmb: Gah. Also, there are lots of registered bug trackers with http://sourceforge.net/tracker/?group_id=336232&atid=1408830 like urls. I thought those would have been prevented. | 15:40 |
| allenap | Or maybe we don't de-dupe those. | 15:41 |
| mars | flacoste, ping | 15:43 |
| flacoste | hi mars | 15:43 |
| gmb | allenap: I have no idea how we deal with those (Well, badly, apparently) but I haven't looked at SF for > 18 months, I think. | 15:43 |
| allenap | gmb: Okay. | 15:45 |
| allenap | gmb: And ta. | 15:45 |
| gary_poster | bigjools: off call. can I still be of help, or did stub already dash your hopes and dreams sufficiently? | 15:45 |
| bigjools | gary_poster: he largely did, yes :) | 15:45 |
| gary_poster | :-) ok | 15:45 |
| bigjools | gary_poster: the pertinent question was why is the write_transaction decorator resetting the store after committing | 15:45 |
| bigjools | it's screwing with my partial commit, basically | 15:46 |
| gary_poster | and the answer was something to the effect of "because that's how things are done with Storm/our DB"? | 15:46 |
| bigjools | gary_poster: neither of us knows | 15:47 |
| gary_poster | oh | 15:47 |
| bigjools | could be an sqlobject throwback | 15:47 |
| bigjools | the effect of doing it is that all my in-memory db objects are suddenly invalid | 15:48 |
| gary_poster | I know that I've talked to Francis about this before--ZODB keeps objects around after commits, and AIUI Landscape actually does too | 15:48 |
| gary_poster | I believe we don't because of paranoia | 15:48 |
| gary_poster | but that's something from well before me being around | 15:48 |
| bigjools | yeah | 15:49 |
| gary_poster | stub, does that ring a bell, that we reset on commits because of paranoia, and Landscape does not? | 15:49 |
| gary_poster | I suspect to change that, we'd have to do a big honking audit and see what the implications are and blah blah blah | 15:50 |
| bigjools | gary_poster: it's only the write | 15:51 |
| bigjools | gary_poster: it's only the write_transaction decorator | 15:51 |
| bigjools | irc fail | 15:51 |
| bigjools | which is used only in my app and the librarian AFAICT | 15:53 |
| gary_poster | the read transaction decorator doesn't toss everything out at the beginning? I think that's our policy for web requests, so it ought to be the story for other code too. I don't know the story for those decorators, but what stub says above about transaction.doom sounds right. | 15:53 |
| stub | gary_poster: It might be a paranoia thing, but I don't know if it actually helps at all. | 15:53 |
| stub | gary_poster: It might be an attempt to ensure that any objects that leak outside of the transaction are useless and can't be used to accidently start a new transaction | 15:54 |
| gary_poster | stub, do we have invalidations set up for Storm across connections? | 15:54 |
| stub | eg. access a stale attribute on an object and a new transaction is started | 15:54 |
| gary_poster | that's the kind of thing that would be unncessary with the current set up | 15:55 |
| stub | no, we only do that in the appserver. We have lots of code that relies on objects being available across transactions | 15:55 |
| stub | jml, spiv or jamesh might know the history of why the reset is there. | 15:56 |
| jml | I don't. | 15:56 |
| jml | We used to have something similar for the authserver (RIP) | 15:56 |
| gary_poster | but, I mean, a changed object committed in thread/connection X will cause that object to be flushed and reloaded in subsequent thread/connection Y, yeah, stub? | 15:57 |
| * gary_poster about to go on another call | 15:57 | |
| jml | perhaps it is meant to be used with threads. bigjools certainly isn't using threads yet. | 15:58 |
| gary_poster | subsequent transaction in thread/connection Y I mean | 15:58 |
| gary_poster | yes, the policy is for threads | 15:58 |
| bigjools | that'd make a lot more sense | 15:59 |
| stub | jml: These decorators would be those same authserver decorators | 16:00 |
| jml | stub: ahh, ok :) | 16:00 |
| jml | stub: then yeah, we were doing @defer_to_thread; @write_transaction | 16:01 |
| bigjools | jml: what's the right way of re-raising an exception as a Failure? | 16:03 |
| jml | bigjools: depending on exactly what you mean: try: thing_that_raises(); except: return Failure() | 16:03 |
| bigjools | ah that was it | 16:03 |
| jml | bigjools: alternatively, just use maybeDeferred | 16:03 |
| jml | return maybeDeferred(thing_that_raises) | 16:04 |
| bigjools | jml: the problem is in the startBuild code, it raises from verifyBuildRequest | 16:04 |
| jml | bigjools: ahh ok. | 16:04 |
| bigjools | I don't want to return | 16:04 |
| bigjools | jml: see the _dispatchBuildCandidate we wrote | 16:05 |
| bigjools | the failure.trap does bugger all for CannotBuild which happens immediately :) | 16:05 |
| * jml depresses his mental clutch and swiftly changes gears | 16:05 | |
| jml | bigjools: yeah, I'd change this line: | 16:06 |
| jml | d = self.startBuild(candidate, logger) | 16:06 |
| jml | to: | 16:06 |
| jml | d = defer.maybeDeferred(self.startBuild, candidate, logger) | 16:06 |
| bigjools | right | 16:06 |
| bigjools | ok that's more like it - now to work out how we buggered the logic elsewhere :) | 16:09 |
| jamesh | gary_poster: some of the big hammer style reset logic probably traces its roots back to when the code was using sqlobject/sqlos | 16:27 |
| gary_poster | jamesh: ah ok, thanks. so, we ought to consider removing the hammer and see if it buys us any performance wins, then, in your opinion? | 16:28 |
| jamesh | sqlos's transaction handling was particularly busted, to the point where it would only join a connection to the transaction the first time. So tearing things down completely was necessary to make the second transaction in the thread work | 16:29 |
| gary_poster | bleh | 16:29 |
| jamesh | there might be other code that depends on it, but Storm itself shouldn't need that kind of thing. | 16:29 |
| === Ursinha is now known as Ursinha-lunch | ||
| jamesh | sqlobject on its own wasn't so bad, but sqlobject+sqlos was a mess. | 16:31 |
| gary_poster | right, the other code is what I was afraid of generally, since I knew Landscape was keeping the objects around | 16:33 |
| jamesh | like Storm, sqlobject had its own connection wrappers and did some house keeping on commit or rollback. | 16:34 |
| jamesh | sqlos tried to get sqlobject to run on top of a zope.rdb connection, and then try to make sure the house keeping occurred when the connection got committed or rolled back behind sqlobject's back | 16:35 |
| jamesh | it didn't always get things right. | 16:35 |
| jamesh | The Storm zope integration code does things right, and the Storm level abstraction is registered with the transaction manager | 16:35 |
| gary_poster | Right, cool, jamesh. If ever I want to muddle around in the code, do you happen to know where the code is in Storm to invalidate changed objects on transaction boundaries? | 16:39 |
| bigjools | jml: Total: 32 tests, 0 failures, 0 errors | 17:19 |
| jml | bigjools: woot. | 17:19 |
| bigjools | I am surprised | 17:19 |
| jml | bigjools: this test_manager? | 17:19 |
| bigjools | yes | 17:20 |
| bigjools | all the FakeMethod crap is still there, we can do it properly now | 17:20 |
| jml | I'm surprised too :) | 17:20 |
| bigjools | and I can simply remove TestRecordingSlave | 17:20 |
| jml | what about RecordingSlave? | 17:20 |
| jml | can you remove that? | 17:20 |
| bigjools | yup | 17:21 |
| bigjools | it's not used in that branch at all | 17:21 |
| jml | \m/>.<\m/ | 17:21 |
| === Ursinha-lunch is now known as Ursinha | ||
| * bigjools does a little dance | 17:21 | |
| jml | bigjools: I can cast my eye over the code (although maybe not today) | 17:22 |
| jml | bigjools: http://paste.ubuntu.com/503374/ has all of the other stuff that I still had down as to-do. | 17:22 |
| bigjools | ok, I'll take a butchers | 17:22 |
| jml | not a builders | 17:22 |
| jml | English slang is very confusing. | 17:22 |
| bigjools | s/English/Cockney/ | 17:23 |
| === gary_poster is now known as gary-lunch | ||
| malaria | Hi everyone, I would like to discuss https://bugs.launchpad.net/rosetta/+bug/608631 and the attached patch | 17:25 |
| _mup_ | Bug #608631: Visual tag to represent narrow non-breaking spaces <diacritic:Invalid> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/608631> | 17:25 |
| malaria | danilos, if you are here? | 17:25 |
| danilos | malaria, hi, I've got to finish something and then I can help out... is something like 30 mins ok? | 17:26 |
| malaria | danilos: no problem, I can wait | 17:26 |
| danilos | malaria, thanks :) | 17:26 |
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| === matsubara is now known as matsubara-lunch | ||
| bigjools | g'night folks | 17:55 |
| === al-maisan is now known as almaisan-away | ||
| jml | g'night all. | 18:15 |
| === gary-lunch is now known as gary_poster | ||
| danilos | malaria, hi, sorry, it took longer than I expected | 18:25 |
| malaria | danilos: no problem, I ran some test in the mean time | 18:25 |
| danilos | malaria, basically, the main issue is that you've got to provide an executable test | 18:30 |
| malaria | danilos: There isn't already a test for other tags? (so something easy to modify) | 18:31 |
| danilos | malaria, even though the doctest you updated looks just like documentation, you can run it with "./bin/test -cvv -m lp.translations -t browser-helpers.txt" | 18:32 |
| danilos | malaria, oh, yes, there is, it's the same file you updated :) also, I am not sure of the name "[nbthin]" (actually, I am sure that we can come up with a better name :) | 18:32 |
| malaria | ok for the test | 18:33 |
| malaria | danilos: about the name, do you have a idea? | 18:33 |
| malaria | the relevant name should be [nnbsp], but it's actually too close to [nbsp] | 18:33 |
| danilos | malaria, I was going to ask you the same thing - I'd say 'thinspace' but this is a nb variant | 18:33 |
| malaria | danilos: the html 'shortcut' for the thin space is   | 18:34 |
| danilos | malaria, 'nbthinspace' is too much to type imo, so how big of an issue is typing this out? | 18:34 |
| malaria | [nbthinsp] seems too long for me too | 18:35 |
| danilos | malaria, right, and there's no &nbthinsp; character reference? | 18:35 |
| malaria | danilos: no | 18:35 |
| danilos | malaria, yeah | 18:35 |
| malaria | danilos: does [nbthin] really sounds clumsy? | 18:35 |
| danilos | malaria, it really sounds weird to me, but I guess we can also ask a few other people as well | 18:36 |
| EdwinGrubbs | abentley: Have you encountered this problem writing tests for cron scripts? The cron script creates a new entry in the ScriptActivity table, but between each test method, the sequences are reset to the original value, since it believes that it has rolled back any changes to the tables. | 18:37 |
| danilos | malaria, i.e. you can get a reviewer to think about it so it's not a blocker for going into review | 18:37 |
| malaria | danilos: of course, the best would be to have a localised version of each tag (ie [fine] in French) but it can't be done right now | 18:37 |
| abentley | EdwinGrubbs: no, I haven't noticed problems like that. | 18:38 |
| danilos | malaria, right, we'll get it sometime in the future and then the problem won't be so bad | 18:38 |
| danilos | malaria, anyway, I don't think we should spend sleepless night on this | 18:38 |
| abentley | EdwinGrubbs: I assume it hasn't actually rolled back the changes? What changes? | 18:38 |
| danilos | malaria, how familiar are you with our submission/review process? | 18:38 |
| === beuno-lunch is now known as beuno | ||
| malaria | danilos: I'm an absolute newbie :-) | 18:39 |
| danilos | malaria, heh, ok, so there's also https://dev.launchpad.net/PatchSubmission for some documentation | 18:39 |
| EdwinGrubbs | abentley: the most important change is the new row inserted into the ScriptActivity table. The next test method that runs tries to insert another row, but since the sequence has been reset, it collides with the previously added primary key. | 18:39 |
| malaria | danilos: yes, I had a look to it already | 18:39 |
| danilos | malaria, basically, you'll have to add some tests for what you are adding, sign a contributor agreement and then you are ready to go if you ask me :) | 18:40 |
| danilos | malaria, cool, do you need any help with that? | 18:40 |
| malaria | danilos: I have to look the test stuff closer | 18:40 |
| malaria | danilos: I will ask here if I need some advices | 18:41 |
| abentley | EdwinGrubbs: I actually haven't had any dealings with the ScriptActivity table. | 18:41 |
| malaria | danilos: anyway, can you have a look at this? http://malaria.perso.sfr.fr/fines/rosetta_nbthin_test.png | 18:42 |
| danilos | malaria, right, sounds good | 18:42 |
| malaria | danilos: it's from a test (patched version of course) | 18:42 |
| danilos | malaria, yep, does the +filter page fail to "escape" them? | 18:43 |
| malaria | danilos: even if those char are unlikely to be the last of a string, there seems to be a bug in this case | 18:43 |
| malaria | danilos: no, escaped tags seem to just work | 18:44 |
| danilos | malaria, hum, interesting... it would be nice to demonstrate this with a test (that fails) | 18:44 |
| malaria | danilos: ok, I will have a look | 18:45 |
| malaria | danilos: but I think this is an other issue (not a regression because of the patch I mean) and this situation should not happen in "real life" | 18:46 |
| malaria | (ie. last char is nbsp or nnbsp) | 18:47 |
| danilos | malaria, yeah, it's unrelated to this, but would still be nice to fix | 18:47 |
| malaria | danilos: ok | 18:47 |
| danilos | malaria, I don't even think it would be that unlikely (for example, with string composition, you may often want nbsp at the end of one string) | 18:47 |
| danilos | malaria, but if it's really a problem, please file a separate bug about it and don't work on it right now :) | 18:47 |
| malaria | danilos: ok :-) | 18:48 |
| danilos | malaria, (just to keep things simpler) | 18:48 |
| === matsubara-lunch is now known as matsubara | ||
| === salgado-lunch is now known as salgado | ||
| thumper | morning | 21:11 |
| sinzui | thumper, https://blueprints.edge.launchpad.net/~launchpad/+specworkload | 21:21 |
| rockstar | abentley, wanna chat? | 21:42 |
| abentley | rockstar: sure. | 21:42 |
| rockstar | abentley, I'll call you. | 21:42 |
| lifeless | jml: so did you have a review? | 21:56 |
| wallyworld | morning | 21:59 |
| jml | lifeless: yes. I did it. | 21:59 |
| jml | lifeless: waiting for your reply. | 22:00 |
| mars | morning wallyworld | 22:00 |
| jml | but I must sleep soon | 22:00 |
| wallyworld | hi mars | 22:00 |
| lifeless | jml: I can't see it on the review page... how odd | 22:03 |
| lifeless | ah now it works | 22:03 |
| rockstar | wallyworld, thumper, standup? | 22:03 |
| wallyworld | yep. then coffee :-) | 22:03 |
| jml | wallyworld: ahh, classic mistake | 22:03 |
| rockstar | wallyworld, not sure how long it takes you to get coffee, but you could gamble on when you think thumper will be here for the standup. | 22:04 |
| * thumper is here | 22:04 | |
| thumper | do it | 22:04 |
| thumper | do it now | 22:04 |
| lifeless | getFeatureFlag does not define raising as part of its contract | 22:04 |
| wallyworld | jml: well, i am the eternal optimist. i also think hally berry will return ny calls one day too :-) | 22:04 |
| jml | lifeless: so why the finally: at all? | 22:04 |
| lifeless | jml: but if it did raise the if timeout_str code path would not run | 22:04 |
| lifeless | I think you have misread the code | 22:04 |
| jml | lifeless: quite right. | 22:05 |
| jml | lifeless: so why the finally: at all? | 22:05 |
| lifeless | it restores the reentrancy check disabling feature flags setting the timeout | 22:06 |
| rockstar | wallyworld, I don't see you on skype. | 22:06 |
| wallyworld | rockstar: skype is running and i'm logged in and all that | 22:06 |
| jml | lifeless: yeah, I get that, but not why it's in a finally, if getFeatureFlag does not define raising as part of its contract | 22:07 |
| lifeless | jml: because ctrl-C | 22:07 |
| jml | lifeless: ok | 22:07 |
| lifeless | jml: etc, defensive programming | 22:07 |
| jml | lifeless: what about my other review point? | 22:08 |
| lifeless | "I'll add some more to the prose to point folk at feature flags info. | 22:08 |
| lifeless | " | 22:08 |
| jml | lifeless: ta | 22:08 |
| lifeless | specifically | 22:09 |
| lifeless | -periods. | 22:09 |
| lifeless | +periods. For more information on feature flags see lp.esrvices.features. | 22:09 |
| jml | fix the typo & you're laughing | 22:09 |
| lifeless | that was a test ;P | 22:09 |
| jml | I am going to sleep, perchance to watch several episodes of The Wire | 22:10 |
| lifeless | enjoy, please vote on the form on your way through. | 22:10 |
| jml | already done | 22:10 |
| sinzui | gary_poster, ping | 22:11 |
| gary_poster | sinzui: five min | 22:11 |
| lifeless | jml: thank you! | 22:12 |
| mars | how long does it take for a dput package to show up in the team PPA? | 22:14 |
| mwhudson | mars: depends on the ppa build queue | 22:17 |
| mars | mwhudson, any place I can look? LP ate my upload yesterday - I would like to know if it even got through :( | 22:18 |
| mwhudson | mars: oh, a day or so is way longer than it should be | 22:19 |
| mars | hehe | 22:19 |
| mwhudson | mars: did you get an 'accepted' mail? | 22:19 |
| mars | I just uploaded it now. An no, I did not get any mail | 22:19 |
| mwhudson | you should get that within 5 minutes | 22:19 |
| gary_poster | sinzui: pong | 22:19 |
| mwhudson | it's possible that if you didn't sign it with a key registered on lp that it will just get eaten | 22:20 |
| sinzui | gary_poster, my name is now in the emails associated with lazr.restful does not compile on python 2.5 failures | 22:20 |
| mars | mwhudson, even if dput says "Good signature" everywhere? | 22:21 |
| sinzui | gary_poster, what is the plan to deal with this...I do not think I can fix this build | 22:21 |
| mwhudson | mars: possibly, i mean dput doesn't know which keys are registered in lp | 22:21 |
| mwhudson | mars: have you successfully uploaded to the ppa before? | 22:21 |
| mars | nope | 22:21 |
| mwhudson | any ppa? | 22:21 |
| mars | nope | 22:21 |
| mwhudson | have you signed the code of conduct? | 22:22 |
| mars | had to learn so time, didn't I? :) | 22:22 |
| mars | ah, nope | 22:22 |
| mwhudson | well do that then :) | 22:22 |
| mwhudson | though i thought that resulted in emailed rejections | 22:23 |
| mwhudson | mars: have you seen https://dev.launchpad.net/LaunchpadPpa by the by? | 22:23 |
| bdmurray | I am adding a checking to a view to see if the referer is localhost to help a test pass and that feels hackish to me. Is it? | 22:24 |
| mars | yes, those were the directions I was following | 22:24 |
| mwhudson | ok cool | 22:24 |
| mars | bdmurray, are you checking for the existance of a referrer? 'localhost' exists for every test run, so is it possible for the test to fail? | 22:25 |
| bdmurray | mars: https://pastebin.canonical.com/37968/ | 22:27 |
| gary_poster | sinzui, the general pain is supposed to end next week, with lucid all around. For this particular problem, you should ignore it, though I will pursue some questions on my side as to whether I will ignore it. | 22:28 |
| sinzui | thanks | 22:28 |
| thumper | abentley: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/libsoup2.4/lucid | 22:32 |
| mars | bdmurray, what happens with your patch if the referrer is None? | 22:32 |
| thumper | abentley: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick | 22:32 |
| mars | bdmurray, it looks like it will take the first conditional branch. The old behaviour had it taking the second. | 22:32 |
| bdmurray | mars: okay, if I get that squared away though does checking for localhost seem reasonable? | 22:33 |
| mars | bdmurray, if the XXX comment says "We need to do this because [foo] is different when running the test suite", then it sounds ok. | 22:34 |
| abentley | thumper: hitchhiker lp:~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick mirror . local | 22:34 |
| mars | bdmurray, is this a problem where the test harness returns a different value than production? | 22:34 |
| bdmurray | mars: as I understand it yes and ReturnToReferrerMixin helps with this but because BugTaskView does some rendering of its own using that mixin wasn't working | 22:38 |
| mars | bdmurray, well, I'm out of my depth here then :) | 22:41 |
| mars | sorry I can't help more | 22:43 |
| mars | mwhudson, you were right about the mails. Turns out the rejection mail was sent to only the last address on my key | 22:43 |
| === matsubara is now known as matsubara-afk | ||
| === salgado is now known as salgado-afk | ||
| mwhudson | mars: huh, that sounds a bit odd, but ok | 22:48 |
| mars | well, I have three addresses on my key. The rejection mail was only sent to one of them. | 22:48 |
| mwhudson | still seems strange, surely it should be sent to your preferred email address? | 22:48 |
| mwhudson | or at least the one in the changes file | 22:48 |
| mars | it went to my preferred address. The one in the changes file didn't get it, and the other one in the "Change" record didn't get it either | 22:49 |
| mwhudson | ah | 22:49 |
| mars | well, it is fixed now, and building | 22:50 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| mars | mwhudson, still around? | 23:43 |
| mwhudson | mars: it's 11:45 am, so it would be a bit early for me to bunk off :-) | 23:43 |
| mars | heh | 23:44 |
| mwhudson | although i suppose i'll be off for lunch soonish | 23:44 |
| mwhudson | mars: how can i help? | 23:44 |
| mars | mwhudson, would you happen to know the dpkg or apt invocation that would take an on-disk .deb(s) and place it in the system cache? | 23:45 |
| mars | I want to test the launchpad-dependencies package I just built | 23:45 |
| mwhudson | mars: no, why not run dpkg -i $deb | 23:45 |
| mwhudson | ? | 23:45 |
| mars | hmm. That did not work because the new version forces a downgrade of python-psycopg2, which dpkg won't do becauase it is "not on the system" | 23:46 |
| mwhudson | ah ok | 23:46 |
| mars | however, if I use apt-get to download the downgraded package | 23:46 |
| mars | then it would be there for dpkg to use | 23:46 |
| lifeless | losa ping; whats the eta for having all db servers on lucid ? | 23:46 |
| mwhudson | mars: "apt-cache add" maybe? | 23:46 |
| mars | the "debugging only" warning is a bit unsettling | 23:47 |
| wallyworld | thumper: ping? | 23:48 |
| thumper | wallyworld: hey | 23:48 |
| wallyworld | i figured out the windmill stuff myself, but there's a bug in the windmill code.... | 23:48 |
| mwhudson | mars: asking wgrant or some distro person is probably a better idea than asking me :-) | 23:48 |
| wallyworld | it is fixed in trunk but the only download package is still 1.3 beta2 | 23:48 |
| mars | mwhudson, I will, thank you for the help though | 23:48 |
| wallyworld | so what's the go here? | 23:49 |
| mars | wallyworld, if you want to upgrade it, huge +1 from me | 23:49 |
| mbarnett | lifeless: hmm, that is an interesting question. I am not sure. I belive that the process is starting tonight, but I have not been working on the lucid upgrades, so I am not sure what the overall schedule is right now. | 23:49 |
| mars | wallyworld, in fact, the Windmill maintainers explicitly requested that we do so | 23:49 |
| mars | for testing | 23:49 |
| wallyworld | ok. i would have to produce the source egg from trunk directly since the lasted packaged version is from 2009 | 23:49 |
| mars | they said 1.4 is entirely backwards compatible | 23:49 |
| mars | oh, that.... | 23:50 |
| lifeless | mbarnett: we have a buildbot failure due to python2.6, and I'm skeptical we'll be fully on lucid/python2.6 tomorrow; thats why i'm enquiring. | 23:50 |
| wallyworld | wonder why they are so slack with packaging a new version ? | 23:50 |
| mars | ... uhm, /that's/ why I haven't done it yet | 23:50 |
| wallyworld | s/version/release | 23:50 |
| mars | wallyworld, they may have just missed it. If you jump onto #windmill and ask, they will help | 23:51 |
| mars | wallyworld, our sdist of windmill is... odd | 23:51 |
| mars | I couldn't recreate a clean build when I last tried it | 23:51 |
| wallyworld | mars. will do thanks. i basically need to pull their trunk and package something newer than the 1.3b2 release we currently use in lp | 23:52 |
| mars | however, if I tried it again, I would just try tossing the stock 1.4 sdist into the tree and give it a go | 23:52 |
| mars | wallyworld, go for 1.4.0 then. | 23:52 |
| wallyworld | mars: will do | 23:53 |
| maxb | jelmer: Do you think it is practical to make a bzr-svn release happen and get it into Launchpad 10.10? | 23:54 |
| maxb | It would be good to get the KDE branch fixes | 23:54 |
| poolie | hi there | 23:55 |
| jelmer | hi maxb, poolie | 23:56 |
| jelmer | maxb: We're already past FinalFreeze, I don't think these bugs qualify as release critical. | 23:57 |
| maxb | jelmer: Launchpad 10.10, not Ubuntu 10.10 :-) | 23:57 |
| jelmer | maxb: ahh, sorry | 23:57 |
| jelmer | maxb: Yes, that would definitely be possible. | 23:58 |
| maxb | It's not essential - the project-neon folks won't mind if it slips, since my desktop is currently importing kdebase and kdesupport for them hourly :-) | 23:58 |
| poolie | thumper, no lp committers have read <https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877> yet | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
