https://de.wikipedia.org/api/rest_v1/page/summary/DB-Baureihe%20483%2FA484 does not work. Strange.

Shouldn't it be https://de.wikipedia.org/api/rest_v1/page/summary/DB-Baureihe%20483%2F484, which returns the same result as https://de.wikipedia.org/api/rest_v1/page/summary/DB-Baureihe%20483/484

Duplicate of T436766

Fixed now.

Shameless plug: Alternatively use https://allblocksever.toolforge.org/ to show all active and previous global and local blocks as well a global locks.

@JJMC89, sorry but a column missing in the Toolforge replica view for no good reason is a bug not a missing feature.

In T428230#12120524, @dcaro wrote:

@Count_Count Do you have a sample code I can use to test? (I'll figure out on my own but might help save some time)

In T429938#12058337, @fnegri wrote:

Views are created. The cookbook is currently syncing the DNS records for all wikis, that will take a while.

In T429938#12058082, @fnegri wrote:

Usually these tasks can wait for longer, without breaking any tools. But I didn't realize that when I ran the maintain-meta_p script on Wed, that also imported the new wikis into meta_p. The root cause here is that the process for deleting a wiki is complex and not well tested, because we do it very rarely.

Thanks for taking care of that!

Some crosswiki tools, which query those views for all wikis, are broken until this is done, e.g.

• https://guc.toolforge.org/?by=date&user=Count+Count
• ...

In T415293#12050779, @fnegri wrote:

@Count_Count can you confirm the problem is resolved for your tools?

For spamcheck I am now using a simple Javascript gate for queries which just sets a long-term cookie and reloads the page (idea from this blog). If the cookie is present the gate is never triggered. This seems to filter out just about all bot traffic.

Problem is with kuchikikiki, see https://github.com/xtexx/kuchikikiki/issues/30

I confirm that this is indeed my alt account.

This is also of interest for dewiki.

Thanks @matmarex. I have adapted the links in our template and it works great. It will save the stewards an additional click on a common task and will improve documentation for global multi locks as the additional reason field is now prepopulated with a permalink to the request on [[SRG]]. I will add a similar feature request for global multi block and mention this request there.

@dancy Works now, thanks!

Is it planned to store webservice logs in Loki as well? I don't see a task for it.

docker pull docker-hub-mirror.cloud.releng.team/library/rust:latest DOES NOT work for me locally either.

 docker pull docker-hub-mirror.cloud.releng.team/library/rust:latest
latest: Pulling from library/rust
6e7932d5cb55: Pull complete
705f67984ab3: Pull complete
1c17e454c787: Pull complete
fb5461f2dc96: Downloading  16.22MB/226.2MB
b925852ec78f: Downloading
received unexpected HTTP status: 503 Service Unavailable

@Urbanecm_WMF I checked with one person who had the same problem and it seems better today. But it still takes about 0.5/3 secs on their watchlist:
https://performance.wikimedia.org/excimer/profile/94e38eb4fbe6be9a

Apparently the cdnjs auto-update has been broken for a while, see https://github.com/cdnjs/cdnjs/issues/14263#issuecomment-3800585676

Could we archive the old etherpads to Cloud VPS object storage using something like this: https://github.com/okfn/etherpad-archiver and have a web service on toolforge to display them ready-only?

@dcaro , @DamianZaremba: I can confirm that it works fine now. Thank you both.

Using

filelog-stdout: $TOOL_DATA_DIR/logs/notify.log
filelog-stderr: $TOOL_DATA_DIR/logs/notify.log

works. If that is the new intended behavior then that is fine and we can add this caveat to the documentation.

What do you mean? I have mount: all in the yaml file.

Got the errors too today, three times in a row but the emails were sent.

Assigning to Ladsgroup as discussed here: https://meta.wikimedia.org/wiki/Talk:Spam_blacklist#c-Ladsgroup-20251006153200-Count_Count-20251006075900

This issue blocks the migration of my tools away from file logs. One hour is very low.

The category count is definitely broken today, see e.g. sub categories here all listed as empty when they are not: https://de.wikipedia.org/wiki/Kategorie:Wohngeb%C3%A4ude_in_Niedersachsen

It comes from the DiscussionTools extension CSS:
https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/0b877fba05b8a2d984e84100695196d797ec1bc3/modules/dt.init.less#L358-L360

As a dewiki CU with a technical background I have been quite frustrated with the limitations of Special:Investigate (limited no. of accounts / ips), no adding accounts manually, no widening of IPv6 ranges, no advanced filtering, etc. and have been thinking about writing a better tool for some time. So just like @L235 I would like to have the ability to use the API on dewiki to develop such a tool.

The move log entries are not exactly duplicate, they differ in the associated_rev_id field of the log_params column.

Looks like there are no more instances of fully duplicate entries though, more general quarry query: https://quarry.wmcloud.org/query/93916

They are not only appearing twice, there are actually two entries created in the db, see https://quarry.wmcloud.org/query/93904

This is indeed no longer reproducible.

It needs to be removed from the sitematrix as well. Code which tries to access the associated URL now fails, because the DNS entry has been removed.

This seems to be completely broken as I can't save anything. It also makes a test fail:

❯ cargo test -- tests::api::test_immutable 
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running unittests src/lib.rs (/Users/hans/dev/countcount/mwbot/target/debug/deps/parsoid-2eaed1445b9c5a61)

Ahh, because @doctaxon as oversighter suppressed the username.

I still don't understand why doctaxon is listed as the blocking admin while the block was done by another admin originally.

I did not know about the restriction that the revert has to be marked as patrolled in order for the reverted tag to be applied. After marking the revert as patrolled the reverted edit is properly marked as reverted.

Now at https://gitlab.wikimedia.org/toolforge-repos/stimmberechtigung

Can this be completed? cswikivoyage is still not listed in the meta_p.wiki table while events are being sent out. This causes problems for my spamcheck tool.

There are some native Rust wikitext parsers we could consider as well:

• https://crates.io/crates/parse-wiki-text-2
• https://crates.io/crates/wikitext-parser
• https://crates.io/crates/mediawiki_parser

This works fine with non-cnb images by using commands like this in the job definition:

command: exec ./xlinks.sh # in turn execs the binary

@bd808 I remember now. Thanks for reminding me.

@bd808 Thank you! I have started using the Mediawiki REST API instead (see https://phabricator.wikimedia.org/T369414#9958156), using e.g. https://en.wikipedia.org/w/rest.php/v1/page/MediaWiki:Spam-blacklist, which works fine as well.

In T369414#9958164, @Bugreporter wrote:

when using curl, please specify a custom user agent.