Update bundled ERFA to 1.2.0 - #3802

I've looked through this and apart from the CHANGE log typo it looks good to me (assuming travis passes). If anyone else looks at the diffs, note that the apparent deletion of int eraPmsafe is just because that was defined twice in the original. Nothing is deleted.

Thanks for the quick turnaround @eteq!

I haven't been involved in any of the ERFA releases or updates. If there wasn't a changelog entry before there ought to have been yes.

Merged manually in 9b8169e. I fixed the changelog entry too.

@taldcroft Just to make sure I understand correctly, this change should not be backported to v0.4.x right? IIUC you already added a patch there via #3795.

@embray - this is perhaps also a question for @olebole and/or @sergiopasra: if we backport this to 0.4.x that would mean versions that use the system ERFA should switch to ERFA 1.2 for consistency...

Also, this is a very minor thing, but @embray, I notice that this now says "closed" instead of "merged" (and for me it says the branch has unemerged commits). Not a big deal except that it leads to some confusion when trying to do statistics with the merge fraction. I suspect this is because you amended the last commit here with the typo fix instead of adding another commit. So it might be better to try to only add commits if this sort of thing comes up in the future.

I am not sure if I understand this. In Debian Jessie, we have astropy-0.4.2, erfa-1.1.1, and this is just what you get if you install the latest stable Debian version .
I plan to backport astropy-1.X to Jessie, and I would also backport erfa-1.2 then, and since one can decide on what one actually installs from the desktop, you can get all possible combinations (except if astropy-1.X would require erfa-1.2). I think for Fedora this is basically the same game.

I think for manual merges it always does this anyways.

I think it's probably fine to just add a patch to the erfa-1.1.1 package.

@eteq @olebole For Fedora, we still ship 0.4 in Fedora 21. I haven't upgraded to 1.x because there are small incompatibilities. So, yes, if you do a 0.4.x I will use it in Fedora 21.

Even if you don't, I will update erfa to 1.2 in Fedora 21 with astropy 0.4.5. The library is backwards compatible, so astropy should work with it (regardless of some tests failing)

@embray - re: the manual merge: that is definitely not true. It used to be, but now it properly recognizes a manual merge as a merge most of the time. I'm not entirely sure why it fails, but I've pretty much always had it work if I add commits on after the end of the existing pull request (instead of rebasing or amending).

@olebole - after this, you could in principal use astropy 1.x with erfa <1.2, but then you would not get the correct leap second correction. But it is still interface-level compatible.

For 0.4.x, the weird thing now is that the ERFA included there is not exactly matched to any ERFA version - if I understand right, #3795 ported back the leap second changes but not some of the other (I think all very minor) changes. So they should all be compatible in an interface sense, but with slight differences in leap seconds.

This is clear -- and one of the (dis)advantages of separate packaging: if you are stick to astropy-0.4 but want to have the current leap second definition, just upgrade erfa. Also, if you upgrade erfa, all programs that use erfa will benefit (including f.e. AST and ds9). Vice versa, if you just upgrade astropy (and not erfa) you will not have the newest leap second definition -- which may be surprising (especially if the release notes mention this as a feature). However, one can set the backports archive with high priority and so one automatically gets all updates.

@eteq Okay, I've wondered about that, because I have seen a handful of manually merged PRs where GH seemed to pick up the merge commit and mark the PR as merged. If it does work properly that's relatively new because it definitely didn't always. I've never gotten it do that myself though, so I don't know how it works. I wonder if appending a commit rather than modifying an existing commit would still be okay, because that still would be merging a different branch than the one the original PR was made from.

Yes, I recently had to do a manual merge on a project and was happy to see that the original PR was automatically marked as merged.