I can't reproduce this: removing panels from dashboards works fine for me:

In our setup (as an open source project) we often get differentials created with base commits which do not exist in upstream. As a result using arc patch often fails, even worse, in a non-recoverable way as --reject is passed to git apply. In a patch fails to cleanly apply it is hard to continue the work-flow and manually correct the merge conflicts.

"Bizarro Gremlin" is just an alias for Quicksand

i'm bad at search

I'm going to write up Diviner now, then Upgrading guide

🅾 Ⓜ 💎

🙉

Yeah, 7.1.2 RC1 seems to fix the problems. There are like 2 dozen random "uuhh fix off by one error, revert thing that overflowed something, you bastard, fix this too" commits in that commit log, even some affecting stuff like libgd (which you'd think would have been pretty hardened), so it's really impossible to tell what fixed what without it becoming tedious.

I think we currently don't really try to handle these cases:

That tip probably does not fit on screen in any of the orientations: it obviously won't fit to the north or east. If we try to put it to the south, part of it will be offscreen to the right. If we try to put it to the west, part of it will be off the top of the screen (the rectangle we use to detect the size of the tip box is slightly larger than the actual pixel size of the tip because we get weird scrollbar interactions if we use the size of the tip exactly).

My trick is:

Yeah I couldn't quite grab a screen

Here's what I see:

Chrome:

• Go to Workboard
• Click Fullscreen
• Hover over Fullscreen - tooltip is elsewhere?

Yeah, I don't think I fixed it. I tried this set of steps at master prior to D17308:

I'm not sure if I actually fixed @rphl's issue or not. D17308 was just aimed at the existing issue under the theory that we'll see more of it after this ships if we aren't already seeing it, but his report definitely might be a new issue.

I thought it might be that same issue, but sounded like it was a new issue and not a pre-existing one.

Awesome, thanks for hunting that down.

This should now be resolved at HEAD of master, and should promote to stable later today.

My testing from D17296 indicates this would also resolve the original problem described in T9639

Gotcha... Thanks for the explanation. Initially, I wasn't exactly sure what was going on... I sent an email out telling folks to use "Auditor: ..." in their commit messages, upgraded to clean up what I mentioned here T12181: Bulk Deleting Audits does not remove "Audit Required" from Commit, and then the "Auditor: ..." tag stopped working when our team started using it. Appreciate the fix!

Thanks! I think this is the timeline of events:

Ahhh... Before both "Auditor: ..." and "Auditors: ..." worked. Now it appears that only "Auditors: ..." works. I must not have been trying it with "Auditors: ..." at all.

Per above, it sounds like upgrading fixed what you were seeing?

This isn't a bug report we can accept upstream. See Contributing Bug Reports for help. In particular:

No, not yet... In those examples, I just happened to have Auditors on the first line. Usually, it's not on the first line for us.

Does that explain what you're seeing locally?

This isn't a bug report we can accept upstream. See Contributing Bug Reports for help. In particular:

Those commits are not expected to trigger an audit after D17122 / T10312. The first line of commit messages is now always parsed as a title, even if it begins "Auditors: ...", "Tests: ...", "Reviewers: ...", etc.

Is there a full description or is it a joke? I need to do my case study on tasks that contain errors. I guess that is some empty task that was deleted by the creator immediately.
Will buy case study anyway, no point in looking for phantoms here.

@epriestley can you have a look at this, please?

@epriestley can you have a look at this, please?

I would imagine they're using something along those lines yes. I think we'll probably keep a bunch of people happy if pushing Git refs up were supported.

I'm just curious how people are generating diffs, just command line then cut and paste? I would presume those users would be fine with pushing a branch up for review. Are there other methods we're not considering, like IDEs?

Chances are we're going to get complaints that go either way. Myself, i'd tend to prefer T5000.

You would prefer this over T5000?

We've had some people in KDE kick up some fuss about this.

The best way to get help here is to provide us with all information, every step taken, system, phabricator versions, if you could reproduce it on Phacility, etc. Just giving an error message isn't enough for us to give you a lot of guidance

It is a private repository - and I have access to it. I can clone it and push to it. So why would this error be thrown. Diffusion shows the number of commits correctly and the name of the recent commit as well but when I click on the repo it outputs the above error.

In T12196#210013, @epriestley wrote:

PHP7.1 segfaults about a dozen times a day for me, every day, with little apparent rhyme or reason to the segfaults.

I can only assume I am being punished for not rushing it into production as soon as possible. Perhaps we can deploy PHP 7.2 to production directly from master without waiting for an actual release.

PHP7.1 segfaults about a dozen times a day for me, every day, with little apparent rhyme or reason to the segfaults.

Request reopen, based on my above comment.

This does not contradict T5474, but compliments it. Both tickets are required to provide seamless operation

Awwwww yissssssss, looks like PHP 7.1.2 RC1 fixes it! Using the Fedora 25 "PHP 7.1 Remi Testing" repository, 7.1.2 just completely finished a run of arc liberate on Phabricator without problem.

Yeah, the sury repository is the one maintained by one of the PHP devs. I think if you just do something like apt remove php71* or apt remove php7.1* you can just reinstall all the php5.6 packages and you'll be dandy, at least as far as arc is concerned. They're all in the same repo, just separated by version suffix.

I updated to test this bug. I'll have to roll back if I need to add a new class.

Just curious -- did you just notice this, or did you upgrade just to test this bug? If it was the first, that's an interesting data point! (that arc liberate is less common than I expected)

a devastating self-own. we've all owned ourselves.

well i've ruined my dev environment now...

Yup, that's the one @chad. I haven't tracked it down any further with strace or anything -- but if you try running that phutil_symbols.php command a billion times, note it doesn't fail every time, or possibly even at all (try like, for x in $(seq 1 1000); do php ... >/dev/null; echo $?; done | grep 1 or something). But if you run arc liberate again, it *will* fail every time, just on a different file, at a different point.

xhprof isn't needed to reproduce this; it's xhpast that's involved. Maybe. (xhpast is just a simple bison/flex parser/lexer combo so it isn't dependent on PHP internals in any way, and it's what drives the module parsing, etc)

like this:

T9805?

i like that dog's hat. it's a good hat.

We need a neologism for "bad workaround".

(A "workaround" is to not use dashboards, but we'll fix this soon.)

Ah, cool -- thanks!