[00:00:00] trying to figure out where that LocalSettings.php came from and why the skins were cloned into that workspace [00:00:08] the problem is somehow a skin was able to trigger a mwext-qunit job [00:00:14] probably a check experimental thing [00:00:29] got it [00:00:45] is there an ext that depends on the Donate skin? [00:01:02] no extensions depend upon skins [00:02:25] you sure? [00:02:31] I've never heard of it, just asking K4 about it [00:02:36] :) [00:03:11] Hmmm K4 doesn't know about it either [00:03:16] I mean, in *CI* no extensions depend upon skins ;) [00:04:25] Not doc'd here https://www.mediawiki.org/wiki/Category:All_skins [00:07:25] It does exist: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/skins/Donate,branches [00:09:10] legoktm: marxarelli: success!! https://gerrit.wikimedia.org/r/#/c/265829/ [00:17:45] legoktm: i'm still confused about why there was a skin.json in src/skins/Donate for that workspace [00:17:48] pardon the ignorance [00:18:48] so zuul-cloner automatically clones $ZUUL_PROJECT [00:18:59] and somehow a patch in skins/Donate triggered the mwext-qunit job [00:19:05] so it cloned the repo into src/ [00:20:10] marxarelli: legoktm: cwd: diving into the old mediawiki/extensions/skins repo, I found that the skin was added in 2009 for that year's fundraiser [00:20:14] "Checking in 2009 fundraiser skin done by NY Tomas" [00:20:15] the zuul/layout.yaml has Donate using the mw-checks template which includes mwext-qunit [00:20:37] that's it :/ [00:20:44] probably should have a separate mw-skins-checks or something [00:21:04] Probably is long past its expiry date ;p [00:21:59] legoktm: marxarelli: cwd: how about on Monday we check with all of FR-tech just to make sure 100% sure that skin has no use (or at least no use in FR) [00:22:02] ? [00:22:19] um [00:22:27] sure? [00:22:37] Make sense? Should I make a Phab task, I guess? [00:22:49] AndyRussG: wait, why? [00:23:07] this is a CI problem, not a problem with that skin in particular [00:23:19] * AndyRussG imagines: "Donate skin, meet Phabricator. Phabricator, meet Donate skin. Donate skin: 'what, where's bugzilla?? Bwaaaahh' " [00:23:30] the main issue seems to be leaving the workspaces dirty, imo [00:23:50] um, we intentionally clone like this so we don't have to reclone later [00:23:53] marxarelli: sure but I think that skin is maxicruft and should be superpruned [00:23:56] yes, i know [00:24:04] but it's a problem in some cases clearly [00:24:04] its just that installer + skin = stupid [00:24:06] yeah [00:24:07] skins* [00:24:11] what if we just delete the skins dir [00:24:12] yeah [00:24:16] also that skin is broken! [00:24:28] legoktm: ^ right, so that's why I think we otta trash it [00:24:51] I don't think there's much cheese left under the layers of mould [00:25:26] the master branch of Donate doesn't seem to have that broken skin.json [00:25:40] so maybe it was just a broken patch [00:25:54] which hopefully didn't merge [00:26:05] legoktm: marxarelli: cwd: gotta run for family supper, I'll get backscroll pings if any tho. Thx so much!!!!!! :) cya [00:26:08] well, didn't merge [00:26:16] AndyRussG|souper: np [00:26:21] ;) [00:29:22] legoktm: seems like there should be an intermediate clone step, kind of like we do for scap3. i.e. clone to a central cache, then clone locally. the latter is efficient if it's on the same fs [00:29:35] we used to have that [00:29:39] then clone locally *to the workspace* [00:29:53] gerrit replication to the host, and then clone to the workspace [00:30:07] but we lost that when migrating to zuul cloner I think [00:30:16] i see [00:30:42] https://phabricator.wikimedia.org/T97106 [00:30:43] hmm [00:31:07] i'll bring it up with hashar. since we're moving to single-use instances, we'll need to solve for the caching layer anyway [00:31:55] those are currently using shallow clones [00:32:04] but we haven't figured it out for jobs that rely on multiple repos... [00:32:46] 10Deployment-Systems, 10Architecture, 10Wikimedia-Developer-Summit-2016-Organization, 7Availability: WikiDev 16 working area: Software engineering - https://phabricator.wikimedia.org/T119032#1958403 (10RobLa-WMF) [00:39:29] 6Release-Engineering-Team, 10Browser-Tests-Infrastructure, 10Reading-Web, 5Patch-For-Review: MW-Selenium associates wrong SauceLabs job with Jenkins artifact - https://phabricator.wikimedia.org/T105589#1958453 (10dduvall) I was finally able to reproduce this but introducing failures into the `features/sauc... [01:11:49] 10Gitblit-Deprecate, 10Diffusion, 5Patch-For-Review, 7WorkType-NewFunctionality: redirect gerrit repo paths to diffusion callsigns - https://phabricator.wikimedia.org/T110607#1958556 (10JanZerebecki) Another reason for some of the 404s is that T616 is not done yet. [01:48:16] 10Gitblit-Deprecate, 10Diffusion, 5Patch-For-Review, 7WorkType-NewFunctionality: redirect gerrit repo paths to diffusion callsigns - https://phabricator.wikimedia.org/T110607#1958613 (10Paladox) @demon does that it batches. And also from now when some requests a repo in gerrit it will also be done in phabr... [01:49:28] 5Gerrit-Migration, 10Gitblit-Deprecate, 6Release-Engineering-Team, 10Diffusion, and 2 others: Import all gerrit.wikimedia.org repositories with Diffusion - https://phabricator.wikimedia.org/T616#1958614 (10Paladox) Seems that there only needs to be a few repos created in phabricator. I'm not sure how many... [02:26:20] (03PS1) 10Dduvall: Log SauceLabs session URLs via Cucumber logger embeds [selenium] - 10https://gerrit.wikimedia.org/r/265894 (https://phabricator.wikimedia.org/T105589) [02:27:55] (03PS2) 10Dduvall: Log SauceLabs session URLs via Cucumber logger embeds [selenium] - 10https://gerrit.wikimedia.org/r/265894 (https://phabricator.wikimedia.org/T105589) [02:35:19] Yippee, build fixed! [02:35:19] Project browsertests-WikiLove-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #825: 09FIXED in 2 min 18 sec: https://integration.wikimedia.org/ci/job/browsertests-WikiLove-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/825/ [03:15:14] PROBLEM - English Wikipedia Main page on beta-cluster is CRITICAL: CRITICAL - Socket timeout after 10 seconds [03:16:06] PROBLEM - App Server Main HTTP Response on deployment-mediawiki01 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [03:16:35] PROBLEM - App Server Main HTTP Response on deployment-mediawiki02 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [03:16:39] PROBLEM - English Wikipedia Mobile Main page on beta-cluster is CRITICAL: CRITICAL - Socket timeout after 10 seconds [03:20:07] RECOVERY - English Wikipedia Main page on beta-cluster is OK: HTTP OK: HTTP/1.1 200 OK - 39866 bytes in 1.026 second response time [03:20:58] RECOVERY - App Server Main HTTP Response on deployment-mediawiki01 is OK: HTTP OK: HTTP/1.1 200 OK - 39554 bytes in 0.620 second response time [03:21:26] RECOVERY - App Server Main HTTP Response on deployment-mediawiki02 is OK: HTTP OK: HTTP/1.1 200 OK - 39533 bytes in 0.523 second response time [03:21:32] RECOVERY - English Wikipedia Mobile Main page on beta-cluster is OK: HTTP OK: HTTP/1.1 200 OK - 31523 bytes in 0.743 second response time [10:56:16] PROBLEM - English Wikipedia Main page on beta-cluster is CRITICAL: CRITICAL - Socket timeout after 10 seconds [10:57:06] PROBLEM - App Server Main HTTP Response on deployment-mediawiki01 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [10:57:36] PROBLEM - App Server Main HTTP Response on deployment-mediawiki02 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [10:57:42] PROBLEM - English Wikipedia Mobile Main page on beta-cluster is CRITICAL: CRITICAL - Socket timeout after 10 seconds [11:06:06] RECOVERY - English Wikipedia Main page on beta-cluster is OK: HTTP OK: HTTP/1.1 200 OK - 39868 bytes in 0.687 second response time [11:06:58] RECOVERY - App Server Main HTTP Response on deployment-mediawiki01 is OK: HTTP OK: HTTP/1.1 200 OK - 39540 bytes in 0.478 second response time [11:07:24] RECOVERY - App Server Main HTTP Response on deployment-mediawiki02 is OK: HTTP OK: HTTP/1.1 200 OK - 39533 bytes in 0.772 second response time [11:07:30] RECOVERY - English Wikipedia Mobile Main page on beta-cluster is OK: HTTP OK: HTTP/1.1 200 OK - 31523 bytes in 0.730 second response time [12:48:23] PROBLEM - Host deployment-mediawiki01 is DOWN: PING CRITICAL - Packet loss = 80%, RTA = 2843.38 ms [12:50:46] RECOVERY - Host deployment-mediawiki01 is UP: PING OK - Packet loss = 0%, RTA = 1.27 ms [12:51:01] Project beta-scap-eqiad build #87335: 04FAILURE in 6 min 14 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/87335/ [13:00:09] Yippee, build fixed! [13:00:10] Project beta-scap-eqiad build #87336: 09FIXED in 5 min 22 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/87336/ [14:35:45] Yippee, build fixed! [14:35:45] Project browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce build #393: 09FIXED in 7 min 44 sec: https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/393/ [16:58:01] Project browsertests-Wikidata-SmokeTests-linux-firefox build #84: 15ABORTED in 3 hr 0 min: https://integration.wikimedia.org/ci/job/browsertests-Wikidata-SmokeTests-linux-firefox/84/ [18:49:35] /msg NickServ VERIFY REGISTER paladox xrtuqqfwchfr [18:51:08] paladox, there goes your password in public. Time to change it. [18:51:23] oh wait, it's only *verifying*. Then no worries, sorry. [18:51:38] Still, better to use a dedicated tab for that instead of an existing channel. [18:54:32] elasticsearch latency is spiking to really unacceptable levels, half of the servers (all the old ones) are maxed on cpu...deploying a patch to repoint some es queries from eqiad to codfw cluster [18:54:45] https://grafana.wikimedia.org/dashboard/db/elasticsearch-percentiles [19:03:17] 10Beta-Cluster-Infrastructure, 6Labs, 10Labs-Infrastructure, 6operations: beta: Get SSL certificates for *.{projects}.beta.wmflabs.org - https://phabricator.wikimedia.org/T50501#1959150 (10Tgr) >>! In T50501#1951388, @faidon wrote: > Can someone repeat why we can't just flatten the beta hostnames and just... [19:18:44] andre__: Sorry i was learning how to register and i had a space between /msg. [19:26:19] 10Continuous-Integration-Config: Set up composer-test for all MW extensions where it isn't broken - https://phabricator.wikimedia.org/T124342#1959168 (10Paladox) How would we enable this on all the repos in one go without adding it too the repos that will fail. [19:32:32] paladox: I'm happy you register :) [19:32:55] andre__: Ok. :) [19:35:44] (03PS3) 10Paladox: [mediawiki/event-schemas] Add jenkins tests [integration/config] - 10https://gerrit.wikimedia.org/r/265534 (https://phabricator.wikimedia.org/T124319) [19:36:33] (03PS4) 10Paladox: [mediawiki/event-schemas] Add jenkins tests [integration/config] - 10https://gerrit.wikimedia.org/r/265534 (https://phabricator.wikimedia.org/T124319) [19:36:46] (03PS5) 10Paladox: [mediawiki/event-schemas] Add jenkins tests [integration/config] - 10https://gerrit.wikimedia.org/r/265534 (https://phabricator.wikimedia.org/T124319) [19:40:42] (03PS1) 10Paladox: Add file extension avsc to json-lint.php file [integration/jenkins] - 10https://gerrit.wikimedia.org/r/265940 [19:41:01] (03PS6) 10Paladox: [mediawiki/event-schemas] Add jenkins tests [integration/config] - 10https://gerrit.wikimedia.org/r/265534 (https://phabricator.wikimedia.org/T124319) [21:19:58] Project browsertests-QuickSurveys-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #152: 04FAILURE in 3 min 58 sec: https://integration.wikimedia.org/ci/job/browsertests-QuickSurveys-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/152/