Re: Anybody volunteering to try to save falcon in Debian (Was: Bug#936503: falcon: Python2 removal in sid/bullseye)
Control: tags -1 upstream Control: forwarded -1 https://github.com/PacificBiosciences/FALCON_unzip/issues/160 Antoni, thanks for opening the issue, Andreas. -- http://fam-tille.de
Re: ksw2 library - nobody else at it, right?
Hi again, anybody up for contacting upstream as a first step? Kind regards Andreas. On Tue, Jun 09, 2020 at 05:28:28PM +0200, Andreas Tille wrote: > Hi, > > is anybody up for this challenge? This is needed for the minimap2 > Python module which we need for other packages. > > Kind regards > > Andreas. > > On Fri, May 15, 2020 at 02:30:02PM +0200, Andreas Tille wrote: > > Hi Steffen, > > > > On Fri, May 15, 2020 at 02:39:51AM +0200, Steffen Möller wrote: > > > I am happy that you asked - it is here > > > https://salsa.debian.org/med-team/ksw2 > > > > > > Sadly not a problem of that library which features the same files that > > > are also distributed with minimap2, just as an older version in the > > > separate ksw2 repository if I am not erroneous. > > > > Yes, file ksw2_exts2_sse.c seems to be older than in the code copy in > > minimap2. > > > > > We need to find the > > > problem within the minimap2 package, I am afraid. Was looking for a > > > while now - thought multiple times that I had it - but ... sigh. > > > > > > That ksw2 library needs some love by upstream and I suggest to avoid > > > packaging it for now. Also, it does not ship with a license and comes > > > with the sources of a journal publication - er - have a look. > > > > Besides that I agree that it should be sorted out with upstream I > > think the proper action would be: > > > > > > 1. Sort out the code update with upstream > > 2. Ask upstream for a proper release > > 3. Fix the build system I've invented to get a proper library > > > > Regarding the last item: I have added extremely rough automake stuff to > > the packaging. The idea was that I want a proper library with static and > > dynamic library. However, my automake skills are limited. Here are the > > flaws: > > > > 1. Proper check for zlib is needed (see the dirty hack in d/rules) > > 2. There is no propagation of HAVE_KALLOC definition (no idea why) > > 3. Check and use parasail > > 4. May be package gaba (whatever this might be and check and link > > against this) > > > > Finally I took over the simde patch from minimap2. Unfortunately I have > > no idea how to add this to the linker. This has also be done inside > > my weak attempt of automake. (If you comment the simde patch the package > > at least builds.) > > > > Kind regards > > > > Andreas. > > > > -- > > http://fam-tille.de > > > > > > -- > http://fam-tille.de > > -- http://fam-tille.de
Re: [covid-19] Help for ocaml package needed
Hi again, I've added Pierre Boutillier to CC since he once had made some progress[3] with this package. What I've done is the following: 1. Asked ftpmaster for fastprocessing of mcl to enable a smoother access to the ocaml bindings of mcl 2. Tried to build pplacer with a local copy of libmcl-ocaml-dev which ended up in ... /usr/bin/ocamlmklib.opt -o pam_src/pplacer_pam pam_src/pam.o pam_src/caml_pam.o /usr/bin/ocamlmklib.opt -o pplacer_src/pplacercside pplacer_src/linear_c.o pplacer_src/unix_support.o ocamlfind ocamldep -package batteries -package csv -package xmlm -package gsl -package sqlite3 -package zip -package mcl -modules pplacer_src/rppr.ml > pplacer_src/rppr.ml.depends + ocamlfind ocamldep -package batteries -package csv -package xmlm -package gsl -package sqlite3 -package zip -package mcl -modules pplacer_src/rppr.ml > pplacer_src/rppr.ml.depends ocamlfind: Package `mcl' not found Command exited with code 2. I have not checked the tutorials linked below. Ralf, I've added you as developer for mcl and pplacer in salsa - hope this will enable you to push changes. Anybody else is kindly invited to ask for push permissions. Kind regards Andreas. [3] https://lists.debian.org/debian-ocaml-maint/2020/05/msg00102.html On Sun, Jun 14, 2020 at 05:13:13PM +0100, Shayan Doust wrote: > Hello Ralf et al., > > Apologies for the consecutive email. Kindly CC'ing to the mailing lists > just in case someone has an idea as there are no sensitive info within > the emails. > > I was just experimenting with this tutorial[1] on pplacer[2] and I've > still hit no luck. The errors remain persistent as denoted below. > > I am sure the mcl library is compiled properly. > > $ocamlobjinfo /usr/lib/ocaml/mcl.cma > File /usr/lib/ocaml/mcl.cma > Force custom: no > Extra C object files: -lmcl_stubs > Extra C options: > Extra dynamically-loaded libraries: -lmcl_stubs > Unit name: Mcl > Interfaces imported: > ad45f251bbf98d3a0bf3b883546ecfc8Stdlib > 7fab99051af85dcaec18ca28f9f431c7Mcl > a2b1a9d869fd05813beb35645bd9cd94CamlinternalFormatBasics > Required globals: > Uses unsafe features: YES > Primitives declared in this module: > caml_mcl > Force link: no > > > If anyone has got an idea with a possible solution, feel free to contribute. > > Kind regards, > Shayan Doust > > [1]: > https://www.mancoosi.org/~abate/ocamlbuild-stubs-and-dynamic-libraries.html > [2]: https://salsa.debian.org/med-team/pplacer > > On 13/06/2020 20:54, Shayan Doust wrote: > > Hello Ralf, > > > > Thanks for the patch, I've merged it. > > > > Running make after the usual build package procedures, we now see actual > > ld errors (undefined reference) with regards to the mcl stubs: > > > > ``` > > ... > > /usr/bin/ld: /usr/lib/ocaml/libunix.a(getproto.o): in function > > `unix_getprotobynumber': > > (.text+0xe8): warning: Using 'getprotobynumber' in statically linked > > applications requires at runtime the shared libraries from the glibc > > version used for linking > > /usr/bin/ld: /usr/lib/ocaml/libunix.a(getproto.o): in function > > `unix_getprotobyname': > > (.text+0xc1): warning: Using 'getprotobyname' in statically linked > > applications requires at runtime the shared libraries from the glibc > > version used for linking > > /usr/bin/ld: /usr/lib/ocaml/libunix.a(getserv.o): in function > > `unix_getservbyname': > > (.text+0x109): warning: Using 'getservbyname' in statically linked > > applications requires at runtime the shared libraries from the glibc > > version used for linking > > /usr/bin/ld: /usr/lib/ocaml/libunix.a(getserv.o): in function > > `unix_getservbyport': > > (.text+0x159): warning: Using 'getservbyport' in statically linked > > applications requires at runtime the shared libraries from the glibc > > version used for linking > > /usr/bin/ld: /usr/lib/ocaml/libmcl_stubs.a(matrix.o): in function > > `mclxMapTest': > > (.text+0x71c): undefined reference to `mclgUnionv' > > /usr/bin/ld: /usr/lib/ocaml/libmcl_stubs.a(matrix.o): in function > > `mclxScrub': > > (.text+0x43d6): undefined reference to `mclgUnionv' > > /usr/bin/ld: /usr/lib/ocaml/libmcl_stubs.a(matrix.o): in function > > `mclxFold': > > (.text+0x5209): undefined reference to `mclgUnionv' > > /usr/bin/ld: /usr/lib/ocaml/libmcl_stubs.a(shadow.o): in function > > `mcl_density_adjust': > > (.text+0xce4): undefined reference to `mclgEdgeIterInit' > > /usr/bin/ld: (.text+0xeca): undefined reference to `mclgEdgeInc' > > /usr/bin/ld: /usr/lib/ocaml/libmcl_stubs.a(transform.o): in function > > `mclgTFgraph': > > (.text+0x13c6): undefined reference to `mclgKNNdispatch' > > /usr/bin/ld: (.text+0x143f): undefined reference to `mclgKNNdispatch' > > /usr/bin/ld: (.text+0x14b8): undefined reference to `mclgKNNdispatch' > > /usr/bin/ld: /usr/lib/ocaml/libmcl_stubs.a(cat.o): in function > > `clm_split_overlap': > > (.text+0x233d): undefined reference to `mclgUnionv' > > /usr/bin/ld: /usr/lib/
Re: PhyML error - does that ring any bell? Re: RFS: python-biopython
On 2020-06-12 20:40, Steffen Möller wrote: > I found this > > Bio.PDB.mmtf docstring test ... skipped, missing Python dependency > Bio.PDB.mmtf.DefaultParser docstring test ... skipped, missing Python > dependency > Bio.PDB.mmtf.mmtfio docstring test ... skipped, missing Python dependency > > to suggest packaging https://github.com/rcsb/mmtf-python - sigh. Any takers? > Would be quite a fit for next week's hackathon, I presume. FYI, mmtf-python was accepted to unstable today. Best wishes, Andrius
[RFS] readucks
Hi, I've packaged a NEW module: readucks - a Nanopore read de-multiplexer. It builds in a clean chroot with passing tests. I've pushed my changes to team-repo[1]. This needs review and sponsorship. [1]: https://salsa.debian.org/med-team/readucks Thanks and regards Nilesh
Re: [RFS] readucks
Hi Nilesh, Uploaded to new and added to the new request for ftpmaster. Thanks for your work on this Andreas. On Mon, Jun 15, 2020 at 08:02:21PM +0530, Nilesh Patra wrote: > Hi, > I've packaged a NEW module: readucks - a Nanopore read de-multiplexer. > It builds in a clean chroot with passing tests. > I've pushed my changes to team-repo[1]. > This needs review and sponsorship. > > [1]: https://salsa.debian.org/med-team/readucks > > Thanks and regards > Nilesh -- http://fam-tille.de
Re: [RFS] readucks
On Mon, 15 Jun 2020, 22:30 Andreas Tille, wrote: > Hi Nilesh, > > Uploaded to new and added to the new request for ftpmaster. Thanks a lot! :-) > >
