[00:17:54] * Krinkle writes it up [00:18:02] What's wrong with mwscript in deployment-prep? [00:18:06] Seems I can't pass it an absolute path [00:18:12] The MediaWiki script file "/home/krinkle/wmfManageJobs.php" does not exist. [00:18:18] var_dump(file_exists('/home/krinkle/wmfManageJobs.php')); [00:18:18] bool(true) [00:18:28] works on terbium [00:18:30] in prod [00:20:19] Ah, chmod visible of my home dir [00:20:21] nvm :/ [00:20:28] for www-data user [00:35:10] bd808: Got a script up - https://gerrit.wikimedia.org/r/368116 [00:44:55] Krinkle: on casual read it looks good [03:27:09] TimStarling: I'm trying to compile PoolCounter (first time) on Mac OS. Aside from libevent, any other requirements I should know about? [03:27:33] Currently getting this from Make: https://gist.github.com/Krinkle/5dae481d3b0ff918139f329ef52c9e01 [03:27:44] don't think so [03:28:01] you could... compile it on linux [03:29:03] http://manpages.ubuntu.com/manpages/xenial/en/man2/accept4.2.html [03:29:10] that is a function that exists [03:29:59] I've been thinking that we should split the daemon out to a separate repo, as a first step towards making it useful for things that aren't mediawiki [03:39:23] Ah, on mac it's just accept [03:39:44] HAVE_ACCEPT4 already accounts for this [03:39:46] * Krinkle tries again [03:40:53] Just 2 left [03:40:53] https://gist.github.com/Krinkle/5dae481d3b0ff918139f329ef52c9e01 [03:41:15] TimStarling: I'm writing a Readme for the repo. It's kinda funny and sad that it requires 4 different programming languages and 5 different build tools to test fully [03:41:27] (PHP, composer, node.js, npm, Ruby, Bundler, C, Make) [03:41:37] And whatever runs Rake [03:57:30] Meh, fixing ACCEPT4=0 just exposes more errors (next one is: non-standard header malloc.h, use stdlib/stdio instead) [03:57:40] I'll compile inside Vagrant instead [04:02:20] inside Vagrant, all fine, although the Cucumber tests does have 2 failures : https://gist.github.com/Krinkle/5dae481d3b0ff918139f329ef52c9e01 [04:10:23] are you done with README.md? [04:18:08] Yeah [04:18:26] I didn't know Jenkins also runs the tests for the C daemon. Quite nice [04:18:43] Must be something with my vagrant then. The ACQ4ANY always times out for me in the test. [04:22:39] well, one of the cucumber tests just failed when I tried to merge README.md, so maybe not [04:26:38] Hm.. [04:28:34] Cannot assign requested address - connect(2) for 127.0.0.1:7531 (Errno::EADDRNOTAVAIL) [04:31:40] I guess it needs SO_REUSEADDR [14:48:30] o/ CindyCicaleseWMF [14:49:36] Greetings bd808! [14:51:35] When you are settled in we should talk about the 3rd-party stuff that ended up in the annual plan. I think you get to be one of the people who thinks about what and how we should work on better comms. [14:57:09] Sounds good! The firehose of new information has started to slow down a bit, so I'll add something to your calendar. [14:57:41] awesome [15:02:23] Yay! [17:49:30] DanielK_WMDE_: Yo what do we need to do to get https://gerrit.wikimedia.org/r/#/c/367328/ live? [17:49:45] (I held back wikidatawiki to wmf.10 yesterday) [17:57:40] RainbowSprinkles: I cherry-picked it to the wmf/1.30.0-wmf.10 branch of Wikibase now: https://gerrit.wikimedia.org/r/#/c/368224/ [17:57:57] +2'd [17:58:06] It has to somehow get into the wmf/1.30.0-wmf.10 of wikidata, though. Either by patching it into the build, or by making a new build. [17:58:18] i'm rather blurry on the details. [17:58:23] We have a wmf.10 build of wikidata? I saw wmf.7 in make-wmf-branch [17:58:44] according to https://phabricator.wikimedia.org/diffusion/EWDA/branches/master/ we do [17:58:58] aude: are you around? [17:59:12] can you help getting a patch backported? [17:59:18] Ah, wonder if it was added to wmf.10 after the fact but not updated in make-wmf-branch [17:59:24] So we reverted to wmf.7 this week [18:00:12] RainbowSprinkles: addshore also knows, i think. he said he's out for a bit, but will come back later. hoo isn't online. Tobi_WMDE_SW is marked as away. [18:00:25] Ah ok, wmf.10 is on both [18:00:29] (10 and 11) [18:00:37] So not on wmf.7, red herring :) [18:00:41] to be honest, all that build stuff confuses me. I'll stick to complex refactoring ;) [18:00:48] #truth [18:03:36] so, the latest Wikidata build should already have the patched version: https://phabricator.wikimedia.org/rEWDA7f3df0037203feba867a795154b72c0d2beda5ad [18:04:17] but the wmf.10 build of wikidata should be based on the wmf.10 build of wikibase, not master of wikibase, right? [18:04:41] so, i'm not sure how to now get all the ducks in a row... [18:05:21] confirmed, the fix is on Wikidata/master: https://phabricator.wikimedia.org/rEWDA7f3df0037203feba867a795154b72c0d2beda5ad#e4007f3a [18:06:43] Hmm. Sooooo, it's live already? [18:06:59] Or Wikidata/master needs to be merged to wmf.10? [18:07:09] * RainbowSprinkles is trying to follow along [18:07:35] it's not live. master of Wikidata only goes to beta [18:07:50] Gotch [18:07:51] a [18:08:00] we'd have to update the wmf.10 branch of wikidata. i don't know how to do that. [18:08:35] i guess we could make a patch by diffing the relevant files between wmf.10 and master, and patching that into wmf.10 of wikidata. [18:08:47] but i'm scared :) [18:09:00] Yeah, I thought I could do that. [18:09:02] But it's scary [18:09:29] Katie is the expert for the build stuff. I should really learn how to do that, though... [18:09:50] It'd be easy enough to monkey patch in with a diff, but I'd be afraid of it being overwritten [18:09:53] she has been around the last couple of days. i'll shoot her an email [18:10:13] only master is updated automatically, afaik [18:10:23] deployment branches don't get updated [18:10:38] would be nice if they were - then we'd just have to wait :) [18:12:47] DanielK_WMDE_: Here's what we'll do. We'll go ahead with the train @ noon like usual, but just hold wikidata back to wmf.10 for now (like I did yesterday) [18:12:57] Then later today when build is updated (or tomorrow even), we'll update wikidata [18:13:10] cc thcipriani, that sound ok by you? ^ [18:13:39] fine by me [18:14:03] yay teamwork :) [18:14:19] RainbowSprinkles: ok. I'll put that into the mail. [18:15:28] thcipriani: Went ahead and prepped wikiversions.json [18:15:33] wikidata remains as the only wmf.10 wiki [18:15:37] RainbowSprinkles: so... you are updating everything to wmf.11, but keep wikidata on wmf.10? you'd have t odo that anyway, because there is no wmf.11 branch of wikidata, no? [18:15:37] https://gerrit.wikimedia.org/r/#/c/368228/ [18:15:53] DanielK_WMDE_: Well we haven't bumped the MW core version to wmf.11 [18:15:59] I was under the impression this was a blocker to that :) [18:16:06] i don't think it is [18:16:14] this is unrelated to core compat [18:16:17] Hah. So we could've moved ahead anyway? [18:16:24] Yay blocker confusion [18:16:26] :) [18:16:40] proooobably. [18:16:58] i soo no reason how this would block updating core. [18:17:11] wikibase itself is broken (and now fixed). [18:17:34] we just have to make sure to not deploy a version of wikidata that has the broken code. let me check [18:19:30] RainbowSprinkles: so Wikidata's wmf.10 branch has the bad code. It must be patched, or mustn't be deployed. [18:19:40] This is probably the reason that the live version is wmf.7 [18:19:51] Configured version is wmf.7 [18:19:55] But git log on tin looks like wmf.10 [18:20:03] huh [18:20:19] I'm just saying what I see.... [18:20:27] i have no idea what it means :) [18:21:23] the critical code is in extensions/Wikibase/client/includes/Changes/WikiPageUpdater.php [18:21:36] if that file mentions getEmptyTransactionTicket(), it's the broken code [18:21:54] if however extensions/Wikibase/client/includes/Changes/InjectRCRecordsJob.php exists, it's the fixed code [18:22:05] if neither is the case, it's the old code. [18:22:18] ...old code meaning it's not broken, but it sucks. [18:23:59] RainbowSprinkles: maybe someone just reverted WikiPageUpdater.php?! [18:27:50] demon@tin /srv/mediawiki-staging/php-1.30.0-wmf.10/extensions/Wikidata ((41db3da4c...))$ git status [18:27:52] HEAD detached from 65c7e4687 [18:27:52] nothing to commit, working tree clean [18:28:13] so, this is live with the base code?... uh.... [18:34:03] so wikidata wmf.10 has been live since last week's train it looks like: https://github.com/wikimedia/mediawiki-tools-release/commit/cf41b4c5447dbac95dfcbdcd528156ec68757b9c [18:35:14] That matches what I saw on tin [18:36:30] Ignore everything I said about wmf.7 [18:36:45] (my git clone was out of date....) [18:36:55] So yes, we just need Daniel's backport into wikidata @ wmf.10 [18:42:27] if wmf.10 of wikidata has been live without the patch for a week, there's no point in blocking on it now. [18:43:44] the error causes log spam, and database transactions get a bit strange, but nothing should be loast [18:43:49] *lost [18:46:10] I haven't seen this spam specifically...hmm [18:46:11] Ok [18:47:21] ok, so I'll just roll forward wmf.11 to all wikis during the train window. [19:36:01] RainbowSprinkles: so, monkey patching is apparently the correct thing to do: https://wikitech.wikimedia.org/wiki/How_to_deploy_Wikidata_code#Deploy_a_hotfix [19:36:32] But...not commit? [19:36:35] That sounds scary! [19:40:54] sure, commit and push for review. [19:41:00] not sure why it says "not merge". [19:41:29] i guess the idea is to leave it to deployers to merge the backport [19:41:50] on a good side, if your shotgun is powerful enough, you can shoot yourself on the foot only once [19:43:05] MaxSem: yes, especially if you hold it the wrong way up... [19:45:01] Nah, you can just get a prosthetic foot and then shoot yourself in that. [21:25:51] DanielK_WMDE_: RainbowSprinkles I'm here :) [22:13:45] addshore: i tried to update the wmf/1.30.0-wmf.10 wikidata build, but composer is messing with vendor/composer/installed.json and i don't quite understand what it's doing. [22:14:20] messing with it how? it just just update it to show what is installed [22:14:21] would be nice to get the build updated. it's not super urgent though, tomorrow will do [22:14:27] See https://gerrit.wikimedia.org/r/#/c/368312/1 that I made [22:14:45] well, either composer changed a lot more than i expected, or it's messing with the order, creating a huge diff [22:15:01] vendor/composer/installed.json | 150 ++++++++++++------------ [22:15:05] not sure why jenkins is failing though, looks like a similar CI failure was happening with the build on master for the past 5 days or so, but todays build it didnt fail [22:15:43] DanielK_WMDE_: yeh I have 182 changed in installed.json, it basically removes the wikibase bit from the json and re adds it to the end (as it was the most recently changed component) [22:16:01] most of the 182 lines are the same, but the hashes have changes, but it looks big because of the move [22:16:18] so you think i can just trust it? [22:18:32] DanielK_WMDE_: PS2 I made but moved the json section into the same place [22:18:32] https://gerrit.wikimedia.org/r/#/c/368312/2/vendor/composer/installed.json [22:18:50] still no idea why CI fails though [22:19:45] ha, i was about to push that. you beat me to it. i need more practice ;) [22:20:26] RainbowSprinkles: --^^ [22:21:14] DanielK_WMDE_: see -operations, already told greg & thcipriani, but if I cant figure out why the CI is being lame soon we might just have to leave it till tommorrow for now [22:22:10] The .git directory is missing from extensions/PropertySuggester/ [22:22:12] etf? [22:22:17] wtf even [22:22:58] addshore: why does it need a .git file there? [22:23:23] no idea [22:23:33] Im 99% sure it is nothing relating to the chage [22:23:35] *change [22:23:41] I'm checking with https://gerrit.wikimedia.org/r/#/c/368315/ [22:24:09] but yeh, the builds for the 26th 25th 24th 23rd etc all seem to have the same CI error [22:24:17] but the 27th passed and was merged [22:35:01] DanielK_WMDE_: its not blocking the train any more so I'll look again tommorrow and reply to the email again too :) [23:03:26] hi [23:04:00] \m/ [23:25:47] RainbowSprinkles: around?