[09:45:34] aude: https://bugzilla.wikimedia.org/show_bug.cgi?id=41352#c15 [09:48:12] * aude sighs [09:49:29] it has a bunch of dependencies, like the test cases [10:09:47] DanielK_WMDE: aude : I have rewrote https://gerrit.wikimedia.org/r/#/c/29972/ Stash global only once per test case. [10:09:55] removed the recursive call [10:13:00] and rebased the subsequent patches [10:20:42] hashar: thanks [10:30:19] reviewing 29973 right now [10:31:47] hashar: thanks [10:43:02] $ns = $this->getDefaultWikitextNS(); [10:43:02] $title = Title::newFromText( 'EditPageTest_testEditConflict', $ns ); [10:43:03] .... [10:43:09] our API is really dumb [10:43:19] newFromText() should really take care of it all by itself [10:51:24] hashar: hm? how could it? the "default wikitext NS" is itself a hack that is only useful for unit tests. [10:51:36] New patchset: Henning Snater; "ItemView / Site link templates" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30566 [10:51:36] hashar: btw i replied on https://gerrit.wikimedia.org/r/#/c/28014/ [10:59:13] DanielK_WMDE: my bot is using null in its summary http://wikidata-test-repo.wikimedia.de/wiki/Special:Contributions/MerlIwBot . That's because interwikimap at wikidata test does not include prefixes for wikipedia. Should i fix it at my bot or create a bug to update interwikimap http://wikidata-test-repo.wikimedia.de/w/api.php?action=query&meta=siteinfo&siprop=interwikimap ? [11:01:13] aude: DanielK_WMDE: reviewed https://gerrit.wikimedia.org/r/#/c/29973/ (Bug 41352) Provide tests for edit conflicts. [11:09:08] your tests are interesting [11:09:21] forced me to go have a look at EditPage.php which I haven't opened for yeaaars [11:09:34] our code base is really dirty :-( [11:12:51] New patchset: Henning Snater; "data type template for PropertyView" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30568 [11:35:04] hashar: editpage is indeed very ugly :o [11:35:25] no wonder it's fragile and breaks easily :( [11:35:42] and lacks tests :-] [11:35:51] yes [11:36:34] Merlissimo: looking at the interwiki map [11:36:38] aude: much of its functionality should be factored out into something like our EditItem class. [11:36:54] in fact, there should be a common EditSomething base class which both extends [11:37:17] all the conflict detection etc should happen there [11:37:32] and the form generation and handling should be isolated from that [11:37:40] (the conflict detection as impülemented in tewditpage is pretty broken btw) [11:37:57] DanielK_WMDE: agree [11:43:04] aude: JeroenDeDauw1: stripping your private account's rights on wikidata.org [11:44:03] aude: JeroenDeDauw1: or not [11:44:06] not enough rights [11:44:22] Lydia_WMDE: ok [11:44:38] we need to setup staff rights [11:45:33] aude: can you do that? [11:45:48] i think so [11:45:52] aude: and who can remove admin and beurocrat from your and jeroen's private accounts? [11:46:36] Reedy: do you have a staff account? [11:46:57] Reedy: we'd like to not have private accounts get admin rights initially [11:48:17] * aude will be admin as community member but there's a process on meta wiki for that [11:50:04] http://meta.wikimedia.org/wiki/Steward_requests/Permissions can be used for the initial admins, etc. [11:53:17] aude: we probably should ask the stewards about how we should work together with that [11:53:44] aude: because we could do most of the stewards job on wikidata in the beginning, if they do not mind [11:53:53] and unbusy them [11:54:32] btw is the favicon broken for others too on wikidata.org? i see half an office logo [11:54:42] or is that intentional? [11:54:43] favicon is broken i think [11:55:06] hi aude [11:55:15] probably needs to be stewards to assign initial rights, just to clearly separate roles [11:55:22] hi Nikerabbit [11:55:30] did I understand correctly that I need to fix something in Translate after all? [11:56:02] Nikerabbit: in the translationutils i think, it tries to create a new revision with null content [11:56:47] the TextContent constructor (and wikitext) expects a string, so an empty string would work if that makes sense in your situation [11:57:02] DanielK_WMDE: is that right? [11:57:05] aude: it tries to create a diff [11:57:33] i think between empty and existing content? [11:59:13] yeah [11:59:20] don't remember the details right now [11:59:24] only that the otherside was null [12:07:16] New patchset: Jeroen De Dauw; "Added base test for DataValue tests and some initial work on the string value test" [mediawiki/extensions/DataValues] (master) - https://gerrit.wikimedia.org/r/29337 [12:26:49] New patchset: Henning Snater; "Entity, label, description and property templates" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30574 [12:34:15] Silke_WMDE_: can you run the populateInterwiki script on the test repo so the interwikimap works correctly for the bots? [12:34:30] (it's in the client, but probably should be moved to lib or be a core maintenance script) [12:34:58] Change merged: Tobias Gritschacher; [mediawiki/extensions/DataValues] (master) - https://gerrit.wikimedia.org/r/29337 [12:44:02] Nikerabbit: i'd say that any code trying to create a diff against null is broken and should be fixed. [12:45:41] DanielK_WMDE: well, I tried to ask week ago whether I need to fix something or not, but got no definite answer until now [12:46:04] Nikerabbit: that may be because i was on vacation last week ;) [12:46:49] i knew aude did something to TextContent, but I din't know it was related to the Translate extension [12:47:29] can someone merge https://gerrit.wikimedia.org/r/#/c/29969/ ? TobiasG_WMDE verified it, it kind of hinders Anja's tests... [12:48:30] Nikerabbit: hm... what exactly is "verified" used for on bugzilla? does it mean the problem is verified, or the solution is? [12:49:23] solution [12:49:59] ah, so verified means the bug is closed. thanks. [12:52:27] aude: Done. Is it okay now? [13:00:16] Change merged: John Erling Blad; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/29969 [13:02:12] Silke_WMDE_: looks good [13:02:13] http://wikidata-test-repo.wikimedia.de/w/api.php?action=query&meta=siteinfo&siprop=interwikimap [13:02:16] all the wikipedias are there :) [13:02:29] Merlissimo: ^ [13:03:30] aude / Silke_WMDE_: thx [13:03:31] jeblad_WMDE: thank you! [13:03:45] np [13:05:17] DanielK_WMDE: any luck with the fatal exception error that we see on wikidata.org? [13:08:55] aude: oh, the one from editing mediawiki:mainpage? [13:09:05] DanielK_WMDE: or any page or item [13:09:06] damn! is that even on bugzilla? [13:09:11] o_O [13:09:12] well, not editing.... creating [13:09:20] there is a bug [13:09:43] wikidata.org, not wikipedia.org.. =D [13:09:52] https://bugzilla.wikimedia.org/show_bug.cgi?id=41436 [13:10:23] aude: guh, didn't have the "ContentHandler" component [13:10:38] i'll look into it, that seems to be a real blocker ;) [13:10:41] it is [13:10:53] Lydia_WMDE, Denny_WMDE etc are eager to have editing [13:11:09] only page editable now is the main page and only by autoconfirmed users [13:13:15] New patchset: Henning Snater; "HTML Templates for aliases edit tool" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30579 [13:14:33] other semi-blockers are wikidata ssl and a few ULS things (requesting unavailable jsons - either because they don't exist or allow origin issues) and anon caching [13:14:48] Denny_WMDE: ^ FYI [13:15:19] oh, i thought ssl cert is done already? [13:15:33] not totally fixed yet [13:15:33] https://wikidata.org/ [13:15:41] maybe it's just not been deployed yet [13:17:50] New patchset: Anja Jentzsch; "Tests for Change I6ea1f848: Prefix term search" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30132 [13:19:13] !nyan [13:19:13] ~=[,,_,,]:3 [13:19:28] heh [13:20:33] \o/ [13:20:44] finally. the bot is complete [13:21:00] aude: i can't reproduce the issue locally [13:21:03] this sucks. [13:21:28] DanielK_WMDE: neither can i with the wmf core branch and extension branch [13:21:43] * aude tried [13:23:21] aude: can you check whether our jenkins runs use $wgContentHandlerUseDB = false; ? [13:23:23] they should [13:24:04] New patchset: Anja Jentzsch; "Tests for Change I6ea1f848: Prefix term search" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30132 [13:25:38] actually... it should have the same setting as on wikidata.org [13:26:03] from looking at the error, it seems to be set to true there. So we should do that, too. [13:27:12] i have it false on my setup [13:27:22] oh, do i? [13:27:33] it's true on my repo [13:27:55] AnjaJ_WMDE: [13:28:03] 13:23 < DanielK_WMDE> aude: can you check whether our jenkins runs use $wgContentHandlerUseDB = false; ? [13:28:48] AnjaJ_WMDE: basically, we should make sure it has the same setting that is used on wikidata.org [13:29:11] which, from the looks of it, is "true". [13:29:41] it is true on wikidata.org [13:31:07] http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php [13:31:17] Change merged: Tobias Gritschacher; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30132 [13:38:39] DanielK_WMDE: and it doesn't matter whether wikibase is enabled or not on wikidata.org [13:38:54] it's just the contenthandlerusedb setting that affects this [13:40:03] aude: yea. i think i know what is happening. it has to do with db transactions and/or the master/slave setup. [13:40:30] http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php [13:40:53] ah [13:40:53] if the extension is disabled, so are our namespace settings [13:41:08] really, transactions? [13:41:15] yes [13:42:24] somehow title === null there [13:42:39] basically, the Revision object tries to create a Title object to determin the content model. to do this, it looks at the page table, using a page id that came from previously inserting a new record into the page table. [13:43:09] however, depending on db setup, this may fail, because the insert wasn't yet committed to the database, so the record can not be read back in [13:43:27] i'm pretty sure i know how to fix it, but i have no idea how to test it ;) [13:44:27] * aude sees [13:45:14] but it works without cotnent handler setting [13:45:22] however that's done [13:45:37] there's no null check there but [13:46:44] if( isset( $row->page_latest ) ) { [13:46:57] then the title gets set or else it's null [13:49:08] aude: yes, if the db isn't used for the content model, then the revision object doesn't need the title. [13:49:20] anyway... [13:49:49] hm... i guess the usedb setting is what is protecting all the other sites from this bug ;) [13:49:52] ok [13:50:02] it is [13:50:36] i'm currently running all unit tests against my fix. it's a bit more than strictly necessary, cleans up some dodgy code too. [13:50:47] ok [13:50:54] i'll dubmit patches for master and wmf2 [13:51:01] ok, thanks [13:51:20] New patchset: Jeroen De Dauw; "Added testGetSortKey" [mediawiki/extensions/DataValues] (master) - https://gerrit.wikimedia.org/r/30584 [14:01:10] Lydia_WMDE: / Sebaso_WMDE: when will wikidata.org db tables also be available on toolserver? is wikidata really on the busy s3 cluster? [14:02:05] yes, it's on s3 [14:02:10] Merlissimo: not sure when - but tbh that's not exactly our main concern right now ;-) [14:02:20] other things are more important to fix atm [14:03:24] our jenkins is also using $wgContentHandlerUseDB = false [14:04:20] o_0 [14:04:34] Lydia_WMDE: so you want me to de-crat everyone? [14:05:20] AnjaJ_WMDE: probably want to change that, but thanks for checking :) [14:05:25] Lydia_WMDE: yes i know, but tool authors also need some time to handle for updating their scripts. But that's more a toolserver task than yours. [14:05:29] Reedy: staff accounts are fine for now with the rule that they're only supposed to do staff actions [14:05:37] * aude nods [14:05:40] Reedy: not create content and stuff like that [14:05:56] Merlissimo: *nod* understood [14:05:57] Reedy: i think we'll setup a new permissions group, like 'wikidata-staff' [14:06:19] and it could get the same rights as admins / bureaucrats but to be used only for staff actions [14:06:27] yeah [14:06:34] Lydia_WMDE: addinig a rule to titleblacklist could make sense to prevent edits [14:06:49] Merlissimo: ? [14:07:04] we can't be in the 'staff' global group as that's for WMF only [14:07:19] you could add a rule, so that ony admin/staff can create new pages as wikidata.org [14:07:33] Merlissimo: ah yeah well it's broken atm anyway :D [14:07:38] even without a rule [14:07:39] \o/ [14:07:54] :( [14:08:18] Merlissimo: i assume you want to be an admin? [14:09:10] aude: why? i think an empty wiki does not need any admins ;-). [14:09:21] or a bureaucrat? [14:09:25] :) [14:09:38] we'll have to get some admins once we start getting content [14:09:47] just to take care of things [14:10:01] * Sannita shyly raise his hand [14:10:06] yeah but let's figure out a process for that before we do it ;-) [14:10:09] http://meta.wikimedia.org/wiki/Steward_requests/Permissions [14:10:16] New patchset: Jeroen De Dauw; "added toJSON and equals tests and fixed broken test method :)" [mediawiki/extensions/DataValues] (master) - https://gerrit.wikimedia.org/r/30587 [14:10:32] that's the process i think for the first few folks and then we can have a local policy on the wiki [14:11:01] we shouldn't be in the business of deciding who's admin. the community should do it [14:11:36] yes [14:11:46] that's what i am saying [14:11:47] yes [14:11:49] we should not hand it out until that decision is made [14:12:08] the stewards page on meta is how it's normally done before a wiki has a local policy [14:12:25] then the initial community makes the decision [14:17:28] Lydia_WMDE: i think we need some rule of thumb for handing out admin access before there's much of a community. [14:17:53] maybe just require them to be an admin on one large or two small wikis, or some such. [14:17:59] Reedy: why does wmf not use a new cluster for wikidata only like for big wikis? Or mayebe a new cluster for wikidata+centralauth only? because downtime of this cluster causes outage of all other wikis [14:18:38] A new cluster requires purchasing and provisioning of new hardware [14:18:53] It'll likely be done when it's in full production, but now there isn't much point [14:18:54] Merlissimo: i suppose the will once wikidata gets big [14:18:55] DanielK_WMDE: that's essentially how the stewards do it [14:19:02] As for centralauth, having a seperate cluster is pointless [14:19:12] Just because it's on it's own hardware, doesn't mean it won't go down [14:19:15] so now if either s3 or s7 is down everything goes down, too. then maybe move wikidata to s7? [14:20:00] Maybe [14:20:01] Maybe not [14:21:14] having two indepentent points of failture each causing complete outage does not make sense to for me [14:21:14] It's really not a concern at the moment [14:21:38] If s1 goes down, that tends to cause problems everywhere [14:21:43] Same for commons [14:21:52] DanielK_WMDE: probably the criteria for a steward are enough for the moment [14:22:01] s1 is enwiki only . e.g. dewiki is still ok then. [14:23:09] and commons was moved to a separate cluster because of this. but a commons outage only breaks the view, not the wiki usage [14:23:42] It breaks global usage [14:23:43] (and globalimagelinks on commons is really incomplete because of short outages) [14:24:44] I don't see why this matters now [14:24:52] It's not ready for production usage [14:25:23] that's why a cluster move is quite simple atm [14:25:24] So it isn't an issue for the short term... I'm not sure when it's penned for much wider use [14:25:32] It's no more difficult later [14:25:40] Just might take longer due to more data [14:25:49] But as I said, there isn't any spare hardware for it now [14:25:58] ... and outage while moving [14:26:01] And? [14:26:05] Shit happens [14:26:16] So you'd have to wait 2-4 weeks for purchasing, authorisation, delivery, installation, deployment... [14:27:44] Either way, it's not my decision [14:27:50] Bring it up on wikitech-l [14:28:20] !nyan [14:28:20] ~=[,,_,,]:3 [14:28:50] heh [14:28:57] ty Jens_WMDE, really helpful :p [14:35:12] New patchset: Jeroen De Dauw; "Added script to import blacklisted items" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30590 [14:35:19] New patchset: Jeroen De Dauw; "Added script to import blacklisted items" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30590 [14:40:26] New patchset: Jeroen De Dauw; "Added script to import blacklisted items" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30590 [14:43:13] New patchset: John Erling Blad; "(Bug 41164) Initial commit of wbgetclaims" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/30591 [14:47:21] Reedy: i keep hearing "outage". did i miss something? [14:47:24] what did i break? [14:47:36] I don't think you broke anything [14:47:38] Gerrit keeps dying [14:47:42] /erroring [14:48:22] It doesn't seem to want to let me clone core to branch 1.21wmf3 [14:50:06] oh, it's going now [14:50:08] just sloowly [14:58:56] New review: Denny Vrandecic; "I have not run it, though." [mediawiki/extensions/Wikibase] (master); V: 0 C: 2; - https://gerrit.wikimedia.org/r/30590 [15:04:21] aude: When shall we look into #41112? Tomorrow morning? [15:07:32] When do you want upgrading to 1.21wmf3? Today with test, test2 and mediawikiwiki? [15:10:21] Diff and Wikibase are still on your branch. ULS (and core) are updated to master [15:13:58] DanielK_WMDE: I think this call is for you.. ;) [15:14:52] But we use master for our work so last version is more likely to work.. /me thinks [15:15:35] Reedy: i'm about to submit a patch to fix the fatal error on wikidata.org. Shall I submit it to wmf2 or wmf3? [15:16:10] Well, it's currently on wmf2 [15:16:19] Depending on your answer to my question above, it might be both ;) [15:16:34] i think we can update wikidata.org core to wmf3 today. [15:16:52] Cool [15:17:23] Just submit it to wmf3, I'll merge it and it should be live in the next hour or so when the localisation cache has been updated and synced [15:17:48] Reedy: is wmf3 created now? [15:17:56] yup [15:18:04] ok [15:18:50] gah, API tests take forever! [15:19:18] DanielK_WMDE: will editing on wikidata.org work then? [15:21:57] wmf3 on wikidata is great [15:22:24] since wmf2, some of the content handler test files were reorganized so will be nice to have that [15:22:57] * aude can't wait to go home and try editing wikidata.org :D [15:23:46] http://www.wikidata.org/wiki/Wikidata:Main_Page :O [15:24:22] :) [15:24:41] really, guys... I'm so fu**ing excited :D [15:25:07] Sannita: you should be able to edit the main page [15:25:21] not sure how the autoconfirm works here with the new wiki [15:26:05] http://www.wikidata.org/w/index.php?title=Special:Log&offset=&limit=5000&type=newusers [15:26:10] 3164 accounts created on the wiki... [15:26:20] ok, not yet autoconfirmed [15:26:29] Reedy: i think they are autocreated with SUL somehow [15:26:41] Usually it requires actually visiting the wiki [15:26:43] unless something changed [15:26:44] really? [15:26:53] * aude can't imagine 3164 people visiting [15:27:08] wtf? [15:27:08] Or it's the image loading... [15:27:08] we had the central notice icon [15:27:10] yes, that's it [15:27:11] yeah [15:27:25] that counts as "visiting" :) [15:27:25] rebase from wmf2 to wmf3 creates a gazillion conflicts [15:27:40] DanielK_WMDE: not surprised [15:27:50] i am. why would it show conflicts in files i dodn't touch? [15:28:00] Reedy: do you want to review https://gerrit.wikimedia.org/r/#/c/27164/ [15:28:01] I can in a few minutes [15:28:02] it would be nice to finally get that one in [15:28:29] it keeps causing conflicts when hacking on editpage or vice versa [15:28:59] siebrand brave enough to deglobalize editpage.php :) [15:29:33] uhm I tried to edit my userpage and "Internal error: [2237deb0] 2012-10-29 15:29:07: Fatal exception of type MWException" [15:29:36] +508, -409 [15:29:37] Feck. [15:29:43] Sannita: Yup, we know [15:29:43] No editing works there [15:29:48] there's no prob [15:29:58] Should be fixed in the next couple of hours [15:30:28] Sannita: sad :( [15:30:42] no editing yet [15:31:12] pfff, guys, really... you're doing an amazing job, wish I wasn't a simple politologist to give you some help :P [15:31:56] Sannita: if you want to help us with http://meta.wikimedia.org/wiki/Wikidata/Main_Page_draft :) [15:32:00] that would be great [15:32:23] I'll try to contact some wikigraphics on it.wp [15:41:20] Reedy, aude: i just posed fixes for the fatal error on creating pages [15:41:35] (including a stupid typo in the tag line) [15:43:28] aude: merged ;) [15:44:49] Sannita: So you are a poltergeist? [15:45:55] jeblad_WMDE: my room is, atm [15:46:04] Hehe; 123 items with 234 properties :D [15:46:52] * jeblad_WMDE digs into wbsetclaimvalue and disapear [15:46:55] yay! [15:47:24] Nice and clean draft for the main page! =) [15:53:11] Reedy: is there a way to try my patch on wikidata.org before pushing it out to all apop servers? [15:55:19] Not exactly, but we're in a good position to do it when this scap has finished [15:55:28] Can test it only on test2/wikidata [15:55:59] Reedy: ok, let me know [15:56:08] i'll probably be available for another hour or so. [15:56:22] digging into other stuff now [16:03:02] Reedy: does bug 41309 still exist? was it a one-time fluke? [16:03:06] DanielK_WMDE: i see it uses $linkCache->addLinkObj( $this ); via getArticleID [16:03:24] that worries me a little bit although the code seems to work with the patch [16:04:03] aude: yes, but as far as I can see, we nowhere rely on this. [16:04:17] ok [16:04:22] * aude trusts you :) [16:04:25] until now, the Revision object always wnated a page id. now you can also supply a title object. [16:04:46] well... don't trust is good, *blind* trust is silly :) [16:04:47] this seems better than before but still a little messy [16:05:08] well yea - the way stuff gets passed into the Revision constructor is nasty. [16:05:10] * aude tries to create more pages with the patch [16:05:20] yes [16:07:15] DanielK_WMDE: I'd have to dig through the logs. I can do later [16:07:30] ok, just post to the bug [16:09:43] seems to be that $mArticleID should = 0 if the page doesn't exist [16:09:43] that would work [16:17:49] oh, wait, then article Id should never be 0? [16:18:34] sorry, not artcile id [16:18:34] item id [16:18:36] i was confused [16:24:47] Denny_WMDE: item id should also never be 0. [16:25:05] i think for not-yet-created items it would be null, not ß [16:25:10] err, not 0 [16:26:19] but mPage can't be null in revision [16:26:27] for content handler [16:27:27] you do a Title::newFromID( 0 ) essentially [16:28:06] if title does not exist yet in revision [16:35:52] Denny_WMDE: https://gerrit.wikimedia.org/r/#/c/30597/ [16:36:18] We should replace null with ß [16:36:21] =) [16:37:53] gerrit broke again [16:40:00] eeek [16:40:02] aude: i am afraid i cannot review that :( [16:40:09] Denny_WMDE: ok [16:40:15] don't feel confident enough about it [16:40:31] actually, sorry, don't feel confident enough about my own skills for that [16:40:34] the issue seems to be with database replication and a lag [16:41:36] the entire revision class and edit page appear a bit fragile but think and hope this fixes it [16:44:53] DanielK_WMDE: https://gerrit.wikimedia.org/r/#/c/30599/ [16:44:53] That fixes it [16:45:09] Note, you could've cherry picked the change from master to use the same change-id ;) [16:46:28] aude: i don't get it. in https://gerrit.wikimedia.org/r/#/c/30597/ why should mTitle be an object in line 604? wouldn't it be a string, due to line 583? [16:48:42] New review: John Erling Blad; "This verifies when I run the tests, bu note that there are no specific tests for this changeset yet...." [mediawiki/extensions/Wikibase] (master); V: 0 C: 0; - https://gerrit.wikimedia.org/r/30591 [16:48:43] we can edit! [16:48:52] well, when i go home [16:49:50] I have a user page! =) [16:50:10] aude: don't you have a wmde account? [16:51:08] yes [16:51:23] as user:aude, i keep getting logged out after logging in :( [16:51:33] bad [16:51:39] cannot replicate [16:52:10] should i try to create an item? [16:52:22] The requested URL /wiki/Special:RecentChanges was not found on this server. [16:52:27] Thats weird [16:52:49] i am getting 404s too sometimes [16:53:03] retry and it works [16:53:05] still wondering where it comes from [16:53:08] Yes it did.. [16:54:02] creating an item gives me this: [16:54:02] Database error [16:54:02] A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: [16:54:02] (SQL query hidden) [16:54:02] from within function "ORMRow::insert". Database returned error "1146: Table 'wikidatawiki.wb_changes' doesn't exist (10.0.6.44)". [16:54:18] from within function "ORMRow::insert". Database returned error "1146: Table 'wikidatawiki.wb_changes' doesn't exist (10.0.6.44)". [16:54:24] Reedy: ! [16:54:33] i think we missted a schema update [16:54:33] o_0 [16:54:36] I've been logged out.. :( [16:54:41] was update.php run? [16:54:47] No [16:54:48] jeblad_WMDE: my staff account seems to stick [16:54:49] We don't run it on the cluster [16:54:51] ever [16:55:02] he imported sql files but we missed one [16:55:07] * Reedy looks where it came from [16:55:47] ah, ok [16:55:54] repo/sql/changes.sql ? [16:56:02] that's it? [16:56:16] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Wikibase.git;a=tree;f=lib/sql;h=f2d3470c9657d8febc8d7a448a3a18f25e0048ef;hb=refs/heads/wikidata-wmfphase1beta [16:56:18] It's not in that branch [16:56:20] Hmm [16:56:23] let me check something [16:57:10] really? [16:57:20] * aude checks out the branch [16:57:45] wb_changes used to be in lib, now it's in the repo, i think [16:57:49] got moved, btu should alwaysw be there [16:57:52]