The server I copied to is a debian server with the same version of mariadb installed. Could I point that server at the db that I copied and then dump that, restore, and copy it back to wmflabs?

The Stretch grid hosts have libssl1.0.2 and libssl1.1 installed instead of libssl1.0.0.

Checked in wmf.18.

So yeah earlier we tried to remotely enter bios and enable the 10G nic and failed (it requires crash cart.) So this is ready for Chris to take over and migrate the rack when he has time to do so.

Some updates

• The project page is now marked for translation (except for updates):
  • https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions

It almost sounds like rather than having a live stream of edit events, or at least acting entirely on a live stream of edit events, the updater should instead do internal batching

I just hung out with @CaitVirtue & disabling the KAM extension resolved it

@Ottomata - LGTM. Ideally, we'd get some low-priority tasks filed for the service-template-node dependency issues, but that's not an emergency. And probably something on which I can follow up.

Uhh I see now, I can reproduce this.

I'm happy with the design in the attached screenshot, as long as Prateek and the rest of AHT can get the build to pass.

See T214724#4969881! Please test on RWS

This will be fixed on Turkish Wikipedia next week, with the deployment of MW 1.33.0-wmf.19.

Back to you.
There are a few new QA instructions
See: https://phabricator.wikimedia.org/transactions/detail/PHID-XACT-TASK-yxcovnrdyniyvf4/
Please test on reading web staging (just updated)

I'm sorry, but that is a totally unacceptable answer.

Our Gerrit instance has ldap.localUsernameToLowerCase = true. Reading the doc at https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#ldap.localUsernameToLowerCase :

@sbassett, I've moved your TODO list into the task description. I believe I've resolved all of the relevant things.

Change 491857 merged by Ottomata:
[operations/deployment-charts@master] Set cors to false for eventgate-analytics node service chart

Change 491857 had a related patch set uploaded (by Ottomata; owner: Ottomata):
[operations/deployment-charts@master] Set cors to false for eventgate-analytics node service chart

Change 491655 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Talk is at bottom of main page

Change 491655 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Talk is at bottom of main page

I'm so sorry! Only saw your ping now. I'd love to have a chat with you. Can you send me an email at lydia.pintscher@wikimedia.de so we don't clutter up the ticket here?

Though the emails are already publicly available. They are used by git/gerrit :)

In T216605#4969481, @sbassett wrote:

Protecting this for now, since user emails are exposed, which we typically don't want in public Phab tasks.

Unassigning myself although I would like to resolve this one someday.

Change 491856 had a related patch set uploaded (by Bmansurov; owner: Bmansurov):
[mediawiki/extensions/EventBus@master] page-links-change: emit link deletions on page delete

From https://www.mediawiki.org/wiki/Topic:050e2fb772abdae40bd7842b2b77d26b, which still reproduces the error when viewed, at time of writing.

Thanks for he patch @Zoranzoki21 !

Approved! https://toolsadmin.wikimedia.org/tools/membership/status/483

Mentioned in SAL (#wikimedia-cloud) [2019-02-20T20:59:12Z] <wm-bot> framawiki: Deployed 8f72587 on -web-01 T216581

There might be other languages where the same thing would be helpful, but in that case we should probably implement it on a per-language basis.

Not much to do here. The slave deployment-db04 eventually managed to start mysql and new instances are rebuild with a dump/import to them.

lodash <= 4.17.5

It looks like the lodash is fixed by updating service-runner to 2.6.9. Done.

Change 491718 merged by jenkins-bot:
[analytics/quarry/web@master] view.css: Fixed problem with the display of certain letters

In T216067#4961394, @Krenair wrote:

Transfer running the documented way, screen import on -db05 and export on -db04.
Once this is done I'll probably make deployment-db06 and copy stuff there too, then make MediaWiki treat one of them as a master.
Ignore the log above, it does require mysql to be running (I assumed the opposite)

In T216067#4964127, @Krenair wrote:

And of course I can't find the package from db03/db04 because their apt status is corrupted...

Posting the blow-by-blow of another test, because it shows the replication point 2, “In Progress articles appears as Suggestion and marking them Favourite is possible.”

Change 491404 merged by jenkins-bot:
[mediawiki/core@master] Fix password policy handling in temporary password provider

Without innodb-force-recovery = 1, I get the same P8111 by simply moving enwiki/archive files. So that table definitely has some kind of issue, I think we can afford to loose it entirely. However the page fault is more concerning:

[Note] InnoDB: The log sequence numbers 212565209189 and 212565209189 in ibdata files do not match the log sequence number 233682420105 in the ib_logfiles!
[Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer...
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 971.

Data looks very corrupted. At this point the best option is to rebuild that host from the slave.

Data looks very corrupted. At this point the best option is to rebuild that host from the slave

The repository seems to be checked out properly in 1.33.0-wmf.18 (not enabled, so nothing interesting actually is happening yet).

Uh, so this is not going to be easy.

@matmarex: Just re-checked this on test wiki which is running wmf.18 right now. Still seems broken to me.

Mentioned in SAL (#wikimedia-cloud) [2019-02-20T20:38:18Z] <framawiki> re-activating puppet on -web-01, csp conf looks good T214637

The /data/project/itwikiarticlebot/wikiarticlebot/bot.rb script seems to be Telegram bot rather than a webservice. It looks to me like it would run as intended if submitted to the job grid using a command something like jstart -N wikiarticlebot /data/project/itwikiarticlebot/wikiarticlebot/scripts/toolforge-start. The use of jstart here is a shorthand for jsub -once -continuous. -once tells jsub to check for an existing job of the same name (-N ...) running on the grid before actually starting the new job. -continuous wraps the submitted job in an while loop that checks the exit status of the wrapped job and restarts it if it ends with a non-zero exit code (which typically signifies a crash).

typical DS search:
Contribution Source Like usd% ...AND...
Contribution Date - greater than or equal to "January 1st, 2019 12:00 AM" AND less than or equal to "January 31st, 2019 11:59 PM" ...AND...
Exclude Recurring Contributions ...AND...
Transaction ID Like p%