Re: package bcftools dependencies for gff2gff.py and guess-ploidy.py cause bcftools to have 10x as many dependencies

[Andrius Merkys]

Hi,

On 2024-06-18 21:37, Giulio Genovese wrote:
To address bug #1069234 
 the bcftools 
package acquired, through commit a46c2e25 
, two new dependencies:

- python3-gffutils
- python3-matplotlib
This causes the size of the package dependencies to explode from <50MB 
to >500MB.


As bcftools is mostly a C software, I believe the most appropriate 
approach is to have those dependencies as recommended dependencies, so 
that the package can be installed in a minimalistic fashion with the 
apt-get --no-install-recommends command while not affecting other use 
cases, similarly to how it was done for the bwa package in commit 
e3fef43e 
 where perl was demoted to a recommended dependency.


Would it be possible to split off the tools requiring this many 
dependencies to a separate binary package? Then users could choose 
between a minimalistic installation and a fully fledged one.


Best,
Andrius

Re: Action needed for R-pkg Uploaders

[Andrius Merkys]

Hi Andreas,

On 2024-05-07 15:53, Andreas Tille wrote:

Andrius Merkys :
  r-cran-cyclocomp
  r-cran-lintr
  r-cran-rlinsolve
  r-cran-xmlparsedata


I confirm these are my packages in Debian R Team. I intend to maintain 
them just as before. All of them are up-to-date and bug-free at the time 
of writing.


Best wishes,
Andrius

Re: designing dh_pytorch for PyTorch reverse dependencies

[Andrius Merkys]

Hi Mo,

On 2023-09-09 22:29, M. Zhou wrote:

I'm writing down my draft design for dh_pytorch here in order to hear
some comments or feedbacks. If you maintain a package that depends
on python3-torch or relevant pytorch packages, please let me have
your attention.


I maintain a pair of pytorch reverse dependencies.


We need a custom dh module for pytorch because we have multiple
pytorch variants in our repository, which might or might not
fill the reverse dependency requirements of its reverse dependencies.
PyTorch is somewhat similar to numpy, but we have to implement
something different than dh_numpy.

For instance, a reverse dependency might be agnostic to the actual
variant of pytorch. An example is src:pytorch-ignite. It provides
a higher-level abstract to the pytorch API, and contains no arch
specific file. So it can depend on any pytorch variant, e.g.,
   Depends: python3-torch | python3-torch-cuda | python3-torch-...

A reverse dependency might be depending on a particular variant
as well. An example is src:pytorch-vision. It compiles binaries
against libtorch2.0 (with B-D: libtorch-dev). In that case,
the cpu variant (python3-torch) will not be able to fill the
dependency requirement.

My proposed solution for automatically filling in the pytorch
dependency is as follows:

Firstly, every pytorch variant will provide a virtual package
   python3-torch-api-2.0
to declare that the package provides the high level API of pytorch.

Then it is the dh_pytorch processing logic in pseudo code:
(dh_pytorch is inserted before dh_gencontrol)

for each binary package $pkg {

   if $pkg.architecture is all {
 # does not require specific variant
 append the following to python3:Depends
 "python3-torch | python3-torch-api-2.0"


Why not just python3-torch-api-2.0? AFAIU, python3-torch will provide 
python3-torch-api-2.0 as well. Or is this here to indicate preference?



   } else {
 # for arch-any package

 if $pkg.substvars contains "libtorch*" {
   # this variant-specific dependency
   do nothing to python3:Depends.
   Just use the default dependency.
 
 } else {

   # does not contain "libtorch*" dependency
   # that indivates variant-agnostic package.
   append the following to python3:Depends
   "python3-torch | python3-torch-api-2.0"


Am I right that src:pytorch-vision would fall in this category? In that 
case python3-torch would fill the dependency requirement, but will the 
binary package get the needed shared libraries in all cases?



   }
}

The $pkg.substvars files are generated by dpkg-shlibdeps.


As a result, the src:pytorch-ignite, a variant-agnostic reverse
dependency, will be able to depend on any variant that provides
python3-torch-api-2.0, including python3-torch, python3-torch-cuda,
python3-torch-rocm, etc.

Meanwhile, the src:pytorch-vision, a variant-specific reverse
depenedency, will simply require python3-torch-cuda.
(I will upload the cuda version of torchvision as
python3-torchvision-cuda in the future)

I don't have much experience in writing custom debhelper modules.


Me neither.


Any comments or suggestions are welcome.
The perl implementation is work in progress.


Thank you for working on this.

Best wishes,
Andrius

Re: Date versions: (Was: Humble comments...)

[Andrius Merkys]

Hi Kingsley,

On 2023-06-25 00:48, Kingsley G. Morse Jr. wrote:

You politely proposed using download date as
version for CCD.

You're smart.

Maybe you already know this, but Debian's Policy
Manual has a sub-sub-section called

 "3.2.1. Version numbers based on dates"

If you haven't checked it out yet, maybe it would
be

 interesting, or even

 helpful.

It's at

 3.2.1. Version numbers based on dates
 
https://www.debian.org/doc/debian-policy/ch-binary.html#version-numbers-based-on-dates


Thanks for the link. I had not read this portion before, but I believe I 
have been adhering to its spirit. I would use the same versioning scheme 
for CCD.



PS: I agree my ginormous spread sheet summarizing
 life span experiments may interest Debian's
 Med team.

 Through no fault of yours, I failed to explain
 the reason why I asked if the PDB Chemical
 Component Dictionary might compliment it.

 I wondered if data in the CCD might add value
 to it for synergistic technical and biological
 reasons.

 My ginormous spread sheet summarizing life
 span experiments is currently a for-profit
 project.

 But, I'd love to find a crowd funding guru who
 could show me how to

 get paid and

 publish it under a permissive license, like
 the PDB Chemical Component Dictionary, so it
 could

 be part of Debian and

 expedite research to

 slow, and maybe even

 reverse

 the scourge of aging.


I see. I believe such discussion is worth a thread of its own.

Best wishes,
Andrius

Re: Packaging PDB Chemical Component Dictionary

[Andrius Merkys]

Hi Maarten,

On 2023-06-23 20:22, Maarten L. Hekkelman wrote:
Although I agree that having an up-to-date CCD file is useful. And 
having it installed by the system would even be better. But I wonder, 
who is going to make new packages with the latest CCD file? That's a 
task that needs to be executed weekly. Or do you envision a way to 
automate that?


Surely it would be difficult to keep up with such frequency of updates. 
My idea would be to update it at least before the freezes of Debian and 
Ubuntu releases.


I also assume you want to replace the current cron script from libcifpp 
with this new package?


No, libcifpp cron script would remain for those willing to use the most 
up-to-date CCD, as CCD package would remain immutable for the most of 
the Debian stable lifecycle.


Best wishes,
Andrius

Re: Humble comments on... (Was: Packaging PDB Chemical Component Dictionary)

[Andrius Merkys]

Hi Kingsley,

Thank you for your comments.

On 2023-06-23 10:17, Kingsley G. Morse Jr. wrote:

You politely and confidently invited comments.

1.) Thanks!

2.) I like your use of the concise "TL;DR" (ie:
 "Too Long; Don't Read").

3.) Sometimes I shorten it even more, to "TLDR".


Thanks for pointing this out.


4.) How is the PDB Chemical Component Dictionary
 licensed, if at all? Is it in the public domain?


It is licensed as CC0 1.0 Universal Public Domain Dedication.


5.) Could it somehow compliment a big computer spread
 sheet summarizing life span experiments, where
 a column named "intervention" contains the
 names of molecules, like "vitamin c" and
 "glycine"[1]?


This might be of interest for Debian Med team. Do you envisage this body 
of data being used by software packages in Debian?



6.) Could debian packages have version numbers
 based on dates the CCD was downloaded?


I propose using download date as version for CCD. Or do you mean other 
software packages? If so, this would be somewhat unusual, albeit some 
Javascript packages seem to carry versions of their parts.



[1] World's biggest collection of the results of
 life span experiments
 https://kingsleymorse.ch/life_extension.html#preprocessed_life_span_data


Best wishes,
Andrius

Packaging PDB Chemical Component Dictionary

[Andrius Merkys]

Hello,

TL;DR: I propose packaging frequently updated PDB Chemical Component 
Dictionary. Reasons, technical solutions and limitations below.


PDB Chemical Component Dictionary (CCD) [1] is a single file (~400 MB 
uncompressed) collection of small molecule components found in PDB 
entries. It is used by at least a couple of Debian packages: 
openstructure, which needs it as a build dependency, and libcifpp.


For openstructure I have resorted to putting some version of the CCD in 
debian/ directory to fulfill the build requirement and then provide it 
as /usr/share/openstructure/components.cif.gz. However, due to this CCD 
is not updated as frequently as it is released. Moreover, large-sized 
debian/ directories are frowned upon. Therefore I would like to 
outsource the CCD.


libcifpp package provides a cron task which keeps an up-to-date CCD in 
its cache directory, which is good as Debian-packaged CCD file would 
stay static between Debian releases. However, this does not help 
building openstructure due to network access constraint.


I propose packaging CCD as a separate source package. It does not have 
version, thus update date would have to be used instead. I have hacked 
together a watch file to check for new versions, but it fails on 
mk-origtargz step:


version=4
opts="downloadurlmangle=s|status.*|monomers/components.cif.gz|,filenamemangle=s|(\d+)/$|ccd-$1.gz|" 
\

https://files.wwpdb.org/pub/pdb/data/status/ \
 https://files.wwpdb.org/pub/pdb/data/status/(\d+)/

Thus the tarball would have to be produced by get-orig-source target in 
debian/rules unless there are other solutions.


Here I would like to ask for comments and suggestions. I am aware that 
packaging large and frequently updated data files is not usual practice, 
but I believe that doing so would both resolve problems with building 
openstructure and benefit users needing a stable CCD version.


[1] https://www.wwpdb.org/data/ccd

Best wishes,
Andrius

Re: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andrius Merkys]

Hello,

On 2023-01-14 13:12, 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 for it.)


Its reverse dependencies are keras, deepnano and invesalius.

It is currently broken, probably by numpy 1.24 (#1027215), and the 
immediately obvious fixes weren't enough 
(https://salsa.debian.org/science-team/theano/-/pipelines).


Is this worth spending more effort on fixing, or should we just remove it?


keras is needed to train evaluation models for qmean [1] which I intend 
[2] to package eventually. qmean is a quite popular protein model 
evaluation tool, personally I use it a lot and I believe it would be 
useful to have it in Debian.


That said, it is OK to omit keras in bookworm if need be, but I would 
like to see it back for trixie.


[1] 
https://git.scicore.unibas.ch/search?search=keras&nav_source=navbar&project_id=69&group_id=25&search_code=true&repository_ref=master

[2] https://bugs.debian.org/976981

Best,
Andrius

Re: TBB package update

[Andrius Merkys]

Hi Andreas,

On 2022-06-18 15:42, Andreas Tille wrote:
> Is there some kind of "porting to latest tbb FAQ"?  For instance I
> wonder how to fix issues like in twopaco[1] or the other bugs files
> against several packages.  I personally have no idea how to deal
> about tbb and I'm wondering if there are some "easy cases" I could
> fix with some little doc.

I have forwarded twopaco failure to build with TBB 2021.5.0 upstream [2]
and got a response that they have already fixed twopaco as embedded in
pufferfish. Maybe this fix could be backported to twopaco proper.

> [1] https://salsa.debian.org/med-team/twopaco/-/jobs/2894511

[2] https://github.com/medvedevgroup/TwoPaCo/issues/28

Best,
Andrius

Re: TBB package update

[Andrius Merkys]

Hi Nilson,

On 2022-06-07 22:11, Nilson Silva wrote:
> I would like to know when the team will upload the new version of TBB to
> the debian repositories.

As Mo wrote, you may find onetbb/2021.5.0-9 in experimental. Transition
experimental -> unstable is in planning now, you may monitor the
progress at #1007222.

Best,
Andrius

Re: Salvaging keras - unpushed commits?

[Andrius Merkys]

Hi,

On 2022-04-28 13:12, Stephen Sinclair wrote:
> The last time I looked at Keras, there were some hard to fix issues
> and since it is my understanding that keras as a package outside of
> Tensorflow has reached end of life, it does not seem useful to try to
> maintain it.

At first glance issues with Keras in Debian seemed simple to me: just
incompatibilities with newer Python versions, but I admit patching them
is slow converging process. TensorFlow is needed for Keras 2.4.0 or
later and that seems stuck. I would prefer bookworm having Keras 2.3.1
than not having Keras at all.

Anyway, I have solved the issue with unpushed commits and tag. Will see
if I can get it further.

Best,
Andrius

Re: Salvaging keras - unpushed commits?

[Andrius Merkys]

Hi Andreas,

On Wed, 27 Apr 2022, 16:48 Andreas Tille,  wrote:

> seems Stephen is not active.  If I where you I'd push the uploaded state
> to Git and upload the latest upstream version.
>

Thanks for suggestion - I will take care of keras then.

Best,
Andrius

>

Salvaging keras - unpushed commits?

[Andrius Merkys]

Hello,

keras has recently dropped out of testing due to two RC bugs [1]. Both
of them seem quite easy to fix. However, repository on Salsa lacks
commits and tag for 2.3.1+dfsg-3. Stephen, could you please push them in
order to have up-to-date history on Salsa?

Moreover, newer upstream releases are ready. I suspect RC bugs might be
fixed upstream. Having missing commits in Salsa I could attempt updating
keras on Debian, if no one is against that.

[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=keras

Best,
Andrius

Re: shiny-server in debian

[Andrius Merkys]

Hi all,

Sorry I cannot keep up with all the developments. I have no idea how
shiny-server work, thus I would not be much of a help here, but I think
it is in good hands now :)

Replying only to Eric's summary of nodejs dependencies.

On 2022-03-27 06:20, Eric Brown wrote:
> So in summary, I think we should try, if this sounds sensible:
> 1. remove libjs-sockjs as a dependency of shiny-server

Sure, libjs-sockjs is superseded by node-sockjs-client, and should not
only be removed from shiny-server dependencies, but from Debian
altogether. I will contact libjs-sockjs maintainer about that.

> 2. add back the dist directory to node-sockjs-client, and add
> node-sockjs-client as a dependency of shiny-server

Right, node-sockjs-client is indeed missing the dist/ directory. This is
due to incomplete build (me to blame), I will attempt to fix it.

> 3. update outdated node-shiny-server-client to latest upstream

Seems a wise thing to do.

Best,
Andrius

Re: shiny-server in debian

[Andrius Merkys]

Hi Nilesh,

On 2022-03-24 12:03, Nilesh Patra wrote:
> On 3/24/22 3:09 PM, Nilesh Patra wrote:
>> I figured out the problem. It is so because the debian package
>> node-send is patched[1]
>> to use node-mime-types instead of node-mime (not sure why)
>>
>> I just filed a bug report (with you in x-debbugs-cc) to possibly fix
>> it in node-send.

Thanks for debugging this.

> After fixing this locally, there are few failing tests (majority pass,
> thankfully)
> on similar lines of:
> 
> |  1) iputil
> |   validates addresses:
> | TypeError: (intermediate value).isValid is not a function
> |  at Object.isValid (lib/core/iputil.js:35:29)
> |  at /home/nilesh/packages/shinyserv/shiny-server/test/iputil.js:32:36
> |  at Array.forEach ()
> 
> But right now I have no time to further debug this. Would be great if
> you can take a look.

I gave this a glance, but I cannot understand the problem, alas.

Best,
Andrius

Re: shiny-server in debian

[Andrius Merkys]

Hi Nilesh,

On 2022-03-24 10:04, Nilesh Patra wrote:
> On Thu, Mar 24, 2022 at 08:41:01AM +0200, Andrius Merkys wrote:
>> Looking deeper into it, the problem seems to be that node-mime-types has
>> dropped define() in v2.0.0, as per
>> /usr/share/doc/node-mime-types/HISTORY.md.gz:
>>
>> 2.0.0 / 2014-09-02
>> ==
>>
>>   * Use `mime-db`
>>   * Remove `.define()`
> I am a bit confused -- the error seems to stem from 'node-send' package right?

Oh right, it is 'node-send' which needs patching:

$ cat test.js
var send = require('send')
var mime_types = require('mime-types')
var mime = require('mime')

console.log(send.mime.define)
console.log(mime_types.define)
console.log(mime.define)

$ nodejs test.js
undefined
undefined
[Function: bound ]

However, I have no idea how to fix this in 'node-send'.

Best,
Andrius

Re: shiny-server in debian

[Andrius Merkys]

Hi Nilesh,

On 2022-03-24 00:25, Nilesh Patra wrote:
> I uploaded rewire to NEW. On testing locally with rewire, I get:
> 
> | TypeError: send.mime.define is not a function
> |at Object. 
> (/home/nilesh/packages/shinyserv/shiny-server/lib/router/directory-router.js:27:11)
> |at Module._compile (internal/modules/cjs/loader.js:999:30)
> |at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
> |at Module.load (internal/modules/cjs/loader.js:863:32)
> 
> Does not quite ring a bell, maybe wil take a look next weekend.

Thanks a lot for packaging rewire! I confirm I get the same error.
Looking deeper into it, the problem seems to be that node-mime-types has
dropped define() in v2.0.0, as per
/usr/share/doc/node-mime-types/HISTORY.md.gz:

2.0.0 / 2014-09-02
==

  * Use `mime-db`
  * Remove `.define()`

So shiny-server needs to be patched to register 'text/R' mimetype in
more up-to-date manner.

Best,
Andrius

Re: shiny-server in debian

[Andrius Merkys]

Hi Eric,

On 2022-03-23 16:25, Eric Brown wrote:
> Thank you Andrius, Andreas et al. for your work in getting
> node-sockjs-client in Debian testing. It appears that shiny-server
> (https://salsa.debian.org/science-team/shiny-server) may now have just
> one dependency left - node-rewire, which I'm not sure is actually
> required to build as it is for CI/development. Also note despite the
> warning for node-stable it appears to be packaged
> (https://packages.debian.org/sid/node-stable).

Revisiting shiny-server, I have turned on the build time tests to have a
better understanding of what is left to be done. Tests now fail due to
missing rewire:

   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
mocha test

Error: Cannot find module 'rewire'

Maybe tests using rewire could be ignored for now. Yet I would very much
want to run the tests, as this would be a great way to find out whether
shiny-server works as packaged for Debian.

> There have been many interested parties in packaging shiny-server in
> Debian over the past few years. I wonder if anyone has the time to
> revisit now that (all?) the dependencies are in Debian? I
> unfortunately lack the skills for this.

I can give it a glance. However, as I have never used shiny-server
before, I do not think there is much I can do apart from checking the tests.

Best,
Andrius

Re: [Pkg-javascript-devel] sockjs-client is in Debian but needs update (Was: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit))

[Andrius Merkys]

Hi Eric,

On 2022-02-27 22:36, Eric Brown wrote:
> Likewise, thank you very much! It’s exciting that the dependencies for
> shiny-server are coming together. Please note the upstream for
> sockjs-client responded to me and released 1.6.0 which also updates some
> other dependency versions.

You are welcome. I have uploaded node-sockjs-client on Friday, it is in
NEW now. I will update it to 1.6.0 once it clears NEW.

It would be nice if someone could take a look at shiny-server, since it
starts to come together finally. I most likely will not have time for
that. I would suggest against updating it at first, as new JS
dependencies have a tendency to appear rapidly.

Best,
Andrius

Re: [Pkg-javascript-devel] sockjs-client is in Debian but needs update (Was: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit))

[Andrius Merkys]

Hello,

Replying to Nilesh and Andreas in the same mail.

On 2022-02-25 07:49, Andreas Tille wrote:
> Am Fri, Feb 25, 2022 at 03:09:36AM +0530 schrieb Nilesh Patra:
>>> Sure. It would be nice to get ACK from Pirate, though, as he owns the ITP.
>> I am a bit confused, why would you need ack from someone who ITP'ed it, even 
>> if you need the ack, you'd ask this to the maintainer, right?
> Yes.  The ITP should have been closed manually long before.  The fact
> that this not happened yet is IMHO a sign that the original maintainer
> does not care any more for the package (and forgot to orphan it).

I admit I got confused a bit. There is an orphaning bug [1] without an
owner and ITP bug [2] owned by Pirate Praveen. I think I will merge
these and close them with the upload.

[1] https://bugs.debian.org/836492
[2] https://bugs.debian.org/886155

>> But in any case, this does not seem to have any reverse dependencies so this 
>> should be safe to upload. As far as I know Praveen, he will not stop you 
>> until it breaks something (the package is in a bitrot anyway)
> Yes.
>  
>>> FYI, the upload will have to go through NEW due to both source and binary
>>> package renaming.
>> Although this does not make much sense to do this here but still if you want 
>> to play extra safe, you might want to upload it targetting experimental.
> You might even consider using the old name for an upload to unstable and
> at the same time push a renamed package to experimental via new.  This
> would enable to keep on working on shiny-server (despite I'm not sure
> whether we need to be in a hurry here ... I personally have other things
> on my table unfortunately).

Since there are no reverse dependencies on libjs-sockjs and we are not
in a hurry with shiny-server (we can still work on that with local
node-sockjs-client package), I would like to avoid experimental. This
way I would not have to deal with Breaks+Replaces due to same locations
occupied by two different packages.

Best,
Andrius

Re: sockjs-client is in Debian but needs update (Was: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit))

[Andrius Merkys]

On Thu, 24 Feb 2022, 22:21 Andreas Tille,  wrote:

> Am Wed, Feb 23, 2022 at 06:10:24PM +0200 schrieb Andrius Merkys:
> > >
> https://github.com/sockjs/sockjs-client/commit/d9584abe2c7c913ce95a1aea29e5744dd85e1af4
> > > <
> https://github.com/sockjs/sockjs-client/commit/d9584abe2c7c913ce95a1aea29e5744dd85e1af4
> >
> >
> > I have turned this commit into a patch, and now sockjs-client builds and
> > passes its autopkgtest successfully. So we do not have to wait for the
> > next release.
>
> Would you mind uploading?


Sure. It would be nice to get ACK from Pirate, though, as he owns the ITP.

FYI, the upload will have to go through NEW due to both source and binary
package renaming.

Best,
Andrius

Re: sockjs-client is in Debian but needs update (Was: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit))

[Andrius Merkys]

Hi Eric,

On 2022-02-22 14:52, Eric Brown wrote:
> If I’m understanding the below correctly, it appears that the node-json3
> may already have been removed from the dependency socksjs-client, but
> the updated version is not released yet.
> 
> https://github.com/sockjs/sockjs-client/commit/d9584abe2c7c913ce95a1aea29e5744dd85e1af4
> 

I have turned this commit into a patch, and now sockjs-client builds and
passes its autopkgtest successfully. So we do not have to wait for the
next release.

Best,
Andrius

Re: sockjs-client is in Debian but needs update (Was: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit))

[Andrius Merkys]

Hi Eric,

On 2022-02-22 14:52, Eric Brown wrote:
> If I’m understanding the below correctly, it appears that the node-json3
> may already have been removed from the dependency socksjs-client, but
> the updated version is not released yet.
> 
> https://github.com/sockjs/sockjs-client/commit/d9584abe2c7c913ce95a1aea29e5744dd85e1af4
> 

Great - this saves quite some work.

> I wonder if we ask the dev to consider a release, and then update the
> Debian package, that would solve the problem?

Preferably. Otherwise we could convert this commit to a patch and
attempt applying it, or package development version, but having a stable
release would be better.

Best,
Andrius

Re: sockjs-client is in Debian but needs update (Was: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit))

[Andrius Merkys]

On 2022-02-22 13:20, Andreas Tille wrote:
> Unfortunately we have a new problem as
> autopkgtest shows[4]
> 
>sockjs-client : Depends: node-json3 (>= 3.3.2) but it is not installable
> 
> while we had this package before it was removed[5] from Debian.
> 
> I need to admit that I have no idea how to sensibly proceed from here
> and would love if someone from Debian Javascript Maintainers would take
> over from here.

Citing [6]:

  JSON 3 is **deprecated** and **no longer maintained**. Please don't
  use it in new projects, and migrate existing projects to use the
  native `JSON.parse` and `JSON.stringify` instead.

My sense is that sockjs-client needs node-json3 usage replaced with
calls to native JSON module (by upstream or by patch).

> [1] https://tracker.debian.org/pkg/sockjs-client
> [2] https://salsa.debian.org/js-team/node-sockjs-client
> [3] https://bugs.debian.org/979958
> [4] https://salsa.debian.org/js-team/node-sockjs-client/-/jobs/2499248
> [5] https://bugs.debian.org/931653

[6] https://www.npmjs.com/package/json3

Best,
Andrius

Re: [covid-19] shiny-server (Was: dependencies Re: ITP: streamlit)

[Andrius Merkys]

Hi Eric,

On 2022-02-22 06:43, Eric Brown wrote:
> It appears that significant progress has been made in packaging the
> dependencies of shiny-server. I wonder if anyone is interested and
> able to revisit packaging shiny-server?

In past I have worked to package the dependencies of shiny-server.
Sadly, I do not have enough free cycles to work on shiny-server now. It
would be great if someone experienced in JS (js-team?) could give it a look.

As for the remaining dependencies, sockjs, sockjs-client and rewire
stands out. There is some work on sockjs-client done in salsa, seemingly
never uploaded.

Best,
Andrius

Re: mmdb2

[Andrius Merkys]

Hello,

On 2022-02-09 20:28, Nilesh Patra wrote:
> $ reverse-depends libmmdb2-dev
> Reverse-Depends
> * libclipper-dev
> * libssm-dev
> 
> $ reverse-depends libmmdb2-dev -b
> Reverse-Build-Depends
> * clipper
> * libccp4
> * molmodel
> * ssm

I have checked with ratt, all these build fine. Thus I have uploaded
mmdb, thanks Maarten for updating it!

By the way, other ccp4 packages (clipper, libccp4 and ssm) may as well
have new releases published in Paul Emsley's Coot dependencies
directory. Maybe it is a good idea to update them as well.

Some time ago I spent much effort to package Coot. It is still on my
wishlist, but I could not get past the license collection stage. There
is just too many files having vague copyright needing manual investigation.

Best,
Andrius

Re: mmdb2

[Andrius Merkys]

Hi Maarten,

On Wed, 9 Feb 2022, 18:26 Maarten L. Hekkelman, 
wrote:

> Since you are the one who uploaded mmdb2 last: I've updated the package
> to include the latest version and committed that to salsa. But I believe
> I cannot upload this package so now I'm looking at you. (Or someone else
> in the science area.)
>

Will upload tomorrow. Thanks! By the way, maybe you have tested the reverse
dependencies?

I've changed the watch file to look in Paul Emsley's Coot dependencies
> directory. That's not optimal. I've asked Charles Ballard to put the
> latest of mmdb2 in the ftp directory at ccp4 and he is willing to do so,
> but hasn't up until now. An additional problem is that the FTP server is
> threatened to be taken down due to people being scared by such an old
> fashioned protocol.
>

Oh well. Anyway, I think what you did is good, let's watch this location
from now on.

Anyway, maybe you want to upload this package, or maybe you want to wait
> until a final destination for ccp4 code has been found.
>

Let's live with the state-of-the art for now.

Best,
Andrius

>

Re: alphafold Debian packaging ?

[Andrius Merkys]

On 2022-01-12 17:34, Gard Spreemann wrote:
> Andrius Merkys  writes:
>> On 2022-01-11 16:14, Gard Spreemann wrote:
>>> I'm taking the liberty to forward this to the debian-ai list as well.
>>
>> Thanks. Highly relevant issue for debian-ai@ might be the retraining of
>> the neural network model.
> 
> Indeed! I was thinking that it might be an interesting – and
> complicated! – test case for Mo Zhou's draft ML policy [2].
> 
> [2] https://salsa.debian.org/deeplearning-team/ml-policy

Sure!

>> In addition to being pre-trained, the model itself is licensed under
>> CC-BY-NC-4.0, thus not suitable for Debian main. I could not find a
>> guide for retraining, and an issue on their tracker [1] asks for the
>> same.
> 
> Hmm, interesting! Where did you see this? Regarding the output
> predictions, alphafold.com states CC-BY-4.0 (in two different places):
> 
>> All of the data provided is freely available for both academic and 
>> commercial use under Creative Commons Attribution 4.0 (CC-BY 4.0) license 
>> terms. If you use this resource please cite the following papers: 
>> […]
> 
> And their code repository is Apache. Or did you find the actual
> pretrained models somewhere under CC-BY-NC?

Interesting. Maybe I am looking at some other source. Am I right to
assume we are talking about [3]? If so, it says that the parameters are
CC-BY-NC here: [4].

[3] https://github.com/deepmind/alphafold
[4] https://github.com/deepmind/alphafold#model-parameters

Best,
Andrius

Re: alphafold Debian packaging ?

[Andrius Merkys]

Hi,

On 2022-01-11 16:14, Gard Spreemann wrote:
> I'm taking the liberty to forward this to the debian-ai list as well.

Thanks. Highly relevant issue for debian-ai@ might be the retraining of
the neural network model. In addition to being pre-trained, the model
itself is licensed under CC-BY-NC-4.0, thus not suitable for Debian
main. I could not find a guide for retraining, and an issue on their
tracker [1] asks for the same.

Yet another issue is AlphaFold's dependence on GPU.

Would it be OK for me to open an RFP to collect the knowledge and
continue the discussion there?

[1] https://github.com/deepmind/alphafold/issues/323

Best,
Andrius

Re: alphafold Debian packaging ?

[Andrius Merkys]

Hi,

On 2022-01-11 15:47, PICCA Frederic-Emmanuel wrote:
> I would like to know if you are aware of an effort to package alphafold[1] on 
> Debian ?

Some time ago there was a thread on debian-med@ [2], but I do not recall
how did it end.

Moreover, I noticed some interest in compiling alphafold using
Debian-provided libraries [3], but I also do not know how did that end.

I am as well interested in packaging alphafold.

> [1] https://alphafold.com/

[2] https://lists.debian.org/debian-med/2021/08/msg5.html
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992931

Best,
Andrius

Re: Debian Math Team

[Andrius Merkys]

Hi Nilesh,

On 2021-11-04 13:13, Nilesh Patra wrote:
> On Thu, Nov 04, 2021 at 11:48:45AM +0200, Andrius Merkys wrote:
>> Maybe separate mailing lists could be enough? In the end
>> upstreams mostly work on one-two source packages, and even if they
>> become DMs they do not get push/upload permissions for all source
>> packages of a team, do they?
> 
> I think this point is not exactly a discussion for the mathematics team, but
> pretty much several other teams (i.e separate lists, etc)
> Since this looks (to me) very generic and not very specific, maybe you'd
> want to ask -devel for more opinions, but :)

I agree, this is a topic for a separate discussion :)

>>> since R packages are extremely uniform and
>>> usually come with test suites that can be re-used which to some extend
>>> is taking over the role of an expert knowing the software.  There are
>>> also not really any specific decisions to make about the packaging since
>>> everything is really straightforward.
>>>
>>> This is absolutely different to software written in Python, Java or
>>> anything else.
>>
>> I disagree. I find at least JavaScript and Perl packages quite uniform,
>> and I have an impression that at least 
> 
> I cannot say about perl, but your argument is certainly invalid for 
> javascript team.
> My journey to contributing in debian started with JS team, and I've been 
> involved there
> ever since (few years by now), and no, they are _not_ uniform.
> Several packages need much more work than the defaults and maintaining JS is 
> also more work
> for more techinal reasons (like embedding node modules for instance)
> 
> Several packages come with typescript defs, and you need to take care of them.
> They come with varieties of build systems - webpack, rollup, grunt then 
> terser, uglifyjs for
> minifying and what not.
> In majority of the JS packages I've touched (several dozens by now) I almost 
> always had
> to do something more than just running some scripts and I can attest to that.

Interestingly, my experience is different. Most of JS packages I deal
with are rather uniform, but maybe it is just luck.

> A couple of years back, there was no pkg-js-tools (sort of a debhelper sort 
> of tool for JS team) and
> the work was even more. Yadd later wrote this nice tool that automates a 
> number of tasks, and maybe that
> gives you an impression that stuff is unform - sure, it has improved a lot, 
> but you cannot compare it with
> R packages. You can maintain R packages without knowing the build system very 
> well, but not JS.

Maybe it is just pkg-js-tools, yes. When I came to JS packaging,
pkg-js-tools were already there, so I have no experience with the
situation before that. Nevertheless, thanks to pkg-js-tools, JS packages
look quite uniform to me now :)

Apart from that, maintainers of the JS team do great deal of (seemingly
semi-automated) improvements on team-maintained packages. Thus I am
happy about my JS packages in JS team as they are taken care of even
without my attention.

> In case of R packages, dh-R takes care of literally everything. Ofcourse 
> there are exceptions,
> but they are very rare. A template legit works just okay, always.

OK, good to know.

Best,
Andrius

Re: Debian Math Team

[Andrius Merkys]

Hi Ole,

On 2021-11-03 13:52, Ole Streicher wrote:
> Andrius Merkys  writes:
>> problem: How would we define what is math software? What would be done
>> with interdisciplinary software? For example, I maintain two packages, 
>> spglib and voronota, which deal with crystallography (chemistry?), but
>> employ heavy math. Should I put them in debichem or debian-math? I 
>> believe the classification problem cannot be solved in general way,
>> leading to looking for more "pragmatic" classification.
> 
> I sometimes have this problem for Debian Astro packages, and then I
> decide on whether the package is (intended to be) useful outside of
> astronomy. Sometimes this is difficult; f.e. I just uploaded
> "mpl-animators" which does animations with matplotlib, but this depends
> on astropy for many functions which hints me that the authors focus on
> astronomy (and not general) usage.

This might be a candidate for objective criterion, yes.

>>> By this logic, we could push entire debian-med python packages into
>>> python-team, java packages into java-team and so on...
> 
> I really think this is a bit problematic; IMO the problem here is mainly
> that we imply disjunct teams.
> 
> Why can't a Python math package be maintained by both the Python and the
> math team?
> 
> Maintainer: Debian Math Team <...>
> Uploaders: Debian Python Team <...>, me 
> 
> This would set a primary team (and the place in the Salsa directory
> structure), but also allow the Python team to exercise required changes
> as team upload.
> 
> Probably policies and scripts should be adjusted to make use of
> this. And "somehow" the Salsa permissions should match this.

This suggestion gives some feed for thought. I think it should be
proposed on debian-devel first to see if it is possible to adjust
policies, scripts and salsa permissions accordingly.

I am replying to this message instead of yours from Fri, 05 Nov 2021
14:14:35 +0100 just to cite your whole proposal.

Best,
Andrius

Re: Debian Math Team

[Andrius Merkys]

Hi Andreas,

On 2021-11-03 17:55, Andreas Tille wrote:
> Am Wed, Nov 03, 2021 at 01:26:34PM +0200 schrieb Andrius Merkys:
>>> No notes, Andreas came up with this idea in debconf, you could find it on 
>>> videos.debian.net.
>>> But anyways, I have the following point to make:
>>>
>>> 1. Separate team will help keep track of math-specific software, making it 
>>> easy for
>>> interested folks to work on them. Currently there is no specific team, and 
>>> packages
>>> are scattered across several teams which is (in my eyes) a bit haphazard
>>
>> I find it hard to believe that all (most?) of math software in Debian will
>> be brought under this team.
> 
> First let those maintainers move their packages to that team who like it.
> Once this has proven to work nicely others will follow.
> 
>> Then there is the categorization problem: How
>> would we define what is math software? What would be done with
>> interdisciplinary software?
> 
> Blends categorisation is *not* exclusive.  One package can be in two or
> more Blends (and we have lots of examples for this).

ACK. However, team categorization is exclusive.

>> For example, I maintain two packages, spglib and
>> voronota, which deal with crystallography (chemistry?), but employ heavy
>> math. Should I put them in debichem or debian-math?
> 
> Leaving it where it is would be a first approach.
> 
>> I believe the
>> classification problem cannot be solved in general way, leading to looking
>> for more "pragmatic" classification.
> 
> I consider it pragmatic to simply not change anything that works for
> you.  Nobody will force you to move your packages.

OK.

>>> 2. debian-math meta-package (with a separate team) -- this will help 
>>> researchers to get
>>> math related software and tooling in one go (exactly like the debian-med 
>>> metapackage)
>>
>> I would extend Stuart's argument [4] by saying that meta-packages should be
>> independent from teams. As said, I find it hard to believe that all math
>> software will end up in debian-math.
> 
> I try to reword what I thought I would have explained several times (in
> this thread and always when similar discussion was done):  Metapackages
> are *designed* to be independent from teams.  The idea was to build
> sensible sets of user oriented packages and users usually do not ask who
> is maintaining a package (as long as it is maintained at all).  The
> impossibility to put all packages under one team actually created the
> need to find other ways to build those sets of packages.

OK, I got this impression from Nilesh's comment "debian-math
meta-package (with a separate team)". I stand corrected.

> Well, it turns out that maintainers of somehow related software find
> together in one team to enhance cooperation and team maintenance.  But
> this has nothing to do with the metapackage approach per se.

Understood. I think I expressed my doubts about this already.

>>> 3. Easier to find and contribute for people -- I am sure there are a lot of 
>>> people on this list,
>>> and even DDs who are interested in math, having such a team helps them 
>>> approach and contribute well.
>>
>> I am still not entirely sure this will improve the bus factor. Nevertheless
>> please add me to debian-math.
> 
> We can never be sure - but I'm personally extremely optimistic
> considering the amount of positive responses which I'd consider
> overwhelming compared to similar attempts I've seen in the past.

Great - let's see how it goes!

>>> 4. Better maintainance - Lots of math softwares which are still lying 
>>> un-updated, or broken in some ways.
>>> So it helps improve the overall quality
>>
>> This greatly depends on the enthusiasm on the members of the new team (as
>> everywhere in Debian).
> 
> This is correct.  However, the existence of a team is lowering the
> barrier to touch those packages.  I have quite some experience with
> this.

Unless everyone in debian-science (and other teams from where math
packages originate from) are given permissions to push to debiam-math,
barrier is actually raised for them - now they have to apply for
permissions in debian-math. As for the newcomers, fragmentation isolates
them inside these smaller teams, which is probably good.

>>> 5. We have debichem team for chemistry packages, astro team for astronomy 
>>> ones, and now even a new robotics team
>>> We had a new AI team made a few months back. These would also come under 
>>> science earlier, so if we could
>>> make teams for specific d

Re: Debian Math Team

[Andrius Merkys]

Hi Andreas,

Thanks for finding time to reply to my worries.

On 2021-11-01 16:19, Andreas Tille wrote:
>   1. Another "one-man" team
>  I think Ole gave a good answer here:  Its not about creating a
>  one-man team but rather attract more people to the team - from
>  inside and outside Debian.  For those who have any doubt that this
>  can work:  There are 23 people who confirmed, that they became
>  DDs *because* Debian Med exists[4].  Debian Med is now nearly
>  20 years old.  I would love if Debian Math would beat Debian Med
>  in attracting new developers.  (Andrius, you even belong to this
>  set. ;-) )

It is true that I am among these 23 :) My reason for being in the list
is mostly pragmatical: it was Debian Med people who signed my key and
advocated me to become a DD, and for this I am very grateful. I believe
being very open and very friendly to newcomers is one of the strongest
sides of Debian Med.

>  Those 20 years when the Debian Med project have teached me that
>  it is very important to advertise the fact to the world that Debian
>  is targeting specific fields of science and IMHO mathematics is
>   a) well worth to be advertised
>   b) has lots of technically competent people beeing potential DDs
> 
>   2. Further fragmentation of debian-science
>  I do not think that another Blend will lead to fragmentation of
>  Debian Science.  Sure, some mathematics related packages will be
>  moved sooner or later but I personally can not see in how far
>  this might weaken Debian Science.  I personally see also additional
>  contributors for Debian Science once more mathematicans might
>  join Debian (as I'm very positive about).
> 
> Am Sat, Oct 30, 2021 at 06:18:28PM +0530 schrieb Nilesh Patra:
>> Hi Andrius,
>>
>> Thanks for replying. See below :-
>>
>> On Sat, Oct 30, 2021 at 10:33:02AM +0300, Andrius Merkys wrote:

I am skipping most of your replies to Nilesh's response to my mail. I
ACK the skipped parts.

>>> Furthermore, from my experience one does not need domain
>>> knowledge to successfully package and maintain packages in Debian.
>>> What makes more sense to me, is organizing packages into teams based on
>>> programming languages and build/test systems, as such teams indeed
>>> possess specific knowledge. I think most of the mails asking for help in
>>> debian-med concern language and build system problems, not
>>> domain-specific issues. 
>>
>> I'm sorry, but I have to admit this argument of yours is sloppy, Andrius. 
>> By this logic, we could push entire debian-med python packages into 
>> python-team,
>> java packages into java-team and so on...
> 
> While this would work in principle the point of creating a Blend is to
> attract experts who know the algorithm and internals of a certain
> software to craft sensible packages and enable thorough testing.  This
> is usually not simply a programming language issue.  In Debian Med we
> have several upstreams maintaining their software as Debian packages
> (after sufficient teaching of the packaging process and for sure
> sponsored by a DD).  IMHO exactly this is the strength of the Blends
> concept to pair experts of the software with packaging experts.  Even
> better if this can be completed to involve users into that effort which
> does not (yet) work as good as expected (but this has IMHO more external
> reasons which we can hardly solve).

I see your point. However I am not entirely convinced that teams are
essential here. Maybe separate mailing lists could be enough? In the end
upstreams mostly work on one-two source packages, and even if they
become DMs they do not get push/upload permissions for all source
packages of a team, do they? Domain-specific mailing lists could indeed
be a go-to place for newcomers, those in need of help with packaging and
sponsoring and so on.

>>> I am worried reading about R packages being moved from debian-r to new
>>> debian-math. I am afraid doing so might negatively impact their quality.
>>
>> You are right in your worries, but I have some statistics to present here.
>> See here[1] or more specifically, look here[2,3]
> 
> I'm not worried about moving R packages to some other Blend.  It has
> turned out to be a good idea to move all R packages from Debian Science,
> Debian Med Debichem and possibly others into one language specific team.
> However, this had happened since R packages are extremely uniform and
> usually come with test suites that can be re-used which to some extend
> is taking over the role of an expert knowing the software.  There are
> also not really any specific decisions to make about 

Re: Debian Math Team

[Andrius Merkys]

Hi Nilesh,

On 2021-10-30 15:48, Nilesh Patra wrote:

Thanks for replying. See below :-


Thanks for answering my concerns, and sorry for the long silence.


On Sat, Oct 30, 2021 at 10:33:02AM +0300, Andrius Merkys wrote:

I agree with Anton here. I do not see how further fragmentation of
debian-science could benefit it. I missed the BoF, but maybe there are
notes reflecting this decision?


No notes, Andreas came up with this idea in debconf, you could find it on 
videos.debian.net.
But anyways, I have the following point to make:

1. Separate team will help keep track of math-specific software, making it easy 
for
interested folks to work on them. Currently there is no specific team, and 
packages
are scattered across several teams which is (in my eyes) a bit haphazard


I find it hard to believe that all (most?) of math software in Debian 
will be brought under this team. Then there is the categorization 
problem: How would we define what is math software? What would be done 
with interdisciplinary software? For example, I maintain two packages, 
spglib and voronota, which deal with crystallography (chemistry?), but 
employ heavy math. Should I put them in debichem or debian-math? I 
believe the classification problem cannot be solved in general way, 
leading to looking for more "pragmatic" classification.



2. debian-math meta-package (with a separate team) -- this will help 
researchers to get
math related software and tooling in one go (exactly like the debian-med 
metapackage)


I would extend Stuart's argument [4] by saying that meta-packages should 
be independent from teams. As said, I find it hard to believe that all 
math software will end up in debian-math.



3. Easier to find and contribute for people -- I am sure there are a lot of 
people on this list,
and even DDs who are interested in math, having such a team helps them approach 
and contribute well.


I am still not entirely sure this will improve the bus factor. 
Nevertheless please add me to debian-math.



4. Better maintainance - Lots of math softwares which are still lying 
un-updated, or broken in some ways.
So it helps improve the overall quality


This greatly depends on the enthusiasm on the members of the new team 
(as everywhere in Debian).



5. We have debichem team for chemistry packages, astro team for astronomy ones, 
and now even a new robotics team
We had a new AI team made a few months back. These would also come under 
science earlier, so if we could
make teams for specific domains, *and* they are doing well, why not do so for 
math?
I mean this comes as a very natural choice to me, considering other blends.


Indeed, precedents for debian-math exist. I do not want to block 
launching debian-math, I am just questioning whether fragmentation by 
domain will result in significant increase of net attention for packages.


For debian-ai, I see a clear need. Packaging AI software for Debian has 
its own specific implications, and its coordination is important.



Separate team and separate mailing list will have less members than
debian-science.


Well, every other team has started exactly the same way in Debian (i.e. less 
members) -- it would
grow with time, I don't think it'll be stalled for ever.
I could _somehat_ agree with the mailing list thingy, maybe we can
keep using this list for discussions.
  

Furthermore, from my experience one does not need domain
knowledge to successfully package and maintain packages in Debian.
What makes more sense to me, is organizing packages into teams based on
programming languages and build/test systems, as such teams indeed
possess specific knowledge. I think most of the mails asking for help in
debian-med concern language and build system problems, not
domain-specific issues.


I'm sorry, but I have to admit this argument of yours is sloppy, Andrius.
By this logic, we could push entire debian-med python packages into python-team,
java packages into java-team and so on... >
You also mentioned debian-med above, so if you think everything would be 
per-language
organised, why do you think separate teams (like -med, or -astro) should even 
exist?


Sure, feel free to disagree. I however cannot solve the package 
categorization even for myself - almost every time I package stuff I 
have to deliberate on where to push it. I see per-language teams 
employing semi-automated means to update packages/fix common issues, 
therefore I believe my packages would stay in good shape there even 
without my input.



The whole point of blends is to help people with "specific" needs, right.
and such teams help organize that in a reliable way.


In real life I personally do not meet Debian/Ubuntu users who know what 
a "blend" or "team" in Debian is. Most users I meet use apt to search 
for particular packages they need, that's all. If not found, they turn 
to snap or conda or just .deb lying around on the Web. Of course thi

Re: Debian Math Team

[Andrius Merkys]

On 2021-10-30 14:45, Anton Gladky wrote:
> I do not see any benefits from creating a one-more team. It decreases
> definitely bus-factor of the package, will unlikely increase their quality
> and for end-users it is mostly not visible, in what team it is maintained.
> 
> Sure, feel free to create it, if you want, but please do not move any existing
> packages from any team to a new one without prior confirmation of all
> uploaders.
> 
>>From my point of view, we have enough really useful work in Debian which
> needs to be done (fixing bugs, adding autopkgtests, setting-up
> CI-pipelines etc.)
> instead of moving packages between teams.

Couldn't agree more. Uploader agreement to moving is a must, IMO.

Best,
Andrius

Re: Debian Math Team

[Andrius Merkys]

Hi,

On 2021-10-29 20:31, Torrance, Douglas wrote:
> During the Debian Science BoF at this year's DebConf, there was some
> discussion of creating a team devoted to packaging mathematical software.

I agree with Anton here. I do not see how further fragmentation of
debian-science could benefit it. I missed the BoF, but maybe there are
notes reflecting this decision?

Separate team and separate mailing list will have less members than
debian-science. Furthermore, from my experience one does not need domain
knowledge to successfully package and maintain packages in Debian.

What makes more sense to me, is organizing packages into teams based on
programming languages and build/test systems, as such teams indeed
possess specific knowledge. I think most of the mails asking for help in
debian-med concern language and build system problems, not
domain-specific issues. Thus I am very comfortable keeping my math
packages in per-language teams knowing that these teams will take good
care of them if needed.

I am worried reading about R packages being moved from debian-r to new
debian-math. I am afraid doing so might negatively impact their quality.

Best,
Andrius

Re: Update Ceres Solver to 2.0.0

[Andrius Merkys]

Hi François,

On 2021-10-03 12:50, François Mazen wrote:
> I've just packaged the last version of ceres package and I've pushed it
> to the salsa repo [1], and to mentors [2].
> 
> Could someone review the package? The tricky part may be the transition
> of the lib package from libceres1 to libceres2. For now, I've just
> renamed the binary package but maybe some additional actions are
> required?

Transitions for libs packages in Debian indeed have to proceed a certain
workflow [3]. To start with, you should target experimental instead of
unstable in debian/changelog.

> In addition, could you please grant me right to upload the package as
> I'm DM?

It would be best if Anton could help you with upload and rights.

> [1] https://salsa.debian.org/science-team/ceres-solver
> [2] https://mentors.debian.net/package/ceres-solver/

[3] https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Best,
Andrius

Re: DEP-12 field cite-as case sensitivity

[Andrius Merkys]

Hi,

On 2021-05-12 15:49, Gard Spreemann wrote:
> It is my understanding that fields in d/u/metadata are meant to be
> case-insensitive (according to [1]). Yet, Lintian seems to complain
> about "Cite-as", but not "Cite-As". Is this a Lintian bug, or a
> documentation bug, or a me-bug?

The statement "Field names are case-insensitive" is under "Deprecated
features" section, thus I assume this statement is deprecated too. Thus
lintian is correct by complaining about "Cite-as".

Best,
Andrius

Re: Packaging Open Porous Media (OPM) software suite

[Andrius Merkys]

Hi Markus,

On 2021-04-28 16:17, Markus Blatt wrote:
> I have recently posted an ITP (bug )for this software
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987381

Thanks a lot an interesting ITP, and welcome to the team!

Just a couple of comments on points not addressed by Anton:

> - For the library packages the SONAME will change with each release, as
>  the ABI is quite unstable. The version is not part of the library
>  package name, which lintian would warn about. But we are overwriting
>  the warning currently.

This lintian warning is quite important. If the ABI is unstable, I would
suggest making these libraries private by putting them under
/usr/lib//opm (for example) and shipping them in the same
binary package as the main executable(s).

> - Does the top-level directory in the tarballs need to have a special
>  name (like opm-common-2021.04 for version 2021.04 of opm-common)?
>  The reason for asking is that upstream tags final versions as
>  release//final, which will make uuscan us funny looking
>  opm-common-release-2021.04-final. If it does upstream needs to use the
>  more common tagging scheme v, or we need to create the
>  tarballs ourselves and use gbp import-orig .

The suffix '-final' can be removed by uscan's option 'uversionmangle'.

Best,
Andrius

Re: Multi-Body Dynamics Simulation in Debian

[Andrius Merkys]

Hi Rock,

On 2021-03-26 16:37, Rock Storm wrote:
> I recently came across the question of whether I could replace
> proprietary MSC ADAMS [1] software for multi-body dynamics simulation with
> a FOSS alternative. Best, option seems to be MBDyn [2]. However, it is
> not packaged in Debian though it was requested quite long ago [3].
> 
> [1]: https://en.wikipedia.org/wiki/MSC_Adams
> [2]: https://www.mbdyn.org
> [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899218

I managed to build MBDyn on Debian unstable and pushed my initial
packaging efforts to salsa [4]. The package needs some work to be
finished (I plan to do that), and hopefully MBDyn will arrive in Debian
soon.

[4] https://salsa.debian.org/science-team/mbdyn

Best,
Andrius

Re: Bug#984497: weasels and doves

[Andrius Merkys]

On 2021-03-10 02:38, George N. White III wrote:
> On Mon, 8 Mar 2021 at 12:36, Andrius Merkys  <mailto:mer...@debian.org>> wrote:
> Many users will not look into e-mail addresses. They will search online
> using the name of the software, and will arrive at the same developers'
> desk. This might be offset by renaming entire pieces of software, but
> renamed packages become hardly visible and all valuable online material
> related to the original name becomes hidden from users.
> 
> Renaming should be like "debian-sid-" for supported 
> by Debian packages.

I assume your suggestion is to keep such packages sid-only. Apart from
compilers/build systems (sbt and bazel, to name a few), I am not sure
about the benefit of sid-only packages.

> There are, however, use-cases where packaging is not
> helpful to users:
> 
> 1. a package that relies on "customized" configurations of widely used
> libraries
> (hdf4 and gdal are examples of libraries with many optional extensions).
> 
> 2. a package whose purpose is to provide highly optimized versions of common
> libraries for low volume hardware (such as large HPC systems).   There are
> many potential hardware configurations with new configurations being
> released
> multiple times a year.   There are complicated issues of reproducibility
> and
> testing that don't have one size fits all answers.

This problem is general, not limited to software whose developers object
inclusion in Debian.

Andrius

Re: Bug#984497: weasels and doves

[Andrius Merkys]

Hi,

On 2021-03-08 15:44, Albert van der Horst wrote:
> I don't see the problem here. If there is a bug in an old version supplied 
> with Debian, the bug report lands with Debian. 

Not necessary. Many users cannot tell whether a bug is caused by
upstream code or Debian packaging. Many users do not know about Debian
BTS. Thus Debian-specific bugs land in upstream trackers, and some
upstreams do not want to provide support outside what they consider
"canonical" use of their software.

> Then Debian can solve the bug report by renewing upstream. Sot that bug 
> report is not against the package, but against the packaging.

True, but this might be slowed down by the update process in stable.

> If it persists in the newest version, the bug can be passed to 
> upstream.

Again - if the report ends up in Debian BTS.

> Bug reports will not land at the developpers desk, or Debian has to take 
> measures that they don't, e.g. by replacing e-mail addresses. No reasonable 
> upstream developer will object to such an arrangement.

Many users will not look into e-mail addresses. They will search online
using the name of the software, and will arrive at the same developers'
desk. This might be offset by renaming entire pieces of software, but
renamed packages become hardly visible and all valuable online material
related to the original name becomes hidden from users.

Best,
Andrius

Re: Shipping bibtex files

[Andrius Merkys]

On 2021-01-27 11:06, Andreas Tille wrote:
> In any case you should run `yamlling` on the result.  I think there
> are also some lintian checks applied.

Indeed lintian does some checks:

$ grep debian/upstream/metadata -lR /usr/share/lintian/tags/
/usr/share/lintian/tags/d/debian-upstream-obsolete-path.tag
/usr/share/lintian/tags/p/privacy-breach-donation.tag
/usr/share/lintian/tags/u/upstream-metadata-not-yaml-mapping.tag
/usr/share/lintian/tags/u/upstream-metadata-field-present.tag
/usr/share/lintian/tags/u/upstream-metadata-in-native-source.tag
/usr/share/lintian/tags/u/upstream-metadata-missing-repository.tag
/usr/share/lintian/tags/u/upstream-metadata-exists.tag
/usr/share/lintian/tags/u/upstream-metadata-yaml-invalid.tag
/usr/share/lintian/tags/u/upstream-metadata-file-is-missing.tag
/usr/share/lintian/tags/u/upstream-metadata-is-not-a-file.tag
/usr/share/lintian/tags/u/upstream-metadata-missing-bug-tracking.tag

However, the references themselves (in Reference field) do not seem to
be checked. I volunteer to implement that in lintian.

Best,
Andrius

Re: Shipping bibtex files

[Andrius Merkys]

Hi Gard,

On 2021-01-23 12:01, Gard Spreemann wrote:
> I took a stab at it for one package. Does this seem sane?
> 
> https://salsa.debian.org/gspr/hera/-/blob/2749a47cad5b1b25f4c5cd219db2db907bd4ddc7/debian/upstream/metadata

Seems OK to me. I am not aware of any validation tool for d/u/metadata,
as one would be helpful for building from scratch. Adding it to my
mental todo list :)

Best,
Andrius

Re: Shipping bibtex files

[Andrius Merkys]

Hi Gard,

On 2021-01-22 15:09, Gard Spreemann wrote:
> I've been meaning to add upstream's bibliography data to some of my
> packages. My understanding [1] is that this should be done through
> d/upstream files, but it is also my impression that DEP-12 has stalled a
> bit.
> 
> What is the current preferred way to do this?

I have seen quite some packages with bibliographic data in d/u/metadata
in DEP-12 style [2]. Debian Med seems to be using it successfully,
AFAIK, their Blend page [3] is generated from d/u/metadata.

I am not aware of any helper tools, however. Converter from BibTeX to
DEP-12 YAML would be really nice.

> [1] https://wiki.debian.org/DebianScience/Citations

[2] https://wiki.debian.org/UpstreamMetadata
[3] https://blends.debian.org/med/tasks/

Best,
Andrius

nauty 2.7r1+ds-1 uploaded

[Andrius Merkys]

Hi Doug,

Yesterday I reviewed and uploaded your packaging of nauty 2.7r1+ds-1.
Thanks a lot for your work!

Best,
Andrius

Re: Please delete science-team/ete3

[merkys]

On 2020-07-09 09:10, PICCA Frederic-Emmanuel wrote:
> done

Thanks!
Andrius

Please delete science-team/ete3

[merkys]

Hello,

Could someone with appropriate rights delete empty repository science-team/ete3 
from salsa? This one has been named incorrectly, and was replaced with 
med-team/python-ete3.

Thanks,
Andrius

Re: RFS ete

[merkys]

On 2020-07-03 13:50, zhao feng wrote:
> Thanks for your help. I can build the package on buster and bullyseye.
> Which distribution do you use? I find the version of softwares like
> python is quite new.

The package fails to build on clean sid chroot. Most likely some Python
dependencies are missing from debian/control.

> The upstream uses `ete` as the name of repository but they call the
> Python package `ete3`. In their paper, they explain the number 3 is
> the version and in their roadmap they plan to release `ete4`.
> (https://github.com/etetoolkit/ete/wiki/ROADMAP). I think using a
> version independent name like `ete` for source package and
> `python3-ete` for library is convenient. How to do think about it?

I agree that the source package could stay named 'ete'. However, after
reading the Debian Python naming conventions [1] I became even more
convinced to name the package 'python3-ete3'.

[1]
https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html#package_names

> 2-5 has been fixed now.

The copyright entry for 'SQLite-Levenshtein' seems still missing from
debian/copyright. Could you please add it?

> I have created a directory in
> https://salsa.debian.org/science-team/ete3 but I do not have
> privileges to create a branch. Can you help on it?

I see you have named the repository 'ete3'. This means you want to name
the source package 'ete3' as well, or was this unintentional?

By the way, packaging of 'ete3' seems to be ongoing in Debian Med team
as well (adding Andreas in CC):
https://salsa.debian.org/med-team/python-ete3. I suggest getting in
touch with them to keep duplicate efforts minimal.

Best wishes,
Andrius

Re: RFS ete

[merkys]

Hello,

On 2020-07-02 17:23, zhao feng wrote:
> ok, the warning has been fixed by 3.1.1-3

Thanks for fixing lintian issues. I have cloned your repository, tried
to build it, and ran into the following problem:

   dh_auto_test -O--buildsystem=pybuild
pybuild --test -i python{version} -p 3.8
I: pybuild base:217: cd
/home/andrius/debian-packages/ete/.pybuild/cpython3_3.8_ete/build;
python3.8 -m pytest -k "not test_ncbiquery and not test_skbio and not
test_ncbi_compare and not test_get_topology and not
test_01tree_annotation and not test_00_update_database"
ete3/test/test_api.py
= test session starts
==
platform linux -- Python 3.8.4rc1, pytest-4.6.11, py-1.8.1, pluggy-0.13.0
rootdir: /home/andrius/debian-packages/ete
plugins: timeout-1.3.3, cov-2.8.1
collected 51 items / 6 deselected / 45 selected

ete3/test/test_api.py Aborted
E: pybuild pybuild:352: test: plugin distutils failed with: exit
code=134: cd
/home/andrius/debian-packages/ete/.pybuild/cpython3_3.8_ete/build;
python3.8 -m pytest -k "not test_ncbiquery and not test_skbio and not
test_ncbi_compare and not test_get_topology and not
test_01tree_annotation and not test_00_update_database"
ete3/test/test_api.py
dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned
exit code 13
make: *** [debian/rules:9: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -I failed
gbp:error: 'debuild -i -I -uc -us' failed: it exited with 29

Do you know what might be the reason?

A few more issues to address to address:

1. I am under the impression that the Python package should be named
'ete3', not 'ete'. After installing the .deb package Python command
'import ete3' fails.

2. Directory 'SQLite-Levenshtein' (SQLite extension for Levenshtein
algorithm) should not be present in the .deb package, at least not in
its current form. However, it could be packaged separately in the future.

3. If 'SQLite-Levenshtein' remains in the source, it should be mentioned
in debian/copyright.

4. The copyright for ETE is GPL-3+.

5. Please consider licensing debian/ directory under the same license
too to avoid possible license incompatibilities.

6. Please consider maintaining this package under the umbrella of Debian
Python or Science teams. To do so, join the appropriate team, move the
packaging repository to their namespace, and adjust Maintainer and
Uploaders fields in debian/control.

Thanks for your efforts to package ete.

Best wishes,
Andrius

Re: RFS ete

[merkys]

Hi,

I have tried building the package from the packaging repository on
salsa, however, 'upstream' and 'pristine-tar' branches are missing
there. Could you please push them with 'salsa push' or 'git push --all
&& git push --tags'?

On 2020-07-02 11:03, zhao feng wrote:
> feng@debian:~/ete$ lintian python3-ete_3.1.1-1.1_all.deb
> W: python3-ete: binary-without-manpage usr/bin/ete3
> W: python3-ete: copyright-has-url-from-dh_make-boilerplate
> W: python3-ete: description-synopsis-starts-with-article
> W: python3-ete: executable-not-elf-or-script
> usr/lib/python3/dist-packages/ete3/test/test_circle_label.py
> W: python3-ete: executable-not-elf-or-script
> usr/lib/python3/dist-packages/ete3/test/test_treeview/barchart_and_piechart_faces.py
> W: python3-ete: executable-not-elf-or-script
> usr/lib/python3/dist-packages/ete3/test/test_treeview/bubble_map.py
> W: python3-ete: executable-not-elf-or-script ... use
> --no-tag-display-limit to see all (or pipe to a file/program)
> W: python3-ete: file-in-unusual-dir usr/ete3/tools/ete_build.cfg
> W: python3-ete: non-standard-dir-in-usr usr/ete3/
> W: python3-ete: package-contains-vcs-control-file
> usr/lib/python3/dist-packages/ete3/ncbi_taxonomy/SQLite-Levenshtein/.gitignore
> feng@debian:~/ete$ lintian --version
> Lintian v2.80.0

These lintian warnings too should be fixed. Most of them are rather easy
to fix.

Best wishes,
Andrius

Re: RFS ete

[merkys]

Hello,

On 2020-06-30 11:56, zhao feng wrote:
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/ete

mentors.debian.net report lintian errors for this package. These have to
be addressed prior to sponsoring.

Best wishes,
Andrius

Re: [RFS] bibutils for an upload in experimental

[merkys]

Hi Pierre,

On 2020-04-26 12:39, Pierre Gruet wrote:
> Absolutely, the only non-Haskell reverse dependency is the binary bibutils.
> I have already filed a blocking bug, which I am going to raise to RC, and I
> will write to the list following your advice.

bibutils themselves should be fine. Haskell packages might require
either binNMU, or source uploads.

Best wishes,
Andrius

Re: [RFS] bibutils for an upload in experimental

[merkys]

Hi Pierre,

On 2020-04-25 15:53, Pierre Gruet wrote:
> The release team has just asked to go ahead after I submitted a transition
> bug [1]; I have prepared the upload to unstable in Salsa [2] (with
> UNRELEASED distribution), would you please mind uploading it, as you kindly
> offered?

Done. Thanks for your contribution!

I see that the most of the reverse dependencies of bibutils belong to
Haskell team. As I am not a member of that team, please contact them for
sponsoring haskell-* packages.

Best wishes,
Andrius

Re: [RFS] bibutils for an upload in experimental

[Andrius Merkys]

Hi Pierre,

On Tue, 14 Apr 2020, 18:54 Pierre Gruet,  wrote:

> Thanks a lot for reviewing my work, correcting this mistake and uploading
> the package to experimental!
>

Happy to help!

I will now wait for it to exit NEW and then launch the transition procedure.


Sure! Ping me when you need an upload to unstable for this.

Best wishes,
Andrius

Re: [RFS] bibutils for an upload in experimental

[merkys]

Hi Pierre,

On 2020-04-08 19:59, Pierre Gruet wrote:
> Some days ago I worked on the packaging of bibutils, which is maintained in
> the team. I had to bump the SONAME and therefore I ask for sponsorship to
> put it in *experimental* in order to begin a transition procedure, having
> identified four reverse-dependencies.
>
> If time permits, I would be happy to get feedback on my packaging and to
> have the package uploaded.

I have uploaded bibutils to experimental today. I have just changed a
line in the debian/changelog saying that libraries are placed in
/usr/share, when indeed they seem to be placed in /usr/lib.

Thanks a lot for your contribution!

Best,
Andrius

Re: Request to source-only upload https://salsa.debian.org/science-team/ricks-amdgpu-utils/

[merkys]

Hi Steffen,

On 2020-04-08 20:03, Steffen Möller wrote:
> My GPG key expired, could someone please source-only upload Rick's
> AMDGPU utils from
> https://salsa.debian.org/science-team/ricks-amdgpu-utils/ ? I have run
> it through cowbuilder. 

Done.

Best,
Andrius

Re: Insufficient privileges on Salsa to create a default branch

[merkys]

On 2019-04-25 16:45, Emmanuel Arias wrote:
> If you need work, meanwhile you can create your own repo.
> Then, when you have privileges you can transfer the repo.

Sure, thanks.

Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Insufficient privileges on Salsa to create a default branch

[merkys]

Hello,

it seems that my current privileges in Debian Science group on Salsa
('Developer') are sufficient to create new projects, but insufficient to
create default branches for them:

remote: GitLab:
remote: A default branch (e.g. master) does not yet exist for
science-team/coot-reference-structures
remote: Ask a project Owner or Maintainer to create a default branch:
remote:
remote:  
https://salsa.debian.org/science-team/coot-reference-structures/project_members
remote:
To salsa.debian.org:science-team/coot-reference-structures.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to
'g...@salsa.debian.org:science-team/coot-reference-structures.git'

Could I be promoted to Maintainer status? My Salsa login is 'merkys'.

Thanks,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

On 05/05/2018 03:30 PM, PICCA Frederic-Emmanuel wrote:
> Is it possible to add a get-orig-source target in order to deal with the ccp4 
> release process workflow.
> using bzr in order to get the latest trunk branch of mmdb ?.

This should be doable, but I have to find some more time to look into it. I'm 
not common with bzr.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

On 05/05/2018 03:15 PM, PICCA Frederic-Emmanuel wrote:
> It was uploaded into experimental.

Oh, I overlooked 2.0.1-1~exp1. Currently experimental contains 2.0.5-1~exp1, 
which has libmmdb2-0-dbgsym debug symbols package, which superseded the -dbg 
one. Sorry. Fixed now.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

On 05/05/2018 02:55 PM, PICCA Frederic-Emmanuel wrote:
> the migration is for the libmmdb2-0-dbg package and not the  libmmdb0-dbg one.

True indeed, but package 'libmmdb2-0-dbg' was never uploaded neither to 
unstable nor to testing. Therefore, there is no use of 'Breaks' or 'Replaces' 
indication for it. Or do I miss something?

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

On 05/05/2018 12:44 PM, PICCA Frederic-Emmanuel wrote:
> Can you do this before the upload ?

Done. I hope I did it right. Debug symbols package descriptions now contain 
correct Breaks and Replaces records.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

Hi,

On 05/05/2018 12:16 PM, PICCA Frederic-Emmanuel wrote:
> You juts have to follow the instructions and remove all the -dbg packages and 
> add the dh command line options :)

Sounds really easy :)

> Yes, and did you subscribe to ccp4-dev mailinglist.
> It would be great also to work with the upstream in order to integrate the 
> relevant debian patches :).

True indeed. I have just subscribed to the list.

> Just tell me when it is ok for you, and I will upload mmdb first to start the 
> transition :).

I think that's OK with me right now :) Please proceed, and let me know should 
anything fail.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

Hello,

On 05/04/2018 11:38 AM, PICCA Frederic-Emmanuel wrote:
> It would be great if you could add yourself to the Uploaders list.

done :)

> https://wiki.debian.org/AutomaticDebugPackages
>
> So it seems that you need to add the migration in the rules file :)

I see. OK, I was not aware of that.

> Is it possible for you to check with the ccp4 upstream on the ccp-dev mailing 
> list if it is possible to have the lastest sources packages of libccp4, mmdb, 
> ssm and clipper.
> I had to ask for them each time to Marcin Wojdyr

I saw your recent e-mail to the ccp4-dev mailing list. Let's hear what they 
will say.

> then I will upload the packages, once I build them with sbuild :))

Great!

Thanks,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

Hi Frederic-Emmanuel,

I have reserved a transition slot 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897579) and updated the mmdb 
reverse dependencies. There were new upstream releases for ssm and clipper, I 
have packaged both of them.

I have updated topmost changelog entries, however, I signed them as myself to 
prevent lintian timewarp warnings. Feel free to replace my signatures with 
yours.

Moreover, I don't know what to do with '--ddeb-migration' dh options. Do you 
know, should they be removed before the transition? I have left them where they 
were.

Could you please upload updated mmdb, ssm, clipper and libccp4 packages to 
unstable if they are OK? If not, let me know what should I fix.

Thanks,
Andrius

On 05/02/2018 07:25 PM, PICCA Frederic-Emmanuel wrote:
> It would be nice tu update all these library to the lateste versions :))

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

On 05/02/2018 07:25 PM, PICCA Frederic-Emmanuel wrote:
> It would be nice tu update all these library to the lateste versions :))

OK, I'll see what I can do :)

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: mmdb transition

[Andrius Merkys]

Hello,

On 05/02/2018 07:21 PM, PICCA Frederic-Emmanuel wrote:
> Not enough time from my side :((. If you want to take care of this. It is ok 
> for me.

sure, I would like to give it a try. Will you help me with uploading the 
packages once they're ready?

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

mmdb transition

[Andrius Merkys]

Dear Frédéric-Emmanuel,
dear all,

I noticed that mmdb v2.0.5 was uploaded to experimental, however, the full 
transition of mmdb does not seem to be carried out yet. I wonder what were the 
showstoppers? All r-dependencies of mmdb 
(https://release.debian.org/transitions/html/auto-mmdb.html) seem to build 
successfully for me, therefore, I guess the transition could be initiated. mmdb 
>= 2 is a build dependency of coot, which I would like to see in Debian one day.

Best wishes,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: [Debichem-devel] Membership and permissions for repository creation on salsa

[Andrius Merkys]

Dear Daniel,

On 04/13/2018 01:34 PM, Daniel Leidert wrote:
> We basically follow the same role principle as described in the debian-
> science policy. To create a new project, you can simply ask. Another
> possibility is to create the project in your personal workspace. As soon
> as you find it ready, tell us, and we can import it into the group space
> from there. Then we can also adjust the projects permissions if necessary.

thanks for the explanation. I prefer creating projects in my personal workspace 
and asking to be moved after they are done.

Best,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: [Debichem-devel] Membership and permissions for repository creation on salsa

[Andrius Merkys]

Dear Boris,

On 04/12/2018 11:27 AM, Boris Pek wrote:
> It is briefly described in Debian Science Policy Manual:
> https://science-team.pages.debian.net/policy/#idm145

thanks for the link. I was not aware of this change of the policy.

Best wishes,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Membership and permissions for repository creation on salsa

[Andrius Merkys]

Hello,

I am a member of Debian Science Team and Debichem, and as a "Member" I had 
permissions to create repositories on anonscm.debian.org in both projects. 
However, on salsa.debian.org I am "Developer", therefore I can not create new 
repositories in neither of the projects. How can I contribute new packages on 
salsa?

Best wishes,
Andrius

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Re: Pushing commits to GitLab-Salsa not allowed

[Andrius Merkys]

Dear Boris,

On 01/11/2018 10:59 AM, Boris Pek wrote:
> Just join to Debian Science Team group:
> https://salsa.debian.org/science-team
> as a member with Developer level of access:
> https://docs.gitlab.com/ee/user/permissions.html

many thanks for the explanation! I have requested to join the Team and
now I am able to push my commits.

Best regards,
Andrius

-- 
Andrius Merkys
PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, 
room V325
LT-10257 Vilnius, Lithuania

Pushing commits to GitLab-Salsa not allowed

[Andrius Merkys]

Dear all,

I used to own a guest account on Alioth, and with this account I have
created a few packaging GIT repositories. However, since the transition
to GitLab-Salsa I am unable to push my commits:

andrius@tasmanijos-velnias cod-tools $ git remote set-url origin
g...@salsa.debian.org:science-team/cod-tools.git
andrius@tasmanijos-velnias cod-tools $ git push
GitLab: You are not allowed to push code to this project.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights

I have signed up on salsa.debian.org (@merkys-guest) and set up my SSH
key. Could this be because of me being absent from 'Project members' of
my package's project
(https://salsa.debian.org/science-team/cod-tools/project_members)? If
so, could I be added?

Best wishes,
Andrius

-- 
Andrius Merkys
PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, 
room V325
LT-10257 Vilnius, Lithuania

Bug #864713: cod-tools package is ready

[Andrius Merkys]

Dear maintainers,

I have prepared the Debian package for cod-tools in its package
repository of Debian Science
(https://anonscm.debian.org/git/debian-science/packages/cod-tools.git/)
and I am looking for a sponsor. I think the package is suitable for
DebianScience/Chemistry metapackage.

Sincerely,
Andrius Merkys

-- 
Andrius Merkys
PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, 
room V325
LT-10257 Vilnius, Lithuania

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

[Andrius Merkys]

Dear Andreas,

thank you for your message. I would gladly maintain my package in either
Debian Science or DebiChem team.

Best wishes,
Andrius


On 10/06/17 07:58, Andreas Tille wrote:
> Hi Andrius,
>
> thanks for this interesting ITP.  This package seems to fit nicely into
> the scope of Debian Science or DebiChem.  I'd like to suggest you should
> maintain the package in either of this team.
>
> Kind regards
>
>Andreas.
>
> On Wed, Jun 07, 2017 at 04:33:49PM +0300, Andrius Merkys wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Andrius Merkys 
>>
>> * Package name: cod-tools
>>   Version : 2.0
>>   Upstream Author : Saulius Gražulis , Andrius Merkys 
>> , Antanas Vaitkus 
>> * URL : http://wiki.crystallography.net/cod-tools
>> * License : GPL 2.0
>>   Programming Lang: C, Perl, Python, Shell
>>   Description : tools for manipulation of Crystallographic Information 
>> Format v1.1 and v2.0 files
>>
>> The package contains Crystallographic Information Format (CIF) v1.1 and
>> v2.0 parser (parser of CIF v1.1 is compared to other parsers in Merkys et
>> al. 2016, doi:10.1107/S1600576715022396) and scripts for manipulating CIF
>> files. Package includes CIF parser bindings for C, Perl and Python. Tools
>> from the package are used in the development and maintenance of the
>> Crystallography Open Database (http://www.crystallography.net/cod/, usage
>> described in Gražulis et al. 2009, doi:10.1107/S0021889809016690 and
>> Gražulis et al. 2015, doi:10.1107/S1600576714025904). The tools follow
>> the same filter-like usage pattern as Netpbm.
>>
>> As I am an upstream author, I plan to maintain the package myself. As
>> this is my first submission, I will need a sponsor.
>>
>>

-- 
Andrius Merkys
PhD student at Vilnius University Institute of Biotechnology, Saulėtekio al. 7, 
room V325
LT-10257 Vilnius, Lithuania
Lecturer at Vilnius University Faculty of Mathematics and Informatics, 
Naugarduko g. 24
LT-03225 Vilnius, Lithuania