The movie isn't playable for me.

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

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?

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)

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.

Comment deleting is to help with accidental information leaks or outright spam. It is not our expectation that users will delete information from Phabricator and warn against it.

It is not too much different from removing comments. And this people are allowed to remove. (BTW I wonder what happens if one removes a comment with a mention)

Audit-ability is a core feature of Phabricator. We're very limited in what we allow people to delete.

But then I unmention it and it's unreflected. This seems to be wrong. Perhaps another record like "Task Y does not mention this task anymore" could be added, but it looks better to just remove the initial record. Or, optionally, it would be sense-full to provide a person who did the mention a possibility to do it manually -- thus some judgement could be applied.

This isn't a bug; you mentioned the other object and we accurately reflect that.

This report does not include reproduction instructions. Bug reports must include complete reproduction instructions. See Providing Reproduction Steps.

Well, apparently I chose another base than I intended, making the diff huge indeed. The 16554943 lines were correct, thanks for the pointer there. I think this issue can be closed.

how many lines would you say the diff is? is it reviewable?

Thanks for your response. I just tried php 5.6:

Can you try php 5, we don't support php 7 at this time. These also sound like Windows errors, not sure what we can do about them.

This is the Phabricator install for Phabricator development, looks like you're probably in the wrong place.

Thank you guys, your explanations really made the difference. We are now happily tagging our releases. :)

I'm closing this, because it's not technically a bug report.

I do discourage it, but I was using italics to highlight the difference, which is pretty delicate.

In T11121#179831, @julioromano wrote:

Your usage of italic makes me think that perhaps tagging practices like
this are to be discouraged. Is this the case?

Your usage of italic makes me think that perhaps tagging practices like
this are to be discouraged. Is this the case?

If that herald is blocking your push, it means you're pushing new commits, not only new tags.

That's what we've tried to do so far, but the git push tag command is being
blocked by our Herald rule because there is no approved differential
revision associated with that push.

T10329 is likely also related if you really want to do what you've been doing so far.

In that case, you should create the tag when you release, and only release from code that was already pushed, not from code that is "about to be pushed".

We'd like to use them to tag releases.

This should probably be a Ponder question (See Support Resources).

Config → All Settings → phpmailer.smtp-encoding

How can I enable base64 encoding within phabricator?

Let's just make base64 the default and see what that breaks. ¯\_(ツ)_/¯

More specifically, I believe phabricator is violating the RFC when it sends overly long lines and that postfix (or whatever is munging the output) is taking a rather silly action as a result.
base64 encoding the output should work around the problem.

From RFC 2822 There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
I believe the behavior of splitting the lines using a ! is implementation specific.

If your email goes through postfix, it breaks lines after 1000 bytes, rain or shine.
The solution I got from IT was "Set phabricator to encode the mail using base64".

The client was thunderbird and the webclient (based Open-Xchange). I received it on my personal mail account, outside the company.

Received: from giant.haxx

Interesting. The same mail was delivered to me intact:

Here's the mail that I received for your comment. You can see that the M stream is broken with "!" in two places. This seems to match the behavior I observed initially, although there was also an extraneous blank.

https://nylas.com/

All the cool companies use Phabricator.

I should switch to Nylas since they use Phabricator.

Airmail on Mac, it has a few quirks with our HTML emails, but I haven't tried to debug it yet. I'm sure we're doing something weird since all other HTML seems fine in it.

I think we're relying on white-space: pre-wrap; right now. We could explicitly do \n -> <br /> conversion which might fix newlines, at least.

Which client do you use? I imagine the html relies on <br> or something, but would \n vs. \r\n be involved at all?