similar to: Fedora 42 R source build issues

On Wed, 16 Apr 2025 at 09:48, Roger Bivand via R-SIG-Fedora < r-sig-fedora at r-project.org> wrote: > Building R 4.5.0 from source on Fedora 42 hits problems because 42 ships > with Tcl/Tk 9. tcl8-devel and tk8-devel are available and can be used, but > I haven't yet found a viable incantation yet. Neither R released nor devel > support Tcl/Tk 9

On Wed, 16 Apr 2025 at 10:11, I?aki Ucar <iucar at fedoraproject.org> wrote: > On Wed, 16 Apr 2025 at 09:48, Roger Bivand via R-SIG-Fedora < > r-sig-fedora at r-project.org> wrote: > > > Building R 4.5.0 from source on Fedora 42 hits problems because 42 ships > > with Tcl/Tk 9. tcl8-devel and tk8-devel are available and can be used, > but > > I

El lun., 30 oct. 2023 12:26, Roger Bivand <Roger.Bivand at nhh.no> escribi?: > I also noticed this: > > https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/ > > which is concerning. Until now, I've retained X11 on Fedora because of > difficulties in screen sharing via zoom in Wayland sessions. > KDE Plasma user here. FWIW, I've been using Wayland

I also noticed this: https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/ which is concerning. Until now, I've retained X11 on Fedora because of difficulties in screen sharing via zoom in Wayland sessions. Roger -- Roger Bivand Emeritus Professor Norwegian School of Economics Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway Roger.Bivand at nhh.no

In trying to install the pbatR package, I was greeted with the error Error: package 'tcltk' does not have a name space Execution halted Directly installing the package tcltk2 returned the following error: Loading required package: tcltk Error in firstlib(which.lib.loc, package) : Tcl/Tk support is not available on this system I have seen from previous posts that tcl/tk must be

Roger, just to you: Thanks for taking the time! I hope that Ari follows your recommendation, fingers crossed. Best wishes, Achim On Thu, 13 Feb 2025, Roger Bivand via R-help wrote: > Ari, > > There were multiple errors in the acs package. If CRAN states that the maintainer abandoned it, that is what happened. Had you reached out to Ezra Glenn (cc-ed here) and offered to help keep

Ari, There were multiple errors in the acs package. If CRAN states that the maintainer abandoned it, that is what happened. Had you reached out to Ezra Glenn (cc-ed here) and offered to help keep the package maintained, this hiccup need not have happened. The three problems were: 1) stale URLs using http: not https:, of which some are dead (locally changed to https:, so reported as such):

The third report on the R-spatial evolution project has been published. https://r-spatial.org/r/2023/04/10/evolution3.html It links back to earlier blogs and presentations, and focuses on work that maintainers of R packages and workflows using rgdal, rgeos and maptools need to put in train now before the packages are archived on CRAN. The first changes will occur in June 2023, and the

The third report on the R-spatial evolution project has been published. https://r-spatial.org/r/2023/04/10/evolution3.html It links back to earlier blogs and presentations, and focuses on work that maintainers of R packages and workflows using rgdal, rgeos and maptools need to put in train now before the packages are archived on CRAN. The first changes will occur in June 2023, and the

On Sat, 10 Nov 2018, I?aki Ucar wrote: > On Sat, 10 Nov 2018 at 15:17, Roger Bivand <Roger.Bivand at nhh.no> wrote: >> >> On upgrading my F28 to F29, I've found that R-core and a number of R >> packages: >> >> R-evaluate R-glue R-highr R-knitr R-magrittr R-markdown R-mime R-stringi >> R-stringr R-yaml >> >> are installed, although I

Hello! I'm confused as to what the actual problem with includeRnw is? Is the problem that it relies on R-knitr? Before it would be withdrawn, may I be given an opportunity to fix said problem? includeRnw only invokes the already existing R installation, and should not affect any other global settings or affect the installation in any way. If this is the case, it's a bug and I'd

I was looking at the example on the manual page of plot.window, and noticed that it needs fixing - names(eurodist) should now be labels(eurodist): --- /home/rsb/topics/R-2.2.0/src/library/graphics/man/plot.window.Rd 2005-04-18 12:18:59.000000000 +0200 +++ plot.window.Rd 2005-10-11 21:08:57.000000000 +0200 @@ -48,6 +48,6 @@ ry <- range(y <- -loc[,2]) plot(x, y, type="n",

Questions are threaded into the output: ******************** #./configure --without-python checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking

Hello Roger: Thank you for your email. Some details for the problem. This is the message of the console in R: ------------------ install.packages("rgdal") Installing package into ?/home/aliendist/R/x86_64-redhat-linux-gnu-library/3.1? (as ?lib? is unspecified) probando la URL 'http://cran.rstudio.com/src/contrib/rgdal_0.9-1.tar.gz' Content type 'application/x-gzip'

On upgrading my F28 to F29, I've found that R-core and a number of R packages: R-evaluate R-glue R-highr R-knitr R-magrittr R-markdown R-mime R-stringi R-stringr R-yaml are installed, although I only ever install R from source and always keep my Rs locally. So I don't use Fedora R rpms, but these were installed without my command. Something in texlive is doing this. A remedy is to

I contacted John Fox about this first, because parts of the file are attributed to him. He says that he didn't write rstandard.glm(), and suggests asking r-devel. As it stands, rstandard.glm() has summary(model)$dispersion outside the sqrt(), while in rstandard.lm(), the sd is already sqrt()ed. This seems to follow stdres() in VR/MASS/R/stdres.R. Of course for the c("poisson",

In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R version installed. Very recently, users installing rgdal from source with R installed from RPM are seeing problems, such as those reported in this thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html The diagnosis by

I've run into a problem that I hope has an obvious solution. The sp package uses S4 classes and has a NAMESPACE, and when installed without package versions, runs OK, passes R CMD check, and so on. A user reported that he installed it --with-package-versions, and that from then on it would fail at first use of a class defined in the package. I've reconstructed the problem in a

On Sat, 10 Nov 2018, Andreas Storvik Strauman wrote: > Hello! I'm confused as to what the actual problem with includeRnw is? Is > the problem that it relies on R-knitr? Before it would be withdrawn, may > I be given an opportunity to fix said problem? Yes, the problem is that it expesses an external dependence on anything outside texlive. On packaging systems (for me Fedora),

Excuse my asking here than on R-help, but it may be a Fedora question. On Fedora 7, I'm running a fresh R 2.7.1 built from source, usually in en_GB, but also tried in en_GB.UTF8. Running example(plotmath) generates lots of: Pango-WARNING **: shape engine failure, expect ugly output. the offending font is 'Symbol Not-Rotated ...' Setting: x11(type="Xlib") relieves the