Re: Help requested: r-bioc-rhdf5lib patches need updating for bioc-3.19 upgrade

[Michael R. Crusoe]

On 10/07/2024 15.58, Nilesh Patra wrote:

On Wed, Jul 10, 2024 at 12:14:05PM +0200, Michael R. Crusoe wrote:

I upgraded r-bioc-rhdf5lib from 1.24.2 to 1.26.0 in the "debian/experimental" 
branch on salsa.

https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib/-/tree/debian/experimental?ref_type=heads

However when I try to build other packages using the resulting "r-bioc-rhd5lib" 
binary package, I get the following build errors:

# From r-bioc-alabaster.base 
https://salsa.debian.org/r-pkg-team/r-bioc-alabaster.base
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o alabaster.base.so 
RcppExports.o check_csv.o check_list.o choose_numeric_missing_placeholder.o 
is_rfc3339.o load_csv.o load_list.o validate.o 
/usr/lib/R/site-library/Rhdf5lib/libs/libhdf5_cpp.a 
/usr/lib/R/site-library/Rhdf5lib/libs/libhdf5.a -lcrypto -lcurl -lpthread -lsz 
-lz -ldl -lm -lz -L/usr/lib/R/lib -lR
/usr/bin/ld: cannot find /usr/lib/R/site-library/Rhdf5lib/libs/libhdf5_cpp.a: 
No such file or directory
/usr/bin/ld: cannot find /usr/lib/R/site-library/Rhdf5lib/libs/libhdf5.a: No 
such file or directory
collect2: error: ld returned 1 exit status

Can I get some help with this?

Please push any fixes directly to the "debian/experimental" branch on Salsa and 
let me know, thank you!


I don't have the time to write a patch/hack around this right now, but I
understood what the issue is and it should be relatively easy to fix.

alabaster.base used Rhdf5lib::pkgconfig("PKG_CXX_LIBS") to get the linker flags
for Rhdf5 lib as can be see here[1]

This has been set to an incorrect value as per the debian installed package[2].
It points to a path that does not exist since we are using hdf5 packaged in
debian instead of building and using embedded copies.

Patching the code to point to the correct path should fix the issue for you.


Thank you, Nilesh, that got me further!

With 
https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib/-/commit/1ce8837d34d244f60b4a26469ba378babcb0
I get

g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o alabaster.base.so 
RcppExports.o check_csv.o check_list.o choose_numeric_missing_placeholder.o 
is_rfc3339.o load_csv.o load_list.o validate.o 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.a 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.a -lcrypto -lcurl -lpthread -lsz 
-lz -ldl -lm -lz -L/usr/lib/R/lib -lR
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.a(H5Exception.o): warning: 
relocation against `_ZTVN2H518DataTypeIExceptionE' in read-only section `.text'
/usr/bin/ld: 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.a(H5Exception.o): relocation 
R_X86_64_PC32 against symbol `_ZTVN2H59ExceptionE' can not be used when making 
a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[1]: *** [/usr/share/R/share/make/shlib.mk:10: alabaster.base.so] Error 1




For building r-bioc-alabaster.base, feel free to use the bioc-3.19 test 
packages I've been making: https://people.debian.org/~crusoe/bioc/

--
Michael R. Crusoe


[1]: 
https://salsa.debian.org/r-pkg-team/r-bioc-alabaster.base/-/blob/master/src/Makevars?ref_type=heads#L1
[2]: 
https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib/-/blob/debian/experimental/R/zzz.R?ref_type=heads#L73

Best,
Nilesh


OpenPGP_signature.asc
Description: OpenPGP digital signature

Help requested: r-bioc-rhdf5lib patches need updating for bioc-3.19 upgrade

[Michael R. Crusoe]

[whoops, forgot to include the debian-r list]

Hello teams,

I upgraded r-bioc-rhdf5lib from 1.24.2 to 1.26.0 in the "debian/experimental" 
branch on salsa.

https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib/-/tree/debian/experimental?ref_type=heads

However when I try to build other packages using the resulting "r-bioc-rhd5lib" 
binary package, I get the following build errors:

# From r-bioc-alabaster.base 
https://salsa.debian.org/r-pkg-team/r-bioc-alabaster.base
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o alabaster.base.so 
RcppExports.o check_csv.o check_list.o choose_numeric_missing_placeholder.o 
is_rfc3339.o load_csv.o load_list.o validate.o 
/usr/lib/R/site-library/Rhdf5lib/libs/libhdf5_cpp.a 
/usr/lib/R/site-library/Rhdf5lib/libs/libhdf5.a -lcrypto -lcurl -lpthread -lsz 
-lz -ldl -lm -lz -L/usr/lib/R/lib -lR
/usr/bin/ld: cannot find /usr/lib/R/site-library/Rhdf5lib/libs/libhdf5_cpp.a: 
No such file or directory
/usr/bin/ld: cannot find /usr/lib/R/site-library/Rhdf5lib/libs/libhdf5.a: No 
such file or directory
collect2: error: ld returned 1 exit status

Can I get some help with this?

Please push any fixes directly to the "debian/experimental" branch on Salsa and 
let me know, thank you!

For building r-bioc-alabaster.base, feel free to use the bioc-3.19 test 
packages I've been making: https://people.debian.org/~crusoe/bioc/

--
Michael R. Crusoe


OpenPGP_signature.asc
Description: OpenPGP digital signature

Help requested: r-bioc-rhdf5lib patches need updating for bioc-3.19 upgrade

[Michael R. Crusoe]

Hello team,

I upgraded r-bioc-rhdf5lib from 1.24.2 to 1.26.0 in the "debian/experimental" 
branch on salsa.

https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5lib/-/tree/debian/experimental?ref_type=heads

However when I try to build other packages using the resulting "r-bioc-rhd5lib" 
binary package, I get the following build errors:

# From r-bioc-alabaster.base 
https://salsa.debian.org/r-pkg-team/r-bioc-alabaster.base
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o alabaster.base.so 
RcppExports.o check_csv.o check_list.o choose_numeric_missing_placeholder.o 
is_rfc3339.o load_csv.o load_list.o validate.o 
/usr/lib/R/site-library/Rhdf5lib/libs/libhdf5_cpp.a 
/usr/lib/R/site-library/Rhdf5lib/libs/libhdf5.a -lcrypto -lcurl -lpthread -lsz 
-lz -ldl -lm -lz -L/usr/lib/R/lib -lR
/usr/bin/ld: cannot find /usr/lib/R/site-library/Rhdf5lib/libs/libhdf5_cpp.a: 
No such file or directory
/usr/bin/ld: cannot find /usr/lib/R/site-library/Rhdf5lib/libs/libhdf5.a: No 
such file or directory
collect2: error: ld returned 1 exit status

Can I get some help with this?

Please push any fixes directly to the "debian/experimental" branch on Salsa and 
let me know, thank you!

For building r-bioc-alabaster.base, feel free to use the bioc-3.19 test 
packages I've been making: https://people.debian.org/~crusoe/bioc/

--
Michael R. Crusoe


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074302: unifrac: autopkgtest failure with python3-skbio 0.6.1-1 from experimental

[Michael R. Crusoe]

Source: unifrac
Version: 1.3-2
Severity: important
X-Debbugs-Cc: debian-med@lists.debian.org, cru...@debian.org

Hello team,

While upgrading the qiime/q2-* packages (specifically q2-diversity-lib), I 
noticed that there is a new version of python-skbio, 0.6; Testing that in 
experimental show that unifrac is the only package not compatible with the new 
version of python-skbio.

https://ci.debian.net/packages/u/unifrac/unstable/amd64/48132933/#L688

There are 4 errors, all with the same message:

> ValueError: ``taxa`` is required for phylogenetic diversity metrics.

So we need a patch to add in the "taxa" keyword to the calls to 
skbio.diversity.beta_diversity in unifrac's tests.

Thanks!



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: If someone wants to join (Was: Any input for some talk about usage of Debian in HPC)

[Michael R. Crusoe]

The call is today (2024-06-20) at 17:00 UTC (19:00 CEST, for example)

Timezone converter: 
https://time.is/1700_20_June_2024_in_UTC?Debian_GNU/Linux_for_Scientific_Research

Thank you Andreas for presenting!

On 20/06/2024 13.15, Andreas Tille wrote:

Hi,

feel free to pick the relevant data from this document


https://docs.google.com/document/d/1rcvtsD5QVmmLxSDNxm6FBrWdI0GjXSZtfJ-vkGfKPO4

if you want to join.  Thanks to all who provided input which
was really valuable for me.

Kind regards
 Andreas.


Am Sun, May 19, 2024 at 01:12:40PM +0200 schrieb Andreas Tille:

Hi,

I have an invitation to have some talk with the title

Debian GNU/Linux for Scientific Research

Abstract:

Over the past decade, Enterprise Linux has dominated large-scale
research computing infrastructure. However, recent developments have
sparked increased interest in community-led alternatives. Debian
GNU/Linux, a long-standing choice among researchers for supporting
scientific work, is experiencing a renewed interest for High-Throughput
Computing (HTC) and High-Performance Computing (HPC) applications.  This
presentation will provide an overview of how Debian is being utilized to
support scientific research and will include a case study showcasing the
migration of HTC operations from Enterprise Linux 7 (EL7) to Debian.

While I could talk about Debian Science and Debian Med in general it
would be cool to reference to some real life examples where Debian is
used in Science and what might be the reason to use Debian.

I personally would like to stress the "we package what we use" aspect
and the "we mentor upstream to merge competence of the program with
packaging skills" idea.  Any input would be welcome to cover more ideas.

Kind regards
 Andreas.

--
https://fam-tille.de






OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 02/04/2024 07.54, Andreas Tille wrote:

Hi,

Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss:



New packages that aren't "Architecture: all": 1. Add
"architecture-is-64-bit" and "architecture-is-little-endian" to the
"Build-Depends" list in "debian/control".


Nice, didn't know about these virtual packages before. Makes sense for
new packages -- would this result in an equivalent effect as restricting
the "Architecture" list in all binary packages?


If we agree about the policy to restrict new packages to the said
architectures I'd recommend adding this to our package template[1].


Draft MR is at 
https://salsa.debian.org/med-team/community/package_template/-/merge_requests/2 
; to be merged after the policy is accepted ; comments appreciated there


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 30/03/2024 01.00, Diane Trout wrote:

On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote:


Like all policy proposals, this is not meant to be a hard rule for
all time. We can and should revisit the issue later!


What do you think of the policy being instead of "-med team packages
MUST support all current Debian architectures", "-med team packages
(CAN or SHOULD) try to support all current Debian architectures."


Thank you for introducing this phrasing. I don't think there is a current 
Debian-Med team policy on architecture support. And from what I can see, there 
is nothing in the policy of Debian itself that packages SHOULD or MUST support 
all official Debian architectures.

I would suggest "-med team packages SHOULD try to support all 64-bit little-endian 
architectures. Team packages are allowed to exclude 32-bit and/or big-endian 
architectures without justification."

More details in the MR that I am preparing.



Many packages do work fine, but some make no sense without being able
to access much more than 4G of memory or have picky CPU architecture
dependencies.

I don't think the team should automatically turn off all more obscure
architectures, but it seems very reasonable to be quite willing disable
builds for things that cause problems outside of x86_64/arm64.


And riscv64, which I predict will be the next big architecture for scientific computing 
in a few years. Which is why I'm proposing that we cast a wider net using "64-bit 
and little-endian".



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 29/03/2024 19.44, Steven Robbins wrote:

On Thursday, March 28, 2024 8:51:01 A.M. CDT Michael R. Crusoe wrote:


Therefore I personally conclude that:
Support Debian-Med packages for 32-bit and/or big-endian architectures is
not a good use of our limited resources.



I am left with a question whether that is what you are proposing, or whether
you mean to preemptively restrict the architectures even when they are not
troublesome?  I would support the former but the latter position seems
unwarranted to me.


At least the first, but preferably also the second. Why waste the computing 
resources / climate damage / maintainer time when that does not benefit our 
users?

Yes, it is true that compiling for 32-bit and/or big-endian architectures 
occasionally highlights coding errors that were otherwise hidden and could 
cause problems later. But I'm proposing that it isn't worth it, and that if a 
member of the team wishes to restrict the architectures built, they should do 
so.




Like all policy proposals, this is not meant to be a hard rule for all time.
We can and should revisit the issue later!


Absolutely.  The working set of machines does change over time as you mention
yourself.  I remember doing neuroinformatics research coding on SGI IRIX
machines -- which will surely date me.  :-)


:-D


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 29/03/2024 07.21, Andreas Tille wrote:

Hi,

I'm personally fine with Michaels suggestion in general.


:+1:



Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra:



On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe"  wrote:

There are also packages inside debian med umbrella which are not necessarily 
related to medicine or bioinformatics. These include some general purpose 
python packages, some C/C++ libraries et. al. There are packages that 
reverse-depend on the same. I don't think it's a good idea to remove 32 bit 
support in *all* the packages that are under our umbrella, but probably only 
the ones that are end-user applications.


When reading Michaels proposal I also was thinking about generic
libraries we are packaging as pre-dependencies for our end-user
applications.  I'd be fine with mentioning those as exceptions from what
I consider perfectly sensible for the packages that are really targeting
at our user base.


Ack.


It may be good to move packages not related to medicine to different teams over 
time but some of them actually don't fit into any availability team as per my 
understanding and may have to be moved to debian/ namespace.

What do you think?


I'm not convinced that moving package out of our focus is a good idea.
When we did so in the past these packages somehow went out of our focus
and we hear back from them only by testing removal warnings.  I have no
problem with moving packages if there is some request from somewhere
else and thus there is some convincing interest that the package is
maintained properly.  But I would not browse the packages maintained by
our team, check which might be of general interest, seek in what other
team it might be appropriate, become a member of that team and maybe
learn that this team has quite a different policy than we have (as I
learned in DPT recently).

In short:  Keep on maintaining what we have and apply common sense

where to restrict the architectures sensibly.

BTW. actively restricting the architectures for existing packages just
creates work for no use.  I think we should simply focus on new packages
and those that create some troublesome bug reports that we can deal
with by removing unused architectures.


Sure, I'll adjust the proposal based upon this feedback and similar comments 
from others.


One other hint: I consider it a good idea to forward our proposed change
of policy to debian-devel@l.d.o (once we agreed upon the change - maybe
in some MR) for two reasons:

   1. There might be a chance we have overlooked something.
   2. There might be other teams that are interested in a similar
  change of policy.


This is reasonable, sure.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 29/03/2024 05.43, Nilesh Patra wrote:



On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe"  wrote:

Alas this is an involved process. If we have to do it a lot, it would be nice 
if someone writes a tool to automate any aspect of the above!

---

Fweh, that's a long email. Please do share your feedback here


There are also packages inside debian med umbrella which are not necessarily 
related to medicine or bioinformatics. These include some general purpose 
python packages, some C/C++ libraries et. al. There are packages that 
reverse-depend on the same. I don't think it's a good idea to remove 32 bit 
support in *all* the packages that are under our umbrella, but probably only 
the ones that are end-user applications.


I hear you, thanks.


It may be good to move packages not related to medicine to different teams over 
time but some of them actually don't fit into any availability team as per my 
understanding and may have to be moved to debian/ namespace.


Sure, no reason to abandon a package we care about if there isn't a welcoming 
team to receive it.



What do you think?


and on the Debian-Med Matrix channel for instant discussions: 
https://app.element.io/#/room/#debian-med:matrix.org


I'll be happy to open another thread about it, but while we are at it, do you 
think it makes sense to make this as our official communication media?

Most of us don't hang out on #debian-med IRC and it would be a little 
misleading for someone wanting to contact us.

Should we just close the IRC channel and endorse the matrix channel as the 
official one?


The current Debian-Med policy doesn't even mention the IRC channel. I agree, 
lets make the matrix room official! → 
https://salsa.debian.org/med-team/policy/-/merge_requests/2



Thanks,
Nilesh


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 01/04/2024 21.12, Sascha Steinbiss wrote:

Hi all,

first of all thanks Michael for this idea and also for the elaborate
proposal email that outlines the intended way to go quite well.


Thanks!



[...]

Support Debian-Med packages for 32-bit and/or big-endian architectures is not a 
good use of our limited resources.


Agreed.

 

If there is agreement with this, then I would like an amend the Debain-Med team 
policy to make it clear that we, as a community of package maintainers and 
users, are okay with removing support for 32-bit and/or big-endian systems 
without discussion.


I'd probably not go as far as to eagerly _remove_ all support for 32-bit
as in RM'ing existing packages that still build and work fine. I'd
rather like to see such a policy change to illustrate a common position
that we'd rather disable an architecture and RM its binaries rather than
fix a non-trivial issue on that platform, which might block a testing
transition or cause some other roadblocks for the archs we actually care
about.
I know that many others in Debian care about their specific niche
architecture and would be offended at some random maintainer just
dismissing their subjectively reasonable request to fix things. Making
it known beforehand where Debian Med puts its focus would help in making
such situations feel less personal.


How to make implement this policy with the tools available to us in 2024.

New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and 
"architecture-is-little-endian" to the "Build-Depends" list in "debian/control".


Nice, didn't know about these virtual packages before. Makes sense for
new packages -- would this result in an equivalent effect as restricting
the "Architecture" list in all binary packages?


Yes, but with the benefit that we don't have to add in new 64-bit/little-endian 
archs that appear, like that which has been done for riscv64 and loong64 quite 
often these last few years.




Removing architectures in existing packages:

[...]

This approach looks good. As I said, I'd rather only go this way if the
maintainer in question notices that there is a need to do so.

I agree that if it turns out that for a package to be removed there are
reverse dependencies outside of Debian Med's maintainership which would
be affected, we would need to coordinate with the maintainers of these
reverse dependencies. My gut feeling says these cases will be
exceptional though.

I think it could also make sense to think of what to do for other
architectures that are not yet covered in Michael's proposal, such as
(subjectively) obscure archs that still are considered official release
architectures (riscv64, mips64el, ...) or all the non-official architectures 
(alpha, hurd-*, m68k, ...)?


For non-official archs within the context of Debian-Med, I just ignore them 
unless a simple patch is provided in BTS. They don't block migration to 
testing, so I don't think about them.



Cheers
Sascha


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

On 28/03/2024 14.51, Michael R. Crusoe wrote:

Dear colleagues and users,

[snip]

Fweh, that's a long email. Please do share your feedback here and on the 
Debian-Med Matrix channel for instant discussions: 
https://app.element.io/#/room/#debian-med:matrix.org


Thank you all for the thoughtful and helpful replies!

I will reply to some of your messages now and later I will open a merge request 
to the policy document later with specific text taking the feedback into 
account. I'll post the link here and we can continue to discuss the details.

--
Michael R. Crusoe


OpenPGP_signature.asc
Description: OpenPGP digital signature

Debian-Med policy proposal: 64-bit & little-endian only* for new packages

[Michael R. Crusoe]

the above!

---

Fweh, that's a long email. Please do share your feedback here and on the 
Debian-Med Matrix channel for instant discussions: 
https://app.element.io/#/room/#debian-med:matrix.org

Cheers from Berlin,

--
Michael R. Crusoe


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: regarding filtering architectures

[Michael R. Crusoe]

This is a great tip, thanks!

I've pushed commits that use the provisions from the
architecture-properties package to clean up d/control for the following
packages:

abyss
bazel-bootstrap
bowtie
bowtie2
canu
diamond-aligner
gmap
jellyfish
kallisto
mmseqs2
pbcopper
python-skbio
subread

On Sun, Mar 3, 2024 at 9:49 PM Andreas Tille  wrote:

> Hi,
>
> Paul has sent me a valuable hint.  I totally missed this information
> but will try to fix all our packages that are only available for 64 bit
> architectures according to this.  I'm just bouncing this information
> to the list in case I'm not the only one who missed this simple option
> to exclude 32bit.
>
> Kind regards
> Andreas.
>
> Am Sun, Mar 03, 2024 at 07:28:57AM +0100 schrieb Paul Gevers:
> > Hi Andreas,
> >
> > I just spotted two of you packages [1] where you stopped supporting 32
> bits.
> > I'm not going to judge on that (I don't even look at the reason), but
> > instead of hard-coding the list of architectures, could you use a
> > Build-Dependens on architecture-is-64-bit (from
> > https://packages.debian.org/unstable/architecture-properties).
> >
> > Rationale: https://lists.debian.org/debian-devel/2022/09/msg00105.html
> >
> > Paul
> >
> > [1]
> https://tracker.debian.org/media/packages/e/emboss/control-6.6.0dfsg-13
> > [2]
> https://tracker.debian.org/media/packages/r/r-bioc-rhtslib/control-2.4.1dfsg-2
> >
> > Paul
>
>
>
>
> --
> http://fam-tille.de
>
>

Re: autopkgtest-pkg-pybuild (Was: [Git][med-team/python-bx][master] 2 commits: d/control: now run the autopkgtesting using pybuild-autopkgtest.)]

[Michael R. Crusoe]

I find autopkgtest-pkg-pybuild to often be superior, but it can't be
enabled automatically like the -python version as it won't work
automatically nearly as often without additional configuration like the
"-python" version.


--
Michael R. Crusoe ; he/him

On Tue 27 Feb 2024, 20:20 Andreas Tille,  wrote:

> Hi Michael,
>
> I just learned about
>
>Testsuite: autopkgtest-pkg-pybuild
>
> in your commit.  Could you please (on the mailing list) be more verbose
> about this?  Routine-update is adding autopkgtest-pkg-python by default?
> Is this an outdated strategy we should change?
>
> Kind regards
> Andreas.
>
> Am Tue, Feb 27, 2024 at 06:34:24PM + schrieb Michael R. Crusoe
> (@crusoe):
> >
> >
> > Michael R. Crusoe pushed to branch master at Debian Med / python-bx
> >
> >
> > Commits:
> > 4438273f by Michael R. Crusoe at 2024-02-27T18:57:39+01:00
> > d/control: now run the autopkgtesting using pybuild-autopkgtest.
> >
> > - - - - -
> > 5e79d014 by Michael R. Crusoe at 2024-02-27T18:57:39+01:00
> > routine-update: Ready to upload to unstable
> >
> > - - - - -
> >
> >
> > 5 changed files:
> >
> > - debian/changelog
> > - debian/control
> > - + debian/patches/post-install-testing
> > - debian/patches/series
> > - debian/rules
> >
> >
> > Changes:
> >
> > =
> > debian/changelog
> > =
> > @@ -1,12 +1,13 @@
> > -python-bx (0.11.0-2) UNRELEASED; urgency=medium
> > +python-bx (0.11.0-2) unstable; urgency=medium
> >
> >* d/rules: use dh_numpy3 to inject a dependency on the appropriate
> >  numpy ABI.
> >* mark the fix_BIN_OFFSETS_MAX patch as being forwarded upstream.
> >    * d/control: switch to pyproject based building.
> >* d/patches/pytest8: add pytest 8.x compatability.
> > +  * d/control: use pybuild-autopkgtest to provide non-superficial
> autopkgtests
> >
> > - -- Michael R. Crusoe   Tue, 27 Feb 2024 16:05:18
> +0100
> > + -- Michael R. Crusoe   Tue, 27 Feb 2024 18:54:18
> +0100
> >
> >  python-bx (0.11.0-1) unstable; urgency=medium
> >
> >
> >
> > =
> > debian/control
> > =
> > @@ -3,7 +3,7 @@ Maintainer: Debian Med Packaging Team
>  >  Uploaders: Steffen Moeller ,
> > Michael R. Crusoe 
> >  Section: python
> > -Testsuite: autopkgtest-pkg-python
> > +Testsuite: autopkgtest-pkg-pybuild
> >  Priority: optional
> >  Build-Depends: debhelper-compat (= 13),
> > dh-sequence-python3,
> >
>
> --
> http://fam-tille.de
>

Re: [hamap] Changing HAMAP license to match UniProt (CC-BY-4.0)?

[Michael R. Crusoe]

This is wonderful news, thank you very much!

On Monday, September 25, 2023, Nicole Redaschi via RT 
wrote:
> Hi Michael,
>
> I got the go ahead to change the HAMAP license to CC-BY-4.0. We intend to
do
> this for the next release, which is due on Nov 8.
>
> Hope that helps!
>
> Cheers,
> Nicole
>
> ---
>   Nicole Redaschi nicole.redaschi@sib.swiss
>   SIB Swiss Institute of Bioinformatics   Tel: +41 (0)22 379 59 65
>   CMU, rue Michel Servet 1
>   1211 Geneve 4, Switzerland
>   www.sib.swiss - www.uniprot.org - www.rhea-db.org - www.expasy.org
> ---
>
>
>

Re: [Help] Could someone please have a look at gmap build failure

[Michael R. Crusoe]

Hey César,

Can you look at the build failures for non-x86?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041451

https://buildd.debian.org/status/fetch.php?pkg=gmap=arm64=2023-06-01%2Bds-1=1689254473=0

Note: /<>/build/src/gmap.nosimd does not exist.  For faster
speed, may want to compile package on an non-SIMD machine
Error: appropriate GMAP version not found

But otherwise the build suceeds

On Mon, Jul 17, 2023 at 12:57 PM César Pomar  wrote:

> Hi Andreas,
>
> It's a pleasure to be involved. If there's anything pending that I can
> assist with, please let me know.
>
> Best regards,
> César
>
> El jue, 13 jul 2023 a las 14:16, Andreas Tille ()
> escribió:
>
>> Hi César,
>>
>> Am Thu, Jul 13, 2023 at 09:49:03AM +0200 schrieb César Pomar:
>> > I can also take a look. ...
>>
>> Thanks a lot for becoming involved
>> Andreas.
>>
>> --
>> http://fam-tille.de
>>
>>

Re: [Help] One remaining build time error in toil

[Michael R. Crusoe]

I thought I patched out all the WDL tests; I suggest adding `WdlToilTest`
to the skip list.

On Thu, Jul 13, 2023 at 9:42 PM Andreas Tille  wrote:

> Hi folks,
>
> before I switch of my laptop for today I'd like to hand over some
> remaining build time error in toil:
>
> ___ WdlToilTest.test_empty_file_path
> ___
> [gw0] linux -- Python 3.11.4 /usr/bin/python3.11
> Traceback (most recent call last):
>   File "/usr/lib/python3.11/unittest/case.py", line 57, in testPartExecutor
> yield
>   File "/usr/lib/python3.11/unittest/case.py", line 623, in run
> self._callTestMethod(testMethod)
>   File "/usr/lib/python3.11/unittest/case.py", line 579, in _callTestMethod
> if method() is not None:
>
>   File
> "/builds/med-team/toil/debian/output/source_dir/src/toil/test/wdl/wdltoil_test.py",
> line 54, in test_empty_file_path
> assert b'Could not find' in stderr
>^^^
> AssertionError
>
>
> see
>
> https://salsa.debian.org/med-team/toil/-/jobs/4428408
>
>
> Any help would be welcome to enable me starting with some new tasks
> tomorrow, ;-)
>
> Kind regards
> Andreas.
>
> --
> http://fam-tille.de
>
>

Re: [Help] Could someone please have a look at gmap build failure

[Michael R. Crusoe]

Here is my fix
https://salsa.debian.org/med-team/gmap/-/commit/596beba027da3944b0f45a9ffc9e03d1d9dca5ba

On Thu, Jul 13, 2023 at 11:15 AM Michael R. Crusoe <
michael.r.cru...@gmail.com> wrote:

> Thanks César; I've done much of this already. I'll push my changes shortly
> (testing the AVX512 level now)
>
> On Thu, Jul 13, 2023 at 9:49 AM César Pomar 
> wrote:
>
>> Hi,
>>
>> I think the same way. The code has multiple levels of vector extensions:
>> SSE2, SSE3, AVX... AVX512. The code has macros to define the data types
>> according to the selected extension. It's very possible that they focused
>> on SSE3 or AVX (which are already the minimum supported by any machine) and
>> neglected to test SSE2.
>>
>> I can also take a look. Additionally, since it supports up to AVX512, it
>> would be good to create multiple binaries (as we did in VeryFastTree) with
>> different levels so that modern hardware can take advantage of them while
>> preserving compatibility.
>>
>> El jue, 13 jul 2023 a las 9:36, Michael R. Crusoe (<
>> michael.r.cru...@gmail.com>) escribió:
>>
>>> The real error is at
>>>
>>> gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2   
>>> -DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -DGSNAP=1 
>>> -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-avx2 
>>> -g -O2 -ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=. 
>>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>>> gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo 
>>> './'`intersect-uint2.c
>>> intersect-simd.c: In function 'v1':
>>> intersect-simd.c:242:8: warning: implicit declaration of function 
>>> '_mm_lddqu_si128'; did you mean '_mm_loadu_si128'? 
>>> [-Wimplicit-function-declaration]
>>>   242 |   F0 = _mm_lddqu_si128((const __m128i *)(freq));
>>>   |^~~
>>>   |_mm_loadu_si128
>>>
>>> I don't think upstream tested the SSE2 build recently; I'm looking at this 
>>> now
>>>
>>>
>>> On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille  wrote:
>>>
>>>> Hi,
>>>>
>>>> I admit I'm bad in such hardware internals that seem to break the
>>>> build of gmap:
>>>>
>>>> intersect-uint2.c:409:21: error: incompatible types when initializing
>>>> type '__m128i' using type 'int'
>>>>   409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *)
>>>> &(shuffle_mask16[r*16]));
>>>>   | ^~~~
>>>> intersect-uint2.c:427:17: error: incompatible types when assigning to
>>>> type '__m128i' from type 'int'
>>>>   427 |   v_b = _mm_lddqu_si128((const __m128i *) [i_b]);
>>>>   | ^~~
>>>>
>>>> See
>>>>https://salsa.debian.org/med-team/gmap/-/jobs/4423598
>>>> for the full build log.
>>>>
>>>> Any help would be welcome
>>>> Andreas.
>>>>
>>>> --
>>>> http://fam-tille.de
>>>>
>>>>

Re: [Help] Could someone please have a look at gmap build failure

[Michael R. Crusoe]

Thanks César; I've done much of this already. I'll push my changes shortly
(testing the AVX512 level now)

On Thu, Jul 13, 2023 at 9:49 AM César Pomar  wrote:

> Hi,
>
> I think the same way. The code has multiple levels of vector extensions:
> SSE2, SSE3, AVX... AVX512. The code has macros to define the data types
> according to the selected extension. It's very possible that they focused
> on SSE3 or AVX (which are already the minimum supported by any machine) and
> neglected to test SSE2.
>
> I can also take a look. Additionally, since it supports up to AVX512, it
> would be good to create multiple binaries (as we did in VeryFastTree) with
> different levels so that modern hardware can take advantage of them while
> preserving compatibility.
>
> El jue, 13 jul 2023 a las 9:36, Michael R. Crusoe (<
> michael.r.cru...@gmail.com>) escribió:
>
>> The real error is at
>>
>> gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2   
>> -DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -DGSNAP=1 
>> -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-avx2 
>> -g -O2 -ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>> gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo 
>> './'`intersect-uint2.c
>> intersect-simd.c: In function 'v1':
>> intersect-simd.c:242:8: warning: implicit declaration of function 
>> '_mm_lddqu_si128'; did you mean '_mm_loadu_si128'? 
>> [-Wimplicit-function-declaration]
>>   242 |   F0 = _mm_lddqu_si128((const __m128i *)(freq));
>>   |^~~
>>   |_mm_loadu_si128
>>
>> I don't think upstream tested the SSE2 build recently; I'm looking at this 
>> now
>>
>>
>> On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille  wrote:
>>
>>> Hi,
>>>
>>> I admit I'm bad in such hardware internals that seem to break the
>>> build of gmap:
>>>
>>> intersect-uint2.c:409:21: error: incompatible types when initializing
>>> type '__m128i' using type 'int'
>>>   409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *)
>>> &(shuffle_mask16[r*16]));
>>>   | ^~~~
>>> intersect-uint2.c:427:17: error: incompatible types when assigning to
>>> type '__m128i' from type 'int'
>>>   427 |   v_b = _mm_lddqu_si128((const __m128i *) [i_b]);
>>>   | ^~~
>>>
>>> See
>>>https://salsa.debian.org/med-team/gmap/-/jobs/4423598
>>> for the full build log.
>>>
>>> Any help would be welcome
>>> Andreas.
>>>
>>> --
>>> http://fam-tille.de
>>>
>>>

Re: [Help] Could someone please have a look at gmap build failure

[Michael R. Crusoe]

The real error is at

gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2
-DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\"
-DGSNAP=1 -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1
-mno-sse4.2 -mno-avx2 -g -O2
-ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=.
-fstack-protector-strong -Wformat -Werror=format-security -c -o
gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo
'./'`intersect-uint2.c
intersect-simd.c: In function 'v1':
intersect-simd.c:242:8: warning: implicit declaration of function
'_mm_lddqu_si128'; did you mean '_mm_loadu_si128'?
[-Wimplicit-function-declaration]
  242 |   F0 = _mm_lddqu_si128((const __m128i *)(freq));
  |^~~
  |_mm_loadu_si128

I don't think upstream tested the SSE2 build recently; I'm looking at this now


On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille  wrote:

> Hi,
>
> I admit I'm bad in such hardware internals that seem to break the
> build of gmap:
>
> intersect-uint2.c:409:21: error: incompatible types when initializing type
> '__m128i' using type 'int'
>   409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *)
> &(shuffle_mask16[r*16]));
>   | ^~~~
> intersect-uint2.c:427:17: error: incompatible types when assigning to type
> '__m128i' from type 'int'
>   427 |   v_b = _mm_lddqu_si128((const __m128i *) [i_b]);
>   | ^~~
>
> See
>https://salsa.debian.org/med-team/gmap/-/jobs/4423598
> for the full build log.
>
> Any help would be welcome
> Andreas.
>
> --
> http://fam-tille.de
>
>

Re: pychopper has switched to a non-free license in new upstream version

[Michael R. Crusoe]

That's a shame. The 2.7.3 release (which is quite small) is still under the
original license

https://github.com/epi2me-labs/pychopper/compare/v2.7.2...v2.7.3
https://github.com/epi2me-labs/pychopper/releases/tag/v2.7.3

On Thu, Jun 15, 2023 at 5:54 PM Nilesh Patra 
wrote:

> Hi,
>
> I'm dropping this mail to draw the attention of anyone who's interested in
> updating pychopper.
> While going through the list of outdated packages, I found pychopper as a
> candidate. Unfortunately
> upstream seems to have modified the license in a way that makes in
> non-dfsg compliant.
> In the commit
>
>
> https://github.com/epi2me-labs/pychopper/commit/445bde1611ae2024c50f87e89dfe8c53bc039a32
>
> It says:
>
> '''
> 1.10. "Research Purposes" means use for internal research and not intended
> for or directed towards commercial advantages or monetary compensation;
> provided, however, that monetary compensation does not include sponsored
> research of research funded by grants.
> '''
>
> Best,
> Nilesh
>
>

In Japan, June 24-July 6

[Michael R. Crusoe]

Hi hi,

I'll be in Japan for two weeks and I'll be happy to sign keys, meet 
Debian folk, and possibly co-work a bit.


From June 24th - July 1st I'll be attending the 2023 Japan BioHackathon 
in Kagawa, Japan.


https://2023.biohackathon.org/

From July 1st - 4th I'll be in Kyoto. I'm giving a talk on July 4th 
about the Common Workflow Language at the Bioinformatics Center, 
Institute for Chemical Research, Kyoto University.


On July 5th & 6th I'll be in the Tokyo/Chiba area and also attending the 
Pitagora Network meeting.


https://pitagora-network.org/events/workshop/2023/cwl-seminar

--
Michael R. Crusoe



OpenPGP_signature
Description: OpenPGP digital signature

Re: CWL media type and file extension now in /etc/mime.types

[Michael R. Crusoe]

Great, thank you!

I forget, what's the best way to advertise that cwltool and the toil
packages can handle those media types?

On Sun, May 15, 2022 at 10:22 AM Charles Plessy  wrote:

> Hello everybody,
>
> I just updated the media-types package in Sid, which brings (among other
> changes) the application/cwl media type (and its json variant) in the
> `/etc/mime.types` file.
>
> If a backport would be useful to some purposes, please let me know.
>
> Have a nice Sunday,
>
> Charles
>
> --
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Debian Med packaging team http://www.debian.org/devel/debian-med
> Tooting from work,   https://mastodon.technology/@charles_plessy
> Tooting from home, https://framapiaf.org/@charles_plessy
>
>

Re: ncbi-vdb plans (fixing i386, enabling arm64)

[Michael R. Crusoe]

On Tue, Nov 2, 2021 at 3:25 AM Aaron M. Ucko  wrote:

> sra-sdk in unstable fixes this bug, but is blocked by ncbi-vdb, which
> FTBFS on i386 as of the latest release.  I have a fix worked out
> (disabling vdb3 for now, which AFAICT has no effect on the resulting
> binaries), and plans for some other tune-ups, perhaps most notably
> enabling arm64 builds.  I ran out of time for them today, but hope to
> take care of them later in the week.
>


Hey Aaron, thanks for the update and thanks for your continued support!

Source-only upload of debmutate 0.35 or 0.36

[Michael R. Crusoe]

Hello Jelmer,

Can you make a source-only upload of debmutate 0.35-1 or later? This is
blocking lintian-brush & routine-updates's migration back into testing.

I'm happy to make a NMU, if you wish.

Cheers,

Re: Restricting kma architectures to 64 bit?

[Michael R. Crusoe]

On Mon, Aug 23, 2021 at 5:32 PM Nilesh Patra  wrote:

>
>
> On 8/23/21 9:00 PM, Nilesh Patra wrote:
> > Recently I added autopkgtest to the latest version of resfinder, which
> uses kma_index binary from src:kma package. That started failing on
> > 32 bit architectures[1]
> >
> > I reported the same upstream, and upstream says that kma could never
> work properly on 32-bit arches, see here[2]
> > However, kma had been passing its own autopkgtests on 32 bit arches for
> a while now -- now when I checked, for example this[3]
> > I see that it actually throws an error, but the test passes because the
> upstream did not exit with the right exit code, which they have fixed now.
> >
> > Should I file removal bug for removals from all 32-bit arches for kma?
>

No objection from me.

Re: vcflib does not install scripts - missing bgziptabix

[Michael R. Crusoe]

Thanks for catching this, Steffen!

A bug report would be appreciated, so we don't lose track of this.

--
Michael R. Crusoe

On Sun, May 23, 2021, 14:51 Steffen Möller  wrote:

> Hello,
>
> cudaSV needs bgziptabix to be happy, which is how I became aware fo all
> the scripts in
>
> Med/libvcflib$ ls scripts/
> bed2region  plotXPEHH.R   vcfindelproximity
> vcfnulldotslashdot  vcfregionreduce_and_cut
> bgziptabix  vcf2bed.py   vcfindels
> vcfplotaltdiscrepancy.r  vcfregionreduce_pipe
> plotBfst.R  vcf2sqlite.pyvcfjoincalls
> vcfplotaltdiscrepancy.sh   vcfregionreduce_uncompressed
> plotHaplotypes.R  vcfbiallelic   vcfmultiallelic
> vcfplotsitediscrepancy.r   vcfremovenonATGC
> plotHapLrt.R  vcfclearid   vcfmultiway
> vcfplottstv.sh  vcfsnps
> plotPfst.R  vcfclearinfo   vcfmultiwayscripts
> vcfprintaltdiscrepancy.r   vcfsort
> plot_roc.r  vcfcomplex   vcfnobiallelicsnps
> vcfprintaltdiscrepancy.sh  vcf_strip_extra_headers
> plotSmoothed.R  vcffirstheader   vcfnoindels
> vcfqualfilter  vcfvarstats
> plotWCfst.R  vcfgtcompare.sh  vcfnosnps   vcfregionreduce
> Med/libvcflib$ du -sh scripts/
> 399Kscripts/
>
> being plain missing in libvcflib1 . Should there be a libvcflib-bin
> package? These scripts are expected to install together with vcflib, so
> maybe having them recommended is a good idea? The vcftools package is
> something independent.
>
> debian/rules removes *.R files, so someone on this list knows more about
> it all than me, please give some directions.
>
> Best,
> Steffen
>
>

2021 Europe* BioHackathon, applications due 2021-04-01

[Michael R. Crusoe]

The applications for the 2021 Europe* BioHackathon just opened and are due
on April 1st.

Perhaps packaging TensorFlow and the bioinformatic tools that need it would
be a good topic?

* Not limited to those in Europe

https://elixir-europe.org/BIoHackathon2021-project-submission

Given the special emphasis on industry partners, this would be a nice time
to sync up with the TensorFlow team at Google.

More details: https://biohackathon-europe.org/

I'm a member of ELIXIR Netherlands, so I would be happy to help anyone with
their application.

(I'm not subscribed to debian-ai@ , please keep me CC'd)

-- 
Michael R. Crusoe

Some patches for gmap from Debian

[Michael R. Crusoe]

Dear Thomas,

I wanted you to know about some patches that Debian-Med volunteers added 
to gmap when we package it for Debian:


https://salsa.debian.org/med-team/gmap/-/blob/master/debian/patches/cross

https://salsa.debian.org/med-team/gmap/-/blob/master/debian/patches/install-data-local

https://salsa.debian.org/med-team/gmap/-/blob/master/debian/patches/only-do-cpuid-on-amd64-i386.patch

https://salsa.debian.org/med-team/gmap/-/blob/master/debian/patches/remove_getopt_code_copy.patch

One question from us: is there a publicly accessible version control 
system for the gmap source code? We would like to link to it, and we 
could also provide these and future patches in the form of 
pull(merge)-requests.


Many thanks for providing your software under an open source license.

Cheers,

--
Michael R. Crusoe   




OpenPGP_signature
Description: OpenPGP digital signature

Re: Python louvain packages naming confusion.

[Michael R. Crusoe]

On Tue, 9 Feb 2021 at 23:53, Diane Trout  wrote:

> Hello,
>
> The fairly popular (in the world of bioinformatics) ScanPy package uses
> a Python version of the louvain clustering algorithm implemented by:
>
> https://github.com/vtraag/louvain-igraph
> https://pypi.org/project/louvain/
>
> which installs into the "louvain" dist-packages directory.
> (from debc)
> ./usr/lib/python3/dist-packages/louvain/
>
> I have it mostly packaged
>
> However currently in the Debian archive there's a different louvain
> package
>
> https://github.com/taynaud/python-louvain
> https://pypi.org/project/python-louvain/
> https://salsa.debian.org/python-team/packages/python-louvain
>
> It installs into (according to debc)
> ./usr/lib/python3/dist-packages/community/
>
> Unfortunately for this package we now automatically run autodep8 which
> fails because the import name is community and not louvain.
>

In the short term I recommend fixing this by adding a file to the Debian
python-louvain package named "debian/tests/autopkgtest-pkg-python.conf"
with the contents "import_name = community"


-- 
Michael R. Crusoe

Re: hyphy - amd64 Test failures

[Michael R. Crusoe]

Thanks both :-)

Yeah, I remember thinking about this, but in my rush I forgot. I've pulled
the installation of the simd-dispatcher script into
override_dh_install-indep.

Cheers,

On Sun, 31 Jan 2021 at 00:41, Juhani Numminen 
wrote:

> Hi Nilesh and Michael,
>
> On Sat, 30 Jan 2021, 23.24 Nilesh Patra  wrote:
>
>> Hi Michael,
>>
>> Thanks for your work on hyphy.
>> It seems that with your last upload, CI tests are failing on amd64, but
>> working everywhere else, as can be seen on tracker here[1]
>>
>> The log for amd64 on debci[2] seems to have compliance with salsa CI[3]
>> I see the binaries generated as desired on corresponding buildd log,
>>
>
> The build logs lead me to believe something is missing though.
>
> The target override_dh_install-arch attempts to install simd-dispatch into
> binpkg hyphy-common. Now consider that the buildd network builds the
> arch-independent binary packages separately. During arch-indep build, the
> "-arch" suffixed target is ignored, so simd-dispatch perhaps surprisingly
> does not end up in hyphy-common.
>
>
> Regards,
> Juhani
>

Re: Reminders about using SIMDe

[Michael R. Crusoe]

On Wed, 27 Jan 2021 at 10:59, Nilesh Patra  wrote:

> Hi Michael
>
> On Wed, 27 Jan 2021 at 14:51, Michael R. Crusoe  wrote:
>
>> Hello,
>>
>> After scheduling a binary rebuild[0] of packages using libsimde-dev
>>
>
> First off, thanks a lot for doing this!
>
>
>> I noticed that there are a few new packages using SIMDe (yay!) but aren't
>> listed on https://wiki.debian.org/SIMDEverywhere
>>
>
> It is at my end, I added simde support to plast, ngmlr and scrappie but
> completely missed adding them to the wiki, sorry about that.
> I actually wanted to know answers of a couple of questions before I open a
> PR for them upstream:
>
> * In the simde wiki, point no.3, it is written to remove -msse3,
> -march=native et al flags, however in a few PRs that you opened up, this[1]
> for example, I do not see this change
>

Yeah, for Debian we need to remove them, but I don't want to enforce that
upstream.


>it is however appended with a -D__SIM_SSE3 - does this allow the
> -msse3 flag to work well? And am I expected to do the same stuff in the
> upstream build system?
>

That is a package specific flag. Most PRs are simpler than that one. This
particular flag was removed later in the PR, so it is no longer needed:
https://github.com/stamatak/standard-RAxML/pull/50/files#diff-1a92a17afd64b6b3dd4626377cd6bed402fbc85276bbcf60581a330fa6936187L5934

The PR is mainly to start the conversation with upstream. Some will be
interested and will adapt and accept the PR. Some upstream maintainers will
ignore it.


> * There is no need to add in arguments: "-DSIMDE_ENABLE_OPENMP
> -fopenmp-simd" into the upstream build system right?
>

That's a gcc specific invocation. If they already have code to
differentiate between gcc, clang, icc, and other compilers, then slipping
it into the gcc section makes sense. Otherwise it can be left out unless
the project explicitly only supports gcc.


> Just to be sure that I'm doing it the right way, could you please review
> the PR I sent for plast[2] (sent this PR last month)?
> (Building the upstream repository locally, it looked okay)
>

Sure!

I apologize if these questions might somehow sound stupid, but I do not
> know SIMDe's working well enough to take a judgement without being clear.
>

Not stupid at all, they are good questions. Feel free to update the wiki
with what you learn.


>
> [1]:
> https://github.com/stamatak/standard-RAxML/pull/50/files#diff-8bf5a567e3d917cc040b7bf12f499844b30961ed930b421b717d25039efdd94aR6
> [2]: https://github.com/PLAST-software/plast-library/pull/8
>
> Thanks a lot,
> Nilesh
>

Reminders about using SIMDe

[Michael R. Crusoe]

Hello,

After scheduling a binary rebuild[0] of packages using libsimde-dev I
noticed that there are a few new packages using SIMDe (yay!) but aren't
listed on https://wiki.debian.org/SIMDEverywhere

Please do add them to the table and forward your patch upstream. For
upstream, you may need to add a git submodule [1] or if only one #include
of simde is needed, you can produce a single file using the amalgamate.py
[2] script. If upstream already uses git submodules, then that is
recommended.

Packages that need adding to the table include
- ngmlr
- scrappie

Thanks!

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980997
[1] https://github.com/simd-everywhere/simde-no-tests
[2] https://github.com/simd-everywhere/simde/blob/master/amalgamate.py

-- 
Michael R. Crusoe

Re: [Debian-med-packaging] kmc_3.1.1+dfsg-2_source.changes ACCEPTED into unstable

[Michael R. Crusoe]

Happy to help! Feel free to ping me via email directly or CC email about
non-x86 portability issues in packages.
FYI: This particular set of patches does need to be cleaned up and sent
upstream, as do the patches[0] for onednn and wtdbg2.

When packages are not portable, we should document why in a dated comment
in debian/control so that we don't repeatedly try to port packages that
have significant fundamental issues (like hand written assembler, or
requiring 64 bit archs).

If this is agreeable to the team, perhaps someone wants to volunteer to
document this convention in the Debian-Med policy[1]?

[0] https://wiki.debian.org/SIMDEverywhere#Packages_Status
[1] https://salsa.debian.org/med-team/policy/-/blob/master/policy.rst

On Fri, 22 Jan 2021 at 20:04, Étienne Mollier 
wrote:

> Debian FTP Masters, on 2021-01-22 11:48:44 +:
> > Accepted:
> [...]
> > Changes:
> >  kmc (3.1.1+dfsg-2) unstable; urgency=medium
> >  .
> >* Team upload.
> >  .
> >[ Étienne Mollier ]
> >* Remove non-portable -m64 flag put back by error.
> >  .
> >[ Michael R. Crusoe ]
> >* Support non-x86 systems via libsimde-dev. Closes: #977498
>
> Amazing!  Thanks!  :)
>
> (My apologies for the i386 issue, I spotted it but forgot to
>  push it earlier.)
>
> Kind Regards,
> --
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/2, please excuse my verbosity.
>
>
>

Re: armhf regressions in a few packages

[Michael R. Crusoe]

Bus error tends to be about unaligned memory access. I personally don't fix
such issues, but I do report them upstream and then disable that
architecture for building.

For bioinformatics, there is no reason to support armhf.

--
Michael R. Crusoe

On Sat, Nov 21, 2020, 22:11 Nilesh Patra  wrote:

> Hi,
>
> I've seen some packages failing _only_ on armhf when I added autopkgtests
> to them. Murasaki[1] and lighter[2] for example.
> They seem to fail with this common error message:  Bus Error --
> 
>
> Could it be because of lack of RAM/memory issue there?
>
> Couple of days ago, Praveen (in CC) reported to me an error with
> golang-github-honnef-tools[3]
> But on running in an armhf porter box, it works just fine as I'm told.
>
> I've also noticed that the tests in these packages need a _relatively_
> higher computation power.
> I'm unsure if this is a fault in the tests, or a limitation at CI's end.
> Please let me know what you'd think about this and plausible solutions to
> this.
>
> [1]:
> https://ci.debian.net/data/autopkgtest/testing/armhf/m/murasaki/8213738/log.gz
> [2]:
> https://ci.debian.net/data/autopkgtest/testing/armhf/l/lighter/8203401/log.gz
> [3]:
> https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-honnef-go-tools/8213705/log.gz
>
> Regards,
> Nilesh
>
>

Re: Project idea: port GKL to non-x86

[Michael R. Crusoe]

On Wed, 18 Nov 2020 at 10:32, Andreas Tille  wrote:

> Hi Michael,
>
> On Wed, Nov 18, 2020 at 12:00:29AM +0100, Michael Crusoe wrote:
> > With https://salsa.debian.org/java-team/gkl/-/merge_requests/3 I am
> able to
> > build a GKL package that runs on non-amd64 (though probably at a huge
> speed
> > sacrifice)
> >
> > Using the resulting libgkl-java package and
> >
> https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
> > I am able to build and run Picards tools on arm64
>
> Cool.  Should I upload gkl (after some routine-update)?
>

Already done :-)


> I also wonder why that package is in java-team if only Debian Med
> members are working on it and its relevant for Debian Med.
>

I don't know!


-- 
Michael R. Crusoe

Re: shapeit4 and AVX2

[Michael R. Crusoe]

On Mon, 9 Nov 2020 at 17:21, Étienne Mollier 
wrote:

> Howdy,
>
> I'm filling a wishlist item in the bug tracker, so that the
> discussion does not disappear inside mail archives.  I gave a
> try to shapeit4 autopkgtest suite with and without FMA & AVX2
> support, but it had a run time of 1m25s in both cases on my
> machine (Ryzen 5 3600 w/ 6 cores).  It is quite possible I
> neglected some other bottlenecks though, but the assembler did
> embed AVX2 instructions when I checked the build result.  Out of
> curiosity, has someone figures on the performance gain for that
> software when extensions are available?
>
> Michael R. Crusoe, on 2020-11-05 21:26:30 +0100:
> > As documented at
> > https://wiki.debian.org/SIMDEverywhere
>
> shapeit4 provides a dedicated code path for "-mfma -mavx2" build
> options, and another one for generic builds.  Is it still worth
> using SIMDe in this particular situation?  The "use case"
> paragraph of the wiki page seems to suggest it is not strictly
> needed here.
>

Given the fallback route that doesn't use SIMD, then implementing our own
is not necessary, however compiling the FMA+AVX2 path using SIMDe on
non-x86 archs may result in a speedup for them.

Would be best to get a bigger training dataset to confirm the benefit, or
at least the lack of regression :-)

If a performance benefit is observed, it might be interesting to see if the
AVX-only and "lower" SIMD levels on x86 also experience a speed up.

Re: Happy! Fwd: pigx-rnaseq_0.0.10+ds-1_amd64.changes ACCEPTED into unstable, unstable

[Michael R. Crusoe]

On Sat, Oct 24, 2020 at 4:18 AM Steffen Möller 
wrote:

> Dear all,
>
> We got our first RNA-seq pipeline as a package in Debian. Many thanks go
> to all who contributed. I need to let this sink in for a while, which
> coincides with being distracted with what I am paid to do :o) And then
> let's use it to reanalyse a few datasets that are associated with
> COVID-19. Got some ideas already that need to somehow solidify
> themselves, still.
>

Huzzah! Thank you, Steffen

Re: Videoconference Saturday 2020-10-17 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020))

[Michael R. Crusoe]

On Fri, Oct 16, 2020 at 3:50 PM Andreas Tille  wrote:

> Hi,
>
> the video conferences of the Debian Med team have shifted to two
> meetings per month now.  Do enable different people joing we shift
> weekdays by simply meeting on every
>
>2th  and  17th
>
> of a month.  So the next meeting is tomorrow 18:00 UTC
>
> For those who would like to join our next videomeeting it will happen at
> Friday
>
>
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference=20201017T20=37=1
>

Notes are at
https://storm.debian.net/shared/SlUYTQlMWDJUfhR7J2PIiDaMDa_e28was0bsjELz77k

Thanks to the attendees!


> The meeting is on the Debian Social channel
>
>  https://jitsi.debian.social/DebianMedCovid19
>
> These video meetings were started in the Debian Med Biohackathon[1].
> The topic is what contributors have done in the past week and to
> coordinate the work for next week.  Here are the reports of some past
> meetings:
>
>  https://wiki.debian.org/DebianMed/Meeting/WeeklyCovid19
>
> To repeat myself: Newcomers are always welcome.
>
> Most probably I will not be able to attend myself the meeting
> tomorrow - but I wish all attendees a lot of fun
>
>Andreas.
>
> [1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html
>
> --
> http://fam-tille.de
>
>

ELIXIR & Debian(-Med)

[Michael R. Crusoe]

I'd like to see Debian/Debian-Med become an official ELIXIR Core Data
Resource during the next cycle.

https://f1000research.com/articles/5-2422/v2 has the details about the last
review round.

Would anyone like to help me with the application process?

Thanks,

Re: [COVID-19 Hackathon] Bazel build system pending NEW

[Michael R. Crusoe]

On Mon, Aug 24, 2020 at 4:51 PM Olek Wojnar  wrote:

> Hi Mo,
>
> Sorry about the slow reply, I've been a bit buried with emails and I'm not
> answering them as well as I would like. :(
>
> On Wed, Aug 19, 2020 at 12:40 AM Mo Zhou  wrote:
>
>> Hi Olek,
>>
>> What a good news! Your hardword is much appreciated.
>>
>
> Thanks! I'm really looking forward to this making life easier for people
> who want to package software that uses Bazel to build.
>
> There are some preliminary packaging changes (using bazel) for
>> tensorflow. Is it in shape so that I can build TF from the git repo?
>> Or what remains to be done?
>>
>
> I'm not sure, Michael (copied above) took the lead on the TensorFlow
> packaging. Michael, could you please provide an update? Are you running
> into any specific issues that you could use help with?
>

Hey Mo, we have some unpackaged dependencies. Currently TensorFlow can be
built using code copies, but obviously that isn't a great plan. Here are
the current code copies:
https://github.com/meteorcloudy/tensorflow/tree/r2.2-debian/debian/dist

If you want to help out you can use the bazel-bootstrap and
libcheck-framework-java binary packages from
https://people.debian.org/~olek/packages/


>
> Our primary contact on the upstream Bazel team (who also does some work
> with upstream TensorFlow) verified that the latest Debian Bazel
> (bazel-bootstrap) package *does* successfully build TensorFlow but I
> believe there may have been some TensorFlow dependencies that were still
> missing in Debian?
>

I've added our upstream contact Yun Peng to this thread.


>
> -Olek
>

Notes from the 2020-07-17 Bazel-Debian-Google meeting

[Michael R. Crusoe]

https://salsa.debian.org/bazel-team/meta/-/wikis/2020-07-17-notes

Olek will upgrade his bazel-boostrap package to 3.4 and then we can use the
unofficial packages to re-start the Tensorflow 2.1.0 packaging while we
wait for everything else to pass the NEW queue.

Many thanks to Olek and Yun!

-- 
Michael R. Crusoe

Re: RFS: snap-aligner

[Michael R. Crusoe]

Done. I also ran `routine-update -f` which did a number of cleanups. It
would be nice if you ran that yourself in the future :-)

I also fixed a spelling error in the upstream source that lintian now
notices.

Uploaded. Thanks!


On Thu, Jul 9, 2020 at 8:52 AM Pranav Ballaney 
wrote:

> Hi,
> I've added autopkgtests to snap-aligner. Please review and sponsor.
> https://salsa.debian.org/med-team/snap-aligner
>
> Regards,
> Pranav
> ᐧ
>

Re: Videoconference today Friday 2020-06-12 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020)))

[Michael R. Crusoe]

Thank you Andreas for announcing the meeting, and thanks to the attendees
for their participation. Our meeting notes are at
https://storm.debian.net/shared/6NfKT87njAmCg3tr_uhkE2Qp9SQhVxy8mwD1fQUzfMy

On Fri, Jun 12, 2020 at 1:07 PM Andreas Tille  wrote:

> Hi,
>
> for those who would like to join our next videomeeting it will happen at
>
>
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference=20200612T20=37=1
>
> As last week we will use
>
>  https://jitsi.debian.social/DebianMedCovid19
>
> These weekly video meetings were started in the Debian Med
> Biohackathon[1].  The topic is what contributors have done in the past
> week and to coordinate the work for next week.  Despite the one week of
> hackathon is over Covid-19 is not and there is a lot of remaining work
> to do.  Newcomers are always welcome.
>
> See you
>
>Andreas.
>
> [1] https://lists.debian.org/debian-devel-announce/2020/03/msg00010.html
>
> --
> http://fam-tille.de
>
>

Re: "Computational Strategies to Combat COVID-19: Useful Tools to Accelerate SARS-CoV-2 and Coronavirus Research"

[Michael R. Crusoe]

On Thu, Jun 4, 2020 at 9:07 PM Andreas Tille  wrote:

> Hi Michael,
>
> On Thu, Jun 04, 2020 at 08:12:01PM +0200, Michael R. Crusoe wrote:
> > Alas the DOI is too new!
>

Here is the working DOI link:
https://doi.org/10.20944/preprints202005.0376.v1


> >
> > It will work later. https://www.preprints.org/manuscript/202005.0376/v1
> > works today.
>
> Thanks a lot for the link.  I extracted "our todo list" to
>
>
> https://salsa.debian.org/blends-team/med/-/blob/master/covid-19_doc/Computational_Strategies_to_Combat_COVID-19.txt


You are welcome. Note, several of those aren't standalone tools, but are
pipelines using many 3rd party tools. So we'll need to dig deeper to fully
know which tools are being recommended by the authors of this pre-print.

At least one mentioned there (Beast2) is just done. ;-)
>
> Would you mind adding this link to our announcement e-mail giving another
> motivation why we are doing another sprint?
>

Sure, I'm doing that now.


>
> Kind regards
>
>   Andreas.
>
> > --
> > Michael R. Crusoe
> >
> > On Thu, Jun 4, 2020, 20:11 Michael R. Crusoe  wrote:
> >
> > > Pardon me, https://doi.org/10.0.81.208/preprints202005.0376.v1 is the
> > > correct link
> > >
> > > --
> > > Michael R. Crusoe
> > >
> > > On Thu, Jun 4, 2020, 20:06 Michael R. Crusoe 
> wrote:
> > >
> > >> https://10.20944/preprints202005.0376.v1
> > >>
> > >> --
> > >> Michael R. Crusoe
> > >>
> > >
>
> --
> http://fam-tille.de
>
>

Re: "Computational Strategies to Combat COVID-19: Useful Tools to Accelerate SARS-CoV-2 and Coronavirus Research"

[Michael R. Crusoe]

Alas the DOI is too new!

It will work later. https://www.preprints.org/manuscript/202005.0376/v1
works today.

--
Michael R. Crusoe

On Thu, Jun 4, 2020, 20:11 Michael R. Crusoe  wrote:

> Pardon me, https://doi.org/10.0.81.208/preprints202005.0376.v1 is the
> correct link
>
> --
> Michael R. Crusoe
>
> On Thu, Jun 4, 2020, 20:06 Michael R. Crusoe  wrote:
>
>> https://10.20944/preprints202005.0376.v1
>>
>> --
>> Michael R. Crusoe
>>
>

Re: "Computational Strategies to Combat COVID-19: Useful Tools to Accelerate SARS-CoV-2 and Coronavirus Research"

[Michael R. Crusoe]

Pardon me, https://doi.org/10.0.81.208/preprints202005.0376.v1 is the
correct link

--
Michael R. Crusoe

On Thu, Jun 4, 2020, 20:06 Michael R. Crusoe  wrote:

> https://10.20944/preprints202005.0376.v1
>
> --
> Michael R. Crusoe
>

"Computational Strategies to Combat COVID-19: Useful Tools to Accelerate SARS-CoV-2 and Coronavirus Research"

[Michael R. Crusoe]

https://10.20944/preprints202005.0376.v1

--
Michael R. Crusoe

Debian @ COVID-19 Biohackathon (April 5-11, 2020)

[Michael R. Crusoe]

Dear Debian Community,

There will be an virtual (online) COVID-19 Biohackathon from April 5-11, 
2020 and the Debian Med team invite you help us improve biomedical FOSS 
and the tools/libraries that support those projects.


Most tasks do not require any knowledge of biology or medicine, and all 
types of contributions are welcome: bug triage, testing, documentation, 
CI, translations, packaging, and code contributions.


1. Debian related bugs are viewable at [covid19-bugs]

2. Software awaiting packaging is listed at [covid-19-packages], please 
respond to the RFP with your intent so we don't duplicate work


3. You can also contribute directly to the upstream packages, linked 
from the Debian Med COVID-19 task page at [covid-19-packages]. Note: 
many biomedical software packages are quite resource limited, even 
compared to a typical FOSS project. Please be kind to the upstream 
author/maintainers and realize that they may have limited resources to 
review your contribution. Triaging open issues and opening pull requests 
to fix problems is likely to be more useful than nitpicking their coding 
style.


4. Architectures/porting: Please focus on amd64, as it is the primary 
architecture for biomedical software. A secondary tier would be arm64 / 
ppc64el / s390x (but beware the endian-related issues on s390x). From a 
free/open hardware perspective it would be great to see more riscv64 
support, but that is not a priority right now


5. The Debian Med team is also trying to improve the availability of 
automated biomedical pipelines/workflows [robust-workflows] using the 
Common Workflow Language open standard. The reference implementation of 
CWL is written in Python and there are many open issues ready for work 
that don't require any biomedical background [cwltool-issues]


6. It is very easy to contribute to Debian Med team. We have a lowNMU 
policy for all our packages. Merge requests on Salsa are usually 
processed quickly (but please ping some of the latest Uploaders of the 
package to make sure it will be noticed). Even better if you ask for 
membership to the team and push directly to the salsa repository.


7. The [debian-med-team-policy] should answer all questions how to 
contribute.


The main COVID-19 biohackathon is being organized at [covid-19-bh20] and 
for Debian's participation we are using [salsa-covid-19-bh20]


[covid-19-bugs] https://blends.debian.org/med/bugs/covid-19.html

[covid-19-packages] https://blends.debian.org/med/tasks/covid-19

[covid-19-bh20] https://github.com/virtual-biohackathons/covid-19-bh20

[salsa-covid-19-bh20] 
https://salsa.debian.org/med-team/community/2020-covid19-hackathon


[robust-workflows] https://doi.org/10.1007/s41019-017-0050-4

[cwltool-issues] https://github.com/common-workflow-language/cwltool/issues

[COVID-19-advice] 
https://www.who.int/emergencies/diseases/novel-coronavirus-2019/advice-for-public


[debian-med-team-policy] https://med-team.pages.debian.net/policy/

Sincerely,

Michael R. Crusoe on behalf of the Debian-Med team

Bug#951072: ITP: htscodecs -- Custom compression for CRAM and others

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: htscodecs -- Custom compression for CRAM and others
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: htscodecs
  Version : 0.5
  Upstream Author : , Genome Research Ltd.
* URL : https://github.com/jkbonfield/htscodecs/
* License : BSD-3-clause
  Programming Lang: C
  Description : Custom compression for CRAM and others
 This library implements the custom CRAM codecs used for "EXTERNAL" block
 types. These consist of two variants of the rANS codec (8-bit and 16-bit
 renormalisation, with run-length encoding and bit-packing also supported
 in the latter), a dynamic arithmetic coder, and custom codecs for name/ID
 compression and quality score compression derived from fqzcomp.
 .
 They come with small command line test tools to act as both compression
 exploration programs and as part of the test harness.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/htscodecs

Bug#950607: ITP: bwa-mem2 -- the next version of the bwa-mem algorithm in bwa

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: bwa-mem2 -- the next version of the bwa-mem algorithm in bwa
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: bwa-mem2
  Version : 2.0~pre2
  Upstream Author : , Vasimuddin Md, Sanchit Misra, Intel Corporation, Heng Li.
* URL : https://github.com/bwa-mem2/bwa-mem2/
* License : MIT
  Programming Lang: C
  Description : the next version of the bwa-mem algorithm in bwa
 It produces alignment identical to bwa and is ~80% faster.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/bwa-mem2

Bug#948518: RM: grabix [s390x] -- ROM; upstream htslib broke s390x and is holding up several transitions

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: important

A follow on to https://bugs.debian.org/948092 as I forgot to include
grabix in the list; this appears to be holding up the transition to
testing if I'm reading https://release.debian.org/britney/update_output.txt 
correctly.

Thanks!

Bug#948330: ITP: libsys-info-perl -- Fetch information from the host system

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libsys-info-perl -- Fetch information from the host system
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libsys-info-perl
  Version : 0.7811
  Upstream Author : , Burak Gursoy 
* URL : https://metacpan.org/release/Sys-Info
* License : Artistic
  Programming Lang: Perl
  Description : Fetch information from the host system
 Extracts and collects information from the host system.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/libsys-info-perl

Bug#948329: ITP: libsys-info-driver-linux-perl -- Linux driver for Sys::Info

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libsys-info-driver-linux-perl -- Linux driver for Sys::Info
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libsys-info-driver-linux-perl
  Version : 0.7905
  Upstream Author : , Burak Gursoy 
* URL : https://metacpan.org/release/Sys-Info-Driver-Linux
* License : Artistic
  Programming Lang: Perl
  Description : Linux driver for Sys::Info
 This is the main module in the Linux driver collection.

Remark: This package is maintained by Michael R. Crusoe at
   https://salsa.debian.org/med-team/libsys-info-driver-linux-perl

Bug#948325: ITP: libbio-featureio-perl -- Modules for reading, writing, and manipulating sequence features

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-featureio-perl -- Modules for reading, writing, and 
manipulating sequence features
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-featureio-perl
  Version : 1.6.905
  Upstream Author : BioPerl Team 
* URL : https://metacpan.org/release/Bio-FeatureIO
* License : Artistic
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : Modules for reading, writing, and manipulating sequence 
features
 An I/O iterator subsystem for genomic sequence features.
 .
 Bio::FeatureIO is a handler module for the formats in the FeatureIO set (eg,
 Bio::FeatureIO::GFF). It is the officially sanctioned way of getting at the
 format objects, which most people should use.
 .
 The Bio::FeatureIO system can be thought of like biological file handles.
 They are attached to filehandles with smart formatting rules (eg, GFF format,
 or BED format) and can either read or write feature objects (Bio::SeqFeature
 objects, or more correctly, Bio::FeatureHolderI implementing objects, of
 which Bio::SeqFeature is one such object). If you want to know what to do
 with a Bio::SeqFeatureI object, read Bio::SeqFeatureI.
 .
 The idea is that you request a stream object for a particular format. All the
 stream objects have a notion of an internal file that is read from or written
 to. A particular FeatureIO object instance is configured for either input or
 output. A specific example of a stream object is the Bio::FeatureIO::gff
 object.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/libbio-featureio-perl

Bug#948092: RM: htslib, delly, fastqtl, kallisto, libtabixpp, qtltools, rsem, samtools, segemehl, shapeit4, stringtie, stacks [s390x] -- ROM; upstream htslib broke s390x and is holding up several tran

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Dear ftp.debian.org people,

htslib FTBFS on big-endian systems
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947462 and this is
blocking the following transitions: auto-htslib, python2-rm, python3.8,
and auto-pbbam

I propose we delete the affected s390x packages for now and when/if
upstream has fixed their code for big endian systems then we can upload
the fixed versions later.

Thanks in advance

Bug#946468: ITP: libbio-variation-perl -- BioPerl variation-related functionality

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-variation-perl -- BioPerl variation-related functionality
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-variation-perl
  Version : 1.7.4
  Upstream Author : Copyright: Allen Day , Heikki 
Lehvaslaiho 
* URL : https://metacpan.org/release/Bio-Variation
* License : Artistic
  Programming Lang: Perl
  Description : BioPerl variation-related functionality
  The code in this distribution focuses on simple low-dependency variant-related
 functionality for BioPerl.
 .
 Bio::Variation name space contains modules to store sequence variation
 information as differences between the reference sequence and changes
 sequences. Also included are classes to write out and recrete objects
 from EMBL-like flat files and XML. Lastly, there are simple classes to
 calculate values for sequence change objects.

Remark: This package is maintained by Debian Med Team at
   https://salsa.debian.org/med-team/libbio-variation-perl

Bug#946272: ITP: libbio-procedural-perl -- Simple low-dependency procedural interfaces to BioPerl

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-procedural-perl -- Simple low-dependency procedural 
interfaces to BioPerl
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-procedural-perl
  Version : 1.7.4
  Upstream Author : Copyright: Ewan Birney 
* URL : https://metacpan.org/release/Bio-Procedural
* License : Artistic
  Programming Lang: Perl
  Description : Simple low-dependency procedural interfaces to BioPerl
 The code in this distribution focuses on simple low-dependency procedural
 interfaces to BioPerl that don't require knowledge of BioPerl classes and
 methods.

Remark: This package is maintained by Debian Med team at
   https://salsa.debian.org/med-team/libbio-procedural-perl

Bug#946269: ITP: libbio-db-refseq-perl -- Database object interface for RefSeq retrieval

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-refseq-perl -- Database object interface for RefSeq 
retrieval
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-refseq-perl
  Version : 1.7.3
  Upstream Author : Copyright: Heikki Lehvaslaiho 
* URL : https://metacpan.org/release/Bio-DB-RefSeq
* License : Artistic
  Programming Lang: Perl
  Description : Database object interface for RefSeq retrieval
 Allows the dynamic retrieval of sequence objects Bio::Seq from the RefSeq
 nucleotide database using the dbfetch script at EBI:
 .
 http://www.ebi.ac.uk/Tools/dbfetch/dbfetch
 .
 At this time the module specifically retrieves nucleotide sequences only.
 .
 In order to make changes transparent we have host type (currently only ebi)
 and location (defaults to ebi) separated out. This allows later additions of
 more servers in different geographical locations.
 .
 The functionality of this module is inherited from Bio::DB::DBFetch which
 implements Bio::DB::WebDBSeqI.

Remark: This package is maintained by Debian Med team at
   https://salsa.debian.org/med-team/libbio-db-refseq-perl

Bug#946266: ITP: libbio-db-swissprot-perl -- Database object interface to SwissProt retrieval

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-db-swissprot-perl -- Database object interface to 
SwissProt retrieval
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-db-swissprot-perl
  Version : 1.7.3
  Upstream Author : Copyright: Jason Stajich 
* URL : https://metacpan.org/release/Bio-DB-SwissProt
* License : Artistic
  Programming Lang: Perl
  Description : Database object interface to SwissProt retrieval
 SwissProt is a curated database of proteins managed by the Swiss
 Bioinformatics Institute. Additional tools for parsing and manipulating
 swissprot files can be found at
 ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/.
 .
 Allows the dynamic retrieval of Sequence objects (Bio::Seq) from the
 SwissProt database via an Expasy retrieval.
 .
 In order to make changes transparent we have host type (currently only
 expasy) and location (default to Switzerland) separated out. This allows the
 user to pick the closest Expasy mirror for running their queries.
 .
 This description was automagically extracted from the module by dh-make-perl.

Remark: This package is maintained by Debian Med team at
   https://salsa.debian.org/med-team/libbio-db-swissprot-perl

Bug#944905: RM: jellyfish [arm64 mips64el ppc64el riscv64] -- ANAIS; Non-AMD64 not supported by upstream

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Thanks!

Bug#944785: ITP: pufferfish -- An efficient index for the colored, compacted, de Bruijn graph

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: pufferfish -- An efficient index for the colored, compacted, de 
Bruijn graph 
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: pufferfish
  Version : 1.0.0
  Upstream Author : , 2016 Rob Patro, Avi Srivastava, Hirak Sarkar
* URL : https://github.com/COMBINE-lab/pufferfish
* License : GPL-3+
  Programming Lang: C
  Description : An efficient index for the colored, compacted, de Bruijn 
graph 
 Pufferfish is a new time and memory-efficient data structure for indexing a
 compacted, colored de Bruijn graph (ccdBG). 
 .
 Though the de Bruijn Graph (dBG) has enjoyed tremendous popularity as an
 assembly and sequence comparison data structure, it has only relatively
 recently begun to see use as an index of the reference sequences (e.g. deBGA,
 kallisto). Particularly, these tools index the compacted dBG (cdBG), in which
 all non-branching paths are collapsed into individual nodes and labeled with
 the string they spell out. This data structure is particularly well-suited for
 representing repetitive reference sequences, since a single contig in the cdBG
 represents all occurrences of the repeated sequence. The original positions in
 the reference can be recovered with the help of an auxiliary "contig table"
 that maps each contig to the reference sequence, position, and orientation
 where it appears as a substring. The deBGA paper has a nice description how
 this kind of index looks (they call it a unipath index, because the contigs we
 index are unitigs in the cdBG), and how all the pieces fit together to be able
 to resolve the queries we care about.  Moreover, the cdBG can be built on
 multiple reference sequences (transcripts, chromosomes, genomes), where each
 reference is given a distinct color (or colour, if you're of the British
 persuasion). The resulting structure, which also encodes the relationships
 between the cdBGs of the underlying reference sequences, is called the
 compacted, colored de Bruijn graph (ccdBG).  This is not, of course, the only
 variant of the dBG that has proven useful from an indexing perspective. The
 (pruned) dBG has also proven useful as a graph upon which to build a path
 index of arbitrary variation / sequence graphs, which has enabled very
 interesting and clever indexing schemes like that adopted in GCSA2. Also,
 thinking about sequence search in terms of the dBG has led to interesting
 representations for variation-aware sequence search backed by indexes like the
 vBWT (implemented in the excellent gramtools package).

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pufferfish

This package will be team maintained by Debian-Med

Bug#944735: RM: rapmap [arm64 mips64el ppc64el] -- ANAIS; non-amd64 not supported by upstream

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Thanks!

Bug#923386: RM: python-schema-salad & python-typing-extensions -- ROM; binary packages for Python 2 no longer needed

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the binary package python-schema-salad version
2.6.20171201034858-3 and the binary package python-typing-extensions version
3.7.2-1 from the archive. We now only need and build for Python 3
and these packages are holding up the migration of python3-typing-extensions:
https://qa.debian.org/excuses.php?package=python-typing-extensions

Thanks!

Bug#919681: ITP: sourmash -- tools for comparing DNA sequences with MinHash sketches

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: sourmash
  Version : 2.0.0~a11
  Upstream Author : C. Titus Brown , Luiz C. Irber, Jr 

* URL : http://sourmash.readthedocs.io/en/latest/
* License : BSD-3-Clause
  Programming Lang: Python, C++
  Description : tools for comparing DNA sequences with MinHash sketches

 Compute MinHash signatures for nucleotide (DNA/RNA) and protein sequences.
 .
 MinHash sketches provide a lightweight way to store “signatures” of large DNA
 or RNA sequence collections, and then compare or search them using a Jaccard
 index. MinHash sketches can be used to identify samples, find similar samples,
 identify data sets with shared sequences, and build phylogenetic trees
 (Ondov et al. 2015).
 .
 sourmash provides a command line script, a Python library, and a CPython
 module for MinHash sketches

Sourmash is team maintained by Debian-Med at 
https://salsa.debian.org/med-team/sourmash

Bug#919570: ITP: python-mypy-extensions -- Experimental type system extensions for mypy typechecker (Python 3)

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: python-mypy-extensions
  Version : 0.4.1
  Upstream Author : Jukka Lehtosalo and contributors
* URL : https://github.com/python/mypy_extensions/
* License : Expat
  Programming Lang: Python
  Description : Experimental type system extensions for mypy typechecker 
(Python 3)

(Include the long description here.
 Add type annotations to your Python programs, and use mypy to type check them.
 Mypy is essentially a Python linter on steroids, and it can catch many
 programming errors by analyzing your program, without actually having to run
 it. Mypy has a powerful type system with features such as type inference,
 gradual typing, generics and union types.
 .
 The "mypy_extensions" module defines experimental extensions to the
 standard "typing" module that are supported by the mypy typechecker.
 .
 This package provides the modules for Python 3.

This python module was previously part of the python3-mypy binary package from
the mypy source package as it came from the same PyPI source distribution. Now
it has been split into its own sdist/GitHub repo as of mypy v 0.660, so this
separate package is needed.

As with mypy, python-mypy-extensions will be team maintained by Debian Med.

Bug#918871: RM: python-bd2k -- ROM; No longer needed by Debian, abandoned upstream

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Control: block -1 by 918869

To be removed after python-cgloud, #918869 [1] for the same reasons:
python-bd2k was originally packaged as a dependency of Toil[2], but by the time
Toil arrived in the NEW queue it had dropped its dependency on python-bd2k.

Other than the aforementioned python-cgcloud, there are no other
(reverse-)dependencies on python-bd2k in Debian.

Thanks!

[1] https://bugs.debian.org/918869
[2] https://ftp-master.debian.org/new/toil_3.18.0-1.html

Bug#918869: RM: python-cgcloud -- ROM; No longer need by Debian, abandoned upstream

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

This was originally packaged as a dependency of Toil[1], but by the time that 
made
it to the NEW queue Toil had dropped its dependency on cgcloud.

[1] https://ftp-master.debian.org/new/toil_3.18.0-1.html

Bug#918343: RM: tnseq-transit [arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x] -- ANAIS; has missing (build-)dependency on amd64 only package

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

Hello,

This package was missing a source and binary dependency on BWA which is only
built for amd64.

Please remove the non-amd64 binary packages of tnseq-transit so that the new
Debian package can migrate from sid to testing.

Thanks!

Bug#918251: d-shlibs: devlibs error: There is no package matching [libsvm3-dev] and noone provides it

[Michael R. Crusoe]

Package: d-shlibs
Version: 0.83
Severity: normal

Dear Maintainer,

While fixing the missing linkage to libsvm in libpsortb I received the
following message:

devlibs error: There is no package matching [libsvm3-dev] and noone provides
it, please report bug to d-shlibs maintainer

So here I am :-)

d-shlibmove --commit \
--multiarch \
--devunversioned \
--exclude-la \
debian/tmp/usr/lib/*/libsvmloc.so
Library package automatic movement utility
devlibs error: There is no package matching [libsvm3-dev] and noone provides 
it, please report bug to d-shlibs maintainer 


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8), 
LANGUAGE=ro_RO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages d-shlibs depends on:
ii  apt   1.8.0~alpha3
ii  binutils  2.31.1-11

d-shlibs recommends no packages.

d-shlibs suggests no packages.

-- no debconf information

Bug#918117: RM: python-htseq-doc/0.6.1p1-4

[Michael R. Crusoe]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hello,

Please remove python-htseq-doc from the testing distribution. It is no
longer build by the source package and its presence is blocking a migration
from unstable.

Thanks!

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ro_RO.utf8, LC_CTYPE=ro_RO.utf8 (charmap=UTF-8), 
LANGUAGE=ro_RO.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#915852: ITP: bagit -- Create and validate BagIt packages

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: bagit
  Version : 1.7.0
  Upstream Author : Ed Summers 
* URL : https://libraryofcongress.github.io/bagit-python/
* License : CC0
  Programming Lang: Python
  Description : Create and validate BagIt packages

bagit is a Python library and command line utility for working with
 `BagIt `__ style data packages.

A new dependency of cwltool. Will be team maintained by Debian-Med.

Bug#914991: RM: testing/htslib [i386 hurd-i386 kfreebsd-i386] -- ANAIS; ROM *i386 no longer supported upstream

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
Owner: Debian Med team 

Upstream report: https://github.com/samtools/htslib/issues/565
The provided workaround does not fix the issue and it has now been a year with
no progress

Thanks!

Bug#911076: ITP: libdeflate -- fast, whole-buffer DEFLATE-based compression and decompression

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: libdeflate
  Version : 1.0
  Upstream Author : Eric Biggers 
* URL : https://github.com/ebiggers/libdeflate
* License : MIT
  Programming Lang: C
  Description : fast, whole-buffer DEFLATE-based compression and 
decompression

The supported formats are:
 . 
 DEFLATE (raw)
 zlib (a.k.a. DEFLATE with a zlib wrapper)
 gzip (a.k.a. DEFLATE with a gzip wrapper)
 libdeflate is heavily optimized. It is significantly faster than the zlib
 library, both for compression and decompression, and especially on x86
 processors. In addition, libdeflate provides optional high compression modes
 that provide a better compression ratio than the zlib's "level 9".

libdeflate is a recommended dependency of htslib and will be team-maintained by
Debian Med

Bug#890755: ITP: ctdconverter -- Convert CTD files into Galaxy tool and CWL CommandLineTool files

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: ctdconverter
  Version : 2.0
  Upstream Author : WorkflowConversion
* URL : https://github.com/WorkflowConversion/CTDConverter/
* License : GPL-3 / Apache-2.0
  Programming Lang: Python
  Description : Convert CTD files into Galaxy tool and CWL CommandLineTool 
files

Common Tool Descriptors (CTDs) are XML documents that represent the inputs,
outputs, parameters of command line tools in a platform-independent way.

CTDConverter, given one or more Common Tool Descriptors (CTD) XML files,
generates Galaxy tool wrappers and Common Workflow Language (CWL) Command
Line Tool v1.0 standard descriptions from CTD files.

Will assist in including CWL descriptions in the seqan-apps, openms/topp,
flexbar, and lambda-align packages

Will be team-maintained by Debian Med

Bug#890752: ITP: ctdopts -- Gives your Python tools a CTD-compatible interface

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: ctdopts
  Version : 1.2
  Upstream Author : Andras Szolek et al.
* URL : https://github.com/WorkflowConversion/CTDopts
* License : GPL-3+
  Programming Lang: Python
  Description : Gives your Python tools a CTD-compatible interface

Common Tool Descriptors (CTDs) are XML documents that represent the inputs,
outputs, parameters of command line tools in a platform-independent way.

CTDopts is a module for enabling tools with CTD reading/writing, argument
parsing, validating and manipulating capabilities.

Needed for CTDConverter to convert CTD to CWL (and Galaxy) as part of including
CWL descriptions in the seqan-apps, openms/topp, flexbar, and lambda-align
packages

Will be team-maintained by Debian Med

Bug#890061: ITP: galaxy-lib -- Subset of Galaxy core code base designed to be used

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: galaxy-lib
  Version : 17.9.10
  Upstream Author : Galaxy Project and Community 
* URL : https://github.com/galaxyproject/galaxy-lib
* License : AFL
  Programming Lang: Python
  Description : Subset of Galaxy core code base designed to be used


Dependency for the Toil workflow system; group maintained by Debian-Med

Lack of license for pal2nal

[Michael R. Crusoe]

Hello,

I'm writing you on behalf of the Debian Med team which is a subgroup
inside Debian with the objective to package free software in the field
of biology and medicine for official Debian releases. We have packaged
pal2nal but we can not distribute it as it has no license.

Since Debian only distributes free software (for instance licensed under
GPL, BSD or so) we are wondering whether you might consider to publish
the source code of this software under a free license.

The advantage would be that users of Debian / Ubuntu and its derivatives
systems which are quite frequently used in bioinformatics could easily
install your software.  You also get some additional quality assurance
and I can confirm that all authors who decided to open source their
software to enable the Debian Med packaging team were happy about this
step since it contributed to a wider distribution of their software and
a better user response.

Kind regards and thanks for considering,

-- 
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project <http://www.commonwl.org/>
https://impactstory.org/u/-0002-2961-9670
m...@commonwl.org

Bug#860746: ITP: easel -- a library of C functions for biological sequence analysis

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: easel
  Version : 0.43
  Upstream Author : Sean R. Eddy 
* URL : https://github.com/EddyRivasLab/easel
* License : BSD-3-clause
  Programming Lang: C
  Description : a library of C functions for biological sequence analysis

 Easel is an ANSI C code library for computational analysis of
 biological sequences using probabilistic models. Easel is used by
 HMMER, the profile hidden Markov model software that underlies the
 Pfam protein families database, and by Infernal, the profile
 stochastic context-free grammar software that underlies the Rfam RNA
 family database. Easel aims to make similar applications more robust
 and easier to develop, by providing a set of reusable, documented, and
 well-tested functions.

Several existing packages contain code copies and it is high time this and the 
example
apps were seperately packaged.

This will be team maintained by Debian Med

Bug#851488: ITP: python-gffutils -- Work with GFF and GTF files in a flexible database framework

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: python-gffutils
  Version : 0.8.7.1
  Upstream Author : Ryan Dale 
* URL : http://daler.github.io/gffutils/
* License : MIT
  Programming Lang: Python
  Description : Work with GFF and GTF files in a flexible database framework

 A Python package for working with and manipulating the GFF and GTF format
  files typically used for genomic annotations.  Files are loaded into a
   sqlite3 database, allowing much more complex manipulation of hierarchical
features (e.g., genes, transcripts, and exons) than is possible with
 plain-text methods alone.

Dependency of bcbio, to be team maintained by Debian Med

Bug#851358: ITP: python-pybedtools -- Python wrapper around BEDTools for bioinformatics work

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: python-pybedtools
  Version : 0.7.8
  Upstream Author : Ryan Dale 
* URL : https://github.com/daler/pybedtools
* License : GPL 2+
  Programming Lang: Python, Cython, 
  Description : Python wrapper around BEDTools for bioinformatics work


The BEDTools suite of programs is widely used for genomic interval
 manipulation or “genome algebra”. pybedtools wraps and extends BEDTools and
  offers feature-level manipulations from within Python.

Dependency for bcbio; and will be team maintained by Debian Med

Bug#841047: ITP: r-hms-dbmi-spp -- GNU R package for processing ChIP-seq & other functional sequencing data

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-hms-dbmi-spp
  Version : 1.14
  Upstream Author : peterK 
* URL : http://compbio.med.harvard.edu/Supplements/ChIP-seq/
* License : GPL-2
  Programming Lang: R, C++
  Description : GNU R package for processing ChIP-seq & other functional 
sequencing data

A set of routines for reading short sequence alignments, calculating tag
density, estimates of statistically significant enrichment/depletion
along the chromosome, identifying point binding positions (peaks), and
characterizing saturation properties related to sequencing depth.

Dependency of phantompeakqualtools, a dependency of the new pRSEM feature in
rsem. Will be group maintained by the Debian Med team.

Bug#834592: ITP: hisat2 -- graph-based alignment of short nucleotide reads to many genomes

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: hisat2
  Version : 2.0.4
  Upstream Author : HISAT2 team 
* URL : https://ccb.jhu.edu/software/hisat2/index.shtml
* License : GPL-3+
  Programming Lang: Perl, Python, C++
  Description : graph-based alignment of short nucleotide reads to many 
genomes

 HISAT2 is a fast and sensitive alignment program for mapping next-generation
 sequencing reads (both DNA and RNA) to a population of human genomes (as well
 as against a single reference genome). Based on an extension of BWT for graphs
 a graph FM index (GFM) was designed and implementd. In addition to using
 one global GFM index that represents a population of human genomes, HISAT2
 uses a large set of small GFM indexes that collectively cover the whole genome
 (each index representing a genomic region of 56 Kbp, with 55,000 indexes
 needed to cover the human population). These small indexes (called local
 indexes), combined with several alignment strategies, enable rapid and
 accurate alignment of sequencing reads. This new indexing scheme is called a
 Hierarchical Graph FM index (HGFM).

hisat2 will be team-maintained by the Debian Med team.

Bug#828850: ITP: r-bioc-deseq2 -- R package for RNA-Seq Differential Expression Analysis

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-bioc-deseq2
  Version : 1.12.3
  Upstream Author : Michael Love 
* URL : https://bioconductor.org/packages/DESeq2
* License : LGPL-3+
  Programming Lang: R
  Description : R package for RNA-Seq Differential Expression Analysis

Differential gene expression analysis based on the negative binomial
distribution. Estimate variance-mean dependence in count data from
high-throughput sequencing assays and test for differential expression based
on a model using the negative binomial distribution.

Popular bioinformatics tool/library; team maintained by Debian Med

Bug#828796: ITP: r-bioc-geneplotter -- R package of functions for plotting genomic data

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-bioc-geneplotter
  Version : 1.50.0
  Upstream Author : Bioconductor Package Maintainer 

* URL : http://bioconductor.org/packages/geneplotter/
* License : Artistic-2.0
  Programming Lang: R
  Description : R package of functions for plotting genomic data

geneplotter contains plotting functions for microarrays

Dependency for r-bioc-deseq2; team mainted by Debian Med

Bug#828690: ITP: r-cran-pscbs -- R package: Analysis of Parent-Specific DNA Copy Numbers

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-pscbs
  Version : 0.61.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/PSCBS
* License : GPL-2+
  Programming Lang: R
  Description : R package: Analysis of Parent-Specific DNA Copy Numbers

Segmentation of allele-specific DNA copy number data and detection of regions
 with abnormal copy number within each parental chromosome. Both tumor-normal
 paired and tumoronly analyses are supported.

Prerequisite for cnvkit, to be maintained by Debian Med

Bug#828197: ITP: r-cran-future -- R package: A Future API for R

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-future
  Version : 1.0.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/future
* License : LGPL-2.1+
  Programming Lang: R
  Description : R package: A Future API for R

In programming, a future is an abstraction for a value that may be available
 at some point in the future. The state of a future can either be unresolved or
 resolved. As soon as it is resolved, the value is available. Futures are
 useful constructs in for instance concurrent evaluation, e.g. parallel
 processing and distributed processing on compute clusters. The purpose of this
 package is to provide a lightweight interface for using futures in R.

A dependency of r-cran-pscbs, team maintained by Debian Med

Bug#828196: ITP: r-cran-globals -- R package: Identify Global Objects in R Expressions

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-globals
  Version : 0.6.1
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/globals
* License : LGPL-2.1+
  Programming Lang: R
  Description : R package: Identify Global Objects in R Expressions

 Identifies global ("unknown") objects in R expressions by code inspection
 using various strategies, e.g. conservative or liberal. The objective of this
 package is to make it as simple as possible to identify global objects for the
 purpose of exporting them in distributed compute environments.

Dependency of r-cran-future, will be team maintained by Debian Med

Bug#828194: ITP: r-cran-listenv -- R package: Environments Behaving (Almost) as Lists

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-listenv
  Version : 0.6.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/listenv
* License : LGPL 2.1+
  Programming Lang: R
  Description : R package: Environments Behaving (Almost) as Lists

List environments are environments that have list-like properties. For
 instance, the elements of a list environment are ordered and can be accessed
 and iterated over using index subsetting, e.g. 'x <- listenv(a=1, b=2); for (i
 in seq_along(x)) x[[i]] <- x[[i]]^2; y <- as.list(x)'.

A dependency of r-cran-pscbs, will be team maintained by Debian Med.

Bug#828189: ITP: r-bioc-dnacopy -- R package: DNA copy number data analysis

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-bioc-dnacopy
  Version : 1.46.0
  Upstream Author : Venkatraman E. Seshan 
* URL : 
http://www.bioconductor.org/packages/release/bioc/html/DNAcopy.html
* License : GPL-2.0+
  Programming Lang: R
  Description : R package: DNA copy number data analysis

 Implements the circular binary segmentation (CBS) algorithm to segment DNA
 copy number data and identify genomic regions with abnormal copy number.
 .
 This package is for analyzing array DNA copy number data, which is usually
 (but not always) called array Comparative Genomic Hybridization (array CGH)
 data It implements a methodology for finding change-points in these data which
 are points after which the (log) test over reference ratios have changed
 location. This model is that the change-points correspond to positions where
 the underlying DNA copy number has changed. Therefore, change-points can be
 used to identify regions of gained and lost copy number. We also provide a
 function for making relevant plots of these data.

This is a dependency for r-cran-pscbs and will be team maintained by the Debian 
Med team

Bug#828184: ITP: r-cran-r.cache -- R package: Fast and Light-Weight Caching of Objects and Results

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-cran-r.cache
  Version : 0.12.0
  Upstream Author : Henrik Bengtsson 
* URL : https://github.com/HenrikBengtsson/R.cache
* License : LGPL (>= 2.1)
  Programming Lang: R
  Description : R package: Fast and Light-Weight Caching of Objects and 
Results

Memoization can be used to speed up repetitive and computational expensive
function calls.  The first time a function that implements memoization is
called the results are stored in a cache memory.  The next time the function is
called with the same set of parameters, the results are momentarily retrieved
from the cache avoiding repeating the calculations.  With this package, any R
object can be cached in a key-value storage where the key can be an arbitrary
set of R objects.  The cache memory is persistent (on the file system).

Dependency of r-cran-pscbs, will be team maintained by the Debian Med team

Bug#828176: ITP: cnvkit -- Copy number variant detection from targeted DNA sequencing

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: cnvkit
  Version : 0.7.11
  Upstream Author : Eric Talevich 
* URL : http://cnvkit.readthedocs.io/
* License : Apache-2.0
  Programming Lang: Python
  Description : Copy number variant detection from targeted DNA sequencing

A command-line toolkit and Python library for detecting copy number variants
and alterations genome-wide from targeted DNA sequencing. It is designed for
use with hybrid capture, including both whole-exome and custom target panels,
and short-read sequencing platforms such as Illumina and Ion Torrent.

Will be team maintained by the Debian Med team

Bug#823512: ITP: mypy -- Optional static typing for Python

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: mypy
  Version : 0.3.1
  Upstream Author : Jukka Lehtosalo 
* URL : http://www.mypy-lang.org/
* License : MIT
  Programming Lang: Python
  Description : Optional static typing for Python

Add type annotations to your Python programs, and use mypy to type check them.
Mypy is essentially a Python linter on steroids, and it can catch many
programming errors by analyzing your program, without actually having to run
it. Mypy has a powerful type system with features such as type inference,
gradual typing, generics and union types.

This package is useful for every Python developer. It will be group maintained
by the Debain Med team.

Re: Parallel software performance analysis

[Michael R. Crusoe]

Hello Jonathan,

The Debian-Med team is considering plans for optimising large parts of the
scientific software in Debian /en masse/.

Many of the participants work for EU organisation.

I'm sure they would appreciate your participation:
https://lists.debian.org/debian-med/2016/03/msg00152.html

Cheers,

On Thu, Mar 31, 2016 at 3:58 PM, Jonathan Boyle <jonathan.bo...@nag.co.uk>
wrote:

> Dear All
>
>
>
> I’m currently involved in a EU funded project to help EU organisations
> (e.g. academia and industry) improve performance of parallel software by
> analysing performance and making recommendations on how to improve. These
> services are free of charge to EU organisations.
>
>
>
> It’s important to realise we don’t offer to refactor code, and the code
> analysis tools are designed for typical HPC software, e.g. MPI & OpenMP
> running on Linux/Unix, which will undoubtedly place limits on who we can
> help.
>
>
>
> This could be useful to someone developing or using parallel software so I
> thought I’d send details to the list. There’s more information on the
> website https://pop-coe.eu/services including how to apply.
>
>
>
> Please feel free to send on the information to anyone who might be
> interested, or to get in touch with myself to discuss further.
>
>
>
> Best wishes
>
> Jonathan
>
>
>
> Jonathan Boyle
>
> HPC Application Analyst
>
> Numerical Algorithms Group (NAG)
>
> Peter House, Oxford Street, Manchester, M1 5AN
>
> +44 (0)161 602 3821
>
> http://nag.co.uk/
>
>
>
>
>
>
>



-- 
Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu
Common Workflow Language projectUniversity of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe

Bug#817056: ITP: python-typing -- Type Hints for Python

[Michael R. Crusoe]

See
https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code
Pe 8 mar. 2016 06:24, "Brian May" <b...@debian.org> a scris:

> "Michael R. Crusoe" <cru...@ucdavis.edu> writes:
>
> >  This is a backport of the standard library typing module to Python
> >  versions older than 3.5.
>
> Not sure what the point of this is; doesn't typing hinting require PEP
> 3107, which isn't in Python 2.x?
> --
> Brian May <b...@debian.org>
>

Bug#817056: ITP: python-typing -- Type Hints for Python

[Michael R. Crusoe]

That was my plan. Though I just realized that I don't need this if I switch
to building only the Python 3 version of schema-salad-tool so I am likely
to close this ITP.

The package is at git+ssh://git.debian.org/git/debian-med/python-typing.git
if anyone is interested.

On Mon, Mar 7, 2016 at 7:38 PM, Scott Kitterman <deb...@kitterman.com>
wrote:

> On Monday, March 07, 2016 09:01:30 AM Michael R. Crusoe wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Debian Med team <debian-med@lists.debian.org>
> >
> > * Package name: python-typing
> >   Version : 3.5.0.1
> >   Upstream Author : Guido van Rossum, Jukka Lehtosalo, Łukasz Langa
> > <jukka.lehtos...@iki.fi> * URL :
> > https://docs.python.org/3.5/library/typing.html * License :
> Python
> > 2.0
> >   Programming Lang: Python
> >   Description : Type Hints for Python
> >
> >  This is a backport of the standard library typing module to Python
> >  versions older than 3.5.
> >
> >  Typing defines a standard notation for Python function and variable
> >  type annotations. The notation can be used for documenting code in a
> >  concise, standard format, and it has been designed to also be used by
> >  static and runtime type checkers, static analyzers, IDEs and other
> >  tools.
> >
> > This is a new dependency for python-schema-salad, and will be for any
> other
> > Py2/Py3 package that contains typing hints. It will be maintained by the
> > Debian-Med team but I'm happy to hand it over to other interested
> parties.
>
> Please only package this for python(2).  We are in the process of dropping
> python3.4, so a python3 package isn't needed.
>
> Scott K
>



-- 
Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu
Common Workflow Language projectUniversity of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe

Bug#817056: ITP: python-typing -- Type Hints for Python

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: python-typing
  Version : 3.5.0.1
  Upstream Author : Guido van Rossum, Jukka Lehtosalo, Łukasz Langa 

* URL : https://docs.python.org/3.5/library/typing.html
* License : Python 2.0
  Programming Lang: Python
  Description : Type Hints for Python

 This is a backport of the standard library typing module to Python
 versions older than 3.5.
 
 Typing defines a standard notation for Python function and variable
 type annotations. The notation can be used for documenting code in a
 concise, standard format, and it has been designed to also be used by
 static and runtime type checkers, static analyzers, IDEs and other
 tools.

This is a new dependency for python-schema-salad, and will be for any other
Py2/Py3 package that contains typing hints. It will be maintained by the
Debian-Med team but I'm happy to hand it over to other interested parties.

Re: bamtools_2.4.0+dfsg-4_amd64.changes REJECTED

[Michael R. Crusoe]

Can I get bamtools 2.4.0+dfsg-4 sponsored? I split the library
documentation into a separate package so I can't upload on my own.

On Sat, Mar 5, 2016 at 8:21 PM, Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:

>
>
> ACL dm: NEW uploads are not allowed
>
> ===
>
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
>
>


-- 
Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu
Common Workflow Language projectUniversity of California, Davis
https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe

Bug#814000: ITP: cwltool -- Common workflow language reference implementation

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: cwltool
  Version : 1.0.20160203221531
  Upstream Author : Common Workflow Language working group 

* URL : http://www.commonwl.org
* License : Apache-2.0
  Programming Lang: Python
  Description : Common workflow language reference implementation

This is the reference implementation of the Common Workflow Language. It is
intended to be feature complete and provide comprehensive validation of CWL
files as well as provide other tools related to working with CWL.

This is written and tested for Python 2.7.

The reference implementation consists of two packages. The "cwltool" package
is the primary Python module containing the reference implementation in the
"cwltool" module and console executable by the same name.

The "cwl-runner" package is optional and provides an additional entry point
under the alias "cwl-runner", which is the implementation-agnostic name for the
default CWL interpreter installed on a host.

The Debian Med team will be maintaining this package. I am also the CWL
Community Engineer.