[00:18] lifeless: https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-migration-script/+merge/93883 <- I think that could/should be done as an API script, what's your opinion? [00:19] poolie: Do you want to redo https://code.launchpad.net/~mbp/launchpad/remove-bsondump2/+merge/93778 with a proper whoami? [00:19] You seem to have been setuplxc'd. [00:19] * StevenK prods wgrant to fix the topic [00:19] I'm bac, what are you talking about. [00:19] Haha === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wgrant | Firefighting: - | Critical bugtasks: 4*10^2 [00:33] wgrant, ok [00:34] that was icky [00:34] i'm glad i caught it [00:34] these scripts that do lots of random modifications to your host machine :( [00:34] You mean a lot like rf-setup? [00:35] yeah, but lxc ought to be a chance to get away from that [00:35] perhaps i should run setuplxc inside a vm :/ [00:48] wallyworld_: oi, can I please have a link on the team code home page for the +recipes please [00:48] wallyworld_: I'll buy you a drink [00:48] wallyworld_: maybe a backrub? [00:48] thumper: oooh, now you're talking [00:49] * StevenK reviews his breakfast [00:49] TypeError: ('Incompatible metatypes', (, )) [00:49] * StevenK stabs Zope [01:26] StevenK or wgrant: do either of you know what is causing W: GPG error: http://archive.canonical.com precise Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key [01:27] thumper: intercepting proxy cache [01:28] Or scandium being terrible again. [01:28] But I think that's mostly fixed, so probably your ISP is shite. [01:28] in NZ proxy caches you. [01:33] thumper: it can also be the file in /var/lib/apt/lists being corrupt [01:39] lifeless: I'd like to remove feature rules for these removed flags: https://pastebin.canonical.com/60613/ [01:39] lifeless: And add this rule for my heat changes (not yet deployed): https://pastebin.canonical.com/60614/ [01:40] if the code is gone, thats a no-brainer [01:40] The code is indeed gone. [01:40] And it is a no-brainer, but I still need a +1 :) [01:40] +1 on them both [01:40] Thanks. [01:43] Totally not cool, fglrx. [01:43] Ooh [01:43] New apport in precise, though. [01:44] does this mean LP won't have 9 bazillion bugs filed daily... [01:45] Ah, no, still uploads to LP [01:57] lifeless: Bug comment searching has never been enabled on prod AFAICT. Can I remove the code, since the current implementation is never going to perform even vaguely acceptably? [01:58] yes [01:58] Thanks. [01:58] or should I say 'no, I want the quota' :P [01:58] I'm removing targetnamesearch too [01:58] Heh [02:24] flacoste: I'm not sure we define 'core functionality' anywhere :) [02:54] * wgrant massacres the branchscammer [02:58] Sounds lke an apt name. [02:58] Put up a branch renaming it and it'll mark it r=me [02:58] Maybe it's choking on MySQL again. [02:59] Plausible. [03:16] StevenK: https://code.launchpad.net/~wgrant/launchpad/obliterate-targetnamesearch/+merge/93914 [03:16] * wgrant is preparing for the LOCTS [03:21] wgrant: Sorry, I was lunching. Looking now. [03:23] k [03:24] wgrant: r=me [03:25] * StevenK approves of all this code death [03:25] Thanks. [03:25] see #launchpad for some related ;P [03:25] Makes my disclosure work easier, and puts me in a good position for the LOCTS that will surely eventuate. [03:25] Haha [03:25] TS? [03:26] I've not wanted to find out how much code I've ripped out versus added. [03:27] Specifying multiple revspecs would help [03:28] lifeless: Lines of Code Trading Scheme [03:28] lifeless: Like an ETS, but for maintenance burden. [03:29] Sigh, defeated by PQM [03:29] Since it's the committer for each rev. [03:30] Because auditing is for chumps [03:30] wgrant: so, you're committed to futures [03:30] StevenK: pqm isn't the author though, which is what you care about; just uses the merged in revs. or annotate. [03:32] wgrant: you've checked prodconf for the heat config key ? [03:32] lifeless: Yup, nothing there [03:33] lifeless: How does annotate help? What I'd like is a large diff of any rev I have or someone else has landed to devel [03:33] StevenK: so, perhaps it doesn't :) but it can tell you loc last touched by you, for the current tree, which is a related q [03:34] Ohloh gives lines changed, but not +- [03:34] anyhow, use the merged in revs to determine author, and mainline diffs for the content [03:35] Perhaps I should learn bzrlib [03:35] I was hoping I could loop over bzr log [03:36] wgrant: So, given IBug's definition in configure.zcml, I don't need to split it into IBugView and IBugLimitedView, I can just move id to LimitedView ? [03:37] StevenK: Unfortunately, yes. [03:38] * StevenK reverts the split he did [03:38] If you've got a split that works, by all means do it. [03:39] I do -- but only in terms of Python. I wasn't sure how to shoehorn it into the ZCML [03:42] wgrant: Given the branch I just reviewed, can MessageChunk.fti die a horrible death? [03:42] I'd prefer not. [03:42] It's write-once so pretty cheap. [03:42] And I hope we'll do comment searching in future, even if we don't move to Solr soonish. [03:43] tsvector concat should make it pretty easy to do comment searches. [03:43] didn't you just remove comment searching? [03:43] Yes [03:44] But if we want to do a non-stupid implementation in future, it might well make use of MessageChunk.fti [03:44] Since that table is never updated it's cheap to keep. [03:46] http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui -- interesting [03:46] Yeah, saw that a couple of days ago. [03:47] Pretty interesting indeed. [03:47] But it relies on having a cascading last_updated column on pretty much everything. [03:47] Which has to increase write contention massively. [03:48] i wonder if it's in plain old sql [03:48] they are caching into memcache I believe [03:48] They cache into memcached, yes. [03:48] But IIRC it's all ActiveRecord otherwise. [03:48] so contention == redundant writes more than lock-slows [03:48] lifeless: no, no [03:48] also i guess unlike lp they have relatively few objects read by millions of people [03:48] lifeless: The whole caching scheme relies on having a last_updated field to generate the cache key from [03:49] though, would that really be more mtime fields than lp? [03:49] perhaps [03:49] There's no project mtime field. [03:49] max_heat is the closest, and I deleted that two weeks ago :) [03:49] Partly because of contention, partly because of terrible implementation. [03:50] hm [03:50] an mtime on /ubuntu would probably suck [03:50] Exactly. [03:50] but i wonder if you would really need it [03:50] wgrant: I missed that; it looked like they just update the cache on any write, recursively, on all places affected. [03:50] lifeless: They update the mtime all the way up the tree. [03:50] lifeless: Cache contents never change for a given key. [03:50] wgrant: sure, but that's just the mtime of the write [03:50] The key includes in the update time. [03:50] anyhow, so it's interesting that they have headed down the course lp was going to take ~2y ago, and that lp abandoned [03:51] wgrant: doesn't imply table storage of said value [03:51] and, the opposite of lp's handlebars approach [03:51] poolie: Did you see the HN discussion? [03:51] wgrant: or are you saying 'to find the cached entry they need a consistent mtime on all things' ? [03:51] no [03:51] poolie: It goes into stuff like this. Let me find it. [03:51] lifeless: Right. [03:52] lifeless: The invalidation mechanism is that the object's mtime changes. [03:52] So to change something 5 levels down, they need to write a new mtime on all 5 levels. [03:53] http://news.ycombinator.com/item?id=3603367 [03:53] poolie: ^^ [03:53] wgrant, so (perhaps hn answers this), i don't think you would necessarily have to have an mtime all the way up [03:53] There is a bit of an argument over whether forcing everything to be server-side like this is smart. [03:53] in the db [03:54] So, you could probably store the mtime in something more sensible. [03:54] for instance if you change a bugtask in /ubuntu, you would need to invalidate any caches of bugs/ubuntu [03:54] Right. [03:54] it seems like the important thing is to have a pubsub-ish tree of "I changed!" [03:55] And you only care about last-update-wins, so ACID is not useful. [03:56] There is a bit of an argument over whether forcing everything to be server-side like this is smart. [03:56] it's useful data that it can be made to work well [03:56] Indeed. [03:56] i guess they need the FE to be close to the users [03:56] Yep [03:56] but perhaps no more so than for a more ajaxy approach, if they are doing few requests [03:57] DHH goes into the latency aspects. [03:57] they are using ajax [03:57] according to the HN thing, 50% of their code is coffeescript, or thereabouts [03:57] Just over half-way down the HN comments. [04:00] lifeless, well i said 'more ajaxy', don't you think this is a less ajaxy approach? [04:01] if you accept a definition of ajax that the x means data comes down as xml or json [04:01] I think this is equivalently ajaxy; it does what lp does in large part (which is one of the things that is terrible about LP client side support) [04:02] we render on the server, ship html to the browser, the browser shoves it into the dom [04:03] their big claim is less client-side /stuff/ - no MVC on the client, no template rendering on the client, so less surface area of e.g. browser variation to deal with [04:04] sure [04:04] what i meant was http://news.ycombinator.com/item?id=3604732 [04:09] I don't think LP's template caching thing should be abandoned. [04:09] It was just applied in completely the wrong way. [04:09] It was used to make slow things fast. [04:10] Rather than fast things very fast. [04:10] It was used as a means to stop timeouts. [04:10] I think it still has a place in LP. [04:10] But not for any of its current uses, except the blog caching thing. [04:16] its causing plenty of complaints today :) - e.g. jono's why-is-the-list-of-projects-stale qeru from a few days back [04:17] Oh yes, as I said, the current implementation is fucking terrible. [04:20] rargh [04:20] Must smash multitask bugs [04:20] Slow branch vocab is slow [04:55] wgrant, i'm still shaving bzr yaks towards rebasing the bsondmp patch [04:56] and ubuntu bugs ftm [04:59] poolie: There's a mostly working rewrite branch that I used for that purpose last week. [05:06] translationstobranch and the gardener need a few good amputations :( [05:57] wgrant, https://code.launchpad.net/~mbp/launchpad/remove-bsondump2/+merge/93778 has the right userid now [05:57] any other comments? [05:57] "good riddance" [05:57] poolie: Can you land it yourself? [05:58] yes [05:58] Great. [06:01] * wgrant touches Storm in inappropriate places. [06:02] * StevenK attempts to resist the urge to /nick Storm [06:13] http://en.wikipedia.org/wiki/Storm_%28Marvel_Comics%29 [06:19] 33 [06:20] bah [06:33] Ah, heh [06:33] garbo runs tasks in threads, so of course the default script feature controller isn't always visible. === almaisan-away is now known as al-maisan [07:25] wgrant: I think garbo's architecture would suite switching to multiprocess now that the new stdlib library is available. [07:26] stub: Yeah, multiprocessing is pretty nice [07:26] Might look at that once we're on 2.7 [07:26] Oh, it's in 2.6 too [07:26] Oh... was thinking it was 2.6 [07:26] yer [07:26] stub: https://code.launchpad.net/~wgrant/launchpad/garbo-feature-flags/+merge/93928 is a quick fix for now [07:26] It's one line of significant change, if you want to review... [07:27] sure. not sure what it is fixing yet... [07:27] oic [07:27] Feature controllers are thread-local. [07:28] garbo calls login to set up an interaction in the fresh thread, but it also needs a feature controller now [07:29] So what is that constant for anyway? I'm not sure how we calculate bug heat any more. [07:29] (r=stub btw) [07:29] Thanks. [07:30] Bug heat no longer degrades over time, so it doesn't need to be updated weekly, just on changes to the bug. [07:30] But we change the algorithm occasionally. [07:30] So I adjusted the garbo job to read a timestamp from a feature flag -- anything older than that flag is considered invalid and gets recalculated. [07:30] So the timestamp is for the last time we changed the algorithm. I see. [07:31] I could argue that it gets hardcoded in the code somewhere rather than abusing feature flags, as it will change when the code changes. [07:31] We don't know when the code is deployed, though. [07:32] You don't need to know - pick a date a few days in the future and she'll be right. [07:32] Heh [07:32] Not quite [07:32] It will then recalculate every bug every hour until then. [07:32] Which sounds less than ideal for bloat. [07:32] But it won't, as it will take a while to recalculate. Anyway... this has already been discussed I'm sure. [07:32] An alternative is a version column, but meeeh [07:32] It won't take long. [07:33] Yeah, lifeless suggested this approach. [07:34] Looks like rather than feature flags, we need some generic shared runtime configuration. Feature flags could be built on that. Zookeeper almost meets the needs, but I'd rather not call Zookeeper from inside stored procedures. [07:35] aren't feature flags generic, shared and at runtime ? [07:36] Yes, and if you renamed them you would have an implementation :) [07:37] Like washing my dishes in a toilet. Technically, it is doable and done right no problems. But it is still called a toilet, and people still go euwww. [07:55] What are we going to do about ProductSeries.name ? It is actually a version number, and should be using the debversion type. [07:55] Quick fix and change the type with a dbpatch, or a correct fix and rename the column and change its type? [07:56] Bug #718660 [07:56] <_mup_> Bug #718660: Drop version_sort_key, changing columns to debversion type < https://launchpad.net/bugs/718660 > [07:56] I guess we can rename the column and keep 'name' around for compatibility, API clients etc. [07:57] I'm not sure the rename is valuable. [07:57] Or even correct. [08:09] Mainly thinking about maintaining API compatibility. I haven't played with it so not sure what the policies and such are. [08:16] * wgrant feels dirty, but hopes for a review of https://code.launchpad.net/~wgrant/launchpad/bulk-insert/+merge/93930 === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [08:33] stub: api compat - its fairly loosely typed [08:33] stub: that would cast into a string for instance (or at least I'd hope it does ;P) [08:36] It will be a string from Python - I don't think we have a debversion type? [08:36] We do [08:36] We use it extensively in Soyuz [08:38] But versions are normally handled as strings. [08:39] wgrant: Your bulk insert - shouldn't Storm do that optimization, using multi row insert if it has several objects of the same type to create in sequence? === mthaddon` is now known as mthaddon [08:40] stub: Yeah, but there are questions around how that works with ordering guarantees. [08:41] And I need this now, not in 6 months when the Storm devs have worked out what the guarantees are :) [08:41] Bug #411556 [08:41] <_mup_> Bug #411556: Storm should support multi-row inserts < https://launchpad.net/bugs/411556 > [08:41] Syntax also differs between DBMSes. [08:43] wgrant: I don't see what the ordering problem is. [08:44] wgrant: You have a list of things to flush. If you are about to do an INSERT, and the next item is also an INSERT of the same type, you do them together as one statement. [08:47] There are also issues around populating the primary keys. [08:47] MySQL provides no way to do it AFAICT [08:47] And I'm not sure if postgres guarantees order. [08:47] Not sure who on the team can review branches poking Storm privates anymore - allanap or bac? [08:47] (Storm relies on knowing the PK for each inserted object) [08:48] They're read-only storm privates, so they're mostly harmless :) [08:48] You would invoke the database multiinsert you are landing, or aarons executemany [08:50] stub: But the RETURNING order is undefined. [08:50] AFAICT [08:50] So we can't map them back to the objects. [08:54] Really? That seems somewhat silly :-( [08:56] Its a PostgreSQL extension, so I assume it is defined as the same order of the rows you are inserting. It isn't explicitly documented, but the extension would have been added for exactly this use case. [08:57] (Inserting a set of records, and you want to know what the DB set your NULLs to and how the triggers munged your data) [08:58] I guess. [08:59] Hello [09:03] * jelmer is still strugging with his scanner branch [09:04] jelmer: What's up? [09:04] good morning [09:06] wgrant: I'm trying to reproduce the timeout issue we've been seeing on qastaging but have failed so far [09:07] jelmer: It's not just qastaging being terrible/ [09:07] jelmer: abentley is working on a scanner DB performance branch at present. [09:07] I doubt it, we saw similar issues on production earlier (the incident) [09:07] True. [09:08] wgrant: oh, I didn't realize abentley was working on that bug now [09:08] it was assigned to Graham for a while and then unassigned I think [09:08] jelmer: He's batching the BranchRevision inserts AIUI [09:08] I should talk to Aaron and make sure our changes don't conflict too badly [09:09] stub: Also, about executemany, it seems it's implemented in psycopg2 as just a sequence of normal executes. [09:10] stub: Which seems like it would have negligible benefit. [09:10] If it isn't doing anything with prepared statements, yer [09:12] It might be using prepared statements under the hood btw. [09:12] It didn't seem to be. [09:12] * wgrant rechecks. [09:13] If it is interpolating its own variables into the query string, it isn't. [09:13] If the query string and parameters are being sent to libpq separately, it might :) [09:15] https://bazaar.launchpad.net/+branch/ubuntu/psycopg2/view/head:/psycopg/cursor_type.c#L491 [09:15] 524 looks pretty suspicious. [09:16] It parses the args into 'operation', then passes that straight into execute. [09:16] That is really ugly Python [09:16] Heh [09:20] It isn't doing interpolation there... if it is happening, it is down in _psyco_curs_execute [09:27] Might be write on multi value insert returning rows in an arbitrary order :-( [09:27] c/write/correct [09:29] stub: I didn't have any evidence either way, apart from the docs not specifying it and it seeming too good to be true. [09:43] stub: Have you already created those indices? [09:44] wgrant: No. Was waiting for the backups to complete before suggesting [09:44] Yeah [09:45] Finished early tonight. [09:45] Actually, it's been quick for the last week [09:45] Hmm [09:56] wgrant: So https://code.launchpad.net/~wgrant/launchpad/more-indices/+merge/93916 ? [09:57] stub: Yup [09:57] k. I'll apply that now. [09:59] Thanks. [10:00] hey guys, good morning from Madrid [10:01] one question about launchpadlib, how can I get the complete list of bugs for a given project? As far as I saw I have to get all the bugs and examine them one by one .. I'm pretty sure I'm missing something [10:01] lcanas: lp.projects['fooproject'].searchTasks() [10:05] wgrant, oh! great! thank you :D === al-maisan is now known as almaisan-away [11:54] morning [12:05] hey guys, why do my daily builds show up as successful, yet I get these also what is up with 'ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored.' errors? === almaisan-away is now known as al-maisan === danilo_ is now known as danilos [14:07] Morning, everyone. [14:07] hey Deryck [14:10] 'morning deryck :) [14:23] aloha [14:24] hey guys, what's with the 'You have not informed bzr of your Launchpad ID, and you must do this to...' ? [14:32] abentley, adeuring -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup [14:33] Remove the following packages: [14:33] 1) pbuilder-satisfydepends-dummy ? [14:34] ESphynx: copying and pasting the same question into multiple channels is not necesary, when someone can answer it they will. [14:35] czajkowski sorry I thought you were telling me I should ask here as well :P [14:35] ESphynx: not at the same time, pick one place perhaps :) [14:35] well it all depends whether the same people are in both places or not ;P [14:36] i'm trying to move ia32-libs ahead :| [14:41] https://launchpad.net/lpjsmin [14:44] man, someone should tel stub his part message probably needs some cleaning/fixing. [14:46] adeuring: http://pypi.python.org/pypi/modern-package-template as well, <3 [14:46] rick_h: thanks! [14:50] deryck: https://dev.launchpad.net/JavaScriptIntegrationTesting?highlight=%28yuixhr%29 looks like what you were talking about? [14:50] rick_h, indeed. Was having a hard time finding it myself. [14:50] rick_h, didn't think to try the wiki. :) [14:50] deryck: ok cool, will go from there. Thanks for the heads up. [14:51] rick_h, np. Thanks for handling it. [15:14] sinzui, can you land https://code.launchpad.net/~salgado/launchpad/bug-937310/+merge/93987 for me? [15:14] Yes I can [15:15] thanks! === al-maisan is now known as almaisan-away [15:35] launchpad doesn't use pbuilder -- meh ? [15:53] sinzui: aloha there! thanks for the mail over the weekend [15:53] youy welcome [15:53] sinzui: worked my way through the review projects and manged ok [15:53] there are 11 there am which I am sunsure of [15:53] and didnt want to just ack them === almaisan-away is now known as al-maisan [16:05] czajkowski, I ran this : ./disable_projects.py ielix campus vinfolio ptchiang+test [16:05] ahh [16:06] czajkowski, I am deactivating the three ~registry projects [16:06] nods those were the ones I wasn't sure about [16:06] This one needs a fix first https://launchpad.net/madrasah [16:07] madrasah is not the upstream for edubuntu-live. We need to remove the package link to deactivate it. [16:07] yes they had picked too many liciences [16:07] The licenses are fine [16:07] Anything like a distro will have them all [16:08] czajkowski, I followed the All packages link from the project page to find https://launchpad.net/madrasah/+packages [16:09] We want to remove the package, then this will be an empty, meaningless project that we will deactivate [16:09] ok [16:09] and I have done that [16:09] The four remaining projects can be approved [16:10] sinzui: thanks [16:10] glad I checked with you [16:13] deryck: so just a heads up, added a card to see about updating the yui xhr tests to be combo loader friendly. Not sure the best way to do that off the top of my head yet. === salgado is now known as salgado-lunch === al-maisan is now known as almaisan-away === salgado-lunch is now known as salgado === deryck is now known as deryck[lunch] [17:47] flacoste, around? when you moved me to ~launchpad-emeritus I ceased being a member of https://launchpad.net/~launchpad-dev and because of that lost my subscription to launchpad-dev@ [17:47] what's the correct way to get me subscribed again? do I need to join https://launchpad.net/~launchpad-dev? [17:50] moin [17:50] salgado: just join it, its an open list [17:51] -> no privileges are granted by membership in it :> [17:52] oh, right, missed that [17:52] lifeless, btw, I've sent a mail a few hours ago so it's probably stuck waiting for moderation. care to let it through? === deryck[lunch] is now known as deryck [19:02] lifeless, you don't want to let my message through? ;) [19:07] salgado: haven't seen it - I'm doing my morning mail scan [19:07] salgado: plus giving czajkowski a hand [19:09] salgado: I dont see you mail in the queue either [19:09] lifeless, oh, ok, thought you didn't see my previous msg [19:09] hm, maybe it's dropped if I'm not subscribed to the list [19:10] but I should have good "standing", no? do we still have the concept of good standing in LP? [19:10] sinzui: got a second to mumble? [19:11] salgado: I think so :) [19:42] jcsackett, I can mumble. X just gave me some problems, but I think I am stable again [19:42] sinzui: cool. [19:44] salgado: I can't see the moderate mail for you [19:44] salgado: I have no idea why not. I suspect a bug due to your odd state. [19:44] jcsackett, http://people.canonical.com/~ianb/picker-demo.ogv [19:44] sinzui may know. [19:44] lifeless, my odd state? [19:44] salgado: you didn't leave the team directly [19:45] salgado, yes we have standing [19:45] We can make you excellent so that you can post to any list [19:46] salgado, you have excellent standing now [19:46] sinzui, heh, no need to worry; was just wondering because a message sent to launchpad-dev@ while I was not subscribed seems to have been discarded [19:46] oh, well, thanks [19:47] salgado, I see messages I moderate arrive. Maybe out list is ours/days behind again [19:48] sinzui, I resent it and it's arrived already, so I think that's unlikely? [19:49] I agree [19:52] right, the lack of moderation notice is what was odd [19:52] I'm thinking its because of a glitch in that you didn't 'leave' the team - you had indirect membership. I am probably wrong. [19:55] sinzui: speaking of IE9 937722 [19:55] bah [19:55] sinzui: speaking of IE9 - bug 937722 [19:55] <_mup_> Bug #937722: error loading Inkscape page on IE9 < https://launchpad.net/bugs/937722 > [19:55] sinzui: I'd like to get your thoughts on IE* + js compat. [19:56] sinzui: and chrome frame. Do you have time to talk (voice) today ? [19:56] in a few minutes [20:01] cool [20:03] lifeless: that looks like a dupe of bug 894797, should be pretty simple fix for that one at least [20:03] <_mup_> Bug #894797: bug portlet ajax calls break in IE and break js for other features < https://launchpad.net/bugs/894797 > [20:04] though not sure since that ie9 and my test/bug was ie8 I believe [20:05] rick_h: sure, its more the overall challenge we're setting ourselves I'm interested in [20:05] lifeless: gotcha, ok. [20:05] rick_h: (I mean, please do dupe it :P) [20:06] well, I'm not 100% sure, it's a different error string it looks like [20:06]