I'm 95% done a diff, will have it to you in 2.

I'm taking a look now....

I can confirm this behaviour, going to take a quick look otherwise will ask @btrahan to look into.

Just to note for future users: now there is an option diffusion.ssh-port for correct clone URI display

I don't think I am seeing this any more.

Quoting myself from T6277:

Note that the other potential issue identified here - https://secure.phabricator.com/D10490#90899 - is not fixed by these changes. "bin/migrate" started to feel a bit crazy magical to me and otherwise I think we can deal with this unaddressed problem if / when we create it.

Closed by commit rPc0848bca6d91.

Alternative fix is to delete Gravatar support.

DarkConsole is primarily for Phabricator development, and the backtick symbol if fairly common with other coding languages (Perl, SQL, etc). I don't think this issue is limited to Phabricator.

Usually this is because outbound HTTP requests are firewalled and we're trying to fetch a Gravatar. Workaround is to disable security.allow-outbound-http. Real fix is to time out the request and/or detect this during config.

I would also be curious if the issue repros on a new account on your install.

Are there timeout errors in your server logs? Anything in the developer console on your browser?

Not here...here is correct, if you look my images, is changed!!! :(

Does the issue reproduce for you here?

But cannot open the interface where I can choose the file...I get a time-out error after I click on Edit Picture Profile...

Is the file larger than PHP or MySQL's limits? Are you storing in the database, disk, or elsewhere? Is the filetype supported by your system? Theres lots of things that could be misconfigured.

The Real Name field is optional, and users may feel free to put whatever they want in that space. This is the right default for vanilla Phabricator (which most installs are corporate). You should be able to change the "language" of the field as needed in your base English Translations (happy to fix that if needed, it may not exist).

No worries, I am very confident, and if someone hits it they'll report it. Thanks!

Sorry, I've been having other phabricator fires today. And I changed my config to no longer import production.conf, so it's a bit hard for me to test it -- sorry!

well, actually I landed it so just update to HEAD and let me know if I didn't fix it. =D

Closed by commit rP69b1ff303238.

@csilvers - can you test D10643 if you have a second?

Closed by commit rP928b4edffb66.

Support Impact This breaks older installs which used phabricator_read_config_file(...) with any of the default config files when they attempt to upgrade.

I believe using %T instead of %Q probably fixes this.

Is the proposed fix correct? (Binary just needs to be quoted? ...and that will still work in newer sql?) I'd implement it slightly differently with the wonders of qsprintf

(This doesn't technically get harder to fix over time.)

Support Impact storage upgrade is broken on old MySQL and installs attempting to upgrade will be left in a nonworking state.

Just wanted to say I am having the same issue on an existing Phabricator install.

workaround:
Manually changed line 241 in PhabricatorStorageManagementAPI.php
from

At a guess...

Even Randal Monroe agrees that ISO 8601 is the one true date format -- https://xkcd.com/1179/

Support Impact Addresses various support issues with multiple occurrences.

Support Impact This doesn't really create much of a support burden but is confusing and stupid.

Support Impact This feature is fairly useless right now for all but the simplest things.

Reopen if you get more info.

Arcanist does warn when it's a big diff.

Sorry for all the noise, but is this WONTFIX for having Arcanist warn when the diff is really big?

We collapse text in large diffs by default, but show files with inline comments (including lint messages). Because this diff has 250 lint messages, most of the files expand, defeating the "this is a large diff, so collapse to speed it up" feature. D9991 is an example of a diff on this install which is larger (affects more files) but loads very quickly because files collapse by default (as it does not have lint messages). A potential workaround for this is to use --nolint when running arc diff to suppress linting.

We don't expect patches of this size to be reviewed in Phabricator. Arcanist should warn before submission.

Closed by commit rP3c6781b177d4.

P1266 is a similar POC script that takes a project name like Herculoids and will make the membership of all projects matching a prefix like Herculoids-Sprint the same. This might be useful for per sprint projects until T3670 to avoid the re-joining annoyance.

In case anyone else is using this setSuppressEvents is no longer a thing and an emptyness check is needed for projects like

See also T1895

Got it, I hadn't turned on pygments.enabled

Here's a screenshot of a random C++ file with no highlighting. Note the button on the sidebar says "Disable Highlighting", so Phabricator thinks it's on I guess. Toggling that option has no effect.

That would be very useful. You can also add a warning on the Pygments installation instructions to carefully check that temporary directory and, in any case, double check it's functional using the debug function page you showed me: that was really clear and shot the bug.

Awesome. I think we can improve this setup check so that it reports a more useful error if pygmentize exists and just fails when we try to run it.

Great!
With the debug code I (in fact indirectly YOU) solved the issue. This was my output of the ../debug page:

Here's an example of the output on my machine:

(The debug.php file does not normally exist, you'll have to create it.)

I have no clue how AppArmor works, sorry -- I just know some users have run into this kind of problem with it.

Thank you,
I must confess that I'm using Linux since Linus' first version, but I have little sysadmin experience.

Mnn, I'm very sure 3 languages (cbk-zam, map-bms and roa-tara, i.e. Chavacano, Banyumasan and Taratino) will be refused. But how about Nahuatl (639-2: nah, which is a superset?) and Norman (using Narom's 639-3 nrm)?

Offhand, I'm not sure. We actually run pygmentize as pygmentize -h to check it, does that exit with a zero exit code? It's possible that the -h flag has changed across versions, or -h is somehow broken on your install.