It's inconsistent because you need to be watching a room and someone has to post a message (in order to trigger a sound). Thanks for the report!

No this is good, master gets promoted weekly, so this is a bug in master that will be promoted unless we fix it.

Any weird environment variables defined on those workstations? Also add --trace to the arc diff command might give more details

Just tried it, didn't help :(

And by doing that, I realize that I have been keeping up with master instead of stable like an (oh, there's no donkey emoji, too bad...).
So it's fixed... Sorry!

Sorry, it completely slipped my mind!

Your system has php-fcgi installed on the CLI (note cgi-fcgi in the output). This is incorrect. Replace this binary with a php-cli SAPI binary.

What if you disable the extdiff extension? The documentation doesn't mention modifying regular diff output but probably worth trying.

How could we make it more clear that we require version information for bug reports? Here's how we currently communicate this, but it seems like it didn't work well in this case. Is there a way we could improve this or make it more clear?

Can you show me the output of this command?

We have installed mercurial 3.9.2 both in the server and client, in fact we downgraded the client mercurial from 4.1 to 3.9.2 to match the versions, but nothing changed. The version of arcanist is 3c4735795a29 (pre-last commit) and phabricator is at ef839192aa5a (from Tuesday).

I have been updating the DB manually to set status back to 0 as a workaround for now. But you could probably see how this affects our workflow!

Please identify the versions of mercurial used on client/server, also the version of Phabricator in use. If you're on an older version of Phabricator it's possible that upgrading may resolve the issue.

I don't personally, since I neither use hg or windows, but maybe @cspeckmim from the community has some suggestions.

I tried to reproduce with other users, on the same phabricator install but there is only one user with a particular windows setup (that has nothing different from other users except for his particular windows machine) that is experiencing this problem. I tried following the stack trace and adding some error_log's on the php. But my php knowledge is close to zero. In any case something like this:

Please read and follow Contributing Bug Reports.

We need a "Resolved: Ghosts" status.

(Offhand this sounds expected)

Bug reports require version information, and repeatable, detailed reproduction information. Please!

@epriestley I see, tried the same steps and it doesn't play directly within chrome. Thanks for investigating.

I can't play it in Chrome in any circumstance.

I can not play the .mov file in Chrome no matter what I try:

@chad The first video still doesn't play in Chrome (Version 58.0.3029.110 (64-bit); seems working in FF and safari now.

This is what I see in chrome (Version 58.0.3029.110 (64-bit))

Here's a screenshot of this working correctly for me in Safari:

@avivey I no longer run into this problem, please feel free to close this bug.

@epriestley not sure if the current phabricator install has been upgraded to lastest code that contains this fix yet, but the first video included in this bug which is a mov file still doesn't play. If I download it, it works, so the mov file itself is working.

While it would have saved me some time and some wondering if this kind of error message would have been in place I agree, it would ideally be in git. I'll see if there is anything about that on the git front.

We could say "checkout failed, you might have a bad hook" but I'd want to wait for more users to run into this first, and maybe try to pursue a fix in git with the upstream.

There doesn't appear to be any reasonable way for us to perform something like git checkout --skip-hooks, and I think we shouldn't even if we could.

Ha yeah that is interesting

Can you show me the output of these commands?

This is a productive environment, so I could not test to reproduce it and I don't know how can I reproduce it.

Okay, but just to point out: having an apostrophe in one's name is not that exotic...

• O'Brien
• O'Connor
• D'Angelo
• O'Dowd
• O'Malley
• O'Hara
• D'Arcy
• D'Addario

So someone could quite conceivably have Chris.O'Dowd@BBC.co.uk or something like that.
Anyway, if anyone's looking for how to get around this in the future, an alternate solution to changing PhabricatorUserEmail.php would be to go into the DB phabricator_user, in table user_email, and change it directly in there, thus bypassing validation.
If you did want to change the code, though, look into http://php.net/manual/en/filter.examples.validation.php - FILTER_VALIDATE_EMAIL and FILTER_SANITIZE_EMAIL.

Per T12359, we aren't interested in supporting technically-deliverable-but-bizzarely-exotic addresses in the upstream. Feel free to fork to support this kind of address.

I'm inclined not to actually pursue the autofocus approach I was considering before, at least until we get a better read on whether click-to-select is a good behavior or not. Instead, I'm just going to fiddle with the UI a bit to fix the alignment issue. The new hidden inline state has some similar alignment issues.

That's partly because "\n" isn't a newline in bash:

Yes, the behavior depends on the shell. I was using bash.

Ah, I see that it works differently in other shells. The above output was from zsh. In bash, indeed all output is written to the file:

It shows no output because there are no warnings. If you replace phabricator/bin/storage dump with a command that does give various formats of warnings on stderr, you see that it works:

$ sh -c 'echo "output1"; echo "error\nwarning\nerror2" 1>&2; echo "output2"' >foo.txt 2> >(grep -v warning)
error
error2
$ cat foo.txt
output1
output2

I'm not sure this works as expected.

I used the subshell redirection trick as mentioned by @epriestley to hide this warning from our cron output as well:

In T12716#223717, @chad wrote:

I assume this is T4334

I assume this is T4334

uuuuuuuuuuuuuugh

Go for it, a couple emails came in that I'm still digging through. Thanks!

Do you have this or should I snipe? I'm home now.

We currently (at least, in theory) prevent this situation from ever occurring by preventing simultaneous tagging with both "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1". Since a task can not appear in both a milestone and subproject of a particular parent task, users can never be faced with the opportunity to perform a destructive drag operation.

Okay. When a task is in "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1", and you view the "Warp Drive" board and drag the task from "Milestone 1" to "Backlog", what do you expect to happen to the projecs the task is tagged with?

Okay. When a task is in "Warp Drive > Thermocoupling" and "Warp Drive > Milestone 1", and you view the "Warp Drive" board and drag the task from "Milestone 1" to "Backlog", what do you expect to happen to the projecs the task is tagged with?

Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with subproject "Warp Drive > Thermocoupling"?

No, Thermocoupling alone is enough, as it implies it's part of Warp Drive.

Do you expect a task to be able to be tagged with "Warp Drive" and also simultaneously tagged with milestone "Warp Drive > Milestone 1"?

No, Milestone 1 alone is enough, as it implies it's part of Warp Drive