On 01/19/2016 04:50 PM, Ole Streicher wrote:
Hi Julian,
thank you for the bug report. To check the packaging, I run the unit
tests that come with the package (hoping that they cover a good part of
the code), and I think this is a reasonable "minimal effort" to ensure a
package is working.
no running the unittests is not minimal effort for Debian, at least not
without knowing that the unittests represent a sufficient test coverage
to guarantee some usability.
For pretty much all pipelines this is not the case. If a pipeline works
is done via esorex and test datasets. Those are not part of the source
tarballs, though the demo datasets sometimes contain a subset of the
test data.
This may not be ideal for third party redistribution, but this is also
not something upstream needs to necessarily care about.
If you want to package something it is your job to make sure it actually
works and not only that it builds. And if you don't know the package
well enough to ensure that, then don't package it. Debian is better of
without some software than with software that doesn't work.
Fwiw. the easiest way to test at least a subset of the shipped recipes
is to run the demo datasets via the upstream provided Reflex package,
ideally you just have to load the workflows and press play.
You can collect the raw esorex calls and sofs from its temporary folders
printed in the workflow.
Could I ask you to provide a minimal test case that could be used? "Any"
is a bit vague... Can you make a small test case, maybe using your demo
data set
ftp://ftp.eso.org/pub/dfs/pipelines/visir/visir-demo-reflex-0.1.tar.gz
which I could use? Just the parameters, the SOF, and the expected output
would be probably enough
cat data.sof
demoroot/img/aqu/VISIR.2015-07-21T07:09:09.829.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T07:09:56.706.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T07:10:33.128.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T07:11:17.722.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:13:14.577.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:14:48.712.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:16:14.751.fits BURST
demoroot/img/aqu/VISIR.2015-07-21T08:17:48.743.fits BURST
esorex visir_img_reduce --delete-temp=false data.sof
It will fail on all three points. When adding the config and adapting
the swarp executable name it will fail with a division by zero due to
the weight maps from swarp being wrongly just zeros (in the tmp folder
tmp_coadd_wgt_*.fits)
The recipe should work with swarp 2.19 but that version has other issues
which will cause failures with other data.
The patches to swarp in visir do not fix that, they just work around it
by reverting some stuff, so they are not much use to the package as is.
I contacted upstream about the issues when they were discovered (quite a
long time ago) though never received an answer, though I should retry
contacting if time allows for it.
