[03:44:02] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team, 10MediaWiki-Core-Tests, 10Wikimedia-log-errors (Shared Build Failure): Quibble CI jobs failing due to memory allocation - https://phabricator.wikimedia.org/T198432 (10Krinkle) [07:45:09] (03CR) 10Prtksxna: "Legoktm, feel free to take over this patch." [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/446271 (https://phabricator.wikimedia.org/T199768) (owner: 10Prtksxna) [08:36:53] zeljkof: hello! I got a tiny patch to simplify the selenium / wdio / daily jobs: https://gerrit.wikimedia.org/r/#/c/integration/config/+/455203/ :] [08:39:08] hashar: I got back from Italy yesterday evening, still unpacking [08:39:18] I'll be around for our 1:1 [08:53:05] zeljkof: I have someone at home for the gaz heater maintenance... [08:53:10] should not be long [08:56:43] 10Release-Engineering-Team, 10MediaWiki-extensions-WikimediaIncubator, 10Epic, 10I18n: Make creating a new Language project easier - https://phabricator.wikimedia.org/T165585 (10Amire80) >>! In T165585#4533109, @Liuxinyu970226 wrote: > Currently @Wolverène oppose this idea, following reasons below: > > #... [09:03:16] hashar: I'm around, let me know when you're ready [09:22:05] zeljkof: back [09:28:11] hashar: ok, joining hangout [09:53:11] 10Phabricator: Open tasks are not shown on a project workboard when they are in a hidden column - https://phabricator.wikimedia.org/T202878 (10Aklapper) p:05Triage>03Lowest [09:57:21] 10Phabricator (Upstream), 10Upstream, 10User-Matthewrbowker: Phabricator emails are sometimes mis-encoded on iOS - https://phabricator.wikimedia.org/T180405 (10Aklapper) 05stalled>03declined [11:00:16] (03PS1) 10Hashar: docker: install Quibble from latest patch not head [integration/config] - 10https://gerrit.wikimedia.org/r/455536 [11:02:01] (03CR) 10Hashar: [C: 032] docker: install Quibble from latest patch not head [integration/config] - 10https://gerrit.wikimedia.org/r/455536 (owner: 10Hashar) [11:02:14] (03CR) 10Hashar: [C: 04-2] docker: install Quibble from latest patch not head [integration/config] - 10https://gerrit.wikimedia.org/r/455536 (owner: 10Hashar) [11:02:25] (03CR) 10Hashar: [C: 032] docker: install Quibble from latest patch not head [integration/config] - 10https://gerrit.wikimedia.org/r/455536 (owner: 10Hashar) [11:03:54] (03Merged) 10jenkins-bot: docker: install Quibble from latest patch not head [integration/config] - 10https://gerrit.wikimedia.org/r/455536 (owner: 10Hashar) [11:37:02] (03PS3) 10Hashar: ffmpeg is needed for recording videos of Selenium tests [integration/config] - 10https://gerrit.wikimedia.org/r/452703 (https://phabricator.wikimedia.org/T193157) (owner: 10Zfilipin) [11:42:36] (03PS4) 10Hashar: ffmpeg is needed for recording videos of Selenium tests [integration/config] - 10https://gerrit.wikimedia.org/r/452703 (https://phabricator.wikimedia.org/T193157) (owner: 10Zfilipin) [11:47:42] (03CR) 10Hashar: "Turns out to be simpler than expected, one of the parent container already has the apt configuration for jessie-backports." (031 comment) [integration/config] - 10https://gerrit.wikimedia.org/r/452703 (https://phabricator.wikimedia.org/T193157) (owner: 10Zfilipin) [12:15:33] (03CR) 10Hashar: [C: 032] "Lets give that a try..." [integration/config] - 10https://gerrit.wikimedia.org/r/452703 (https://phabricator.wikimedia.org/T193157) (owner: 10Zfilipin) [12:15:40] zeljkof: I think I got ffmpeg sorted out [12:15:51] that makes the container ~ 140 MBytes larger though :\ [12:15:57] hashar: uh oh [12:16:05] is ffmpeg that big? [12:16:16] it + its dependencies ;] [12:18:06] (03Merged) 10jenkins-bot: ffmpeg is needed for recording videos of Selenium tests [integration/config] - 10https://gerrit.wikimedia.org/r/452703 (https://phabricator.wikimedia.org/T193157) (owner: 10Zfilipin) [12:49:36] PROBLEM - Free space - all mounts on integration-slave-docker-1026 is CRITICAL: CRITICAL: integration.integration-slave-docker-1026.diskspace.root.byte_percentfree (<33.33%) [12:56:44] 10Release-Engineering-Team (Kanban), 10MediaWiki-Core-Tests, 10Quibble, 10Patch-For-Review, 10User-zeljkofilipin: Quibble does not install ffmpeg - https://phabricator.wikimedia.org/T193157 (10hashar) The CI containers now have `ffmpeg`. Versions are: * docker-registry.discovery.wmnet/releng/quibble-stre... [13:03:41] (03PS1) 10Hashar: Bump JJB jobs to latest Quibble containers [integration/config] - 10https://gerrit.wikimedia.org/r/455552 [13:03:52] (03CR) 10Hashar: [C: 032] Bump JJB jobs to latest Quibble containers [integration/config] - 10https://gerrit.wikimedia.org/r/455552 (owner: 10Hashar) [13:04:34] RECOVERY - Free space - all mounts on integration-slave-docker-1026 is OK: OK: All targets OK [13:05:48] (03Merged) 10jenkins-bot: Bump JJB jobs to latest Quibble containers [integration/config] - 10https://gerrit.wikimedia.org/r/455552 (owner: 10Hashar) [13:12:55] (03Abandoned) 10Hashar: operations-puppet-rake-jessie: fail build on junit error [integration/config] - 10https://gerrit.wikimedia.org/r/331861 (https://phabricator.wikimedia.org/T78342) (owner: 10Hashar) [13:13:32] (03Abandoned) 10Hashar: Validate integration/composer with the shipped version [integration/config] - 10https://gerrit.wikimedia.org/r/259243 (owner: 10Hashar) [13:19:37] hashar: can we install this? https://wiki.jenkins.io/display/JENKINS/Naginator+Plugin [13:19:56] you can make it auto retry builds that have output that matches a regex [13:20:12] so we canm make it auto retry composer, npm etc internet / connection issues [13:20:25] * addshore would love this [13:20:46] (03PS2) 10Hashar: License under Apache 2.0 [integration/quibble] - 10https://gerrit.wikimedia.org/r/426116 (https://phabricator.wikimedia.org/T192132) [13:21:20] if you think it is a good idea i can write a ticket [13:21:44] (03CR) 10Hashar: [C: 032] "I forgot about this change ... Here it is under Apache 2.0 and we can always change / dual license later on." [integration/quibble] - 10https://gerrit.wikimedia.org/r/426116 (https://phabricator.wikimedia.org/T192132) (owner: 10Hashar) [13:22:02] addshore: do fill a ticket :] That is a good thing for history purposes! [13:22:09] will do [13:22:25] addshore: I am 100% sure that will NOT work with Zuul though [13:22:28] (03Merged) 10jenkins-bot: License under Apache 2.0 [integration/quibble] - 10https://gerrit.wikimedia.org/r/426116 (https://phabricator.wikimedia.org/T192132) (owner: 10Hashar) [13:22:37] hashar: :( [13:22:46] what is broken? [13:23:01] (03CR) 10jenkins-bot: License under Apache 2.0 [integration/quibble] - 10https://gerrit.wikimedia.org/r/426116 (https://phabricator.wikimedia.org/T192132) (owner: 10Hashar) [13:25:23] !log Delete gerrit repo operations/debs/pkg-php/php-ast , was for php-ast 1.6 which is now in Debian | T174338 [13:25:33] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [13:25:34] T174338: Provide php-ast 0.1.5 or later as a Debian package for CI - https://phabricator.wikimedia.org/T174338 [13:31:50] (03Abandoned) 10Hashar: WIP for mediawiki/extensions testing [integration/config] - 10https://gerrit.wikimedia.org/r/369691 (owner: 10Hashar) [13:31:51] well, just anoying random failurs because composer fails to get a package are annoying [13:32:03] and then having to retry all 8 jobs, for example when you know you only actually need to re run one [13:32:15] hashar: ^^ [13:35:38] addshore: ahh yeah that is annoying (retriggering all jobs) ... [13:36:01] packagist.org failling somehow is definitely an issue [13:36:10] we had the same trouble with npmjs.org a few weeks ago [13:36:32] maybe we could add a cache / proxy in between [13:39:50] (03Abandoned) 10Hashar: parsoidsvc-hhvm-parsertests to Docker [integration/config] - 10https://gerrit.wikimedia.org/r/418984 (owner: 10Hashar) [13:44:28] (03PS3) 10Hashar: Use shallow clone for phplint jobs [integration/config] - 10https://gerrit.wikimedia.org/r/405722 (https://phabricator.wikimedia.org/T179963) [13:46:51] (03CR) 10Hashar: [C: 032] "I have completely forgot about this change :( Update jobs:" [integration/config] - 10https://gerrit.wikimedia.org/r/405722 (https://phabricator.wikimedia.org/T179963) (owner: 10Hashar) [13:47:38] !log updating phplint jobs to use shallow clone AND wipe the workspace | https://gerrit.wikimedia.org/r/#/c/integration/config/+/405722/ | T179963 [13:47:43] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [13:47:43] T179963: Workspaces for mwgate-php55lint / mwgate-php70lint are getting huge - https://phabricator.wikimedia.org/T179963 [13:47:44] you dont think the retry plugin would work then? would zuul already think the job failed and still report it as failed if jenkins retried it then? [13:47:55] do zuul plugins work? [13:48:08] addshore: if composer install / npm install are the issues, probably we can make quibble to retry after X seconds? [13:48:29] yeh we could do it within quibble! that could be a good plan! [13:48:39] infact, that's a great plan [13:48:57] and this way we only retry that specific bit [13:49:02] essentially id like to see the failure of jenkins jobs due to compoer package internet issues, packagist internet issues and npm internet issues fall to 0 [13:49:11] (03Merged) 10jenkins-bot: Use shallow clone for phplint jobs [integration/config] - 10https://gerrit.wikimedia.org/r/405722 (https://phabricator.wikimedia.org/T179963) (owner: 10Hashar) [13:49:14] +4 [13:49:16] :D [13:49:19] shall I file a ticket? [13:50:35] your bet ? :] [13:50:48] * addshore files a ticket [13:51:07] addshore: that is merely to get everyone more or less informed, and at least to have some kind of context for later [13:51:36] * hashar wants a logstash [13:52:33] xD [13:52:35] for? [13:53:43] CI logs :D [13:54:08] would be cool! [13:54:27] I did an experiment a year and a half ago with the Jenkins plugin [13:54:41] but it was way too slow (doing a connect/disconnect to elastic search on each line) [13:55:09] (03CR) 10Hashar: [C: 032] Xvfb does not need to listen on a unix socket [integration/quibble] - 10https://gerrit.wikimedia.org/r/455110 (https://phabricator.wikimedia.org/T202710) (owner: 10Hashar) [13:55:30] oh wow [13:56:01] e_too_many_things [13:56:04] (03Merged) 10jenkins-bot: Xvfb does not need to listen on a unix socket [integration/quibble] - 10https://gerrit.wikimedia.org/r/455110 (https://phabricator.wikimedia.org/T202710) (owner: 10Hashar) [13:56:35] (03CR) 10jenkins-bot: Xvfb does not need to listen on a unix socket [integration/quibble] - 10https://gerrit.wikimedia.org/r/455110 (https://phabricator.wikimedia.org/T202710) (owner: 10Hashar) [14:00:32] (03CR) 10Hashar: [C: 032] git-changed-in-head did not detect renames [integration/jenkins] - 10https://gerrit.wikimedia.org/r/423676 (owner: 10Hashar) [14:00:42] (03PS3) 10Hashar: git-changed-in-head did not detect renames [integration/jenkins] - 10https://gerrit.wikimedia.org/r/423676 [14:00:55] (03CR) 10Hashar: [C: 032] git-changed-in-head did not detect renames [integration/jenkins] - 10https://gerrit.wikimedia.org/r/423676 (owner: 10Hashar) [14:01:39] (03Merged) 10jenkins-bot: git-changed-in-head did not detect renames [integration/jenkins] - 10https://gerrit.wikimedia.org/r/423676 (owner: 10Hashar) [14:10:27] (03CR) 10Hashar: "Phan is now in a Docker container iirc :]" [integration/config] - 10https://gerrit.wikimedia.org/r/371097 (https://phabricator.wikimedia.org/T174339) (owner: 10Addshore) [14:12:43] 10Release-Engineering-Team, 10MediaWiki-extensions-WikimediaIncubator, 10Epic, 10I18n: Make creating a new Language project easier - https://phabricator.wikimedia.org/T165585 (10StevenJ81) Liuxinyu posted it, not me. But Wolverène posted it at the end of the discussion in Incubator (before my closing secti... [14:19:35] 10Continuous-Integration-Config, 10Tracking: Add CI to all Gerrit repositories - https://phabricator.wikimedia.org/T180317 (10hashar) [14:19:38] 10Continuous-Integration-Config, 10Release-Engineering-Team (Kanban), 10Dumps-Generation: Add CI to all operations/dumps/* repositories and archive obsolete ones - https://phabricator.wikimedia.org/T180328 (10hashar) 05Open>03declined Can be done later if there is any interest. [14:21:34] 10Continuous-Integration-Config, 10Tracking: Add CI to all Gerrit repositories - https://phabricator.wikimedia.org/T180317 (10hashar) [14:21:38] 10Continuous-Integration-Config, 10Operations, 10Traffic, 10Patch-For-Review: Add CI to all operations/software/varnish/* repositories and archive obsolete ones - https://phabricator.wikimedia.org/T180329 (10hashar) 05Open>03Resolved a:03ema CI has been configured by @ema via various tasks [14:23:06] (03Abandoned) 10Hashar: Skip php 5.5 for mediawiki wmf branches [integration/config] - 10https://gerrit.wikimedia.org/r/344642 (https://phabricator.wikimedia.org/T94149) (owner: 10Hashar) [14:26:17] (03PS1) 10Hashar: QA report: skip All-Avatars.git [integration/config] - 10https://gerrit.wikimedia.org/r/455570 [14:26:30] (03CR) 10Hashar: [C: 032] QA report: skip All-Avatars.git [integration/config] - 10https://gerrit.wikimedia.org/r/455570 (owner: 10Hashar) [14:28:04] (03Merged) 10jenkins-bot: QA report: skip All-Avatars.git [integration/config] - 10https://gerrit.wikimedia.org/r/455570 (owner: 10Hashar) [14:33:54] 10Continuous-Integration-Infrastructure (shipyard), 10Release-Engineering-Team, 10Quibble, 10Patch-For-Review: Xvfb causes _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created - https://phabricator.wikimedia.org/T202710 (10hashar) Will be in Quibble 0.0.22 [14:34:32] 10Continuous-Integration-Infrastructure (shipyard), 10Release-Engineering-Team (Kanban), 10Quibble, 10Patch-For-Review: Xvfb causes _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created - https://phabricator.wikimedia.org/T202710 (10hashar) a:03hashar [15:05:13] 10Release-Engineering-Team (Kanban), 10Scap, 10User-zeljkofilipin, 10Wikimedia-Incident: Perform scap canary checks after sync-wikiversions - https://phabricator.wikimedia.org/T198640 (10thcipriani) a:03thcipriani D1100 should fix this. I'll do followup work/testing and get a new scap version out sometim... [15:12:54] is phabricator still considered english-only, even after subproject changes from 2016? https://www.mediawiki.org/w/index.php?title=Topic:Snt9rp93nmo6y7jb&topic_showPostId=snuc76u8b9p25s72#flow-post-snuc76u8b9p25s72 [15:17:56] I've seen non-English tasks, but I don't know whether that is generally approved [15:25:48] from the discussion 3 years ago i understood that the main problem with non-english tasks is that it messes things up in global feed, after introducing subprojects in 2016 the separation should be quite straightforward [15:27:28] would it make sense to bring this topic up again and where exactly? or are there more arguments to consider? [15:58:12] 10Release-Engineering-Team (Kanban), 10Release, 10Train Deployments: 1.32.0-wmf.18 deployment blockers - https://phabricator.wikimedia.org/T191064 (10thcipriani) 05Open>03Resolved 1.32.0-wmf.18 is on all wikis. [16:02:59] PROBLEM - SSH on integration-slave-docker-1021 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [16:07:56] RECOVERY - SSH on integration-slave-docker-1021 is OK: SSH OK - OpenSSH_6.7p1 Debian-5+deb8u5 (protocol 2.0) [16:10:19] tramm, non-english tasks seem like a bad idea [16:10:29] it would be make it difficult to centrally administer everything [16:10:53] PROBLEM - Puppet errors on deployment-chromium01 is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [16:10:58] most projects would not want to accept non-english tasks [16:11:13] PROBLEM - Puppet errors on deployment-kafka-main-2 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [16:11:53] PROBLEM - Puppet errors on deployment-redis06 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [16:12:01] PROBLEM - Puppet errors on deployment-ms-be03 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [16:12:06] PROBLEM - Puppet errors on deployment-pdfrender02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:12:24] PROBLEM - Puppet errors on deployment-mathoid is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:12:24] PROBLEM - Puppet errors on deployment-cpjobqueue is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [16:12:24] PROBLEM - Puppet errors on deployment-maps03 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:12:32] PROBLEM - Puppet errors on deployment-sca02 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [16:12:36] PROBLEM - Puppet errors on deployment-certcentral02 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [16:12:48] PROBLEM - Puppet errors on deployment-db03 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:12:50] hmm [16:12:56] PROBLEM - Puppet errors on deployment-cache-text04 is CRITICAL: CRITICAL: 40.00% of data above the critical threshold [0.0] [16:13:07] PROBLEM - Puppet errors on deployment-parsoid09 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [16:13:11] I removed https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/336840/ to see if stuff would start breaking [16:13:11] PROBLEM - Puppet errors on deployment-ms-fe02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:13:15] PROBLEM - Puppet errors on deployment-urldownloader02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:13:21] PROBLEM - Puppet errors on deployment-deploy01 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:13:25] PROBLEM - Puppet errors on deployment-aqs03 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [16:13:27] PROBLEM - Puppet errors on deployment-snapshot01 is CRITICAL: CRITICAL: 22.22% of data above the critical threshold [0.0] [16:13:53] PROBLEM - Puppet errors on deployment-ms-be04 is CRITICAL: CRITICAL: 40.00% of data above the critical threshold [0.0] [16:13:59] PROBLEM - Puppet errors on deployment-deploy02 is CRITICAL: CRITICAL: 30.00% of data above the critical threshold [0.0] [16:13:59] PROBLEM - SSH on integration-slave-docker-1021 is CRITICAL: CRITICAL - Socket timeout after 10 seconds [16:14:10] PROBLEM - Puppet errors on deployment-imagescaler01 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [16:14:22] PROBLEM - Puppet errors on deployment-poolcounter04 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [16:14:24] PROBLEM - Puppet errors on deployment-sca04 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [16:14:24] PROBLEM - Puppet errors on deployment-restbase01 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [16:14:38] PROBLEM - Puppet errors on deployment-mediawiki-09 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [16:14:38] PROBLEM - Puppet errors on deployment-aqs01 is CRITICAL: CRITICAL: 50.00% of data above the critical threshold [0.0] [16:14:42] PROBLEM - Puppet errors on deployment-logstash2 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [16:14:43] this is weird though [16:14:48] PROBLEM - Puppet errors on deployment-jobrunner03 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [16:15:13] PROBLEM - Puppet errors on deployment-conf03 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [16:15:15] PROBLEM - Puppet errors on deployment-webperf11 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [16:15:17] PROBLEM - Puppet errors on deployment-memc05 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [16:15:21] PROBLEM - Puppet errors on deployment-ircd is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [16:15:23] PROBLEM - Puppet errors on deployment-memc06 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [16:15:33] PROBLEM - Puppet errors on deployment-mediawiki-07 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [16:16:00] PROBLEM - Puppet errors on deployment-kafka-jumbo-1 is CRITICAL: CRITICAL: 60.00% of data above the critical threshold [0.0] [16:16:34] PROBLEM - Puppet errors on deployment-etcd-01 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [16:16:42] PROBLEM - Puppet errors on deployment-webperf12 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [16:18:45] I wasn't expecting puppet to actually have problems [16:18:49] RECOVERY - SSH on integration-slave-docker-1021 is OK: SSH OK - OpenSSH_6.7p1 Debian-5+deb8u5 (protocol 2.0) [16:19:14] but it's strange [16:19:22] puppet appears to succeed everywhere [16:19:29] so why is shinken saying it's failing everywhere? [16:20:15] PROBLEM - Puppet errors on integration-slave-docker-1021 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [16:20:30] Krenair: you mean administer in technical sense as for running the server or moderating the content? [16:20:47] moderating the content [16:20:53] organising the content [16:20:56] * tramm is talking about non-technical subprojects of wikimedia local chapters [16:21:00] doing virtually anything with the content [16:21:39] isn't this responsibility of project owner and not a central administrator? [16:22:08] central administrators have to be able to moderate [16:22:19] and frequently organising stuff falls to them as well [16:22:27] or at least the wider community [16:23:27] RECOVERY - Puppet errors on deployment-snapshot01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:23:35] why do they have to be able to moderate something they don't know about? i can understand of filtering spam or some technical things, not the content [16:24:40] because no one else is able to perform moderation functions in phabricator [16:24:54] only they can delete other user's comments and disable users [16:26:34] RECOVERY - Puppet errors on deployment-etcd-01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:04] RECOVERY - Puppet errors on deployment-pdfrender02 is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:22] RECOVERY - Puppet errors on deployment-mathoid is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:24] RECOVERY - Puppet errors on deployment-maps03 is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:24] RECOVERY - Puppet errors on deployment-cpjobqueue is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:27] so if there were at least central administrator who understands swedish, wm-se could have subprojects in swedish? [16:27:31] RECOVERY - Puppet errors on deployment-sca02 is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:37] RECOVERY - Puppet errors on deployment-certcentral02 is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:47] RECOVERY - Puppet errors on deployment-db03 is OK: OK: Less than 1.00% above the threshold [0.0] [16:27:52] I'm not sure that's a good idea [16:27:55] RECOVERY - Puppet errors on deployment-cache-text04 is OK: OK: Less than 1.00% above the threshold [0.0] [16:28:09] RECOVERY - Puppet errors on deployment-parsoid09 is OK: OK: Less than 1.00% above the threshold [0.0] [16:28:09] RECOVERY - Puppet errors on deployment-ms-fe02 is OK: OK: Less than 1.00% above the threshold [0.0] [16:28:13] RECOVERY - Puppet errors on deployment-urldownloader02 is OK: OK: Less than 1.00% above the threshold [0.0] [16:28:21] RECOVERY - Puppet errors on deployment-deploy01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:28:25] RECOVERY - Puppet errors on deployment-aqs03 is OK: OK: Less than 1.00% above the threshold [0.0] [16:28:38] maybe there are some ways to at least come close to that situation, especially if that's the only problem with non-english subprojects? [16:28:52] RECOVERY - Puppet errors on deployment-ms-be04 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:00] RECOVERY - Puppet errors on deployment-deploy02 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:08] RECOVERY - Puppet errors on deployment-imagescaler01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:20] RECOVERY - Puppet errors on deployment-poolcounter04 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:24] RECOVERY - Puppet errors on deployment-sca04 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:26] RECOVERY - Puppet errors on deployment-restbase01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:36] RECOVERY - Puppet errors on deployment-mediawiki-09 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:38] RECOVERY - Puppet errors on deployment-aqs01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:42] RECOVERY - Puppet errors on deployment-logstash2 is OK: OK: Less than 1.00% above the threshold [0.0] [16:29:48] RECOVERY - Puppet errors on deployment-jobrunner03 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:11] RECOVERY - Puppet errors on deployment-webperf11 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:13] RECOVERY - Puppet errors on deployment-conf03 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:17] RECOVERY - Puppet errors on deployment-memc05 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:19] admins come and go [16:30:22] by the way, blocking users with wikimedia account can be done outside phabricator anyway [16:30:23] RECOVERY - Puppet errors on deployment-ircd is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:24] RECOVERY - Puppet errors on deployment-memc06 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:34] RECOVERY - Puppet errors on deployment-mediawiki-07 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:36] yes and it leaves their phabricator access working [16:30:51] this seems really easy to fix, no? [16:30:53] RECOVERY - Puppet errors on deployment-chromium01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:30:59] RECOVERY - Puppet errors on deployment-kafka-jumbo-1 is OK: OK: Less than 1.00% above the threshold [0.0] [16:31:11] no [16:31:27] RECOVERY - Puppet errors on deployment-kafka-main-2 is OK: OK: Less than 1.00% above the threshold [0.0] [16:31:46] RECOVERY - Puppet errors on deployment-webperf12 is OK: OK: Less than 1.00% above the threshold [0.0] [16:31:56] RECOVERY - Puppet errors on deployment-redis06 is OK: OK: Less than 1.00% above the threshold [0.0] [16:31:58] RECOVERY - Puppet errors on deployment-ms-be03 is OK: OK: Less than 1.00% above the threshold [0.0] [16:32:04] so there is a reason why wikimedia accounts need to remain functioning after they have been blocked in global wikimedia system? [16:34:47] not all phabricator accounts are tied to SUL [16:34:57] some are tied to LDAP [16:35:06] which I don't think even has such a concept [16:35:24] what do you do if an account is tied to both? [16:36:04] how do you clean up existing phab sessions when someone's SUL account is disabled? [16:36:45] if CentralAuth gets broken to the point where it thinks everyone is disabled, phabricator also gets broken [16:38:24] i don't know the details about how phabricator manages sessions, but i can think of technical solutions, that are not too exhaustive [16:38:59] are there lots of ldap accounts and are they random users or from some time span or affiliated with something? [16:39:14] I would expect there are quite a few [16:39:29] pretty sure I've normally signed in via LDAP [16:39:40] you can sign up with either [16:39:50] add the other one later [16:40:33] I think SUL integration was done so most non-technical users wouldn't need to make themselves a wikitech/LDAP account etc. [16:40:42] * tramm notiecs that phabricator, especially for wm chapter instances are not very prone to trolling and exploiting, more like hard to find even for chapter members [16:41:22] for example wm-se doesn't seem to have too many users and traffic [16:42:21] so maybe trying to find perfect system for that occasion doesn't make sense and we don't need to be as fool proof from administration point of view as wikipedia itself [16:43:31] very small scale problems can be solved when they appear [16:43:45] it might be worth discussing at least [16:44:50] Krenair: what about content moderation part, not blocking users but deleting or editing task descriptions and comments? [16:45:08] well, what about it? [16:45:21] editing task descriptions can be done by anyone [16:45:33] deleting other people's comments cannot [16:46:13] only site-wide admins can do that and no other way out of it? [16:46:25] well who else would you let do it? [16:46:58] it would be quite natural if project owner had such rights [16:47:11] um [16:47:19] anyone can edit the list of projects [16:47:40] I can go up to a random task, add some project where I'm an owner, and boom I can admin everything there? [16:47:50] that's a security vulnerability [16:48:38] which is currently there, right? :-) [16:50:20] no [16:50:44] the projects list of a task does not have any ACL implications [16:53:29] you are not talking about some technical exploit with recursivity or creating millions of empty projects? otherwise i cannot get what security vulnerability you could mean [16:54:19] but anyway, closing task with special message is as good as moderating, isn't it? [16:54:48] no [16:55:03] if people can handle wiki talk pages, they can handle phabricator tasks too, isn't it? [16:55:16] RECOVERY - Puppet errors on integration-slave-docker-1021 is OK: OK: Less than 1.00% above the threshold [0.0] [16:56:24] i mean you can moderate and fix content to some reasonable level without being central admin [16:58:09] i certainly agree that extreme cases can be solved only by admin, but there are means for basic moderating for non-admins too [17:03:13] (03Abandoned) 10Hashar: Change environment when running Selenium tests [integration/quibble] - 10https://gerrit.wikimedia.org/r/446701 (https://phabricator.wikimedia.org/T198201) (owner: 10Hashar) [17:08:18] Krenair: anything else besides blocking malicious users and moderating comments you consider important for allowing non-english content? [17:09:16] well so [17:09:28] sometimes people think it's okay to create a task and not put any tags on it [17:09:36] i.e. no projects at all [17:10:13] it might make things tricky to start categorising into the right projects if people do it in languages that aren't normally used around phabricator [17:11:06] and it might be a problem if someone (the creator or someone reviewing a no-projects ticket) decides that the right project(s) include one or more that are not capable of dealing with non-english tickets [17:12:54] what usually happens to tasks without tags? if you cannot find out the right project you delete then at some point? [17:13:57] Well if it were up to me we simply would not permit them. [17:14:10] it's not up to me of course [17:14:15] would be my intuition too [17:14:24] so what happens instead is they sit there [17:14:44] and someone comes along and tries to find a relevant project [17:16:49] well, if you can detect language, then it could be sent to relevant chapter subproject for review [17:17:13] if there are half a dozen of languages, this might work, but if more, it gets complicated [17:17:27] (03CR) 10Hashar: [C: 032] "I will make them relative to workspace while in docker. But as is indeed, that is in /log whenever using a Docker container :]" [integration/quibble] - 10https://gerrit.wikimedia.org/r/451294 (owner: 10Tarrow) [17:18:25] (03Merged) 10jenkins-bot: Update Quibble Docker README log directory [integration/quibble] - 10https://gerrit.wikimedia.org/r/451294 (owner: 10Tarrow) [17:18:58] (03CR) 10jenkins-bot: Update Quibble Docker README log directory [integration/quibble] - 10https://gerrit.wikimedia.org/r/451294 (owner: 10Tarrow) [17:19:16] tramm, okay but what happens when someone starts filing technical bugs in non-english languages? [17:19:30] do you mean the chapter would provide a translation? [17:19:42] no [17:19:51] this cannot be encouraged [17:20:23] zeljkof: Hi, I heard you were looking for me re. the July 17th incident? [17:22:06] Krenair: if chapter projects are clearly separated and ui is in english, this won't happen much? especially when we think that only experienced chapter members usually find their way to phabricator anyway [17:22:36] re UI: I don't know where they are with translations for that [17:22:44] I think people were talking about it but I don't know what happened [17:23:43] awight: hello, yeah we could use some feedback following the train report. Our main doc is https://wikitech.wikimedia.org/wiki/Incident_documentation/20180717-Train [17:23:57] T199504 Editing of content model other than wikitext fails [17:23:57] T199504: Editing of content model other than wikitext fails - https://phabricator.wikimedia.org/T199504 [17:23:58] Not done Feedback needed from Adam Wight (Scoring Platform), Daniel Kinzler (Wikimedia Deutschland). [17:23:58] Daniel Kinzler reverted a bad patch by Adam Wight, in gerrit:445658. This is resolved now. [17:24:15] Krenair: if i want to bring this whole topic up again, where should i do it? [17:24:17] awight: so I guess it is about providing a little feedback on that task :) [17:24:25] hasharAway: I provided the feedback in that second line, so not sure what more to say... [17:24:44] * tramm will ask wm-se about their experience before doing it anyway [17:24:48] ah, on the task? I can do that if that's all that's left. [17:25:11] awight: yeah maybe it is better to copy paste on the task :] Though I am not sure what zeljko is expeting exactly [17:25:21] I guess "a patch got reverted" is good enough [17:26:03] Thanks for the note, I'll explain a bit more in the task, then. [17:27:39] tramm, well I would say wikitech-l though obviously you want this for non-technical tasks which may complicate things [17:27:52] you could create a task under #phabricator as a sort of request for comments [17:28:36] talk to people and see what they think. it's not like there's explicit rules against it, I just think we'd need to think the whole thing through before encouraging other languages there [17:28:45] awight: thank you! :] [17:30:38] PROBLEM - Free space - all mounts on integration-slave-docker-1026 is CRITICAL: CRITICAL: integration.integration-slave-docker-1026.diskspace.root.byte_percentfree (<11.11%) [17:35:15] hasharAway: It's helpful to be nudged--in hindsight, this error should have been caught by unit tests, so it's definitely worthwhile to document. [17:36:33] awight: then if there is no unit tests, there is nothing to catch :] [17:36:48] awight: but yeah I guess the idea of the feedback is to identify area of improvements [17:36:51] anyway dinner for real [17:38:00] Krenair: thanks for your comments, i have much better idea of the situation now! [17:39:33] no worries, good luck [17:40:38] RECOVERY - Free space - all mounts on integration-slave-docker-1026 is OK: OK: All targets OK [18:04:00] PROBLEM - Free space - all mounts on integration-slave-docker-1001 is CRITICAL: CRITICAL: integration.integration-slave-docker-1001.diskspace.root.byte_percentfree (<30.00%) [18:22:29] 10Release-Engineering-Team (Kanban), 10Release, 10Train Deployments: 1.32.0-wmf.18 deployment blockers - https://phabricator.wikimedia.org/T191064 (10thcipriani) Wrote a preliminary incident report for this train: https://wikitech.wikimedia.org/wiki/Incident_documentation/20180821-Train [18:24:01] RECOVERY - Free space - all mounts on integration-slave-docker-1001 is OK: OK: All targets OK [18:24:48] awight: sorry, on the phone, can you please email me? So I don't forget [18:30:06] zeljkof: sure thing [18:30:50] Hi! I'm looking to deploy an extension on testwiki and I have these four patches up: https://gerrit.wikimedia.org/r/#/q/%22Add+TemplateWizard+extension%22+status:open [18:31:02] Can someone give them a quick look and see if they look okay? [18:31:09] James_F: If you got a moment.^ [18:31:23] Hey. [18:33:42] Niharika: Yeah, that looks fine. It should go live on a BC wiki too ideally (and you need the mediawiki/tools/release patch to https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/tools/release/+/master/make-wmf-branch/config.json ). [18:36:44] 10MediaWiki-Codesniffer: PHPCS should make sure @covers tags are absolute - https://phabricator.wikimedia.org/T183218 (10Umherirrender) mostly? It seems it is covered fully by the trait. Or is there some part still open? [18:41:36] PROBLEM - Free space - all mounts on integration-slave-docker-1026 is CRITICAL: CRITICAL: integration.integration-slave-docker-1026.diskspace.root.byte_percentfree (<22.22%) [18:42:28] (03CR) 10Thcipriani: [C: 032] "deployed" [integration/config] - 10https://gerrit.wikimedia.org/r/454306 (https://phabricator.wikimedia.org/T201224) (owner: 10Thcipriani) [18:42:48] (03CR) 10Thcipriani: [C: 032] "deployed" [integration/config] - 10https://gerrit.wikimedia.org/r/454436 (https://phabricator.wikimedia.org/T201224) (owner: 10Thcipriani) [18:43:00] (03PS1) 10Niharika29: Add TemplateWizard extension [tools/release] - 10https://gerrit.wikimedia.org/r/455617 [18:43:40] (03CR) 10Jforrester: [C: 032] Add TemplateWizard extension [tools/release] - 10https://gerrit.wikimedia.org/r/455617 (owner: 10Niharika29) [18:44:22] Woo, thanks James_F. [18:45:10] (03Merged) 10jenkins-bot: Notify if node disconnected due to disk space [integration/config] - 10https://gerrit.wikimedia.org/r/454306 (https://phabricator.wikimedia.org/T201224) (owner: 10Thcipriani) [18:45:12] (03Merged) 10jenkins-bot: Take node offline if / is full [integration/config] - 10https://gerrit.wikimedia.org/r/454436 (https://phabricator.wikimedia.org/T201224) (owner: 10Thcipriani) [18:45:23] (03Merged) 10jenkins-bot: Add TemplateWizard extension [tools/release] - 10https://gerrit.wikimedia.org/r/455617 (owner: 10Niharika29) [18:49:44] !log ores:0e8cc73 is going to beta cluster [18:49:46] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [18:51:01] PROBLEM - Free space - all mounts on integration-slave-docker-1025 is CRITICAL: CRITICAL: integration.integration-slave-docker-1025.diskspace.root.byte_percentfree (<22.22%) [18:53:34] 10Release-Engineering-Team (Kanban), 10Patch-For-Review, 10Release Pipeline (Blubber): Move path for blubber.yaml to ./.pipeline/blubber.yaml for all blubber jobs - https://phabricator.wikimedia.org/T202068 (10thcipriani) 05Open>03Resolved Moved path in Jenkins pipeline [18:56:39] Hello again. Can someone help deploy a new extension to prod? My team's usual extension deployer (MaxSem) is out for a few weeks. [18:56:57] I have the patches but I'm not very confident on the ordering of the patches. [19:05:33] Niharika: I can help. Do you have a window? [19:06:36] RECOVERY - Free space - all mounts on integration-slave-docker-1026 is OK: OK: All targets OK [19:11:03] RECOVERY - Free space - all mounts on integration-slave-docker-1025 is OK: OK: All targets OK [19:12:16] 10MediaWiki-Codesniffer: Add sniff to remove semicolon after class declaration - https://phabricator.wikimedia.org/T202922 (10Umherirrender) [19:21:09] James_F: Whoops, missed your message. The calendar is chock full today. I'm hoping to steal half the Security window (it's two hours long) if Reedy doesn't want it. [19:21:24] That's RelEng's call. :-) [19:21:42] Ain't it Security team's call? [19:22:09] It's their call to not use their window. It's not theirs to have you do stuff with it instead. [19:22:37] PROBLEM - Free space - all mounts on integration-slave-docker-1026 is CRITICAL: CRITICAL: integration.integration-slave-docker-1026.diskspace.root.byte_percentfree (<11.11%) [19:22:49] Oh sure. They can shorten the window on the calendar and I can claim it. :P I'll schedule something for tomorrow if that plan fails. [19:28:36] (03PS1) 10Umherirrender: Enable PSR2.Classes.ClassDeclaration [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/455626 [19:29:22] (03CR) 10jerkins-bot: [V: 04-1] Enable PSR2.Classes.ClassDeclaration [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/455626 (owner: 10Umherirrender) [19:30:11] (03CR) 10Umherirrender: "Found the sniff by searching for a fix of the comma in "implements" for T168970" [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/455626 (owner: 10Umherirrender) [19:34:19] (03PS1) 10Ladsgroup: Enable LFS for research/ores/wheels [All-Projects] (refs/meta/config) - 10https://gerrit.wikimedia.org/r/455629 (https://phabricator.wikimedia.org/T197096) [19:36:09] composer install seems to be failing a ton more than normal today [19:36:31] I wonder if something is wrong with our extra caching stuff [19:42:14] (03CR) 10Legoktm: [C: 032] Add myself (stjn) to the CI whitelist [integration/config] - 10https://gerrit.wikimedia.org/r/446185 (owner: 10Saint Johann) [19:42:24] (03CR) 10Legoktm: [C: 032] Add MR70 to CI whitelist [integration/config] - 10https://gerrit.wikimedia.org/r/455226 (owner: 10Gergő Tisza) [19:43:02] (03CR) 10Umherirrender: "recheck" [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/455626 (owner: 10Umherirrender) [19:43:13] Niharika: which extension/where's the task for context? [19:43:47] (03Merged) 10jenkins-bot: Add myself (stjn) to the CI whitelist [integration/config] - 10https://gerrit.wikimedia.org/r/446185 (owner: 10Saint Johann) [19:43:56] (03Merged) 10jenkins-bot: Add MR70 to CI whitelist [integration/config] - 10https://gerrit.wikimedia.org/r/455226 (owner: 10Gergő Tisza) [19:44:27] (03CR) 10Legoktm: [C: 032] "Confirmed no-op by jenkins." [integration/config] - 10https://gerrit.wikimedia.org/r/455203 (https://phabricator.wikimedia.org/T188742) (owner: 10Hashar) [19:45:04] !log deployed https://gerrit.wikimedia.org/r/446185 https://gerrit.wikimedia.org/r/455226 [19:45:07] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [19:47:05] greg-g: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/TemplateWizard [19:47:05] and https://phabricator.wikimedia.org/T202545 [19:48:49] (03Merged) 10jenkins-bot: jjb: simplify selenium definitions [integration/config] - 10https://gerrit.wikimedia.org/r/455203 (https://phabricator.wikimedia.org/T188742) (owner: 10Hashar) [20:09:27] Niharika: first you deploy to beta cluster for at least a week then production [20:09:50] greg-g: Yeah well there's no instructions on deploying to beta. [20:09:57] https://www.mediawiki.org/wiki/Review_queue#Preparing_for_deployment [20:10:08] then 2 sections down [20:10:15] greg-g: Very outdated incorrect instructions. [20:10:37] greg-g: `extension-list-labs` no longer exists. [20:10:41] Niharika: tyler will be updating them this week [20:10:53] but regardless, it needs to be on beta for at least a week before production [20:11:16] Sure. I'd love to do that if only it's clear how. :) [20:12:30] fair, let's clear that up and then proceed with the normal process [20:13:04] AFAIUI from the commit I pointed out last week it seems that the plugin should be added to extension-list (i.e., the same one as production) and then leave it unconfigured for production, that is: only configure it for use in beta [20:13:29] Another thing is it asks to add config to -labs config files which actually don't have that anymore. [20:13:47] The -labs files don't do wfLoadExtension() for any extension now. [20:14:01] I'm not sure where to configure the extension. [20:14:53] `CommonSettings-labs` specifically. [20:16:53] it seems like the new pattern may be to use the $wmfUse[extension]-type variables [20:18:16] thcipriani: I don't have any variables to configure, I only want to load the extension. Like https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/CommonSettings.php#L511 [20:18:44] That no longer happens in the -labs file for reasons I don't understand and aren't documented anywhere. [20:19:31] Niharika: Then you just need to add it to InitialiseSettings-labs.php. [20:19:46] I think (and I'm just trying to dig through commits so I could be wrong) that you do exactly that, have the wmgUsePagedTiffHandler in CommonSettings.php and then set it in both IS.php and IS-labs.php [20:19:58] Yup. [20:20:02] but in IS-labs.php you set it to true and in IS.php set to false [20:20:05] We consolidated this (finally). [20:20:10] James_F: The `$wgUse...` variable? Where do I *use* it? [20:20:20] Niharika: CommonSettings.php. [20:20:45] James_F: Ah, okay so CS-labs not needed. [20:20:56] Yup. [20:21:05] In general, CS-labs shouldn't be touched much. [20:21:39] And do I still need https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/455614/ if I am deploying to beta? [20:26:05] James_F: thcipriani ^ [20:26:28] It'll do it automatically for you, I think. [20:26:37] As long as it exists in mediawiki/extensions.git. [20:26:41] * James_F looks. [20:26:55] Yeah, it [20:26:57] Bah. [20:27:03] Yeah, it's in mediawiki/extensions.git. [20:27:22] Okay, great. Thanks much! [20:32:14] Project beta-scap-eqiad build #220418: 04FAILURE in 45 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220418/ [20:34:04] Project beta-scap-eqiad build #220419: 04STILL FAILING in 11 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220419/ [20:44:07] Project beta-scap-eqiad build #220420: 04STILL FAILING in 18 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220420/ [20:51:41] Project beta-scap-eqiad build #220421: 04STILL FAILING in 11 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220421/ [20:54:06] Project beta-scap-eqiad build #220422: 04STILL FAILING in 12 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220422/ [20:59:59] ^^ i have no clue :/ [21:04:04] Project beta-scap-eqiad build #220423: 04STILL FAILING in 12 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220423/ [21:10:36] * thcipriani looks [21:20:11] should be fixed [21:30:22] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Kanban), 10Patch-For-Review, 10Wikimedia-log-errors (Shared Build Failure): Workspaces for mwgate-php55lint / mwgate-php70lint are getting huge - https://phabricator.wikimedia.org/T179963 (10hashar) 05Open>03Resolved a:03hashar Shou... [21:44:54] Yippee, build fixed! [21:44:55] Project beta-scap-eqiad build #220424: 09FIXED in 31 min: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/220424/ [22:10:13] 10MediaWiki-Codesniffer: PHPCS should make sure @covers tags are absolute - https://phabricator.wikimedia.org/T183218 (10Legoktm) I think I might have been referring to the fact that not all tests use the trait? I'm not sure to be honest. I'm OK marking this as resolved. [22:16:53] (03PS4) 10Legoktm: Detect nesting of inline ternary statements without parentheses [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/449149 (https://phabricator.wikimedia.org/T171520) (owner: 10PleaseStand) [22:17:55] (03CR) 10jerkins-bot: [V: 04-1] Detect nesting of inline ternary statements without parentheses [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/449149 (https://phabricator.wikimedia.org/T171520) (owner: 10PleaseStand) [22:28:04] (03PS5) 10Legoktm: Detect nesting of inline ternary statements without parentheses [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/449149 (https://phabricator.wikimedia.org/T171520) (owner: 10PleaseStand) [22:29:31] (03CR) 10jerkins-bot: [V: 04-1] Detect nesting of inline ternary statements without parentheses [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/449149 (https://phabricator.wikimedia.org/T171520) (owner: 10PleaseStand) [22:31:06] (03PS6) 10Legoktm: Detect nesting of inline ternary statements without parentheses [tools/codesniffer] - 10https://gerrit.wikimedia.org/r/449149 (https://phabricator.wikimedia.org/T171520) (owner: 10PleaseStand) [22:57:56] 10Release-Engineering-Team (Watching / External), 10Core-Platform-Team, 10PoolCounter, 10Patch-For-Review: Fix tests of PoolCounter extension - https://phabricator.wikimedia.org/T178517 (10Legoktm) a:03Legoktm