p-a-s/n-f-u: isdnutils and reverse-build-depends of libcapi20-dev
I'd like to clarify the package-arch-specific / s390 not-for-us status
of isdnutils and of a few of my packages which build-depend on
libcapi20-dev, a binary package built by isdnutils.
* asterisk-chan-capi is in not-for-us for s390. Why? Reading old build
logs suggests that the problem was that the build-depends on
libcapi20-dev was not satisfiable on s390. It is now. So, unless you
have another reason to have it as not-for-us, please remove that!
* capi4hylafax is architecture-restricted in p-a-s; the only reason
known to me for that would be that it build-depends on an
architecture-restricted package, namely libcapi20-dev. But the
restriction is more strict than the actual situation in etch/sid;
please include _all_ architectures that have or will have
libcapi20-dev installed. That is, to the best of my knowledge:
alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc
Given that the only reason is unavailable build-depends, wouldn't
state "dep-wait" be more accurate than a listing in p-a-s? At least
then it doesn't need human intervention when the array of
architectures the build-dependency is available on grows.
* p-a-s lists "chan-capi". This package has been removed from Debian:
You probably want to remove that line.
* p-a-s lists libcapi20 as being architecture-restricted; in
particular s390 is not in the list. There are several issues here:
1) The binary package is now named libcapi20-3, so I presume that
this line has no effect. If the reason for existence of that line
still exists, it should be changed to libcapi20-3. If not, remove
On the other hand, it has been quite some time since the package
was named libcapi, so even if theoretically justified, it seems
that not having that line doesn't bother anyone... as nobody
2) I would expect libcapi20-dev to have the same restrictions as
libcapi20-3, but it is not present in p-a-s.
3) s390 has successfully built libcapi20-3 and libcapi20-dev, and
they are in the archive, probably as a result of the renaming not
being reflected in p-a-s. So either these packages are broken,
but nobody noticed because nobody used them or s390 should be
added to the list. I'm inclined to believe that s390 should be
added to the list because the "Architecture:" line of the control
file in the sources includes s390.
More generally, probably p-a-s should reflect the "Architecture:"
lines; missing are hppa, ppc64, s390, for all binary packages of
isdnutils (except arch: all ones).
Note that hppa seems to be in the same situation than s390: the
packages are successfully compiled and installed.
4) The comment says:
# isdnutils has one arch: any package (isdnvboxclient), so we can't % it ....
but that is wrong. isdnvboxclient is:
Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc ppc64 sparc s390
like the rest of the binary packages (except for the architecture: all ones).
So, % it all the way?
5) Any particular reason armeb/armel is not in the list, both for
p-a-s and the architecture line in debian/control?