Question: travis-ci to test linux arm/ppc/mips

[mayeut]

I saw that travis-ci has been added to build/test official linux/macos binaries (& test other things).

Are you interested in having travis-ci test other architectures than x86/x86_64 ?
If so, are you doing that on your own or some contributions are welcome ?

I may be able to look at that within a couple months if that helps.
From experiences on #97, I already know that arm64 can be done and given the description in this link, a few others should also be possible.

[dcommander]

Very interested in that, yes. Also, I was never able to get the gcov stuff from your .travis.yml to work right. Not sure if I fully understood what that was supposed to do.

Would testing other architectures require another docker image?

[mayeut]

Yes, testing other architectures will require other docker images, one by architecture. A common step that will also be needed is to install qemu-arch-static on the docker host.

Regarding the gcov stuff, I don't know which step failed on your end. If this is the last one from my .travis.yml i.e. if [[ "${LDFLAGS}" =~ "coverage" ]]; then find $(pwd) -type f -name '*.gcno' -execdir gcov -pbl {} \;; bash <(curl -s https://codecov.io/bash) -X gcov; fi then the answer might be that you need to register that repo at codecov.io. Here's the link to the ci branch in my fork so that you can get an idea of what's actually reported & capabilities of that service: https://codecov.io/gh/mayeut/libjpeg-turbo/list/ci

[dcommander]

Ah, yes. That was the issue exactly. I didn't register at that web site because I didn't fully understand what the gcov script was supposed to do. What sorts of issues can be prevented by gathering coverage statistics? I've never actually done that before.

[mayeut]

Well, I won't say that it actually prevent issues on its own. An analysis of the coverage report can however help to pinpoint where tests could be enhanced so that all code paths are taken.
Mostly, it helps me when setting up tests. If I know that all code paths are taken, it's less likely that a regression will be introduced as a side effect of an enhancement or bug fix.

I consider that metric to be qualitative & I don't usually rely on it alone too much.

[dcommander]

Thanks for the explanation. For now I think I want to leave gcov as an exercise for the individual developers rather than include it in CI builds. I don't think that information is something I would use frequently enough to justify the CI overhead.

[mayeut]

I can understand that.
Just to be thorough, the previous link pointed to a commit that doesn't exist anymore... So there was only partial information (coverage per file). This link points to an existing commit for jcphuff.c https://codecov.io/gh/mayeut/libjpeg-turbo/src/174a3d2658544b17321e8d8854f2239bbf599b35/jcphuff.c
Here we can see that there are no tests involving restart markers.

[dcommander]

Yeah, but you can get the same information locally by running lcov. Philosophically, I see CI as a sanity check against regression, not as a useful tool for guiding development. Development takes place locally and usually requires numerous testing iterations to get right, so tools that guide development are better kept locally as well.

[mayeut]

I made some progress on other arch builds with travis-ci.
I haven't been able to get a mips image to work properly so no mips at the moment.

Here are the different docker images used:

• dcommander/buildljt:latest
• mayeut/ljtbuilder2:arm64-xenial
• mayeut/ljtbuilder2:armhf-xenial
• mayeut/ljtbuilder2:ppc64el-xenial

You can find Dockerfile for mayeut/ljtbuilder2 repository here: https://github.com/mayeut/ljtbuilder

I have also imported your Dockerfile for CentOS 5 in order to create a consistent TAG for this image in my repo mayeut/ljtbuilder2:amd64-centos5.
All images are using Ubuntu 16.04 LTS (xenial) except for the CentOS 5 image.

I updated the .travis.yml in my fork but since you'll probably want to get docker images in your repo, I've not created a PR yet (& not rebased/squashed my branch yet either).
The .travis.yml now checks for forks/PR => can't access secure environment variables, don't deploy.

You can get an overview here: https://travis-ci.org/mayeut/libjpeg-turbo/builds/166536277

At the moment, I know the SIMD path is taken while testing for arm64 & ppc64el. I still need to check in the armhf case.

[dcommander]

Thanks for your work. I'll play with these over the coming weeks and look at how best to integrate them.

[dcommander]

I brought up my own local copies of these images and validated all of them against the libjpeg-turbo build. Because it is so slow to do a complete build/test with these images (presumably due to the overhead of emulating the instructions), I think it is best for now not to include them in the CI builds. However, I will use the images locally to test and validate any changes made to the ARM-specific and PPC-specific code.

[dcommander]

I've actually been unable to make the PPC image work. Can you verify which version of Docker you are using? For me, when I try to build the image, it gives me the following when it runs apt-get update:

Processing triggers for libc-bin (2.23-0ubuntu3) ...
/sbin/ldconfig.real: 1: /sbin/ldconfig.real: Syntax error: word unexpected (expecting ")")

[dcommander]

I'm running 1.12.3.

[mayeut]

I'm running 1.12.1 but that does not seem to be the problem.
I tried to rebuild the image and it's failing with the same error.
I can pull & run the image I built some time ago but if I try to run apt-get upgrade, I get the same error.
Not sure what's going on.

[mayeut]

So, not knowing what was happening and not finding any issues opened that seemed related to this problem, I took another way around this issue. I updated my script & docker file to build images from scratch rather than from an existing image. Feel free to check the scripts which are still there: https://github.com/mayeut/ljtbuilder
I could test this on travis-ci (I restarted the same build than 2 months ago): https://travis-ci.org/mayeut/libjpeg-turbo/builds/166536277

[dcommander]

Same issue happens with your new Dockerfile, unfortunately. :(

[mayeut]

Weird, this time around I can build/rebuild without issues which was not the case last time.

[dcommander]

I'll try one of the other architectures. Stand by.

[dcommander]

Eh, never mind. I was going to try ppc64 instead of ppc64le, but they don't have a build for it unfortunately.

[dcommander]

Got it working using the Trusty image. Apparently this problem is specific to Xenial.

[mayeut]

Ok, good to know.
I added some fedora images while investigating this.
While the arm64 & ppc64le builds are probably useless now, they also have a ppc64 image that has at least one advantage - from a testing point-of-view - , it's big-endian. I couldn't get fedora 25 to work (seems there are some connectivity issues which I didn't try to solve). So I'm using fedora 24, it works and all tests are passing. There's a need to update multiarch support on the host to register ppc64 big-endian. I will open a PR at multiarch/qemu-user-static for that.

[dcommander]

I already have access to a real big endian PPC Linux server, as well as a Snow Leopard VM that can run big endian PPC code via Rosetta, so really the only reason I was interested in getting this up and running was to test ppc64le and ARM code. What I could really use more than anything right now is a way to test MIPS code.

[mayeut]

OK,
I'm having trouble finding a suitable MIPS image for now but I didn't lose hope in this matter yet. Not spent that much time on it yet.

[mayeut]

I finally got a MIPS image to work. Seems the issue is not in the image but in the way mips/mipsel is registered. It's in fact overwritten by mipsn32/mipsn32el. I will open an issue at multiarch/qemu-user-static to see what can be done.
I simply added the same qemubinary with the name of the n32 variant.
You'll find this pushed to my repo.
I built & tested master and all went well.

[dcommander]

That worked. Thanks!

[dcommander]

I had this working briefly with Travis, on their native Arm and PPC runners, before they started asking open source projects for money in order to continue using their system. I was forced to move to GitHub Actions, which does not have non-x86 build support. Oh well...