[00:31:50] sorry fr-tech, the day just flew by. I'll take a half day PTO [00:37:56] ejegg: sorry to put pressure on you but can I get you to review the civi upgrade tomorrow so I can deploy on (your) sun [00:38:51] I'l be online tomorrow to check for any issues [00:53:52] yep, I'll get that all squared away eileen [00:54:02] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: Banner preview: fix banner editor for users without CN admin rights - https://phabricator.wikimedia.org/T230857 (AndyRussG) [00:54:14] I was just looking over the upgrade today and didn't see much substantial change. [00:54:31] most of the things with big changed-line counts were just extracting a fn [00:55:37] thanks ejegg - there are a couple of upstream merges over the last couple of days & 5.18 hasn't quite been cut so I will do one more sync up with upstream when it's cut later today - I can tweak those patches or do a new one if you feel that would invalidate your digging to date [00:56:45] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: Replace hacky check for choiceData staleness with a real check, and send back data on how often it happens - https://phabricator.wikimedia.org/T229365 (AndyRussG) [00:56:46] I generally deploy the latest rc because that puts us on the latest code & while it's not unheard of for a regression to be found & fixed during the month it's in RC I watch those pretty closely & would react if anything came up that matters [00:57:38] & lol there lots of functions that need extracting.... [00:58:15] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: CentralNotice: Don't show live preview section for users without CN rights - https://phabricator.wikimedia.org/T226961 (AndyRussG) See also {T230857}. [00:58:44] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: CentralNotice alerts: Document new CN Hook - https://phabricator.wikimedia.org/T224700 (AndyRussG) [00:59:16] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice, Security: CentralNotice alerts: Specific alerts config for production monitoring - https://phabricator.wikimedia.org/T224931 (AndyRussG) [01:00:00] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice, Security: CentralNotice alerts: Add error handling - https://phabricator.wikimedia.org/T224699 (AndyRussG) [01:00:32] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: CentralNotice: Re-create automatic browser tests on node selenium - https://phabricator.wikimedia.org/T223634 (AndyRussG) [01:01:12] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice, Performance-Team (Radar): CentralNotice: Remove bannerController RL modules - https://phabricator.wikimedia.org/T224034 (AndyRussG) [01:01:56] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: CentralNotice: fix freegeoipLookup module and maybe integrate into other modules, or just remove it - https://phabricator.wikimedia.org/T224038 (AndyRussG) [01:02:25] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: Create Grafana graphs for CentralNotice impression rates for active campaigns - https://phabricator.wikimedia.org/T223932 (AndyRussG) [01:13:01] (PS1) Eileen: Fix missing db prefix [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/534716 [01:13:14] ejegg: if you are still around that db fail was a missing db prefix [01:13:27] I'm prob gonna self-merge that if need be [01:22:56] (CR) Ejegg: [C: +2] COALESCE the decile fields to '' [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/534696 (https://phabricator.wikimedia.org/T231538) (owner: Eileen) [01:23:12] (CR) Ejegg: [C: +2] Fix missing db prefix [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/534716 (owner: Eileen) [01:23:32] d'oh, i shoulda caught that in the first round of review [01:23:47] (Merged) jenkins-bot: COALESCE the decile fields to '' [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/534696 (https://phabricator.wikimedia.org/T231538) (owner: Eileen) [01:23:55] (Merged) jenkins-bot: Fix missing db prefix [wikimedia/fundraising/tools] - https://gerrit.wikimedia.org/r/534716 (owner: Eileen) [01:26:21] Fundraising Sprint Ivory and eggshell white are the same color, Fundraising Sprint Junebugs prefer July, Fundraising-Backlog, Fr-Q2-2019-cleanup-list, Patch-For-Review: Adapt ingress of CN data into Druid to EventLogging-based impression recording - https://phabricator.wikimedia.org/T186048 (A... [01:29:21] eileen: if you can use the same Change-Id for the big patch, gerrit will tell me what's different in the next PS [01:41:19] ejegg: ok great - I'll just amend it [01:42:26] (PS1) Eileen: Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/tools into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/534717 [01:42:39] (CR) Eileen: [C: +2] Merge branch 'master' of https://gerrit.wikimedia.org/r/wikimedia/fundraising/tools into deploy [wikimedia/fundraising/tools] (deploy) - https://gerrit.wikimedia.org/r/534717 (owner: Eileen) [01:44:45] !log tools revision changed from 643c48b26a to 1e405864d7 [01:44:46] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [01:48:05] hmm, payments-wiki has a decent deploy backlog [01:48:09] think i might push that out [01:48:47] (PS1) Ejegg: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/534718 [01:48:52] (CR) Ejegg: [C: +2] Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/534718 (owner: Ejegg) [01:53:06] thanks ejegg! I also fixed that minor tidy up you pointed out https://gerrit.wikimedia.org/r/#/dashboard/self [01:53:07] Fundraising-Backlog, MediaWiki-extensions-CentralNotice: Investigate error tracking and alerts for in-banner JS - https://phabricator.wikimedia.org/T215842 (AndyRussG) >>! In T215842#4945525, @Jdlrobson wrote: > I wrote a blog post about this here if you are interested: > https://medium.com/freely-sharin... [01:53:15] no herre https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/534570/ [01:53:17] oh cool [01:54:23] oh man, that $null = NULL is bringing back vague recollections of horrible test voodoo [01:54:59] Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice, Patch-For-Review: CentralNotice: Remove unused code for banner preview in banner editor - https://phabricator.wikimedia.org/T161907 (AndyRussG) [01:56:18] oh huh, I guess it was just to pass a var in to cache->set [01:57:08] Fundraising Sprint Murphy's Lawyer, Fundraising Sprint Navel Warfare, Fundraising Sprint Outie Inverter, Fundraising Sprint Prank Seatbelt, and 5 others: Clone button for CN campaigns - https://phabricator.wikimedia.org/T91078 (AndyRussG) [01:58:11] (CR) Ejegg: [C: +2] Switch Omnimail tests to headless. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/534570 (owner: Eileen) [01:58:27] just don't look! [01:58:49] I think I finally fixed those PEAR ones in core a while back [01:59:02] whew [02:00:57] (Merged) jenkins-bot: Merge branch 'master' into deployment [extensions/DonationInterface] (deployment) - https://gerrit.wikimedia.org/r/534718 (owner: Ejegg) [02:03:11] (PS1) Ejegg: Update DonationInterface submodule [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/534719 [02:03:29] (CR) Ejegg: [C: +2] Update DonationInterface submodule [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/534719 (owner: Ejegg) [02:03:33] (Merged) jenkins-bot: Switch Omnimail tests to headless. [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/534570 (owner: Eileen) [02:08:25] (Merged) jenkins-bot: Update DonationInterface submodule [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/534719 (owner: Ejegg) [02:08:50] alright, let's see how this goes [02:10:24] that's the deploy? [02:11:30] (CR) jenkins-bot: Update DonationInterface submodule [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/534719 (owner: Ejegg) [02:11:33] !log updated payments-wiki from 51d9ed79b6 to 04120169b0 [02:11:35] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [02:11:51] oh phooey, css cached? [02:12:45] hmm, force-reload makes it look good [02:13:16] I'll send an email around [02:15:02] ah dang, I'm going to roll back. [02:15:44] !log payments-wiki rolled back to 51d9ed79b6 [02:15:45] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [02:16:36] don't know why any live code is loading the orphan adapter, but I messed up setting the setGatewayDefaults method accessibility there [02:17:44] ???? [02:17:56] I don't get it, the fn is protected in all its incarnations [02:19:34] (PS6) Eileen: Add exportUi extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/533137 (https://phabricator.wikimedia.org/T228826) [02:19:36] (PS7) Eileen: Update afform [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532842 (https://phabricator.wikimedia.org/T228826) [02:19:38] what the heck generated this then? "PHP Fatal error: Access level to GlobalCollectOrphanAdapter::setGatewayDefaults() must be public (as in class GlobalCollectAdapter)" [02:19:38] (PS7) Eileen: Update contactlayouteditor in tandem [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532843 (https://phabricator.wikimedia.org/T228826) [02:19:40] (PS12) Eileen: Add extension to manage our query modifications [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532845 (https://phabricator.wikimedia.org/T228826) [02:19:42] (PS13) Eileen: Update deduper for 5.18 [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532844 (https://phabricator.wikimedia.org/T228826) [02:20:08] ah, probably just rsync shear [02:20:41] :-( [02:21:12] i mean, just a request that came in while some files were rsynced (rsyunc?) and others weren't [02:21:23] i.e. something that's not going to happen again [02:21:46] I think I can roll that forward again [02:22:59] well It seems like if failed quick [02:23:09] so if you try again the backout plan is easy [02:24:57] test CC donation worked [02:25:23] !log updated payments-wiki (again) from 51d9ed79b6 to 04120169b0... false alarm [02:25:25] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [02:25:50] dang I might have just overwritten my 'best' commit with an older one in gerrit [02:29:47] aw boo [02:29:54] git reflog to the rescue? [02:30:19] yeah I can recover it - not least because of this https://github.com/eileenmcnaughton/org.wikimedia.dedupetools [02:30:40] ahh, nice [02:30:52] hooray for extra-distributed systems [02:32:57] ooh, unintended change to amazon form :( [02:33:09] payment method now shows up ABOVE donation amount [02:33:18] ok, really will roll back for that [02:33:21] it's just weird [02:34:55] !log rolled back payments-wiki to 51d9ed79b6 [02:34:57] Logged the message at https://wikitech.wikimedia.org/wiki/Server_Admin_Log [02:35:08] ok, gonna call it a night and fix that amazon oddity tomorrow [02:36:12] ok [02:37:49] (PS7) Eileen: Add exportUi extension [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/533137 (https://phabricator.wikimedia.org/T228826) [02:37:51] (PS8) Eileen: Update afform [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532842 (https://phabricator.wikimedia.org/T228826) [02:37:53] (PS8) Eileen: Update contactlayouteditor in tandem [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532843 (https://phabricator.wikimedia.org/T228826) [02:37:55] (PS13) Eileen: Add extension to manage our query modifications [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532845 (https://phabricator.wikimedia.org/T228826) [02:37:57] (PS14) Eileen: Update deduper for 5.18 [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/532844 (https://phabricator.wikimedia.org/T228826) [02:53:26] (CR) jenkins-bot: Update DonationInterface submodule [core] (fundraising/REL1_31) - https://gerrit.wikimedia.org/r/534719 (owner: Ejegg) [02:54:42] Fundraising-Backlog, Fr-CentralNotice-Translation-Bugs, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: CentralNotice: When fetching banner settings, pull translation metadata only when necessary - https://phabricator.wikimedia.org/T205118 (AndyRussG) [02:55:12] Fundraising-Backlog, Fr-Q2-2019-cleanup-list: Compare data between new and old pipelines - https://phabricator.wikimedia.org/T207501 (AndyRussG) [02:58:07] Fundraising-Backlog: Investigate missing country and language fields on LandingPage events. - https://phabricator.wikimedia.org/T203501 (AndyRussG) [03:00:31] Fundraising-Backlog, Fr-Q2-2019-cleanup-list: Investigate missing country and language fields on LandingPage events. - https://phabricator.wikimedia.org/T203501 (AndyRussG) [03:03:33] Fundraising-Backlog, Fr-CentralNotice-Translation-Bugs, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: Fix CentralNotice rebuilding of Translate message cache - https://phabricator.wikimedia.org/T205483 (AndyRussG) [04:11:11] Fundraising-Backlog, Fr-CentralNotice-Translation-Bugs, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice, and 3 others: CentralNotice must not query master on GET request (page views) - https://phabricator.wikimedia.org/T216287 (AndyRussG) [04:12:39] Fundraising Sprint Window dressing is mostly olive oil, Fundraising Sprint XML ate my homework, Fundraising-Backlog, Fr-Q2-2019-cleanup-list, MediaWiki-extensions-CentralNotice: Consider not displaying protection log entries in RecentChanges caused by C... - https://phabricator.wikimedia.org/T210101 [06:26:41] (PS1) Eileen: [WIP] Add not-yet-working attempt to log into Silverpop [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/534736 (https://phabricator.wikimedia.org/T230509) [06:28:55] Fundraising Sprint Never Ending Query, Fundraising Sprint Office  , Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog, and 2 others: Scrape HTML from IBM UI and bring queries into civi - https://phabricator.wikimedia.org/T230509 (Eileenmcnaughton) I've been battling thi... [06:31:14] (CR) jerkins-bot: [V: -1] [WIP] Add not-yet-working attempt to log into Silverpop [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/534736 (https://phabricator.wikimedia.org/T230509) (owner: Eileen) [06:35:10] Fundraising-Backlog, FR-Civi-Dedupe: Civi dedupe: if existing CID has email opt-out, ask script to keep that when merging new ones - https://phabricator.wikimedia.org/T232151 (CCogdill_WMF) Hm, I would disagree here. I might expect a donor would unsubscribe their old email address knowing that they only... [06:39:33] Fundraising Sprint Never Ending Query, Fundraising Sprint Office  , Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog, and 2 others: Scrape HTML from IBM UI and bring queries into civi - https://phabricator.wikimedia.org/T230509 (CCogdill_WMF) @Eileenmcnaughton let me k... [06:40:46] Fundraising Sprint Never Ending Query, Fundraising Sprint Office  , Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog, and 2 others: Scrape HTML from IBM UI and bring queries into civi - https://phabricator.wikimedia.org/T230509 (Eileenmcnaughton) Thanks - I'll see if a... [06:41:14] Fundraising Sprint Never Ending Query, Fundraising Sprint Office  , Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog, and 2 others: One-time import of target smart data into IBM -- how to do this? - https://phabricator.wikimedia.org/T231538 (CCogdill_WMF) Great, thanks... [07:03:28] (PS5) Eileen: Stock CiviCRM 5.18rc [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/534244 (https://phabricator.wikimedia.org/T228826) [07:07:23] (PS4) Eileen: Reapply WMF patches [wikimedia/fundraising/crm/civicrm] - https://gerrit.wikimedia.org/r/534249 (https://phabricator.wikimedia.org/T228826) [13:36:07] Fundraising-Backlog, FR-Civi-Dedupe: Civi dedupe: if existing CID has email opt-out, ask script to keep that when merging new ones - https://phabricator.wikimedia.org/T232151 (MBeat33) Thanks, @CCogdill_WMF I should have been clearer, I was thinking only of exact email address matches, but yes, let's co... [13:52:33] tzag fr-tech i'm watching the dutchphp talk that jgleeson sent out [13:52:49] "RTFM" - it's really good [14:18:36] Fundraising-Backlog, FR-Civi-Dedupe: Civi dedupe: if existing CID has email opt-out, ask script to keep that when merging new ones - https://phabricator.wikimedia.org/T232151 (CCogdill_WMF) Oh sorry! If we're talking exact matches, yes, I think they should be opted out until the donor tells us otherwise.... [15:28:41] Fundraising Sprint Quick and the Deadlocked, Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog, Recurring-Donations, Patch-For-Review: trigger a second email in recurring upsell to denote the recurring part - https://phabricator.wikimedia.org/T228162 (DStrine) Here is a... [15:55:54] Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog: Enable Visa, Mastercard, Amex, and JCB for Adyen in Ireland - https://phabricator.wikimedia.org/T230621 (XenoRyet) a:XenoRyet [15:56:12] Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog: Center payment icons on payments page for user view - https://phabricator.wikimedia.org/T231391 (XenoRyet) a:XenoRyet [16:06:39] fundraising-tech-ops: Issue new SSL Client Certificate for ccarter - https://phabricator.wikimedia.org/T232138 (Dwisehaupt) ccarter contacted me via email and suggested doing this on the 10th as he is out of the office. Will get this done then. [16:07:58] fundraising-tech-ops: Issue new SSL Client Certificate for jcuriel - https://phabricator.wikimedia.org/T232139 (Dwisehaupt) @JCuriel was provided with the cert and password. He was working on getting it installed in his browser but didn't complete as he had a deadline to meet. I will check back with him earl... [17:14:40] Fundraising Sprint Quick and the Deadlocked, Fundraising Sprint Rocky Horror Presentation Layer, Fundraising-Backlog, Recurring-Donations, Patch-For-Review: trigger a second email in recurring upsell to denote the recurring part - https://phabricator.wikimedia.org/T228162 (Cstone) The first r... [18:08:15] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [19:08:55] fr-tech here's a fix for the Amazon form in the new no-tables layout: https://gerrit.wikimedia.org/r/534858 [19:29:54] ejegg when I try and load the amazon form it takes me to a real amazon login page, am I missing a setting somewhere? [19:30:05] ejegg how do you access that widget? i'm getting the same as cstone [19:30:14] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [19:30:14] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [19:30:32] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Cannot make SSL connection. [19:32:58] mepps and cstone yep, you need to log in with test credentials [19:33:12] RECOVERY - check_gcsip on payments2003 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 0.164 second response time [19:33:12] RECOVERY - check_gcsip on payments2001 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 0.157 second response time [19:33:16] you can manage those at the amazon pay console [19:33:24] is there a different login url it wasn't accepting my credentials on that page [19:33:29] but... lemme add those to a sandbox file [19:33:47] cstone so that URL has a sandbox param on it, meaning real amazon accounts don't work [19:34:09] I'll put a login & pw up in the settings repo [19:35:16] RECOVERY - check_yubico on frauth2001 is OK: HTTP OK: HTTP/1.1 200 OK - 311 bytes in 0.128 second response time [19:35:26] ah I see, I was trying the sandbox one I thought we had set up but maybe its the wrong password [19:38:16] cstone and mepps I added a comment to the 20-DI-Accounts.php file in the payments-wiki-testing folder in the settings repo on frpm [19:38:26] thanks! [19:38:29] nice ejegg [19:43:49] you can also add more sandbox donor accounts with different types of backing payment methods via the amazon pay console [19:55:19] oh, they made the permissions more fine-grained. I'll grant test account admin to all the fr-tech accounts [19:58:33] ok, that's all granted. The URL to manage test accounts is https://sellercentral.amazon.com/gp/pyop/seller/testing/ref=ps_pyoptest_dnav_home_ [20:03:12] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:05:14] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:05:14] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:08:14] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:10:14] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:10:16] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:13:12] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:15:16] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:15:16] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:18:12] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:18:42] dang, more ingenico connectivity problems [20:20:15] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:20:15] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:23:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:25:15] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:25:15] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:26:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [20:28:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:29:27] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Cannot make SSL connection. [20:30:17] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:31:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [20:32:21] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Cannot make SSL connection. [20:35:15] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:35:15] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:36:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [20:38:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:40:15] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:40:15] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:41:07] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Cannot make SSL connection. [20:41:11] RECOVERY - check_gcsip on payments2002 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 0.167 second response time [20:45:15] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:46:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [20:48:17] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:50:17] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:50:17] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:51:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [20:53:13] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:55:15] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:55:17] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [20:56:05] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Cannot make SSL connection. [20:58:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:00:13] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:00:13] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:05:15] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:05:15] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:06:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [21:08:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:10:17] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:10:17] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:11:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [21:13:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:15:17] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:15:17] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:16:17] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Socket timeout after 61 seconds [21:18:11] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:20:11] PROBLEM - check_gcsip on payments2001 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:20:11] PROBLEM - check_gcsip on payments2003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:20:31] PROBLEM - check_yubico on frauth2001 is CRITICAL: CRITICAL - Cannot make SSL connection. [21:25:01] PROBLEM - check_gcsip on payments2002 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:25:01] RECOVERY - check_gcsip on payments2001 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 0.163 second response time [21:25:01] RECOVERY - check_gcsip on payments2003 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 0.166 second response time [21:25:17] RECOVERY - check_yubico on frauth2001 is OK: HTTP OK: HTTP/1.1 200 OK - 311 bytes in 0.121 second response time [21:26:11] RECOVERY - check_gcsip on payments2002 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 0.168 second response time [21:28:17] PROBLEM - check_gcsip on payments1003 is CRITICAL: CRITICAL - Socket timeout after 121 seconds [21:31:23] RECOVERY - check_gcsip on payments1003 is OK: HTTP OK: HTTP/1.1 200 OK - 343 bytes in 4.556 second response time [22:30:43] eileen: what do you think about this solution for creditnote_id? https://gerrit.wikimedia.org/r/534893 [22:31:58] yeah so that would improve it - I also put this up https://github.com/civicrm/civicrm-core/pull/15232 [22:33:25] eileen: ah, sure [22:33:46] cool, I'll +2 yours for this weekend's deploy [22:34:10] It might be controversial - we'll see [22:34:27] the people that added that code into core don't think it's 'just their requirement' [22:34:55] because 'everyone needs sequential credit note ids - our accountant says so....' [22:35:54] I wonder how fr-online got on with the import [22:36:37] lol [22:37:27] and what if you've purged the contributions from a decade ago? [22:40:37] derp, why can i not push to my fork of civicrm-core? says connect to github.com port 22 timed out, but I can pull just fine [22:42:16] ok, that worked [22:56:25] https://github.com/civicrm/civicrm-core/pull/15235 [23:02:21] yeah - the community can get a bit obsessed with their use case [23:04:28] OK, I can accept it, but even if you need those to be sequential, I can't imagine they would prohibit you archiving data from more than a decade ago [23:05:45] anyway, the patch I pushed up should keep the sequential-ness, just finding the next ID in a smarter way [23:14:19] eileen: hmm, getting 500 errors on the rest api endpoint trying to test the deduper update [23:14:39] but... no text in the response? [23:14:41] digging [23:15:34] some more obvious progress/error indications for that 'find duplicates' button might be nice [23:17:05] ejegg: hmm - I will retest - [23:17:20] & yeah progress indicators would be good! [23:18:15] ejegg one super minor update I just added https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/civicrm/+/534896/ [23:18:16] greyed out button is at least something, but something with motion seems to be the current trend for 'search in progress' [23:18:53] +2ed [23:19:03] also this - hopefully just a rubber stamp https://gerrit.wikimedia.org/r/#/c/wikimedia/fundraising/crm/+/534548/ [23:21:13] I would definitely like to improve that progress - esp on the batch actions [23:21:24] although maybe if I publish the extension someone will do it for me [23:22:10] hehe [23:23:02] I want to move our conflict resolution into the extension too [23:23:20] k, +2ed that too [23:23:29] if I can just figure out this awful silverpop login stuff I might be able to work on it :-) [23:23:35] & intials [23:24:16] ejegg: I just pulled latest approved code + deduper patch onto staging [23:24:25] it seems to work - where are you hitting 500s? [23:24:43] oho, allowed memory size exhausted! [23:24:58] maybe I'll try with a smaller number of contacts [23:25:38] yep, dialing dupe limit back to 100 gives me nice speedy results [23:25:56] ah - how many were you trying? locally or on staging? [23:26:04] ccccccknfuvhcviicrlflhfgrcugdjrnikdklcuvjrrf [23:26:07] opps [23:26:07] locally, with the default 1000 [23:26:15] hmm that should be OK.... [23:26:16] and memory limit of 128MB [23:26:46] & are there are a lot of matches to find on your local/ [23:27:10] yeah, all those "es, test" ones are pretty dupe-y [23:27:50] or hmm, a lot of them have unique emails. but there are a good number of duplicates [23:28:14] changing the number does give different results now! [23:29:31] yeah - I does sound a bit dodge but on live memory was never the bottleneck [23:40:55] ok, it's dying in the while ($dao->fetch()) {} loop inside Finder::dupes() [23:41:17] I guess my local db has a pretty combinatorial number of similar emails [23:41:25] err, pairs of similar emails [23:41:48] but the code changes look reasonable [23:42:13] Yeah & that issue is not new in this set of changes [23:42:37] & it's nothing however many GB of RAM we have on live can't deal with.... [23:43:12] ok, +2ed [23:43:42] got to head out, but I'll hopefully be able to take a look at the silverpop login voodoo on monday [23:44:16] I'll try to check in on the upgrade too [23:46:59] see ya!