Comment 7 for bug 2003668

Overall, nice work! I do have some questions and remarks, though.

* Why not Arch: any ? opencryptoki is available on all platforms specifically
  to make testing easier, I think this provider should do the same.
  Anecdotically, it builds fine on amd64.

* Can we install the .so files in /usr/lib/$ARCH/ossl-modules ? This would
  allow better integration with oepnss, make the openssl.cnf.in a bit simpler,
  and probably shut lintian up on some of its warnings. An easy way to get the
  path is via `openssl version -m`

* Can it work with any pkcs11 implementation, or is it just opencryptoki? The
  naming suggests that it is implementation-agnostic.

* d/control: why Ubuntu MOTU as maintainers? Customarily we use Ubuntu
  Developers <email address hidden>

* error: d/control: Section: why specify 'universe'? I don't have an example of
  a Ubuntu-only universe package at hand, but all packages imported from Debian
  simply have "libs" as a section, and they all go to their designated section
  anyway. Leaving it unspecified allows for an MIR without having to change the
  packaging, which is always nice.

* d/copyright: the packaging copyright should be under the same license as
  upstream, to avoid issues when dealing with patches. That's in alignment with
  Canonical's policy.

* Lintian: the package isn't Lintian-clean, but then again I'm expecting most of these
  to go away if you address all the previous points:
W: openssl-pkcs11-sign-provider: package-name-doesnt-match-sonames pkcs11sign
W: openssl-pkcs11-sign-provider: shared-library-lacks-version usr/lib/x86_64-linux-gnu/pkcs11sign.so pkcs11sign.so
W: openssl-pkcs11-sign-provider: unknown-section universe/libs
W: openssl-pkcs11-sign-provider-dbgsym: unknown-section universe/debug
I: openssl-pkcs11-sign-provider: no-symbols-control-file usr/lib/x86_64-linux-gnu/pkcs11sign.so
I: openssl-pkcs11-sign-provider: typo-in-manual-page "allows to" "allows one to" [usr/share/man/man5/pkcs11sign.cnf.5.gz:123]

* d/control: This is pedantism in its purest form: there's usually a space
  between '=' and the version number in your dependency contraints.

* d/control: a neat tool to keep things organized in your control file is
  wrap-and-sort, it would help keeping your Build-Depends in check and make
  evolutions easier to review.

* d/watch: I'm far from an expert in uscan and watchfiles. However, there seems
  to be something wrong there, the filenamemangle talks about tar.xz whereas
  the GH api is apparently giving a tar.gz. In addition, upstream provides
  signature files (.asc), and uscan had the capability to automatically check
  them, could we enable that?