• 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".

I found the project ID with that method link
The bug can be closed, thanks to all of you !

Can't reproduce on any Windows nor any Chrome versions. (Win7, Win8, Win10), Chrome 48, 49.

Is the local system a raspberry pi?

The project's hashtag.

Thank you!
I was sure there is solution like that.
But what abbreviation is for Project object ?

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

I can't reproduce this.

Is it allowed to set up a patch with other motivator facts? For example a motivator like:

• Tested with Chrome 48.0.2564.97 on Windows7

I will try it this evening on different client platforms and check whether it has something to do with our enterprise proxy or firewall.

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

Yes, my Windows clients can push now. Strangely enough, my Linux clients now can't. This seems to be bug T9639

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.

yes it's fixed. thx for the fast response.

Should be fixed at HEAD. Thanks for the report!

i just did a simple git pull like every other update

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

Sounds like this might be a PHP version issue, are you using one older than 5.5?

Can you provide details on reproducing the errors? My sandbox and this install are both at HEAD.

Are you also using Windows client?

@storrgie - SELinux is very nice for tightening security, but unless you are very well versed in it is a pain in arse... and ruins everything you love. Phabricator + SE Linux.... Well, either disable SELinux or happy hunting!

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.

User defined symbols probably shouldn't be shown on any typeahead.

@rftfaria Did you just disable selinux... or did you work through it?

Anyone ever systematically worked through this? it's quite a tangled mess.

Slightly more useful:

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

Thanks for this, just got caught by it myself.

(This is the 3rd time this came up in IRC). Looks like people are trying to keep phabricator-ssh-hook.sh close to the phabricator code.

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.

just got an instance set up and ran into this, adding my voice to say issue is obnoxious.

You're welcome. Thanks for the quick fix.

Thanks for the report, should be fixed at HEAD.