Bug reports require clear, easy to reproduce, set of steps anyone can follow. Please read Contributing Bug Reports for how to file a complete bug report.

Presuming setting Public view policy on repo resolves the issue. Let us know if not!

@beber does setting EFL to "Public" resolve your issue?s

https://phab.enlightenment.org/diffusion/EFL/ view policy is set to "All Users".

This isn't a bug in Phabricator, then. Please review Contributing Bug Reports and Support Resources carefully for details on what we provide support with.

I tried with fields available in the upstream, so it can not be reproduced with vanilla up-to-date- copy.

In T11613#194409, @dfumagalli wrote:

In T11613#194396, @chad wrote:

Assuming probably you're seeing T10352

Yes, I have read that. Putting "END" solves the recursion but the issue about path being empty comes up as in that bug report.
Since the suggested diagnostic PHP snippet shows path being correctly handled by "END" (except for when we call the website root), a quick'n' dirty fix I have tried is to look at the code checking path <> "" and set path = '/' if empty instead of raising an exception.

In T11613#194396, @chad wrote:

Assuming probably you're seeing T10352

Assuming probably you're seeing T10352

In T11613#194389, @chad wrote:

Can you file a bug report then if you believe the documentation contains a bug?

Can you file a bug report then if you believe the documentation contains a bug?

In T11613#194386, @chad wrote:

After fixing a bug in the provided .htaccess (recursion because of using "L" flag in self-modifying path), setup starts.

Are you following another guide on the internet? We don't provide .htaccess configurations in our guides.

After fixing a bug in the provided .htaccess (recursion because of using "L" flag in self-modifying path), setup starts.

we detect and work correctly with both apc and apcu; Specifically, apcu pretends to be apc in many contexts, and we have code to distinguish them when needed.

Did you pull the latest code down? What is the error you are seeing now?

After fixing a bug in the provided .htaccess (recursion because of using "L" flag in self-modifying path), setup starts. However by quickly assessing the PHP code, I have noticed how APC "auto-detect" is PHP < 5.5 oriented.

D16542 should fix this and reveal whatever the underlying error is.

In T11613#194219, @chad wrote:

Are you running apparmor or selinux?

Yes it is solved!

Presuming this is resolved, but let us know if you're still having troulbe.

I believe this is fixed in HEAD of master. Update libphutil (by running git pull in libphutil/) and let us know if you're still seeing issues?

Yes my client system is Windows, while server hosting Phabricator is CentOS

No, I downloaded the non thread safe php version from official site.

I think I broke this in D16504, I'll fix it shortly.

Is your system Windows?

Honestly never seen these functions not included with any PHP distribution.

Did you compile or build PHP yourself manually?

PHP 5.6.13 (cli) (built: Sep 3 2015 15:14:39)

After upgrading and several weeks of the icons not disappearing,

Thanks anyways!

We can't move forward then, sorry.

No sorry, I don't have logging set up on that server.

Does your webserver error log have a long-form version of that error with a stack trace in it?

I'm honestly not sure. I followed the normal upgrading instructions as always:

I can't reproduce this. arc diff is working fire for me and many other users, and 5 different users have created 7 revisions against this install so far today alone (D16482 through D16489).

In T11517#192337, @rayzyar wrote:

In T11517#192332, @michaeljs1990 wrote:

I've just tried to reproduce again, seems my steps cannot reproduce it.
I couldn't find out a good way to reproduce this bug.
Here is what I found :
when I change my existing code (removing the comment of an exported variable or method), arc lint at root git directory doesn't trigger the ADVICE
however arc lint xxx/xxx.go could trigger the lint ADVICE

And I tried to copy the same code to try to reproduce this, it works perfectly with arc lint at root git directory.
BTW, I am using some extension, https://github.com/zerodiff/traphic

Thank you a lot for looking into this

In T11517#192332, @michaeljs1990 wrote:

I've just tried to reproduce again, seems my steps cannot reproduce it.
I couldn't find out a good way to reproduce this bug.
Here is what I found :
when I change my existing code (removing the comment of an exported variable or method), arc lint at root git directory doesn't trigger the ADVICE
however arc lint xxx/xxx.go could trigger the lint ADVICE

Sorry, I missed the thread on this.

Closing for now, feel free to follow up with steps we can follow to observe this locally. I have no idea how you're install got into this state.

How can we reproduce this error locally? Bug reports here require reproduction steps, not just the error message.

In T11517#191349, @chad wrote:

Please follow the instructions in Contributing Bug Reports. This is not a valid report without version information and step by step reproduction information.

I need help:>>> UNRECOVERABLE FATAL ERROR <<<

Note: this is only to log informations and try to reproduce the issue, with other user who see this bug, is it okay if I keep using this ticket ?

Ah, the project creation issue with gd issue is captured in T10405.

@epriestley - I did the same on your setup and can't reproduce!

Thanks! I still can't reproduce this. Here's the install I brought up, following your instructions as closely as possible:

@epriestley - Find the steps below. If the below seems insufficient, please close the ticket. I have a workaround which works and I have attempted to substitute any other extra reproduction steps with a diagnosis.

This is not a bug report until it has reproduction instructions. If we don't get reproduction instructions, we will not send this to the bottom of the list -- instead, we will close the report as "Invalid" and ignore the problem: we can not move forward without reproduction instructions.

@epriestley - I want to be as clear as possible that this is NOT a support request. I have a perfectly working hack ( something I think actually addresses the root issue of JS dependencies at some level ). So I am just trying to help and I don't have a sense of how critical this issue is to the overall Phab roadmap. So I will perfectly happy with Phab eveb if this gets thrown at the bottom of the list and will be happy to stop updating this specific issue if its distracting.

Is anyone encountering this on a https:// protocol install? I was plagued by this issue for a while and switched to https:// and it seemingly disappeared. Although I can't reproduce today on the http:// protocol either.

We really, truly need reproduction instructions that let us reproduce the problem in an environment we control. We're happy to accept this bug report and fix the underlying issue as soon as we're able to reproduce it.

Chrome Version 41.0.2272.89 (64-bit)

I'm reproducing this issue on a standard installation. As I said, here is our configuration

I am not suggesting that as a fix, far from it. That was hack I made to get it to work for me.

The problem is that the current code works for almost everybody; Adding reverse() will likely break it for everyone except for you...

@cspeckmim - I am on a Mac/Chrome. No plugins.

@chad I understand your insistence on the Steps to Reproduce for a public project like Phab. The reason I am vague ( can also be said about T10120 ) is that this is a very hard issue to reproduce reliably.

What operating system, browser, and browser plugins are you using?

We believe you're seeing a bug, but we can't reproduce it as described, knowing what you are doing differently than us is important. Reproduction steps should be thorough enough that we can follow them, step by step, and see the exact same issue as you are. Without being able to see the bug locally, we'll have no idea if we've fixed it or not.

These steps don't reproduce for me here, on Phacility, nor in multiple development environments.

@avivey - I have added the Steps to reproduce the issue.

Reproductions steps :

Sorry, we don't offer help diagnosing problems. See Support Resources for a list of what we do and do not offer help with.

Yes, this seems to be exactly what the other issue was referring to. We've just recently upgraded (previous codebase was 2+ years old) and massive amounts of commit email are getting sent out.

Yeah, this is likely the same as T11188. See that task for some additional discussion.

I also don't know how to reproduce the problem. I followed the guide found in T10246 to set up DryDock. I reported the bug hoping you could help me diagnosis the problem. How do you limit the number of working copies ?

I can't reproduce this.

Got it, sorry I missed that! Thanks for all the help you've been able to provide otherwise. If I figure out the root cause for this issue, I'll let you know. Thanks again!

Sorry! How could we rewrite Support Resources or Contributing Bug Reports to be more clear that we don't offer help diagnosing or troubleshooting issues like this?

Not sure that you read my response. I wasn't asking for installation help. Please re-read.

This isn't a valid bug report, and we haven't received new information in several days.

Sorry, we don't offer installation and setup help. See Support Resources for help understanding what kind of support is and isn't available from the upstream.

To clarify these errors are being written to the logs continuously until the disk fills up and I have to delete the file. And, I'm not sure what triggered this behavior.

I understand where you're coming from, but the problem is I'm not sure what led to this happening so I'm not sure how to proceed. Can you tell me is there some information I could obtain for you that would be helpful? Otherwise would you recommend upgrading/reinstalling my instance?

We are unable to reproduce this, and haven't received more information in about a week. Feel free to file a new task if you're able to develop reproduction steps which we can follow to reproduce the issue.