I don't think we mention every commit in the changelog?

I may have missed it but it doesn't look like this was mentioned in any changelog in December/January - or is this not yet in stable?

I think we're back in action and I have learned a series of valuable life lessons.

(This host is the replica database for the "Files" application partition, so even if I had to completely burn it to the ground nothing would be lost.)

I foolishly ran apt-get dist-upgrade because I am bad at computer and the motd said I should.

I wasn't able to reproduce this earlier so I'm not sure how to move forward, but feel free to follow up if you have more information.

One thought here is that updating variables_order is fine on the server, but I really don't want to force arc users to muck with php.ini. Some possible "solutions":

I'm going to merge this into T11580 because I think that describes what remains here.

I briefly dug these up:

I'm going to merge this into T11036, which specifically describes subproject columns.

One concern I have with this is that the largest sequential milestone may not be the "current" milestone. If you're currently in Sprint 4, someone may reasonably create Sprint 5 before Sprint 4 concludes.

Per above, this is working as intended. I'm open to implementing "Copy Columns from <Previous Milestone>" if anyone actually wants that, but it seems like I may have just made it up. Feel free to file a new task if you'd like to see it.

Yep, that looks good to me.

Just for my own understanding:

For (2), the specific problem is that there's no way to look up the milestone PHID, right? If you have the PHID I believe maniphest.search lets you find tasks tagged with a particular milestone:

@avivey my local repo does not have the metadata file but some of the commits do have the git-svn-id in the commit message. I think once we make enough commits on this repo this problem should probably go away but this particular repo doesn't receive commits very often. I would rather not fork arc.

@jcarrillo7: Does your local repo has a .git/svn/.metadata file? We're short on actual data for this use-case.
Alternatively, can you fork arcanist for your install?

When I try to make E1211 recurring (see screenshot below), I get

See also T4144#175505

Please read and follow the guidelines in Contributing Feature Requests, this should have been at the top of the Feature Request form (see below). Unfortunately we're not able to take requests that don't state a root problem.

n/m, I see this was fixed today with https://secure.phabricator.com/rP1f2306999bb599bcedc0c4bfff2f2b3aade58630

I think this should be fixed by D17146, which landed a few hours ago. Presumably you're running some ancient stone-age version of Phabricator that's 6 or more hours old?

P.S. I love the new categories, they're my favorite improvement in the last year!

I think I got all of these, but yell if you catch any more.

We keep hitting the same thing where a conduit reports an svn commit for "sourceControlBaseRevision" on a repo that is git (was originally svn and was transferred to git).

This should do it:

Yep, here is the default value on all the installs of PHP I've done from source:

Am glad to get ahead of it. What's the exact incantation we need to put into our php.ini?

(After T12071 we will almost certainly require "E", so you could get ahead of that now.)

Actually, it looks like PHP defaults to "EGPCS" but ships with config files that use "GPCS" (??? why would you do this ???), so this is probably not something that got changed or configured intentionally or accidentally.

Perfect, thanks! That's what I expected, so D17148 should resolve this. Alternatively, setting that value to "EGPCS" (without upgrading, just restarting the daemons) should also resolve this.

I believe this is now fixed at HEAD of master. You should be able to pick up the change with arc upgrade now (if you run master) or in about 36 hours (if you run stable).

While I'm chasing this down, can you show me the output of this command?

This is an unintended side effect of D17100 but resolution isn't straightforward.

This is D17122 interacting with some extremely high-quality code in arc.

This is far afield from an actionable bug report.

Yeah, There is no postfix, but my distro (SUSE Linux Enterprise) sendmail is a postfix variant. I have to match your sendmail config to my postfix. The last part was done with the help of canonical which is wrong way to do it probably. If it is too much work to debug this just drop it. It seems to be a very special case of configuration, server variant.

Patch attached which addresses this - filter and object selection done on a new getToOrCCAddresses call. This patch is based off stable branch commit 58375fa9e6db4a389fd6029ee1ad14ddb0dc9e90.

Using postfix instead of sendmail

Sorry for the typos :D, Step by Step Guide:
Follow this: https://secure.phabricator.com/book/phabricator/article/configuring_inbound_email/#local-mta-installing-mai (Local MTA Section)

We could possibly remove it entirely since I think it isn't useful for 99% of users, but D17144 just fixes the command.