[Debian-med-packaging] Bug#879248: r-cran-nmf FTBFS on some arches because of misuse of detectCores()

[Andreas Tille]

Hi Renaud,

seems I was using a wrong e-mail address.  The address mentioned at
CRAN as maintainer was bouncing.

Kind regards

      Andreas,

control: forwarded -1 Renaud Gaujoux <renaud at mancala.cbio.uct.ac.za>

On Sat, Oct 21, 2017 at 07:59:51AM +0200, Andreas Tille wrote:
> control: tags -1 upstream
> control: forwarded -1 Renaud Gaujoux <renaud at tx.technion.ac.il>
> 
> 
> Hi Renaud,
> 
> I'm hereby forwarding an issue that was reported at the Debian
> package.
> 
> Kind regards
> 
>        Andreas.
> 
> 
> On Sat, Oct 21, 2017 at 05:10:44PM +1300, Michael Cree wrote:
> > Source: r-cran-nmf
> > Version: 0.20.6-1
> > Severity: wishlist
> > 
> > r-cran-nmf FTBFS on alpha, sparc64 and the non-linux arches, because
> > it calls R base function parallel::detectCores() and expects the
> > result to be an integer, however the detectCores() documentation
> > states that the result is an integer only if the number of CPU cores
> > is actually detected, and NA otherwise.  On the above mentioned
> > systems detectCores() fails to detect the number of CPUs thus returns
> > NA which leads to the failure to build in r-cran-nmf.
> > 
> > The problem is at line 81 of R/options.R which has:
> > 
> >         , pbackend= if( parallel::detectCores() > 1 ) 'par' else 'seq'
> > 
> > Presumably that code should be modified to assign detectCores() to a
> > variable and test for NA, and if it is NA just go with one core.
> > 
> > Use of detectCores() is also in R/parallel.R and presumably that
> > also should be checked for an NA returned value.
> > 
> > Cheers
> > Michael.
> > 
> > _______________________________________________
> > Debian-med-packaging mailing list
> > Debian-med-packaging at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> > 
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de