[MIR] electric-fence
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
electric-fence (Ubuntu) |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
Electrice fence has no open bugs in Ubuntu and is subject to only very slow change, so it should not add maintenance work in Main.
Availability: Available in Universe and built on all archs.
Rationale:
The rationale for this MIR is as a build-dependency for clamav. It is a build-dep in Debian, but we drop it in Ubuntu. If we promoted electric-fence in Ubuntu we could run more tests and it would make it so the package could be sync'ed. Up to now, because of apparmor support, clamav had to be merged, but that's being incorporated into Debian, so if we could promote electric-fence it would reduce the overall maintenance workload in Ubuntu.
Security:
Security history is good
Quality assurance:
For use with clamav, usage is automatic. The package does document it's use well for it's target audience (developers).
It has no debconf questions
No Ubuntu bugs. Two minor Debian bugs (newest is from 2005). No expectation that maintenance work would be needed to support this package.
https:/
https:/
There is no "upstream" bug tracker as this is a Debian native package.
There is no UI.
Dependencies:
All build-dep and depends in Main.
Standards compliance: No FHS issues. It's slightly unusual because it's a test library, not a normal shared lib, but it works as it is.
Maintenance: No maintenance expected.
Background information: Information in the package is clear
Security checks
Check how many vulnerabilities the package had in the past and how they were handled by upstream and the Debian/Ubuntu package:
http://
http://
http://
Check for security relevant binaries. If any are present, this requires a more in-depth security review.
No security relevant binaries.
- The source package comes with some odd build artifacts still in it. Like debian/ *.debhelper. log, debian/substvars, and a broken libefence.so symlink in the toplevel. Not actual problems. But seems sloppy.
- There is a compile warning that seems problematic, in that it indicates the XSI version of strerror_r is being used, but the code is expecting the GNU one (see the man page for strerror_r):
page.c: In function 'stringErrorRep ort': r(errno, (char *)err_message,128);
page.c:46:2: warning: return makes pointer from integer without a cast [enabled by default]
return strerror_
^
- Also needs a team bug subscriber for whichever team will look after this in Ubuntu.
- I like the tests being run on build! Besides the above comments, looks good.