Bug#1037221: Aw: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to support Bullseye version for 3-4 years?

[Steffen Möller]

> Gesendet: Samstag, 10. Juni 2023 um 18:15 Uhr
> Von: "Andy Pugh" 
> An: "EMC developers" 
> Cc: 1037...@bugs.debian.org
> Betreff: [Emc-developers] Bug#1037221: Bug#1037221: linuxcnc: Prepared to 
> support Bullseye version for 3-4 years?
>
> 
> 
> > On 10 Jun 2023, at 16:34, Petter Reinholdtsen  wrote:
> > 
> > [Andy Pugh]
> >> I don't fully understand the question.
> > 
> > The purpose of my question is to make sure the project understand the
> > current version in Debian Testing is the one that will be around in
> > Debian for the duration of Debian 12 Bookworm
> 
> Is there really no opportunity to push an updated version at this point? 
> 
> I suppose we can always point users at our own repository if they want the 
> new stuff (like the Mesa modbus driver)

I backport sounds reasonable to me. Would want to wait for the official 2.9 in 
Debian testing, though.

Steffen

Bug#1032975: Aw: Steffen, please raise your opinion about igdiscover

[Steffen Möller]

Hi Andreas,

I am afraid I cannot put the extra effort into those packages and, admittedly, 
the NCBI software suite is just a bit intimidating, too. Please remove those 
packages from testing and if nobody shows any interest in the required updates 
then eventually those packages should also be removed from unstable.

Thank you tons,
Steffen

Bug#1021041: Aw: Bug#1021041: ITP: parallel-hashmap --

[Steffen Möller]

Hi Andrius,
Thank you tons, yes, by all means, please proceed.
Best,
Steffen

> Gesendet: Mittwoch, 15. Februar 2023 um 08:12 Uhr
> Von: "Andrius Merkys" 
> An: 1021...@bugs.debian.org, "Steffen Moeller" 
> Betreff: Bug#1021041: ITP: parallel-hashmap --  description>
>
> Hi Steffen,
>
> On Fri, 30 Sep 2022 23:50:47 +0200 Steffen Moeller 
> wrote:
> > Subject: ITP: parallel-hashmap -- 
> > Package: wnpp
> > Owner: Steffen Moeller 
> > Severity: wishlist
>
> I found your ITP and initial packaging for parallel-hashmap. I need this
> library to package pytorch-sparse (#1031265). Is it OK if I finalise and
> upload it, or do you prefer to do so yourself?
>
> Best wishes,
> Andrius
>

Bug#1014274: yosys RM of s390x should be requested, too

[Steffen Möller]

Dear all,

The s390x package of yosys is no longer built, either, and should hence
also be removed, see https://tracker.debian.org/pkg/yosys . Does this
need a separate RM?

Many thanks!

Steffen

Bug#1014100: We should do an update of all qiime2 modules as soon as possible (Was: Bug#1014100: qiime: autopkgtest needs update for new version of python-decorator)

[Steffen Möller]

On 30.06.22 11:51, Andreas Tille wrote:

I'd like to point out to this serious bug.  Steffen, would you mind
koordinating (not doing alone) an upgrade of the qiime infrastructure to
make sure everything will go smoothly?

I added "to be updated" tags to all the qiime2 packages on

https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=1986383821

Yes, these updates are overdue. I'll see what I can do, help is of
course much appreciated.

Many thanks!

Steffen

Bug#1012789: linucnc runtime prob with tiff is because of tiff

[Steffen Möller]

The problem is with the tiff library. On
https://github.com/LinuxCNC/linuxcnc/pull/1700 it is explained how to
install an earlier version from snapshot.debian.org

To trigger the problem independently from linuxcnc, try

$ wish
% package require Img

Bug#1012789: tk Img error while importing

[Steffen Möller]

The same error is triggered from within Tcl/Tk. LinuxCNC I do not think
to be to blame.

$ wish
% package require Img
couldn't load file
"/usr/lib/tcltk/x86_64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so":
/usr/lib/tcltk/x86_64-linux-gnu/Img1.4.13/libtifftcl4.1
.0.so: undefined symbol: _TIFFsetString, version LIBTIFF_4.0^

Bug#1003968: [Pkg-electronics-devel] Bug#1003968: fpga-icestorm: icetime looking in wrong directory for chipdb files

[Steffen Möller]

Uploaded.

On 18.01.22 20:41, Daniel Gröber wrote:

Hi Scott,

Thanks, for the report.

On Tue, Jan 18, 2022 at 05:50:58PM +, Scott Ashcroft via 
Pkg-electronics-devel wrote:

icetime seems to be looking in /usr/local/share/icebox and
/usr/bin/../share/icebox for chipdb files instead of /usr/share/fpga-
icestorm/chipdb.

Looks like we dropped a patch that had a fix for this lumped in.

I've pushed a fix to salsa[1] and I'm pinging Steffen to sponsor the
upload.

[1]: 
https://salsa.debian.org/electronics-team/fpga-icestorm/-/commit/65390136afafd321515c76cb7fb725ab4f02d151

--Daniel

Bug#999632: r-bioc-isoformswitchanalyzer FTBFS: ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available

[Steffen Möller]

On 14.11.21 08:47, Andreas Tille wrote:

Control: blocked -1 by 995252

Hi Steffen


ERROR: dependencies ‘DRIMSeq’, ‘tximeta’ are not available for package 
‘IsoformSwitchAnalyzeR’

r-bioc-tximeta is in Debian and just needs to be mentioned in
Build-Depends.  However, Git seems not to be up to date so please push.

Seems like we have a race condition. I dumped my local one and
routine-updated what was in salsa.


What is the status of r-bioc-drimseq?  I have not found it in new neither
did I found any mentioning it on the maintainers list.


g...@salsa.debian.org:r-pkg-team/r-bioc-drimseq.git

Seems like I had not uploaded it. Just upgraded it to a newer version
and sent it away.


PS: Please use a chroot when building your packages.


I typically do. For the ones with build dependencies in the NEW queue I
once had my own local repository but at some point stopped doing that.

Steffen

Bug#984243: Help: mothur: ftbfs with GCC-11

[Steffen Möller]

On 21.10.21 20:21, Étienne Mollier wrote:

Hi Andreas,

Andreas Tille, on 2021-10-21:

In file included from addtargets2.cpp:3:
myutils.h:176:1: error: reference to 'byte' is ambiguous

Since C++ 2017, the std::byte type is defined:


   176 | byte *ReadAllStdioFile(FILE *f, off_t );
   | ^~~~
In file included from /usr/include/c++/11/bits/stl_algobase.h:61,
  from /usr/include/c++/11/bits/char_traits.h:39,
  from /usr/include/c++/11/string:40,
  from myutils.h:8,
  from addtargets2.cpp:3:
/usr/include/c++/11/bits/cpp_type_traits.h:404:30: note: candidates are: 'enum 
class std::byte'

The redefinition below thus gives indeterminations, as the code
is running in namespace "std":


In file included from addtargets2.cpp:3:
myutils.h:42:23: note: 'typedef unsigned char byte'
42 | typedef unsigned char byte;
   |   ^~~~
myutils.h:177:1: error: reference to 'byte' is ambiguous

The option which seems the most viable would be to replace all
occurrences of the "byte" type by something that does not clash
with the new standard library, maybe "byte8" to be somewhat
consistent with upstream naming conventions.


In hope this helps,

Have a nice evening,  :)


My C++ skills are a bit rosty but would removing the typedef for byte
solve the problem?

Best,
Steffen

Bug#969416: LinuxCNC is coming to Debian

[Steffen Möller]

Petter kindly got in touch about me supporting the LinuxCNC developers
in their packaging and an eventual upload to Debian. So, it is happening
and we happily close this RFP with the upload. The package will be
maintained by the LinuxCNC developers as DMs with me (or Petter, I
presume) sponsoring in the meantime.

Best,
Steffen

Bug#995723: r-cran-dbscan_1.1-8+ds-1_amd64.changes REJECTED

[Steffen Möller]

Hello,

I admit not to recall if I had responded, but I had "-sa"-uploaded a
fixed version -2.

Many thanks to you all
Steffen

On 11.10.21 16:47, Andreas Tille wrote:

Hi Thorsten,

just in case Steffen had not responded and to have a record in the ITP bug:
A fixed package was uploaded to new.

Kind regards and thanks for your work as ftpmaster

 Andreas.

Am Sun, Oct 10, 2021 at 06:00:09PM + schrieb Thorsten Alteholz:

Hi Steffen,

please also mention at least University of Maryland as copyright holder in your 
debian/coypright.

Thanks!
  Thorsten

Bug#989866: ITP: illustrate -- cartoonish representations of large biological molecules

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : illustrate
  Version : 0.0+git20200923.217db48
  Upstream Author : David S Goodsell
* URL : https://github.com/ccsb-scripps/Illustrate
* License : Apache-2.0
  Programming Lang:  Fortran
  Description : cartoonish representations of large biological
molecules
 This package provides a binary to transform PDF-formatted proteins into
 simplified but instructive graphics. The software has been used for
 the Protein-of-the-month's biomolecular illustrations for the past 20
 years.

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

Bug#989535: ITP: cmdock -- fit chemical compounds to proteins and nucleotides

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name    : cmdock
  Version : 0.1.3
  Upstream Author : RiboTargets (subsequently Vernalis (R) Ltd)
* URL : https://sidock.si
* License : LGPL-3.0+
  Programming Lang: C
  Description : fit chemical compounds to proteins and nucleotides
 This tool for molecular docking / in silico drug screening is a
 derivatrive of rDock and core to the SiDock@Home project to
 find inhibitors of the SARS-CoV-2 virus.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/cmdock

Bug#989465: ITP: pythondata-software-compiler-rt -- extends compiler_rt for Python usage

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : pythondata-software-compiler-rt
  Version : 2020.08
  Upstream Author : Copyright: LiteX Authors 
* URL :
https://github.com/litex-hub/pythondata-software-compiler_rt
* License : MIT
  Programming Lang: Python
  Description : extends compiler_rt for Python usage
 Non-Python files needed for the software compiler_rt packaged
 into a Python module so they can be used with Python libraries
 and tools. It is developed in the context of hardware programming
 with LiteX.

Remark: This package is maintained by Debian Electronics Team at
https://salsa.debian.org/electronics-team/pythondata-software-compiler-rt

LiteX is the diver of this development, which is why this package is not
uploadeded to the Python salsa repository.

Bug#989015: ITP: catfishq -- concatenates fastq files

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: catfishq
  Version : 1.1.3+ds
  Upstream Author : philres
* URL : https://github.com/philres/catfishq
* License : MIT
  Programming Lang: Python
  Description : concatenates fastq files
 FASTQ is the most common format to store the reads from high-throughput
 biological sequencing. This tool takes paths to an arbritary number
 of zipped and unzipped FASTQ files and/or folders containing zipped or
 unzipped FASTQ files, concatenates them and prints them to standard out
 (default) or an unzipped output file.
 .
 Supported file extensions are: '*.fastq', '*.fastq.gz', '*.fasta',
 '*.fasta.gz', '*.fa', '*.fa.gz', '*.fq', '*.fq.gz'

Remark: This package is about to be team-maintained
   https://salsa.debian.org/med-team/catfishq

Bug#989014: vcflib: executables in scripts/* are not packaged

[Steffen Möller]

Source: libvcflib
Severity: normal

A reminder to self.

Bug#988822: ITP: pyensembl -- installs data from the Ensembl genome database

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : pyensembl
  Version : 1.9.1+ds
  Upstream Author : Copyright: Alex Rubinsteyn 
* URL : https://github.com/openvax/pyensembl
* License : Apache-2.0
  Programming Lang: Python
  Description : installs data from the Ensembl genome database
 The Ensembl genome database is an established reference
 for genomic sequences and their automated annotation.
 To have this data local has advantages for bulk analyses,
 e.g. for the mapping of reads from RNA-seq against the
 latest golden path - or a previous one to compare analyses.
 .
 This package provides a reproducible way to insatll this
 data and thus simplify the automation of respective
 workflows.

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

Bug#988821: ITP: python-memoized-property -- decorator to avoid redundant computation

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : python-memoized-property
  Version : 1.0.3
  Upstream Author : Copyright: Steven Cummings 
* URL : https://github.com/estebistec/python-memoized-property
* License : BSD-3-Clause
  Programming Lang: Python
  Description : decorator to avoid redundant computation
 This package allows to tag methods that have may have their
 result buffered to save redundant computation, as in:
   @memoized_property
   def name(self):
   return some_expensive_load()

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-memoized-property

Bug#988806: ITP: python-serializable -- base class with serialization methods

[Steffen Möller]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: python-serializable -- base class with serialization methods
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : python-serializable
  Version : 0.2.1
  Upstream Author : . Mount Sinai School of Medicine
* URL : https://github.com/iskandr/serializable
* License : Apache-2.0
  Programming Lang: Python
  Description : base class with serialization methods
 "Serialisation" refers to the transformation of objects into
 a bitstream and back into the original structure. The idea
 expressed by this class has a direct analogy to Java:
 A method is declared thattransform the object into, e.g., a
 JSON formatted file. Another method knows how to reinstantiate
 the object from that output.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-serializable

Bug#988801: ITP: python-gtfparse -- parser for gene transfer format (aka GFF2)

[Steffen Möller]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: moel...@debian.org

Subject: ITP: python-gtfparse -- parser for gene transfer format (aka GFF2)
Package: wnpp
Owner:  Steffen 
Severity: wishlist

* Package name    : python-gtfparse
  Version : 1.2.1
  Upstream Author : Copyright:  
* URL : https://github.com/openvax/gtfparse
* License : Apache-2.0
  Programming Lang: Python
  Description : parser for gene transfer format (aka GFF2)
 You find a gene in the genome? Or a feature about it?
 The gene transfer format (GTF, identical to GFF2)
 allows your program or your database to exchange
 this information so it can be presented with genome
 browsers or used e.g. as a selection for other features
 like nucleotide variants.
 .
 This package provides a parser for GTF/GFF2 files, i.e.
 sets of routines that read that file and support the
 computational interpretation of these data.

Remark: This package is maintained by steffen at
   https://salsa.debian.org/med-team/python-gtfparse

Bug#988723: ITP: python-datacache -- helpers for transparently downloading datasets

[Steffen Möller]

Subject: ITP: python-datacache -- 
Package: wnpp
Owner:  Steffen 
Severity: wishlist

* Package name    : python-datacache
  Version : 0.4.7
  Upstream Author : Copyright: Alex Rubinsteyn 
* URL : https://github.com/openvax/datacache
* License : Apache-2.0
  Programming Lang: Python
  Description : helpers for transparently downloading datasets

Remark: This package is maintained by steffen at
https://salsa.debian.org/med-team/python-datacache

Bug#988720: ITP: python-typechecks -- express constraints on types

[Steffen Möller]

Package: wnpp
Severity: wishlist

* Package name    : python-typechecks
  Version : 0.1.0
  Upstream Author : Copyright:  
* URL : https://github.com/openvax/typechecks
* License : Apache-2.0
  Programming Lang: Python
  Description : express constraints on types
 Variables in Python are just that - variable. Sometimes
 though you want to make sure that a variable is of a
 particular type, like an integer, a string or a something
 to iterate (loop) through.
 .
 To express such constraints on the type that a variable
 may have in the code, such that the program can react
 to it at runtime, this small modules provides a set of
 routines.

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

Bug#988690: ITP: xpore -- Nanopore analysis of differential RNA modifications

[Steffen Möller]

Package: wnpp
Severity: wishlist

* Package name    : xpore
  Version : 1.0
  Upstream Author : Ploy N. Pratanwanich 
* URL : https://github.com/GoekeLab/xpore/
* License : Expat
  Programming Lang: Python
  Description : Nanopore analysis of differential RNA modifications
 RNA is transcribed from DNA, possibly spliced and exported to the
 cytoplasm - fine - but its bases can also be modified, edited, and
 not all such modifications are visible by Sanger sequencing methods
 and its derivatives.
 .
 The Nanopore measures potentials, and if the bases have a different
 shape then this is measured - not necessarily in an interpretable manner,
 something must be left for mass spectrometry, but one may be pointed
 to a difference. And maybe one can even statistically associate such
 differences with a molecular or clinical phenotype.

Remark: This package is maintained at
   https://salsa.debian.org/med-team/xpore

Bug#988183: gemma ftbfs on buster, newer version builds fine one bullseye

[Steffen Möller]

Would a regular backport be the way to go?

Bug#954170: Help: Test suite failures (Was: ITP: anndata -- Annotated gene by sample numpy matrix)

[Steffen Möller]

Hi all,

Am 06.11.20 um 23:20 schrieb Diane Trout:
> On Fri, 2020-11-06 at 08:23 +0100, Andreas Tille wrote:
>> Dear Diane,
>>
>> would you mind pushing your patch to the Git repository?  I mean its
>> your ITP and you are Uploader - so I hesitate to push your very own
>> patch on behalf of you. ;-)
>>
>> Thanks a lot for your helpful hints and contacting upstream
> I pushed the patches... Is there anything else anyone wants to do to
> the package or should I submit to NEW?

To me, https://salsa.debian.org/med-team/python-anndata looks fine,
except that it reads "UNRELEASED" :) . Or did anthing happen in the
meantime that I have missed?

I am perfectly happy with an upload. Please go ahead, with a bit of luck
we make it into the release, still.

Best,

Steffen

Bug#980972: xxsds-dynamic: Changelog entry missing trailer line

[Steffen Möller]

Thank you, Logan.

I just fixed that and uploaded. Nothing new from upstream.

Steffen

Bug#969904: ITP: libwww-curl-simple-perl -- Simpler interface to WWW::Curl

[Steffen Möller]

Hi Andreas,

On 08.09.20 18:19, Andreas Tille wrote:
> Debian has libwww-curl-perl.  What is the difference to this "simple"
> version
I said it in the description: You create simple one-liners with the very
popular curl library.
> and do we really need this?
Yes. Google points you (almost) directly to it when you ask for "how to
retrieve a web resource with Perl".
> For the actual packaging in Git[1]: Please fix the spelling of the
> Vcs-Fields (letter after '-' should be upper case.  There is also
>
>Copyright: ,
>
> in d/copyright.
Fixed. And lintian clean now.

Thanks!

Steffen

Bug#966452: ITP: r-bioc-biocsingular -- Singular Value Decomposition for Bioconductor Packages

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : r-bioc-biocsingular
 Version : 1.4.0
 Upstream Author : Aaron Lun
* URL : https://bioconductor.org/packages/BiocSingular/
* License : GPL-3
 Programming Lang: GNU R
 Description : Singular Value Decomposition for Bioconductor Packages
Implements exact and approximate methods for singular value
decomposition and principal components analysis, in a framework that
allows them to be easily switched within Bioconductor packages or
workflows. Where possible, parallelization is achieved using
the BiocParallel framework.

Remark: This package is maintained by Debian R Packages Maintainers at
  https://salsa.debian.org/r-pkg-team/r-bioc-biocsingular

Bug#948919: sambama FTBFS: asked htslib about missing patch

[Steffen Möller]

https://github.com/samtools/htslib/issues/1098

Bug#948919: sambamba - htslib needs patch - guix - has the answer

[Steffen Möller]

http://git.genenetwork.org/guix-bioinformatics/guix-bioinformatics/src/commit/a2a200402b91a352dbdede01eec85accb892b8e1/htslib-add-cram_to_bam.patch

That patch just makes the cram_to_bam routine visible and should be
adopted without danger.

Steffen

Bug#961233: ITP: jsmn -- header-only JSON library

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : jsmn
  Version : 1.1.0
  Upstream Author : Serge A. Zaitsev
* URL : https://github.com/zserge/jsmn
* License : MIT
  Programming Lang: C
  Description : header-only JSON library
 Philosophy
 .
 Most JSON parsers offer you a bunch of functions to load JSON data,
 parse it and extract any value by its name. jsmn proves that checking
 the correctness of every JSON packet or allocating temporary objects
 to store parsed JSON fields often is an overkill.
 .
 JSON format itself is extremely simple, so why should we complicate it?
 .
 jsmn is designed to be robust (it should work fine even with erroneous
 data), fast (it should parse data on the fly), portable (no superfluous
 dependencies or non-standard C extensions). And of course, simplicity is
 a key feature - simple code style, simple algorithm, simple integration
 into other projects.
 .
 Features
 .
  * compatible with C89
  * no dependencies (even libc!)
  * highly portable (tested on x86/amd64, ARM, AVR)
  * about 200 lines of code
  * extremely small code footprint
  * API contains only 2 functions
  * no dynamic memory allocation
  * incremental single-pass parsing
  * library code is covered with unit-tests

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/science-team/jsmn

Bug#960368: kallisto_0.46.2+dfsg-1_source.changes ACCEPTED into unstable

[Steffen Möller]

I was not aware of that, admittedly, just did a routine-update. But the
build is clean. Can we integrate the test in the build, then?

On 15.05.20 13:53, Andreas Tille wrote:


Hi Steffen,

considering bug #960368 it was probably no good idea to upload.  Or did
you tested the upstream tests before uploading?  If not bug #960368
might be RC now. :-(

Kind regards

 Andreas.

On Fri, May 15, 2020 at 11:33:57AM +, Debian FTP Masters wrote:


Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 May 2020 13:12:09 +0200
Source: kallisto
Architecture: source
Version: 0.46.2+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Med Packaging Team 

Changed-By: Steffen Moeller 
Changes:
  kallisto (0.46.2+dfsg-1) unstable; urgency=medium
  .
* Team upload.
* New upstream version
* Standards-Version: 4.5.0 (routine-update)
* Add salsa-ci file (routine-update)
* Rules-Requires-Root: no (routine-update)
* Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
  Repository-Browse.
* Remove obsolete field Name from debian/upstream/metadata (already
  present in machine-readable debian/copyright).
Checksums-Sha1:
  748a94aa9df165cf079d38a2ac992fefa9bb45a1 2115 kallisto_0.46.2+dfsg-1.dsc
  9cd6f32f91c9b65e54f0d86de9f67ce1c988d1ae 1076104 
kallisto_0.46.2+dfsg.orig.tar.xz
  22e1af49ea502a3137f0196bd1f742366338b407 6056 
kallisto_0.46.2+dfsg-1.debian.tar.xz
  2dcfbd5867f0c97cec06026ffa25e72c007fb9e2 7340 
kallisto_0.46.2+dfsg-1_source.buildinfo
Checksums-Sha256:
  c1bdf3beeb0e9d1497cf68b52b82e2e757cea36d5459ed508bd9d56d03d8d774 2115 
kallisto_0.46.2+dfsg-1.dsc
  b92d212294147e371fc9e77190e6384b3101045af1f832d144101285791b29db 1076104 
kallisto_0.46.2+dfsg.orig.tar.xz
  2feab01c83183a936bba04d1bf108638a12bc2ea0eb07e6631b0ef27fa40e4d1 6056 
kallisto_0.46.2+dfsg-1.debian.tar.xz
  e7913b6d99090b250deb0d4a30ccafb62db0d31de43a55382bfdbfba9842150d 7340 
kallisto_0.46.2+dfsg-1_source.buildinfo
Files:
  1e6bfc35f0b45688b94b543bee2de3ac 2115 science optional 
kallisto_0.46.2+dfsg-1.dsc
  0e8ff786acae328e36281ad930529f98 1076104 science optional 
kallisto_0.46.2+dfsg.orig.tar.xz
  ec8a7e935b70cf65ffb1b1ad418d96dd 6056 science optional 
kallisto_0.46.2+dfsg-1.debian.tar.xz
  cfa8101b986ed28eb5613bc1297f85b3 7340 science optional 
kallisto_0.46.2+dfsg-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEEhMGXeonn7+0+XKYuL9i+2sAg7tEFAl6+eUwTHG1vZWxsZXJA
ZGViaWFuLm9yZwAKCRAv2L7awCDu0aScEACReSt5e3SwbFYfKpVK7h+HXhHRlyoo
OQ3YZ6S4ljj50vEkl1eOFHeu5fv1lzXrvmHFnAkEfdnzxhWsxBJH9LiQ7PLFAg2C
RHYasQPMCpisvri6BSb5IZcZaN1Hi8eXFscW1kzHEBA0bmP2GvwItTLm0Za9C2Qi
Is/h4vTppdHNeWtY56qegin0QIRIypqw31W5NXw5bH0AAU6lioFbn+9pAQVTv+DQ
MkMFwQKZTSQuYuzJEdHv0aiBBH9cZ0Qt4h5q7Rs1JMfr1HMOAvFsiLrTDKy3MFzb
NcncAd5ZCswelMaUyqNxcI0l13ehESWGPwacfANr+fST/bq4EKF4B2hBVfQixW6t
eS9RKzOKnlKmZ+tILutV+QA9OuiFjxoS7StB6cy55uVC3OEXwLZUaT5LiLnGWEpO
4vIpVRq5BGomArtNK2tvCuEnJ6aaTImQDACGhxfy+l1Kvuln8YAnVy7U0H9oActW
G2VaKhRXMCjvSQePREueaphgUd5Y1E8KKbzqOP+k86lZUFYwy0oIM5FAyjNARIAG
iki5ZxXHiKFWDOpB8iEsW854q51/KCeZ9IGwq39VsYJObmPFBX3lyb1ZGCtqT95q
kFTGp75EgdRoUDKuwaaGjU9ARvMmHYCPdn0rZqsV88fMifn/da3EgVzVxfQu1NMh
RruyO90mAuBEbQ==
=diJW
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#949966: libgclib-dev: getLine ABI uses off_t and thus depends on _FILE_OFFSET_BITS

[Steffen Möller]

On 29.01.20 16:26, Helmut Grohne wrote:

Hi Andreas,

On Wed, Jan 29, 2020 at 04:14:26PM +0100, Andreas Tille wrote:

I have implemented a solution in Git[1] but want to discuss other options
here.  Latest upstream version seem to need a SONAME bump anyway as far
as I can see.

You can just set future=-lfs unconditionally. It really affects all
32bit archs. A better check might be $(DEB_HOST_ARCH_BITS)==32, but the
option is meaningless for 64bit, so you can really just set it without
any branching. Please save the next 32bit architecture the trouble from
having to add the option.


I wonder what you think how important large file support in gffread might
be for those rarely used architectures.

I don't make any statement on whether lfs is important. I just figured
that it fails to build from source. I didn't even read the package
description. ;)


Large file support is important for DNA/RNA sequencing. I can well
imagine some smaller machines embedded in some hardware that
create/move/merge files around or edit some metadata within.

Many thanks for addressing this!

Steffen

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[Steffen Möller]

Heya,

Please contact upstream about that GPL-2 vs GPL-2+ issue. They may not
be aware.

Cheers,

Steffen 

On 27.01.20 13:19, Gürkan Myczko wrote:

Hi John,


The package is in great shape. The only challenge to getting the
package in
the archive seems to be the copyright file. Coreboot's README says
Some files are licensed under the "GPL (version 2, or any later
version)",
and some files are licensed under the "GPL, version 2". For some parts,
which were derived from other projects, other (GPL-compatible)
licenses may
apply. Please check the individual source files for details.


That'll be a pain to do but yes.


debian/copyright says most files are GPL 2+, but it my digging
indicates the
majority are GPL 2 only, and I think I saw additional licenses too.


I see, more work.


I believe upstream has recently expressed desire to make listings
files with
respective licenses and/or using SPDX identifiers, rather than their
lengthy
headers in the source. If that's true, checking out the Git version
might help
you parse the licenses.


I heard about that in #coreboot irc channel.


Speaking of which, you repacked Coreboot with the contents of 3rdparty/
removed. As a Libreboot user I thought I understood why, but as best
as I can
tell those files are free. On Coreboot's downloads page they appear to
distribute the blobs separately which is news to me.


Partly removed, half re-added for util/cbfstool to build.


If there really is a problem with those files I would appreciate your
letting
me know what I missed. Otherwise I hope you can avoid the repacking
trouble in
the future.


Probably not, but the repacking is not trouble.


Lastly, a small enhancement is to add a debian/watch file so that
tools can
check for and utilize new upstream versions automagically. I plan to
send a
Salsa merge request with details shortly.


You can save you that pain. I already stole your watch file, now it says:
E: coreboot source: debian-watch-file-pubkey-file-is-missing


I hope my feedback is useful for you to help your package.


Yes appreciated, thank you.

BTW, my latest work is here:
http://phd-sid.ethz.ch/debian/coreboot/
the 4.11 one.

Bug#949730: python -> python3 done in new upload

[Steffen Möller]

A new version 5.7.3 is out, so I have addressed the "python" in the test
routines and wherever I encountered them.

Some tests still fail since files are written to the install folder
where they are not tested. Other comparisons now fail since there is a
linebreak in the help output where there was none before if I interpret
this right. If someone could send a patch for that this would be much
appreciated.

Steffen

Bug#855494: Last chance to fix mgltools-pmv

[Steffen Möller]

I am too busy to chase this all up, I am afraid.

On 07.12.19 09:04, Andreas Tille wrote:

Hi,

I just removed mgltools-pmv from debian-med metapackages to prepare its
removal.  I realised that autodocktools depends mgltools-pmv so this has
to go as well.  Since there is no sign that this 2.5 year old critical
bug is fixed and there is no Python3 port anyway those package should go
and might be re-introduced later.

Steffen, Tony, any thoughts?

Kind regards

   Andreas.

Bug#855494: Broken with different error - I'm going to ask for removal of the package soon

[Steffen Möller]

Hello,

On 08.11.19 23:14, Andreas Tille wrote:

On Fri, Nov 08, 2019 at 06:00:08PM +0100, Michael Crusoe wrote:

I got farther, but now the "dashboard" module won't load (no traceback).
The tests still fail spectacularly.

This is very old and non-free code. I suggest that all mglools* and
autodocktools* packages be removed.

I'm all for this - but as far as I understood Steffen he does not like
this idea.  I decided personally not invest any time into these
packages any more.


if the autodocktools are blocking something else then they have to go.
If not, well, I admit these packages are close to me but if this works
nowhere else than with me then there is no point, really.

Resistance weakens. I somehow keep doing things that are more important
than chasing the mgltools up. Maybe this all needs a new start, indeed.

Steffen

Bug#903762: BOINC server experimental package python 2-3 transition error: Upstream is aware of it

[Steffen Möller]

Hi Andreas,

thank you for the report. A "once worked" patch is part of
https://github.com/BOINC/boinc/pull/3259. No exact idea what this is
waiting for but I remain confident that it will eventually be accepted.

Cheers,
Steffen

Bug#930216: ITP: python-noise -- Perlin noise for image generation

[Steffen Möller]

On 08.06.19 15:17, Chris Lamb wrote:

Steffen Moeller wrote::


Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-noise
   Version : 1.2.3
* URL : https://github.com/casemane/noise

404s for me.


https://github.com/caseman/noise

Ooops. Sorry.

Thank you for spotting this. Have just re-uploaded.

Steffen

Bug#913369: pluto-jpl-eph: diff for NMU version 0.0~git20180228-1.1

[Steffen Möller]

Hi Adrian,

On 08.01.19 13:00, Adrian Bunk wrote:

Control: tags 913369 + patch
Control: tags 913369 + pending

I've prepared an NMU for pluto-jpl-eph (versioned as 0.0~git20180228-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it.


Thank you for your interest in the pluto-* packages.

The package is team maintained on

https://salsa.debian.org/debian-astro-team/pluto-jpl-eph

I would appreciate if that resource would be used and I cordially invite 
you to help with co-maintenance. The package is a bit tricky in that 
Upstream only evolves over time to get his bits separated to independent 
parts and some circular dependencies are ambiguous to dissect and may 
even have changed over time. That is why first uploads of pluto-* went 
to experimental. Support in transitioning it all to unstable is very 
welcome.


Best,

Steffen

Bug#907624: What ffindex do we want to package

[Steffen Möller]

Heya, I have replied, at least I had typed it :o/

So, yes, I had chosen that version of ffsort_index to get hhsuite to 
compile. I have no idea if there are other reverse dependencies on 
ffindex, my priority is on hhsuite.


Cheers,

Steffen

On 04.01.19 18:17, Michael Crusoe wrote:
I think 0.9.9.7+sog+git20160415.14274c9-1 is the source of the recent 
FTBFS of hhsuite: https://bugs.debian.org/917495 as our packaged 
version is missing the "ffsort_index" function.


The hh-suite github repo contains a submodule pointing at their fork 
of ffindex at ~ 2017-06-01:
https://github.com/soedinglab/hh-suite/tree/v3.0-beta.3/lib → 
https://github.com/soedinglab/ffindex_soedinglab/tree/360e4176ece531be34a94298c808349916d016ac


I suggest that we package it as part of hhsuite until another package 
needs it.


hhsuite does provide  "*-Source*" packages that include ffindex, so we 
wouldn't need a multi-source build.




În joi, 20 dec. 2018 la 11:59, Andreas Tille > a scris:


Ping?
Steffen, if you did not had a specific reason I assume it was by
mistake and will replace the Segfaulting code by the original one.
If I do not hear from you I assume you will agree.
Kind regards, Andreas.

On Wed, Dec 19, 2018 at 09:53:38AM +0100, Andreas Tille wrote:
> Hi,
>
> after reading
https://github.com/soedinglab/ffindex_soedinglab/issues/4
> I came to the conclusion that we somehow picked the wrong fork of
> ffindex.  For me it seems very probable that if we pick the old
codebase
> bug #907624 which was introduced when choosing this will vanish
if we
> revert to the previously packaged code base.  I have a local commit
> which is doing this:
>
>
> diff --git a/debian/changelog b/debian/changelog
> index 6a26115..c409f4f 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,12 @@
> +ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED;
urgency=medium
> +
> +  * The previous location on Github was an improperly choosen fork
> +    (see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
> +    Here the version is now named "0.9.9.7+sog" (Saved On Github)
> +    to make it alphabethically later than the previous one.
> +
> + -- Andreas Tille mailto:ti...@debian.org>>
Wed, 19 Dec 2018 09:16:09 +0100
> +
>  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable;
urgency=medium
>
>    * Fix watch file (version should actually be
+git20171201.74550c8 but
> diff --git a/debian/watch b/debian/watch
> index 91b4f38..b47f123 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,4 +1,4 @@
>  version=4
>
> -opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \
> - https://github.com/soedinglab/ffindex_soedinglab.git HEAD
> +opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
> + https://github.com/ahcm/ffindex.git HEAD
>
>
>
> Upstream at github.com/ahcm/ffindex
 was extremely quick to tag a
> release and so it is at least active.
>
> Steffen, was your pick intentional or did you just stumbled by
chance
> over the other fork?  Are you OK with reverting to the old code?
>
> Kind regards
>
>       Andreas.
>
> PS: I reported the segfault issue to the according fork anyway
> https://github.com/soedinglab/ffindex_soedinglab/issues/7
>
>
> --
> http://fam-tille.de
>
>

-- 
http://fam-tille.de




--
Michael R. Crusoe
Co-founder & Lead, Common Workflow Language project 


Direktorius, VšĮ "Darbo eigos", Vilnius, Lithuania
https://orcid.org/-0002-2961-9670 


m...@commonwl.org 
+1 480 627 9108 / +370 653 11125

Bug#907624: What ffindex do we want to package

[Steffen Möller]

Hi Andreas,

the reverse dependency HH-suite failed to compile with the ffindex 
version Debian shipped.


I have no feelings about it. It should just work :)  The HH-suite is 
about structure prediction from sequence homology, which I found we 
should continue to offer in our distribution 
https://en.wikipedia.org/wiki/HH-suite 
https://tracker.debian.org/pkg/hhsuite . Are there other reverse 
dependencies for ffindex in our distribution?


Priority is the HH-suite. Then ffindex. If difficulties surface anywhere 
then we have initiate some head scratching / banging. If there is 
nothing happening somewhere that I don't know about then I would leave 
it as it is.


Cheers,

Steffen

On 19.12.18 09:53, Andreas Tille wrote:

Hi,

after reading https://github.com/soedinglab/ffindex_soedinglab/issues/4
I came to the conclusion that we somehow picked the wrong fork of
ffindex.  For me it seems very probable that if we pick the old codebase
bug #907624 which was introduced when choosing this will vanish if we
revert to the previously packaged code base.  I have a local commit
which is doing this:


diff --git a/debian/changelog b/debian/changelog
index 6a26115..c409f4f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+ffindex (0.9.9.7+sog+git20160415.14274c9-1) UNRELEASED; urgency=medium
+
+  * The previous location on Github was an improperly choosen fork
+(see https://github.com/soedinglab/ffindex_soedinglab/issues/4)
+Here the version is now named "0.9.9.7+sog" (Saved On Github)
+to make it alphabethically later than the previous one.
+
+ -- Andreas Tille   Wed, 19 Dec 2018 09:16:09 +0100
+
  ffindex (0.9.9.7+soedinglab+git20180802.74550c8-1) unstable; urgency=medium
  
* Fix watch file (version should actually be +git20171201.74550c8 but

diff --git a/debian/watch b/debian/watch
index 91b4f38..b47f123 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
  version=4
  
-opts="mode=git,pretty=0.9.9.7+soedinglab+git%cd.%h" \

-https://github.com/soedinglab/ffindex_soedinglab.git HEAD
+opts="mode=git,pretty=0.9.9.7+sog+git%cd.%h" \
+https://github.com/ahcm/ffindex.git HEAD



Upstream at github.com/ahcm/ffindex was extremely quick to tag a
release and so it is at least active.

Steffen, was your pick intentional or did you just stumbled by chance
over the other fork?  Are you OK with reverting to the old code?

Kind regards

   Andreas.

PS: I reported the segfault issue to the according fork anyway
 https://github.com/soedinglab/ffindex_soedinglab/issues/7

Bug#911162: pybel : BEL vs Babel

[Steffen Möller]

I messed this one up, biblical proportions, so to say, by confusing the 
BEL as in "Biological Expression Language" from github repository 
https://github.com/pybel/pybel with the module provided by OpenBabel, 
which is about reformatting molecular data between different formats 
(and a bit more). As embarrassing as this now is, as helpful can it 
possibly be for us to get it right.


PLIP demands the latter. And this apparently goes with 
/usr/lib/python2.7/dist-packages/pybel.py of the python-openbabel package.


Just for the sake of completeness, there is also python-babel, which 
again is needed by sphinx.


So, let this ITP be about the BEL language's pybel. So, the package 
would be python-pybel with a description clearly indicating that this is 
very independent from the other *bel python packages.


Cheers,

Steffen

Bug#908150: ITP: gnucap-python -- Python bindings for the GNU circuit analysis package

[Steffen Möller]

Hi Felix,

you may be interested in https://wiki.debian.org/Teams/pkg-electronics

Cheers,

Steffen

Bug#807553: Request for co-maintenance of alfred init script

[Steffen Möller]

Hello,

I am about to upload 2018.2 of alfred. Over here I just start alfred
manually after every boot. Admittedly, an init script would be nicer. I
have seen the one you referenced but I do not think batman-vis etc
should be started together with alfred. That should be another init
script. And, in an ideal world that should be part of the upstream
source tree. We (you) should hence plan to contribute that (these) back.

Please consider to help me out with an explicit patch for me to merge
against https://github.com/ffoh/debian-alfred. I happily grant commit
privileges.

Best,

Steffen

Bug#812749: Adopting magic

[Steffen Möller]

Hi Ruben, Roland,

On 7/26/18 10:49 PM, Ruben Undheim wrote:
> Hi Roland,
>
> I see you have orphaned "magic". Is it OK for you that I adopt it (in
> the team Debian Science).
>
> I am alreadly maintaing very closely related packages (some from the
> same upstream) such as qflow, qrouter, graywolf.
>
>
> Best regards
> Ruben

>From all I read I think it is just fine for you, Ruben, to steam ahead
with your update. Just ping me for sponsoring.

Best,

Steffen

Bug#900532: ITP: estscan -- ORF-independent detector of coding DNA sequences

[Steffen Möller]

On 6/3/18 10:01 AM, Göran Weinholt wrote:
> Steffen Möller  writes:
>
>> Hello Göran,
>>
>> On 6/2/18 10:54 PM, Göran Weinholt wrote:
>>> Steffen Moeller  writes:
>>>
>>>> Package: wnpp
>>>> Severity: wishlist
>>>> Owner: Steffen Moeller 
>>>>
>>>> * Package name: estscan
>>>>   Version : 3.0.3
>>>> * URL : http://estscan.sourceforge.net/
>>>> * License : non-free custom
>>>>   Programming Lang: C, Fortran
>>>>   Description : ORF-independent detector of coding DNA sequences
>>>>
>>>> Continues packaging seeded by Bio-Linux, package is team maintained at
>>>> https://salsa.debian.org/med-team/estscan
>>> Hello Steffen,
>>>
>>> I saw "non-free", got curious, and had a look at the license. To me it
>>> looks fine for main.
>>>
>>> I think the reason it might initially look non-free is § 1 (a), but
>>> before that it says "under one of the following terms", and § 1 (b) is
>>> no more than what's in the GPL and so clearly should be fine for main.
>>> Did I perhaps miss something troublesome in the license?
>>>
>> They don't allow charging for its redistribution with a fee that exceeds
>> material/handling/shipping costs.
> That's what I thought the confusion was about. But we can ignore § 1 (a)
> in the license and choose to redistribute under § 1 (b) instead. Under §
> 1 (b) it doesn't say that we aren't allowed to charge a fee for the
> initial distribution; the limitation on the fee in that case is for when
> someone later comes and asks us for a copy of the source code.
>
> So one could redistribute the binaries for €100 per CD if one only
> charges, let's say, €1-3 per source code CD. Alternatively § 1 (b)
> allows us to distribute the binaries accompanied by the source. This is
> the same as the GPL and should be fine for main.
>
> Now I'm curious why you closed the bug... I could formulate an email to
> debian-legal and ask about the license, if you're still unsure (and if
> it's still relevant)?

;Because I was so damn certain and you could reopen it.

I finally reread it. You are right. I'll re-upload to main.

Many thanks and greetings

Steffen - will close with the upload this time :)

Bug#894298: python-gffutils new version 0.9 - relevant again?

[Steffen Möller]

Hello,

I thought I should work a bit on the yellow (in git but not uploaded) 
packages and came across python-gffutils. There is a newer version 0.9 
out, so, yeah, motivating. Just when about to upload I then found 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894298 . So this is a 
package that transitioned from green to yellow :o/ Should we invent a 
new colour for it? As in "not wanted"?


I'll now update our git repository with that 0.9 version since the work 
is done and indicate the removal in the changelog.


Best,

Steffen

Bug#891852: ITP: pluto-jpl-eph -- command line handling of JPL ephemeres data

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name    : pluto-jpl-eph
  Upstream Author : Bill Gray
* URL : https://github.com/Bill-Gray/jpl_eph
* License : GPL-2
  Programming Lang: C++
  Description : command line handling of JPL ephemeres data

The package is prepared on 
https://salsa.debian.org/debian-astro-team/pluto-jpl-eph

Bug#890233: Subject: ITP: cyvcf2 -- efficient htslib-based VCF parser

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name    : cyvcf2
* URL : https://github.com/brentp/cyvcf2/releases
* License : MIT
  Programming Lang: Python
  Description : efficient htslib-based VCF parser

Packaging is orchestrated on https://salsa.debian.org/med-team/cyvcf2.

Bug#887880: Different results for g++-4/5 vs g++-6/7

[Steffen Möller]

Dear Aurelien,

The package compiles just fine with the later gcc version. But - and 
this is a big but - about 10 to 25 percent of results produced with the 
newer versions give slightly different results, i.e. different enough 
that the difference between the g++ versions is bigger than the 
difference between platforms (ARM, 32bit annd 64bit Intel and AMD 
machines, ARM and Intel with an OpenCL implementation).


I would not have found that compiler dependency if g++-5 had already 
been completely removed from the distribution. So, I am really thankful 
for that. It was not expected. I can see that you want to remove that 
older gcc, but I think it would be a mistake. I do not say that the 
newer version has an issue, that may or may not be the case, just be 
aware that the binaries at hand have been tested against against 
injected known truths and error tolerance thresholds been derived from 
there. This needs more investigation. Please do not remove this package 
or g++-5 yet.


Cheers,

Steffen

Bug#848220: g++-4.9/g++-5 show floating point diff to g++-6/g++-7

[Steffen Möller]

Hello,

I just introduced g++-5 as a build dependency to 
https://packages.qa.debian.org/b/boinc-app-eah-brp.html because of small 
- but very present - runtime differences. It had helped me a lot to have 
g++-5 in unstable so I could just go and test. You certainly have 
reasons to remove it, but please be aware of this downside. I can well 
imagine that for many industrial settings the parallel availability of 
both versions is helping the transition.


Cheers,

Steffen

Bug#873847: ITP: libbroad-barclay-java -- Command line argument parsing and documentation generation

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name    : libbroad-barclay-java
* URL : https://github.com/broadinstitute/barclay
* License : BSD
  Programming Lang: Java
  Description : Command line argument parsing and documentation
generation

It is the command line interpretation on the basis of jopt-simple
that constitutes the GATK.

This package and the GATK are maintained by Debian Med community.

Bug#873756: ITP: gradle-git-version-plugin -- allows gradle to find source tree version in git

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name    : gradle-git-version-plugin
  Version : 0.8
  Upstream Author : Palantir
* URL : https://github.com/palantir/gradle-git-version
* License : Apache
  Programming Lang: Java
  Description : allows gradle to find source tree version in git

Reverse dependency for upcoming GATK v4 tools.

Bug#869974: FAHV VINA 64bit app is not executable on Linux

[Steffen Möller]

Dear WCG support,

I was pointed to this issue by the report of Debian BOINC user on 

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

and can confirm the issue for FightAids@Home.

For you to cross-check:

cd /var/lib/boinc-client/projects/www.worldcommunitygrid.org

ldd wcgrid_fahv_gfx_7.34_x86_64*

all fine.

ldd wcgrid_fahv_vina_7.34_x86_64*
    not a dynamic executable

fair enough, but a core is dumped immediately upon its execution.

The Rosetta-based Microbiome project I am testing is fine, so
I exclude an issue with the BOINC client. Please kindly confirm
so we can close the bug report on our side.

Best,

Steffen

Bug#870912: python-rdflib: Please update python-rdflib to 4.2.2

[Steffen Möller]

Package: python-rdflib
Version: 4.2.1-2
Severity: wishlist

Dear Maintainer,

The version 4.2.2 of rdflib is a dependency for cwltool. Please kindly help
with an update. I had give it a shot myself, but it fails two tests which
I could not help.

Many thanks

Steffen

==
FAIL: http://code.google.com/p/rdflib/issues/detail?id=5
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File
"/home/moeller/git/collab-maint/rdflib/test/test_finalnewline.py", line
30, in testFinalNewline
    assert len(failed)==0, "No final newline for formats: '%s'" % failed
AssertionError: No final newline for formats: 'set(['json-ld',
'application/ld+json'])'

==
FAIL: test.test_roundtrip.test_cases(('nt', 'json-ld',
'test/nt/keywords-04.nt'),)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/moeller/git/collab-maint/rdflib/test/test_roundtrip.py",
line 62, in roundtrip
    assert rdflib.compare.isomorphic(g1, g2)
AssertionError

--
Ran 1828 tests in 28.131s

FAILED (SKIP=22, failures=2)

Bug#808895: lofreq - new version 2.1.3.1 out

[Steffen Möller]

A new version 2.1.3.1 was just released
https://github.com/CSB5/lofreq/blob/master/Changelog

I have not seen the issue to be addressed, but maybe someone more
familiar with the source tree can comment.

Cheers,

Steffen

Bug#867455: python3-shellescape: missing dependencies

[Steffen Möller]

Well spotted, many thanks! If it is easy for you then I happily see you
uploading your fixed package to the distribution.
Steffen

Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files

[Steffen Möller]

Hi Andrius,

I happily help with sponsoring. You may also consider to team up with
Debian Science at some point.

Best,

Steffen

Bug#861600: ITP: boinc-app-eah-brp -- BOINC extension for Einstein at Home binary pulsar search

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: boinc-app-eah-brp
* URL : http://www.einsteinathome.org/
* License : GPL-2
  Programming Lang: C++
  Description : BOINC extension for Einstein at Home binary pulsar
search

This project is about about bringing more people (as in "eyeballs",
ideas and options) and more computers (as in non-mainstream computers
with all sorts of thinkable extensions) to the Einstein@Home project.

The packaging is prepared as publicly as possible on
https://github.com/VolunteerComputingHelp/boinc-app-eah-brp

Bug#753763: the graphics program crashes with a segfault

[Steffen Möller]

Hi Yixuan,

On Fri, 04 Jul 2014 15:18:56 -0400
=?utf-8?b?R3VvIFlpeHVhbiAo6YOt5rqi6K2eKQ==?=  wrote:
> Package: boinc-app-seti-graphics
> Version: 7.28~svn2408-1
> Severity: important
> Tags: upstream

> Currently, clicking on "show graphics" in boinc manager doesn't work for
> seti.
>
> dmesg output:
> setiathome_grap[8764]: segfault at 28 ip 7f19c18d785b sp
> 7fff4a080980 error 6 in setiathome_graphics[7f19c18d2000+a000]

about three years down the road I tend to think that your crash has
auto-repaired itself.
But it still does not run when started as a regular user with the
boinc-manager. It works fine,
however, when invoked as root and in the working directory of the
running task

cd /var/lib/boinc-client/slots/0
/usr/lib/boinc-app-seti-graphics/setiathome_graphics

It all also works just fine when the boincmgr is started as root, which
reduces it to a
permission thingy. And indeed, my account was just assigned to the boinc
group.
That changed fixed the graphics display.

Best,

Steffen

Bug#851418: ITP: python-futures -- backport of concurrent.futures from Python 3.2 to Python 2

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-futures
  Version : 3.0.5
* URL : https://github.com/agronholm/pythonfutures
* License : BSD
  Programming Lang: Python
  Description : backport of concurrent.futures from Python 3.2 to
Python 2

Python-futures is a dependency for the BD2KGenomics' cgcloud-core
package. It shall not be confused with the package python-future that
is already in our distribution.

The package is apt for group maintenance with the Python team in their
git repository.

Bug#851401: ITP: python-cgcloud -- Image and VM management for Jenkins

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-cgcloud
* URL : https://github.com/BD2KGenomics/cgcloud/
* License : Apache 2.0
  Programming Lang: python
  Description : Image and VM management for Jenkins, Spark and Mesos
clusters in EC2

The package is a runtime requirement for toil. The packaging
will be maintained under the auspices of Debian Med on their
git repository.

Bug#851365: ITP: toil -- cross-platform workflow engine

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: toil
  Version : 3.5.0~alpha
* URL : https://github.com/BD2KGenomics/toil
* License : Apache
  Programming Lang: Python
  Description : cross-platform workflow engine

The package will be maintained in the Debian Med git repository.
Toil goes together with the CommonWorkflowLanguage to distribute
processes in distributed environments, which means clouds and
clusters alike.

Bug#851341: ITP: python-bd2k -- general utility library for bd2k python package

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-bd2k
* URL : https://github.com/BD2KGenomics/bd2k-python-lib
* License : Apache
  Programming Lang: Python
  Description : general utility library for bd2k python package

The package is a 2nd degree dependency of the Toil workload distributor
expected in Debian any time soon. It is about to be group-maintained at
anonscm.debian.org/cgit/debian-med/python-bd2k

Bug#851242: ITP: python-bx -- library to manage genomic data and its aligment

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-bx
  Version : 0.7.2
* URL : https://github.com/bxlab/bx-python
* License : MIT
  Programming Lang: Python
  Description : library to manage genomic data and its aligment

python-bx is a requirement for getting the Galaxy workflow suite closer
to our distribution.

The packaging is maintained by the Debian Med team and hosted on
https://anonscm.debian.org/cgit/debian-med/python-bx.git/

Bug#784451: Do you have resources to look after ball? [progress info]

[Steffen Möller]

Hi,

well done!


On 11/11/2016 13:06, Andreas Tille wrote:
> Hi Danny,
>
> thanks again for your help.
>
> On Fri, Nov 11, 2016 at 12:36:49PM +0100, Danny Edel wrote:
>> Control: block 784451 by 832420
>>
>> that is fine with me.  I'll keep the bugs in CC too.
> :-)
>  
>>> We somehow should target to Qt5 anyway (see #784451) better sooner than
>>> later.
>>>  
>> For now, I have backported the fixes to the released, but Qt4-based
>> 1.4.3~beta1 version, to resolve the current FTBFS with a targeted fix.
>> The changes are uploaded to the debian-med/ball repository on alioth,
>> pending your review and upload.
> Build is just running ...  I'll come back later in case of any issues
> I feel unable to deal with myself.
>  
>> In that process, I tried building various stages of upstream master, and
>> bae96ab4 'Merge branch issue_596' might be a candidate for a snapshot
>> (entire testsuite passes).  However, there is the problem that
>> QtWebEngine is not yet included in Debian, so I could only build recent
>> master if I explicitly disabled support with -DUSE_QTWEBENGINE=OFF.  I
>> am not sure if this would be a good thing for users.
> I admit that I have no idea whether this is a real constraint.  I added
> Steffen in CC who might raise his opinion.
In my opinion, the BALL library is the essential part that is nice to
redistribute
in Debian. BALLView would be a nice application working with that and
certainly
I hope for many more BALL applications to come.

The dynamic web engine would of course be nice to eventually surface in our
distro but if we can get BALL without it then this is just fine as it is
no regression
from what we had before.
>> I added a blocking relationship to the ITP of QtWebEngine, I hope I
>> didn't mix up the numbers.  The changelog contains a Closes: clause on
>> both FTBFS issues, even though I could only test amd64.  Feel free to
>> remove those before uploading if that's an issue.
> I will also test on amd64.  If it turns out that there might be some
> issues on other architectures we possibly need to excluded these.
It would be particularly nice we could come up with ways to help BALL
development in some ways. Attracting fantastic folks like Danny is one
thing.
Another be could become the continuous integration work, such that even
while possibly working with other operating distros Upstream could learn
about upcoming difficulties (like with the QtWebEngine) and we would not
be taken by surprise either.

Best,

Steffen

Bug#843902: ITP: python-myhdl -- Hardware description generating framework

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-myhdl
  Version : 0.9
* URL : http://www.myhdl.org/
* License : LGPL
  Programming Lang: Python
  Description : Hardware description generating framework

 MyHDL provides Python routines for embedding programmable hardware,
 as in Field Programmable Gate Arrays (FPGA) in regular python code.
 It may be used for complete products and for test environments
 alike, can generate and interact with existing VHDL or Verilog code.

 The source code will be team maintained on
 https://anonscm.debian.org/cgit/python-modules/packages/myhdl.git/

Bug#732069: mgltools-vision and cadd should appear in tasks page

[Steffen Möller]

Hello,

I propose to have mgltools-pmv, mgltools-vision on the tasks page and
also mgltools-cadd. The other parts of the mgltools are more of a
collection of helping libraries that the non-developing user seems
unlikely to be aware of.

Cheers,

Steffen

Bug#830686: [patch] python2.7: idlelib: macos _tk_type shall always be "other"

[Steffen Möller]

Package: python2.7
Version: 2.7.12-1
Severity: normal


Hello,

there is a corner in the idle module with a special affiliation with the
MacOS, which is truly irrelevant for Debian. However, if starting the
PyShell from within Python, the init routine "initializeTkVariantTests"
that would be called from the command line is not called and an
exception is raised. The Python community is also not overly happy with
this situation from what I understand, see

https://bugs.python.org/issue27239

However, the issue prohibits to start the autodocktools which starts a
shell itself

sudo apt-get install autodocktools
runAdt

With all the confidence that eventually the Python community will fix
their behaviour towards something that works like a couple of releases
back, I propose to help the Debian community with the knowledge that
none of the typical MacOS Tk styles ever apply and initialise the
_tk_type with "other" rather than "None". The following works for me

$ cat debian/patches/circumventMacOSXconfig.patch
Index: python2.7-2.7.12/Lib/idlelib/macosxSupport.py
===
--- python2.7-2.7.12.orig/Lib/idlelib/macosxSupport.py
+++ python2.7-2.7.12/Lib/idlelib/macosxSupport.py
@@ -18,7 +18,7 @@ def isCarbonAquaTk(root):
 DeprecationWarning, stacklevel=2)
 return isCarbonTk()
 
-_tk_type = None
+_tk_type = "other"
 
 def _initializeTkVariantTests(root):
 """


Cheers,

Steffen

Bug#830573: python2.7: FTBFS in autotest because of erroneously reported missing, Windows-only winreg module

[Steffen Möller]

Package: python2.7
Version: 2.7.12-1
Severity: minor

Dear Maintainer,


   * What led up to the situation?

apt-get source python2.7
cd python2.7

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

dpkg-buildpackage -rfakeroot -uc -us

   * What was the outcome of this action?

cd /home/moeller/e/python2.7-2.7.12/build-static && ./python
../debian/mincheck.py \
minmods.py mindeps.txt
Listed modules: ['ConfigParser', 'StringIO', 'UserDict', '__builtin__',
'__future__', '_abcoll', '_bisect', '_bytesio', '_codecs',
'_collections', '_fileio', '_functools', '_hashlib', '_heapq', '_io',
'_locale', '_md5', '_random', '_sha', '_sha256', '_sha512', '_socket',
'_sre', '_ssl', '_struct', '_symtable', '_sysconfigdata', '_types',
'_warnings', '_weakref', '_weakrefset', 'abc', 'array', 'atexit',
'base64', 'binascii', 'bisect', 'cPickle', 'cStringIO', 'calendar',
'cmath', 'codecs', 'collections', 'compileall', 'contextlib', 'copy',
'copy_reg', 'datetime', 'dis', 'encodings', 'errno', 'exceptions',
'fcntl', 'fnmatch', 'functools', 'gc', 'genericpath', 'getopt', 'glob',
'grp', 'hashlib', 'heapq', 'imp', 'inspect', 'io', 'itertools',
'keyword', 'linecache', 'locale', 'logging', 'marshal', 'math', 'md5',
'opcode', 'operator', 'optparse', 'os', 'pickle', 'pkgutil', 'platform',
'popen2', 'posix', 'posixpath', 'pwd', 'py_compile', 'random', 're',
'repr', 'runpy', 'select', 'sha', 'shutil', 'signal', 'socket', 'spwd',
'sre', 'sre_compile', 'sre_constants', 'sre_parse', 'ssl', 'stat',
'string', 'strop', 'struct', 'subprocess', 'sys', 'sysconfig', 'syslog',
'tempfile', 'textwrap', 'thread', 'time', 'token', 'tokenize',
'traceback', 'types', 'unicodedata', 'warnings', 'weakref', 'zipimport',
'zlib']

Dependent modules: ['ConfigParser', 'StringIO', 'UserDict',
'__builtin__', '__future__', '_abcoll', '_bisect', '_codecs',
'_collections', '_functools', '_heapq', '_io', '_locale', '_random',
'_socket', '_sre', '_ssl', '_struct', '_symtable', '_sysconfigdata',
'_warnings', '_weakref', '_weakrefset', 'abc', 'array', 'atexit',
'base64', 'binascii', 'bisect', 'cStringIO', 'calendar', 'cmath',
'codecs', 'collections', 'compileall', 'contextlib', 'copy', 'copy_reg',
'datetime', 'dis', 'encodings', 'errno', 'exceptions', 'fcntl',
'fnmatch', 'functools', 'gc', 'genericpath', 'getopt', 'glob', 'grp',
'hashlib', 'heapq', 'imp', 'inspect', 'io', 'itertools', 'keyword',
'linecache', 'locale', 'logging', 'marshal', 'math', 'md5', 'opcode',
'operator', 'optparse', 'os', 'pickle', 'pkgutil', 'platform', 'popen2',
'posix', 'posixpath', 'pwd', 'py_compile', 'random', 're', 'repr',
'runpy', 'select', 'sha', 'shutil', 'signal', 'socket', 'spwd', 'sre',
'sre_compile', 'sre_constants', 'sre_parse', 'ssl', 'stat', 'string',
'strop', 'struct', 'subprocess', 'sys', 'sysconfig', 'syslog',
'textwrap', 'thread', 'time', 'token', 'tokenize', 'traceback', 'types',
'unicodedata', 'warnings', 'weakref', 'winreg', 'zipimport', 'zlib']

Missing modules in python-minimal:
set(['winreg'])
winreg used in:  ['platform']
debian/rules:426: recipe for target 'stamps/stamp-mincheck' failed



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

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

Versions of packages python2.7 depends on:
ii  libpython2.7-stdlib  2.7.12-1
ii  mime-support 3.60
ii  python2.7-minimal2.7.12-1

python2.7 recommends no packages.

Versions of packages python2.7 suggests:
ii  binutils   2.26.1-1
pn  python2.7-doc  

-- no debconf information

Bug#826615: iverilog NMU prepared

[Steffen Möller]

Hello,

My team membership application pending I have prepared an NMU for
iverilog 10.1. Is anything speaking against the version update?

Best,

Steffen

Bug#829017: ITP: python-bioblend -- CloudMan and Galaxy API library

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: python-bioblend
  Version : 0.7.0
* URL : https://github.com/galaxyproject/bioblend
* License : MIT/X
  Programming Lang: Python
  Description : CloudMan and Galaxy API library

The package is about to be uploaded to the python-modules repository.

Bug#829006: ITP: wchartype -- handling of double-byte characters

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: wchartype
  Version : 0.1
* URL : http://ginstrom.com/code/wchartype.html
* License : MIT/X
  Programming Lang: Python
  Description : handling of double-byte characters

About to be uploaded to python-modules as a reverse
dependency for the Galaxy suite.

Bug#828974: ITP: svgwriter -- Python library for creating SVG images

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: svgwriter
  Version : 1.1.8
* URL : https://pypi.python.org/pypi/svgwrite/
* License : MIT/X
  Programming Lang: Python
  Description : Python library for creating SVG images

It is a about to appear in the python-modules repository,
Just waiting for this ITP number :o)

Bug#817385: Moving Bytecode to Debian Med (or Java) Git

[Steffen Möller]

Go ahead. This pkg-escience was that Taverna collective effort.

Thanks

Steffen


On 20/06/16 15:38, Olivier Sallou wrote:
> I made a quick fix to switch to compat 9 and fix Java version to current
> jdk in sid.
>
> However, i cannot push to pkg-escience / bytecode (permission denied).
>
> It would be best to move package to pkg-java instead of debianmed
> according to me, as it is pure Java package.
>
> Patching is quite easy:
>
> switch d/compat to 9 (no issue)
>
> d/control: update dependencies to use default-jdk and default-jre
> instead of openjdk/sun-jdk/java2-compiler
>
> add a patch to build.xml to add in all javac commands :  source="1.6"
> target="1.6"
>
> build is fine with no specific lintian error
>
>
> Olivier
>
> On 06/20/2016 12:21 PM, Andreas Tille wrote:
>> Hi,
>>
>> the RC bug #817385 affects several Debian Med packages.  IMHO it would
>> be best if the package would be moved to either Debian Med or Debian
>> Jave Git.  The package is currently unmaintained (Steffen, please
>> correct me if I'm wrong) and urgently needs a proper update.  I need
>> to cope with some backlog and can not do this before end of this week.
>>
>> Any volunteer?
>>
>> Kind regards
>>
>>Andreas.
>>

Bug#817385: Moving Bytecode to Debian Med (or Java) Git

[Steffen Möller]

Hi Andreas,

On 20/06/16 12:21, Andreas Tille wrote:
> Hi,
>
> the RC bug #817385 affects several Debian Med packages.  IMHO it would
> be best if the package would be moved to either Debian Med or Debian
> Jave Git.  The package is currently unmaintained (Steffen, please
> correct me if I'm wrong) and urgently needs a proper update.  I need
> to cope with some backlog and can not do this before end of this week.
>
> Any volunteer?
>
I once did this for Taverna and am both happy and suprised to see
reverse dependencies surfacing. If you (or someone else) could adopt
this package it would be very nice, indeed.

Many thanks

Steffen

Bug#807553: Could you possibly provide the init scripts?

[Steffen Möller]

Hi Franz,

somehow I am still shying off a bit from providing the init scripts for
alfred and friends. The link you provide is stale now. If you happen to
have something fancy available that with a chance is already tested then
I would add it to the package.

Cheers,

Steffen

Bug#823650: RFS: gcc-6-doc/6.1.0-1 [ITP]

[Steffen Möller]

Uploaded.

Best,

Steffen


On 07/05/16 04:03, Guo Yixuan (郭溢譞) wrote:
> Package: sponsorship-requests
> Severity: wishlist
> Control: block 822667 by -1
>
> Dear mentors,
>
> I'm looking for a sponsor for my package gcc-6-doc. (ITP: #822667)
>
> * Package name: gcc-6-doc
>   Version : 6.1.0-1
>   Upstream Author : FSF
> * URL : http://gcc.gnu.org/
> * License : GFDL-1.3+, with invariant sections
>   Programming Lang: Texinfo
>   Description : documentation for the GNU compilers (gcc, gobjc, g++)
>
> This package contains manual pages and documentation in info, html,
> and pdf format, for the GNU compilers.
>
> This documentation is licensed under the terms of the GNU Free
> Documentation License, and contains invariant sections, so it can't be
> part of Debian main.
>
> (See gcc-5-doc as an example.)
>
>   It builds those binary packages:
>
>  cpp-6-doc  - documentation for the GNU C preprocessor (cpp)
>  gcc-6-doc  - documentation for the GNU compilers (gcc, gobjc, g++)
>  gccgo-6-doc - documentation for the GNU Go compiler (gccgo)
>  gcj-6-doc  - documentation for the GNU Java tools (gcj, gij)
>  gfortran-6-doc - documentation for the GNU Fortran Compiler (gfortran)
>  gnat-6-doc - documentation for the GNU Ada Compiler (gnat)
>
>   To access further information about this package, please visit the 
> following URL:
>
>   https://mentors.debian.net/package/gcc-6-doc
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/non-free/g/gcc-6-doc/gcc-6-doc_6.1.0-1.dsc
>
>
> Thanks,
> Yixuan
>

Bug#818605: ITP: dindel -- find insertions and deletions in biological sequences

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 
 
* Package name: dindel
* URL : https://sites.google.com/site/keesalbers/soft/dindel
* License : GPL-3.0+
  Description : find insertions and deletions in biological sequences

 The packaging is ready and about to surface on the Debian Med git repository.

 Dindel is a program for calling small indels from short-read sequence
 data ('next generation sequence data'). It currently is designed to
 handle only Illumina data.
 .
 Dindel requires a BAM file containing the read-alignments as input. It
 then extracts candidate indels from the BAM file, and realigns the reads
 to candidate haplotypes consisting of these candidate indels. If there
 is sufficient evidence for an alternative haplotype to the reference,
 it will call an indel.
 .
 It is possible to test indels discovered with other methods using Dindel,
 for instance longer indels obtained through assembly methods. Dindel
 will then realign both mapped and unmapped reads to see if the candidate
 indel is supported by the reads.
 .
 Dindel outputs both genotype likelihoods and includes a script to
 convert these to a VCF file with indel and SNP calls.

Bug#816925: ITP: condetri -- Perl-based trimming of Illumina FASTQ files

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: condetri
  Version : 2.3
* URL : https://github.com/linneas/condetri/
* License : to be clarified
  Programming Lang: Perl
  Description : Perl-based trimming of Illumina FASTQ files

There is no particular technical challenge in packaging a Perl
script with not dependencies. It is more about rendering the
community aware of this (published and referenced) tool to
increase flexibility in biological workflows.

The "trimming" is a means of quality control in next-generation
sequencing workflows, i.e. the quantification of the abundance
of transcripts or genomic fragments. This particular tool was
developed in the context of de novo genomic sequencing.

The package yet cannot be uploaded because of the license not
being declared. Upstream is informed.

Bug#813934: ITP: python-shellescape -- escapes characters to safely assemble command lines

[Steffen Möller]

Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-shellescape
* URL : https://github.com/chrissimpkins/shellescape
* License : MIT
  Programming Lang: Python
  Description : escapes characters to safely assemble command lines

 The shellescape Python module defines the shellescape.quote() function
 that returns a shell-escaped version of a Python string. This is a
 backport of the shlex.quote() function from Python 3.4.3 that makes
 it accessible to users of Python 3 versions < 3.3 and all Python 2.x
 versions.

Bug#811460: ITP: fast5 -- library for reading Oxford Nanopore Fast5 files

[Steffen Möller]

Hi, I happily help with sponsoring  and any feedback on how nice the
nanopore is working for you would be appreciated :)
Best,
Steffen

On 19/01/16 09:07, Afif Elghraoui wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian Med Packaging Team 
> 
> Control: block 811458 by -1
>
> * Package name: fast5
>   Version : 0~20150918
>   Upstream Author : Matei David
> * URL : https://github.com/mateidavid/fast5
> * License : MIT
>   Programming Lang: C++
>   Description : library for reading Oxford Nanopore Fast5 files
>
> Fast5 is a lightweight C++11 library to read raw signal data from Oxford
> Nanopore's FAST5 files.
>
> This package will be maintained by the Debian Med team. It is a requirement
> for nanopolish.
>

Bug#807546: overriding auto clean to compile on non-linux systems

[Steffen Möller]

Hello,

The AL.F.R.E.D. makefile happily tests for the missing library also for
the cleaning of the source tree. And that clean is executed prior to the
build. FAIL.

My next update of alfred, which shall be a new upstream version, will see

override_dh_auto_clean:
$(MAKE) $(MAKEOPTIONS) -j1 distclean

added to debian/rules. If there are users of alfred on those platforms
already, please kindly report if this is any successful.

Cheers,

Steffen

Bug#807555: [alfred] Don't modify upstream tarball

[Steffen Möller]

Hi Franz,

On 10/12/15 11:17, Franz Schrober wrote:
> Just looked at what you've modified in this "3.0 (quilt)" package and why you 
> had to create a new tarball (see #807555). Following was shown me when I 
> diffed the two tarballs:
>
> diff -ruN orig/alfred-2015.1/vis/debugfs.c deb/alfred-2015.1/vis/debugfs.c
> --- orig/alfred-2015.1/vis/debugfs.c 2015-08-04 16:04:17.0 +0200
> +++ deb/alfred-2015.1/vis/debugfs.c 2015-11-19 22:01:56.0 +0100
> @@ -58,6 +58,7 @@
> return len+1;
>
> snprintf(buffer, size-1, fmt, debugfs_mountpoint, mesh_iface);
> + buffer[size - 1] = '\0';
> return 0;
> }
>
> @@ -88,7 +89,9 @@
> /* give up and parse /proc/mounts */
> fp = fopen("/proc/mounts", "r");
> if (fp == NULL) {
> - perror("Error - can't open /proc/mounts for read");
> + fprintf(stderr,
> + "Error - can't open /proc/mounts for read: %s\n",
> + strerror(errno));
> return NULL;
> }
>
>
> These changes SHOULD NEVER EVER EVER EVER EVER EVER be made in the debian 
> upstream tarball. They don't qualify for a dfgs tarball at all. You have 
> debian/patches for that purpose in "3.0 (quilt)" packages.
>
> Btw. These modifications don't seem to have been forwarded. According to 
> codesearch.debian.net, at least batctl should also receive this patch. There 
> are most likely more projects using it because these functions are from the 
> perf project source code in the linux kernel tree
Hm. I do not recall to have performed these changes. Can only
investigate next weekend.
Are we possibly just looking at different versions? Anyway, your
scrutiny is appreciated.
Would you possibly want to adopt the package - and close both bugs?

Best,

Steffen

Bug#802255: ITP: ecdsautils -- elliptic curve cryptography command line

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: "Steffen Möller" <moel...@debian.org>

* Package name: ecdsautils
  Version : 0.3.2
  Upstream Author : Nils Schneider
* URL : https://github.com/tcatm/ecdsautils
* License : custom MIT-like
  Programming Lang: C
  Description : elliptic curve cryptography command line tools


The package provides a series of tools to support, all
on the basis of the uecc library the
 * generation
 * signing
 * verifification
of keys for elliptic key cryptography.

The package became popular in the Freifunk Wireless
networks communities.

Bug#802174: ITP: batman-adv-kernelland -- source for the batman-advanced kernel module

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: "Steffen Möller" <steffen_moel...@gmx.de>

* Package name: batman-adv-kernelland
  Version : 2013.4.0
* URL : http://www.open-mesh.net/
* License : GPL
  Programming Lang: C
  Description : source for the batman-advanced kernel module

 This package provides the source code for the batman-adv-source kernel
 modules.  Kernel source or headers are required to compile these
 modules.
 .
 B.A.T.M.A.N. (better approach to mobile ad-hoc networking)
 is a new routing protocol for multi-hop ad-hoc mesh networks.
 B.A.T.M.A.N.-advanced is the implementation of this protocol
 on ISO/OSI Layer 2, allowing mesh networks to be used as a virtual
 switch. With this approach, LANs and WANs can be easily integrated,
 and more protocols (like DHCP, IPv6) are supported.

Bug#801466: ITP: fastd -- Fast and Secure Tunneling Daemon

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: "Steffen Möller" <moeller@localhost.localdomain>

* Package name: fastd
  Version : 17
  Upstream Author : Matthias Schiffer
* URL : https://projects.universe-factory.net/projects/fastd
* License : custom
  Programming Lang: C
  Description : Fast and Secure Tunneling Daemon

Fastd came to fame in the Freifunk WLAN communities. Debian
is frequently seen as a bridge between the public Internet
and the individual comnunities. The cross-platformness of
Debian renders Debian's adoption of this developer-maintained
package to be of particular interest, preparing for the
encrypted information exchange also between embedded devices.

Bug#793464: Aw: Bug#793464: astrometry-data-2mass -- Star catalogs for astrometry.net from 2MASS

[Steffen Möller]

Hi Ole,

please have a look at what 
https://wiki.debian.org/getData
can possibly do for you.

An idea about how your package could possibly look like you find here
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/autodocksuite/trunk/debian/autodock-getdata.install?view=markup

Best,

Steffen

 Gesendet: Freitag, 24. Juli 2015 um 11:43 Uhr
 Von: Ole Streicher oleb...@debian.org
 An: Debian Bug Tracking System sub...@bugs.debian.org
 Betreff: Bug#793464: astrometry-data-2mass -- Star catalogs for 
 astrometry.net from 2MASS

 Package: wnpp
 Owner: Ole Streicher oleb...@debian.org
 Severity: wishlist
 X-Debbugs-Cc: debian-de...@lists.debian.org,debian-as...@lists.debian.org
 
 * Package name: astrometry-data-2mass
   Version : 4200
   Upstream Author : Dustin Lang
 * URL : http://data.astrometry.net/
 * License : GPL
   Description : Star catalogs for astrometry.net from 2MASS
  Astrometry.net needs complete catalogs of star positions, which
  are provided with several resolutions in these packages.
 
 The uncompressed size of these catalogs upstream ranges from
 129 kBytes (1000 stars) to ~15 GB (200 million stars), with
 roughly doubling the number of stars with each step. Since it
 is not useful to put flood the Debian archive with Milky Way
 stars, I started a discussion on debian-devel [1]. However, until 
 there is a good solution, I would package a subset (total ~120 MB),
 which overs about 3 million stars. I still have no idea about the
 best way to split it into subpackages; probably I would combine the
 smallest catalogs into one 8 MB package, and then have one larger
 catalog per package (8 MB, 15 MB, 30 MB, 60 MB).
 
 Best regards
 
 Ole
 
 The package will be maintained within the Debian Astronomy Team.
 
 Best regards
 
 Ole
 
 [1] https://lists.debian.org/debian-devel/2015/07/msg00314.html
 
 
 -- 
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/55b208db.5050...@debian.org
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787746: Aw: Re: ball: FTBFS, depends on non existant libqt4-gui

[Steffen Möller]

 I would highly appreciate if you can either allow me to push this as an NMU 
 or 
 just build+upload yourself.

Oh, please feel free to NMU - every piece of help is much appreciated.

Best,

Steffen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787746: Aw: Bug#787746: ball: FTBFS, depends on non existant libqt4-gui

[Steffen Möller]

 On Friday 05 June 2015 16:33:45 Lisandro Damián Nicanor Pérez Meyer wrote:
  Mm, no, I'm afraid ball keeps FTBFS due to the same error:
  
  Linking CXX executable ../../../bin/BALLView
  /usr/bin/ld: CMakeFiles/BALLView.dir/main.o: undefined reference to symbol
  'XInitThreads'
  //usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing
  from command line
  collect2: error: ld returned 1 exit status
  make[4]: *** [bin/BALLView] Error 1
 
 The attached patch fixes this but... there is yet another problem further on 
 with some python stuff.

Thank you, Lisandro. I am about to upload an early version of BALL 1.5
and will incorporate your changes over the next days / one/two weeks.

Best,

Steffen


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783864: Aw: Bug#783864: ITP: gcc-5-doc -- documentation for the GNU compilers (gcc, gobjc, g++)

[Steffen Möller]

Hi Yixuan,

 
 I'm maintaining gcc-4.(8|9)-doc now. All the packaging work is in available in
 git[1].
 
 [1] 
 http://anonscm.debian.org/gitweb/?p=users/yixuan-guest/gcc-doc.git;a=summary
 

as always, I am around, just wait a bit if some one else surfaces as a new 
contact.

A colleague of mine will be in Philadelphia this summer - not me :/

Best,

Steffen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#783109: Aw: Bug#783109: ITP: orocos-kdl -- Orocos Kinematics and Dynamics Library

[Steffen Möller]

Hi Leopold,

I would definitely wish to have the time to play with this. The least I can do 
is to help with sponsoring.

Ping me.

Steffen

 Gesendet: Mittwoch, 22. April 2015 um 12:37 Uhr
 Von: Leopold Palomo-Avellaneda l...@alaxarxa.net
 An: Debian Bug Tracking System sub...@bugs.debian.org
 Betreff: Bug#783109: ITP: orocos-kdl -- Orocos Kinematics and Dynamics Library

 Package: wnpp
 Severity: wishlist
 Owner: Leopold Palomo-Avellaneda l...@alaxarxa.net
 
 * Package name: orocos-kdl
   Version : 1.3.0
   Upstream Author : Orocos Developers orocos-...@lists.mech.kuleuven.be
 * URL : http://www.orocos.org/kdl
 * License : LGPL
   Programming Lang: C++
   Description : Orocos Kinematics and Dynamics Library
 
 Orocos project to supply RealTime usable kinematics and dynamics code,
 it contains code for rigid body kinematics calculations and
 representations for kinematic structures and their inverse and forward
 kinematic solvers. This package contains the development files
 of the library.
 
 - why is this package useful/relevant? 
 
 Yes, it's a good kinematics and dynamics library, especially for kinematic
 chains.
 
 - is it a dependency for  another package? do you use it? if there are other 
 packages
   providing similar functionality, how does it compare?
 
 A lot of robotics packages use it. We use it in our lab. AFAIK, not other
 are so complete and well designed.
 
 - how do you plan to maintain it? inside a packaging team?
 
 Inside debian-science team. I have done a preliminary work in:
 
 http://anonscm.debian.org/cgit/debian-science/packages/orocos/kdl.git
 
 - are you looking for co-maintainers? do you need a sponsor?
 
 Yes, both. Any help will be welcome. It's better to have co-maintainers.
 
 
 -- 
 To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/20150422103708.17390.6226.report...@soho.upc.es
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#782736: ITP: nodogsplash -- manages public internet access

[Steffen Möller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller steffen_moel...@gmx.de

* Package name: nodogsplash
* URL : https://github.com/smoe/nodogsplash/tree/master
* License : GPL-2.0+
  Description : manages public internet access

https://github.com/smoe/nodogsplash/tree/master/debian

Nodogsplash controls access to a public Internet connection and offers
a simple way to open a Hotspot for wireless networks. It provides a
captive portal to inform users about the services and optionally have
them acknowledge the terms and conditions of its use.

The packaging is maintained together with the
upstream source tree on
https://github.com/smoe/nodogsplash/tree/master/debian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#755897: Aw: Re: ITP: alfred -- Almighty Lightweight Fact Remote Exchange Daemon

[Steffen Möller]

Ciao Elena,

 any news on the status of this? I'm trying to use debian (instead of
 OpenWRT) on my ninux (italian community network) node and having 
 alfred would be quite useful.
 
 P.S. I've noticed that somebody from FreiFunkNord already did some 
 packaging (outside debian, it seems): do you know about it?
 
 https://github.com/ffnord/alfred-debian

I presume that Alfred was already packaged independently
by a handful of people, including myself ;)  I would not want
to maintain the package for Debian but can perform the upload(s)
until a repective person is found. Can we (as in both the Debian
and Freifunk communities) win you as a package maintainer?

Best,

Steffen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#777002: Aw: Bug#777002: libusb-java: can't load library: wrong name

[Steffen Möller]

Ouch.

Thank you for spotting this. Somewhat weird that it had escaped me.

Please kindly help yourself with a symbolic link for the moment.

Is there a chance that you would feel prepared to adopt the
maintenance of the libusb-java package? Or join me as a co-maintainer?
I am somewhat more than swamped these days.

Cheers,

Steffen


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771154: [Debian-med-packaging] Bug#771154: plink: New major upstream version of plink

[Steffen Möller]

  
  Much in support of Dylan, please also think about the binary filename of the executable. We had the unfortunate p-link for Version 1 to avoid a clash with one of the putty tools. This was a mistake at the time imho. Shall we correct for that? Or is upstream already defaulting to plink2? This would then give us p-link and plink2 as executables. Hurts.
Cheers,
Steffen
-- 
Sent from my Android phone with GMX Mail. Please excuse my brevity.Dylan bob.dyb...@gmail.com wrote:


  

  Hi Andreas,
  

  


  
2014-12-16 15:35 GMT+01:00 Andreas Tille andr...@an3as.eu:

  For this actual case I wonder whether plink2 would be a drop in
  replacement we can provide instead of the old pling (which means the
  interface is compatible and the test suite if there is any creates the
  same results) or whether you think plink and plink2 should be provided
  in parallel.
  

  
  


  I recommend to provide both versions of plink for the moment as the first version is always widely used and the interface is not completely compatible, some flags are not supported by the new version. The upstream recommends to use the old plink for these flags. Moreover, the new version is a major update (i.e. many algorithms changes) which could be problematic for replicate some previous results for those using old plink.
  


  I will push the new plink on git.debian.


  
  
  
Best regards,
  
  Dylan
  

  

  

___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
  



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#772153: Aw: Bug#772153: RFS: mrtdreader/0.1.2-1 [ITP]

[Steffen Möller]

Hi Ruben,

do you already have the two signature of your GPG key? You are then a prime 
candidate to become a Debian Maintainer ... which also helps attracting
sponsors :)

Ping me if there is nobody else surfacing.

Best,

Steffen

 Gesendet: Freitag, 05. Dezember 2014 um 17:16 Uhr
 Von: Ruben Undheim ruben.undh...@gmail.com
 An: sub...@bugs.debian.org
 Betreff: Bug#772153: RFS: mrtdreader/0.1.2-1 [ITP]

 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package mrtdreader
 
  * Package name: mrtdreader
Version : 0.1.2-1
Upstream Author : Ruben Undheim ruben.undh...@gmail.com
  * URL : https://github.com/rubund/mrtdreader
  * License : GPL-3+
Section : utils
 
 It builds those binary packages:
 
   libmrtd-dev - Development files for libmrtd0
   libmrtd0   - MRTD - Machine-readable travel document library
   libmrtd0-dbg - debug symbols for libmrtd0
   mrtdreader - Reader for machine-readable travel documents (MRTDs / 
 passports)
 
 To access further information about this package, please visit the
 following URL:
 
   http://mentors.debian.net/package/mrtdreader
 
 
 Alternatively, one can download the package with dget using this command:
 
   dget -x 
 http://mentors.debian.net/debian/pool/main/m/mrtdreader/mrtdreader_0.1.2-1.dsc
 
 or with git using this command:
 
   git clone git://github.com/rubund/mrtdreader.git -b debian
 
 More information about hello can be obtained from http://www.example.com.
 
 Changes since the last upload:
 
   Initial release (Closes: #771708)
 
 
 Regards,
  Ruben Undheim
 
 
 -- 
 To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 https://lists.debian.org/CA+ChNyVpnpXsG+bKwz8Ks=w8yznq-djm1csfn8cgavk1c1q...@mail.gmail.com
 
 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#767411: Aw: Bug#767411: torque: should not be released with jessie

[Steffen Möller]

Hello,
  
Von: Dominique Belhachemi domi...@debian.org
I agree that the 2.4 branch is completely outdated. We should switch to a 
newer branch.
The 2.5 and 4.1 branches are not suitable for Debian due to licensing issues.
But the 4.2 branch is licensed under the same license as the 2.4 branch, so I 
suggest we upload the 4.2.9 release to unstable.

I agree.  You? Me? I am too busy for the upcoming weeks, sadly.

Best,

Steffen


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org