| 2019-11-21 19:29:32 |
Rafael David Tinoco |
bug |
|
|
added bug |
| 2019-11-21 19:29:45 |
Rafael David Tinoco |
bug |
|
|
added subscriber Ubuntu Server |
| 2019-11-21 19:29:50 |
Rafael David Tinoco |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2019-11-21 19:30:06 |
Rafael David Tinoco |
ndctl (Ubuntu): milestone |
|
ubuntu-20.04 |
|
| 2019-11-21 19:31:06 |
Rafael David Tinoco |
description |
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency: pmdk (LP: #1790856)
[Rationale]
[Security]
[Quality assurance]
[UI standards]
[Dependencies]
[Standards compliance]
[Maintenance]
[Background information] |
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency: pmdk (LP: #1790856)
TODO: The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on.
TODO: mention which binaries we actually want (if the package builds more than one). Check the dependency-tree.txt file which binary we actually need vs the debian/control file in the source
[Rationale]
This is part of the MIR activity for all dependencies of mailman3
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/mailman3/+bug/1775427
Mailman (2) has only python2 support, but we strive for python3,
therefore Mailman3 which has python3 support should be promoted to main.
TODO: check if this code (or older versions of it) was part of mailman2 already - if it was leave here: This code was formerly part of mailman2 which is in main, but was split into an extra package and evolved from ther eon its own)
[Security]
TODO: check the security History of the package
- http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- http://cve.mitre.org/cve/cve.html
[Quality assurance]
The mailman3 stacks as of now (Disco) installs fine and provides a base
config. But due to the nature of the package that needs further modification
to be of real use.
TODO: 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.
TODO: 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.
TODO: 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.
TODO: The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
TODO: The package should not deal with exotic hardware which we cannot support.
TODO: 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.
TODO: 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.
TODO: It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
TODO: 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.
[UI standards]
TODO: End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
TODO: End-user applications must ship 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 to get an overview.
[Standards compliance]
TODO: The package should meet the FHS and Debian Policy standards.
TODO: Major violations should be documented and justified.
TODO: Also, the source packaging should be reasonably easy to understand and maintain.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
TODO: The package descriptions should explain the general purpose and context of the package. Additional explanations/justifications should be done in the MIR report. |
|
| 2019-11-22 22:21:03 |
Rafael David Tinoco |
description |
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency: pmdk (LP: #1790856)
TODO: The package must already be in the Ubuntu universe, and must build for the architectures it is designed to work on.
TODO: mention which binaries we actually want (if the package builds more than one). Check the dependency-tree.txt file which binary we actually need vs the debian/control file in the source
[Rationale]
This is part of the MIR activity for all dependencies of mailman3
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/mailman3/+bug/1775427
Mailman (2) has only python2 support, but we strive for python3,
therefore Mailman3 which has python3 support should be promoted to main.
TODO: check if this code (or older versions of it) was part of mailman2 already - if it was leave here: This code was formerly part of mailman2 which is in main, but was split into an extra package and evolved from ther eon its own)
[Security]
TODO: check the security History of the package
- http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- http://cve.mitre.org/cve/cve.html
[Quality assurance]
The mailman3 stacks as of now (Disco) installs fine and provides a base
config. But due to the nature of the package that needs further modification
to be of real use.
TODO: 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.
TODO: 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.
TODO: 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.
TODO: The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
TODO: The package should not deal with exotic hardware which we cannot support.
TODO: 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.
TODO: 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.
TODO: It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
TODO: 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.
[UI standards]
TODO: End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
TODO: End-user applications must ship 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 to get an overview.
[Standards compliance]
TODO: The package should meet the FHS and Debian Policy standards.
TODO: Major violations should be documented and justified.
TODO: Also, the source packaging should be reasonably easy to understand and maintain.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
TODO: The package descriptions should explain the general purpose and context of the package. Additional explanations/justifications should be done in the MIR report. |
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency:
pmdk (LP: #1790856)
* Package exists since bionic (-updates) in universe:
61.2-0ubuntu1~18.04.1 | bionic-updates/universe
63-1.3 | disco/universe
65-1 | eoan/universe
67-1 | focal/universe
* Packages:
ndctl libndctl6 libndctl-dev
daxctl libdaxctl1 libdaxctl-dev
ndctl: dctl is utility for managing the "libnvdimm" kernel
subsystem. The "libnvdimm" subsystem defines a kernel device
model and control message interface for platform NVDIMM resources
like those defined by the ACPI 6.0 NFIT (NVDIMM Firmware
Interface Table).
Operations supported by the tool include, provisioning capacity
(namespaces), as well as enumerating/enabling/disabling the
devices (dimms, regions, namespaces) associated with an NVDIMM
bus.
daxctl: The daxctl utility provides enumeration and provisioning
commands for the Linux kernel Device-DAX facility. This facility
enables DAX mappings of performance / feature differentiated
memory without need of a filesystem.
* Architectures:
source, amd64, arm64, armhf, i386, ppc64el, s390x
PMEM: A system-physical-address range where writes are persistent. A
block device composed of PMEM is capable of DAX. A PMEM address
range may span an interleave of several DIMMs.
BLK: A set of one or more programmable memory mapped apertures
provided by a DIMM to access its media. This indirection precludes
the performance benefit of interleaving, but enables DIMM-bounded
failure modes.
DAX: File system extensions to bypass the page cache and block layer
to mmap persistent memory, from a PMEM block device, directly into a
process address space.
Binary Packages:
ndctl
libndctl6
libndctl-dev
daxctl
libdaxctl1
libdaxctl-dev
[Rationale]
This is part of the MIR activity for all dependencies of pmdk.
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/1790856
Package was introduced in bionic after bionic was released (19.04.1)
in universe and it is still in universe until now.
[Security]
TODO: check the security History of the package
- http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- http://cve.mitre.org/cve/cve.html
[Quality assurance]
* Documentation:
- https://docs.pmem.io/ndctl-users-guide
- https://nvdimm.wiki.kernel.org/
Both packages (ndctl and daxctl) and its libraries (libndctl6,
libndctl-dev, libdaxctl1, libdaxctl-dev) install fine and are
operational (check comment #1).
TODO: 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.
TODO: 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.
TODO: 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.
TODO: The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
TODO: The package should not deal with exotic hardware which we cannot support.
TODO: 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.
TODO: 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.
TODO: It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
TODO: 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.
[UI standards]
TODO: End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
TODO: End-user applications must ship 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 to get an overview.
[Standards compliance]
TODO: The package should meet the FHS and Debian Policy standards.
TODO: Major violations should be documented and justified.
TODO: Also, the source packaging should be reasonably easy to understand and maintain.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
The Persistent Memory Development Kit (PMDK) is a collection of
libraries and tools for System Administrators and Application
Developers to simplify managing and accessing persistent memory
devices. The libraries build on the Direct Access (DAX) feature which
allows applications to directly access persistent memory as
memory-mapped files. This is described in detail in the Storage
Network Industry Association (SNIA) NVM Programming Model.
PMDK depends on libndctl.
The Non-Volatile Device Control (ndctl) is a utility for managing the
LIBNVDIMM Linux Kernel subsystem. The LIBNVDIMM subsystem defines a
kernel device model and control message interface for platform NFIT
(NVDIMM Firmware Interface Table). This interface was first defined
by the ACPI v6.0 specification. Later versions may enhance or modify
this specification. The latest ACPI and UEFI specifications can be
found at http://uefi.org/specifications.
The latest ACPI and UEFI specifications can be found at uefi.org.
Operations
supported by ndctl include:
- Provisioning capacity (namespaces)
- Enumerating Devices
- Enabling and Disabling NVDIMMs, Regions, and Namespaces
- Managing NVDIMM Labels
The LIBNVDIMM subsystem provides support for three types of NVDIMMs,
namely, PMEM, BLK, and NVDIMM devices that can simultaneously support
both PMEM and BLK mode access. These three modes of operation are
described by the "NVDIMM Firmware Interface Table" (NFIT) in ACPI
v6.0 or later. Linux Kernel documentation can be found at:
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt. |
|
| 2019-11-22 22:26:46 |
Rafael David Tinoco |
attachment added |
|
emulated_vm.xml https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+attachment/5307204/+files/emulated_vm.xml |
|
| 2019-11-23 00:00:25 |
Rafael David Tinoco |
description |
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency:
pmdk (LP: #1790856)
* Package exists since bionic (-updates) in universe:
61.2-0ubuntu1~18.04.1 | bionic-updates/universe
63-1.3 | disco/universe
65-1 | eoan/universe
67-1 | focal/universe
* Packages:
ndctl libndctl6 libndctl-dev
daxctl libdaxctl1 libdaxctl-dev
ndctl: dctl is utility for managing the "libnvdimm" kernel
subsystem. The "libnvdimm" subsystem defines a kernel device
model and control message interface for platform NVDIMM resources
like those defined by the ACPI 6.0 NFIT (NVDIMM Firmware
Interface Table).
Operations supported by the tool include, provisioning capacity
(namespaces), as well as enumerating/enabling/disabling the
devices (dimms, regions, namespaces) associated with an NVDIMM
bus.
daxctl: The daxctl utility provides enumeration and provisioning
commands for the Linux kernel Device-DAX facility. This facility
enables DAX mappings of performance / feature differentiated
memory without need of a filesystem.
* Architectures:
source, amd64, arm64, armhf, i386, ppc64el, s390x
PMEM: A system-physical-address range where writes are persistent. A
block device composed of PMEM is capable of DAX. A PMEM address
range may span an interleave of several DIMMs.
BLK: A set of one or more programmable memory mapped apertures
provided by a DIMM to access its media. This indirection precludes
the performance benefit of interleaving, but enables DIMM-bounded
failure modes.
DAX: File system extensions to bypass the page cache and block layer
to mmap persistent memory, from a PMEM block device, directly into a
process address space.
Binary Packages:
ndctl
libndctl6
libndctl-dev
daxctl
libdaxctl1
libdaxctl-dev
[Rationale]
This is part of the MIR activity for all dependencies of pmdk.
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/1790856
Package was introduced in bionic after bionic was released (19.04.1)
in universe and it is still in universe until now.
[Security]
TODO: check the security History of the package
- http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- http://cve.mitre.org/cve/cve.html
[Quality assurance]
* Documentation:
- https://docs.pmem.io/ndctl-users-guide
- https://nvdimm.wiki.kernel.org/
Both packages (ndctl and daxctl) and its libraries (libndctl6,
libndctl-dev, libdaxctl1, libdaxctl-dev) install fine and are
operational (check comment #1).
TODO: 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.
TODO: 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.
TODO: 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.
TODO: The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
TODO: The package should not deal with exotic hardware which we cannot support.
TODO: 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.
TODO: 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.
TODO: It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
TODO: 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.
[UI standards]
TODO: End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
TODO: End-user applications must ship 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 to get an overview.
[Standards compliance]
TODO: The package should meet the FHS and Debian Policy standards.
TODO: Major violations should be documented and justified.
TODO: Also, the source packaging should be reasonably easy to understand and maintain.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
The Persistent Memory Development Kit (PMDK) is a collection of
libraries and tools for System Administrators and Application
Developers to simplify managing and accessing persistent memory
devices. The libraries build on the Direct Access (DAX) feature which
allows applications to directly access persistent memory as
memory-mapped files. This is described in detail in the Storage
Network Industry Association (SNIA) NVM Programming Model.
PMDK depends on libndctl.
The Non-Volatile Device Control (ndctl) is a utility for managing the
LIBNVDIMM Linux Kernel subsystem. The LIBNVDIMM subsystem defines a
kernel device model and control message interface for platform NFIT
(NVDIMM Firmware Interface Table). This interface was first defined
by the ACPI v6.0 specification. Later versions may enhance or modify
this specification. The latest ACPI and UEFI specifications can be
found at http://uefi.org/specifications.
The latest ACPI and UEFI specifications can be found at uefi.org.
Operations
supported by ndctl include:
- Provisioning capacity (namespaces)
- Enumerating Devices
- Enabling and Disabling NVDIMMs, Regions, and Namespaces
- Managing NVDIMM Labels
The LIBNVDIMM subsystem provides support for three types of NVDIMMs,
namely, PMEM, BLK, and NVDIMM devices that can simultaneously support
both PMEM and BLK mode access. These three modes of operation are
described by the "NVDIMM Firmware Interface Table" (NFIT) in ACPI
v6.0 or later. Linux Kernel documentation can be found at:
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt. |
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency:
pmdk (LP: #1790856)
* Package exists since bionic (-updates) in universe:
61.2-0ubuntu1~18.04.1 | bionic-updates/universe
63-1.3 | disco/universe
65-1 | eoan/universe
67-1 | focal/universe
* Packages:
ndctl libndctl6 libndctl-dev
daxctl libdaxctl1 libdaxctl-dev
ndctl: dctl is utility for managing the "libnvdimm" kernel
subsystem. The "libnvdimm" subsystem defines a kernel device
model and control message interface for platform NVDIMM resources
like those defined by the ACPI 6.0 NFIT (NVDIMM Firmware
Interface Table).
Operations supported by the tool include, provisioning capacity
(namespaces), as well as enumerating/enabling/disabling the
devices (dimms, regions, namespaces) associated with an NVDIMM
bus.
daxctl: The daxctl utility provides enumeration and provisioning
commands for the Linux kernel Device-DAX facility. This facility
enables DAX mappings of performance / feature differentiated
memory without need of a filesystem.
* Architectures:
source, amd64, arm64, armhf, i386, ppc64el, s390x
PMEM: A system-physical-address range where writes are persistent. A
block device composed of PMEM is capable of DAX. A PMEM address
range may span an interleave of several DIMMs.
BLK: A set of one or more programmable memory mapped apertures
provided by a DIMM to access its media. This indirection precludes
the performance benefit of interleaving, but enables DIMM-bounded
failure modes.
DAX: File system extensions to bypass the page cache and block layer
to mmap persistent memory, from a PMEM block device, directly into a
process address space.
Binary Packages:
ndctl
libndctl6
libndctl-dev
daxctl
libdaxctl1
libdaxctl-dev
[Rationale]
This is part of the MIR activity for all dependencies of pmdk.
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/1790856
Package was introduced in bionic after bionic was released (19.04.1)
in universe and it is still in universe until now.
[Security]
TODO: check the security History of the package
- http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- http://cve.mitre.org/cve/cve.html
[Quality assurance]
* Documentation:
- https://docs.pmem.io/ndctl-users-guide
- https://nvdimm.wiki.kernel.org/
- Both packages (ndctl and daxctl) and its libraries (libndctl6,
libndctl-dev, libdaxctl1, libdaxctl-dev) install fine and are
operational (check comment #1).
- There are no debconf templates and/or questions in this package.
TODO: 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.
TODO: 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.
TODO: The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
TODO: The package should not deal with exotic hardware which we cannot support.
TODO: 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.
TODO: 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.
TODO: It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
TODO: 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.
[UI standards]
TODO: End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
TODO: End-user applications must ship 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 to get an overview.
[Standards compliance]
TODO: The package should meet the FHS and Debian Policy standards.
TODO: Major violations should be documented and justified.
TODO: Also, the source packaging should be reasonably easy to understand and maintain.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
The Persistent Memory Development Kit (PMDK) is a collection of
libraries and tools for System Administrators and Application
Developers to simplify managing and accessing persistent memory
devices. The libraries build on the Direct Access (DAX) feature which
allows applications to directly access persistent memory as
memory-mapped files. This is described in detail in the Storage
Network Industry Association (SNIA) NVM Programming Model.
PMDK depends on libndctl.
The Non-Volatile Device Control (ndctl) is a utility for managing the
LIBNVDIMM Linux Kernel subsystem. The LIBNVDIMM subsystem defines a
kernel device model and control message interface for platform NFIT
(NVDIMM Firmware Interface Table). This interface was first defined
by the ACPI v6.0 specification. Later versions may enhance or modify
this specification. The latest ACPI and UEFI specifications can be
found at http://uefi.org/specifications.
The latest ACPI and UEFI specifications can be found at uefi.org.
Operations
supported by ndctl include:
- Provisioning capacity (namespaces)
- Enumerating Devices
- Enabling and Disabling NVDIMMs, Regions, and Namespaces
- Managing NVDIMM Labels
The LIBNVDIMM subsystem provides support for three types of NVDIMMs,
namely, PMEM, BLK, and NVDIMM devices that can simultaneously support
both PMEM and BLK mode access. These three modes of operation are
described by the "NVDIMM Firmware Interface Table" (NFIT) in ACPI
v6.0 or later. Linux Kernel documentation can be found at:
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt. |
|
| 2019-11-23 01:16:39 |
Rafael David Tinoco |
description |
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency:
pmdk (LP: #1790856)
* Package exists since bionic (-updates) in universe:
61.2-0ubuntu1~18.04.1 | bionic-updates/universe
63-1.3 | disco/universe
65-1 | eoan/universe
67-1 | focal/universe
* Packages:
ndctl libndctl6 libndctl-dev
daxctl libdaxctl1 libdaxctl-dev
ndctl: dctl is utility for managing the "libnvdimm" kernel
subsystem. The "libnvdimm" subsystem defines a kernel device
model and control message interface for platform NVDIMM resources
like those defined by the ACPI 6.0 NFIT (NVDIMM Firmware
Interface Table).
Operations supported by the tool include, provisioning capacity
(namespaces), as well as enumerating/enabling/disabling the
devices (dimms, regions, namespaces) associated with an NVDIMM
bus.
daxctl: The daxctl utility provides enumeration and provisioning
commands for the Linux kernel Device-DAX facility. This facility
enables DAX mappings of performance / feature differentiated
memory without need of a filesystem.
* Architectures:
source, amd64, arm64, armhf, i386, ppc64el, s390x
PMEM: A system-physical-address range where writes are persistent. A
block device composed of PMEM is capable of DAX. A PMEM address
range may span an interleave of several DIMMs.
BLK: A set of one or more programmable memory mapped apertures
provided by a DIMM to access its media. This indirection precludes
the performance benefit of interleaving, but enables DIMM-bounded
failure modes.
DAX: File system extensions to bypass the page cache and block layer
to mmap persistent memory, from a PMEM block device, directly into a
process address space.
Binary Packages:
ndctl
libndctl6
libndctl-dev
daxctl
libdaxctl1
libdaxctl-dev
[Rationale]
This is part of the MIR activity for all dependencies of pmdk.
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/1790856
Package was introduced in bionic after bionic was released (19.04.1)
in universe and it is still in universe until now.
[Security]
TODO: check the security History of the package
- http://people.ubuntu.com/~ubuntu-security/cve/universe.html
- http://cve.mitre.org/cve/cve.html
[Quality assurance]
* Documentation:
- https://docs.pmem.io/ndctl-users-guide
- https://nvdimm.wiki.kernel.org/
- Both packages (ndctl and daxctl) and its libraries (libndctl6,
libndctl-dev, libdaxctl1, libdaxctl-dev) install fine and are
operational (check comment #1).
- There are no debconf templates and/or questions in this package.
TODO: 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.
TODO: 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.
TODO: The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
TODO: The package should not deal with exotic hardware which we cannot support.
TODO: 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.
TODO: 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.
TODO: It is often useful to run lintian --pedantic on the package to spot the most common packaging issues in advance
TODO: 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.
[UI standards]
TODO: End-user applications must be internationalized (translatable), using the standard intltool/gettext build and runtime system and produce a proper PO template during build.
TODO: End-user applications must ship 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 to get an overview.
[Standards compliance]
TODO: The package should meet the FHS and Debian Policy standards.
TODO: Major violations should be documented and justified.
TODO: Also, the source packaging should be reasonably easy to understand and maintain.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
The Persistent Memory Development Kit (PMDK) is a collection of
libraries and tools for System Administrators and Application
Developers to simplify managing and accessing persistent memory
devices. The libraries build on the Direct Access (DAX) feature which
allows applications to directly access persistent memory as
memory-mapped files. This is described in detail in the Storage
Network Industry Association (SNIA) NVM Programming Model.
PMDK depends on libndctl.
The Non-Volatile Device Control (ndctl) is a utility for managing the
LIBNVDIMM Linux Kernel subsystem. The LIBNVDIMM subsystem defines a
kernel device model and control message interface for platform NFIT
(NVDIMM Firmware Interface Table). This interface was first defined
by the ACPI v6.0 specification. Later versions may enhance or modify
this specification. The latest ACPI and UEFI specifications can be
found at http://uefi.org/specifications.
The latest ACPI and UEFI specifications can be found at uefi.org.
Operations
supported by ndctl include:
- Provisioning capacity (namespaces)
- Enumerating Devices
- Enabling and Disabling NVDIMMs, Regions, and Namespaces
- Managing NVDIMM Labels
The LIBNVDIMM subsystem provides support for three types of NVDIMMs,
namely, PMEM, BLK, and NVDIMM devices that can simultaneously support
both PMEM and BLK mode access. These three modes of operation are
described by the "NVDIMM Firmware Interface Table" (NFIT) in ACPI
v6.0 or later. Linux Kernel documentation can be found at:
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt. |
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506
[Availability]
There is an on-going MIR for a package whose ndctl is a dependency:
pmdk (LP: #1790856)
* Package exists since bionic (-updates) in universe:
61.2-0ubuntu1~18.04.1 | bionic-updates/universe
63-1.3 | disco/universe
65-1 | eoan/universe
67-1 | focal/universe
* Packages:
ndctl libndctl6 libndctl-dev
daxctl libdaxctl1 libdaxctl-dev
ndctl: dctl is utility for managing the "libnvdimm" kernel
subsystem. The "libnvdimm" subsystem defines a kernel device
model and control message interface for platform NVDIMM resources
like those defined by the ACPI 6.0 NFIT (NVDIMM Firmware
Interface Table).
Operations supported by the tool include, provisioning capacity
(namespaces), as well as enumerating/enabling/disabling the
devices (dimms, regions, namespaces) associated with an NVDIMM
bus.
daxctl: The daxctl utility provides enumeration and provisioning
commands for the Linux kernel Device-DAX facility. This facility
enables DAX mappings of performance / feature differentiated
memory without need of a filesystem.
* Architectures:
source, amd64, arm64, armhf, i386, ppc64el, s390x
PMEM: A system-physical-address range where writes are persistent. A
block device composed of PMEM is capable of DAX. A PMEM address
range may span an interleave of several DIMMs.
BLK: A set of one or more programmable memory mapped apertures
provided by a DIMM to access its media. This indirection precludes
the performance benefit of interleaving, but enables DIMM-bounded
failure modes.
DAX: File system extensions to bypass the page cache and block layer
to mmap persistent memory, from a PMEM block device, directly into a
process address space.
Binary Packages:
ndctl
libndctl6
libndctl-dev
daxctl
libdaxctl1
libdaxctl-dev
[Rationale]
This is part of the MIR activity for all dependencies of pmdk. "ndctl" and "daxctl" are userland tools used to configure NVDIMMs and should be supported and put in main pocket (and server).
The "main" MIR of it is at:
https://bugs.launchpad.net/ubuntu/+source/pmdk/+bug/1790856
Package was introduced in bionic after bionic was released (19.04.1)
in universe and it is still in universe until now.
[Security]
- No related CVEs found at: cve.mitre.org
[Quality assurance]
* Documentation:
- https://docs.pmem.io/ndctl-users-guide
- https://nvdimm.wiki.kernel.org/
- Both packages (ndctl and daxctl) and its libraries (libndctl6,
libndctl-dev, libdaxctl1, libdaxctl-dev) install fine and are
operational (check comment #1).
- There are no debconf templates and/or questions in this package.
- The only existing/opened bug affecting the package was LP: #1811785 and I have already provided 2 MRs fixing that issue. No other long-term outstanding bug affecting it. Upstream seems well maintained and isolating fix commits, making them easy to cherry-pick and/or backport.
- There are no current Debian bugs for ndctl (https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=ndctl)
- Upstream has 25 cases opened (almost all of them with comments and discussions) and 77 cases already closed, leading to a conclusion that is actively maintained and provides good feedback to reporters.
- Package does not deal with exotic hardware, but, indeed, it deals with NEW type of hardware, getting more common every day (NVDIMMs). DAX support is already included in EXT4 and XFS filesystems, allowing NVDIMMs to be transparently used as block devices (without page cache). The userland libraries allow applications to get all benefits with a new memory (non-volatile) layer.
- Package has a minimum DEP8 support (for obvious issues with the binaries, as the utils need NVDIMMs to be present in the running environment).
- Package uses debian/watch.
- No lintian errors (pedantic).
- Package does not rely on obsolete packages:
$ apt-cache rdepends ndctl
ndctl
Reverse Depends:
daxctl
ndctl-dbgsym
daxctl
$ apt-cache depends ndctl
ndctl
PreDepends: init-system-helpers
Depends: libc6
Depends: libdaxctl1
Depends: libjson-c4
Depends: libkeyutils1
Depends: libndctl6
Depends: libuuid1
[UI standards]
N/A
[Dependencies]
$ apt-cache depends ndctl
ndctl
PreDepends: init-system-helpers
Depends: libc6
Depends: libdaxctl1 (itself)
Depends: libjson-c4 - main (exists since eoan)
Depends: libkeyutils1 - main
Depends: libndctl6 (itself)
Depends: libuuid1 - main
[Standards compliance]
- Package follows FHS.
- Debian Standards 4.4.1
- Source package is clear and well done.
[Maintenance]
The Server team will subscribe for the package for maintenance
[Background]
The Persistent Memory Development Kit (PMDK) is a collection of
libraries and tools for System Administrators and Application
Developers to simplify managing and accessing persistent memory
devices. The libraries build on the Direct Access (DAX) feature which
allows applications to directly access persistent memory as
memory-mapped files. This is described in detail in the Storage
Network Industry Association (SNIA) NVM Programming Model.
PMDK depends on libndctl.
The Non-Volatile Device Control (ndctl) is a utility for managing the
LIBNVDIMM Linux Kernel subsystem. The LIBNVDIMM subsystem defines a
kernel device model and control message interface for platform NFIT
(NVDIMM Firmware Interface Table). This interface was first defined
by the ACPI v6.0 specification. Later versions may enhance or modify
this specification. The latest ACPI and UEFI specifications can be
found at http://uefi.org/specifications.
The latest ACPI and UEFI specifications can be found at uefi.org.
Operations
supported by ndctl include:
- Provisioning capacity (namespaces)
- Enumerating Devices
- Enabling and Disabling NVDIMMs, Regions, and Namespaces
- Managing NVDIMM Labels
The LIBNVDIMM subsystem provides support for three types of NVDIMMs,
namely, PMEM, BLK, and NVDIMM devices that can simultaneously support
both PMEM and BLK mode access. These three modes of operation are
described by the "NVDIMM Firmware Interface Table" (NFIT) in ACPI
v6.0 or later. Linux Kernel documentation can be found at:
https://www.kernel.org/doc/Documentation/nvdimm/nvdimm.txt. |
|
| 2019-11-23 01:32:32 |
Rafael David Tinoco |
bug |
|
|
added subscriber MIR approval team |
| 2019-11-25 10:07:13 |
Christian Ehrhardt |
ndctl (Ubuntu): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2019-11-25 11:37:07 |
Christian Ehrhardt |
ndctl (Ubuntu): assignee |
Christian Ehrhardt (paelzer) |
Ubuntu Security Team (ubuntu-security) |
|
| 2019-11-25 11:37:13 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2019-11-27 16:33:42 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2019-12-03 18:31:40 |
Joshua Powers |
bug |
|
|
added subscriber Joshua Powers |
| 2019-12-06 03:04:51 |
Rafael David Tinoco |
attachment added |
|
canonical-convert-ndctl-test-into-qa-regression-ndctl.patch https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+attachment/5310106/+files/canonical-convert-ndctl-test-into-qa-regression-ndctl.patch |
|
| 2019-12-06 19:24:46 |
Rafael David Tinoco |
attachment removed |
canonical-convert-ndctl-test-into-qa-regression-ndctl.patch https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+attachment/5310106/+files/canonical-convert-ndctl-test-into-qa-regression-ndctl.patch |
|
|
| 2019-12-06 19:25:08 |
Rafael David Tinoco |
attachment added |
|
canonical-convert-ndctl-test-into-qa-regression-ndctl.patch https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+attachment/5310302/+files/canonical-convert-ndctl-test-into-qa-regression-ndctl.patch |
|
| 2019-12-07 07:45:12 |
Rafael David Tinoco |
attachment removed |
canonical-convert-ndctl-test-into-qa-regression-ndctl.patch https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+attachment/5310302/+files/canonical-convert-ndctl-test-into-qa-regression-ndctl.patch |
|
|
| 2019-12-07 07:45:19 |
Rafael David Tinoco |
attachment removed |
emulated_vm.xml https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+attachment/5307204/+files/emulated_vm.xml |
|
|
| 2019-12-08 04:07:43 |
Rafael David Tinoco |
merge proposal linked |
|
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/ndctl/+git/ndctl/+merge/376487 |
|
| 2019-12-08 16:14:23 |
Rafael David Tinoco |
merge proposal linked |
|
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/ndctl/+git/ndctl/+merge/376493 |
|
| 2020-01-23 15:59:47 |
Joy Latten |
ndctl (Ubuntu): assignee |
Ubuntu Security Team (ubuntu-security) |
|
|
| 2020-01-23 16:00:48 |
Joy Latten |
bug |
|
|
added subscriber Joy Latten |
| 2020-01-23 16:20:38 |
Joy Latten |
bug watch added |
|
https://github.com/pmem/ndctl/issues/131 |
|
| 2020-01-28 07:32:22 |
Christian Ehrhardt |
ndctl (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-01-28 07:32:25 |
Christian Ehrhardt |
ndctl (Ubuntu): status |
New |
In Progress |
|
| 2020-02-04 21:30:47 |
Andreas Hasenack |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/qa-regression-testing/+git/qa-regression-testing/+merge/378543 |
|
| 2020-02-06 14:41:43 |
Sebastien Bacher |
ndctl (Ubuntu): status |
In Progress |
Fix Released |
|
