[Debian-med-packaging] Last step NanoPlot

[olivier sallou]

On Thu, 2020-04-30 at 19:59 +0200, Étienne Mollier wrote:
> Hi Andreas,
> 
> Andreas Tille, on 2020-04-30 11:30:42 +0200:
> > 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.
> 
> The last (and only) time I've been confronted to JavaScript
> based programs, I had to call a professional JavaScript
> developer for help.  I can review a thing or two, but fear I
> won't be very helpful on that side; help is welcome indeed.

I have not packaged nodejs packages, but rules are related to 
https://wiki.debian.org/Javascript/Nodejs

after quick look to code, software is a node module, and a
/usr/bin/orca shell should be linked to
*debian_module_path*/bin/orca.js

Olivier

> 
> > On Wed, Apr 29, 2020 at 11:44:42PM +0200, Étienne Mollier wrote:
> > > 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? 
> 
> I suppose both sides can be handled in parallel yes.  After
> further investigations, it looks like the problem is confirmed
> to be in the python3-statsmodels library:
> 
> 	https://github.com/statsmodels/statsmodels/issues/6679
> 
> I pointed upstream to this issue; a few more eyes on that bug
> will help hopefully.
> 
> > > 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.
> 
> I'm personally very picky about the quality of manual pages,
> I spend a lot of time reading them; but in such context it makes
> sense I guess.  I will at least make sure that Lintian has no
> reason to complain about their content.
> 
> Kind Regards,
> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438