similar to: R CMD build error during vignettes build

On 21/02/17 19:06, Sebastian P. Luque wrote: > Hello, > > I'm trying to rebuild a package (using R version 3.3.2 (2016-10-31)) > that has not seen any changes since it was last built without problems > in previous R versions. It fails during vignette building with: > > ---<--------------------cut here---------------start------------------->--- > $ R CMD build

Hello: Changes in R seem to have broken the sos vignette, and I don't know how to fix it. The build on R-forge, "https://r-forge.r-project.org/R/?group_id=235&log=build_src&pkg=sos&flavor=patched", ends as follows: Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, : Running 'texi2dvi' on 'sos.tex' failed. LaTeX

The NEWS for R-devel has the following item: > The previously included versions of zlib, bzip2, xz and PCRE have > been removed, so suitable external (usually system) versions are > required (see the ?R Installation and Administration? manual). Therefore I believe the following information in 'src/library/base/man/regex.Rd' is no longer valid: > If PCRE support was compiled

In a package 'vig' R CMD build vig (or tools::buildVignettes(dir="vig") with $ cat vig/vignettes/vig1.Rnw \documentclass{article} \begin{document} <<>>= x <- 1 @ \end{document} $ cat vig/vignettes/vig2.Rnw \documentclass{article} \begin{document} <<>>= x @ \end{document} produces vig2.pdf where x is defined with value 1 -- the vignettes share a build

I get an error when running "make check" after building R-devel r70629 on Ubuntu 14.04. Here are the relevant lines in the file "reg-tests-1c.Rout.fail": > ## m1z uses match(x, *) with length(x) == 1 and failed in R 3.3.0 > ## PR#16909 - a consequence of the match() bug; check here too: > dv <- data.frame(var?1 = 1:3, var?2 = 3); dv[,"var?2"]

On 18/05/16 13:50, Martin Maechler wrote: >>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>>> on Wed, 18 May 2016 13:05:24 +0300 writes: > > > I get an error when running "make check" after building > > R-devel r70629 on Ubuntu 14.04. > > Here are the relevant > > lines in the file

With new R releases soon to come, I suggest updating the Rcopyright macro in "doc/manual/R-defs.texi" to use year 2017. -- Mikko Korpela Department of Geosciences and Geography University of Helsinki

(Belated) thanks for the confirmation, Ista. I just reported this issue on the R bug tracker: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17412 Best regards, - Mikko -----Alkuper?inen viesti----- L?hett?j?: Ista Zahn [mailto:istazahn at gmail.com] L?hetetty: 7. helmikuuta 2018 17:05 Vastaanottaja: Korpela Mikko (MML) Kopio: r-devel at r-project.org Aihe: Re: [Rd] Possible bug in

Hello, sorry for not being clear enough. My problem is represented with the following code, running on OSX: mkdir ~/test ln -s ~/test ~/testlink touch ~/test/foo Rscript -e 'Sys.readlink(c("~/test/foo", "~/testlink/foo")); normalizePath(c("~/test/foo","~/testlink/foo"))' I expected `Sys.readlink` to show the same output as `normalizePath`. Also,

Thank you for the introduction to these recent changes, Martin. I think this was the second time I ran "make check" on that platform (Raspberry Pi 32-bit), and the first time (some months ago) it worked fine. So, that makes it kind of "suddenly", although I must say that my use of "make check" is very irregular. I compared code before and after the split you are

The R Bugzilla at <https://bugs.r-project.org/bugzilla3/> is down, for at least some hours by now. The error message from my web browser reads: Can't connect to the database. Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) Is your database installed and up and running? Do you have the correct username and password selected

On Thu, Feb 23, 2017 at 03:23:10PM +0100, Martin Maechler wrote: > >>>>> Mikko Korpela <mikko.korpela at helsinki.fi> > >>>>> on Thu, 23 Feb 2017 14:02:58 +0200 writes: > > > With new R releases soon to come, I suggest updating the > > Rcopyright macro in "doc/manual/R-defs.texi" to use year > > 2017. >

Hello together, the function `Sys.readlink` uses the system's readlink command to resolve symlink paths. On OSX/BSD the command has a different meaning than on Linux [1]. There exists the tool 'realpath', which seems suitable for the task, at least applied at the command line level [2]. It is used in `normalizePath`. I suggest (at least the latter) to * use realpath instead readlink

When 'getOption("checkPackageLicense")' is 'TRUE' and the user calls 'library(grid)' for the first time, R asks the user to either accept or decline the package license. This should not be necessary as the package license is "Part of R ..." with "..." denoting the R version number, and R is free and open source. The unnecessary license

If the "Matrix" package is attached, 'example(dget)' fails: > library(Matrix) > example(dget) dget> fil <- tempfile() dget> ## Write an ASCII version of function mean to our temp file dget> dput(mean, fil) dget> ## And read it back into 'bar' dget> bar <- dget(fil) Error in initialize(value, ...) : '...' used in

It seems there is a problem in tests/d-p-q-r-tst-2.R (R-devel r79091): NA / NaN mismatch is not allowed by a test on lines 590--592, but the comment suggests otherwise. A run of "make check" fails there when tested on a Raspberry Pi with Raspberry Pi OS (based on Debian Buster): all 'NaN' is expected, but all 'NA' is returned when testing the function 'rf()' with

On 23.02.2016 14:06, Mikko Korpela wrote: > On 23.02.2016 11:37, Martin Maechler wrote: >>>>>>> nospam at altfeld-im de <nospam at altfeld-im.de> >>>>>>> on Mon, 22 Feb 2016 18:45:59 +0100 writes: >> >> > Dear R developers >> > I think I have found a bug that can be reproduced with two lines of code >>

I noticed that sub() gives unexpected results for the following test case. In the test case, the (initial) input is ASCII but the replacements are UTF-8. The first sub() produces an UTF-8 result with an "unknown" Encoding. This makes the result garbled in Windows (no UTF-8 locale there). The second sub() produces a correct result, although for some reason it is converted to the native

On a Windows computer (other platforms not tested), installing a package from source may fail if the environment variable R_ICU_LOCALE is set, depending on the package and the locale. For example, after setting R_ICU_LOCALE to "fi_FI", install.packages("seriation", type = "source") (package version 1.2-3) fails with the following error: ** preparing package for

I have just committed your first patch (the strlen() replacement) to R-devel, and will soon put it in R-patched as well. I wont have time to look at this again before the 3.2.4 release, so your file.show() patch isn't going to make it unless someone else gets to it. There's still a faint chance that I'll do more in R-devel before 3.3.0, but I think it's best if there were bug