There's a similar PHP 8.1 related deprecation notice in the Unit renderer on this line:

See T12847. All the technical parts of this are now solved except for billing, but since Phacility is winding down I no longer plan to pursue it.

I resolved this in rCORE320b2854.

After T13630:

Only one instance was impacted by this and I just credited them until 2099. I don't currently expect to pursue this.

I no longer expect to pursue this.

• Hosts in the repo class are now build by Piledriver (see T13630), which automatically creates the rbak device entries, so this error isn't likely to occur again.
• I also don't expect to launch any more hosts.

I compacted secure onto new hardware (T13671) and shut down saux001 ("Land Revision") and sbuild001 (Harbormaster remote builds). I think all the remaining work is covered under T13630 (largely, just a handful of large database migrations remain).

I just swapped configs over without merging the LBs, since it wasn't immediately obvious to me what the Application vs Classic state of the world is and swapping was good enough.

The aphlict/notify stuff still needs to be tweaked. I think the snlb + slb setup can be merged into a single slb with "TCP (Secure)" forwarding now.

Databases are moved and secure is out of read-only mode. I'm going to adjust repository configuration, then I should be able to tear down secure001.

I'm going to put secure back into read-only mode now and move the databases to the new host.

I brought up the new host and pointed the slb001 load balancer at it. The database is still on the old host, and the new host doesn't have repositories yet, but the basics seem to be working.

Merging 003 into 001 worked fine with a few expected tricks (e.g., when secure is in read-only mode, you can't push a change to take it out of read-only mode, since pushing is a write). Next up is launching a modern m4.large secure-pool host and then migrating the data.

I'm putting secure into read-only mode now, with the intent of completing steps 1-5 above.

• Fix missing variable initialization.

• Fix another random PHP 8.1 issue.

• Fix a PHP 8.1 issue in application search code.

• Fix a PHP 8.1 check in local disk storage engine code.

• Fix a PHP 8.1 issue in user querying.

• Fix a piece of user initializing code for PHP 8.1.

• Correct behavior in query clause construction.

• Fix a strlen() in query construction.

• Add annotations for interfaces implemented by PhabricatorHandleList.

PHP 8.1 changed semantics of static variables in methods. See:

See also T13588. Using static::class to work around changes to the scope of static in PHP 8.1 is also possible now that PHP 5.5 is the minimum version, and some uses of get_class($this) might be replaceable. There's no strong motivator for this, it's just a little cleaner.

See also T13588.

It would still be nice to have this from a completeness/correctness perspective, but other changes have made it less valuable:

...possibly, but not conclusively, a result of an SSH version upgrade...

I put all the database migration stuff everywhere and it appears stable. I'm hooking up Postmark as an outbound pathway now. If I get that working, I'll let it sit for a while and start migrating databases.

Finally, there are other some MySQL version issues which can be avoided with:

• Also fix service profiler test case.

• Fix unit tests and a handful of other errors.

The new core/ support for the API is partially deployed; the new services/ support isn't anywhere yet.

Ah, yep, should be 7.2 -- thanks!

... and was formally deprecated in PHP 7.4 and removed in PHP 8.0.

The lint emitted says 7.2 (which appears to be correct), a minor inconsistency in the revision description

See also T13232. Here's a possible build strategy for PHP 8.1 under macOS Mojave. Anyone reasonable should probably give up and use brew instead.

The latest version of Phabricator itself is everywhere.

I'm going to hold it until the weekend and try deploying then if things look calm on my end.

I'm satisfied that we aren't violating our commitment to our customers by continuing to use Mailgun as a service provider...

Purely venting, but the advanced version of "click here to schedule a mysterious meeting" is to outright lie -- pretending that you deeply respect the recipient's achievements -- before asking them to schedule a mysterious meeting.

While waiting to deploy db stuff, I was planning to look at pruning dead data out of S3 -- but, on closer examination, the total S3 bill is something like $1/day, so no priority on that whatsoever.

Piledriver also needs to be able to provision database hosts, but these are more-or-less a trivial subset of repository hosts.

• Make InstancesStateQuery use a dictionary when building the database ref information internally.