Guess I should probably add M1 to the remarkup blocklist now.

I switched to an M1 Mac Mini on Big Sur, which has motivated me somewhat to try to get this working since I suspect doing another install through Homebrew on M1 silicon will be more adventure than I have stomach for.

So I don't forget:

With the four revisions I've just added, arc lint works with PHP 8 when run inside the arcanist repo, and arc unit --everything has no regressions compared with PHP 7.4 (both do have a few failures but they're the same and relate to pyflakes/jshint/hg, and look environment-specific so nothing to do with PHP 8).

In D21496, declaring a method private final (which is redundant, as a private method may never be overridden) causes an issue in PHP8.

Just want to add a note that with git lfs managed files, arc patch won't work unless one fetch the ref tag and then the lfs blobs from the staging server first. See https://discourse.phabricator-community.org/t/arc-patch-fails-with-git-lfs-files/2447/3

As of macOS X 11 (Big Sur), php on the CLI emits:

That seems reasonable. I also ran into a couple of other suggestions elsewhere:

Off the wall suggestion: how about a trigger that sets the subtype:

The profiling in D20566 seems satisfactory, and has been useful in resolving or understanding a few performance-related issues.

• There is no way to pull custom field values with *.search. See above.
  • There is no way to edit non-custom field values with *.edit. The underlying transactions haven't been modularized yet; they should be, then EditEngine should get appropriate EditField definitions.
  • There's no way to identify which custom fields can be edited. This overlaps with T13248, but is also a Conduit API Console UI problem. The web UI should have some way to inspect parameter variations per object subtype for available subtypes.
    • As a workaround, you can try to edit an invalid field. The error message will identify valid fields.
  • There's no way to create steps with *.edit because you can't specify a step type. See T13449 for a general variation of the "type is required to initialize objects" problem.

HarbormasterBuildStepCoreCustomField emits no fields if a BuildStep has no attached Implementation object. This dates from D15352 and is conceptually reasonable ("don't crash if a build step exists but the implementation no longer does") but should probably be represented differently (e.g., an explicit "InvalidImplementation").

This appears fixed by D21484 (and @20after4 confirmed the fix on rPc0414732 -- thanks!) so I'm going to mark it as resolved.

See https://discourse.phabricator-community.org/t/strpos-throwing-in-phabricatorauthpasswordengine/4335, and D21477.

I know it's an old thread, but I am encountering what is, as far as I can tell, exactly the same issue. I'm on the latest version of trunk (~Oct 26) with php 5.5.9 on Linux 3.13.0. I also observed the issue on the May 30 version.

I think I've got a small tidbit to add on a specific use-case with Jenkins. I had been using pipeline builds which are working nicely but I just tried to setup a multi-branch pipeline build and this requires the branch name in the Jenkins URL of the HTTP request triggering the build. I suspect in this case the proper thing to do would be to trigger and build twice. I guess that's more of an on-branch-change sort of situation than on-commit and using those triggers in Herald (they look to be present, I haven't used them) and having that information passed on to Harbormaster as mentioned could fill the need.

Same issue here.

This synthetic script demonstrates the conceptual problem with FutureIterator:

I've marked D21461 as resolving this, since the new errors surface the particulars:

• D21457 fixes approximately 20 additional errors identified by the linter in phabricator/.

I just created a poll where I accidentally hit enter while editing options, so I was left with an incomplete poll which I wasn't allowed to complete, so I had to close it. Would you consider adding a feature that allows us to edit poll options as long as there are no votes cast yet?

• D21454 fixes the specific issue in HTTPSFuture.

Check if arc lint catches this.

Probably related: According to https://phabricator.wikimedia.org/T261642, it seems that when leaving a project, phabricator leaves behind some cruft in the form of materialized memberships for milestones of that project.

MYSQL_PWD can be observed always

The main problem here is that command "./bin/storage dump" exposes password on system process list in clear text. It happens due to way the storage tool calls mysqldump command. In my opinion this is universally applicable to every Linux distribution Phabricator can run on.