Review for Package: src:libxcvt
[Summary]
libxcvt is a simple library (and tool) to generate xorg-server and xwayland mode
lines given the horizontal and vertical resolution and refresh rate (among other
optional paramters). It has been part of xorg-server in the past and has now
been split out as an indiviual library, to be used by xwayland as well.
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 not need a security review
List of specific binary packages to be promoted to main: libxcvt0
Specific binary packages built, but NOT to be promoted to main: xcvt,
libxcvt-dev
Notes:
This is a split out library that has been part of xorg-server before, so it
should usually not need big MIR as the code is already in main as part of
another package. But OTOH this split gives us a change to improve the current
situation of this library. You mention that inside xorg-server this code only
got 21 commits over the years and therefore does not require automated testing.
There is very little testing around this library, I know it's small and doesn't
change often, but still it could be hit by misscompilation and other things.
Is there any bigger (manual) testing story around libxcvt, that you could
outline in a comment?
Required TODOs:
#1: please add some basic autopkgtests, I recommend those two easy cases:
- linking a tiny binary agains libxcvt0 and checking for expected output,
similar to what got recently implemented in src:protobuf-c: d/t/build-test
- calling xcvt with some parameters and checking for the expected output:
$ cvt 1080 1920 75
# 1080x1920 74.98 Hz (CVT) hsync: 150.40 kHz; pclk: 225.00 MHz
Modeline "1080x1920_75.00" 225.00 1080 1176 1288 1496 1920 1923 1933 2006
-hsync +vsync
Recommended TODOs:
#2 the autopkgtests as mentioned above (in case we have a proper manual testing
story defined somewhere, that has not been mentioned in the MIR before)
[Duplication]
There is no other package in main providing the same functionality.
I found several tools doing a similar job, but not is available in main or can
be used as a library:
http://manpages.ubuntu.com/manpages/jammy/man1/videogen.1.html
http://manpages.ubuntu.com/manpages/jammy/man1/gtf.1.html (old GTF standard)
[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- 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
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 parse data formats
- 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: None
[Common blockers]
OK:
- does not FTBFS currently
- no new python2 dependency
Problems:
- does not have a test suite that runs at build time
- does not have a non-trivial test suite that runs as autopkgtest
- if a non-trivial test on this level does not make sense (the lib alone
is only doing rather simple things), is the overall solution (app+libs)
extensively covered i.e. via end to end autopkgtest ?
=> MIR does not mention a bigger testing story
[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok (if needed, e.g. non-native)
- Upstream update history is slow, but OK (not a lot of changes expected)
- Debian/Ubuntu update history is , but OK for the same reason
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list
Problems: None
[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as we can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case (not user visible)
Problems: None
** Changed in: libxcvt (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1960500
Title:
[MIR] libxcvt
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libxcvt/+bug/1960500/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
