sorry that I can't provide reproduction steps

(Specifically, the scrolling is a feature which I added in D10188 but punted on making work in Firefox.)

Write Depends on D123. in the summary of B.

Nice. This is likely something easy/simple/silly, I just haven't been able to reproduce it locally and the answer has yet to come to me in a dream.

ip2long can also return negative values (see rP30473549).

Yep, we'll close issues once we resolve them.

This was almost certainly fixed by 5a723bf (D14991 / T10116) on January 11.

What version of Phabricator are you running?

It sounds like neither of you have actually configured Phabricator's real-time infrastructure. See:

I can reproduce some variant of this locally by following these steps on OS X:

Ah, thanks. I think this is almost certainly related to your keyboard layout and how we're detecting that you typed "@".

I cloned Linux and examined the commit, but couldn't immediately see anything wrong with it. I'll do the full import when I have a chance.

@OCram, do you have an non-US keyboard?

• You only need to run arc liberate when developing Phabricator itself (e.g., writing Phabricator extensions or otherwise modifying Phabricator).
  • The one ARM system (the Raspberry Pi) we have other direct evidence of users attempting to do installs on is explicitly not supported as a Phabricator host platform -- see Installation Guide. You can try, but you're on your own.
  • If you're using an ARM system that could, in theory, broadly qualify as a "normal computer" to host and/or develop Phabricator this is something we might eventually look at supporting, but we don't currently have any evidence that anyone else is trying to do this. We are vanishingly unlikely to dedicate resources to ARM support for the benefit of only one user (if you are developing on ARM hardware) or one install (if you are hosting on ARM hardware).
  • If you did read the "Installation Guide" and believed ARM hardware to reasonably qualify as "a normal computer", we can add additional language to make it clear that ARM is not included in what we consider "a normal computer".

Is the local system a raspberry pi?

You can use bin/policy unlock to unlock an object.

I can't reproduce this.

I can't reproduce this with Chrome 48.0.2564.97 on OSX. Here's the autocomplete working on my local instance in Chrome:

Yeah, I agree that these are pretty confusing in typeaheads. They kind of ended up there by accident, I'll swap them back to always being fa-user in that context.

Should be fixed at HEAD. Thanks for the report!

@chad, I'm going to push this back down to PHUIHandleTagListView.php and rename it:

I merged these to stable and upgraded web001 to fix the immediate issue. The utf8 fix technically needs to go to the repo hosts, but we don't need it there immediately since it only aided in identifying and debugging the gzip issue.

Alright, I made some progress on this.

Slightly more useful:

Logging for this is now in production, but the initial data is totally useless:

I've issued all instances a 72-hour credit for this disruption.

I purged dead instances on db001 more aggressively, leaving us with this result:

Service on db001 has been restored, although there's a backlog of backups + daemons that are slamming it so it won't be very responsive until those drain.

db001 is still loading. It's through the particularly slow instance and I expect it to finish in the relatively near future.

• db004 loaded in 14m18s and is now 11% utilized (6.2G).
• db005 is 77% utilized (46G) with a 250MB compressed backup.
• db005 dumped in about 1m30s.
• db005 loaded in 8m22s.
• db005 is now 8% utilized (4.7GB).
• db001 is still loading, and I think I pretty much just have to wait it out. Major issue is one enormous, disabled "test" instance but there's no easy way to skip it.

• I destroyed out-of-service instances on db004.
• I disabled and destroyed two very large "test" instances which were still technically in service but had one user, no activity, and were long overdue on billing (just not >120 days overdue yet, so they hadn't triggered automatic suspension). One of them had some extra information which strongly suggested it was a "test" instance. If this was in error, they can be restored from backups later.
• This leaves db004 59% utilized (35G) with a 1.1GB compressed backup size.
• db004 dumped in 3m32s.
• db004 is now loading.
• I'm preparing db005.
• db001 is still loading.

• db003 has 31% utilization (19G) with a 250MB total compressed backup size.
• Reassuringly, dump time was 1m49s.
• Load time was 6m32s.
• db003 is now 8% utilized (4.3G).
• I'm prepping db004.
• db001 is still loading.

• The db002 load completed in a relatively reasonable 17m50s.
• Utilization is now 18% (11G). A sizable chunk of this is removable at some future date.
• I'm in the process of preparing db003.
• The db001 load is ongoing.

• The db002 dump completed in 7m31s, which is much more promising.
• I wiped the data and enabled per-file tables.
• I'm currently reloading the databases.

• db001 compressed much better than admin001 or secure001 and overshot volume free space on restore. I've cleared space and restarted the restore.
• db002 is starting at 31% utilized (19GB) with a 3GB compressed backup (a significant portion of this is unmigrated file data, though, which I expect to dump and restore relatively quickly).
• I disabled network on db002 and am dumping the data.

• I destroyed all out-of-service test instances on the host.
• I destroyed one unusually large out-of-service "test" instance.
• This left us 67% utilized (40GB) with a 1.3GB compressed backup.
• I disabled network traffic.
• I dumped the databases, which took 35m44s (???).
• I wiped the data and enabled per-file tables.
• I'm currently reloading the databases, but I expect that to take a while.

I'm beginning this on db001 now. The high volume utilization shouldn't be an issue since the ultimate process doesn't involve doing anything in place.

This host took 4m4s to dump and 9m36s to restore. Utilization is now 21% (6.1G).

Er, I was reading the wrong backup filesize -- the actual size is 1.5GB. A big chunk of this is in parse caches, so I ran bin/cache purge --purge-all. I'm now doing the actual maintenance.

I'm beginning this on secure001 now (this host). Prior to maintenance, the volume is 52% utilized (16GB) with a 306M compressed backup. Service on this host will be briefly interrupted.

I disabled network connections to MySQL and restarted it.

Prior to optimization, admin001 was 46% utilized (27GB of database data) with a 434M total backup size.

I am beginning this on admin001 now.

This may actually be not-too-terrible. I think there's a good chance that db005 really does have less than 22% of a volume of "actual" data, since the compressed size of backups for all active instances on the shard is only about 300MB. We had a bunch of heavy test instance churn on that shard for whatever reason.

I'm going to do this tonight/tomorrow, but this is going to be fairly involved. Current utilization is:

what the heck

Maybe clang-format could be changed to give an output that's properly "split up" -- I don't know how feasible it would be, but given how fiddly it is (the whole tool is a collection of special cases), I expect that would be Hard.

This is live on this server (secure.phabricator.com) -- let us know if you're still seeing issues. Seems OK for me on a physical iPhone 4s.

This is now deployed to this server (secure.phabricator.com) -- let me know if you're still seeing issues? Behavior seems OK in the simulator and with my physical iPhone 4s, but I don't have a fancy physical 6s to test.