Need expertise from @astrofrog , @mhvk , or @olebole on the exotic archs:

    The headers or library files could not be found for zlib,
    a required dependency when compiling Pillow from source.

You need to install the development libraries of zlib. On Debian/Ubuntu:

apt-get install zlib1g-dev

@olebole , thanks, that solved zlib, but now it is complaining about The headers or library files could not be found for jpeg. Not sure why these being missing isn't a problem in master but somehow is a problem in v4.0.x branch.

@plim Similarly, install libjpeg-dev. Probably you will need to install even more -- see https://packages.debian.org/source/stable/pillow for a list of build dependencies ("adep") if the "pillow" package.Maybe you just install python3-pil from the system and this way avoid to install it yourself? It is in stable however version 5.4.1; but if that works, it may be the quicker way.

Not sure why Azure didn't kick off this time. 🤷

Not sure why Azure didn't kick off this time. shrug

you upset it.

Now the aarch64 and s390x jobs are failing at trying to build freetype...

    Building freetype in build/freetype-2.6.1
    GNU make (>= 3.80) or makepp (>= 1.19) is required to build FreeType2.

apt-get install libfreetype6-dev?

That didn't work but I think it is a symptom of a different problem. I don't think it should be trying to build these things from source.

error: invalid command 'bdist_wheel'

Yeah, I dunno what is going on with the aarch64 and s390x. Ideally, I shouldn't have to modify what I copied over from master at all. Options:

• Wait for @astrofrog to tell me what to do.
• Remove these two archs from LTS CI. (Not ideal?)

@plim since we build it on 390x for Debian, I am wondering what the exact problem here is (I couldn't find it out by the logs). One way would be to just install build dependencies from the Debian build as needed. They are here.

Another option, maybe sounding strange, is to install python3-astropy - it will pull everything in. That's how I had it initially on travis, before we felt that it was perhaps a bit circular. But for LTS, the dependencies are going to remain OK and we can at least move forward! (just need to check the logs once that we are not testing Debian's version!)

If deb-src is in etc/apt/sources.list:

deb-src http://deb.debian.org/debian/ buster main

one could also do apt build-dep astropy, which pulls all dependencies to build astropy (the buster version 3.1.2).

I just made a test (on x86_64): I could build (no tests) the astropy-4.2 with the following updates:

• pyerfa (rebuild from the current sources; needed in turn the new liberfa, tests disabled)
• extension-helpers (rebuild from the current sources)
• numpy-1.19 (needed to update from pip). This would seriously prevent me from providing a backport btw.

Pytest-4 would be another, for the tests.

This PR is only for astropy 4.0.x . It has new errors now but I am not familiar with it.

I'll have a look at this.

Thanks, @embray ! Might need a rebase, not sure. Feel free to take over this PR.

I'll rebase. Was there any remaining issue other than the failing tests on "exotic" architectures?

Also @pllim your branch names are always such a joy.

Was there any remaining issue

Yes, the non-exotic CI was failing too. Though this current error is different than what I remember -- RuntimeError: module compiled against API version 0xe but this version of numpy is 0xd

Not sure why clocale had matplotlib pinned to 2.1.x

I have no recollection of this. If @astrofrog doesn't know, I'll dig more tomorrow. Thanks for working on this!

@pllim Well what's weird is this tox.ini did not even appear in this branch until this PR, but I don't see any record of that line ever existing in the tox.ini on the main branch.

Also why are you on GH on Sunday night? XD

I'm working on the aarch64 and s390x builds. I have a few fixes I'm testing out to speed up their builds. I also fixed the Python 3.7+numpy 1.17 build but I'll push the fix tomorrow once I (hopefully) have the other fixes working as well. Gonna go to bed and check in the morning since it's still quite slow to run the tests on those =)

@embray - just to reply to your comment about backports, we still do these manually and not through PRs (but I think there were some discussion about changing how we do backport in the infrastructure group)

I'm seeing some ✔️ here 😁

Looks OK with the Quantity check; still pondering wether this is a better place for the test than _wrap_wofz...
Your solution would have the widest possible effect, wheres putting it outside would keep _hum2zpf16c closest to Franz Schreier's original implementation; also it is by definition a function of a dimensionless number.

@dhomeier Please open a PR when you get a chance for a better fix. I'm running out of time here that I can work on this.

Concerning the extra units, Lorentz1D can also produce results like Unit("Jy micron2 / nm2"). But these two indeed seem to be the only two instances, so it might be worth addressing.
Some other functions change units from the expected values (like 100 cm instead of 1 m), but I'd leave those and try to make
assert m(*args[:-1]).unit.powers == args[-1].unit.powers
work in the tests - that's a PR for master indeed.

Anyone know anything about this SAMP failure?

astropy.samp.errors.SAMPProxyError: <SAMPProxyError 5: 'Private-key e08fe4be-8826-11eb-9f18-9bedc64c72c6 expired or invalid.'>

I don't think it has anything to do with the other one I fixed.

Ugh... It's always something with SAMP. I haven't seen that error but for the sake of the release, just xfail that one unless @astrofrog can come up with something.

I don't really have time to dig into the SAMP failure so either restart the CI to see if it's non-deterministic, or xfailing seems sensible.

Yeah I was thinking of restarting it too.

@dhomeier Please open a PR when you get a chance for a better fix. I'm running out of time here that I can work on this.

This looks good to me, not really sure actually which variant I would prefer.
Just one other suggestion to change the FUNC_MODELS value to

 {'class': Voigt1D,
  'parameters': {'amplitude_L': 2 * u.Jy, 'x_0': 505 * u.nm,
-                'fwhm_L': 100 * u.AA, 'fwhm_G': 50 * u.AA},
+                'fwhm_L': 100 * u.AA, 'fwhm_G': 5000 * u.pm},
  'evaluation': [(0.51 * u.micron, 1.0621795524 * u.Jy)],
  'bounding_box': False},

to check the numerical result if all inputs have different units.

@pllim with the "(Allowed Failure) Python 3.7 with remote data and dev version of key dependencies" I know you mentioned something about xfail_strict = false, but since it's titled "Allowed Failure" isn't allowed to fail for now?

since it's titled "Allowed Failure" isn't allowed to fail for now?

Sure... Sometimes ignoring it masks real bugs but if it is only SAMP, I guess we can ignore.

Except the SAMP one wasn't on that :/

Looks like the SAMP error was indeed a random fluke.

I'm confused by those IERS xpasses, because I'm not seeing that locally... can anyone else reproduce outside of CI?

Sorry folks, I'm gonna have to bow out for tonight. We're still just waiting on the ARM test, but it was working last time I ran it, and it looks like the zArchitecture test passed. I'm not top worried about the allowed-fail test, though as @eteq says it is weird. If anyone wants to add a workaround to it they're welcome to. Otherwise I'm happy with where things stand, and can address the remaining issue in a follow up.

I'm confused by those IERS xpasses

Turns out we simply skip them in dev now, so I manually backported those skips here.

I think that's the remaining issues, given that the rest of CI is now green? Can we merge when CI is green?

p.s. This is still technically my PR and I cannot approve it.

CI is green! Thanks, @embray ! @eteq or @astrofrog , please approve if you okay with this.

The two that I did in the last minute was:

• TST: XPASS to not fail IERS test #10700 -- already in 4.2
• TST: Skip flaky utils test on Travis #10757 -- already in 4.2

Therefore, I believe they will not be listed by any backport scripts. If they are, then something is wrong.