We still need a complete bug report for this. See Contributing Bug Reports.

I'll do so as soon as I can.

I can probably copy-pasta that feature.

The movie isn't playable for me.

any plans/chance to implement search if you unbeta phame? T6383?

One thing I've seen people do is something like an encrypted ssh key (For SSL certs):

Cool, pretty sure I've got a repro then -- real fix coming up in a second.

Yup, that did the trick!

Ah, I think I've got a repro. Does this "fix" it?

We are seeing an issue where the global default email preferences are not reflected in the user email preferences.

There's a very small possibility that D16110 fixed a race condition which was causing this, but that seems like quite a stretch.

In T11141#180290, @epriestley wrote:

Is the behavior you want the same as @vinzent's desired behavior, your phone's behavior, and your laptop's behavior? That is, blindly trust client timezone unconditionally, without prompting or notifying you? From the original description, it seemed like you wanted essentially the opposite behavior.

GitHub does not appear to ever render absolute time. Instead, it renders relative times like "5 hours ago", etc.

what do others do about that timezone thing? I'm not aware that i needed to specify a timezone on other services.

Is the behavior you want the same as @vinzent's desired behavior, your phone's behavior, and your laptop's behavior? That is, blindly trust client timezone unconditionally, without prompting or notifying you? From the original description, it seemed like you wanted essentially the opposite behavior.

In T11141#180288, @epriestley wrote:

auto-adjusted based on location

If you auto-adjust the primary local time displayed on your system, why don't you also want to adjust Phabricator?

We pop this dialog because your browser's time (which only has one time, and which is the only time we can see) has changed.

auto-adjusted based on location

In T11141#180280, @epriestley wrote:

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

"Adjust timezone" dialog doesn't have a way to cancel/ignore

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

Why don't you want to change your timezone?

Catching a couple more funky diffs:

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

I believe this is fixed now, but reproduction has always been somewhat elusive so I'm not completely certain. Please let us know if you still see issues after updating. Thanks for the report!

This commit now appears properly in the history view on this install, so I think the issue is resolved:

So fast :)) Many thanks for you work)

Look at my repo history without bug fixing.

No, not in full commit info. See history window with all commits of project.

I can't reproduce this -- rGITTESTaa541e7b324424e201c124dc58588c33e48d8bf5 seems to work fine for me.

I found source of problem: many lines of code in libphutil and phabricator use a strlen and substr functions instead of using mb_strlen and mb_substr. If you replace this functions to multibyte-analogs, this bug go away)

If the "Audit" setting for packages had three settings instead, would that solve your use case?

Thanks. That trace is consistent with the one I was able to reproduce, so I suspect the changes above fix this. I'll leave this open for a bit in case anyone else shows up, this fix is the kind of fix that's likely to have spooky side effects.

The command output was:

[2016-06-13 17:45:26] EXCEPTION: (InvalidArgumentException) Argument 1 passed to DiffusionCommandEngine::setURI() must be an instance of PhutilURI, instance of PhutilGitURI given, called in /home/ubuntu/phabricator/src/applications/repository/storage/PhabricatorRepository.php on line 511 and defined at [<phutil>/src/error/PhutilErrorHandler.php:200]
arcanist(head=stable, ref.master=e8a0ebaeffaa, ref.stable=7b0aac5c6f31), phabricator(head=1558175ec84c7b13ba3f692b897464901bc00578, ref.master=55767aac0f86, custom=2), phutil(head=stable, ref.master=dad3ab8d7e87, ref.stable=ad458fb7df59)
  #0 PhutilErrorHandler::handleError(integer, string, string, integer, array) called at [<phabricator>/src/applications/diffusion/protocol/DiffusionCommandEngine.php:52]
  #1 DiffusionCommandEngine::setURI(PhutilGitURI) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:511]
  #2 PhabricatorRepository::newRemoteCommandEngine(array) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:497]
  #3 PhabricatorRepository::newRemoteCommandFuture(array) called at [<phabricator>/src/applications/repository/storage/PhabricatorRepository.php:488]
  #4 PhabricatorRepository::getRemoteCommandFuture(string, string) called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:350]
  #5 PhabricatorRepositoryPullEngine::executeGitUpdate() called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:125]
  #6 PhabricatorRepositoryPullEngine::pullRepositoryWithLock() called at [<phabricator>/src/applications/repository/engine/PhabricatorRepositoryPullEngine.php:40]
  #7 PhabricatorRepositoryPullEngine::pullRepository() called at [<phabricator>/src/applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php:43]
  #8 PhabricatorRepositoryManagementPullWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:410]
  #9 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:303]
  #10 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/scripts/repository/manage_repositories.php:22]

The latest commit on stable fixes the problem for us 👍

I appear to have found a reproduction case for this in the cluster.

I'm deploying this to the cluster now.

In T10936#175435, @rencris wrote:

This specific issue also happens on my computer, which is running Windows 7 SP1 with PHP 5.6.20

I'm using stable versions of libphutil and arcanist as of May 16th.

If I rollback Arcanist to commit rARC737f5c0df976 the problem is gone.

@ivo, if you see this before I post a fix, can you show me the output of this command so I can make sure I'm reproducing exactly the same issue?

This issue describes a narrow issue with typehinting URIs, introduced by T10227.

I'm going to merge this into T11137. They don't describe the same issue, but I'm planning to fix them in the same way.

Reverted commit rP55a698a28a750017e787979a72dd125858997fa5 on our install and repository updates now work again.

sorry, I don't restart the php-fpm, maybe the old process is still running.

In T11126#179873, @eadler wrote:

Silly question but can't we use CSP Level 2's referrer directive (https://www.w3.org/TR/CSP11/#directive-referrer) to avoid leaking information without the need to build full image proxying?
If that doesn't work can we use <iframe seamless referrerpolicy="no-referrer"> ?

ɯɯɯɯɯɥ

hmmmmm

hmmmmm

(And those UIs might also not actually be useful for future-administrators, particularly since I don't really plan to ever help users with third-party stuff, although who knows.)

My intent with a lot of that stuff is to make administration and support (particularly in the future, once third-party applications are more common) easier, so they're targeted primarily at future-administrators who have questions like these, possibly because we've asked them for the information: