[MIR] itypes as dependency of mailman3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
itypes (Ubuntu) |
In Progress
|
Undecided
|
Unassigned |
Bug Description
[Availability]
Package is in Universe (https:/
noarch (_all.deb).
It produces py2 and py3 binary packages, but we only want the py3 one:
python3-itypes.
[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.
[Security]
No CVEs: http://
No hits in the Ubuntu CVE tracker at
http://
[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.
- no debconf questions
- upstream has CI: https:/
- upstream has 2 open issues (not critical), and 3 closed ones:
https:/
- upstream is a tiny package, basically one python file with just about 220
lines of code
- no open or closed bugs in Ubuntu:
https:/
- no bugs in debian (on the source package, or either of the binaries)
- Debian tracker: https:/
- lintian shows just two warnings: changelog-
source-
- no exotic hardware involved
- there is no test suite, nor DEP8 tests.
- package ships a working debian/watch file
- a local lintian run only reports this:
$ lintian -I --pedantic
P: itypes source: file-contains-
I: itypes source: out-of-
- package has build-deps on python2, but just because it produces both py2 and
py3 packages.
[UI standards]
Does not apply since this is a pure python module that provides specific data
types only.
[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 to get an overview.
[Standards compliance]
There are no FHS violations.
Regarding the 4.1.3 policy, I checked
https:/
and I don't see major violations.
The package's d/rules file is an example of simplicity.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
Nothing at the moment.
[Duplication]
No duplication of that functionality in the Archive in general or main in particular.
[Embedded sources and static linking]
This package does not contain embedded library sources.
This package does 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
- open a port
- integrates arbitrary javascript into the desktop
- deals with system authentication
- uses centralized online accounts
- processes arbitrary web content
- parse data formats
[Common blockers]
- builds fine at the moment
- 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
Not perfect but ok
- does not run build time tests (but there are no tests by upstream to run)
[Packaging red flags]
- no current ubuntu Delta to evaluate
- no library with classic symbol tracking
- watch file is present
- Lintian warnings are present but ok
- debian/rules is rather clean
- no usage of Built-Using
- no golang package that would make things harder
[Upstream red flags]
- no suspicious errors during build
- 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
[Summary]
Ack from the MIR-Teams POV, as outlined above a security review is IMHO not required.