[11:10:29] Vulpix, re. your tip about manageJobs yesterday. I've just added some documentation to https://www.mediawiki.org/wiki/Manual:ManageJobs.php . If you have any experience with the script (or even if you don't), could you double-check to see if it looks good? [11:12:41] Jhs-: I'd say you've done a very good job documenting it. Very explicative, Thanks! [11:14:35] Vulpix, thanks! The only problem is that I can't actually run it myself (I need to ask a guy with access to the server we use to run any commands...), so I don't know what the output would look like, for instance [11:15:07] also, i'm not sure about the command syntax -- should it be --action delete or --action=delete ? (I _think_ the former, but again: not sure) [11:16:05] --action=delete [11:31:28] 👍 [11:43:26] hello [11:43:28] me again [11:43:43] I've disabled GoogleLogin pending a site update to 35 [11:43:53] but suddenly I can't login... There seems to be a problem with your login session; this action has been cancelled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again. [11:44:28] same in an incognito window [11:45:21] sorry, ignore me [11:45:36] Was testing $wgReadOnly... apparently it just stops me loggin in! [11:47:55] https://www.mediawiki.org/wiki/Manual:$wgReadOnly#Upgrading sigh [12:31:19] Hi, I'm using the official docker image. I'm currently struggling with file uploads. Should file uploads work by default? [12:45:10] hello [12:45:39] I'm trying to upate to 35 using git, but I'm seeing Your branch is up to date with 'origin/REL1_35'. / modified: skins/Vector (new commits) [12:46:22] and several similar messages [12:46:29] git submodule update --recursive didn't fix the issue [12:46:58] Have you made modifications inside the Vector folder? [12:47:47] Reedy: no, nor the others [12:48:04] there is a list of about 6 extensions and three skins [12:48:22] the diff shows two different commits [12:48:56] e.g. git diff extensions/TitleBlacklist # -Subproject commit 84c647d9151ce9328b06f8b66784d49db097e894 / +Subproject commit c8a084459957b1232912e1295c3e6bb447f19d99 [12:49:12] extensions/TitleBlacklist says REL1_35 [12:50:20] Hmm, I see commit 84c647d9151ce9328b06f8b66784d49db097e894 (origin/wmf/1.35.0-wmf.32, origin/wmf/1.35.0-wmf.31, origin/wmf/1.35.0-wmf.30) [12:50:21] probably want a git reset or some encantation in the mw core folder before running submodule update again [12:50:41] thats abotu 20 comits behind REL1_35 [12:50:49] yeah [12:52:44] no joy [12:52:47] same issue [12:52:52] same list of extensions and skins [12:53:07] its like the extensions have moved on, but the submodule wasn't tagged [12:53:13] (if I had to guess) [12:54:11] That sounds like the behaviour I get when switch between release branches and haven't run submodule update yet [12:54:18] I've set all extensions to REL1_35 by hand [12:54:30] That's probably the problem/reason [12:54:52] https://phabricator.wikimedia.org/P15499 [12:55:03] assuming I dont' want to be at REL1_35 on all extensions, do I manually set the checkout to match the core? [12:55:11] I mean, what the core thinks it should be [12:56:17] I was missing the --init ... [12:56:23] fatal Fatal fatal [12:56:59] this is going from bad to worse [12:57:17] Ahhh.. init expects them to not be there? [12:58:20] wow... seems... fixed [13:06:19] thanks so much Reedy, I was pulling my hear out [13:06:21] hear [13:06:24] hair [13:08:38] Reedy and/or Vulpix, do you know what will happen if I delete all the abandoned jobs from the job table? [13:09:10] my "test article" (which is having issues) is this one: https://lokalhistoriewiki.no/wiki/Hadeland_Glassverk [13:09:29] Check the category "Glassverk", you'll see that it's not there, even after multiple edits [13:10:17] Are you sure it's not just your very low job run rate? :P [13:10:40] yeah, completely sure [13:10:49] also, it's not low, it's set to 1, which is the max [13:11:11] It's the max? [13:11:23] yeah, it's between 0.01 and 1 [13:11:40] 1 = do one job per 1 request on average [13:11:48] 0.01 = do one job per 100 requests [13:12:07] You can use > 1 [13:12:12] 1 definitely isn't the max [13:12:34] Whether you'd want to, of course, is a different issue [13:12:37] ah, interesting [13:12:41] i misunderstood then [13:13:00] but anyways, there are 1,000 abandoned jobs which i just can't force to run [13:13:06] manageJobs.php did nothing :( [13:13:09] And if you set it higher, you'd probably want to make sure you set $wgRunJobsAsync [13:14:29] so my last idea now is to remove all the abandoned jobs from the jobs table and do null edits to try and trigger new jobs. do you think that would work? [13:14:55] It might fix some issues [13:15:06] But wouldn't surprise me if some links tables, counts and such end up out of skew [13:22:29] Honestly, setting $wgRunJobsAsync to true usually leads to broken jobs and you don't even notice what's happening. There are so many reasons that can make the "http connection to itself" used by $wgRunJobsAsync to fail... [13:23:47] Once you bring back those abandoned jobs to pending with manageJobs.php, why don't you run runJobs.php directly? That way you could look at the output and see if they're failing with an error message [13:26:57] Vulpix, they didn't return to pending after running manageJobs.php :( [13:28:51] modified: vendor (untracked content) [13:28:59] Looks ... OK...? [13:29:21] had switched itself to master... I put it back on REl1_35 [13:29:26] I was playing with composer [13:30:44] oh flip.. after update my whole site is down... I wonder what I got wrong [13:30:57] is currently unable to handle this request HTTP ERROR 500 [13:31:26] Jhs-: Well, that's... surprising. Looking at the code, they should be pushed to run again (I'm not sure if their state is simply changed or new jobs are inserted as a copy of those abandoned ones). However I have no idea if there's some bug on that code or something else may be failing... [13:31:45] !blank | faceface [13:31:45] faceface: A blank page or HTTP 500 error usually indicates a fatal PHP error. For information on debugging (including viewing errors), see . [13:32:41] just looking at the log now [13:33:32] it's an issue with semantic bundle [13:35:15] Vulpix, here is the pastebin from running manageJobs.php + showJobs.php --group: https://paste.toolforge.org/view/a5707ee9 [13:36:02] We've tried several varieties (both = and space after the parameter work the same, btw), and the only thing that changes in subsequent runs is the "Last re-push time" [13:36:26] Jhs-: Ah, hmmmm... try using = to separate from argument name and value instead of space [13:36:33] php maintenance/manageJobs.php --action=repush-abandoned --type=refreshLinks [13:37:03] At least the counts of "Re-pushed 0 job(s) [0 skipped]." should be different than 0 [13:37:46] Vulpix, we tried that too, same result except the time changed [13:37:54] !class JobQueueGroup [13:37:54] See https://doc.wikimedia.org/mediawiki-core/master/php/classJobQueueGroup.html [13:40:23] I'd say there's some bug in the code that gets all abandoned jobs... [13:44:20] Vulpix, there is some skip logic in https://github.com/wikimedia/mediawiki/blob/master/maintenance/manageJobs.php#L78-L81 , could that be the culprit? [13:46:14] Jhs-: If that was the cause, the output would indicate "X skipped", where X > 0. But that's not the case... [13:46:33] [YIAsrqozCjJwgU7LA8GxagAAAAE] /index.php?title=Special:UserLogin&returnto=Main+Page Error from line 152 of /var/www/html/mediawiki/extensions/OATHAuth/src/Key/TOTPKey.php: Class 'jakobo\HOTP\HOTP' not found [13:46:51] * faceface cries [13:47:12] Vulpix, yes, good point [13:47:34] faceface: Forgot to run composer update? [13:48:26] Vulpix: I ran it... just not sure if I did it correclty [13:48:51] maybe you need to run it from inside the extensions/OATHAuth folder [13:49:10] Vulpix: I was wondering that, but it's an extension managed by git [13:49:21] ... hmm... composer is for php deps? [13:50:13] - Downloading jakobo/hotp-php (v2.0.0) [13:50:14] Yes, it downloads libraries that may be needed for that extension [13:50:35] yay! [13:50:44] so... do I just need to know this? [13:50:53] Go in to some extension and run composer? [13:51:02] It's in the instructions [13:51:07] Before you answer... thank you! [13:51:13] If you "play with composer", stuff breaks [13:51:16] the update mediawiki page? [13:51:18] oic [13:51:48] OK, after going through purgatory, I can now confirm my issue is just as it was [13:51:56] 33 or 35... [13:52:05] GoogleLogin doesn't work [13:54:28] The supplied credentials are not associated with any user on this wiki. [13:56:33] Thanks for help everyone. Seems like the update trials need to be done every year or two ;-) [13:59:38] GoogleLogin needs to be the only primary authentication provider [13:59:45] what does that mean? [14:01:36] Vulpix, JobQueue.php just has this for getAllAbandonedJobs() : return new ArrayIterator( [] ); // not implemented [14:01:39] could that be the culprit? [14:03:31] Jhs-: this class is abstract, it must be implemented on subclasses. It depends where you're storing your jobs [14:03:39] aha, i see [14:04:21] Jhs-: Well,what a surprise! https://doc.wikimedia.org/mediawiki-core/master/php/classJobQueueRedis.html for redis it's implemented, but not for database! https://doc.wikimedia.org/mediawiki-core/master/php/classJobQueueDB.html [14:04:40] faceface: https://www.mediawiki.org/wiki/Topic:V6xw2jj3zgf1swia [14:07:53] Thanks Reedy [14:08:34] Seems if I create the account using google, I can then login iwth that account. but the requirements for the wiki to create a user for me from a google login look too confusing [14:08:39] I'll leave it for now [14:09:31] I created a user with the given gmail address, but that user still couldn't login with google, for example... I don't know if the username needs to match... seems to suggest not [14:09:52] This extension has done so much work... it just falls short of actually being usefull ;-) [14:10:57] I guess it got me to update... [14:11:10] thanks again, I couldn't have done this witout your kind help [14:21:09] faceface: So... do you expect a user account created before/outside of the Google Login extension would login with Google after enabling it, just because it has set a @gmail.com email? [15:02:53] Vulpix, i have another idea for how to solve my problem that i'd like to run by you. From what I can understand by looking at JobQueue.php & friends, the only thing that makes a job "abandoned" is that the number of attempts exceeds the limit set by $maxTries in JobQueue.php . So if I locally change the number of $maxTries from the default 3 to 5 in our copy of JobQueue.php, that could trigger them to be run. Does this make sense? [15:03:31] Yes [15:05:58] Vulpix, alright thanks, will give it a shot! But it has to wait until tomorrow, because the guy who can actually run the commands is finished for the day … :o) [15:07:11] if it works, i will make a phab ticket requesting that $maxTries (which already seems configurable) be added as something you can choose to override with runJobs.php [15:09:19] Or even better, implement getAllAbandonedJobs() on the classJobQueueDB class [15:32:18] Vulpix, ¿por qué no los dos? [15:34:35] there is already https://phabricator.wikimedia.org/T276945 [15:48:01] Jhs-: Needs backporting to 1.35 (doing) [15:50:16] The doxygen page wasn't listing it... looks like outdated [15:51:33] it was merged two weeks ago [15:52:52] >Generated on Sat Mar 20 2021 18:11:10 for MediaWiki by doxygen 1.8.19 [15:52:56] That looks... broken [15:53:38] 16:06:31 Error: Missing one or more required components of PHP. [15:53:39] 16:06:31 You are missing a required extension to PHP that MediaWiki needs. [15:53:39] 16:06:31 Please install: [15:53:39] 16:06:31 * intl [15:53:40] lol [15:54:58] :) [15:55:04] so it is … un-intl-igent *puts on two pairs of sunglasses* [17:14:49] Nikerabbit: regarding T252923 - does setting wgDeprecationReleaseLimit or error_reporting not work? [17:14:50] T252923: Ensure flood of hard-deprecations are caught during (train) deployments - https://phabricator.wikimedia.org/T252923 [17:15:50] Letting error_reporting ignore all E_USER_DEPRECATED would not be great I suppose, but I'm guessing that's what you had before? I don't quite get what effectively changed for you. [17:16:29] (per-error acking would be nice, but I'm trying to first understand how you get it before to see if we can get that back in a similar/reasonable way) [17:25:28] Krinkle: we've been stuck at wgDeprecationReleaseLimit = '1.30' for a long time. I changed it to 1.31 briefly today and filed some tasks against SMW but the amount of deprecation notices would completely hide any real errors in the error log (we just log to a file, no fancy filtering) [17:26:50] so logging to a different file was an idea I tried to apply, but noticed it is (no longer?) possible [17:32:13] Nikerabbit: hm.. I see, so you'd still be logging it all but under a different file in a way where storage is less an issue? [17:33:02] In theory, you could use MWDebug::$deprecationFilters to ignore certain ones that you don't care about. [17:33:18] it's currently protected and I don't think we'll support it officially, but it might be something you can leverage [17:34:04] I think if you use error_reporting then you could get a separate channel [17:34:44] 'error' would not contain any mw-deprecated stuff (althoguh it'll still contain PHP -deprecated stuff). And then from onLogException() you can write them elsewhere. [17:36:16] eg. if ErrorException && $surpressed && getSeverity == e_user_deprecated [17:36:29] then wfDebugLog('deprecated') or something [17:36:47] you'd configure regular php error_reporting to ignore user_deprecated [17:37:02] that'd be a stable and supported way [17:38:50] not so worried about space, rather than the high amount of deprecations (at least one per request basically I think) hiding the real errors, which we get notifications for [17:44:31] Nikerabbit: ack, ok. well I hope some of that helps. the hook could also be more generally useful e.g. possibly not setting $wgDebugLogGroups['error'] at all and using the hook for both writing to your regular system and to the deprecated log file. whichever way you like better :) [17:52:42] Krinkle: yeah I'll explore options if I have time [18:00:22] replied with a summary [20:48:25] Hi guys, is it possible to notice if a magic word gets deleted from an article. If e.g. {{foo:word}} is removed from an article? Couldn't find a hook for that [20:52:33] Fred77302: Extension:AbuseFilter [20:53:44] thank you Skizzerz I'll take a look