[00:00] ajmitch, those are bzr-ish errors, unlikely to be caused by a proxy [00:01] jml: well [00:01] What are the programming languages used in Launchpad? [00:01] lifeless, NoSuchRevision caused by a proxy? [00:01] jml: if pack-names gets cached in violation of our request it would cause that symptom [00:02] right, and I'd not really paid attention to the bzr+ssh:// part of that [00:02] neither had I:P [00:02] bzr+ssh definitely isn't a proxy [00:02] firefly2442, Python. Python. Python. :) [00:02] ajmitch: where are you seeing those errors? [00:02] i get this http://paste.ubuntu.com/223935/ when running make schema [00:02] thanks [00:03] lifeless: on checking various branches in lp-sourcedeps, when running rocketfuel-get [00:03] firefly2442, but you can get the code & look for yourself. :) [00:03] so [00:03] how can we get the ohloh guys to upgrade their version of Bazaar? [00:03] I'm just rerunning it at the moment after killing off the dulwich branch [00:04] etank: there's an instruction in that error message [00:04] Ah, you got /p/launchpad. Good. [00:04] jml: don't you have friends at sourceforge now? [00:04] wgrant, but we didn't get the name 'Launchpad'! [00:05] mwhudson, hmm. there's a thought. [00:06] jml: send in the hordes of rabid lawyers? [00:07] ajmitch: its an error, or something logged in .bzr.log? [00:07] * jml looks again at his beautiful diagram [00:08] lifeless: an error with a traceback, just waiting on it to reproduce [00:08] hey, it would be really nice if an error halfway through make didn't totally screw your working tree [00:09] I've found it in .bzr.log if you want it on pastebin [00:09] sure [00:09] mwhudson: i did that and got 'link-external-sourcecode: error: Parent branch not specified, and could not be discovered.' [00:10] http://paste.ubuntu.com/223939/ [00:10] etank: did you run rocketfuel-setup to start with? [00:10] mwhudson: yeah. [00:10] at least dulwich branched without errors after a careful rm -rf :) [00:10] it took quite a few hours to finish [00:10] though i have to admit, i can't get make to work either right now.... [00:11] etank: what's in sourcecode in your branch? [00:11] jml: call? [00:11] ajmitch: file a bug please [00:11] thumper, sure. fire away. [00:11] ajmitch: it looks like that branch hasn't been upgraded and the converter is running into trouble [00:11] ok [00:11] lifeless: So it was trying to convert to 2a? [00:12] on the fly yes [00:12] _fetch_batch [00:12] is part of IDS [00:13] That would be because rocketfuel-get was broken earlier, and was creating 2a repos before pulling sourcedeps. [00:13] Now it just checks them out, so no conversion is required. [00:13] thumper, try again please. [00:13] ooh [00:13] mwhudson: just whatever rocketfuel-setup put there [00:14] wgrant: regardless, it should have succeeded [00:14] etank: can you run python2.4 bootstrap.py --ez_setup-source=ez_setup.py --download-base=download-cache/dist --eggs=eggs [00:14] etank: and see what that says? [00:17] * gmb calls it a night. T'morrow, folks. [00:17] lifeless: what else do you need on https://bugs.edge.launchpad.net/bzr/+bug/402778 ? [00:17] Malone bug 402778 in bzr "NoSuchRevision error when branching with rocketfuel-get" [Undecided,New] [00:18] mwhudson: it said nothing [00:19] etank: and does plain 'make' work now? [00:20] will it ever become possible for community contributors to earn commit rights? [00:20] gmb, g'night. [00:21] nellery: good question! probably [00:21] nellery: though with a DVCS it's not that much of an issue [00:22] nellery: given that you can commit & push branches already & most likely propose them for review & merging, I'd say yes [00:23] nellery: in the sense of committing directly to trunk? no - noone has that right even @ canonical - commits are done by a daemon that runs the test suite [00:24] nellery: in the sense of being able to submit something to land; as mwhudson says, probably :) [00:24] there's info on the wiki about the steps to take for that [00:32] * jml grumbles, the point of commit messages is to communicate [00:34] Is there some kind of Launchpad Roadmap available? I was looking for the wiki integration, but all I found is this blueprint (https://blueprints.edge.launchpad.net/launchpad-registry/+spec/launchpad-wiki). It seems everything it links to has been removed from launchpad. I was just curious if there already is a decision on this topic. [00:35] jml: rather than defeating obscure regular expressions? [00:35] MarkusT1: there's https://dev.launchpad.net/VersionThreeDotO [00:35] mwhudson, wgrant: what exactly was the rocketfuel problem? [00:35] kfogel: i don't know exactly [00:35] kfogel: Which one? The 2a upgrade one that I referred to? [00:36] wgrant: "which one"... not reassuring words :-). Yes, I meant the 2a one I saw in backscroll. [00:36] mwhudson: It seems it's quite empty. So I guess: no decision made on that issue. [00:36] mwhudson: obscure regular expressions are cause & effect by an obscure joke by obscure losas [00:36] kfogel: the sourccode branches aren't in 2a [00:36] kfogel: and for at least one of them converting on the fly errors [00:36] MarkusT1: which issue, sorry? [00:37] kfogel: bug 402778 [00:37] Malone bug 402778 in bzr "NoSuchRevision error when branching with rocketfuel-get" [Undecided,New] https://launchpad.net/bugs/402778 [00:37] jml: is this in reference to knowing what pqm is apparantly listening to? [00:37] mwhudsono: The question whether launchpad.net get's a wiki or not. :-) [00:37] kfogel: rocketfuel-get had a brand new bug which treated all of the source dependencies as if they were SSO and ShipIt. So, to save time, it first branched devel into the target directory, then pulled the dep. This caused the deps to get on-the-fly conversions to 2a. [00:37] Which is slow and crashy. [00:37] lifeless, wgrant: thank you, got it. [00:38] ajmitch, in particular, it's in reference to the heinous practice of saying rs=me or release-critical=me [00:38] * thumper is trying to avoid the firehose that is #launchpad-dev :) [00:38] MarkusT1: launchpad.net will get a wiki [00:38] thumper: it's only a few people here causing the trouble :) [00:39] at least we're past the first hump === Ursinha is now known as Ursinha-bbl [00:39] yes, less spraying around now than before [00:39] I meant downloads actually ;P [00:40] kfogel: should standup minutes go to the launchpad-dev mailing list now? [00:40] I keep getting intermittent connection resets when talking to launchpad.dev, and the local XML-RPC server seems to do it consistently when I attempt to resolve lp://dev/ URLs. [00:40] thumper: Great news! Is there any announcement on that? (Besides you telling me now :->) [00:40] MarkusT1: there is much work to do for it [00:40] MarkusT1: it is in the planning phase post 3.0 [00:41] thumper: "XXX on leave for next week" probably shouldn't go to a public list [00:41] MarkusT1: we know what we want to offer, and no-one has done it yet [00:41] mwhudson: good point [00:41] thumper: I think so. If there's any company confidential stuff, it can go internal of course. [00:41] MarkusT1, https://bugs.edge.launchpad.net/launchpad-project?orderby=-users_affected_count [00:41] * thumper looks at his notes again [00:41] MarkusT1, it's the single most popular bug on the entire Launchpad project :) [00:42] thumper: that is, the confidential stuff can be separated out and go internal. But I think our standup notes should be like bzr's, which are sent publicly AFAIR. [00:42] jml: no, that's "cheddar" [00:42] kfogel: ok, will do [00:42] kfogel, *blink* [00:43] pkern: Have you succeeded in running publish-distro yet? [00:44] As long as it's on the agenda I'm allright. You guys proved very well how you're able to handle this project. I found the bug report before, I just could not find any official comment on it. Thanks for sharing. This is getting better and better :-) [00:45] I presume it's just a matter of populating distroseries.lucilleconfig and the librarian properly, then running it in full careful mode. [00:46] * thumper updates his trunks [00:47] hmm, what's the chance I actually write any code before lunch... [00:47] https://www.ohloh.net/topics/3685?page=1#post_11061 [00:47] depends how strong your "ignore stuff" field is [00:47] * mwhudson is coding [00:47] (and gabbing while acceptance tests run...) [00:48] I wonder how uploadpolicy is wired into the system, because that might screw with my tries to add a distroseries for Debian. [00:49] I might just manually process a PPA upload a publish PPAs for now. [00:49] jml: yayness [00:49] Since the librarian is decidedly file-less, and I can't be bothered working out how to get gina to work. [00:54] wgrant, spiv has commented more than once in my hearing that the librarian is an ideal candidate for spinning off into a standalone app, fwiw [00:58] thumper: barry points out that standup notes can contain vacation times and other personal stuff, and that therefore they shouldn't be public [00:58] thumper: I think we're going to need to think about this more carefully; I will ponder and post a proposal, but for now do it internally I guess. I think really we're going to have to have two versions: one with internal stuff and another with public dev stuff. [00:59] kfogel: I checked my standup notes for personal details [00:59] kfogel: I agree we should be careful with what we put in public notes [00:59] mwhudson: no make does not run [00:59] i get the same error [01:00] etank: i can only suggest running the commands make is running one by one (without the ssh.py bit) and seeing what is breaking [01:00] thumper: but we will need a system that is documented and can be routinized. We don't want team leads having to improvise this every time. [01:02] kfogel: right === matsubara is now known as matsubara-dinner [01:13] What happens with mail in devmode? I expected it to go to /var/tmp/launchpad_mailqueue, but it instead seems to be sent to root. [01:15] well yes, it gets sent to root [01:15] i once found the code that did that, i can't remember where it is though [01:26] ping [01:26] oh wow [01:26] from lp.registry.model.person import *\nAttributeError: \'module\' object has no attribute \'generate_nick\'\n' [01:26] not managed that one before [01:26] (it's a circular import, of course) [01:27] Did anyone try/manage to install launchpad on Debian (lenny)? [01:29] hmm. I seem to be getting conflicts every time I pull. :\ [01:31] I guess that's because a directory change is moving through the trunk branches. [01:35] bz_g, I don't think anyone's tried yet, that I know of. [01:37] it would be nice if different pyflakes warnings came out as different colours in flymake [01:37] that sounds kind of hard to achieve though [01:38] mwhudson, interesting notion. [01:38] mwhudson, have you got pep8.py hooked up to flymake as well? [01:38] jml: no [01:39] mwhudson, I do, and I'm quite liking it, but I do wish the warnings were differently coloured. [01:40] jml: time to read flymake.el a bit i guess! [01:40] mwhudson, good luck. [01:40] Here is your elisp trowel. Use it wisely. [01:41] it has different faces for errors and warnings at leas [01:41] t [01:42] mwhudson, pyflakes doesn't really distinguish between the two though [01:42] right [01:42] * jml sometimes wonders if it should have some more reporting options. [01:42] i guess it's a regexp somewhere in flymake to try to tell the difference [01:43] \o/ [01:43] heh [01:43] it's a warning if the string "warning" appears in the output i think [01:44] and an error otherwise? [01:44] ah, mildly more complex than that [01:44] jml: yeah === matsubara-dinner is now known as matsubara [01:52] Hmmmmm. The Soyuz karmaactions are in sampledata/current.sql, but not sampledata/current-dev.sql, so they were missing from my DB. Why would that be? [01:52] mwhudson: you mean flymake is two-faced? :) [01:52] spiv: zing! [01:53] jml: thanks. Maybe I'll give a go... [01:53] wgrant: the sampledata used for tests is not the sampledata that you get when you run make run and poke around [01:53] wgrant: i don't know which is which any more :) [01:53] we want to reduce the sampledata used for tests [01:54] The missing karmaaction was crashing things :( [01:54] Yay, a successfully populated and published PPA. [01:55] * mwhudson goes for lunch [01:59] I tried really hard to find the right documentation, but I still have a question left :-) : How do I actually delete projects and users in lp as the foo.bar admin user? I'm able to set projects inactive, but I can't find the "delete" button? :-/ [01:59] MarkusT1: Projects are only ever deactivated. [02:00] They can't be deleted. [02:00] Same with people. [02:00] wgrant: Ah thanks. So at least I can stop searching :-) [02:01] congratz to launchpad-dev team \o/ . [02:02] lajjr, thanks :) [02:05] your welcome great source release. I can't wait to look at the code. [02:06] * Snova_ would, but 280 MB is huge for this time of day [02:08] I download the tar.gz file and it is done, but the ./rocketfuel-setup started 10 mins ago. [02:09] I think that might be awhile yet :P [02:09] lajjr: Did you prepopulate the repository with the tar.gz's contents? [02:09] yep.. [02:09] (also, rocketfuel-setup calls rocketfuel-get, which downloads lots more) [02:09] it will work right?? [02:10] What is rocketfuel-setup saying it's doing? [02:10] downloading the deps apache etc. [02:12] fresh install on a new laptop Jaunty 9.04. [02:14] You can use the following commands to manage your Launchpad [02:14] development environment: [02:14] rocketfuel-get [02:14] Update your copy of devel and the necessary source [02:14] dependencies, and make sure all source dependencies are properly [02:14] linked in to all the branches you are working on. [02:14] rocketfuel-branch foo [02:14] Create a new branch of LP called "foo" in [02:14] /home/lajjr/launchpad/lp-branches/foo, [02:14] with all the source dependencies properly linked in. [02:14] rocketfuel-status [02:14] wow I guess it's done. [02:15] ooi, is there a summary of what couples Launchpad to a specific python version so much more so than other python code? [02:15] yep it just ran a list with that at the top.. [02:16] rocketfuel etc etc rocketfuel status etc. === Ursinha-bbl is now known as Ursinha [02:16] lajjr: That doesn't tell you much. What does ~/launchpad/lp-branches/devel/sourcecode have in it? [02:21] thumper, mwhudson, rockstar: there are still a few untested test plan items [02:21] * thumper looks [02:22] ok hold on. [02:22] maxb: zope [02:24] lp-branches lp-sourcedeps [02:24] nd the script rocketfuel-setup [02:25] s/nd/and [02:25] maxb, we're very close to being able to switch to a more modern python. [02:26] and we can't wait [02:26] which will be great for those of us who use karmic. [02:26] thumper, indeed :) [02:28] jml: given the sort of people who are probably likely to grab a copy of the launchpad source, running on karmic may be a good thing :) [02:29] ajmitch, yeah [02:29] ajmitch, I'm running in a hardy chroot atm, which is working out ok [02:29] it'd save me trying to dig around in makefiles to get simple things like bin/py [02:29] ajmitch, but I have a screwed up postgres config which is causing difficulties. [02:30] I should probably setup something in kvm anyway [02:32] one consideration is that we deploy on LTS [02:32] spm: is there going to be a staging update before rollout? [02:32] so we need to keep working there regardless of the current ubuntu development status [02:33] maxb: i bet most blobs of python code as large as launchpad end up fairly tied to a specific python version [02:34] jml: looking [02:34] mwhudson, thanks. [02:34] it takes more work than one might think to support more than one python version reliably. [02:35] guh. [02:35] it's like 0.0001 units of aggravation per line of code or something [02:35] so distracted that I have a half written item in my todo list :\ [02:35] mwhudson, what is the SI unit for aggravation anyway? [02:36] jml: i don't know, i'm sure we can come up with something suitably offensive [02:36] jml: the BSOD ? [02:36] jml: "the openoffice" ? [02:36] hahaha [02:36] jml: I dunno, we do 2.4/2.5/2.6 quite easily in bzr [02:37] jml: the clippy [02:37] lifeless, I think that's the imperial unit. [02:37] * mwhudson plays the "is my code on staging yet" game [02:37] lifeless: have you seen http://www.ntk.net/doh/options.html ? [02:37] lifeless, I bet you had to change code to support 2.5 and 2.6. [02:38] jml: yes, but it was pretty painless, and we don't routinely have trouble with new code [02:38] mwhudson: classic, and no, I hadn't [02:39] lifeless: one of the funniest things on the internet i think :) [02:39] Annoy me with that sodding paperclib: [02:39] ( ) all the time [02:39] (*) when i least expect it [02:43] thumper: staging restore: Wed Jul 22 02:17:56 BST 2009 Lock file deleted. Script finished [02:44] spm: when was that? [02:45] like half an hour ago? [02:45] yup [02:45] spm: but staging is revno 8298, and I need 8301 :( [02:46] spm: why did staging come up with old code? [02:46] erm [02:46] thumper: mainly as the actual code side happened about 12 hoursish ago [02:46] is stable still being merged into db-devel [02:46] ? [02:47] :( [02:47] mwhudson: it should be [02:47] 1 failure on db_lp builder [02:47] :( [02:47] thumper: I lie. code was updated ~ Tue Jul 21 21:27:44 BST 2009 [02:48] WTF? [02:48] why is the doc test printing out javascript code??!?! [02:49] lol [02:49] i need to test the revision _after_ what is running on both staging and edge [02:49] damn sprite! [02:50] beuno: was that you? [02:50] mwhudson, my script says there's 1 revision in devel not in stable, and 4 in db-devel that aren't in db-stable [02:50] mwhudson, but that stable & db-devel are up to dae [02:50] jml: cool, i was confused for a few minutes, but i've got it figured out now, i think [02:51] kernel update caused a reboot. lol [02:55] * jml has a buildout moment [02:56] jml: i made a branch earlier, buildout broke and the easiest thing to do seemed to be to throw away the branch and start again === matsubara is now known as matsubara-afk [02:59] :\ [02:59] mwhudson, sometime after the release, we need to make sure that sourcecode/bzr never ever gets created an automated process [03:00] mwhudson, there's a great well of hidden errors just waiting to bite us there. [03:00] jml: maybe there should be an engineer devoted to working on these things for an entire cycle! [03:01] jml: we need to be careful we never import the system bzr somehow too [03:01] (god knows how) [03:01] mwhudson, hmm. [03:02] mwhudson, we could make all of launchpad a bzr plugin & use bzr's api thing [03:02] jml: i admit that wasn't a suggestion i was expecting! [03:02] mwhudson, :) [03:04] I likes it [03:10] * mwhudson finds canonical.launchpad.scripts.logger.BufferLogger, finds it to be a piece of crap [03:11] :) [03:14] beuno: so what happened with your laptop yesterday? Did you ever get it working again? [03:20] sinzui: I changed bug #386797 to invalid; hope that was okay. [03:20] Malone bug 386797 in launchpad-foundations "Enable distributed content development" [Undecided,Invalid] https://launchpad.net/bugs/386797 [03:21] kfogel: not at all [03:23] sinzui: not okay? [03:23] :-) [03:23] sinzui: "not at all" is ambiguous in this context, but I assume you meant "no problem at all" [03:24] kfogel: it is okay. Francis would ignore it for a few years. I even suggested that he spend a day Triaging bugs because he could close 50 of them [03:24] * jml instruments [03:24] closing 50 bugs would be nice [03:25] Since foundations was the old Launchpad, Francis could easily transfer 50 bugs to each our our porjects [03:25] that would be less nice [03:25] sinzui: I've been a bit hands off about triaging bugs, not knowing if I should be making decisions like that. Should I be a bit more aggressive and assume that mistakes can be corrected? [03:26] We should be honest [03:26] If we really don't intend to do it, close it [03:26] jml: how about: BranchCollection.getTeamsWithBranches(person): [03:26] """Return the Teams that person is a member of that have branches.""" [03:26] sinzui: agreed. It's not like the record of the conversation is lost if we close it anyway. [03:27] Every bug in blueprint, launchpad-answers, and launchpad-registry really should be fixed or implemented. I wish that was true of foundations [03:27] kfogel: right. The cost of a mistake there is pretty low. The worst is probably offending the reporter, which is a pretty bad thing to do, but ignoring their report is probably just as bad... [03:27] thumper, what's the question exactly? [03:27] jml: comments on a BranchCollection method to return a result set of People [03:27] thumper, ahh ok. [03:28] jml: good or not? [03:28] jml: it'd use the _getBranchIdQuery [03:28] thumper, my spider sense is tingling [03:28] thumper, why do you want it? [03:28] jml: mostly, but tweak for owner [03:28] jml: we need to be able to get the teams that have branches in a given collection for a person quickly [03:28] jml: one query rather than one query per team [03:29] jml: beuno is in 86 teams, and the query is taking 150ms ish [03:29] thumper, is this to generate links from the Person branch listing? [03:29] jml: yes [03:30] thumper, I feel that it's something of a violation of the spirit of the interface, but I don't have any better ideas right now. [03:30] jml: we already have branch collection returning branches and merge proposals [03:30] jml: we could add a new utility somewhere [03:30] jml: not sure what to call it though [03:31] thumper, returning branches is its raison d'etre, and merge proposals are a pretty natural follow on. [03:31] jml: yeah, I know [03:32] jml: but not sure how to get at the collection internals without it being a method on the collection itself [03:32] thumper, yeah. me neither. [03:32] thumper, I think just put it in there for now, making a comment about how it doesn't quite fit. [03:32] jml: ok [03:33] * jml idly wonders why 'reason for being' lacks punch in English. [03:34] jml: "to be or not to be"? [03:37] spiv: that isn't punchy either [03:43] instrumenting code :( [03:46] mwhudson, I wonder. [03:47] mwhudson, how would monkey patching and lazr imports interact, do you think? [03:47] jml: lazy imports? [03:47] mwhudson, yes. [03:47] sorry. [03:47] jml: i guess it could get exciting [03:47] jml: does ScopeReplacer implement __setattr__ ? [03:48] jml: i think i guess where you're coming from [03:48] lazr imports? [03:48] thumper, lazy. [03:48] jml: lp-serve not logging oops? [03:48] jml: sorry, read that just after hitting enter [03:48] mwhudson, I can't hide anything from you, can I? :) [03:49] jml: lazy imports --- day before release --- monkey patching --- talking about test plans earlier [03:49] jml: it wasn't _that_ hard :) [03:50] oh and this brain wave sensor [03:50] * jml throws away his aluminium foil hat [03:50] I knew it. It *has* to be tin. This one's no good. [03:50] jml: go get your cowboy hat :) [03:55] mwhudson, I now have solid evidence that the monkeypatched version is not being called. [03:55] mwhudson, what is this ScopeReplacer of which you speak? [03:55] jml: it's an implementation detail of lazy imports [03:55] bzrlib.lazy_import [03:56] oh. bzr-grep usage fail [03:57] mwhudson, it looks like it implements __setattr__ beautifully. [03:58] jml: new theory required then [03:58] dammit. going to have to do this the Right Way. [03:58] damn storm compilation problems [03:58] * thumper smacks head on thetable [03:59] mwhudson, I think I have a new theory. [03:59] jml: does something somewhere do "from bzrlib.trace import log_exception_quietly" ? [03:59] mwhudson, bzrlib.smart.protocol imports 'log_exception_quietly' directly from bzrlib.trace before it gets patched [03:59] jml: arghlbargl [03:59] mwhudson, ... [04:00] mwhudson, so I can shuffle around some code, probably. [04:01] statement: SELECT Branch.id, Branch.unique_name FROM Branch WHERE false AND Branch.private = false [04:01] mwhudson, or I can abandon this approach and do it the right way by giving bzr the appropriate hooks. [04:01] that's not a very useful query [04:01] no, 'tisn't. [04:01] i wonder why storm is generating it [04:01] jml: i think the time may have come for the right way [04:02] oh ffs [04:02] mwhudson, ok. I'll file bugs appropriately and prepare a patch for bzr [04:03] jml: cool [04:03] mwhudson, the code I've already written in Launchpad was deliberately designed to be easy to switch to hooks [04:03] so I should only have to change one or two functions & probably none of the tests. [04:04] jml: yay [04:04] * jml -> lunch etc. [04:32] http://pastebin.ubuntu.com/224061/ :( [04:38] mwhudson: eh? [04:38] thumper: circular import [04:38] mwhudson: I think I know why [04:38] yeah [04:38] mwhudson: you need to import canonical.launchpad.database first [04:38] import * is evil [04:38] it blows [04:39] that it is [04:39] bug 402845 [04:39] Malone bug 402845 in launchpad-registry "./bin/py -c 'from lp.registry.model import person' fails due to circular import" [Undecided,Triaged] https://launchpad.net/bugs/402845 [04:39] thumper: removing import *s from canonical.launchpad.database will help i think [04:39] mwhudson: yeah, but likely to be a world of hurt [04:39] mwhudson: it was a PITA when I did the code ones [04:39] mwhudson: all the page tests :( [04:40] thumper: maybe only a continent of hurt [04:40] mwhudson: an Australia of hurt [04:44] thumper: want to review https://code.edge.launchpad.net/~mwhudson/launchpad/much-faster-rewrite-map/+merge/9121 ? [04:44] lifeless: you might be interested too [04:44] * thumper looks [04:45] awaiting diff [04:45] mwhudson: not really, unless its different than we discussed [04:45] mwhudson: does it nuke the cache? [04:45] fair enough [04:45] lifeless: what do you mean? [04:45] it still caches [04:46] how fast is a miss now? [04:46] but cache misses are done via 1 direct query [04:46] lifeless: < 1 ms i hope [04:46] thats pretty good [04:46] I'd really like to nuke the cache [04:46]