[Debian-med-packaging] Last step NanoPlot

Andreas Tille andreas at fam-tille.de
Thu Apr 30 10:30:42 BST 2020


Hi Étienne,

On Wed, Apr 29, 2020 at 11:44:42PM +0200, Étienne Mollier wrote:
> > installation methods:
> > 
> > 	https://github.com/plotly/orca
> 
> Hi Andreas
> 
> Moving forward on this topic, during autopkgtest the orca
> executable is required to export figures as static images, but
> after visual inspection of test data, the lack of of this
> component does not impede the core usage of NanoPlot (although
> there is an export capability missing indeed, and it produces a
> lot of trace during the execution of the program).

Thank you for your investigation into this topic.  I have
injected

   https://salsa.debian.org/med-team/plotly-orca

but I need to admit that I have to admit I have no idea how to build
JavaScript packages.  Nilesh, could you lend some helping hand?
I consider the package quite interesting in any case - so why not
packaging it if its needed for full functionality of NanoPlot.
 
> After some testing, it turned out to be unrelated to:
> > The second set of errors looks like the following issue, and
> > might be data dependent, but there could be a chance it is
> > related to the error hereover:
> > 
> > 	https://github.com/wdecoster/NanoPlot/issues/177
> 
> Feeding the test with alignment_fasta.bam instead of
> alignment.bam showed that some dataset was triggering the error
> and not others indeed.  In the next version of NanoPlot, the
> upstream author removed the need to use the statsmodels python
> library, which is causing the bug, so just cherry picked that:
> 
> 	https://github.com/wdecoster/NanoPlot/commit/da185a2e9d4f494987aedeb1eb15374cdbf99d7a
> 
> As long as python3-statsmodels is *not installed* on the
> machine, it does the job.  However, if the package is pulled for
> whatever reason, then the problem comes back.  I don't know what
> the best approach would be to solve this properly, for the
> moment.

May be we gain some time to work this out with upstream when
plotly-orca is in preparation? 
 
> On a side note, I took example on what you did for python-pauvre
> in producing a manual page.  A long sequence of characters to
> describe a set ended up pulling another lintian warning, so I
> did some manual changes to relax the format of sets of options,
> and allow well formatted manual pages.  It goes a bit against
> the automation, will it do anyway ?

Yes.  It happens from time to time that manual changes are needed.  If
there are really heavy changes I sometimes keep the autogenerated and
the changes in separate manpages branch.  The idea behind it is that it
might be possible to apply those patches to newly generated manpages.
But in fact I did not really used this in practice.

Its your choice if you want to turn your manual changes into sed / awk /
perl code whatever to do it automatically.  But I do not think that
spending too much time into it.  I'm not sure how much those manpages
are *really* used by the users.  I do not know any user of our packages
*in person* who ever consulted a manpage.  May be that's just me but
I would restrict the effort here to some sensible limit.

Kind regards

      Andreas.

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list