[MIR] django-haystack as dependency of mailman3
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| django-haystack (Ubuntu) |
In Progress
|
Undecided
|
Unassigned | ||
Bug Description
[Availability]
The package is already in universe.
Package builds for python2 and python3, but we only need python3
[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 package is not formerly part of mailman2.
[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.
Launchpad bugs (0): https:/
Debian bugs (0): https:/
Upstream issues: https:/
I haven't found any important bugs.
Package seems well mainained at https:/
Package does not depend on exotic hardware.
Package does not ship a test suite.
Package includes a debian/watch file
Lintian --pedantic is clean
Package does not rely on obsolete or about to be demoted packages.
[UI standards]
Not an end user application
[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]
Package follows standard python install practices.
[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]
Good package description.
| Christian Ehrhardt (paelzer) wrote | #1 |
| Changed in django-haystack (Ubuntu): | |
| status: | New → In Progress |
| Christian Ehrhardt (paelzer) wrote | #2 |
[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.
There are some examples and docs but none of them qualifes as embedded source.
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
- open a port
- uses centralized online accounts
- integrates arbitrary javascript into the desktop
- deals with system authentication
- processes arbitrary web content
- parse data formats
Django after all is a web framework, but this component seems to be on the other end and not exposed.
Therefore IMHO there is no security review needed for this.
[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 acceptable:
- the self tests are no run at the moment.
The reason is that they required a live solr server.
Therefore they would have to be a autopkgtest which isn't implemented
yet (but mentioned in d/rules)
[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
[Upstream red flags]
- no suspicious errors during build (a few warnings, but nothing concerning)
- it is pure python, so no incautious use of malloc/sprintf
- no use of sudo, gksu (only mentioned in docs which is fine)
- 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 for this component a security review seems not required.