hi harish, > I have added autopkgtest coverage for the dicomscope package > and pushed the work to Salsa[0]. The earlier test issue and > warning are resolved. Kindly review it and let me know if any > adjustments are needed.
> [0] > :https://salsa.debian.org/med-team/dicomscope/-/tree/master/debian/tests?ref_type=heads > Thanks for your investigations in getting better autopkgtest coverage for Debian Med packages! I looked up your changes, plus your question from the Matrix channel: >> Should I ignore this type of warning that occurs while >> testing packages ,even after the tests pass? >> tmp/autopkgtest.Hb1m12/build.YWw/real-tree/debian/tests/run-unit-test: line >> 25: kill: (95245) - No such process I see the test is derived from similar autopkgtests relying on starting graphical applications within an Xvfb X server, like can be seen in edfbrowser[1]. To me, the intent of such test is to make sure that the graphical application is capable of idling without immediate crash. Therefore, having lost the process before the kill command is invoked may be symptomatic of the graphical application having crashed early and should be investigated. That said, the evaluation of $program_pids does capture a pid (95245), which means there is something running few milliseconds earlier, or the pid is improperly captured. [1]: https://salsa.debian.org/med-team/edfbrowser/-/raw/master/debian/tests/run-unit-test?ref_type=heads I have run the autopkgtest with a full `ps aux` output and a `set -x` invocation, resulting in an output like: + ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND […] unshare 20 0.0 0.0 4592 3368 ? S 18:28 0:00 /bin/bash /tmp/autopkgtest.fKYQHc/build.iHv/src/debian/tests/run-unit-test unshare 21 0.0 0.0 2688 1884 ? S 18:28 0:00 /bin/sh /usr/bin/xvfb-run --auto-servernum /usr/bin/dicomscope /usr/share/dicomscope/reports/reportsi.dcm unshare 32 0.2 0.0 28708 22076 ? S 18:28 0:00 Xvfb :99 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.tbuoOC/Xauthority unshare 35 10.7 0.0 21074700 120684 ? Sl 18:28 0:03 java -Xms128M -Xmx16384m -jar /usr/share/java/DICOMscope.jar /usr/share/dicomscope/reports/reportsi.dcm unshare 79 0.0 0.0 6792 3976 ? R 18:29 0:00 ps aux ++ ps aux ++ awk '/^unshare.*dicomscope/ {print $2}' ++ xargs + local 'program_pids=21 35 82' ++ awk '-vORS= ' '/^unshare.*[X]vfb/ {print $2}' ++ ps aux ++ xargs + local xvfb_pids=32 + '[' -n '21 35 82' ']' + kill 21 35 82 /tmp/autopkgtest.fKYQHc/build.iHv/src/debian/tests/run-unit-test: line 27: kill: (82) - No such process My impression is that the $program_pids captures too many pids and you probably want to make the awk invocation in the pipeline to capture more precisely the java DICOMscope.jar invocation. $xvfb_pids does not have this problem. Maybe something like that will do? local program_pids="$( ps aux \ | awk "/^$USER"'.* java .*DICOMscope.jar/ {print $2}' \ | xargs )" Also, please avoir `|| true` after the tests, as this would prevent catching real issues if dicomscope were to actually crash during autopkgtest. Instead, you may like to implement a meanigful error message like you may see on edfbrowser's autopkgtest. This will facilitate the reading and diagnostic of future autopkgtest failures by just looking at the log, instead of having to investigate things by hand from the ground up. Other than that, you may like to drop Priority: optional and Rules-Requires-Root: no, as they are now default properties. Please adjust dicomscope accordingly and ping back when you're done, so someone can review your changes. Have a nice day, :) -- .''`. Étienne Mollier <[email protected]> : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-
signature.asc
Description: PGP signature
