[09:17:07] silverwhitefish: whoops, sorry for the late reply, I didn't notice you continued the convo and pinged me, but I'm not sure the the %s is relating to, and I don't have config access or root access or access to the server mailman is running on or etc [10:29:07] hi! I've got an extension that adds tags to recent changes using a RecentChange_save handler - anyone know how I should get a test onto that handler? [10:29:59] do i need to somehow fake up a bunch of revisions? [10:33:19] the code is question is that in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/702798 [10:42:18] the code I would like to get a text on is essentially: `public function getTagsForIds( int $oldId, int $newId ): array` [15:18:45] inductiveload: you can use an integration test (ie. actually save a revision and see if the hook does what it's supposed to do), or a unit test (where you can pass in mock objects, or mutable revision objects) [15:20:14] tgr: is there a good example of the former kind? [15:21:50] it'd be kind of awkward to do the unit test kind, because there's an API under the function I want to test that operates by rev ID, and I don't really want to have to reach and and mess with it at that level [15:23:04] check some tests subclassing MediaWikiIntegrationTestCase [15:23:32] e.g. under /tests/phpunit/integration in core [15:23:38] (remember that I only really started PHP last week, so you're talking to a bona fide idiot) [15:24:00] at least in terms of MW's PHP stuff ^_^ [15:24:13] for other things, opinions vary [15:25:19] that class has a method (doEdit or something like that?) that can be used for doing the edit, and methods for setting global variables and services for the duration of the test [15:26:21] aha [15:26:25] sounds good [15:26:44] i was prodding around in phpunit/includes [15:26:51] this looks much more promising [15:28:44] phpunit/includes is a mix of unit and integration tests which haven't yet been moved to their proper place [22:19:10] Platonides: wow, https://lists.wikimedia.org/hyperkitty/list/daily-image-l@lists.wikimedia.org/thread/5TOP2JJ5WZJ2PC6PKFZTITF7BFZ2H62A/ looks like a disaster. � everywhere :| [22:19:43] however, it showed correctly when sent to myself [22:19:49] so perhaps it's just hyperkitty? [22:20:07] yeah, the version that went to the list looks fine [22:20:27] it has Content-Type: text/plain; charset="utf-8" [22:20:40] when running through jsub it's fialing with UnicodeEncodeErrors [22:21:56] ok, that seems fixed [22:22:11] ugh, it's still using Python 2 [22:23:00] what did you expect? :D [22:23:00] the git repo is https://github.com/toollabs/daily-image-l btw [22:23:18] I expected I would have ported it back in 2015 when I last touched it! [22:23:26] the line that was failing on jsub wasn't even on the repo [22:23:31] * legoktm shames 2015-self [22:23:34] o.O [22:23:36] xD [22:24:40] let's see if the cron works from now on [22:25:15] If a user is editing from an IPv6 address, and someone applies an autoblock to the user, do other users under just that address get blocked, or does it apply to the entire /64 range containing that address? [22:25:44] mahir256: just that IP, there's no special handling for IPv6. If you want to block the /64, use a range block on that /64 [22:25:54] Platonides: fingers crossed. thanks for looking at it :) [22:26:19] eh [22:27:03] I came accross that task yesterday when seeing if T286122 was a duplicate [22:27:04] T286122: Make auditing members of mailing lists bound to a user right easier - https://phabricator.wikimedia.org/T286122 [22:27:52] legoktm: so basically autoblocks are practically useless for accounts with IPv6 addresses? (can't block a range if I can't find out what it is) [22:28:28] mahir256: it depends on how smart the IPv6 user is, I guess [22:29:15] https://www.mediawiki.org/wiki/Help:Range_blocks/IPv6 links to https://en.wikipedia.org/wiki/User:TonyBallioni/Just_block_the_/64 [22:30:32] there was an RfC at one time to have MW treat all IPv6 addresses in the same /64 as one IP but it didn't get accepted IIRC [22:31:52] yeah, TonyBallioni's advice is great (and should be required reading for any admin), but unless the account accidentally edits anonymously even once (exposing its own IP), it's impossible to apply a good range block akin to that provided for an IPv4 autoblock on the account [22:33:28] I think it would make sense to have a setting to /64 IPv6 blocks [22:40:39] Some related tickets include T26294 and T179454 (I could not find a ticket pertaining specifically to /64 IPv6 autoblocks) [22:40:40] T26294: Should block IPv6 addresses at /64 instead of /128 - https://phabricator.wikimedia.org/T26294 [22:40:41] T179454: AbuseFilter range blocks should be smarter - https://phabricator.wikimedia.org/T179454 [22:42:14] https://www.mediawiki.org/wiki/Requests_for_comment/IPv6_contributions_and_talk_pages is what I was remembering [22:42:45] https://phabricator.wikimedia.org/T112325#1668806