RFS: sweed update to fix ftbfs with gcc 10

Greetings, I had a look at fixing sweed's failure to build from source with Gcc 10 (#957851) and implemented a patch to fix it. The thing ended up to be rather hairy, so maybe it would have been simpler to just append the -fcommon build option, yet there it is. I also took that oportunity to upd

Re: RFS: sweed update to fix ftbfs with gcc 10

Hi Étienne, On Wed, Jul 22, 2020 at 01:03:34PM +0200, etienne.moll...@mailoo.org wrote: > I had a look at fixing sweed's failure to build from source with > Gcc 10 (#957851) and implemented a patch to fix it. The thing > ended up to be rather hairy, so maybe it would have been simpler > to just a

Re: semi-RFS: xenium - good enough for me (at the moment)

Thank you for the upload. With xenium in new, and upstream of DYNAMIC polishing a bit (not only) for us, we will soon have everything for mmmulti. This still leaves quite some work for the viralrecon workflow but is quite a milestone, I tend to think. I just went through the spreadsheet and found

Re: RFS: sweed update to fix ftbfs with gcc 10

Hi Andreas, I see the package has been rejected due to a mismatch of pristine tar, if I understood correctly. Andreas Tille, on 2020-07-22 13:18:06 +0200: > Thanks once again for your work. I just realise that we even missed > to do a source only upload which is done now. Is the reject related

Re: RFS: sweed update to fix ftbfs with gcc 10

Hi Étienne On Wed, Jul 22, 2020 at 05:31:40PM +0200, etienne.moll...@mailoo.org wrote: > > Is the reject related to the issue with your missing source only > upload, or is there any chance this could be caused by a > mishandling of mine ? I doubt its your fault. For whatever reason the pristine

Re: RFS: sweed update to fix ftbfs with gcc 10

Hi Andreas, Andreas Tille, on 2020-07-22 21:37:33 +0200: > On Wed, Jul 22, 2020 at 05:31:40PM +0200, etienne.moll...@mailoo.org wrote: > > Is the reject related to the issue with your missing source only > > upload, or is there any chance this could be caused by a > > mishandling of mine ? > > I

[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 script

Re: [RFS] python-xopen

Allowed. Well done! Steffen On 22.07.20 22:42, Nilesh Patra wrote: > 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

RFS: dialign-t: fix ftbfs with Gcc 10

Aloha, Before I go to sleep, I took the liberty to have a look at another FTBFS with the move to Gcc 10, affecting dialign-t. (Bug #957131 to be precise.) Changes have been pushed to Salsa: https://salsa.debian.org/med-team/dialign-t/ It should be mostly lintian clean (modulo a few info

Re: PIQUE packaging (Was: request for r-cran packages) [correction]

On 20/07/2020 13:03, Andreas Tille wrote: [...] OK, just ITPed package. BTW, I was running make in the tests dir and it ends with: Analysis finished: Mon Jul 20 13:56:47 2020 Create sativas_GWAS.covar file... smartpca -p sativas_GWAS.par > sativas_GWAS-smartpca.log OOPS -i flag not specified

Re: PIQUE packaging (Was: request for r-cran packages) [correction]

Hi Tony, On Wed, Jul 22, 2020 at 11:46:03PM +0100, Tony Travis wrote: > > Analysis finished: Mon Jul 20 13:56:47 2020 > > > > Create sativas_GWAS.covar file... > > smartpca -p sativas_GWAS.par > sativas_GWAS-smartpca.log > > OOPS -i flag not specified at /usr/bin/smartpca line 21. > > pique: erro