Ah, yes -- this is where I got off track. In my head I had conflated being able to clone the repo with having the arc certificate installed. These steps are unrelated, I understand clearly now. As long as the SSH key is added in Phabricator and the Repo is activated in Diffusion, cloning it is no problem. In this case, I thought it was the lack of arc certificate blocking me, when in was actually just that I forgot to activate the repo. Whoops. Thanks for clarifying.

You should be able to can arc install-certificate --conduit-uri=https://whatever to install a certificate for an arbitrary install with no other configuration.

Fwiw, if someone else lands here (which I just did by Googling the same error message), the problem for me was the same as for the original poster -- having not first initialized a repo locally one way or another. My intuition (which is probably wrong) is that there is an interesting order of operations problem here.

SSL Certificate, key and Ca files. Of course they can be saved as SSH keys but I don't want to mix them together.

What is your use case for API access to notes?

D17373 should fix the typo.

Thanks! Your reproduction instructions were extremely clear and made hunting this down straightforward. D17372 should resolve this.

Well by the time you divide false into 3600 pieces you can't have much left!

err, looks like it returns "FALSE on failure", and naturally in PHP, FALSE / 3600 is 0, so we just consider it as "UTC".

This information is obtained from your PHP, using datetimezone.getoffset(), so it's not all in our control.

This setting (In the Phabricator web interface) is very old, and should exist in all versions. Ask your admin to configure it (Assuming your admin created the repository).

thanks all your answers

I think it was historically possible for third-party code to read custom config, but not possible for them to add new settings until D16928 (Nov 2016), which might be why we don't warn about bad values. Should be fine to do so now, though.

Well, it looks like we didn't expect users to set encoding from arc:

Closing, because it's probably not a bug. Comment again if you think it is. But if you do, a smaller file would help debugging.

Actually I think this is my fault, I was providing the offset in Unicode characters, not in bytes.

See Planning.

I am getting the same error with

arcanist c58f1b9a2507488b2152473dd1f0bbc7e99c09c1 (29 Apr 2016)
libphutil 0709cd5cfc2616c29104387de6dde3de1db7fa32 (2 May 2016)

and

svn, version 1.9.4 (r1740329)
   compiled Apr 28 2016, 01:15:57 on x86_64-apple-darwin15.4.0

+1 for random grepping. Thanks for the fix!

(Your diagnosis of the root cause was also correct.)

I deployed D17346 and rebuilt the indexes on this install with bin/search index --type DivinerLiveSymbol and behavior now seems correct. Thanks for the report!

Please file a new task following the instructions in Contributing Bug Reports if you'd like us to take a look. We need all that information before we can start looking at a bug.

I'm going to merge this into T12196; this is almost certainly an issue with PHP7. Upgrading to PHP 7.1.2 may resolve it.

I think this compression had messed up with HTTP served Git repository. Git complains with

I presume there is no logical need to add the same panel twice to a dashboard.

See downstream for general discussion. See T12256 / T12257 for upstream followups.

Example: I disabled a bogus user when the "confirm your e-mail" MTA job was on its ~200th attempt. It's now at its ~240th attempt :)

Ah, thanks! Good to know what my own community is doing.

This is a copy of downstream https://phabricator.kde.org/T5242. See that task for discussion.

Thanks, this should now be fixed in HEAD of master. Let us know if you run into anything else.

Oh we already had one of these

D17333 is a probable fix without needing to resort to a bunch of weird setInterval() juggling. I've pushed that here, let me know if you're still seeing the issue? If you are, does your JS console have anything in it?

I'm having some trouble reproducing this -- I tried Safari and Chrome here and in my sandbox. You aren't using anything weird, right?

T11050 describes a way you could work around this issue in some cases in the future, by resigning from the review (basically, saying "I'm not going to review this on behalf of Project 1 because user B is on top of it, so get it out of my queue"). That doesn't help if you want it in your queue but just not in the "Must Review" bucket.

Thanks for the report, and for including detailed reproduction steps. The were very helpful in reproducing and fixing this issue.

I think you don't need to rebuild the search index for that to take full effect. Although rebuilding it will change the content in the index in some cases, the new, more-tailored queries should match either version.