[00:04:04] Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Fix GeoIP lookup for IPv6 - https://phabricator.wikimedia.org/T121938#1891998 (awight) [00:04:21] Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Fix GeoIP lookup for IPv6 - https://phabricator.wikimedia.org/T121938#1891975 (awight) [00:05:49] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: composer broken on DonationInterface vendor repo - https://phabricator.wikimedia.org/T121932#1892002 (Reedy) p:Triage>Low [00:07:01] Fundraising-Backlog, MediaWiki-extensions-DonationInterface: composer broken on DonationInterface vendor repo - https://phabricator.wikimedia.org/T121932#1891904 (Reedy) https://github.com/composer/composer/issues/4717 Filed an upstream task. Suspecting it's going to be WONTFIX-ed, but I tried. It is fa... [00:07:46] awight: Thinking about it... Your vendor repo shouldn't need the repos that are in core checked in [00:07:51] Not sure a nice way of working around this though [00:09:12] Fundraising-Backlog, fundraising-tech-ops: Share Fundraising disaster protocol with all of ops - https://phabricator.wikimedia.org/T121941#1892017 (awight) NEW [00:13:56] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-DonationInterface: Donors need an option to pay from another country - https://phabricator.wikimedia.org/T96047#1892043 (awight) There is no solution that I know of, we'll always have some number of who fall into this zone. Use cases:... [00:16:13] Reedy: Agreed, I wish we could conveniently pull in the extension's composer.json, without doing terrible things with the directory structure. [00:16:31] Maybe move them to require-dev [00:16:43] Or remove them completely... Knowing core vendor has them [00:16:45] We also use this extension as a library under Drupal, though... [00:17:09] Turtles :D [00:17:31] hehe, yeah we dig pretty deep holes here [00:18:28] Reedy: Thanks for filing that upstream bug! [00:18:36] np [00:18:55] It might not be indended behaviour to commit the resultant vendor repo [00:19:02] But like you say, and from googling, it's common [00:19:05] They should handle it better [00:21:19] Reedy: btw, cwd is planning to write a general compile script that builds our deployment from the master branch. Do you think we should be looking at wmf-release tools for reuse? [00:21:34] Hmm [00:21:40] Not sure on the best way [00:21:50] Have you seen how/what Wikidata/Wikibase et al do? [00:21:51] * bd808 reads the upstream Composer bug [00:22:24] Reedy: i have not, i was basically writing bash scripts [00:22:30] then i got side tracked [00:22:34] lol [00:22:35] looking forward to getting back to it though [00:22:54] I'm sure if you loop in releng/mw core people they'll be able to add some pearls of wisdom [00:23:04] The Wikidata team create essentially a meta repo for WMF deployment [00:23:14] https://github.com/wikimedia/mediawiki-extensions-Wikidata [00:23:23] the builder is at https://github.com/wmde/WikidataBuildResources/ [00:23:28] Brings in all the repos, random vendor dependancies [00:23:42] Not a bad approach. [00:23:43] I'm not saying it's the way to do it... But it generally works well, so might be worth some time [00:23:55] cool, thanks! [00:24:00] yeah, our master/deployment branch thing is just a kludge [00:24:17] If you ask aude et al nicely, I'm sure they'll add a few cents too [00:24:18] i actually live right by thcipriani in releng so i've consulted him quite a bit [00:24:34] cwd: no offline meetings. kthx [00:24:35] * Reedy grins [00:24:39] hehe [00:25:05] I'd have offline meetings with Tyler. He's a beer guy [00:25:32] Fundraising Tech Backlog, Fundraising-Backlog, Traffic, operations, Patch-For-Review: Switch Varnish's GeoIP code to libmaxminddb/GeoIP2 - https://phabricator.wikimedia.org/T99226#1892105 (awight) [00:25:37] yeah, he's like _the_ beer guy [00:26:01] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: GeoIP lookup for IPv6 connections delays banner loading - https://phabricator.wikimedia.org/T121925#1892108 (awight) [00:26:21] I have another friend in the greater Denver area who would contest that [00:26:39] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: GeoIP lookup for IPv6 connections delays banner loading - https://phabricator.wikimedia.org/T121925#1891807 (awight) [00:26:41] Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Fix GeoIP lookup for IPv6 - https://phabricator.wikimedia.org/T121938#1892116 (awight) [00:26:57] he has an arduino temp sensor on his kegerator that pages him if it gets too warm or cold [00:27:28] that's awesome [00:27:56] bd808: at my last job we made a tweeting kegerator: https://twitter.com/sparkfunkeg [00:28:21] nice. I'd forgotten that you were another sparkfun refugee [00:29:20] indeed! [00:35:03] Finally--technology doing something useful [00:51:09] I wish jenkins would be useful [00:51:25] "zomg... test failure" [00:51:29] "oh, it's not your fault" [00:53:34] have a good weekend everyone! [06:11:02] Fundraising-Backlog, Wikimedia-Fundraising, MediaWiki-extensions-DonationInterface: Donors need an option to pay from another country - https://phabricator.wikimedia.org/T96047#1892473 (Krinkle) > Allow donors to manually switch their country. There should be a flag icon on every donation page, which... [06:30:14] Fundraising Sprint Zapp, Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Unplanned-Sprint-Work: Fix GeoIP lookup for IPv6 - https://phabricator.wikimedia.org/T121938#1892474 (Krinkle) > the US had 1.36M en.m.wikipedia.org page views and 1.17M impressions on v4 networks (86% impression rat... [06:50:35] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Technical-Debt: Clean up DonationInterface validation - https://phabricator.wikimedia.org/T121966#1892485 (awight) NEW [06:51:33] Fundraising-Backlog, MediaWiki-extensions-DonationInterface, Technical-Debt: Decouple session and token handling from payment gateway class - https://phabricator.wikimedia.org/T121967#1892492 (awight) NEW [07:09:32] Fundraising-Backlog, MediaWiki-General-or-Unknown: Investigate porting GeoIP for HHVM or using GeoIP2-php - https://phabricator.wikimedia.org/T64990#1892502 (awight) [07:14:14] Fundraising-Backlog, MediaWiki-General-or-Unknown: Investigate porting GeoIP for HHVM or using GeoIP2-php - https://phabricator.wikimedia.org/T64990#1892503 (awight) declined>Open Reopening, we need to run geoip as a fallback on donatewiki and paymentswiki when cookies are missing. The HHVM librar... [08:40:15] Fundraising-Backlog, MediaWiki-extensions-ContributionTracking, Technical-Debt: Remove premium and paypal things from ContributionTracking - https://phabricator.wikimedia.org/T121969#1892533 (awight) NEW [12:12:43] Blocked-on-Fundraising-Tech, Fundraising Sprint Yo La Tengo, Fundraising Sprint Zapp, Fundraising Tech Backlog, and 429 others: fulcontrol - https://phabricator.wikimedia.org/T121975#1892656 (LordLSDlite) NEW a:admin [13:13:07] Fundraising Sprint Zapp, Fundraising-Backlog, Traffic, Unplanned-Sprint-Work, operations: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1892741 (BBlack) >>! In T121922#1891801, @faidon wrote: > The only fix I see for now (bes... [13:33:28] (CR) Aklapper: "@Sherah: This patch has been sitting here for more than a year without review or merge and is among the oldest unreviewed ones in Gerrit. " [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/166565 (owner: Ssmith) [16:48:17] (Abandoned) Awight: Merge branch 'master' of ssh://gerrit.wikimedia.org:29418/mediawiki/extensions/DonationInterface into HEAD [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/166565 (owner: Ssmith) [17:26:16] Fundraising Sprint Zapp, Fundraising-Backlog, Traffic, Unplanned-Sprint-Work, operations: Firefox SPDY is buggy and is causing geoip lookup errors for IPv6 users - https://phabricator.wikimedia.org/T121922#1892853 (faidon) On IPv4-only clients, geoiplookup.wm.org isn't used at all (the GeoIP co... [18:15:09] (CR) Aklapper: "Sigh, I blame Gerrit... Thanks and sorry for the hassle!" [extensions/DonationInterface] - https://gerrit.wikimedia.org/r/166565 (owner: Ssmith) [19:05:36] (PS1) Krinkle: Clean up ext.centralNotice.geoIP qunit tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/260208 [19:05:38] (PS1) Krinkle: Fix fallback to geoiplookup.wikimedia.org for empty IPv6 geo cookies [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/260209 [19:05:54] ejegg|away: AndyRussG: ^ [19:13:01] Krinkle: nice, you figured it out? looking... [19:39:15] (CR) Ejegg: [C: 1] "Looks good to me, but I'll wait for AndyRussG to weigh in." [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/260209 (owner: Krinkle) [21:07:55] ejegg|mobl: It may not be the only problem, but it's certainly one of the problems. [21:10:07] (PS2) Krinkle: Clean up ext.centralNotice.geoIP qunit tests [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/260208 [21:11:06] (PS2) Krinkle: Fix fallback to geoiplookup.wikimedia.org for empty IPv6 geo cookies [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/260209 [21:17:46] (PS3) Krinkle: Fix fallback to geoiplookup.wikimedia.org for empty IPv6 geo cookies [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/260209 (https://phabricator.wikimedia.org/T121938) [21:19:31] ejegg|mobl: AndyRussG: I've elaborated in my commit message to explain how this regression came to be. [21:20:01] From what I can tell, the currently deployed code *never* results in a valid geolocation for any IPv6 connection. Any Geolocation that does happen for IPv6 seems like an anomaly. [21:20:16] I've added a test case for it as well (which was missing). [21:20:19] Krinkle: arrrrg OK. So this is _the_ bug? [21:20:30] Thank you for finding it, BTW! [21:20:36] yw :) [21:21:27] Well, that's embarassing [21:21:32] (commit message info) [21:21:46] There is a XX default which was preserved from the old code [21:21:53] But it's in the part that was refactored [21:22:18] out to ext.centralNotice.display.state.js [21:23:18] I'll be able to look at this in detail this evening so we should be able to deploy first thing Monday morning [21:23:23] Krinkle: ^ [21:24:01] AndyRussG: Yeah, no doubt XX was preserved in the display code for choosing banners. [21:24:09] But not when deciding to load the geoiplookup fallback [21:24:16] that is now agnostic from the render code [21:24:19] which is a good separation to have [21:24:26] but the tolerance for .length=0 was kept it seems [21:24:28] The old code was completely intertwined geoIP and banner display stuff [21:24:37] which is a remnant of when these were intertwined, exactly [21:25:05] If parsing the cookie results in country: '' then most certainly the other fields are empty as well, ergo, we shoudl do a geoiplookup [21:25:17] certainly doesn't hurt at that point. [21:25:44] Krinkle: can you point me to serve-side GeoIP code that would also ensure I can understand all the pieces here? [21:25:48] If you apply my patch with the test part only and keep the main code as in the current master you'll see the test case failing [21:26:14] I think we can force Jenkins's hand for the test patch, no? [21:27:46] AndyRussG: https://github.com/wikimedia/operations-puppet/blob/2a906c6fe90930cbbb09fc26018ccf53a1dec527/templates/varnish/geoip.inc.vcl.erb#L214 [21:27:51] AndyRussG: I separated it. They are both passing. [21:27:55] No need to force anything. [21:28:19] I'm just saying my second patch's test case fails if you apply it partly (on purpose I mean) for you to see that the current code is broken. [21:28:21] Ah ^ OK I understand what you mean [21:28:28] Yeah got it [21:28:33] That's good [21:29:17] Rrrrg I had no idea any significant number of users were on IPv6 [21:29:51] * AndyRussG scolds self for ignorance [21:38:49] Krinkle: wasn't there also some problem server-side? I remember paravoid checking something but I wasn't clear what it meant [21:39:41] Ah looks like that was somehow a way to verify the Firefox SPDY bug [21:39:46] AndyRussG: In some circumstances, Firefox users on IPv6 may not succeed in using the geoiplookup/ipv4 fallback because Firefox wrongly re-uses the Ipv6 connection to en.wikipedia for geoiplookup. [21:39:49] Yeah [21:39:53] but that's a relative minority. [21:39:54] https://phabricator.wikimedia.org/T121922#1891801 [21:39:58] Right now we're not even hitting that code path [21:40:06] because of the bug in JS [21:40:21] Huh OK [21:40:33] So what was it that Faidon was seeing? [21:41:42] Maybe some other source (on our sites or elsewhere) hitting the geoiplookup endpoint? [21:41:44] AndyRussG: He was opening en.wikipedia en geoiplookup.wikimedia in separate tabs directly [21:42:08] And also yeah, it might be triggered from some legacy code somewhere, and there might also be corrupt cookies. [21:42:14] in which case it does trigger the fallback [21:42:20] Ah OK hmmm [21:42:42] Yeah I'm pretty sure I've seen an extension that called geoiplookup itself [21:42:48] When I clear cookies and localstorasge in firefox and open 'https://en.wikipedia.org/wiki/Main_Page' there is no request made to geoiplookup.wikimedia.org in the network inspector. And no banner and an empty Ipv6 geo cookie. [21:42:51] same in Chrome [21:43:00] because the JS is never even trying right now [21:43:07] OK [21:43:09] Gotcha [21:43:45] once we fix that, Firefox might still come up empty, but at least it'll work in the majority of other desktop browsers and mobile browsers. [21:44:50] I'm anxious to find out how much fundraising increase this effectively oneline patch (remove lenght==0 condition) will do [21:47:22] Krinkle: everything indicates it'll be quite a bit! [21:48:08] I was also totally wrong yesterday morning in thinking maybe this isn't contributing to the discrepancy we'd seen before, it definitely is, a lot [21:49:03] Fortunately there's still a good bit of time left in the campaign [23:47:07] Hey — is there a page that shows the current funds raised vs the goal for 2015-2016? [23:47:18] https://frdata.wikimedia.org/ only shows year 2000 :-( [23:47:58] and includes a row in campaign-vs-amount.csv entitled "yourmom" [23:47:59] yourmom,test,28,2.023572,2011-11-19T02:15:07,10.0,58.78,2.099286,2011-10-27T23:47:24 [23:48:13] ooglek: I believe not [23:48:51] Check back on Monday if u want more details, it's not the aspect of this stuff that I deal with [23:48:56] gtg!