Bug#1071207: ITP: r-cran-calculus -- High Dimensional Numerical and Symbolic Calculus

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: r-cran-calculus
  Version : 1.0.1
  Upstream Author : Emanuele Guidotti 
* URL : https://cran.r-project.org/package=calculus
* License : GPL-3
  Programming Lang: GNU R
  Description : High Dimensional Numerical and Symbolic Calculus

Efficient C++ optimized functions for numerical and symbolic calculus as 
described in Guidotti (2022). It includes basic arithmetic, tensor 
calculus, Einstein summing convention, fast computation of the 
Levi-Civita symbol and generalized Kronecker delta, Taylor series 
expansion, multivariate Hermite polynomials, high-order derivatives, 
ordinary differential equations, differential operators (Gradient, 
Jacobian, Hessian, Divergence, Curl, Laplacian) and numerical 
integration in arbitrary orthogonal coordinate systems: cartesian, 
polar, spherical, cylindrical, parabolic or user defined by custom scale 
factors.


I found this package useful at my $DAYJOB.

Remark: This package is to be maintained with Debian R Packages 
Maintainers at

   https://salsa.debian.org/r-pkg-team/r-cran-calculus

Bug#1071176: ITP: python-htmltools -- Tools for creating, manipulating, and writing HTML

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-htmltools
  Version : 0.5.1
  Upstream Author : Posit Software, PBC
* URL : https://github.com/rstudio/py-htmltools
* License : Expat
  Programming Lang: Python
  Description : Tools for creating, manipulating, and writing HTML 
(Python 3)


Tools for creating, manipulating, and writing HTML from Python.

This package is needed to package py-shiny.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-htmltools

Bug#956194: streamlit status

[Andrius Merkys]

Hello,

Is anybody still interested in streamlit? Some time ago I packaged its 
dependency node-xxhashjs and ended up maintaining it. I do not use 
node-xxhashjs myself and would like to pass its maintenance to people 
interested in streamlit.


Andrius

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Andrius Merkys]

Hi Nilesh,

On 2024-04-10 19:53, Nilesh Patra wrote:

On Mon, Apr 08, 2024 at 08:59:26AM +0300, Andrius Merkys wrote:

On 2024-04-07 15:28, Nilesh Patra wrote:

Assistance required with maintaining the singularity-container package.


I am not offering help with singularity-container, but do you by any chance
know why apptainer is not packaged for Debian? I cannot find a wnpp bug.


I am lazy to find references right now, but you should be able to find it in
debian-hpc and debian-devel archives. If I don't miss anything this was the
sequence of events:

1) While updating singularity-container, Andreas created a repo for apptainer on
salsa.
2) The goal at that time was to get a mobility compute (either apptainer or
singularity) up and running
3) singularity and apptainer codebases are in sync so as per my understanding
there's no real point in having *both* - here's a brief discussion about it[1]


Thanks a lot for the summary. I found packaging repository for apptainer 
on salsa and wrote the debian-hpc team to ask about its status [4]. I 
was not aware about the close relation between apptainer and singularity.



My opinion: It does not make a lot of sense to package apptainer as well.
Although the latter is "community" maintained, the codebases for
sylabs/singularity and apptainer are in close sync at most times which also
means they keep inheriting CVEs from each other too.

As a result one may not be able to maintain apptainer well in stable release
either unless they have:
a) Good/Great go programming skills
b) ability to deal with CVEs and backports

I'd like to just link to a similar discussion thread about the same rather than
repeating the points[2] and here's what upstream says[3].


I agree with you, if their codebases are in sync, it does not make sense 
to have them both.



[1]: https://lists.debian.org/debian-hpc/2022/08/msg00021.html
[2]: https://lists.debian.org/debian-devel/2023/01/msg00078.html
[3]: https://lists.debian.org/debian-devel/2023/01/msg00080.html


[4] https://lists.debian.org/debian-hpc/2024/04/msg00012.html

Best wishes,
Andrius

Bug#1068692: RFP: python-pycddl -- Deserialize CBOR and/or do CDDL schema validation

[Andrius Merkys]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-rust-maintain...@lists.alioth.debian.org

* Package name: python-pycddl
  Version : 0.6.1
  Upstream Author : Systema Development LLC
* URL : https://gitlab.com/tahoe-lafs/pycddl
* License : Expat
  Programming Lang: Python
  Description : Deserialize CBOR and/or do CDDL schema validation

CDDL is a schema language for the CBOR serialization format. pycddl 
allows one to validate CBOR documents match a particular CDDL schema, 
based on the Rust cddl library. Optionally, it can decode CBOR documents.


python-pycddl is a new dependency of tahoe-lafs. It has parts written in 
Rust. I have no knowledge of Rust packaging thus it would be great if 
someone could help. Thus I am CCing Rust team via X-Debbugs-CC.


Andrius

Bug#1068578: RFH: singularity-container -- container platform focused on supporting "Mobility of Compute"

[Andrius Merkys]

Hi Nilesh,

On 2024-04-07 15:28, Nilesh Patra wrote:

Assistance required with maintaining the singularity-container package.


I am not offering help with singularity-container, but do you by any 
chance know why apptainer is not packaged for Debian? I cannot find a 
wnpp bug.


Thanks for caring about singularity-container.

Andrius

Bug#1068294: RFH: liboqs -- library for quantum-safe cryptographic algorithms

[Andrius Merkys]

Package: wnpp
Severity: normal

In the light of recent calls to increase the quality and the bus factor 
of security-related packages, I request assistance with maintaining the 
liboqs package. I do not have enough time nor expertise to properly 
maintain liboqs alone.


The package is sid-only per upstream request (#1000303) and should stay 
this way until the upstream gives a green light.


I fail to keep up with upstream releases mostly due to the work needed 
to update debian/copyright. The upstream does a great job in applying 
REUSE standards on liboqs source, but as the package is in active 
development there usually are many changes to its source files.


The package description is:

liboqs is an open source C library for quantum-safe cryptographic 
algorithms. It provides a collection of open source implementations of 
quantum-safe key encapsulation mechanism (KEM) and digital signature 
algorithms; a common API for these algorithms; a test harness and 
benchmarking routines.


liboqs is part of the Open Quantum Safe (OQS) project, which aims to 
develop and integrate into applications quantum-safe cryptography to 
facilitate deployment and testing in real world contexts. In particular, 
OQS provides prototype integrations of liboqs into TLS and SSH, through 
OpenSSL and OpenSSH.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1003512: closed by Debian FTP Masters (reply to Patrick Winnertz ) (Bug#1003512: fixed in cherrytree 1.1.0+dfsg-1)

[Andrius Merkys]

Hi Patrick,

On 2024-03-28 17:09, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the wnpp package:

#1003512: RFA: cherrytree -- hierarchical note taking application

It has been closed by Debian FTP Masters  (reply to 
Patrick Winnertz ).


Thanks for taking care of cherrytree!

Best wishes,
Andrius

Bug#943315: ITP: vst3sdk -- professional audio plugin development kit

[Andrius Merkys]

Hello,

I had some luck in packaging vst3sdk. I pushed my packaging attempts 
(just the debian/ directory) to my personal repository on salsa [1]. The 
package builds and installs VST3 plugins, debian/copyright is as well 
almost finished.


I had some difficulties in constructing the multiple upstream tarball 
(MUT). uscan does not seem to be able to handle debian/watch correctly, 
thus I first have to change upstream version to 0 in debian/changelog, 
run 'uscan --download', revert the upstream version in debian/changelog 
and run it again. From downloaded tarballs the MUT is built by 
debian/get-orig-source. I plan to import the constructed MUT into the 
same git repository [1] to simplify its usage, but I will probably 
exclude doc/ subdirectory due to multiple source-is-missing problems.


[1] https://salsa.debian.org/merkys/vst3sdk

Andrius

Bug#1067212: ITP: libgraph-grammar-perl -- Grammar for graphs

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libgraph-grammar-perl
  Version : 0.1.0
  Upstream Author : Andrius Merkys 
* URL : https://metacpan.org/release/Graph-Grammar
* License : BSD-3-Clause
  Programming Lang: Perl
  Description : Grammar for graphs

Graph::Grammar is a Perl implementation of a graph rewriting method 
(a.k.a. graph grammar). Much of the API draws inspiration from 
Parse::Yapp, but instead of acting on text streams Graph::Grammar is 
oriented at graphs, as implemented in Perl's Graph module. 
Graph::Grammar implements a single method parse_graph() which accepts an 
instance of Graph and an array of rules. Every rule is evaluated for 
each vertex in a graph and, if a match is found, an action associated 
with the rule is executed.


Graph::Grammar is a new dependency of chemonomatopist.

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libgraph-grammar-perl

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[Andrius Merkys]

Hi,

On 2024-02-14 00:21, Peter Hyman wrote:

Description : tmpwatch is a utility searches for files not accessed in a
specific time and deletes them


I fail to parse the short description as a sentence. Maybe:

s/utility searches/utility which searches/

Best,
Andrius

Bug#1058865: ITP: python-pubchempy -- pubchem python rest api chemistry cheminformatics

[Andrius Merkys]

Hi Yogeswaran,

On 2023-12-17 09:57, Yogeswaran Umasankar wrote:

* Package name: python-pubchempy
   Version : 1.0.4
   Upstream Contact: Matt Swain
* URL :https://github.com/mcs07/PubChemPy
* License : Expat
   Programming Lang: Python
   Description : pubchem python rest api chemistry cheminformatics


I find this package interesting as well. You may turn to me whenever you 
need a sponsor for it.


Best wishes,
Andrius

Bug#1053729: RFP: SAIL image decoding library

[Andrius Merkys]

Hi Sudip,

On 2023-12-13 12:28, Sudip Mukherjee wrote:

Hi Andrius,

On Wed, Oct 18, 2023 at 08:38:52AM +0300, Andrius Merkys wrote:

Hi Dmitry,

On 2023-10-17 16:25, Dmitry Baryshev wrote:

  > Does it produce desired Debian packages?

I've just pushed a couple of fixes to the Debian rules. I'm able to
build packages on LUbuntu 23.04. Maybe a couple of small fixes are still
needed to build packages on Debian. So the recommended git sha to use is
4705cb4cf96. It's a release candidate and ready to use in client
applications.








OK, makes sense.

Since this is an image decoding library, my personal opinion is that it
would better fit the scope of Debian Multimedia Team instead of Debian
Science Team.


Just wanted to check if you are planning to package this. Its still a
RFP so I guess not, but still want to confirm. If you are not packaging
this then I can take it up.


No, I am not planning to work on packaging SAIL anytime soon, so please 
go ahead.


Thanks,
Andrius

Bug#1056343: ITP: nanovg -- antialiased vector graphics rendering library for OpenGL

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: nanovg
  Version : 0.0~git20230826.f93799c
  Upstream Author : Mikko Mononen 
* URL : https://github.com/memononen/nanovg
* License : Zlib
  Programming Lang: C
  Description : antialiased vector graphics rendering library for 
OpenGL


NanoVG is small antialiased vector graphics rendering library for 
OpenGL. It has lean API modeled after HTML5 canvas API. It is aimed to 
be a practical toolset for building scalable user interfaces and 
visualizations.


NanoVG is embedded in a few Debian packages.

Remark: This package is to be maintained with Debian Multimedia 
Maintainers at

   https://salsa.debian.org/multimedia-team/nanovg

Bug#943315: ITP: vst3sdk -- professional audio plugin development kit

[Andrius Merkys]

Hi IOhannes,

On Wed, 23 Oct 2019 10:31:40 +0200 IOhannes m zmoelnig 
 wrote:

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: vst3sdk
  Version : 3.6.13
  Upstream Author : Steinberg Media Technologies GmbH
* URL : https://github.com/steinbergmedia/vst3sdk
* License : GPL3
  Programming Lang: C
  Description : professional audio plugin development kit

 Virtual Studio Technology (VST) is an audio plugin software interface
 that integrates software synthesizer and effects in digital audio
 workstations.
 VST and similar technologies use digital signal processing to simulate
 traditional recording studio hardware in software.
 .
 VST is the de-facto industry standard for audio plugins and plugin hosts.

I intend to package this under the umbrella of the multimedia-team.


What is the status of this ITP? Did you have any luck in packaging 
vst3sdk? I noticed a packaging repository on salsa, but it seems empty.


Best,
Andrius

Bug#995352: dput tahoe-lafs_1.17.0-1_amd64.changes --delayed 7

[Andrius Merkys]

Hello,

As I have not received any response, I uploaded tahoe-lafs to NEW with 
'--delayed 7'. If you are against it, please let me know and/or 'dcut 
rm' it from delayed NEW queue.


Best wishes,
Andrius

Bug#1054572: ITP: libgraph-moreutils-perl -- utilities for Perl graphs

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libgraph-moreutils-perl
  Version : 0.1.0
  Upstream Author : Andrius Merkys 
* URL : https://metacpan.org/release/Graph-MoreUtils
* License : LGPL-3
  Programming Lang: Perl
  Description : utilities for Perl graphs
 Graph::MoreUtils provides additional utilities for Perl graph handling.
 These utilities work with Perl Graph class objects.

This package is needed to update chemonomatopist (a new dependency).

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libgraph-moreutils-perl

Bug#1053729: RFP: SAIL image decoding library

[Andrius Merkys]

Hi Dmitry,

On 2023-10-17 16:25, Dmitry Baryshev wrote:

 > Does it produce desired Debian packages?

I've just pushed a couple of fixes to the Debian rules. I'm able to 
build packages on LUbuntu 23.04. Maybe a couple of small fixes are still 
needed to build packages on Debian. So the recommended git sha to use is 
4705cb4cf96. It's a release candidate and ready to use in client 
applications.


In Debian the common practice is to separate the upstream repository 
(i.e., the package source) from packaging repository (i.e., where Debian 
packaging instructions are being developed). Common practice is to host 
the latter on salsa.debian.org, usually together with the package 
source. Thus I would suggest following this approach. I have put a short 
guide about how to do that [1].



 > Are these packages lintian-clean?

The only error Lintian showed is "unknown distribution", but this is 
because I run it on Ubunutu.


Right.

 > Do you know any software already in Debian which would benefit from 
having SAIL in Debian?


It's a library and I guess end users will benefit from it.


OK, makes sense.

Since this is an image decoding library, my personal opinion is that it 
would better fit the scope of Debian Multimedia Team instead of Debian 
Science Team.


[1] https://wiki.debian.org/AndriusMerkys/PackagingInSeconds

Best wishes,
Andrius

Bug#1053729: RFP: SAIL image decoding library

[Andrius Merkys]

Hi Dmitry,

On 2023-10-17 13:29, Dmitry Baryshev wrote:
It would be great to have SAIL in Debian, at least in experimental. It's 
a C/C++ image decoding library similar to FreeImage. It's already 
available in Conan and VCPKG with thousands of installations.


Website: https://sail.software/ 
GitHub:https://github.com/HappySeaFox/sail 

RFP request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053729 


Build system: CMake
Debian rules: Yes, but need revisiting

Please pardon me if I'm writing to a wrong mailing list. Please CC any 
comments as I'm not in the list.


I saw the GitHub repository already has debian/ directory, this is a 
good start. Does it produce desired Debian packages? Are these packages 
lintian-clean? Do you know any software already in Debian which would 
benefit from having SAIL in Debian?


Best wishes,
Andrius

Bug#1054097: ITP: libparse-man-perl -- Perl library for parsing nroff-formatted manpages

[Andrius Merkys]

Hi Ole,

On 2023-10-17 02:05, Ole Peder Brandtzæg wrote:

Package: wnpp
Severity: wishlist
Owner: Andrius Merkys 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libparse-man-perl
   Version : 0.03
   Upstream Author : Paul Evans 
* URL : https://metacpan.org/dist/Parse-Man
* License : Perl 5
   Programming Lang: Perl
   Description : Perl library for parsing nroff-formatted manpages

Parse::Man, an abstract subclass of Parser::MGC, recognises nroff
grammar from a file or string value. It invokes methods when various
nroff directives are encountered. It is intended that this class be used
as a base class, with methods provided to handle the various directives
and formatting options. Typically a subclass will store intermediate
results in a data structure, building it as directed by these method
invocations.

This is a dependency of sdview/libapp-sdview-perl (see #1054001);
Andrius expressed interest in having Parse::Man in Debian and offered to
package it, hence I've marked him as the owner of this bug.


I have just uploaded libparse-man-perl. You may find its packaging 
repository on salsa:


https://salsa.debian.org/perl-team/modules/packages/libparse-man-perl

Feel free to add yourself to the list of its uploaders.

Best wishes,
Andrius

Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

[Andrius Merkys]

Hi Ole,

On Mon, 16 Oct 2023, 00:09 Ole Peder Brandtzæg,  wrote:

> On Sun, Oct 15, 2023 at 07:49:58PM +0300, Andrius Merkys wrote:
> > I am as well interested in having Parse::Man in Debian. I can help you by
> > packaging it if you wish.
>
> Wonderful, should I just file another wnpp bug for it?
>

Yes, please. You may put me as the owner of the bug to mark that I take
responsibility for packaging it.

Best,
Andrius

>

Bug#1054001: ITP: libapp-sdview-perl -- terminal document viewer for POD and other syntaxes

[Andrius Merkys]

Hi Ole,

On Sun, 15 Oct 2023, 19:42 Ole Peder Brandtzæg,  wrote:

> libapp-sdview-perl does depend on a few other modules (all by the same
> upstream author) not presently packaged in Debian, so they would need to
> be packaged, too, but I figured I should file this first. They are:
>
> - Object::Pad::FieldAttr::Checked [0]
> - Parse::Man [1]
> - String::Tagged::Markdown [2]
>
> All the best,
> Ole
>
> [0]: https://metacpan.org/dist/Object-Pad-FieldAttr-Checked
> [1]: https://metacpan.org/dist/Parse-Man
> [2]: https://metacpan.org/dist/String-Tagged-Markdown


I am as well interested in having Parse::Man in Debian. I can help you by
packaging it if you wish.

Best,
Andrius

Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Andrius Merkys]

Hi Yadd,

On 2023-10-11 09:39, Yadd wrote:

Better view of dependencies (`npm2deb depends` is often false):

$ pkgjs-depends vite
# vite@4.4.11
# 13 missing npm module(s)
DEPENDENCIES:
   esbuild (esbuild)
   node-chokidar (chokidar)
   node-immutable (immutable)
   node-less (less)
   node-postcss (postcss, source-map-js)
   node-pre-gyp (detect-libc)
   node-stylus (stylus)
   node-terser (terser)
   nodejs (@types/node)
   rollup (rollup)

MISSING:
vite@4.4.11
  └── fsevents (2.3.3) # BANNED (not compatible with linux)
  └── lightningcss (1.22.0)
  └── lightningcss-darwin-arm64 (1.22.0)
  └── lightningcss-darwin-x64 (1.22.0)
  └── lightningcss-freebsd-x64 (1.22.0)
  └── lightningcss-linux-arm-gnueabihf (1.22.0)
  └── lightningcss-linux-arm64-gnu (1.22.0)
  └── lightningcss-linux-arm64-musl (1.22.0)
  └── lightningcss-linux-x64-gnu (1.22.0)
  └── lightningcss-linux-x64-musl (1.22.0)
  └── lightningcss-win32-x64-msvc (1.22.0)
  └── sass (1.69.2) # easy to replace by node-sass
  └── sugarss (4.0.1)

The "lignthningcss-*" are prebuilt objects, lightningcss should build 
only required package


Thanks, this gives much more optimism than npm2deb generated list. It 
seems that fsevents are not needed at all, thus lightningcss and sugarss 
seem to be the only lacking dependencies.


Best,
Andrius

Bug#1053782: RFP: node-vite -- Next Generation Frontend Tooling

[Andrius Merkys]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
Control: block 1042095 by -1

* Package name: node-vite
  Version : 4.4.11
  Upstream Author : Evan You
* URL : https://github.com/vitejs/vite
* License : Expat
  Programming Lang: JavaScript
  Description : Next Generation Frontend Tooling

Vite is a frontend build tool, including development server and build 
command bundling code with Rollup, pre-configured to output optimized 
static assets for production.


Vite is needed to produce CSS and JS files for sphinx-press-theme.

An estimate of work needed to package Vite:

$ npm2deb depends vite
Dependencies:
NPM   Debian
vite (4.4.11) None
├─ esbuild (^0.18.10) None
├─ fsevents (~2.3.2)  None
├─ postcss (^8.4.27)  node-postcss 
(8.4.20+~cs8.0.23-1)

└─ rollup (^3.27.1)   node-rollup (3.28.0-2)

Build dependencies:
NPM   Debian
@ampproject/remapping (^2.2.1) node-ampproject-remapping 
(2.2.0+~cs5.15.37-1)

@babel/parser (^7.22.7)   None
@babel/types (^7.22.5)node-babel 
(6.26.0+repack-3~bpo10+1)

@jridgewell/trace-mapping (^0.3.18)   None
@rollup/plugin-alias (^4.0.4) node-rollup-plugin-alias (5.0.0~ds-1)
@rollup/plugin-commonjs (^25.0.3) node-rollup-plugin-commonjs (25.0.4+ds1-1)
@rollup/plugin-dynamic-import-vars (^2.0.4)   None
@rollup/plugin-json (^6.0.0) node-rollup-plugin-json (6.0.0+ds1-2)
@rollup/plugin-node-resolve (15.1.0) node-rollup-plugin-node-resolve 
(15.1.0+ds-1)
@rollup/plugin-typescript (^11.1.2) node-rollup-plugin-typescript 
(11.1.2~ds+~1.0.1-1)

@rollup/pluginutils (^5.0.2) node-rollup-pluginutils (5.0.2~ds+~2.8.2-1)
@types/escape-html (^1.0.2)   None
@types/pnpapi (^0.0.2)None
acorn (^8.10.0)   acorn 
(8.8.1+ds+~cs25.17.7-2)

acorn-walk (^8.2.0)   None
cac (^6.7.14) None
chokidar (^3.5.3) node-chokidar (3.5.3-2)
connect (^3.7.0)  node-connect 
(3.7.0+~3.4.35-1)

connect-history-api-fallback (^2.0.0) None
convert-source-map (^2.0.0) node-convert-source-map (1.9.0+~1.5.2-1)
cors (^2.8.5) node-cors (2.8.5-1)
cross-spawn (^7.0.3)  node-cross-spawn (5.1.0-2)
debug (^4.3.4)node-debug 
(4.3.4+~cs4.1.7-1)

dep-types (link:./src/types)  None
dotenv (^16.3.1)  None
dotenv-expand (^9.0.0)None
es-module-lexer (^1.3.0)  node-es-module-lexer 
(1.1.0+dfsg-2)
escape-html (^1.0.3)  node-escape-html 
(1.0.3+~1.0.2-2)
estree-walker (^3.0.3)node-estree-walker 
(2.0.2-5)

etag (^1.8.1) node-etag (1.8.1-3)
fast-glob (^3.3.1)None
http-proxy (^1.18.1)  node-http-proxy (1.18.1-8)
json-stable-stringify (^1.0.2) node-json-stable-stringify 
(1.0.2+repack1+~cs1.0.34-2)

launch-editor-middleware (^2.6.0) None
lightningcss (^1.21.5)None
magic-string (^0.30.2)node-magic-string 
(0.30.1-1)
micromatch (^4.0.5)   node-micromatch 
(4.0.5+~4.0.2-1)

mlly (^1.4.0) None
mrmime (^1.0.1)   None
okie (^1.0.1) None
open (^8.4.2) node-open (8.4.0-6)
parse5 (^7.1.2)   node-parse5 (7.1.2+dfsg-2)
periscopic (^3.1.0)   None
picocolors (^1.0.0)   node-picocolors (1.0.0-4)
picomatch (^2.3.1)node-anymatch 
(3.1.3+~cs4.6.1-2)

postcss-import (^15.1.0)  None
postcss-load-config (^4.0.1) node-postcss-load-config (2.1.2+~cs6.0.0-1)
postcss-modules (^6.0.0)  node-postcss-modules 
(6.0.0+~cs5.1.3-2)

resolve.exports (^2.0.2)  None
rollup-plugin-license (^3.0.1)None
sirv (^2.0.3) None
source-map-support (^0.5.21) node-source-map-support (0.5.21+ds+~0.5.4-1)
strip-ansi (^7.1.0)   node-strip-ansi (6.0.1-2)
strip-literal (^1.3.0)None
tsconfck (^2.1.2) None
tslib (^2.6.1)node-tslib (2.4.1-1)
types (link:./types) 

Bug#995352: tahoe-lafs: progress

[Andrius Merkys]

X-Debbugs-Cc: team+tahoe-t...@tracker.debian.org

On Wed, 25 Jan 2023 14:10:37 +0200 Andrius Merkys  wrote:
I have achieved some progress in packaging tahoe-lafs 1.17.0 locally. 
Almost all required dependencies are in Debian already, except 
python-pyutil (ITP #1029567) which I have uploaded to NEW and 
python-collections-extended (ITP #1029488) which is a bit more 
problematic due to failing tests.


With these dependencies tahoe-lafs passes most of its tests (throwing a 
lot of DeprecationWarnings on the way). Some tests fail and I will 
return to them when I find time.


All the mentioned dependencies have entered Debian. The package for 
tahoe-lafs 1.17.0 builds successfully despite a couple of tests failing 
due to minor reasons. I have pushed the packaging to salsa [1] and would 
like to proceed with uploading if reporter and owner of the ITP bug 
agree. I would as well be happy to join Debian Tahoe Team and 
co-maintain the package.


[1] https://salsa.debian.org/merkys/tahoe-lafs

Best wishes,
Andrius

Bug#1053489: ITP: scikit-build-core -- Python package build systems and CMake integration

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: scikit-build-core
  Version : 0.5.1
  Upstream Author : Henry Schreiner
* URL : https://github.com/scikit-build/scikit-build-core
* License : Apache-2.0
  Programming Lang: Python
  Description : Python package build systems and CMake integration

Scikit-build-core is a ground-up rewrite of Scikit-build, a bridge 
between Python package build systems and CMake.


This is a new build dependency for spglib.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/scikit-build-core

Bug#1052636: ITP: tuning-library -- Surge Synth Team Tuning Library

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1025206 by -1

* Package name: tuning-library
  Version : 1.1.0+ds
  Upstream Author : Paul Walker
* URL : https://github.com/surge-synthesizer/tuning-library
* License : Expat
  Programming Lang: C
  Description : Surge Synth Team Tuning Library

Standalone C++ header only library for microtuning.

MTS-ESP is needed by bespokesynth (ITP #1025206)

Remark: This package is to be maintained with Debian Multimedia 
Maintainers at

   https://salsa.debian.org/merkys/tuning-library

I preemptively pushed the package to personal space on salsa, but will 
ask to have it moved to Debian Multimedia Maintainers space.

Bug#1052621: ITP: mts-esp -- microtuning support to audio and MIDI plugins

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1025206 by -1

* Package name: mts-esp
  Version : 0.0~git20230110.9df9a9c
  Upstream Author : ODDSound Ltd.
* URL : https://github.com/ODDSound/MTS-ESP
* License : 0BSD
  Programming Lang: C
  Description : microtuning support to audio and MIDI plugins

The MTS-ESP library is a simple but versatile C/C++ library for adding
microtuning support to audio and MIDI plugins. It allows for a single 
master plugin to simultaneously control the tuning of any number of 
connected client plugins across a DAW session. Connection between a 
master and clients is automatic and invisible.


MTS-ESP is needed by bespokesynth (ITP #1025206)

Remark: This package is to be maintained with Debian Multimedia 
Maintainers at

   https://salsa.debian.org/multimedia-team/mts-esp

Bug#1025206: bespoke: RFP -> ITP

[Andrius Merkys]

Control: retitle -1 ITP: bespokesynth -- modular music synthesizer
Control: owner -1 !

Hello,

I managed to successfully build bespokesynth, thus I am taking ownership 
of this RFP.


Andrius

Bug#970575: pytorch-geometric: RFP -> ITP

[Andrius Merkys]

Control: retitle -1 ITP: pytorch-geometric -- Geometric Deep Learning
Control: owner -1 !

Hello,

I managed to successfully build pytorch-geometric. Will upload soon.

Andrius

Bug#1052148: ITP: pytorch-cluster -- PyTorch extension library of optimized graph cluster algorithms

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 970575 by -1

* Package name: pytorch-cluster
  Version : 1.6.1
  Upstream Author : Matthias Fey
* URL : https://github.com/rusty1s/pytorch_cluster
* License : Expat
  Programming Lang: C
  Description : PyTorch extension library of optimized graph 
cluster algorithms (Python 3)


This package consists of a small extension library of highly optimized 
graph cluster algorithms for the use in PyTorch. The package consists of 
the following clustering algorithms:


  * Graclus from Dhillon et al.: Weighted Graph Cuts without 
Eigenvectors: A

Multilevel Approach
  * Voxel Grid Pooling from, e.g., Simonovsky and Komodakis: Dynamic
Edge-Conditioned Filters in Convolutional Neural Networks on Graphs
  * Iterative Farthest Point Sampling from, e.g. Qi et al.: PointNet++: 
Deep

Hierarchical Feature Learning on Point Sets in a Metric Space
  * k-NN and Radius graph generation
  * Clustering based on nearest points
  * Random Walk Sampling from, e.g., Grover and Leskovec: node2vec: 
Scalable

Feature Learning for Networks

All included operations work on varying data types and are implemented 
both for CPU and GPU.


pytorch-cluster is a test dependency for pytorch-geometric (ITP bug 
#970575).


Remark: This package is to be maintained with Debian Deep Learning Team at
   https://salsa.debian.org/deeplearning-team/pytorch-cluster

Bug#1043349: RFA: node-assume -- Expect-like assertions that work in node and the browser

[Andrius Merkys]

Package: wnpp

Hello,

I would like to pass the maintenance of node-assume to someone more
motivated. The package is in good shape. I sponsored its initial upload, 
but in the end I did not use it. Now it seems to be used by a bunch of 
node-* packages.


Package description from debian/control:

 Assume is an expect inspired assertion library who's sole purpose is 
to create
 a working and human readable assert library for browsers and node. The 
library

 is designed to work with different assertion styles.
 .
 Assume is written with client and server-side Javascript in mind and uses
 commonjs module system to export itself.
 .
 This package is used as a build dependency for other Debian packages.
 Specifically it is used in the testing phase of the build process.

Andrius

Bug#976981: Bug#1042574: RM: theano, keras, deepnano -- RoM (theano), broken by numpy 1.24, theano mostly abandoned upstream

[Andrius Merkys]

On 2023-07-30 18:35, Rebecca N. Palmer wrote:
theano's reverse dependencies (keras and deepnano) are both also broken 
by this.  keras _also_ has apparently unrelated problems, #1026738, and 
is orphaned, #1027938.


This was previously discussed in #1027215 (on, among others, deepnano's 
team list), where it was noted that removing keras would also block the 
addition of qmean (ITP #976981), but attempts to fix theano failed.


There seems to be hope for keras: keras 3 is going to be released this 
fall [1], again with support for multiple backends including less 
problematic pytorch. Maybe it is worth to keep src:keras for the time 
being, until keras 3 arrives?


[1] https://keras.io/keras_core/announcement/

Andrius

Bug#976981: Bug#1042574: RM: theano, keras, deepnano -- RoM (theano), broken by numpy 1.24, theano mostly abandoned upstream

[Andrius Merkys]

Hi,

On 2023-07-30 18:35, Rebecca N. Palmer wrote:
theano has been mostly abandoned upstream since 2018.  (The Aesara fork 
is not abandoned, but includes interface changes including the import 
name, so would break reverse dependencies not specifically altered to 
use it.  Neither of the two in Debian are so altered.)


Since numpy 1.24, theano has been completely broken (won't even import). 
  Some parts of this are fixable (#1033589), but other parts have no 
known fix (#1027215).  Note that the "OK" status on Salsa CI is *not* an 
actual fix, but is because theano skips most of its tests in Salsa CI 
because they take several hours.


theano's reverse dependencies (keras and deepnano) are both also broken 
by this.  keras _also_ has apparently unrelated problems, #1026738, and 
is orphaned, #1027938.


This was previously discussed in #1027215 (on, among others, deepnano's 
team list), where it was noted that removing keras would also block the 
addition of qmean (ITP #976981), but attempts to fix theano failed.


This is sad news for qmean. I got the package up and running and I use 
it quite a lot (built locally currently due to unresolved issues with 
pretrained network weights). The only viable solution I see right now is 
to ask qmean's upstream to migrate away from keras.


Best,
Andrius

Bug#1039466: ITP: frugally-deep -- use Keras models in C++

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: frugally-deep
  Version : 0.15.20
  Upstream Author : Tobias Hermann
* URL : https://github.com/Dobiasd/frugally-deep
* License : Expat
  Programming Lang: C++
  Description : use Keras models in C++

frugally-deep is a small header-only library written in modern and pure 
C++. It supports inference for sequential models and computational 
graphs with a more complex topology, created with the functional API. It 
re-implements a small subset of TensorFlow, i.e., the operations needed 
to support prediction. frugally-deep results in a much smaller binary 
size than linking against TensorFlow. It avoids temporarily allocating 
additional RAM during convolutions (by not materializing the im2col 
input matrix).


The package is required to update voronota.

Remark: This package is to be maintained with The Debichem Group at
   https://salsa.debian.org/debichem-team/frugally-deep

Bug#1039462: ITP: functionalplus -- helpers to write concise and readable C++ code

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: functionalplus
  Version : 0.2.18
  Upstream Author : Tobias Hermann and the FunctionalPlus contributors
* URL : https://github.com/Dobiasd/FunctionalPlus
* License : BSL-1.0
  Programming Lang: C++
  Description : helpers to write concise and readable C++ code

FunctionalPlus is a small header-only library used to increase the 
brevity and maintainability of code. It strives to provide pure and 
easy-to-use functions implementing commonly used flows of control.


This package is needed to update voronota.

Remark: This package is to be maintained with Andrius Merkys at
   https://salsa.debian.org/debian/functionalplus

Bug#1036966: ITP: chemonomatopist -- derive IUPAC systematic names for chemical structures

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: chemonomatopist
  Version : 0.4.0
  Upstream Author : Andrius Merkys, Miglė Urbonaitė
* URL : https://github.com/merkys/ChemOnomatopist
* License : BSD-3-Clause
  Programming Lang: Perl
  Description : derive IUPAC systematic names for chemical structures

ChemOnomatopist is a tool to derive IUPAC systematic names for chemical 
structures. It analyses chemical graphs to determine IUPAC names 
according to the "Nomenclature of Organic Chemistry. IUPAC 
Recommendations and Preferred Names 2013", also known as the Blue Book.


Remark: This package is to be maintained with Debichem Team.

Bug#1002470:

[Andrius Merkys]

On 2023-05-27 14:54, Fioddor Superconcentrado wrote:

Any update here?


Some additional details. The package builds and installs successfully, 
and I have collected the required build dependencies to debian/control. 
I did not do anything about the server, though. The upstream provides 
their own debs and possibly the easiest way would be to mimic their setup.


Andrius

Bug#1002470:

[Andrius Merkys]

Hi,

On 2023-05-27 14:54, Fioddor Superconcentrado wrote:

Any update here?


Not much since. I dropped the ball at the stage of collecting the 
dependencies. Also it needs lucene9 (still in NEW).


Do you have your (unfinished) work publicly available? I don't see this 
in salsa (https://salsa.debian.org/users/merkys-guest/projects 
 or 
https://salsa.debian.org/users/merkys/projects 
)


You are right, it has not been pushed. Now I have pushed it to:

https://salsa.debian.org/merkys/opensearch

Let me know if you reach any progress with it.

Best,
Andrius

Bug#1031713: ITP: python-klein -- micro-framework for developing web services with Python

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 995352

* Package name: python-klein
  Version : 21.8.0
  Upstream Author : Aaron Gallagher et al.
* URL : https://github.com/twisted/klein
* License : Expat
  Programming Lang: Python
  Description : micro-framework for developing web services with Python

Klein is a micro-framework for developing production-ready web services 
with Python. It is 'micro' in that it has an incredibly small API 
similar to Bottle and Flask. It is not 'micro' in that it depends on 
things outside the standard library. This is primarily because it is 
built on widely used and well tested components like Werkzeug and Twisted.


klein is needed by tahoe-lafs.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-klein

Bug#1031491: ITP: libmusic-chord-namer-perl -- given notes, return the best chord name

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libmusic-chord-namer-perl
  Version : 0.01
  Upstream Author : Jimi-Carlo Bukowski-Wills
* URL : https://metacpan.org/release/Music-Chord-Namer
* License : Artistic
  Programming Lang: Perl
  Description : given notes, return the best chord name

Music::Chord::Namer optionally exports one sub, chordname, which accepts 
some notes as either a string or a list and returns the best chord name 
it can think of.


Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libmusic-chord-namer-perl

Bug#1021041: ITP: parallel-hashmap --

[Andrius Merkys]

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#1031272: ITP: pytorch-scatter -- PyTorch Extension Library of Optimized Scatter Operations

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1031265 by -1

* Package name: pytorch-scatter
  Version : 2.1.0
  Upstream Author : Matthias Fey
* URL : https://github.com/rusty1s/pytorch_scatter
* License : Expat
  Programming Lang: C
  Description : PyTorch Extension Library of Optimized Scatter 
Operations


This package consists of a small extension library of highly optimized 
sparse update (scatter and segment) operations for the use in PyTorch, 
which are missing in the main package. Scatter and segment operations 
can be roughly described as reduce operations based on a given 
"group-index" tensor. Segment operations require the "group-index" 
tensor to be sorted, whereas scatter operations are not subject to these 
requirements.


Remark: This package is to be maintained with Debian Deep Learning Team at
   https://salsa.debian.org/deeplearning-team/pytorch-scatter

Bug#1031265: ITP: pytorch-sparse -- PyTorch Extension Library of Optimized Autograd Sparse Matrix Operations

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 970575 by -1
Control: block -1 by 1021041

* Package name: pytorch-sparse
  Version : 0.6.16
  Upstream Author : Matthias Fey
* URL : https://github.com/rusty1s/pytorch_sparse
* License : Expat
  Programming Lang: Python
  Description : PyTorch Extension Library of Optimized Autograd 
Sparse Matrix Operations


This package consists of a small extension library of optimized sparse 
matrix operations with autograd support.


pytorch-sparse is needed by pytorch-geometric.

To be maintained under Debian Deep Learning Team 

Bug#1031205: ITP: libmusic-scales-perl -- supply necessary notes/offsets for musical scales

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libmusic-scales-perl
  Version : 0.07
  Upstream Author : Ben Daglish
* URL : https://metacpan.org/release/Music-Scales
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : supply necessary notes/offsets for musical scales

Music::Scales supplies notes/offsets for assorted musical scales. Given 
a keynote A-G(#/b) and a scale-name, it will return the scale in a 
number of formats - as an array of notenames, a hash of semitone-offsets 
for each note, or in MIDI/PDL format.


I plan to use this module in my music theory applications.

Remark: This package is to be maintained with Debian Perl Group at
   https://salsa.debian.org/perl-team/modules/packages/libmusic-scales-perl

Bug#1030247: ITP: libtext-names-perl -- module for proper name parsing, normalization, recognition and classification

[Andrius Merkys]

Hi Mason,

On 2023-02-01 17:04, m...@kohaaloha.com wrote:

Text::Namess provides a number of name normalization routines, plus

 ^

Letter 's' is duplicated (Namess) in package description in debian/control.

Best,
Andrius

Bug#1030296: ITP: libobject-extend-perl -- add and override per-object methods

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: libobject-extend-perl
  Version : 0.4.0
  Upstream Author : chocolateboy 
* URL : https://metacpan.org/release/Object-Extend
* License : Artistic
  Programming Lang: Perl
  Description : add and override per-object methods

Object::Extend allows objects to be extended with per-object methods, 
similar to the use of singleton methods in Ruby. Object methods are 
added to an object-specific shim class (known as an eigenclass), which 
extends the object's original class. The original class is left unchanged.


I find this Perl package useful to override methods in existing objects.

Remark: This package is to be maintained with Debian Perl Group at

https://salsa.debian.org/perl-team/modules/packages/libobject-extend-perl

Bug#1029765: ITP: python-tubes -- data-processing and flow-control engine for event-driven programs

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-tubes
  Version : 0.2.1
  Upstream Author : Allen Short
* URL : https://github.com/twisted/tubes
* License : Expat
  Programming Lang: Python
  Description : data-processing and flow-control engine for 
event-driven programs


Tubes is a data-processing and flow-control engine for event-driven 
programs. Presently based primarily on Twisted, its core data structures 
are fairly framework-agnostic and could be repurposed to work with any 
event-driven container.


tubes is a dependency of klein which is in turn needed by tahoe-lafs.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-tubes

Bug#930578: #930578: ITP: txi2p -> RFP: txi2p

[Andrius Merkys]

Control: retitle -1 RFP: txi2p -- I2P bindings for Twisted
Control: noowner !

On Wed, 13 Oct 2021 09:28:28 +0300 Andrius Merkys  wrote:

Control: retitle -1 ITP: txi2p -- I2P bindings for Twisted
Control: owner -1 !
Control: tags -1 + patch


Since tahoe-lafs does not need this anymore (replaced with txi2p-tahoe), 
I am changing this ITP back to RFP.


Andrius

Bug#995352: tahoe-lafs: progress

[Andrius Merkys]

Hello,

I have achieved some progress in packaging tahoe-lafs 1.17.0 locally. 
Almost all required dependencies are in Debian already, except 
python-pyutil (ITP #1029567) which I have uploaded to NEW and 
python-collections-extended (ITP #1029488) which is a bit more 
problematic due to failing tests.


With these dependencies tahoe-lafs passes most of its tests (throwing a 
lot of DeprecationWarnings on the way). Some tests fail and I will 
return to them when I find time.


Would it make sense to push my packaging efforts to salsa?

Best,
Andrius

Bug#1029567: ITP: python-pyutil -- library of useful Python functions and classes

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 995352 by -1

* Package name: python-pyutil
  Version : 0.0~git20221225.46c0611
  Upstream Author : tpltnt 
* URL : https://github.com/tpltnt/pyutil
* License : GPL-2.0+ or SPL-1+ or TGPPL-1.0+
  Programming Lang: Python
  Description : library of useful Python functions and classes

Many of these utilities (or their ancestors) were developed originally 
by Zooko Wilcox-O'Hearn for the Mojo Nation, Mnet, Allmydata.com 
Mountain View, Tahoe-LAFS, or SimpleGeo's products.


python-pyutil is needed by tahoe-lafs.

Remark: This package is to be maintained with Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-pyutil

Bug#1029488: ITP: python-collections-extended -- Extra Python Collections - bags, setlists, RangeMap and IndexedDict

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 995352 by -1

* Package name: python-collections-extended
  Version : 2.0.2
  Upstream Author : Michael Lenzen
* URL : https://github.com/mlenzen/collections-extended
* License : Apache-2.0
  Programming Lang: Python
  Description : Extra Python Collections - bags, setlists, RangeMap 
and IndexedDict


collections_extended is a pure Python module with no dependencies providing:

  * a bag class, also known as multiset,
  * a setlist class, which is a unique list or ordered set,
  * a bijection class, RangeMap which is a mapping from ranges to values,
  * a IndexedDict class, which is an ordered mapping whose elements can 
be accessed using index, in addition to key.


 There are also frozen (hashable) varieties of bags and setlists.

collections-extended is a dependency of tahoe-lafs. As of 2.0.2, the 
package is not compatible with Python 3.11 [1] which is a blocker to get 
it into Debian.


Remark: This package is to be maintained with Debian Python Team at

https://salsa.debian.org/python-team/packages/python-collections-extended

[1] https://github.com/mlenzen/collections-extended/issues/198

Bug#1029229: Relationship between txi2p and python-txi2p-tahoe

[Andrius Merkys]

Hello,

tahoe-lafs maintainers have forked txi2p (ITP #930578) as txi2p-tahoe 
(ITP #1029229) to have Python 3 support which is unavailable in the 
original txi2p. Therefore I intend to package txi2p-tahoe as 
src:python-txi2p-tahoe in Debian to provide the missing dependency for 
tahoe-lafs.


Both txi2p and txi2p-tahoe use the same Python module name txi2p. 
Nevertheless I plan to name txi2p-tahoe binary package 
python3-txi2p-tahoe to avoid possible future name clash (and the need 
for epoch) with mainstream txi2p.


Andrius

Bug#1029229: ITP: python-txi2p-tahoe -- txi2p is a set of I2P bindings for Twisted

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Control: unblock 995352 by 930578
Control: block 995352 by -1
Severity: wishlist

* Package name: python-txi2p-tahoe
  Version : 0.3.7
  Upstream Author : Aaron Gallagher <_...@habnab.it>
* URL : https://github.com/tahoe-lafs/txi2p
* License : ISC
  Programming Lang: Python
  Description : txi2p is a set of I2P bindings for Twisted

txi2p is a set of I2P bindings for Twisted 10.1 or greater. txi2p
supports both the SAM and BOB APIs for I2P. The default API is SAM.

I am aware of ITP for txi2p (#930578). I will describe their interaction 
in a follow-up message soon.


Remark: This package is to be maintained with Python Team at
   https://salsa.debian.org/python-team/packages/python-txi2p-tahoe

Bug#1002470: opensearch: RFP -> ITP

[Andrius Merkys]

Control: retitle -1 ITP: opensearch -- search engine, fork of Elasticsearch
Control: owner -1 !

Hello,

I had some success in building OpenSearch with Debian-provided 
dependencies. Some parts of the source had to be skipped, but not much. 
I will push my packaging to salsa once I figure out the source does not 
contain anything non-free.


Andrius

Bug#1013214: O: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++

[Andrius Merkys]

On 2022-12-19 20:26, M. Zhou wrote:

Sure, just do whatever you see appropriate, since you are the\
future maintainer  Thanks for taking it over!


Great, thank you!

Best wishes,
Andrius

Bug#1013214: O: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++

[Andrius Merkys]

Hi,

On Sat, 18 Jun 2022 20:04:05 -0700 "M. Zhou"  wrote:

I intend to orphan the asmjit package.


I would like to adopt the package inside Debian Deep Learning Team. 
However, I would drop the artificial shared library as asmjit is 
explicitly unstable [1]. Is it OK?


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013214#12

Andrius

Bug#971356: ITA: python-redmine -- Python library for the Redmine RESTful API (Python 3)

[Andrius Merkys]

Hi Matt,

On Thu, 16 Jun 2022 17:30:49 -0400 Matt Barry  wrote:

retitle -1 ITA python-redmine -- Python library for the Redmine RESTful API 
(Python 3)
thanks


I understand this as your intent to adopt python-redmine (your email 
probably was intended to control@ rather than 971356@). Are you still 
interested in adopting this package? There were no uploads from you.


Andrius

Bug#1025306: ITP: carrotsearch-procfork -- process forking/killing utility

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1020551 by -1

* Package name: carrotsearch-procfork
  Version : 1.0.6~git20211215.86e726d+ds
  Upstream Author : Dawid Weiss
* URL : https://github.com/carrotsearch/procfork
* License : BSD-3-Clause-with-acknowledgement
  Programming Lang: Java
  Description : Process forking/killing utility

carrotsearch-procfork is required to package lucene9.

Remark: This package is to be maintained with Debian Java Maintainers at
   https://salsa.debian.org/java-team/carrotsearch-procfork

Bug#1020551: RFP: lucene9 -- full-text search engine library for Java

[Andrius Merkys]

Hello,

Buildsystem is Gradle. Nevertheless, I had some success in building 
lucene9 using plain javahelper:


$ find . -name module-info.java | xargs rm
$ 
CLASSPATH=/usr/share/java/junit4.jar:/usr/share/java/randomizedtesting-runner.jar:/usr/share/java/spatial4j.jar:/usr/share/java/antlr4-runtime.jar:/usr/share/java/jetty9-server.jar:/usr/share/java/httpclient.jar:/usr/share/java/assertj-core.jar:/usr/share/java/opennlp-tools.jar:/usr/share/java/morfologik-stemming.jar:/usr/share/java/icu4j.jar:/usr/share/java/morfologik-polish.jar:/usr/share/java/s2-geometry-library-java.jar:/usr/share/java/hppc.jar 
jh_build --no-javadoc --javacopts='-source 11 -encoding UTF-8' 
lucene.jar lucene/


This leaves with ~150 errors, some of them due to unpackaged 
dependencies, such as procfork.


Andrius

Bug#1013214: O: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++

[Andrius Merkys]

Hello,

I have stumbled upon asmjit while packaging openmm. Asmjit is also 
embedded at least in erlang and mame [1], thus packaging it might be a 
good idea. However, asmjit is not yet stable [2], thus the shared 
library approach might not be appropriate: breaking changes will 
interfere with shared library handling in Debian and are likely to cause 
mess if sonames are not changed. A bit better approach, IMO, would be to 
ship static library. Anyway it is quite early to unembed asmjit from 
other sources.


[1] 
https://codesearch.debian.net/search?q=This+file+is+part+of+AsmJit+project=1

[2] https://asmjit.com/doc/group__asmjit__breaking__changes.html

Andrius

Bug#1022157: ITP: python-mpiplus -- Python GPU framework for alchemical free energy calculations

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-mpiplus
  Version : 0.0.1
  Upstream Author : Chodera Lab
* URL : https://github.com/choderalab/mpiplus
* License : Expat
  Programming Lang: Python
  Description : Python GPU framework for alchemical free energy 
calculations


GPU-accelerated Python framework for exploring algorithms for alchemical 
free energy calculations.


python-mpiplus is needed to package openmmtools.

Remark: This package is to be maintained with Debian Science Maintainers 
at https://salsa.debian.org/science-team/python-mpiplus

Bug#1022000: ITP: clipper -- Cross-platform clipboard access in Go

[Andrius Merkys]

Hi,

On Wed, 19 Oct 2022 00:12:23 +0530 rajudev  wrote:

* Package name    : clipper


This source package name clashes with already existing clipper package 
in Debian Science.


Andrius

Bug#897673: coot packaging: update

[Andrius Merkys]

Hello,

I gave coot 1.0.05 a try. The package builds successfully, but is not 
installable as some of the code still is in Python2.


Andrius

Bug#1021395: ITP: jumbo -- Java library for processing CML

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: jumbo
  Version : 6.0
  Upstream Author : Peter Murray-Rust et al.
* URL : https://github.com/BlueObelisk/jumbo6
* License : Apache-2.0
  Programming Lang: Java
  Description : Java library for processing CML

JUMBO is a library which validates and supports CML Schema.

jumbo is needed by jumbo-converters, converter package to and from CML, 
Chemical Markup Language.


Remark: This package is to be maintained with Debian Java Maintainers at
   https://salsa.debian.org/java-team/jumbo

Bug#944785: pufferfish wants to link with twopaco and ntcard

[Andrius Merkys]

Hi Andreas,

On 2022-10-04 12:54, Andreas Tille wrote:

Am Tue, Oct 04, 2022 at 10:38:01AM +0300 schrieb Andrius Merkys:

Alas, I did not get far. Static libraries for ntcard and twopaco are
easy to add (I have pushed 'static-library' branches to salsa for these
packages). However, pufferfish has patched main() functions of ntcard
and twopaco executables in order to use them in internal calls.


This sounds like you should keep the code copies (which was your initial
strategy anyway if I remember correctly).
  

At this point I do not think much can be done without getting the
upstreams of pufferfish, ntcard and twopaco to align their interfaces.


IMHO we need some fast migration path of pufferfish into Debian to
get salmon fixed / updated.  I do not have the feeling that aligning
upstreams is a promising way to be fast.


Agree. I would suggest bringing back the embedded twopaco and ntcard for 
now, launching upstream alignment in the background.


Best,
Andrius

Bug#1021296: ITP: chemicaltagger -- tool for semantic text-mining in chemistry

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: chemicaltagger
  Version : 1.6.2
  Upstream Author : Lezan Hawizy, David M. Jessop, Daniel Lowe and Peter
Murray-Rust
* URL : https://github.com/BlueObelisk/chemicaltagger
* License : Apache-2.0
  Programming Lang: Java
  Description : tool for semantic text-mining in chemistry

ChemicalTagger parser is a medium-depth, phrase-based semantic NLP tool
for the language of chemical experiments. Tagging is based on a modular
architecture and uses a combination of OSCAR, domain-specific regex and
English taggers to identify parts-of-speech. The ANTLR grammar is used
to structure this into tree-based phrases.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/chemicaltagger

Bug#1014815: kiwipy initial packaging

[Andrius Merkys]

Hi Bastian,

On 2022-10-04 02:12, Bastian Germann wrote:
> What is the status on kiwipy?

For some time kiwipy was blocked by pytray, but pytray is in unstable
now. I will revisit kiwipy.

Best,
Andrius

Bug#944785: pufferfish wants to link with twopaco and ntcard

[Andrius Merkys]

Hi,

On 2022-10-03 18:32, Andreas Tille wrote:
> My main motivation to start ntcard and twopaco packages was to avoid
> code duplication in pufferfish.  I admit it seems I faild in doing this
> sensibly to forget creating a library package.  Simply do whatever
> brings you forward with pufferfish and fix what I failed to do.

Thanks for replies, Andreas and Steffen!

Alas, I did not get far. Static libraries for ntcard and twopaco are
easy to add (I have pushed 'static-library' branches to salsa for these
packages). However, pufferfish has patched main() functions of ntcard
and twopaco executables in order to use them in internal calls.

At this point I do not think much can be done without getting the
upstreams of pufferfish, ntcard and twopaco to align their interfaces.

Best,
Andrius

Bug#944785: pufferfish wants to link with twopaco and ntcard

[Andrius Merkys]

Hello,

twopaco has entered testing (yay!), thus I gave its reverse dependency,
pufferfish (ITP bug #944785), a look. pufferfish carries embedded copies
of twopaco and ntcard with a modified build system to create static (or
is it shared?) libraries for these two and then links pufferfish with
them. For Debian twopaco and ntcard have been un-embedded from
pufferfish and packaged as separate binary packages instead. However,
they do not build neither shared nor static libraries, just executables.

I think we can get around by patching twopaco and ntcard builds to
include static libraries in their binary packages. Does this sound right?

Best,
Andrius

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi Evgeny,

On 2022-09-30 17:18, Evgeny Posenitskiy wrote:
>> Please fix the remaining issue with lintian overrides. After that I will
>> upload the package to NEW.
> 
> Done, thank a lot for debugging the issues! Looking forward to
> apt-get-ing the libtrexio :-)

Great, thanks! Actually, it is still quite some journey apt-get :) First
we have to wait for acceptance into unstable by ftpmaster (mostly
copyright review) and then until the next Debian release. Ubuntu tends
to be released more frequently, thus there is a chance your package will
first appear there.

> One last question: I have noticed that some packages have the `watch`
> file. Does it automate synchronization with the upstream? I was thinking
> about the future updates of the package if/when we release a new version
> of the upstream library.

Yes, that's right. Since your package is hosted on GitHub, you will find
a lot of examples of how to do so. There are also examples in 'man
uscan'. You can check how the debian/watch file works by issuing 'uscan
--debug'.

I have just uploaded your package. Please now tag the git commit from
which I did the upload (cb56db7559202fb1dba20909e117e1a8f10f1663) with
'gbp tag --sign'. If you have already added more commits, return to
aforementioned commit first:

$ git checkout cb56db7559202fb1dba20909e117e1a8f10f1663
$ gbp tag --sign

Then push the tag, 'salsa push' will do that for you.

If you are fine with that, I will request moving libtrexio from your
personal salsa user space to debichem (like the Vcs-* in debian/control
state). This way me and other DebiChem members will be able to maintain
this package if need be.

Best wishes,
Andrius

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi Evgeny,

On 2022-09-30 14:00, Evgeny Posenitskiy wrote:
> Regarding the lintian errors, I have not observed the ones that you
> reported on my machine. Just in case, I have lintian v2.62.0ubuntu2.1.
> The 2 warnings that I had and decided to ignore before uploading on Salsa:
> 
> W: libtrexio-dev: improbable-bug-number-in-closes 1020772
> W: libtrexio0: improbable-bug-number-in-closes 1020772
> 
> I could not reproduce your errors, so I apply the changes as you proposed.

Yes, this difference must be caused by mismatch of lintian versions. For
packaging we are supposed to use the newest versions as they are in
Debian sid (a.k.a. unstable). Thus I do not get
improbable-bug-number-in-closes, but I see source-is-missing.

>> 4. lintian errors about source-is-missing for HTML files. If these files
>> are not generated from some precursor inputs, then this warning is false
>> positive and should be silenced using lintian override. You may take [1]
>> for example. If these files are generated, then it would be better to
>> exclude them from the tarball and regenerate during build.
> 
> It's a bit tricky since both the source and the documentation files are
> generated from the Emacs org-mode files. This is why we ship the final
> HTMLs in the tarball. Re-generating them from source code is not
> possible, moreover it would require the package to depend on the Emacs
> (and the htmlize.el module), which is not desirable. I added the
> following in lintian-overrides as follows (let me know if the path is
> wrong):
> 
>  libtrexio source: source-is-missing
> [share/doc/trexio/tutorial_benzene.html]

OK, adding lintian-overrides will do then. However, the way you have
added them now does not work. You should put the following:

libtrexio source: source-is-missing [docs/templator_front.html]
libtrexio source: source-is-missing [docs/templator_hdf5.html]
libtrexio source: source-is-missing [docs/templator_text.html]
libtrexio source: source-is-missing [docs/tutorial_benzene.html]

Notice 'docs/' instead of 'share/doc/trexio/' as we are supposed to put
paths inside the source tarball. Only these four files have to be
overridden, others are fine.

>> 7. Vcs-* fields in debian/control should point to correct URLs on salsa.
> 
> I modified the Vcs fields with the URLs pointing to the debichem-team
> namespace (as in [2] from your e-mail).

OK, these are fine now.

>> 8. In debian/changelog: UNRELEASED -> unstable
> 
> This change actually leads to a lintian error on my machine:
> 
> E: libtrexio changes: bad-distribution-in-changes-file unstable
> 
> I have changed it anyway but let me know if it should be rolled back.

On my machine this is the expected value, but as said, I am doing builds
on Debian sid, as expected for Debian packaging.

Please fix the remaining issue with lintian overrides. After that I will
upload the package to NEW.

Best,
Andrius

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi Evgeny,

On 2022-09-29 18:18, Evgeny Posenitskiy wrote:
> Thank you for the prompt and detailed reply!

Thanks for prompt action! I will omit parts of your reply that are done.

>> 3. I see your debian/copyright is very detailed. This is not a
>> disadvantage, but maintaining such level of details takes much time. For
>> your package it might be enough to just have the following:
> 
> In the past, I followed the debmake manual from the Debian website
> (https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html#autotools-single)
> and the detailed copyright file was produced somewhere along the way.

Don't get me wrong, detailed is usually better than not. However, very
detailed debian/copyright might be difficult to maintain moving forward.
I almost never mention autoconf-generated files in debian/copyright.

> I applied your changes, so now there is the BSD-3 license on all files
> except the ax_lib_hdf5.m4 and ax_pkg_swig.n4 macros which I copied from
> the Autoconf archive. If you think that these licences can be removed
> too - please let me know and I will do it.

Thanks, I think debian/copyright is fine as is now.

>> In fact, it might be good to exclude them from the distribution tarball
>> altogether as they are regenerated from source anyway.
> 
> The Autoconf files were placed in the tarball automatically, I have not
> written any additional macros for that.
> In general, I trust Autotools when it comes to the distribution tarballs.
> However, if you think that Autoconf-generated files should be removed -
> please let me know.

Right. Since autoconf-generated files are removed and regenerated during
build, a cleanroom approach of dropping them from the tarball looks
tempting to me. To do so, one can introduce Files-Excluded stanza in
debian/copyright to have these files excluded. But this is not
mandatory, your package is fine as it is now.

Some additional comments after building your package:

4. lintian errors about source-is-missing for HTML files. If these files
are not generated from some precursor inputs, then this warning is false
positive and should be silenced using lintian override. You may take [1]
for example. If these files are generated, then it would be better to
exclude them from the tarball and regenerate during build.

5. lintian warns about extended-description-contains-empty-paragraph.
This means you should remove the initial description line which consists
of a single '.' (for both binary packages)

6. Since you are willing to team-maintain the package in Debichem,
debian/control has to show it in Maintainer and Uploaders fields. You
may look at [2].

7. Vcs-* fields in debian/control should point to correct URLs on salsa.

8. In debian/changelog: UNRELEASED -> unstable

And that's about it. Having these issues fixed, the package can be uploaded.

[1]
https://salsa.debian.org/python-team/packages/python-weblogo/-/blob/master/debian/source/lintian-overrides
[2] https://sources.debian.org/src/promod3/3.2.1%2Bds-5/debian/control/

Best,
Andrius

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi Evgeny,

On 2022-09-29 13:35, Evgeny Posenitskiy wrote:
> I have requested access to the Debichem on GitLab (pending) and pushed
> the libtrexio package here: https://salsa.debian.org/q-posev/libtrexio .
> The contents of the debian/ folder were produced by following your guide
> and fixing some build issues along the way.

Great, thanks! I gave your package a look, a few comments:

1. You seem to have pushed just the 'master' branch of the packaging
repository. There should be at least two more, 'upstream' and
'pristine-tar'. Please push them too as I cannot build the package with
gbp without these branches. I personally use 'salsa push' command
('salsa' is in 'devscripts' package) which always pushes all branches
and tags.

2. Why do you need to patch files under helpers-debian/? I do not think
they are used in build or installed anywhere. If so, there is no need to
patch them.

3. I see your debian/copyright is very detailed. This is not a
disadvantage, but maintaining such level of details takes much time. For
your package it might be enough to just have the following:

Files: *
Copyright: 2021, TREX Center of Excellence
License: BSD-3-Clause

All autoconf-generated files are rarely mentioned in debian/copyright.
In fact, it might be good to exclude them from the distribution tarball
altogether as they are regenerated from source anyway.

> What would be the best way to open the RFS bug report now? I mean,
> should I mention your name there or you prefer someone else to have a
> look at it?

I will sponsor trexio, so there is no need for RFS. Usually they are
submitted when looking for a sponsor.

Best,
Andrius

Bug#1020896: ITP: python-pymbar -- Python implementation of the multistate Bennett acceptance ratio (MBAR)

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: python-pymbar
  Version : 3.1.0
  Upstream Author : Michael R. Shirts, John D. Chodera
* URL : https://simtk.org/home/pymbar
* License : Expat
  Programming Lang: Python
  Description : Python implementation of the multistate Bennett
acceptance ratio (MBAR)

Pymbar is a library that provides tools for optimally combining
simulations from multiple thermodynamic states using maximum likelihood
methods to compute free energies (normalization constants) and
expectation values from all of the samples simultaneously.

This package is a dependency of other tools for free energy calculation,
for instance, openmmtools.

Remark: This package is to be maintained with Debian Science Maintainers
at https://salsa.debian.org/science-team/python-pymbar

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi Evgeny,

On 2022-09-27 14:43, Evgeny Posenitskiy wrote:
> I think that my package is now ready to be published. Where can I ask
> for sponsorship?

The common way is to open a RFS (request for sponsor) bug report,
similarly like you did for this ITP.

I could in principle sponsor your package. Have you pushed your
packaging repository to salsa.debian.org? I would recommend this if you
want your package to be maintainer under Debichem umbrella. Moreover, I
would recommend you to join the Debichem team - this way you will be
able to commit and push to Debichem namespace on salsa.debian.org.

Best,
Andrius

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi Evgeny,

On 2022-09-26 16:49, Evgeny Posenitskiy wrote:
> Thanks! Following the Upstream Guide I should probably precise the
> following:
> 
>   - I forgot to provide a link to the the distribution tarball of trexio
> 2.2.0 produced by `make distcheck`:
> https://github.com/TREX-CoE/trexio/releases/download/v2.2.0/trexio-2.2.0.tar.gz
> 
> 
>   - For the dependencies, I did not mention that HDF5 library is already
> available in apt as `libhdf5-dev`.

Good, thanks.

The most usual workflow in Debichem Team is to create packaging
repositories on salsa.debian.org using git-buildpackage workflow and
then ask for sponsorship. I have prepared a small step-by-step tutorial
according to my personal practice, you may follow it if you wish:

https://wiki.debian.org/AndriusMerkys/PackagingInSeconds

An alternative may be to keep debian/ directory in the original upstream
repository, but I do not know if/how this is done. I am the upstream of
some of packages in Debian and I choose the salsa.debian.org approach.

Hope this helps,
Andrius

Bug#1020772: ITP: trexio -- TREX I/O library and data format to exchange the quantum chemistry data.

[Andrius Merkys]

Hi,

Thanks for an interesting ITP.

On 2022-09-26 15:58, Evgeny wrote:
> As this is my first packaging attempt, I do not know about the best practices 
> and would 
> appreciate any piece of advice.

I noticed you are also the upstream of this package. I believe Debian
Upstream Guide could be of use for you:

https://wiki.debian.org/UpstreamGuide

Best,
Andrius

Bug#1020557: ITP: xtb -- semiempirical extended tight-binding program package

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: xtb
  Version : 6.5.1
  Upstream Author : Sebastian Ehlert
* URL : https://github.com/grimme-lab/xtb
* License : LGPL-3+
  Programming Lang: C, Fortran
  Description : semiempirical extended tight-binding program package

xtb program performs semiempirical quantummechanical calculations. The
underlying effective Hamiltonian is derived from density functional
tight binding (DFTB). This implementation of the xTB Hamiltonian is
currently compatible with the zeroth, first and second level
parametrisation for geometries, frequencies and non-covalent
interactions (GFN) as well as with the ionisation potential and electron
affinity (IPEA) parametrisation of the GFN1 Hamiltonian. The generalized
born (GB) model with solvent accessable surface area (SASA) is also
available available in this version. Ground state calculations for the
simplified Tamm-Danceoff approximation (sTDA) with the vTB model are
currently not implemented.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/xtb

Bug#1020551: RFP: lucene9 -- full-text search engine library for Java

[Andrius Merkys]

Package: wnpp
Severity: wishlist
Control: block -1 by 1002470

Lucene 9 is available [1], it is needed to package OpenSearch (ITP bug
#1002470).

[1] https://lucene.apache.org

Andrius

Bug#1019958: ITP: mctc-lib -- modular computation tool chain library

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: mctc-lib
  Version : 0.3.1
  Upstream Author : Sebastian Ehlert
* URL : https://github.com/grimme-lab/mctc-lib
* License : Apache-2.0
  Programming Lang: Fortran
  Description : modular computation tool chain library

Common tool chain for working with molecular structure data in various
applications. This library provides a unified way to perform operations
on molecular structure data, like reading and writing to common geometry
file formats.

mctc-lib is required by xtb which I intend to eventually package.

Remark: This package is to be maintained with Debian Science Maintainers
at https://salsa.debian.org/science-team/mctc-lib

Bug#1019890: ITP: oxdna-cuda -- coarse-grained simulation software for DNA, RNA, and related systems

[Andrius Merkys]

Hi Constantine,

On 2022-09-15 19:03, Constantine Evans wrote:
> oxDNA is a simulation code that was initially conceived as an
> implementation of the coarse-grained DNA model introduced by
> T. E. Ouldridge, J. P. K. Doye and A. A. Louis. It has been since
> reworked and it is now an extensible simulation+analysis framework. It
> natively supports DNA, RNA, Lennard-Jones and patchy particle
> simulations of different kinds on both single CPU cores and NVIDIA
> GPUs.

This sounds interesting. oxDNA could be a great addition to DebiChem or
Debian Med teams.

> oxDNA has CUDA and CPU simulation backends. I've only made a package
> so far including CUDA support, which would thus need to go in
> contrib, because I primarily use the CUDA backend, and have mostly
> seen others using it and presenting results with it.  It also has two
> python libraries, oxpy and oxDNA_analysis_tools, which I have packaged
> as separate binary packages.>
> I have not made a serious Debian package before, and would need a
> sponsor for this; I'd plan to upload it to mentors.  Like much
> research software, it was not built with standard system-wide
> installation as a priority, and has needed some tweaking to its
> build process in that regard, but it is reasonably simple, and the
> upstream authors are responsive to changes to make things easier.

I have never worked with packaging CUDA software. Since it cannot be
built on buildd, I suppose all uploads will have to source+binary. It is
interesting how this works with sponsoring, in particular who (you or
sponsor) will have to build the binaries for upload.

By the way, what would be the binary compatibility of the CUDA package?
I.e., what is the range of CUDA versions that could use the binary
package without rebuilding it from source?

Best,
Andrius

Bug#1019241: ITP: coma -- detect distant protein evolutionary relationships

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: coma
  Version : 1.10+git20201228.c4add90+ds
  Upstream Author : Mindaugas Margelevičius
* URL : https://github.com/minmarg/coma
* License : CC-BY-NC-3.0-Unported
  Programming Lang: C++
  Description : detect distant protein evolutionary relationships

Software package for the detection of distant evolutionary relationships
between protein families using theory of sequence profile-profile
comparisons.

This package is a stand-alone version of COMA server
(http://bioinformatics.ibt.lt/coma/), which I find extremely useful when
searching for homology modeling templates when no close homologs are
available. The obvious benefits of this package are CLI and the ability
to perform COMA search using own resources. In addition, the COMA server
seems to be down sometimes.

Package is licensed as CC-BY-NC-3.0-Unported, thus it will enter
non-free part of Debian archive. Autobuild is possible.

Remark: This package is to be maintained with Debian Med Packaging Team at
   https://salsa.debian.org/med-team/coma

Bug#974154: ocrad: RFA -> ITA

[Andrius Merkys]

control: retitle -1 ITA: ocrad -- optical character recognition program
control: owner -1 !

Hello,

I would like to adopt ocrad.

Best,
Andrius

Bug#682760: osra: RFP -> ITP

[Andrius Merkys]

control: retitle -1 ITP: osra -- optical structure recognition
control: owner -1 !

Hello,

I have made considerable progress in packaging osra. Thus I am taking on
the ITP. I will push my packaging changes to salsa soon.

Andrius

Bug#974153: RFA: gocr -- Command line OCR

[Andrius Merkys]

Hi Gürkan,

On Tue, 10 Nov 2020 20:11:35 +0100 =?UTF-8?Q?G=C3=BCrkan_Myczko?=
 wrote:
> I request an adopter for the gocr package.

I am interested in gocr as a reverse dependency for osra (#682760). I
have recently filed a pair of bugs against gocr blocking osra. I am now
expressing my wish to adopt gocr in order to fix them and possibly
others. In future it would be nice to have gocr team maintained by an
appropriate team.

> Be aware about these bugs though:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gocr

Acknowledged.

Best wishes,
Andrius

Bug#1017505: ITP: lightdock -- protein-protein, protein-peptide and protein-DNA docking framework

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 1016888

* Package name: lightdock
  Version : 0.9.2
  Upstream Author : LightDock developers
* URL : https://github.com/lightdock/lightdock
* License : GPL-3
  Programming Lang: Python
  Description : protein-protein, protein-peptide and protein-DNA
docking framework

LightDock is a protein-protein, protein-peptide and protein-DNA docking
framework based on the Glowworm Swarm Optimization algorithm.

The LightDock framework is highly versatile, with many options that can
be further developed and optimized by the users: it can accept any
user-defined scoring function, can use local gradient-free minimization,
the simulation can be restrained from the beginning to focus on
user-assigned interacting regions, it supports residue restraints in
both receptor and ligand partners.

Remark: This package is to be maintained with Debichem Team.

Bug#1017000: ITP: cpptraj -- fast, parallelized molecular dynamics trajectory data analysis

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1016952 by -1

* Package name: cpptraj
  Version : 5.1.0
  Upstream Author : Daniel R. Roe
* URL : https://github.com/Amber-MD/cpptraj
* License : GPL-3+
  Programming Lang: C++
  Description : fast, parallelized molecular dynamics trajectory
data analysis

CPPTRAJ is a program designed to process and analyze molecular dynamics
trajectories and relevant data sets derived from their analysis. CPPTRAJ
supports many popular MD software packages including Amber, CHARMM,
Gromacs, and NAMD.

Remark: This package is to be maintained with Debichem Team.

Bug#1016952: ITP: gmx-mmpbsa -- end-state free energy calculations with GROMACS files

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 1015857

* Package name: gmx-mmpbsa
  Version : 1.5.6+ds
  Upstream Author : Mario S. Valdes-Tresanco and
Mario E. Valdes-Tresanco
* URL : https://valdes-tresanco-ms.github.io/gmx_MMPBSA/dev/
* License : GPL-3.0
  Programming Lang: Python 3
  Description : end-state free energy calculations with GROMACS files

gmx_MMPBSA is a tool based on AMBER's MMPBSA.py aiming to perform
end-state free energy calculations with GROMACS files.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/gmx-mmpbsa

Bug#1016906: ITP: weblogo -- Sequence Logo Generator

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: weblogo
  Version : 3.7.12
  Upstream Author : Gavin E. Crooks et al.
* URL : https://github.com/WebLogo/weblogo
* License : Expat
  Programming Lang: Python
  Description : Sequence Logo Generator

WebLogo is a web based application designed to make the generation of
sequence logos as easy and painless as possible.

WebLogo can create output in several common graphics' formats, including
the bitmap formats GIF and PNG, suitable for on-screen display, and the
vector formats EPS and PDF, more suitable for printing, publication, and
further editing. Additional graphics options include bitmap resolution,
titles, optional axis, and axis labels, antialiasing, error bars, and
alternative symbol formats.

A sequence logo is a graphical representation of an amino acid or
nucleic acid multiple sequence alignment. Each logo consists of stacks
of symbols, one stack for each position in the sequence. The overall
height of the stack indicates the sequence conservation at that
position, while the height of symbols within the stack indicates the
relative frequency of each amino or nucleic acid at that position. The
width of the stack is proportional to the fraction of valid symbols in
that position.

Remark: This package is to be maintained with Debichem Team.

Bug#1016888: ITP: prody -- Python package for protein dynamics analysis

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: prody
  Version : 2.2.0
  Upstream Author : James Krieger et al.
* URL : https://github.com/prody/ProDy
* License : Expat
  Programming Lang: Python
  Description : Python package for protein dynamics analysis

ProDy is a free and open-source Python package for protein structure,
dynamics, and sequence analysis. It allows for comparative analysis and
modeling of protein structural dynamics and sequence co-evolution. Fast
and flexible ProDy API is for interactive usage as well as application
development. ProDy also comes with several analysis applications and a
graphical user interface for visual analysis.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/prody

Bug#1015857: ITP: parmed -- parameter and topology file editor and molecular mechanical simulator

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: parmed
  Version : 3.4.3
  Upstream Author : Dwight Mcgee, Bill Miller III, and Jason Swails
* URL : https://parmed.github.io/ParmEd/html/index.html
* License : GPL-2+
  Programming Lang: Python 3
  Description : parameter and topology file editor and molecular
mechanical simulator

ParmEd is a package designed to facilitate creating and easily
manipulating molecular systems that are fully described by a common
classical force field. Supported force fields include Amber, CHARMM,
AMOEBA, and several others that share a similar functional form (e.g.,
GROMOS).

ParmEd is capable of reading and writing to a wide array of different
file formats, like the Amber topology and coordinate files, CHARMM PSF,
parameter, topology, and coordinate files, Tinker parameter, topology,
and coordinate files, and many others. The expressive central data
structure (the Structure class) makes it easy to quickly and safely
manipulate a chemical system, its underlying topology, and force field
parameters describing its potential energy function.

There are two parts of ParmEd---a documented API that you can
incorporate into your own Python scripts and programs, and a GUI/CLI
pair of programs that provide a means to quickly perform various
modifications to chemical systems for rapid prototyping.

The API also provides bindings to the OpenMM library, permitting you to
carry out full molecular dynamics investigations using ParmEd on
high-performant hardware, like AMD and NVidia GPUs.

To be maintained inside DebiChem Team.

Bug#1014815: kiwipy initial packaging

[Andrius Merkys]

Hi Guilherme,

On 2022-07-12 17:43, Guilherme de Paula Xavier Segundo wrote:

Cool, I'll review your previous packaging, it will be a pleasure.
You can be sure it will help and I thank you for your help.


Good to hear!


Initially what caught my attention was that it was a Python package.
Currently I have focused my studies on this language and I have been
looking to package programs along this line. However we are currently
deploying a queue service in the company and we are between Kafka and
RabbitMQ so I merged those two things.


This makes sense. I have interest in packages depending on kiwipy, thus 
this would be great help to my cause as well.



One question, are you interested in being my Sponsor in this package? If
it's a problem, ignore it.


Sure, just ping me whenever you need a review and upload for this 
package or its dependencies.


Best,
Andrius

Bug#1014815: kiwipy initial packaging

[Andrius Merkys]

Hi Guilherme,

On 2022-07-12 17:21, Guilherme de Paula Xavier Segundo wrote:

Thank you for your contact.
I started kiwipy packaging. But it's okay to give you the ITP.

Do you want me to give you the ITP?

If not, I will follow the packaging and keep the package on the team. At
the moment I'm not part of the team yet, but I'm waiting for approval.


No, I am fine with you having it. I did not notice RFP -> ITP 
transition, so I decided to update and push my local attempt to package 
kiwipy. Feel free to reuse anything, rewrite (once you are in the team) 
or ignore if you want.


Just out of curiosity, what caught your interest to kiwipy/plumpy?

Best,
Andrius

Bug#1014815: kiwipy initial packaging

[Andrius Merkys]

Hello,

I have pushed my initial packaging of kiwipy to salsa [1]. Everyone in 
Python Team are welcome to contribute.


[1] https://salsa.debian.org/python-team/packages/python-kiwipy

Best,
Andrius

Bug#962932: ITP: plumpy -- Python workflows library

[Andrius Merkys]

Control: retitle -1 ITP: python-plumpy -- Python workflows library

Hi Bastian,

On 2022-07-11 22:28, Bastian Germann wrote:

On Tue, 16 Jun 2020 07:56:34 +0300 mer...@debian.org wrote:
plumpy is required by aiida-core (ITP #901392). However, packaging of 
plumpy is currently blocked by its incompatibility with 
python3-tornado >= 5 [1].


I plan to maintain plumpy together with the DPMT.

[1] https://github.com/aiidateam/plumpy/issues/72


This is resolved with v0.16.0. Do you still want to package plumby?


Thanks for pinging me regarding this development. I have pushed my 
packaging of python-plumpy v0.21.0 to salsa [2]. However, there still 
are unpackaged dependencies, thus I will have to leave it for later. You 
are welcome to commit to the repository if you need plumpy as well.


[2] https://salsa.debian.org/python-team/packages/python-plumpy

Best,
Andrius

Bug#1014513: ITP: pdb-tools -- tools for manipulating and editing PDB files

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1014457 by -1

* Package name: pdb-tools
  Version : 2.5.0
  Upstream Author : João Pedro Rodrigues
* URL : https://www.bonvinlab.org/pdb-tools/
* License : Apache-2.0
  Programming Lang: Python
  Description : tools for manipulating and editing PDB files

Manipulating PDB files is often painful. Extracting a particular chain
or set of
residues, renumbering residues, splitting or merging models and chains,
or just
ensuring the file is conforming to the PDB specifications are examples
of tasks
that can be done using any decent parsing library or graphical
interface. These,
however, almost always require 1) scripting knowledge, 2) time, and 3)
installing
one or more programs.

pdb-tools were designed to be a swiss-knife for the PDB format. They have no
external dependencies, besides obviously the Python programming language.
They are the descendant of a set of old FORTRAN77 programs that had the
particular advantage of working with streams, i.e. the output of one script
could be piped into another. Since FORTRAN77 is a pain too, I rewrote
them in
Python and added a few more utilities.

The philosophy of the scripts is simple: one script, one task. If you
want to
do two things, pipe the scripts together. Requests for new scripts will
be taken
into consideration - use the Issues button or write them yourself and
create a
Pull Request.

pdb-tools is a dependency of haddock3 (ITP #1014457), but it is also a
useful package on its own.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/pdb-tools

Bug#1014457: ITP: haddock3 -- High Ambiguity Driven biomolecular DOCKing

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name: haddock3
  Version : 3.0.0~beta.2
  Upstream Author : Alexandre Bonvin
* URL : https://github.com/haddocking/haddock3
* License : Apache-2.0
  Programming Lang: Python
  Description : High Ambiguity Driven biomolecular DOCKing

HADDOCK is a software package for integrative modeling of biomolecular
complexes.

HADDOCK uses non-free CNS for at least some of its functions. Since the
interface with CNS is via CNS executable calls, CNS-using functions
should work having CNS executable in $PATH.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/haddock3

Bug#682760: Revisiting osra

[Andrius Merkys]

Hello,

I have revisited building osra v2.1.3. There seems to be an issue with
outdated Autoconf directives now. I have filed an upstream ticket about
it [1].

[1] https://sourceforge.net/p/osra/bugs/20/

Best,
Andrius

Bug#1012289: A better future for Lintian / Bug#1012289: O: lintian -- Debian package checker

[Andrius Merkys]

Hello,

I have also sent a request to join lintian team on salsa. I am not sure
how much I will be able to contribute, but I did some contributions to
lintian in past, so I feel I have some idea about its code. Also I am
quite fluent in Perl.

Best,
Andrius