[00:07:47] 10Continuous-Integration-Config, 10Differential, 10OOjs-Router: Add 'npm test' Jenkins job to Differential commits for oojs-router - https://phabricator.wikimedia.org/T163865#3212617 (10Krinkle) [00:09:41] twentyafterfour: Hm.. replication is broken for oojs-router from Phab diff to github? [00:09:45] commits from last year aren't there yet [00:19:45] https://phabricator.wikimedia.org/T163866 filed [00:51:16] James_F: that seems sensible to me [00:51:21] Krinkle: ok I'll look into it [00:51:55] Kk. [01:02:00] James_F: Tbh, without a workboard I *hate* having those milestones [01:02:08] It makes tracking the actual release impossible [01:02:37] eg: https://phabricator.wikimedia.org/maniphest/?project=PHID-PROJ-sa7lalnfkw2yiavuprku&statuses=open()#R [01:02:50] vs https://phabricator.wikimedia.org/project/board/2400/ [01:04:22] Ah, I can archive the old milestones [01:11:06] RainbowSprinkles: That's a different set of projects; see my question in -devtools earlier. [01:11:19] Hm [01:11:52] RainbowSprinkles: There's "wmf.XY blockers" which I'm suggesting should be under the "release" (blockers) projects, because they block them. [01:12:19] RainbowSprinkles: And there's "wmf.XY release" which I've moved from MW1.30+ to be under the "release notes" (no-one cares) projects. [01:12:45] I disagree [01:12:49] RainbowSprinkles: But I don't know if we can retrospectively move MW1.29's "wmf.XY release" milestones to MW1.29-release-notes. [01:12:58] Blocker to wmf release does not imply blocker to general release. [01:13:09] Sure, but it's a "worth considering". [01:13:17] Sure, I guess :) [01:13:24] Unlike "wmf.XY release" which definitely aren't. :-) [01:13:41] Eg: a bug in WikimediaEvents can block a wmf release, but doesn't block a stable MW tar :) [01:13:56] RainbowSprinkles: Also you just archived https://phabricator.wikimedia.org/project/view/2703/ even though it's still in prod, which isn't very helpful. :-( [01:14:36] I keep each milestone open 'til it rolls off the train. [01:15:35] It might be easier to just switch the labels/descriptions of "MW-1.29-release" and "MW-1.29-release-notes" at this point. :-( [01:16:28] Whoops, meant to do just thru 19 [01:17:10] What pipeline do those release-note projects feed btw? [01:17:27] We don't use them for the mw.org release notes we generate weekly. I definitely don't use them when doing the tarballs [01:18:20] They're used for the weekly task triages / release notes and QA verifications. [01:23:32] fair 'nuff [01:29:07] It'd be nice if we could consolidate the efforts, though. [01:29:10] Eh. Later. [04:06:09] Project selenium-MultimediaViewer » safari,beta,OS X 10.9,BrowserTests build #373: 04FAILURE in 10 min: https://integration.wikimedia.org/ci/job/selenium-MultimediaViewer/BROWSER=safari,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=OS%20X%2010.9,label=BrowserTests/373/ [06:53:37] 10Deployment-Systems, 10Scap (Scap3-MediaWiki-MVP), 06Operations, 13Patch-For-Review: Install conftool on deployment masters - https://phabricator.wikimedia.org/T163565#3213002 (10Joe) I don't think scap should interact with conftool by itself, unless it reproduces what the `restart-` scripts are... [06:55:10] 10Beta-Cluster-Infrastructure: ORES errors on zhwp beta - https://phabricator.wikimedia.org/T163873#3213003 (10vjudge404) [08:30:04] Yippee, build fixed! [08:30:05] Project selenium-Core » firefox,beta,Linux,BrowserTests build #393: 09FIXED in 6 min 5 sec: https://integration.wikimedia.org/ci/job/selenium-Core/BROWSER=firefox,MEDIAWIKI_ENVIRONMENT=beta,PLATFORM=Linux,label=BrowserTests/393/ [08:43:44] 10Beta-Cluster-Infrastructure, 10media-storage: Migrate beta cluster Swift cluster from Trusty to Jessie - https://phabricator.wikimedia.org/T162247#3213102 (10fgiunchedi) Indeed we'll have to do this also because production will no longer have trusty "soon" (cfr T162609). I'll start with provisioning a jessie... [08:55:16] I've provisioned deployment-ms-fe02 for that ^ just now, getting an error about self-signed cert when running puppet [08:55:21] what was the fix again? [08:55:23] Warning: SSL_connect returned=1 errno=0 state=error: certificate verify failed: [self signed certificate in certificate chain for /CN=Puppet CA: deployment-puppetmaster02.deployment-prep.eqiad.wmflabs] [09:01:39] got it, https://wikitech.wikimedia.org/wiki/Standalone_puppetmaster#Step_2:_Setup_a_puppet_client [09:05:49] PROBLEM - Puppet errors on deployment-ms-fe02 is CRITICAL: CRITICAL: 70.00% of data above the critical threshold [0.0] [09:11:04] 10Beta-Cluster-Infrastructure, 10media-storage, 15User-fgiunchedi: Migrate beta cluster Swift cluster from Trusty to Jessie - https://phabricator.wikimedia.org/T162247#3213127 (10fgiunchedi) [09:18:11] 10Beta-Cluster-Infrastructure, 10media-storage, 15User-fgiunchedi: Migrate beta cluster Swift cluster from Trusty to Jessie - https://phabricator.wikimedia.org/T162247#3213149 (10fgiunchedi) @hashar for ms-be the used ram seems in the order of ~12GB so m1.large would be tight. I'll go with m1.xlarge for now,... [09:21:47] Hi RelEng people, I was wondering what the process is to get shell access on the Beta Cluster. [09:22:02] I'd like to run a new MW maintenance script there as a test [09:25:49] RECOVERY - Puppet errors on deployment-ms-fe02 is OK: OK: Less than 1.00% above the threshold [0.0] [09:34:52] PROBLEM - Puppet errors on deployment-ms-be03 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [09:54:50] RECOVERY - Puppet errors on deployment-ms-be03 is OK: OK: Less than 1.00% above the threshold [0.0] [10:35:50] PROBLEM - Puppet errors on deployment-ms-be04 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [10:39:58] 10Continuous-Integration-Config, 10MobileFrontend, 06Reading-Web-Backlog: Migrate experimental CI job mwext-MobileFrontend-npm-run-lint-modules to stable - https://phabricator.wikimedia.org/T163882#3213309 (10Jhernandez) [10:41:54] 10Continuous-Integration-Config, 10MobileFrontend, 06Reading-Web-Backlog: Add disabling comment syntax to resource-modules linter - https://phabricator.wikimedia.org/T160056#3213326 (10Jhernandez) This one was resolved as part of the parent T146748, sorry I didn't see it before. The part that wasn't done is... [10:42:57] 10Continuous-Integration-Config, 10MobileFrontend, 06Reading-Web-Backlog: Migrate experimental CI job mwext-MobileFrontend-npm-run-lint-modules to stable - https://phabricator.wikimedia.org/T163882#3213329 (10Jhernandez) [10:52:17] 10Gerrit, 06Release-Engineering-Team: Update gerrit to 2.13.8 - https://phabricator.wikimedia.org/T158946#3213356 (10Paladox) [10:55:50] PROBLEM - Puppet errors on deployment-ms-be03 is CRITICAL: CRITICAL: 11.11% of data above the critical threshold [0.0] [11:00:51] RECOVERY - Puppet errors on deployment-ms-be04 is OK: OK: Less than 1.00% above the threshold [0.0] [11:05:51] RECOVERY - Puppet errors on deployment-ms-be03 is OK: OK: Less than 1.00% above the threshold [0.0] [11:19:53] PROBLEM - Puppet errors on deployment-sca03 is CRITICAL: CRITICAL: 33.33% of data above the critical threshold [0.0] [11:24:10] Anyone around who could answer my question? [11:29:32] 10Gerrit, 06Release-Engineering-Team: Update gerrit to 2.13.8 - https://phabricator.wikimedia.org/T158946#3213422 (10Paladox) See http://gerrit-documentation.storage.googleapis.com/Documentation/2.13.8/pgm-MigrateAccountPatchReviewDb.html [11:43:45] tto: depend on the question [11:43:49] I might be able to help [11:43:59] Amir1, Hi RelEng people, I was wondering what the process is to get shell access on the Beta Cluster. [11:43:59] I'd like to run a new MW maintenance script there as a test [11:44:30] tto: For me, we made a phab card [11:44:47] let me find it for you [11:45:39] tto: https://phabricator.wikimedia.org/T128130 [11:45:55] HTH [11:46:45] Amir1: OK, thanks for that! As you commented at the task description, the process is, at best, poorly defined :) [11:47:15] hashar did wrote that but yeah ;) [11:47:44] Oh I see, yes he did write it! Should have known from the classic curly-bracket mouth emoticon he used :-} [11:48:12] :))) [11:58:37] 10Beta-Cluster-Infrastructure: Request for shell access on beta cluster - https://phabricator.wikimedia.org/T163887#3213475 (10TTO) [12:01:33] 10Beta-Cluster-Infrastructure, 10ORES, 10Revision-Scoring-As-A-Service-Backlog: ORES errors on zhwp beta - https://phabricator.wikimedia.org/T163873#3213496 (10Aklapper) [13:19:35] just going to check if the beta cluster has data in redis that'll allow the automated browser tests to pass [13:20:12] for the GettingStarted extension [13:20:29] (requires running a maintenance script on the beta cluster that'll dump extension-specific info) [13:20:34] https://github.com/wikimedia/mediawiki-extensions-GettingStarted/blob/master/maintenance/dump_redis.php [13:22:54] interesting, the script can't connect to the redis slave [13:26:07] it could be because of eqiad to codfw switch. [13:26:30] phuedx ^^ [13:27:18] since visualeditor isent working on wikitech since the switch. so could be related. [13:31:45] paladox: could be [13:31:59] paladox: equally likely is i'm messing up invoking the script ;) [13:32:07] oh [13:35:06] There's a bit of datacenter work happening this morning that affects one of the labs servers. We're /pretty sure/ this won't have any effect on CI/nodepool, but lmk if things go crazy in the next 30-60 mins. [14:00:30] 10Gerrit, 10MediaWiki-Vagrant: "index-pack failed" when installing new MediaWiki-Vagrant box - https://phabricator.wikimedia.org/T152801#3213944 (10TheDJ) Zomg, this is really cumbersome.. I just spent a lot of minutes trying to support someone in wikimedia-dev only to run into this. Tried all of the above me... [14:27:24] 10Gerrit, 10MediaWiki-Vagrant: "index-pack failed" when installing new MediaWiki-Vagrant box - https://phabricator.wikimedia.org/T152801#3213984 (10Paladox) We could switch to phabricator for cloning if no one needs to upload a change from vagrant? [14:43:46] 10Gerrit, 06Release-Engineering-Team, 13Patch-For-Review: Update gerrit to 2.14 - https://phabricator.wikimedia.org/T156120#3214068 (10Paladox) >>! In T156120#3194172, @demon wrote: > As I've said a dozen times, we're not upgrading until at least 2.14.1, so there's no rush. I'm unsubscribing from this until... [14:56:32] 10Gerrit, 10MediaWiki-Vagrant: "index-pack failed" when installing new MediaWiki-Vagrant box - https://phabricator.wikimedia.org/T152801#2860585 (10Reedy) >>! In T152801#3213984, @Paladox wrote: > We could switch to phabricator for cloning if no one needs to upload a change from vagrant? Many people would do.... [14:59:03] 10Gerrit, 10MediaWiki-Vagrant: "index-pack failed" when installing new MediaWiki-Vagrant box - https://phabricator.wikimedia.org/T152801#3214129 (10bd808) >>! In T152801#3213984, @Paladox wrote: > We could switch to phabricator for cloning if no one needs to upload a change from vagrant? @Paladox please stop... [15:01:57] 10Gerrit, 10MediaWiki-Vagrant: "index-pack failed" when installing new MediaWiki-Vagrant box - https://phabricator.wikimedia.org/T152801#3214141 (10Paladox) I was only suggesting something. Why are you being rude? [15:09:23] 10Gerrit, 10MediaWiki-Vagrant: "index-pack failed" when installing new MediaWiki-Vagrant box - https://phabricator.wikimedia.org/T152801#3214150 (10bd808) >>! In T152801#3214141, @Paladox wrote: > I was only suggesting something. Why are you being rude? Your persistent low value interactions do not help solv... [15:11:10] 10Gerrit, 13Patch-For-Review: REL1_28 checkout of extensions.git is broken - https://phabricator.wikimedia.org/T162884#3214156 (10Paladox) 05Open>03Resolved a:03Reedy I think this is now resolved. Please reopen if it isn't. [15:11:24] 10Gerrit: REL1_28 checkout of extensions.git is broken - https://phabricator.wikimedia.org/T162884#3214160 (10Paladox) [15:21:13] 10Beta-Cluster-Infrastructure, 10media-storage, 13Patch-For-Review, 15User-fgiunchedi: Migrate beta cluster Swift cluster from Trusty to Jessie - https://phabricator.wikimedia.org/T162247#3214221 (10fgiunchedi) ms-be0[34] and ms-fe02 are up and running with swift 2.10, next steps: [] add new backends to t... [15:24:37] !log add new deployment-ms-be0[34] backends to swift in deployment-prep - T162247 [15:24:43] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [15:24:44] T162247: Migrate beta cluster Swift cluster from Trusty to Jessie - https://phabricator.wikimedia.org/T162247 [16:14:27] PROBLEM - Long lived cherry-picks on puppetmaster on deployment-puppetmaster02 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:05:39] PROBLEM - Puppet errors on buildlog is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:05:45] PROBLEM - Puppet errors on swift is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:06:45] PROBLEM - Puppet errors on deployment-urldownloader is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:07:17] PROBLEM - Puppet errors on swift-storage-01 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:07:23] PROBLEM - Puppet errors on deployment-ircd is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:08:46] PROBLEM - Puppet errors on deployment-phab01 is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0] [17:24:25] 10Continuous-Integration-Config, 10VisualEditor: VisualEditor-MediaWiki: Don't be "smart" about only running jsduck on JS file changes - https://phabricator.wikimedia.org/T155862#3214905 (10matmarex) [17:33:03] Good morning RelEng. Is anyone around to talk about https://phabricator.wikimedia.org/T163114 and https://phabricator.wikimedia.org/T126306 ? [17:33:21] Ran into an issue during deployment on Monday with twentyafterfour [17:33:25] and keen to get to the bottom of what happened [17:33:47] jdlrobson: I think I figured it out [17:33:58] the problem is that the config files are symlinked [17:34:13] and you have to touch the symlink or hhvm doesn't clear it from cache [17:34:18] I should have known this already [17:34:20] twentyafterfour: i saw that comment.. but did those files get touched yet? [17:34:24] (I mean, I did, just forgot) [17:35:07] jdlrobson: not by me but possibly by another swat [17:35:08] twentyafterfour: because even with your fix https://phabricator.wikimedia.org/rOMWC1a75877790c878b1241818bc2a6aef2d5822ca46 if the file got touched the correct config would apply [17:35:14] but it still isn't applying [17:35:30] CommonSettings.php isn't a symlink thouhg? [17:35:55] jdlrobson: if there is something more going on then I'm still stumped [17:36:06] https://phabricator.wikimedia.org/rOMWC1a75877790c878b1241818bc2a6aef2d5822ca46 < Reedy any ideas why this would be happening? [17:36:31] We used to get stupid stuff like this with not touching InitialiseSettings [17:36:55] i.e. why would $wmgRelatedArticlesFooterWhitelistedSkins not be defined in CommonSettings.php when it is defined in wmf-config/InitialiseSettings.php [17:36:56] But scap has been touching it itself for quite a while [17:37:01] caching [17:37:29] if ( @filemtime( $filename ) >= filemtime( "$wmfConfigDir/InitialiseSettings.php" ) ) { [17:37:29] $cacheRecord = @file_get_contents( $filename ); [17:37:29] if ( $cacheRecord !== false ) { [17:37:29] $globals = unserialize( $cacheRecord ); [17:37:31] } [17:37:34] } [17:37:53] also i've noticed that if a config variable is defined as ['a'] in an extension.json, defining the same config variable in InitialiseSettings as [] has no effect (cc legoktm ) [17:37:53] sometimes, just touching initialisesettings on deployment host and pushing is enough to fix it [17:38:16] when's the next safe time to try that? [17:38:30] should be fine to jfdi for that [17:38:38] Though, there were some deploys earlier, so they might've done it [17:38:53] can someone try it now just in case? [17:38:59] 'cause at least then i can rule that out [17:39:09] there are dblists involved as well [17:39:13] so not sure if that's adding to the problem [17:39:46] nah, you'd at least get the default [17:41:27] touched [17:41:59] the default is what i'm trying to avoid. The dblist turns a ['minerva'] into a [] [17:42:23] could it be doing something other than assignment? e.g. array_merge Reedy ? [17:44:40] it could be doing something weird with an array, maybe [17:44:51] we've had a few issues with things like that [17:45:05] I've got a filed bug about wanting to unconditionally override stuff in extension.json [17:48:02] what's the bug number Reedy ? [17:48:26] does extension.json allow for overriding? [17:48:34] i couldn't find any documentation [17:48:41] but I see merge_strategy in various places [17:49:33] yeah [17:50:34] FWIW, scap touches InitialiseSettings for every sync unless you pass --beta-only-change to any of the sync-* commands https://github.com/wikimedia/scap/blob/master/scap/tasks.py#L407 [17:51:10] * thcipriani catches up [17:51:36] thcipriani: Indeed. It should [17:51:46] But it's been known to not actually work now and again [17:52:06] jdlrobson: https://phabricator.wikimedia.org/T142663 [17:52:38] Reedy: ohhh... so it doesn't work like that? WTF? [17:52:51] What is the workaround? [17:53:37] i.e. if we need to empty a list that's in config how can we do that. [17:54:33] I believe, contactpage was the problem here that caused me to file it [17:54:34] wfLoadExtension( 'ContactPage' ); [17:54:34] $wgContactConfig = []; [17:54:34] $wgContactConfig['default'] = [ [17:54:34] 'RecipientUser' => null, [17:55:11] yugggggg [17:55:35] but I'm not sure why that works particularly [17:55:45] I just noticed https://gerrit.wikimedia.org/r/#/c/335383/6 [17:55:46] but when i use a dblist that option isn't possible right? [17:56:00] you could work around it [17:56:06] and do the config in commonsettings [17:56:13] look for the dblist in $wikiTags [17:56:20] very much HACKHACKHACK [17:56:36] all of mediawiki config stuff is essentially a big ball of hacks [17:56:41] and not the good kind [17:57:02] hahah [17:57:09] and then they break with extension registration [17:57:21] Same with many of the hacks that people do in the PHP files [17:57:27] Because they have been able to, for years [17:57:56] The patch I linked above looks interesting though [17:59:02] Reedy: do you think https://gerrit.wikimedia.org/r/350459 would work? [18:00:06] I'm confused... line 2878 shouldn't have any effect [18:01:20] Hang on [18:01:34] Hmm [18:01:42] I thought we'd possibly removed the config from the extension too [18:02:55] you can ofcourse, set it in the extension in the registration method as a default... Again, another hacky [18:03:13] I'd rather not because it makes the extension more complicated to setup for 3rd parties [18:03:48] 'default' => [ 'minerva' ], 'related-articles-footer-blacklisted-skins' => [], seem to be in contention [18:03:51] Not particularly [18:04:07] looks like tgr added some input [18:04:08] You just do an !isset or similar, and set a default there [18:04:14] "The problem is probably that both default and related-articles-footer-blacklisted-skins match and they are either merged or only the first one is used, I don't remember which. InitializeSettings should really be documented somewhere." [18:04:27] bahhahahaa [18:04:30] welcome to SiteConfiguration.php [18:04:48] ffs [18:05:11] it's kinda interesting we don't hit these edge cases more often [18:06:43] IIRC, default should be used last [18:06:53] it shouldn't be using the default and the variable [18:06:58] agreed [18:07:03] I think it's dbname, dblist, default, in that order [18:07:09] that's how default's usually work in programming languages [18:08:21] That is [18:08:25] unless you do like +dbname [18:09:14] https://github.com/wikimedia/mediawiki/blob/master/includes/SiteConfiguration.php#L23-L121 [18:09:26] does related-articles-footer-blacklisted-skins.dblist need to be computed? [18:09:35] im guessing not [18:09:37] since it's just a list [18:10:04] wait [18:10:09] is the dblist new? [18:10:25] meh, it's in the tags [18:10:28] So it's not that [18:10:44] Reedy: there is a - prefix for exactly this use case [18:11:01] or used to be, I can't find the code or doc anywhere now [18:11:01] which part? [18:11:41] use '-dblist' instead of 'dblist' and then it gets overridden, not merged [18:11:47] or subtracted? can't remember [18:12:32] but it's handled by some completely different thing, note SiteConfig [18:13:10] i thought it was subtracted [18:14:47] it kinda feels like a couple of different issues here [18:14:59] according to the deployment going on it's unlikely to be the symlink issue here [18:15:02] the php warnings would be from a cache type issue, $wmgFoo is undefined [18:15:12] It's almost certainly not [18:15:25] portals falls over it... private too [18:15:33] which involve symlinks [18:15:55] doing a grep for => [] it seems nothing tries to do this... [18:16:15] indeed [18:16:19] I probably missed part of the conversation, I came here from https://gerrit.wikimedia.org/r/#/c/350459/1/wmf-config/CommonSettings.php [18:16:34] ohhh wgDisableQueryPageUpdate does [18:16:41] which is ineffective because $wmg already contains the merged array [18:16:42] and it does 'small' => [], [18:17:03] but wgDisableQueryPageUpdate defaults to false in DefaultSettings [18:17:17] ah ok [18:17:47] another option... [18:17:52] I think wgMFMobileFormatterHeadings also has the same problem [18:18:06] $wgExtensionFunctions[] = function() { } in CommonSettings under MF, and just set it there for WMF config [18:18:12] https://www.irccloud.com/pastebin/6WymA8af/ [18:18:19] literally do the global $wmg, $wg; $wg = $wmg; [18:18:39] seems like a bug in ConfigurationSettings ? [18:18:48] Might be worth adding a test case to check [18:19:17] I think it's extension registration issue [18:19:25] with what it's doing with the array in the extnesion [18:20:42] i bet if you create a test $wmg, differently, with the same contents as this one, you'll end up with you expect [18:20:49] Reedy: https://github.com/wikimedia/mediawiki/blob/master/includes/registration/ExtensionRegistry.php#L272 [18:20:52] as in that's the problem? [18:20:59] wtf is this merge_strategy stuff? [18:21:29] and how can it apply to a flat array? [18:21:47] pretty much [18:22:07] we kinda need a 'use localsettings if set' [18:22:20] ignore val [18:22:41] case 'override': [18:22:41] break; [18:23:39] https://www.mediawiki.org/wiki/Manual:Extension.json/Schema#Merge_strategies [18:24:01] Can you define merge_strategy in CommonSettings? ttps://gerrit.wikimedia.org/r/350459 [18:24:23] nope [18:24:42] jdlrobson: ask yurik about merging fun and gamex [18:24:44] *games [18:24:45] xD [18:25:12] wa? [18:25:21] yurik: extension.json and array merging of config [18:25:30] stay away from merging - one person, one project. Merging is evil :) [18:25:38] ah, that crazy thing... sigh [18:26:01] jsonconfig kinda figured it out by now [18:26:13] but it is a bit of woodoo [18:28:04] extension registry being applied after InitializeSettings is super unintuitive [18:28:21] well, it's expected [18:28:27] yeah, you'll have to use a callback in that case [18:28:32] wfLoadExtension puts it in a loading queue [18:28:38] so it runs at some indeterminate point in hte future [18:28:45] and fsck's with the globals [18:28:59] i'm stumped. So Reedy you think PS3 will work? https://gerrit.wikimedia.org/r/350459 [18:29:40] yeah, I imagine the big vision is that at some indeterminate point in the future InitializeSettings will be loaded the same way, and then ordering will work out [18:30:15] jdlrobson: Yes, but I really wouldn't suggest reusing a random callback like that [18:30:24] Just add your own in the usemobilefrontend guarded if [18:31:34] Reedy what about (PS4) Jdlrobson: Workaround issue of overriding whitelist config variable [mediawiki-config] - https://gerrit.wikimedia.org/r/350459 [18:32:19] I'd still stick it around 2884 [18:32:23] And you added whitespace further up [18:35:22] gonna try to deploy PS6 [18:36:38] tgr: Yes, switching InitialiseSettings to JSON (i.e., static definition) is the long-term plan, I believe. [18:37:31] James_F, i think YAML would work much better because we shouldn't code in a data exchange format. comments are a mandatory part of proper code [18:37:52] yurik: I don't care. :-) [18:37:56] or https://hjson.org/ [18:38:00] (Not my project.) [18:38:03] James_F, devs do ;) [18:38:07] thanks Reedy wll let yu know if it works [18:40:25] Is someone about to make RELEASE-NOTES-1.30 or should I? [18:40:52] (And all the other crap. [18:42:45] Have we bumped? [18:42:59] Well, greg-g declared that the next production branch will be 1.30-wmf.1 [18:43:16] merge conflict all the things [18:43:40] I guess it can just be done then, yeah [18:44:21] So… as of 273eea7357c546d1a1aafd73320e10e8ddac79eb we're in 1.30-ville. [18:44:22] OK. [18:45:53] 1.29 needs branching too then [18:46:25] And my battery is gonna die. 1% and I'm sat at a restaurant table [18:46:30] Reedy: chad will branch it on thursday post train [18:46:36] cc RainbowSprinkles ^ [18:47:20] some release note transplanting to be done then I guess after [18:47:29] Reedy: Not yet! [18:47:45] Can do that thursday night / friday :) [18:48:07] Reedy: `git log 273eea7357c546d1a1aafd73320e10e8ddac79eb.. RELEASE-NOTES-1.29` returns nowt. [18:48:30] Reedy, RainbowSprinkles: https://gerrit.wikimedia.org/r/350463 [18:48:32] I wish oojs-ui updated release-notes as it's an external library change [18:49:48] Reedy: I'll do that once REL1_29 is branched. Touching RELEASE-NOTES with a script that runs every week is a way to be painful to lots of people unnecessarily. [18:50:03] Not really [18:50:05] That section isn't edited so often [18:50:28] Eh. Maybe. Also regex-based editing of human-written notes considered harmful. ;-) [18:51:00] just look for the section below [18:52:10] 06Release-Engineering-Team, 10Scap: Include service and tmpfiles.d files into keyholder package - https://phabricator.wikimedia.org/T163716#3215236 (10mmodell) 05Open>03Resolved [18:52:19] my laptop is now on 0% [18:52:46] Run it through parsoid? [18:52:57] Reedy: Don't troll. :-) [18:54:20] Human written notes are harmful ;-) [19:36:26] hey folks — I'm trying to upgrade wikitech-static (via seat-of-pants) and my upgrade.php is failing with "Error: your composer.lock file is not up to date. Run "composer update" to install newer dependencies" [19:36:31] Is that… normal? [19:37:07] the error message or the lockfile not being up to date? [19:37:35] yes / probably no, respectively [19:37:37] either? [19:37:46] In any case I don't know how to run 'compuser update' [19:37:50] um… composer [19:38:02] so suggestions are welcome [19:38:04] it can easily happen when you do git checkouts though [19:38:37] composer.json is version-controlled, composer.lock is not, you change the branch or something, bam [19:38:39] am I supposed to have composer in my path? Or is there some context to 'composer update' that eludes me? [19:39:35] no clue how it's done on that specific machine, but it's a PHP file, you can just get it from the web [19:39:42] thicipriani hi, im getting this error AttributeError: Lock instance has no attribute '_get_lock_excuse' when using scap. [19:39:49] How would i fix that please? [19:40:15] tgr: I think you're still assuming I know too much :( [19:40:19] woops wrong name i meant thcipriani ^^ [19:40:26] So I want 'composer.php'? [19:40:36] which is not part of any of the mediawiki checkouts otherwise? [19:40:40] paladox: where are you seeing that? [19:40:45] andrewbogott: https://getcomposer.org/doc/00-intro.md#downloading-the-composer-executable [19:40:54] on phab-tin (labs) [19:40:55] paladox: should be fixed in master by https://github.com/wikimedia/scap/commit/8193eb3993a05457b328350cc3799cf1cdda46fc [19:41:09] oh ah. [19:41:30] presumably someone already did that to set up the site, but if you don't find it, redownloading might be less effort than looking for it [19:41:58] it could be called composer.php, composer, composer.phar... depends on the installation method [19:42:08] and not part of the checkout, yeah [19:42:33] 06Release-Engineering-Team (Deployment-Blockers), 05Release: MW-1.29.0-wmf.21 deployment blockers - https://phabricator.wikimedia.org/T161733#3215368 (10mmodell) [19:42:58] that fixed it by removing the file [19:42:59] thanks [20:01:06] tgr: ok, versioning questions… I just upgraded to 1.29.0-wmf.21 but should probably actually be using non-wmf branches for this. I don't see a REL1_29 branch... [20:01:22] is that because there isnt' one yet and I should just do 1_28? And, will that get me .1 or just .0? [20:03:37] 10Beta-Cluster-Infrastructure, 10ORES, 10Revision-Scoring-As-A-Service-Backlog: On beta cluster, ORESFetchScoreJob got a HTTP 400 bad request from ores-beta - https://phabricator.wikimedia.org/T157790#3215429 (10Mattflaschen-WMF) [20:04:12] andrewbogott there will be a REL1_29 branch tommror i think [20:04:36] 10Beta-Cluster-Infrastructure, 10ORES, 10Revision-Scoring-As-A-Service-Backlog: On beta cluster, ORESFetchScoreJob got a HTTP 400 bad request from ores-beta - https://phabricator.wikimedia.org/T157790#3016510 (10Mattflaschen-WMF) [20:09:32] 06Release-Engineering-Team, 06Operations, 10Phabricator, 10ops-eqiad: setup/install phab1001.eqiad.wmnet - https://phabricator.wikimedia.org/T163938#3215445 (10RobH) [20:09:44] 06Release-Engineering-Team, 06Operations, 10Phabricator: reinstall iridium (phabricator) as phab1001 with jessie - https://phabricator.wikimedia.org/T152129#3215465 (10RobH) [20:09:47] 06Release-Engineering-Team, 06Operations, 10Phabricator, 10hardware-requests, 10ops-eqiad: replacement hardware for iridium (phabricator) - https://phabricator.wikimedia.org/T156970#2991469 (10RobH) 05Open>03Resolved Resolving this task, as there is now a setup task for the system. [20:13:37] So im about to install phab1001 [20:13:45] but i see someone has it as a cname to iridium [20:13:53] twentyafterfour: ^ is it going to break anything when i remove that cname? [20:14:19] overall i think its a bad practice to cname hostnames to one another =] [20:14:50] there is also lines for phab1001-vcs ? [20:16:22] robh: it should be fine [20:16:36] cool, i dunno what the -vcs stuff is but shouldnt affect this [20:16:51] the -vcs is a second IP used by the same server [20:16:55] for git [20:17:56] oh, so that ip is actually routed to iridium currently then? [20:17:59] it's needed because git ssh and admin ssh both need the same port [20:18:15] and iridium is using two IPs, one with a hostname of hpab1001-vcs? [20:18:19] phab1001-vcs even [20:18:24] I don't know if phab1001-vcs is used [20:18:31] but iridium is using 2 ips [20:18:42] checking [20:18:48] git-ssh.wikimedia.org [20:19:06] yep [20:19:07] it's got two varnish vhosts [20:19:10] so that is confusing ;] [20:19:24] iridium is using irdium.eqiad.wmnet, as well as phab1001-vcs.eqiad.wmnet [20:19:47] also when it does move, it will require an IP change. [20:19:53] since iridium isnt in the same row... [20:20:10] ok .. I don't think anything depends on the IP directly, at least I hope not [20:20:16] !log Update mobileapps to 14bd4a5 [20:20:23] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [20:20:24] yeah, but when we move it, dns takes time to propogate [20:20:33] so we'll move it to a 5 minute ttl when we are going to move it (from the 1 hour) [20:20:48] but it'll still likely cause whoever relies on phab1001-vcs.eqiad.wmnet routing to break [20:21:12] for the 5 minutes of dns caching... we can invalidate internally and it may make it instant but not sure. [20:21:17] we have a regularly scheduled downtime on wednesday nights (actually 1:00AM UTC thursdays now, I believe) [20:21:23] cool, so it can happen then no worries [20:21:46] also phab1001-vcs isn't heavily mission-critical [20:21:51] i'll be installing shortly, but i wouldnt count on it for today =] [20:21:53] since gerrit is still our primary vcs [20:22:12] robh, that's fine, we should probably wait until after the dc switch-back [20:22:24] even less impact then, yeah no rush [20:22:26] 10Deployment-Systems, 06Operations, 10Ops-Access-Requests: Enable keyholder for ORES deployments - https://phabricator.wikimedia.org/T163939#3215512 (10Halfak) [20:22:27] and then deal with phab1001+phab2001 [20:22:38] it'll be spun up and getting updates for you when you are ready [20:22:51] cool thank you! [20:22:58] quite welcome =] [20:24:26] 06Release-Engineering-Team, 06Operations, 10Phabricator, 10ops-eqiad, 13Patch-For-Review: setup/install phab1001.eqiad.wmnet - https://phabricator.wikimedia.org/T163938#3215530 (10RobH) [20:25:05] 10Deployment-Systems, 06Operations, 10Ops-Access-Requests: Enable keyholder for ORES deployments - https://phabricator.wikimedia.org/T163939#3215512 (10Dzahn) I think what needs to happen here is adding a new "identity" for ORES deployments. As in the Identity column in the table on https://wikitech.wikimed... [20:27:15] 06Release-Engineering-Team, 06Operations, 10Phabricator, 10ops-eqiad, 13Patch-For-Review: setup/install phab1001.eqiad.wmnet - https://phabricator.wikimedia.org/T163938#3215563 (10RobH) [20:28:55] hello mk__ [20:29:50]