Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi all, Le 29/12/2023 à 14:07, Andreas Tille a écrit : Am Wed, Dec 27, 2023 at 09:43:19PM +0100 schrieb Steffen Möller: for teaching and meeting reasons. But as I just wrote, 17-18 also works. I'd opt for the earlier date, so we have a bit of a break before some of us I expect to bump into each other again in Hamburg if Holger's event materialises a month later. Well, but there is FOSDEM 3+4. February - so this is even more dense. I'd love to fix 17-18. February (or lets meet at 16.2. February evening inside the water tower like last year.) So let's fix it, there is no perfect slot but at least it allows us to move forward with the bookings. I don't remember having read possible constraints from you Étienne? I will probably not be able to join in the water tower on the 16th, but no worry about this. Kind regards Andreas. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Last call for any other location than Berlin (Was: Any suggestions for next Debian Med sprint (in person meeting)?)
Hi all, Le 21/12/2023 à 16:15, Sascha Steinbiss a écrit : Hi, [...] How about Feb 10-11, for example? My weekends are still free for now so it's your choice. I admit I'd prefer Feb. 17-18 over 10-11. Other opinions? I will be available on both weekends, although I prefer 10-11 over 17-18 for teaching and meeting reasons. But as I just wrote, 17-18 also works. Fine with me! Cheers Sascha Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
[Advent bug squashing] Bug #1058683 : incompatibility between igv and htsjdk
Hello, I fixed bug #1058683, which showed up in igv after an important upgrade of htsjdk. Great idea to improve one's Advent bug squashing metrics: upgrade software, break things, fill bugs, fix them. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Thanks a lot [ftpmas...@ftp-master.debian.org: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable]
Hi Andreas, Le 12/12/2023 à 20:05, Andreas Tille a écrit : Hi Pierre, this is really good and important work. Thanks a lot for it You're welcome! I am astonished to see it cleared NEW in one hour anf a half, I had not even the time to prepare my Advent Calendar email related to it. That said, I am always very happy when we move software out of non-free! Bug #1032688 was solved by you, and bug #1010358 by Michael :) Andreas. Best, -- Pierre - Weitergeleitete Nachricht von Debian FTP Masters - Date: Tue, 12 Dec 2023 19:00:13 + From: Debian FTP Masters To: Debian Med Packaging Team , Pierre Gruet Subject: ugene_49.1+dfsg-1_amd64.changes ACCEPTED into unstable Thank you for your contribution to Debian. Accepted: Format: 1.8 Date: Tue, 12 Dec 2023 14:49:53 +0100 Source: ugene Binary: ugene ugene-data ugene-dbgsym Architecture: source all amd64 Version: 49.1+dfsg-1 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Pierre Gruet Description: ugene - integrated bioinformatics toolkit ugene-data - required data for UGENE - integrated bioinformatics toolkit Closes: 1010358 1018252 1032688 Changes: ugene (49.1+dfsg-1) unstable; urgency=medium . * Team upload * New upstream version 49.1+dfsg * Refreshing patches * Shipping to main instead of non-free (Closes: #1018252): - Excluding files with non-free license (*.so and psipred) - Rewriting d/copyright * Updating install paths * Setting the runpaths so that private shared libraries can be found * Fixing spelling mistakes * Using python3 instead of python in shebangs * Fixing Lintian override syntax * Overriding Lintian warnings about spelling errors due to false positives . [ Andreas Tille ] * Fix watch file * Standards-Version: 4.6.2 (routine-update) * Build-Depends: s/libprocps-dev/libproc2-dev/ (Closes: #1032688) . [ Michael R. Crusoe ] * debian/patches/Fix-for-non-constant-SIGSTKSZ.patch: from Ubuntu, Closes: #1010358 Checksums-Sha1: 94b7823fb1fc97799fbfe4df06950b8651d6ae7c 2290 ugene_49.1+dfsg-1.dsc 5a8f61ab1ef8a884ffd57cd5ee8f8c2cb4a8c594 16227828 ugene_49.1+dfsg.orig.tar.xz f7c9a78fda51e047a8c1630d98c5b9deb9d4e39b 40636 ugene_49.1+dfsg-1.debian.tar.xz 024ec6144aecdde337e85fd01371704ab0bdd4b0 7612600 ugene-data_49.1+dfsg-1_all.deb 3581df8eda69842e4d996c76428bf4384c85bd6d 608828980 ugene-dbgsym_49.1+dfsg-1_amd64.deb 8513bc897a1929f09f843b28f9460adf1f99ad67 13359 ugene_49.1+dfsg-1_amd64.buildinfo c5361fc2e28811066b4f6d687437d66b0b8ed183 22210740 ugene_49.1+dfsg-1_amd64.deb Checksums-Sha256: d6b50935c791298da631f297312be1a56f97684acefb2f462152d4f9cb544feb 2290 ugene_49.1+dfsg-1.dsc 0e84cb5ebc26bacddd0d538b9ccf0906c49ac867a39cc81c033f8d3adf796b6d 16227828 ugene_49.1+dfsg.orig.tar.xz 8dfa17a74603f24075957774dd602d7bf1e27c5c3494aca5fbb690f7fd5ac793 40636 ugene_49.1+dfsg-1.debian.tar.xz 73a0e7773901fc7bf59488ace2ef35c5d04dba0db5af8fbb9912da4cbe1560b2 7612600 ugene-data_49.1+dfsg-1_all.deb f627e3ca06edc61b7fff9ff33af4f5b0da70e7b1ae9e45d6e4220351c3fa5030 608828980 ugene-dbgsym_49.1+dfsg-1_amd64.deb 954a1daca20405613f306cdbba456a469ebab70b3a94711e33d56dbd4515582b 13359 ugene_49.1+dfsg-1_amd64.buildinfo 18b07770fb8abd57a756f2454386e1df0c0290b239923b21ac14b40832b204c3 22210740 ugene_49.1+dfsg-1_amd64.deb Files: 4741a35a40dff8d6a425ea8d2772e62f 2290 science optional ugene_49.1+dfsg-1.dsc c2423d8701dc5fb5a007684882d3d167 16227828 science optional ugene_49.1+dfsg.orig.tar.xz 8a36134d6fed4abd7e1424770ec7 40636 science optional ugene_49.1+dfsg-1.debian.tar.xz 5be3f6a848d90b76512e81251b53cd83 7612600 science optional ugene-data_49.1+dfsg-1_all.deb c31a479dfc5ba8d9b8982ac92662e1ea 608828980 debug optional ugene-dbgsym_49.1+dfsg-1_amd64.deb f336fa8fdc484f38d594f6d1784fdab2 13359 science optional ugene_49.1+dfsg-1_amd64.buildinfo 180f6b1502a223163062a95437b1bd96 22210740 science optional ugene_49.1+dfsg-1_amd64.deb ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging - Ende weitergeleitete Nachricht - OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Could some SnpEff user from the community please ping authors
Hi Nilesh, Le 05/12/2023 à 21:30, Nilesh Patra a écrit : On Tue, Nov 28, 2023 at 05:54:30PM +0100, Andreas Tille wrote: I wonder whether some people from the community might be able to join our attempt to get this issue fixed and raise their voice inside the Github issue (or use other channels) to get this finally fixed. I guess the problem does not only occure in snippy test suite but also in other pipelines so the community might be affected by this issue. [1] https://github.com/pcingola/SnpEff/issues/455 Sometimes just tagging upstream author does wonders :) Yeah! Thanks for having done so. I also saw his answer today. I have the test case of Andreas' colleagues settled down on my computer, I will take time in the upcoming days to check that upstream's trick can allow us to circumvent #1029202. They have replied and the (upstream) bug has been closed. BTW, are you able to still reproduce (without any fixes for snpeff/snippy) #1031465? For me, it is working fine in an unstable chroot (including autopkgtests) and maybe could be closed. Thanks also for having verified this; if you checked this in a chroot I guess you can just close the bug. Best, Nilesh Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
[Advent bug squashing] 9 bugs
Hi, Fixing minor bugs #1043696, #1045612, #1046315, #1046647, #1046802, #1046809, #1047000, #1048408, #1049745. Not crucial, but they offer the opportunity to do some housekeeping in our packages! Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: genomicsdb not migrating and new upstream version
Hi Andreas, Le 27/11/2023 à 11:31, Andreas Tille a écrit : Hi Pierre, I realised that you've fixed bug #1054675 (thanks for doinig so) but You're welcome! :) that several architectures are failing to build[1] which I do not understand when looking at the build logs. Since there was a new upstream version I imported this and tried to adapt the patches. Unfortunately the new version does not build. I've switched on Salsa CI to late so we do not have build logs there but I guess you will be able to reproduce the failure at your site. It would be great if you could have a look. Yes, since I first packaged genomicsdb I have only had it build on amd64 and mips64el, on the other architectures there are test failures. I tried to investigate them with gdb but have not been successful for the moment. (Basically) the source package builds an Architecture: all package and an Architecture: any one, the former depending on the latter, and the transition tracker complains about this situation only for arm64 even though the build is failing on many other architectures. Up to now it has not prevented genomicsdb to migrate. This time it did... I guess it is reasonable to spend time on investigating the tests failures with the debugger, I admit I have not committed to do so up to now. I fixed the issue with the build of version 1.5.1 which you updated, yet another error fills in the place and I shall look at it a bit later. It is pushed to Salsa. Thanks a lot for your work on this package Andreas. [1] https://buildd.debian.org/status/package.php?p=genomicsdb Let's hope this can get solved quickly! Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Any suggestions for next Debian Med sprint (in person meeting)?
Hi Andreas, Le 02/11/2023 à 17:27, Andreas Tille a écrit : Hi, its autumn so we should prepare for winter. For Debian Med winter is the time where we usually do our in person meeting. The last meetings were in a perfectly fitting location in Berlin and I for myself would be fine to meet there again. If someone knows better option (also better for *you* to reach *your* location) do not hesitate to make to propose alternatives. No better idea from my part. The location in Berlin was actually fine and I cannot propose a better (also closer to me) place. Last time we discussed this, you evoked a place in Hamburg. Which would not change a lot of things for me compared to Berlin. I'd be happy if we could find some decision in the next 2-3 weeks since we probably need some time to organise the travel for people coming from a distant. I'd love if Nilesh would manage to come this year and visa things would be more successfully than last year. Same here! Kind regards Andreas. Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Java help for bbmap needed
Hi Andreas, Le 18/10/2023 à 18:48, Andreas Tille a écrit : Hi Pierre (or whoever wants to take this task), I tried to upgrade bbmap but failed[1]. I stumbled upon the line: jh_build: error: find current -name '*.java' -and -type f -print0 | xargs -s 512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp /usr/share/java/mpi.jar:debian/_jh_build.bbmap -d debian/_jh_build.bbmap -encoding ISO8859-1 -source 7 -target 7 returned exit code 123 since we should probably have "-source 8 -target 8" instead but I have not found any string '-source' inside the source tarball. So may be here is some magic in the Jave build process. I can only guess whether those build errors might vanish if source/target=8 is used and would be really happy if someone with Java experience could have a look on this possibly simple issue. Thanks for drawing my attention on this. In fact the issues were few lines before the quoted part, there were 4 calls to non existing methods or fields in Java classes. I guess upstream does not see this because they have an ad-hoc build script which probably does not compile all classes. So it is likely there is some vintage code here, that could be removed. I opened a ticket on the page of BBmap to say so and I uploaded the Debian package with some fixes to correct the 4 errors! Kind regards Andreas. [1] https://salsa.debian.org/med-team/bbmap/-/jobs/4824812 Best, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: New CamiTK 5.1.0 release
Hello Emmanuel, Le 29/08/2023 à 17:48, Emmanuel Promayon a écrit : Dear Pierre, On 25/08/2023 22:46, Pierre Gruet wrote: Sorry, it seems your questions have remained unanswered for quite some time. Vacations, summer, ...! No problem at all, vacations is really important! On my setup, everything seems to be ready for upload, but I did not tag the master branch with the debian/5.1.0 tag, as I am not 100% sure that everything is valid (as always it seems ok on my side, but I might have missed something). About this: I could not get the upstream source from the upstream/pristine-tar branches of the Salsa repository, and launching "uscan" did not allow me to grasp version 5.1.0. Do you think you could fix this? I can have a look afterwards. my bad, I forgot to run gbp import orig (and then push the tags as well...) It should be better now. Let me know if this sounds right (my experience of packaging is very casual and therefore full of gaps). I think the pristine-tar branch has not been updated, you may fix this if you have time; anyway, I could build, and it looks good, so I uploaded. The package got built on the autobuilders, yet I just saw this in the build log [0] : dpkg-shlibdeps: warning: cannot find library libjawt.so needed by debian/camitk-actionstatemachine/usr/bin/camitk-actionstatemachine (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libjvm.so needed by debian/camitk-actionstatemachine/usr/bin/camitk-actionstatemachine (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libjawt.so needed by debian/libcamitk-dev/usr/bin/camitk-cepgenerator (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libjvm.so needed by debian/libcamitk-dev/usr/bin/camitk-cepgenerator (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libjawt.so needed by debian/libcamitk-dev/usr/bin/camitk-testactions (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') dpkg-shlibdeps: warning: cannot find library libjvm.so needed by debian/libcamitk-dev/usr/bin/camitk-testactions (ELF format: 'elf64-x86-64' abi: 'ELF:64:l:amd64:0'; RPATH: '') I wonder if some symbols fail to be found at runtime, or if the packages with the mentioned libs are in the dependencies of the package? Maybe you could do some additional tests with the Debian-packaged camitk to be sure there is no problem. Best regards, Emmanuel Let us know if anything goes wrong, Best regards, -- Pierre [0] https://buildd.debian.org/status/fetch.php?pkg=camitk=amd64=5.1.0-1=1693555686=0 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: New CamiTK 5.1.0 release
Hi Emmanuel,
Sorry, it seems your questions have remained unanswered for quite some
time. Vacations, summer, ...!
Le 28/07/2023 à 13:27, Emmanuel Promayon a écrit :
Dear all,
CamiTK 5.1.0 was released upstream and I have updated the package on
salsa accordingly. It is now fully compatible with VTK9 and should
hopefully be able to migrate back to testing flawlessly!
I found out that VTK9 includes java by default (and it does not seem
possible to avoid it, although it is not required by all VTK modules). I
suppose that breaking vtk into more packages (or just have a vtk9-java
package) requires a lot of work, but that would be nice!
The inclusion of Java by default (even if not used/required by camitk at
all) generated a problem during the autopkgtest process. It seems that
the java libs are not included in the default system linker path. I had
to add the Java lib path to the LD_LIBRARY_PATH at the beginning of the
two autopkgtest scripts (test/config-test.sh and cepgenerator-test.sh):
export JAVA_HOME=/usr/lib/jvm/default-java
export LD_LIBRARY_PATH=${JAVA_HOME}/lib/:${JAVA_HOME}/lib/server/
(btw, thanks to a lot to Pierre Gruet who had already done that in d/r,
it was a great inspiration!)
Does anyone know if that's the expected behavior, if I missed something
somewhere in the camitk dependencies, or in the packaging setup?
You're welcome, I had even forgotten about this!
I think traditional Java libraries are not expected to use the shared
libs of java, they are there for the executables that come along the
JRE/JDK.
But as you say, it can happen that we rely on them.
On my setup, everything seems to be ready for upload, but I did not tag
the master branch with the debian/5.1.0 tag, as I am not 100% sure that
everything is valid (as always it seems ok on my side, but I might have
missed something).
About this: I could not get the upstream source from the
upstream/pristine-tar branches of the Salsa repository, and launching
"uscan" did not allow me to grasp version 5.1.0. Do you think you could
fix this?
I can have a look afterwards.
Can someone please have a look and tag+upload if everything seems correct?
Thank you in advance for your feedback and all your help along the way.
Best regards,
Emmanuel
Best,
--
Pierre
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Volunteer request
Hello Rakesh, Welcome! Le 25/08/2023 à 14:26, Andreas Tille a écrit : Hi, [...] Admittedly, I'm very busy with other things, so I defer MoM stuff to Andreas. I'd also delay past-DebConf but there is no good reason for Rakesh to wait. All communication is on the list and usually there are helpful people around who might step in for questions. I'd be happy to answer questions and help you as well. Cheers, -- Pierre OpenPGP_signature.asc Description: OpenPGP digital signature
Re: GATK
Hi Andreas, Le 14/07/2023 à 08:14, Andreas Tille a écrit : Hi Pierre, [...] Right now I am preparing the move of my family some hundreds of kilometers away, I expect to get more time to look at it closer afterwards. Sure, Real life should have preference over volunteer work. Is the place where you move to a good location to have a developer sprint? While I like the location in Berlin (with the chance to get even more comfortable room) we can for sure rotate the sprint location a bit again to possibly attract other people. It's Lille, North of France. While the location is not the most difficult to reach, I still have to see if we could meet in some comfortable places, especially during weekends for the sprints. Possibly something could be done in Brussels, which is not far, but still I guess we would have to know someone to get in. In any case, I like the idea and think about it. [...] Kind regards Andreas. Have a great Sunday, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: GATK
Hi Andreas, Le 12/07/2023 à 15:01, Andreas Tille a écrit : Hi Pierre, I was wondering whether we might be able to package GATK for the next release. I've just fixed the watch file in Git. It would be great if you could have a look once you might find some spare cycles. Yeah, GATK is one of my main goals, with Nextflow. If I remember correctly, scala was a blocker but there might be a way to deal with it... Right now I am preparing the move of my family some hundreds of kilometers away, I expect to get more time to look at it closer afterwards. Still, as I said, GATK and Nextflow are my packaging goals in the team, and I am happy to say many dependencies have been added in the last year :) Kind regards Andreas. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: "Poll" for video conference date
Hi Andreas, Le 10/07/2023 à 10:03, Andreas Tille a écrit : Hi, I think we do not need any poll site to decide how to schedule our video conferences in future. IMHO it makes sense to do it in the beginning of each month and as far as I understood responses (private and public) it make sense to stick close to weekends. If you have some opinion when it is good for you simply rank your preferences with numbers 1 (=prefered), 2 (=OK), 3 (=I might join), 4 (=its hard vor me to join) of 5 (=I will not be able to join) Answers for me: Friday [5] 17 UTC [5] 18 UTC [2] 19 UTC Saturday [5] 17 UTC [5] 18 UTC [2] 19 UTC Sunday [5] 17 UTC [5] 18 UTC [2] 19 UTC 19 UTC + Summer Time in Europe is the best combination, unfortunately no one can help here! Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Do we want to have a video conference tomorrow or is a monthly meeting more appropriate
Hi all, Le 06/07/2023 à 11:04, Andreas Tille a écrit : Hi, last time we were wondering whether a monthly video meeting is more sensible. Its not that much we need to talk about (in case there is something we can perfectly do ad hoc meetings) and may be its enough to meet only once a month. If we want to switch to a monthly period, do we want to meet a a certain day of the week (say Friday or Sunday) or do we want to meet say at each 17th of a month to move over all weekdays which will not exclude somebody who might not be able to join at a certain day of the week. While not being the most active attendee, I trust switching to a monthly meeting is reasonable if people feel so. As you say, organizing ad hoc meetings when we need it is sensible. Also I would vote for holding the meeting on the nth Friday/Sunday/whatever in a month, I imagine this would allow people to join more often (after an initial choice appealing to the majority). Kind regards Andreas. See you soon, I hope! -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: pychopper has switched to a non-free license in new upstream version
Hi again, Le 17/06/2023 à 22:14, Pierre Gruet a écrit : Hi all, Le 17/06/2023 à 19:37, Nilesh Patra a écrit : On 06/17/2023 11:21 AM IST Andreas Tille wrote: ''' 1.10. "Research Purposes" means use for internal research and not intended for or directed towards commercial advantages or monetary compensation; provided, however, that monetary compensation does not include sponsored research of research funded by grants. ''' What about opening an upstream to the consequence that this change of the license will remove the package from Debian. That's a sensible thing to do, but I will not do it. I see my time spent well on packaging instead of engaging with upstream in matters that are /not/ technical, and I have no interest to pursue the same in this case either. If you or anybody else would like to ask upstream about reconsidering their license, that's be great. I only wanted to draw the attention to not go ahead with a pychopper update (to 2.7.4) at the moment. [1] https://wiki.debian.org/DebianMed/SoftwareLiberation I opened an issue [2] and marked it in [1]. Let's see... [2] https://github.com/epi2me-labs/pychopper/issues/27 Updates: upstream answered they would not revert to a DFSG-free license, although the given reasons do not seem to address our concern, as tmancill also pointed out in the Github issue [2]. Meanwhile, I updated the package in Debian to version 2.7.3, which is the last one under MPL-2.0. I dropped a note in debian/README.source about the licensing issue. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: pychopper has switched to a non-free license in new upstream version
Hi all, Le 17/06/2023 à 19:37, Nilesh Patra a écrit : On 06/17/2023 11:21 AM IST Andreas Tille wrote: ''' 1.10. "Research Purposes" means use for internal research and not intended for or directed towards commercial advantages or monetary compensation; provided, however, that monetary compensation does not include sponsored research of research funded by grants. ''' What about opening an upstream to the consequence that this change of the license will remove the package from Debian. That's a sensible thing to do, but I will not do it. I see my time spent well on packaging instead of engaging with upstream in matters that are /not/ technical, and I have no interest to pursue the same in this case either. If you or anybody else would like to ask upstream about reconsidering their license, that's be great. I only wanted to draw the attention to not go ahead with a pychopper update (to 2.7.4) at the moment. [1] https://wiki.debian.org/DebianMed/SoftwareLiberation I opened an issue [2] and marked it in [1]. Let's see... [2] https://github.com/epi2me-labs/pychopper/issues/27 Best, Nilesh Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Please review release notes patch
Hi all, Le 25/05/2023 à 09:51, Andreas Tille a écrit : Hi Nilesh, Am Wed, May 24, 2023 at 10:16:22PM +0530 schrieb Nilesh Patra: On Wed, May 24, 2023 at 11:28:13AM +0200, Pierre Gruet wrote: Le 24/05/2023 à 08:25, Andreas Tille a écrit : https://salsa.debian.org/med-team/community/communication/-/blob/master/releasenotes/bookworm/release-notes.patch Please review and comment on it (or just push fixes and enhancements)! Is there any important piece of software we packaged during this release cycle and that could be worth highlighting? From my limited perspective I have none that comes to mind, but maybe it will for someone else. I do remember that during the bullseye release, we were looking forward to get nextflow into bookworm. AFAICS, that did not happen but I do see a capsule-nextflow package. Although it is mostly a deployment tool, _maybe_ it is worth a mention? I've CC'ed Steffen for any inputs about the same. Steffen? IMHO I consider it less worth mentioning than shiny-server. I agree. Let's (in my opinion) skip this and see it as a motivation to ship nextflow in Trixie. Another package that should be mentioned is shiny-server -- we were looking forward to have it for quite a while and it is finally there. That said, it is a science team package and maybe deserves a mention with the release-notes patch of that team. I've just added shiny-server diff --git a/releasenotes/bookworm/release-notes.patch b/releasenotes/bookworm/release-notes.patch index 586dbdd..81d91c8 100644 --- a/releasenotes/bookworm/release-notes.patch +++ b/releasenotes/bookworm/release-notes.patch @@ -2,8 +2,10 @@ As in every release new packages in the field of life sciences and medicine -were added. We kept on to get Continuous Integration support for the -packages maintained by the Debian Med team. +were added. The new package shiny-server might be worth extra mentioning +since it simplifies scientific web applications using R. We kept on to get +Continuous Integration support for the packages maintained by the Debian Med +team. The Debian Med team is continuously interested in feedback from users specifically in the form of requesting the packaging of not yet packaged I admit I would like to reward the work of Nilesh, Étienne and Pierre explicitly but I doubt whether release notes are the right place to mention people behind the work. Thanks in any case ;) I also doubt, but possibly we can say something like "many libraries have been packaged in order to pave the way for future inclusion of more prominent software in the field"? Just an idea, nothing mandatory here, especially since this sentence is not very specific! Kind regards Andreas. Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Please review release notes patch
Hello Andreas, Le 24/05/2023 à 08:25, Andreas Tille a écrit : Hi, as for every release we want to increase or visibility to show up in the release notes. I've drafted a patch https://salsa.debian.org/med-team/community/communication/-/blob/master/releasenotes/bookworm/release-notes.patch Please review and comment on it (or just push fixes and enhancements)! Thanks for this patch, I reviewed it and I don't mean to change anything. Is there any important piece of software we packaged during this release cycle and that could be worth highlighting? From my limited perspective I have none that comes to mind, but maybe it will for someone else. Kind regards Andreas. Have a great day, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Nextflow - have just used it on our HPC cluster and liked it
Hi Andreas, Le 09/05/2023 à 18:36, Andreas Tille a écrit : Hi Pierre, Am Mon, May 08, 2023 at 10:50:54PM +0200 schrieb Pierre Gruet: It is very nice to hear from you on Nextflow, this is a motivation booster for the packaging! +1 I have indeed packaged many dependencies, and if I remember correctly I had two issues at this step: - kryo 5.x is needed although we have libkryo-java/2.7 in Debian, which cannot be upgraded to version 5.x as it would break gradle (!). So we need a dedicated src:kryo5 package, I began doing it but took a break for whatever reason; If we need two versions of kryo it needs passing new - thus you can upload it at any time, thought. True, yes. - more annoying: I need groovy 3.x and in Debian we have groovy 2.4.21. I tried to package it but met some antlr4 issues on which I have to spend more time. I think reworking on this will be a good task after the release of Bookworm. I can try again and post possible issues here. May be groovy can be upgraded in experimental to version 3.x? Possibly I have been unclear there, sorry: when trying to build groovy 3.x, I had issues linked to antlr4 which prevented me from completing the whole build, so I am not even ready to propose a working upgrade of groovy... but since then, I have met other issues with antlr4 in other packages and could circumvent some of them, so I guess I should just try again as I now have more experience, and possibly coordinate with other interested people in debian-java. Thanks a lot for working on all these dependencies! And thanks for advising! :) Kind regards Andreas. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Nextflow - have just used it on our HPC cluster and liked it
Hi Steffen, Le 05/05/2023 à 22:16, Steffen Möller a écrit : Hello, I must admit that I am rather impressed - a series of images were auto-downloaded to function together with singularity and this then worked on a test data collection of the workflow. So, with singularity (or docker) in Debian, and nextflow, we would have an immediate sync with what upstream offers. I had a look at the table in Google docs and found that the one dependency that was once missing to get nextflow through its autotests, i.e. capsule-nextflow is in the archive now. So I thought to give the main package of nextflow another look. I am impressed by all work that Pierre already invested into the packaging. @Pierre, where does that work stand? I only saw that kryo5 is listed as a dependency that is not in the archive. It is very nice to hear from you on Nextflow, this is a motivation booster for the packaging! I have indeed packaged many dependencies, and if I remember correctly I had two issues at this step: - kryo 5.x is needed although we have libkryo-java/2.7 in Debian, which cannot be upgraded to version 5.x as it would break gradle (!). So we need a dedicated src:kryo5 package, I began doing it but took a break for whatever reason; - more annoying: I need groovy 3.x and in Debian we have groovy 2.4.21. I tried to package it but met some antlr4 issues on which I have to spend more time. I think reworking on this will be a good task after the release of Bookworm. I can try again and post possible issues here. Best, Steffen Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: New version bali-phy 4.0-beta2
Hi Benjamin, Le 28/03/2023 à 03:52, Benjamin Redelings a écrit : Hi, I'd like to upload a new version 4.0-beta2 of bali-phy. It decreases memory usage over the existing 3.6.1 by > 20fold in some cases. The first question I have is about using uscan with the "-beta2" suffix. I hacked the debian/watch file to make uscan recognize the tag name, but now its creating a dfsg source file called `bali-phy_4.0+dfsg.orig.tar.xz`. I suspect this should really be called `bali-phy_4.0-beta2+dfsg.orig.tar.xz`. Any guidance on how to handle -beta versions? I guess normally we may not want these, but in this case I think we do. Probably you wouold like to do something as in https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2 for the gedit-plugins package? This was found by typing "path:debian/watch beta" in the search field of sources.debian.org. There are other packages which you could check there. Secondly, I suppose that any new version would need to go into experimental, since we are in a hard freeze? I would like to start working on packaging for version 4 now, since some things have changed and I'd like to figure out how to deal with them now. Yes, uploading to experimental is the right thing to do right now :) -BenRI Have a good day, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Snippy autopkgtest claims that snpeff is version 0
Hi Andreas, Le 03/02/2023 à 13:05, Andreas Tille a écrit : Hi Pierre, Am Fri, Feb 03, 2023 at 11:32:07AM +0100 schrieb Pierre Gruet: [16:13:15] Found snippy-vcf_to_tab - /usr/bin/snippy-vcf_to_tab [16:13:15] Found snippy-vcf_report - /usr/bin/snippy-vcf_report [16:13:15] Checking version: samtools --version is >= 1.7 - ok, have 1.16 [16:13:15] Checking version: bcftools --version is >= 1.7 - ok, have 1.16 [16:13:15] Checking version: freebayes --version is >= 1.1 - ok, have 1.3.6 [16:13:15] Need snpEff -version >= 4.3 but you have 0 - please upgrade it. autopkgtest [16:13:16]: test run-unit-test: ---] I have no idea what this might mean. In fact it turns out snpeff itself is not installable on i386. I just tried to apt-get install snpeff in an i386 chroot and I got Strange that this log is that different from s390x where the installation issue is more direct, but in principle the same. ---8< Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libngs-java : Depends: libngs-jni (>= 3.0.3+dfsg-4) but it is not installable Depends: libngs-jni (< 3.0.3+dfsg-4.1~) but it is not installable E: Unable to correct problems, you have held broken packages. Command apt-get --dry-run install -- snpeff exited with exit code 1. ---8< libngs-jni and libngs-java are built from src:sra-sdk, of which binaries are only for amd64 and arm64, see [3]. Thus we could ignore autopkgtest failures on arches other than amd64 and arm64 for snippy -- although I cannot explain right now how its autopkgtests are passing on armel for instance, as libngs-jni is unavailable there. I think with this explanation the conclusion should be diff --git a/debian/tests/control b/debian/tests/control index cd113c6..fd46ed1 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,4 +1,4 @@ Tests: run-unit-test Depends: @ Restrictions: allow-stderr, skip-not-installable -Architecture: !s390x +Architecture: amd64 arm64 which I'll upload soon. Looks perfectly reasonable, yes. Thanks! Would you have time today, you can take a decision if it is obvious to you. Else I will look at it during the weekend! IMHO we need to decide whether we should ship snpeff version 5.0 rather than 5.1 to deal with bug #1029202. May be you can estimate the effort needed for this change? I have no idea how many applications besides snippy are suffering from this issue but it does not sound good. I am frustrated to say this, but possibly the biggest difficulty is... getting the source. Version 5.0 was never tagged in the GitHub repo, it is not available anymore on the website of SnpEff, the Wayback Machine has not registered it :-( I understand your colleagues are using version 5.0 from conda. I can find the binaries there, but do the people from conda register the sources anywhere? Bye, -- Pierre Kind regards Andreas. [3] https://buildd.debian.org/status/package.php?p=sra-sdk OpenPGP_signature Description: OpenPGP digital signature
Re: Snippy autopkgtest claims that snpeff is version 0
Hi Andreas, Le 03/02/2023 à 11:17, Andreas Tille a écrit : Hi, I realised that snippy autopkgtest is failing for i386 and s390x[1] The log for i386[2] says: Get:310 http://deb.debian.org/debian testing/main i386 libsnpeff-java all 5.1+d+dfsg-3 [2,150 kB] ... [16:13:15] Found snpEff - /usr/bin/snpEff ... [16:13:15] Found snippy-vcf_to_tab - /usr/bin/snippy-vcf_to_tab [16:13:15] Found snippy-vcf_report - /usr/bin/snippy-vcf_report [16:13:15] Checking version: samtools --version is >= 1.7 - ok, have 1.16 [16:13:15] Checking version: bcftools --version is >= 1.7 - ok, have 1.16 [16:13:15] Checking version: freebayes --version is >= 1.1 - ok, have 1.3.6 [16:13:15] Need snpEff -version >= 4.3 but you have 0 - please upgrade it. autopkgtest [16:13:16]: test run-unit-test: ---] I have no idea what this might mean. In fact it turns out snpeff itself is not installable on i386. I just tried to apt-get install snpeff in an i386 chroot and I got ---8< Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libngs-java : Depends: libngs-jni (>= 3.0.3+dfsg-4) but it is not installable Depends: libngs-jni (< 3.0.3+dfsg-4.1~) but it is not installable E: Unable to correct problems, you have held broken packages. Command apt-get --dry-run install -- snpeff exited with exit code 1. ---8< libngs-jni and libngs-java are built from src:sra-sdk, of which binaries are only for amd64 and arm64, see [3]. Thus we could ignore autopkgtest failures on arches other than amd64 and arm64 for snippy -- although I cannot explain right now how its autopkgtests are passing on armel for instance, as libngs-jni is unavailable there. Meanwhile I've pushed a change to ignore s390x architecture for debci since the required bcftools does not exist here. Kind regards Andreas. [1] https://qa.debian.org/excuses.php?package=snippy [2] https://ci.debian.net/data/autopkgtest/testing/i386/s/snippy/30738457/log.gz Would you have time today, you can take a decision if it is obvious to you. Else I will look at it during the weekend! Best, -- Pierre [3] https://buildd.debian.org/status/package.php?p=sra-sdk OpenPGP_signature Description: OpenPGP digital signature
pplacer status (Was: Re: [RFH] aeonbits-owner and capsule-maven-nextflow)
Hi all, Le 22/12/2022 à 17:17, Andreas Tille a écrit : Am Thu, Dec 22, 2022 at 08:55:27PM +0530 schrieb Nilesh Patra: I see three options: 1. Revert mcl to past version From a user base point of view I do not consider this a good option. 2. Wait for upstream reaction on ocaml support for mcl -- they said someone might be interested to look into it but the wait time is not definite I admit I'm not really optimistic that this will happen right in time but may be we can support backports later. 3. Disable build time tests which use pplacer and move the depends on pplacer to suggests; mention in README.Debian to get pplacer from github or something similar This seems to be a good alternative. Andreas and I had a discussion during the ongoing sprint, we think it is better to keep pplacer out of testing as there are reverse dependencies, of which users could also be annoyed by a manual work to get pplacer from github. Let's backport it later if something positive happens upstream on this side. Kind regards Andreas. Bye, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Sprint can start Friday evening - who would like to join
Hi Andreas and everyone, Le 18/01/2023 à 11:28, Andreas Tille a écrit : Am Wed, Jan 18, 2023 at 07:56:55AM +0100 schrieb Andreas Tille: Hi, Am Tue, Jan 17, 2023 at 10:07:28PM +0100 schrieb Sascha Steinbiss: FYI the Vietnamese place (Viet Kitchen) around the corner has many vegan options and is quite good. https://goo.gl/maps/M7gwo7S97qpqs6ms6 OK, lets meet Friday 18:00 at this Vietnamese place. I have added these details to the main sprint page https://wiki.debian.org/Sprints/2022/Debian%20Med%20Sprint%202023%2C%20Berlin Thanks for this and everything else to you, Sascha, ... and other people involved. May I suggest we do some keysigning during the weekend? I will bring papertips with my key. See you Andreas. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Sprint can start Friday evening - who would like to join
Hi all, Le 16/01/2023 à 19:27, Andreas Tille a écrit : Hi, on top of the small hotel at EUREF-Campus 22 there is a lounge for 8 persons. I can book this with Debian sponsored money for the evening - so we can meet there. Who would like to join and at what time do we want to meet? They hotel asked whether we would like to have catering in this room. Alternatively we could have dinner in a nearby restaurant (there is a vietnamese restaurant nearby). I would appreciate joining! I could be there around 5:30pm I think. I have no preference regarding the dinner :) For more details I'd suggest we use the matrix channel[1]. See you Andreas. [1] https://app.element.io/?#/room/#debian-med:matrix.org Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
[Advent bug squashing] #1026659 and #1026764 (Was: Re: [RFH] aeonbits-owner and capsule-maven-nextflow)
Hello, Le 22/12/2022 à 14:21, Nilesh Patra a écrit : Hi Pierre, all, Recent rebuilds have led to bug reports #1026659 and #1026764 for aeonbits-owner and capsule-maven-nextflow respectively. As you might have guessed, both of them are java packages and I've quite frankly been unable to figure out these on my own so far. Could you please take care of them? Now the RC bugs in these two packages are fixed! Thanks! Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: [RFH] aeonbits-owner and capsule-maven-nextflow
Hi Nilesh and everyone, Le 22/12/2022 à 14:21, Nilesh Patra a écrit : Hi Pierre, all, Recent rebuilds have led to bug reports #1026659 and #1026764 for aeonbits-owner and capsule-maven-nextflow respectively. As you might have guessed, both of them are java packages and I've quite frankly been unable to figure out these on my own so far. Could you please take care of them? Sure! Also Andreas wrote to me about aeonbits-owner recently. I have had little time since then, but I can say capsule-maven-nextflow is not worrying as I fixed similar issues in other packages. aeonbits-owner needs more investigation as nothing obvious comes at first glance. But I am sure there will be an easy fix. I am planning to take care of both soon! Thanks! You're welcome! In passing: what do you think of the current RC bug of pplacer? It would cause the removal of sepp and tipp which seem to have quite a few users, but I am not sure of the direction to take to fix it. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
[Advent bug squashing] Fwd: Bug#1025953: marked as done (beast-mcmc: only usable with OpenCL)
Hi, Andrius made a bug report for beast-mcmc, thanks to the upstream of beast2-mcmc I could find the origin lay in libhmsbeagle and I just fixed it. Cheers, -- Pierre Message transféré Sujet : Bug#1025953: marked as done (beast-mcmc: only usable with OpenCL) Date : Fri, 16 Dec 2022 22:24:05 + De : Debian Bug Tracking System Répondre à : 1025...@bugs.debian.org Pour : Pierre Gruet Your message dated Fri, 16 Dec 2022 22:20:56 + with message-id and subject line Bug#1025953: fixed in libhmsbeagle 3.1.2+dfsg-13 has caused the Debian Bug report #1025953, regarding beast-mcmc: only usable with OpenCL to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1025953: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: beast-mcmc Version: 1.10.4+dfsg-5 Severity: important Control: block 1025424 by -1 Hello, When launched on a system without OpenCL, beast-mcmc executable dies: $ beast-mcmc -help OpenCL error: CL_DEVICE_NOT_FOUND from file , line 122. From a quick glance this seems to be happening due to beast-mcmc using OpenCL version of libhmsbeagle1v5 (the line cited in the error message is in libhmsbeagle source). However, beast-mcmc seems to support CLI options to switch to libhmsbeagle1v5 CPU instance (see 'beagle_CPU' in src/dr/app/beast/BeastMain.java). Maybe it is possible to make CPU mode the default to avoid loading OpenCL-dependent libraries. Andrius --- End Message --- --- Begin Message --- Source: libhmsbeagle Source-Version: 3.1.2+dfsg-13 Done: Pierre Gruet We believe that the bug you reported is fixed in the latest version of libhmsbeagle, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1025...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Pierre Gruet (supplier of updated libhmsbeagle package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 16 Dec 2022 22:41:31 +0100 Source: libhmsbeagle Architecture: source Version: 3.1.2+dfsg-13 Distribution: unstable Urgency: medium Maintainer: Debian Med Packaging Team Changed-By: Pierre Gruet Closes: 1025953 Changes: libhmsbeagle (3.1.2+dfsg-13) unstable; urgency=medium . * Team upload * Stopping supporting OpenCL (Closes: #1025953) Checksums-Sha1: 344f7c2c0cce31f09d697e76714d0fdc55b6a409 2337 libhmsbeagle_3.1.2+dfsg-13.dsc 25a9f4aeb988b973b39a216cba2da027bd99a5a2 37220 libhmsbeagle_3.1.2+dfsg-13.debian.tar.xz df0753bf5759f898dee69caeb897ad1213369224 14604 libhmsbeagle_3.1.2+dfsg-13_amd64.buildinfo Checksums-Sha256: 307ab3ef407d70ecada6838325b2b7af25594a5c842dceb6a6c5421a22f8f07e 2337 libhmsbeagle_3.1.2+dfsg-13.dsc 6105baa129f69c68d43d0684cc99e23f6d4e5074c431faa2eb0ee04b53dc0cb1 37220 libhmsbeagle_3.1.2+dfsg-13.debian.tar.xz 1971546c01918c71b612a7b57397ecbdbdc09b9d83893383a532b2bd11146896 14604 libhmsbeagle_3.1.2+dfsg-13_amd64.buildinfo Files: 6af997f8b1e4c46455c2691c9285495b 2337 libs optional libhmsbeagle_3.1.2+dfsg-13.dsc 1085b37ed81835856e34e419eadc76dc 37220 libs optional libhmsbeagle_3.1.2+dfsg-13.debian.tar.xz 5984894bea0ee300b873d04a63f89225 14604 libs optional libhmsbeagle_3.1.2+dfsg-13_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmOc6pQACgkQYAMWptwn dHaoyRAAi38wbl6mJzZmuZ+bx8g3IFLMaQBJnNG6hV46V+E62BwMz98Jmeq39ARa vxygiBjUm2e1qrihqbggDZDrObo4cOCdkXCtrMg6E1Erj9q6uxpTSMIqnS+NUpY2 kSfTxet/xiXnnAkrq06KyLeugJxW5VUikdRYj4imUNBd+OOhSFpvkZINHDt3n1IX k+ZuKOj1z6kq8iJ4bTmeEmXFn83MhbhyTiOc6nB88sebEAHU34t4fgwcjCXN/VPV nFxc62yjTzod4ExC/M9UAdK4zlivKp/+ScLRHMhBIUPfaQK3Rh+6xp+ZdztuPx5w fEyhNnTqUovzAntCtP/ohGBIEKLyoSQJjvTwjGsgOJgTki5L96cnRmJYRCNlCy3k 4kEfgnHSzL1sa77v+wuJtmlx8cmEopozLQAE3siUGGdqszMpbsvErMxQIdqxbGr6 zT2FSjGnnZUSzjjaUHnciO2/45GSOeXeAFCNeXT9NimBqawS63s8JiGNlDOXDqiN V5lChf4Q7MSpUd/bsPFdaDheawUqGl02StoqlngEb7zV006vgNdJVnhxY7R8ZxQe 7Ue766AnmV5hlwNpHLpUCvnstzRgJIAsBIcNTWVISPB//rWAaPeBt6KmfKWrTXZl elrOlabPeku9g+tBNa0GA4wB59MMG3F1cUS1/CsPffqadcz20HA= =BRvX -END PGP SIGNATURE- --- End Message --- OpenPGP_signature Description: OpenPGP digital signature
[Advent bug squashing] This weekend: closed #1025887, eased testing migration, opened more bugs
Hello, I fixed bug #1025887 in biojava4-live thanks to a patch submitted along with the bug report. Also I eased the migration to testing of a few packages with long-standing failing migrations (autopkgtests and architectures problems essentially) and I opened some bugs -- so my contribution to the reduction of the number of bugs is negative but this is for good reasons :) Have a good week, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: [help] vdjtools autopkgtest fails
Hi Andreas, Le 27/11/2022 à 07:07, Andreas Tille a écrit : Hi Pierre, when fixing the watch file I stumbled upon an autopkgtest error[1]. Do you have an idea what might be wrong here? At last I found classpath issues in the build, and I could provide a cleaner way to build the jar which was previously a fat one with all dependencies bundled inside. Addressing these two issues allowed me to get a passing autopkgtest. Also I made some other significant changes and uploaded. It seems an autopkgtest can be useful also for a package in non-free :) Kind regards Andreas. [1] https://salsa.debian.org/med-team/vdjtools/-/jobs/3581757 Have a good day, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: [help] vdjtools autopkgtest fails
Hi Andreas, Le 27/11/2022 à 07:07, Andreas Tille a écrit : Hi Pierre, when fixing the watch file I stumbled upon an autopkgtest error[1]. Do you have an idea what might be wrong here? My guess is there is a missing jar in the manifest of the jar shipped by libmilib-java, which I updated two weeks ago. I will be looking at it shortly! Kind regards Andreas. Have a good Sunday (more "day" than "sun" here and now), -- Pierre [1] https://salsa.debian.org/med-team/vdjtools/-/jobs/3581757 OpenPGP_signature Description: OpenPGP digital signature
Re: [Help] Build issue of latest version of libsbml (probably Java compatibility issue)
Hi Andreas, Le 25/11/2022 à 10:57, Andreas Tille a écrit : Hi, I just realised that libsbml moved to Github. After fixing the watch file I tried to package the latest upstream version. Unfortunately the build fails and I see the lines /builds/med-team/libsbml/debian/output/source_dir/src/bindings/java/AutoTestRunner.java:48: error: package org.sbml.libsbml.test does not exist import org.sbml.libsbml.test.*; ^ Note: /builds/med-team/libsbml/debian/output/source_dir/src/bindings/java/AutoTestRunner.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. 1 error in the build log[1]. Any help would be appreciated. Done! Indeed there was an import of an empty set of Java classes, I repaired this. Also I added a missing #include in another set of bindings. I submitted my patches upstream. Now dh_auto_build succeeds but there is a whole bunch of reports for dh_missing, see relevant excerpt at the end of this email (Salsa CI job stopped outputting before this step). Would you like to take over? Kind regards Andreas. Best regards, -- Pierre --8<- debian/rules override_dh_missing make[1]: Entering directory '/<>' find debian -name test.xml -delete rm -f debian/tmp/usr/share/libsbml/*.txt \ debian/tmp/usr/share/libsbml/README* dh_missing dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/compareFiles.m exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/runTests.m exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/algebraicRules.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/both.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/convertedFormulas.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/convertedFormulas2.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/convertedFormulasL2.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/createdAnnotation.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/createdAnnotationL2.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/csymbolAvogadro.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/csymbolDelay.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/csymbolTime-reaction-l2.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/csymbolTime.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/errors.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fatal.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fbc.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fbcL3V2V1.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fbcL3V2V2.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fbcV2.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fbcV2Labels.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/test/test-data/fbc_groups.xml exists in debian/tmp but is not installed to anywhere dh_missing: warning:
Re: Possibility of In-person sprints in 2023?
Hi, Le 22/11/2022 à 14:38, Andreas Tille a écrit : Hi Sascha, Am Tue, Nov 22, 2022 at 12:38:21AM +0100 schrieb Sascha Steinbiss: I have been in touch with our front desk and it looks like a meeting at my employer here is doable in principle, given the same conditions as last time. So I guess Berlin could be an option. Thanks a lot for checking. +1! I'd prefer to wait until I have some confirmation in writing before making a reservation -- do we already have some idea of a timeframe I can communicate? For me the weekends (+Friday and/or Monday) in January except the weekend from 7./8. January are an option. It gets worse in February for me. Personally: all weekends would work except 28th-29th of January. Other dates in March would work (also hopefully for Andreas) but I guess we should not delay the sprint too much after the beginning of the freeze? Kind regards Andreas. Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Possibility of In-person sprints in 2023?
Hi everyone, Le 29/10/2022 à 21:28, Nilesh Patra a écrit : Hi, I suppose sprints in 2021 and 2022 have been virtual so far due to COVID. There were some COVID related sprints in 2020 as well. Is there a possibilty to have an in-person debian-med sprint in 2023? Would someone be interested in it, or so? Thanks for bringing in the idea, I know it was discussed also in the online meeting of today. Personally I would welcome such in-person event for our team and I would happily join. I trust this is much better than an online event for the team. Thanks! Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Med video conference tomorrow, Wednesday 2022-11-02 18:00 UTC
Hi everyone, Le 01/11/2022 à 16:35, Andreas Tille a écrit : Hi, this is the call for the next video conference of the Debian Med team [...] For those who are interested in hot topics we want to tackle, here are some items: - RC bugs - Pushing latest versions of our software While I won't be able to join tomorrow, I want to underline many (Java) packages of the team were recently marked for auto-removal due to RC bugs with "OpenJDK17" in their titles. This is because OpenJDK17 has just become the default in Debian instead of OpenJDK11, bugs had been filed some months ago and they have just been bumped to RC. I have had the opportunity to fix some of them, but obviously the least trivial ones are remaining. I fixed the one of htsjdk in experimental today. I will be letting the package in experimental until I can coordinate with rdeps like picard-tools which has its own OpenJDK17-related RC bug. Help is welcome to tackle these RC bugs in ciftools-java (Java team), capsule-nextflow, intervalstorej (Java team)... They are my priority but if they get fixed before I look at them again, I will be very happy. [...] Andreas. Kind regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: gdcm: vtk[6,7] removal
Hi Andreas, Le 26/10/2022 à 11:24, Andreas Tille a écrit : Hi Pierre, Am Wed, Oct 26, 2022 at 10:41:51AM +0200 schrieb Pierre Gruet: [1] https://salsa.debian.org/med-team/gdcm/-/jobs/3427720 This is really just a missing include dir, as the problematic header is in /usr/lib/jvm/default-java/include/linux/ . I will be having a look shortly, we should be able to handle this and keep the Java packages if this is the only Java-related issue. Please see the hint of Mathieu. To be clear about this: We'll keep the general Java support libgdcm-java but it seems we need to remove libvtkgdcm-java which is way less frequently used. (For sure if you see any chance to fix this feel free to re-add what was removed in Git - but I guess this is some issue that needs to be fixed upstream.) Kind regards Andreas. Yes, it is likely I overlooked the whole frame of the issue. Will look again later... this Java point seems not to be the most urgent thing. Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: gdcm: vtk[6,7] removal
Hi, Le 26/10/2022 à 10:35, Andreas Tille a écrit : Hi Mathieu, Am Wed, Oct 26, 2022 at 08:10:42AM +0200 schrieb Mathieu Malaterre: On Wed, Oct 26, 2022 at 7:53 AM Andreas Tille wrote: Hi, in the bug log there is some discussion to drop C# and Java VTK bindings. This would mean to drop the packages libvtkgdcm-cil and libvtkgdcm-java. I'm perfectly fine with this and I just pushed a change in d/control where I replaced s/vtk7/vtk9/ globally. The build[1] is currently failing at a probably simple Java issue: /usr/lib/jvm/default-java/include/jni.h:45:10: fatal error: jni_md.h: No such file or directory 45 | #include "jni_md.h" | ^~ compilation terminated. I have no idea whether we might keep on supporting the Java bindings if this can be solved. But I'm pretty sure we should act on droping what needs to be droped in a timely manner to make sure gdcm will remain in testing. Any help is welcome. See my original work at: https://salsa.debian.org/med-team/gdcm/-/commits/debian/experimental/ Ups, sorry for missing this. I've merged your changes into master but the said problem remains[1]. Kind regards Andreas. [1] https://salsa.debian.org/med-team/gdcm/-/jobs/3427720 This is really just a missing include dir, as the problematic header is in /usr/lib/jvm/default-java/include/linux/ . I will be having a look shortly, we should be able to handle this and keep the Java packages if this is the only Java-related issue. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Please have a look at beast2-mcmc in Git
Hi Andreas, Le 24/10/2022 à 09:58, Andreas Tille a écrit : Hi Pierre, I've updated beast2-mcmc in Git but the new upstream version fails to build[1] which has hopefully a simple fix. Thanks for drawing my attention on this issue. I pushed the effort forward, but now half of the tests are failing. It seems upstream changed its build process and kind of relies on another project of theirs, BeastFX. I believe we can make a build without BeastFX, though, but maybe some of the test failures show one should tweak a bit the packaging... I will have another look soon. My changes are pushed to Salsa. Kind regards Andreas. [1] https://salsa.debian.org/med-team/beast2-mcmc/-/jobs/3420119 Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1022258: ITP: libmjson-java -- lean JSON Library for Java with a compact API
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: libmjson-java Version : 1.4.0 Upstream Author : Miami-Dade County * URL : https://bolerio.github.io/mjson/ * License : Apache-2.0 Programming Lang: Java Description : lean JSON Library for Java with a compact API mJson is an extremely lightweight Java JSON library with a very concise API. Unlike other JSON libraries, it focuses on manipulating JSON structures in Java without necessarily mapping them to/from strongly typed Java objects. Because of its tiny size, it is well-suited for any application aiming at a small footprint such as mobile applications. mjson is needed as a dependency of htsjdk, which is an important software in the Debian-med ecosystem.
Bug#1021934: ITP: biojava6-live -- Java API to biological data and applications (version 6)
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: biojava6-live Version : 6.0.5 Upstream Author : BioJava Developers * URL : https://biojava.org * License : LGPL-2.1 Programming Lang: Java Description : Java API to biological data and applications (version 6) This package presents the Open Source Java API to biological databases and a series of mostly sequence-based algorithms. BioJava is an open-source project dedicated to providing a Java framework for processing biological data. It includes objects for manipulating sequences, file parsers, server support, access to BioSQL and Ensembl databases, and powerful analysis and statistical routines including a dynamic programming toolkit. Important changes in the API at each major version have made it necesssary to have a new source package for every major version of the library. In the Debian-med team, we have already started seeing packages depending on biojava 6 and it would be a very valuable addition to have it into Debian. The package will be team-maintained by the Debian-med team.
Re: Finishing ncbi-vdb and sra-sdk
Hi Aaron, Le 14/10/2022 à 02:05, Aaron M. Ucko a écrit : Pierre Gruet writes: I have just pushed some changes. I adopted the -- I believe -- least invasive solution by creating a new package libngs-jni which depends on the shared lib package (not the -dev one), only ships a symlink to the shared lib with full version number, and on which the -java package depends. By the way I also made it Architecture: all and ensured it was binNMU-able. That ought to work, thanks, but shouldn't it be Architecture: amd64? We could get away with all as long as the package is otherwise amd64-only, but we may be able to revisit getting it to build on either or both of ncbi-vdb's other supported architectures (arm64 and x32). Hmm, I did not have in mind that the package is ready for amd64 only. If this is the case, then yes, we should not use Architecture: all at the moment (which is otherwise the general rule for -java packages). As such, the new -jni package is not Multi-Arch: same as it ships the shared lib symlink in /usr/lib/jni. But if you think it should be, then we could install the symlink in /usr/lib//jni. This is less canonical regarding the Java policy but technically that should be OK. I'm all for Multi-Arch in general, but am content to defer to Java policy in this case. After giving it some thoughts, I convinced myself it would be better to fit Multi-Arch: same and put the symlink in /usr/lib//jni, which only violates a "should" in the Java policy but is nevertheless done for many packages. Also this architecture-specific path is searched when loads shared libraries from Java code, so I have pushed the change to Salsa. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Finishing ncbi-vdb and sra-sdk
Hi Aaron, Le 12/10/2022 à 04:48, Aaron M. Ucko a écrit : Pierre Gruet writes: Indeed, this warning should be overridden, usually I do so and add a pointer to the discussion in https://lists.debian.org/debian-java/2018/06/msg00021.html in the comment in the .lintian-overrides file. Got it, thanks! Do you have an idea of the exact way the .so is loaded by the Java code? The methods in LibManager.java are a bit involved and I am unsure to see which behaviour is expected exactly. If you don't, I shall investigate further in order to help, no worry. No, sorry. That said, this issue is neither new nor urgent; I just noticed it and wanted to take the opportunity to address it if it would be reasonably easy to do so. I have just pushed some changes. I adopted the -- I believe -- least invasive solution by creating a new package libngs-jni which depends on the shared lib package (not the -dev one), only ships a symlink to the shared lib with full version number, and on which the -java package depends. By the way I also made it Architecture: all and ensured it was binNMU-able. No patch of the upstream code is required. As such, the new -jni package is not Multi-Arch: same as it ships the shared lib symlink in /usr/lib/jni. But if you think it should be, then we could install the symlink in /usr/lib//jni. This is less canonical regarding the Java policy but technically that should be OK. Also, I have added a Lintian override for the embedded JS, as we discussed. Feel free to ping me if some issues show up later, but I expect none. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Finishing ncbi-vdb and sra-sdk
Hi Aaron and Andreas, Le 11/10/2022 à 15:06, Aaron M. Ucko a écrit : Andreas Tille writes: I wanted to set you "Owner" of the Debian Med team repository since this is the maximum power. I realised you are owner. So either someone has beaten me and just did so or something is wrong if you can't do what you want to do. OK, thanks. A closer look indicated that GitLab doesn't normally allow *anyone* to force-push to protected branches: https://docs.gitlab.com/ee/user/project/protected_branches.html I temporarily enabled force pushes for this one just long enough for my needs. I would have preferred to be able to relax the policy just for owners, but AFAICT nobody else pushed in the interim anyway. - The javadocs contain embedded copies of files from libjs-jquery and libjs-jquery-ui that should become symlinks (with dependencies added). I've seen packages where this is ignored. If you want to approach this and need helping hands just ask here. I reckon it should be straightforward enough, thanks; it just wasn't a priority. Indeed, this warning should be overridden, usually I do so and add a pointer to the discussion in https://lists.debian.org/debian-java/2018/06/msg00021.html in the comment in the .lintian-overrides file. Once I saw a package trying to address this issue by symlinking with rdfind, but it was causing broken symlinks everytime the libjs-query package (which contains the referenced files) layout changed. - Lower priority: I have not yet taught the Java bindings to look for full SONAMEs, so they still depend on a -dev package. I'd appreciate help from someone more familiar with Java. I admit I do not understand the problem but I have put Pierre in CC. More concretely, the bindings should directly load libncbi-ngs.so.3, and depend directly on libncbi-ngs3, rather than going through the unversioned libncbi-ngs.so symlink and depending on libncbi-ngs-dev. I made appropriate changes on the Python front, but I'm not so clear on how to do the same for Java. Most commonly, when Java programs have bindings to native code in C or C++, this library is shipped in a -jni package which is Architecture: any and contains a .so file (with no version number appended) in /usr/lib/jni. But here I understand you need to load the library which is in the shared lib package. Do you have an idea of the exact way the .so is loaded by the Java code? The methods in LibManager.java are a bit involved and I am unsure to see which behaviour is expected exactly. If you don't, I shall investigate further in order to help, no worry. A comment to your question in your other mail: Sorry, I have no idea how to teach CI to pick from experimental. OK, thanks. No big deal, though it might be nice to have it working. Meanwhile, I reckon I'll also want to revisit debian/copyright, particularly with a pass through NEW upcoming. ;-) Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
sight failing to build
Hello Flavien, We have just had this bug report on sight: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016276 My last upload of sight was 15 days ago with no issue. Anyway, if you have some time to look at it, it will be useful! Best wishes, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: CMake help needed for tiddit
Hi Andreas,
Le 26/07/2022 à 13:50, Andreas Tille a écrit :
Hi,
from my perspective the CMakeLists.txt of tiddit has not changed compared
to the last upstream version. Unfortunately the build fails[1] with
CMake Error at CMakeLists.txt:42 (add_executable):
No SOURCES given to target: TIDDIT
which is not really true if I read the CMakeLists.txt file correctly.
Any idea what might be wrong here?
Indeed ${TIDDIT_FILES} is empty; I see the src/ folder has disappeared
in the new upstream version, which probably means tiddit is Python-only now?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/tiddit/-/jobs/3038929#L962
Best wishes,
--
Pierre
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1016046: ITP: genomicsdb -- sparse array storage library for genomics
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: genomicsdb Version : 1.4.3 Upstream Author : Intel Health and Lifesciences * URL : https://www.genomicsdb.org/ * License : Expat Programming Lang: C++, Java Description : sparse array storage library for genomics GenomicsDB is built on top of a htslib fork and an internal array storage system for importing, querying and transforming variant data. Variant data is sparse by nature (sparse relative to the whole genome) and using sparse array data stores is a perfect fit for storing such data. The GenomicsDB stores variant data in a 2D array where: - Each column corresponds to a genomic position (chromosome + position); - Each row corresponds to a sample in a VCF (or CallSet in the GA4GH terminology); - Each cell contains data for a given sample/CallSet at a given position; data is stored in the form of cell attributes; - Cells are stored in column major order - this makes accessing cells with the same column index (i.e. data for a given genomic position over all samples) fast. - Variant interval/gVCF interval data is stored in a cell at the start of the interval. The END is stored as a cell attribute. For variant intervals (such as deletions and gVCF REF blocks), an additional cell is stored at the END value of the variant interval. When queried for a given genomic position, the query library performs an efficient sweep to determine all intervals that intersect with the queried position. There is a C++ library and a Java library, we plan to ship both of them. This library is needed as a dependency of gatk, which is a packaging target of the Debian-med team.
Bug#1014344: ITP: gatk-bwamem -- interface to call Heng Li's bwa mem aligner from Java code
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: gatk-bwamem Version : 1.0.4 Upstream Author : Broad Institute * URL : https://github.com/broadinstitute/gatk-bwamem-jni/ * License : BSD-3-Clause Programming Lang: Java Description : interface to call Heng Li's bwa mem aligner from Java code BWA (Burrows-Wheeler Aligner) is a software package for mapping low-divergent sequences against a large reference genome, such as the human genome. It is written in C. gatk-bwamem provides a Java library and a shared library to allow one to use BWA from Java code.
Re: milib moved to gradle build system - help needed
Hi Andreas and tony,
Le 01/07/2022 à 19:13, tony mancill a écrit :
On Thu, Jun 30, 2022 at 05:06:50PM +0200, Andreas Tille wrote:
Hi Pierre (and others)
I injected latest version of milib which moved to gradle even in some
versions before. My extremely weak attempt to switch to gradle failed
(quite expected) but I hope its a nice start for you (or anybody else
who might know gradle better than me which is basically zero).
Hi Andreas,
Not only did upstream switch to Gradle, but the build file is written in
Kotlin, which I don't be believe our build toolchain currently supports.
Fortunately, the build doesn't look very complex - it's mostly concerned
with publishing, none of which we need - so we should be able to write a
simple build.gradle for the project.
Thanks for the first look into the package!
I have patched the build file quite a lot (rewriting it from scratch
could have been simpler, but there are the dependencies...), refreshed
dependencies and Maven rules, made small changes to be able to compile
and to run the tests successfully!
I will give this a go, but it likely won't be until the end of next week
due to some ${real_life} family considerations. (Pierre, if you are
already ahead of me on this, feel free to go ahead with an upload.)
There remains a few tiny steps in the "TODO" section in d/changelog. I
think I could address them within the two upcoming days. If I can't, I
will tell you tony!
Cheers!
tony
Warm regards,
--
Pierre
OpenPGP_signature
Description: OpenPGP digital signature
Re: Removing myself from uploaders in (most) med-packages / Winding down involvement a little
Hi everyone, Le 24/06/2022 à 22:15, Étienne Mollier a écrit : [...] In the light of Andreas' own time shrinking, my id is also available if need be (disregarding the fact that I felt having the head underwater in the past few months myself). I'll try to add myself systematically when intervening on packages where only one or the other is uploader, so the load can be a bit more evenly distributed. Same here! Thanks Nilesh for the stunning amout of work you have already done. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Re: Upgrading biojava-live from 1.7 to 1.9
Hi Olivier, Andreas, Steffen, Le 28/03/2022 à 17:54, Steffen Möller a écrit : On 28.03.22 17:15, Andreas Tille wrote: Am Mon, Mar 28, 2022 at 04:42:15PM +0200 schrieb olivier sallou: ... that's fine for me Thanks a lot for this effort Many thanks - brings some memories back! Steffen Thanks for your quick answers, let's go then! Bye, -- Pierre
Upgrading biojava-live from 1.7 to 1.9
share/java/dnaplotter.jar:
- Class-Path: /usr/share/java/artemis.jar /usr/share/java/batik-codec.jar
/usr/share/java/batik-dom.jar /usr/share/java/batik-ext.jar
/usr/share/java/batik-svggen.jar /usr/share/java/batik-util.jar
/usr/share/java/biojava.jar /usr/share/java/cglib.jar
/usr/share/java/commons-lang3.jar /usr/share/java/commons-logging.jar
/usr/share/java/commons-net.jar /usr/share/java/htsjdk.jar
/usr/share/java/ibatis.jar /usr/share/java/j2ssh-core.jar
/usr/share/java/log4j-1.2.jar /usr/share/java/picard.jar
/usr/share/java/postgresql-jdbc.jar
+ Class-Path: /usr/share/java/artemis.jar /usr/share/java/batik-codec.jar
/usr/share/java/batik-dom.jar /usr/share/java/batik-ext.jar
/usr/share/java/batik-svggen.jar /usr/share/java/batik-util.jar
/usr/share/java/biojava-core.jar /usr/share/java/cglib.jar
/usr/share/java/commons-lang3.jar /usr/share/java/commons-logging.jar
/usr/share/java/commons-net.jar /usr/share/java/htsjdk.jar
/usr/share/java/ibatis.jar /usr/share/java/j2ssh-core.jar
/usr/share/java/log4j-1.2.jar /usr/share/java/picard.jar
/usr/share/java/postgresql-jdbc.jar
Main-Class: uk.ac.sanger.artemis.circular.DNADraw
diff -Nru artemis-18.1.0+dfsg/debian/changelog
artemis-18.1.0+dfsg/debian/changelog
--- artemis-18.1.0+dfsg/debian/changelog2021-11-07 15:25:19.0
+0100
+++ artemis-18.1.0+dfsg/debian/changelog2022-02-28 18:24:58.0
+0100
@@ -1,3 +1,9 @@
+artemis (18.1.0+dfsg-7) UNRELEASED; urgency=medium
+
+ * Changing coordinates of biojava, which is now Maven-packaged
+
+ -- Pierre Gruet Mon, 28 Feb 2022 18:24:58 +0100
+
artemis (18.1.0+dfsg-6) unstable; urgency=medium
* Using -Xmx1946m instead of -Xm4g in the autopkgtest, so that it runs on
diff -Nru artemis-18.1.0+dfsg/debian/control artemis-18.1.0+dfsg/debian/control
--- artemis-18.1.0+dfsg/debian/control 2021-11-05 20:52:28.0 +0100
+++ artemis-18.1.0+dfsg/debian/control 2022-02-28 18:24:58.0 +0100
@@ -43,23 +43,8 @@
Package: artemis
Architecture: all
Depends: ${misc:Depends},
- ${java:Depends},
-# java:Depends adds a dependency on a versioned biojava, but that does not
-# contain the required biojava.jar file
- libbiojava-java,
- libhtsjdk-java,
- libcommons-net-java,
- libcommons-lang3-java,
- libcommons-logging-java,
- libbatik-java,
- libj2ssh-java,
- libibatis-java,
- liblog4j1.2-java,
- libpostgresql-jdbc-java,
- libpicard-java,
- jemboss,
- libcglib-java,
- default-jre
+ ${maven:Depends}
+Suggests: ${maven:OptionalDepends}
Description: genome browser and annotation tool
Artemis is a genome browser and annotation tool that allows visualisation of
sequence features, next generation data and the results of analyses within the
diff -Nru artemis-18.1.0+dfsg/debian/maven.rules
artemis-18.1.0+dfsg/debian/maven.rules
--- artemis-18.1.0+dfsg/debian/maven.rules 2020-09-05 15:02:32.0
+0200
+++ artemis-18.1.0+dfsg/debian/maven.rules 2022-02-28 18:24:58.0
+0100
@@ -15,3 +15,4 @@
junit junit jar s/.*/4.x/ * *
slf4j slf4j-nop jar s/.*/debian/ * *
org.mockito mockito-core jar s/.*/debian/ * *
+org.biojava s/biojava/core/ jar s/1.*/1.x/ * *
diff -Nru
artemis-18.1.0+dfsg/debian/patches/missing_htsjdk_dependency_in_pom.patch
artemis-18.1.0+dfsg/debian/patches/missing_htsjdk_dependency_in_pom.patch
--- artemis-18.1.0+dfsg/debian/patches/missing_htsjdk_dependency_in_pom.patch
2021-04-26 17:29:15.0 +0200
+++ artemis-18.1.0+dfsg/debian/patches/missing_htsjdk_dependency_in_pom.patch
2022-02-28 18:22:16.0 +0100
@@ -5,7 +5,7 @@
--- a/pom.xml
+++ b/pom.xml
-@@ -298,7 +298,13 @@
+@@ -296,7 +296,13 @@
diff -Nru artemis-18.1.0+dfsg/debian/patches/no_install_of_provided_jars.patch
artemis-18.1.0+dfsg/debian/patches/no_install_of_provided_jars.patch
--- artemis-18.1.0+dfsg/debian/patches/no_install_of_provided_jars.patch
2021-04-26 17:29:03.0 +0200
+++ artemis-18.1.0+dfsg/debian/patches/no_install_of_provided_jars.patch
2022-02-28 18:22:20.0 +0100
@@ -7,7 +7,7 @@
--- a/pom.xml
+++ b/pom.xml
-@@ -415,76 +415,6 @@
+@@ -413,76 +413,6 @@
diff -Nru artemis-18.1.0+dfsg/debian/patches/running_build_tests.patch
artemis-18.1.0+dfsg/debian/patches/running_build_tests.patch
--- artemis-18.1.0+dfsg/debian/patches/running_build_tests.patch
2021-04-26 17:30:25.0 +0200
+++ artemis-18.1.0+dfsg/debian/patches/running_build_tests.patch
2022-02-28 18:22:23.0 +0100
@@ -10,7 +10,7 @@
--- a/pom.xml
+++ b/pom.xml
-@@ -510,28 +510,6 @@
+@@ -508,28 +508,6 @@
@@ -39,7 +39,7 @@
-@@ -540
Bug#1008304: ITP: http-nio -- http/s file system provider for Java NIO.2
Hi Guillem, Le 28/03/2022 à 13:43, Guillem Jover a écrit : Hi! On Sat, 2022-03-26 at 14:59:17 +0100, Pierre Gruet wrote: Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: http-nio Version : 0.1.0 Upstream Author : Daniel Gomez-Sanchez * URL : https://github.com/lbergelson/http-nio * License : BSD-3-Clause Programming Lang: Java Description : http/s file system provider for Java NIO.2 This package provides a http or https file system that can be used in conjunction with Java NIO.2. This lightweight library provides a few classes related to file systems and paths. It is provided by the developers of gatk, which is a long-term packaging target of Debian-med team. I am packaging it as a reverse dependency of gatk. For this reason, it will be team-maintained inside Debian-med team. The http-nio name seems rather generic to be used as either source or binary package name. Could you namespace it? I don't see a very clear naming convention in the archive for Java packages, but then I have not checked the java-policy, TBH. What I see is either -jave or lib-java, either would work here. Thanks for your advice on this; the lib-java pattern seems wholly appropriate here, as it matches the name of the binary package that will be built by this source package. I will make the change as you suggest. Thanks, Guillem Best regards, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1008304: ITP: http-nio -- http/s file system provider for Java NIO.2
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: http-nio Version : 0.1.0 Upstream Author : Daniel Gomez-Sanchez * URL : https://github.com/lbergelson/http-nio * License : BSD-3-Clause Programming Lang: Java Description : http/s file system provider for Java NIO.2 This package provides a http or https file system that can be used in conjunction with Java NIO.2. This lightweight library provides a few classes related to file systems and paths. It is provided by the developers of gatk, which is a long-term packaging target of Debian-med team. I am packaging it as a reverse dependency of gatk. For this reason, it will be team-maintained inside Debian-med team.
Bug#1008128: ITP: gatk-fermilite -- interface to call Heng Li's fermi-lite assembler from Java code
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: gatk-fermilite Version : 1.2.1 Upstream Author : Broad Institute * URL : https://github.com/broadinstitute/gatk-fermilite-jni * License : BSD-3-clause Programming Lang: Java, C Description : interface to call Heng Li's fermi-lite assembler from Java code Fml-asm (fermi-lite assembler) is a command-line tool for assembling Illumina short reads in regions from 100bp to 10 million bp in size, based on the fermi-lite library. gatk-fermilite provides a Java library and a shared library to allow one to use fermilite from Java code. The package will be team-maintained inside Debian-med team. It is needed as a dependency of the packaging target gatk.
Re: Advice needed: building new gatk-bwamem-jni against another version of bwa
Hi Andrius, Thanks for looking at my issue. Le 14/03/2022 à 06:03, Andrius Merkys a écrit : Hi Pierre, On 2022-03-13 16:35, Pierre Gruet wrote: My proposal would be to design a multiple upstream tarball for gatk-bwamem-jni: original one + the sources at the tip of the Apache2 branch of bwa. It would build a libbwa.a lib which would not be installed in /usr/lib, but in a private directory of gatk-bwamem-jni. Quick question. AFAIU, libbwa.a would be statically linked to gatk-bwamem-jni binaries. So would there still be a need to install libbwa.a anywhere? Yes this is totally right, my mistake. In fact there would be no (alternative) libbwa.a to install, the link to the JNI shared library would indeed be static. Thanks for pointing this out. Best, Andrius Best, -- Pierre
Re: Advice needed: building new gatk-bwamem-jni against another version of bwa
Hi Nilesh, Thanks for the quick answer. Your advice is much appreciated, as always. Le 13/03/2022 à 15:46, Nilesh Patra a écrit : On 3/13/22 8:05 PM, Pierre Gruet wrote: What should I do? My proposal would be to design a multiple upstream tarball for gatk-bwamem-jni: original one + the sources at the tip of the Apache2 branch of bwa.> It would build a libbwa.a lib which would not be installed in /usr/lib, but in a private directory of gatk-bwamem-jni. By doing so, I would not interfere with the currently Debian-packaged bwa and I would also be able to build, run and ship gatk-bwamem-jni... which would, still, be independent of the bwa that is shipped in Debian. Does this seem sensible? Introducing code copies in packages are bad for several reasons - for instance, possible security issues in the embedded copy that would go into next stable release; and hence this should be the last resort. Probably the better thing to do would be to instead talk to upstream about it and ask them to port the code to latest bwa versions. If the ETA is sensible, it makes sense to wait; however if nothing else works, vendoring should work as you proposed. Sure, security is a big issue and also the reason I asked here. You're right, anyway upstream should be asked about it first. My ultimate packaging target is gatk, so I guess we have a bit of work before getting it: plenty of time to exchange with upstream. If you want a multi-orig solution, please do it programmatically with d/watch and d/gbp.conf as for instance done in JS team[1] [1]: https://wiki.debian.org/Javascript/GroupSourcesTutorial#Manual_way Incidentally I have already worked on some MUT packages, so yes, I am used to do so! Regards, Nilesh Best, -- Pierre
Advice needed: building new gatk-bwamem-jni against another version of bwa
Hello everyone, I need your advice on a packaging issue I am meeting right now. I am in the course of packaging gatk-bwamem-jni [0], providing a native interface which allows one to use bwa (Debian packaged [1]) from Java code. Fine. But the upstream of gatk-bwamem-jni relies on a version of bwa which is the tip of a -- now stale -- branch called "Apache2" in the Github repository of bwa. It cannot build against the Debian-packaged libbwa-dev as differences between the bwa branches "Apache2" and "master" are now too important. What should I do? My proposal would be to design a multiple upstream tarball for gatk-bwamem-jni: original one + the sources at the tip of the Apache2 branch of bwa. It would build a libbwa.a lib which would not be installed in /usr/lib, but in a private directory of gatk-bwamem-jni. By doing so, I would not interfere with the currently Debian-packaged bwa and I would also be able to build, run and ship gatk-bwamem-jni... which would, still, be independent of the bwa that is shipped in Debian. Does this seem sensible? Thanks a lot for your attention and help. Best regards, -- Pierre [0] https://github.com/broadinstitute/gatk-bwamem-jni [1] https://tracker.debian.org/pkg/bwa OpenPGP_signature Description: OpenPGP digital signature
Bug#1006834: ITP: aeonbits-owner -- API to handle application configuration through Java properties file
Package: wnpp Severity: wishlist Owner: Debian med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: aeonbits-owner Version : 1.0.12 Upstream Author : Luigi R. Viggiano * URL : http://owner.aeonbits.org/ * License : BSD-3-clause Programming Lang: Java Description : API to handle application configuration through Java properties file OWNER was written because the code dealing with the configuration is frequently repetitive, redundant, it’s made of static classes, singletons, long list of methods just doing conversion from a string property to a named method returning a Java primitive or a basic Java object. OWNER solves the problem providing an interface object that - is easy to mock, easy to pass to other objects (via dependency injection); - declaratively maps the configuration without any redundancy; - can easily expand the loading logic in order to have multiple configuration files, multiple level of overriding (global configuration, user-level, defaults, etc); - doesn’t need to have an actual properties file backing the configuration, if one uses @DefaultValue. - provides a lot of features, like hot reloading, variables expansion, etc; - leaves one free to do everything one is already doing with java.util.Properties; - does support a super powerful type conversion, which includes arrays, collections, many standard Java objects, and even the possibility to plug one's own conversion logic. The package is needed as a dependency of gatk, which is a packaging target of Debian-med team. It will be maintained in this team.
Bug#1006501: ITP: snpsift -- tool to annotate and manipulate genome variants
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: snpsift Version : 5.1 Upstream Author : Pablo Cingolani * URL : https://pcingola.github.io/SnpEff/ss_introduction/ * License : Expat Programming Lang: Java Description : tool to annotate and manipulate genome variants SnpSift is a toolbox that allows one to filter and manipulate annotated files. Once the genomic variants have been annotated, one needs to filter them out in order to find the "interesting / relevant variants". Given the large data files, this is not a trivial task (e.g. one cannot load all the variants into XLS spreadsheet). SnpSift helps to perform this VCF file manipulation and filtering required at this stage in data processing pipelines. The package will be team-maintained by Debian-med team.
Re: Datasets to design autopkgtests for our packages
Hi Andrius, Le 18/02/2022 à 17:21, Andrius Merkys a écrit : Hi Pierre, On 2022-02-18 17:52, Pierre Gruet wrote: To give a bit of context: I am currently writing autopkgtests for htsjdk, which is one Java library we maintain in the team. Those autopkgtests should test reverse-dependencies to ease upgrades of htsjdk. When designing such tests, I would need data to run, let's say, artemis or igv which process FASTA, or whatever, files. Do you have some idea of a place to get data files that can be safely included in our packages for such uses? Maybe some website with open data? It depends whether you need simple protein FASTA sequences or alignments. You may find simple sequences in PDB, for example [1], go to "Download Files" and FASTA format is just there. AFAIR, PDB data is freely distributable. Thanks! I will have a look. In any case, this is exactly the kind of information I was asking for :) [1] https://www.rcsb.org/structure/6fti Best, Andrius Best regards, -- Pierre
Datasets to design autopkgtests for our packages
Hi everyone, To give a bit of context: I am currently writing autopkgtests for htsjdk, which is one Java library we maintain in the team. Those autopkgtests should test reverse-dependencies to ease upgrades of htsjdk. When designing such tests, I would need data to run, let's say, artemis or igv which process FASTA, or whatever, files. Do you have some idea of a place to get data files that can be safely included in our packages for such uses? Maybe some website with open data? Thanks a lot in any case, -- Pierre
Bug#1005356: ITP: rockhopper -- system for analyzing bacterial RNA-seq data
Hi, Le 12/02/2022 à 06:42, Andreas Tille a écrit : Very cool! You're welcome! Eventually, all the .class files in the archive were just igv and its dependencies, so that I could remove all of them and have igv as the sole dependency of the binary package :-) Best regards, -- Pierre
Bug#1005356: ITP: rockhopper -- system for analyzing bacterial RNA-seq data
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: rockhopper Version : 2.0.3 Upstream Author : Brian Tjaden * URL : https://cs.wellesley.edu/~btjaden/Rockhopper * License : GPL-3+ Programming Lang: Java Description : system for analyzing bacterial RNA-seq data Rockhopper is a comprehensive and user-friendly system for computational analysis of bacterial RNA-seq data. As input, Rockhopper takes RNA sequencing reads output by high-throughput sequencing technology (FASTQ, QSEQ, FASTA, SAM, or BAM files). Rockhopper supports the following tasks: * Reference based transcript assembly (when one or more reference genomes are available) - Aligning reads to genomes - Assembling transcripts - Identifying transcript boundaries and novel transcripts such as small RNAs * De novo transcript assembly (when reference genomes are unavailable) * Normalizing data from different experiments * Quantifying transcript abundance * Testing for differential gene expression * Characterizing operon structures * Visualizing results in a genome browser The package will be team-maintained by Debian-med team.
Re: New version of snpeff in Git (Was: snpeff_4.3t+dfsg1-1_amd64.changes REJECTED)
Hi again, Le 03/02/2022 à 22:22, Andreas Tille a écrit : Am Thu, Feb 03, 2022 at 02:42:40PM +0100 schrieb Pierre Gruet: Yes, just before looking at king/libpdfbox-graphics2d-java I was updating snpeff and seeing if I could turn some unit tests into autopkgtests -- and I trust I can, this is my current task. Fine. So if you think putting snpeff can be delayed 2 or 3 days, let's just wait I write the tests. Else, please consider uploading, this is fine :) Well, the arrival of snpeff took years - so a couple of days for an updated version does not matter at all. I just stumbled upon the uscan issue and was wondering what might be going on. Well, thanks for your opinion about this! By the way, now I realize the above-quoted suggestion was a bit silly: because of the testing migration delay, an upload with autopkgtest "2 or 3 days" later would just have erased the first one. I did not have that in mind at the time of writing...! Thanks for all your work Andreas. PS: If you are seeking for new challenges my colleagues would be happy about https://salsa.debian.org/med-team/rockhopper I just realised that there is an issue even with Build-Depends and I remember it was quite some mess with lots of binary *.class files included. Definitely nothing you can work out in one evening. ;-) I will keep that in mind, ok :-D Thanks for the feedback, as always, Best, -- Pierre
Re: New version of snpeff in Git (Was: snpeff_4.3t+dfsg1-1_amd64.changes REJECTED)
Hi Andreas, Le 03/02/2022 à 10:31, Andreas Tille a écrit : Hi, Am Sat, Jan 22, 2022 at 09:49:32PM +0100 schrieb Pierre Gruet: I did the upload -- I agree autopkgtests would be valuable, still. Yet I remember the tests I did when designing the package last Spring, and I feel providing a dataset is necessary for even a basic use of snpeff, which, I think, makes the design of an autopkgtest difficult. But if anyone has specific ideas -- maybe you, Steffen? -- I would be really happy to implement them. Or else, I will have a look again! I realised that you commited 5.1+dfsg which builds nicely for me and also fixes the watch file (which I'm hunting for in all our packages). Do you have any reason to wait with uploading the current status in Git? Ha, this is the second time today I see I should have put information in d/changelog for such case ;) sorry for not doing it, next time I will. I mean, if we can't provide an autopkgtest yet the current Git has a lot of advantages for our users. Yes, just before looking at king/libpdfbox-graphics2d-java I was updating snpeff and seeing if I could turn some unit tests into autopkgtests -- and I trust I can, this is my current task. So if you think putting snpeff can be delayed 2 or 3 days, let's just wait I write the tests. Else, please consider uploading, this is fine :) Kind regards Andreas. Best regards, -- Pierre
Re: Java help for king needed
Hi, Le 28/01/2022 à 22:42, Andreas Tille a écrit : Am Fri, Jan 28, 2022 at 10:11:27PM +0100 schrieb pgtdeb...@free.fr: If you want, I would be happy to package pdfbox-graphics2d. I can do that very soon. Else, please tell me if you start something :-) I've pushed https://salsa.debian.org/java-team/libpdfbox-graphics2d-java and would like to hand over from here. d/control needs (Build-)Depends d/rules is a rough template d/copyright could need some review Thanks a lot for your offer to work on this Just dropping a note here: king is ready for an upload but we just have to wait that libpdfbox-graphics2d-java exits NEW before... Andreas. Bye, -- Pierre
Re: Java help for king needed
Hi Andreas, Le 28/01/2022 à 22:42, Andreas Tille a écrit : Am Fri, Jan 28, 2022 at 10:11:27PM +0100 schrieb pgtdeb...@free.fr: If you want, I would be happy to package pdfbox-graphics2d. I can do that very soon. Else, please tell me if you start something :-) I've pushed https://salsa.debian.org/java-team/libpdfbox-graphics2d-java and would like to hand over from here. d/control needs (Build-)Depends d/rules is a rough template d/copyright could need some review Thanks! I think the package now looks quite nice. I will just do some checks tomorrow, write the ITP bug and upload. Thanks a lot for your offer to work on this Andreas. And thanks for initiating the packaging. Best regards, -- Pierre
Re: Java help for king needed
Hi Andreas, Le 28/01/2022 à 22:30, Andreas Tille a écrit : Am Fri, Jan 28, 2022 at 10:11:27PM +0100 schrieb pgtdeb...@free.fr: If you want, I would be happy to package pdfbox-graphics2d. I can do that very soon. Else, please tell me if you start something :-) I've just collected a basic debian/ dir and will push soon. I'd love if you'll take over later. Please do, I will do so when it is pushed :-) Kind regards Andreas. Best regards, -- Pierre
Re: 20 years of Debian Med list :-) and suggested sprint date
Dear all, Le 24/01/2022 à 16:09, Andreas Tille a écrit : Hi folks, on Mon, 21 Jan 2002 11:59:11 +0100 the first mail to this list was sent[1]. So somehow we can celebrate some anniversary. :-) Great :-) Happy to celebrate this! Since 11 years we are doing team sprints - preferably face to face but last year it was not possible and thus we did it online. Same seems to be true for this year. I'd suggest a three days meeting either from Friday 11.2. - Sunday 13.2. or Friday 18.2. - Sunday 20.2. February 18th is a heavy day in my day job agenda, so I would be happier with the first range of dates. But if you select the second one no worry, I will join as much as possible in any case. We can use https://app.element.io/#/room/#_oftc_#debian-ftp:matrix.org as meeting space and can do Jitsi meetings every second hour as we did last year. I'd be happy if people who intend to join would confirm joining the sprint and what date might be prefered. Kind regards Andreas. [1] https://lists.debian.org/debian-med/2002/01/msg0.html Warm regards, -- Pierre
Re: snpeff_4.3t+dfsg1-1_amd64.changes REJECTED
Hi again Andreas, Le 22/01/2022 à 21:24, Andreas Tille a écrit : Hi Pierre, Am Sat, Jan 22, 2022 at 08:37:54PM +0100 schrieb Pierre Gruet: Le 22/01/2022 à 16:43, Andreas Tille a écrit : Thanks a lot Pierre for fixing it quickly in a new upload. Its a great step forward if we have this package. Thanks also to Thorsten for checking You're welcome! Thanks for taking time to write this. I usually inform ftpmaster about a re-upload. This seems to enhance the chances to get processed quickly (but there are few counter-examples). Yeah, I remembered you usually did so! And I followed your example, seemingly successfully. Maybe you saw the package eventually got accepted quickly after the second upload to NEW. Now we have snpeff, cool! Yes, very cool. There are a few things to tweak in the source-only upload, but not that much. I shall make it soon! Some autopkgtest would be cool - but feel free to do the changes you planed and upload without a test. I did the upload -- I agree autopkgtests would be valuable, still. Yet I remember the tests I did when designing the package last Spring, and I feel providing a dataset is necessary for even a basic use of snpeff, which, I think, makes the design of an autopkgtest difficult. But if anyone has specific ideas -- maybe you, Steffen? -- I would be really happy to implement them. Or else, I will have a look again! Thanks again Andreas. Have a great Sunday, -- Pierre
Re: snpeff_4.3t+dfsg1-1_amd64.changes REJECTED
[redirecting to debian-med@lists.debian.org for information] Hi Andreas, Le 22/01/2022 à 16:43, Andreas Tille a écrit : Thanks a lot Pierre for fixing it quickly in a new upload. Its a great step forward if we have this package. Thanks also to Thorsten for checking You're welcome! Thanks for taking time to write this. Maybe you saw the package eventually got accepted quickly after the second upload to NEW. Now we have snpeff, cool! There are a few things to tweak in the source-only upload, but not that much. I shall make it soon! Andreas. Best regards, -- Pierre
Bug#1004152: ITP: malt -- sequence alignment and analysis tool to process sequencing data
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: malt Version : 0.5.2 Upstream Author : Daniel Huson * URL : https://github.com/danielhuson/malt * License : GPL-3+ Programming Lang: Java Description : sequence alignment and analysis tool to process sequencing data MALT, an acronym for MEGAN alignment tool, is a sequence alignment and analysis tool designed for processing high-throughput sequencing data, especially in the context of metagenomics. It is an extension of MEGAN6, the MEGenome Analyzer and is designed to provide the input for MEGAN6, but can also be used independently of MEGAN6. The core of the program is a sequence alignment engine that aligns DNA or protein sequences to a DNA or protein reference database in either BLASTN (DNA queries and DNA references), BLASTX (DNA queries and protein references) or BLASTP (protein queries and protein references) mode. The engine uses a banded-alignment algorithm with ane gap scores and BLOSUM substitution matrices (in the case of protein alignments). The program can compute both local alignments (Smith-Waterman) or semi-global alignments (in which reads are aligned end-to-end into reference sequences), the latter being more appropriate for aligning metagenomic reads to references. The package will be team-maintained in Debian-med team.
Bug#1003782: ITP: megan-ce -- interactive tool to explore and analyse microbiome sequencing data
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: megan-ce Version : 6.21.1 Upstream Author : Daniel Huson * URL : https://github.com/danielhuson/megan-ce * License : GPL-3+ Programming Lang: Java Description : interactive tool to explore and analyse microbiome sequencing data MEGAN Community Edition is a shotgun sequencer to analyze microbiome samples. It is a rewrite and extension of the widely-used microbiome analysis tool MEGAN so as to facilitate the interactive analysis of the taxonomic and functional content of very large microbiome datasets. Other new features include a functional classifier called InterPro2GO, gene-centric read assembly, principal coordinate analysis of taxonomy and function, and support for metadata. By integrating MEGAN CE with the high-throughput DNA-to-protein alignment tool DIAMOND a powerful and complete pipeline for the analysis of metagenome shotgun sequences can be provided. megan-ce will be team-maintained by Debian-med team.
Re: [Advent bug squashing] Pierre Gruet fixed: Bug#1002155: marked as done (libgoby-java: FTBFS: [WARNING] /<>/goby-io/../goby-distribution/src/main/java/org/campagnelab/goby/modes/FastaT
Hi Andreas, On 23/12/2021 19:42, Andreas Tille wrote: Hi Pierre, Am Thu, Dec 23, 2021 at 05:42:24PM +0100 schrieb Pierre Gruet: You're welcome! Thanks for your help on this. That's team work, isn't it? ;-) Sure ! :) BTW, if you are seeking new challanges: It would be great to have malt[1] and megan-ce[2]. Both repositories are untouched for more than three years. The point where I gave up is that both projects need code from each other and we somehow need to bootstrap one first by injecting the code from the other and once it is available make the other depend from it. At the time I gave up with this there were also problems with libsis-hdf5-java and I never managed to come back to this. So its not something that we need to hurry about - but the project itself is somehow known. Thanks for drawing my attention to these two repositories, I shall have a look! But may be its not as important as gatk - so well, there are some challenges left for the new year. ;-) Ah... yes, gatk. Steffen and I looked at it last Summer, we put the long list of its missing dependencies in the common spreadsheet. I admit a great amount of courage will be necessary to tackle this list. Yet, little by little... we could do it. Kind regards and thanks again Andreas. Kind regards, and merry Christmas to everyone here who celebrate it! -- Pierre
Re: [Advent bug squashing] Pierre Gruet fixed: Bug#1002155: marked as done (libgoby-java: FTBFS: [WARNING] /<>/goby-io/../goby-distribution/src/main/java/org/campagnelab/goby/modes/FastaT
Hi Andreas, On 23/12/2021 17:27, Andreas Tille wrote: Thanks Pierre for your work. :-) Maintainer: Debian Med Packaging Team Changed-By: Pierre Gruet Closes: 1002155 Changes: libgoby-java (3.3.1+dfsg2-6) unstable; urgency=medium . * Adding --no-parallel flag to dh_auto_test to avoid concurrent access to some files during the tests (Closes: #1002155) You're welcome! Thanks for your help on this. While we are at it: this new version solved the issue but another test failed, seemingly for the same reason. So I uploaded version 3.3.1+dfsg2-7 which ensures the folder in which tests should print their outputs exists before running them. Well, this worked! Sidenote: I have just uploaded latest upstream version of igv (which depends on goby). To do so, I had to remove some features that need the Amazon SDK. It should not be a real problem for our users as those features simplify grasping files from Amazon servers in some conditions, but they don't prevent anyone from getting genome files and browsing them! Cheers, -- Pierre
Re: libgoby-java: FTBFS: [WARNING] /<>/goby-io/../goby-distribution/src/main/java/org/campagnelab/goby/modes/FastaToCompactMode.java:23: error: package edu.rit.pj does not exist
Control: tags -1 unreproducible help Hi, Currently I am not able to reproduce the issue on my computer nor on several machines of the Debian project. I shall investigate further a bit later, but so far looking at a diff between the provided build log and mine has not helped. The warning mentioned in the bug title is issued by the Javadoc builder, which we do not use. It does not trigger the failure of the build. The real issue is in the tests: for some reason, a FileNotFoundException is raised by the FileOutputStream constructor when being called on files in the test-results/ directory. Cheers, -- Pierre
Re: autopkgtest requiring large data sets (pique, hinge)
Hello Lance, On 21/12/2021 14:33, Lance Lin wrote: Debian Medical Team, I have started looking at adding autopkgtest suites for a variety of packages. Two of the packages (hinge, pique) require very large data sets to run their included examples. The sizes are several GB. It also looks like they may be graphical in nature. Thanks for working on adding tests to the packages. For sure this is always useful! Is it permissible for autopkgtest suites to download such large amounts of data from the internet? Or should they be included in the repo? Autopkgtests must be able to run on a minimal system with only the unpacked source tree, the dependencies of the binary packages, and no access to the Internet. This implies that one cannot rely on downloading while running the tests: the data that you use have to be included in the installed binary packages or to lie in the source tree. If so, I am happy to continue to look at these packages to include some basic level of testing. Yes please, making efforts to write tests is definitely worth it. From my experience, you might contact upstream developers to ask them for meaningful commands requiring no more data that the ones that are in the source tree. Friendly upstreams usually Thank you! As I don't have direct domain knowledge of the technology Hope this is useful, Best, -- Pierre Lance Lin GPG Fingerprint: 8CAD 1250 8EE0 3A41 7223 03EC 7096 F91E D75D 028F P.S.: I am CC'ing explicitly as I don't know if you subscribed to the debian-med list. Next time I won't, assuming you did.
Re: Scala error when trying to build latest version of pilon
Hi Andreas, On 18/12/2021 08:52, Andreas Tille wrote: Hi Pierre, Am Fri, Dec 17, 2021 at 11:27:50PM +0100 schrieb Pierre Gruet: I have just uploaded latest upstream version of pilon to unstable, together with a fix for the scala issues showing up. Normally we would have had to update scala from 2.11 to 2.13, but here the fix was very short to write. Thanks a lot! Sorry, I mixed up the changelog entries a bit because I forgot to pull from Salsa before working on the package, but now on Salsa everything is right. :-) Anyway, for sure the right thing would be to upgrade Scala. Yep. We need this anyway. Right! This email is the opportunity to ask you a question: I saw you were the initial sponsor of sbt, the Scala Build Tool. The source package was accepted with a lot of embedded jars inside. Do you remember if you had some discussion with FTP Masters about it before they accepted the package? Arguably this is costly to avoid in such a setting, where we need Scala dependencies to build a tool that builds Scala programs... I vaguely remember that the bootstrapping process required some discussion with ftpmaster but I forgot the details. Since the discussion was long ago I think it needs to be taken up again if needed. No problem! Thanks for confirming this discussion took place. Admittedly we would have to hold it again when upgrading the packages. I am regularly spending time collecting the repositories with the sources of those embedded jars. Some are hard to find. Still, I think this is a necessary (but huge) step to go on packaging all the Scala stuff. I am interested in this, because I regularly give some time to improving the state of the Scala ecosystem in Debian, and sbt if central in it. It would be really great if you could update Scala since we will face issues over and over with other recent software using it. Indeed...! I also see it more and more often. Warm regards, Same to you Andreas. Best, -- Pierre
Re: Scala error when trying to build latest version of pilon
Hi Andreas, On 09/09/2021 14:21, Andreas Tille wrote: Hi Pierre, thanks a lot for your educated answer. On Thu, Sep 09, 2021 at 12:48:33PM +0200, Pierre Gruet wrote: Any hint how to fix this? Well, /maybe/ we could patch this last pilon version to use Scala 2.11 with it... but I see there were quite a lot of changed in pilon seemingly related to newer Scala [3,4], so I am unsure we would succeed. Regarding pilon we are not in a hurry. Its just one of the packages with broken watch file I'm touching step by step. I have just uploaded latest upstream version of pilon to unstable, together with a fix for the scala issues showing up. Normally we would have had to update scala from 2.11 to 2.13, but here the fix was very short to write. Sorry, I mixed up the changelog entries a bit because I forgot to pull from Salsa before working on the package, but now on Salsa everything is right. Anyway, for sure the right thing would be to upgrade Scala. Yep. We need this anyway. Right! This email is the opportunity to ask you a question: I saw you were the initial sponsor of sbt, the Scala Build Tool. The source package was accepted with a lot of embedded jars inside. Do you remember if you had some discussion with FTP Masters about it before they accepted the package? Arguably this is costly to avoid in such a setting, where we need Scala dependencies to build a tool that builds Scala programs... I am interested in this, because I regularly give some time to improving the state of the Scala ecosystem in Debian, and sbt if central in it. This is one thing I would like to do and discuss with the Java team, will try to do it quite soon... This would be cool. Please do not waste time with patching pilon meanwhile. Kind regards Andreas. Warm regards, -- Pierre
[Advent bug squashing] Fwd: Bug#1001681: marked as done (sight: FTBFS in unstable)
RC bug in sight is now fixed! Forwarded Message Subject: Bug#1001681: marked as done (sight: FTBFS in unstable) Date: Thu, 16 Dec 2021 06:21:03 + From: Debian Bug Tracking System Reply-To: 1001...@bugs.debian.org To: Pierre Gruet Your message dated Thu, 16 Dec 2021 06:18:37 + with message-id and subject line Bug#1001681: fixed in sight 21.0.0-3 has caused the Debian Bug report #1001681, regarding sight: FTBFS in unstable to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1001681: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001681 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: sight Version: 21.0.0-2 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu jammy Hi Flavien, sight is failing to build in unstable right now with the following error: cd /tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/io/dimse && /usr/bin/c++ -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_LOG_DYN_LINK -DBOOST_LOG_SETUP_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SPIRIT_USE_PHOENIX_V3 -DBOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0 -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_PROVIDES_FUTURE -DBOOST_THREAD_VERSION=2 -DIO_DIMSE_EXPORTS -Dio_dimse_EXPORTS -I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/io/dimse/include -I/tmp/sight-21.0.0/libs -I/tmp/sight-21.0.0/libs/core -I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/pch/pchData/include/pchData -I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/core/include -I/usr/include/libxml2 -I/tmp/sight-21.0.0/obj-x86_64-linux-gnu/libs/core/data/include -g -O2 -ffile-prefix-map=/tmp/sight-21.0.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -march=sandybridge -mtune=generic -mfpmath=sse -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -Wconversion -Wno-unused-parameter -Wno-ignored-qualifiers -std=gnu++17 -include "pch.hpp" -Winvalid-pch -MD -MT libs/io/dimse/CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o -MF CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o.d -o CMakeFiles/io_dimse.dir/SeriesEnquirer.cpp.o -c /tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp /tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp: In member function 'std::string sight::io::dimse::SeriesEnquirer::findSOPInstanceUID(const string&, unsigned int)': /tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:5: error: 'OFIterator' was not declared in this scope; did you mean 'OF_error'? 748 | OFIterator it= responses.begin(); | ^~ | OF_error /tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:26: error: expected primary-expression before '*' token 748 | OFIterator it= responses.begin(); | ^ /tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:27: error: expected primary-expression before '>' token 748 | OFIterator it= responses.begin(); | ^ /tmp/sight-21.0.0/libs/io/dimse/SeriesEnquirer.cpp:748:29: error: 'it' was not declared in this scope; did you mean 'io'? 748 | OFIterator it= responses.begin(); | ^~ | io I don't know where OFIterator is supposed to come from, but clearly something has changed. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Source: sight Source-Version: 21.0.0-3 Done: Pierre Gruet We believe that the bug you reported is fixed in the latest version of sight, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1001...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Pierre Gruet (supplier of updated sight package) (This message was generated automatically at their request; if you believ
[Advent bug squashing] Bugs #989328 and #989961 : newest picard-tools in unstable
Hi, Newest picard-tools is in unstable, and I fixed the two bugs the source package had! Best, Pierre
Re: RM profphd?
Hi Nilesh, Le 23/11/2021 à 19:11, Nilesh Patra a écrit : Hi, It looks like profphd has a open RC bug for a little over two years by now, and upstream looks dead. It has only reverse-recommends, no reverse-(build-)depends $ reverse-depends profphd Reverse-Recommends * norsnet * norsp * profbval * profphd-utils [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x] Is it a candidate for removal? Should I request a RM? I think it is very reasonable to do so, yes. The discussions in the thread of the RC bug and my personal examinations of the package make me think no one will ever care for the issues (if I remember correctly, mostly linked to the many many occurrences of the $[ variable in the Perl code). Regards, Nilesh Best regards, -- Pierre
Re: libjung-java needs some love
Hi, Le 10/11/2021 à 15:14, Andreas Tille a écrit : Hi, I realised that libjung-java "smells"[1] and in fact it was not uploaded a long time and has some maintenance issues. I tried to build the current state in Git but it fails the API fails to build. I hope this is not a big issue for a Java educated DD. I am interested in working on this and I will do it in the coming days provided that no usual uploader is willing to do so, of course. Kind regards Andreas. [1] https://trends.debian.net/packages-with-smells-sorted-by-maintainer.txt Best, -- Pierre
Re: Thanks a lot for enabling igv in main [Was: igv_2.6.3+dfsg2-1_amd64.changes ACCEPTED into unstable, unstable]
Hi Andreas, Le 09/11/2021 à 18:29, Andreas Tille a écrit : Hi Pierre, Am Tue, Nov 09, 2021 at 06:02:39PM +0100 schrieb Pierre Gruet: If you are not able to reproduce I can send a full build log. It would be fine for me if you would just fix - build - upload yourself. I just wanted to help a bit. ;-) Sure, thanks for your help on this! Unfortunately I am not able to reproduce this failure at home, so I would enjoy getting your build log please. Sent via private mail to not bloat the list archive with binary files. Thanks! I saw the test failing on your side is a thread safety test. DO you have any idea why it fails on your machine? Are you enabling some multithread features by default...? Just trying to guess. I still have in mind some failures in libsis-jhdf5-java, which were caused by a tricky garbage collector problem showing up on some machines only. We eventually got this fixed, but I truly hope it will be far easier with igv. Smells like excluding the test is a sensible thing. On the other hand if Salsa-CI and autobuilders would be OK I'd be fine if you do a source only upload. I should say I am hesitating to remove the test about thread safety, and it is true things are OK on Salsa-CI and on the autobuilders. Yet, before source-only-uploading, I would like to at least dig a bit on the issue you are facing. But if we cannot reproduce it, then I think a source-only upload will be OK. Kind regards Andreas. Best regards, -- Pierre
Re: Thanks a lot for enabling igv in main [Was: igv_2.6.3+dfsg2-1_amd64.changes ACCEPTED into unstable, unstable]
Hi Andreas, Le 09/11/2021 à 07:55, Andreas Tille a écrit : Hi Pierre, thanks a lot for all your work on this. You are welcome! Indeed I am very pleased this long-term target of mine is now reached! I intended to do a source-only upload and when doing so at least fixing the watch file (I remember we need to stick for the current version for the moment ;-) ). Thanks for this fix. Unfortunately I was running in a build failure in my pbuilder chroot 432 tests completed, 1 failed, 103 skipped Finished generating test XML results (0.04 secs) into: /build/igv-2.6.3+dfsg2/build_java11/test-results/test Generating HTML test report... Finished generating test html results (0.109 secs) into: /build/igv-2.6.3+dfsg2/build_java11/reports/tests/test :test FAILED :test (Thread[Task worker for ':',5,main]) completed. Took 1 mins 55.727 secs. If you are not able to reproduce I can send a full build log. It would be fine for me if you would just fix - build - upload yourself. I just wanted to help a bit. ;-) Sure, thanks for your help on this! Unfortunately I am not able to reproduce this failure at home, so I would enjoy getting your build log please. I still have in mind some failures in libsis-jhdf5-java, which were caused by a tricky garbage collector problem showing up on some machines only. We eventually got this fixed, but I truly hope it will be far easier with igv. Thanks again Andreas. Best wishes, -- Pierre
Bug#996993: ITP: biojava5-live -- Java API to biological data and applications (version 5)
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: biojava5-live Version : 5.4.0 Upstream Author : BioJava Developers * URL : https://www.biojava.org/ * License : LGPL-2.1 Programming Lang: Java Description : Java API to biological data and applications (version 5) This package presents the Open Source Java API to biological databases and a series of mostly sequence-based algorithms. BioJava is an open-source project dedicated to providing a Java framework for processing biological data. It includes objects for manipulating sequences, file parsers, server support, access to BioSQL and Ensembl databases, and powerful analysis and statistical routines including a dynamic programming toolkit. This is the version 5 of biojava, which brings several changes compared to version 4, packaged in biojava4-live. It will be maintained by the Debian-med team.
Re: New upstream version of drop-seq does not build
Hi Andreas, Le 13/10/2021 à 07:38, Andreas Tille a écrit : Hi Pierre, Am Tue, Oct 12, 2021 at 09:13:49PM +0200 schrieb Pierre Gruet: Cool. I also think we should pimp biojava4 watch file to return the last upstream source of biojava4 and than also provide biojava5. We will soon see upstreams using this and may be we can migrate existing packages to version 5.4. Sure! The watch file of biojava4-live seems OK, as it mentions https://github.com/biojava/biojava/tags .*/biojava-?(4\S*)\.tar\.gz Yep, but with more and more 5.x tags uscan was not able to find these versions any more. I've just fixed this[1] soon after I've sent my mail. ;-) Sorry, now I understand the concern :-) Thanks for the fix! Kind regards Andreas. Best regards, -- Pierre
Re: New upstream version of drop-seq does not build
Hi again, Le 12/10/2021 à 18:58, Andreas Tille a écrit : Hi Pierre, Am Tue, Oct 12, 2021 at 03:29:33PM +0200 schrieb Pierre Gruet: I have added biojava4 as a dependency, then some paths had to be changed because upstream relies on a far outdated version of biojava, and then I had to revise one autopkgtest. Now everything seems to be fine, I shall upload drop-seq soon! Cool. I also think we should pimp biojava4 watch file to return the last upstream source of biojava4 and than also provide biojava5. We will soon see upstreams using this and may be we can migrate existing packages to version 5.4. Sure! The watch file of biojava4-live seems OK, as it mentions https://github.com/biojava/biojava/tags .*/biojava-?(4\S*)\.tar\.gz so we can now work on the new package biojava5-live. Interestingly, after I forwarded a patch to the upstream of drop-seq today, they answered they would be interested in switching to biojava5. I offer to give it a try. Kind regards Andreas. Best regards, -- Pierre
Re: New upstream version of drop-seq does not build
Hi again, Le 12/10/2021 à 15:24, Andreas Tille a écrit : Am Tue, Oct 12, 2021 at 12:12:43PM +0200 schrieb Pierre Gruet: Thanks for pointing this out; I looked at it and saw biojava has not been a dependency of drop-seq until now. It seems version 2.4.1 is the first to need biojava. So I will try to add biojava4 as a dependency and see if drop-seq 2.4.1 can now be built. Ahhh, I should have checked this. Somehow I'm starting to get blind for such simple things when upgrading all those packages. ;-) I can understand this :-D I have added biojava4 as a dependency, then some paths had to be changed because upstream relies on a far outdated version of biojava, and then I had to revise one autopkgtest. Now everything seems to be fine, I shall upload drop-seq soon! Kind regards Andreas. Kind regards, -- Pierre
Re: New upstream version of drop-seq does not build
Hi Andreas, Le 12/10/2021 à 09:59, Andreas Tille a écrit : Hi Pierre, I realised that you updated Git of drop-seq to fix the watch file. I simply uploaded basically as is to have a proper signal in our tools that there is a new upstream version. Unfortunately I realised that there seems to be an issue with the new version 2.4.1 and Debian's biojava. I did not investigated deeper since I want to move on with other packages with broken watch files. So just droping a note here to let others know. Thanks for pointing this out; I looked at it and saw biojava has not been a dependency of drop-seq until now. It seems version 2.4.1 is the first to need biojava. So I will try to add biojava4 as a dependency and see if drop-seq 2.4.1 can now be built. Kind regards Andreas. Best regards, -- Pierre
Re: Pilon might need newer scala
Hi,
Le 01/10/2021 à 16:52, Andreas Tille a écrit :
Hi,
I intended to update pilon to its latest upstream version but
got:
scalac -classpath /usr/share/java/htsjdk.jar -d pilon.jar
src/main/scala/org/broadinstitute/pilon/*
src/main/scala/org/broadinstitute/pilon/BamFile.scala:24: error: object jdk is
not a member of package scala
import scala.jdk.CollectionConverters._
^
src/main/scala/org/broadinstitute/pilon/BamFile.scala:65: error: value asScala
is not a member of java.util.List[htsjdk.samtools.SAMSequenceRecord]
val seqs = r.getFileHeader.getSequenceDictionary.getSequences.asScala
^
src/main/scala/org/broadinstitute/pilon/BamFile.scala:96: error: value asScala
is not a member of htsjdk.samtools.SAMRecordIterator
val reads = r.queryUnmapped.asScala.filter(validateRead(_)).toList
^
src/main/scala/org/broadinstitute/pilon/BamFile.scala:119: error: value asScala
is not a member of htsjdk.samtools.SAMRecordIterator
possible cause: maybe a semicolon is missing before `value asScala'?
(region.start-1) max 0, (region.stop+1) min
region.contig.length).asScala
^
src/main/scala/org/broadinstitute/pilon/PileUpRegion.scala:22: error: object
jdk is not a member of package scala
import scala.jdk.CollectionConverters._
^
src/main/scala/org/broadinstitute/pilon/BamFile.scala:297: error: value asScala
is not a member of htsjdk.samtools.SAMRecordIterator
for (read <- r.iterator.asScala) {
^
src/main/scala/org/broadinstitute/pilon/BamFile.scala:341: error: value asScala
is not a member of htsjdk.samtools.SAMRecordIterator
val reads = r.queryOverlapping(region.name, region.start,
region.stop).asScala.filter(validateRead(_)).toList
^
src/main/scala/org/broadinstitute/pilon/Scaffold.scala:31: error: object jdk is
not a member of package scala
import scala.jdk.CollectionConverters._
^
src/main/scala/org/broadinstitute/pilon/PileUpRegion.scala:136: error: value
asScala is not a member of java.util.List[htsjdk.samtools.CigarElement]
val cigarElements = cigar.getCigarElements.asScala
^
src/main/scala/org/broadinstitute/pilon/Scaffold.scala:351: error: value
asScala is not a member of htsjdk.samtools.SAMRecordIterator
for (read <- reader.iterator.asScala if (!read.getReadUnmappedFlag)) {
^
10 errors found
Just verifying with Pierre whether my assumption that this requires
newer Scala is correct or whether there might be possibly a simple fix.
Yes, as a follow-up to the discussion we had some weeks ago [0]:
scala.jdk has been provided since Scala 2.13, and in Debian we are stuck
with 2.11 at the moment.
If I remember correctly, many of the last upstream commits of pilon
modify the code so that it needs Scala 2.13, and I figured out patching
the code to depend on Scala 2.11 would not be that trivial.
So yes, I think we definitely need a newer Scala :-(
Kind regards
Andreas.
Best regards,
--
Pierre
[0] https://lists.debian.org/debian-med/2021/09/msg00016.html
Re: Do users know about README.Debian and /usr/share/doc/packagename (Was: libcifpp)
Hi Andreas, Thanks for forking the thread and launching this conversation. Le 01/10/2021 à 08:48, Andreas Tille a écrit : Hi, Am Thu, Sep 30, 2021 at 02:10:50PM +0200 schrieb Pierre Gruet: My concern with this is the average user might not even know about the README.Debian file and could forget to check in the manpage. My gut feeling is that the average Debian Med user does not know about the docs we are providing. At least all those users I had the chance to ask have never read any README.Debian neither did they confirmed they know about /usr/share/doc/packagename. This is interesting, thanks for sharing this information. Actually I cannot say I am surprised. Do you know if users read our manpages? I feel we can expect /some/ users will type man command if something is not working as expected, but for sure not all of them will. But I am unsure there is a better way, as a debconf information, for instance, would be shown only once and only to the system administrator... I agree that debconf information (or debian/NEWS) will be seen only once by some admin and it is not sure whether the admin is a user at the same time and will pass the information. While I'm aware that this is not a good situation I do not have any idea how to enhance it. Have you sometimes used debconf to spread information? This (or debian/NEWS) gives a chance to reach some end users at the cost of implementing the debconf mechanism / writing a NEWS text. But if they skip the information and do not know about the /usr/share/doc/packagename directory... Kind regards Andreas. I am interested in ideas or comments on this issue! Best regards, -- Pierre
Re: libcifpp
Hi Maarten, Le 29/09/2021 à 17:28, Andreas Tille a écrit : Should I add a call to this update script in the post install hook? Having 500MB of data in Debian that's probably updated the very next day after installation seems very inconvenient, right? I'm not sure whether we have example solutions here. But this kind of volatile data should probably not be part of a package. The example I can think of is sepp: it provides tipp, which requires approx. 200 MB of data to be downloaded in order to be run. I have decided to let the burden of downloading those data (which could also be volatile, as Andreas underlines) to the user by adding a README.Debian file [0] and also information in the manpage [1] of the program. My concern with this is the average user might not even know about the README.Debian file and could forget to check in the manpage. But I am unsure there is a better way, as a debconf information, for instance, would be shown only once and only to the system administrator... Best regards, -- Pierre [0] https://salsa.debian.org/med-team/sepp/-/blob/master/debian/README.Debian [1] https://salsa.debian.org/med-team/sepp/-/blob/master/debian/man/run_tipp.py.1
Re: Upgrading IGV
HI Andreas, Le 28/09/2021 à 07:11, Andreas Tille a écrit : Hi Pierre, On Mon, Sep 27, 2021 at 08:38:34PM +0200, Pierre Gruet wrote: Actually the situation is a bit complicated with igv: - I am waiting for libgoby-java to exit NEW so that I can upload the version currently packaged to main instead of non-free; - Any newer upstream version would require new dependencies, including at least the SDK of Amazon, which is the reason why I expected to stay with the current version of igv until we can package this SDK. Does it seem sensible to you (and to the whole team)? Yes, this sounds very sensible. I think you also reported about this and I simply forgot. Feel free to revert my upstream version bump in Git. No problem! Yes I think I will revert the version bump as I planned to keep the same one. Thanks a lot for your patient work on this Andreas. And thanks for the discussion on the matter. Best regards, -- Pierre
Bug#995294: ITP: tipp -- taxonomic identification and abundance profiling tool
Package: wnpp Severity: wishlist Owner: Debian-med team X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org * Package name: tipp Version : 1.0 Upstream Author : Siavash Mirarab * URL : https://github.com/TeraTrees/TIPP * License : GPL-3 Programming Lang: Python, Java Description : taxonomic identification and abundance profiling tool TIPP is a modification of SEPP for classifying query sequences (i.e. reads) using phylogenetic placement. TIPP inserts each read into a taxonomic tree and uses the insertion location to identify the taxonomic lineage of the read. The novel idea behind TIPP is that rather than using the single best alignment and placement for taxonomic identification, it uses a collection of alignments and placements and considers statistical support for each alignment and placement. TIPP can also be used for abundance estimation by computing an abundance profile on the reads binned to marker genes in a reference dataset. sepp is already packaged in Debian, and up to now, the binaries of tipp were provided by sepp. Now the sources of sepp and tipp have been separated, which is the reason for making this package. tipp will be team-maintained by Debian-med team.
Re: Upgrading IGV
Hi Andreas, Le 27/09/2021 à 17:26, Andreas Tille a écrit : Hi Pierre, I was running routine-update on igv and as usually some patches did not applied. There is no urgent pressure to upgrade the package but its raising a signal that the watch file is not working (due to changes on github). The status in Git has a fixed watch file and it would help to push this to unstable to get this fixed. Do you have time to accomplish this? Kind regards Andreas. Actually the situation is a bit complicated with igv: - I am waiting for libgoby-java to exit NEW so that I can upload the version currently packaged to main instead of non-free; - Any newer upstream version would require new dependencies, including at least the SDK of Amazon, which is the reason why I expected to stay with the current version of igv until we can package this SDK. Does it seem sensible to you (and to the whole team)? Best regards, -- Pierre
Re: Any volunteer to verify autopkgtest of spades?
Hi Tony, Le 23/09/2021 à 22:06, Tony Travis a écrit : On 23/09/2021 17:16, Steffen Möller wrote: [...] You would install both the source tree (with the Debian folder) and install the binary. Then run sh debian/tests/run-unit-test from the source directory. Hi, Steffen. Please forgive my ignorance, but I don't know where to git clone a copy of the source tree from. Any advice would be gratefully accepted :-) No problem! You could install git-buildpackage if you don't have it, and then type gbp clone https://salsa.debian.org/med-team/spades.git to get all the relevant branches from Salsa. If you have a ssh key properly set up for Salsa, gbp clone git:salsa.debian.org:med-team/spades also works. If you don't know git-buildpackage, you could refer to the pdf provided by the package debmake-doc [0] and also to the documentation of git-buildpackage [1], which is nice. Alternatively, just using git clone https://salsa.debian.org/med-team/spades.git would be enough. If you need more details, just ask. Thanks, Tony. Best regards, -- Pierre [0] /usr/share/doc/debmake-doc/debmake-doc.en.pdf [1] /usr/share/doc/git-buildpackage/manual-html/index.html
