Bug#811500: cpl-plugin-visir: does not work
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.
Bug#811500: cpl-plugin-visir: does not work
Package: cpl-plugin-visir Version: 4.1.0+dfsg-1 Severity: serious the packaged recipe does not work at all for several reasons: 1. removed patched copy of swarp, visir does not work with 2.38, it needs 2.19 or the embedded convinience copy. To see run the visir_img_reduce recipe on any data and look at the garbage weight map it produces 2. does not work with packaged swarp even if that one would work because it is name SWarp not swarp as the pipeline expects. 3. the required swarp configuration visir_default.swarp is not installed. Please spend at least at least the minimal effort to see if what you are packaging even works or don't bother at all. Note that in future the embedded swarp might receive more visir specific patches. As upstream does not want this pipeline packaged in distributions I would recommend removing it completely.
Bug#811500: cpl-plugin-visir: does not work
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. 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. What concerns the removal: When I started to package the pipelines, I asked upstream (on cpl-h...@eso.org) for opinions, but I never got any response, neither positive nor negative, to the packaging. The only statement here was your mail in debian-science that these packages are "too special", but you then did not answer to my response. I also recently discussed the topic with Pascal Ballester (upstream project head), and he also never mentioned that ESO does not want to have the pipelines packaged in Debian. Therefore, I would ask you to start a discussion on the Debian-Astro mailing list about the status of the ESO pipelines, and what the reason is why ESO does not want them to be in Debian. You may also invite other people from ESO to join the discussion -- we are an open community, and therefore we should solve this problem accordingly (if it is really one for ESO). For the swarp problem: I regularly check their web page, the SVN repository and the forum to see if there are problems that should be solved for the Debian package. Up to now, there is no problem reported, except some statements by you that were not supported by a concrete example. Could I ask you to report the problem to swarp upstream so that they are aware of and that they can fix it? We all would benefit from that. Best regards Ole
