[00:14:53] 10Continuous-Integration-Config, 10MediaWiki-Core-Tests, 10Accessibility: Consider using pa11y as automated accessibility integration test - https://phabricator.wikimedia.org/T170096#3419228 (10Krinkle) [00:16:58] Yippee, build fixed! [00:16:59] Project selenium-Flow » chrome,beta,Linux,BrowserTests build #447: 09FIXED in 57 sec: https://integration.wikimedia.org/ci/job/selenium-Flow/BROWSER=chrome,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=Linux,label=BrowserTests/447/ [00:40:45] 10Release-Engineering-Team (Kanban), 10releng-201617-q4, 10MediaWiki-General-or-Unknown, 10MW-1.29-release, 10Release: Release MediaWiki 1.29 - https://phabricator.wikimedia.org/T153271#3419246 (10demon) Assuming no issues come up in rc.1 I plan to issue the final release within a week. [03:32:02] The error rate limits on scap may be a bit low. l10nupdate was blocked by these random lua errors -- https://logstash.wikimedia.org/goto/3888cca979647b9381a7739b0bdbc88e [03:35:36] Project beta-scap-eqiad build #163344: 04FAILURE in 1 min 55 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/163344/ [03:45:51] Yippee, build fixed! [03:45:51] Project beta-scap-eqiad build #163345: 09FIXED in 2 min 13 sec: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/163345/ [04:18:28] Project selenium-MultimediaViewer » firefox,beta,Linux,BrowserTests build #448: 04FAILURE in 22 min: https://integration.wikimedia.org/ci/job/selenium-MultimediaViewer/BROWSER=firefox,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=Linux,label=BrowserTests/448/ [05:55:39] Project selenium-Wikibase » chrome,test,Linux,BrowserTests build #417: 04FAILURE in 1 hr 15 min: https://integration.wikimedia.org/ci/job/selenium-Wikibase/BROWSER=chrome,MEDIAWIKI_ENVIRONMENT=test,PLATFORM=Linux,label=BrowserTests/417/ [06:16:32] PROBLEM - Puppet errors on deployment-pdfrender02 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [06:19:46] 10Deployment-Systems, 10Release-Engineering-Team (Next), 10Operations, 10Performance-Team, 10HHVM: Translation cache exhaustion caused by changes to PHP code in file scope - https://phabricator.wikimedia.org/T103886#3419367 (10Joe) @Krinkle sure, we can enable reusing TC in beta for now and test if the f... [06:29:13] PROBLEM - Free space - all mounts on deployment-fluorine02 is CRITICAL: CRITICAL: deployment-prep.deployment-fluorine02.diskspace._srv.byte_percentfree (<11.11%) [06:49:11] RECOVERY - Free space - all mounts on deployment-fluorine02 is OK: OK: All targets OK [06:56:02] PROBLEM - Puppet errors on integration-slave-jessie-1002 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [06:56:32] RECOVERY - Puppet errors on deployment-pdfrender02 is OK: OK: Less than 1.00% above the threshold [0.0] [07:09:26] PROBLEM - Puppet staleness on deployment-eventlogging03 is CRITICAL: CRITICAL: 40.00% of data above the critical threshold [43200.0] [07:31:05] RECOVERY - Puppet errors on integration-slave-jessie-1002 is OK: OK: Less than 1.00% above the threshold [0.0] [08:06:53] 10Browser-Tests-Infrastructure, 10Release-Engineering-Team (Watching / External), 10Wikipedia-Android-App-Backlog, 10Wikipedia-iOS-App-Backlog, 10Ruby: Create end-to-end automated test for Wikipedia native app(s) - https://phabricator.wikimedia.org/T90177#3419540 (10Aklapper) a:05BGerstle-WMF>03None... [11:19:48] 10Browser-Tests-Infrastructure, 10Continuous-Integration-Infrastructure, 10User-zeljkofilipin: Upgrade to Chromium 59 or newer on Debian Jessie in CI - https://phabricator.wikimedia.org/T170032#3417522 (10zeljkofilipin) p:05Triage>03Normal [11:25:22] PROBLEM - Puppet staleness on deployment-kafka01 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [43200.0] [12:17:33] PROBLEM - Puppet errors on deployment-pdfrender02 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [12:52:33] RECOVERY - Puppet errors on deployment-pdfrender02 is OK: OK: Less than 1.00% above the threshold [0.0] [13:31:55] RECOVERY - Long lived cherry-picks on puppetmaster on deployment-puppetmaster02 is OK: OK: Less than 100.00% above the threshold [0.0] [13:46:38] Yippee, build fixed! [13:46:38] Project selenium-VisualEditor » firefox,beta,Linux,BrowserTests build #455: 09FIXED in 2 min 37 sec: https://integration.wikimedia.org/ci/job/selenium-VisualEditor/BROWSER=firefox,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=Linux,label=BrowserTests/455/ [14:23:27] PROBLEM - Puppet errors on deployment-puppetmaster02 is CRITICAL: CRITICAL: 20.00% of data above the critical threshold [0.0] [14:43:52] 10Beta-Cluster-Infrastructure, 10Operations, 10Performance-Team, 10Thumbor, 10Patch-For-Review: Beta thumbnails are broken - https://phabricator.wikimedia.org/T169114#3420891 (10Gilles) I've added the Beta poolcounter to deployment-imagescaler01's config in horizon. Seems to work fine! [15:04:49] 10Continuous-Integration-Infrastructure: Use phpcs.xml of core in mediawiki-core-phpcs-jessie - https://phabricator.wikimedia.org/T170159#3421026 (10Umherirrender) [15:23:03] CI folks: I'm about to add some new hosts to the labvirt pool — since they're empty, nodepool VMs will stampede over to the new hosts more-or-less immediately. Let me know if you see any interesting effects. [15:31:32] 10Release-Engineering-Team (Kanban), 10Release, 10Train Deployments: MW-1.30.0-wmf.9 deployment blockers - https://phabricator.wikimedia.org/T167893#3421207 (10thcipriani) a:03thcipriani [15:33:06] PROBLEM - Puppet errors on integration-slave-docker-1000 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [15:35:13] PROBLEM - Puppet errors on deployment-aqs01 is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [15:46:45] 10Scap: Add support for ssh in as one user but creating files as another file in scap - https://phabricator.wikimedia.org/T170163#3421277 (10Paladox) [15:54:30] Project selenium-MobileFrontend » chrome,beta,Linux,BrowserTests build #484: 04FAILURE in 32 min: https://integration.wikimedia.org/ci/job/selenium-MobileFrontend/BROWSER=chrome,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=Linux,label=BrowserTests/484/ [16:10:12] RECOVERY - Puppet errors on deployment-aqs01 is OK: OK: Less than 1.00% above the threshold [0.0] [16:13:11] PROBLEM - Puppet errors on deployment-ms-be03 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [16:20:33] PROBLEM - Puppet errors on deployment-ms-be04 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [16:23:14] 10Deployment-Systems, 10Release-Engineering-Team (Watching / External), 10Operations, 10Performance-Team, and 2 others: Translation cache exhaustion caused by changes to PHP code in file scope - https://phabricator.wikimedia.org/T103886#3421453 (10greg) [16:39:45] RainbowSprinkles i've been testing furthur changes to gerrit with scap. And have managed to put it behind a switch locally (testing how to do it). i think we should symblink review_site in /srv/deployment/gerrit/gerrit to /srv/gerrit/review_site [16:40:19] the switch did not break /var/lib/gerrit2 :) [16:45:57] I don't want to move it really [16:46:02] It's a bigger pain than it's worth [16:46:39] ah ok [16:46:50] that will make this really easy then :) [16:48:24] i can make it full scap then heh [16:54:57] its ready RainbowSprinkles :). Very simple to implement as most of the code is for /var/lib/gerrit2 :) [16:58:09] 10Release-Engineering-Team (Kanban), 10Cloud-Services, 10Phabricator, 10wikitech.wikimedia.org, and 2 others: Blocking an account on wikitech should disable LDAP logins - https://phabricator.wikimedia.org/T168692#3421582 (10mmodell) p:05Normal>03Low [16:58:49] 10Release-Engineering-Team (Backlog), 10Cloud-Services, 10Phabricator, 10wikitech.wikimedia.org, and 2 others: Blocking an account on wikitech should disable LDAP logins - https://phabricator.wikimedia.org/T168692#3421583 (10greg) p:05Low>03Lowest [17:07:17] 10Continuous-Integration-Config, 10Release-Engineering-Team, 10Wikipedia-Android-App-Backlog, 10Spike, 10Technical-Debt: Investigate how to improve Android CI performance and stability - https://phabricator.wikimedia.org/T158014#3421615 (10Mholloway) These days the `apps-android-wikipedia-periodic-test`... [17:07:57] 10Release-Engineering-Team (Kanban), 10Wikimedia-Site-requests: Please close the Asturianu Wikiquote - https://phabricator.wikimedia.org/T30964#3421618 (10MarcoAurelio) a:03demon [17:13:19] 10Continuous-Integration-Config, 10Release-Engineering-Team, 10Wikipedia-Android-App-Backlog, 10Spike, 10Technical-Debt: Investigate how to improve Android CI performance and stability - https://phabricator.wikimedia.org/T158014#3421649 (10greg) Cool, thanks for the quick update @Mholloway ! Then can I... [17:16:44] 10Continuous-Integration-Config, 10Release-Engineering-Team, 10Wikipedia-Android-App-Backlog, 10Spike, 10Technical-Debt: Investigate how to improve Android CI performance and stability - https://phabricator.wikimedia.org/T158014#3421667 (10Mholloway) Seems closable to me. @Niedzielski? [17:40:38] 10Release-Engineering-Team (Backlog), 10Cloud-Services, 10Phabricator, 10wikitech.wikimedia.org, and 2 others: Blocking an account on wikitech should disable LDAP logins - https://phabricator.wikimedia.org/T168692#3421835 (10MarcoAurelio) So instead of disabling an account here, a block on Wikitech will ha... [17:41:33] 10Continuous-Integration-Infrastructure, 10Release-Engineering-Team (Kanban), 10Operations, 10Patch-For-Review: CI for operations/puppet is taking too long - https://phabricator.wikimedia.org/T166888#3421841 (10greg) RelEng plans to work on the Docker Jenkins job until completion in the short term. This in... [17:43:06] 10Release-Engineering-Team (Backlog), 10Cloud-Services, 10Phabricator, 10wikitech.wikimedia.org, and 2 others: Blocking an account on wikitech should disable LDAP logins - https://phabricator.wikimedia.org/T168692#3373658 (10Luke081515) Phabricator OAuth is based on blocked at mediawiki.prg isn't it? [17:55:46] 10Continuous-Integration-Config, 10Release-Engineering-Team, 10Wikipedia-Android-App-Backlog, 10Spike, 10Technical-Debt: Investigate how to improve Android CI performance and stability - https://phabricator.wikimedia.org/T158014#3421910 (10Niedzielski) 05Open>03declined {icon thumbs-up} [18:01:35] 10Release-Engineering-Team (Backlog), 10Cloud-Services, 10Phabricator, 10wikitech.wikimedia.org, and 2 others: Blocking an account on wikitech should disable LDAP logins - https://phabricator.wikimedia.org/T168692#3421928 (10demon) >>! In T168692#3421835, @MarcoAurelio wrote: > So instead of disabling an a... [18:13:41] could someone check this phan complaint: https://integration.wikimedia.org/ci/job/mwext-php70-phan-jessie/2663/console - looks like false positive [18:14:00] ah wait maybe not [18:15:02] hmm it seems to ignore use statements or something... claims the class is not there though it is [18:17:05] and the class name is wrong ("use" is being ignored by phan) [18:24:14] 10Release-Engineering-Team (Backlog), 10Cloud-Services, 10Phabricator, 10wikitech.wikimedia.org, and 2 others: Blocking an account on wikitech should disable LDAP logins - https://phabricator.wikimedia.org/T168692#3422040 (10zhuyifei1999) See also https://wikitech.wikimedia.org/wiki/Help:Disabling_an_accou... [18:36:31] 10Release-Engineering-Team (Kanban), 10Toolforge, 10LDAP: Archive user account purodha - https://phabricator.wikimedia.org/T152857#3422112 (10demon) 05Open>03Resolved a:03demon I think we did everything needed here. [18:50:18] hey, scap's error rate checking went bonkers, Niharika had it failing 5 times before she had to use --force [18:53:41] yep, saw that. I don't think it's bonkers, I just think it's false positives [18:55:00] the decision its making is if a single host's 30-second average error rate from the last hour increases by 10x in the last 20 seconds, fail it. Unfortunately that means that low error rates pre-deploy can cause false positives since 10x a low number is still a low number. [18:55:48] tried to mitigate that somewhat by having the minimum 30 second average error rate pre-deploy be 1 (since there were more problems when it was allowed to be, like, 0.05) [18:59:09] 10Scap, 10Wikimedia-log-errors: Repeat SCAP errors due to some Extension:Scribunto error - https://phabricator.wikimedia.org/T170186#3422215 (10MarcoAurelio) [19:00:27] 10Scap, 10Wikimedia-log-errors: Repeat SCAP errors due to some Extension:Scribunto error - https://phabricator.wikimedia.org/T170186#3422229 (10MarcoAurelio) [19:29:47] 10Release-Engineering-Team (Kanban), 10Scap, 10Patch-For-Review, 10Wikimedia-log-errors: Repeat SCAP errors due to some Extension:Scribunto error - https://phabricator.wikimedia.org/T170186#3422384 (10thcipriani) 05Open>03Resolved a:03thcipriani The extra noise here was caused by {T166348} the root c... [19:56:26] thcipriani thanks for the review, i've added the ssh keys here https://gerrit.wikimedia.org/r/#/c/363755/ :) [20:00:38] paladox: nice :) [20:00:47] yep :) [20:00:50] all tested too [20:04:03] works in your labs project? [20:07:08] yep [20:07:25] thcipriani, i have managed to get scap working on phab-tin [20:07:37] so i scap there to deploy phabricator and now gerrit :) [20:08:02] you have outpaced production :) [20:08:17] so... eh... [20:08:26] i think that public keys should be in public repo [20:08:33] and private in private / labs/private [20:08:52] but it seems that this is not the case with the scap setup [20:09:01] that will require a change in scaps module + moving keys from the private repo (pub keys) [20:09:12] where .pub files are added in labs/private [20:09:29] so i said i won't block the phab change if that is how all others do it [20:09:35] I don't know how the secret module works, honestly [20:09:42] or secret function rather [20:09:46] never looked at the source [20:09:54] but i still think it's a bit wrong.. but we should change all at once then i guess [20:10:17] the thing is that there is no need to put it in secret [20:10:27] it's called .pub [20:10:37] so it can just be in the normal place [20:11:30] is there a secret module in the public repo? [20:11:53] no, in the private repo [20:12:03] and in labs it's the fake "labs/private" [20:12:07] fake = actually public too [20:12:22] oh, I see what you're saying: keyholder shouldn't be using secret to grab the public key since it's not a secret. [20:12:28] my point is, if you have a keypair, and you have the public and private part [20:12:41] the public part would be in the normal public repo [20:12:53] and the private part would be in "secret" (in prod) and "labs/private) (in labs) [20:13:02] then puppet role just works [20:13:10] without an extra "if labs" check or anything [20:13:24] thcipriani: yes [20:13:44] i just said that because that's how we do it with SSL certs [20:13:49] yeah, we just need to update logic: https://github.com/wikimedia/puppet/blob/production/modules/keyholder/manifests/agent.pp#L59 [20:13:58] it makes sense [20:14:42] that can be changed to using the puppet module calling it? [20:14:43] yea, in that line the conflict between "secret" and "pub" that is what caught my eye when i looked at paladox' change too [20:15:24] but i really didn't mean to turn that phab change into "change all the things" so sorry about that [20:15:34] as long as it is consistent [20:15:47] and we could change them all later maybe [20:17:43] yeah, I think that'd make sense. Although the private/public split is a bit opaque from outside. I think that's why we put them all on one side rather than have the two halves of the keys straddle repos. [20:18:36] it's true that in reality it isn't much of a difference, except you have to create 2 files in labs/private [20:19:02] and i also don't want to break it :) [20:19:42] this is fair :) [20:21:20] thcipriani what do you mean by "you have outpaced production"? :) [20:22:06] paladox: I just mean gerrit isn't using scap3 yet and you are [20:22:15] ah yep [20:22:24] * paladox is testing it. [20:27:00] sounds right to me, first labs then prod :) [20:29:03] paladox: "gerri-roott" [20:29:23] in deployment_server.yaml on your change [20:31:53] mutante woops [20:31:57] fixed now [20:31:58] thanks :) [20:35:27] cool. so if https://gerrit.wikimedia.org/r/#/c/363726/ looks good to you guys.. i'd merge it with some +1s.. not blocking [20:35:46] up to you when is the best time to switch anything [20:36:50] mutante that is a backwords compat change so will not break anything :). though yeh needs a +1 from RainbowSprinkles and thcipriani :) [20:36:58] hrm, trying to find the punch-line for the use of the gerrit2 user [20:37:16] punch-line? [20:37:45] I know RainbowSprinkles had some reservations about using that user for deployment, but I don't know what the resolution of that discussion was [20:38:12] because it won't be "2" anymore? [20:38:26] and upstream changed it , right [20:38:32] to just "gerrit" [20:39:17] yeh upstream are planning a 3.0 release though gerrit2 should work fine for us. [20:39:46] oh, is that what it was about, we can make that configurable later, me thinks. [20:39:49] lgtm [20:41:04] 10Continuous-Integration-Config, 10MediaWiki-Core-Tests, 10Accessibility: Consider using pa11y as automated accessibility integration test - https://phabricator.wikimedia.org/T170096#3422682 (10Isarra) How well would this actually work? Would it catch our common issues? Would it react badly to all the bad st... [20:41:24] er wait... [20:43:29] I wonder can scap create the symblink? [20:43:39] I made a comment earlier about this, but since /var/lib/gerrit2/review_site will be a symlink to /srv/deployment/gerrit/gerrit/review_site that means we'll need to figure out how to manage the files inside it managed by puppet [20:43:50] ah yep [20:43:57] can scap do the symblinking? [20:44:17] it could do that as part of a check step [20:44:27] ah thanks [20:44:28] those files can't be moved outside of the deployment directory? [20:44:43] well review_site can be out of it [20:44:51] though i am thinking of something easy [20:45:18] like java -jar gerrit.war init -d review_site will put the jar in there [20:45:41] i guess chad could cp them over to /var/lib/gerrit2? [20:50:43] paladox: what was the symlink for again [20:50:54] to make it easier to apply local hacks, right [20:50:58] when testing [20:51:09] mutante for /srv/deployment/gerrit/gerrit/review_site -> /var/lib/gerrit2/review_site [20:51:16] to make it easier to update gerrit [20:51:16] ah [20:51:42] because you could be in /srv/deployment/gerrit/gerrit/ [20:51:57] then you could cp the plugins into review_site/plugins [20:52:02] then execute this command [20:52:08] java -jar gerrit.war init -d review_site [20:52:47] can't that be a full path? [20:52:56] -d /... [20:53:25] when you start it, you could just pass it the other filename? [20:54:39] it can be a full path [20:54:39] oh [20:54:42] yeh [20:54:44] i guess it can [20:54:49] * paladox removes symblink [20:56:16] heh [20:59:30] thcipriani i've removed the symlink :) [21:16:43] thcipriani actually https://gerrit.wikimedia.org/r/#/c/364320/ wont be needed as you can give java -jar the full path :) [21:17:16] ie java -jar gerrit.war init -d /var/lib/gerrit2/review_site [21:18:12] but I'm guessing you still need the files in that directory for something? [21:19:03] anyway, I left a big brain dump of options: https://gerrit.wikimedia.org/r/#/c/364320/3 [21:19:27] RainbowSprinkles may have an addtional braindump since he's gerrit bdfl around here ;) [21:19:49] im not sure what /var/lib/gerrit2/persist/[some-file] is ? [21:20:28] it's not currently anything, it's just a place that wouldn't be affected by deployments if you symlink /var/lib/gerrit2/code_review -> /srv/deployment/gerrit/gerrit [21:20:51] so you could put files in there and they would persist to exist in there between deployments [21:21:05] oh i see [21:21:11] we want it the otherway [21:21:29] so that /srv/deployment/gerrit/ links to /var/lib/gerrit2 [21:21:52] so that we can copy the jars in [21:24:11] oh [21:24:12] wait [21:24:18] never mind we doint need symblinking [21:24:41] i guess it will be less hacky if we supply the full path [21:24:44] thcipriani ^^ [21:24:45] leaving that aside for a moment, everything in /srv/deployment/gerrit/gerrit will be as if its a fresh checkout every time so any files that puppet puts in there will be gone after deployment. Looking at the puppet module for gerrit this seems like a problem. [21:25:04] yep [21:26:44] i've abandoned it for now [21:26:58] as it we can do the full path and make it less hacky [22:16:12] MaxSem: this number seems low: https://quarry.wmflabs.org/query/20175 [22:16:58] harej, just finished, writing report. the script dumped everything into mainpace without prefixes anyway [22:17:53] so more will trickle in over time? [22:18:41] without prefixes? [22:21:54] see phab [22:25:49] sure [22:30:17] MaxSem: so the issue is that the script broke, or something else? [22:30:51] it exploded until I fixed it [22:31:37] But now I see only four pages in the main namespace with any of the four prefixes [22:32:02] no prefixed, see results in phab [22:32:15] * TabbyCat is confused [22:39:04] harej: so what's next? [22:39:28] what about those Broken/ pages? where do we move them? [22:40:19] <MaxSem> Broken/ is genrally due to conflicts with already existing mainspace stuff [22:41:37] <harej> TabbyCat: I suppose we can have a bot that moves pages back. I have a spreadsheet with all the page titles :) [22:42:15] <TabbyCat> harej: if that fixes it, sure [22:42:29] <TabbyCat> you have a spreadsheet... I've got a bot [22:42:42] <TabbyCat> or you can flood-flag yourself and do it [22:42:48] <TabbyCat> if it is more confortable to you [22:43:15] <paladox> thcipriani i just deployed https://gerrit.wikimedia.org/r/#/c/363734/ to gerrit-test3 :) [22:43:32] <harej> TabbyCat: if you have a bot please proceed [22:43:36] <harej> Let me dump the spreadsheet somewhere convenient [22:44:25] <harej> TabbyCat: https://hastebin.com/raw/ojuqegerev [22:45:03] <paladox> seems to work https://gerrit.git.wmflabs.org/r/#/dashboard/self [22:45:40] <TabbyCat> harej: sorry for being an idiot but I don't know what to do with that list [22:45:51] <TabbyCat> I'm a bit nervous [22:48:05] <TabbyCat> 22:47, 10 July 2017 MarcoAurelio (talk | contribs | block) moved page Broken/2016 Strategy/Communities to Talk:2016 Strategy/Communities without leaving a redirect (revert) <-- this ? [22:48:34] <harej> Hold on [22:52:18] <harej> TabbyCat: "Broken/" replaces the name of the namespace [22:52:41] <harej> So given a "Broken/X" you want to find the corresponding page in the list and rename the page accordingly [22:52:51] <TabbyCat> i'm fetching the pywikibot move.py script syntax [22:53:54] <harej> MaxSem: how does it work if there's a "Programs:X" and a "Programs talk:X"? They can't both be "Broken/X" [22:54:09] <paladox> thcipriani or RainbowSprinkles could you +1 or -1 the scap change please? :) [23:02:15] <bd808> harej: wouldn't the talk become main talk namespace "Broken/X"? [23:02:28] <bd808> I think that's what it does anyway [23:02:42] <harej> Talk:Broken/X? Makes sense. [23:07:57] <TabbyCat> bd808: harej https://meta.wikimedia.org/w/index.php?title=Participation_talk:MarkAHershberger/SMWConFall2013MarkAHershberger/SMWConFall2013&action=history [23:09:00] <harej> TabbyCat: that looks good [23:09:05] <harej> though, I am concerned that a talk page was in the main namespace [23:09:34] <TabbyCat> that one was in grants / grants talk [23:09:42] <TabbyCat> meta namespaces are a mess [23:09:58] <harej> Right; I mean that there was no "Talk:Broken/X" that bd808 was referring to [23:10:06] <harej> https://meta.wikimedia.org/w/index.php?title=Special%3APrefixIndex&prefix=Broken%2F&namespace=1 [23:12:01] <TabbyCat> bd808: can you dry-run https://phabricator.wikimedia.org/T170176 ? [23:12:35] <bd808> yeah... let me get a shell that can do that [23:14:14] <bd808> TabbyCat: https://phabricator.wikimedia.org/T170176#3423251 [23:15:02] * TabbyCat rolls eyes [23:15:20] <TabbyCat> well, eswiki do not have any images locally uploaded for years already [23:15:25] <TabbyCat> how's that possible? [23:17:26] <harej> So if "broken" pages weren't created in the Talk namespace, what happens when there is a common page_title in both a namespace and its corresponding talk? [23:17:52] <bd808> harej: read the code :) nobody knows [23:18:14] <bd808> and make a patch if its wrong for bonus karma [23:18:51] <TabbyCat> I keep thinking this was not the script to run, but I won't continue arguing over it. What's done it's done and one way or another we'd have to clean the titles. [23:25:08] <TabbyCat> harej: gotta go, hope that we can find a way to repair this :) [23:25:11] <TabbyCat> see ya [23:29:49] <wmf-insecte> Project selenium-MobileFrontend » firefox,beta,Linux,BrowserTests build #486: 04FAILURE in 25 min: https://integration.wikimedia.org/ci/job/selenium-MobileFrontend/BROWSER=firefox,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=Linux,label=BrowserTests/486/