[R] R CMD check fails at package dependencies check on Fedora Core 5, works on other systems

[Kurt Hornik]

>>>>> Marc Schwartz (via MN) writes:

> On Tue, 2006-09-19 at 22:16 +1000, Robert King wrote:
>> Here is another thing that might help work out what is happening.  If I 
>> use --no-install, ade4 actually fails as well, in the same way as zipfR.
>> 
>> [Desktop]$ R CMD check --no-install ade4
>> * checking for working latex ... OK
>> * using log directory '/home/rak776/Desktop/ade4.Rcheck'
>> * using Version 2.3.1 (2006-06-01)
>> * checking for file 'ade4/DESCRIPTION' ... OK
>> * this is package 'ade4' version '1.4-1'
>> * checking if this is a source package ... OK
>> * checking package directory ... OK
>> * checking for portable file names ... OK
>> * checking for sufficient/correct file permissions ... OK
>> * checking DESCRIPTION meta-information ... ERROR
>> 
>> [Desktop]$ R CMD check --no-install zipfR
>> * checking for working latex ... OK
>> * using log directory '/home/rak776/Desktop/zipfR.Rcheck'
>> * using Version 2.3.1 (2006-06-01)
>> * checking for file 'zipfR/DESCRIPTION' ... OK
>> * checking extension type ... Package
>> * this is package 'zipfR' version '0.6-0'
>> * checking if this is a source package ... OK
>> * checking package directory ... OK
>> * checking for portable file names ... OK
>> * checking for sufficient/correct file permissions ... OK
>> * checking DESCRIPTION meta-information ... ERROR

> <snip>

> Robert,

> I tried the process last night (my time) using the initial instructions
> on my FC5 system with:

> $ R --version
> R version 2.3.1 Patched (2006-08-06 r38829)
> Copyright (C) 2006 R Development Core Team


> I could not replicate the problem.

> However, this morning, with your additional communication:

> $ R CMD check --no-install zipfR_0.6-0.tar.gz
> * checking for working latex ... OK
> * using log directory '/home/marcs/Downloads/zipfR.Rcheck'
> * using Version 2.3.1 Patched (2006-08-06 r38829)
> * checking for file 'zipfR/DESCRIPTION' ... OK
> * checking extension type ... Package
> * this is package 'zipfR' version '0.6-0'
> * checking if this is a source package ... OK
> * checking package directory ... OK
> * checking for portable file names ... OK
> * checking for sufficient/correct file permissions ... OK
> * checking DESCRIPTION meta-information ... OK
> * checking top-level files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for syntax errors ... OK
> * checking R files for library.dynam ... OK
> * checking S3 generic/method consistency ... OK
> * checking replacement functions ... OK
> * checking foreign function calls ... OK
> * checking Rd files ... OK
> * checking Rd cross-references ... WARNING
> Warning in grep(pattern, x, ignore.case, extended, value, fixed,
> useBytes) :
>          input string 70 is invalid in this locale
> * checking for missing documentation entries ... WARNING
> Warning in grep(pattern, x, ignore.case, extended, value, fixed,
> useBytes) :
>          input string 70 is invalid in this locale
> All user-level objects in a package should have documentation entries.
> See chapter 'Writing R documentation files' in manual 'Writing R
> Extensions'.
> * checking for code/documentation mismatches ... OK
> * checking Rd \usage sections ... OK
> * checking DVI version of manual ... OK

> WARNING: There were 2 warnings, see
>   /home/marcs/Downloads/zipfR.Rcheck/00check.log
> for details



> So I am wondering if this raises the possibility of a locale issue on
> your FC5 system resulting in a problem reading DESCRIPTION files?  It
> may be totally unrelated, but one never knows I suppose. Mine is:

> $ locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=


> HTH,

> Marc Schwartz

That's a bug in tools:::Rd_aliases (it needs to preprocess the Rd lines,
which re-encodes if necessary and possible).

I'll commit a fix later today.

Thanks for spotting this.

Best
-k