Specifically, this is my best guess at what's going on:

I've marked D15135 as fixing this out of a general abundance of sunny optimism.

I think D15135 actually fixes this. I can't reproduce it in iOS Simulator after applying that patch.

D15136 distinguishes between "touch-device" mouseovers and "mouse-device" mouseovers rather than relying on device detection, since the screen resolution of the iPad Pro is apparently a billion pixels by a trillion pixels and device detection is clearly increasingly hopeless.

Nice work! I arrived at the same conclusion shortly after you did.

I can reproduce this on my iPhone 4s which correctly selects 1-up mode, so I agree that this is probably not a duplicate of T9969.

(Oh, there's a missing comma after e in some of the output above, but that's just because I typed the replacement text for the patch wrong in my "linter".)

Here's what I did:

(Where "XYZ" and "QWERTY" can be arbitrarily long sequences and may each contain zero or more newlines, and may each be of arbitrary length -- you can replace a single character with a huge block, or vice versa, etc. -- lint is not line-oriented internally.)

The expectation is that this will just work properly already. We have a number of similar rules in the upstream.

• Emit messages for every line with a problem.
• If you raise them at "warning" severity, they will only be shown if the user modified the line.

This is intentional. The file is visible in the UI in the edit history of the comment, and still part of the object in that sense.

I think we can do the background drag thing too, that shouldn't interact poorly with anything else (I think? Probably?).

bin/host destroy exists now and no one has specifically asked for this, so I think it's OK to leave it as an "email us" option until the workload justifies making it explicit.

I've implemented this and relieved pressure on db005, although see followup in T10236.

Sorry, we don't offer support for custom development. See Support Resources and Contributing Bug Reports for details.

Would this phrasing be more clear?

Please see Planning. We update tasks when new information is available, we don't have a secret shadow tracker with lots of juicy secrets that we aren't sharing.

There is no cache mechanism which would be cleared by adjusting configuration that is not also cleared by restarting the webserver and daemons, so it sounds like this was caused by evil spirits.

This is the policy on the IAM user:

Can you give me an example of a rule which is sometimes wrong and where the implied patch is not obvious from the rule name?

It may also be useful to run arc unit --everything in libphutil/, as that will trigger a number of signature-related test cases.

PhabricatorEmbedFileRemarkupRule has the "correct" solution for this problem, via a chain of permissions grants tied together with KEY_EMBED_FILE_PHIDS. This will grant the file the same permissions as the relevant object (e.g., the task or whatever).

Broadly, here's a command string (with live, active credentials) which works for me to put data into an eu-west-1 bucket:

I can't reproduce this. Before we move further, it looks like libphutil may be out of date?

We are too; that's expected to work correctly.

Thanks. I'll bring up a eu-west-1 bucket and see if I can reproduce this.

Can you show me the output of this command on your system?

At least some of these were likely T10214. I'm just going to merge this there until more evidence crops up.

I also can't reproduce this here or locally. I tried several different projects, and tried users with and without permission to edit the menu.

This should be resolved by D15112. I've made a note in T9789 to catch this class of issue sooner before we make the consequences more dire by pursuing changes planned there.

The only issue that I've noticed so far is that @{article: triggers the autocomplete, whereas it probably should not.

After D15105:

This looks like a known issue with implementors using NSS instead of OpenSSL. Here's the Red Hat bug:

This should be fixed in HEAD. Thanks for the report!

What system are you on that doesn't support this cipher?