On Mon, 2020-05-18 at 20:40 +0200, Mattias Ellert wrote: > 1. Have you removed the 2.6.8-1 version? It is still listed as being > part of unstable here: https://packages.debian.org/unstable/gfal2 > I know there is some delay in those pages to be updated, but getting > THAT VERSION removed was the purpose of filing the bug in the first > place. If it is not removed, the problem is not solved.
That page looks suspicious as it claims arm64 is an "unoffical port". Someone on IRC suspects it might use an ancient Packages index from ports.d.o from 2014 for arm64 that gets shown when the main archive no longer has the package... I would recommend either using the Packages/Sources indices from mirrors (with delayed updates) or the `rmadison` tool from the devscripts package which accesses the authoritative database used by dak. `rmadison` is probably better as there are no delays with updates and sometimes a package is not shown in the Packages index. The current state in the archive is this: $ rmadison -S -s unstable gfal2 gfal2 | 2.17.3-1 | unstable | source, all gfal2-doc | 2.17.3-1 | unstable | all gfal2-plugin-dcap | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-file | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-gridftp | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-http | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-mock | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-sftp | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-srm | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal-transfer2 | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal2-2 | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal2-dev | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x > 2. Is a re-upload really necessary? A re-upload wouldn't end up in NEW > anyway, since no new binary packages would be created by the new upload > that are not already in unstable (except for on arm64). If the existing > binary arm64 build can't be put back in, a binnmu for arm64 should be > sufficient. It would be wasteful to rebuild the package for all > architectures. I restored the arm64 binaries (2.17.3-1). Ansgar
