Re: Developer statistics

Hi Joost, On 2024-09-18 12:13, Joost van Baal-Ilić wrote: On Wed, Sep 18, 2024 at 08:57:21AM +0300, Andrius Merkys wrote: Is it possible to: 1. List all uploads of a certain DD during a given period of time? 2. List all closed bugs by a certain DD during a given period of time? I am

Developer statistics

Dear Team, Is it possible to: 1. List all uploads of a certain DD during a given period of time? 2. List all closed bugs by a certain DD during a given period of time? I am applying for a local open science award and would like to put quantitative measurements in my application. Best wishes

Re: Action needed for R-pkg Uploaders

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

Re: emboss and python-biopython stuck in Building state

Hi Étienne, On 2024-04-23 20:25, Étienne Mollier wrote: r-cran-hunspell looks also affected on armel: r-cran-hunspell (6d 7h 31m, arm-arm-01) python-biopython (6d 5h 16m, arm-arm-03) also pyresample on arm64: emboss (6d 7h 49m, arm-arm-01) pyresample (6d 7h 9m,

emboss and python-biopython stuck in Building state

Hello, Five days ago I have uploaded emboss and python-biopython. Both are stuck in "Building" state since then, emboss on arm64 and python-biopython on armel. This is strange to me, as normally long builds timeout after periods of inactivity (no output). I have successfully rebuilt emboss on

Re: Emboss not migrating due to autopkgtest error on s390x

Hi Nilesh, On 2024-04-16 17:03, Nilesh Patra wrote: On Tue, Apr 16, 2024 at 04:52:01PM +0300, Andrius Merkys wrote: On 2024-04-16 15:04, Nilesh Patra wrote: OTOH, does anyone actually use s390x for any med team package? If not, can we consider to add this too along with other 32-bit archs to

Re: Emboss not migrating due to autopkgtest error on s390x

Hi, On 2024-04-16 15:04, Nilesh Patra wrote: I suppose you meant "RM" instead of "BTS" here. Thanks for filing a report. No, I meant filing a BTS bug, which I did file as #1069098 in order to keep track of the issue in previous Debian releases too. OTOH, does anyone actually use s390x for

Bug#1069098: emboss: all executables segfault on s390x

Package: emboss Version: 6.6.0+dfsg-9 Severity: important Tags: bullseye bookworm trixie sid X-Debbugs-CC: debian-med@lists.debian.org Hello, All emboss executables segfault on s390x since bullseye. Segfault is evident when calling any of emboss executables without CLI arguments or only with '

Re: Emboss not migrating due to autopkgtest error on s390x

On 2024-04-16 03:23, Aaron M. Ucko wrote: s390x is a 64-bit architure, so the time_t64 transition was a pure formality there. (The old s390 architecture would have been affected but retired several years ago.) Oh, right, it really is. Just checked on a porterbox, apparently all emboss executa

Re: Emboss not migrating due to autopkgtest error on s390x

Hi, On 2024-04-14 16:42, Andreas Tille wrote: according to tracker[1] emboss is not migrating due to a test suite error on s390x[2]. IMHO the appropriate thing to do is to also remove s390x architecture - but we also need to care for all rdepends (again after removing these for 32bit). Any vol

Re: libcifpp updated

Hi Maarten, On 2024-04-03 18:32, Maarten L. Hekkelman wrote: Could someone with the appropriate powers have a look a the updated package for libcifpp and upload it to the proper location? I guess it needs to go through experimental again? I can give it a look. I noticed that libcifpp git repo

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

Hello, On 2024-03-29 06:43, Nilesh Patra wrote:> There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the s

Re: Passing on maintenance of node-shiny-server dependencies

Hi Nilesh, On 2023-09-28 19:28, Nilesh Patra wrote: On Thu, Sep 28, 2023 at 10:28:31AM +0300, Andrius Merkys wrote: The packages are in a good shape, most of them have no open bugs and are up-to-date with their upstreams. I will wait for responses for a couple of weeks before orphaning them

Passing on maintenance of node-shiny-server dependencies

Hi all, Back in a day I packaged/sponsored a bunch of node packages needed by node-shiny-server. I ended up never using shiny-server and/or node-shiny-server, but with the responsibility for its dependencies. I would be happy if someone from Med or JS teams could step up and replace me as the

Re: [Advent bug squashing] Fwd: Bug#1025953: marked as done (beast-mcmc: only usable with OpenCL)

Hi Pierre, On 2022-12-17 00:35, Pierre Gruet wrote: Andrius made a bug report for beast-mcmc, thanks to the upstream of beast2-mcmc I could find the origin lay in libhmsbeagle and I just fixed it. Thanks a lot! I can confirm this is indeed fixed. Thus now #1025424 (add autopkgtest for beast-

Re: Seqan2 FTBFS

Hello, On 2022-12-07 10:02, olivier sallou wrote:> Is it really failing ? [1] link only shows failure due to max execution time in CI and job was killed by CI. seqan2 indeed builds (it takes many hours on single CPU on barriere.d.o), but fails most of its tests with the following: a bytes-

Re: Seqan2 FTBFS

Hi, On 2022-12-07 08:42, Andreas Tille wrote: I just wanted to do some polishing changes (watch file + lintian-brush) but I realised seqan2 is failing to build[1]. I wonder whether we need to care for this library and thus need to fix it or whether it is time to remove it from Debian. seqan2

Re: [Advent bug squashing] python-biopython back with tests (#1009118, #1022307)

Hi Étienne, On 2022-12-04 22:21, Étienne Mollier wrote: These ones are the result of team work, with the identification of the issue, report upstream, packages revert, adjustments of wrappers, etc. Closing as the affected tests finally could be restored. This is great news! Thanks a lot for y

Re: dssp

Hi Maarten, On 2022-11-24 14:01, Maarten L. Hekkelman wrote: We're getting closer to finishing all the tools that depend on libcifpp. However, there's one small issue left. I've split dssp into a library and a wrapper. Currently, I create a static library and this is used by the tool tortoize

Re: Help needed with python-cobra and python-pyani

Hello, On 2022-11-24 06:31, Nilesh Patra wrote: python-pyani This is because python3-biopython does not vendor shared object libs for python3.11 yet $ apt-file list python3-biopython | grep '_align' ... python3-biopython:/usr/lib/python3/dist-packages/Bio/Align/_aligners.cpython-310-x86_64-lin

Re: looking for help to finish uploading libcifpp

On 2022-11-13 18:15, Maarten L. Hekkelman wrote: Today I checked in the code for libcifpp 5 in salsa. However, now I need to go through all those procedures to update e.g. the SONAME and I don't remember what the required steps are, nor do I have the time to look them up. I also don't have the

Re: looking for help to finish uploading libcifpp

Hi Maarten, On 2022-11-13 18:15, Maarten L. Hekkelman wrote: Today I checked in the code for libcifpp 5 in salsa. However, now I need to go through all those procedures to update e.g. the SONAME and I don't remember what the required steps are, nor do I have the time to look them up. I also do

Re: Debian Med video conference tomorrow, Wednesday 2022-11-02 18:00 UTC

Hi Pierre, On Tue, 1 Nov 2022, 23:39 Pierre Gruet, wrote: > Help is welcome to tackle these RC bugs in ciftools-java (Java team), > capsule-nextflow, intervalstorej (Java team)... > They are my priority but if they get fixed before I look at them again, > I will be very happy. > I will give cif

Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

Hi Andreas, On 2022-10-27 12:37, Andreas Tille wrote: Am Thu, Oct 27, 2022 at 12:00:59PM +0300 schrieb Andrius Merkys: I have just pushed a fix. Please check if that works for you as well. Hmmm, this results in uscan info: Newest version of libomp-jonathonl on remote site is 0.0

Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)

Hi Andreas, On 2022-10-27 11:31, Andreas Tille wrote: Unfortunately its not just omp but the latest commit from the development branch. Thus I tried gitmode[1] according to the docs: $ cat debian/watch version=4 opts="mode=git,gitmode=full,pgpmode=none,pretty=0.0+git%cd.%h" \ https://git

Re: cmake help for minimac4 needed

Hi Andreas, On 2022-10-27 08:44, Andreas Tille wrote: just another cmake issue I'd like to ask for help here. As you can see in salsa CI[1] the cmake configuration of minimac4 fails with: CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set t

Re: python3-biopython: incompatible with muscle >= 5

Hi Andreas, On 2022-10-13 14:31, Andreas Tille wrote: On Thu, 7 Apr 2022 15:44:43 +0300 Andrius Merkys wrote: python3-biopython is incompatible with muscle >= 5. I tend to think this is serious-ish as biopython integration with muscle from Debian package will not work. Upstream has b

Re: python3-biopython: incompatible with muscle >= 5

Hello, Since the bookworm's freeze is getting closer, I would like to attract team's attention to bug #1009118 in biopython: On Thu, 7 Apr 2022 15:44:43 +0300 Andrius Merkys wrote: python3-biopython is incompatible with muscle >= 5. I tend to think this is serious-ish

Re: pufferfish wants to link with twopaco and ntcard

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, puff

Re: pufferfish wants to link with twopaco and ntcard

Hi Steffen, On 2022-10-04 12:25, Steffen Moeller wrote: Am 04.10.2022 um 09:38 schrieb Andrius Merkys: At this point I do not think much can be done without getting the upstreams of pufferfish, ntcard and twopaco to align their interfaces. In my experience, upstreams are thankful for such

Re: pufferfish wants to link with twopaco and ntcard

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 a

pufferfish wants to link with twopaco and ntcard

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

Re: rdflib: URLInputSource can be abused to retrieve arbitrary documents if used naïvely

Hi Nilesh, On Sun, 31 Jul 2022, 12:12 Nilesh Patra, wrote: > rdflib has been removed from testing along with a bunch of other packages. > And it is triggering -rm-s for packages in testing anyway. > > Upstream is not actively working on the issue as I see from the github > Issue > URL. -- Do you

Re: Added autopkgtest for busco - Closes #1010653

On 2022-06-08 21:54, Andreas Tille wrote: >> Or try finding some other dataset that is free and can be used for testing. > Yes, this would be another option. Hoping for input from busco users > here. I have used busco in my research, but not enough to understand the datasets, alas. Best, Andrius

Re: Added autopkgtest for busco - Closes #1010653

Hi Andreas, On 2022-06-07 12:34, Andreas Tille wrote: > [1] - https://salsa.debian.org/med-team/busco > [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010653 > [3] - https://gitlab.com/ezlab/busco/-/issues/566 Thanks a lot for pushing forward with this. Can you tell me w

Re: Added autopkgtest for busco - Closes #1010653

Hi Andreas, On 2022-06-07 09:57, Andreas Tille wrote: >> On 2022-06-06 22:37, Mohd Bilal wrote: >>> I have added an autopkgtest for busco[1] as mentioned in bug report[2]. >>> The license for the test data needs to be added. I have opened an >>> issue[3] upstream asking for clarification. Requesti

Re: Added autopkgtest for busco - Closes #1010653

Hi Mohd, On 2022-06-06 22:37, Mohd Bilal wrote: > I have added an autopkgtest for busco[1] as mentioned in bug report[2]. > The license for the test data needs to be added. I have opened an > issue[3] upstream asking for clarification. Requesting someone to review > my changes . > > Thanks, > rmb

Re: Advice needed: building new gatk-bwamem-jni against another version of bwa

Hi Pierre, On 2022-03-13 16:35, Pierre Gruet wrote: > My proposal would be to design a multiple upstream tarball for > gatk-bwamem-jni: original one + the sources at the tip of the Apache2 > branch of bwa. It would build a libbwa.a lib which would not be > installed in /usr/lib, but in a private d

Re: Nanolyse autopkgtest broken - could someone provide a proper fastq file?

Hi Andreas, On 2022-02-22 12:16, Andreas Tille wrote: > by chance I realised that the autopkgtest of nanolyse was not > working on the provided dataset. After fixing this[1] the test > breaks unfortunately[2]: > > Traceback (most recent call last): > File "/usr/bin/NanoLyse", line 33, in >

Re: Autodocksuite not available at Sourceforge any more

Hello, On Sun, 20 Feb 2022, 09:40 Andreas Tille, wrote: > I realised that > >https://sourceforge.net/projects/autodocksuite/files/ > > has no files any more. Could you shade some light into what we should > package and what we should rather drop? Does it help to keep the > current autodock

Re: Datasets to design autopkgtests for our packages

Hi Pierre, On 2022-02-18 17:52, Pierre Gruet wrote: > To give a bit of context: I am currently writing autopkgtests for > htsjdk, which is one Java library we maintain in the team. Those > autopkgtests should test reverse-dependencies to ease upgrades of htsjdk. > > When designing such tests, I w

Re: libcifpp transition

Hi Maarten, Sorry for dropping the ball on this. On 2022-02-06 21:16, Maarten L. Hekkelman wrote: > Op 4-2-2022 om 11:43 schreef Maarten L. Hekkelman: >> It took some time and effort, but I managed to get everything fixed >> and building correctly. But tortoize still is marked as partial in the >

Re: libcifpp transition

Hi Maarten, On 2022-02-02 12:44, Maarten L. Hekkelman wrote: > Op 31-01-2022 om 14:49 schreef Andrius Merkys: >> This is purely informational. It says you probably should not attempt >> transitioning libcifpp and libpdb-redo at the same time. > > Hmmm, that didn't w

Re: libcifpp transition

e packages from this new patch (v2.0.4-6) I > can build all the dependencies as well. Great! > Op 24-01-2022 om 12:46 schreef Andrius Merkys: >>>> In file included from src/cif2pdb.cpp:28: >>>> src/cif-tools.hpp:34:10: fatal error: cif++/Config.hpp: No such file o

Re: libcifpp transition

Hi Maarten, On 2022-01-24 12:23, Maarten L. Hekkelman wrote: > Op 16-01-2022 om 09:47 schreef Andrius Merkys: >> libcifpp 2.0.4-1 has just been accepted to experimental (yay!). This >> means now we have to carry out its transition [1] (libcifpp1 -> >> libcifpp2). >

Re: New version of muscle with changed options compared to previous versions [muscle_5.1-1_source.changes ACCEPTED into unstable]

Hi, On 2022-01-17 20:43, Andreas Tille wrote: > Am Mon, Jan 17, 2022 at 05:45:49PM +0200 schrieb Andrius Merkys: >> I consider myself a muscle user, albeit mostly for teaching. Integration >> with biopython is quite important aspect to me as well. >> >> Although sta

Re: New version of muscle with changed options compared to previous versions [muscle_5.1-1_source.changes ACCEPTED into unstable]

Hi, On 2022-01-17 16:55, Andreas Tille wrote: > I've just realised there is a new version of muscle (now on Github) > which has not only a changed algorithm but also changed command line > options (I had to adapt autopkgtest which is also a bit weak - some > educated person should check the result

libcifpp transition

Hi Maarten, libcifpp 2.0.4-1 has just been accepted to experimental (yay!). This means now we have to carry out its transition [1] (libcifpp1 -> libcifpp2). I see you have in the meantime released libcifpp with soversion of 3. Thus instead of doing libcifpp1 -> libcifpp2 we may skip to libcifpp1

Re: Somehow some dh_auto_test of Python3 packages insist to install wheel via pip

On 2021-12-23 12:27, Andreas Tille wrote: > This change > > diff --git a/debian/control b/debian/control > index faadcf3..5f9cfbd 100644 > --- a/debian/control > +++ b/debian/control > @@ -18,7 +18,7 @@ Build-Depends: debhelper-compat (= 12), > python3-pytest-xdist , >

Re: Somehow some dh_auto_test of Python3 packages insist to install wheel via pip

Hi Andreas, On 2021-12-23 12:09, Andreas Tille wrote: > error: Command '['/usr/bin/python3.10', '-m', 'pip', > '--disable-pip-version-check', 'wheel', '--no-deps', '-w', > '/tmp/tmp89sdjpdu', '--quiet', 'xmlschema']' returned non-zero exit status 1. Is Python package providing 'xmlschema' insta

Re: emboss: FTBFS with OpenJDK 17 due to com.sun.net.ssl removal

Hi, On 2021-12-13 19:55, Andreas Tille wrote: > I've just asked for help on bug #982036 but no response so far. I think > it is time to care if we want to keep emboss for the next stable > release. I am very much for retaining emboss, thus I may give it a look. The code using com.sun.net.ssl see

Re: Packaging TechneNotes [Was: Re: Project proposal for the Debian Med group]

Hello, On 2021-12-08 17:15, Andreas Tille wrote: > Am Wed, Dec 08, 2021 at 04:21:30PM +0200 schrieb Andrius Merkys: >> On 2021-11-20 13:48, Guido Rovera wrote: >> You may start from Debian packaging portal [1], but I cannot seem to >> find it presenting the modern tools

Packaging TechneNotes [Was: Re: Project proposal for the Debian Med group]

Dear Guido, On 2021-11-20 13:48, Guido Rovera wrote: > According to the wiki page that you linked, the only "upstream" tasks > that I would need to perform are: > - Create an official tarball > - Add licence details to the repo Yes, these are absolutely necessary requirements for the source packa

Re: Project proposal for the Debian Med group

Dear Guido, On 2021-12-05 09:35, Guido Rovera wrote: > I kindly ask for your feedback on my previous email, when you have time. Thanks for pinging again. I have somehow skipped your previous email. I will reply to it in a couple of days, sorry. Best, Andrius

Re: Project proposal for the Debian Med group

Hi Guido, Debian maintainer for CherryTree here. On 2021-11-17 10:49, Guido Rovera wrote: > Since I haven't heard back from you, I would like to know if there is > anyone interested in the "TechneNotes" project > (https://grovera.gitlab.io/technenotes/ > )

Re: libpdb-redo

Hi Maarten, On 2021-11-08 14:39, Maarten L. Hekkelman wrote: > Yes, the new libcifpp is required. But mainly because I've switched to > cmake entirely for building software, and the cmake file of libpdb-redo > requires the  cmake config files from libcifpp. > > I could build and test the package

Re: libpdb-redo

Hi Maarten, On 2021-11-08 13:59, Maarten L. Hekkelman wrote: > A new version of libpdb-redo is ready for upload to experimental (new > SONAME, new package libpdb-redo2). > > Could someone have a look and upload this, please? Does libpdb-redo require new libcifpp? I could give it a look. I have n

Re: RFH: Getting fastp building on more archs

Hi Nilesh, On 2021-11-05 00:01, Nilesh Patra wrote: > Ondrej was very kind to extend isal support to more archs. However, > it does not build on i386 and s390x, and fastp is still stalled from > migrating. > > Is there $something-else we could do? Do you think simply asking for removals > on i3

Re: libcifpp

Hi Nilesh, On 2021-11-04 12:54, Nilesh Patra wrote: > On Thu, Nov 04, 2021 at 08:25:27AM +0200, Andrius Merkys wrote: >> ... require >> passing through NEW due to libcifpp1 -> libcifpp2. Maarten, is the >> packaging ready to be uploaded? > Gentle reminder: please do

Re: libcifpp

Hi Maarten, On 2021-11-04 11:32, Maarten L. Hekkelman wrote: > Op 04-11-2021 om 07:25 schreef Andrius Merkys: > >> libcifpp has cleared NEW queue a couple of days ago. I see that salsa >> already contains changelog entry for 2.0.4-1 which will again require >> pa

Re: libcifpp

Hi, On 2021-10-13 16:31, Maarten L. Hekkelman wrote: > Yes, libcifpp is still in the queue @ftp-master. But I uploaded a new > package to salsa anyway. This one brings a new upstream version and also > includes the new update mechanism as proposed here. > > Would be nice if anyone with more power

Re: RFH: Getting fastp building on more archs

Hi Nilesh, On 2021-10-16 11:44, Nilesh Patra wrote: > Hi Andrius, the reason is quoted below (reply from zigo on -python) > >> Hi, >> >> Did you look into the source package? isal is written in assembly >> language... On the same thread Graham reported success in building isal on armhf, ppc64el

Re: RFH: Getting fastp building on more archs

Hi Nilesh, On 2021-10-16 08:54, Nilesh Patra wrote: > The new version of fastp B-D on libisal-dev, whick is available only on > amd64, arm64 and kfreebsd-amd64 > Due to this, fastp is no longer able to build on archs it was able to > build on, earlier. > > And as a direct consequence, testing mig

Re: Do users know about README.Debian and /usr/share/doc/packagename (Was: libcifpp)

Hi Pierre, On 2021-10-04 22:18, Pierre Gruet wrote: > Do you know if users read our manpages? I feel we can expect /some/ > users will type > >     man command > > if something is not working as expected, but for sure not all of them will. I have few years of experience in teaching administrati

Re: libcifpp

Hi Maarten, On 2021-09-29 18:03, Maarten L. Hekkelman wrote: > I just committed my changes to salsa, however, this is not building yet. > > Problem is, the current build process tries to download a huge CCD file > (components.cif) and this somehow fails since in the debian package > building envi

Re: libcifpp

On 2021-09-29 17:10, Andreas Tille wrote: > On Wed, Sep 29, 2021 at 04:24:28PM +0300, Andrius Merkys wrote: >> On 2021-09-29 16:19, Maarten L. Hekkelman wrote: >>> I cannot upload anyway, there will be new libs with new SONAMES and thus >>> new binary packages. >

Re: libcifpp

On 2021-09-29 16:19, Maarten L. Hekkelman wrote: > I cannot upload anyway, there will be new libs with new SONAMES and thus > new binary packages. I see. @Andreas: Maybe it is worth to ask ftpmaster to REJECT your upload of 1.0.1-4 in order not to make libcifpp get through NEW two times in a row?

Re: libcifpp

On 2021-09-29 16:15, Nilesh Patra wrote: > On 9/29/21 6:42 PM, Maarten L. Hekkelman wrote: >> Should I wait until the dust settles and libcifpp-data is accepted by the >> might powers before trying to move my changes into salsa? > You can move your changes into salsa if you like, but do not upload

Re: Providing components.cif.gz [Was: Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced]

Hi Maarten, On 2021-09-09 17:54, Maarten L. Hekkelman wrote: > Op 09-09-2021 om 15:14 schreef Andrius Merkys: >>> But I would not mind having a system wide service to update data files >>> like these. Perhaps with a log with version info, so you can look up >>> what

Re: Providing components.cif.gz [Was: Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced]

Hi Maarten, On 2021-09-08 22:50, Maarten L. Hekkelman wrote: > > Op 8-9-2021 om 09:07 schreef Andrius Merkys: >> I am aware of solutions to similar problems, for example, libcifpp >> package, which keeps an up-to-date mmcif_pdbx_v50.dic.gz at >> /var/cache/libcifpp/mmc

Re: Providing components.cif.gz [Was: Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced]

Hi Michael, On 2021-09-08 11:50, Michael Crusoe wrote: > I would advocate for a local copy (if missing) and an environment > variable to override so that users can get a newer/different version. A fallback copy sounds good. Perhaps it would be best to package it in a separate source/binary packag

Providing components.cif.gz [Was: Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced]

Hi all, On 2021-07-19 10:24, Nilesh Patra wrote: > On 19 July 2021 12:50:03 pm IST, Andrius Merkys wrote: >> Currently I am looking into ProMod3 [3], which seems to be the engine >> behind the great SWISS-MODEL service [4]. I seem to have figured out >> the >>

Re: soname question

Hi Maarten & Nilesh, On Fri, 3 Sep 2021, 21:09 Nilesh Patra, wrote: > On 9/3/21 10:45 PM, Maarten L. Hekkelman wrote: > > Tried to use my fresh new powers as a maintainer today. > > Nice, and congrats! > > > That worked well, until I tried to update the SONAME one of my libraries > (libzee> The

Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced

Hi Nilesh, On 2021-07-19 10:24, Nilesh Patra wrote: > On 19 July 2021 12:50:03 pm IST, Andrius Merkys wrote: >> Currently I am looking into ProMod3 [3], which seems to be the engine >> behind the great SWISS-MODEL service [4]. I seem to have figured out >> the >>

Re: DeepMind’s AI Advanced Protein Structure Prediction tool Open Sourced

Hi Steffen, On 2021-07-18 21:47, Steffen Möller wrote: > Following the references in > > https://www.nature.com/articles/d41586-021-01968-y > > I found this reference > > https://github.com/RosettaCommons/RoseTTAFold/tags > > but I admittedly cannot tell that I'd have fully grasped who is doin

Re: mcaller - may be ready

Hi Nilesh, On 2021-06-21 17:10, Nilesh Patra wrote: > On Mon, 21 Jun 2021 at 11:27, Andrius Merkys <mailto:mer...@debian.org>> wrote: > > Hello, > > On 2021-06-21 08:16, Andreas Tille wrote: > >>> Repository data is changed during t

Re: mcaller - may be ready

Hello, On 2021-06-21 08:16, Andreas Tille wrote: >>> Repository data is changed during the tests, which I dislike, but ... >>> well ... we need to get somewhere. >> * And I dislike this as well, so I simply removed the build time test, and >> running that as autopkgtest. IMO doing this is even bet

Re: Autopkgtests for pilercr

Hello, On 2021-06-17 09:42, Shruti Sridhar wrote: > The fasta files that I used are present as their examples.  > It can also be found on their repository here - > (https://github.com/dcouvin/CRISPRCasFinder/blob/master/install_test/sequence.fasta >

Re: What date format for d/u/metadata ? Re: "Entry: NA" in debian/upstream/metadata

Hi Tony, On 2021-03-08 18:51, tony mancill wrote: > Just commenting on the date format part of the thread. Perhaps I am not > representative because I work in the computer field, but I don't find > the RFC 3339 confusing, nor do I think most other Americans would. I > can't recall seeing -DD

Re: Moving packages removed in the archive to /attic?

On 2021-03-10 21:30, Andreas Tille wrote: > On Wed, Mar 10, 2021 at 08:44:36PM +0530, Nilesh Patra wrote: >>> 2. Vcs-* URLs in debian/control will break after moving repositories. >>> Not sure if these URLs are of any use for removed packages, though. > > That's an additional point to my argument

Re: Moving packages removed in the archive to /attic?

Hi, On 2021-03-10 16:48, Robbi Nespu wrote: > On 3/10/21 10:14 PM, Nilesh Patra wrote: >> There are some packages that have been removed from the archive, but >> their repositories still reside on the med-team salsa namespace. >> >> It might be helpful to preserve such repositories in case someone

Re: What date format for d/u/metadata ? Re: "Entry: NA" in debian/upstream/metadata

Hi Steffen, On 2021-03-05 21:19, Steffen Möller wrote: > Am 05.03.21 um 16:13 schrieb Andrius Merkys: >> On 2021-03-04 23:12, Steffen Möller wrote: >>> Somewhere else was the suggestion made to also add a time stamp. This >>> makes perfect sense for the NA/~ and in

Re: "Entry: NA" in debian/upstream/metadata

Hi Steffen, On 2021-03-04 23:12, Steffen Möller wrote: > This reminds me of the early days of my computer science education with > the question if {} and {{}} are the same thing. They are not. My first > idea was that the parser is to blame, but the example at > https://yaml.org/type/null.html mak

Re: "Entry: NA" in debian/upstream/metadata

Hi Charles, On 2021-03-04 07:06, Charles Plessy wrote: > how about YAML's null value for entries for which it was confirmed that > the information does not exist ? This was my initial idea. I do not know much about YAML, but at least Perl YAML implementations see no difference between different w

Re: "Entry: NA" in debian/upstream/metadata

Hi Steffen, On 2021-03-03 19:58, Steffen Möller wrote: > > Am 03.03.21 um 17:39 schrieb Matus Kalas: >> Hey all again, and thanks for your thoughts Andrius and Andreas! >> >> On 2021-03-03 09:36, Andreas Tille wrote: >>> Hi Andrius, >>> >>> O

Re: "Entry: NA" in debian/upstream/metadata

On 2021-03-03 18:39, Matus Kalas wrote: > Hey all again, and thanks for your thoughts Andrius and Andreas! > > On 2021-03-03 09:36, Andreas Tille wrote: >> Hi Andrius, >> >> On 2021-03-03 08:54, Andrius Merkys wrote: >>> Dear Matus, >>> >>> On

Re: "Entry: NA" in debian/upstream/metadata

Hi Andreas, On 2021-03-03 10:36, Andreas Tille wrote: > I wrote the UDD importer for the metadata files and thus look at the > data as a "consumer" of the provided information. From this side those > different meanings of unknown are all turned into "ignore this value". > So in this respect diffe

Re: "Entry: NA" in debian/upstream/metadata

Dear Matus, On 2021-03-02 19:56, Matus Kalas wrote: > I'd suggest hearing from the folks who have done the most of the work > with manually including those IDs, and letting them approve/decide. Absolutely! > I can imagine that for purely practical reasons in the process of the > manual curation,

Re: "Entry: NA" in debian/upstream/metadata

Dear Matus, Thank you for prompt response. On 2021-03-02 13:16, Matus Kalas wrote: > If I understood correctly, the idea behind NA was to mark explicitly > that the tool has been searched in those registries and not found. > Perhaps N/A would be an even more obvious string, and definitely not > c

"Entry: NA" in debian/upstream/metadata

Hello, As announced earlier [1], I am working on the validation of debian/upstream/metadata files (a.k.a. DEP 12) we ship with Debian packages. Recently I have noticed that many packages (~400 of ~1300 debian-med packages as of 2021-02-11) have registry entries with "NA" for names, for example [2]

Re: Validating debian/upstream/metadata for debian-med projects

Hi Étienne, On 2021-02-11 20:04, Étienne Mollier wrote: > Thanks from me as well! I landed in the industrial world before > having a chance to start a PhD thesis; publication nomenclatures > are kind of foreign to me. I really welcome automated tools to > point me to my mistakes in that matter.

Re: Validating debian/upstream/metadata for debian-med projects

Hi Andreas, Nilesh & Steffen, Thanks a lot for your feedback! I completely agree with Andreas about the assignment lintian message levels (error/warning etc) for issue categories 1-3. On 2021-02-11 15:52, Andreas Tille wrote: > On Thu, Feb 11, 2021 at 03:16:51PM +0200, Andrius Merkys wro

Validating debian/upstream/metadata for debian-med projects

Hello, Recent thread on debian-science@ [1] motivated me to look deeper into enforcing quality standards of debian/upstream/metadata files (a.k.a. DEP 12) we ship with Debian packages. I learnt that lintian already runs YAML syntax check on debian/upstream/metadata files, but further validation is

Re: Workflow for releasing new upstream versions to experimental?

On 2021-02-09 19:43, Michael Crusoe wrote: > I strongly prefer a separate branch for experimental, to avoid commit > reverts and the like. +1 Best, Andrius

Re: Quick shot at bio-vcf but it needs more Ruby knowledge than I have (actually zero)

Hi Andreas, On 2021-01-28 16:24, Andreas Tille wrote: > So obviously the VERSION file is searched and needs to be put on some > sensible place (and the code needs to be patched according to that place > possibly). I have pushed commit cd918a04ea4acffcea61e7fb9e23a465b5e0ab59 dealing with this iss

Re: libcifpp, libpdb-redo, density-fitness

Hi Maarten, On 2021-01-05 14:22, Maarten L. Hekkelman wrote: > Op 05-01-2021 om 12:15 schreef Andrius Merkys: >>> And ppc64el is still failing in libclipper/libccp4 reading MTZ files. >> AFAIU, this is fixed by your patch in #979314 (many thanks!). > Correct. > > A

Re: libcifpp, libpdb-redo, density-fitness

Hi Maarten, On 2021-01-04 12:14, Maarten L. Hekkelman wrote: > I noticed that libpdb-redo still fails to build on i386 and ppc64el. > > The reason for i386 is that the tolerance for floating comparison in the > test code is too strict (i386 being 32bit has a different double outcome > for some ca

Re: libcifpp, libpdb-redo, density-fitness

On 2021-01-04 09:57, Maarten L. Hekkelman wrote: > Just started the new year by applying a couple of contributed patches. > Could someone please upload the changes I committed to the packages > libcifpp, libpdb-redo and density-fitness? Done! Best, Andrius

Re: libcifpp, libpdb-redo, density-fitness

Hi Maarten, On 2021-01-04 09:57, Maarten L. Hekkelman wrote: > Just started the new year by applying a couple of contributed patches. > Could someone please upload the changes I committed to the packages > libcifpp, libpdb-redo and density-fitness? I'm on it. Best, Andrius

Re: Should we standardize a way to create and maintain manpages?

On 2020-12-23 11:28, Andreas Tille wrote: > This would possibly offer a new way to create our manpages: > > Fetch > > .SH NAME > > from short description and simply add a hint how to call the help > screen of the program in question. We "simply" need to find out > what option will show some h

  1   2   >