Re: Help to finalise libjloda-java needed

[Andreas Tille]

Hi Pierre,

On Wed, Nov 18, 2020 at 05:58:32PM +0100, Pierre Gruet wrote:
> Good news: this is now fixed!
> I have explicitly listed the necessary jars and added two missing
> dependencies. Now the package builds. My changes have been pushed to Salsa.

Cool.  Thanks a lot, just uploaded.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Re: [RFS] mssstest

[Andreas Tille]

Hi Nilesh,

I confirm the website is throwing 404. :-(

You might like to contact upstream - here is the last contact

   https://lists.debian.org/debian-med/2016/01/msg00084.html

May be if its not online even more the interest in keeping it
non-free is even less?

Kind regards

  Andreas.

On Wed, Nov 18, 2020 at 06:51:19PM +0530, Nilesh Patra wrote:
> On Wed, 18 Nov 2020 at 18:35, Andreas Tille  wrote:
> 
> > On Wed, Nov 18, 2020 at 06:05:36PM +0530, Nilesh Patra wrote:
> > > dcut dm --uid npatra...@gmail.com --allow  mssstest
> >
> > BTW, when uploading such non-free software we should probably
> > re-ping upstream for a free license.
> >
> 
> Argh, I did not notice this is non-free and I added autopkgtests :/
> 
> The upstream homepage as given in d/control gives a 404 and the d/watch
> file points to a fake upstream (https://people.debian.org/~eriberto/
> FakeWatchNoUpstreamReleaseForThisPackage-(\d\S+)\.gz)
> 
> Any idea where the code for mssstest might live? I'll mail the maintainer
> as mentioned in d/copyright if nothing works out
> 
> Kind regards
> Nilesh

-- 
http://fam-tille.de

Re: [RFS] libcifpp

[Maarten L. Hekkelman]

The package in salsa is now updated to include all suggested changes, 
including a debconf to ask for permission to enable the cron task.


regards, -maarten

Op 17-11-2020 om 20:25 schreef Maarten L. Hekkelman:

Just pushed libcifpp into salsa.

Libcifpp is a library to read, write and manipulate files containing 
macro molecular structure info. It works internally with mmCIF 
structures but can read and write PDB files as well.


This is a first step, a couple of other tools bases on libcifpp will 
follow shortly.


Perhaps a review is needed, esp. the automatic download of 
mmcif_pdbx_v50.dic files. As discussed on this list, I put those in 
/var/cache/libcifpp.


regards, -maarten

--
Maarten L. Hekkelman
http://www.hekkelman.com/


--
Maarten L. Hekkelman
http://www.hekkelman.com/

Re: Help to finalise libjloda-java needed

[Pierre Gruet]

Hi again,

Le 18/11/2020 à 15:59, Pierre Gruet a écrit :
> Hi Andreas,
> 
> 
> Le 18/11/2020 à 11:09, Andreas Tille a écrit :
>> Hi Pierre (and others)
>>
>> I tried to update libjloda-java but the build fails with
>>
>> ...
>> compile:
>> [javac] Compiling 360 source files to 
>> /build/libjloda-java-2.0/antbuild/modules/jloda
>> [javac] error: the unnamed module reads package org.xml.sax.helpers from 
>> both java.xml and xml.apis
>> [javac] error: the unnamed module reads package org.xml.sax.ext from 
>> both java.xml and xml.apis
>> [javac] error: the unnamed module reads package org.xml.sax from both 
>> java.xml and xml.apis
>> ...
>> [javac] error: the unnamed module reads package 
>> org.apache.batik.ext.awt.g2d from both batik.awt.util and batik.all
>> [javac] error: the unnamed module reads package 
>> org.apache.batik.ext.awt.font from both batik.awt.util and batik.all
>> [javac] error: the unnamed module reads package 
>> org.apache.batik.ext.awt.color from both batik.awt.util and batik.all
>> [javac] 100 errors
>>
>> BUILD FAILED
>> /build/libjloda-java-2.0/antbuild/build.xml:59: Compile failed; see the 
>> compiler error output for details.
>>
>> Total time: 1 second
>> make[1]: *** [debian/rules:15: override_dh_auto_build] Fehler 1
>>
>>
>> I guess its a simple CLASSPATH issue which is easy to fix for someone
>> with more experience than I have.
>>
> 
> Yes, this is caused by the fact that several jars provide the same package.
> I'm not very used to modules with Java, but I think that, based on what
> you pasted and the contents of the package, there are two sources of
> problems:
> - the jars in the directory jars/ of the source package (which we should
> remove) : for instance one of the jars therein provides xml.apis;
> - the line
>   
> in the patched antbuild/build.xml , where ${jfxdir} is /usr/share/java,
> causes all installed jars in /usr/share/java to be searched for
> modules... and libbatik-java ships a lot of subjars and one super-jar
> (batik-all.jar) which gathers them all. This is the reason for the
> errors involving batik on the last lines you pasted.
> 
> I can give it a try and keep you informed!

Good news: this is now fixed!
I have explicitly listed the necessary jars and added two missing
dependencies. Now the package builds. My changes have been pushed to Salsa.

> 
>>
>> Kind regards
>>
>>   Andreas.
>>

Best,
Pierre

Re: Help to finalise libjloda-java needed

[Pierre Gruet]

Hi Andreas,


Le 18/11/2020 à 11:09, Andreas Tille a écrit :
> Hi Pierre (and others)
> 
> I tried to update libjloda-java but the build fails with
> 
> ...
> compile:
> [javac] Compiling 360 source files to 
> /build/libjloda-java-2.0/antbuild/modules/jloda
> [javac] error: the unnamed module reads package org.xml.sax.helpers from 
> both java.xml and xml.apis
> [javac] error: the unnamed module reads package org.xml.sax.ext from both 
> java.xml and xml.apis
> [javac] error: the unnamed module reads package org.xml.sax from both 
> java.xml and xml.apis
> ...
> [javac] error: the unnamed module reads package 
> org.apache.batik.ext.awt.g2d from both batik.awt.util and batik.all
> [javac] error: the unnamed module reads package 
> org.apache.batik.ext.awt.font from both batik.awt.util and batik.all
> [javac] error: the unnamed module reads package 
> org.apache.batik.ext.awt.color from both batik.awt.util and batik.all
> [javac] 100 errors
> 
> BUILD FAILED
> /build/libjloda-java-2.0/antbuild/build.xml:59: Compile failed; see the 
> compiler error output for details.
> 
> Total time: 1 second
> make[1]: *** [debian/rules:15: override_dh_auto_build] Fehler 1
> 
> 
> I guess its a simple CLASSPATH issue which is easy to fix for someone
> with more experience than I have.
>

Yes, this is caused by the fact that several jars provide the same package.
I'm not very used to modules with Java, but I think that, based on what
you pasted and the contents of the package, there are two sources of
problems:
- the jars in the directory jars/ of the source package (which we should
remove) : for instance one of the jars therein provides xml.apis;
- the line

in the patched antbuild/build.xml , where ${jfxdir} is /usr/share/java,
causes all installed jars in /usr/share/java to be searched for
modules... and libbatik-java ships a lot of subjars and one super-jar
(batik-all.jar) which gathers them all. This is the reason for the
errors involving batik on the last lines you pasted.

I can give it a try and keep you informed!

> 
> Kind regards
> 
>   Andreas.
> 

Best regards,
Pierre

Re: [RFS] mssstest

[Nilesh Patra]

On Wed, 18 Nov 2020 at 18:35, Andreas Tille  wrote:

> On Wed, Nov 18, 2020 at 06:05:36PM +0530, Nilesh Patra wrote:
> > dcut dm --uid npatra...@gmail.com --allow  mssstest
>
> BTW, when uploading such non-free software we should probably
> re-ping upstream for a free license.
>

Argh, I did not notice this is non-free and I added autopkgtests :/

The upstream homepage as given in d/control gives a 404 and the d/watch
file points to a fake upstream (https://people.debian.org/~eriberto/
FakeWatchNoUpstreamReleaseForThisPackage-(\d\S+)\.gz)

Any idea where the code for mssstest might live? I'll mail the maintainer
as mentioned in d/copyright if nothing works out

Kind regards
Nilesh

Re: [RFS] mssstest

[Andreas Tille]

On Wed, Nov 18, 2020 at 06:05:36PM +0530, Nilesh Patra wrote:
> dcut dm --uid npatra...@gmail.com --allow  mssstest

BTW, when uploading such non-free software we should probably
re-ping upstream for a free license.

Kind regards

 Andreas.

-- 
http://fam-tille.de

done Re: [RFS] mssstest

[Steffen Möller]

Thanks!

On 18.11.20 13:35, Nilesh Patra wrote:
> dcut dm --uid npatra...@gmail.com 
> --allow  mssstest

[RFS] mssstest

[Nilesh Patra]

dcut dm --uid npatra...@gmail.com --allow  mssstest

Re: PDBx dictionary in Debian [Was: Re: Bug#974973: ITP: libcifpp -- A library for creating and manipulating mmCIF and PDB files containing macro molecular structure information]

[Maarten L. Hekkelman]

Op 17-11-2020 om 22:49 schreef Aaron M. Ucko:

I've read the specs for /var/ in the Debian Policy. That's why I came
up with /var/cache, it seems to match my requirements exactly.

Sure, but nothing (besides dpkg) is supposed to modify files packages
ship.  (Configuration files under /etc are a special case.)  Best
practice would probably be to ship an empty directory under /var/cache,
ship the stock dictionary in /usr/lib/libcifpp or /usr/share/libcifpp as
appropriate (depending on whether it varies by architecture), and have
your postinst script copy the stock dictionary into the /var/cache
directory as needed.

OK, I'll do that.

Also, please ensure that your cron job requires explicit opt-in.
Good point. But that means adding a /etc/defaults/libcifpp file 
containing a flag whether the update script is allowed to run and some 
script to enable dpkg-reconfigure?


regards, -maarten

Re: Project idea: port GKL to non-x86

[Steffen Möller]

On 18.11.20 10:35, Michael R. Crusoe wrote:
>
>
> On Wed, 18 Nov 2020 at 10:32, Andreas Tille  > wrote:
>
> Hi Michael,
>
> On Wed, Nov 18, 2020 at 12:00:29AM +0100, Michael Crusoe wrote:
> > With https://salsa.debian.org/java-team/gkl/-/merge_requests/3
>  I am
> able to
> > build a GKL package that runs on non-amd64 (though probably at a
> huge speed
> > sacrifice)
> >
> > Using the resulting libgkl-java package and
> >
> 
> https://salsa.debian.org/med-team/picard-tools/-/commit/a6e95fb137e4293491b84e04b780bd6ebd5cfe34
> 
> 
> > I am able to build and run Picards tools on arm64
>
> Cool.  Should I upload gkl (after some routine-update)?
>
>
> Already done :-)
>  
>
> I also wonder why that package is in java-team if only Debian Med
> members are working on it and its relevant for Debian Med.
>
>
> I don't know!

The idea typically is that if there is something happening on the Java
front with many reverse dependencies then this can be dealt with. For
some packages there should be dual-memberships.

Best,

Steffen

Help to finalise libjloda-java needed

[Andreas Tille]

Hi Pierre (and others)

I tried to update libjloda-java but the build fails with

...
compile:
[javac] Compiling 360 source files to 
/build/libjloda-java-2.0/antbuild/modules/jloda
[javac] error: the unnamed module reads package org.xml.sax.helpers from 
both java.xml and xml.apis
[javac] error: the unnamed module reads package org.xml.sax.ext from both 
java.xml and xml.apis
[javac] error: the unnamed module reads package org.xml.sax from both 
java.xml and xml.apis
...
[javac] error: the unnamed module reads package 
org.apache.batik.ext.awt.g2d from both batik.awt.util and batik.all
[javac] error: the unnamed module reads package 
org.apache.batik.ext.awt.font from both batik.awt.util and batik.all
[javac] error: the unnamed module reads package 
org.apache.batik.ext.awt.color from both batik.awt.util and batik.all
[javac] 100 errors

BUILD FAILED
/build/libjloda-java-2.0/antbuild/build.xml:59: Compile failed; see the 
compiler error output for details.

Total time: 1 second
make[1]: *** [debian/rules:15: override_dh_auto_build] Fehler 1


I guess its a simple CLASSPATH issue which is easy to fix for someone
with more experience than I have.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: libmaus2 update attempt 2.0.766

[Andreas Tille]

Hi Étienne,

On Wed, Nov 18, 2020 at 10:31:38AM +0100, Étienne Mollier wrote:
> Good day,
> 
> I think my changes are ready for upload of libmaus2 2.0.766.

I took the freedom to grant you upload permissions for libmaus2
and biobambam2.

Please let me know if you want an additional review.

Thanks a lot for your work on this

Andreas.

> The main change, in addition to the new upstream version, is the
> support for libsecrecy encrypted files; I almost forgot to add
> it before upload, since German added a check for libsecrecy
> support in configure.ac.  :)
> 
> Changes are available on Salsa:
> 
> Étienne Mollier, on 2020-11-12 23:12:00 +0100:
> > Andreas Tille, on 2020-11-12 18:35:28 +0100:
> > > On Thu, Nov 12, 2020 at 05:45:44PM +0100, Étienne Mollier wrote:
> > > > 
> > > > https://salsa.debian.org/med-team/libmaus2
> > > > 
> > > > I'm still running additionnal builds to catch eventual
> > > > regressions on arm64 and ppc64el, just in case.
> > > 
> > > Very cool.  Please let us know the result.
> 
> No changes in the build and test results on my end:
> 
> > The build and build-time tests targeting arm64 went quite well.
> > The build went well on ppc64el, but build-time test crashed on
> > testdnarank.sh and testRank.sh at the same steps as riscv64[1],
> > itanium[2] and mips64el[3] (that is, "testing CacheLineRank" and
> > "running short tests", respectively).
> > 
> > [1] 
> > https://buildd.debian.org/status/fetch.php?pkg=libmaus2=riscv64=2.0.743%2Bdfsg-1=1598631353=0
> > [2] 
> > https://buildd.debian.org/status/fetch.php?pkg=libmaus2=ia64=2.0.743%2Bdfsg-1=1598627935=0
> > [3] 
> > https://buildd.debian.org/status/fetch.php?pkg=libmaus2=mips64el=2.0.743%2Bdfsg-1=1598625102=0
> > 
> > There is one difference though, the test now crashes with a
> > segmentation fault, instead of a full report with a backtrace:
> > 
> > [V] testing CacheLineRank:
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > ./testRank.sh: line 7: 474960 Segmentation fault  ../src/testRank
> > Exiting with return code 139
> > FAIL testRank.sh (exit status: 139)
> > [...]
> > [V] running short tests...
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > ./testdnarank.sh: line 7: 474972 Segmentation fault  
> > ../src/testdnarank
> > Exiting with return code 139
> > FAIL testdnarank.sh (exit status: 139)
> > 
> > At least, the build on i386 went through, so there are chances
> > #934619 can be addressed with a new update at least.  I started
> > an armhf build just to see...
> 
> I have not closed #934619.  Build works on i386, but armhf still
> fails on my end, and Helmut was mentioning explicitely armhf.
> 
> Please review, and upload or grand upload permissions.
> 
> Kind Regards,
> -- 
> Étienne Mollier 
> Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
> Sent from /dev/pts/4, please excuse my verbosity.



-- 
http://fam-tille.de

Re: Project idea: port GKL to non-x86

[Michael R. Crusoe]

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

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

Already done :-)


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

I don't know!


-- 
Michael R. Crusoe

Re: Project idea: port GKL to non-x86

[Andreas Tille]

Hi Michael,

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

Cool.  Should I upload gkl (after some routine-update)?
I also wonder why that package is in java-team if only Debian Med
members are working on it and its relevant for Debian Med.

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: libmaus2 update attempt 2.0.766

[Étienne Mollier]

Good day,

I think my changes are ready for upload of libmaus2 2.0.766.
The main change, in addition to the new upstream version, is the
support for libsecrecy encrypted files; I almost forgot to add
it before upload, since German added a check for libsecrecy
support in configure.ac.  :)

Changes are available on Salsa:

Étienne Mollier, on 2020-11-12 23:12:00 +0100:
> Andreas Tille, on 2020-11-12 18:35:28 +0100:
> > On Thu, Nov 12, 2020 at 05:45:44PM +0100, Étienne Mollier wrote:
> > > 
> > >   https://salsa.debian.org/med-team/libmaus2
> > > 
> > > I'm still running additionnal builds to catch eventual
> > > regressions on arm64 and ppc64el, just in case.
> > 
> > Very cool.  Please let us know the result.

No changes in the build and test results on my end:

> The build and build-time tests targeting arm64 went quite well.
> The build went well on ppc64el, but build-time test crashed on
> testdnarank.sh and testRank.sh at the same steps as riscv64[1],
> itanium[2] and mips64el[3] (that is, "testing CacheLineRank" and
> "running short tests", respectively).
> 
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libmaus2=riscv64=2.0.743%2Bdfsg-1=1598631353=0
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=libmaus2=ia64=2.0.743%2Bdfsg-1=1598627935=0
> [3] 
> https://buildd.debian.org/status/fetch.php?pkg=libmaus2=mips64el=2.0.743%2Bdfsg-1=1598625102=0
> 
> There is one difference though, the test now crashes with a
> segmentation fault, instead of a full report with a backtrace:
> 
>   [V] testing CacheLineRank:
>   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>   ./testRank.sh: line 7: 474960 Segmentation fault  ../src/testRank
>   Exiting with return code 139
>   FAIL testRank.sh (exit status: 139)
>   [...]
>   [V] running short tests...
>   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>   ./testdnarank.sh: line 7: 474972 Segmentation fault  
> ../src/testdnarank
>   Exiting with return code 139
>   FAIL testdnarank.sh (exit status: 139)
> 
> At least, the build on i386 went through, so there are chances
> #934619 can be addressed with a new update at least.  I started
> an armhf build just to see...

I have not closed #934619.  Build works on i386, but armhf still
fails on my end, and Helmut was mentioning explicitely armhf.

Please review, and upload or grand upload permissions.

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.


signature.asc
Description: PGP signature