(From our own install's perspective) I don't think the would make anyone at all sad. It seemed to be a pretty random decision by one of our newer users while he was playing around with things.

Partly, just haven't gotten there yet.

(This is T6740, not T9979.)

Performance concern. At least one use case requires us to scour *all diffs and all diff ids*. Also a desire to avoid having deprecated calls in our codebase.

(Is this a performance concern or do you just want like 6 fewer lines of code to maintain?)

Feel free to add it to Community Resources, you should be able to edit that page.

This is because we now recognize shortname.git in some cases, and it's ambiguous if quack.git is "the repository with shortname quack.git", or "the repository with shortname quack, addressed as a Git repository".

WMF has extensions and modifications to Phabricator so you shouldn't report anything you experience on that install to us directly. Report it locally, make sure it isn't because of an extension, then bring it upstream. The versions we could show you would not be useful anyway because they'd be hashes of local commits which do not appear in the upstream, so we would just close your report as invalid and say "test with unforked code before submitting a report" anyway.

Looking through the code, looks like Maniphest doesn't use ngrams yet? Any reason?

I think this might be T9979 though.

Spin up a test instance on Phacility, build a reproduction case and update the ticket. We don't have any insights into how the server you mentioned is configured of administered. We can with Phacility instances if you can't install something locally.

@chad, thanks but isn't this an upstream bug? The example I gave downstream were of convenience. Do you need me to find an example upstream?

Please contact your administrator if you want to file a bug against Phabricator. I believe there is an area where you can file bugs for us to look into in the downstream.

Basically anything that would be accepted as a Bug would require you to have admin access to some install before you have enough information to submit it, so this is more-or-less a moot point.

I'd say 75% or more bug reports we get require administrative access to resolve. You can spin up a Phacility instance for free.

Confirmed this on my local. It seems to be due to D16851, specifically this line: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/diffusion/application/PhabricatorDiffusionApplication.php$104.

The Croatian letter "č" is also missing, but it's the only Croatian diacritic that's not present in the distributed version of Aleo, resulting in this:

Why? We set up email integration before, but each task needs to have specific projects so that didn't work and now I'm stuck doing the entry by hand.
This is in the realm of reasonable, and likely easy to solve with custom inbound addresses and Herald rules, or with a small extension to Herald. We might try to improve the documentation to make the feature easier to discover or understand.

I've marked D16905 as resolving this: we now recommend a minimum value (33554432).

Thank you so much for the tips! I'll check the resources and try them out.

See also T10246#163438 for Drydock, and the Harbormaster / Drydock documentation.

Here's the general shape of how to do this. Since we encourage synchronous pre-review lint to fill this role instead of asynchronous build-like processes, support is much rougher than support for lint.

In T11900#201218, @epriestley wrote:

Have you looked at the existing lint support already?

The major advantage of lint over a bot is that it happens before code goes for review, so that patches generated by beautifiers like clang-tidy are incorporated locally. Reviewers never need to see unbeautified code or deal with inlines about formatting/style issues.

(Sorry I clicked submit too early)

Have you looked at the existing lint support already?

We have at least one tricky issue remaining: when applying storage upgrades, we currently apply them like this:

Although it's very possible that this is a bug, this state also has a 72-hour internal cache which wasn't written correctly in older versions of Phabricator.

Ok, whatever you say.

See T11898 for the previous iteration on this.

Please read Contributing Feature Requests carefully before filing a feature request.

Can you show me the <VirtualHost> entry you've added for Phabricator in your Apache config? I suspect you may have omitted the B flag in the RewriteRule.

Phrequent is a prototype, and we don't accept bug reports for prototypes. See User Guide: Prototype Applications for discussion.

I tried the openssl connection you suggested and it still bombed.

General state of the world here:

Thanks to point out @chad I will take a look closer to it.

What about Node.js v0.10 and v0.12?

If you're still currently using Node.js v0.10 or v0.12, it is time to begin the transition to v4 or v6. Both v0.10 and v0.12 are considered to be in Maintenance mode currently and will fall off our support plan completely later this year.

Great thanks!

Closing for now, happy to reopen with reproduction steps we can follow.

This should now be fixed in HEAD of master and stable.

Cool. D16901 should fix this properly. Thanks for the report!

Fixed and I'm back up and running, thanks!

I can confirm that SHOW TABLES IN phabricator_xhpast works just fine as root mysql user, and dropping the credentials from the upgrade command yields exactly the same results as running under root. So that seems like it all ties up. I can work around this any number of ways and I will do just that.

Yeah, looks like some credential shenanigans are afoot. I instrumented the user we're actually connecting as and am getting a mixture of what I passed with -u ("trunk") and the default user ("root").

Maybe also: do you have cluster.databases configured?

If you run this from mysql directly, as root, does it work?

The Event Hovercards are not really useful: E990 The Mouse-over dialog shows no date and time for example...