[MIR] lazr.delegates as dependency of mailman3

[Christian Ehrhardt ]

[Availability]
The package is already universe for quite a while and build/works fine so far.
It is for example already used for https://lists.canonical.com/mailman3/postorius/lists/
OTOH it is a utility that can/could be used for much more than just the mailman3 stack.

This source builds python2 and python3 binaries (being compatible) but we will only pull in the python3 package as part of the switch to mailman3.

[Rationale]
This is part of the MIR activity for all dependencies of mailman3
The "main" MIR of it is at bug 1775427:

Mailman (2) has only python2 support, but we strive for python3,
therefore Mailman3 which has python3 support should be promoted to main.

This is to do deletgate object tasks, I haven't even found that in mailman2.
So I'd assume this is (mostly) new code.

[Security]

No known CVEs found.

[Quality assurance]

As part of the mailman3 stacks as of now (Disco) this installs fine and works fine.
On itself it is useful to (many) other dependencies and does not need a post install configuration on its own.

The package does not ask debconf questions.

Zero known bugs in Debian for this component.
One (very old) bug in Ubuntu, but currently in non reproducible state.

There are rarely upstream updates (just stable as-is?) but Debian is packaging fixes every now and then.

No exotic HW involved.

The package utilizes build time self tests as well as some (rather trivial) smoke test as autopkgtest.

d/watch is set up and ok.

No Lintian warning except newer Standards/Compat versions and non HTTPS links in copyright.
Furthermore it uses sphinx and has old style VCS links - but overall nothing to be concerned of.

The package does not rely on demoted or obsolete packages.

Note: IMHO by accident this has a dependency to nose (not nose2) from the binaries.
Since nose is only used for tests and would drag in more packages lets break that dependency.
I added a marker for extra work to the package.

[UI standards]

This is a low level library without (a lot) of user visible strings - no translations (needed).
No End-user applications that needs a standard conformant desktop file.

[Dependencies]

Some dependencies are not in main, but we drive MIR for all related packages
that are not in main at the same time.
Please check the list of bugs from the main Mailman3 MIR in bug 1775427 in bug 1775427 to get an overview.

[Standards compliance]
The package meets the FHS and Debian Policy standards.
The packaging itself is very straight forward and uses dh_* as much as possible - the d/rules fits on one screen.

[Maintenance]

The Server team will subscribe for the package for maintenance, but in
general it seems low on updates and currently is a sync from Debian.

[Background]
The package description explains the general purpose and context of the package well.

[Christian Ehrhardt  (paelzer)]

[Duplication]
No duplication for this functionality in main at the moment.

[Embedded sources and static linking]
This package does not contain embedded library sources.
This package doe not statically link to libraries.
No Go package

[Security]
I can confirm that there seems to be no CVE/Security history for this package.
It Does not:
- run a daemon as root
- uses old webkit
- uses lib*v8 directly
- opens a port
- uses centralized online accounts
- integrates arbitrary javascript into the desktop
- deals with system authentication
- processes arbitrary web content
- parse data formats
=> Therefore IMHO there is no security review needed for this.

[Common blockers]
- builds fine at the moment
- utilizes build time self tests
- utilizes (rather trivial) smoke test as autopkgtest.
- server Team committed to subscribe once this gets promoted (enough for now)
- code is not user visible, no translation needed
- dh_python is used
- package produces python2 bits, but they are not pulled into main by mailman3

[Packaging red flags]
- no current ubuntu Delta to evaluate
- no library with classic symbol tracking
- watch file is present
- Lintian warnings are present bug ok
- debian/rules is rather clean
- no usage of Built-Using
- no golang package that would make things harder

The last build was really long ago (in wily) which is concerning about
the rebuildability. But in a disco build today it worked, so it is fine.

Not perfect but ok:
- past updates to the package were sporadic (mostly as-is since intial packaging
- due to that the most current release is not packaged (only a minor upgrade)
- The server team already took a task to check viability to update to the newest version on pypi

[Upstream red flags]
- it is pure python, so no incautious use of malloc/sprintf
- no use of sudo, gksu
- no use of pkexec
- no use of LD_LIBRARY_PATH
- no important open bugs
- no Dependency on webkit, qtwebkit, libgoa-*
- no embedded copies in upstream either

There is one suspicious error on build (a syntax error):
 959 byte-compiling /<<PKGBUILDDIR>>/debian/python-lazr.delegates/usr/lib/python2.7/dist-packages/lazr/delegates/_python3.py to _python3.pyc
 960 File "/usr/lib/python2.7/dist-packages/lazr/delegates/_python3.py", line 27
 961 def delegate_to(*interfaces, context='context'):
 962 ^
 963 SyntaxError: invalid syntax

That is not critical (a bit unelegant thou).
It is a py2/py3 split that is done int __init__.py and only in the py3 case this file is included.
In py2 where this is a syntax error it does not matter as there it is never used.
For the py2 this file shouldn't be (tried to) pycompile at all, so room for improvement but nothing fatal.

[Summary]
MIR Team Ack as the package seems small, easy and sane to me.
As outlined above it will not need a security review.

Note: As the Server team has updating this on their task list already, taking a look at the syntax error mentioned above as well would be nice.

[Christian Ehrhardt  (paelzer)]

After evaluating dependencies, required further changes and mostly maintainability for security and packaging it was decided there are too many concerns - not about any single package in particular, but the overall Mailman3 stack - about the ability to maintain and monitor it as well as we need it for support in main.

We have closed the primary LP bug already, the MIRs that are already approved - like this one - will stay that way, but we will make no seed change to pull things in for now. Yet if other needs come up for those they have a prepared MIR already.
Other bugs which are not yet completed in terms of review will be closed as Won't Fix.

Even thou it ended being aborted, I think that is a valid outcome of the MIR evaluations. Never the less I want to thank everybody involved for all the work spent in what was nearly a year working through these MIRs.