Re: Your packaging of sumaclust today
Hi Andreas, hi everyone, Le 02/04/2020 à 08:43, Andreas Tille a écrit : > Hi Pierre, > > sorry for violating netiquette but we have an open culture in Debian Med > team and private discussion should only happen for really private > things. So I'm quoting you in public on the Debian Med mailing list and > would be really happy if you would answer there. No problem about that, thanks for letting me know. Please believe I did not intend to hide things, but only to reduce noise. Next time I shall use the mailing list. > > On Wed, Apr 01, 2020 at 10:30:42PM +0200, Pierre Gruet wrote: >> Hi Andreas, >> >> I have seen you did an upload on the package sumaclust today; I am >> writing to let you know that I got in touch with its upstream yesterday >> with a patch proposal, and the developer has released a new version >> (1.0.35) fixing the Serious bug #952093 that you closed with the upload >> of 1.0.34-2. > Actually that bug was pretty easy by setting a simple -I option in > Makefile. I admit I wonder why that has build before at all. Seems > upstream has found a different fix since my patch did not created any > conflict when importing and building the new upstream version. I do not understand how that built before. We discussed this with upstream yesterday. > >> If you want, I would be happy to package it in Debian Med Team (but I >> would need a sponsor). If you prefer doing it yourself, please just do. > I admit for *every* package in the Debian Med team I love to be only > sponsor instead of doing most of the work. So every reader is kindly > invited to pick packages, fix bugs, write tests - whatever. I'm by > no means proud upon having my name inside the majority of packages as > Uploader. So in this case: Yes, you are kindly invited to join me > in maintaining sumaclust - and may be also sumatra and sumalibs (just > uploaded to new). > > For the actual 1.0.35 upload I simply used the very quick solution and > fired up routine-update[1] and just uploaded the result which took me > less than a minute work. So its not that I really want to do this but > that *currently* I considered it way more straightforward than asking > you to do it. If you would volunteer to work on this I'd be really > happy if you > >1. Would create a salsa.d.o login >2. Join the Debian Med team >3. Read Debian Med team policy[2] in case you might not be > comfortable with usual workflows in team similar to >4. Add yourself as Uploader to all packages you would > volunteer to package >5. Review my work! (Well, I have some routine but it might > be wrong. May be there is a better fix in sumaclust than > tweaking the Makefile in a quilt patch.) >6. Review sumalibs packaging - we could definitely use also > a dynamic library since we should avoid code duplication > in sumaclust and sumatra >7. Enjoy beeing member of the Debian Med team > > Thanks again for your attempt to help Thanks for that detailed proposal. Yes, I would like to join the team and asked for it in Salsa. If I may add something: having read the policy some days ago, I feel it lacks a kind of ``general habits'' section, like what you explained above: is it casual/rude to begin working on a package that already has uploaders who uploaded recently without asking them, for instance? The general Debian documentation would strongly advise against doing so, but what about team work? You answered this concerning Debian Med Project. Of course this is not a critics to anyone, just a newcomer's feeling. > > Andreas. > > > [1] https://salsa.debian.org/science-team/routine-update > [2] https://med-team.pages.debian.net/policy/ > Have a great day, Pierre
Re: Your packaging of sumaclust today
Hi again, Le 02/04/2020 à 10:28, Andreas Tille a écrit : > >> If I may add something: having read the policy some days ago, I feel it >> lacks a kind of ``general habits'' section, like what you explained >> above: is it casual/rude to begin working on a package that already has >> uploaders who uploaded recently without asking them, for instance? The >> general Debian documentation would strongly advise against doing so, but >> what about team work? > A, really nice hint. Yes, we should mention this explicitly! > >> You answered this concerning Debian Med Project. >> Of course this is not a critics to anyone, just a newcomer's feeling. > I'm personally even open for critics. That's fine. And here you have a > really valid point. It would be s cool if I would simply put this > in policy and would get rid of all my Uploaders duties in the next > month. ;-) This might help, but maybe only for newcomers ;-) >> Have a great day, > Same to you > > Andreas. > Thanks for being so welcoming, I really appreciate! Best, Pierre
Re: Your packaging of sumaclust today
Hi Andreas, Le 03/04/2020 à 22:26, Andreas Tille a écrit : > > I tried with a new paragraph at the beginning of "How to Contribute". > Feel free to enhance that text! I think this paragraph clarifies things a lot. Having explained rules this way, there should be less hesitations. > > BTW, just one final note: The mailing list polic in Debian is that the > original poster is not CCed since it is expected that a poster has > subscribed the list (despite this is not required). Thus I'm stoping to > CC you from now on and I recommend you do so as well. Sometimes on > other list you might get a bit unfriendly replies if you do not respect > this. Acknowledged, thanks! > > Thanks a lot for your contribution > > Andreas. > Have a nice day, Pierre
RFS: sumaclust with autopkgtest
Hi, I have worked on sumaclust and pushed it on salsa [0] with version ``unreleased''. Lines have been suppressed in the last patch because upstream has made the necessary changes so that sumaclust builds. I have also provided autopkgtests, which check the executable works fine in a few simple cases. They all pass in a schroot. If time permits, could anyone please review it? Thanks a lot and have a great day, Pierre [0] https://salsa.debian.org/med-team/sumaclust
Re: RFS: sumaclust with autopkgtest
Hi again, Le 04/04/2020 à 10:14, Andreas Tille a écrit : > > I try to put high priority on newcomer contributions so I just take > my time for a review. I can confirm that the tests are passing and > thus we could upload the package as is. Thanks a lot for the quick review! > There is some additional feature we try to approach in Debian Med: > [...] I wonder whether you could just write a > run-unit-test as a wrapper for your four single scripts and install > these all into /usr/share/doc/sumaclust/examples (together with > README.test). IMHO this increases the value of the scripts for the end > user if it can be executed right on the local machine. > I agree this is valuable to the user. I have written run-unit-test, using the one of package-template, and designed a debian/sumaclust.examples file to install it in /usr/share/doc/sumaclust/examples together with the four scripts and the README.test file. The wrapper script echoes one line per test, with its name and ``PASSED'' or ``FAILED''. I tested it on my computer after installation. I have not touched debian/tests/control, which still calls the four scripts instead of the wrapper run-unit-test. If you think it would be better to only call the wrapper, please tell me. All the best, Pierre
Re: sumatra uploaded using Debian packaged sumalibs
Hi Andreas, Le 09/04/2020 à 14:45, Andreas Tille a écrit : > Hi Pierre, > > as you might have noticed the Debian package for sumalibs was just > accepted. I've now built sumatra against this lib. I'd happily leave > the maintenance of all suma* packages to you. Yes, I noticed that sumalibs was accepted; I will happily take over the maintenance effort for those three packages! > I think an open todo > item would be to remove the sumalibs code copy from sumaclust and > build both, sumaclust and sumatry, against the same lib. > > Let me know what you think. I remember you evoked it a few days ago, and I have thought about it since then. I am now looking at the changes you did today on sumalibs and sumatra. My question is: as I understand /4.13 Embedded code copies/ in the Debian policy, sumatra and sumaclust should use the libs in sumalibs to build, but the code of those libs that is duplicated inside sumaclust should remain there (and not be used), right? Furthermore, currently sumalibs provides a static library built by upstream's Makefiles, should we try to move to a shared library or should we instead not differ from upstream on that? > Kind regards > >Andreas. > Best regards, Pierre
Re: sumatra uploaded using Debian packaged sumalibs
Hi Andreas, Le 09/04/2020 à 23:01, Andreas Tille a écrit : >> >> My question is: as I understand /4.13 Embedded code copies/ in the Debian >> policy, sumatra and sumaclust should use the libs in sumalibs to build, but >> the code of those libs that is duplicated inside sumaclust should remain >> there (and not be used), right? > > Well, I prefer to remove what is not used - just to make sure its really > not used. The suma* packages are also inconsistent from upstream side: > sumaclust included sumalibs but sumatra does not include it. May be > this issue can be tackled from upstream to exlude it consistently? > I have been getting in touch with upstream, who wish to postpone this task until they have more time to care for it. After we exchanged emails, they have published new versions of sumalibs, sumatra and sumaclust with my patch proposal for a regression I observed last week, but they reintegrated the sumalibs directory in sumaclust and sumatra: now sumalibs is present three times in their repositories. When I packaged them, I removed the directory from sumaclust and sumatra, adding ``+ds'' to the upstream version number. > >> Furthermore, currently sumalibs provides a static library built by >> upstream's Makefiles, should we try to move to a shared library or should we >> instead not differ from upstream on that? > > Debian usually provides shared *and* static lib. This can be easily > approached by a more modern build system than plain Makefile (automake - > not really modern but anyway, cmake, meson, ...) I once had added > automake to some lib to approach this: > > > https://salsa.debian.org/med-team/libsmithwaterman/-/blob/master/debian/patches/autoconf.patch > > Its not that I personally love autoconf - I just found an example of it > and in all the years of Debian I gathered the most experience with this. > This should be no advise to use autoconf here. > I have used CMake to package sumalibs in the way you did with libsmithwaterman. I have split it into libsuma1 which holds the shared library, and libsuma-dev which holds the static library and the symlink to the shared one. Besides: * I have used .install files for the libs in sumalibs, and put a .symbols file for libsuma1; * I have added a test, which builds and runs a simple program, for libsuma-dev, and provided it for autopkgtest and as an example; * sumaclust and sumatra now rely on libsuma1; * sumatra now has tests, written for autopkgtest and provided as examples. If you have time, I would appreciate a review of the three packages, which are in their three Salsa repositories. https://salsa.debian.org/med-team/sumaclust/ https://salsa.debian.org/med-team/sumatra https://salsa.debian.org/med-team/sumalibs > > Kind regards > > Andreas. > Thanks and have a nice evening, Pierre
[RFS] Bug fixed in uc-echo
Dear all, I have prepared an upload for the package uc-echo, of which autopkgtest was failing on arm64 due to a (by default unsigned) char type being used to store negative integer values. I will forward this fix to upstream. The package is in its Salsa repository [1]. Thanks in advance for the review when time permits, Best regards, Pierre [1] https://salsa.debian.org/med-team/uc-echo
Re: [RFS] Bug fixed in uc-echo
Hi Nilesh and Andreas, Le 17/04/2020 à 19:21, Nilesh Patra a écrit : > > > On Fri, 17 Apr 2020, 22:44 Pierre Gruet, <mailto:pgtdeb...@free.fr>> wrote: > > Dear all, > > I have prepared an upload for the package uc-echo, of which autopkgtest > was > failing on arm64 due to a (by default unsigned) char type being used to > store negative integer values. > I will forward this fix to upstream. > > The package is in its Salsa repository [1]. > > > Thank you so much for fixing this! :D (This was lying on my desk for quite > sometime by now) > > Hoping this gets uploaded soon. > Thanks Nilesh for the feedback! Thanks Andreas for the upload of this package, and also for the other ones you did for me recently. All the best, Pierre
Re: sumatra uploaded using Debian packaged sumalibs
Hi Andreas, Le 14/04/2020 à 18:53, Andreas Tille a écrit : >> >> If you have time, I would appreciate a review of the three packages, which >> are in their three Salsa repositories. >> >> https://salsa.debian.org/med-team/sumaclust/ >> https://salsa.debian.org/med-team/sumatra >> https://salsa.debian.org/med-team/sumalibs > > This all sounds pretty sensible. I've uploaded sumalibs to new since > the additional binary is requiring that detour. Once it has hit > unstable I'll upload the two dependencies. > > Thanks again for this very sensible work Thanks! I have just seen that sumalibs has successfully entered unstable and that the automatic piuparts warnings have disappeared from its tracker.debian.org page: everything seems to be fine concerning that new package. Could you please upload sumatra and sumaclust (waiting in their Salsa repositories) when time permits? > > Andreas. > Kind regards, Pierre
Re: sumatra uploaded using Debian packaged sumalibs
Hi Andreas, Le 20/04/2020 à 13:00, Andreas Tille a écrit : > Hi Pierre, > > On Mon, Apr 20, 2020 at 11:29:04AM +0200, Pierre Gruet wrote: >> I have just seen that sumalibs has successfully entered unstable and that >> the automatic piuparts warnings have disappeared from its tracker.debian.org >> page: everything seems to be fine concerning that new package. >> >> Could you please upload sumatra and sumaclust (waiting in their Salsa >> repositories) when time permits? > > Done. Thank you for the preparation. I've added some mor Files-Excluded > to have a more clean tarball for next version. > Thanks for the upload and for appending this list of files in debian/copyright for next version! I will consider doing so in similar cases. > > Kind regards > > Andreas. > Have a nice afternoon, Pierre
RFS : new upstream version of jebl2
Hi, I have packaged the new upstream version of jebl2 and made various changes. Now the packaging is in Salsa [1], could someone please check and upload it when time permits? The changes are * New upstream version 0.1+git20190308 * Deleting now useless patch source_8.patch * Bumping Standard version to 4.5.0 (adding Rules-Requires-Root field) * Marking the binary packages Multi-Arch: foreign * Using secure URL in debian/copyright * Dropping debian/compat file, using debhelper-compat * Trimming trailing whitespaces * Adding salsa-ci.yml file * Correcting path in debian/libjebl2-java-doc.javadoc * Adding and documenting lintian overrides. Thanks a lot in advance, Best, Pierre [1] https://salsa.debian.org/med-team/jebl2
Re: RFS : new upstream version of jebl2
Hi Andreas, Le 24/04/2020 à 22:34, Andreas Tille a écrit : > Hi Pierre, > > thanks a lot for your work. I usually would leave the commit ID inside > the version number (so 0.1+git20190308.a98448e) since this would silence > the new upstream available check - but I guess you thought about this > and left it as is when uploaded. > Thanks for the review and the upload. I must admit I had not thought about the new upstream message that would remain... I only considered keeping the meaningful, ``understandable'' part of the version number. I will consider this choice next time. > > Work on Java packages is extremely welcome since we have an unfortunate > lack of Java knowledge in the team. If you need some inspiration what > task to tackle next - I'm happy to hand over other Java tasks. ;-) > I'm taking note! I will thus consider working on other Java packages then. > > Thanks again > > Andreas. > Have a nice week-end, Pierre
Re: RFS : new upstream version of jebl2
Hi Andreas, Le 25/04/2020 à 11:20, Andreas Tille a écrit : > Hi again, > > perhaps also getting > >https://salsa.debian.org/med-team/libsis-jhdf5-java > > done would be helpful. I've pushed latest upstream but did not > found the time to update the old patches to the new version. > Getting this extremely outdated package updated would be great. > Thanks for the suggestion; I have begun working on it. Updating the patches is done, but I am facing build issues that you had already seen one year and a half ago, related to some header file H5private.h. Do you remember about that issue? Otherwise no worry, I will investigate :-) Afterwards, I will be interested in packaging the dependencies of snpeff as you suggested yesterday. I will fill ITP bugs when I am ready for beginning this. > > Kind regards > Andreas. > Enjoy your week-end --- at home, as for me, I'm afraid :-( , Pierre
Packaging libsis-jhdf5-java -- help needed
Hi everyone, I have been trying to package libsis-jhdf5-java, after Andreas imported the last upstream version. This package builds a java package with a .jar file and a jni package with native code used by the .jar. I have been able to: - refresh patches; - get rid of the private header H5private.h of source package hdf5, which is not shipped by any package. Only a few simple preprocessor directives of that file were used; - update the list of build-depends; - have the package build, including the override of dh_auto_test that caused issues previously. Yet: - it seems that only a few upstream-provided tests are run in dh_auto_test, so having the build complete is maybe not so meaningful :-( ; - I have begun designing tests for the autopkgtest testsuite, using upstream-provided tests, and while around 30 of them pass, there remains a lot of failing tests. It seems that the linking of the jni with the jar is not correctly done at build-time. At that point I would need help, as this package is complicated: the build processes of the jar and the jni are somehow entangled and I do not have enough knowledge of Java packaging to be able to solve the issues I'm facing. Maybe there does not remain so much to be done; if someone has Java knowledge and could look to the current packaging I have put into Salsa [1], this would be really great. Thank you and have a good week, All the best, Pierre [1] https://salsa.debian.org/med-team/libsis-jhdf5-java
Re: Packaging libsis-jhdf5-java -- help needed
Hi Gilles, Le 29/04/2020 à 17:53, Gilles Filippini a écrit : > Andreas Tille a écrit le 29/04/2020 à 17:36 : >> Hi Gilles, >> >> On Wed, Apr 29, 2020 at 05:10:38PM +0200, Gilles Filippini wrote: >>> >>> I've cloned the git repo and attempted a build. But the dh_auto_test >>> part doesn't execute any test actually: >>> >>>debian/rules override_dh_auto_test >>> make[1]: Entering directory >>> ... >>> === >>> All >>> Tests run: 0, Failures: 0, Skips: 0 >>> === >>> >>> >>> === >>> All >>> Total tests run: 0, Failures: 0, Skips: 0 >>> === >> >> Thanks a lot for checking - any idea how to force execution of >> the tests? > > No, I don't know how this is supposed to work :/ > Thanks for checking; I had also seen that these tests did not run, this will have to be fixed. More important is the fact that I have put and arranged the piece of code of dh_auto_test override into a test in debian/tests/providedTests; here they run, and while the first ones pass, next ones fail and I feel this is because the java code cannot link to the native code in the jni package. Yet, my problem is that I have not been able to investigate more deeply, as the Java part is build using Gradle but the jni part is built outside of Gradle, using a single command. I thus don't know if the link between the Java and native code is correctly done at that stage. While I agree, of course, that we will need that the tests in override_dh_auto_test run, we are already able to reproduce the problem I am describing by running autopkgtest on the built package. > > _g. > Thanks again for considering this, All the best, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hello Gilles,
Le 30/04/2020 à 23:17, Gilles Filippini a écrit :
>>>
>>> Thanks for checking; I had also seen that these tests did not run, this will
>>> have to be fixed. More important is the fact that I have put and arranged
>>> the piece of code of dh_auto_test override into a test in
>>> debian/tests/providedTests; here they run, and while the first ones pass,
>>> next ones fail and I feel this is because the java code cannot link to the
>>> native code in the jni package.
>>>
>>> Yet, my problem is that I have not been able to investigate more deeply, as
>>> the Java part is build using Gradle but the jni part is built outside of
>>> Gradle, using a single command.
>>> I thus don't know if the link between the Java and native code is correctly
>>> done at that stage.
>>>
>>> While I agree, of course, that we will need that the tests in
>>> override_dh_auto_test run, we are already able to reproduce the problem I am
>>> describing by running autopkgtest on the built package.
>>
>> Here is what I obtain running autopkgtest against the binary packages:
>>
>> autopkgtest [19:41:00]: test providedTests: [---
>> xargs: javac: No such file or directory
>> autopkgtest [19:41:00]: test providedTests: ---]
>> autopkgtest [19:41:01]: test providedTests: - - - - - - - - - - results
>> - - - - - - - - - -
>> providedTestsFAIL non-zero exit status 127
>> autopkgtest [19:41:01]: test providedTests: - - - - - - - - - - stderr
>> - - - - - - - - - -
>> xargs: javac: No such file or directory
>> autopkgtest [19:41:01]: summary
>> providedTestsFAIL non-zero exit status 127
>>
>> Is the salsa git repo up to date?
>
> I've managed to run the tests (adding default-jdk the the Depends field
> into debian/tests/control), and reproduced the failures you mentioned.
>
> I can't tell whether it it the library's fault or the test cases' one,
> but most failures are due to the JNI library not being loaded. Adding
> System.loadLibrary("sis-jhfd5");
> to the init() method of HDF5DataSetRandomAccessFileTest.java fixed them.
>
> It remains 16 unrelated failures (IllegalArgumentException,
> AssertionError, HDF5DatatypeInterfaceException).
>
Really sorry, I had forgotten to push my last change, which is exactly what
you did (putting default-jdk in the Depends field of the tests). I have just
done it.
Thanks for looking at the issue and proposing a fix. It is very helpful!
I will thus look at it and investigate further the failures that remain.
>
> Best,
>
> _g.
>
Best regards,
Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi Gilles, Le 01/05/2020 à 01:12, Gilles Filippini a écrit : > Pierre Gruet a écrit le 30/04/2020 à 23:45 : >> Thanks for looking at the issue and proposing a fix. It is very helpful! >> I will thus look at it and investigate further the failures that remain. > > This package looks weird. Where does the mix-up between libhdf5-java and > libsis-jhdf5-java come from? There shouldn't have any dependency to > libhdf5-java as I understand it. The tests failures come from this > confusion. > > Using the attached patch, the package builds correctly and only 10 > failing test cases remain. > > BTW the override_dh_auto_clean target should be reintroduced. > > Best, > > _g. > Thank you for this additional feedback. Concerning the mix-up, upstream was previously using a file from hdf5 to build sis-jhdf5, I removed it some days ago. I introduced other dependencies at that time and did not remove them... thanks for your patch thus! I was planning to consider a full refresh of debian/rules, including dh_auto_clean. Best regards, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas and Gilles, Andreas, I have just seen you uploaded my commits of libsis-jhdf5-java to unstable, thanks for that! I had not written to ask for it as I intended to do further changes before the upload (the script h5ar in /usr/bin should be removed or another jar should be compiled, as h5ar is not working as is). But this is not a problem as the package you uploaded builds well, all tests pass and the jar and jni are usable. I shall provide another version soon, that fixes the /usr/bin/h5ar issue. Gilles, huge thanks again for your help, with your input I could solve the remaining issues and, afterwards, improve debian/rules consequently. All the best, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas, Le 07/05/2020 à 16:26, Andreas Tille a écrit : > On Thu, May 07, 2020 at 09:43:11AM +0200, Andreas Tille wrote: >> I also >> think that observing autobuilders and possibly fix issues there in a >> subsequent upload with your additional changes could be a good idea. > > As expected there is some more work to do which escaped my sponsors > view: See bug #959955. :-) > > Kind regards > > Andreas. > Wow, I had not seen that, thanks for showing me. I will prepare a new upload very soon to fix the issue. Best regards, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi again, Le 07/05/2020 à 16:26, Andreas Tille a écrit : > On Thu, May 07, 2020 at 09:43:11AM +0200, Andreas Tille wrote: >> I also >> think that observing autobuilders and possibly fix issues there in a >> subsequent upload with your additional changes could be a good idea. > > As expected there is some more work to do which escaped my sponsors > view: See bug #959955. :-) > > Kind regards > > Andreas. > I have just uploaded the new version 19.04.0+dfsg-2 of libsis-jhdf5-java to Salsa: to close bug #959955, I have changed the name of the .so that is generated to avoid name collisions. All tests from build-time and autopkgtest testsuite are passing. All the best, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas, Le 08/05/2020 à 22:05, Andreas Tille a écrit : > > Very nice. Thanks a lot for your work. I've built and installed the > package. When noticing that there is no manpage for h5ar I intended to > check whether it might be cheap to create one via help2man. However, > this ended up in > > $ h5ar > cat: /usr/version.txt: Datei oder Verzeichnis nicht gefunden > Error: Unable to access jarfile /usr/lib/sis-jhdf5-h5ar-cli-.jar > > > I think we need some more patches adjusting pathes to let this script > run successfully. Are you volunteering to have a look? > Absolutely. This is part of the complementary tasks I was planning to do (my Salsa push of yesterday was only to fix the RC bug). h5ar was not in the previous packaging of libsis-jhdf5-java. I have seen that creating a man page should be easy, and while running h5ar as you did, I saw there was an issue with that version.txt file (easy to fix) and another one with the jar file, which is currently not built as it has not been part of the package libsis-jhdf5-java up to now. I will thus try to patch the gradle build script (or to edit d/rules) to build this new jar, and I need to learn a bit more about gradle to do so, which I am doing those days :-) Curiously, the jar is provided by upstream, there exists a task to build it in its gradle script, but it is not built by jh_build. > > Thanks a lot for your work in any case > > Andreas. > Thanks for having looked at this! All the best, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas, Le 08/05/2020 à 22:51, Andreas Tille a écrit : > Hi Pierre, > > On Fri, May 08, 2020 at 10:24:47PM +0200, Pierre Gruet wrote: >> >> Absolutely. This is part of the complementary tasks I was planning to do >> (my Salsa push of yesterday was only to fix the RC bug). h5ar was not in >> the previous packaging of libsis-jhdf5-java. > > If you think you might be able to care for the h5ar binary issue in the > next couple of days I would delay the upload to fix the RC bug. I guess > this will not have any practical drawback if the propagation of this > package to testing will be delayed some more days. > Fine then, we can delay the upload as I plan to care for h5ar those days :-) > > [...] > > I can confirm that you can't prevent learning something when dealing > with Debian packages. ;-) > I guess this is one of the great things about packaging! > > Kind regards > > Andreas. > Have a nice day, Pierre
Re: Packaging libsis-jhdf5-java -- help needed
Hi Andreas, Le 08/05/2020 à 22:51, Andreas Tille a écrit : > > If you think you might be able to care for the h5ar binary issue in the > next couple of days I would delay the upload to fix the RC bug. I guess > this will not have any practical drawback if the propagation of this > package to testing will be delayed some more days. > This is done, I have pushed the changes to Salsa. The candidate upload would: - close bug 959955 by renaming the .so (we discussed it some days ago); - provide a *new binary package*, which I called h5ar. It contains the wrapper script /usr/bin/h5ar and the jar that it wraps. The build of this jar is done using jh_build as it is not handled by the gradle call of upstream. I put the wrapper and its jar in a new package in order to comply with Debian Java policy [0], which makes a clear distinction between programs and libraries; - provide a test for this h5ar package in the testsuite; - provide hardening while building this .so; - provide tests of the testsuite as package examples. Thanks in advance for your time and possible future advice on this packaging (in particular in case you would recommend another name for the new package h5ar), Best regards, Pierre [0] https://www.debian.org/doc/packaging-manuals/java-policy/ch02.html
Bug#961158: ITP: distlib -- Java library of statistical distribution functions
Package: wnpp Severity: wishlist Owner: Debian-med project * Package name: distlib Version : 0.9.1 Upstream Author : Peter N. Steinmetz * URL : https://sourceforge.net/projects/statdistlib * License : GPL-2 Programming Lang: Java Description : Java library of statistical distribution functions This is a library written in Java, providing probability density function, cumulative distribution function, quantiles and random variate generation for several common statistical distributions. This package will be taken care of in Debian-med team, where it is needed as a dependency of SnpEff.
Bug#961158: ITP: distlib -- Java library of statistical distribution functions
Control: retitle -1 ITP: libdistlib-java -- Java library of statistical distribution functions Hi Scott and Andreas, Le 21/05/2020 à 06:44, Scott Kitterman a écrit : > On Thursday, May 21, 2020 12:08:44 AM EDT Andreas Tille wrote: >> At least the name of the binary package should be >> >> libdistlib-java >> >> Choosing the same name for the source package as the binary package is >> frequently done. > > That would certainly resolve my concern. > > Thanks, > > Scott K > Thanks for your reactions and suggestions, this looks fine. I am therefore renaming the ITP bug and changing the identification block for this new package to the following. * Package name: libdistlib-java Version : 0.9.1 Upstream Author : Peter N. Steinmetz * URL : https://sourceforge.net/projects/statdistlib * License : GPL-2 Programming Lang: Java Description : Java library of statistical distribution functions Best regards, Pierre
RFS : libdistlib-java
Hi, I have packaged libdistlib-java, which is a Java implementation of several cdf, pdf, quantile and simulation functions from R, originally written in C. This was announced in ITP bug #961158. Would it be possible to have a review? It would be precious, as this is my first initial packaging! It is in the Salsa repository [0]. Beyond packaging, I have also written tests that allowed me to create a patch fixing issues in the original code (tiny errors from the conversion from initial C to Java code). I will forward the patch to upstream. Thanks a lot and have a nice week, Best, Pierre [0] https://salsa.debian.org/med-team/libdistlib-java
Re: RFS : libdistlib-java
Hi Andreas, Le 25/05/2020 à 23:12, Andreas Tille a écrit : > Hi Pierre, > > On Mon, May 25, 2020 at 10:47:58PM +0200, Pierre Gruet wrote: >> I have packaged libdistlib-java, which is a Java implementation of >> several cdf, pdf, quantile and simulation functions from R, originally >> written in C. >> > [...] >> >> Would it be possible to have a review? It would be precious, as this is >> my first initial packaging! > > Looks pretty good. The only nitpicking comment would be that > in d/changelog you are repeating the version number inside the > text section. I left it as is but its a bit redundant. > Thanks for the review, the upload and this comment! I shall avoid such redundancy next time. > [...] > > Its uploaded now. Thanks a lot again > > Andreas. > > Have a nice afternoon, Best regards, Pierre
Maintaining non-med packages in the team only to satisfy dependencies
Dear all, Lastly I have begun packaging Java software needed as dependencies of snpeff, that we would need in Debian Med as it is related to genes and proteins. I have thus worked on a Java library related to cdf, pdf and random variates generation: libdistlib-java. It is currently in NEW. Now I am looking at the packaging of apfloat, a Java software to perform computations with arbitrary precision. I have just seen it needs another Java software not yet in Debian, aparapi, allowing to execute Java code on a GPU. I am willing to package them, but my question (maybe naive as from a newcomer) is the following: is it reasonable to do this packaging work in the team as those software obviously have a scope larger than ours? Should we offer other teams (for instance, Debian Science for libdistlib-java) to host the packaging in a way that would be more formal than only submitting the ITP bug and waiting for reactions? This would not necessarily mean waiting the other team to do the packaging, but maybe to put their ID in the Maintainer field of debian/control if they want. Of course we in Debian Med will do the maintenance effort as we need those software (e.g. for snpeff, which we want to have in Debian), but don't you think that other teams could blame us for working on packages that would logically be maintained by them? I imagine you already have an opinion on that, and I would be interested in the rationale. Thanks for reading, and have a very nice week-end, Pierre
Re: Maintaining non-med packages in the team only to satisfy dependencies
Hi Andreas, Le 30/05/2020 à 07:51, Andreas Tille a écrit : > Hi Pierre, > > On Fri, May 29, 2020 at 11:48:39PM +0200, Pierre Gruet wrote: >> >> Lastly I have begun packaging Java software needed as dependencies of >> snpeff, that we would need in Debian Med as it is related to genes and >> proteins. > > At first I'd like to say thanks a lot for this. > You are welcome! :) > > > For picking a team there is no real right or wrong. As I recently wrote > here[1] we should assemble all biology / medicine related software no > matter what language it is written in, here. But also to this rule > exceptions exist. > > We have a very "bad" example for generic software in Debian Med team > which is libzstd which is now even on boot disks. I'd love to get rid > of this here - but there is no other place and it was initially > maintained by a Debian Med member. > > I think the decision where to maintain involves also some gut feeling. > I usually decide based on the chances I see to get the best maintenance. > Its better to get mails about RC bugs via the channels you usually read > instead of just getting information that your final target package will > be removed from testing due to RC bugs somewhere else. > Thanks a lot for giving your opinion in details, this helps! > >> Of course we in Debian Med will do the maintenance effort as we need >> those software (e.g. for snpeff, which we want to have in Debian), but >> don't you think that other teams could blame us for working on packages >> that would logically be maintained by them? > > There is no "blame" about this. Teams like Debian Med and Debian > Science are working closely together. There is no real competition > about who maintaines what. > I perfectly understand. I was not suggesting competition, but trying to infer some rules in the mechanisms that lead one package to be maintained in one team or another. Besides, I am very much aware of one of the main reasons, which is the needs and time of the members of the teams. > >> I imagine you already have an opinion on that, and I would be interested >> in the rationale. > > For you as a newcomer I'd recommend to stay in a team where you are > comfortable with. Finally packages can be moved between teams if > needed. I'm personally reading Debian Science list but not with the > same frequence as the Debian Med list. So if you want a quick response > from me, just maintain it here. If you rather want to meet people in > Debian Science which can be interesting, just do it there (and may be > CC me in mails to be save to get quick response). Both is fine. > Thanks again. I am indeed very comfortable in Debian Med; my only concern was to do things correctly in my Debian work :-) I will thus go on doing the packaging efforts toward SnpEff in Debian Med. > >> Thanks for reading, and have a very nice week-end, > > Same to you > > Andreas. > Kind regards, Pierre
Issue about mutual dependencies for aparapi
Hello everyone, I am currently beginning packaging aparapi, which is a Java API to execute Java code on a GPU. In Debian Med, we need it as dependency of the dependency apfloat of SnpEff. This package relies on a JNI (native code) package which the same upstream develops as aparapi-native. Yet aparapi and aparapi-native are somehow interleaved, as aparapi depends on aparapi-native *and* aparapi-native needs a small number of source files of aparapi to build. I understand upstream uses symlinks to solve this locally on their computers. Having in mind Debian packaging, what would in your opinion be the best solution for us? We could: - build a package with multiple tarballs, which would provide both the JNI and Java binary packages; - use debian/missing-sources to add the few files that are needed by the JNI part and be able to build the two packages one after the other; - another solution? Thanks a lot for your attention, Best regards, Pierre
Re: Issue about mutual dependencies for aparapi
Hello, Le 04/06/2020 à 22:36, Thorsten Glaser a écrit : > On Thu, 4 Jun 2020, Mechtilde wrote: > >> This is an outdated information. You can collect all source tar.gz >> together in to one orig.tar.xz. In the d/gbp.conf you configure a > > DON’T DO THAT. > > MUTs (multi-origtgz) were invented for a good reason. > > bye, > //mirabilos > Thanks to everyone for the advice and links about this issue! I understand there are various solutions that can be implemented and are valuable. I think I will first try gbp with a MUT package. All the best, Pierre
Re: Any volunteer to spent some time on the new version of artemis (Was: Bug#963430: artemis: FTBFS: /bin/sh: 1: /usr/share/java/j2ssh-core.jar: Permission denied)
Hi Emmanuel, Le 22/06/2020 à 16:30, Andreas Tille a écrit : > Hi Emmanuel, > > On Mon, Jun 22, 2020 at 10:57:15AM -0300, Emmanuel Arias wrote: >> I would be happy to help on artemis. Obviously I will need >> a more experienced developer helping me. :) > > I'll try hard to answer any question you might rise here on > this list (no matter how basic it might be) if you volunteer > to work on Artemis (or any other package). > > Thanks a lot for your commitment > > Andreas. > If you need it, I will be very happy to try to help you, based on my recent Java packaging tasks. All the best, Pierre
Bug#963630: ITP: libaparapi-java -- framework for executing native Java code on the GPU
Package: wnpp Severity: wishlist Owner: Debian-med project * Package name: libaparapi-java Version : 2.0.0 Upstream Author : Gary Frost, Syncleus, Inc. * URL : http://aparapi.com/ * License : Apache-2.0 Programming Lang: Java Description : framework for executing native Java code on the GPU This framework converts Java bytecode to an OpenCL kernel dynamically at runtime, to allow Java code to be executed on a graphics card GPU. This allows developers to take profit from GPU architecture while writing Java programs. This package will be taken care of in Debian-med team, where it is needed as a dependency of apfloat, which is itself a dependency of SnpEff.
[RFS] libaparapi-java
Dear all, I have pushed the initial packaging of libaparapi-java to Salsa [0], I would need a review and an upload if time permits. This is a dependency of apfloat (to be packaged), which is a dependency of SpnEff that we would like to get packaged. libaparapi-java builds two binary packages. This is a MUT package built from three tarballs, it can be handled with git-buildpackage using the file debian/gbp.conf. Thanks a lot in advance, Pierre [0] https://salsa.debian.org/med-team/libaparapi-java
Re: [RFS] libaparapi-java
Hi Andreas,
Le 25/06/2020 à 22:49, Andreas Tille a écrit :
> Hi Pierre,
>
> On Thu, Jun 25, 2020 at 10:20:46PM +0200, Pierre Gruet wrote:
>> I have pushed the initial packaging of libaparapi-java to Salsa [0], I
>> would need a review and an upload if time permits.
>
> I'd love to help as quick as possible.
>
Thanks! :-)
>
>> This is a dependency of apfloat (to be packaged), which is a dependency
>> of SpnEff that we would like to get packaged.
>
> Did you noticed that I've just injected
>
> https://salsa.debian.org/java-team/libapfloat-java
>
> (and stopped due to missing libaparapi-java ... so thanks a lot for it!)
> Feel free to do whatever you want to do with my weak attempt!
>
Great! I had also begun, and then I saw aparapi had to be packaged
first. I could thus work upon your attempt now.
>
>> libaparapi-java builds two binary packages. This is a MUT package built
>> from three tarballs, it can be handled with git-buildpackage using the
>> file debian/gbp.conf.
>
> Could you please tell me what I need to do to get the tarballs?
> I simply get
>
> gbp:info: Tarballs 'libaparapi-java_2.0.0.orig.tar.gz,
> libaparapi-java_2.0.0.orig-native.tar.gz,
> libaparapi-java_2.0.0.orig-jni-headers.tar.gz' not found at '../tarballs/'
> gbp:error: Couldn't find upstream tree 'upstream/2.0.0^{tree}' to create orig
> tarball via pristine-tar
>
Sorry about that, I had forgotten to push tags (thus "upstream/2.0.0").
Please try again, it should be OK now and gbp will handle the tarballs.
>
> Kind regards
>
> Andreas.
>
>
>> [0] https://salsa.debian.org/med-team/libaparapi-java
>>
>>
>
All the best,
Pierre
Re: [RFS] libaparapi-java
Hi Andreas,
Le 26/06/2020 à 18:14, Andreas Tille a écrit :
> On Fri, Jun 26, 2020 at 05:33:30PM +0200, Pierre Gruet wrote:
>>> Did you noticed that I've just injected
>>>
>>> https://salsa.debian.org/java-team/libapfloat-java
>>>
>>> (and stopped due to missing libaparapi-java ... so thanks a lot for it!)
>>> Feel free to do whatever you want to do with my weak attempt!
>>>
>>
>> Great! I had also begun, and then I saw aparapi had to be packaged
>> first. I could thus work upon your attempt now.
>
> I think it was not really much done. Most probably your attempt is way
> more recent. I just wanted to let you know that there is an existing
> repository. Feel free to override everything I did!
>
Very well, I will go on with this repo!
>
>>> Could you please tell me what I need to do to get the tarballs?
>>> I simply get
>>>
>>> gbp:info: Tarballs 'libaparapi-java_2.0.0.orig.tar.gz,
>>> libaparapi-java_2.0.0.orig-native.tar.gz,
>>> libaparapi-java_2.0.0.orig-jni-headers.tar.gz' not found at '../tarballs/'
>>> gbp:error: Couldn't find upstream tree 'upstream/2.0.0^{tree}' to create
>>> orig tarball via pristine-tar
>>
>> Sorry about that, I had forgotten to push tags (thus "upstream/2.0.0").
>> Please try again, it should be OK now and gbp will handle the tarballs.
>
> Good to know that multi-tarball sources are working now with gbp.
> I need to remember this as an example.
>
Yes, besides building debian/watch to care for many tarballs, one must
also list the components in debian/gbp.conf... and then you are done!
>
> Thanks a lot for your work on this
>
> Andreas.
>
And thanks for the review and the upload!
Best regards,
Pierre
RFS : jebl2
Hello everyone, I have packaged the new upstream version of jebl2, available in the repository https://salsa.debian.org/med-team/jebl2 Could you please see and upload? Apart the new upstream version, there is just an update of the compat level. Regards, Pierre
Attributions concern for aparapi (currently in NEW)
Hi, I just realized there was a strange paragraph in the ATTRIBUTIONS.md file in libaparapi-java root folder : https://salsa.debian.org/med-team/libaparapi-java/-/blob/master/ATTRIBUTIONS.md It seems to be restrictive and perhaps annoying for us. Afterwards I saw that Andreas had already raised and discussed the issue on Debian lists, and that we were still waiting for an answer about removing this clause : https://github.com/aparapi/aparapi/issues/50 Yet I packaged libaparapi-java and we sent it in NEW, where it currently lies. Sorry for not seeing it before. Shoud we wait and see if it exits NEW or ask for its removal now? Thanks for the advice, Pierre
About Snpeff packaging (Was : Re: Attributions concern for aparapi (currently in NEW))
Hi Andreas, Le 26/07/2020 à 17:22, Andreas Tille a écrit : > Hi Pierre, > >> >> https://github.com/aparapi/aparapi/issues/50 > > I've pinged that issue. > Thanks! > >> Yet I packaged libaparapi-java and we sent it in NEW, where it currently >> lies. Sorry for not seeing it before. > > Well, its not only your fault - I should have seen it when sponsoring. > Well, I should have looked more carefully -- which I will do, in the future! > >> Shoud we wait and see if it exits NEW or ask for its removal now? > > May be some explicit hint to ftpmaster and asking for opinions is the > best way to go. > Thanks for the suggestion, I will thus do so, stating the issue explicitly. While I am at it: - if aparapi cannot enter Debian, I should be able to deactivate the module of apfloat that uses it, as this module is not part of the main code. I have got a similar issue for the module using jscience, as important non backward-compatible ABI changes in a dependency of jscience will prevent us from packaging it unless a new version comes one day. Snpeff does not use any of those modules (aparapi and jscience wrappers); - charts4j is currently in NEW; - distlib is in unstable and testing; - I have some concerns about akko-actor, as the build of this software seems to be relying on Scala Build Tool (sbt), which is packaged in Debian but not in good shape currently. I will look for a workaround if possible. > > Kind regards > > Andreas. > Best regards, Pierre
Re: yanosim does not migrate to testing - does anybody understand the missing dependency thingy?
Hi Steffen, Le 27/07/2020 à 12:19, Steffen Möller a écrit : > Hello, > > I had felt much like informing upstream about yanosim in Debian but > somehow it does not migrate. I don't really get this since the build is > just fine. Is it a runtime dependency? And why isn't the site clearly > stating what package is missing? > > https://qa.debian.org/excuses.php?package=yanosim > All I can see is that the runtime dependency python3-pysam is not in testing (nor in unstable) for the architecture s390x: https://packages.debian.org/bullseye/python3-pysam I can see nothing more :-( > > Many thanks! > > Steffen > Best regards, Pierre
Re: libgtextutils is marked for autoremoval from testing
Hello,
C++11 introduced references on rvalues, which basically allows to use a
non-constant reference on a temporary object (ie waiting for
affectation). Before, temporary objects could only be references by a
const reference.
Thus, from there, it becomes a problem to have two implicit conversion
operators defined in the class TextLineReader (text_line_reader.h):
operator const std::string& () const { return line_string() ; }
operator std::string() const { return line_string(); }
A call such that
TextLineReader r(...);
std::string str=r;
becomes ambiguous as the compiler could use the affectation operator of
std::string that take a const std::string& as input (thus calling the
first above operator) *or* the affectation operator of std::string that
takes a reference on a rvalue as input (thus calling the second above
operator, which returns a temporary object).
I suggest removing the second one. The first one is needed, for instance, in
const std::string& str=r;
which is non-ambiguous, whereas
std::string str=r;
and
std::string str(r);
are ambiguous and can work with either of the two implicit conversion
operators of TextLineReader.
I will prepare an upload.
Bye,
Pierre
RFS : libgtextutils
Hi, I have prepared an upload of libgtextutils in https://salsa.debian.org/med-team/libgtextutils It solves RC bug #925745 and makes the package lintian-clean. I have also added a C++-filtered symbols file. Could you please review when time permits? All the best, Pierre
Re: RFS : libgtextutils
Hi Andreas, Le 29/07/2020 à 21:52, Andreas Tille a écrit : > Hi Pierre, > > On Wed, Jul 29, 2020 at 05:36:29PM +0200, Pierre Gruet wrote: >> I have prepared an upload of libgtextutils in >> >> https://salsa.debian.org/med-team/libgtextutils >> >> It solves RC bug #925745 and makes the package lintian-clean. I have >> also added a C++-filtered symbols file. > > Thanks a lot! > >> Could you please review when time permits? > > Sure. Uploaded and thank you for your time > Thank you as well, for the upload and for your changes concerning the static lib of this package, which I am going to read carefully! > >Andreas. > Best regards, Pierre
Re: Please list your contributions to COVID-19 sprint as intput for my DebConf20 talk
Hi Andreas, Congratulations for getting this opportunity to talk about our work! Personally, I have worked on * Sumaclust (and its close relatives Sumatra and Sumalibs); * Dependencies of Snpeff, which is part of the Covid-19 task. Bye, Pierre Le 28/07/2020 à 08:43, Andreas Tille a écrit : > Hi, > > my talk proposal for DebConf20[1] was accepted recently. I would like > to thank all contributers (who "stayed home and contributed" ;-) ) in > this talk. To make sure I will not miss anybody please be so kind and > send me an e-mail with a list of your contributions - I'm afraid I would > forget something if I try to assemble it all. > > Feel free to add your contribution here to this thread on the mailing > list - I see no reason to hide it in some private mail (which is fine > anyway if you prefer this). > > Thanks again to all those who contributed and who keep on contributing > >Andreas. > > [1] > https://debconf20.debconf.org/talks/21-stay-home-and-contribute-to-debian-med/ >
Re: About Snpeff packaging (Was : Re: Attributions concern for aparapi (currently in NEW))
Hi Andreas, Le 26/07/2020 à 22:28, Andreas Tille a écrit : > Hi Pierre, > > >> While I am at it: >> - if aparapi cannot enter Debian, I should be able to deactivate the >> module of apfloat that uses it, as this module is not part of the main >> code. I have got a similar issue for the module using jscience, as >> important non backward-compatible ABI changes in a dependency of >> jscience will prevent us from packaging it unless a new version comes >> one day. Snpeff does not use any of those modules (aparapi and jscience >> wrappers); > > Thanks a lot for your investigation. While I'd prefer to provide a full > featured package but finally its very good news that we might be able to > leave out what is not possible to package due to licensing issues. > I plainly agree a full package would be better. Yet we will be able to provide the best possible package considering licensing issues, and everything will be prepared for including the missing part as soon as it becomes possible! > >> - I have some concerns about akko-actor, as the build of this software >> seems to be relying on Scala Build Tool (sbt), which is packaged in >> Debian but not in good shape currently. I will look for a workaround if >> possible. > > I remember we have some other package inside Debian which is Scala source > (I would need to check which package if it is of interest) and finally > we found a way to deal with this. > If this does not require too much time, I would be interested in knowing which one it is. I have recently browsed all packages with "scala" in their names, I saw many of them included files for sbt but the Scala compiler (in package 'scala') was used instead. This could maybe do the job with akka, yet I have the impress (but I have to further investigate to confirm) that akka would require a version of the Scala compiler that is newer than the one being currently packaged in Debian. I will discuss this on Java list if I need it. > > Thanks a lot for your work on this snpeff. Its very appreciated > > Andreas. > Thanks and have a good Sunday, Pierre
RFS : snap
Hello, I have prepared an upload of snap, fixing the gcc-10 FTBFS: https://salsa.debian.org/med-team/snap I have let 2 Lintian warnings, one of them stating a policy violation due to traversing link usr/lib/debian-med/bin/snap -> usr/bin/snap-hmm . While I understand this link is useful for Debian Med users who have their PATH set up correctly, shouldn't we do something as the Debian Policy is broken there? Feel free to give advice or to upload if you think it is fine :-) Thanks a lot for your time, Pierre
[RFS] libdistlib-java
Hi, I have packaged the new upstream version of libdistlib-java (taking into account many of our patches!), which lies in https://salsa.debian.org/med-team/libdistlib-java If time permits, could you please look at it and upload? Many thanks in advance, Pierre
Re: Sepp has build issued (Was: semi-RFS: xenium - good enough for me (at the moment))
Hi Pranav,
Le 13/08/2020 à 10:14, Andreas Tille a écrit :
> Hi Pranav,
>
> On Thu, Aug 13, 2020 at 05:54:41AM +0530, Pranav Ballaney wrote:
>> Hi,
>> I was writing autopkgtests for busco and noticed that sepp is indeed a
>> dependency. I tried continuing the packaging work for sepp, and I found a
>> TODO in the changelog with the following:
>>
>> [javac] Note: Some input files use or override a deprecated API.
>> [javac] Note: Recompile with -Xlint:deprecation for details.
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] Note: Some messages have been simplified; recompile with
>> -Xdiags:verbose to get full output
>> [javac] 3 errors
>> [javac] 5 warnings
>>
>> Is this because sun.java2d.SunGraphicsEnvironment API has been deprecated,
>> or is it just that it is missing a dependency so it can't import the API? I
>> don't know much about Java packages, but if someone could point me in the
>> right direction, I might be able to help.
>
> I admit I have no idea about those Java issues, but I've put Pierre
> Gruet in CC. If he can not help it might be sensible to ask at
> debian-j...@lists.debian.org.
>
I had not heard of this deprecation issue and I don't think it matters
for us. It only causes warnings.
Concerning the errors, they happen because JSONArray objects are passed
to an function that needs a sub-interface of Collection,
whereas JSONArray is a sub-interface of Collection. I have
written the patch json_collections.patch (enclosed), which solves the
errors by adding elements one by one instead of mistakingly calling a
global add function. I think this was the intent of upstream, but tell
me if you have build-time tests that fail.
The build can go on after using this patch.
Besides, I think you could use the other enclosed patch to build with a
more recent version of Java, this would suppress two other warnings.
Do not hesitate if you would like to discuss these issues more deeply.
Best regards,
Pierre
--- a/tools/merge/build.xml
+++ b/tools/merge/build.xml
@@ -29,7 +29,7 @@
-
+
--- a/tools/merge/src/phylolab/taxonamic/PPlacerJSONMerger.java
+++ b/tools/merge/src/phylolab/taxonamic/PPlacerJSONMerger.java
@@ -312,7 +312,9 @@
return name1.compareTo(name2);
}
});
- sortedPlacements.addAll(resultsPlacements);
+for (int i=0 ; i it=placements.iterator() ; it.hasNext() ;) {
+ sortedPlacements.add(it.next());
+}
double total = 0;
ArrayList < JSONArray > list = new ArrayList < JSONArray > ();
for (Iterator < JSONArray > itp = sortedPlacements.iterator(); threshold > total && itp.hasNext();) {
@@ -559,7 +561,9 @@
return name1.compareTo(name2);
}
});
- sortedPlacements.addAll(resultsPlacements);
+ for (int i=0 ; i
Re: Sepp has build issued (Was: semi-RFS: xenium - good enough for me (at the moment))
Hi Andreas,
Le 14/08/2020 à 23:35, Andreas Tille a écrit :
> Hi Pierre,
>
> On Fri, Aug 14, 2020 at 10:40:28PM +0200, Pierre Gruet wrote:
>> I had not heard of this deprecation issue and I don't think it matters
>> for us. It only causes warnings.
>>
>> Concerning the errors, they happen because JSONArray objects are passed
>> to an function that needs a sub-interface of Collection,
>> whereas JSONArray is a sub-interface of Collection. I have
>> written the patch json_collections.patch (enclosed), which solves the
>> errors by adding elements one by one instead of mistakingly calling a
>> global add function. I think this was the intent of upstream, but tell
>> me if you have build-time tests that fail.
>> The build can go on after using this patch.
>>
>> Besides, I think you could use the other enclosed patch to build with a
>> more recent version of Java, this would suppress two other warnings.
>>
>> Do not hesitate if you would like to discuss these issues more deeply.
>
> I admit I love your explanation since it gives me a slight tiny bit of
> understanding. In principle I'd prefer you commit those patches right
> to Git for the very simple reason that our edit history has the correct
> names of people who did the actual changes.
>
You are right, it is the second time I miss this... next time I will :-)
>
> The Java part seems to build. Now I'm stumbling upon a strange
>
>
> I: pybuild base:217: python3.8 setup.py config
> Traceback (most recent call last):
> File "setup.py", line 28, in
> from setuptools import find_packages
> File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 8, in
>
> import _distutils_hack.override # noqa: F401
> ModuleNotFoundError: No module named '_distutils_hack'
> E: pybuild pybuild:352: configure: plugin distutils failed with: exit code=1:
> python3.8 setup.py config
> dh_auto_configure: error: pybuild --configure -i python{version} -p 3.8
> returned exit code 13
>
>
> error - which needs to be investigated tomorrow (except somebody might
> beat me which is always prefered).
>
I don't know what to do with this, but it seems to be a bug in
python3-setuptools, reported yesterday night:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968410
Probably we should wait for a new upload of python3-setuptools.
>
> Kind regards and thanks a lot for your Java patches
>
> Andreas.
>
Thanks and have a good day,
Pierre
Re: [benjamin.redeli...@gmail.com: Bug#968739: igv will not run]
Hi, Le 21/08/2020 à 12:44, Andreas Tille a écrit : > Hi Pierre, > > On Fri, Aug 21, 2020 at 11:32:47AM +0200, Pierre Gruet wrote: >>> I injected the latest upstream version into Git. It does not include so >>> many binary jar's any more but I think its trying to download these >>> instead. I gave up for the moment since I have no idea about gradle. >>> >> Thanks! Many of those jars are in Debian packages, so there is hope to >> get rid of many, maybe all... I'm looking at it. >> Contrarily to what I wrote a few days ago, I do not think we are ready to remove all included jars in igv. For instance we would have to package libgoby-java, I have just made some packaging effort on its new upstream version [0] after Andreas began but, as Olivier noticed before on a previous upstream version [1], there are still many jars missing in Debian. We would also need to have the huge Amazon AWS SDK packaged... I will thus work on #968739 and on the new upstream version but I am afraid we will have to keep igv in non-free for the moment :-( > > Thanks a lot. That would be another mile stone! > > Kind regards > > Andreas. > All the best, Pierre [0] https://salsa.debian.org/med-team/libgoby-java/ [1] https://lists.debian.org/debian-med/2013/02/msg00152.html
Re: [benjamin.redeli...@gmail.com: Bug#968739: igv will not run]
Hi Andreas, Le 24/08/2020 à 12:39, Andreas Tille a écrit : > Hi Pierre, > > On Mon, Aug 24, 2020 at 12:08:28PM +0200, Pierre Gruet wrote: >> Contrarily to what I wrote a few days ago, I do not think we are ready >> to remove all included jars in igv. >> For instance we would have to package libgoby-java, I have just made >> some packaging effort on its new upstream version [0] after Andreas >> began but, as Olivier noticed before on a previous upstream version [1], >> there are still many jars missing in Debian. >> >> We would also need to have the huge Amazon AWS SDK packaged... > > Well, I never claimed it will be an easy task. ;-) > True :-D Only I underestimated this. > >> I will thus work on #968739 and on the new upstream version but I am >> afraid we will have to keep igv in non-free for the moment :-( > > Yep. Better have a working one in non-free than only a non-working one. > In fact, looking more closely at it, upstream has stopped bundling useful jars after version 2.6.3 (last upstream version is 2.8.10, current Debian-packaged one is 2.4.17). We currently do not have the right libs in Debian to package a version after v2.6.3. I think I will thus go back to v2.6.3 and package it, it will still be a progress, it is just 1 year old, and it will lead to a working package, still in non-free. Medium-term work should then allow to get the right dependencies packaged and hopefully to handle the last upstream version. > >> All the best, > > Same to you > > Andreas. > > Best regards, Pierre
Java packaging in Debian med [Was : Re: [benjamin.redeli...@gmail.com: Bug#968739: igv will not run] ]
Hi Steffen and Andreas, Le 25/08/2020 à 06:35, Andreas Tille a écrit : > On Tue, Aug 25, 2020 at 12:12:04AM +0200, Steffen Möller wrote: >> I created a "Java" tab on our spreadsheet. Would of course be great if >> that sees some momentum. Took the freedom to also add Cytoscape. And if >> I get this right, then also nextflow qualifies, which because of >> "capsule" seems kind of stuck. Thanks, I will populate the tab. I already have access to the file. > > Thanks to Pierre we are close to snpeff. Cytoscape is another very nice > thing to have as well as gatk. Having this in Debian 11 would be a real > advantage. > BTW, snpeff depends on akka-actor, a (Scala+Java) library which still has to be packaged, and I am afraid it will be blocked by the version of Scala in Debian, itself being stuck to 2.11 as Scala build tool (SBT) requires work. I shall document all this in the spreadsheet! > > Kind regards > > Andreas. > Best regards, Pierre
Re: Java packaging in Debian med [Was : Re: [benjamin.redeli...@gmail.com: Bug#968739: igv will not run] ]
Hi Andreas, Le 26/08/2020 à 07:13, Andreas Tille a écrit : >> >> BTW, snpeff depends on akka-actor, a (Scala+Java) library which still >> has to be packaged, and I am afraid it will be blocked by the version of >> Scala in Debian, itself being stuck to 2.11 as Scala build tool (SBT) >> requires work. I shall document all this in the spreadsheet! > > Did you talked about the needed Scala with Debian Java team? I > remember there was some work under way for sbt which was stalled. > If you want me to revive this discussion I can try to catch up. > I haven't asked, since I instead got informed about what blocks Scala packaging in an open bug asking for packaging Scala 2.12, of which thread https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845113 explains sbt is mandatory for building new Scala versions and asks for help. I thus see the Java team is much aware of Scala state. Personally I don't think I can help with sbt packaging. If you remember seeing a discussion on sbt, I think it might be revived to express our interest. > > Kind regards > > Andreas. > Thanks for your help, Pierre
Re: Bug#845113: scala 2.12 released. Please upload version 2.12 ASAP into debian sid, so that it integrates into debian stable 9 stretch
Dear Maintainers, For our information, do you know if it might be possible to unblock the situation soon? Is there some ongoing work on sbt? In Debian-med, we would be interested in having Scala 2.12 or 2.13 to package the pre-dependency akka. Thanks a lot in any case, Best regards, Pierre Gruet
[RFS] igv 2.6.3
Hi, I have worked on the packaging of igv 2.6.3+dfsg, which is in https://salsa.debian.org/med-team/igv This igv packaging still relies on its embedded jars. I have solved build issues related to gradle, another one linked to the current version of htsjdk (solves Grave bug on igv), and had to skip build-time tests which required a network access. You will see the remaining tests are quite verbose as they output information to stderr and stdout, but all are passing. I installed and ran the package on my computer (running Testing), it seemed to work fine. I have not packaged the most recent upstream version (2.8.10) as all upstream versions > 2.6.3 rely on jars that are downloaded from the internet at build time. It is thus very relevant to package the predependencies of igv -- which I have begun, two of them are awaiting sponsorship on Debian Java mailing list. Thanks in advance for looking at igv and sponsoring it when time permits, All the best, Pierre
Re: [RFS] igv 2.6.3
Hi Andreas, Le 02/09/2020 à 09:09, Andreas Tille a écrit : > Hi Pierre, > > On Tue, Sep 01, 2020 at 10:54:52PM +0200, Pierre Gruet wrote: >> I have worked on the packaging of igv 2.6.3+dfsg, which is in >> >> https://salsa.debian.org/med-team/igv >> >> This igv packaging still relies on its embedded jars. I have solved >> build issues related to gradle, another one linked to the current >> version of htsjdk (solves Grave bug on igv), and had to skip build-time >> tests which required a network access. >> You will see the remaining tests are quite verbose as they output >> information to stderr and stdout, but all are passing. >> I installed and ran the package on my computer (running Testing), it >> seemed to work fine. > > I'm running testing as well and I think that's OK. > Thanks! Would you mind pushing the changes and tags to Salsa so that I can get them? > >> It is thus very relevant to package the predependencies of igv -- which >> I have begun, two of them are awaiting sponsorship on Debian Java >> mailing list. > > Feel free to ping me in CC - I'm perfectly willing to sponsor packages > also in other teams. I'll check the list right now. > OK, I will ping you in CC if I need it in the future. Thanks for having already looked at those two packages! > >> Thanks in advance for looking at igv and sponsoring it when time permits, > > Sponsoring your fine work does not much time and is really important to > me since it solves issues in our packages. BTW, if you might find some > time for artemis - that would be really cool as well since it is > outdated since some time and also needs love. > I will have a look! > > Thanks again for your effort > > Andreas. > Best regards, Pierre
[RFS] artemis
Hi, I have worked on artemis, which required some attention :-) We now have the most recent upstream version and the RC bug is fixed. Upstream now uses Maven for the build, which led to many changes. https://salsa.debian.org/med-team/artemis Could you please review and upload? My key is not in the Maintainers keyring yet. Thanks a lot and have a good week, Pierre
Re: libbarclay-java needs update, libpicard-java runtime tests by pigx-scrnaseq
Hi, Le 10/09/2020 à 17:11, Andreas Tille a écrit : > Hi Steffen, > > On Thu, Sep 10, 2020 at 03:32:49PM +0200, Steffen Möller wrote: >> libpicard-java needs an argparse class from the barclay library. This >> was found by the intense build-time testing of the PIGx-scRNAseq. >> ... >> How shall I/we proceed? My immediate plan was to just update locally to >> vesion 4.0.0 (released a few days ago) and see if the two reverse >> dependencies still build. > > From my naive point of view the migration to a recent libbarclay-java > should be easy given that only two packages in our hands are rdepends > of it. Thus I was running routine-update on barclay[1] but the build > is running into: > > ... > radle Test Executor 1 finished executing tests. > Results: FAILURE (346 tests, 344 successes, 2 failures, 0 skipped) > > > Pierre, can you help? ;-) > I have had a really hard time, but I finally found the issue (a LinkedHashMap was wrongly iterated over in a Freemarker template), now all build tests are passing and the .deb can be built :-) I have pushed my changes to Salsa. Could someone do some final checks (maybe forward the patch I have written)? > >> If this update then then happens to also fix >> the failed test of PIGx-scRNAseq, then this shall be it. Alternatively, >> well, we would need versioned library packages, then, and I'll see how >> far version 3 carries me. > > I do not think we should spent time on a version that just became > outdated so version 4 should most probably be our target. > >> Right? If there is anyone out there who is a >> bit closer to the barclay library, please direct me if there is any need >> to keep the older version 2 in the archive. > > Libpicard-java needs an update as well - so I'd suggest to upgrade > libbarclay-java first and than see how to continue (may be together > with upstream). > > Disclaimer: All I said is probably absolutely naive and not based on > any deeper knowledge about the software involved simply guided by my gut > feeling about what usually was a sensible strategy. > I do not know barclay either but I would say the same. > > Kind regards > >Andreas. > > [1] https://salsa.debian.org/java-team/barclay > Best regards, Pierre
Re: libbarclay-java needs update, libpicard-java runtime tests by pigx-scrnaseq
Hi Steffen, Le 11/09/2020 à 02:23, Steffen Möller a écrit : > Hi again, > > On 11.09.20 00:01, Pierre Gruet wrote: >> Hi, >> >> Le 10/09/2020 à 17:11, Andreas Tille a écrit : >>> Hi Steffen, >>> >>> On Thu, Sep 10, 2020 at 03:32:49PM +0200, Steffen Möller wrote: >>>> libpicard-java needs an argparse class from the barclay library. This >>>> was found by the intense build-time testing of the PIGx-scRNAseq. >>>> ... >>>> How shall I/we proceed? My immediate plan was to just update locally to >>>> vesion 4.0.0 (released a few days ago) and see if the two reverse >>>> dependencies still build. >>> From my naive point of view the migration to a recent libbarclay-java >>> should be easy given that only two packages in our hands are rdepends >>> of it. Thus I was running routine-update on barclay[1] but the build >>> is running into: >>> >>> ... >>> radle Test Executor 1 finished executing tests. >>> Results: FAILURE (346 tests, 344 successes, 2 failures, 0 skipped) >>> >>> >>> Pierre, can you help? ;-) >>> >> I have had a really hard time, but I finally found the issue (a >> LinkedHashMap was wrongly iterated over in a Freemarker template), now >> all build tests are passing and the .deb can be built :-) >> I have pushed my changes to Salsa. >> >> Could someone do some final checks (maybe forward the patch I have written)? > > https://github.com/broadinstitute/barclay/ > > You can expect to be listed as a contributor one your patch is accepted. > That > and an unpredictable exchange with upstream is what you earned. The > submission > to upstream is on you :) Should you feel a bit awkward with github then I > happily help ... but since you are doing just fine with gitlab ... > Thanks! :-) I have just forwarded the patch. I was too lazy (or it was too late) to do it yesterday night. Thanks for your words! > > I added > > > --- a/debian/pom-barclay.xml > +++ b/debian/pom-barclay.xml > @@ -5,7 +5,7 @@ > barclay > jar > barclay > - 2.1.0 > + 4.0.0 > barclay > > org.broadinstitute > > but otherwise left it and it looks good!?: > > $ dpkg -c ../libbarclay-java_4.0.0-1_all.deb > drwxr-xr-x root/root 0 2020-09-10 23:55 ./ > drwxr-xr-x root/root 0 2020-09-10 23:55 ./usr/ > drwxr-xr-x root/root 0 2020-09-10 23:55 ./usr/share/ > drwxr-xr-x root/root 0 2020-09-10 23:55 ./usr/share/doc/ > drwxr-xr-x root/root 0 2020-09-10 23:55 > ./usr/share/doc/libbarclay-java/ > -rw-r--r-- root/root 709 2020-09-10 23:55 > ./usr/share/doc/libbarclay-java/changelog.Debian.gz > -rw-r--r-- root/root 3287 2020-09-10 23:55 > ./usr/share/doc/libbarclay-java/copyright > drwxr-xr-x root/root 0 2020-09-10 23:55 ./usr/share/java/ > -rw-r--r-- root/root 147669 2020-09-10 23:55 > ./usr/share/java/barclay-4.0.0.jar > drwxr-xr-x root/root 0 2020-09-10 23:55 ./usr/share/maven-repo/ > drwxr-xr-x root/root 0 2020-09-10 23:55 ./usr/share/maven-repo/org/ > drwxr-xr-x root/root 0 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/ > drwxr-xr-x root/root 0 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/ > drwxr-xr-x root/root 0 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/4.0.0/ > -rw-r--r-- root/root 2246 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/4.0.0/barclay-4.0.0.pom > drwxr-xr-x root/root 0 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/debian/ > -rw-r--r-- root/root 2247 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/debian/barclay-debian.pom > lrwxrwxrwx root/root 0 2020-09-10 23:55 > ./usr/share/java/barclay.jar -> barclay-4.0.0.jar > lrwxrwxrwx root/root 0 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/4.0.0/barclay-4.0.0.jar > -> ../../../../../java/barclay.jar > lrwxrwxrwx root/root 0 2020-09-10 23:55 > ./usr/share/maven-repo/org/broadinstitute/barclay/debian/barclay-debian.jar > -> ../../../../../java/barclay.jar > > >> >>>> If this update then then happens to also fix >>>> the failed test of PIGx-scRNAseq, then this shall be it. Alternatively, >>>> well, we would need versioned library packages, then, and I'll see how >>>> far version 3 carries me. >>> I do not think we should spent time on a version that just became >>> outdated so version 4 should most proba
Re: libbarclay-java needs update, libpicard-java runtime tests by pigx-scrnaseq
Hi Steffen, Le 11/09/2020 à 15:27, Steffen Möller a écrit : > Hello again, > > [...] > > and the error prevails when minimizing the invocation as to > > > ~/git/med-team/pigx/pigx-scrnaseq$ /usr/bin/java -XX:ParallelGCThreads=1 > -Xmx4G -Xss16M -Djava.io.tmpdir=/tmp -cp $PICARD_CLASSPATH -j > ar /usr/share/java/picard.jar FastqToSam > Error: Unable to initialize main class picard.cmdline.PicardCommandLine > > while the following (without the -jar) is working (borrowed from the > picard-tools script): > > > export > PICARD_CLASSPATH=/usr/share/java/picard.jar:/usr/share/java/htsjdk.jar:/usr/share/java/guava > .jar:/usr/lib/jvm/default-java/lib/tools.jar:/usr/share/java/commons-lang3.jar:/usr/share/java/gkl.jar:/usr/share/java/gatk-native-bindings.jar:/usr/share/java/barc > lay.jar > > ~/git/med-team/pigx/pigx-scrnaseq$ /usr/bin/java -XX:ParallelGCThreads=1 > -Xmx4G -Xss16M -Djava.io.tmpdir=/tmp -cp $PICARD_CLASSPATH p > icard.cmdline.PicardCommandLine FastqToSam > > With a quick confirmation from > https://stackoverflow.com/questions/15930782/call-java-jar-myfile-jar-with-additional-classpath-option > it seems like some work is needed on the Manifest that accompanies our > libpicard-java package. > > I'll read up how to do that properly in Debian, so our .jar is > compatible with what the community apparently expects. @Andreas, if this > is something close to your routine, please jump in. > I have just looked at picard-tools and I saw that, yesterday, you modified libpicard-java.manifest. I suspect this fixed the test-case you submitted above. Can you confirm? Let me know if the classpath of libpicard-java needs further investigation. > > Best, > > Steffen > > Best, Pierre
Re: Problem when trying to upgrade htsjdk
Hi Andreas, hi everyone, Le 11/09/2020 à 09:08, Andreas Tille a écrit : > Hi, > > I tried to upgrade htsjdk[1] but unfortunately I got some build time > test errors. It would be great if somebody could have a look. > I have looked and tried to build, which succeeded. Then I looked at the log and noticed, to sum up, 4 points: - many tests output to stdout or stderr because they are verbose but they succeed : no problem with them; - the test htsjdk.samtools.SAMSequenceDictionaryTest.testMergeDictionaries[7] outputs an error, but it's OK because it is expected to raise an Exception; - the test htsjdk.samtools.CRAMReferencelessTest.testReadCRAMWithEmbeddedReference outputs several messages like Ignoring SAM validation error: ERROR::INVALID_ALIGNMENT_START:Read name 20FUKAAXX100202:2:1:20271:61529, Mate Alignment start (748) must be <= reference sequence length (200) on reference 20 I guess this is bad, but don't know what to do with it; - the tests htsjdk.samtools.SAMFileWriterFactoryTest.testMakeWriter* output lines like Ignoring SAM validation error: ERROR::HEADER_RECORD_MISSING_REQUIRED_TAG:File /work/testMakeWriterPathbam, Error parsing SAM header. @RG line missing SM tag. Line: @RG ID:1 I don't know either what to do with it. Does anyone have some experience with htsjdk to guide me? Inspecting the inputs of the tests is hard because many files are binary. > > Kind regards > > Andreas. > > Best regards, Pierre
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hello, Le 15/09/2020 à 09:02, Andrius Merkys a écrit : > Hello, > > On 2020-09-15 09:50, Andreas Tille wrote: >> Any idea what to do? Seems like a new dependency[2] but I want to make >> sure whether I'm right here and whether we really need this since it >> sounds pretty unrelated to that program. > > Jsign looks like a developer tool. Should be safe to patch out. > Indeed, and I saw it is only for builds on Microsoft Windows. As Andrius suggests, I have patched build.xml to remove it. I have also added two patches: - letters with accents in a Java annotation were causing build failures; - a useless (and unpackaged) Java package was imported for a test, I removed it. Everything is pushed in Salsa. Whereas the .deb can be built, there are three test failures (I can investigate), and tests errors linked to GPU/OpenCL, outputting thinks like [junit] beignet-opencl-icd: no supported GPU found, this is probably the wrong opencl-icd package for this hardware [junit] (If you have multiple ICDs installed and OpenCL works, you can ignore this message) [junit] [junit] OpenCL error: CL_DEVICE_NOT_FOUND from file , line 122. If someone is fine with those OpenCL issues, please kindly advise me :) beignet-opencl-icd is installed as a dependency of libhmsbeagle-java, which is a (Build-)dependency of beast2-mcmc. Best, Pierre
Re: Git-lfs (Was: RFS: r-bioc-org.mm.eg.db)
Hi, Le 21/09/2020 à 08:43, Andreas Tille a écrit : > Hi again, > > [...] > > I once tried git-lfs for gatk but failed. Could anybody fix the > gatk repository (may be create a new one since as far as I understand > its necessary for git-lfs to declare this at creation time)? I gave > up last year on this task. > Some days ago, I worked on gatk. The most recent upstream tarball is lighter (approx. 50 Mo) and thus I considered creating the usual Git frame master/upstream/pristine-tar. I have just tried to push to current repository but it failed. If it's ok for you, I will create a new repository for gatk in a few hours and handle it normally. > > BTW, having gatk in Debian 11 would be a really great thing as well! > Currently I am facing build issues with Gradle (which is now used by upstream instead of, formerly, Maven). It's quite high on my stack, but if someone wants to work on this sooner it's perfectly fine :) > > Kind regards > >Andreas. > Have a good day, Pierre
Re: Fails to build at my side but works somewhere else
Hi Olivier and Andreas, Le 22/09/2020 à 15:41, olivier sallou a écrit : > On Tue, 2020-09-22 at 07:45 +0200, Andreas Tille wrote: >> [Switching back to mailing list - Olivier explicitly in CC] >> >> Hi, >> >> Olivier, we are talking about package libsis-jhdf5-java which fails >> to >> build in my pbuilder as well as ci.d.n but works for Pierre. I >> remember >> this also happened with htsjdk. > > I did try a build on my side and get some 8 errors > Thanks for attempting to build. The version of libsis-jhdf5-java you tested is indeed one upon which the build results of (Andreas and ci.debian.net) and me are not the same. > >> >> On Mon, Sep 21, 2020 at 11:31:21PM +0200, Pierre Gruet wrote: >>> Thanks for providing me with this log file, it helps. I see 8 >>> failing >>> tests is also what happens in the buildd of ci.debian.net [0]. >> >> Its somehow releaving that I'm not the only one - but I admit I >> wished >> that the error would not occure. :-( >> >>> Yet I am quite puzzled, as everything goes well on my own computer >>> (also >>> with amd64), with either pbuilder or sbuild. I would like to >>> reproduce >>> the issues but I can't. >>> >>> Have you already met such problem before? >> >> I observed that some package did not build for me but for >> others. For >> instance htsjdk did not build for me but Olivier Sallou was >> successful. >> Unfortunately I realised right now he seemed to upload the binary >> package >> instead of the source - so we can not see the log at build- >> infrastructure. >> Olivier, could you please do a source-only upload to let the package >> migrate to testing? >> >>> I will go on trying to understand this tomorrow. >> >> May be we should document this here on our list and seek external >> help >> may be from reproducible builds team since they might have some >> experience with issues like this. Doing the build either inside or outside the chroot on my computer results in all tests passing, I am not able to reproduce the failing tests of ci.debian.net nor either of yours. I will ask debian-ci to see if this is a documented issue, cc-ing debian-med. >> >> Kind regards >> >> Andreas. >> >>> [0] >>> https://ci.debian.net/data/autopkgtest/unstable/amd64/libs/libsis-jhdf5-java/6188493/log.gz Best, Pierre
Tests failing in many chroots but passing in some others
Dear Debian CI project members, In Debian-med we have the package libsis-jhdf5-java. I can build it inside or outside a chroot on my computer with no error concerning build-time tests, which are also run by autopkgtest -- also fine. Two other members of the team have run the same tests in their chroots and got 8 failing tests, which is also the case of ci.debian.net [0]. I would like to know if there have already been such problems with tests failing in some chroots and passing in others; if so, would you have examples or pointers to provide us with? Many thanks in advance, Pierre Gruet [Please CC-me, I have not subscribed to the list] [0] https://ci.debian.net/data/autopkgtest/unstable/amd64/libs/libsis-jhdf5-java/6188493/log.gz
Re: Tests failing in many chroots but passing in some others
Hi Paul, Thanks for the quick answer! Le 22/09/2020 à 22:11, Paul Gevers a écrit : > Hi Pierre, > > On 22-09-2020 21:45, Pierre Gruet wrote: >> Dear Debian CI project members, >> >> In Debian-med we have the package libsis-jhdf5-java. I can build it >> inside or outside a chroot on my computer with no error concerning >> build-time tests, which are also run by autopkgtest -- also fine. >> >> Two other members of the team have run the same tests in their chroots >> and got 8 failing tests, which is also the case of ci.debian.net [0]. >> >> I would like to know if there have already been such problems with tests >> failing in some chroots and passing in others; if so, would you have >> examples or pointers to provide us with? > > What version of Debian is the host running? ci.d.n runs on stable with > some autopkgtest related packages from unstable. > I am running Testing and performing the autopkgtest in a Sid chroot. This is also the case of at least one of the other team members who yet had failing tests. > > > What's the test doing? ci.d.n runs not in chroots, but in lxc's. It's > possible to hit issues there. Typically this requires isolation > restrictions, i.e. isolation-machine. (not saying that the isolation is > needed here, but ...) Thanks for this precision concerning lxc. The failing tests are basically just opening and closing files, counting open files... I think this is not an issue here. > >> Many thanks in advance, >> Pierre Gruet >> >> [Please CC-me, I have not subscribed to the list] >> >> >> >> [0] >> https://ci.debian.net/data/autopkgtest/unstable/amd64/libs/libsis-jhdf5-java/6188493/log.gz > > Paul > Thanks a lot again, Pierre
Re: Fails to build at my side but works somewhere else
Hi Olivier and Andreas, Le 23/09/2020 à 09:27, Andreas Tille a écrit : > On Wed, Sep 23, 2020 at 08:08:01AM +0200, olivier sallou wrote: >>> Given that you also have detailed knowledge in Java do you feel able >>> to >>> fix those 8 issues? That would really help several other packages. >> >> I had a look but could not fix. >> Pierre, for info, I do my testing inside a debian sid docker container. Thanks for telling me! >> >> Don't know if related to hdf5 related binding. Issue seems related to >> deletion of files. >> Some tests *pass* but seem not to delete created files (with >> file.delete or file.deleteOnExit) as expected, leading to other tests >> failure (where they test that library do not contain any file). >> >> I have no hdf5 knowledge. I do not know if deletion could be *delayed* >> depending on machine/chroot/... and lead to test failure because file >> is deleted *too late*... > > When reading this and considering that partly unreproducible results > sometimes are happening due to parallelisation I'm wondering whether > this could be an issue. I admit I can not really see from that Java > command line whether the call is parallelized or not - but may be you > can try to explicitly switch parallel processing off. > Thanks for the idea! Yet, gathering information about the test tool TestNG [0], I see that parallel threads are currently not used for the tests of libsis-jhdf5-java, as no "parallel" parameter is passed in debian/rules nor in sourceTest/java/tests.xml. By adding "-parallel tests -threadcount 4" to the TestNG call in debian/rules, I allow parallel testing but get no failing test. I will be going on investigating... > > Kind regards > > Andreas. > All the best, Pierre [0] https://testng.org/doc/documentation-main.html#running-testng
Re: dependencies on new packages
Hi, Le 24/09/2020 à 11:27, Andrius Merkys a écrit : > Hi Maarten, > > On 2020-09-24 12:21, Maarten L. Hekkelman wrote: >> Suppose you want to submit two separate packages and one depends on the >> other, do you have to wait with the second until the first has been >> accepted and uploaded? Given the time it takes at the moment to process >> packages that might add up to a long period if you have multiple >> packages in a chain, right? > > I don't think you have to wait. I have myself uploaded to NEW packages > that depend on one another, and they went in fine. > > Best, > Andrius > I asked the question on debian-java mailing lists some days ago, I got an answer from Olek Wojnar [0], his personal policy was to be cautious in order to avoid build issues. Indeed, I have already seen many packages not exiting NEW in the order they entered it. >From Andrius' answer, I guess things still go fine quite often... Best, Pierre [0] https://lists.debian.org/debian-java/2020/09/msg00012.html
[RFS] libdistlib-java and charts4j
Hi, I have fixed some missing classpath entries for libdistlib-java and I need to do a source-only upload for charts4j, which has just exited NEW. Would you mine either reviewing them [0] [1] or giving me DM rights? dcut dm --uid "Pierre Gruet" --allow libdistlib-java charts4j (note my key is in the DM keyring in unstable but not in testing yet) Thanks a lot in advance, Pierre [0] https://salsa.debian.org/med-team/libdistlib-java [1] https://salsa.debian.org/java-team/charts4j
Re: [RFS] libdistlib-java and charts4j
Hi Andreas, Le 25/09/2020 à 11:22, Andreas Tille a écrit : > Hi Pierre, > > On Fri, Sep 25, 2020 at 07:50:13AM +0200, Pierre Gruet wrote: >> >> I have fixed some missing classpath entries for libdistlib-java and I >> need to do a source-only upload for charts4j, which has just exited NEW. >> >> Would you mine either reviewing them [0] [1] or giving me DM rights? > > Uploaded since I had to update my debian-keyring package. > >> dcut dm --uid "Pierre Gruet" --allow libdistlib-java charts4j >> (note my key is in the DM keyring in unstable but not in testing yet) > > Granted after my keyring is up to date now to enable you future > uploads of these packages. > > And not to forget: Congratulations that your key is in the DM > keyring! > Thanks a lot! :) I'm very happy about this. And thanks for doing the uploads and granting me those rights! > > Kind regards > > Andreas. > >> [0] https://salsa.debian.org/med-team/libdistlib-java >> [1] https://salsa.debian.org/java-team/charts4j > Best regards, Pierre
Re: Git-lfs (Was: RFS: r-bioc-org.mm.eg.db)
Hi Andreas, Le 21/09/2020 à 13:34, Andreas Tille a écrit : > Hi Pierre, > > On Mon, Sep 21, 2020 at 10:32:54AM +0200, Pierre Gruet wrote: >> Le 21/09/2020 à 08:43, Andreas Tille a écrit : >> >> Some days ago, I worked on gatk. The most recent upstream tarball is >> lighter (approx. 50 Mo) and thus I considered creating the usual Git >> frame master/upstream/pristine-tar. I have just tried to push to current >> repository but it failed. >> >> If it's ok for you, I will create a new repository for gatk in a few >> hours and handle it normally. > > I'll rename the current one to gatk_old. > I thought I would manage to care with git-lfs, but I did not, and faced the same difficulties you met some years ago. So I used the gatk_old repository with only the debian branch to push my new work on gatk -- to be continued. Could you please remove the new (and empty) gatk repository and rename gatk_old to gatk? > > [...] > > Andreas. > Thanks a lot :) Pierre
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hi, Le 21/09/2020 à 09:01, Andreas Tille a écrit : > On Tue, Sep 15, 2020 at 04:04:49PM -0400, Aaron M. Ucko wrote: >> Andrius Merkys writes: >> >>> AFAIR, buildds are not guaranteed to have running X sessions, thus I >>> suggest skipping these tests (most likely by using patches). >> >> For tests that simply require X, another option is to declare build >> dependencies on xauth and xvfb and run them under xvfb-run. OpenCL may >> need different treatment, though. > > That's true but according to my experience the issue did not occured > on the build daemons. > > Apropos testing - may be somebody wants to turn the build time tests > into some autopkgtest? > I have begun working on it. Caring for the tests opened the way to improvements: there are convenience copies of code to remove, paths mixed up between beast-mcmc and beast2-mcmc... > > Kind regards > > Andreas. > Best, Pierre
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hi Andreas, Le 28/09/2020 à 19:47, Andreas Tille a écrit : > Hi Pierre, > > On Mon, Sep 28, 2020 at 06:07:43PM +0200, Pierre Gruet wrote: >>> That's true but according to my experience the issue did not occured >>> on the build daemons. >>> >>> Apropos testing - may be somebody wants to turn the build time tests >>> into some autopkgtest? >> >> I have begun working on it. Caring for the tests opened the way to >> improvements: there are convenience copies of code to remove, paths >> mixed up between beast-mcmc and beast2-mcmc... > > Very cool. Thanks a lot, Andreas. > You are welcome :) I have a question about "best practices": last uploaded version of beast2-mcmc is 2.6.3+dfsg-2, but I will need to repack the tarball to remove some convenience copies of code. What would you do concerning the version number? I would consider something like 2.6.3+dfsg-1 for the upstream version and 2.6.3+dfsg-1-1 for the Debian revision... but maybe juste removing cruft is not worth increasing the version and 2.6.3+dfsg-3 would be fine for the next upload? Thanks in advance, Pierre
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hi again Andreas, Le 28/09/2020 à 21:36, Andreas Tille a écrit : > On Mon, Sep 28, 2020 at 08:23:11PM +0200, Pierre Gruet wrote: > >> I have a question about "best practices": last uploaded version of >> beast2-mcmc is 2.6.3+dfsg-2, but I will need to repack the tarball to >> remove some convenience copies of code. >> What would you do concerning the version number? I would consider >> something like 2.6.3+dfsg-1 for the upstream version and 2.6.3+dfsg-1-1 >> for the Debian revision... but maybe juste removing cruft is not worth >> increasing the version and 2.6.3+dfsg-3 would be fine for the next upload? > > I would use > > 2.6.3+dfsg1-1 > > (without the '-' between dfsg and 1). That's something I have seen > frequently. > Thanks for your advice! Nevertheless, this seems to rank before the current version number, as echo "2.6.3+dfsg-2,2.6.3+dfsg1-1" | tr ',' '\n' | sort --version-sort outputs 2.6.3+dfsg1-1 2.6.3+dfsg-2 Yet I understand you mean the upstream version number should be changed. For instance T could thus use 2.6.3+dfsg.1-1, which is a bit ugly but sorts well. Please kindly tell me if this sound unreasonable to you. > > Kind regards > > Andreas. > Thanks again for the advice, Pierre
Re: Beast-mcmc2 upgrade is missing class net.jsign.JsignTask
Hi Andrius, Le 29/09/2020 à 07:57, Andrius Merkys a écrit : > Hi Pierre, > > On 2020-09-28 22:47, Pierre Gruet wrote: >> Thanks for your advice! Nevertheless, this seems to rank before the >> current version number, as >> >> echo "2.6.3+dfsg-2,2.6.3+dfsg1-1" | tr ',' '\n' | sort --version-sort >> >> outputs >> >> 2.6.3+dfsg1-1 >> 2.6.3+dfsg-2 > > Debian (dpkg) uses slightly different mechanism for version comparison > than 'sort': > > dpkg --compare-versions 2.6.3+dfsg-2 '<<' 2.6.3+dfsg1-1 && echo LESS > > outputs 'LESS'. > Thank you for pointing this out! I should have referred to the Developer's reference as i have just seen dpkg --compare-versions is presented there. > > Thus AFAIK it is usual for '+dfsg1' to follow '+dfsg'. > Very well then :-) > > Best, > Andrius > Best regards, Pierre
[RFS] beast2-mcmc
Hi, I have worked on beast2-mcmc: autopkgtests have been added, which came along with some patches. Would you mind either reviewing [0] or giving me DM rights? dcut dm --uid "Pierre Gruet" --allow beast2-mcmc Thanks a lot in advance, Pierre [0] https://salsa.debian.org/med-team/beast2-mcmc
Sepp : including a dataset?
Hi, I have almost finished the initial packaging of sepp [0]. Beside the sepp program, upstream also provides the tipp program in the same tarball. Basically, tipp classifies sequences using sepp and a collection of alignments and placements data and statistical methods. People installing tipp are invited to download a dataset (approx. 240Mo) [1] which does not belong to the same Github repository and has no license information inside it. Technically, I guess we might consider creating a sepp-data package with those data, but I also imagine this is not really feasible if we don't have much information about where those data come from, who collected them, ... Based on your experience, would you have some advice on this? My proposal is to let tipp aside and only focus on sepp, which is ready. Thanks a lot, Pierre [0] https://salsa.debian.org/med-team/sepp [1] https://github.com/tandyw/tipp-reference/
Re: Sepp : including a dataset?
Hi Andreas, Le 07/10/2020 à 22:43, Andreas Tille a écrit : > Hi Pierre, > > On Wed, Oct 07, 2020 at 10:30:34PM +0200, Pierre Gruet wrote: >> I have almost finished the initial packaging of sepp [0]. Beside the >> sepp program, upstream also provides the tipp program in the same >> tarball. Basically, tipp classifies sequences using sepp and a >> collection of alignments and placements data and statistical methods. >> People installing tipp are invited to download a dataset (approx. 240Mo) >> [1] which does not belong to the same Github repository and has no >> license information inside it. >> >> Technically, I guess we might consider creating a sepp-data package with >> those data, but I also imagine this is not really feasible if we don't >> have much information about where those data come from, who collected >> them, ... >> >> Based on your experience, would you have some advice on this? My >> proposal is to let tipp aside and only focus on sepp, which is ready. > > If the data are not part of the source tarball it might be an option > to provide both executables and add the documentation you are quoting > above. Thanks for the advice, this might be the most suitable idea then. I will do so. > > Kind regards > >Andreas. > Best, Pierre >> [0] https://salsa.debian.org/med-team/sepp >> [1] https://github.com/tandyw/tipp-reference/ >> >> >
Bug#971870: ITP: sepp -- methods using ensembles of Hidden Markov Models (HMM)
Package: wnpp Severity: wishlist Owner: Debian-med project X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: sepp Version : 4.3.10 Upstream Author : Siavash Mirarab * URL : https://github.com/smirarab/sepp/ * License : GPL-3 Programming Lang: Python, Java Description : methods using ensembles of Hidden Markov Models (HMM) The tools SEPP and TIPP implementing these methods use ensembles of Hidden Markov Models (HMMs) in different ways, each focusing on a different problem. SEPP stands for "SATe-enabled Phylogenetic Placement", and addresses the problem of phylogenetic placement of short reads into reference alignments and trees. TIPP stands for "Taxonomic Identification and Phylogenetic Profiling", and addresses the problem of taxonomic identification and abundance profiling of metagenomic data. This package is useful to treat genomic data and will be maintained by Debian-med.
[RFS] sepp
Hi, I have finished the initial packaging of sepp [0]. Could someone please review it and sponsor if everything is OK? As discussed recently on the list, the binary package sepp includes programs called sepp and tipp, the last one needing the user to download a given dataset to be run. This is documented in README.Debian and in the manpage of the program. Upstream also provides a third program called upp. It is of minor importance compared to sepp and tipp and needs pasta, which is not packaged yet, as a dependency. I felt it would be better to have sepp and tipp without upp in bullseye than to have none of them, so I deactivated everything related to upp -- but it is ready and only needs pasta to be packaged. Thanks a lot in advance, Pierre [0] https://salsa.debian.org/med-team/sepp
Re: [RFS] sepp
Hi Andreas and Steffen, Le 09/10/2020 à 18:37, Steffen Möller a écrit : > ;) You win! > > Thanks! > > Steffen > > On 09.10.20 18:33, Andreas Tille wrote: >> On Fri, Oct 09, 2020 at 06:32:55PM +0200, Steffen Möller wrote: >>> @Andreas et al., I'll happily sponsor. >> Ups, just receiving this. I'm keen on seeing who will win this >> race condition. My upload is done and my change pushed. >> >> Kind regards >> >> Andreas. >> > Many thanks for your time and support :-D Warm regards, Pierre
[RFS] jebl2
Hi, I have worked on jebl2 which has a new upstream version. Would you mind either reviewing [0] or giving me DM rights? dcut dm --uid "Pierre Gruet" --allow jebl2 Thanks a lot in advance, Pierre [0] https://salsa.debian.org/med-team/jebl2
Re: [RFS] jebl2
Hi Andreas, Le 13/10/2020 à 09:40, Andreas Tille a écrit : > Hi Pierre, > > On Mon, Oct 12, 2020 at 09:34:04PM +0200, Pierre Gruet wrote: >> I have worked on jebl2 which has a new upstream version. > > Ahhh, I did so yesterday evening without actually reading your mail. ;-) > No problem, really :) > >> Would you mind either reviewing [0] or giving me DM rights? >> >> >> dcut dm --uid "Pierre Gruet" --allow jebl2 > > I did so now to enable you for the next time. ;-) > In principle I prefer making people work self standing so > I simply should become used to it that you are DM now. > Thanks for the upload and for allowing me to do further uploads. And once again, this is not really a problem as the package got sent, which is the essential thing! > > Thanks a lot for your work on this > > Andreas. > All the very best, Pierre
Re: Tests failing in many chroots but passing in some others
Hi Paul, Le 22/09/2020 à 22:11, Paul Gevers a écrit : > Hi Pierre, > > On 22-09-2020 21:45, Pierre Gruet wrote: >> Dear Debian CI project members, >> >> In Debian-med we have the package libsis-jhdf5-java. I can build it >> inside or outside a chroot on my computer with no error concerning >> build-time tests, which are also run by autopkgtest -- also fine. >> >> Two other members of the team have run the same tests in their chroots >> and got 8 failing tests, which is also the case of ci.debian.net [0]. >> >> I would like to know if there have already been such problems with tests >> failing in some chroots and passing in others; if so, would you have >> examples or pointers to provide us with? > > What version of Debian is the host running? ci.d.n runs on stable with > some autopkgtest related packages from unstable. > > What's the test doing? ci.d.n runs not in chroots, but in lxc's. It's > possible to hit issues there. Typically this requires isolation > restrictions, i.e. isolation-machine. (not saying that the isolation is > needed here, but ...) > Some weeks ago I wrote you about tests in a Java package of Debian-med, that were failing on some computers and passing on others. I have just found this was due to a file not being closed with the close() method. Afterwards some other tests were counting open files and failing because of this file not being closed whereas they expected it. I guess the Java garbage collector was closing the file early enough on some computers, and not on others. Maybe this case will help in the future when meeting other such situations. >> Many thanks in advance, >> Pierre Gruet >> >> [Please CC-me, I have not subscribed to the list] >> >> >> >> [0] >> https://ci.debian.net/data/autopkgtest/unstable/amd64/libs/libsis-jhdf5-java/6188493/log.gz > > Paul > Thanks again for caring, Pierre
Bug#972554: ITP: icb-utils -- Java library of utilities to manage files and compute statistics
Package: wnpp Severity: wishlist Owner: Debian-med project X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: icb-utils Version : 2.0.1+git20161002.afee1d9 Upstream Author : Fabien Campagne * URL : https://github.com/CampagneLaboratory/icb-utils * License : Apache-2.0 Programming Lang: Java Description : Java library of utilities to manage files and compute statistics icb-utils is a group of tools originally designed by the Campagne laboratory for computational biomedicine software. They include extensions of standard Java to manage io, extended iterator classes, hashtables, network-related classes, as well as a set of classes allowing for the computation of statistics. This software is needed as a predependency for igv, currently in non-free. It is also a dependency of several software Debian-med is willing to package. The package will be taken care of in Debian-med team.
[RFS] icb-utils
Hello, I have prepared the package icb-utils [0], which is a dependency of goby, itself needed to move igv from non-free to main... It is a NEW source package and thus would need a review and upload when time permits. Thanks a lot in advance, Pierre [0] https://salsa.debian.org/med-team/icb-utils/
[RFS] icb-utils
Hello, icb-utils has just exited NEW; I have prepared a source-only upload. Would you mind either reviewing [0] or giving me DM rights? dcut dm --uid "Pierre Gruet" --allow icb-utils Thanks a lot in advance, Pierre [0] https://salsa.debian.org:med-team/icb-utils
Bug#973568: ITP: libpj-java -- API and middleware for parallel programming in Java
Package: wnpp Severity: wishlist Owner: Debian-med project X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: libpj-java Version : 20150107 Upstream Author : Alan Kaminsky * URL : https://www.cs.rit.edu/~ark/pj.shtml * License : GPL-3+ Programming Lang: Java Description : API and middleware for parallel programming in Java Parallel Java (PJ) is for parallel programming in 100% Java on shared memory multiprocessor (SMP) parallel computers, cluster parallel computers, and hybrid SMP cluster parallel computers. PJ was developed in the Department of Computer Science at the Rochester Institute of Technology. libpj-java is needed as a dependency of goby, which is itself needed in the ongoing efforts in Debian-med to package igv in the main section. It will be maintained inside the Debian-med team.
[RFS] libpj-java
Hi, I have prepared the initial packaging of libpj-java, a dependency of goby (needed for igv). If someone would have time to review it [0] and upload if convenient, it would be great :) Thanks a lot, Pierre [0] https://salsa.debian.org/med-team/libpj-java
Bug#963630: RFS-ing libaparapi-java due to licensing issues at the moment
Control: retitle -1 RFS: libaparapi-java -- framework for executing native Java code on the GPU I am changing the ITP bug to RFS because the wording of the license still precludes packaging. The blocking part is the last paragraph in ATTRIBUTIONS.md: it does not seem to be harming when considering packaging aparapi itself, but it would impose restrictions on other software that might be bundled with it. We will discuss it with upstream and consider packaging later. Pierre Gruet
Bug#963630: RFP-ing libaparapi-java due to licensing issues at the moment
Control: retitle -1 RFP: libaparapi-java -- framework for executing native Java code on the GPU (this is RFP and not RFS, sorry...) I am changing the ITP bug to RFP because the wording of the license still precludes packaging. The blocking part is the last paragraph in ATTRIBUTIONS.md: it does not seem to be harming when considering packaging aparapi itself, but it would impose restrictions on other software that might be bundled with it. We will discuss it with upstream and consider packaging later. Pierre Gruet
[RFS] igv
Hi everyone, I have fixed the RC bug in igv. Would you mind either reviewing [0] or giving me DM rights? dcut dm --uid "Pierre Gruet" --allow igv Thanks a lot, Pierre [0] https://salsa.debian.org/med-team/igv
[RFS] artemis
Hi, artemis had only a superficial autopkgtest not marked as such. I have marked it and provided another autopkgtest running some build tests. Would you mind either reviewing [0] or giving me DM rights? dcut dm --uid "Pierre Gruet" --allow artemis Thanks a lot, Pierre [0] https://salsa.debian.org/med-team/artemis
Re: Help to finalise libjloda-java needed
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: Help to finalise libjloda-java needed
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
Progress of Snpeff packaging (Was: Re: /usr/bin/picard Re: bcbio will need another while - needs gatk)
Hi, Le 15/11/2020 à 18:16, Andreas Tille a écrit : > >> >> This may be worth a sidenote - bcbio to me is something metaphorical. We >> have it in the distribution already. And now we work to get all the >> runtime-dependencies in to make it functional. And snpEff is pretty high >> up (it interprets the importance of nucleotide variations, you need to >> have identified these variants for that, first). So, my comment on >> "snpeff" being invoked was to be interpreted as "see, here we are already". > > Snpeff is wanted from several sided. I really hope we get it soon. > It's good we talk about it. There were 4 identified missing packages to be able to complete the packaging of Snpeff; 3 of them are now in Debian, only akka-actor misses. akka-actor is part of akka, this is a framework for concurrent programming written in Scala. And here is the problem: we have Scala 2.11 in Debian, current upstream version is 2.13 and akka would need at least 2.12. Also, Scala 2.12 and 2.13 would need Scala Build Tool (sbt) in order to be built, and sbt in turns requires Scala 2.12 or 2.13. I guess at some point, this loop did not exist and there might be an old version of either sbt or Scala which could be built with what we currently have in Debian. But this is quite a lot of work, and I feel no one is willing to do it now -- perhaps that Scala thing is quite peculiar and we would need someone with time and high skills. In September I exchanged a few emails with a colleague of Steffen, who knows Scala. While he helped a lot on understanding some aspects of the language, he does not know about the Debian workflow -- which is plainly understandable -- and thus we are, so far, left with the current issue. Maybe we should see if there is another framework for concurrent programming in pure Java that we could fit into Snpeff by writing patches... > > Kind regards > >Andreas. > Bye, Pierre
Re: libsis-jhdf5-java hasn't migrated to testing since last 18 days
Hi Nilesh and Andreas, Le 26/11/2020 à 17:14, Andreas Tille a écrit : Hi Nilesh, On Thu, Nov 26, 2020 at 06:00:38PM +0530, Nilesh Patra wrote: It seems that libsis-jhdf5-java hasn't migrated to testing due to build failure on s390x, log attached[1] This is preventing a chain of other packages which are stalled to testing migration as well. Could you please have a look at this? Thanks for the heads up. IMHO we should not spent to much time into those architectures that are very uncommon in our field of work. I'm going to file a bug report to remove libsis-jhdf5-java for architecture s390x. May be we can address this later but the migration should not be blocked. > Thanks for raising the issue; actually it was on my before-bullseye-release todo but I did not have in mind the issue was blocking so many packages. Thus I guess the bug Andreas has filled is the best thing to do for now. Concerning the issue itself, it is raised by the unexpected behaviour of a function which is in the hdf5 source package. This appears while proceeding the tests, so could indicate an issue in hdf5 for s390x or something improperly done within the tests themselves... To be investigated. Kind regards Andreas. Bye, Pierre
Packaging Jalview -- any general guidelines concerning privacy?
Hello, I'm currently on the packaging of Jalview. I would like to get some advice as Jalview upstream is collecting statistics on its use through the Internet. Basically this amounts to 4 things, I'm quoting/commenting their documentation: - HTTP logs on the Jalview website We record IP addresses of machines which access the web site, either via the browser when downloading the application, or when the Jalview Desktop user interface is launched. - Questionnaires, from time to time The questionnaire web service at www.jalview.org/cgi-bin/questionnaire.pl is checked and a unique cookie for the current questionnaire is stored in the Jalview properties file. - The Jalview web services stack is contacted to retrieve the currently available web services. All interactions with the public Jalview web services are logged, but we delete all job data (input data and results) after about two weeks. - Google Analytics, used if user explicitly consents Since Jalview 2.4.0b2, the Jalview Desktop records usage data with Google Analytics via the JGoogleAnalytics class. The Google Analytics logs for Jalview version 2.4 only record the fact that the application was started, but in the future, we will use this mechanism to improve the Desktop user interface, by tracking which parts of the user interface are being used most often. I would like to know if you have general practice or advice to give concerning this: can we package as is or do we need to take some special care about privacy? If you have some pointers to provide me with, I will also be very happy. Thanks a lot for reading, Pierre
Re: Packaging Jalview -- any general guidelines concerning privacy?
Hi Andreas,
Le 27/11/2020 à 09:22, Andreas Tille a écrit :
Hi Pierre,
On Thu, Nov 26, 2020 at 10:11:14PM +0100, Pierre Gruet wrote:
>> [...]>>
- HTTP logs on the Jalview website
We record IP addresses of machines which access the web site, either via
the browser when downloading the application, or when the Jalview Desktop
user interface is launched.
- Questionnaires, from time to time
The questionnaire web service at
www.jalview.org/cgi-bin/questionnaire.pl is checked and a unique cookie for
the current questionnaire is stored in the Jalview properties file.
- The Jalview web services stack is contacted to retrieve the currently
available web services. All interactions with the public Jalview web
services are logged, but we delete all job data (input data and results)
after about two weeks.
- Google Analytics, used if user explicitly consents
Since Jalview 2.4.0b2, the Jalview Desktop records usage data with
Google Analytics via the JGoogleAnalytics class.
The Google Analytics logs for Jalview version 2.4 only record the fact
that the application was started, but in the future, we will use this
mechanism to improve the Desktop user interface, by tracking which parts of
the user interface are being used most often.
This all sounds like privacy violations from a Debian point of view -
at least if this is implemented as default.
I would like to know if you have general practice or advice to give
concerning this: can we package as is or do we need to take some special
care about privacy?
If you have some pointers to provide me with, I will also be very happy.
I've never seen those things before. The only thing set of packages
that was collecting user data systematically were those using
pp-popularity-contest. This was some agreement with the lab where a
set of software was developed and where the funding was dependant from
the number of users.
Regarding Jalview the license permits us to change the code and to patch
this out. While this would be probably the easiest means we could to in
the interest of our users it would probably be not fair against upstream.
I wonder whether it would be really hard to provide some kind of opt-in
mechanism that can be controlled via a debconf question. However, if
this is really hard to implement I'd vote for patching things out in a
first update of this package and leave the enhancement for later.
Thanks for the detailed answer. Concerning the Google Analytics part, is
uses a class that is not in Debian and is also poorly licensed in my
opinion, so this will be deactivated in any case.
For the rest, I think I could join upstream so that a fair decision can
be made. Maybe the popularity-contest information can be informative enough.
Anyway, although all that you said makes much sense, would you know of
any assessment of Debian rules and priorities concerning privacy, beyond
the DFSG?
Thanks a lot for reading,
Thanks a lot for working on this!
Kind regards
Andreas.
Best regards,
Pierre
PS: I have one more Java issue. As the ITP bug #956838 shows there are
some remaining JARs which I overlooked :-( in r-cran-rcdk. If I
remove these JARs the build fails with
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for 'rcdk':
.onLoad failed in loadNamespace() for 'rcdk', details:
call: .jnew("org/openscience/cdk/formula/rules/NitrogenRule")
error: java.lang.ClassNotFoundException
Error: loading failed
Execution halted
Its definitely a Java problem but somehow hidden in the R build system
and I have no idea where to ask how to fix
https://salsa.debian.org/r-pkg-team/r-cran-rcdk
Acknowledged! I will answer in the bug thread.
