[MIR] libstring-license-perl

I dropped libfeature-compat-class-perl in https://launchpad.net/ubuntu/+source/libstring-license-perl/0.0.2-1ubuntu2

Hi Lukas,

In debian/control, shouldn't this line be removed too?
  libfeature-compat-class-perl <!nocheck>

Or do you intend to use -P nocheck for the time being?

Hey Adrien! Does that fail any usecase for you (build or test)? It shouldn't matter too much, as the libfeature-compat-class-perl library/module is not being used in the code. I tried to keep the delta at a minimum, that's why it's still in there as a build-depends.

NB: libstring-license-perl is very young because it is split off from
licensecheck; instead of referring to the history of this new package, I will
often refer to licensecheck's

[Availability]
- The package libstring-license-perl is already in Ubuntu universe.
- The package libstring-license-perl builds for the architectures it is designed to work on.
- It currently builds and works for architectures: "all"
- Link to package [[https://launchpad.net/ubuntu/+source/libstring-license-perl|libstring-license-perl]]

[Rationale]
- The package libstring-license-perl is split from licesecheck and now a dependency of it
- Quoting upstream:
  + Initial CPAN release (before that part of App::Licensecheck since 2016,
    Debian devscripts since 2007, and KDE SDK since 2000).

- The package libstring-license-perl is required in Ubuntu main in time for
  23.10 since it is now a requirement for licensecheck. The licensecheck
  version that depends on this package (i.e. >= 3.3.5) is already in Debian
  testing.

[Security]
- No relevant CVEs/security issues in this software in the past
  - since this is a new package, I looked into the history of devscripts and
    licensecheck and while they had security issues, these are not related to
    this new package

- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs

[Quality assurance - function/usage]
- The package works well right after install

[Quality assurance - maintenance]
- libstring-license-perl is too recent and looking at licensecheck's history
  is more relevant
- licensecheck itself has no pending critical bug
- there are several bug reports that ask for more/better detection but I think
  it is quite expected that licensecheck cannot handle all situations (this
  part of licensecheck is the one that is being put in libstring-license-perl)
- The package is maintained well in Debian/Ubuntu/Upstream and does
  not have too many, long-term & critical, open bugs
  - Ubuntu https://bugs.launchpad.net/ubuntu/+source/licensecheck/+bug
  - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=licensecheck
  - Upstream's bug tracker: I couldn't find one but the project is so
    targetted at Debian than it seems the Debian bug tracker is the
    corresponding location

[Quality assurance - testing]
- The package runs a test suite on build time, if it fails
  it makes the build fail.
- Build log at
  https://launchpadlibrarian.net/647702226/buildlog_ubuntu-lunar-amd64.libstring-license-perl_0.0.2-1ubuntu2_BUILDING.txt.gz
  (look for dh_auto_test)

- The package runs an autopkgtest, and is currently passing on
  all architectures (except i386 but it looks like an external issue and since
      it's perl, it is likely actually passing).
- Test logs at https://autopkgtest.ubuntu.com/packages/libstring-license-perl/lunar/amd64

- The package does have not failing autopkgtests right now

[Quality assurance - packaging]
- debian/watch is present and works

- debian/control defines a correct Maintainer field

- This package does not yield massive lintian Warnings, Errors
- Build log: https://launchpadlibrarian.net/647702226/buil...

Lukas, my issue was that I couldn't build the package due to the missing dependencies. Thinking again about this, it works indeed since the package is in universe and it's a build-depends. I think my main issue here is that I don't really understand why it's a Build-Depends and not a Depends but maybe it's some perl magic (in which case I think I don't want to know more :D ).

Interesting. It builds fine for me in a Lunar based sbuild chroot (and also inside the official infrastructure buildds). Being a B-D it's fine policy wise to be in universe, we just need the runtime depends to be in "main", too.

The libstring-license-perl binary package has a dependency defined on ${perl:Depends}, which make debhelper to automatically pick up runtime dependency (perl modules) that are used during build time. But as we're not making use of that module when building, it won't end up as a runtime dependency. The Ubuntu delta is also dropping the explicit runtime dependency on libfeature-compat-class-perl from debian/control.

Having it installed in the build-environment is a bit of (unnecessary) overhead, but doesn't hurt either. And it keeps the delta against Debian a bit smaller. I'd also be fine with dropping it from the B-Ds if that's what you want to do.

Review for Package: libstring-license-perl

[Summary]
MIR team ACK under the constraint to resolve the below listed recommended TODOs.
This does not need a security review

Notes:
Recommended TODOs:
- Need clarification on what is the latest upstream release. Running uscan fetched a new version (0.0.4) which is not in upstream git repo: https://salsa.debian.org/perl-team/modules/packages/libstring-license-perl/-/tags. Debian is also on 0.0.2. Do you mind checking?

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- libstring-license-perl checked with `check-mir`
- all dependencies can be found in `seeded-in-ubuntu` (already in main)
- none of the (potentially auto-generated) dependencies (Depends
  and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source. (Only from local package source code files)
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test
- no new python2 dependency

[Packaging red flags]
OK:
- Ubuntu does carry a delta, but it is reasonable and maintenance under
  control
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is good
- Debian/Ubuntu update history is good
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems:
- Need clarification on what is the latest upstream release. Running uscan fetched a new version (0.0.4) which is not in upstream git repo: https://salsa.debian.org/perl-team/modules/packages/libstring-license-perl/-/tags. Debian is also on 0.0.2. Do you mind checking?

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (usage is OK ...

Thanks for the review.

Below is the list of changes occuring after 0.0.2:

> v0.0.4 2023-01-18
>
> [ Test Suite ]
> - tighten to test-recommend Software::LicenseUtils 0.104002
>
> v0.0.3 2023-01-17
>
> [ Test Suite ]
> - update test Software-License.t: check license ISC since
> Software::License 0.104002
> - update test Software-License.t: list licenses without fallback as
> undefined (not empty string)
> - update test Software-License.t: resolve plan from hash %LICENSE
> - update test Software-License.t: uncruft license EUPL-1.1, apparently
> needed in some (test) scenarios

(copied from https://metacpan.org/release/JONASS/String-License-v0.0.4/source/Changes )

As you can see, the changes are all related to tests. Moreover the code is extracted from licensecheck which is an old and well-known package and the source code it will run on is not going to change noticeably for lunar. Lastly, the author is also the package maintainer in Debian and also the package maintainer of licensecheck in Debian, and didn't feel a need to update in Debian. I therefore didn't see a need to update to 0.0.4 this cycle.

Thanks for clarification. ~foundations-bugs is already subscribed to the package. I feel like this is ready for promotion.

Thanks for the feedback, this is ready and shows up in mismatches.
Updating state

Thanks for the quick update, approving them. Can you remind the unpstream maintainer to update the git repo? :)

Override component to main
libstring-license-perl 0.0.2-1ubuntu2 in lunar: universe/misc -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar amd64: universe/perl/optional/100% -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar arm64: universe/perl/optional/100% -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar armhf: universe/perl/optional/100% -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar i386: universe/perl/optional/100% -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar ppc64el: universe/perl/optional/100% -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar riscv64: universe/perl/optional/100% -> main
libstring-license-perl 0.0.2-1ubuntu2 in lunar s390x: universe/perl/optional/100% -> main
8 publications overridden.

I have to say I think I don't completely understand how upstream uses git in practice. IIRC I got the impression they only pushed when needing that for a debian release. And CPAN seems to be the main code hosting?! I'll see what I can do nonetheless.