On Sun, 2020-08-16 at 15:51 +0200, Attila Szalay wrote: > I have a relatively new package (BoxFort). In the beginning, I used > the "any" architecture in the control so it was (tried to be) > compiled on all architectures. But from the build logs, I > realized that currently the package can only be compiled/used in a > very few architectures (amd64, arm64, i386) because of various > reasons. > > Also, a bit late, I learned that if I have a package with only a > static library inside, I do not need the lib package, only the -dev. > So I dropped the lib package for the next upstream version and > limited the architecture to the reliable 4 and uploaded it to the new > pool. > > But for some reason (either because the dropped lib package or post- > initial arch change) the Britney miss the "armel" and the "armhf" > architectures and not let the package arrive at testing.
It's the latter. You stopped building the binary package on those architectures but the old binary packages are still in unstable. You could check this yourself on e.g. the ftp-master mirror (or by looking at the relevant packages files): $ dak ls boxfort -S boxfort | 0.0.0-git20200105-3e16c0a-2 | unstable | source boxfort | 0.0.0-git20200105-3e16c0a-6 | unstable | source boxfort | 0.0.0-git20200808-ac0507b-2 | unstable | source libboxfort | 0.0.0-git20200105-3e16c0a-2 | unstable | armel libboxfort | 0.0.0-git20200105-3e16c0a-6 | unstable | armhf libboxfort-dev | 0.0.0-git20200105-3e16c0a-2 | unstable | armel libboxfort-dev | 0.0.0-git20200105-3e16c0a-6 | unstable | armhf libboxfort-dev | 0.0.0-git20200808-ac0507b-2 | unstable | amd64, arm64, i386 > What can be done to fix this situation? You need to ask ftp-master to remove the old binaries, via an appropriately-titled ftp.debian.org bug. Regards, Adam
