[10:54:36] (PS1) Legoktm: Use SPDX 3.0 license identifier [extensions/CentralNotice] - https://gerrit.wikimedia.org/r/401966 (https://phabricator.wikimedia.org/T183858) [12:00:37] (PS13) Jgleeson: DonationStats now tracking average processing times [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 [12:15:17] (CR) jerkins-bot: [V: -1] DonationStats now tracking average processing times [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 (owner: Jgleeson) [13:11:12] fr-tech, is there a way to force a jenkins CI run on a particular patch? [13:28:16] jgleeson try adding a comment that just says 'recheck' [13:41:47] (CR) Jgleeson: "recheck" [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 (owner: Jgleeson) [13:44:06] thanks! [13:46:14] jenkins hit a permission problem during the tests I think so I wanted to rerun the tests to see if it goes away second time around. This time is passed [13:46:26] it* [13:47:00] 12:00:45 git.exc.GitCommandError: 'git clean -x -f -d' returned with exit code 1 [13:47:00] 12:00:45 stderr: 'warning: failed to remove sites/default/files/ [13:47:00] 12:00:45 warning: failed to remove sites/default/settings.php' [15:04:17] man does it seem questionably wise to even be using a computer at this point [15:05:10] well on the basis that you're not running windows... [15:05:14] https://github.com/torvalds/linux/commit/a89f040fa34ec9cd682aed98b8f04e3c47d998bd#diff-678874d00bf0df04f6f427f16f1dea36 [15:05:39] wow [15:06:40] and we only sort of understand the implications for linux because it's open [15:06:41] ok, I retract the earlier reply [15:06:49] M$ and apple are mum af [15:07:04] well on the basis that you're not running windows (or an intel chip)... [15:08:10] it's almost as if allowing one megacorp to make all the world's cpus was a mistake [15:08:22] :) [15:08:26] who'd of saw that coming... [15:10:16] https://octodon.social/@joeyh/99292169221398042 [15:23:15] amazon and other "cloud" providers will be in real trouble [15:23:34] although it looks like they've known about it for some time [15:25:30] the idea of the worlds cloud providers overselling shared resources in recent years to then have disclose that "oh by the way, __ALL__ your private keys are available unencrypted in memory for all to access due to our tech being built on sand castles" [15:26:36] yep [15:29:24] hi all! [15:29:29] hey ejegg! [15:30:21] hi ejegg [15:30:28] sorry for the late start. back in bogota, and headed up to the old co-working spot, but I guess most offices are closed till the 6th. [15:30:29] rebooting some servers btw [15:30:40] holidays are srs bzns here [15:30:59] ses bzns? [15:31:11] srs bzns* ? [15:33:17] https://octodon.social/@joeyh/99292274107680707 [15:39:04] lol [15:39:10] jgleeson: serious business [15:42:58] oh cool, gnu social grew out of libre.fm [15:46:05] got it :) [16:00:16] jgleeson: what's your thinking on the usefulness of those multiple periods for donations/sec? [16:00:40] If we're just multiplying out, do the additional periods really mean anything? [16:00:59] maybe per minute and per hour for handy human-readability? [16:02:24] Personally I'm not keen on the average periods being multiplied out. I added some comments on it here https://phabricator.wikimedia.org/T179214#3770211 [16:02:25] Fundraising Sprint Asymmetrical Earth Theory, Fundraising-Backlog, FR-Ingenico: Ingenico audit wobble? 12/20 transactions not in Civi - https://phabricator.wikimedia.org/T183934#3875468 (Ejegg) Hi @MBeat33. Really sorry about this - I had turned off the nightly run to test the newer, faster version,... [16:04:29] however, I just added a few defaults that made sense to me. We could also achieve the same thing in the grafana data source query and just work from one [16:04:54] OK, this should be good for now [16:05:03] the prometheus output looks great! [16:06:06] I think once I finish the current switch over to a predominately label-based way of separating out the data, we'll likely change the processing rate stuff also [16:06:33] sounds good [16:07:17] although adding the functionality in the stats-collector do allow us to use compound stats for Prometheus labels, while maintaining a sensible api for non-Prometheus use cases has not been a walk in the park [16:07:55] ah yeah [16:08:49] in a world with no other obligations, it would be great to have a second monitoring system output class from the start [16:09:41] Fundraising-Backlog, FR-Ingenico: Close all old and unresolved GC orders - https://phabricator.wikimedia.org/T183190#3875503 (Ejegg) p:Triage>Normal [16:09:52] this is where I am so far with the stat-collector stuff, https://github.com/jackgleeson/stats-collector/compare/WIP/compoundIncrementing?expand=1 [16:11:00] ejegg, do you mean independent or Prometheus or of the civi stuff? [16:12:02] like a nagios exporter or something [16:12:56] ah yeah, that's the underlying idea [16:12:56] hopefully keeping it backend agnostic will allow that [16:14:05] although there is some work to be done to tidy up the current implementation. The more time I spend looking at it, the more I feel the current DonationStats class needs to extend the stats collector vs it's current "compositional" approach, but that can come in the next wave. [16:14:58] you think there's too much interplay between the two? Like DonationStats is using stuff that should be protected? [16:15:53] Or that DonationStats users should be able to call the underlying inc, sum, etc functions? [16:16:27] I kind of like having just one class that talks to the stats-collector backend [16:16:31] yeah more the latter, it feels like the singleton design encourages the facade-like extension model [16:17:22] otherwise you have an intermediate class which is populating a singleton to then be thrown away and resurrected when it wants to do something else [16:17:40] oh yeah, I can see that [16:17:49] it's the break between them two stages that I'm not 100% on with the current approach [16:19:38] at the rate it's evolving even for our single use case, I imagine the answers will present themselves once adding in the thank-you mailer stats and other areas [16:20:19] if I can keep that up, while maintaining the api for other non-prometheus use, I'll be happy with it [16:20:26] :) [16:20:51] I do really like this way of building things for re-usability from the outset [16:22:20] i am going for a quick hike, back in ~1hr [16:22:29] have fun! [16:22:33] enjoy! [16:26:01] (CR) Ejegg: [C: 2] "Output looks good! As per IRC, we can revisit the generation of the stats for different periods once we switch over the rest of the stats " [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 (owner: Jgleeson) [16:27:31] ejegg, before we release that patch, I wanna fire up my local end-to-end Prometheus test and confirm the new stats and labels work as expected and avoid what happened last time :| [16:27:41] ok, cool [16:28:06] I just did a cat /var/spool/prometheus/* | cut -d' ' -f 1 | sort | uniq -c [16:28:19] to make sure each metric/label only occurs once in the whole dir [16:28:37] and it looked good on my machine (TM) [16:28:47] you really are the wizard of unix oneliners :) [16:29:10] good way to test! [16:29:22] heh, and for each of them there's probably a cooler way to do it in awk [16:32:49] there's been a few times in the past I've tried using one of the PHP libs like goutte for scraping related purpose but then after getting frustrated at the magic that I revert back to good old curl/grep/cut/sort [16:33:21] and the code just becomes php issuing a shell comand [16:33:40] which then triggers my security paranoia :) [16:35:19] (CR) jerkins-bot: [V: -1] DonationStats now tracking average processing times [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 (owner: Jgleeson) [16:35:30] hehe, maybe python subprocess for param/env sanitization? [16:35:37] hrm? [16:35:53] this happened earlier [16:36:01] hence the "recheck" [16:36:05] I didn't believe it [16:36:07] ah, weird [16:36:17] 16:26:05 stderr: 'warning: failed to remove sites/default/files/ [16:36:18] 16:26:05 warning: failed to remove sites/default/settings.php' [16:36:18] 16:26:05 Build step 'Execute shell' marked build as failure [16:36:30] same permission issue I think [16:36:32] man, it's annoying when that happens on the gate&submit step [16:36:34] no idea what is causing it [16:36:42] I think I have to take off my c+2 and re-apply it [16:37:06] (CR) Ejegg: [C: 2] DonationStats now tracking average processing times [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 (owner: Jgleeson) [16:43:37] (Merged) jenkins-bot: DonationStats now tracking average processing times [wikimedia/fundraising/crm] - https://gerrit.wikimedia.org/r/392425 (owner: Jgleeson) [16:43:43] :) [16:44:27] although we probably need to work out why it doesn't have permissions to clear the affected files [17:11:47] Fundraising-Backlog, FR-Adyen, FR-Smashpig: Adyen capture failure - https://phabricator.wikimedia.org/T184200#3875720 (Ejegg) [17:49:25] Fundraising-Backlog, Analytics: Storage for banner history data - https://phabricator.wikimedia.org/T161635#3875876 (fdans) Open>declined @DStrine closing this task since there are no new updates. Feel free to reopen and ping us if you get back to it. [18:00:54] fundraising-tech-ops, Patch-For-Review: route incoming mail for civicrm.wikimedia.org to civi1001.frack.eqiad.wmnet - https://phabricator.wikimedia.org/T184120#3872981 (herron) Exim and DNS changes to support this have been merged and logs show mail to civicrm.wikimedia.org is now being routed to civi100... [18:22:17] fundraising-tech-ops, Patch-For-Review: route incoming mail for civicrm.wikimedia.org to civi1001.frack.eqiad.wmnet - https://phabricator.wikimedia.org/T184120#3876006 (Jgreen) Open>Resolved a:Jgreen >>! In T184120#3875922, @herron wrote: > Exim and DNS changes to support this have been merge... [18:55:03] Wikimedia-Fundraising, Mobile-Content-Service, Wikipedia-Android-App-Backlog, Wikipedia-iOS-App-Backlog, and 2 others: Run Big English fundraising on apps - https://phabricator.wikimedia.org/T181004#3876163 (Pcoombe) [18:55:08] Wikimedia-Fundraising, Android-app-feature-Feeds, Wikipedia-Android-App-Backlog, Wikipedia-iOS-App-Backlog, and 2 others: Big English Mobile App Fundraising ideas - https://phabricator.wikimedia.org/T180741#3876162 (Pcoombe) Open>Resolved [18:56:09] Wikimedia-Fundraising, Mobile-Content-Service, Wikipedia-Android-App-Backlog, Wikipedia-iOS-App-Backlog, and 2 others: Run Big English fundraising on apps - https://phabricator.wikimedia.org/T181004#3776010 (Pcoombe) Open>Resolved [Spreadsheet](https://docs.google.com/spreadsheets/d/1_zlH... [19:06:02] well dang. i went to check out the hippie-ish co working space, and it's out of business [20:57:23] Fundraising-Backlog, Africa-Wikimedia-Developers, MediaWiki-extensions-CentralNotice, Easy: BUG: Campaign date fields cannot be edited as text - https://phabricator.wikimedia.org/T97159#3876512 (Eugene233) @D3r1ck01 I am removing the tag** Africa-Wikimedia-Developers** because the bug does not ex... [20:57:46] Fundraising-Backlog, MediaWiki-extensions-CentralNotice, Easy: BUG: Campaign date fields cannot be edited as text - https://phabricator.wikimedia.org/T97159#3876514 (Eugene233) [20:58:52] fr-tech, I am signing off for tonight. Finally finished the updates to the stats-collector that should allow us to support the new Promehthus labels based naming convention (now that we can increment & decrement metic labels / compound stats). Remote branch for this update is here https://github.com/jackgleeson/stats-collector/compare/WIP/compoundIncrementing [20:59:39] jgleeson: have a good night! [20:59:52] thanks jgleeson, have a good one! [20:59:58] the next phase is to pull the updates into the civi project and refactor the DonationStats class to use labels alongside the existing counter behaviour, that's tomorrows task! [21:00:11] have a good one! [21:01:37] intel's public statement is very donald [21:01:45] Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. [21:01:54] we fucked up? FAKE NEWS [21:12:47] well they are not unique to intel right? But Intel is supposed to be the biggest offender. [21:14:04] some aspects are unique to intel [21:14:10] but it's definitely a bug and a flaw [22:09:16] hmm ok [22:21:48] dstrine: are you an intel sympathizer? [22:33:21] meltdown (the one that has a fix) is supposedly Intel specfic [22:34:06] Spectre is in like everything that has speculative execution branching [22:41:49] if you use the right parens their statement is truthy [22:42:17] (exploits are caused by a “bug” or a “flaw”) && (are unique to Intel products) == false [23:07:25] cwd: lol no all the computers I built on my own were amd. I was just randomly joining in on IRC conversations like I do. [23:07:57] :) [23:20:11] PROBLEM - check_mysql on payments1003 is CRITICAL: Slave IO: Connecting Slave SQL: Yes Seconds Behind Master: (null) [23:20:56] oops [23:25:11] RECOVERY - check_mysql on payments1003 is OK: Uptime: 561 Threads: 1 Questions: 866 Slow queries: 0 Opens: 25 Flush tables: 1 Open tables: 88 Queries per second avg: 1.543 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0 [23:35:30] https://i.redd.it/fhmfvcbtn3801.jpg [23:37:04] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Fr-backlog-cleanup-Q3_2017-18: Attempt to replicate replag issue in a simple piece of code to allow upstreaming of bug - https://phabricator.wikimedia.org/T180531#3876737 (DStrine) [23:37:23] Fundraising-Backlog, Fr-Ingenico-integration_2017-18, Fr-backlog-cleanup-Q3_2017-18: Create mustache forms for online bank transfer - https://phabricator.wikimedia.org/T171312#3876738 (DStrine) [23:38:04] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Fr-backlog-cleanup-Q3_2017-18: Engage seeing warning message when editing in Civi. - https://phabricator.wikimedia.org/T176371#3876739 (DStrine) [23:38:46] Fundraising-Backlog, Fr-backlog-cleanup-Q3_2017-18, MediaWiki-extensions-DonationInterface, Spike: Investigate update payments to REL1_28 - https://phabricator.wikimedia.org/T159273#3876740 (DStrine) [23:39:19] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Fr-backlog-cleanup-Q3_2017-18, Spike: Investigate searching civi by zipcode and specific radius - https://phabricator.wikimedia.org/T155679#3876741 (DStrine) [23:40:24] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Fr-backlog-cleanup-Q3_2017-18, Spike: Investigate searching civi by zipcode and specific radius - https://phabricator.wikimedia.org/T155679#2950811 (DStrine) I feel like this is a dupe. We have a usable version using longitude and latitude. You... [23:41:30] Fundraising-Backlog, Fr-backlog-cleanup-Q3_2017-18: Determine whether we should raise any phab tickets to track old unmerged code by Adam - https://phabricator.wikimedia.org/T175091#3876744 (DStrine) [23:41:51] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Fr-backlog-cleanup-Q3_2017-18: UKFC as Payment Instrument option for foreign check import - https://phabricator.wikimedia.org/T167355#3876745 (DStrine) [23:42:10] Fundraising-Backlog, Wikimedia-Fundraising-CiviCRM, Fr-backlog-cleanup-Q3_2017-18: Ask Coinbase to export CSVs in an encoding that is compatible with Excel - https://phabricator.wikimedia.org/T119913#3876746 (DStrine) [23:49:45] Fundraising Sprint Autotune Earphones, Fundraising Sprint Baudelaire Bowdlerizer, Fundraising Sprint Costlier Alternative, Fundraising Sprint Deferential Equations, and 11 others: Fix Coinbase file to support importing UTM fields - https://phabricator.wikimedia.org/T153791#3876794 (DStrine)