Confirmed at HEAD.

D17656 is legitimately pretty hacky so this is now entangled with T11110, etc.

This is a sort-of-intended result of several different rules colliding to make a mess. Here's the primary rule:

Thanks. Deployed just now and confirmed working.

This should be fixed by D17654 and available at HEAD of master and stable. Thanks for the report!

This reproduces for me locally. (??!?)

Please put your version information on all bug reports. There has been a lot of churn here so we need to know you're at HEAD before trying to reproduce.

Thanks, closing this one!

You should have sweeping janitorial powers as a member of Community now.

Or I guess, you* can close this since I can't. Whoops.

Scratch that, you're right @epriestley . We just got confused during the workflow and didn't realize jmeador previously accepted.

Whoops, I think I may have totally fudged the screenshots. Let me try to reproduce with proper screenshots.

It looks like before step (2), jmeador can only accept for one reviewer (the package), since he's already accepted for himself. The current rule is:

This seems to have fixed the issue. Thanks for the quick fix.

Thanks for that catch in D17651, let me know if you're still seeing issues after updating. I'll cherry-pick that to stable too.

Yeah, that looks like it's consistent with the hypothesis above. I expect:

Not sure if this is useful:

Yeah, pretty sure what's happening is:

See also T12532 for related work.

I think the first error is causing (maybe?) the chunk engine to fail, so we're falling back to the "upload the entire file in one shot" engine, which ain't great on 4GB files.

Alright, let me take a look. That exception is pretty specific and it may be obvious from the code.

Hmm, I got a different error with a 9MB file. But this looks like a problem on our end:

I originally tried a 1GB file and wasn't able to reproduce...

(Actually maybe you need a 9MB file.)

Does this reproduce with a 5MB file?

From the server-side error logs:

Okay, I managed to reproduce it with non-sensitive data:

A SAAS install reported bumping into this.

Absolutely. Thanks very much.

Does the language in D17648 look OK?

@epriestley would

The second field (which is the password field) must not be set to !!. This value will prevent login. If it is set to !!, run 'usermod -p NP vcs-user' to block only password logins. If usermod is not available on your system you will need to set the password field value for vcs-user to 'NP' by manually editing /etc/shadow.

be acceptable?

The address is verified but the verified flag on your account is not set.

• After D17646, event reminder mail should render with timezone information.
• Additionally, timezone information in this mail and other modern ModularTransactions mail will now render with timezone abbreviations where available: (PDT) instead of (UTC-7), for example.
• I wasn't able to identify or reproduce any actual bug here. Hopefully the additional information in D17646 will make it clear what's happening. The expectation is that the mail you receive should use the same locale as your account uses in Settings → Date and Time → Timezone, and in all my local attempts to reproduce this that was the case. Note that if an event is scheduled in UTC but instances cross daylight savings time in a particular locale the local time of the event may change. I don't think that's what happened here, just mentioning it. See also T11073.

I think this is a legitimate bug where the viewer's timezone on the event becomes stuck as the last invitee we process, so events with multiple invitees in different timezones can generate mail with the last user's timezone.

I believe this occurs only if an install has improperly migrated legacy data. This install does; presumably yours does as well.

ICS issues seem to have calmed down so I'm going to call this resolved; future issues can just be filed as separate tasks.

In T12521#218608, @chad wrote:

Does this reproduce against a Phacility instance or our test mercurial repository here?

• When you click "Delete File", we currently delete the file in the web process. Since we've supported enormous files and pluggable storage backends for a while, this could take an arbitrarily long amount of time to complete.
  • Instead, we want to flag the file as "deleted", hide it in the web UI, and queue up a task in the daemons to actually get rid of the data.

Please indicate the versions of mercurial on client/server as well as any extensions you have enabled on client/server

Use diffusion.repository.search or phid.lookup to map repository identifiers to PHIDs.

Does this reproduce against a Phacility instance or our test mercurial repository here?

This isn't a bug; the cURL request is not a websocket request.

The segfaults appear to have subsided for me so I'm just going to close this as "upgrade to PHP 7.1.2".

While we haven't been showered in free money, I also haven't seen more reports of this so I'm going to presume it's resolved.

This appears to now be resolved for me, presumably by the fixes for T12079 and T12219.

I'm just going to merge this into T8033 since I our intent there is to prevent this situation entirely.

We don't know how to reproduce this, so we can't move forward.

We don't have any way to move forward here.

In T12516#218475, @rabahmeradi wrote:

Is this really the new 'Needs review' icon or I have problem with fonts?

Is this really the new 'Needs review' icon or I have problem with fonts?

Happy to accept a patch for these!

Feel free to submit patches for these!