control: tag -1 + moreinfo Hi,
On 2022-07-11 02:46, Magnus Danielson wrote: > Package: rpcsvc-proto > Version: 1.4.2-4 > Severity: grave > Justification: renders package unusable rpcsvc-proto is used to build many packages in Debian, so I doubt it is completely unusable. > Dear Maintainer, > > Template answers first, for your convenience. > > * What led up to the situation? > > Rebuilding an application using rpcgen. > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > Run rpcgen, then tried to compile the produced files. > > * What was the outcome of this action? > > Any of the /usr/include/rpc/* header-files referenced such as > #include <rpc/rpc.h> > etc. fail to include, all the related definitions missing causes large > amount > of compile errors. Could you please give me more details about the issue? Ideally copy and paste the error message. My guess is that your problem is not related to rpcsvc-proto itself which just provides rpcgen and related header files, but with the removal of the SunRPC implementation for glibc. You need to switch to the TI RPC implementation instead (using the libtirpc-dev package). > * What outcome did you expect instead? > > Nice compile as headerfiles is found. > > This is most likely a consequence of repackaging the rpc-part. Looking back > at > the stable version of libc6 the header files is there in libc6-dev, but for > testing and unstable they are not. I expect that using these this would > work. > If the headerfiles is in another package, dependence on that should be in > place. The files that are removed from libc6-dev are the ones related to the removed SunRPC implementation. libc6-dev (indirectly) depends on libtirpc3-dev so the replacement header files should be available on your system. That said it is not a one to one replacement, so you need to use pkgconfig to get the compile and link flags. > Package-testing should actually include a dummy-application that generates > through rpcgen and then compiles it successfully. Then this error would be > caught. Another approach would be to check that the same header files gets > installed from previous packaging and new packaging. Both methods would be > recommended to create fail-safes and quick turn-around for package > maintainers. Don't hesitate to provide a patch doing that. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net