Re-ping. @Aklapper Is this doable or do we need more input here? Regards.

@vvv @Hydriz Could you please have a look at the above patch set? Thanks!

My idea was to run mwscript namespaceDupes.php --wiki=enwiki --fix but will that fix pagelinks? Thanks.

Pinging my team: Stewards-and-global-tools in case they noticed something weird with GlobalBlocking lately.

AFAIR fishbowl.dblist wikis ain't CentralAuth wikis.

@Athena I shall look if they're provided by Collection or we need to create them manually. I'll ask. Thanks.

Increasing the limits would be okay I think, but they are not (thankfully) much of them :)

@demon @Reedy Could you please handle the GitHub mirror? Thanks.

Patch merged and gerritbot output looks as expected so closing this task as resolved. Thanks.

Finishing the cleanup/transition as per https://www.mediawiki.org/wiki/Phabricator/Project_management/Tracking_tasks

Hi @Marostegui and @jcrespo -- can we have your assistance in monitoring this? Thanks.

True. Not sure why an inactive repo isn't shown striked out as it happens on Tasks.

I guess I can inactivate all of them.

Pending a final full formal vote.

As of f0f5e666ee42 the extension.json file has a GPL-2.0+ licensing. Closing as resolved.

Any progress here?

Fixed in 09615351c0da.

Fixed in c9cae10cb4ee by adding BSD-3Clause.

This was changed to Unlicense in 37a2d81cd79e so I assume we can close this as resolved.

I've fixed

id=10249 ns=0 dbk=BP:BF *** dest title exists and --add-prefix not specified
id=10250 ns=0 dbk=BP:T *** dest title exists and --add-prefix not specified
id=5822 ns=0 dbk=WP:BF *** dest title exists and --add-prefix not specified
id=5794 ns=0 dbk=WP:OM *** dest title exists and --add-prefix not specified
id=5837 ns=0 dbk=WP:TA *** dest title exists and --add-prefix not specified
5 pages to fix, 0 were resolvable.

by deleting the shadow conflicts. They now work fine.

I'm fixing the WP/BP conflicts via API.

Hello @Reniervdg and @tomasz:

pagelinks from=3907 ns=0 dbk=Portal: *** INVALID
pagelinks from=6265 ns=0 dbk=Portal: *** INVALID
pagelinks from=6364 ns=0 dbk=Portal: *** INVALID
pagelinks from=6380 ns=0 dbk=Portal: *** INVALID
pagelinks from=6437 ns=0 dbk=Portal: *** INVALID
pagelinks from=6444 ns=0 dbk=Portal: *** INVALID
pagelinks from=6472 ns=0 dbk=Portal: *** INVALID
pagelinks from=6482 ns=0 dbk=Portal: *** INVALID
pagelinks from=6487 ns=0 dbk=Portal: *** INVALID
pagelinks from=6533 ns=0 dbk=Portal: *** INVALID
pagelinks from=6542 ns=0 dbk=Portal: *** INVALID
pagelinks from=6796 ns=0 dbk=Portal: *** INVALID
pagelinks from=7086 ns=0 dbk=Portal: *** INVALID
pagelinks from=7389 ns=0 dbk=Portal: *** INVALID

is concerning. As for the rest, it seems like the script would do a fine job.

@EddieGP I guess 1 was https://gerrit.wikimedia.org/r/#/c/393289/ and 2 is https://gerrit.wikimedia.org/r/#/c/394846/ ; if 3 can be avoided then okay.

My proposal:

It's a patch/change for operations/puppet repo. Adding SRE so they are aware of this.

@StevenJ81 Sorry then for getting you wrong.

Nihil obstat so scheduling this for the next avalaible SWAT window.

From a countervandalism point of view, using rollback to revert malicious page moves would be great. Abuse of the feature for page-move wars is a possibility that, well, already exists with the current not-so-automatic system we've got.

In T118637#3442398, @TerraCodes wrote:

In T118637#2082056, @MarcoAurelio wrote:

It is useless to have this special page now that the SUL finalisation process is finished. What's blocking this?

What is blocking this?

@DStrine However if the campaing reaches its end, why we cannot let the system uncheck the option? After all, the campaign expired and even if the 'enabled' setting is 'on', if the expiration date has passed, it won't run. So while I certainly understand that the setting should be independant, so I can enable and disable campaigns at pleasure, maybe the system could unckeck the 'enabled' setting once the expiration date/time arrived. Sorry if my meaning is not clear. Happy to rephrase if needed (well, try to rephrase). Thanks.

In T169450#3812405, @Joe wrote:

Just trying to understand the context - what the original ticket states is we need to redirect from those domains to others. So the expected result is that if I type 'mo.wikipedia.org' in my browser, I'm redirected to 'ro.wikipedia.org'. Correct?

Yes that's the idea, however:

I must apologize in advance if my impression is not right, but I don't think being combative is helpful here @StevenJ81 (my personal feeling as non-native english speaker).

I think https://de.wikipedia.org/wiki/MediaWiki:Autoblock_whitelist will do the job.

Fixed in c2e994fc25f3. Both projects seems to have been added by now.

We should also need to teach the bot to discriminate against non user creation logs, because it's parsing data from #central where only account creations are reported.

Apparently there's no #login.wikimedia irc.wikimedia.org channel. Is that right?

I'm declining this in favor of T174287.

If there are no concerns with that domain being added I'll try to find a suitable deployment window to merge that patch.

I did this today:

MariaDB [s51541_sulwatcher]> select count(*) from logging where l_timestamp<20171201000000;
+----------+
| count(*) |
+----------+
|   233730 |
+----------+
1 row in set (0.15 sec)