[RFS] python-depinfo
Hi, I have fixed python-depinfo which reports failed tests in debci[1] to pass successfully. It builds fine in a clean chroot with passing autopkgtests. I have also updated to the next upstream release. My changes have been pushed my changes here[2]. Needs review and sponsorship. [1]:https://ci.debian.net/packages/p/python-depinfo/ [2]:https://salsa.debian.org/gi-boi-guest/python-depinfo Thanks and regards Nilesh
[RFS] predictnls
Hi, I have fixed predictnls which reports failed tests in debci[1]. It builds fine in a clean chroot with passing autopkgtests. I have pushed my changes to the team repo, here[2]. Needs review and sponsorship. [1]:https://ci.debian.net/packages/p/predictnls/ [2]:https://salsa.debian.org/med-team/predictnls Thanks and regards Nilesh
[RFS] art-nextgen-simulation-tools
Hi, I have fixed art-nextgen-simulation-tools failed tests in debci. It builds fine in a clean chroot, with passing autopkgtests. I have pushed my changes to team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/art-nextgen-simulation-tools Thanks and regards Nilesh
Re: [RFS] art-nextgen-simulation-tools
On Sun, 23 Feb 2020, 13:55 Andreas Tille, wrote: > Hi Nilesh, > > On Sun, Feb 23, 2020 at 11:52:37AM +0530, Nilesh Patra wrote: > > I have fixed art-nextgen-simulation-tools failed tests in debci. > > It builds fine in a clean chroot, with passing autopkgtests. > > I have pushed my changes to team repo here[1]. > > Needs review and sponsorship. > > > > [1]: https://salsa.debian.org/med-team/art-nextgen-simulation-tools > > Sponsored your changes - thanks a lot, Andreas. > Thanks! \o/
Re: Using janitor-bot? (Was: libzerg | Fix debci, update package (!1))
On Wed, 4 Mar 2020, 14:16 Andreas Tille, wrote: > Hi Nilesh, > > to unhide your question from random salsa merge request I'm > forwarding it to the list. > > On Tue, Mar 03, 2020 at 11:40:59AM +, Nilesh Patra wrote: > > Nilesh Patra commented on a discussion: > https://salsa.debian.org/med-team/libzerg/-/merge_requests/1#note_145441 > > > > Righty. > > Just btw, will it be a good idea to give @janitor-bot-guest > src:[debian-janitor](https://salsa.debian.org/jelmer/debian-janitor) push > access for doing the routine-update thingy on exisitng repositories? > > While I think its a good idea to have some means to mass commit changes > to our repositories I'm not fully convinced that its helpful to enable > bots commiting to our git without any urgent need. I *personally* think > it makes more sense to make changes in a short time frame before an > upload is done. This brings potential issues to the attention of the > maintainer who is actual working on the package. > > > I think right now, ruby-team uses it. > > I have also seen team wide automatic changes in Debian Python Modules > team. But I'm not convinced that this will solve any urgent problem. > I get it. Routine update it is, then. Let's add in even more features to routine-update then, :) Regards, Nilesh
Re: Help with autopkgtest for package andi
Hi, On Sat, 7 Mar 2020, 18:38 Samyak Jain, wrote: > Heya, > > I went through the thread link on the mailing list. I went through the > thread[1] and found the link[2], which intends to upgrade the packages to > the latest upstream version and also lacks the autopkgtest. I would like to > help and asks some doubts regarding the same (newbie doubts :D ). > > I took the package "andi" and updated it to the newest upstream version > which is 0,13,0. I need help with the autopkgtest enabling (any guidance > will be helpful), how it works and done. > I'm not a DD, but if I may suggest: just check the manual,(andi-manual.pdf) in the package itself. It has really nice explanation of using Andi. So based on that you can: * Add a simple test of your own * Plus, the package itself as well provides its own tests in the test/ directory, and the manual lists the way to run those - IMO, they can be enabled. Thanks and regards Nilesh >
[Discussion Needed] Upstream version for pyode?
Hi, pyode is a package of Neuro-debian team, with a RC bug filed; since we are in the process of taking in a few packages(mostly with RC bugs) from neuro-debian into debian med+science, I wanted a clarification on this package. The package seems to be dead upstream with latest version being '1.2'; and as pointed out by Sandro on its RC bug[1], it has a fork available here[2]. However, the new fork doesn't seem to have any release yet. I have opened the issue[3] for the same, but not really sure about the time it would take for an agreement. So I had this question - what should be the new release version for pyode in this case? Also, another option can be to file RM request on the package; it has only one reverse(build) dependency, pyepl(whch has a RC bug against it, as well): [~]$ reverse-depends python-pyode Reverse-Depends === * python-pyepl Packages without architectures listed are reverse-dependencies in: amd64, arm64, armel, armhf, i386, mipsel, ppc64el, s390x [~]$ reverse-depends -b python-pyode Reverse-Build-Depends = * pyepl And pyepl has no reverse-dependencies. So we can probably file RM requests for both: pyode and pyepl? I would like knowing what should be the best thing to do here. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=937495#18 [2]: https://github.com/filipeabperes/Py3ODE [3]: https://github.com/filipeabperes/Py3ODE/issues/6 Thanks and regards, Nilesh
Re: Autopkgtest fails (Was: Kalign3)
Hi, On Fri, 20 Mar 2020, 01:20 Pranav Ballaney, wrote: > Hi Andreas, > I've added some more tests to kalign, but there's a slight problem. > As specified in the README file, kalign supports two ways of taking input: > one is through stdin and the other through the -i flag (or even without it). > For some reason, all tests using the -i flag fail inside my testing > chroot, but work perfectly outside the chroot. > However, inside the chroot and outside, stdin input works as expected. > > In the run-unit-test file, all the tests take input from stdin, and all > the tests pass. > It's the same as what happened with loki earlier, I guess. Please > uncomment the lines with -i and try running them on your system. Maybe if > they work on yours and others', it's just an issue with my chroot. > > Here are the errors generated when commands using -i are run inside the > chroot: > LOG : kalign -i BB11001.tfa -f msf -o out.msf > ERROR : Input alignment format could not be detected. (rwalign.c line 314) > ERROR : Function "detect_alignment_format(b, &type)" failed. (rwalign.c > line 187) > ERROR : Function "tmp_msa = read_input(param->infile[i],tmp_msa)" failed. > (run_kalign.c line 383) > ERROR : Function "run_kalign(param)" failed. (run_kalign.c line 353) > Looking into it. Will push the fixes soon.
Re: Autopkgtest fails (Was: Kalign3)
On Fri, 20 Mar 2020, 01:20 Pranav Ballaney, wrote: > Hi Andreas, > I've added some more tests to kalign, but there's a slight problem. > As specified in the README file, kalign supports two ways of taking input: > one is through stdin and the other through the -i flag (or even without it). > For some reason, all tests using the -i flag fail inside my testing > chroot, but work perfectly outside the chroot. > However, inside the chroot and outside, stdin input works as expected. > > In the run-unit-test file, all the tests take input from stdin, and all > the tests pass. > It's the same as what happened with loki earlier, I guess. Please > uncomment the lines with -i and try running them on your system. Maybe if > they work on yours and others', it's just an issue with my chroot. > > Here are the errors generated when commands using -i are run inside the > chroot: > LOG : kalign -i BB11001.tfa -f msf -o out.msf > ERROR : Input alignment format could not be detected. (rwalign.c line 314) > ERROR : Function "detect_alignment_format(b, &type)" failed. (rwalign.c > line 187) > ERROR : Function "tmp_msa = read_input(param->infile[i],tmp_msa)" failed. > (run_kalign.c line 383) > ERROR : Function "run_kalign(param)" failed. (run_kalign.c line 353) > Just checked. My best guess here is that -i invokes interaction, which won't work in a chroot. The best way to pass input inside a chroot is via either STDIN, or redirecting input with pipes. Also Just a suggestion: Autopkgtests look fine to me, but I would suggest to also add other .tfa and .msf files in ./dev/data directory and run tests on them. Regards, Nilesh >
Re: Autopkgtest fails (Was: Kalign3)
On Sat, 21 Mar 2020, 01:16 Pranav Ballaney, wrote: > On Fri, Mar 20, 2020 at 1:38 AM Nilesh Patra wrote: > >> Just checked. My best guess here is that -i invokes interaction, which >> won't work in a chroot. >> The best way to pass input inside a chroot is via either STDIN, or >> redirecting input with pipes. >> > >> Also >> Just a suggestion: Autopkgtests look fine to me, but I would suggest to >> also add other .tfa and .msf files in ./dev/data directory and run tests on >> them. >> > Thank you. I've added the remaining tests as well. Please review and > sponsor. > Hi, I'm not a DD (yet), have CC'ed to Andreas so it gets uploaded. Thanks! >
Re: COVID-19 Biohackathon April 5-11 2020
Hi, On Sun, 22 Mar 2020, 23:50 Andreas Tille, wrote: > On Tue, Mar 17, 2020 at 08:25:02AM +0100, Andreas Tille wrote: > > We now have > > > >https://blends.debian.org/med/tasks/covid-19 > > Is there any volunteer who can add more of our packages here? Steffen > was talking about lots of packages he had in mind to get bcbio ready. > Steffen, can you please add links at least as comments into the covid-19 > task. I'd volunteer to add rough packaging skeletons at least to make > them showing up at our tasks page which is currently pretty weak. > > Please always remember: I'm **NOT** a medical expert - I'm weak in > deciding what is helpful and what is not. We need your support - just > an e-mail here would be helpful! > I'm not sure if what I'm suggesting here is useful - but can we consider packaging bioconda, or its dependencies? I'm not from medical background, but just wanted to give in a suggestion. Apologies is that does not sound good. > > > > Great, how to do this? Do we spam BTS with user tags, or is there a > way to > > > > get all bugs for a list of packages? > > > > > > We just have it after next cron job at > > > > > >https://blends.debian.org/med/bugs/ > > > > No idea why the bugs page does not yet exist but I'll check later. > > That's fixed. The whole bugs pages generation was broken and is updated > now again. > > > Its now time to feed actual packages into > > > > https://salsa.debian.org/blends-team/med/-/blob/master/tasks/covid-19 > > Please, pretty please give hints here! > > > We can think about how to speed up package propagation once a package is > > on that page and is really not processed. > > I had a private mail exchange with a member of the ftpteam. He has > confirmed my suspicion that we can rely on them if its needed but > general blaming that new queue processing is an issue is not helpful at > all and I consider it a very good idea if we don't do this. > I was just wondering if we can, may be we can upload packages to fasttrack.debian.net as well? That would speed up the process. Again, apologies if that doesn't sound good enough. Regards, Nilesh
Re: COVID-19 Biohackathon April 5-11 2020
Hi, Someone just suggested this one[1] on the JavaScript team mailing list. Looks interesting, can we add this in for the Hackathon? :) This might require version bumps, but there's probably no harm in adding it for now? [1]: https://github.com/ahmadawais/corona-cli Regards, Nilesh
Re: Droping pyqi which seemed to be needed for qiime1 only (Was: Bug#954500: pyqi: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2)
Hi
On Mon, 30 Mar 2020, 17:12 Andreas Tille, wrote:
> Hi,
>
> I fixed the actual issue in Git but got a new error:
>
>
> ...
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:217: cd
> /build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build; python3.8 -m unittest
> discover -v
> /build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build/pyqi/core/interfaces/html/__init__.py:359:
> SyntaxWarning: "is not" with a literal. Did you mean "!="?
> if full_name in postvars and i.Type is not 'upload_file':
> pyqi.core.interfaces.html (unittest.loader._FailedTest) ... ERROR
>
> ==
> ERROR: pyqi.core.interfaces.html (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: pyqi.core.interfaces.html
> Traceback (most recent call last):
> File "/usr/lib/python3.8/unittest/loader.py", line 470, in
> _find_test_path
> package = self._get_module_from_name(name)
> File "/usr/lib/python3.8/unittest/loader.py", line 377, in
> _get_module_from_name
> __import__(name)
> File
> "/build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build/pyqi/core/interfaces/html/__init__.py",
> line 25, in
> from cgi import parse_header, parse_multipart, parse_qs, FieldStorage
> ImportError: cannot import name 'parse_qs' from 'cgi'
> (/usr/lib/python3.8/cgi.py)
>
Just checked, none of the cgi imports (parse_header, parse_qs et al) are
being used anywhere in the file.
Imo, you can just delete this import line.
On doing that, build passed for me.
>
> --
> Ran 1 test in 0.000s
>
> FAILED (errors=1)
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1:
> cd /build/pyqi-0.3.2+dfsg/.pybuild/cpython3_3.8/build; python3.8 -m
> unittest discover -v
> dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned
> exit code 13
> ...
>
>
> Since pyqi has no rdepends any more and IMHO was only packaged
> for qiime version 1.x I'd suggest to remove this package.
>
> Am I missing something?
>
Regards, Nilesh.
Re: [covid-19] A relevant software mentioned during today's BH meeting (consider packaging)
Hiya, On Sun, 5 Apr 2020 at 23:05, Liubov Chuprikova wrote: > Hi everyone, > > I am going to share lists of packages/workflows that were mentioned during > the "Kickoff" opening video conference today. Those are possible candidates > for us to work on or to continue working on (if already in Debian): > >- R package for the data collated by Johns Hopkins: >https://github.com/rOpenStats/COVID19 >- CHIME: COVID-19 Hospital Impact Model for Epidemics: >https://penn-chime.phl.io >- COVID-19 Scenario simulator: >https://github.com/neherlab/covid19_scenarios >- The ARTIC Network: https://github.com/artic-network. I've seen, >Porechop and Nanopolish are already in Debian. Maybe, Rampart is another >possible candidate to package. >- R wrapper around the COVID Tracking Project API: >https://github.com/aedobbyn/covid19us > > Pipelines/Workflows: > >- https://artic.network/ncov-2019 -- contains some bioinformatics >protocols and datasets >- >https://github.com/BU-ISCIII/SARS-Cov2_analysis/wiki/Analysis-pipelines >- Galaxy workflows: https://covid19.galaxyproject.org/genomics/ -- >really nice and well structured, in my opinion >- Nexstrain workflows: https://github.com/nextstrain/ncov >- https://github.com/nf-core/viralrecon >- https://github.com/connor-lab/ncov2019-artic-nf > > I also tried to filter out COVID19-related data resources. But, if someone > needs it, there are, for example, wiki pages of `Bio statistics` and `Covid > 19 Phylogeny` Topics ( > https://github.com/virtual-biohackathons/covid-19-bh20/wiki) with a lot > of links to datasets. > > I also mined a bit for some other viral genomics/epidemiology related > software, that is not in Debian. These are not directly related to COVID19, > but, I think, they deserve our attention: > >- https://github.com/HaploConduct/HaploConduct -- Haplotype-aware >genome assembly toolkit. HaploConduct consists of two methods: SAVAGE >(Strain Aware VirAl GEnome assembly) and POLYTE (POLYploid genome fitTEr) >- https://github.com/chanzuckerberg/idseq-dag -- Pipeline engine for >IDseq (Infectious Disease Sequencing Platform) >- https://github.com/chanzuckerberg/idseq-bench -- IDseq infectious >disease benchmarking tools >- https://github.com/rcs333/VAPiD -- Viral Annotation and >Identification Pipeline >- https://github.com/DennisSchmitz/Jovian -- Metagenomics/viromics >pipeline that focuses on automation, user-friendliness and a clear audit >trail. >- https://github.com/viromelab/tracespipe -- Reconstruction and >analysis of viral and human-host genomes at multi-organ level >- https://github.com/babinyurii/recan -- genetic distance plotting for >recombination events analysis >- https://wupathlabs.wustl.edu/virusseeker/ -- a computational >pipeline for virus discovery and virome composition analysis >- https://github.com/kentnf/VirusDetect -- an automated pipeline for >efficient virus discovery using deep sequencing of small RNAs (Licence - ?) >- https://github.com/keylabivdc/VIP -- Virus Identification Pipeline >(Licence - ?) >- https://github.com/ICBI/viGEN/ -- a bioinformatics pipeline for the >exploration of viral RNA in human NGS data (Licence - ?) > > Thanks for the good work. To make this more organized and to avoid double work, I have created a wiki page here[1]. I would request all to add their name against the package when they start working on it, and tick the checkbox once done. [1]: https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work Best, Nilesh
[RFC] Update libssw? (Needed by parasail)
Hiya, The upstream of libssw has version - 1.24 [1] mentioned in their code, and it seems the haven't made the releases properly. (This is not the case with the same file in Debian though) Andreas Tille has also opened an issue about the same for making suitable releases here [2]. I'm right now trying to package parasail, which has a dependency on libssw (After removing the corresponding code copy). Using libssw available in debian's archive, I end up with this error [3]. It appears that this is likely due to update in the upstream code. Hence, I would request switching libssw to git mode temporarily so as to make an update, and upload the same. Please excuse my brevity if in case this is my personal mistake, and has got nothing to do with libssw's update. [1]: https://github.com/mengyao/Complete-Striped-Smith-Waterman-Library/blob/master/src/ssw.c#L59 [2]: https://github.com/mengyao/Complete-Striped-Smith-Waterman-Library/issues/72 [3]: https://paste.debian.net/1139433/ Thanks and regards Nilesh
Re: [RFC] Update libssw? (Needed by parasail)
Hi Fabian and Micheal On Fri, 10 Apr 2020, 12:35 Fabian Klötzl, wrote: > Hi, > > The error in parasail complains that some structure doesn't have a > `saturated` property. However, the libssw repository you linked to > doesn't contain that word either. Thus, the version you deleted has some > crucial changes, I guess. There are a few ways you could go. > > 1) Judging from the name of the erroneous file `tests/test_openmp.c`, it > is "just a test". Can you build parasail without? > > 2) Build with the shipped copy of libssw. > > 3) Port the changes to the true libssw without breaking many other > programs. > > If you still wanted to update libssw to 1.24, I would recommend the > following steps: Clone the git repo. Write all changes to a file (git > diff v1.1..master > huge.patch). Apply the patch using standard debian > procedures. > Thanks a lot for the suggestions. Duly noted. I think it would make sense to talk to upstream about it, and ask them the real source of the file, since it appears that the copy used is modified by libssw's author and is forked from somewhere. Maybe mailing them makes sense. In any case, thanks a lot to help, :-) Regards, Nilesh
Re: [RFS] Bug fixed in uc-echo
On Fri, 17 Apr 2020, 22:44 Pierre Gruet, wrote: > Dear all, > > I have prepared an upload for the package uc-echo, of which autopkgtest was > failing on arm64 due to a (by default unsigned) char type being used to > store negative integer values. > I will forward this fix to upstream. > > The package is in its Salsa repository [1]. > Thank you so much for fixing this! :D (This was lying on my desk for quite sometime by now) Hoping this gets uploaded soon. > > > Thanks in advance for the review when time permits, > > Best regards, > Pierre > > [1] https://salsa.debian.org/med-team/uc-echo > >
Re: Welcoming GSoC students
Hi On Tue, 5 May 2020, 10:34 Andreas Tille, wrote: > Hi, > > I'm hereby welcoming > > Pranav Ballaney > for the topic > Quality Assurance and Continuous Integration for Applications in Life > Sciences and Medicine. > > and > > Nilesh Patra > for the topic > Packaging and Quality Assurance of COVID-19 Relevant Applications. > > as Google Summer of Code students. Both should be now well known in our > team due to their previous contributions. So welcoming you two in our > team is probably not the right word since you are considered team > members even now. That's why I just say: I'm very happy that I've got > official confirmation. Please keep on the great work you have started! Yes, that's the plan - doing good work together. It was only possible because of your cooperation, really thanks a lot for your support :-) And congrats to Pranav for making it! Regards, Nilesh
Re: RFS: cgview
On Sun, 10 May 2020 at 03:17, Pranav Ballaney wrote: > Hi Andreas, > > On Sun, May 10, 2020 at 1:21 AM Andreas Tille wrote: > >> Hi Pranav, >> >> On Sat, May 09, 2020 at 09:54:56PM +0530, Pranav Ballaney wrote: >> > I've added autopkgtests to cgview. Since the output is an image, I >> haven't >> > compared it to a reference - is that alright? >> >> Its definitely better than nothing. >> >> > If not, how do we usually test packages like this? I tried running a >> diff >> > but that reported the files to be different, even though they were >> visually >> > the same. >> >> I somehow thought there are some image comparison packages inside Debian. >> A short search has lead me to >> >> >> https://softwarerecs.stackexchange.com/questions/9774/command-line-tool-to-check-whether-two-images-are-exactly-the-same-graphically >> >> which recommends >> >>identify -quiet -format "%#" images... >> >> > Please take a look and let me know if any additional steps are required. >> > https://salsa.debian.org/med-team/cgview >> >> Please note that I used xz compression on the xml data to save some >> space also on developers machines. I've also called routine-update -f >> to update the packaging. I do not think that the image comparison is >> mandatory here - its way better to test at all than to make it perfect. >> But if you want to give identify a try that would be fine. >> > > Okay then let's leave the test here. Thanks for the compression, I'll keep > that in mind for future tests. > > However, we have a remaining problem in my pbuilder chroot: >> >> autopkgtest [19:32:42]: test run-unit-test: [--- >> run-detectors: unable to find an interpreter for /usr/bin/cgview >> autopkgtest [19:32:43]: test run-unit-test: ---] >> autopkgtest [19:32:43]: test run-unit-test: - - - - - - - - - - results >> - - - - - - - - - - >> run-unit-testFAIL non-zero exit status 2 >> >> > This is weird - all tests pass in my chroot. Could it be like the issue we > had with loki a few months ago? > It worked perfectly on Liubov's machine too. > > @Nilesh, could you please take a look here? > > >> It somehow sounds similar to this thread: >> >> https://lists.debian.org/debian-java/2016/04/msg00098.html >> >> I'd recommend to check with debian-j...@lists.debian.org . In >> the case of artfastqgenerator I've circumvented the problem >> a wrapper script. > > > Let's let Nilesh try it once, and if the problem persists, we'll take it > up with the Java team. > It doesn't work for me. However the error is different from Andreas's. Pasting them below: (Reading database ... 17925 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [03:50:57]: test run-unit-test: [--- /tmp/autopkgtest.VDRUQo/build.fD2/real-tree/debian/tests/run-unit-test: line 22: /usr/bin/cgview: cannot execute binary file: Exec format error autopkgtest [03:50:58]: test run-unit-test: ---] autopkgtest [03:50:58]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-testFAIL non-zero exit status 126 autopkgtest [03:50:58]: summary run-unit-testFAIL non-zero exit status 126 Liubov, could you try this once and let us know the output? Kind Regards, Nilesh
[RFS] freecontact
Hi, I have added autopkgtests for free contact, and build + tests pass in a clean chroot. I have pushed my changes to the team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/freecontact Kind regards, Nilesh
[RFS] codonw
Hi, I have added autopkgtests for codonw. It builds in a clean chroot with passing tests. My changes are pushed here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/codonw Thanks and regards Nilesh
Re: Infrastructure for next Covid-19 Sprint
On Sun, 24 May 2020, 00:46 Steffen Möller, wrote: > Heya, > > I understood that it was a bit difficult with IRC to orchestrate the > participants on the last Sprint. I am not so much worried about the old > timers (not sure they need a Sprint in the first place) but the > newcomers certainly benefit from something less clumsy and an > integration of sound and vision (https://xkcd.com/1782/). And if we > indeed plan to have some fancier presentation by some upstream devs > then, well, in my very humble opinion IRC is just a no-go. > > There is https://discord.com/open-source out there which I started to > like. There are some BOINC and Gridcoin channels via which I got in > contact. Any better ideas on your sides? I'm not sure how feasible my suggestion is, but there's signal[1] as well which can help. Also, for screen-share and presentation, jitsi can be a good option as well. That said, discord is a pretty good alternative - the above options is just to add suggestions to the list. [1]: https://signal.org/en/ Thanks and regards Nilesh
[RFS] opensurgsim
Hi, opensurgsim currently FTBFS as reported in the RC bug: 960496 I have fixed this, and this now builds in a clean chroot. It however reports a lintian warning, which it reported possibly right from it's first upload: W: libopensurgsim: package-name-doesnt-match-sonames libIdentityPoseDevice0.7.0 libKeyboardDevice0.7.0 libMouseDevice0.7.0 libMultiAxisDevice0.7.0 libReplayPoseDevice0.7.0 libSurgSimBlocks0.7.0 libSurgSimCollision0.7.0 libSurgSimDataStructures0.7.0 libSurgSimDeviceFilters0.7.0 libSurgSimDevices0.7.0 libSurgSimFramework0.7.0 libSurgSimGraphics0.7.0 libSurgSimInput0.7.0 libSurgSimMath0.7.0 libSurgSimParticles0.7.0 libSurgSimPhysics0.7.0 Not very sure as to how to go about this, since there are multiple .so files. Just maybe, this can be ignored. My changes have been pushed to the team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/opensurgsim Thanks and regards Nilesh
[RFS] abacas
Hi, I have added autopkgtests for abacas. This builds in a clean chroot with passing tests. My changes have been pushed to the team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/abacas Thanks and regards Nilesh
Re: [RFS] abacas
Hi, On Thu, 28 May 2020, 20:08 Andreas Tille, wrote: > Hi Nilesh, > > On Thu, May 28, 2020 at 07:39:02PM +0530, Nilesh Patra wrote: > > I have added autopkgtests for abacas. This builds in a clean chroot with > > passing tests. > > Thank you fro your prompt work on this after I pointed to the list. > > > My changes have been pushed to the team repo here[1]. > > Needs review and sponsorship. > > Looks good so far but the abacas binary package is just 24kB and the > additional > data would blow it up to 2MB. This is a bit to much. Would you mind > moving the > files to say abacas-examples package or so? > Done. Please check and upload. Regards, Nilesh
[RFS] biomaj3-core
Hi, I've added and fixed autopkgtests in biomaj3-core. This also closes the RC bug against it: #961902. This builds fine in a clean chroot with passing tests. My changes have been pushed here [1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/biomaj3-core Thanks and regards Nilesh
[RFS] libgff
Hi, I have added autopkgtests for libgff: it builds in a clean chroot with passing tests. My changes have been pushed to team-repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/libgff Regards, Nilesh
[RFS] poretools
Hi, I've added autopkgtests for poretools. In the process I realised that a circular import was causing the package to be unusable. I've fixed this, and also fixed output for "poretools times" command which was not giving the desired result. It builds in a clean chroot with passing tests and I've pushed my changes to the team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/poretools Regards, Nilesh
[RFS] solvate
Hi, I've added autopkgtests for solvate. It builds in a clean chroot with passing tests. My changes have been pushed to the team-repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/solvate Regards, Nilesh
Re: RFH: NanoSV - pkg_resources.DistributionNotFound: The 'configparser' distribution was not found and is required by NanoSV
Hi On Mon, 8 Jun 2020, 20:11 Steffen Möller, wrote: > > On 08.06.20 14:25, Andreas Tille wrote: > > On Sun, Jun 07, 2020 at 05:49:37PM +0200, Steffen Möller wrote: > >> $ NanoSV > >> Traceback (most recent call last): > >> File "/usr/bin/NanoSV", line 6, in > >> > >> raise DistributionNotFound(req, requirers) > >> pkg_resources.DistributionNotFound: The 'configparser' distribution was > >> not found and is required by NanoSV > >git pull > > > > :-) > > Thank you, Andreas. Have added an autogenerated man page as an > expression of me appreciating your fix. > Would you have a similarly splendid idea on why the tests don't work? > It seems like there are actually no tests to run on. I've enabled the tests anyway for now and this should run on any tests if added in the future. Please pull my changes and let me know if they look right to you. Kind Regards, Nilesh >
[RFS] mencal
Hi, I have added autopkgtests to mencal: builds in a clean chroot with passing tests. My changes have been pushed to the team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/mencal Regards, Nilesh
Re: pll-modules tests failing
Hi On Tue, 9 Jun 2020, 02:58 Pranav Ballaney, wrote: > Hi, > I've committed a few changes to 2to3.patch along with a test.patch file > that I used to try and debug this. > It reports the following errors while running test/runtest.py: > > obj/binary/binary-random: error while loading shared libraries: > libpll_binary.so.0: cannot open shared object file: No such file or > directory > obj/optimize/blopt-5states: error while loading shared libraries: > libpll_optimize.so.0: cannot open shared object file: No such file or > directory > obj/tree/parsimony-tree: error while loading shared libraries: > libpll_tree.so.0: cannot open shared object file: No such file or directory > > Any ideas about this? > If you are testing it in a chroot, install libpll-dev and libpll0 and this error should go away. *_As far as_* I had a look, it throws up an error: src/common.o file doesn't exist while building. Probably we need to tweak the Makefile to compile it before hand. Regards, Nilesh >
[RFS] seqtools
Hi, I have added autopkgtests to seqtools: builds in a clean chroot with passing tests. My changes have been pushed to the team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/seqtools Regards, Nilesh
[RFS] gatb-core
Hi, Currently gatb-core FTBFS and has RC bug: #960414 filed against it. I've fixed it and pushed[1]. Needs review and sponsorship. [1]:https://salsa.debian.org/med-team/gatb-core Regards, Nilesh
Re: [RFS] gatb-core
Hi, On Wed, 10 Jun 2020, 23:06 Steffen Möller, wrote: > Hi Nilesh, > > On 10.06.20 17:53, Nilesh Patra wrote: > > Hi, > > Currently gatb-core FTBFS and has RC bug: #960414 filed against it. > > I've fixed it and pushed[1]. > > Needs review and sponsorship. > > > > [1]:https://salsa.debian.org/med-team/gatb-core > > <https://salsa.debian.org/med-team/gatb-core> > > Typically Andreas is faster than me - since he just said he'd be busy, > you have not closed the bug in the changelog. Should I add that I suppose that's added? https://salsa.debian.org/med-team/gatb-core/-/blob/master/debian/changelog#L4 Am I missing something? and upload? > Please do, that would be great! :-) Regards, Nilesh >
[RFS] vsearch
Hi, I've added autopkgtests to vsearch and a few other small fixes. Builds with passing tests in a clean chroot. Needs review and sponsorship. https://salsa.debian.org/med-team/vsearch Regards, Nilesh
Re: [RFS] vsearch
Hi Andreas On Sat, 13 Jun 2020, 03:24 Andreas Tille, wrote: > Uploaded. Thanks for your work on this, Andreas. > Due to the sheer size of examples, I've made a separate binary (Since vsearch-data doesn't seem to be in NEW/debian archive I've taken a part of this) - vsearch-examples. And hence, this would go to NEW. You seem to have done a source-only-upload; could you do a binary upload here? That'd be great. Kind regards Nilesh
[RFS] readucks
Hi, I've packaged a NEW module: readucks - a Nanopore read de-multiplexer. It builds in a clean chroot with passing tests. I've pushed my changes to team-repo[1]. This needs review and sponsorship. [1]: https://salsa.debian.org/med-team/readucks Thanks and regards Nilesh
Re: [RFS] readucks
On Mon, 15 Jun 2020, 22:30 Andreas Tille, wrote: > Hi Nilesh, > > Uploaded to new and added to the new request for ftpmaster. Thanks a lot! :-) > >
[RFS] streamz
Hi, I've packaged a NEW module: streamz - Helps build pipelines to manage continuous streams of data. It builds in a clean chroot with passing tests. I've pushed my changes to team-repo[1]. *NB: The license on the repo looks like an exact copy of BSD-3-clause license. However, it has some missing cosmetic changes (Missing numbering for example). It would be great if it could be confirmed that using BSD-3-clause license here is OK* This needs review and sponsorship. Thanks and regards Nilesh
[RFS] shovill
Hi, I've packaged a NEW module: shovill - Assemble bacterial isolate genomes from Illumina paired-end reads It builds in a clean chroot. I've not added autopkgtests at the moment since some of the dependencies are still in NEW, and it would be better suited (for me) to add these once the dependencies are accepted. I've pushed my changes to team-repo[1]. This needs review and sponsorship. [1]: https://salsa.debian.org/med-team/shovill Thanks and regards Nilesh
[RFS] yanosim
Hi, I've packaged a NEW module: shovill - Assemble bacterial isolate genomes from Illumina paired-end reads It builds in a clean chroot. There are no autopkgtests yet - since I'm not very sure of the exact data this needs. I've pushed my changes to team-repo[1]. This needs review and sponsorship. [1]: https://salsa.debian.org/med-team/yanosim Thanks and regards Nilesh
Re: [RFS] yanosim
On Tue, 16 Jun 2020 at 21:43, Nilesh Patra wrote: > Hi, > I've packaged a NEW module: shovill - Assemble bacterial isolate genomes > from Illumina paired-end reads > OOPS!!! It's yanosim - Read simulator nanopore DRS datasets Pardon me :P It builds in a clean chroot. There are no autopkgtests yet - since I'm not > very sure > of the exact data this needs. > I've pushed my changes to team-repo[1]. > This needs review and sponsorship. > > [1]: https://salsa.debian.org/med-team/yanosim > > Thanks and regards > Nilesh >
Re: Can someone else check and sponsor (Was: nanofilt ready for upload)
On Wed, 17 Jun 2020, 03:08 Shayan Doust, wrote: > Hello Andreas, > > > I've done some minor changes and was building the package. Unfortunately > > my computer crashed when ... or rather after(!) ... running the test. > I've > > seen > > > > [1] PASS > > > > on the screen and than my screen froze. No ssh login possible any more. > > Waiting for more than 10min. I switched power-off and reboot worked > > fine (so no harm done) but I'm tired now and want to go to bed. I do > > not think that its actually related to the test - since the > > > >echo "[1] PASS" > > That's very odd. I know that NanoFilt will either pass or fail when > executing the command, but I like checking and making sure the filesize > is greater than 0 bytes as a double defense of making sure the program > *actually* does work properly as I have nothing to diff against. > If I may suggest ... You can run the test on your machine manually once and you'll get output file(s). This is something you can diff against. Add those files to say "debian/tests/expected/" and install these files as examples and take diff with what you get when you run-unit-test. > Also this standard version changing is a bad practice for me, as I use > Buster for my main workstation, and it seems like cme loves changing the > standards version to a lower one (and I keep forgetting to set it back > to 4.5.0. > +1: I use stable as well. I have another debian-sid "schroot" made. For cme I always do this: $ schroot -c debian-sid $ cme fix dpkg $ exit Works out of the box. > Thanks for letting me know about not needing to add GPL text. I didn't > think twice of it because I used the full license text within another > package (mmseqs2?), at least that saves time now. :) > > > I'm to tired for today now. > > Good night and kind regards, > Shayan Doust > > On 16/06/2020 22:28, Andreas Tille wrote: > > Hi Shayan, > > > > On Tue, Jun 16, 2020 at 08:48:51PM +0100, Shayan Doust wrote: > >> > >> I believe nanofilt[1] is ready. Please check and, if green light given, > >> upload :) > > > > I've done some minor changes and was building the package. Unfortunately > > my computer crashed when ... or rather after(!) ... running the test. > I've > > seen > > > > [1] PASS > > > > on the screen and than my screen froze. No ssh login possible any more. > > Waiting for more than 10min. I switched power-off and reboot worked > > fine (so no harm done) but I'm tired now and want to go to bed. I do > > not think that its actually related to the test - since the > > > >echo "[1] PASS" > > > > is actually the end of the script and syslog also looks harmless. But > > I'm to tired for today now. > > > > Thanks for your preparation > > > > Andreas. > > > >> Kind regards, > >> Shayan Doust > >> > >> [1]: https://salsa.debian.org/med-team/nanofilt > > > > pub RSA 4096/19D02395 2019-09-04 Shayan Doust (Personal EMAIL) < > he...@shayandoust.me> > >> > > > > > > > > >
[RFS] yanagiba
Hi, I've packaged a new module - "yanagiba". I've ensured that this looks good, and usable. Pushed to team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/yanagiba Thanks and regards Nilesh
[Help needed] ont-fast5-api
Hi, I was working on packaging ont-fast5-api, and did a few workarounds (disabling tests needing sudo and copying data to .pybuild dir - weirdly enough it wasn't getting copied). The build time tests work fine, but the build fails with this weird error: dh_link -O--buildsystem=pybuild dh_strip_nondeterminism -O--buildsystem=pybuild dh_compress -O--buildsystem=pybuild dh_fixperms -O--buildsystem=pybuild dh_missing -O--buildsystem=pybuild dh_dwz -a -O--buildsystem=pybuild objcopy: Unable to recognise the format of the input file `debian/ont-fast5-api/usr/lib/debug/.dwz/x86_64-linux-gnu/ont-fast5-api.debug' dh_dwz: error: objcopy --compress-debug-sections debian/ont-fast5-api/usr/lib/debug/.dwz/x86_64-linux-gnu/ont-fast5-api.debug returned exit code 1 make: *** [debian/rules:9: binary] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2 Build finished at 2020-06-18T10:07:10Z I admit, I've no idea what this means - could someone please take a look? That'd be great. Here's the repo: https://salsa.debian.org/med-team/ont-fast5-api Thanks and regards Nilesh
[RFS] ngmlr
Hi, I've packaged a new module - "ngmlr". I've ensured that this looks good, and usable.Many thanks to Pranav for adding autopkgtests to this \o/ Pushed to team repo here[1].Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/ngmlr Thanks and regards Nilesh
Re: RFH pychopper - test in cowbuilder does not find tests
On Thu, 18 Jun 2020 at 18:44, Steffen Möller wrote:
> Hello,
>
> https://salsa.debian.org/med-team/pychopper
>
> It is a Python module with a small script to its side that is not named
> pychopper - a bit surprising. More surprising, cowbuilder gives me
>
> writing... pychopper.1{
> cmd_listmodulespychopperpychopper.phmm_datapychopper.primer_datapychopper.tests}
>
> done
> build succeeded.
>
> The manual pages are in _build/man.
>
> Build finished. The manual pages are in _build/man.
> make[2]: Leaving directory '/build/pychopper-2.4.0/docs'
> make[1]: Leaving directory '/build/pychopper-2.4.0'
>dh_auto_test -O--buildsystem=pybuild
> pybuild --test --test-pytest -i python{version} -p 3.8
> I: pybuild base:217: cd
> /build/pychopper-2.4.0/.pybuild/cpython3_3.8_pychopper/build; python3.8
> -m pytest
> =
>
> test session starts
>
> ==
> platform linux -- Python 3.8.3, pytest-4.6.11, py-1.8.1, pluggy-0.13.0
> rootdir: /build/pychopper-2.4.0, inifile: pytest.ini
> plugins: xonsh-0.9.18, doctestplus-0.7.0, xdist-1.32.0, cov-2.8.1,
> mock-1.10.4, openfiles-0.5.0, forked-1.1.3, arraydiff-0.3,
> hypothesis-5.16.0, timeout-1.3.3, remotedata-0.3.2
> collected 0 items
>
> =
>
> no tests ran in 0.02 seconds
>
> =
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=5:
> cd /build/pychopper-2.4.0/.pybuild/cpython3_3.8_pychopper/build;
> python3.8 -m pytest
> dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
> 3.8 returned exit code 13
>
Very weird and same for me (gbp buildpackage with sbuild).
And I've pushed a patch - this runs now.
$git pull :)
However - one of the tests fail, and I'm leaving this on you to debug.
Regards,
Nilesh
[RFS] paryfor
Hi, I've packaged a new module - "paryfor" - this is a dependency of mmmulti. I've added some workarounds - and I'm not very sure if they are fine (also added a lintian override) - but as far as I see it "works". Pushed to team repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/paryfor Regards, Nilesh
Re: [RFS] paryfor
The paryfor-examples package does not make sense IMHO. What we > really want to test is whether test.cpp will build on the user > machine. > > So you rather should move test.cpp to > /usr/share/doc/libparyfor-dev/examples > accompanied by a short Makefile or script that should reproduce the > paryfor-test and run it as test. > Done. I've removed the extra binary - not needed. Also notice CMakeLists.txt is just compiling the tests - and does nothing else. So simply utilized this to compile tests. Please have a look and let me know Also please sponsor if it looks good :P Regards, Nilesh
Re: [RFS] paryfor
Also I'm not sure if arch should be changed to 'any' here. Please check :-) On Fri, 19 Jun 2020, 14:08 Nilesh Patra, wrote: > > > The paryfor-examples package does not make sense IMHO. What we >> really want to test is whether test.cpp will build on the user >> machine. >> >> So you rather should move test.cpp to >> /usr/share/doc/libparyfor-dev/examples >> accompanied by a short Makefile or script that should reproduce the >> paryfor-test and run it as test. >> > > Done. I've removed the extra binary - not needed. > Also notice CMakeLists.txt is just compiling the tests - and does nothing > else. So simply utilized this to compile tests. > Please have a look and let me know > Also please sponsor if it looks good :P > > Regards, Nilesh > >
[RFS] ncls
Please review and sponsor :) https://salsa.debian.org/med-team/ncls Regards, Nilesh
Re: [RFS] ncls
On Fri, 19 Jun 2020, 20:19 Steffen Möller, wrote: > Ooops - this is already done. > Aw, I should have been careful !! Sorry for the noise :-( > > https://salsa.debian.org/med-team/python-ncls > > https://ftp-master.debian.org/new/python-ncls_0.0+git20200225.f9894b0+ds-1.html > > :o/ Sorry. > Can you help me with two things?: 1. remove my repo from salsa 2. Merge the ITP. That'd be very helpful. Regards, Nilesh
[RFS] pyrle
Hi, I've packaged pyrle - that's a new module. I've ensured that this looks good. The repo is here[1] Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/pyrle Thanks and regards Nilesh
[RFS] sorted-nearest
Hi, I've packaged sorted-nearest - that's a new module. I've ensured that this looks good. The repo is here[1] Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/sorted-nearest Thanks and regards Nilesh
[Help Needed] pyranges
Hi, pyranges finally builds now with passing tests - however there are a few issues as lintian reports. Processing triggers for libc-bin (2.30-8) ... E: pyranges source: source-is-missing docs/libs/gitbook-2.6.7/js/app.min.js E: pyranges source: source-is-missing docs/libs/gitbook-2.6.7/js/lunr.js line length is 14839 characters (>512) E: pyranges source: source-is-missing docs/libs/jquery-2.2.3/jquery.min.js E: python3-pyranges: unknown-file-in-python-module-directory usr/lib/python3/dist-packages/hi I know what this is about - this is because this ships minified javascript - which is forbidden in debian. There are several such JS files vendored in the documentation. However - the documentation is vendored in two formats: 1. html files with corresponding JS 2. The exact same documentation is also vendored in .Rmd format - I've compared it and it is indeed, same. Now, coming to the problem:There are two ways to fix the errors: 1. The most ideal way will be to remove all the javascript files and symlink against system files. However, as you can see: there's a file named "app.min.js" : this is a pretty generic name with no obvious source. Hence, I need to ask upstream to provide that file and minify it during build - not sure how many weeks(or months this will take) 2. Simply remove the html + vendored JS. The documentation is anyway vendored in .Rmd files, and by doing this I'm not depriving the users from the documentation - I'm just reducing the functionality a little by removing html files. I admit that I'm honestly tempted to go with this option since this saves me from a lot of un-necessary work as well as waiting for upstream to give me the source of "app.min.js" - the docs are delivered anyway, albeit in different format - hence I do not see any side-effects of doing this. I need opinions and "ACKs" before I do anything. Please let me know what seems good to you. Kind Regards, Nilesh
Re: [Help Needed] pyranges
Hi noticed that there's a new upstream release just 2 days ago which is after when Steffen started to work on the Debian package. And looks like they cleaned their mess, I updated to latest upstream now it should be okay :-) On Sun, 21 Jun 2020, 16:08 Andreas Tille, wrote: > Hi Nilesh, > > On Sun, Jun 21, 2020 at 02:14:25PM +0530, Nilesh Patra wrote: > > Hi, > > pyranges finally builds now with passing tests - however there are a few > > issues as lintian reports. > > > > Processing triggers for libc-bin (2.30-8) ... > > E: pyranges source: source-is-missing > docs/libs/gitbook-2.6.7/js/app.min.js > > E: pyranges source: source-is-missing docs/libs/gitbook-2.6.7/js/lunr.js > > line length is 14839 characters (>512) > > Argh, that's a nuisance. I had these gitbook JS in > > https://salsa.debian.org/r-pkg-team/r-cran-bookdown > > ... luckily including non-compressed JS. > > > E: pyranges source: source-is-missing > docs/libs/jquery-2.2.3/jquery.min.js > > That's usually done by Files-Excluded + Depends: libjs-jquery + dh_link > > > E: python3-pyranges: unknown-file-in-python-module-directory > > usr/lib/python3/dist-packages/hi > > ? > No idea about this - my laptop is working hard to build the test suite > so I do not yet have any chance to inspect the result. > > > I know what this is about - this is because this ships minified > javascript > > - which is forbidden in debian. > > There are several such JS files vendored in the documentation. > > > > However - the documentation is vendored in two formats: > > 1. html files with corresponding JS > > 2. The exact same documentation is also vendored in .Rmd format - I've > > compared it and it is indeed, same. > > > > Now, coming to the problem:There are two ways to fix the errors: > > > > 1. The most ideal way will be to remove all the javascript files and > > symlink against system files. > > However, as you can see: there's a file named "app.min.js" : this is a > > pretty generic name with no obvious source. > > As I said its somewhere hidden inside the source of another package. > > > Hence, I need to ask upstream to provide that file and minify it during > > build - not sure how many > > weeks(or months this will take) > > > > 2. Simply remove the html + vendored JS. The documentation is anyway > > vendored in .Rmd files, and > > by doing this I'm not depriving the users from the documentation - I'm > > just reducing the functionality > > a little by removing html files. > > Yes. That's *way* more simple and straightforward. I doubt that any > user will read it in the Debian package. Just add a README.Debian > where to find the docs online and that's it. > > > I admit that I'm honestly tempted to go with this option since this > saves > > me from a lot of un-necessary work > > as well as waiting for upstream to give me the source of "app.min.js" - > > the docs are delivered anyway, albeit in > > different format - hence I do not see any side-effects of doing this. > > Just go for it and save your valuable time. > > > I need opinions and "ACKs" before I do anything. Please let me know what > > seems good to you. > > Thanks a lot for your work on this > > Andreas. > > -- > http://fam-tille.de > >
Re: [Help Needed] pyranges
> > Please push :-) > Done and on building w/o tests - everything clean. Now building with tests - the tests are too heavy. Shall file an ITP and send RFS when it finishes (hopefully) successfully. > >
Re: [Help Needed] pyranges
On Sun, 21 Jun 2020 at 17:43, Andreas Tille wrote: > On Sun, Jun 21, 2020 at 05:12:58PM +0530, Nilesh Patra wrote: > > > > > > Please push :-) > > > > Done and on building w/o tests - everything clean. > > Now building with tests - the tests are too heavy. > > Yep. Need to switch to another machine. ;-) > yeah, It took 3 full hours! :o Completed now. > > > Shall file an ITP and send RFS when it finishes (hopefully) successfully. > > There is an ITP: #963015 > > Please ping me once you want me to sponsor. > I think everything is fine now. Please review and upload.
Re: sonLib_daemonize.py goes missing before build
On Tue, 23 Jun 2020, 20:40 Shayan Doust, wrote: > Hello, > > For now, I've just resorted to adding this python file into > missing-sources and copying it to the required directory within rules. > If it's included in the upstream branch and not in your master branch, then doing this is not correct. Try to delete the tag once and re-import : this might fix it. >
[Help Needed] unifrac
Hi,
While trying to package unifrac - and applying a couple of patched (which
is IMO, fine), I seem to get this strange error related to HDF5:
h5c++ -shared -o libssu.so tree.o biom.o unifrac.o cmd.o unifrac_task.o
api.o -lc -lhdf5_cpp -L/lib
/usr/bin/ld:
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5_cpp.a(H5IdComponent.o):
relocation R_X86_64_PC32 against symbol `_ZTVN2H511IdComponentE' can not be
used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:62: api] Error 1
make[1]: Leaving directory '/home/nilesh/packages/unifrac/unifrac/sucpp'
Traceback (most recent call last):
File "setup.py", line 94, in
setup(
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 144,
in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.8/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.8/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/lib/python3.8/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/usr/lib/python3.8/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/lib/python3.8/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "setup.py", line 61, in run
self.run_compile_ssu()
File "setup.py", line 65, in run_compile_ssu
self.execute(compile_ssu, [], 'Compiling SSU')
File "/usr/lib/python3.8/distutils/cmd.py", line 335, in execute
util.execute(func, args, msg, dry_run=self.dry_run)
File "/usr/lib/python3.8/distutils/util.py", line 303, in execute
func(*args)
File "setup.py", line 54, in compile_ssu
raise Exception('Error compiling ssu!')
Exception: Error compiling ssu!
E: pybuild pybuild:352: build: plugin distutils failed with: exit code=1:
/usr/bin/python3 setup.py build
dh_auto_build: error: pybuild --build -i python{version} -p 3.8 returned
exit code 13
make: *** [debian/rules:21: build] Error 13
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2
I am not sure if hdf5 needs a recompilation here or there's a flag which
I'm missing.
I've pushed my changes to:
https://salsa.debian.org/med-team/unifrac
Need opinions and help here.
Thanks and regards,
Nilesh
[RFS] seq-gen
Hi, I've added autopkgtests for seq-gen and this builds in a clean chroot with passing tests. The changes have been pushed here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/seq-gen Thanks and regards Nilesh
Re: [Help Needed] unifrac
Hi Aaron On Thu, 25 Jun 2020, 01:34 Aaron M. Ucko, wrote: > Nilesh Patra writes: > > > h5c++ -shared -o libssu.so tree.o biom.o unifrac.o cmd.o unifrac_task.o > > api.o -lc -lhdf5_cpp -L/lib > > Please try adding the h5c++ flag -shlib (which its manual page neglects > to mention as a possibility :-/). > Thank you for the fix :-) >
Re: [RFS] seq-gen
Hi On Fri, 26 Jun 2020, 01:48 Andreas Tille, wrote: > Hi Nilesh, > > On Thu, Jun 25, 2020 at 08:38:58PM +0530, Nilesh Patra wrote: > > Hi, > > I've added autopkgtests for seq-gen and this builds in a clean chroot > with > > passing tests. > > Thanks for your work on this. Unfortunately I doubt that the effort > to add tests to packages in non-free is a waste of time since CI > is only run on packages in main. In this case it would be better to > discuss a free license with upstream. PAML is meanwhile free - so > chances to review seq-gen should be promising. > While we will sure ask for a license file here, but this comment: https://github.com/rambaut/Seq-Gen/issues/12#issuecomment-397349452 Seems to convey that this is free? I did checkout a few files and they seem to have the BSD license at the top of them. Would you have ideas as to what component here would be non-free? Or is it just the absence of LICENSE file that makes it so? Kind regards Nilesh >
Re: [RFS] seq-gen
Well the data and docs look non-free - will ask upstream. On Fri, 26 Jun 2020, 02:17 Nilesh Patra, wrote: > Hi > > On Fri, 26 Jun 2020, 01:48 Andreas Tille, wrote: > >> Hi Nilesh, >> >> On Thu, Jun 25, 2020 at 08:38:58PM +0530, Nilesh Patra wrote: >> > Hi, >> > I've added autopkgtests for seq-gen and this builds in a clean chroot >> with >> > passing tests. >> >> Thanks for your work on this. Unfortunately I doubt that the effort >> to add tests to packages in non-free is a waste of time since CI >> is only run on packages in main. In this case it would be better to >> discuss a free license with upstream. PAML is meanwhile free - so >> chances to review seq-gen should be promising. >> > > While we will sure ask for a license file here, but this comment: > > https://github.com/rambaut/Seq-Gen/issues/12#issuecomment-397349452 > > Seems to convey that this is free? > I did checkout a few files and they seem to have the BSD license at the > top of them. > > Would you have ideas as to what component here would be non-free? > > Or is it just the absence of LICENSE file that makes it so? > > Kind regards > Nilesh > >>
[RFS] beads
Hi, I've added autopkgtests for beads- builds with passing tests. I've pushed my changes to the team-repo[1] Needs review and sponsorship OR grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 [1]: https://salsa.debian.org/med-team/beads Thanks and regards, Nilesh
[RFS] sickle
Hi, I've added autopkgtests for beads- builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/sickle OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] elph
Hi, I've added autopkgtests for elph- builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/elph OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
Re: [RFS] elph
On Tue, 30 Jun 2020, 20:57 Steffen Möller, wrote: > Hi, granted! Thank you :) Just uploaded. > If this package is regularly updated then, to avoid too much extra load > on https://snapshot.debian.org/, I suggest to wait for the next upstream > release, though, you decide. > As per it's release page, the last update was many, many years ago - probably not as frequently updated. There have been bugs filed on this though, which resulted in more (Debian) releases. Regards, Nilesh >
[RFS] pal2nal
Hi, I've added autopkgtests for pal2nal- builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/pal2nal OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
Re: EDFlib 1.18 (new version available)
On Sat, 4 Jul 2020, 13:22 Andreas Tille, wrote: > Hi Teunis, > > On Sat, Jul 04, 2020 at 06:40:51AM +, Teunis van Beelen wrote: > > EDFlib 1.18 is available at: > > > > https://www.teuniz.net/edflib/ > > Thanks for the information. > > I've included the new version into our packaging Git[1]. Unfortunately > the autopkgtest fails: > > gcc -Wall -Wextra -Wshadow -Wformat-nonliteral -Wformat-security > -Wtype-limits -g -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -c unittest.c -o > unittest.o > gcc unittest.o -o edflib_test -ledf > Error, line 79 file unittest.c > autopkgtest [07:47:13]: test run-unit-test: ---] > autopkgtest [07:47:13]: test run-unit-test: - - - - - - - - - - results - > - - - - - - - - - > run-unit-testFAIL non-zero exit status 1 > > > I've included Nilesh and Pranav in CC - may be you can have a look. > Fixed. And cleaned the rest of lintian stuff as well. Please check, and upload. Kind regards Nilesh >
[RFS] mptp
Hi, I've added autopkgtests for mptp - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/mptp OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
Re: advice for gneiss package (more specifically, its unit tests)
Hi, On Thu, 9 Jul 2020, 01:20 Shayan Doust, wrote: > Hello, > > I was planning on packaging q2-gneiss, but gneiss is a missing > dependency which I am packaging right now[1]. Right now, I care about > getting gneiss to run properly hence the incomplete package. > > During nosetest, there is only one error[2]. This is because there is a > missing module called Bokeh. If it's a test-only dependency, IMO you can simply skip that particular test for now. And enable testing it when bokeh is packaged and accepted into the archive. Looking at Bokeh's situation, it seems like > it isn't in the repository, but there has been interest for packaging[3]. > As an additional work - you can enquire about the status of bokeh packaging by replying to the bug, CC'ing Diane (who's doing the original work) > I should also note that within setup.py, bokeh is not listed as a > requirement to build or install, so this makes me have the feeling that > perhaps bokeh is not important to have for this package's core > functionality? > Yeah, I'd anticipate probably not needed. All the upstream tests but one pass, as you reported above - this sounds more convincing that it's very likely not needed. FWIW: Bokeh is a data visualization module, and maybe that's used in tests to visualize and confirm the results of gneiss and nothing more. > I need some advice as to whether or not I should continue packaging > this, or if there is a suggestion to do something else to work around > this missing module or something. > I hope my reply helps you? :-) Kind regards, Nilesh > [1]: https://salsa.debian.org/med-team/gneiss/ > [2]: https://paste.debian.net/1155647/ > [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756017 >
Re: advice for gneiss package (more specifically, its unit tests)
On Thu, 9 Jul 2020, 03:15 Shayan Doust, wrote: > Hello Nilesh, > > > If it's a test-only dependency, IMO you can simply skip that particular > > test for now. > > And enable testing it when bokeh is packaged and accepted into the > archive. > > > Yeah, I'd anticipate probably not needed. > > All the upstream tests but one pass, as you reported above - this sounds > > more convincing that it's very likely not needed. > > > > FWIW: Bokeh is a data visualization module, and maybe that's used in > > tests to visualize and confirm the results of gneiss and nothing more. > > I'm skeptic about this being a test-only module. Imports to bokeh are > done more-so within the gneiss files and not the test files itself, for > instance in the regression plot file[1] > Ah, then this is being used for the data visualization part here, and is probably not a test-only dependency. I suppose the _core_ functionality (analysis) will remain unaffected, but the visualisation part will be unusable. Can you try to use this module - maybe try reading docs and see how broken/not-brokem it looks? If there's no visualization, maybe this isn't fit to go to the archive yet. > > As an additional work - you can enquire about the status of bokeh > > packaging by replying to the bug, CC'ing Diane (who's doing the original > > work) > > I will perhaps ping the bug report and see if there is anything, > I suppose that makes sense. Maybe we'll have to wait till Bokeh gets uploaded, replying might help speed up the process. although I couldn't find anything "bokeh" on Salsa (unless packaging > efforts are being done elsewhere). Here[2] Kind regards, Nilesh > [1]: > > https://salsa.debian.org/med-team/gneiss/-/blob/master/gneiss/plot/_regression_plot.py [2]: https://github.com/detrout/python-bokeh
Re: advice for gneiss package (more specifically, its unit tests)
On Thu, 9 Jul 2020, 05:03 Shayan Doust, wrote: > Hello Nilesh, > > > Ah, then this is being used for the data visualization part here, and is > > probably not a test-only dependency. > > I suppose the _core_ functionality (analysis) will remain unaffected, > > but the visualisation part will be unusable. > > Can you try to use this module - maybe try reading docs and see how > > broken/not-brokem it looks? > > If there's no visualization, maybe this isn't fit to go to the archive > yet. > > From what I can see by reading the source, only one exposed function is > not functional due to the missing module. Specifically, from the > gneiss.plot module, the importation of "radialplot" is the only one that > depends on bokeh. > If "only" radial plot is broken, and rest all of the stuff works out of the box, this can be good to go for an upload. > This seems to be agreeable with the unit test where only one unit test > failed. I am not sure if the failure on one visualisation module (out of > multiple) would constitute a low-standard to where a package is held > back, or if there are presumably some ways around this, as of course > primarily the package installation should handle everything itself and > not rely on some end-user intervention for further third party > installation. > It is a much better idea if you can tweak the code in a way that replaces bokeh's functionality with some other package available in Debian, which can handle radial plots. Matplotlib maybe? That'd make it less functional, but definitely not broken. Add this change in README.Debian in either case. > I did also ping within the bug report for bokeh with your suggestion, > but then I stumbled across bokehjs[1], which seems to be a subset / > included within bokeh as a whole. From what I can see, bokeh seems big > and complex, so that puts a doubt as to when its upload would happen :(. > It can definitely happen, as there are already a huge amount of complex packages in Debian, some of which you'd be running while you typed this email :-) As peb mentioned in the last email on the bug, it comes with a vendored un-minified JS which can be used for a first upload, and this can be removed in long run. I hope Diane replies soon. > [1]: https://wiki.debian.org/Javascript/Nodejs/Tasks/bokehjs I'd help with this too, if things start moving forward. I've earlier JS packaging experience, and I'd love to help. Kind regards, Nilesh >
[RFS] python-py2bit
Hi, I've added autopkgtests for python-py2bit - builds with passing tests. Also fixed the tests not running. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-py2bit OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] cyvcf2
Hi, Currently cyvcf2 FTBFS as reported in the bug report: #964677 I've fixed this, this involved importing to a new release. I've also tested its reverse dependencies with ruby-team/meta and it looks OK : = Found reverse (build) dependencies that can be tested! autopkgtest --- bcbio rebuild --- bcbio Which tests to run: [A(all)/e(dit list)]/s(kip all)] A = Testing reverse (build) dependencies autopkgtest bcbio ... PASS rebuild bcbio ... PASS I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-py2bit OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] patsy
Hi, Currently patsy FTBFS: as seen in RC bug:#964640 and I've fixed this. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/patsy OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] python-scitrack
Hi, I've added autopkgtests for python-scitrack - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-scitrack OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] dwgsim
Hi, I've added autopkgtests for dwgsim - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/dwgsim OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
Re: [RFS] dwgsim
On Tue, 14 Jul 2020, 19:12 Steffen Möller, wrote: > Allowed. > Many thanks, just got the mail now. And done dput. Kind Regards, Nilesh >
[RFS] qrisk2
Hi, I've added autopkgtests for qrisk2 - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/qrisk2 OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] libpll
Hi, I've added autopkgtests for libpll - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/libpll OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] python-biom-format
Hi, python-biom-format reports failing tests in debci: https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-biom-format/6170952/log.gz I've fixed this - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-biom-format OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] python-geneimpacts
Hi, I've added autopkgtests for python-geneimpacts - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-geneimpacts OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] python-deeptoolsintervals
Hi, I've added autopkgtests for python-geneimpacts - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-deeptoolsintervals OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] python-xopen
Hi, I've added autopkgtests for python-xopen - builds with passing tests. I updated the package as well to new upstream version. Since this is a non-leaf package with a few important reverse dependencies, I checked that the new update of the package doesn't break anything with ruby-team/meta scripts. These are the results: = Found reverse (build) dependencies that can be tested! autopkgtest --- igdiscover python-cutadapt python-dnaio python-sqt rebuild --- igdiscover python-cutadapt python-dnaio python-sqt Which tests to run: [A(all)/e(dit list)]/s(kip all)] A = Testing reverse (build) dependencies autopkgtest igdiscover ... PASS rebuild igdiscover ... PASS autopkgtest python-cutadapt ... PASS rebuild python-cutadapt ... PASS autopkgtest python-dnaio... PASS rebuild python-dnaio... PASS autopkgtest python-sqt ... PASS rebuild python-sqt ... PASS I suppose this is fine. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-xopen OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] unifrac
Hi, I had packaged unifrac a few weeks ago at the team-repo. It builds fine however I see these lintian errors which I've no idea about: E: libssu0: custom-library-search-path usr/bin/faithpd /usr/lib/x86_64-linux-gnu/hdf5/serial E: libssu0: custom-library-search-path usr/bin/ssu /usr/lib/x86_64-linux-gnu/hdf5/serial E: libssu0: custom-library-search-path usr/lib/x86_64-linux-gnu/libssu.so.0 /usr/lib/x86_64-linux-gnu/hdf5/serial Andreas had helped me with a few commits earlier wherein they removed the Rpath flag as well hence I have no idea about the source of these errors. Help and advice are greatly appreciated. [1]: https://salsa.debian.org/med-team/unifrac/ Thanks and regards Nilesh
[RFS] mlv-smile
Hi, I've fixed gcc-10 FTBFS for mlv-smile as reported here in #957551. Additionally, I added in autopkgtests as well - builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/mlv-smile OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] prime-philo
Hi, I've fixed gcc-10 FTBFS for prime-philo as reported here in #957708. builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/prime-philo OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] roguenarok
Hi, I've fixed gcc-10 FTBFS for roguenarok as reported here in #957768. builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/roguenarok OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] seaview
Hi, I've fixed gcc-10 FTBFS for seaview as reported here in #957783. builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/seaview OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] saint
Hi, I've fixed gcc-10 FTBFS for saint as reported here in #957772. builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/saint OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] minc-tools
Hi, I've fixed gcc-10 FTBFS for minc-tools as reported here in RC bug #957542. It now builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/minc-tools OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] python-ncls
Hi, I've fixed autopkgtests for python-ncls. It builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/python-ncls OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
Re: Request for a sponsored upload of fast5-research
On Tue, 4 Aug 2020 at 18:20, Shayan Doust wrote: > Hello Andreas, > > Thanks for the nitpicking! > > I've had a moment of inactivity with this package, so I forgot why the > patch was there. I now remember the patch I put there simply disables an > erroneous assertion: > > AssertionError: Tuples differ: (303, 2) != (303, 2, > void(b'\x00\x00\x00\x00')) > > I did this, and dh_missing, to speed up the packaging and should have > really removed those before I emailed. Although, I am not sure how I > can contact upstream and should have just written an email here about > it. I still think this is a very trivial assertion issue, and the tuples > compared are very similar with the exception of the extra void(...) > element. Out of 63 tests, maybe it's still worth keeping the patch > The first two values are still the same - so it is worth comparing atleast these values instead of disabling altogether, right? > (given I add the description) until a future fix, or someone in the team > can rectify this. What do you suggest? I dug in a bit - it looks like that there's an issue with typecasting in the code. Upstream can shed more light on this, it makes sense to open an issue IMO. Also, I've pushed in the above mentioned 'fix' (?) and a couple of other minor changes, please $git pull :) > > As for the manpage, the only other method really is writing manpages for > the two scripts. Apart from the spelling mistakes which can be fixed, > the manpage has quite a featureful and meaningful content of both the > scripts and the library usage - although I agree this is a replication > of the HTML documentation. Do you suggest I simply just write the > manpages for the two scripts? > You can do that, but to save your effort you might consider using ronn[1] or marked-man. [1]: https://packages.debian.org/unstable/ronn [2]: https://tracker.debian.org/pkg/node-marked-man Kind Regards, Nilesh
Re: Request for a sponsored upload of fast5-research
Worth mentioning that the changes have all been made as suggested. Do > let me know if anything else remains outstanding > Looks good to me. I've done these: 1. Added Autopkgtests 2. Change archs to all instead of any 3. Run wrap-and-sort for aesthetic styling - just so that it looks sorted. Enough nitpicking at my end I guess, this is good to go :-) Kind regards Nilesh
[RFS] kalign
Hi, I've fixed gcc-10 FTBFS for kalign as reported here in RC bug #966865 It now builds with passing tests. I've pushed my changes to the team-repo[1] Please: gbp clone --pristine-tar https://salsa.debian.org/med-team/kalign OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and regards Nilesh
[RFS] quicktree
gbp clone --pristine-tar https://salsa.debian.org/med-team/quicktree OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Regards Nilesh
[RFS] psychopy
gbp clone --pristine-tar https://salsa.debian.org/med-team/psychopy OR Grant DM access: PGP key fingerprint: 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Thanks and Regards Nilesh
