Re: RM pinfish?
Hi Nilesh, Am Sun, Sep 04, 2022 at 11:07:12PM +0530 schrieb Nilesh Patra: > Pinfish is working fine in the archive(no bugs), but upstream has abandoned > the development and marked the repo as read-only[1] > Since this does not look very important, is it ok to file a removal request? Steffen? You added this project to the spreadsheet[2]. Would you mind answering Nilesh's question? > I am not a user of the package, nor a bioinformatics guy, hence looking for > opinions > if this is useful. In case you are bored to be specified as Uploader I'd volunteer to exchange our names and upload. Kind regards Andreas. > [1]: https://github.com/nanoporetech/pinfish [2] https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 -- http://fam-tille.de
Re: RM pinfish?
On Wed, Sep 14, 2022 at 02:07:51PM +0200, Andreas Tille wrote: > Am Sun, Sep 04, 2022 at 11:07:12PM +0530 schrieb Nilesh Patra: > > I am not a user of the package, nor a bioinformatics guy, hence looking for > > opinions > > if this is useful. > > In case you are bored to be specified as Uploader I am partly bored because I have so many packages under my name and I have personal interest in only a few. But I also strongly belive in removing software that no-one is using. I agree that our packages usually have low popcon values, but if some package is _never_ gonna be used, and is abandoned upstream, I think it is an absolute waste of my time to keep maintaining it. Frankly, I'd do something else. The purpose of this mail is not to only push myself out of equation, but to also rm something that isn't useful for anyone in debian as such. > I'd volunteer to exchange our names and upload. This is a go package and you have told me several times that you aren't the best person to work on golang-related tasks, most recently on -hpc list[3] So if going forward a bug is reported against pinfish, you'd probably have to spend more time on it that you'd like. So I don't think just exchanging names is a very optimal thing to do here. If I don't hear from Steffen, or no-one raises an objection in the next three weeks, I'll proceed to file an RM bug. > > [1]: https://github.com/nanoporetech/pinfish > [2] > https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 [3]: https://lists.debian.org/debian-hpc/2022/08/msg00020.html -- Best, Nilesh signature.asc Description: PGP signature
Re: RM pinfish?
Hi Nilesh, Am Wed, Sep 14, 2022 at 06:23:58PM +0530 schrieb Nilesh Patra: > > In case you are bored to be specified as Uploader > > I am partly bored because I have so many packages under my name and I have > personal > interest in only a few. Perfectly understandable. > But I also strongly belive in removing software that no-one is using. I agree > that our packages usually have low popcon values, but if some package is > _never_ > gonna be used, How can we know? I simply trusted Steffens insight he has put into the spreadsheet[2] and have put Steffen in CC to confirm. In case he agrees that pinfish is not needed any more we should mention this in this sheet and remove the package accordingly. So my main motivation for my mail was to ping Steffen for clarification. > and is abandoned upstream, I think it is an absolute waste of > my time to keep maintaining it. Frankly, I'd do something else. This is not the first package abandoned upstream - we have even packages where you can find the source only in webarchive (and for sure debian.org). > The purpose of this mail is not to only push myself out of equation, but to > also > rm something that isn't useful for anyone in debian as such. I perfectly understand this. However, I think packages in [2] are useful for some purpose. > > I'd volunteer to exchange our names and upload. > > This is a go package and you have told me several times that you aren't the > best > person to work on golang-related tasks, most recently on -hpc list[3] That's correct. But we have packages in haskell (phybin) and D where I'm even worse. > So if going forward a bug is reported against pinfish, you'd probably have to > spend > more time on it that you'd like. I'd prefer to wait with removal until we have the situation of such a bug that might cause real trouble. > So I don't think just exchanging names is a very optimal thing to do here. > > If I don't hear from Steffen, or no-one raises an objection in the next three > weeks, I'll > proceed to file an RM bug. Steffen??? Kind regards Andreas. > > > [1]: https://github.com/nanoporetech/pinfish > > [2] > > https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 > [3]: https://lists.debian.org/debian-hpc/2022/08/msg00020.html > > -- > Best, > Nilesh -- http://fam-tille.de
[GSoC 2022 Final Report] Quality assurance for biological and medical applications inside Debian
Hello team \o/ , I'm Mohammed Bilal and I've been the GSoC intern working with the Debian Med Team during 2022 and the one who've been bugging this mailing list for the past few months.This is my final report for the GSoC project "Quality Assurance and Continuous Integration for Applications in Life Sciences and Medicine". This is an overview of the work done during my GSoC period with the team. ** About the project The Debian Med project has packaged several applications in life sciences and medicine. Continuous integration for these packages is essential to ensure reproducible results and that all components work together. These, tests often uncover bugs in the code and the packaging process that can cause failures on end-user machines. The aim of my project was to write autopkgtests for Debian Med packages, fix existing tests, any pipeline failures and fix the bugs uncovered by these tests. ** Statistics: Autopkgtests added: 30 Updates : 7 Bugs fixed: 5 Autopkgtests added: *python-datacache *parallel-fastq-dump *nifticlib *gifticlib *dicomnifti *openslide *minc-tools *dcm2niix *atropos *python-bioblend *python-cobra *intake *bmtk *nifti2dicom *biomaj3-cli *gdcm *megadepth *rockhopper *emmax *zalign *plastimatch *delly *dcmtk *nipype *emperor *python-wdlparse *libbigwig *libncl *gatb-core *tvc Package Updates: *q2-dada2 *q2-feature-classifier *q2-fragment-insertion *q2-metadata *q2-phylogeny *delly *q2-sample-classifier RC Bugs fixed *dcm2niix (Closes: #1012336) *dicomnifti (Closes: #1013364) *gdcm (Closes: #1016450) *mothur (Closes: #1014104) *megadepth (Closes: #1016454) I became a Debian Maintainer right before the start of my gsoc journey and I'm thankful to my mentors for giving me access to upload some of my work on my own. Also during gsoc I got the chance to use some of the Debain Project's Infra like I got access to a s390 porterbox for fixing a bug in one of the packages I've worked on I would like to thank my mentors, Andreas Tille and Nilesh Patra for their constant support and encouragement. I had a wonderful experience working with these amazing DDs. They were very quick to respond to my queries, sponsoring uploads and were very supportive. Also I would like to thank other Debian-Med members on this mailing list and the matrix room who guided me during my GSoC period. You all were super supportive and provided much needed feedback for my work. I plan to stick around and continue my contributions to Debian Med in the near feature. A snippet containing the links of all packages I've worked can be found here[1] Finally thanking the Debian Project for giving me this opportunity.I had a fun and productive summer with Debian 😃 [1] - https://salsa.debian.org/-/snippets/609 Thanks -- Mohammed Bilal 2D65 BC1E B966 5A6E 97F9 730A B3F5 9452 8521 9E1F OpenPGP_signature Description: OpenPGP digital signature
Re: [GSoC 2022 Final Report] Quality assurance for biological and medical applications inside Debian
Hi Bilal, thanks a lot for all your work! I would be very happy if you would stay in the team and contribute as long as your time permits. Kind regards Andreas. Am Wed, Sep 14, 2022 at 08:31:23PM +0530 schrieb Mohd Bilal: > Hello team \o/ , > > I'm Mohammed Bilal and I've been the GSoC intern working with the Debian Med > Team during 2022 and the one who've been bugging this mailing list for the > past few months.This is my final report for the GSoC project "Quality > Assurance and Continuous Integration for Applications in Life Sciences and > Medicine". This is an overview of the work done during my GSoC period with > the team. > > ** About the project > > The Debian Med project has packaged several applications in life sciences > and medicine. Continuous integration for these packages is essential to > ensure reproducible results and that all components work together. These, > tests often uncover bugs in the code and the packaging process that can > cause failures on end-user machines. The aim of my project was to write > autopkgtests for Debian Med packages, fix existing tests, any pipeline > failures and fix the bugs uncovered by these tests. > > ** Statistics: > > Autopkgtests added: 30 > Updates : 7 > Bugs fixed: 5 > > > Autopkgtests added: > > *python-datacache > *parallel-fastq-dump > *nifticlib > *gifticlib > *dicomnifti > *openslide > *minc-tools > *dcm2niix > *atropos > *python-bioblend > *python-cobra > *intake > *bmtk > *nifti2dicom > *biomaj3-cli > *gdcm > *megadepth > *rockhopper > *emmax > *zalign > *plastimatch > *delly > *dcmtk > *nipype > *emperor > *python-wdlparse > *libbigwig > *libncl > *gatb-core > *tvc > > > Package Updates: > > *q2-dada2 > *q2-feature-classifier > *q2-fragment-insertion > *q2-metadata > *q2-phylogeny > *delly > *q2-sample-classifier > > > RC Bugs fixed > > *dcm2niix (Closes: #1012336) > *dicomnifti (Closes: #1013364) > *gdcm (Closes: #1016450) > *mothur (Closes: #1014104) > *megadepth (Closes: #1016454) > > > I became a Debian Maintainer right before the start of my gsoc journey and > I'm thankful to my mentors for giving me access to upload some of my work on > my own. Also during gsoc I got the chance to use some of the Debain > Project's Infra like I got access to a s390 porterbox for fixing a bug in > one of the packages I've worked on > > I would like to thank my mentors, Andreas Tille and Nilesh Patra for their > constant support and encouragement. I had a wonderful experience working > with these amazing DDs. They were very quick to respond to my queries, > sponsoring uploads and were very supportive. Also I would like to thank > other Debian-Med members on this mailing list and the matrix room who guided > me during my GSoC period. You all were super supportive and provided much > needed feedback for my work. I plan to stick around and continue my > contributions to Debian Med in the near feature. > > A snippet containing the links of all packages I've worked can be found > here[1] > > Finally thanking the Debian Project for giving me this opportunity.I had a > fun and productive summer with Debian 😃 > > > [1] - https://salsa.debian.org/-/snippets/609 > > Thanks > -- > Mohammed Bilal > 2D65 BC1E B966 5A6E 97F9 730A B3F5 9452 8521 9E1F > -- http://fam-tille.de
[Proposed MBF: wxwidgets3.2 transition] Med/science-team packages
Hi, There are some packages listed under our team and science team namespace as listed below (I snipped the rest of the dd_list) Please consider to port them to new wxwidgets if you happen to work on these packages in near future. And otherwise, help welcome in porting these, as we need to fix these packages sooner or later. Thanks! Nilesh - Forwarded message from Scott Talbert - From: Scott Talbert To: debian-de...@lists.debian.org Date: Mon, 12 Sep 2022 22:32:23 -0400 (EDT) Subject: Proposed MBF: wxwidgets3.2 transition User-Agent: Alpine 2.22 (DEB 394 2020-01-19) Hi, wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). The Release Team has set up a transition tracker for us to track progress [1]. I'm planning to file bugs for all packages that haven't yet migrated. dd-list is attached. Please let me know if you have any questions or comments. Thanks, Scott [1] https://release.debian.org/transitions/html/wxwidgets-3.2.html Debian Med Packaging Team ctsim gentle lamarc mriconvert treeviewx Debian Science Team gnuplot plplot wxastrocapture Debichem Team openbabel qutemol - End forwarded message - signature.asc Description: PGP signature
Re: RM pinfish?
On Wed, Sep 14, 2022 at 03:53:42PM +0200, Andreas Tille wrote: > Am Wed, Sep 14, 2022 at 06:23:58PM +0530 schrieb Nilesh Patra: > > But I also strongly belive in removing software that no-one is using. I > > agree > > that our packages usually have low popcon values, but if some package is > > _never_ > > gonna be used, > > How can we know? We can't, which is exactly the reason why I started this thread in the first place :) > I simply trusted Steffens insight he has put into the > spreadsheet[2] and have put Steffen in CC to confirm. In case he agrees > that pinfish is not needed any more we should mention this in this sheet > and remove the package accordingly. I agree. BTW I wonder if we should get rid of the spreadsheet and document it somewhere else so it is accessible a bit more widely? I have a feeling that the said spreadsheet is ``somewhat'' hidden from rest of the debian and it'd be cool to have everyone take a look at it and/or propose to make modifications. > > and is abandoned upstream, I think it is an absolute waste of > > my time to keep maintaining it. Frankly, I'd do something else. > > This is not the first package abandoned upstream - we have even packages > where you can find the source only in webarchive (and for sure > debian.org). I am aware of it, because I have worked on many of such packages, and I still think that even these packages _should_ be removed if _no one_ is using them. I find it tasteless to burn so much of developer time on things that are no longer relevant. OTOH, there are packages that need updates with new upstream releases and keep waiting which in my opinion is a much more impactful than fixing RC bugs in packages that have sources purged upstream (: We already have so many packages so we probably need same/less number of packages (not more) > > This is a go package and you have told me several times that you aren't the > > best > > person to work on golang-related tasks, most recently on -hpc list[3] > > That's correct. But we have packages in haskell (phybin) and D > where I'm even worse. But that does not mean that you go on adding yourself to _even more_ of such packages/tasks where you are not fully comfortable. I believe you'd like to keep such a list of unexplored territories to a minimum, as it's wise to do so. > > So if going forward a bug is reported against pinfish, you'd probably have > > to spend > > more time on it that you'd like. > > I'd prefer to wait with removal until we have the situation of such a > bug that might cause real trouble. Again, I do not see a lot of point in keeping something 'limping' to the point when it gets completely un-recoverable. The situation with pinfish mayn't be too bad, but I don't see a point in waiting for an RC bug to be filed against it some day or the other and _then_ asking for it to be kicked. What is even worse is that the RC bug is somehow easy to fix, someone fixes it and uploads and we end up maintaining it for even longer, when in principle it might simply not be worth the effort at all. > > So I don't think just exchanging names is a very optimal thing to do here. > > > > If I don't hear from Steffen, or no-one raises an objection in the next > > three weeks, I'll > > proceed to file an RM bug. > > Steffen??? @Steffen, if you are reading this, a quick reply would be appreciated, really! > > > > [1]: https://github.com/nanoporetech/pinfish > > > [2] > > > https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 > > [3]: https://lists.debian.org/debian-hpc/2022/08/msg00020.html -- Best, Nilesh signature.asc Description: PGP signature
Re: [Proposed MBF: wxwidgets3.2 transition] Med/science-team packages
On Wednesday, September 14, 2022 3:21:57 P.M. CDT Nilesh Patra wrote: > Hi, > > There are some packages listed under our team and science team namespace > as listed below (I snipped the rest of the dd_list) > Please consider to port them to new wxwidgets if you happen to > work on these packages in near future. Thanks! I glossed over the original message because I forgot to check for team-maintained things. I will take care of MRIConvert. -Steve signature.asc Description: This is a digitally signed message part.
