[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
Re: RFS: ampliconnoise
Hi Pranav, On Thu, Jul 09, 2020 at 01:25:32PM +0530, Pranav Ballaney wrote: > Hi, > I've added autopkgtests to ampliconnoise. Please review and sponsor. > https://salsa.debian.org/med-team/ampliconnoise I decided that its better to have an extra binary package for the test data, created it and uploaded. Thanks for working on this Andreas. -- http://fam-tille.de
Re: False positive lintian tag: requires-r-api
Hi Dylan, On Wed, Jul 8, 2020 at 10:45 PM Dylan Aïssi wrote: > > it would be fine if lintian could detect both formats > r-api-X and r-api-X.X where X is numeric. To give your teams the greatest possible flexibility I allowed in the extension all characters that are legal for package names. API version numbers that are carried into the package names may now also contain plus and minus (as well as the entire alphabet). From my experience, the prefix 'r-api-' will ensure that it works the way you expect. https://salsa.debian.org/lintian/lintian/-/commit/c4a141e83625b3d424bcf3d31f575aab4c1c2fa0 Please write again if something does not work, after all (or stops working). Please also feel free to contribute additional tags for R or any of your other products. Kind regards Felix Lechner
[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
Re: RFS: snap-aligner
Sure, I'll do it from next time. Thanks! ᐧ On Thu, Jul 9, 2020 at 2:47 PM Michael R. Crusoe wrote: > Done. I also ran `routine-update -f` which did a number of cleanups. It > would be nice if you ran that yourself in the future :-) > > I also fixed a spelling error in the upstream source that lintian now > notices. > > Uploaded. Thanks! > > > On Thu, Jul 9, 2020 at 8:52 AM Pranav Ballaney > wrote: > >> Hi, >> I've added autopkgtests to snap-aligner. Please review and sponsor. >> https://salsa.debian.org/med-team/snap-aligner >> >> Regards, >> Pranav >> ᐧ >> >
Re: RFS: snap-aligner
Done. I also ran `routine-update -f` which did a number of cleanups. It would be nice if you ran that yourself in the future :-) I also fixed a spelling error in the upstream source that lintian now notices. Uploaded. Thanks! On Thu, Jul 9, 2020 at 8:52 AM Pranav Ballaney wrote: > Hi, > I've added autopkgtests to snap-aligner. Please review and sponsor. > https://salsa.debian.org/med-team/snap-aligner > > Regards, > Pranav > ᐧ >
RFS: ampliconnoise
Hi, I've added autopkgtests to ampliconnoise. Please review and sponsor. https://salsa.debian.org/med-team/ampliconnoise Regards, Pranav ᐧ
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: snap-aligner
Hi, I've added autopkgtests to snap-aligner. Please review and sponsor. https://salsa.debian.org/med-team/snap-aligner Regards, Pranav ᐧ
