[Availability]
The package jigit is already in Ubuntu universe.
The package jigit build for the architectures it is designed to work on.
It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
Link to package [[https://launchpad.net/ubuntu/+source/jigit|jigit]]
[Rationale]
- The package jigit is required in Ubuntu main for libisofs (in turn needed for usb-creator)
- The package jigit will not generally be useful for a large part of
our user base, but is important/helpful still because Debian is still using this file format to
publish its releases.
- The package jigit is a new runtime dependency of package usb-creator that
we already support
- It would be great and useful to community/processes to have the
package jigit in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- Binary mkjigsnap in sbin => this requires security review
- 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, ...)
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/jigit/+bug
=> 2 bugs open for years, one incomplete and one briefly asking for multiarch support.
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=jigit
=> Only 3 that are not important but they have been open for years (one from 2004!)
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
- The package does not run a test at build time because no testsuite exists upstream
- The package does not run an autopkgtest because no testsuite exists upstream
- The package can be tested at autopktest time by adding a test that is actually described in libjte/test/demo.c file and that will be added before the promotion (https://launchpad.net/~alexghiti/+archive/ubuntu/riscv/+sourcepub/13673149/+listing-archive-extra)
[Quality assurance - packaging]
- debian/watch is not present and there is nothing explaining how to create the source tar: a bug report
from 2013 proposed to add a watchfile but the maintainer refused it (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697700)
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Please link to a recent build log of the package https://launchpadlibrarian.net/464118381/buildlog_ubuntu-focal-amd64.jigit_1.22-3build1_BUILDING.txt.gz
- Please attach the full output you have got from
`lintian --pedantic` as an extra post to this bug.
$ lintian --pedantic
P: jigit source: no-dep5-copyright [debian/copyright]
P: jigit source: package-uses-old-debhelper-compat-version 10
P: jigit source: silent-on-rules-requiring-root [debian/control]
P: jigit source: trailing-whitespace debian/changelog (line 169)
P: jigit source: trailing-whitespace debian/changelog (line 226)
P: jigit source: trailing-whitespace debian/control (line 19)
P: jigit source: trailing-whitespace ... use --no-tag-display-limit to see all (or pipe to a file/program)
P: jigit source: very-long-line-length-in-source-file libjte/aclocal.m4 line 6631 is 738 characters long (>512)
P: jigit source: very-long-line-length-in-source-file libjte/configure line 10420 is 704 characters long (>512)
P: jigit source: very-long-line-length-in-source-file libjte/libtool.m4 line 6621 is 738 characters long (>512)
- Lintian overrides are not present
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions higher than medium
- Packaging and build is easy, link to d/rules https://sources.debian.org/src/jigit/1.22-3/debian/rules/
[UI standards]
- Application is end-user facing but no translation is present.
- End-user applications without desktop file, not needed because most users won't use it.
[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 Foundations
- Team is already subscribed to the package
- This does not use static builds
- This does not use vendored code
- The package successfully built during the most recent test rebuild (https://launchpad.net/ubuntu/+archive/test-rebuild-20220317-jammy/+sourcepub/13319228/+listing-archive-extra)
[Background information]
The Package description explains the package well
Upstream Name is jigit
Link to upstream project https://www.einval.com/~steve/software/JTE/
~
Review for Package: jigit
[Summary]
MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.
This does need a security review, so I'll assign ubuntu-security
List of specific binary packages to be promoted to main: jigit
(jigit, libjte2, libjte-dev)
Specific binary packages built, but NOT to be promoted to main: libjte2, libjte-dev
Required TODOs:
- this seems rarely getting changes (which might be ok as it is just for
legacy use) but as it wasn't built for 2 years could you please test and
report back if it still builds fine today? Also the linked "recent
build" was from 2 years ago. Everyone would hate to fix an issue to then
be stopped by a rather hard unexpected FTBFS.
- Please add (as you suggested) the demo as self test at autopkgtest time
and more if you find more candidates for testing it
Recommended TODOs:
- add d/watch file. I understand that the Debian maintainer doesn't need one
as they unite Debian and Upstream maintainer. But as suggested in the bug
plenty of tools and checks use it. At least you might ask again as there
isn't a real burden having one right?
- Build warning like "Wunused-result", I wonder couldn't this be using
Werror to generally catch more issues early on (and fix this simple case).
Maybe give it a shot and propose it to Debian?
[Duplication]
There is no other package in main providing the same functionality.
[Dependencies]
OK:
- no other Dependencies to MIR due to this
Although it was confusing first as there is a dependency to libio-compress-perl
which is in universe
libio-
But a more detailed check revealed that it is also provided by perl itself
and therefore working fine. I hope that is working in the component mismatch
check as well.
- no -dev/-debug/-doc packages that need exclusion
There is one, but depedencies will not cause a mismatch
- No dependencies in main that are only superficially tested requiring
more tests now.
Problems: None
[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main
Problems: None
[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
Problems:
- does not parse data formats (jigdo files which can be from external)
- can be used to create images which are then booted (max privilege level)
=> I think to stay on the save side, this should get a security revieww
[Common blockers]
OK:
- does not FTBFS currently
- no special HW required
- no new python2 dependency
Problems:
- does not have a test suite that runs at bu...