** Description changed:
Availability: The package must already be in the Ubuntu universe, and must
build for the architectures it is designed to work on.
- package is in universe: https://launchpad.net/ubuntu/+source/ipmctl
- package is amd64-only:
https://git.launchpad.net/~usd-import-team/ubuntu/+source/ipmctl/tree/debian/control#n18
+ The current version (02.00.00.xxxx) we have in the archive is still
+ labeled as development, but a stable one is expected to be released in
+ March 2020.
Rationale: There must be a certain level of demand for the package, for
example:
ipmctl is a utility for configuring and managing Intel Optane DC persistent
memory modules (DCPMM).
As these devices become more popular, demand for this package will increase.
It's the tool used to configure Intel NVDIMMs at hardware level -- such as
switching between memory mode and AppDirect, configuring interleaving,
etc
Security: The security history and the current state of security issues
in the package must allow us to support the package for at least 9
months (60 for LTS support) without exposing its users to an
inappropriate level of security risks. This requires checking of several
things that are explained in detail in the subsection Security checks.
- This is a new project, so unlikely to have security issues reported yet.
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipmctl shows no results
- no results for the OSS security mailing list
Ubuntu CVE Tracker
http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- no results
- http://people.ubuntu.com/~ubuntu-security/cve/partner.html
+ http://people.ubuntu.com/~ubuntu-security/cve/partner.html
- no results
https://github.com/intel/ipmctl/security/advisories
- empty at the moment
Check for security relevant binaries. If any are present, this requires a
more in-depth security review.
- there is just one binary, /usr/bin/ipmctl, and its shared library
Executables which have the suid or sgid bit set.
- no
Executables in /sbin, /usr/sbin.
- just /usr/bin/ipmctl
which install services / daemons (/etc/init.d/*, /etc/init/*,
/lib/systemd/system/*)
- no
Packages which open privileged ports (ports < 1024).
- no
- Add-ons and plugins to security-sensitive software (filters, scanners, UI
skins, etc)
+ Add-ons and plugins to security-sensitive software (filters, scanners, UI
skins, etc)
- no
-
Quality assurance:
After installing the package it must be possible to make it working with a
reasonable effort of configuration and documentation reading.
- hard to gauge, all we can do without the hardware is to make sure commands
don't crash or fail. The expected result is to show something like "no such
hardware", and that happens:
$ ipmctl show -preferences
CLI_DEFAULT_DIMM_ID=HANDLE
CLI_DEFAULT_SIZE=GiB
APPDIRECT_SETTINGS=RECOMMENDED
DBG_LOG_LEVEL=0
and
$ ipmctl show -dimm
No DIMMs in the system.
On qemu with emulated nvdimms, however, we do get some result, but all the
details are missing:
$ sudo ipmctl show -dimm
- DimmID | Capacity | LockState | HealthState | FWVersion
+ DimmID | Capacity | LockState | HealthState | FWVersion
============================================================
- Unknown | 0.000 GiB | Unknown | Unmanageable | N/A
-
+ Unknown | 0.000 GiB | Unknown | Unmanageable | N/A
The package must not ask debconf questions higher than medium if it is going
to be installed by default. The debconf questions must have reasonable defaults.
- no debconf questions
There are no long-term outstanding bugs which affect the usability of the
program to a major degree. To support a package, we must be reasonably
convinced that upstream supports and cares for the package.
- this package is recent, so maybe not enough time or users. There is one LP
bug about a regression in the upgrade from v1 of this package:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1860537
The corresponding upstream bug is still open but was responded to quickly:
https://github.com/intel/ipmctl/issues/123
In general, but reports seem to be well handled by upstream.
The status of important bugs in Debian's, Ubuntu's, and upstream's bug
tracking systems must be evaluated. Important bugs must be pointed out and
discussed in the MIR report.
- just one bug filed in ubuntu, as shown above. No bugs in debian.
The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
- tracker shows just one build warning, about missing buildflags
(https://qa.debian.org/bls/packages/i/ipmctl.html). Might resolve the lintian
warning shown above too.
The package should not deal with exotic hardware which we cannot support.
- nvdimms might be "exotic" now, but maight not remain so for the duration of
the LTS
If the package ships a test suite, and there is no obvious reason why it
cannot work during build (e. g. it needs root privileges or network access), it
should be run during package build, and a failing test suite should fail the
build.
- no test suite, dep8 or otherwse
The package uses a debian/watch file whenever possible. In cases where this
is not possible (e. g. native packages), the package should either provide a
debian/README.source file or a debian/watch file (with comments only) providing
clear instructions on how to generate the source tar file.
- there is a working d/watch file
It is often useful to run lintian --pedantic on the package to spot the most
common packaging issues in advance
- lintian output provided earlier above
- The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
+ The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
- package has build-depends on asciidoctor
(https://tracker.debian.org/pkg/asciidoctor), which has an open CVE:
https://security-tracker.debian.org/tracker/CVE-2018-18385
- nothing else raised flags
UI standards: (generally only for user-facing applications)
N/A
-
Dependencies:
- All binary dependencies (including Recommends:) must be satisfiable in main
(i. e. the preferred alternative must be in main). If not, these dependencies
need a separate MIR report (this can be a separate bug or another task on the
main MIR bug)
- $ check-mir
+ All binary dependencies (including Recommends:) must be satisfiable in main
(i. e. the preferred alternative must be in main). If not, these dependencies
need a separate MIR report (this can be a separate bug or another task on the
main MIR bug)
+ $ check-mir
Checking support status of build dependencies...
- * debhelper-compat does not exist (pure virtual?)
- * libndctl-dev binary and source package is in universe
- * asciidoctor binary and source package is in universe
+ * debhelper-compat does not exist (pure virtual?)
+ * libndctl-dev binary and source package is in universe
+ * asciidoctor binary and source package is in universe
Checking support status of binary dependencies...
- * libipmctl4 binary and source package is in universe
+ * libipmctl4 binary and source package is in universe
Of these:
- libndctl-dev (src:ndctl) is part of a MIR already that was approved
(https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506)
- asciidoctor is only used to build documentation and does not become a
runtime dependency
- libipmctl4 is part of src:ipmctl, subject of this MIR
-
Standards compliance: The package should meet the FHS and Debian Policy
standards. Major violations should be documented and justified. Also, the
source packaging should be reasonably easy to understand and maintain.
- lintian -I --pedantic:
I: ipmctl source: debian-rules-parses-dpkg-parsechangelog (line 12)
I: libipmctl4: hardening-no-fortify-functions
usr/lib/x86_64-linux-gnu/libipmctl.so.4.0.0
I: ipmctl: manpage-without-executable (many: could be overriden, as they are
manpages for ipmctl subcommands)
I: libipmctl4: spelling-error-in-binary
I: ipmctl: spelling-error-in-manpage (a few)
I: ipmctl source: testsuite-autopkgtest-missing
I: ipmctl source: unused-file-paragraph-in-dep5-copyright paragraph at line 75
I: ipmctl source: wildcard-matches-nothing-in-dep5-copyright
BaseTools/Source/C/BrotliCompress (paragraph at line 75)
I: ipmctl source: wildcard-matches-nothing-in-dep5-copyright
MdeModulePkg/Library/BrotliCustomDecompressLib (paragraph at line 75)
P: ipmctl source: file-contains-trailing-whitespace debian/rules (line 8)
DEP8 tests should be added. Due to hardware requirements, these would
probably be simple smoke tests.
In terms of FHS, I'll just note that the library file contains a config file
in /usr/share, and logrotate configuration:
/etc/logrotate.d/ipmctl
/usr/share/doc/ipmctl/ipmctl_default.conf
/usr/share/ipmctl/ipmctl.conf
/var/log/ipmctl
It's probably expected that the user creates his/her own config, based
on the sample one. The config file in /usr/share is identical to the one
in the documentation directory.
-
Maintenance: The package must have an acceptable level of maintenance
corresponding to its complexity:
All packages must have a designated "owning" team, regardless of complexity,
which is set as a package bug contact.
- server team will own this
The biggest maintenance burden here would be having to rely on specific
hardware for testing, hardware which we might not have at the moment. This puts
Ubuntu in a position where we have to rely strongly on upstream for bug
reporting and fixes.
-
Background information:
The package descriptions should explain the general purpose and context of
the package. Additional explanations/justifications should be done in the MIR
report.
- the package description is good.
** Changed in: ipmctl (Ubuntu)
Status: Confirmed => New
** Description changed:
+ Summary:
+ - this tool requires specific hardware availability
+ - current version in the archive is still labeled as experimental by
upstream, with a stable release expected for March 2020
+
Availability: The package must already be in the Ubuntu universe, and must
build for the architectures it is designed to work on.
- package is in universe: https://launchpad.net/ubuntu/+source/ipmctl
- package is amd64-only:
https://git.launchpad.net/~usd-import-team/ubuntu/+source/ipmctl/tree/debian/control#n18
The current version (02.00.00.xxxx) we have in the archive is still
labeled as development, but a stable one is expected to be released in
March 2020.
Rationale: There must be a certain level of demand for the package, for
example:
ipmctl is a utility for configuring and managing Intel Optane DC persistent
memory modules (DCPMM).
As these devices become more popular, demand for this package will increase.
It's the tool used to configure Intel NVDIMMs at hardware level -- such as
switching between memory mode and AppDirect, configuring interleaving,
etc
Security: The security history and the current state of security issues
in the package must allow us to support the package for at least 9
months (60 for LTS support) without exposing its users to an
inappropriate level of security risks. This requires checking of several
things that are explained in detail in the subsection Security checks.
- This is a new project, so unlikely to have security issues reported yet.
- https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipmctl shows no results
- no results for the OSS security mailing list
Ubuntu CVE Tracker
http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- no results
http://people.ubuntu.com/~ubuntu-security/cve/partner.html
- no results
https://github.com/intel/ipmctl/security/advisories
- empty at the moment
Check for security relevant binaries. If any are present, this requires a
more in-depth security review.
- there is just one binary, /usr/bin/ipmctl, and its shared library
Executables which have the suid or sgid bit set.
- no
Executables in /sbin, /usr/sbin.
- just /usr/bin/ipmctl
which install services / daemons (/etc/init.d/*, /etc/init/*,
/lib/systemd/system/*)
- no
Packages which open privileged ports (ports < 1024).
- no
Add-ons and plugins to security-sensitive software (filters, scanners, UI
skins, etc)
- no
Quality assurance:
After installing the package it must be possible to make it working with a
reasonable effort of configuration and documentation reading.
- hard to gauge, all we can do without the hardware is to make sure commands
don't crash or fail. The expected result is to show something like "no such
hardware", and that happens:
$ ipmctl show -preferences
CLI_DEFAULT_DIMM_ID=HANDLE
CLI_DEFAULT_SIZE=GiB
APPDIRECT_SETTINGS=RECOMMENDED
DBG_LOG_LEVEL=0
and
$ ipmctl show -dimm
No DIMMs in the system.
On qemu with emulated nvdimms, however, we do get some result, but all the
details are missing:
$ sudo ipmctl show -dimm
DimmID | Capacity | LockState | HealthState | FWVersion
============================================================
Unknown | 0.000 GiB | Unknown | Unmanageable | N/A
The package must not ask debconf questions higher than medium if it is going
to be installed by default. The debconf questions must have reasonable defaults.
- no debconf questions
There are no long-term outstanding bugs which affect the usability of the
program to a major degree. To support a package, we must be reasonably
convinced that upstream supports and cares for the package.
- this package is recent, so maybe not enough time or users. There is one LP
bug about a regression in the upgrade from v1 of this package:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1860537
The corresponding upstream bug is still open but was responded to quickly:
https://github.com/intel/ipmctl/issues/123
In general, but reports seem to be well handled by upstream.
The status of important bugs in Debian's, Ubuntu's, and upstream's bug
tracking systems must be evaluated. Important bugs must be pointed out and
discussed in the MIR report.
- just one bug filed in ubuntu, as shown above. No bugs in debian.
The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
- tracker shows just one build warning, about missing buildflags
(https://qa.debian.org/bls/packages/i/ipmctl.html). Might resolve the lintian
warning shown above too.
The package should not deal with exotic hardware which we cannot support.
- nvdimms might be "exotic" now, but maight not remain so for the duration of
the LTS
If the package ships a test suite, and there is no obvious reason why it
cannot work during build (e. g. it needs root privileges or network access), it
should be run during package build, and a failing test suite should fail the
build.
- no test suite, dep8 or otherwse
The package uses a debian/watch file whenever possible. In cases where this
is not possible (e. g. native packages), the package should either provide a
debian/README.source file or a debian/watch file (with comments only) providing
clear instructions on how to generate the source tar file.
- there is a working d/watch file
It is often useful to run lintian --pedantic on the package to spot the most
common packaging issues in advance
- lintian output provided earlier above
The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
- package has build-depends on asciidoctor
(https://tracker.debian.org/pkg/asciidoctor), which has an open CVE:
https://security-tracker.debian.org/tracker/CVE-2018-18385
- nothing else raised flags
UI standards: (generally only for user-facing applications)
N/A
Dependencies:
All binary dependencies (including Recommends:) must be satisfiable in main
(i. e. the preferred alternative must be in main). If not, these dependencies
need a separate MIR report (this can be a separate bug or another task on the
main MIR bug)
$ check-mir
Checking support status of build dependencies...
* debhelper-compat does not exist (pure virtual?)
* libndctl-dev binary and source package is in universe
* asciidoctor binary and source package is in universe
Checking support status of binary dependencies...
* libipmctl4 binary and source package is in universe
Of these:
- libndctl-dev (src:ndctl) is part of a MIR already that was approved
(https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506)
- asciidoctor is only used to build documentation and does not become a
runtime dependency
- libipmctl4 is part of src:ipmctl, subject of this MIR
Standards compliance: The package should meet the FHS and Debian Policy
standards. Major violations should be documented and justified. Also, the
source packaging should be reasonably easy to understand and maintain.
- lintian -I --pedantic:
I: ipmctl source: debian-rules-parses-dpkg-parsechangelog (line 12)
I: libipmctl4: hardening-no-fortify-functions
usr/lib/x86_64-linux-gnu/libipmctl.so.4.0.0
I: ipmctl: manpage-without-executable (many: could be overriden, as they are
manpages for ipmctl subcommands)
I: libipmctl4: spelling-error-in-binary
I: ipmctl: spelling-error-in-manpage (a few)
I: ipmctl source: testsuite-autopkgtest-missing
I: ipmctl source: unused-file-paragraph-in-dep5-copyright paragraph at line 75
I: ipmctl source: wildcard-matches-nothing-in-dep5-copyright
BaseTools/Source/C/BrotliCompress (paragraph at line 75)
I: ipmctl source: wildcard-matches-nothing-in-dep5-copyright
MdeModulePkg/Library/BrotliCustomDecompressLib (paragraph at line 75)
P: ipmctl source: file-contains-trailing-whitespace debian/rules (line 8)
DEP8 tests should be added. Due to hardware requirements, these would
probably be simple smoke tests.
In terms of FHS, I'll just note that the library file contains a config file
in /usr/share, and logrotate configuration:
/etc/logrotate.d/ipmctl
/usr/share/doc/ipmctl/ipmctl_default.conf
/usr/share/ipmctl/ipmctl.conf
/var/log/ipmctl
It's probably expected that the user creates his/her own config, based
on the sample one. The config file in /usr/share is identical to the one
in the documentation directory.
Maintenance: The package must have an acceptable level of maintenance
corresponding to its complexity:
All packages must have a designated "owning" team, regardless of complexity,
which is set as a package bug contact.
- server team will own this
The biggest maintenance burden here would be having to rely on specific
hardware for testing, hardware which we might not have at the moment. This puts
Ubuntu in a position where we have to rely strongly on upstream for bug
reporting and fixes.
Background information:
The package descriptions should explain the general purpose and context of
the package. Additional explanations/justifications should be done in the MIR
report.
- the package description is good.
--
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1854181
Title:
[MIR] ipmctl
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1854181/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
