[Bug 2008789] Re: [MIR] inetutils

Dominik Viererbe 2008789 at bugs.launchpad.net
Tue Mar 14 10:15:08 UTC 2023 

** Description changed:

- WORK IN PROGRESS by foundations
- due to https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2009814
- 
- Dear reviewers, this is my first MIR. I answered all questions very 
- carefully, but if something feels wrong, please look extra closely or 
+ Dear reviewers, this is my first MIR. I answered all questions very
+ carefully, but if something feels wrong, please look extra closely or
  ask me (~dviererbe) to reinvestigate a given answer.
  
  [Availability]
  The package inetutils-telnet is already in Ubuntu universe.
  The package inetutils-telnet build for the architectures it is designed to work on.
  It currently builds and works for architetcures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
  Link to package [[https://launchpad.net/ubuntu/+source/inetutils|inetutils]]
  
  [Rationale]
- RULE: There must be a certain level of demand for the package
-   The package inetutils-telnet is required in Ubuntu main:
-   - The package inetutils-telnet will not generally be useful for a large part of
-     our user base, but is important/helpful still because it is commonly used for 
-     network diagnostics, like protocol testing of SMTP services. 
-   - Additionally telnet is still used for legacy industrial and scientific 
-     equipment.
-   - Package inetutils-telnet covers similar use cases as netkit-telnet, but 
-     is better because netkit-telnet has been dropped altogether from Debian, 
-     thereby we want to replace it.
+  The package inetutils-telnet is required in Ubuntu main:
+  - The package inetutils-telnet will not generally be useful for a large part of
+    our user base, but is important/helpful still because it is commonly used for
+    network diagnostics, like protocol testing of SMTP services.
+  - Additionally telnet is still used for legacy industrial and scientific
+    equipment.
+  - Package inetutils-telnet covers similar use cases as netkit-telnet, but
+    is better because netkit-telnet has been dropped altogether from Debian,
+    thereby we want to replace it.
  
- RULE: Reviews will take some time. Also the potential extra work out of review
- RULE: feedback from either MIR-team and/or security-team will take time.
- RULE: For better priorization it is quite helpful to clearly state the
- RULE: target release and set a milestone to the bug task.
- RULE: When doing so do not describe what you "wish" or "would like to have".
- RULE: Only milestones that are sufficiently well-founded and related to
- RULE: major releases will be considered
-   - The package inetutils-telnet is required in Ubuntu main no later than 
-     April 13th 2023 due to the Ubuntu 23.04 Lunar Lobster release date.
+  - The package inetutils-telnet is required in Ubuntu main no later than
+    April 13th 2023 due to the Ubuntu 23.04 Lunar Lobster release date.
  
  [Security]
- RULE: The security history and the current state of security issues in the
- RULE: package must allow us to support the package for at least 9 months (120
- RULE: for LTS+ESM support) without exposing its users to an inappropriate level
- RULE: of security risks. This requires checking of several things:
- RULE:   - Search in the National Vulnerability Database using the PKG as keyword
- RULE:     https://cve.mitre.org/cve/search_cve_list.html
- RULE:   - check OSS security mailing list (feed into search engine
- RULE:     'site:www.openwall.com/lists/oss-security <pkgname>')
- RULE:   - Ubuntu CVE Tracker
- RULE:     https://ubuntu.com/security/cve?package=<source-package-name>
- RULE:   - Debian Security Tracker
- RULE:     https://security-tracker.debian.org/tracker/source-package/<source-package-name>
-   - Had security issues in the past:
+  - Had security issues in the past:
     - CVE-2019-0053 (needs triage)
       - https://ubuntu.com/security/CVE-2019-0053
     - most likely not relevant:
       - CVE-2022-39028 (only related to telnetd)
         - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39028
-        - https://ubuntu.com/security/CVE-2022-39028     
+        - https://ubuntu.com/security/CVE-2022-39028
       - CVE-2020-10188 (related to netcat):
         - https://www.openwall.com/lists/oss-security/2018/12/13/2
         - https://www.openwall.com/lists/oss-security/2018/12/14/8
       - CVE-2011-4862 (related to telnetd; not sure if relevant anymore)
         - https://ubuntu.com/security/CVE-2011-4862
         - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
     - security issues were patched or reached end of life
  
- RULE: - Check for security relevant binaries and behavior.
- RULE:   If any are present, this requires a more in-depth security review.
-   - no `suid` or `sgid` binaries
-   - no executables in `/sbin` and `/usr/sbin`
-   - Package does not install services, timers or recurring jobs
-   - Packages does not open privileged ports (ports < 1024)
-   - Packages does not contain extensions to security-sensitive software
-     (filters, scanners, plugins, UI skins, ...)
-   - See list of files for:
-     - amd64: https://packages.ubuntu.com/lunar/amd64/inetutils-telnet/filelist
-     - arm64: https://packages.ubuntu.com/lunar/arm64/inetutils-telnet/filelist
-     - armhf: https://packages.ubuntu.com/lunar/armhf/inetutils-telnet/filelist
-     - i386: https://packages.ubuntu.com/lunar/i386/inetutils-telnet/filelist
-     - ppc64el: https://packages.ubuntu.com/lunar/ppc64el/inetutils-telnet/filelist
-     - s390x: https://packages.ubuntu.com/lunar/s390x/inetutils-telnet/filelist
+  - no `suid` or `sgid` binaries
+  - no executables in `/sbin` and `/usr/sbin`
+  - Package does not install services, timers or recurring jobs
+  - Packages does not open privileged ports (ports < 1024)
+  - Packages does not contain extensions to security-sensitive software
+    (filters, scanners, plugins, UI skins, ...)
+  - See list of files for:
+    - amd64: https://packages.ubuntu.com/lunar/amd64/inetutils-telnet/filelist
+    - arm64: https://packages.ubuntu.com/lunar/arm64/inetutils-telnet/filelist
+    - armhf: https://packages.ubuntu.com/lunar/armhf/inetutils-telnet/filelist
+    - i386: https://packages.ubuntu.com/lunar/i386/inetutils-telnet/filelist
+    - ppc64el: https://packages.ubuntu.com/lunar/ppc64el/inetutils-telnet/filelist
+    - s390x: https://packages.ubuntu.com/lunar/s390x/inetutils-telnet/filelist
  
  [Quality assurance - function/usage]
- RULE: - After installing the package it must be possible to make it working with
- RULE:   a reasonable effort of configuration and documentation reading.
-   - The package works well right after install
+  - The package works well right after install
  
  [Quality assurance - maintenance]
- RULE: - To support a package, we must be reasonably convinced that upstream
- RULE:   supports and cares for the package.
- RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug
- RULE:   tracking systems must be evaluated. Important bugs must be pointed out
- RULE:   and discussed in the MIR report.
-   - The package is maintained well in Debian/Ubuntu/Upstream and does
-     not have too many, long-term & critical, open bugs
-     - Ubuntu https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug
-     - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=inetutils
-     - Upstream-Homepage: https://www.gnu.org/software/inetutils/
-     - Upstream-Bugtracker: https://lists.gnu.org/archive/html/bug-inetutils/
-   - The package does not deal with exotic hardware we cannot support
+  - The package is maintained well in Debian/Ubuntu/Upstream and does
+    not have too many, long-term & critical, open bugs
+    - Ubuntu https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug
+    - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=inetutils
+    - Upstream-Homepage: https://www.gnu.org/software/inetutils/
+    - Upstream-Bugtracker: https://lists.gnu.org/archive/html/bug-inetutils/
+  - The package does not deal with exotic hardware we cannot support
  
  [Quality assurance - testing]
- RULE: - The package must include a non-trivial test suite
- RULE:   - it should run at package build and fail the build if broken
-   - The package runs a test suite on build time, if it fails
-     it makes the build fail
+  - The package runs a test suite on build time, if it fails
+    it makes the build fail
  
- RULE:   - The package should, but is not required to, also contain
- RULE:     non-trivial autopkgtest(s).
-   - The package runs an autopkgtest, and is currently passing on
-     amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
-   - link to builds (logs can be accessed through the web UI)
-     https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=built&arch_tag=all
-   - Link to autopkgtests https://autopkgtest.ubuntu.com/packages/i/inetutils 
+  - The package runs an autopkgtest, and its builds are currently passing on
+    amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
+  - link to builds (logs can be accessed through the web UI)
+    https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=built&arch_tag=all
+  - Link to autopkgtests https://autopkgtest.ubuntu.com/packages/i/inetutils
  
- RULE: - existing but failing tests that shall be handled as "ok to fail"
- RULE:   need to be explained along the test logs below
- TODO-A:  - The package does have not failing autopkgtests right now
- TODO-B:  - The package does have failing autopkgtests tests right now, but they
-     allways fail, this is ok because the failure occures at the 
-     inetutils-ping package.
- 
- RULE: - In some cases a solution that is about to be promoted consists of
- RULE:   several very small libraries and one actual application uniting them
- RULE:   to achieve something useful. This is rather common in the go/rust space.
- RULE:   In that case often these micro-libs on their own can and should only
- RULE:   provide low level unit-tests. But more complex autopkgtests make no
- RULE:   sense on that level. Therefore in those cases one might want to test on
- RULE:   the solution level.
- RULE:   - Process wise MIR-requesting teams can ask (on the bug) for this
- RULE:     special case to apply for a given case, which reduces the test
- RULE:     constraints on the micro libraries but in return increases the
- RULE:     requirements for the test of the actual app/solution.
- RULE:   - Since this might promote micro-lib packages to main with less than
- RULE:     the common level of QA any further MIRed program using them will have
- RULE:     to provide the same amount of increased testing.
-  - Not relevant for this package.
+  - The package does have failing autopkgtests tests right now, but they
+    allways fail (See: https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2009814)
+    This is okay because the failure occures at the inetutils-ping package.
+    The Foundations Team is working on a fix.
  
  [Quality assurance - packaging]
- RULE: - The package uses a debian/watch file whenever possible. In cases where
- RULE:   this is not possible (e.g. native packages), the package should either
- RULE:   provide a debian/README.source file or a debian/watch file (with
- RULE:   comments only) providing clear instructions on how to generate the
- RULE:   source tar file.
-   - debian/watch is present and works
+  - debian/watch is present and works
+  - debian/control defines a correct Maintainer field
  
- RULE: - The package should define the correct "Maintainer:" field in
- RULE:   debian/control. This needs to be updated, using `update-maintainer`
- RULE:   whenever any Ubuntu delta is applied to the package, as suggested by
- RULE:   dpkg (LP: #1951988)
-   - debian/control defines a correct Maintainer field
+  - This package does not yield massive lintian Warnings, Errors
+  - Recent build log of inetutils: https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=all&arch_tag=all
+  - Full output of `lintian --pedantic` is attached as an extra post to this bug.
+  - A lintian overrides is present, but ok because it is unused
+  - The lintian Error 'inetutils changes: bad-distribution-in-changes-file lunar-amd64'
+    emitted in the build log, this is because the debian/changelog file
+    specifies 'unstable' as distribution.
  
- RULE: - It is often useful to run `lintian --pedantic` on the package to spot
- RULE:   the most common packaging issues in advance
- RULE: - Non-obvious or non-properly commented lintian overrides should be
- RULE:   explained
-   - This package does not yield massive lintian Warnings, Errors
-   - Recent build log of inetutils: https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=all&arch_tag=all
-   - Full output of `lintian --pedantic` is attached as an extra post to this bug.
-   - A lintian overrides is present, but ok because it is unused
-   - The lintian Error 'inetutils changes: bad-distribution-in-changes-file lunar-amd64' 
-     emitted in the build log, this is because the debian/changelog file 
-     specifies 'unstable' as distribution.
+  - This package does not rely on obsolete or about to be demoted packages.
+    (The dependencies had recent updates and I could not find any open bug
+    ticket that indicates a upcoming demotion)
+  - This package has no python2 or GTK2 dependencies
  
- RULE: - The package should not rely on obsolete or about to be demoted packages.
- RULE:   That currently includes package dependencies on Python2 (without
- RULE:   providing Python3 packages), and packages depending on GTK2.
-   - This package does not rely on obsolete or about to be demoted packages.
-     (The dependencies had recent updates and I could not find any open bug 
-     ticket that indicates a upcoming demotion)
-   - This package has no python2 or GTK2 dependencies
+  - The package will be installed by default, but does not ask debconf
+    questions
  
- RULE: - Debconf questions should not bother the default user too much
-   - The package will be installed by default, but does not ask debconf
-     questions
- 
- RULE:  - The source packaging (in debian/) should be reasonably easy to
- RULE:   understand and maintain.
-   - Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/inetutils/tree/debian/control
-   - There is still the complication that building/testing inetutils-telnet 
-     can fail because of other inetutils-* packages.
+  - Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/inetutils/tree/debian/control
+  - There is still the complication that building/testing inetutils-telnet
+    can fail because of other inetutils-* packages.
  
  [UI standards]
    - Application is not end-user facing (does not need translation)
-   - End-user applications without desktop file, not needed because it is a 
+   - End-user applications without desktop file, not needed because it is a
      command line tool for sysadmins
  
  [Dependencies]
- RULE: - In case of alternative the preferred alternative must be in main.
- RULE: - Build(-only) dependencies can be in universe
- RULE: - If there are further dependencies they need a separate MIR discussion
- RULE:   (this can be a separate bug or another task on the main MIR bug)
-   - No further depends or recommends dependencies that are not yet in main
+  - No further depends or recommends dependencies that are not yet in main
  
  [Standards compliance]
- RULE: - Major violations should be documented and justified.
- RULE:   - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]]
- RULE:   - [[https://www.debian.org/doc/debian-policy/|Debian Policy]]
-   - This package correctly follows FHS and Debian Policy
+  - This package correctly follows FHS and Debian Policy
  
  [Maintenance/Owner]
- RULE: The package must have an acceptable level of maintenance corresponding
- RULE: to its complexity:
- RULE: - All packages must have a designated "owning" team, regardless of
- RULE:   complexity, which is set as a package bug contact. This is not a
- RULE:   requirement for the MIR team ACK, but for the package to be promoted
- RULE:   by an archive admin. Still, it is strongly suggested to subscribe,
- RULE:   as the owning team will get a preview of the to-be-expected incoming
- RULE:   bugs later on.
- RULE: - Simple packages (e.g. language bindings, simple Perl modules, small
- RULE:   command-line programs, etc.) might not need very much maintenance
- RULE:   effort, and if they are maintained well in Debian we can just keep them
- RULE:   synced. They still need a subscribing team to handle bugs, FTBFS and
- RULE:   tests
- RULE: - More complex packages will usually need a developer or team of
- RULE:   developers paying attention to their bugs, whether that be in Ubuntu
- RULE:   or elsewhere (often Debian). Packages that deliver major new headline
- RULE:   features in Ubuntu need to have commitment from Ubuntu developers
- RULE:   willing to spend substantial time on them.
-   - Owning Team will be Ubuntu Foundations
-   - Ubuntu Foundations Bugs is already subscribed to the package
+  - Owning Team will be Ubuntu Foundations
+  - Ubuntu Foundations Bugs is already subscribed to the package
  
- RULE: - Responsibilities implied by static builds promoted to main, which is
- RULE:   not a recommended but a common case with golang and rust packages.
- RULE:   - the security team will track CVEs for all vendored/embedded sources in main
- RULE:   - the security team will provide updates to main for all `golang-*-dev`
- RULE:     packages
- RULE:   - the security team will provide updates to main for non-vendored
- RULE:     dependencies as per normal procedures (including e.g.,
- RULE:     sponsoring/coordinating uploads from teams/upstream projects, etc)
- RULE:   - the security team will perform no-change-rebuilds for all packages
- RULE:     listing an CVE-fixed package as Built-Using and coordinate testing
- RULE:     with the owning teams responsible for the rebuilt packages
- RULE:   - for packages that build using any `golang-*-dev` packages:
- RULE:     - the owning team must state their commitment to test
- RULE:       no-change-rebuilds triggered by a dependent library/compiler and to
- RULE:       fix any issues found for the lifetime of the release (including ESM
- RULE:       when included)
- RULE:     - the owning team must provide timely testing of no-change-rebuilds
- RULE:       from the security team, fixing the rebuilt package as necessary
- RULE:   - for packages that build with approved vendored code:
- RULE:     - the owning team must state their commitment to provide updates to
- RULE:       the security team for any affected vendored code for the lifetime of
- RULE:       the release (including ESM when included)
- RULE:     - the security team will alert the owning team of issues that may
- RULE:       affect their vendored code
- RULE:     - the owning team will provide timely, high quality updates for the
- RULE:       security team to sponsor to fix issues in the affected vendored code
- RULE:     - if subsequent uploads add new vendored components or dependencies
- RULE:       these have to be reviewed and agreed by the security team.
- RULE:     - Such updates in the project might be trivial, but imply that a
- RULE:       dependency for e.g. a CVE fix will be moved to a new major version.
- RULE:       Being vendored that does gladly at least not imply incompatibility
- RULE:       issues with other packages or the SRU policy. But it might happen
- RULE:       that this triggers either:
- RULE:       a) The need to adapt the current version of the main package and/or
- RULE:          other vendored dependencies to work with the new dependency
- RULE:       b) The need to backport the fix in the dependency as the main
- RULE:          package will functionally only work well with the older version
- RULE:       c) The need to backport the fix in the dependency, as it would imply
- RULE:          requiring a newer toolchain to be buildable that isn't available
- RULE:          in the target release.
- RULE: - The rust ecosystem currently isn't yet considered stable enough for
- RULE:   classic lib dependencies and transitions in main; therefore the
- RULE:   expectation for those packages is to vendor (and own/test) all
- RULE:   dependencies (except those provided by the rust runtime itself).
- RULE:   This implies that all the rules for vendored builds always
- RULE:   apply to them. In addition:
- RULE:   - The rules and checks for rust based packages are preliminary and might
- RULE:     change over time as the ecosytem matures and while
- RULE:     processing the first few rust based packages.
- RULE:   - It is expected rust builds will use dh-cargo so that a later switch
- RULE:     to non vendored dependencies isn't too complex (e.g. it is likely
- RULE:     that over time more common libs shall become stable and then archive
- RULE:     packages will be used to build).
- RULE:   - Right now that tooling to get a Cargo.lock that will include internal
- RULE:     vendored dependencies isn't in place yet (expect a dh-cargo change
- RULE:     later). Until it is available, as a fallback one can scan the
- RULE:     directory at build time and let it be generated in debian/rules.
- RULE:     An example might look like:
- RULE:       d/rules:
- RULE:         override_dh_auto_test:
- RULE:             CARGO_HOME=debian /usr/share/cargo/bin/cargo test --offline
- RULE:       d/<pkg>.install:
- RULE:         Cargo.lock /usr/share/doc/<pkg>
- RULE:       d/config.toml
- RULE:         # Use the vendorized sources to produce the Cargo.lock file. This
- RULE:         # can be performed by pointing $CARGO_HOME to the path containing
- RULE:         # this file.
- RULE:         [source]
- RULE:         [source.my-vendor-source]
- RULE:         directory = "vendor"
- RULE:         [source.crates-io]
- RULE:         replace-with = "my-vendor-source"
- 
- RULE: - All vendored dependencies (no matter what language) shall have a
- RULE:   way to be refreshed
-   - This does not use static builds
-   - This does not use vendored code
-   - This package is not rust based
+  - This does not use static builds
+  - This does not use vendored code
+  - This package is not rust based
  
  [Background information]
- RULE: - The package descriptions should explain the general purpose and context
- RULE:   of the package. Additional explanations/justifications should be done in
- RULE:   the MIR report.
- RULE: - If the package was renamed recently, or has a different upstream name,
- RULE:   this needs to be explained in the MIR report.
-   - The Package description explains the package well
-   - Debian transitioned its default ‘telnet’ client from netkit-telnet to 
-     inetutils-telnet. This transition was postponed in Ubuntu for kinetic by 
-     having ubuntu-standard Recommend `netkit-telnet` instead of `telnet`.  
-     But now, netkit-telnet has been dropped altogether from Debian and 
-     process-removals is prompting us to also delete it from lunar.
-     (See: https://packages.debian.org/bookworm/telnet)
-   - other binary packages from this inetutils might be brought into main 
-     accidentally, or even intentionally but with limited oversight, in the future. 
-   - mixed main/universe is a foreign concept to users
+  - The Package description explains the package well
+  - Debian transitioned its default `telnet` client from netkit-telnet to
+    inetutils-telnet. This transition was postponed in Ubuntu for kinetic by
+    having ubuntu-standard Recommend `netkit-telnet` instead of `telnet`.
+    But now, netkit-telnet has been dropped altogether from Debian and
+    process-removals is prompting us to also delete it from lunar.
+    (See: https://packages.debian.org/bookworm/telnet)
+  - other binary packages from this inetutils might be brought into main
+    accidentally, or even intentionally but with limited oversight, in the future.
+  - mixed main/universe is a foreign concept to users
  
  Seeded in lunar.standard as a replacement for netkit-telnet:
  https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=lunar&id=349619dc49fdd0695c0bd7f9ae72f535809c2657

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to inetutils in Ubuntu.
https://bugs.launchpad.net/bugs/2008789

Title:
  [MIR] inetutils

Status in inetutils package in Ubuntu:
  New

Bug description:
  Dear reviewers, this is my first MIR. I answered all questions very
  carefully, but if something feels wrong, please look extra closely or
  ask me (~dviererbe) to reinvestigate a given answer.

  [Availability]
  The package inetutils-telnet is already in Ubuntu universe.
  The package inetutils-telnet build for the architectures it is designed to work on.
  It currently builds and works for architetcures: amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
  Link to package [[https://launchpad.net/ubuntu/+source/inetutils|inetutils]]

  [Rationale]
   The package inetutils-telnet is required in Ubuntu main:
   - The package inetutils-telnet will not generally be useful for a large part of
     our user base, but is important/helpful still because it is commonly used for
     network diagnostics, like protocol testing of SMTP services.
   - Additionally telnet is still used for legacy industrial and scientific
     equipment.
   - Package inetutils-telnet covers similar use cases as netkit-telnet, but
     is better because netkit-telnet has been dropped altogether from Debian,
     thereby we want to replace it.

   - The package inetutils-telnet is required in Ubuntu main no later than
     April 13th 2023 due to the Ubuntu 23.04 Lunar Lobster release date.

  [Security]
   - Had security issues in the past:
     - CVE-2019-0053 (needs triage)
       - https://ubuntu.com/security/CVE-2019-0053
     - most likely not relevant:
       - CVE-2022-39028 (only related to telnetd)
         - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-39028
         - https://ubuntu.com/security/CVE-2022-39028
       - CVE-2020-10188 (related to netcat):
         - https://www.openwall.com/lists/oss-security/2018/12/13/2
         - https://www.openwall.com/lists/oss-security/2018/12/14/8
       - CVE-2011-4862 (related to telnetd; not sure if relevant anymore)
         - https://ubuntu.com/security/CVE-2011-4862
         - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
     - security issues were patched or reached end of life

   - no `suid` or `sgid` binaries
   - no executables in `/sbin` and `/usr/sbin`
   - Package does not install services, timers or recurring jobs
   - Packages does not open privileged ports (ports < 1024)
   - Packages does not contain extensions to security-sensitive software
     (filters, scanners, plugins, UI skins, ...)
   - See list of files for:
     - amd64: https://packages.ubuntu.com/lunar/amd64/inetutils-telnet/filelist
     - arm64: https://packages.ubuntu.com/lunar/arm64/inetutils-telnet/filelist
     - armhf: https://packages.ubuntu.com/lunar/armhf/inetutils-telnet/filelist
     - i386: https://packages.ubuntu.com/lunar/i386/inetutils-telnet/filelist
     - ppc64el: https://packages.ubuntu.com/lunar/ppc64el/inetutils-telnet/filelist
     - s390x: https://packages.ubuntu.com/lunar/s390x/inetutils-telnet/filelist

  [Quality assurance - function/usage]
   - The package works well right after install

  [Quality assurance - maintenance]
   - The package is maintained well in Debian/Ubuntu/Upstream and does
     not have too many, long-term & critical, open bugs
     - Ubuntu https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug
     - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=inetutils
     - Upstream-Homepage: https://www.gnu.org/software/inetutils/
     - Upstream-Bugtracker: https://lists.gnu.org/archive/html/bug-inetutils/
   - The package does not deal with exotic hardware we cannot support

  [Quality assurance - testing]
   - The package runs a test suite on build time, if it fails
     it makes the build fail

   - The package runs an autopkgtest, and its builds are currently passing on
     amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
   - link to builds (logs can be accessed through the web UI)
     https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=built&arch_tag=all
   - Link to autopkgtests https://autopkgtest.ubuntu.com/packages/i/inetutils

   - The package does have failing autopkgtests tests right now, but they
     allways fail (See: https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2009814)
     This is okay because the failure occures at the inetutils-ping package.
     The Foundations Team is working on a fix.

  [Quality assurance - packaging]
   - debian/watch is present and works
   - debian/control defines a correct Maintainer field

   - This package does not yield massive lintian Warnings, Errors
   - Recent build log of inetutils: https://launchpad.net/ubuntu/lunar/+builds?build_text=inetutils&build_state=all&arch_tag=all
   - Full output of `lintian --pedantic` is attached as an extra post to this bug.
   - A lintian overrides is present, but ok because it is unused
   - The lintian Error 'inetutils changes: bad-distribution-in-changes-file lunar-amd64'
     emitted in the build log, this is because the debian/changelog file
     specifies 'unstable' as distribution.

   - This package does not rely on obsolete or about to be demoted packages.
     (The dependencies had recent updates and I could not find any open bug
     ticket that indicates a upcoming demotion)
   - This package has no python2 or GTK2 dependencies

   - The package will be installed by default, but does not ask debconf
     questions

   - Packaging and build is easy, link to debian/rules: https://git.launchpad.net/ubuntu/+source/inetutils/tree/debian/control
   - There is still the complication that building/testing inetutils-telnet
     can fail because of other inetutils-* packages.

  [UI standards]
    - Application is not end-user facing (does not need translation)
    - End-user applications without desktop file, not needed because it is a
      command line tool for sysadmins

  [Dependencies]
   - No further depends or recommends dependencies that are not yet in main

  [Standards compliance]
   - This package correctly follows FHS and Debian Policy

  [Maintenance/Owner]
   - Owning Team will be Ubuntu Foundations
   - Ubuntu Foundations Bugs is already subscribed to the package

   - This does not use static builds
   - This does not use vendored code
   - This package is not rust based

  [Background information]
   - The Package description explains the package well
   - Debian transitioned its default `telnet` client from netkit-telnet to
     inetutils-telnet. This transition was postponed in Ubuntu for kinetic by
     having ubuntu-standard Recommend `netkit-telnet` instead of `telnet`.
     But now, netkit-telnet has been dropped altogether from Debian and
     process-removals is prompting us to also delete it from lunar.
     (See: https://packages.debian.org/bookworm/telnet)
   - other binary packages from this inetutils might be brought into main
     accidentally, or even intentionally but with limited oversight, in the future.
   - mixed main/universe is a foreign concept to users

  Seeded in lunar.standard as a replacement for netkit-telnet:
  https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?h=lunar&id=349619dc49fdd0695c0bd7f9ae72f535809c2657

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/inetutils/+bug/2008789/+subscriptions

More information about the foundations-bugs mailing list