Ok. 5.10.0.0 released.

In T202095#4509506, @MarcoAurelio wrote:

Is it possible to launch a DB query against all Wikimedia wikis databases? (cc. @Reedy )

Shall we rename the global group back until such querying and fixing is resolved?

Regards.

Wikimedia are going to be dropping TLS 1.0 soon... So yes, we basically have to do this

In T202047#4508830, @Legoktm wrote:

In T202047#4506723, @Reedy wrote:

Can we get Library Upgrader to do something like this?

Sounds good to me. We can bundle it along with the standard updates so we don't have to make a ton of extra commits.

I'm guessing I need to do the overdue release, and then look at bumping .NET versions

So... @Magioladitis @Rjwilmsi we're pretty much going to have to jump to .NET 4.5

I've deleted https://pt.wikinews.org/wiki/MediaWiki:Copyright which had an old URL override of what is in WikimediaMessages

Looks just broken for you?

CategoryTree::makeTitle can and does return null. Being passed straight to getHTML without any checking

Can we get Library Upgrader to do something like this?

Dupe of T201776: TitlePermissionTest failing on travis-ci after ContentLanguage service conversion ?

In T198666#4505911, @kaldari wrote:

@Reedy - Any update?

@DFoy I have a list of all the active providers according to zero wiki... I'm not sure if it's private information, so not going to post it on here yet...

In T201776#4503278, @Krinkle wrote:

@Legoktm @Simetrical Is there a commit we can revert meanwhile to unbreak the build? The lack of visibility has already allowed one regression to be lost in the noise - T201900.

I think search isn't well implemented in Flow... T104631: Search in Flow boards (tracking) and T76823: Basic search on Flow board (tracking)

It's a flow board... So it's not going to have a talk namespace....

You'll probably have the same problem with other extensions, eventually. Though, if they're enabled on WMF wikis, we can probably enable it elsewhere (such as mediawiki.org) if necessary

Tried again this morning. Caches seemingly expired and it's working!

In T201952#4504194, @ema wrote:

We reverted the jjb bump to 0.3.4, after which builds completed correctly again. What went wrong is till unclear but maybe we can just try once more to publish 0.3.4 and see if the issue is reproducible?

Not sure why, but I'm wondering if it has something to do with the fact that GeoData extension is not installed on MediaWiki..

Yeah, [contint1001.wikimedia.org] out: Call: docker-registry.discovery.wmnet/releng/mediawiki-phpcs-dryrun:0.1.5 docker-registry.discovery.wmnet/releng/mediawiki-phpcs-dryrun latest is slooooooow

Least unzip isn't a heavyweight dependancy :)

Feel free to bump the package again and add unzip and I can try again

In T200201#4501588, @OlegCinema wrote:

@Aklapper I am upset by this attitude to small projects. Why should we wait a month for you to complete the task? Can the project wait another 10 years? Why?

Got the password (let me know if you want it). It's updated now

Looks like this one isn't claimed by the mediawiki org..

In T197669#4499105, @thcipriani wrote:

This is something Release-Engineering-Team generally does, but this is another in the long list of tasks @demon used to quietly take care of. We'll get to this but will need some help from folks familiar with this process (@Reedy :))

Yeah, "dummy" accounts are used. Often with an appropriate name/username, so the leaking you were mentioning is less of a problem

In T201764#4498765, @ahmad wrote:

By "arbitary address" I meant one set by the form administrator, instead of having to be that of a wikiuser account as currently is the case. Not one entered by the form user.

From what I can see, only extensions would cause this...

None of the code has changed recently... I'm betting it's related to an extension

It looks related to some extension. 667 is

In T201829#4498326, @Jidanni wrote:

1. Update Mediawiki

Make sure 'MediaWiki:Contact' and 'MediaWiki:Contact-url' are defined.

Sending to an arbitary address just seems a great way for spammers to send spam out... It seems to defeat the point of the contactform when it's designed to go to a intended recipient

In T191116#4496669, @saper wrote:

Just ran into this issue when troubleshooting something on 1.31.0, pretty confusing!

In T201572#4494037, @Ladsgroup wrote:

Just wanted to say I think doing this is very much part of our core values about openness and transparency. Several days ago I found a typo in the website but couldn't find the place to fix it and now I forgot where it was...

Scripts run

Testing and unstable have 7.2 :)

In T201524#4489125, @Huji wrote:

For the record, I do have openssl installed, and it does show up on phpinfo() output as well. So in theory, MW should have gracefully used that and not called mcrypt at all.

MW prefers to use openssl_encrypt where possible, so I don't know how important this actually is...

What do you mean it's not allowed?