- User Since
- Jun 9 2021, 22:34 (32 w, 2 d)
Dec 5 2021
(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:
Dec 2 2021
Oct 30 2021
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.)
Sep 22 2021
Sep 4 2021
Ref also Git Commit Message Conventions. Adding a Co-authored-by: name <email@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.
Aug 28 2021
Aug 18 2021
Jul 11 2021
Looks like @deadalnix may need to update DNS:
$ dig phorge.it [...] ;; ANSWER SECTION: phorge.it. 0 IN A 22.214.171.124
$ dig we.phorge.it [...] ;; ANSWER SECTION: we.phorge.it. 0 IN A 126.96.36.199
Jun 23 2021
Jun 20 2021
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
Jun 19 2021
Couple tiny nits and otherwise LGTM!
(It's all in src/docs and can be generated with ./bin/diviner generate)
Jun 18 2021
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
Jun 17 2021
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.
Jun 16 2021
Jun 14 2021
From IRC a while back, for reference:
Looks like we.phorge.it is the winner coming out of that, with a static site hosted at the apex
Jun 13 2021
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.
Jun 12 2021
Good catch, thanks!
Jun 11 2021
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
Jun 10 2021
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?