[00:51:40] gn8 folks [01:35:16] csteipp: ping [01:35:28] Hi Pine [01:35:48] Someone has reported an issue that sounds like it might be appropriate for you to look at, regarding how accounts are attached to SUL [01:36:16] Do you have a moment now? [01:37:40] Yeah, a couple mins... [01:38:26] I haven't looked into this myself but I think it would be nice if you responded to the person who posted since it sounds like a technical security issue. https://meta.wikimedia.org/wiki/Wikimedia_Forum#Unattached_accounts [01:55:00] csteipp: ^ you get that? [01:55:18] Pine: Yup, just adding a response :) [01:55:21] :) [01:55:31] It was a little weird... and I don't think I can fix it. [01:55:39] So I'll ping a few more people tomorrow. [01:56:09] ok thank you [01:58:54] Pine: Do you happen to know the history of kmwiki? Looks like the edit was imported from somewhere... [01:59:26] csteipp: I'm not familiar with it at the moment [02:00:09] Pine: No worries, I'll find someone tomorrow who's familiar with it. [02:00:30] Thanks for looking into it [10:19:54] For the first time in a week the job queue is below 1 Millon :D [10:20:27] shh, don't jinx it [10:44:19] Reedy: still around ? :D [10:59:37] Reedy: when you get around, I could use a review of WikimediaMaintenance update to latest master for 1.21wmf5 and 6 branches. https://gerrit.wikimedia.org/r/#/c/39552/ https://gerrit.wikimedia.org/r/#/c/39554/ [10:59:45] Reedy: could also use your expertise to have that deployed :-] [11:20:23] hashar: I am now [11:20:35] Reedy: got my message above ? [11:20:43] Yup [11:20:53] hashar: You can abandon the wmf5 one as we're not using it any more ;) [11:20:59] agh [11:30:04] Yay, enwiki job queue is down to ~800k [11:30:04] http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=spence.wikimedia.org&v=791276&m=enwiki_JobQueue_length&r=hour&z=small&jr=&js=&st=1356002987&z=large [11:30:14] Much more reasonable [11:37:51] Reedy I know :D I got well excited [11:44:13] Reedy: sorry back. So we only have 1.21wmf6 right now ? :) [11:44:19] Yup [11:44:22] how would I get my https://gerrit.wikimedia.org/r/#/c/39554/ change deployed ? [11:44:24] Last migrations were done last right [11:44:37] should I merge + pull then syncdir the 1.21wmf6/extensions/WikimediaMaintenance dir ? [11:44:43] Yeah [11:44:56] newer git should update the submodule automagically too I think [11:46:12] trying out [11:50:29] sync-dir ask me for fingerprint of almost all IPs :)D [11:57:06] Reedy: do you happen to know how to regenerate the know host file ? :-D [11:57:18] Puppet is supposed to do it... [11:59:03] will check that post lunch [11:59:17] maybe puppet will fix it while I am out :-] [11:59:28] bbl [14:31:57] hashar: hi! say, why does jenkins set a -2 for code-review if a test failed? [14:32:11] that doesn't get reset when submitting new patch sets [14:32:22] so, basically, the change is blocked forever [14:32:27] https://gerrit.wikimedia.org/r/#/c/37233/ [14:32:48] (i don't understand what failed in that case anyway, there seems to be no informative output) [14:35:49] <^demon> It set Verified-2, not CR-2. [14:35:56] <^demon> Also, the output is pretty clear from https://integration.mediawiki.org/ci/job/mediawiki-core-phpunit-databaseless/549/console [14:36:05] <^demon> [exec] PHP Fatal error: Cannot redeclare class TestORMTable in /var/lib/jenkins/jobs/mediawiki-core-phpunit-databaseless/workspace/tests/phpunit/includes/db/TestORMRowTest.php on line 183 [14:46:53] DanielK_WMDE: it does CR-2 when unit tests fails. Will reset to CR+0 whenever they pass again :) [14:47:04] or maybe I removed CR-2 , can't remeber [14:47:45] <^demon> It should only vrif-2 now, we changed that on purpose... [14:47:50] hashar: i don't see why it would set CR-2. CR-2 means "that's a stupid idea, we don't want that". [14:47:52] <^demon> -1. [14:47:58] <^demon> not 2. [14:48:06] yea [14:48:33] it's V+1 for passing lint, V+2 for passing unit tests, and V-1 for failing either, right? [14:48:52] so it does v-1 and v-2 whenever unit test fails. [14:49:09] grr [14:49:15] v-1 and cr-2 whenever unit test fails [14:49:41] <^demon> It should only do verified.... [14:49:50] <^demon> We explicitly wanted jenkins *out* of CR. [14:50:03] then someone could v+2 to merge it ? [14:50:47] <^demon> No. We use MaxWithBlock. [14:50:52] <^demon> The lowest negative score is a veto. [14:51:07] <^demon> Whether it's -1 or -5000. [14:51:24] <^demon> (Lowest possible negative score) [14:56:27] ^demon: sure ? :-D [14:56:37] <^demon> Indeed. [14:56:38] <^demon> I am. [14:58:44] hashar: i'm confused now... how is supposed to press "submit"? see https://gerrit.wikimedia.org/r/#/c/38536/ [14:58:50] what's going to happen there? [14:58:59] right now it looks like it's just sitting there [14:59:41] *who [14:59:51] DanielK_WMDE: it is merged [15:00:16] ah, i guess i looked while jenkins wasn't quite done yet. [15:00:19] maybe I should add a message announcing something like "Oh yeah, lets run unit test and merge that approved changes whenever tests are a success. Please wait.." [15:00:44] sounds nice :) but that wasn't the problem [15:00:57] the tests already passed and it was already set to verified [15:00:59] but not merged [15:01:09] i must have slipped in between these two things happening [15:20:19] ^demon: too late to remove the CR-2 voting. I will fill in a bug and do that tomorrow (if I don't forget about it) [15:22:23] https://bugzilla.wikimedia.org/show_bug.cgi?id=43300 [15:31:24] got the changes in, will merge later :) [15:31:38] see you later [17:13:39] hello, why did jenkins run full tests for https://gerrit.wikimedia.org/r/#/c/37503/ ? i though it wasn't supposed to till the change has been +2'd? [17:13:46] not that i mind, but this is unexpected [17:14:26] as far as i know i'm not on the whitelist ( https://gerrit.wikimedia.org/r/gitweb?p=integration/zuul-config.git;a=blob;f=layout.yaml;hb=HEAD#l81 ) [17:36:12] MatmaRex, try asking now ^ [17:38:29] hello, why did jenkins run full tests for https://gerrit.wikimedia.org/r/#/c/37503/ ? i though it wasn't supposed to till the change has been +2'd? [17:38:31] not that i mind, but this is unexpected [17:38:33] as far as i know i'm not on the whitelist ( https://gerrit.wikimedia.org/r/gitweb?p=integration/zuul-config.git;a=blob;f=layout.yaml;hb=HEAD#l81 ) [17:38:35] hashar: ^ [17:38:40] Krenair: :) [17:46:18] MatmaRex: we don't have any process yet to whitelist people [17:46:26] MatmaRex: I guess if nobody oppose, you will be in :] [17:46:43] hashar: yes, but the thing is, it is already testing my changes [17:46:44] MatmaRex: example to get someone added : https://gerrit.wikimedia.org/r/#/c/39599/ [17:46:49] ah [17:46:50] and i guess this isn't supposed to happen :P [17:47:15] maybe you are whitelisted :) [17:47:21] can't check right now sorry [17:47:27] as far as i can see i am not [17:47:42] according to https://gerrit.wikimedia.org/r/gitweb?p=integration/zuul-config.git;a=blob;f=layout.yaml;hb=HEAD#l81 [17:47:46] indeed [17:47:48] grmblblblbl [17:47:53] and https://gerrit.wikimedia.org/r/#/c/37503/ got -2'd by jenkins twice already [17:47:58] (on two differnet patchsets) [17:49:01] MatmaRex: can you fill a bug for it please ? [17:49:05] I need to leave like "right now" [17:49:06] :/ [17:57:48] Hi, there will be a Wikimedia Mobile team office hour in #wikimedia-office - please participate:) [20:31:04] was/is the Article Feedback Tool at 1.21wmf5 newer sync with AFT-master than at 1.21wmf6-branch? [20:31:19] matthiasmullie: ^ [20:32:09] se4598: no idea, will take a look [20:33:14] because now we have the problem with long feedback and "more"-link not working again [20:33:29] se4598: indeed, looks like it [20:34:57] will get it fixed [20:53:26] se4598: should be updated - looks good for you too? [20:57:11] matthiasmullie: yes [20:57:27] ok great :) [20:57:31] nice catch! [22:41:16] Is there someplace where I can read off the current squid lag in updating images and thumbnails? [22:41:26] Is that a thing? [22:46:53] hmm [22:47:01] lexein: there's not really a specific queue on those i don't think [22:47:11] so no direct lag figure is probably calculable [22:47:29] Hm. Strange - I filed a bug - moment... [22:47:58] https://bugzilla.wikimedia.org/show_bug.cgi?id=42963 [22:48:06] oh, it's now a dup. [22:48:22] https://bugzilla.wikimedia.org/show_bug.cgi?id=41130 [22:53:53] brion - Are you familiar enough with squid to answer a couple of questions? [22:54:21] lexein: possibly not :) but i'll try and can wake up others if need be [22:54:29] the ops people are around, they're just shy [22:54:40] 1. Is there anything users can do to avoid contributing to the problem when uploading images or uploading new versions of images? [22:55:10] 2. actually there was only the one question: the other should go in the bug comments. [22:55:19] 1. I don't _think_ so… the canonical URLs of images and their thumbnails _should_ be automatically purged from the squids as soon as an image gets modified [22:55:33] It's late, and this is not urgent, so no need to wake anyone. [22:55:37] so if it's failing it's probably an internal issue [22:57:24] I wonder if server load is causing the purge process to be dropped on the floor [22:59:41] maybe… or something may not be properly responding [23:08:24] It's strange. I was not affected by any image or thumbnail issues until recently, then, blammo, what the - [23:18:45] Reedy or someone: any idea why test2wiki has issues just now? search completion doesn't work, UW doesn't load, edit tools do not appear, for all browsers [23:19:03] i'll look; we just deployed a bunch of stuff [23:19:06] Uncaught Error: Unknown dependency: ext.postEdit [23:19:12] I'm fairly sure it is you ori-l ;) [23:19:15] we just busted a lot of stuff on test2 [23:19:28] yeah, us. [23:19:32] i'll fix. [23:19:50] cowboys :-) [23:20:00] and how [23:22:46] ori-l: ping me when you think you got it, I can kick off my cross-browser tests again for test2 [23:22:59] chrismcmahon: i think i did [23:23:02] checking [23:23:37] Why isn't test2 loading PostEdit? It's on a lot of wikis. [23:23:51] spagewmf: lots but not test2 [23:23:56] Why does test2 exist? [23:24:07] chrismcmahon: i enabled the missing dependency; i guess a few more minutes for cache [23:25:41] Susan: it's testwiki in an environment that matches the rest of the production wikis [23:27:24] root cause analysis: the JS expresses a dependency that doesn't fail until loaded in a browser. Can one extension express its dependency on another in PHP so it fails earlier? [23:27:25] chrismcmahon: fixed. [23:27:50] Reedy: Unlike test.wikipedia.org? [23:27:57] which has srv193 all to itself [23:28:01] run from NFS [23:28:05] spagewmf: the dependency is in PHP [23:28:21] the relevant ResourceLoaderModule dependency declarations are all in PHP [23:29:09] Right, but they don't cause PHP failure at startup [23:30:03] spagewmf: pre-deployment RL dependency tree validation. ASSIGNED spagewmf [23:30:32] builds for browser tests started [23:31:12] visible here if you're interested: https://wmf.ci.cloudbees.com/ [23:39:53] Chrome back to green [23:42:39] IE6 back to green. ori-l I think you fixed it [23:48:18] chrismcmahon, that's great. Where's the source of the 23 Cloudbees tests? [23:50:04] spagewmf: mirror at https://github.com/wikimedia/qa-browsertests, gerrit at https://gerrit.wikimedia.org/r/#/admin/projects/qa/browsertests, lots of docs linked off of http://www.mediawiki.org/wiki/Groups/Proposals/Browser_testing [23:52:50] chrismcmahon thanks. Do your tests make the basic assertion that all the modules loaded OK? [23:53:29] ori-l figured out the JS for it, see assertNoModuleFailures at end of https://github.com/atdt/karaga/blob/master/karaga/__init__.py [23:53:30] spagewmf: nope. those tests just manipulate elements in the DOM in various ways, like a user would. [23:59:16] chrismcmahon, IMO every page that a test loads should make that assertion, it seems the #1 cause of brokenness in deployments. Works in browser console too. mw.loader.getModuleNames().filter(function (module) { return mw.loader.getState(module) === "error"; })