[MIR] lib*-perl

Review for Package: libindirect-perl

[Summary]
MIR team ACK

This does not need a security review

List of specific binary packages to be promoted to main: libindirect-perl
Specific binary packages built, but NOT to be promoted to main: n/a

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

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main

Problems: None

[Security]
- 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 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)

Problems:
- does parse data formats (usually code in the current use, but not arbitrary
  and low attack surface)

[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 test suite that runs as autopkgtest
- no special HW needed
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Debian/Ubuntu update history is slow (matching upstream)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems:
- Upstream update history is slow, not sure how much we can rely on it.
  Those kind of packages often are without being a problem, but we have to
  be clear this seems like a non (much) active upstream.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (perl only)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case

Problems: None

Review for Package: libobject-pad-perl

[Summary]
MIR team ACK

This does not need a security review

List of specific binary packages to be promoted to main: libobject-pad-perl
Specific binary packages built, but NOT to be promoted to main: n/a

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

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main

Problems: None

[Security]
- 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 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)

Problems:
- does parse data formats (usually code in the current use, but not arbitrary
  and low attack surface)

[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 test suite that runs as autopkgtest
- no special HW needed
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Debian/Ubuntu update history is slow (matching upstream)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems:
- Upstream update history is slow, not sure how much we can rely on it.
  Those kind of packages often are without being a problem, but we have to
  be clear this seems like a non (much) active upstream.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (perl only)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case

Problems: None

Review for Package: libunicode-escape-perl

[Summary]
MIR team NACK
(outdated, unmaintained, alternatives in main)
Unless there is a very strong explanation why this can't be done with
the better alternatives this is a NACK.

This does not need a security review

List of specific binary packages to be promoted to main: libunicode-escape-perl
Specific binary packages built, but NOT to be promoted to main: n/a

Required TODOs:
- give it a reasonable evaluation please if the alternate modules already in
  main like libunicode-utf8-perl might be sufficient for what the new dependency
  needs from libunicode-escape-perl. Modern perl also supports unicode natively
  are we sure this isn't just a (very) old dependency here?
  Also 0.0.2 since 2011, given there are alternatives I'm really not convinced
  we should use this.
Recommended TODOs:
- The package should get a team bug subscriber before being promoted

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

There are many similar ones though, like libstring-escape-perl for general
string escaping. And libunicode-utf8-perl for encode/decode of unicode.
Both are already in main.

Also modern perl supports unicode directly, do we really need this?

CPAN even has more https://metacpan.org/pod/Encode::Escape::Unicode
there might be a proliferation going on, but all except the perl-integrated
one have not seen updates in years.

And if this would not be needed, then libunicode-string-perl also would not
be needed to bepromoted/supported.

I'll add a check for that as required TODO to ensure we are not just re-adding
the same function. Especially since most of these libs seem outdated or at least
rarely updated, it is better to carry fewer.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main

Problems: None

[Security]
- 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 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)

Problems:
- does parse data formats (usually docs in the current use, but not arbitrary
  and low attack surface)

[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 test suite that runs as autopkgtest
- no special HW needed
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and lo...

Review for Package: libunicode-string-perl

[Summary]
MIR team NACK
(indirectly, since libunicode-escape-perl got a NACK)
Once resolved there this can be re-considere. In that case it would be a usual
ack under constraint to resolve the required todos below.

This does not need a security review

List of specific binary packages to be promoted to main: libunicode-string-perl
Specific binary packages built, but NOT to be promoted to main: n/a

Notes:
Required TODOs:
- give it a reasonable evaluation please if the need for this from the
  depending package might nowadays be fulfillable with perls native unicode
  support that it has.
Recommended TODOs:
- The package should get a team bug subscriber before being promoted

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

But that is only true if one insists on the old style handling.
Newer perl supports unicode and the package states that itself:
"These modules predate native Unicode support inside Perl. Normally, the
integrated Perl Unicode support and modules such as Encode should be used
instead of these modules."

We should avoid picking this up by accident, unless the dependency triggering
this does strictly need one of the few special features here it should be
better to get rid of the dependency to this old module.

Please start those checks at libunicode-escape-perl which has a similar
problem and if that isn't needed then libunicode-string-perl is not needed
either.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main

Problems: None

[Security]
- 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 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)

Problems:
- does parse data formats (usually docs in the current use, but not arbitrary
  and low attack surface)

[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 test suite that runs as autopkgtest
- no special HW needed
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Debian/Ubuntu update history is slow (matching upstream)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is no...

Review for Package: libxs-parse-sublike-perl

[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does not need a security review

List of specific binary packages to be promoted to main: libxs-parse-sublike-perl
Specific binary packages built, but NOT to be promoted to main: n/a

Required TODOs:
- the autopkgtest is broken since forever on all but armhf, please fix this
Recommended TODOs:
- The package should get a team bug subscriber before being promoted

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

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main

Problems: None

[Security]
- 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 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)

Problems:
- does parse data formats (usually code in the current use, but not arbitrary
  and low attack surface)

[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 test suite that runs as autopkgtest
- no special HW needed
- no new python2 dependency

Problems:
- the current autopkgtest fails and does so since impish which is why it
  isn't flagged. But this might represent an underlying problem with not only
  the test but the program, we should fix this before considering it ready.

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Debian/Ubuntu update history is slow (matching upstream)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems:
- Upstream update history is slow, not sure how much we can rely on it.
  Those kind of packages often are without being a problem, but we have to
  be clear this seems like a non (much) active upstream.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (perl only)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no t...

Regarding the libunicode-escape-perl issue, it is used to decode some pages encoded via the \uXXXX pattern, as noted in this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008504

The only perl module supporting this particular escape pattern is https://metacpan.org/pod/Encode::Escape::Unicode which is almost as old, and hasn't been packaged yet.

libxs-parse-sublike-perl autopkgtests have been fixed, a team admin has been pinged for package subscriptions for it, libindirect-perl and libobject-pad-perl. Marking it as Fix Committed, I'll ping archive admins once the subscription is done.

Expanding on my earlier comment regarding the libunicode* packages:

They are included due to a single use of Unicode::Escape::unescape() in the dh_sphinx script, to be able to decode Sphinx-generated URLs, as the Python software uses the \uXXXX pattern to escape such characters, as this escape pattern is the standard in the Python language and in JSON. This change is the result of a relatively recent bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008504

That pattern is not very well supported in Perl, to the point that \u is an escape sequence to titlecase the following character. As such, I was only able to find 2 modules on CPAN that explicitly deal with those escape pattern:

* https://metacpan.org/pod/Encode::Escape::Unicode
* https://metacpan.org/pod/Unicode::Escape

In addition, we could probably use the builtin decoder in one of the various JSON modules (some of which are already in main), but that'd require modifying the input string to make it legal JSON, which I'm a bit reluctant to do.

I dived a bit deeper in the sphinx codebase, and it appears that using a full-fledged JSON parser is actually *cleaner* than what is done now, where dh_sphinxdoc is basically parsing a JSON array manually.

I wrote a patch and posted it on Salsa: https://salsa.debian.org/python-team/packages/sphinx/-/merge_requests/3

I'll wait for feedback from the Debian maintainer before contemplating having it as a delta on Ubuntu. Meanwhile, I tagged this MIR as rls-kk-incoming to discuss the possibility within the team of maintaining the libunicode-* packages.

The Debian patch has been accepted and is now on their debian/sid branch. I uploaded a 4.5.0-3maysync1 version with the patch to Kinetic to unblock the situation.

Thus, marking the libunicode* packages as Invalid, and removing the rls-kk-incoming bugs as the question of adopting those old packages is now moot.

Override component to main
libindirect-perl 0.39-1build3 in kinetic: universe/perl -> main
libindirect-perl 0.39-1build3 in kinetic amd64: universe/perl/optional/100% -> main
libindirect-perl 0.39-1build3 in kinetic arm64: universe/perl/optional/100% -> main
libindirect-perl 0.39-1build3 in kinetic armhf: universe/perl/optional/100% -> main
libindirect-perl 0.39-1build3 in kinetic ppc64el: universe/perl/optional/100% -> main
libindirect-perl 0.39-1build3 in kinetic riscv64: universe/perl/optional/100% -> main
libindirect-perl 0.39-1build3 in kinetic s390x: universe/perl/optional/100% -> main
libobject-pad-perl 0.65-1 in kinetic: universe/misc -> main
libobject-pad-perl 0.65-1 in kinetic amd64: universe/perl/optional/100% -> main
libobject-pad-perl 0.65-1 in kinetic arm64: universe/perl/optional/100% -> main
libobject-pad-perl 0.65-1 in kinetic armhf: universe/perl/optional/100% -> main
libobject-pad-perl 0.65-1 in kinetic ppc64el: universe/perl/optional/100% -> main
libobject-pad-perl 0.65-1 in kinetic riscv64: universe/perl/optional/100% -> main
libobject-pad-perl 0.65-1 in kinetic s390x: universe/perl/optional/100% -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic: universe/misc -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic amd64: universe/perl/optional/100% -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic arm64: universe/perl/optional/100% -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic armhf: universe/perl/optional/100% -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic ppc64el: universe/perl/optional/100% -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic riscv64: universe/perl/optional/100% -> main
libxs-parse-sublike-perl 0.16-1ubuntu2 in kinetic s390x: universe/perl/optional/100% -> main
21 publications overridden.