If there's interest, I revived hach-que's old Docker setup and am updating it to work with Phorge because azure devops is killing my soul at work. It's suitable for both local dev environments (T15011) and production installs, and I'll be supplementing the repo with IaC for a production deployment (T15928).

How would we as phorge upstream use the info? Would it inform development? Be just informational?

W5 has been set to editable by Blessed Communicators

We're around, just quiet :-)

I think the issue is that the patch doesn't cleanly apply after D25050 (which also corrects the slugs on 24/25) --- so it's a git issue rather than an arc one (i.e., git apply <diff> produces an equivalent error). Going through the Update Diff flow in the UI seems to want to create a new revision, rather than update this one. Just abandoning this and starting a new revision might be the easier option.

The labs one was me from ages ago before a GH org name was decided on. IIRC the phorge org was already claimed and I just wanted to be squatting on something that could.be used down the road. Happy to delete / change ownership / whatever else

There should be a systemd service for managing the daemons, I'll check tonight what's wrong with it and why it isn't correctly starting daemons on reboot

This is a direct result of T15090: CVE-2022-24765 - Multi-user Git Privilege Escalation - confirmed in the Nginx error logs:

STDERR
fatal: unsafe repository ('/var/repo/1' is owned by someone else)
To add an exception for this directory, call:

Hey, folks -- appreciate the interest! Most of what needs doing still is outlined in T15006: Re-brand Phorge (and to a lesser extent in T15012: Update Diviner documentation to reference Phorge). There's not a ton there that's hugely difficult, there's just a lot and it's mostly tedious. Any help on anything in that list would be immensely appreciated. I have a bit more bandwidth now than I did towards the end of last year, so I can probably start making some headway on the rebrand as well now.

(also refreshing the weirdly-rendered page once it loads corrects the problem)

What browser are you using? This has been a persistent thing for me on Firefox across multiple mobile devices. E.g., from a fresh Android 12 install on a 2340x1080 screen with "Show Desktop Site" turned off in Firefox 94.1.2:

In T15059#1654, @speck wrote:

I just checked the emails I receive to my gmail account and noticed that the emails seem to be from the secure.phorge.dev domain. Should those be received from we.phorge.it instead? I was in the process of filling out an issue form for Microsoft and noticed this discrepancy. Could that cause issues like this?

Do you have any additional repro steps? Mail config will be specific to the Phab/Phorge install. If this is specific to our Phorge installation, yeah... it's sucky. We self-host our email server and that means we're subject to all of the arcane and mystic requirements there. As far as we can tell, it's set up as correctly as is possible (SPF, DKIM, DMARC all configured correctly; domain is old enough that it doesn't negatively impact our trust scores; etc.). (A current spam test result for reference.)

Ref also Git Commit Message Conventions. Adding a Co-authored-by: name <name@example.com> trailer to the commit message seems fairly well-accepted, at least for Git. GitHub and GitLab both recognize and parse it when present.

@roguelazer - added you to Trusted Contributors so you should be able to land now

Looks like @deadalnix may need to update DNS:

$ dig phorge.it
[...]
;; ANSWER SECTION:
phorge.it.              0       IN      A       217.70.184.38

versus

$ dig we.phorge.it
[...]
;; ANSWER SECTION:
we.phorge.it.           0       IN      A       198.74.57.92

In D25011#358, @deadalnix wrote:

Slowing things down is rarely a good idea ever - at least for the reasons external to the patch in question, rejecting a patches because it's not good if obviously just fine. I reject that point outright.

One other option, if we're going to provide a migration guide, par of that could be setting the storage namespace... Brain fart and forgot that'll be something we do. But that'd let existing installs continue to use their Phab namespace and new ones the Phorge one

Confirmed this does indeed break existing installs relying on the default. What options do we have to work around this? Couple that come to mind might be:

• Add a new SQL patch that runs RENAME TABLE old_db.table_name TO new_db.table_name for every Phorge DB and table.
  • Con of this is that it may require a new GRANT ALL PRIVILEGES ON [...] statement based on how each install originally set things up (e.g., granting ON *.* versus ON phabricator%.*)
• Add a line in the release notes telling users to ./bin/config set storage.default-namespace phabricator if they're using the default namespace
  • Con of this is it's an out-of-band upgrade step that relies on instance maintainers reading the release notes and not setting and forgetting an upgrade script in a crontab on the assumption that stable generally is pretty stable
• Leave the default storage namespace as phabricator

Couple tiny nits and otherwise LGTM!

(It's all in src/docs and can be generated with ./bin/diviner generate)

Fair point on being precise with the terminology.

Will it cause a conflict or ask the user to commit or stash untracked changes? But yeahhhhhh, will need some human intervention...

Just confirmed on another instance:

• Had an existing package-lock.json pinning ws to version 7.0.0
• Manually updated package-lock.json to pin to version 7.5.0 (did not actually update installed version of ws)
• Cycled Aphlict service
• Sent a test notification
• Received Web + Desktop popups

It _shouldn't_ mess up anything existing, I don't think. It's been a few months since I did a ton with JS so might be forgetting something obvious here, but if anyone already has Aphlict up and running, I'm pretty sure their existing install will be unimpacted by the presence/absense of package-lock.json. If they want to manually update their npm packages, then they might need the additional steps, but pretty sure it won't be disruptive outside of that.

Do we actually want to be version controlling this? That's the recommended approach for Node projects, and given how hilariously awful dependency management is with npm, it might simplify support if we say "Aphlict runs with this specific version of websockets and its dependencies".

Something was funky in how the repo was originally imported that was causing the issues. Somehow got to a state where it wasn't properly a bare repo (there wasn't a working tree, but everything was still inside .git/ instead of the root folder). Not sure how that happened, but seems to be resolved now

Hah yup, we're all good in case everything catches fire. I'm around all evening and can revert changes if anything goes haywire

Thanks @speck! I think we also need to update the NGINX config and phabricator.base-uri config to we.phorge.it from secure. Will also require updating the clone URI. You want to just bundle both changes at once to make things easier? Looks like @deadalnix already updated DNS so that should be hunky dory

Yeah, logging perms should (I think) be fixed now. I was dumb when I chowned things and forgot what system users needed what access.

Same with a patch workflow against a fresh clone of the repo:

phorge  (master)$ arc --config phabricator.uri=https://secure.phorge.it patch D25000
 INFO  Base commit is not in local repository; trying to fetch.
Created and checked out branch arcpatch-D25000.

<do-it-live.gif>

From IRC a while back, for reference:

Evan Priestley (and others) wrote:

[01:09] ^[: epriestley: Looking at Phabricator from just the right angle, we can see that it's actually a web application framework which comes bundled with a handful of really sophisticated example applications. In your opinion, how silly would it be to surgically separate Phabricator-the-framework from Phabricator-the-dev-suite?
[01:31] epriestley: Relatively easy-ish. You can already use Phabricator as a web framework by subclassing "PhabricatorSite", and "phacility.com" is an extension that uses Phabricator as a framework.
[01:31] epriestley: Phabricator also sort of uses itself as a framework for public blogs in Phame ("PhameBlogSite").
[01:33] epriestley: Depending on your goals and use case, some details might need to be worked out, and some behaviors might be too Phabricator-flavored and difficult or impossible to override purely in extensions today, but I suspect there aren't many of these.
[01:34] epriestley: For example, extensions can get full control of top-level exception handling behavior by subclassing "AphrontRequestExceptionHandler".
[01:35] epriestley: Previously, a larger portion of "framework" behavior was in libphutil/, while "Phabricator" behavior was in phabricator/. The theory was that if you wanted to use the framework parts, you could depend on just libphutil.
[01:36] epriestley: However, essentially no one actually did this so it just represented an additional maintenance cost and general confusion for end-users, and I merged "libphutil/" into "arcanist/" and "phabricator/" last year.
[01:37] epriestley: The layers are still (for the most part) logically separate, they just live in the same repository now.
[01:42] epriestley: The biggest fundamental issue with thinking of Phabricator as a generic web application framework (internally, "Aphront") is probably that a lot of behavior depends on "PhabricatorUser $viewer", and "PhabricatorUser" is a concrete final class with a fair amount of Phabricator-specific behavior (it depends on the Lisk storage layer, etc). Decoupling that into "ViewerInterface $viewer" and making "PhabricatorUser
[01:42] epriestley: implements ViewerInterface" or similar could separate the layers, but that's probably a very messy change.
[01:46] epriestley: But it's also unnecessary if you're okay with using Phabricator's "system" applications (Auth, daemons, mail, etc) and just building your own user-facing applications. "admin.phacility.com" is a Phabricator application running on Phabricator-as-an-application-framework, using Phabricator auth and infrastructure but with none of the normal applications installed. If you install an app that provides a route for "/" and
[01:46] epriestley: uninstall the upstream "Home" app, your app becomes the new landing app.
[01:47] epriestley: (See also https://secure.phabricator.com/D11753.)

Looks like we.phorge.it is the winner coming out of that, with a static site hosted at the apex

Fixed for real this time. I had an error in the sudoers file. Thought the webserver was running under a different user. But just cloned rARC with its HTTPS URI successfully, so should be hunky dory now hopefully.

Good catch, thanks!

I tried to get a start on this in P1, just running

grep -r -n -E '[Pp]habricator[ \.,;:\-\!\?)]' ./src

and found a few occurrences. Not sure how we want to handle the configuration values that are `phabricator.<XYZ>' since they're sort-of internal, sort-of exposed in the UI. I left them in the Paste just to have them documented

There is great benefit from having people submitting the code to push it themselves.

Could just do like Phorge Upstream → Governance, Phorge → Maniphest, etc. with subprojects to have a kind of clean-ish separation between "application" stuff and "administrative" stuff?