Mmh. based on the travis matrix, it's not really clear to me, what's the problem. Debian fpm x86 always seems to fail, with other targets failing at random it seems 🤔

@marcelklehr Did you try to build those failing images locally?

Debian uses different include locations for each architecture

@maxmeyer I tried yes, but it's not quite easy to do and they fail locally as well.

@tianon do you know any solution for the architecture relative library paths on Debian?

@J0WI does this help at all? https://wiki.debian.org/Multiarch/LibraryPathOverview
I may not understand all that's going on in this PR, but I am anxious to see this merged

Pretty sure I found the problem.

@marcelklehr, the lines where you have
test -f "/usr/include/gmp.h" || ln -s "/usr/include/$debMultiarch/gmp.h" /usr/include/gmp.h; \
or similar, i think it should be changed to
test -e "/usr/include/gmp.h" || ln -s "/usr/include/$debMultiarch/gmp.h" /usr/include/gmp.h; \

test -f means the file exists AND is a regular file, which based on the fact that you create a symbolic link on failure means that this file will never be a regular file. test -e is a check for simple existence of a file with no other conditions. If you want to check if /usr/include/gmp.h exists and is specifically a symbolic link, then use test -L instead

Now, we are where I've been before. Still all debian i386 builds are failing. :/

@marcelklehr hmm... the build logs indicate it can't find gmp.h when building in i386... wish I could see where it was trying to look for it. The fpm image is based on debian 'buster', and according to https://packages.debian.org/buster/i386/libgmp-dev/filelist the header file should be at /usr/include/i386-linux-gnu/gmp.h. Wish I could see what dpkg-architecture --query DEB_BUILD_MULTIARCH returns on Debian 'buster' i386. I suspect it isn't "i386-linux-gnu"

take a look at https://travis-ci.org/nextcloud/docker/jobs/603287089#L4009

docker uses /bin/sh to build which doesn't support [[ ]], replacing it with [ ] should fix this

@tilosp literally popped up seconds before I clicked "comment" to say the same thing! Also, can confirm: it builds for me with the suggested change

ooph, fingers crossed. Once the build passes I'll do a rebase to clean things up a bit... 😅

It breaks the build of some of the full example dockerfiles because they try to install gmp.
Simply removing it from those Dockerfiles should fix it.

Hah, if I only I had looked at the examples.

@tilosp @J0WI Have you thought about creating a CONTRIBUTING.md file for this repo, where people can learn how to contribute, how things are supposed to work, some basic info about the CI process? That would go a long way, I think :)

yeah having a CONTRIBUTING.md to help out new contributors makes a lot of sense.
I am not really into writing docs, and i am also not sure what info would be useful.
Maybe explaining which files to edit and which are auto-generated by update.sh.

@marcelklehr what info about the ci would haven been useful to you? Simply explaining which Dockerfiles get build?

btw could you also remove the gmp from the full/fpm-alpine example? It doesn't break the build, but building it twice still wastes resources.

When will this be released? I will test it then asap :) 👍

Once docker-library/official-images#6867 is reviewed and merged it will be build and published by https://doi-janky.infosiftr.net/.