Re: [R-sig-Fedora] Problem with R, staged installation for packages, and samba share

[Tom Callaway]

The log of you running configure on your instance allows me to compare it
to the log of when we build it as a package (you don't need to provide that
one).

Honestly, I have no idea right now _why_ pre-built R would fail to move
files to a cifs share when a non-root user can do it. I'm hoping maybe
something will jump out as to how it configures on your setup. We aren't
modifying R's source code at all, nor are we configuring it in a way that
would affect this as far as I know.

Does this also happen with the older R binary RPMs? If you go back to 4.2.3
or 4.2.2, does it happen?

~spot


On Mon, Jun 12, 2023 at 10:38 AM Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> "is the staged installation enabled too in the cases you don't see this
> issue?"
> -> Yes, it should since we stick to default config.
>
> "Can you provide a log of the output (including the commandline with any
> options passed) for configure?"
> -> If we compile locally there is no issue despite not using any option,
> and if we install R from binary, there is no configure log AFAIK, so I am
> not sure how to meet this request.
>
> "can you provide the specific mount options for the cifs share?"
> ->
> sec=krb5,multiuser,mfsymlinks,user=smbuser,domain=localdomain,_netdev,noauto,x-systemd.automount
>
> ++
>
> On Mon, 12 Jun 2023 at 16:11, Tom Callaway  wrote:
>
>> Okay, so if it's not SELinux... perhaps something about how R is being
>> configured is different?
>>
>> Can you provide a log of the output (including the commandline with any
>> options passed) for configure?
>>
>> Also, can you provide the specific mount options for the cifs share?
>>
>> ~spot
>>
>> On Mon, Jun 12, 2023 at 9:12 AM Alexandre Courtiol <
>> alexandre.court...@gmail.com> wrote:
>>
>>> Thanks for the tip but nope: SELinux is off on that system...
>>>
>>> On Mon, 12 Jun 2023 at 13:24, Iñaki Ucar 
>>> wrote:
>>>
>>>> On Mon, 12 Jun 2023 at 13:19, Tom Callaway  wrote:
>>>> >
>>>> > Hmm, that's a weird one. Is SELinux on and enforcing on that setup?
>>>>
>>>> I was going to bet on the same thing. :) But let me add: if the answer
>>>> is affirmative, and this doesn't happen with SELinux disabled, then
>>>> *the answer is NOT to disable SELinux*. Instead, let's figure this
>>>> out, because the answer is to set the proper labels or permissions.
>>>>
>>>> Iñaki
>>>>
>>>> >
>>>> > ~spot
>>>> >
>>>> > On Mon, Jun 12, 2023, 6:55 AM Alexandre Courtiol <
>>>> > alexandre.court...@gmail.com> wrote:
>>>> >
>>>> > > Dear Fedora-R enthusiasts,
>>>> > >
>>>> > > We are experiencing some issues with the binary releases of R 4.3
>>>> for
>>>> > > Fedora 37 & 38 when running it on our infrastructure.
>>>> > >
>>>> > > The issue is that packages won't install, unless the (default)
>>>> staged
>>>> > > installation process for packages is switched off
>>>> (--no-staged-install).
>>>> > >
>>>> > > It seems to be related to the fact that we are storing R libraries
>>>> on a
>>>> > > drive mounted via samba share.
>>>> > >
>>>> > > Interestingly, installing R from sources does not cause the issue.
>>>> > > When using other OS (e.g. Arch) on the same infrastructure, the
>>>> problem
>>>> > > also disappears.
>>>> > >
>>>> > > We are looking for a way out that would allow users to install R
>>>> packages
>>>> > > as usual and that would ideally not force the admin to install R
>>>> from
>>>> > > sources.
>>>> > >
>>>> > > The issue should be reproducible as follows:
>>>> > >
>>>> > > 1. Mount the share:
>>>> > >
>>>> > > $ mount -t cifs //server/share /mnt/share -o ...options...
>>>> > >
>>>> > > 2. Put R library onto the share:
>>>> > >
>>>> > > $ mkdir /mnt/share/R
>>>> > > $ ln -s /mnt/share/R ~/R
>>>> > >
>>>> > > 3. Install a package that has dependencies (It doesn't matter
>>>> whether the
>>>> > > dependencies actually have to be installed or not. E.g. i

Re: [R-sig-Fedora] Problem with R, staged installation for packages, and samba share

[Tom Callaway]

Okay, so if it's not SELinux... perhaps something about how R is being
configured is different?

Can you provide a log of the output (including the commandline with any
options passed) for configure?

Also, can you provide the specific mount options for the cifs share?

~spot

On Mon, Jun 12, 2023 at 9:12 AM Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> Thanks for the tip but nope: SELinux is off on that system...
>
> On Mon, 12 Jun 2023 at 13:24, Iñaki Ucar  wrote:
>
>> On Mon, 12 Jun 2023 at 13:19, Tom Callaway  wrote:
>> >
>> > Hmm, that's a weird one. Is SELinux on and enforcing on that setup?
>>
>> I was going to bet on the same thing. :) But let me add: if the answer
>> is affirmative, and this doesn't happen with SELinux disabled, then
>> *the answer is NOT to disable SELinux*. Instead, let's figure this
>> out, because the answer is to set the proper labels or permissions.
>>
>> Iñaki
>>
>> >
>> > ~spot
>> >
>> > On Mon, Jun 12, 2023, 6:55 AM Alexandre Courtiol <
>> > alexandre.court...@gmail.com> wrote:
>> >
>> > > Dear Fedora-R enthusiasts,
>> > >
>> > > We are experiencing some issues with the binary releases of R 4.3 for
>> > > Fedora 37 & 38 when running it on our infrastructure.
>> > >
>> > > The issue is that packages won't install, unless the (default) staged
>> > > installation process for packages is switched off
>> (--no-staged-install).
>> > >
>> > > It seems to be related to the fact that we are storing R libraries on
>> a
>> > > drive mounted via samba share.
>> > >
>> > > Interestingly, installing R from sources does not cause the issue.
>> > > When using other OS (e.g. Arch) on the same infrastructure, the
>> problem
>> > > also disappears.
>> > >
>> > > We are looking for a way out that would allow users to install R
>> packages
>> > > as usual and that would ideally not force the admin to install R from
>> > > sources.
>> > >
>> > > The issue should be reproducible as follows:
>> > >
>> > > 1. Mount the share:
>> > >
>> > > $ mount -t cifs //server/share /mnt/share -o ...options...
>> > >
>> > > 2. Put R library onto the share:
>> > >
>> > > $ mkdir /mnt/share/R
>> > > $ ln -s /mnt/share/R ~/R
>> > >
>> > > 3. Install a package that has dependencies (It doesn't matter whether
>> the
>> > > dependencies actually have to be installed or not. E.g. if you
>> install all
>> > > of the dependencies of 'dplyr' and then install 'dplyr' itself in an
>> extra
>> > > call to 'install.packages', the problem will still be triggered.):
>> > >
>> > > $ Rscript -e "install.packages('dplyr', repos='
>> https://cloud.r-project.org
>> > > ')"
>> > >
>> > > 4. The installation will fail while trying to move the package to its
>> final
>> > > location:
>> > >
>> > > mv: cannot move
>> > >
>> '/mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/00LOCK-dplyr/00new/dplyr'
>> > > to '/mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/dplyr':
>> Permission
>> > > denied
>> > > ERROR:   moving to final location failed
>> > >
>> > > 5. Moving the folder as described in the error manually from the shell
>> > > succeeds:
>> > >
>> > > $ mv
>> > >
>> /mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/00LOCK-dplyr/00new/dplyr
>> > > /mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/dplyr
>> > > $ # => works
>> > >
>> > > And if R is either compiled from source (taking the usual
>> > > "configure/make/make install" route) or installed from Conda, the
>> > > permission error at step 4 doesn't happen. We also tested creating the
>> > > binary RPM package on the same machine, and the result was the same as
>> > > installing the binary package from the repo (i.e. error).
>> > >
>> > > ++
>> > >
>> > >
>> > > --
>> > > Alexandre Courtiol, www.datazoogang.de
>> > >
>> > > [[alternative HTML version deleted]]
>> > >
>> > > ___
>> > > R-SIG-Fedora mailing list
>> > > R-SIG-Fedora@r-project.org
>> > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>> > >
>> >
>> > [[alternative HTML version deleted]]
>> >
>> > ___
>> > R-SIG-Fedora mailing list
>> > R-SIG-Fedora@r-project.org
>> > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>>
>>
>>
>> --
>> Iñaki Úcar
>>
>
>
> --
> Alexandre Courtiol, www.datazoogang.de
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Problem with R, staged installation for packages, and samba share

[Tom Callaway]

Hmm, that's a weird one. Is SELinux on and enforcing on that setup?

~spot

On Mon, Jun 12, 2023, 6:55 AM Alexandre Courtiol <
alexandre.court...@gmail.com> wrote:

> Dear Fedora-R enthusiasts,
>
> We are experiencing some issues with the binary releases of R 4.3 for
> Fedora 37 & 38 when running it on our infrastructure.
>
> The issue is that packages won't install, unless the (default) staged
> installation process for packages is switched off  (--no-staged-install).
>
> It seems to be related to the fact that we are storing R libraries on a
> drive mounted via samba share.
>
> Interestingly, installing R from sources does not cause the issue.
> When using other OS (e.g. Arch) on the same infrastructure, the problem
> also disappears.
>
> We are looking for a way out that would allow users to install R packages
> as usual and that would ideally not force the admin to install R from
> sources.
>
> The issue should be reproducible as follows:
>
> 1. Mount the share:
>
> $ mount -t cifs //server/share /mnt/share -o ...options...
>
> 2. Put R library onto the share:
>
> $ mkdir /mnt/share/R
> $ ln -s /mnt/share/R ~/R
>
> 3. Install a package that has dependencies (It doesn't matter whether the
> dependencies actually have to be installed or not. E.g. if you install all
> of the dependencies of 'dplyr' and then install 'dplyr' itself in an extra
> call to 'install.packages', the problem will still be triggered.):
>
> $ Rscript -e "install.packages('dplyr', repos='https://cloud.r-project.org
> ')"
>
> 4. The installation will fail while trying to move the package to its final
> location:
>
> mv: cannot move
> '/mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/00LOCK-dplyr/00new/dplyr'
> to '/mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/dplyr': Permission
> denied
> ERROR:   moving to final location failed
>
> 5. Moving the folder as described in the error manually from the shell
> succeeds:
>
> $ mv
> /mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/00LOCK-dplyr/00new/dplyr
> /mnt/share/R/x86_64-redhat-linux-gnu-library/4.3/dplyr
> $ # => works
>
> And if R is either compiled from source (taking the usual
> "configure/make/make install" route) or installed from Conda, the
> permission error at step 4 doesn't happen. We also tested creating the
> binary RPM package on the same machine, and the result was the same as
> installing the binary package from the repo (i.e. error).
>
> ++
>
>
> --
> Alexandre Courtiol, www.datazoogang.de
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

[R-sig-Fedora] New deps for R-gh

[Tom Callaway]

Hi friends,

R-gh's latest version grew a dependency on httr2 (which has a suggests for
%check on docopt), so I made two new packages for Fedora. They're both
noarch and simple, should be quick reviews for someone. Any help here is
appreciated.

R-docopt: https://bugzilla.redhat.com/show_bug.cgi?id=2176170
R-httr2: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2176171

Thanks in advance,
~spot

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Installing R from source in Fedora -- "minimal package list"

[Tom Callaway]

The Requires on R-core-devel are not in any way intended to prep an
environment to build R (they are intended to provide the minimum
requirements for the R header files to work).

To do what you want, your best bet is to pull down the R.spec file:
https://src.fedoraproject.org/rpms/R/raw/rawhide/f/R.spec

Then, use the "builddep" plug-in from dnf to install the BuildRequires:
dnf builddep R.spec

~spot

On Mon, Nov 7, 2022, 8:26 AM Martin Maechler 
wrote:

> As R Develeoper, I've tried to install R in a fedora podman
> container, starting from plain fedora
>
> dnf install R-core-devel
> dnf install emacs-ess
> dnf install subversion
>
> cd /usr/local
> mkdir -p .../R
> cd   .../R
> svn checkout https://svn.r-project.org/R/trunk R-devel
> mkdir -p inst/R-devel
> cd inst/R-devel/
> ../../R-devel/configure
>
> and then it's telling me I will not have readline, so I stop
>
> and do
>
> dnf install libreadline-devel
>
> but then X11 libraries/headers are missing etc.
>
> -
>
> I had hoped that   the R-core-devel   would already provide me
> with what I needed.
>
> Is there a list of such things to easily add to my list to add
> after starting to run podman in a "base fedora" ?
>
> {I'd be glad to be CC'ed as I'm not subscribed to R-SIG-Fedora}
>
> Thank you in advance,
> Martin
>
> --
> Martin Maechler
> ETH Zurich   and   R core team
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] dependencies for building R

[Tom Callaway]

sudo dnf --enablerepo="*-source" builddep R

This will look at the Fedora R source package (from the Fedora source
repositories, normally disabled) and install all the BuildRequires it
specifies.

I can't remember off hand if the "builddep" plug-in automatically enables
the source repos these days, so that bit might be a no-op, but it's not
harmful.

~spot

P.S. I assume you have a solid reason to build your own, but if you would
like to see changes to the Fedora R package, my inbox is always open. :)

On Fri, Jan 7, 2022, 12:42 AM Jim Lemon  wrote:

> Hi,
> I am once again trying to install the necessary dependencies for
> building R on a new installation of Fedora 35. Is there any easier way
> to do this than running ./configure many times and plugging the holes
> one by one?
>
> Jim
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?

[Tom Callaway]

FWIW, I just built R-testthat-3.0.3 in rawhide.

As far as the R-* packages in the repos, they are either an R package that
someone wanted in Fedora at some point (10%), a package that needed some
love to build in Fedora, either because it is old or Fedora is too new
(5%), BioConductor bits (10%), or dependencies (75%). I am kidding a bit on
that last number, but dependency creep in R is a real thing.

Since Fedora's R-testthat has a patch for the bundled catch, there is value
in having it in Fedora rather than just having people try (and fail) to
build from CRAN. The good news is that if testthat upstream pulls a newer
copy of catch into it, it should pickup the fix, and this issue will
hopefully go away over time.

~spot


On Wed, Jun 23, 2021 at 12:29 PM Gavin Simpson  wrote:

> Thanks Iñaki! toolbox looks really useful for my usecase.
>
> I'm hitting a related issue in that some R-* packages are not up-to-date
> with their CRAN versions (especially testthat, which won't compile on
> F35/rawhide because of a problem in catch that is bundled with testhat and
> something that has changed in the compiler versions in rawhide. So now I'm
> still stuck as I can't install the latest version of vdiffr (which I need
> for R 4.1) as it needs 3.0.3 of testthat.
>
> I'm also a little unclear why there are so many R-* packages in the repos
> now? And how these relate to your COPR-based initiative to provide fedora
> packages for all of CRAN.
>
> I suspect I'm hitting all the issues that Tom and you and others are
> having to deal with in the course of your packaging R packages for fedora,
> but as until recently I just compiled R myself I'm a little unsure what is
> the best/recommended strategy for installing R packages etc on Fedora? Use
> the main repo packages, your COPR, something else? Is there an overview,
> road map or plan somewhere that outlines this and/or what the recommended
> route is?
>
> TIA
>
> G
>
> On Wed, 23 Jun 2021 at 15:45, Iñaki Ucar  wrote:
>
>> On Wed, 23 Jun 2021 at 14:50, Gavin Simpson  wrote:
>> >
>> > How would one go about installing R 4.1 from rawhide? (October is a
>> little too far away to be off r-release for that long while maintaining R
>> packages on CRAN that depend on tidyverse packages.)
>>
>> $ sudo dnf update R --release rawhide
>>
>> should do. Be aware though that this means updating other dependencies
>> too. This may or may not cause problems. A safer option would be to
>> use a containerized environment. Toolbox [1, 2] is perfect for this,
>> especially for development purposes:
>>
>> $ sudo dnf install toolbox
>> $ toolbox enter -r 35
>> [toolbox]$ sudo dnf install R rstudio-desktop
>> [toolbox]$ rstudio
>> # rstudio opens
>>
>> or directly without entering the toolbox first:
>>
>> $ toolbox run -r 35 rstudio
>> # rstudio opens
>>
>> Remember to install any additional repos and/or system dependencies
>> you may need (e.g., to install R packages from source) *inside* your
>> toolbox. Hope it helps.
>>
>> [1] https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/
>> [2] https://fedoramagazine.org/a-quick-introduction-to-toolbox-on-fedora/
>>
>> Iñaki
>>
>> >
>> > TIA
>> >
>> > Gavin
>> >
>> > On Fri, 18 Jun 2021 at 14:21, Tom Callaway  wrote:
>> >>
>> >> I don't think so. If Fedora 34 users want R 4.1, they can install it
>> from
>> >> rawhide.
>> >>
>> >> Or someone that isn't me can spend another two weeks doing it. :)
>> >>
>> >> ~spot
>> >>
>> >> On Fri, Jun 18, 2021, 6:50 AM Iñaki Ucar 
>> wrote:
>> >>
>> >> > Nice! Plans for F34? :))
>> >> >
>> >> > On Fri, 18 Jun 2021 at 00:45, Tom Callaway  wrote:
>> >> > >
>> >> > > The R 4.1 rawhide rebuild is complete, and waiting for bodhi to
>> push it:
>> >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-e7a89430cd
>> >> > >
>> >> > > ~spot
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Iñaki Úcar
>> >> >
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> ___
>> >> R-SIG-Fedora mailing list
>> >> R-SIG-Fedora@r-project.org
>> >> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>> >
>> >
>> >
>> > --
>> > Gavin Simpson, Ph

Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?

[Tom Callaway]

I don't think so. If Fedora 34 users want R 4.1, they can install it from
rawhide.

Or someone that isn't me can spend another two weeks doing it. :)

~spot

On Fri, Jun 18, 2021, 6:50 AM Iñaki Ucar  wrote:

> Nice! Plans for F34? :))
>
> On Fri, 18 Jun 2021 at 00:45, Tom Callaway  wrote:
> >
> > The R 4.1 rawhide rebuild is complete, and waiting for bodhi to push it:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-e7a89430cd
> >
> > ~spot
>
>
>
> --
> Iñaki Úcar
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?

[Tom Callaway]

The R 4.1 rawhide rebuild is complete, and waiting for bodhi to push it:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-e7a89430cd

~spot

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

[R-sig-Fedora] Fwd: new packages needed

[Tom Callaway]

because it is already one of those days and i didn't hit reply all. :/

~spot

-- Forwarded message -
From: Tom Callaway 
Date: Wed, Jun 16, 2021 at 10:02 AM
Subject: Re: [R-sig-Fedora] new packages needed
To: Iñaki Ucar 


shiny (not covr, that was my brain spitting out the wrong thing) imports it
though.

~spot

On Wed, Jun 16, 2021 at 9:54 AM Iñaki Ucar  wrote:

> On Wed, 16 Jun 2021 at 15:48, Tom Callaway  wrote:
> >
> > Hi friends,
> >
> > As the 4.1.0 rebuild progresses, I've identified one set of new
> > dependencies that several packages (DT, covr) need in order to upgrade:
> >
> > bslib
> >  \sass
> >  \jquerylib
>
> DT just suggests bslib, so it shouldn't be required. I looked at the
> code and bslib functions are not called if this package is not
> present.
>
> Iñaki
>
> > If someone here wanted to package them and get them into Fedora, it would
> > be helpful. I'd be happy to do the review, but I'm reluctant to own more
> > packages right now. :)
> >
> > Thanks,
> > ~spot
> >
> > [[alternative HTML version deleted]]
> >
> > ___
> > R-SIG-Fedora mailing list
> > R-SIG-Fedora@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>
>
> --
> Iñaki Úcar
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

[R-sig-Fedora] new packages needed

[Tom Callaway]

Hi friends,

As the 4.1.0 rebuild progresses, I've identified one set of new
dependencies that several packages (DT, covr) need in order to upgrade:

bslib
 \sass
 \jquerylib

If someone here wanted to package them and get them into Fedora, it would
be helpful. I'd be happy to do the review, but I'm reluctant to own more
packages right now. :)

Thanks,
~spot

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?

[Tom Callaway]

I have started the R 4.1.0 build process in rawhide. The side tag is
f35-build-side-42293.

I'm tracking things using a Google Sheet, if anyone wants access, just let
me know.

~spot

On Sat, Jun 5, 2021 at 4:11 PM Iñaki Ucar  wrote:

> On Sat, 5 Jun 2021 at 20:12, Iñaki Ucar  wrote:
> >
> > I've updated RStudio to 1.4.1717, which supports R 4.1, and builds are
> > underway [2, 3, 4]. This may take a while (s390x didn't even start
> > yet).
>
> Oh, planned outage: https://pagure.io/fedora-infrastructure/issue/9960
>
> --
> Iñaki Úcar
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?

[Tom Callaway]

That is a very good point. Oh well. Anyone want to help generate the build
order? :)

~spot

On Fri, Jun 4, 2021, 3:57 PM Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:

> On Fri., Jun. 4, 2021, 10:08 a.m. Tom Callaway,  wrote:
>
>> Is there a way to know which R components provide graphics drivers? I
>> would
>> really rather not rebuild everything if we do not have to.
>>
>>
> Unless you mean rebuild for testing purposes, because you added the R(ABI)
> = major.minor Provides/Requires, you need to rebuild the world anyway.
>
>
>>
>> ~spot
>>
>> On Sun, May 23, 2021 at 6:28 AM Iñaki Ucar 
>> wrote:
>>
>> > On Sat, 22 May 2021 at 22:18, José Abílio Matos 
>> wrote:
>> > >
>> > > Hi all,
>> > >   what should be our plan for R 4.1 update in Fedora?
>> >
>> > See [1]. The plan is to wait for the next RStudio release and
>> > coordinate updates.
>> >
>> > [1] https://stat.ethz.ch/pipermail/r-sig-fedora/2021-May/000736.html
>> >
>> > >   What are the pitfalls and the changes that we should be aware?
>> >
>> > The NEWS says: "The graphics engine version, R_GE_version, has been
>> > bumped to 14 and so packages that provide graphics devices should be
>> > reinstalled." But anyway, we should do the customary mass rebuild of
>> > packages to avoid other possible incompatibilities and "Package was
>> > built under version 4.0" messages.
>> >
>> > Iñaki
>> >
>> > >   The second semester (with the corresponding induced pandemic chaos)
>> is
>> > > dimming down around here so I have at least time to breath again. :-)
>> > >
>> > >   FWIW I am in no hurry to have 4.1 in Fedora 34, my main interest is
>> to
>> > have
>> > > it in rawhide and later if we find it suitable to backport it to F34.
>> > >
>> > >   FWIW since our last talk Octave (for version 7 at least) is
>> starting by
>> > > default to have the major version in the path for packages. :-)
>> > >
>> > > Best regards,
>> > > --
>> > > José Abílio
>> > > [[alternative HTML version deleted]]
>> > >
>> > > ___
>> > > R-SIG-Fedora mailing list
>> > > R-SIG-Fedora@r-project.org
>> > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>> >
>> >
>> >
>> > --
>> > Iñaki Úcar
>> >
>> > ___
>> > R-SIG-Fedora mailing list
>> > R-SIG-Fedora@r-project.org
>> > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>> >
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> R-SIG-Fedora mailing list
>> R-SIG-Fedora@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?

[Tom Callaway]

Is there a way to know which R components provide graphics drivers? I would
really rather not rebuild everything if we do not have to.

~spot

On Sun, May 23, 2021 at 6:28 AM Iñaki Ucar  wrote:

> On Sat, 22 May 2021 at 22:18, José Abílio Matos  wrote:
> >
> > Hi all,
> >   what should be our plan for R 4.1 update in Fedora?
>
> See [1]. The plan is to wait for the next RStudio release and
> coordinate updates.
>
> [1] https://stat.ethz.ch/pipermail/r-sig-fedora/2021-May/000736.html
>
> >   What are the pitfalls and the changes that we should be aware?
>
> The NEWS says: "The graphics engine version, R_GE_version, has been
> bumped to 14 and so packages that provide graphics devices should be
> reinstalled." But anyway, we should do the customary mass rebuild of
> packages to avoid other possible incompatibilities and "Package was
> built under version 4.0" messages.
>
> Iñaki
>
> >   The second semester (with the corresponding induced pandemic chaos) is
> > dimming down around here so I have at least time to breath again. :-)
> >
> >   FWIW I am in no hurry to have 4.1 in Fedora 34, my main interest is to
> have
> > it in rawhide and later if we find it suitable to backport it to F34.
> >
> >   FWIW since our last talk Octave (for version 7 at least) is starting by
> > default to have the major version in the path for packages. :-)
> >
> > Best regards,
> > --
> > José Abílio
> > [[alternative HTML version deleted]]
> >
> > ___
> > R-SIG-Fedora mailing list
> > R-SIG-Fedora@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>
>
> --
> Iñaki Úcar
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Installing R on CentOS 8

[Tom Callaway]

Best guess, something to do with repo prioritization?

~spot

On Tue, May 25, 2021 at 2:43 PM Roger Bos  wrote:

> FYI: I used wget to download the newer version of openblas and
> openblas-threads.  I was then able to install them and then install R.  Not
> sure why the repo wasn't giving me the latest version, but I am good now.
>
> On Mon, May 24, 2021 at 9:05 PM Roger Bos  wrote:
>
> > I am trying to install R on my CentOS 8 server at work and getting an
> > error message about openblas.  It seems I need
> openblas-0.3.3-5.el.x86_64.
> > I have openblas-0.3.3-2.el8.x86_64.  I have added the EPEL repo and
> enabled
> > PowerTools.  I would like to upgrade my openblas from 0..3.3-2 to
> 0.3.3-5,
> > but I don't know how.  Or I could install a lower version of R that works
> > with 0.3.3-2, but I don't know   Could someone please help me get past
> this
> > error?
> >
> > Thanks in advance, Roger.
> >
> > [RCOAdmin@usd1sapp101 ~]$ sudo yum install R
> > [sudo] password for RCOAdmin:
> > Last metadata expiration check: 0:07:14 ago on Tue 25 May 2021 02:51:46
> AM
> > CEST.
> > Error:
> >  Problem: package R-devel-4.0.5-1.el8.x86_64 requires R-core-devel =
> > 4.0.5-1.el8, but none of the providers can be installed
> >   - package R-4.0.5-1.el8.x86_64 requires R-devel = 4.0.5-1.el8, but none
> > of the providers can be installed
> >   - package R-core-devel-4.0.5-1.el8.x86_64 requires openblas-devel, but
> > none of the providers can be installed
> >   - conflicting requests
> >   - nothing provides openblas(x86-32) = 0.3.3-5.el8 needed by
> > openblas-devel-0.3.3-5.el8.i686
> >   - nothing provides openblas-threads(x86-32) = 0.3.3-5.el8 needed by
> > openblas-devel-0.3.3-5.el8.i686
> >   - nothing provides openblas(x86-64) = 0.3.3-5.el8 needed by
> > openblas-devel-0.3.3-5.el8.x86_64
> >   - nothing provides openblas-threads(x86-64) = 0.3.3-5.el8 needed by
> > openblas-devel-0.3.3-5.el8.x86_64
> > (try to add '--skip-broken' to skip uninstallable packages or '--nobest'
> > to use not only best candidate packages)
> >
> > P.S. I tried --skip-broken and --nobest.  It just skips the packages, so
> I
> > still don't get R installed, so skipping is not an option.
> >
> >
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Normalize latex path

[Tom Callaway]

Seems reasonable.

~spot

On Thu, Feb 4, 2021 at 11:15 AM José Abílio Matos  wrote:

> Hi,
>   due to an unrelated bug report in maxima I found out that some packages
> install latex packages in /usr/share/texmf/tex/latex. Instead of using the
> prefix %{_datadir}/texmf we can use the canonical %_texmf defined by
> texlive.
>
> Is there any objection to change the location to the canonical location?
> Actually if you look into the spec file we are using a symbolic link. As
> far
> as I can see the change is harmless.
>
> Probably the %postun and %posttrans sections can be simplified.
>
> Best regards,
> --
> José Abílio
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Rebuild against FlexiBLAS

[Tom Callaway]

These should all be finished now.

Thanks,
Tom

On Mon, Aug 10, 2020 at 10:05 AM Tom Callaway  wrote:

> I'm on it.
>
> Thanks,
> Tom
>
> On Mon, Aug 10, 2020 at 8:24 AM Iñaki Ucar 
> wrote:
>
>> Hi,
>>
>> R has been built against FlexiBLAS in rawhide [1, 2]. These are the R
>> packages that need to be rebuilt:
>>
>> R-ape-0:5.4-2.fc33.x86_64
>> R-expm-0:0.999.4-7.fc33.x86_64
>> R-gee-0:4.13.20-4.fc33.x86_64
>> R-gss-0:2.2.2-3.fc33.x86_64
>> R-igraph-0:1.2.5-3.fc33.x86_64
>> R-msm-0:1.6.8-5.fc33.x86_64
>> R-preprocessCore-0:1.50.0-4.fc33.x86_64
>> R-qtl-0:1.46.2-4.fc33.x86_64
>> R-quadprog-0:1.5.8-5.fc33.x86_64
>>
>> Could somebody with provenpackager superpowers bump the release and
>> rebuild them, please? Thanks in advance!
>>
>> [1] https://src.fedoraproject.org/rpms/R/pull-request/5
>> [2]
>> https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
>>
>> --
>> Iñaki Úcar
>>
>> ___
>> R-SIG-Fedora mailing list
>> R-SIG-Fedora@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Rebuild against FlexiBLAS

[Tom Callaway]

I'm on it.

Thanks,
Tom

On Mon, Aug 10, 2020 at 8:24 AM Iñaki Ucar  wrote:

> Hi,
>
> R has been built against FlexiBLAS in rawhide [1, 2]. These are the R
> packages that need to be rebuilt:
>
> R-ape-0:5.4-2.fc33.x86_64
> R-expm-0:0.999.4-7.fc33.x86_64
> R-gee-0:4.13.20-4.fc33.x86_64
> R-gss-0:2.2.2-3.fc33.x86_64
> R-igraph-0:1.2.5-3.fc33.x86_64
> R-msm-0:1.6.8-5.fc33.x86_64
> R-preprocessCore-0:1.50.0-4.fc33.x86_64
> R-qtl-0:1.46.2-4.fc33.x86_64
> R-quadprog-0:1.5.8-5.fc33.x86_64
>
> Could somebody with provenpackager superpowers bump the release and
> rebuild them, please? Thanks in advance!
>
> [1] https://src.fedoraproject.org/rpms/R/pull-request/5
> [2]
> https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
>
> --
> Iñaki Úcar
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Problem with the update to R 4.0.2 in the Fedora users' list

[Tom Callaway]

I'm inclined to agree. Users are expecting that things they install
manually will override the system default (if any).

Tom

On Tue, Jul 21, 2020, 11:39 AM Iñaki Ucar  wrote:

> On Tue, 21 Jul 2020 at 17:17, José Abílio Matos  wrote:
> >
> > There was a thread this weekend in the fedora users' mailing list where
> a user
> > had problems updating R 4.0.2:
> >
> > "non-rpm R libraries not accessible now w R v 4.0.x"
> >
> https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/
> > thread/2FFST3GWZCNM45SX53VKB255TO4LOV4C/
>
> I don't follow that list, but I see you have everything under control,
> thanks.
>
> > TLDR; as far as I can see the user had installed (as root) a package
> from cran
> > and had installed the same package (R-here) from the Fedora repositories.
> >
> > Since the package were installed in different locations the package
> installed
> > by the user appeared first and thus it won regarding the Fedora package.
> The
> > only problem was that the other package was installed using R 3.6 and
> thus the
> > user had the warning that seemed confusing.
> >
> > Are there any kind of tools to pick these cases or this is one of those
> corner
> > cases that are not worth the trouble?
>
> IMO it's not worth the trouble. Users should never install packages as
> root. That's it. This may sound harsh, but, if they do, then they
> should know what they're doing, and it's their problem. This is like
> the seals on the screws of an electronic device: we ship one
> configuration that works; we simply cannot foresee the countless ways
> to break it once you start tinkering with it. :)
>
> --
> Iñaki Úcar
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R package RPMs for Fedora

[Tom Callaway]

Nice work.

Tom

On Tue, Jul 7, 2020, 9:05 AM Iñaki Ucar  wrote:

> FYI, the CRAN page has been updated. Now, we have:
>
> https://cran.r-project.org/bin/linux/fedora
> https://cran.r-project.org/bin/linux/redhat
>
> The second one is just a symlink to the first one.
>
> Iñaki
>
>
> On Mon, 4 May 2020 at 15:14, Iñaki Ucar  wrote:
> >
> > Hi all,
> >
> > Three months ago, I wrote to Martyn Plummer (to his Warwick email) and
> > offered my help to maintain and modernize this [1] rather updated
> > README, but received no response. Does anyone know how to reach him,
> > or maybe I should contact CRAN directly?
> >
> > [1] https://cran.r-project.org/bin/linux/redhat/README
> >
> > Regards,
> > --
> > Iñaki Úcar
>
>
>
> --
> Iñaki Úcar
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0 rebuild status

[Tom Callaway]

R-BiocFileCache is now branched for f32 (finally). You should be able to
build it if/when the PDC comes back up. Lotta random outages right now.

Tom

On Mon, Jul 6, 2020 at 10:40 AM José Abílio Matos  wrote:

> On Tuesday, 9 June 2020 03.40.52 WEST Tom Callaway wrote:
> > Over the last several days, I've been working hard to get all of the
> Fedora
> > R packages rebuilt against R 4.0 in rawhide (in the F33-R-4 side tag).
> With
> > the exception of R-biomaRt, R-BSgenome, R-GenomicAlignments, and
> > R-rtracklayer, I believe everything is built and updated to the latest
> > versions. And of those packages, they're all ready to go when Fedora
> > infrastructure is working reliably again (the great datacenter migration
> > has started and I can no longer git push). I'll also push R 4.0.1 into
> the
> > tag when that's possible.
>
> In line with what we discussed here I have the updates for R 4.0.2 ready.
>
> The exception is R-BiocFileCache and in that line R-biomaRt. They have an
> asterisk in front of them because of that.
>
> The packages that were rebuilt are in the list attached, together with the
> respective build order.
>
> I pushed an update to updates-testing where I disabled the automatic
> push (both karma and time based).
>
> Report problems either here or on bodhi:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-4c0ce71810
>
> Best regards,
> --
> José Abílio
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0 rebuild status

[Tom Callaway]

This work is already complete in rawhide.

Tom

On Thu, Jun 25, 2020, 1:12 PM José Abílio Matos  wrote:

> On Wednesday, 24 June 2020 10.44.14 WEST Iñaki Ucar wrote:
> > Oh, and maybe in this process we could add to all packages the
> > requirement on R(ABI) = 4 that Tom implemented.
>
> For that we need to start with rawhide and then change the R-rpm-macros
> package.
>
> Probably it should be enough to change the /usr/lib/rpm/R-deps.R script to
> add
>
> Requires: R(ABI)=4.0
>
> I suggest to continue this as is and then implement that change in rawhide
> and
> bring it back to Fedora 32 as new updates are issued.
>
> What do you think?
> --
> José Abílio
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0 rebuild status

[Tom Callaway]

There are a few of those, but not many.

On Tue, Jun 23, 2020 at 11:31 AM José Abílio Matos  wrote:

> On Tuesday, 23 June 2020 16.10.07 WEST I�aki Ucar wrote:
> > 3) For all packages, either merge master into F32 or just increase the
> > release version and send builds to that side tag *in order*.
>
> The part that worries me is the *in order*. :-)
>
> Do we need to do bootstrap builds that are later replaced by the real
> builds?
>
> Because other than that it is business as usual. :-)
> --
> Jos� Ab�lio
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0 rebuild status

[Tom Callaway]

At this point, I simply don't have the time.

Tom

On Tue, Jun 23, 2020, 6:06 AM Iñaki Ucar  wrote:

> On Tue, 9 Jun 2020 at 10:21, Iñaki Ucar  wrote:
> >
> > > Given the huge amount of builds (and rebuilds) in this process, I am
> > > strongly disinclined to attempt this work for Fedora 32 (the idea of
> > > hundreds of bodhi overrides does not fill me with joy), but I would not
> > > prevent someone else who wished to try to do so.
> >
> > Note that this is no longer needed. It is possible to use a side tag
> > for F32 too, which is much easier and more appropriate for a massive
> > update like this.
>
> Any plan on doing this in a side tag for F32? I would happily
> volunteer, but I'm not a provenpackager.
>
> --
> Iñaki Úcar
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0

[Tom Callaway]

Okay, I'm convinced.

https://github.com/rpm-software-management/R-rpm-macros/pull/1

Thanks,
Tom

On Mon, May 11, 2020 at 11:48 AM Iñaki Ucar  wrote:

> On Mon, 11 May 2020 at 16:29, Tom Callaway  wrote:
> >
> > Hmmm. That seems like a rather heavy dependency, given that I think we've
> > only been forced to do rebuilds for everything as a result of 4.0.0 and
> > 3.4.0.
>
> That's just coincidence, because if you browse old NEWS, you can see
> "packages [doing this or that] need to be re(-)installed" here and
> there if most minor versions: maybe there wasn't any of such packages
> in Fedora, maybe a mass rebuild or an update fixed the issue before
> anyone noticed... It's just that we don't have any mechanism to detect
> that unless a user complains.
>
> > Does anyone know if upstream has any sort of commitment to ABI here that
> we
> > could depend on (e.g. only breaking on major versions, never minor) ?
>
> AFAIK, there's this commitment only for patch versions. In fact, the
> path for the personal library is:
>
> ~/R/x86_64-redhat-linux-gnu-library/./
>
> so, when you install a new minor version, you don't have any package
> in your personal library. Most of the time, for many packages, it just
> works if you copy the old packages into the new folder, but many times
> things break and reinstallation is needed. And this may happen for
> compiled packages, but also for non-compiled ones (e.g.: "Packages
> defining S4 classes with the above S3/S4 classes as slots should be
> reinstalled", in R 3.3.0).
>
> So maybe we should streamline mass rebuild of R packages, and do it
> for all minor updates. The virtual provide you proposed will force us
> to do that, and will prevent breakages and complaints.
>
> --
> Iñaki Úcar
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0

[Tom Callaway]

Hmmm. That seems like a rather heavy dependency, given that I think we've
only been forced to do rebuilds for everything as a result of 4.0.0 and
3.4.0.

Does anyone know if upstream has any sort of commitment to ABI here that we
could depend on (e.g. only breaking on major versions, never minor) ?

Tom

On Sat, May 9, 2020 at 5:32 AM Iñaki Ucar  wrote:

> On Sat, 9 May 2020 at 05:46, Tom Callaway  wrote:
> >
> > Thinking out loud here... do we want to have some macro magic to embed a
> > dependency on an R(ABI) provides? Where R 4.0.0 would provide R(ABI) = 4
> > and all R packages built against it would pick up Requires: R(ABI) = 4 ?
>
> Note that recompilation is sometimes required too for minor version
> changes, so the virtual provides should include the minor version to
> be in the safe side.
>
> > I don't suppose we need it, since the likelihood of someone installing R
> > module packages but not updating R is low, but I wanted to throw it out
> > there.
>
> Or updating R and not updating R packages. Even if the chances are
> low, I think it's a cheap thing to add and would make the installation
> more robust to this kind of issue.
>
> --
> Iñaki Úcar
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 4.0.0

[Tom Callaway]

Thinking out loud here... do we want to have some macro magic to embed a
dependency on an R(ABI) provides? Where R 4.0.0 would provide R(ABI) = 4
and all R packages built against it would pick up Requires: R(ABI) = 4 ?
I don't suppose we need it, since the likelihood of someone installing R
module packages but not updating R is low, but I wanted to throw it out
there.

Tom

On Mon, May 4, 2020 at 3:31 PM Iñaki Ucar  wrote:

> On Mon, 4 May 2020 at 19:15, Tom Callaway  wrote:
> >
> > Hi folks,
> >
> > As expected of a new major release of R, there is a break in
> compatibility
> > for R packages. From the NEWS entry for 4.0.0:
> >
> >Packages need to be (re-)installed under this version (4.0.0) of R.
> >
> > This has two impacts on Fedora/EPEL.
> >
> > 1. Users who update to 4.0.0 will need to rebuild any/all packages
> > installed from CRAN.
> > 2. Fedora/EPEL R packages will need to be rebuilt for 4.0.0.
> >
> > For EPEL, #2 is less impactful (there are not that many R packages in
> EPEL)
> > but for Fedora, this is a pretty big lift.
> >
> > I'm thinking that we'll only push this update to EPEL-8, F32, and
> rawhide,
> > but please, if you have input here, chime in.
>
> I agree. And we patched the symbol issues in v3.6.3 in F31 (please,
> don't forget to trigger a build and an update) thanks to Paul Murrell,
> so we're fine on that front.
>
> I'll have to rebuild 15k packages on the CRAN Copr repo. That's gonna
> be huuuge. :) I'll try to do that while the update is sitting in
> updates-testing and before it's pushed to stable.
>
> Iñaki
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

[R-sig-Fedora] R 4.0.0

[Tom Callaway]

Hi folks,

As expected of a new major release of R, there is a break in compatibility
for R packages. From the NEWS entry for 4.0.0:

   Packages need to be (re-)installed under this version (4.0.0) of R.

This has two impacts on Fedora/EPEL.

1. Users who update to 4.0.0 will need to rebuild any/all packages
installed from CRAN.
2. Fedora/EPEL R packages will need to be rebuilt for 4.0.0.

For EPEL, #2 is less impactful (there are not that many R packages in EPEL)
but for Fedora, this is a pretty big lift.

I'm thinking that we'll only push this update to EPEL-8, F32, and rawhide,
but please, if you have input here, chime in.

Thanks,
Tom

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R package RPMs for Fedora

[Tom Callaway]

Thanks Marc. We appreciate it.

Tom

On Mon, May 4, 2020 at 10:28 AM Marc Schwartz  wrote:

> Hi Iñaki,
>
> I don't want to presume to speak for Martyn, but do know from R Foundation
> interactions, that between his move back to the UK and other things, he has
> been very busy.
>
> I am copying him here, and hopefully as his schedule permits, he can
> respond.
>
> Regards,
>
> Marc Schwartz
>
>
> > On May 4, 2020, at 9:14 AM, Iñaki Ucar  wrote:
> >
> > Hi all,
> >
> > Three months ago, I wrote to Martyn Plummer (to his Warwick email) and
> > offered my help to maintain and modernize this [1] rather updated
> > README, but received no response. Does anyone know how to reach him,
> > or maybe I should contact CRAN directly?
> >
> > [1] https://cran.r-project.org/bin/linux/redhat/README
> >
> > Regards,
> > --
> > Iñaki Úcar
> >
> > ___
> > R-SIG-Fedora mailing list
> > R-SIG-Fedora@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] CentOS 7 issues with pdf manual / tex conversion

[Tom Callaway]

On 05/29/2018 04:53 PM, Dirk Eddelbuettel wrote:
> I noticed it with a local, not-public package -- but it appears to apply with
> any source package. I replicated with pkgKitten straight off CRAN and after
> checking that it has a six page manual there.

I'm having trouble reproducing this one. In my fresh CentOS 7 VM, I can
pull the pkgKitten source down, and run R CMD Rd2pdf pkgKitten without
issue:

[spot@localhost ~]$ tar xf pkgKitten_0.1.4.tar.gz
[spot@localhost ~]$ R CMD Rd2pdf pkgKitten
Hmm ... looks like a package
Converting Rd files to LaTeX
Creating pdf output from LaTeX ...

This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013)
 restricted \write18 enabled.
entering extended mode
LaTeX2e <2011/06/27>
Babel  and hyphenation patterns for english, dumylang,
nohyphenation, lo
aded.
(./Rd2.tex (/usr/share/texlive/texmf-dist/tex/latex/base/book.cls
Document Class: book 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/bk10.clo))
(/usr/share/R/texmf/tex/latex/Rd.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/bm.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/alltt.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tools/verbatim.sty)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def))
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def))
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/times.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/color.sty
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/pdftex-def/pdftex.def
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/auxhook.sty)
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def)
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/hyperref.cfg))

Package hyperref Message: Driver (autodetected): hpdftex.

(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))

Package hyperref Warning: Option `hyperindex' has already been used,
(hyperref)setting the option has no effect on input line
366.


Package hyperref Warning: Option `pagebackref' has already been used,
(hyperref)setting the option has no effect on input line
366.

) (/usr/share/texlive/texmf-dist/tex/latex/base/makeidx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.dfu)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.dfu)
(/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.dfu)
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.dfu))
(/usr/share/texlive/texmf-dist/tex/latex/base/latin1.def))
Writing index file Rd2.idx
No file Rd2.aux.
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ptm.fd)
(/usr/share/texlive/texmf-dist/tex/context/base/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1pcr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1phv.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def)
[1{/usr/share/texlive/t
exmf/fonts/map/pdftex/updmap/pdftex.map}]
Overfull \hbox (0.78088pt too wide) in paragraph at lines 65--65
 []\T1/pcr/m/n/10 kitten(name = "anRpackage", path = ".", author,
maintainer, e
mail,[]
(/usr/share/texlive/texmf-dist/tex/latex/base/utf8.def) [2]
No file Rd2.ind.
[3] (./Rd2.aux)

Package rerunfilecheck Warning: File `Rd2.out' has changed.
(rerunfilecheck)Rerun to get outlines right
(rerunfilecheck)or use package `bookmark'.

 )
(see the transcript file for additional information)pdfTeX warning
(dest): name
{Rfn.email.Rul.address} has been referenced but does not exist, replaced
by a f
ixed one

pdfTeX warning (dest): name{Rfn.fullname} has been referenced but does
not exis
t, replaced by a fixed one

pdfTeX warning (dest): 

Re: [R-sig-Fedora] Cannot install broom package

[Tom Callaway]

On 03/22/2018 05:11 PM, xb...@posteo.de wrote:
> Hello,
> 
> I've problems installing several packages in my R on Fedora 27 64 bit. I
> found out that it has to do something with a missing  compiler
> (libgfortran.so.3, see below).
> It works if I downgrade the current version of libgfortran to the
> specified version by downloading libgfortran-6.2.1-2.fc25.x86_64.rpm and
> manually installing it.
> However, I don't want to mess up my system, because the current version
> of libgfortran is replaced by it.
> 
> Is there any other solution to my problem? Can I use e.g. "broom" (see
> below) without having to downgrade libgfortran?
> 
> Thanks! Cheers
> Hans
> 
> 
> 
>> install.packages("broom")
> Installing package into ‘/home/hans/R/x86_64-redhat-linux-gnu-library/3.4’
> (as ‘lib’ is unspecified)
> versuche URL 'https://cran.rstudio.com/src/contrib/broom_0.4.3.tar.gz'
> Content type 'application/x-gzip' length 1397648 bytes (1.3 MB)
> ==
> downloaded 1.3 MB
> 
> * installing *source* package ‘broom’ ...
> ** Paket ‘broom’ erfolgreich entpackt und MD5 Summen überprüft
> ** R
> ** inst
> ** preparing package for lazy loading
> Error : .onLoad failed in loadNamespace() for 'mnormt', details:
>   call: dyn.load(file, DLLpath = DLLpath, ...)
>   error: kann shared object
> '/home/hans/R/x86_64-redhat-linux-gnu-library/3.4/mnormt/libs/mnormt.so'
> nicht laden:
>   libgfortran.so.3: cannot open shared object file: No such file or
> directory

The error above usually occurs when you build a module from CRAN (in
this case, mnormt) at one point in time, then upgrade Fedora. Because
modules built from source and installed via CRAN tools aren't tracked by
Fedora, Fedora doesn't realize that upgrading libgfortran will break them.

I believe the fix should be as simple as running (in R):

install.packages('mnormt')

This should built it again from source, and link the module against the
current libgfortran library, replacing the copy that you'd built before.
It may result in a newer build of mnormt getting installed, so be aware.

hth,

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Cannot install igraph package

[Tom Callaway]

On 10/09/2017 11:16 AM, Paul Smith wrote:
> Dear All,
> 
> I am trying to install
> 
> igraph package
> 
> but getting the following error:
> 
> --
> make: *** [/usr/lib64/R/etc/Makeconf:159: foreign-graphml.o] Error 1
> ERROR: compilation failed for package ‘igraph’
> * removing ‘/usr/lib64/R/library/igraph’
> --
> 
> Any ideas?

Need to see a lot more logs, specifically, the items before that Error
occurs.

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] No rule to make target all.R, needed by compiler.rdb building R 3.4.1 from source, Scientific Linux release 6.9 (Carbon)

[Tom Callaway]

No, not R's configure, PCRE's configure. The PCRE library that you've built
is missing some functionality.

~tom

On Aug 23, 2017 7:53 PM, "Jaime Alvarez Benayas" <
jalvarezbenay...@sheffield.ac.uk> wrote:

> Hello,
>
> Thanks again. I have checked the configure step, the only messages I get
> containing pcre are:
>
> checking for pcre_fullinfo in -lpcre... yes
> checking pcre.h usability... yes
> checking pcre.h presence... yes
> checking for pcre.h... yes
> checking pcre/pcre.h usability... no
> checking pcre/pcre.h presence... no
> checking for pcre/pcre.h... no
> checking if PCRE version >= 8.20, < 10.0 and has UTF-8 support... yes
> checking if PCRE version >= 8.32... yes
> checking whether PCRE support suffices... yes
>
>
> The final status from the command:
>
> R is now configured for x86_64-pc-linux-gnu
>
>   Source directory:  .
>   Installation directory:/fastdata/mbp15ja/R-3.4.1
>
>   C compiler:gcc  -I/usr/local/packages6/
> compilers/gcc/5.4.0/include
>   Fortran 77 compiler:   gfortran  -g -O2
>
>   Default C++ compiler:  g++   -g -O2
>   C++98 compiler:g++  -g -O2
>   C++11 compiler:g++ -std=gnu++11 -g -O2
>   C++14 compiler:g++ -std=gnu++14 -g -O2
>   C++17 compiler:
>   Fortran 90/95 compiler:gfortran -g -O2
>   Obj-C compiler:
>
>   Interfaces supported:  X11, tcltk
>   External libraries:readline, curl
>   Additional capabilities:   PNG, JPEG, NLS, cairo
>   Options enabled:   shared R library, shared BLAS, R profiling
>
>   Capabilities skipped:  TIFF, ICU
>   Options not enabled:   memory profiling
>
>   Recommended packages:  yes
>
>
>
> I haven't seen the JIT message but will give a try at the glibc-devel:
>
>
> Here is the whole log from the configure command
> https://www.dropbox.com/s/m4g2w1hrr2uqldr/configure%20result%20R.txt?dl=0
>
>
>
> -Original Message-
> From: Tom Callaway [mailto:tcall...@redhat.com]
> Sent: miércoles, 23 de agosto de 2017 21:48
> To: Jaime Alvarez Benayas <jalvarezbenay...@sheffield.ac.uk>;
> r-sig-fedora@r-project.org
> Subject: Re: [R-sig-Fedora] No rule to make target all.R, needed by
> compiler.rdb building R 3.4.1 from source, Scientific Linux release 6.9
> (Carbon)
>
>
>
> On 08/23/2017 03:58 PM, Jaime Alvarez Benayas wrote:
> > ../../lib/libR.so: undefined reference to `pcre_assign_jit_stack'
> > ../../lib/libR.so: undefined reference to `pcre_jit_stack_alloc'
> > ../../lib/libR.so: undefined reference to `pcre_free_study'
>
> This is the error. Your PCRE is being built with SUPPORT_JIT undefined.
>
> You should see some warning during the configure phase for PCRE that says
> "JIT support requires pthreads" or something like that. You should get that
> from glibc-devel.
>
> ~tom
>
>
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] No rule to make target all.R, needed by compiler.rdb building R 3.4.1 from source, Scientific Linux release 6.9 (Carbon)

[Tom Callaway]

On 08/23/2017 03:58 PM, Jaime Alvarez Benayas wrote:
> ../../lib/libR.so: undefined reference to `pcre_assign_jit_stack'
> ../../lib/libR.so: undefined reference to `pcre_jit_stack_alloc'
> ../../lib/libR.so: undefined reference to `pcre_free_study'

This is the error. Your PCRE is being built with SUPPORT_JIT undefined.

You should see some warning during the configure phase for PCRE that
says "JIT support requires pthreads" or something like that. You should
get that from glibc-devel.

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] No rule to make target all.R, needed by compiler.rdb building R 3.4.1 from source, Scientific Linux release 6.9 (Carbon)

[Tom Callaway]

On 08/18/2017 01:12 PM, Jaime Alvarez Benayas wrote:
> Hello,
> 
> I am trying to build R from source on Scientific Linux release 6.9
> (Carbon), Linux version 2.6.32-696.3.2.el6.x86_64 (Red Hat 4.4.7-18).

Okay, so the versions of zlib, bzip2, xz, curl, and pcre are too old on
Scientific Linux 6.9 (unless they've updated all of them when I wasn't
looking). That said, I don't think your problem is there.

Why are you calling make -n instead of just make?

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] No rule to make target all.R, needed by compiler.rdb building R 3.4.1 from source, Scientific Linux release 6.9 (Carbon)

[Tom Callaway]

On 08/18/2017 01:12 PM, Jaime Alvarez Benayas wrote:
> Hello,
> 
> I am trying to build R from source on Scientific Linux release 6.9
> (Carbon), Linux version 2.6.32-696.3.2.el6.x86_64 (Red Hat 4.4.7-18).

Before debugging this too far, is there a reason you're building from
source as opposed to using the R prebuilt packages in EPEL?

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Getting R to work with Fedora 26

[Tom Callaway]

On 08/02/2017 03:09 PM, Jeff Trefftzs wrote:
> I just installed Fedora 26 on my laptop, and R now fails to load.  The
> error message is missing libgfortran.so.3.  Does anyone have a fix for
> this?  FC 26 comes with R-3.4.1 as an RPM, but it throws the error, as
> does trying to compile R-3.4.1 from source.

Looking at my Fedora 26 system:

[spot@localhost ~]$ rpm -q R-core
R-core-3.4.1-1.fc26.x86_64

[spot@localhost ~]$ rpm -q R-core --requires |grep libgfortran
libgfortran.so.4()(64bit)
libgfortran.so.4(GFORTRAN_7)(64bit)

I'm not sure how you ended up with an R package that depends on
libgfortran.so.3, unless you have one for an older Fedora. In Fedora 26,
libgfortran.so.4 is provided by libgfortran.

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Installing R 3.4.0 on Red Hat 6

[Tom Callaway]

Hmmm. When I look at the contents of epel-release-latest-6.noarch.rpm, I
see:

/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
/etc/rpm/macros.ghc-srpm
/etc/yum.repos.d/epel-testing.repo
/etc/yum.repos.d/epel.repo
/usr/share/doc/epel-release-6
/usr/share/doc/epel-release-6/GPL

Do you have those .repo files in /etc/yum.repos.d/ ?

~tom


On Fri, Jul 21, 2017 at 11:41 AM, Larry Martell <larry.mart...@gmail.com>
wrote:

> On Fri, Jul 21, 2017 at 11:39 AM, Tom Callaway <tcall...@redhat.com>
> wrote:
> > On 07/21/2017 11:18 AM, Larry Martell wrote:
> >> I am trying to install R 3.4.0 on RHEL6. If I look here is it there:
> >>
> >> http://mirror.sjc02.svwh.net/fedora-epel/6/x86_64/
> >>
> >> I did this:
> >>
> >> sudo subscription-manager repos --enable rhel-6-server-optional-rpms
> >> sudo subscription-manager repos --enable rhel-6-server-extras-rpms
> >> wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-
> 6.noarch.rpm
> >> rpm epel-release-latest-6.noarch.rpm
> >
> > Try this instead:
> >
> > rpm -Uvh epel-release-latest-6.noarch.rpm
>
> That gave me:
>
> package epel-release-6-8.noarch is already installed
>
> > You also may want to install from epel-testing, 3.4.1 is in there.
> >
> > sudo yum --enablerepo=epel-testing install R
>
> That gave me:
>
> Error getting repository data for epel-testing, repository not found
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Installing R 3.4.0 on Red Hat 6

[Tom Callaway]

On 07/21/2017 11:18 AM, Larry Martell wrote:
> I am trying to install R 3.4.0 on RHEL6. If I look here is it there:
>
> http://mirror.sjc02.svwh.net/fedora-epel/6/x86_64/
>
> I did this:
>
> sudo subscription-manager repos --enable rhel-6-server-optional-rpms
> sudo subscription-manager repos --enable rhel-6-server-extras-rpms
> wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
> rpm epel-release-latest-6.noarch.rpm

Try this instead:

rpm -Uvh epel-release-latest-6.noarch.rpm

You also may want to install from epel-testing, 3.4.1 is in there.

sudo yum --enablerepo=epel-testing install R

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Cannot install knitr

[Tom Callaway]

On 06/29/2017 06:04 AM, Paul Smith wrote:
> Dear All,
>
> I am trying to install the package
>
> knitr
>
> but getting the following error:
>
> --
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>   unable to load shared object '/usr/lib64/R/library/stringi/libs/stringi.so':
>   libicui18n.so.56: cannot open shared object file: No such file or directory
> Error : unable to load R code in package ‘knitr’
> ERROR: lazy loading failed for package ‘knitr’
> * removing ‘/usr/lib64/R/library/knitr’
> * restoring previous ‘/usr/lib64/R/library/knitr’
> --
>
> I suppose that the problem is that knitr expects
>
> libicu-56
>
> installed, but it is
>
> libicu-57
>
> that is installed.

Close, but this isn't knitr complaining.
/usr/lib64/R/library/stringi/libs/stringi.so comes from the "stringi"
CRAN module:

https://cran.r-project.org/package=stringi

You might have installed that from source, before updating libicu? You
might not have done this manually, it could have been pulled in as a
dependency of something else. "stringi" does not come with the core R
software, so it wasn't built wrong for Fedora/EPEL. :)

To reinstall it, just invoke (again):

install.packages("stringi")

That should succeed, and then the "stringi" shared object should be able
to load.

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Fail to install xgboost

[Tom Callaway]

On 05/15/2017 10:31 PM, Shu-Ju Tu wrote:
> /dmlc-core/include/dmlc/./base.h:71: note: #pragma message: Will need
> g++-4.6 or higher to compile allthe features in dmlc-core, compile
> without c++0x, some features may be disabled

This is the relevant error. The compiler in RHEL 6 is too old.

~tom

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R 3.4.0 RPMS

[Tom Callaway]

Thanks. I've been traveling almost non stop for the last several months. I
appreciate your help here.

On May 12, 2017 10:25 AM, "José Abílio Matos"  wrote:

> On Thursday, 11 May 2017 17.37.41 WEST Martyn Plummer wrote:
> > Dear Tom,
> >
> > I see that RPMS for R 3.4.0 are not successfully built on Fedora, nor
> > on RHEL 7.
> >
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=1230
> >
> > When I build with mock on Fedora 25 I also get a build failure. R is
> > not able to establish the time zone inside the chroot and this triggers
> > a regression tests which is new in R 3.4.0. Specifically, in file
> > tests/reg-tests-1d.R this test fails:
> >
> > ## PR#17186 - Sys.timezone() on some Debian-derived platforms
> > (S.t <- Sys.timezone())
> > if(is.na(S.t) || !nzchar(S.t)) stop("could not get timezone")
> > ## has been NA_character_  in Ubuntu 14.04.5 LTS
> >
> >
> > The work-around is to set the environment variable TZ to any non-empty
> > string before running make check, in the %check section of the SPEC
> > file, e.g.
> >
> > TZ="Europe/Paris" make check
> >
> > best regards
> > Martyn
>
> Thank you Martyn. :-)
>
> I am rebuilding R bumping the version since the previous version succeeded
> to
> build on el6.
>
> BTW Tom, it is probably time to get rid of the
> %defattr(-, root, root, -)
>
> after we are already in the Spring here in the North hemisphere. :-)
>
> Regards,
> --
> José Abílio
>
> ___
> R-SIG-Fedora mailing list
> R-SIG-Fedora@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
>

[[alternative HTML version deleted]]

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rgl

[Tom Callaway]

On 01/12/2017 08:26 AM, Weiner, Michael wrote:
> EXACTLY!!! I use the NVidia drivers from their site, and that is exactly what 
> happened. I reinstalled mesa-libGL.x86_64 and that resolved the issue (though 
> not sure if that broke anything else on the workstation that relies on the 
> NVidia drivers)

NVIDIA has a fork of libGL that is optimized for their driver. You may
wish to figure out how to replace the mesa-libGL libraries with their
copy. If memory serves, they put their libGL library in a different
directory (then remove the system copy).

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R-3.3.1 RPM release

[Tom Callaway]

Since I've gotten a few off-list replies, I feel like it's worth
pointing out why people are having trouble building R from source on
RHEL/CentOS 5 & 6.

R has always depended on some third party libraries, specifically,
zlib, bzip2, xz, pcre, and curl. Prior to R 3.3.0, R depended on much
older versions of these libraries, but, if they were not found on the
system, they'd use bundled copies that were built on the fly. With
3.3.0+, R now depends on much newer versions of these libraries and no
longer has bundled copies to fall back to.

This means that R 3.3.0+ won't build against RHEL/CentOS 5 or 6 as is,
because all of these libraries are too old on those releases of
RHEL/CentOS. (RHEL/CentOS 7 is new enough, as is all currently supported
releases of Fedora).

Realizing that there are a lot of R users in situations where the
distribution of Linux is out of their control (or who cannot upgrade to
RHEL/CentOS 7 for some reason), I spent a not small amount of time
figuring out how to build static copies of these libraries into R for
EL5/EL6 (and then even more time cleaning the evidence of this work out
of the internals so it didn't inherit into CRAN builds).

That said, you really should consider moving from EL5/6 to EL7. It's nice.

Builds of 3.3.1 are going through koji right now. EL5, EL6, and EL7 are
finished, Fedora 22-24 will be done shortly. Please test and give feedback:

EL5:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-fa43c0f5fa

EL6:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-6add114acf

EL7:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0f6db0c4e2

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

[R-sig-Fedora] Fixed updates for EL5 / EL6

[Tom Callaway]

I know, I know, you've heard this song before... ;)

EL5: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-09c8007e64

EL6: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0a9e4df655

Please go download -8 and test it. It looks good on my end. If it works
for you (with CRAN modules), please give positive karma so it will land
in updates-stable faster than two weeks.

Thanks for your patience,

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] problems compiling packages | 3.3.0 | Linux

[Tom Callaway]

No, that's the correct fix. Another round of new packages will appear later this morning. The libraries it is referencing are linked statically into R, so they are not supposed to be present.
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] problems compiling packages | 3.3.0 | Linux

[Tom Callaway]

On 06/06/2016 05:04 PM, Brian Fallik wrote:
> Apologies if this email is a top post. I'm not sure how to reply to a
> thread if I'm not subscribed.
> 
> We recently encountered the same issue that Evan reported on 6/4 and I can
> confirm that updated to 3.3.0-5 does address the build failure. Will
> 3.3.0-5 make it into EPEL? If so, do you have any idea when? The current
> package is breaking our build process and I'm wondering if it's worth the
> effort to implement a workaround or not.

Yes, this package is going through the update process right now. You can
speed it along by logging into the Fedora Update system and giving
positive karma:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-93778a4eeb

If the build gets +3 karma, it will go to stable immediately.
Otherwise, it takes two weeks to be pushed to stable according to EPEL
policies.

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] problems compiling packages | 3.3.0 | Linux

[Tom Callaway]

On 06/06/2016 10:00 AM, Evan Cooch wrote:
> Thanks very much. I had more or less reached the same conclusions -- I
> was just about to rebuild RPMs for source for zlib, etc, and update
> those, and try again, but I've had mixed success in doing that in past.
> Its easy enough to roll back to 3.2.5 (which compiles perfectly against
> all the CentOS 6.x.x libs), but 3.30 plays nice with a few other things
> I work with. Hence my interest in 3.30.

Yeah. I thought about pulling it all into a separate copr repo with
updated packages, but EL5/6 are fragile as is, without me introducing
major API changes to core libraries. Last thing I need in my life is Red
Hat Support angry at me for breaking people's RHEL boxes. :)

This solution was the best option I could come up with from a list of
bad options.

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rstan warning messages

[Tom Callaway]

On 02/05/2016 09:58 AM, Patrick, Larry B [CSSM] wrote:
> Did the following on my RHEL6 server:
>  [root@ping ~]# export 
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib64/pkgconfig/
>  [root@ping ~]# /usr/bin/curl-config --libs
>  -L/usr/lib64 -lcurl

I'm glad this worked, but you should not have had to specify that. I'd
bet something else is misconfigured on your RHEL 6 system that will
likely cause problems in the future...

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rstan warning messages

[Tom Callaway]

On 02/03/2016 09:52 AM, Tom Callaway wrote:

> Are you trying to build R and components for i686 rather than x86_64?

Never mind. Your logs make it clear that you're building for x86_64.

Can you share the output of:

pkg-config --list-all |grep libcurl
curl-config --libs
rpm -V libcurl-devel libcurl

I'm honestly baffled as to why the configure script is failing to find
libcurl.pc on your system:

  Package libcurl was not found in the pkg-config search path.

  Perhaps you should add the directory containing `libcurl.pc'

  to the PKG_CONFIG_PATH environment variable

  No package 'libcurl' found

Do you have any files installed into /usr/local/ ?

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rstan warning messages

[Tom Callaway]

On 02/03/2016 09:33 AM, Patrick, Larry B [CSSM] wrote:
> I didn't have any libgfortran files in /usr/lib so I did that soft link. 
> Maybe something didn't fully install or configure. I have inherited this 
> machine from another admin and it is not a fresh installation.

So, here's oddity number one:

You're clearly on an x86_64 system, which should store (and look for)
all libraries in /usr/lib64. /usr/lib should only be used for 32bit
libraries.

Are you trying to build R and components for i686 rather than x86_64?

Was R built from source on that system?

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rstan warning messages

[Tom Callaway]

On 02/01/2016 03:45 PM, Patrick, Larry B [CSSM] wrote:
> Got past my libgfortran issue
>  ln -s  /usr/lib64/libgfortran.so.3 /usr/lib/libgfortran.so

Maybe to /usr/lib64/libgfortran.so ? You _should not_ need to do that
though. I didn't need to.

> Now if I could get RCurl and rstan installed.

This one is perplexing. I can't reproduce your failures from my RHEL-6 VM.

Can you provide me the output from:

   rpm -qf /usr/lib64/pkgconfig/libcurl.pc
   rpm -q pkgconfig

Also, if you can run the install.packages again and send me the full
log, that might be helpful.

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] html manual files nonfunctional

[Tom Callaway]

On 01/26/2016 04:43 PM, Tom Callaway wrote:
> On 01/21/2016 10:38 AM, joe cypherpunk wrote:
>> R help.start() opens a web browser as expected, but the “Manual” html links
>> are dead (although the “Reference” and “Miscellaneous Materials” html links
>> do work).  I get a similar problem from within RStudio.
>>
>>
>> I’d like to get pointy-clicky html manuals working, to help migrate users
>> from SAS to R.
>>
>>
>> I do see R manuals on this system from the EPEL R rpm's in info and pdf
>> form, for example at /usr/share/info/R-intro.gz and
>> /usr/share/doc/R-3.2.3/manual/R-intro-pdf
>>
>>
>> I’m running R-3.2.3, installed from EPEL rpm’s on RHEL6.7.
> 
> I see this. This is a consequence of R requiring texinfo 5.1 or newer
> and RHEL6 having texinfo 4.1. I'll bundle in pre-built manuals for those
> cases (RHEL 5 and 6 only).

Please test:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e623c6ffdd

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] html manual files nonfunctional

[Tom Callaway]

On 01/21/2016 10:38 AM, joe cypherpunk wrote:
> R help.start() opens a web browser as expected, but the “Manual” html links
> are dead (although the “Reference” and “Miscellaneous Materials” html links
> do work).  I get a similar problem from within RStudio.
> 
> 
> I’d like to get pointy-clicky html manuals working, to help migrate users
> from SAS to R.
> 
> 
> I do see R manuals on this system from the EPEL R rpm's in info and pdf
> form, for example at /usr/share/info/R-intro.gz and
> /usr/share/doc/R-3.2.3/manual/R-intro-pdf
> 
> 
> I’m running R-3.2.3, installed from EPEL rpm’s on RHEL6.7.

I see this. This is a consequence of R requiring texinfo 5.1 or newer
and RHEL6 having texinfo 4.1. I'll bundle in pre-built manuals for those
cases (RHEL 5 and 6 only).

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] WARNING you cannot build info or html versions of the R manuals

[Tom Callaway]

Ah yes, those. Replace the rpm -Uvh with yum update and it should resolve the 
dependencies for you. If that fails, just pass all of those deps (in "") to yum 
install.

Sorry about that!

On Jan 20, 2016 2:34 AM, Rolf Turner <r.tur...@auckland.ac.nz> wrote:
>
> On 20/01/16 18:31, Tom Callaway wrote: 
>
>  
>
> > Download all of them, except for the src.rpm (and the texinfo-debuginfo 
> > package). 
> > 
> > Then, run: 
> > 
> > sudo rpm -Uvh info-6.0-2.fc17.1.x86_64.rpm 
> > perl-File-ShareDir-Install-0.10-3.fc17.noarch.rpm 
> > perl-Module-Install-AuthorRequires-0.02-10.fc17.noarch.rpm 
> > perl-Module-Install-AuthorTests-0.002-10.fc17.noarch.rpm 
> > perl-Module-Install-ManifestSkip-0.24-4.fc17.noarch.rpm 
> > perl-Module-Install-Repository-0.06-10.fc17.noarch.rpm 
> > perl-Module-Manifest-Skip-0.23-4.fc17.noarch.rpm 
> > perl-Module-Package-0.30-9.fc17.noarch.rpm 
> > perl-Module-Package-Au-2-4.fc17.noarch.rpm 
> > perl-Unicode-EastAsianWidth-1.33-6.fc17.noarch.rpm 
> > texinfo-6.0-2.fc17.1.x86_64.rpm texinfo-tex-6.0-2.fc17.1.x86_64.rpm 
>
> Well, it's the story of my life, but things are still not working.  I 
> followed your instructions (as above) and got: 
>
> > error: Failed dependencies: 
> > perl(Module::Install::Base) is needed by 
> > perl-Module-Install-AuthorRequires-0.02-10.fc17.noarch 
> > perl(Module::Install) is needed by 
> > perl-Module-Install-AuthorTests-0.002-10.fc17.noarch 
> > perl(Module::Install::Base) is needed by 
> > perl-Module-Install-AuthorTests-0.002-10.fc17.noarch 
> > perl(Module::Install::Base) is needed by 
> > perl-Module-Install-ManifestSkip-0.24-4.fc17.noarch 
> > perl(Module::Install::Base) is needed by 
> > perl-Module-Install-Repository-0.06-10.fc17.noarch 
> > perl(File::ShareDir) is needed by 
> > perl-Module-Manifest-Skip-0.23-4.fc17.noarch 
> > perl(Moo) >= 0.091013 is needed by 
> > perl-Module-Manifest-Skip-0.23-4.fc17.noarch 
> > perl(IO::All) >= 0.41 is needed by perl-Module-Package-0.30-9.fc17.noarch 
> > perl(Module::Install) >= 1.01 is needed by 
> > perl-Module-Package-0.30-9.fc17.noarch 
> > perl(Module::Install::Base) is needed by 
> > perl-Module-Package-0.30-9.fc17.noarch 
> > perl(Moo) >= 0.009008 is needed by perl-Module-Package-0.30-9.fc17.noarch 
> > perl(Module::Install::GithubMeta) >= 0.10 is needed by 
> > perl-Module-Package-Au-2-4.fc17.noarch 
> > perl(Module::Install::ReadmeFromPod) >= 0.12 is needed by 
> > perl-Module-Package-Au-2-4.fc17.noarch 
> > perl(Module::Install::ReadmeMarkdownFromPod) >= 0.03 is needed by 
> > perl-Module-Package-Au-2-4.fc17.noarch 
> > perl(Pod::Markdown) >= 1.301 is needed by 
> > perl-Module-Package-Au-2-4.fc17.noarch 
> > perl(Text::Unidecode) is needed by texinfo-6.0-2.fc17.1.x86_64 
>
>
> If there's an easy fix, please tell me.  Otherwise feel free to say "Oh 
> stuff this for a lark!" and carry on with doing useful things instead of 
> worrying about my crap.  I can certainly live without being able to 
> build info and html versions of the R manuals.  I just wanted to 
> eliminate that annoying little glitch if possible, but it's looking like 
> it's too much of a snarl-up to be repaired with a reasonable amount of 
> effort. 
>
> cheers, 
>
> Rolf 
>
> -- 
> Technical Editor ANZJS 
> Department of Statistics 
> University of Auckland 
> Phone: +64-9-373-7599 ext. 88276 
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] WARNING you cannot build info or html versions of the R manuals

[Tom Callaway]

On 01/18/2016 08:50 PM, Rolf Turner wrote:
> Okay; tried this.  The executive summary is:  It didn't work.

I normally would charge a modest fee of a good bottle of liquor or a
six-pack of craft beer for the following lesson, but in the spirit of
easing your suffering, I shall do it once more at no charge. ;)

Let's look at what didn't work.

> In more detail:  I got a sequence of warnings
> 
> warning: group mockbuild does not exist - using root

Yep. This is safe to ignore. What RPM is saying here is that the user
who originally built this package ("mockbuild") isn't on your system.
"mockbuild" is the unprivileged user/group that the Fedora buildsystem
uses to build packages. However, part of that warning is something you
should not ignore:

" - using root".

You should not be building software as root. That path leads to terrible
pain and destruction. When you're ready to install the software you've
built, su to root, but not before.

>> error: Failed build dependencies:
>> help2man is needed by texinfo-6.0-2.fc17.x86_64
>> perl(Locale::Messages) is needed by texinfo-6.0-2.fc17.x86_64
>> perl(Unicode::EastAsianWidth) is needed by texinfo-6.0-2.fc17.x86_64
>> perl(Text::Unidecode) is needed by texinfo-6.0-2.fc17.x86_64

These messages come from RPM and they say "I've checked my database of
packages against what this src RPM says it needs to build and nothing
provides these". RPM isn't psychic. It only knows about packages that
have been installed by RPM. Anything you build from source by hand is
not known to it at all. These "perl(Foo::Bar)" dependencies are provided
by perl packages, where Foo::Bar is the CPAN module. You can see an
example of this by querying the perl package:

[spot@localhost ~]$ rpm -q perl --provides
perl = 4:5.22.1-355.fc24
perl(AnyDBM_File) = 1.01
perl(AutoLoader) = 5.74
perl(AutoSplit) = 1.06
...

This allows you to say:

yum install "perl(AnyDBM_File)"

And yum will go find the RPM package that Provides: perl(AnyDBM_File)
and install it for you. You don't have to remember the name of the
package, just the CPAN module name.

> Did a sudo yum install help2man which seemed to work. 

> Then searched
> around to try to fathom the perl messages.  Found indications that I
> needed to install perl-libintl-1.20-13.fc21.src.rpm.

Points to you. perl-libintl Provides: perl(Locale::Messages). That
package actually exists in Fedora 17, so you can do:

   sudo yum install "perl(Locale::Messages)"

And it will install it for you. The same is true for
"perl(Text::Unidecode)" but sadly, not for "perl(Unicode::EastAsianWidth)".

> Got that rpm and did
> 
> rpmbuild --rebuild perl-libintl-1.20-13.fc21.src.rpm
> 
> going by analogy and hope.  Something seemed to happen.  Then did

That built the src rpm into binary packages for Fedora 17.

> cd ~/rpmbuild/RPMS/x86_64
> sudo rpm -Uvh perl-libintl-1.20-13.fc17.x86_64.rpm
>   perl-libintl-debuginfo-1.20-13.fc17.x86_64.rpm
> 
> (The forgoing two lines were actually a single line; I broke it for
> email formatting.)

That's fine. For future knowledge, you only need to install the
debuginfo packages if you're planning on running the binaries in the
main RPM through gdb. Otherwise, it's just eating space on your hard drive.

> Then tried
> 
> rpmbuild --rebuild texinfo-6.0-2.fc24.src.rpm
> 
> again.  Got the warnings again, of course, then the errors:
> 
>> error: Failed build dependencies:
>> perl(Unicode::EastAsianWidth) is needed by texinfo-6.0-2.fc17.x86_64
>> perl(Text::Unidecode) is needed by texinfo-6.0-2.fc17.x86_64
> 
> 
> Found what seemed to be an appropriate rpm and did
> 
> rpmbuild --rebuild perl-Unicode-EastAsianWidth-1.33-6.fc23.src.rpm
> 
> Got the errors
> 
>> error: Failed build dependencies:
>> perl(Module::Package) is needed by
>> perl-Unicode-EastAsianWidth-1.33-6.fc17.noarch
>> perl(Pod::Markdown) is needed by
>> perl-Unicode-EastAsianWidth-1.33-6.fc17.noarch
>> perl(Module::Package::Au) is needed by
>> perl-Unicode-EastAsianWidth-1.33-6.fc17.noarch
> 
> Scrounged around with Google; found instructions for installing perl
> modules using "cpanm".

Here's where you got off the main road:

Installing modules via CPAN is the same as building them by hand: RPM
doesn't know they exist.

And that's where you lost hope. What you need to do is to keep tracing
down RPM packages for dependencies and rebuilding. Normally, most Fedora
users don't have to do this, because we build a whole repository of
packages for them, but since you're 6 (almost 7) releases out of date,
you've got harder work to do.

koji.fedoraproject.org is your friend here. You can search for srpms
there, download them, and rebuild them.

That said, since you've listened to all of this, I've installed a Fedora
17 VM instance on my laptop and built you the missing packages you need
to build R fully featured:

https://spot.fedorapeople.org/fedora17-R-deps/

There is a src.rpm in there too for texlive, you don't need to install
it, I just included it because I 

Re: [R-sig-Fedora] WARNING you cannot build info or html versions of the R manuals

[Tom Callaway]

On 01/19/2016 11:10 PM, Rolf Turner wrote:
>> https://spot.fedorapeople.org/fedora17-R-deps/
> 
> Thank you for going to all this work.
> 
> However (as usual) I'm still at a bit of a loss.  I *think* that just a
> few more words of instruction will get me to where I need to be.
> 
> I went to the site that you specify and there found a list of 14
> packages (rpm-s) one of which is a ".src.rpm" with the others end just
> in ".rpm" with no ".src" before it.
> 
> OK.  Now what do I do?

Download all of them, except for the src.rpm (and the texinfo-debuginfo
package).

Then, run:

sudo rpm -Uvh info-6.0-2.fc17.1.x86_64.rpm
perl-File-ShareDir-Install-0.10-3.fc17.noarch.rpm
perl-Module-Install-AuthorRequires-0.02-10.fc17.noarch.rpm
perl-Module-Install-AuthorTests-0.002-10.fc17.noarch.rpm
perl-Module-Install-ManifestSkip-0.24-4.fc17.noarch.rpm
perl-Module-Install-Repository-0.06-10.fc17.noarch.rpm
perl-Module-Manifest-Skip-0.23-4.fc17.noarch.rpm
perl-Module-Package-0.30-9.fc17.noarch.rpm
perl-Module-Package-Au-2-4.fc17.noarch.rpm
perl-Unicode-EastAsianWidth-1.33-6.fc17.noarch.rpm
texinfo-6.0-2.fc17.1.x86_64.rpm texinfo-tex-6.0-2.fc17.1.x86_64.rpm

rpm has two install modes:

 * -i installs new packages.
 * -U upgrades a package over an existing install

The reasons for these modes are historical trivia, practically, humans
always use -U, because -i chokes if a package is already present, which
is what you saw. -v tells rpm to be verbose, and -h tells it to do
pretty progress hashing.

hth,

~tom

PS. I totally meant "texinfo" when I referred to the src.rpm earlier.
Too much tex on the brain today.

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] WARNING you cannot build info or html versions of the R manuals

[Tom Callaway]

On 01/16/2016 05:24 PM, Rolf Turner wrote:
> All that being said, the question remains as to *why* R cannot find
> "texinfo" when it is indeed present on my system.

Rather than give you a lengthy discussion of how RPM building works and
hacking the R spec, let's focus on this question instead (I'm still
willing to show you RPM building if you'd like, because if you're
sticking with Fedora 17 indefinitely it will be useful to you...)

The warning message string "you cannot build info or HTML versions of
the R manuals" comes from m4/R.m4:

  if test "${r_cv_prog_texi2any_v5}" != yes; then
warn_info="you cannot build info or HTML versions of the R manuals"
AC_MSG_WARN([${warn_info}])
MAKEINFO=""
  else
MAKEINFO="${MAKEINFO}"
  fi

In that same file, if you look at the beginning of the m4 function, you
see this comment:

  ## Building the R Texinfo manuals requires texinfo v5.1 or later.
  ## Set shell variable r_cv_prog_texi2any_v5 to 'yes' if a recent
  ## enough Makeinfo is found, and to 'no' otherwise.

Fedora 17 has texinfo 4.1, which is several years older than 5.1. You'll
need to upgrade that to silence this error in R.

You might try rebuilding the latest texinfo src RPM. We're at 6.0 in
Fedora 23+:

http://koji.fedoraproject.org/koji/buildinfo?buildID=676407

Download the src RPM from that page, then, on your system, try:

  rpmbuild --rebuild texinfo-6.0-2.fc24.src.rpm

That should (hopefully) result in a texinfo RPM built for Fedora 17.
Then you can install the new RPMS (they'll be in ~/rpmbuild/RPMS/$target
where $target is probably x86_64):

  rpm -Uvh info-6.0-2.fc17.*.rpm texinfo-6.0-2.fc17.*.rpm

hth,

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] WARNING you cannot build info or html versions of the R manuals

[Tom Callaway]

Are you building from a source tarball or using the Fedora SRPM? I strongly 
advise you to rebuild the SRPM, because the resulting binary RPM will have all 
the necessary deps for building and installing. You might need to change the 
spec up a bit, since I assume building on Fedora means a modern system, and 
f17 isn't modern.

On Jan 16, 2016 4:48 PM, Rolf Turner  wrote:
>
>
> My apologies for an inadvertent cross-posting.  I *intended* to send 
> this message to r-sig-fedora but by mistake sent it to 
> us...@lists.fedoraproject.org  . 
> So I am re-sending it to the address that I actually intended. 
>
> Again, I apologise for the screw-up. 
>
> So.  Here we go again: 
>
> It's no big deal, but when I build R from source (as I must) I always 
> get the warning given in the subject line of this post. 
>
> I have searched the web a bit and have found a number of references to 
> this warning.  Universally the proffered solution is "install texinfo". 
>
> So I did (just now) 
>
>  sudo yum install texinfo 
>
> and was told: 
>
> > Package texinfo-4.13a-16.fc17.x86_64 already installed and latest version 
> > Nothing to do 
>
> I checked with "whereis texinfo" and got: 
>
> > texinfo: /usr/share/texinfo /usr/share/man/man5/texinfo.5.gz 
>
>
> So it's there on my system --- but perhaps not where R can find it??? 
>
> Can anyone suggest to me what I need to do to get R and texinfo to 
> cooperate? 
>
> Please note that I am running Fedora 17.  Yes, I know, it's 
> antediluvian.  But for reasons I do not wish to discuss, I'm stuck 
> there.  (This is one of the reasons why I must build R from source. 
> It all works fine, except for that warning.) 
>
> cheers, 
>
> Rolf Turner 
>
> -- 
> Technical Editor ANZJS 
> Department of Statistics 
> University of Auckland 
> Phone: +64-9-373-7599 ext. 88276 
>
> ___ 
> R-SIG-Fedora mailing list 
> R-SIG-Fedora@r-project.org 
> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora 
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] redhat-hardened in CFLAGS

[Tom Callaway]

On 01/15/2016 11:14 AM, Milan Bouchet-Valat wrote:
> Le vendredi 15 janvier 2016 à 14:48 +0100, Jeroen Ooms a écrit :
>> On Fri, Jan 15, 2016 at 2:45 PM, Michael Smith 
>> wrote:
>>>
>>> dnf install redhat-rpm-config
>>
>> I used:
>>
>>  yum install /usr/lib/rpm/redhat/redhat-hardened-cc1
>>
>> And that did the job, however it seems to me this should be a formal
>> dependency of the R-base rpm package.
> Indeed, installing packages is quite an essential operation in R...

Agreed. I'm doing builds with Requires: redhat-rpm-config now (it isn't
needed for EL5/EL6 builds because they aren't hardened).

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rgl.snapshot only captures a small portion what's visible in the RGL device window on CentOS 7

[Tom Callaway]

On 01/11/2016 05:13 PM, Wittner, Ben, Ph.D. wrote:
> I followed the instructions in the link below, which allowed me to install 
> the nvidia driver, which fixed the original problem with rgl.snapshot.
> 
> Thanks very much for all your help.
> 
> I guess I'll file a bug in the CentOS Bug Tracker so that the nouveau driver 
> might get fixed. I'll also post to R-help so someone with the same problem 
> who only searches R-help and not this SIG will see the solution.

Awesome. If you have the cycles, I'm sure the CentOS people would
appreciate it if you ran through the nouveau troubleshooting first:

http://nouveau.freedesktop.org/wiki/Bugs/

You might consider also filing a bug with the Nouveau upstream, as the
CentOS people may not be experts with that driver, but the upstream
certainly will be. Keep in mind that they may want you to test the
latest version of the driver first.

Glad we got it working for you though. :)

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] rgl.snapshot only captures a small portion what's visible in the RGL device window on CentOS 7

[Tom Callaway]

On 01/11/2016 03:52 PM, Wittner, Ben, Ph.D. wrote:

> I started trying to do this, but I'm stuck.
> I started with 
> http://us.download.nvidia.com/XFree86/Linux-x86_64/340.96/README/installdriver.html
>  , which led me to 
> http://us.download.nvidia.com/XFree86/Linux-x86_64/340.96/README/commonproblems.html#nouveau
>  . I created /etc/modprobe.d/disable-nouveau.conf as instructed then 
> rebooted, but the nvidia installer found the nouveau driver running anyway, 
> so it wrote two more .conf files (one in /usr/lib/modproe.d and the other in 
> /etc/modeprobe.d) and then halted. I rebooted and tried the installer again, 
> but again it noticed the nouveau driver running.
> I suspect this is because the initial ramdisk image contains Nouveau because, 
> even though I've done systemctl set-default multi-user.target, during boot I 
> still see something that looks like a graphical screen display for a while 
> before it drops back to a text mode to display the login prompt.
> So, following the instructions, I tried to rebuild the initial ramdisk image. 
> The nvidia documentation does not say how to do that, so I Googled and found 
> https://wiki.centos.org/TipsAndTricks/CreateNewInitrd , which unfortunately 
> gives instructions only for CentOS 5 and CentOS 6, but not CentOS 7. I'm 
> afraid to do the wrong thing, so I'm stuck.
> Any suggestions would be appreciated.
> \

I have not tried it personally, but these instructions seem correct:

http://www.dedoimedo.com/computers/centos-7-nvidia.html

Basically, edit the grub2 cmdline to include the extra option:

  rdblacklist=nouveau

hth,

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] x11() hangs in R 3.2.1

[Tom Callaway]

On 09/15/2015 09:12 AM, Ashley Ford wrote:
> Steven Backus  writes:
> 
>>
>> I'm on RHEL 6.6, R version 3.2.1 Patched (2015-07-30 r68761) --
>> "World-Famous Astronaut".  Issuing the x11() command hangs R and
>> does not complete.  A window is partially drawn then freezes.
>> Does anyone know of a solution?
>>
>> Thanks,
>>   Steve
> 
> 
> I have the same problem, have you found a solution ?
> It's an X server issue as it works from a remote X session.
> Why is only R affected ?

First question: Are you using the nvidia binary driver?

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] Build rpm package for R-MKL

[Tom Callaway]

On 09/07/2015 06:16 AM, arnaud gaboury wrote:
> I want to create a clean .rpm package for R built with MKL and ICC. I
> follow Fedora instrcutions[0] to create the package. As a base, I use
> the R-3.2.2.src.rpm.
> 
> I am left with this error:
> 
> --
> installing R info pages ...
> updating '/usr/share/info/dir' ...
> make[1]: Leaving directory '/home/poisonivy/rpmbuild/BUILD/R-3.2.2/doc/manual'
> + mv doc/manual/R-exts.texi.spot doc/manual/R-exts.texi
> mv: cannot stat 'doc/manual/R-exts.texi.spot': No such file or directory
> ---
> 
> There is indeed no doc/manual/R-exts.texi.spot file. This make
> instruction comes form this in R.spec:
> 
> -
> %if 0%{?fedora} >= 19
> # What a hack.
> # Current texinfo doesn't like @eqn. Use @math instead where stuff breaks.
> cp doc/manual/R-exts.texi doc/manual/R-exts.texi.spot
> cp doc/manual/R-intro.texi doc/manual/R-intro.texi.spot
> sed -i 's|@eqn|@math|g' doc/manual/R-exts.texi
> sed -i 's|@eqn|@math|g' doc/manual/R-intro.texi
> %endif
> 
> # And now, undo the hack. :P
> %if 0%{?fedora} >= 19
> mv doc/manual/R-exts.texi.spot doc/manual/R-exts.texi
> mv doc/manual/R-intro.texi.spot doc/manual/R-intro.texi
> %endif
> --
> 
> How can I solve this issue? Maybe remove the hack?
> I will post configure and make options if needed.

Not sure how you managed that. The first conditional makes the ".spot"
files, the second one undoes it, both conditionals are the same. You can
try removing them both, but you might run into the exact texinfo issue
they were added to dodge.

~tom

==
Red Hat

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] upquote.sty in Fedora 21

[Tom Callaway]

On 12/22/2014 11:56 PM, Jeroen Ooms wrote:
 ‘qpdf’ is needed for checks on size reduction of PDFs

Okay, I've added Requires: qpdf for R-core-devel. Not going to push an
update for a WARNING in the test suite though, we'll just inherit this
with the next update of R.

~tom

==
Red Hat
attachment: tcallawa.vcf___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] upquote.sty in Fedora 21

[Tom Callaway]

On 12/14/2014 03:56 PM, Jeroen Ooms wrote:
 My CMD check server started failing after upgrading to Fedora 21:
 
 LaTeX errors when creating PDF version.
   This typically indicates Rd problems.
   LaTeX errors found:
   ! LaTeX Error: File `upquote.sty' not found.
 
 The problem was easily resolved by installing texlive-upquote. Perhaps
 this package should be included as a dependency to the R-devel
 package?

As pointed out, this is no longer an issue in R 3.1.2, which is in all
Fedora branches (except 21, where it is landing later today, hopefully).

~tom

==
Red Hat
attachment: tcallawa.vcf___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R with external BLAS fails regression test

[Tom Callaway]

On 07/07/2014 08:15 AM, Martyn Plummer wrote:
 Dear Tom,
 
 The change in the Fedora RPM from using R's internal BLAS to external
 BLAS means the Fedora R binary now fails one of R's regression tests,
 specifically: tests/reg-BLAS.R. You can run this code by hand to verify
 the issue.
 
 As noted in the R administration and Installation Manual, R relies on
 ISO/IEC 60559 compliance of an external BLAS. This can be broken if for
 example the code assumes that terms with a zero factor are always zero
 and do not need to be computed - whereas x*0 can be NaN. This is checked
 in the test suite.
 
 The version of BLAS that comes with R contains patched versions of
 DGBMV, DGEMM, and DGEMV.  The patch has been in place since 2010.
 Presumably R blas and reference BLAS have been divergent ever since.
 
 I guess this should be reported upstream as a BLAS bug. Recalling the
 previous thread on openblas, I note that openblas does pass the
 regression test.

Seems like it. In the interim, is there a patch handy, or do I need to
try to untangle it from the R code?

~tom

==
¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸(((º OSAS @ Red Hat
University Outreach || Fedora Special Projects || Fedora Legal
attachment: tcallawa.vcf___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] R binaries for Fedora 17.

[Tom Callaway]

On 08/02/2013 06:01 AM, Rolf Turner wrote:
 
 
 I am currently (still) running Fedora 17 --- having not managed to screw
 my courage to the sticking place and upgrade.
 Even though we are now up to Fedora 20, I think. The traffic on the
 Fedora mailing list on the upgrading issue is a bit terrifying.
 
 I would just like to confirm that:
 
 It is ***NOT*** possible to download a binary of R for  Fedora 17.
 
 Is this correct?
 
 My efforts to obtain a binary using yum install resulted in a binary for
 version 2.15.2.  (Whereas of course the source version available from
 CRAN is 3.0.1.
 
 I just wanted to check that I am not doing something stupid (like maybe
 using an incorrect repository).

Nope, this is right. F17 just end-of-lifed, so I never did a 3.0.1 build
for it (because it would also mean I had to rebuild every other R
package in the Fedora 17 tree).

Apologies for the inconvenience,

~tom

==
Fedora Project

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Re: [R-sig-Fedora] install warning on fedora 16

[Tom Callaway]

On 12/24/2011 10:39 PM, Mark Leeds wrote:
 Does anyone know what the problem might be ? Maybe a difference with gcc ?
 It's only a warning but it scares me a little because the variables should
 be getting used contrary to what the warning says.
 Thanks a lot for any hints/suggestions.

Well, I can't find the source code to be sure, but the gcc in F16 is
newer than the ones before it, and each new gcc is usually stricter
about std compliance than the one before. In addition, -std=gnu99 is
being passed as an optflag, which may result in these warnings when they
would not otherwise.

I would look very closely at those variables and be sure there is not a
logic path where they are set but not actually used.

~tom

==
Fedora Project

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

[R-sig-Fedora] R 2.12.1 in Fedora Updates Testing

[Tom Callaway]

R 2.12.1 is built now for Fedora and EPEL. It is in updates-testing
(or it will be within the next 24 hours).

In accordance with the new policies on Fedora Updates, these new
packages will not be pushed as official updates until they either
receive positive testing from users, or sit in updates-testing for two
weeks.

You can help us test these packages, and move them forward. Here's how:

1. Go to the Fedora Updates web application (its real name is Bodhi):
https://admin.fedoraproject.org/updates/

Once you're there, click the login blue box at the top left, and login
with your Fedora Account. If you don't have a Fedora Account, you can
give feedback, but it doesn't count towards giving the update positive
karma. For that reason, I would strongly recommend that you take 45
seconds and create a Fedora Account. :)

2. Click on the link for the Fedora R test update that matches your release:

Fedora 13:
https://admin.fedoraproject.org/updates/rkward-0.5.4-2.fc13,rpy-2.0.8-6.fc13,R-2.12.1-1.fc13

Fedora 14:
https://admin.fedoraproject.org/updates/rkward-0.5.4-2.fc14,rpy-2.1.9-1.fc14,R-2.12.1-1.fc14

EPEL-4 (RHEL-4):
https://admin.fedoraproject.org/updates/R-2.12.1-1.el4

EPEL-5 (RHEL-5):
https://admin.fedoraproject.org/updates/R-2.12.1-1.el5

3. Now, on your Fedora (or RHEL) system, run this command (as root, or
with root privs) to install the test update:

yum --enablerepo=updates-testing update R

That should update R to the test update (if you don't want the full R
suite, you can replace R in that string with R-core).

4. Test it! Make sure it does all the things you would expect it to.

5. Go back to the web page for the R update (step 2), and at
the bottom, click Add a comment 

(If you didn't login, it will ask you for an email address and make you
complete a captcha to make sure you are a unique individual.)

In that text box which opens up, write a little bit about the testing
you did and if it works okay for you or not. Then (this is the important
part), click the Works for me or Does not work radio button below
it, and click the Add Comment button.

6. That's it! If it worked, you've given that update a +1 karma vote.
(If it didn't work, you've given it a -1 karma vote). Now, if three
people (with Fedora Accounts) give a +1, and the package update gets to
+3, the Fedora Update system will automatically move the update from
testing to a real update, and everyone will get it.

Thanks in advance,

Tom Callaway, Fedora/EPEL R maintainer

___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora