Re: [R-sig-Fedora] evince not showing "greek" and "math" in *.pdf plots

[Iñaki Ucar]

Paul, what I still cannot understand is why Standard Symbols PS doesn't
show all the symbols, if it is supposed to be a replacement of the legacy
Standard Symbols L, see
https://github.com/ArtifexSoftware/urw-base35-fonts/blob/3c0ba3b5687632dfc66526544a4e811fe0ec0cd9/appstream/de.urwpp.StandardSymbolsPS.metainfo.xml#L14-L30
and
https://github.com/ArtifexSoftware/urw-base35-fonts/blob/3c0ba3b5687632dfc66526544a4e811fe0ec0cd9/fontconfig/urw-fallback-specifics.conf#L28
.

Iñaki

On Wed, 13 Mar 2024 at 16:53, Iñaki Ucar  wrote:

> I see. Peter, you are right about the font that causes the issue. Paul,
> thanks for your insights. I'll bring this to the Fedora font experts to see
> if we can arrive at a more permanent fix. I'll report back with any
> conclusion.
>
> @Martin: Meanwhile, at least you have options. One is to embed the fonts,
> either as Peter suggested or using cairo_pdf instead. Alternatively, Peter
> also has shown how to instruct fontconfig to select other fonts as
> replacements.
>
> Hope it helps,
> Iñaki
>
> On Tue, 12 Mar 2024 at 22:10, Paul Murrell 
> wrote:
>
>> Hi
>>
>> I don't think this is an R issue (it is separate from the Cairo Symbol
>> font problem).
>>
>> For PDF output, R actually relies on the Symbol font having the Adobe
>> Symbol Encoding (Appendix D of the PDF Reference
>>
>> https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.7old.pdf)
>>
>> and just outputs the font as "Symbol", which relies on it being one of
>> the Standard 14 Fonts ...
>>
>> "These fonts have built-in encodings that are unique to each
>> font."
>>
>> ... and ...
>>
>> "These fonts, or their font metrics and suitable substitution fonts,
>> must be available to the consumer application."
>>
>> In other words, R passes the buck to the viewer to either have access to
>> the Adobe Symbol font or use a substitute that has all of the necessary
>> glyphs (and in that case, presumably to also take care of satisfying the
>> Adobe Symbol Encoding).
>>
>> It is possible for the R user to specify a different font name for the
>> symbol font for PDF output, but that font has to have all of the
>> necessary glyphs and it has to follow the Adobe Symbol Encoding or all
>> bets are off.
>>
>> Paul
>>
>> On 12/03/24 06:59, Iñaki Ucar wrote:
>> > Martin, I wouldn't rule out an R issue yet. Fonts are... tricky. So I'm
>> > cc'ing Paul Murrell here.
>> >
>> > I tried several viewers here and I see the following: Chrome, Firefox
>> > and Libreoffice Draw show the symbols; however, evince, okular and
>> > xournal++ agree on **not** showing the symbols. **If** there is a bug,
>> > the bug would be in fontconfig, because these ones AFAIK properly
>> > delegate on fontconfig, which is the system-wide component that decides
>> > what font substitution should be made for any given font. However, I
>> see:
>> >
>> > $ fc-match Helvetica
>> > NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
>> >
>> > which is the right choice. And okular confirms this by showing in a
>> > properties dialog that it is substituting Helvetica with URW's Nimbus
>> > Sans Regular. So why aren't the symbols displayed? My best guess is
>> that
>> > this has something to do with how R encodes such symbols. Paul
>> > introduced some changes to fix similar issues for Cairo devices when
>> > Fedora dropped support for Type 1 fonts, see [1]. Now, I'm no font
>> > expert, but it seems to me that the pdf device may require similar
>> > fixes. (And why do xpdf or Firefox show the glyphs... I have no idea. I
>> > guess they do their thing without asking fontconfig).
>> >
>> > [1]
>> >
>> https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/
>> <
>> https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/
>> >
>> >
>> > Peter, as an aside, note that cairo_pdf embeds the fonts by default.
>> >
>> > Best,
>> > Iñaki
>> >
>> > On Mon, 11 Mar 2024 at 15:31, > > <mailto:pst...@gmail.com>> wrote:
>> >
>> > Hi Martin and Tim,
>> >
>> > I also have this bug. Though I think not necessarily with all the
>> same
>> > fonts as Martin.
>> >
>> > Using Martin's code:
>> >
>> > https://imgur.com/a/ILUoe3H
>> > <https://imgur.com/a

Re: [R-sig-Fedora] evince not showing "greek" and "math" in *.pdf plots

[Iñaki Ucar]

I see. Peter, you are right about the font that causes the issue. Paul,
thanks for your insights. I'll bring this to the Fedora font experts to see
if we can arrive at a more permanent fix. I'll report back with any
conclusion.

@Martin: Meanwhile, at least you have options. One is to embed the fonts,
either as Peter suggested or using cairo_pdf instead. Alternatively, Peter
also has shown how to instruct fontconfig to select other fonts as
replacements.

Hope it helps,
Iñaki

On Tue, 12 Mar 2024 at 22:10, Paul Murrell  wrote:

> Hi
>
> I don't think this is an R issue (it is separate from the Cairo Symbol
> font problem).
>
> For PDF output, R actually relies on the Symbol font having the Adobe
> Symbol Encoding (Appendix D of the PDF Reference
>
> https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.7old.pdf)
>
> and just outputs the font as "Symbol", which relies on it being one of
> the Standard 14 Fonts ...
>
> "These fonts have built-in encodings that are unique to each
> font."
>
> ... and ...
>
> "These fonts, or their font metrics and suitable substitution fonts,
> must be available to the consumer application."
>
> In other words, R passes the buck to the viewer to either have access to
> the Adobe Symbol font or use a substitute that has all of the necessary
> glyphs (and in that case, presumably to also take care of satisfying the
> Adobe Symbol Encoding).
>
> It is possible for the R user to specify a different font name for the
> symbol font for PDF output, but that font has to have all of the
> necessary glyphs and it has to follow the Adobe Symbol Encoding or all
> bets are off.
>
> Paul
>
> On 12/03/24 06:59, Iñaki Ucar wrote:
> > Martin, I wouldn't rule out an R issue yet. Fonts are... tricky. So I'm
> > cc'ing Paul Murrell here.
> >
> > I tried several viewers here and I see the following: Chrome, Firefox
> > and Libreoffice Draw show the symbols; however, evince, okular and
> > xournal++ agree on **not** showing the symbols. **If** there is a bug,
> > the bug would be in fontconfig, because these ones AFAIK properly
> > delegate on fontconfig, which is the system-wide component that decides
> > what font substitution should be made for any given font. However, I see:
> >
> > $ fc-match Helvetica
> > NimbusSans-Regular.otf: "Nimbus Sans" "Regular"
> >
> > which is the right choice. And okular confirms this by showing in a
> > properties dialog that it is substituting Helvetica with URW's Nimbus
> > Sans Regular. So why aren't the symbols displayed? My best guess is that
> > this has something to do with how R encodes such symbols. Paul
> > introduced some changes to fix similar issues for Cairo devices when
> > Fedora dropped support for Type 1 fonts, see [1]. Now, I'm no font
> > expert, but it seems to me that the pdf device may require similar
> > fixes. (And why do xpdf or Firefox show the glyphs... I have no idea. I
> > guess they do their thing without asking fontconfig).
> >
> > [1]
> >
> https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/
> <
> https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/
> >
> >
> > Peter, as an aside, note that cairo_pdf embeds the fonts by default.
> >
> > Best,
> > Iñaki
> >
> > On Mon, 11 Mar 2024 at 15:31,  > <mailto:pst...@gmail.com>> wrote:
> >
> > Hi Martin and Tim,
> >
> > I also have this bug. Though I think not necessarily with all the
> same
> > fonts as Martin.
> >
> > Using Martin's code:
> >
> > https://imgur.com/a/ILUoe3H
> > <https://imgur.com/a/ILUoe3H>
> >
> > Fedora 39, Evince 45.0
> >
> > It's a bug with Evince. I think. I think it's substituting in a font
> > set that doesn't have all the required symbols. I think it should be
> > possible to install the required fonts, but I haven't found a
> solution
> > that way, yet.
> >
> > Nevertheless, the following should work, and may be a better solution
> > anyway, given that embedding the fonts is probably more cross-
> > platform/viewer friendly:
> >
> >
> > You can embed the fonts if you have Ghostscript installed (I think it
> > comes with Fedora already(?) if not then:
> >
> > sudo dnf install ghostscript
> >
> > )
> >
> >
> > You can then use the embedFonts() function in R:
> >
> > (pdfil <- paste0("plotmath

Re: [R-sig-Fedora] evince not showing "greek" and "math" in *.pdf plots

[Iñaki Ucar]

Martin, I wouldn't rule out an R issue yet. Fonts are... tricky. So I'm
cc'ing Paul Murrell here.

I tried several viewers here and I see the following: Chrome, Firefox and
Libreoffice Draw show the symbols; however, evince, okular and xournal++
agree on **not** showing the symbols. **If** there is a bug, the bug would
be in fontconfig, because these ones AFAIK properly delegate on fontconfig,
which is the system-wide component that decides what font substitution
should be made for any given font. However, I see:

$ fc-match Helvetica
NimbusSans-Regular.otf: "Nimbus Sans" "Regular"

which is the right choice. And okular confirms this by showing in a
properties dialog that it is substituting Helvetica with URW's Nimbus Sans
Regular. So why aren't the symbols displayed? My best guess is that this
has something to do with how R encodes such symbols. Paul introduced some
changes to fix similar issues for Cairo devices when Fedora dropped support
for Type 1 fonts, see [1]. Now, I'm no font expert, but it seems to me that
the pdf device may require similar fixes. (And why do xpdf or Firefox show
the glyphs... I have no idea. I guess they do their thing without asking
fontconfig).

[1]
https://blog.r-project.org/2020/04/17/changes-to-symbol-fonts-for-cairo-graphics-devices/

Peter, as an aside, note that cairo_pdf embeds the fonts by default.

Best,
Iñaki

On Mon, 11 Mar 2024 at 15:31,  wrote:

> Hi Martin and Tim,
>
> I also have this bug. Though I think not necessarily with all the same
> fonts as Martin.
>
> Using Martin's code:
>
> https://imgur.com/a/ILUoe3H
>
> Fedora 39, Evince 45.0
>
> It's a bug with Evince. I think. I think it's substituting in a font
> set that doesn't have all the required symbols. I think it should be
> possible to install the required fonts, but I haven't found a solution
> that way, yet.
>
> Nevertheless, the following should work, and may be a better solution
> anyway, given that embedding the fonts is probably more cross-
> platform/viewer friendly:
>
>
> You can embed the fonts if you have Ghostscript installed (I think it
> comes with Fedora already(?) if not then:
>
> sudo dnf install ghostscript
>
> )
>
>
> You can then use the embedFonts() function in R:
>
> (pdfil <- paste0("plotmath-example_R",
>  with(R.version, paste0(major, sub("[.]", "", minor))),
> ".pdf"))
>
> pdf(pdfil)
> example(plotmath); mtext(R.version.string)
> dev.off()
>
> # Use embedFonts to embed the fonts in the PDF
> embedFonts(file = pdfil, outfile = paste0("embedded-example", pdfil),
> options = "-dPDFSETTINGS=/prepress")
>
>
> if(interactive()) {
>   system(paste("evince", paste0("embedded-example", pdfil), "&"))
> }
>
>
>
> Or you can do it in the terminal:
>
>
> gs -dNOPAUSE -dBATCH -dPDFSETTINGS=/prepress -sDEVICE=pdfwrite -
> dEmbedAllFonts=true -sOutputFile=plotmath-example-output_embedded.pdf -
> f plotmath-example_R432.pdf
>
>
> Compare:
>
>
> Embedded:
>
> ❯ pdffonts plotmath-example-output_embedded.pdf
> name   type encoding emb sub uni object ID
> --   --- --- --- -- ---
> KHEPSB+Helvetica   Type 1C  Custom   yes yes no  10   0
> WNPVSJ+Symbol  Type 1C  Custom   yes yes no  12   0
> MQBKOK+Helvetica-Bold  Type 1C  WinAnsi  yes yes no  20   0
>
>
> Original:
>
> ❯ pdffonts plotmath-example_R432.pdf
> name   type encoding emb sub uni object ID
> --   --- --- --- -- ---
> Helvetica  Type 1   Custom   no  no  no  16  0
> Helvetica-Bold Type 1   Custom   no  no  no  17  0
> Symbol Type 1   Symbol   no  no  no  18  0
>
>
> I hope this works for you. Like I said, I *think* it's a problem with
> Evince so it's probably better to file a bug report with them, but I
> also think embedding fonts isn't such a bad idea anyway - you'll know
> the output will display as intended regardless of the viewer on the
> user's system. It does lead to a larger file-size, but I think these
> days we can live with that.
>
> Thanks,
> Peter
>
>
>
>
> On Mon, 2024-03-11 at 14:15 +0100, Martin Maechler wrote:
> > > > > > > Tim Taylor
> > > > > > > on Mon, 11 Mar 2024 11:42:35 + writes:
> >
> > > Hi Martin
> > > Probably not the answer you're looking for but on the latest
> > Fedora 39 (workstation edition) both locally, and on a freshly
> > installed VM (with just R-core installed), all fonts render correctly
> > for me in evince.
> >
> > > $ evince --version
> > > GNOME Document Viewer 45.0
> >
> > > $ R --version
> > > R version 4.3.3 (2024-02-29) -- "Angel Food Cake"
> > > Copyright (C) 2024 The R Foundation for Statistical Computing
> > > Platform: x86_64-redhat-linux-gnu (64-bit)
> >
> > > It may be worth sharing more details about your installation
> > (e.g. Fedora version) to see if anyone has any ideas.
> >
> > > Tim
> >
> > Thank you, Tim.
> >
> >
> > Fedora is 

Re: [R-sig-Fedora] R-rmarkdown eot font

[Iñaki Ucar]

Could you please open an issue at bugzilla.redhat.com?

Iñaki


On Mon, 5 Feb 2024 at 15:48, Tim Taylor
 wrote:
>
> Stripping eot fonts from R-rmarkdown (and not linking to alternatives) means 
> Rmarkdown doesn't seem to work for certain document types. To illustrate:
>
> -
>
> echo -e '---\ntitle: "R Notebook"\noutput: html_document\n---' > test.Rmd
> R -s -e "rmarkdown::render('test.Rmd')"
>
> processing file: test.Rmd
>
> output file: test.knit.md
>
> /usr/bin/pandoc +RTS -K512m -RTS test.knit.md --to html4 --from 
> markdown+autolink_bare_uris+tex_math_single_backslash --output test.html 
> --lua-filter /usr/share/R/library/rmarkdown/rmarkdown/lua/pagebreak.lua 
> --lua-filter /usr/share/R/library/rmarkdown/rmarkdown/lua/latex-div.lua 
> --embed-resources --standalone --variable bs3=TRUE --section-divs --template 
> /usr/share/R/library/rmarkdown/rmd/h/default.html --no-highlight --variable 
> highlightjs=1 --variable theme=bootstrap --mathjax --variable 
> 'mathjax-url=https://mathjax.rstudio.com/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML'
>  --include-in-header /tmp/Rtmpc9fCOq/rmarkdown-str1742747432e3f.html
> pandoc: 
> /usr/share/R/library/rmarkdown/rmd/h/bootstrap/css/../fonts/glyphicons-halflings-regular.eot:
>  withBinaryFile: does not exist (No such file or directory)
> Error: pandoc document conversion failed with error 1
> Execution halted
>
> -
>
> I'm not sure if this can/should be solved upstream (and even whether it is 
> actually something to be solved in pandoc over rmarkdown) but the 
> functionality does seem broken as is currently shipped in Fedora.  
> Interestingly this appears to have also been discussed this month at 
> https://discussion.fedoraproject.org/t/cannot-produce-html-notebook-output-with-r-rmarkdown/101678
>  so I'm not sure if something has changed recently (I tend to always be using 
> a copr version of Rmarkdown).
>
> Hope this all makes sense.
>
> Tim
>
>
> [[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

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

[Iñaki Ucar]

On Thu, 15 Jun 2023 at 00:04, Alexandre Courtiol
 wrote:
>
> Hi all,
>
> The admin from our setup created a script that should help you reproduce our 
> problem (see below).
> Of course, it may be that it is not an RPM-related issue, but we hope you 
> will have an idea on how to solve the issue all the same.
>
> # 1. Prepare VM and set up Samba
>
> - install Fedora 38 Workstation (Fedora-Workstation-Live-x86_64-38-1.6.iso). 
> Username: 'user'
> - disable SELinux (edit /etc/selinux/config and set "SELINUX=disabled") and 
> reboot. Alternatively set up SELinux as described here: 
> https://docs.fedoraproject.org/en-US/quick-docs/samba/
>
> ```
> sudo dnf install samba
> mkdir ~/share
> sudo mkdir /mnt/share
> sudo smbpasswd -a user
> sudo cat << 'EOF' >> /etc/samba/smb.conf
> [share]
>   path = /home/user/share
>   writable = yes
>   browsable = yes
>   valid users = user
>   create mask = 0660
>   directory mask = 0770
> EOF
> sudo systemctl restart smb
> sudo mount -t cifs //localhost/share /mnt/share -o username=user,uid=user
> ```
>
>
> # 2. Install R with dnf
>
> ```
> sudo dnf install R
> mkdir /mnt/share/R
> ln -s /mnt/share/R ~/R
> ```
> - start R and install a package with dependencies (e.g. 
> "install.packages('dplyr')")
> - installation should fail (it does so on our side)

Well, actually not "a package with dependencies". Only dplyr seems to
fail, but no other package.

> # 3. Compile R from sources
>
> ```
> sudo dnf erase R
> sudo dnf builddep R
> sudo dnf install java-17-openjdk-devel
> curl -Ls https://cran.r-project.org/src/base/R-4/R-4.3.0.tar.gz | tar xzf -
> cd R-4.3.0
> ./configure
> make
> sudo make install
> ```
> - installing a package with dependencies should succeed now (on our side at 
> least)

The difference with the installation above is that this build is not
installing the help pages. Run R CMD INSTALL with --no-html above and
the installation succeeds too. So something happens with dplyr's html
pages (too many? so too much activity somehow locks the mounted files
temporarily?). No idea, but I don't think it has anything to do with
R.

Iñaki

>
>
> Many thanks, for having another look at this knot.
> Best,
> Alex
>
> On Wed, 14 Jun 2023 at 10:50, Alexandre Courtiol 
>  wrote:
>>
>> Thanks again, unfortunately it still fails when mounting the drive on a 
>> windows machine (even using nolease) on our end.
>> We will prepare a fully reproducible example using a virtual machine. This 
>> could take us a day or two.
>> ++
>>
>> On Tue, 13 Jun 2023 at 11:05, Iñaki Ucar  wrote:
>>>
>>> On Tue, 13 Jun 2023 at 10:35, Alexandre Courtiol
>>>  wrote:
>>> >
>>> > Thanks a lot for persevering.
>>> >
>>> > Iñaki, that sounds very promising, could you please tell me what software 
>>> > your SMB share is running on (i.e. what does the server side look like?), 
>>> > and if it's Samba, then what version did you use?
>>>
>>> There was a Windows 10 machine around, so I created a test folder and
>>> hit "share".
>>>
>>> > (and yes, I am aware of your excellent cran2copr project).
>>> >
>>> > Tom, yes it also created the same issue with older RPMs. Please also find 
>>> > the configure log attached to this email.
>>>
>>> I see no significant differences, so this supports the hypothesis that
>>> the issue is in the mount.
>>>
>>> Iñaki
>>>
>>> >
>>> > Best,
>>> >
>>> > Alex
>>> >
>>> >
>>> >
>>> > On Mon, 12 Jun 2023 at 21:08, Iñaki Ucar  wrote:
>>> >>
>>> >> Update:
>>> >>
>>> >> On Mon, 12 Jun 2023 at 17:40, Iñaki Ucar  wrote:
>>> >> >
>>> >> > Unfortunately, I cannot reproduce the issue here. :( I mounted a smb
>>> >> > share, created a symlink from ~/R, and installed dplyr without any
>>> >> > issue (apart from the installation process taking ages). Fortunately,
>>> >> > this rules out our binary R package as responsible for the issue you
>>> >> > are experiencing, unless I'm missing something.
>>> >>
>>> >> The experiment above was done using kio-fuse to mount the folder. Now
>>> >> I've been able to reproduce the error using a regular CIFS mount. I
>>> >> reproduced this both with Fedora and Debian R binaries. Then I
>>> >>

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

[Iñaki Ucar]

On Tue, 13 Jun 2023 at 10:35, Alexandre Courtiol
 wrote:
>
> Thanks a lot for persevering.
>
> Iñaki, that sounds very promising, could you please tell me what software 
> your SMB share is running on (i.e. what does the server side look like?), and 
> if it's Samba, then what version did you use?

There was a Windows 10 machine around, so I created a test folder and
hit "share".

> (and yes, I am aware of your excellent cran2copr project).
>
> Tom, yes it also created the same issue with older RPMs. Please also find the 
> configure log attached to this email.

I see no significant differences, so this supports the hypothesis that
the issue is in the mount.

Iñaki

>
> Best,
>
> Alex
>
>
>
> On Mon, 12 Jun 2023 at 21:08, Iñaki Ucar  wrote:
>>
>> Update:
>>
>> On Mon, 12 Jun 2023 at 17:40, Iñaki Ucar  wrote:
>> >
>> > Unfortunately, I cannot reproduce the issue here. :( I mounted a smb
>> > share, created a symlink from ~/R, and installed dplyr without any
>> > issue (apart from the installation process taking ages). Fortunately,
>> > this rules out our binary R package as responsible for the issue you
>> > are experiencing, unless I'm missing something.
>>
>> The experiment above was done using kio-fuse to mount the folder. Now
>> I've been able to reproduce the error using a regular CIFS mount. I
>> reproduced this both with Fedora and Debian R binaries. Then I
>> executed the installation step by step, and I checked that, when the
>> mv command is invoked, manually running mv in the console does trigger
>> the error too. So again, I don't think there's any issue with R.
>>
>> However, I've also managed to fix the issue by adding the nolease
>> option to the mount command. Hope it helps.
>>
>> Iñaki
>>
>> >
>> > Issue aside, may I ask what is the purpose of putting the library in a
>> > smb share? May I suggest [1]?
>> >
>> > [1] https://cran.r-project.org/bin/linux/fedora/#additional-packages
>> >
>> > Iñaki
>> >
>> > On Mon, 12 Jun 2023 at 16:48, Tom Callaway  wrote:
>> > >
>> > > 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 
>> > >  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
>> > >>&g

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

[Iñaki Ucar]

Update:

On Mon, 12 Jun 2023 at 17:40, Iñaki Ucar  wrote:
>
> Unfortunately, I cannot reproduce the issue here. :( I mounted a smb
> share, created a symlink from ~/R, and installed dplyr without any
> issue (apart from the installation process taking ages). Fortunately,
> this rules out our binary R package as responsible for the issue you
> are experiencing, unless I'm missing something.

The experiment above was done using kio-fuse to mount the folder. Now
I've been able to reproduce the error using a regular CIFS mount. I
reproduced this both with Fedora and Debian R binaries. Then I
executed the installation step by step, and I checked that, when the
mv command is invoked, manually running mv in the console does trigger
the error too. So again, I don't think there's any issue with R.

However, I've also managed to fix the issue by adding the nolease
option to the mount command. Hope it helps.

Iñaki

>
> Issue aside, may I ask what is the purpose of putting the library in a
> smb share? May I suggest [1]?
>
> [1] https://cran.r-project.org/bin/linux/fedora/#additional-packages
>
> Iñaki
>
> On Mon, 12 Jun 2023 at 16:48, Tom Callaway  wrote:
> >
> > 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 
> >  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 
> >>>  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 
> >>>>> >

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

[Iñaki Ucar]

Unfortunately, I cannot reproduce the issue here. :( I mounted a smb
share, created a symlink from ~/R, and installed dplyr without any
issue (apart from the installation process taking ages). Fortunately,
this rules out our binary R package as responsible for the issue you
are experiencing, unless I'm missing something.

Issue aside, may I ask what is the purpose of putting the library in a
smb share? May I suggest [1]?

[1] https://cran.r-project.org/bin/linux/fedora/#additional-packages

Iñaki

On Mon, 12 Jun 2023 at 16:48, Tom Callaway  wrote:
>
> 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 
>  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 
>>>  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 
>>>>> > > pac

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

[Iñaki Ucar]

Ok, then last check before trying to reproduce this locally: is the
staged installation enabled too in the cases you don't see this issue?

Iñaki

On Mon, 12 Jun 2023 at 15:12, Alexandre Courtiol
 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



-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

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

___
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"

[Iñaki Ucar]

On Mon, 7 Nov 2022 at 17:36, Tom Callaway  wrote:
>
> 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

This works too, but it doesn't get the latest changes in rawhide:

$ dnf builddep R

BTW, Lluís is putting together a guide where all these deps are
listed: https://github.com/r-devel/rdevguide/pull/105

Iñaki

>
> ~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



-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] C diagnostics in rstudio

[Iñaki Ucar]

On Tue, 18 Oct 2022 at 20:24,  wrote:
>
> Great - thank you. Even though it's the same with the official build do you 
> think it's worth a small addendum within 
> https://cran.r-project.org/bin/linux/fedora/#add-ons?

Or, better, we could add "Recommends: clang-devel" to our build in the
next release, and in this way it would be pulled automatically by
default.

Iñaki

>
> Tim
>
>
> > On 18/10/2022 19:10 BST Iñaki Ucar  wrote:
> >
> >
> > On Tue, 18 Oct 2022 at 16:54,  wrote:
> > >
> > > Apologies if this is double posted as I initially sent from an account 
> > > not registered.
> > >
> > > I've noticed that diagnostics and completions for C code do not seem to 
> > > be working within rstudio on f36 (2022.02.4+500-1). Is there something 
> > > additional required to enable them outside of rstudio itself?
> >
> > Yes, you need to install clang-devel, both for our build as well as
> > for the official build.
> >
> > In general, this is how you can find which package provides a certain file:
> >
> > $ dnf repoquery --provides */
> >
> > where =libclang.so in our case.
> >
> > Iñaki
> >
> > > Using .rs.setClangDiagnostics(2) within rstudio gives me the following 
> > > output:
> > >
> > > Attemping to load libclang for x86_64-redhat-linux-gnu
> > > /usr/libexec/rstudio/bin/rsclang/libclang.so
> > > (Not Found)
> > > /usr/lib/libclang.so
> > > (Not Found)
> > > /usr/lib/llvm/libclang.so
> > > (Not Found)
> > > /usr/lib64/libclang.so
> > > (Not Found)
> > > /usr/lib64/llvm/libclang.so
> > > (Not Found)
> > > /usr/lib64/llvm13/lib/libclang.so.1
> > > (Not Found)
> > >
> > > For reference in /usr/lib64 I have
> > > clang
> > > libclang-cpp.so.14
> > > libclang.so.14.0.5
> > > libclang.so.14.0.5
> > > llvm13
> > >
> > > Cheers
> > >
> > > Tim
> > >
> > > ___
> > > R-SIG-Fedora mailing list
> > > R-SIG-Fedora@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
> >
> >
> >
> > --
> > 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

Re: [R-sig-Fedora] C diagnostics in rstudio

[Iñaki Ucar]

On Tue, 18 Oct 2022 at 16:54,  wrote:
>
> Apologies if this is double posted as I initially sent from an account not 
> registered.
>
> I've noticed that diagnostics and completions for C code do not seem to be 
> working within rstudio on f36 (2022.02.4+500-1). Is there something 
> additional required to enable them outside of rstudio itself?

Yes, you need to install clang-devel, both for our build as well as
for the official build.

In general, this is how you can find which package provides a certain file:

$ dnf repoquery --provides */

where =libclang.so in our case.

Iñaki

> Using .rs.setClangDiagnostics(2) within rstudio gives me the following output:
>
> Attemping to load libclang for x86_64-redhat-linux-gnu
> /usr/libexec/rstudio/bin/rsclang/libclang.so
> (Not Found)
> /usr/lib/libclang.so
> (Not Found)
> /usr/lib/llvm/libclang.so
> (Not Found)
> /usr/lib64/libclang.so
> (Not Found)
> /usr/lib64/llvm/libclang.so
> (Not Found)
> /usr/lib64/llvm13/lib/libclang.so.1
> (Not Found)
>
> For reference in /usr/lib64 I have
> clang
> libclang-cpp.so.14
> libclang.so.14.0.5
> libclang.so.14.0.5
> llvm13
>
> Cheers
>
> Tim
>
> ___
> 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

Re: [R-sig-Fedora] Self Introduction

[Iñaki Ucar]

Hi,

Great, some packages are lagging behind, so more hands are welcome,
thanks. We are in the process of creating a FAS group for this, but
it's not ready yet. For now, you can familiarise yourself with the R
packaging guidelines [1], express this interest in [2] and add
yourself to the list in [3].

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/R/
[2] https://pagure.io/fesco/issue/2815
[3] https://fedoraproject.org/wiki/SIGs/R

Best,
Iñaki


On Thu, 21 Jul 2022 at 15:18, Ali Erdinc Koroglu
 wrote:
>
> Hello, Everyone.
> My name is Ali Erdinc Koroglu, I work at Intel in the Linux Systems 
> Engineering team where we build and package optimization work across
> various Linux distros. I'm also CentOS Hyperscale SIG member + Fedora 
> packager (fas: aekoroglu) and NeuroSIG member.
>
> I was planning to work on R + OpenBLAS and upgrade R packages for Fedora and 
> migrate the missing once into EPEL8/9.
> So I think the R SIG is an excellent fit for my efforts and I would like to 
> become a member.
>
> I look forward to working with you all.
>
> Best regards,
> Ali Erdinc Koroglu
>
> -
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidenti...{{dropped:14}}

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

Re: [R-sig-Fedora] rstudio-server toolbox instructions

[Iñaki Ucar]

On Tue, 14 Jun 2022 at 16:33,  wrote:
>
> Following the instructions at 
> https://cran.r-project.org/bin/linux/fedora/#toolbox-container-based-development
> I'm trying to run rstudio server in a fedora 36 toolbox. I run the following 
> commands:
>
> [toolbox]$ sudo dnf install rstudio-server
> [toolbox]$ rserver --server-daemonize=0 --auth-none=1 --server-user=$(whoami)
>
> but this errors with the following:
>
> 2022-06-14T14:29:55.478369Z [rserver] ERROR system error 13 (Permission 
> denied) [path: /var/run/rstudio-server, target-dir: ]; OCCURRED AT 
> rstudio::core::Error rstudio::core::FilePath::createDirectory(const 
> std::string&) const src/cpp/shared_core/FilePath.cpp:842; LOGGED FROM: int 
> main(int, char* const*) src/cpp/server/ServerMain.cpp:626
>
> Do the instructions need updating or am I missing something obvious?

This is kind-of-a hack that used to work, but apparently there are new
constraints now, and more options are required to circumvent the
default directories. We would need to figure out the new options and
maybe provide a wrapper if this becomes too complicated.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

And nowadays there's also R-hub [1], rocker containers [2] for local
testing (which, combined with distrobox [3], is very convenient), and
of course r-actions on GitHub [4] for CI testing.

Iñaki

[1] https://r-hub.github.io/rhub/
[2] https://github.com/rocker-org/rocker
[3] https://fedoramagazine.org/run-distrobox-on-fedora-linux/
[4] https://github.com/r-lib/actions/tree/v2-branch/examples


On Fri, 7 Jan 2022 at 16:02, Milan Bouchet-Valat  wrote:
>
> Hi,
>
> FWIW, a good solution to check packages on the latest R version (in
> particular the development version) is to upload them to Winbuilder:
> https://win-builder.r-project.org/
>
> (I even seem to remember that CRAN recommends this.)
>
>
> Best
>
>
> Le vendredi 07 janvier 2022 à 12:16 +, José Abílio Matos a écrit :
> > On Friday, 7 January 2022 07.30.22 WET Jim Lemon wrote:
> > > Hi Tom,
> > > As I maintain a few packages on CRAN, The Rules say I should build
> > > them with an up to the minute version of R. Whenever I have
> > > installed
> > > R from a repo, it always seems to be a few versions behind. I'll
> > > let
> > > you know how it goes. Thanks.
> > >
> > > Jim
> >
> > Please take what follows as genuine curiosity, because it is. :-)
> >
> > Your remark seems strange because in general Tom rebuilds R in one or
> > two
> > weeks after it is released, at least for point releases.
> >
> > The issue sometimes happens when a new release happens where in some
> > cases the
> > only viable option is to rebuild all the R packages. In that case we
> > need to
> > come with a way to automatically rebuild the packages (because order
> > matters
> > here).
> >
> > Is this the problem that you are seeing?
> >
> > Another worthwhile mentioning project is:
> > https://copr.fedorainfracloud.org/coprs/iucar/cran/
> >
> > Best regards,
> > ___
> > 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

___
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 code works on Fedora 32, but not since Fedora 33

[Iñaki Ucar]

Hi,

Since F33, openblas-openmp is the default BLAS implementation in
Fedora. I see that mboost::cvrisk uses parallelization via mclapply by
default, which may not play well with OpenMP. So you have 3 options
here:

Option 1. Force mboost::cvrisk to run sequentially by providing
papply=lapply as an argument.

Option 2. Limit the number of OpenMP threads to 1:

$ sudo dnf -y install R-flexiblas
$ R
> flexiblas::flexiblas_set_num_threads(1)
> # then, run your script

or simply:

$ OMP_NUM_THREADS=1 R
$ # then, run your script

Option 3. Switch to sequential OpenBLAS:

$ sudo dnf -y install flexiblas-openblas-serial R-flexiblas
$ R
> flexiblas::flexiblas_switch(flexiblas::flexiblas_load_backend("openblas-serial"))
> # then, run your script

or simply:

$ sudo dnf -y install flexiblas-openblas-serial
$ FLEXIBLAS=openblas-serial R
> # then, run your script

See [1] for more info. Hope it helps.

Iñaki

[1] https://cran.r-project.org/bin/linux/fedora/#blaslapack-switching

On Thu, 4 Nov 2021 at 18:47, René Genz  wrote:
>
> Hi,
>
> the other day I was asked to investigate a problem regarding R. The R
> code works on Fedora 32, but not since Fedora 33. I am stuck and need
> help. I can test and provide more information if needed.
>
> On Fedora 32 the code produces a PDF file (397 KiB) containing 6 pages.
> It can be viewed.
> Since Fedora 33 the R calculation stalls after a second. The PDF file
> (3.5 KiB) cannot be viewed.
>
> I tested with virtual machines with Fedora 32 to 35. I installed with
> the netinstall ISO the "Xfce Desktop" group. After installation was done
> I ran as root:
> # dnf update -y --refresh ; dnf install -y R ; reboot
>
> After reboot I logged in as user, received the CSV file and ran:
> $ cd 2021-11-02-R-F32-F34 ; R
> and copy-pasted the R code. The R package "plotly" requires the R
> package "httr" which requires:
> # dnf install -y curl-devel openssl-devel
> Maybe you need to quit and re-run that R package installation command.
>
>
> Attached is the execution log for F32 and F33. If you compare them
> (`diff` or `meld`), you will notice different compiler options and some
> different compiler messages. I do not know if they are related.
>
>
> Attached is the R code. I added the print commands at the end (not
> included in the logs). The command 'print("a")' results in output '[1]
> "a"'. On F32 the output a to f repeats 6 times (matches page number). In
> `top` during PDF creation you can see 3 rsession processes during most
> of calculation. Calculation takes approximately 30 seconds.
>
> Since F33 you see only this output:
> [1] "a"
> [1] "b"
> That means the problem is at "cvm[[i]] <- cvrisk(model[[i]])" line. It
> is part of the R package mboost.
> In `top` you see only 1 rsession process for a second. Calculcation
> stalls. You must abort with Ctrl+c. The PDF file cannot be viewed.
>
> You can leave the R environment (prompt ">") with either:
> - Ctrl+d
> - quit()
> No need to save the workspace image (press n and enter).
>
>
>
> Additional information:
>
> Fedora 32:
>  > sessionInfo()
> R version 4.0.5 (2021-03-31)
> Platform: x86_64-redhat-linux-gnu (64-bit)
> Running under: Fedora 32 (Thirty Two)
>
> Matrix products: default
> BLAS/LAPACK: /usr/lib64/libopenblas-r0.3.12.so
>
> locale:
>   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>   [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>   [7] LC_PAPER=C.UTF-8   LC_NAME=C
>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] parallel  stats graphics  grDevices utils datasets  methods
> [8] base
>
> other attached packages:
> [1] GGally_2.1.2  stringi_1.7.5 plotly_4.10.0 Amelia_1.8.0  Rcpp_1.0.7
> [6] ggplot2_3.3.5 mboost_2.9-5  stabs_0.6-4
>
> loaded via a namespace (and not attached):
>   [1] tidyselect_1.1.1   inum_1.0-4 purrr_0.3.4
> splines_4.0.5
>   [5] lattice_0.20-41colorspace_2.0-2   vctrs_0.3.8
> generics_0.1.1
>   [9] htmltools_0.5.2viridisLite_0.4.0  utf8_1.2.2
> survival_3.2-10
> [13] rlang_0.4.12   pillar_1.6.4   foreign_0.8-81 glue_1.4.2
>
> [17] withr_2.4.2RColorBrewer_1.1-2 plyr_1.8.6
> lifecycle_1.0.1
> [21] munsell_0.5.0  gtable_0.3.0   htmlwidgets_1.5.4
> mvtnorm_1.1-3
> [25] fastmap_1.1.0  fansi_0.5.0scales_1.1.1
> jsonlite_1.7.2
> [29] digest_0.6.28  dplyr_1.0.7grid_4.0.5
> quadprog_1.5-8
> [33] tools_4.0.5magrittr_2.0.1 lazyeval_0.2.2
> tibble_3.1.5
> [37] Formula_1.2-4  crayon_1.4.2   tidyr_1.1.4
> pkgconfig_2.0.3
> [41] partykit_1.2-15ellipsis_0.3.2 libcoin_1.0-9
> Matrix_1.3-2
> [45] data.table_1.14.2  nnls_1.4   reshape_0.8.8  httr_1.4.2
>
> [49] R6_2.5.1   rpart_4.1-15   compiler_4.0.5
>  > Sys.getlocale()
> [1]
> 

Re: [R-sig-Fedora] updating/installing R

[Iñaki Ucar]

On Tue, 7 Sept 2021 at 02:30, Jim Lemon  wrote:
>
> Hi Inaki,
> Your instructions worked perfectly for installing "toolbox" and I
> could start R-4.1.1-1 in my local terminal (konsole). However, I can't
> seem to build a new version of plotrix:
>
> [root@jimACER jim]# toolbox run --release 35 R CMD build

Do not run toolbox as root. As explained in the instructions, the
whole point of using toolbox is that it is rootless.

Iñaki

> jimACER://home/jim/R/plotr
> ix
> Error: directory /home/jim not found in container fedora-toolbox-35
> Using /root instead.
> During startup - Warning messages:
> 1: Setting LC_CTYPE failed, using "C"
> 2: Setting LC_TIME failed, using "C"
> 3: Setting LC_MESSAGES failed, using "C"
> 4: Setting LC_MONETARY failed, using "C"
> 5: Setting LC_PAPER failed, using "C"
> 6: Setting LC_MEASUREMENT failed, using "C"
> ERROR
> cannot change to directory 'jimACER://home/jim/R/plotrix'
>
> I also tried using "localhost" for the loopback server, got the same result.
> I'll try building R-4.1.1 from source on my ancient DELL desktop. If I
> can get a build I can then check it using --as-cran, cross my fingers
> and submit it. I'll get back to you if I'm still stuck. Thanks.
>
> Jim
>
> On Tue, Sep 7, 2021 at 8:43 AM Iñaki Ucar  wrote:
> >
> > On Mon, 6 Sept 2021 at 00:02, Jim Lemon  wrote:
> > >
> > > Hi Inaki,
> > > Fedora 34 KDE spin.
> > >
> > > When I try to install/upgrade as root using dnf:
> > >
> > > [root@jimACER packages]# dnf install R
> > > Fedora 34 - x86_64 - Updates   2.4 kB/s | 3.7 kB
> > >   00:01
> > > Fedora Modular 34 - x86_64 - Updates   5.2 kB/s | 3.6 kB
> > >   00:00
> > > Package R-4.0.5-1.fc34.x86_64 is already installed.
> > > Dependencies resolved.
> > > Nothing to do.
> > > Complete!
> > > [root@jimACER packages]# dnf upgrade R
> > > Last metadata expiration check: 0:00:17 ago on Mon 06 Sep 2021 07:48:38.
> > > Dependencies resolved.
> > > Nothing to do.
> > > Complete!
> >
> > R 4.1 is not available for Fedora 34. Instead, see
> > https://cran.r-project.org/bin/linux/fedora/#toolbox-container-based-development
> >
> > > When I try to connect to:
> > >
> > > https://pagure.io/R/fedora-r-packages
> > >
> > > I get the message:
> > >
> > > pagure.io
> > > Refused to connect
> >
> > Should be a temporary issue. But that's just the source of that
> > document, a git repository, why would you want to access this?
> >
> > > As I used to build R from source, I tried that but couldn't get past
> > > the missing "Intrinsic.h" in configure. I switched to using a newish
> > > laptop (ACER Swift 3) some months ago, so I lost all the tools I had
> > > built up over the years.
> > >
> > > Thanks for any tips.
> >
> > Again (see above) my suggestion is to use toolbox to install R 4.1
> > from the official repos. No need to compile.
> >
> > --
> > 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

Re: [R-sig-Fedora] RStudio does not open completly

[Iñaki Ucar]

The issue seems to be caused by the QtWebEngine. Fedora 35 was
recently branched from rawhide. Try the following to stop using
rawhide and follow this release:

[toolbox]$ sudo dnf config-manager --set-disabled rawhide
[toolbox]$ sudo dnf config-manager --set-enabled fedora,updates
[toolbox]$ sudo dnf distro-sync --releasever=35

If the problem persists, my recommendation is to install
rstudio-server and run this:

[toolbox]$ rserver --server-daemonize=0 --auth-none=1 --server-user=$(whoami)

Then, open a browser and navigate to localhost:8787 to access RStudio Server.

Iñaki


On Fri, 13 Aug 2021 at 12:40, Paul Smith  wrote:
>
> Thanks, Iñaki. Toolbox as well as my computer are running Xorg:
>
> -
> $ echo $XDG_SESSION_TYPE
> x11
> -
>
> Paul
>
>
> On Fri, Aug 13, 2021 at 8:29 AM Iñaki Ucar  wrote:
> >
> > Xorg or Wayland session? RStudio doesn't support the latter yet.
> >
> > Iñaki
> >
> > On Thu, 12 Aug 2021 at 23:19, Paul Smith  wrote:
> > >
> > > Dear All,
> > >
> > > I have just installed R 4.1 and RStudio on Fedora Toolbox. Everything
> > > went fine, but when I try to run RStudio, it opens as a white window
> > > flickering permanently, and does not progress from that.
> > >
> > > Any ideas?
> > >
> > > Thanks in advance,
> > >
> > > Paul
> > >
> > > ___
> > > R-SIG-Fedora mailing list
> > > R-SIG-Fedora@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
> >
> >
> >
> > --
> > 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

Re: [R-sig-Fedora] RStudio does not open completly

[Iñaki Ucar]

Xorg or Wayland session? RStudio doesn't support the latter yet.

Iñaki

On Thu, 12 Aug 2021 at 23:19, Paul Smith  wrote:
>
> Dear All,
>
> I have just installed R 4.1 and RStudio on Fedora Toolbox. Everything
> went fine, but when I try to run RStudio, it opens as a white window
> flickering permanently, and does not progress from that.
>
> Any ideas?
>
> Thanks in advance,
>
> Paul
>
> ___
> 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

Re: [R-sig-Fedora] Makefile error

[Iñaki Ucar]

On Wed, 28 Jul 2021 at 11:59, Bintao Cui  wrote:
>
> Makefile.in:87: *** missing separator.  Stop.
>
> I am trying to install R-4.1.0 version to fedora, and got the error above, 
> please help!

This version is available in rawhide. See [1] about how to install it.

[1] https://stat.ethz.ch/pipermail/r-sig-fedora/2021-June/000770.html

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] RStudio discounts with R when restarting R

[Iñaki Ucar]

On Mon, 12 Jul 2021 at 17:56, Yifan Liu  wrote:
>
> Sorry, it is a typo. I actually mean disconnect.

I can't reproduce the issue. My session just restarts as expected. So
probably the cause of the issue is some session state or local
configuration. Try renaming the ~/.rstudio folder and/or report this
upstream.

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] RStudio discounts with R when restarting R

[Iñaki Ucar]

On Mon, 12 Jul 2021 at 13:19, Yifan Liu  wrote:
>
> Hi All,
>
> I am currently using R 4.0.5 on RStudio 1.4.1717 on Fedora 34. When I
> restart R (Ctrl + Shift + F10), RStudio will always discount with R. This
> issue occurs to my two computers and has been around for about one month.
> Did anyone experience the same issue?

Sorry, what do you mean by "discount with R"?

-- 
Iñaki Úcar

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

[R-sig-Fedora] Newest glibc split makes some packages fail to build

[Iñaki Ucar]

Hi,

See [1] and [2]. We need to keep an eye on what comes out from [3],
because if glibc-gconv-extra is not added to the buildroot, then
R-core-devel would need to put it in Requires. Otherwise, some R
packages fail to build due to missing converters.

[1] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/JQTTSNHMSFV63KIDDPW4M7WV7CI6KZYW/
[2] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS/#IWAOAD6XXXAPBQZ364OKVBZZXDDHG2KS
[3] https://pagure.io/releng/issue/10176

-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

On Wed, 23 Jun 2021 at 19:00, Iñaki Ucar  wrote:
>
> In rawhide, there may be some "glitches", because it's in active
> development, so I have to launch several mass rebuilds until things
> start to settle (no more system-wide changes, no more core library
> updates...). Right now I'm in the middle of a mass rebuild, so you
> won't be able to install some packages until it's finished.

Mass rebuild completed in rawhide for the CRAN Copr repo. There are
still a few dozen fails that need more careful inspection. If you
experience issues, please report them in
https://github.com/Enchufa2/cran2copr/issues.

-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

On Wed, 23 Jun 2021 at 18:29, Gavin Simpson  wrote:
>
> Thanks Iñaki! toolbox looks really useful for my usecase.

Toolbox is *very* cool. :)

> 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.

Currently, in rawhide, I recommend installing R-testthat, which comes
from the official repos, and it's patched. Also, please make some
noise in [1] to get it resolved upstream. ;-)

[1] https://github.com/r-lib/testthat/issues/1373

> 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.

All the R-* packages are in the official repos, most of them
maintained by Elliott (@qulogic). There are a few hundred. Then, if
you have my Copr enabled, you'll have access to R-CRAN-* packages,
which currently are more than 17100 packages. CRAN packages in the
official repos are also in the Copr repo (R-testthat is the official
one; R-CRAN-testthat comes from Copr). These installations are
compatible, because the Copr repo installs stuff into /usr/local to
avoid any clashes with the official repos. The official repos also
have some Bioc packages not present in my Copr repo. See [2] for
further details.

[2] https://cran.r-project.org/bin/linux/fedora/

If you happen to have the same package from several sources, R will
pick your user library as a first option, packages from Copr as the
second option, and packages from the official repos as the third
option.

> 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?

What can I say? :) The Copr repo has been working nicely for me,
especially for stable releases. I have it enabled in all the servers I
manage here at the university. And it's especially convenient when you
install the R-CoprManager package, because then you just call
install.packages() in your R console and binary packages from Copr are
automatically installed if they are available; otherwise, they are
pulled from CRAN, so no big deal.

In rawhide, there may be some "glitches", because it's in active
development, so I have to launch several mass rebuilds until things
start to settle (no more system-wide changes, no more core library
updates...). Right now I'm in the middle of a mass rebuild, so you
won't be able to install some packages until it's finished.

-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

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, PhD [he/him/his]   [t] +1 306 337 8863
> • Research Scientist  [f] +1 306 337 2410
> Institute of Environmental   [tw] @ucfagls
>   Change & Society[w] goo.gl/Zpkdem
> University of Regina  [w] iecs-uregina.ca
> Regina, SK S4S 0A2, Canada   [iD] -0002-9084-8413
>
> • Adjunct Professor, Department of Biology, University of Regina.



-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

We still have a few issues:

# dnf install R-*
Last metadata expiration check: 0:00:08 ago on Tue Jun 22 13:04:20 2021.
Error:
Problem 1: conflicting requests
 - nothing provides R(ABI) = 4.0 needed by R-littler-0.3.12-2.fc34.x86_64
Problem 2: conflicting requests
 - nothing provides R(ABI) = 4.0 needed by R-Rcompression-0.93.2-30.fc34.x86_64
Problem 3: conflicting requests
 - nothing provides R(ABI) = 4.0 needed by R-nws-1:1.7.0.1-24.fc34.noarch
Problem 4: package R-littler-examples-0.3.12-2.fc34.x86_64 requires
R-littler(x86-64) = 0.3.12-2.fc34, but none of the providers can be
installe
d
 - package R-littler-examples-0.3.12-2.fc34.x86_64 requires
/usr/bin/r, but none of the providers can be installed
 - conflicting requests
 - nothing provides R(ABI) = 4.0 needed by R-littler-0.3.12-2.fc34.x86_64
Problem 5: package R-Rcpp-examples-1.0.6-3.fc35.x86_64 requires
/usr/bin/r, but none of the providers can be installed
 - conflicting requests
 - nothing provides R(ABI) = 4.0 needed by R-littler-0.3.12-2.fc34.x86_64
Problem 6: conflicting requests
 - nothing provides R(ABI) = 4.0 needed by R-Rsolid-0.9.31-34.fc34.i686
 - nothing provides R(ABI) = 4.0 needed by R-Rsolid-0.9.31-34.fc34.x86_64
Problem 7: conflicting requests
 - package R-Rsolid-devel-0.9.31-34.fc34.i686 requires
R-Rsolid(x86-32) = 0.9.31-34.fc34, but none of the providers can be
installed
 - package R-Rsolid-devel-0.9.31-34.fc34.x86_64 requires
R-Rsolid(x86-64) = 0.9.31-34.fc34, but none of the providers can be
installed
 - nothing provides R(ABI) = 4.0 needed by R-Rsolid-0.9.31-34.fc34.i686
 - nothing provides R(ABI) = 4.0 needed by R-Rsolid-0.9.31-34.fc34.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

At least R-littler was already rebuilt by Mattias, but it didn't
propagate to the repos yet.

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



-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

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

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

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

[Iñaki Ucar]

On Wed, 16 Jun 2021 at 16:08, Tom Callaway  wrote:
>
> 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.

Ah, true, Shiny 1.6 switched to bslib. Is this version of Shiny
required for the current rebuild then? I'm reluctant to take more R
packages in the official repos because the +17k I maintain in Copr
give me enough headaches. But I'd be happy to help review them too.

Iñaki

> ~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



-- 
Iñaki Úcar

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

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

[Iñaki Ucar]

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

___
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?

[Iñaki Ucar]

RStudio built and update submitted:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7a6c7fd1c1

Iñaki


On Mon, 7 Jun 2021 at 19:53, Tom Callaway  wrote:
>
> 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



-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

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

___
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?

[Iñaki Ucar]

Find attached an ordered build list, one batch per line (Bioc packages
are included). I've pushed the script to [1]. I believe José had more
scripts from the last mass rebuild. If you want to push them too, I
believe (all three of) you should have commit access.

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).

Also, please, let me know when there's a sidetag available with R 4.1,
so that I can start the mass rebuild of the 17k+ packages in [5] (it
takes less than a week, so this shouldn't delay the update).

[1] https://pagure.io/R/packaging/blob/main/f/pkg-build-list.R
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69383481
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69383589
[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=69383669
[5] https://copr.fedorainfracloud.org/coprs/iucar/cran/


On Fri, 4 Jun 2021 at 22:25, Elliott Sales de Andrade
 wrote:
>
> On Fri, 4 Jun 2021 at 16:08, Iñaki Ucar  wrote:
> >
> > This seems like a good opportunity to give this a go: 
> > https://github.com/juhp/fbrnch#parallel-building
> >
>
> I did ask for some enhancements for bootstrap builds there, but I
> don't know how well it works yet. Also, I'm not too sure it
> understands our virtual Provides/BuildRequires, but if that is added,
> then it's a good choice for determining build order.
>
> > On Fri, 4 Jun 2021 at 21:59, Tom Callaway  wrote:
> >>
> >> 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 
> >>  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]]
> >>>> > >
> >>>> > > __

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

[Iñaki Ucar]

This seems like a good opportunity to give this a go:
https://github.com/juhp/fbrnch#parallel-building

On Fri, 4 Jun 2021 at 21:59, Tom Callaway  wrote:

> 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
>>>
>>

-- 
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] Installing R on CentOS 8

[Iñaki Ucar]

On Tue, 25 May 2021 at 13:34, Roger Bos  wrote:
>
> Thanks for your reply.  As the paste below shows, when I try to enable 
> "powertools", I get an error message of "no matching repo".  Mine seems to be 
> proper case "PowerTools".  That command doesn't return anything, so I assume 
> it worked, but "dnf update" still returns the same error.  Any further 
> suggestion greatly appreciated!
>
> [b...@rth.ad.rothschild.com@usd1sapp101 ~]$ dnf config-manager --set-enabled 
> powertools
> Error: This command has to be run under the root user.
> [b...@rth.ad.rothschild.com@usd1sapp101 ~]$ sudo dnf config-manager 
> --set-enabled powertools
> Error: No matching repo to modify: powertools.
> [b...@rth.ad.rothschild.com@usd1sapp101 ~]$ sudo dnf config-manager 
> --set-enabled PowerTools
> [b...@rth.ad.rothschild.com@usd1sapp101 ~]$ sudo dnf update
> CentOS-8 - AppStream  
>   271 MB/s | 5.4 MB 00:00
> CentOS-8 - Base   
>   248 MB/s | 2.2 MB 00:00
> CentOS-8 - PowerTools 
>   5.1 MB/s | 2.0 MB 00:00
> Extra Packages for Enterprise Linux Modular 8 - x86_64
>   594 kB/s | 610 kB 00:01
> Extra Packages for Enterprise Linux 8 - x86_64
>   6.4 MB/s | 9.4 MB 00:01
> 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-core-devel-4.0.5-1.el8.x86_64 requires openblas-devel, but none 
> of the providers can be installed
>   - cannot install the best update candidate for package R-devel-1-1.x86_64
>   - 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)
> [b...@rth.ad.rothschild.com@usd1sapp101 ~]$

On second read, it's actually openblas and openblas-threads what's not
found, which is weirder, because they're in AppStream. I don't know
what's happening here, but it seems it's a configuration problem,
because I cannot reproduce this in a docker container.

Iñaki

> On Tue, May 25, 2021 at 5:34 AM Iñaki Ucar  wrote:
>>
>> On Tue, 25 May 2021 at 03:06, 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)
>>
>> openblas-devel, which is in the powertools repo, is not found above,
>> so it seems you don't actually have powertools enabled. Run:
>>
>> $ dnf config-manager --set-enabled powertools
>>
>> and try again, please.
>>
>> --
>> 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

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

[Iñaki Ucar]

On Tue, 25 May 2021 at 03:06, 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)

openblas-devel, which is in the powertools repo, is not found above,
so it seems you don't actually have powertools enabled. Run:

$ dnf config-manager --set-enabled powertools

and try again, please.

-- 
Iñaki Úcar

___
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?

[Iñaki Ucar]

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

Re: [R-sig-Fedora] Future R 4.1 and Rstudio versions

[Iñaki Ucar]

On Tue, 4 May 2021 at 12:06, Tim Taylor
 wrote:
>
> I've been testing R 4.1 and ran in to an RStudio bug where it crashed
> when used with ggplot2. It seems this has been fixed in an upcoming
> RStudio release (see https://github.com/rstudio/rstudio/issues/9251) but
> I wanted to flag in case the Fedora package maintainers need to
> coordinate the release (e.g. new RStudio prior to new R).

Thanks, Tim, we'll have that in mind. Do you happen to know what's the
schedule for the upcoming RStudio release?

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] (Error?) in a command of your tutorial, "fedora-source"

[Iñaki Ucar]

On Tue, 20 Apr 2021 at 13:29, Bilal Abd  wrote:
>
> Hello, I am contacting you because it seems that there is a problem with your 
> tutorial to install R LIEN, I use a Centos7 server, I have epel and installed 
> R which works, however I cannot install certain libraries which depend on 
> packages like "curl", "TTR" etc ..
> These libraries are available according to your site with the command "dnf 
> repoquery --repo = fedora-source R- *" except that one indicates to me 
> "Error: Unknown repo : fedora-source "I did a lot of research on the internet 
> and this repo does not seem to exist, the only site where I find 
> "fedora-source" is yours ... I tried to replace "fedora- source" by "fedora" 
> or "fedora-packager"etc ... without success ...I also installed curl and 
> Rcurl from the command line (yum install curl etc ...) but that doesn't 
> change anything and curl is just an example of the bigger problem.

That command is for Fedora. Try "repoquery R-*" on CentOS 7. You'll
see that there is a very limited number of packages included in EPEL
7. Also, the R version is outdated, as it is the toolchain available
there, so you won't be able to install many packages from CRAN. My
recommendation is to upgrade to CentOS 8.

-- 
Iñaki Úcar

___
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.css missing in Fedora R-core rpm

[Iñaki Ucar]

FYI, tracked here: https://pagure.io/R/fedora-r-packages/issue/2

On Wed, 10 Mar 2021 at 13:14, Iñaki Ucar  wrote:
>
> On Wed, 10 Mar 2021 at 12:02, Jeroen Ooms  wrote:
> >
> > On Wed, Mar 10, 2021 at 12:18 AM Iñaki Ucar  wrote:
> > >
> > > On Tue, 9 Mar 2021 at 23:55, Jeroen Ooms  wrote:
> > > >
> > > > On Tue, Mar 9, 2021 at 2:27 PM Iñaki Ucar  
> > > > wrote:
> > > > >
> > > > > On Tue, 9 Mar 2021 at 13:26, Jeroen Ooms  wrote:
> > > > > >
> > > > > > When installing an R package from source on Fedora using the 
> > > > > > standard
> > > > > > R-core rpm, we always get a warning at the end because of a missing
> > > > > > css file /usr/share/doc/R/html/R.css:
> > > > > >
> > > > > > ** byte-compile and prepare package for lazy loading
> > > > > > ** help
> > > > > > *** installing help indices
> > > > > > Error in file.copy(file.path(R.home("doc"), "html", "R.css"), 
> > > > > > outman) :
> > > > > >   (converted from warning) problem copying 
> > > > > > /usr/share/doc/R/html/R.css
> > > > > > to 
> > > > > > /usr/lib64/R/library/00LOCK-systemfonts/00new/systemfonts/html/R.css:
> > > > > > No such file or directory
> > > > > >
> > > > > > But when I try to install the missing file, yum says it is already 
> > > > > > installed:
> > > > > >
> > > > > >   yum install /usr/share/doc/R/html/R.css
> > > > > >   ## Package R-core-4.0.3-1.fc32.x86_64 is already installed.
> > > > > >
> > > > > > However it does not actually exist. Perhaps the rpm could make a 
> > > > > > copy
> > > > > > or symlink from /usr/lib64/R/library/base/html/R.css
> > > > >
> > > > > I assume you are doing this in a docker image. That file is not
> > > > > installed because our base images have "tsflags=nodocs" set in
> > > > > /etc/dnf/dnf.conf. Unset this before installing R-core, or, even
> > > > > better, install packages with --no-docs.
> > > >
> > > > Perhaps --no-docs should then be the default if tsflags=nodocs? The
> > > > default behavior is unfortunate, because it makes install.packages()
> > > > fail even if the user is not even interested in documentation, and
> > > > people come up with all sorts of workarounds eg:
> > > > https://github.com/r-lib/devtools/issues/2084
> > >
> > > install.packages doesn't fail. devtools does. I see:
> > >
> > > Warning in file.create(f.tg) :
> > >  cannot create file '/usr/share/doc/R/html/packages.html', reason 'No
> > > such file or directory'
> > > Warning in utils::make.packages.html(.Library, docdir = R.home("doc")) :
> > >  cannot update HTML package index
> > >
> > > The package is correctly installed and usable.
> >
> > Many systems (including devtools, and many others) are set more strict
> > such that installation warnings are turned into errors, to ensure
> > users or applications never ends up installing broken packages.
>
> A warning is not an error. I would expect that R raises an error only
> when the package is really broken. Otherwise, there's no point in
> having warnings and errors. Users have been bitten quite a lot by this
> [1], and as a result, the remotes package (which devtools uses)
> recently stepped out from this odd default behaviour [2] (not yet
> released though).
>
> > Raising this warning by default for every install.packages() is really
> > unfortunate default behaviour, especially because it is evidently
> > unclear to users why this happens.
>
> About what is unclear to users, I refer again to [1]. But note that
> this is *not* default behaviour. It only happens in docker images,
> which have this special setting for a special use case, defined in
> order to minimize image sizes and enforced by the package manager. It
> has nothing to do with the R-core package: it just follows the
> official guidelines and marks documentation files as documentation.
>
> I could add some notes about docker in [3]. Note too that there's an
> easier way to install CRAN packages in Fedora [4].
>
> [1] https://github.com/r-lib/remotes/issues/403
> [2] 
> https://github.com/r-lib/remotes/commit/5a546add30b4538d60d781bc2fa26cd33ccde092
> [3] https://cran.r-project.org/bin/linux/fedora/
> [4] https://cran.r-project.org/bin/linux/fedora/#additional-packages
>
>
> --
> 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

Re: [R-sig-Fedora] R not working in F34 docker image

[Iñaki Ucar]

On Wed, 10 Mar 2021 at 12:22, Jeroen Ooms  wrote:
>
> Not sure if this is a bug in the F34 docker image or R rpm. I would
> like to test some things in F34 so I tried:
>
>   docker run -it fedora:34
>
> And then in docker:
>
>yum update
>yum install R-core
>
> But when I try to start R I get an error:
>
>   ERROR: R_HOME ('/usr/lib64/R') not found

See [1]. TL;DR, this is due to a change in glibc, and needs to be
addressed in runc and/or libseccomp.

However, I cannot reproduce this in Fedora 33 using Docker version
20.10.1, build 831ebea or podman version 3.0.1. So hopefully an update
would solve the issue for you. Otherwise, see the thread in [1] for
workarounds.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1900021#c3

-- 
Iñaki Úcar

___
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.css missing in Fedora R-core rpm

[Iñaki Ucar]

On Wed, 10 Mar 2021 at 12:02, Jeroen Ooms  wrote:
>
> On Wed, Mar 10, 2021 at 12:18 AM Iñaki Ucar  wrote:
> >
> > On Tue, 9 Mar 2021 at 23:55, Jeroen Ooms  wrote:
> > >
> > > On Tue, Mar 9, 2021 at 2:27 PM Iñaki Ucar  wrote:
> > > >
> > > > On Tue, 9 Mar 2021 at 13:26, Jeroen Ooms  wrote:
> > > > >
> > > > > When installing an R package from source on Fedora using the standard
> > > > > R-core rpm, we always get a warning at the end because of a missing
> > > > > css file /usr/share/doc/R/html/R.css:
> > > > >
> > > > > ** byte-compile and prepare package for lazy loading
> > > > > ** help
> > > > > *** installing help indices
> > > > > Error in file.copy(file.path(R.home("doc"), "html", "R.css"), outman) 
> > > > > :
> > > > >   (converted from warning) problem copying /usr/share/doc/R/html/R.css
> > > > > to 
> > > > > /usr/lib64/R/library/00LOCK-systemfonts/00new/systemfonts/html/R.css:
> > > > > No such file or directory
> > > > >
> > > > > But when I try to install the missing file, yum says it is already 
> > > > > installed:
> > > > >
> > > > >   yum install /usr/share/doc/R/html/R.css
> > > > >   ## Package R-core-4.0.3-1.fc32.x86_64 is already installed.
> > > > >
> > > > > However it does not actually exist. Perhaps the rpm could make a copy
> > > > > or symlink from /usr/lib64/R/library/base/html/R.css
> > > >
> > > > I assume you are doing this in a docker image. That file is not
> > > > installed because our base images have "tsflags=nodocs" set in
> > > > /etc/dnf/dnf.conf. Unset this before installing R-core, or, even
> > > > better, install packages with --no-docs.
> > >
> > > Perhaps --no-docs should then be the default if tsflags=nodocs? The
> > > default behavior is unfortunate, because it makes install.packages()
> > > fail even if the user is not even interested in documentation, and
> > > people come up with all sorts of workarounds eg:
> > > https://github.com/r-lib/devtools/issues/2084
> >
> > install.packages doesn't fail. devtools does. I see:
> >
> > Warning in file.create(f.tg) :
> >  cannot create file '/usr/share/doc/R/html/packages.html', reason 'No
> > such file or directory'
> > Warning in utils::make.packages.html(.Library, docdir = R.home("doc")) :
> >  cannot update HTML package index
> >
> > The package is correctly installed and usable.
>
> Many systems (including devtools, and many others) are set more strict
> such that installation warnings are turned into errors, to ensure
> users or applications never ends up installing broken packages.

A warning is not an error. I would expect that R raises an error only
when the package is really broken. Otherwise, there's no point in
having warnings and errors. Users have been bitten quite a lot by this
[1], and as a result, the remotes package (which devtools uses)
recently stepped out from this odd default behaviour [2] (not yet
released though).

> Raising this warning by default for every install.packages() is really
> unfortunate default behaviour, especially because it is evidently
> unclear to users why this happens.

About what is unclear to users, I refer again to [1]. But note that
this is *not* default behaviour. It only happens in docker images,
which have this special setting for a special use case, defined in
order to minimize image sizes and enforced by the package manager. It
has nothing to do with the R-core package: it just follows the
official guidelines and marks documentation files as documentation.

I could add some notes about docker in [3]. Note too that there's an
easier way to install CRAN packages in Fedora [4].

[1] https://github.com/r-lib/remotes/issues/403
[2] 
https://github.com/r-lib/remotes/commit/5a546add30b4538d60d781bc2fa26cd33ccde092
[3] https://cran.r-project.org/bin/linux/fedora/
[4] https://cran.r-project.org/bin/linux/fedora/#additional-packages


--
Iñaki Úcar

___
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.css missing in Fedora R-core rpm

[Iñaki Ucar]

On Tue, 9 Mar 2021 at 23:55, Jeroen Ooms  wrote:
>
> On Tue, Mar 9, 2021 at 2:27 PM Iñaki Ucar  wrote:
> >
> > On Tue, 9 Mar 2021 at 13:26, Jeroen Ooms  wrote:
> > >
> > > When installing an R package from source on Fedora using the standard
> > > R-core rpm, we always get a warning at the end because of a missing
> > > css file /usr/share/doc/R/html/R.css:
> > >
> > > ** byte-compile and prepare package for lazy loading
> > > ** help
> > > *** installing help indices
> > > Error in file.copy(file.path(R.home("doc"), "html", "R.css"), outman) :
> > >   (converted from warning) problem copying /usr/share/doc/R/html/R.css
> > > to /usr/lib64/R/library/00LOCK-systemfonts/00new/systemfonts/html/R.css:
> > > No such file or directory
> > >
> > > But when I try to install the missing file, yum says it is already 
> > > installed:
> > >
> > >   yum install /usr/share/doc/R/html/R.css
> > >   ## Package R-core-4.0.3-1.fc32.x86_64 is already installed.
> > >
> > > However it does not actually exist. Perhaps the rpm could make a copy
> > > or symlink from /usr/lib64/R/library/base/html/R.css
> >
> > I assume you are doing this in a docker image. That file is not
> > installed because our base images have "tsflags=nodocs" set in
> > /etc/dnf/dnf.conf. Unset this before installing R-core, or, even
> > better, install packages with --no-docs.
>
> Perhaps --no-docs should then be the default if tsflags=nodocs? The
> default behavior is unfortunate, because it makes install.packages()
> fail even if the user is not even interested in documentation, and
> people come up with all sorts of workarounds eg:
> https://github.com/r-lib/devtools/issues/2084

install.packages doesn't fail. devtools does. I see:

Warning in file.create(f.tg) :
 cannot create file '/usr/share/doc/R/html/packages.html', reason 'No
such file or directory'
Warning in utils::make.packages.html(.Library, docdir = R.home("doc")) :
 cannot update HTML package index

The package is correctly installed and usable.

> Alternatively, perhaps it makes sense to consider the file
> /usr/share/doc/R/html/R.css to be not part of the documentation,
> because R assumes this file to be available during install.packages().
> Exactly the same R.css file is also included in every installed
> package under html/R.css, even when tsflags=nodocs, so I don't see the
> point of omitting it in the once place where R expects to find it.

-- 
Iñaki Úcar

___
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.css missing in Fedora R-core rpm

[Iñaki Ucar]

On Tue, 9 Mar 2021 at 13:26, Jeroen Ooms  wrote:
>
> When installing an R package from source on Fedora using the standard
> R-core rpm, we always get a warning at the end because of a missing
> css file /usr/share/doc/R/html/R.css:
>
> ** byte-compile and prepare package for lazy loading
> ** help
> *** installing help indices
> Error in file.copy(file.path(R.home("doc"), "html", "R.css"), outman) :
>   (converted from warning) problem copying /usr/share/doc/R/html/R.css
> to /usr/lib64/R/library/00LOCK-systemfonts/00new/systemfonts/html/R.css:
> No such file or directory
>
> But when I try to install the missing file, yum says it is already installed:
>
>   yum install /usr/share/doc/R/html/R.css
>   ## Package R-core-4.0.3-1.fc32.x86_64 is already installed.
>
> However it does not actually exist. Perhaps the rpm could make a copy
> or symlink from /usr/lib64/R/library/base/html/R.css

I assume you are doing this in a docker image. That file is not
installed because our base images have "tsflags=nodocs" set in
/etc/dnf/dnf.conf. Unset this before installing R-core, or, even
better, install packages with --no-docs.

-- 
Iñaki Úcar

___
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 for CentOS 7

[Iñaki Ucar]

On Sat, 31 Oct 2020 at 20:52, H  wrote:
>
> Understood. Since I am running CentOS 7, I guess I could create a CentOS 8 
> docker container and install R in that? I am not planning to upgrade the 
> system to CentOS 8.

Of course, you can do that. With podman it's even easier. But then I'd
use Fedora as the base image instead, because you'll enjoy binary
installations for most of CRAN via Copr [1]. You even have a docker
image ready to go [2]. (Disclaimer: I'm the maintainer of that
project).

[1] https://copr.fedorainfracloud.org/coprs/iucar/cran/
[2] https://hub.docker.com/r/enchufa2/cran2copr/dockerfile

-- 
Iñaki Úcar

___
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 for CentOS 7

[Iñaki Ucar]

Please, see spot's comment in the BZ I linked in my previous comment.
The thing is not that it can't be done (you could install a newer
devtoolset, v8 or v9, build R and use it), the thing is that it cannot
be distributed in EPEL, because we're allowed to build against a
devtoolset, but not depend on it, so the distribution would be broken
(you could not install packages unless you know that you need a
specific devtoolset, so you install and activate it).

On Sat, 31 Oct 2020 at 02:05, Evan Cooch  wrote:
>
> Really? If Iñaki says it can't be done (even using devtools, which I've
> tried), then you need to move on.
>
> On 10/30/2020 8:57 PM, H wrote:
> > On 10/30/2020 05:02 AM, Iñaki Ucar wrote:
> >> Please, do not crosspost. As I said in the Bugzilla issue, R cannot be
> >> further updated in EPEL-7, see
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1871685#c2.
> >>
> >> Iñaki
> >>
> >>
> >> On Fri, 30 Oct 2020 at 02:30, H  wrote:
> >>> I am running R 4.6 under CentOS 7 but would like to upgrade. Just found 
> >>> that 4.0 is available for CentOS 8 but could it be released for CentOS 7 
> >>> as well?
> >>>
> >>> If so, that would be great!
> >>>
> >>> ___
> >>> R-SIG-Fedora mailing list
> >>> R-SIG-Fedora@r-project.org
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
> >>
> > I see. Is anyone running R 4.0 on CentOS 7? If so, how do you do it?
> >
> > ___
> > 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



-- 
Iñaki Úcar

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

[R-sig-Fedora] Rebuild against FlexiBLAS

[Iñaki Ucar]

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

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

[Iñaki Ucar]

On Mon, 27 Jul 2020 at 09:09, Elliott Sales de Andrade
 wrote:
>
> On Tue, 21 Jul 2020 at 11:05, José Abílio Matos  wrote:
> >
> > On Friday, 3 July 2020 18.36.17 WEST Iñaki Ucar wrote:
> > > Nice! What if we create a group "R" on Pagure and a repo
> > > "fedora-scripts" or something like that?
> >
> > I would like to improve the scripts but FWIW here it comes a rough version 
> > of
> > the script I used.
> >
> > The python script loads the csv file and constructs a directed graph and it
> > starts to remove the leave packages (pruning or trimming if you take a
> > gardening analogy).
> >
>
> I'm not exactly fluent in Haskell, but Jens Petersen has a tool called
> fbrnch [1], which is able to calculate the build order, and then
> submit them, and even handles override for non-Rawhide builds. It does
> need you to handle some of the bootstrap conditions yourself, but with
> a defined workflow, it might be possible to request that it handle
> that too.

Very interesting! I poked around a bit and discovered that they use a
Haskell library [1] for that, and a quick search led me to a package
called rpmbuild-order [2]. Never heard of it. So

$ rpmbuild-order sort pkg1 pkg2 pkg3 ...

works nicely. It works by scanning for the packages' SPEC files in the
current working directory, so you need to clone all the repos locally
in the first place.

[1] 
https://github.com/juhp/fbrnch/blob/d37825c1012d35ae3277d0d0185bd55213fdecd2/src/Cmd/Local.hs#L10
[2] https://hackage.haskell.org/package/rpmbuild-order

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Tue, 21 Jul 2020 at 17:05, José Abílio Matos  wrote:
>
> On Friday, 3 July 2020 18.36.17 WEST Iñaki Ucar wrote:
> > Nice! What if we create a group "R" on Pagure and a repo
> > "fedora-scripts" or something like that?
>
> I would like to improve the scripts but FWIW here it comes a rough version of
> the script I used.
>
> The python script loads the csv file and constructs a directed graph and it
> starts to remove the leave packages (pruning or trimming if you take a
> gardening analogy).
>
> The csv files has the dependency of the packages. It is always possible to go
> to the packages that remain after the first stage and using a bootstrap mode
> to remove most of the dependencies and then to run the code again.
>
> This procedure was enough to process all the packages.

Looks great! I've created an R group on Pagure and added you all
(jamatos, qulogic, spot) to it (feel free to add anyone else that may
be interested). Please, create a repo there with these tools. I'll
transfer https://pagure.io/fedora-r-packages there too (if that's
possible; or just mirror it if not).

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

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

Re: [R-sig-Fedora] installing from copr after update

[Iñaki Ucar]

On Wed, 15 Jul 2020 at 10:47, Tim Taylor
 wrote:
>
> I've just updated to R 4.0.2 but am unsure how to get packages from the
> COPR repository to update to those built under the new version of R.
> FI - I'm not currently using CoprManager just trying to update/install from
> terminal.

The Copr repo has been rebuilt under R 4.0.2. Maybe you need to
refresh the metadata to see those updates:

sudo dnf upgrade --refresh

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Tue, 14 Jul 2020 at 18:24, José Abílio Matos  wrote:
>
> On Tuesday, 14 July 2020 09.47.55 WEST Iñaki Ucar wrote:
> > Maybe it's due to the size of the update? File an issue here:
> > https://github.com/fedora-infra/bodhi/issues
>
> Before resorting to this I tried again and this time it worked.
>
> Elliot before had already tried, I got an email message saying:
> bodhi - 2020-07-14 04:47:02.353824 (karma: 0)
> This update has been submitted for stable by qulogic.
>
> Now I got another one saying:
> bodhi - 2020-07-14 16:11:38.021756 (karma: 0)
> This update has been submitted for stable by jamatos.
>
> Let us see if it works this time. :-)

Great, thanks for all the work!

FYI, anyway I opened an issue, because this is likely to hit us in the
future unless it's resolved:
https://github.com/fedora-infra/bodhi/issues/4083

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Tue, 14 Jul 2020 at 01:19, José Abílio Matos  wrote:
>
> On Saturday, 11 July 2020 11.32.32 WEST José Abílio Matos wrote:
> > If I do not hear until then I will push the update Monday night (Western
> > Europe time zone.
>
> Well I tried but I did not succeeded both using the web interface and cli
> interfaces:
>
> b"504 Gateway Time-out\nThe server didn't
> respond in time.\n\n"

Maybe it's due to the size of the update? File an issue here:
https://github.com/fedora-infra/bodhi/issues

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Tue, 7 Jul 2020 at 16:15, Iñaki Ucar  wrote:
>
> On Tue, 7 Jul 2020 at 15:58, José Abílio Matos  wrote:
> >
> > On Tuesday, 7 July 2020 11.44.48 WEST Iñaki Ucar wrote:
> > > Try with the CLI (see "man bodhi"):
> > >
> > > $ bodhi updates edit  --addbuilds 
> >
> > I found that the best call in this case is instead of --addbuilds to use
> > --from-tag since then "this will update the builds to the latest ones in the
> > tag."
> >
> > > BTW, could we coordinate to merge this into stable when I finish
> > > rebuilding stuff in Copr?
> >
> > Sure. I am in no rush to submit this to stable. :-)
>
> Great, I already started. I'll keep you posted.

CRAN rebuilt on Copr. Ready to push to stable.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Tue, 7 Jul 2020 at 15:58, José Abílio Matos  wrote:
>
> On Tuesday, 7 July 2020 11.44.48 WEST Iñaki Ucar wrote:
> > Try with the CLI (see "man bodhi"):
> >
> > $ bodhi updates edit  --addbuilds 
>
> I found that the best call in this case is instead of --addbuilds to use
> --from-tag since then "this will update the builds to the latest ones in the
> tag."
>
> > BTW, could we coordinate to merge this into stable when I finish
> > rebuilding stuff in Copr?
>
> Sure. I am in no rush to submit this to stable. :-)

Great, I already started. I'll keep you posted.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

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

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

[Iñaki Ucar]

On Tue, 7 Jul 2020 at 12:38, José Abílio Matos  wrote:
>
> On Monday, 6 July 2020 21.08.53 WEST Tom Callaway wrote:
> > 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
>
> I have re/built them using the side tag but I do not see how to add them to 
> the
> (bodhi) update.
> I would like to add R-BiocFileCache and R-biomaRt to the update to finish the
> process.
>
> I see that Elliot added three new packages there (thank you) but when I edit 
> the
> update I do not see any field to add new packages, or even to change the 
> existing.

Try with the CLI (see "man bodhi"):

$ bodhi updates edit  --addbuilds 

BTW, could we coordinate to merge this into stable when I finish
rebuilding stuff in Copr?

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Mon, 6 Jul 2020 at 16:40, 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

[Sorry for the dupe, I didn't hit "reply all"]

Wonderful! Now I have 15k packages to rebuild. :)

Have you thought about creating an "R" group in Pagure and toss the
scripts you used into a repo?

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Fri, 3 Jul 2020 at 19:03, José Abílio Matos  wrote:
>
> On Monday, 29 June 2020 13.46.02 WEST Iñaki Ucar wrote:
> > But the mass rebuild process is very different, because releng doesn't
> > follow any particular order (they don't need to, because nothing
> > really changed).
> >
> > The question is whether there is any tool to resolve dependencies and
> > generate a list of builds, as I do with the CRAN database, for an
> > arbitrary list of RPMs. That would be perfect. In theory, this should
> > be possible with dnf, but when I tried, I failed (or my script would
> > theoretically work, but it would take ages to complete). I also took a
> > look at releng's repos on Pagure, but I didn't find any tool to do
> > this either.
> >
> > We should bring this to devel, maybe ask Miro and other Python folks
> > who may have The Method(TM), as they are rebuilding stuff on a daily
> > basis.
>
> I think that I meant the way that the python packages are rebuilt for each new
> python version. I should have said Python mass rebuild.
>
> I took your work as the basis, together with Tom's help and I used dnf to get
> a list of R packages (assuming that their name starts with R- ). The advantage
> of this approach is that it works for CRAN and Bioconductor.
>
> $ dnf list available --disablerepo=\* --enablerepo=rawhide-source R-* | tail -
> n +3 | awk -e '{print $1};' | sed -e 's/\.src$//' > r-packages.txt
>
> That gave the list of the (source) packages to rebuild.
>
> In order to get the list of dependencies I used a similar strategy:
> $ (for p in $(cat r-packages.txt); do echo -n $p, ; dnf -q repoquery --
> disablerepo=\* --enablerepo=rawhide-source --requires $p | sed ':a;N;$!ba;s/
> \n/,/g'; done) > r-packages-dependencies.csv
>
> The resulting file is a csv file with the first column as the package and the
> remaining columns as the dependencies.
>
> Now the idea was to process this file using a python script to create a direct
> graph of dependencies (using networkx). In the process non R packages are
> removed and some dependencies are cleaned (e.g. -devel packages direct to the
> source package).

Nice! What if we create a group "R" on Pagure and a repo
"fedora-scripts" or something like that?

> The advantage of this is that it allows to identify cycles.
>
> My only surprise in this process was to find that several packages require R-
> rpm-macros.
>
> That causes some dependency cycles because R-rpm-macros also requires
> R-rprintf,R-devel,R-knitr,R-stringi,R-testthat.

Are these the packages that require R-rpm-macros or others?

> Since R-rpm-macros is used for Fedora and epel 8 I suggest to remove the
> dependency. Do you agree?

The packages are most probably maintained by Elliott, right? He would
know better why they have this dependency.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Mon, 29 Jun 2020 at 14:25, José Abílio Matos  wrote:
>
> Again you guessed right, that was the main idea. :-)
> As I told above and to reiterate it, the idea of this work is to make it 
> easier to automate the
> process. Similarly to how we do the mass builds for all the packages.

But the mass rebuild process is very different, because releng doesn't
follow any particular order (they don't need to, because nothing
really changed).

The question is whether there is any tool to resolve dependencies and
generate a list of builds, as I do with the CRAN database, for an
arbitrary list of RPMs. That would be perfect. In theory, this should
be possible with dnf, but when I tried, I failed (or my script would
theoretically work, but it would take ages to complete). I also took a
look at releng's repos on Pagure, but I didn't find any tool to do
this either.

We should bring this to devel, maybe ask Miro and other Python folks
who may have The Method(TM), as they are rebuilding stuff on a daily
basis.

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] -specs=/usr/lib/rpm/redhat/redhat-hardened-ld woes

[Iñaki Ucar]

On Mon, 29 Jun 2020 at 11:24, Iñaki Ucar  wrote:
>
> On Mon, 29 Jun 2020 at 10:21, Roger Bivand  wrote:
> >
> > In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD
> > config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R
> > version installed. Very recently, users installing rgdal from source with
> > R installed from RPM are seeing problems, such as those reported in this
> > thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html
> >
> > The diagnosis by Bennet Fauber, that
> >
> > LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
> >
> > is the problem, that LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now'
> > works OK, and that the -specs= conflict with autoconf has not been
> > resolved seems accurate to me (see also
> > https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/,
> > https://bugzilla.redhat.com/show_bug.cgi?id=1343892).
> >
> > I realise that the R RPM needs to follow RH/F standards, but has something
> > happened in the RPM ecosystem recently to poison the -spec/autoconf
> > relationship?
>
> Did something change in rgdal's flags from 1.5-10 to 1.5-12? Because
> the former installs fine. You can see in [1] that it fails since the
> last update.

I see that rgdal changed to C++ recently. The issue is in rgdal,
because the configure script is missing:

CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`

as indicated in Writing R Extensions (note that CPPFLAGS are *not*
CXXFLAGS; I say this because it's a common mistake).

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] -specs=/usr/lib/rpm/redhat/redhat-hardened-ld woes

[Iñaki Ucar]

On Mon, 29 Jun 2020 at 10:21, Roger Bivand  wrote:
>
> In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD
> config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R
> version installed. Very recently, users installing rgdal from source with
> R installed from RPM are seeing problems, such as those reported in this
> thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html
>
> The diagnosis by Bennet Fauber, that
>
> LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
>
> is the problem, that LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now'
> works OK, and that the -specs= conflict with autoconf has not been
> resolved seems accurate to me (see also
> https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/,
> https://bugzilla.redhat.com/show_bug.cgi?id=1343892).
>
> I realise that the R RPM needs to follow RH/F standards, but has something
> happened in the RPM ecosystem recently to poison the -spec/autoconf
> relationship?

Did something change in rgdal's flags from 1.5-10 to 1.5-12? Because
the former installs fine. You can see in [1] that it fails since the
last update.

[1] https://copr.fedorainfracloud.org/coprs/iucar/cran/package/R-CRAN-rgdal/

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] Error: rebuild R-data.table on F32 for R 4.0.2

[Iñaki Ucar]

On Fri, 26 Jun 2020 at 13:12, José Abílio Matos  wrote:
>
> I am at loss here
>
> R-data.table fails to rebuild, the failure happens in the tests where 3 are
> failing.
> https://koji.fedoraproject.org/koji/taskinfo?taskID=46195243
>
> I will continue with the rebuild and let this case to look later or if anyone
> could help I would appreciate. :-)

It's erroring on CRAN too:
https://cran.r-project.org/web/checks/check_results_data.table.html

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Fri, 26 Jun 2020 at 12:09, José Abílio Matos  wrote:
>
> On Friday, 26 June 2020 10.47.13 WEST Iñaki Ucar wrote:
> > I used bcond locally and wrongly assumed that fedpkg build would
> > support --with BCOND and --without BCOND. Instead, the way to activate
> > it is to change to "%bcond_with check" and then revert to
> > "%bcond_without check". The only difference with bootstrap is that
> > "bootstrap" is recognized and a suffix ~bootstrap can be added
> > automatically to the resulting build. So the question is whether we
> > want that suffix or not.
>
> AFAIU the issue is that the bootstrap scheme does not requires to bump the
> release because with the suffix (~) is considered lower while changing from
> "%bcond_with check" to "%bcond_without check" requires to bump the release.
>
> The issue is that koji does not allow 2 builds with the same nvr.
>
> Since we should ensure the upgrade path that also requires to bump the release
> number in rawhide before applying it on f32 (in this particular case).

Then probably sticking to bootstrap is the best option. We should
propose a change of the template SPEC in the guidelines to reflect
that all packages should enclose their suggests and %check into a
%{without boostrap} block, with a "%bcond_with bootstrap" defined on
top.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Fri, 26 Jun 2020 at 11:36, José Abílio Matos  wrote:
>
> On Tuesday, 23 June 2020 16.48.53 WEST Tom Callaway wrote:
> > There are a few of those, but not many.
>
> Hi Tom,
>   I noticed that for example in R-assertthat you have used the bcond:
>
> %bcond_with check
>
> would not it be better to use bootstrap instead to take advantage of:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
>
> I am asking for curiosity since from now on we will need to do this dance once
> a year for the releases that we deem worth (I would expect that to be rawhide
> and the latest stable).
>
> Forgive me if the question does not make sense since I am still trying to make
> sense of this maze. :-)

I used bcond locally and wrongly assumed that fedpkg build would
support --with BCOND and --without BCOND. Instead, the way to activate
it is to change to "%bcond_with check" and then revert to
"%bcond_without check". The only difference with bootstrap is that
"bootstrap" is recognized and a suffix ~bootstrap can be added
automatically to the resulting build. So the question is whether we
want that suffix or not.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

Oh, and maybe in this process we could add to all packages the
requirement on R(ABI) = 4 that Tom implemented.

On Wed, 24 Jun 2020 at 11:42, Iñaki Ucar  wrote:
>
> Thanks, José and Elliott. I can help with reviews.
>
> I attach here a list of batches of CRAN packages to be rebuilt in
> order (batches separated by a blank line), and the script that
> generates it. Hope it helps.
>
> Iñaki
>
> On Wed, 24 Jun 2020 at 11:35, Elliott Sales de Andrade
>  wrote:
> >
> > I could do so, but it wouldn't be until this weekend.
> >
> > Also, Tom mixed in some version bumps to the rebuild, so we'd have to
> > check whether those would actually be okay in a released version. I
> > would also appreciate some review on new (mostly test) dependencies
> > for these bumps.
> >
> > On Tue, 23 Jun 2020 at 09:43, Iñaki Ucar  wrote:
> > >
> > > Maybe Elliott?
> > >
> > > On Tue, 23 Jun 2020 at 15:01, Tom Callaway  wrote:
> > > >
> > > > 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
> > >
> > >
> > >
> > > --
> > > Iñaki Úcar
> >
> >
> >
> > --
> > Elliott
>
>
>
> --
> 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

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

[Iñaki Ucar]

Thanks, José and Elliott. I can help with reviews.

I attach here a list of batches of CRAN packages to be rebuilt in
order (batches separated by a blank line), and the script that
generates it. Hope it helps.

Iñaki

On Wed, 24 Jun 2020 at 11:35, Elliott Sales de Andrade
 wrote:
>
> I could do so, but it wouldn't be until this weekend.
>
> Also, Tom mixed in some version bumps to the rebuild, so we'd have to
> check whether those would actually be okay in a released version. I
> would also appreciate some review on new (mostly test) dependencies
> for these bumps.
>
> On Tue, 23 Jun 2020 at 09:43, Iñaki Ucar  wrote:
> >
> > Maybe Elliott?
> >
> > On Tue, 23 Jun 2020 at 15:01, Tom Callaway  wrote:
> > >
> > > 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
> >
> >
> >
> > --
> > Iñaki Úcar
>
>
>
> --
> Elliott



-- 
Iñaki Úcar
AUC
AsioHeaders
BH
Cairo
DBI
FMStable
NISTunits
R.methodsS3
R6
RColorBrewer
RUnit
Rcpp
RhpcBLASctl
XML
abind
acepack
argon2
assertthat
backports
base64enc
bindr
bit
bitops
brew
chron
clipr
clisymbols
coda
colorspace
combinat
commonmark
crayon
curl
data.table
date
deldir
dichromat
digest
disposables
errors
evaluate
expm
fansi
farver
fastmap
fastmatch
filehash
fontBitstreamVera
fontLiberation
formatR
fortunes
fs
futile.options
gamlss.dist
gee
generics
ggplot2movies
git2r
globals
glue
gmp
gsl
gss
gtable
gtools
hexbin
highlight
highr
import
ini
inline
iterators
jpeg
jsonlite
labeling
lazyeval
listenv
lmodel2
mAr
magrittr
maps
matrixStats
measurements
microbenchmark
mime
mlbench
mvtnorm
ncdf4
nws
packrat
pbdRPC
pbdZMQ
pkgconfig
plogr
png
polyclip
polynom
praise
prettyunits
ps
qcc
qtl
quadprog
rappdirs
rematch
remotes
rlang
rlecuyer
rstudioapi
rsvg
scatterplot3d
sciplot
sfsmisc
snow
sodium
sourcetools
sp
stringdist
stringi
sys
sysfonts
systemfonts
testit
timeDate
tinytest
tkrplot
udunits2
unix
utf8
uuid
viridisLite
waveslim
wavethresh
webp
wesanderson
whisker
withr
xfun
xml2
xmlparsedata
xtable
yaml
zeallot
zoo

R.oo
RCurl
RInside
RcppCCTZ
Rmpfr
V8
ape
askpass
biglm
bindrcpp
bit64
caTools
car
cli
corpus
debugme
diffobj
ellipsis
foreach
fts
future
gdata
gdtools
getPass
htmltools
hunspell
igraph
itertools
jqr
lambda.r
later
lifecycle
lmtest
lokern
lubridate
mapproj
markdown
memoise
mockr
msm
munsell
plyr
poLCA
prettycode
processx
purrr
reticulate
rex
rgdal
rgeos
rprintf
rprojroot
rversions
sandwich
showtextdb
simmer
statnet.common
stringr
tikzDevice
timeSeries
tinytex
tweenr
units
webutils

Bessel
R.utils
RM2
callr
desc
doParallel
futile.logger
gplots
here
htmlwidgets
knitr
multcomp
nanotime
openssl
orcutt
pingr
promises
qpdf
quantities
reshape
reshape2
scales
selectr
sessioninfo
showtext
svglite
systemfit
unitizer
vctrs
websocket
xopen

R.cache
R.devices
blob
cyclocomp
hms
httpuv
httr
jose
pdftools
pillar
pkgbuild
profvis
rmarkdown
rsconnect
spelling
tidyselect

R.rsp
RSQLite
gargle
gh
pkgload
prettydoc
progress
rcmdcheck
repr
reprex
rvest
shiny
tibble
tufte
whoami

IRdisplay
cellranger
cliapp
dplyr
foghorn
forcats
gapminder
ggplot2
miniUI
nycflights13
readr
rematch2
repurrrsive
roxygen2
testthat

IRkernel
dbplyr
dtplyr
gmailr
haven
lintr
mockery
parsedate
pkgdown
readxl
styler
tidyr
usethis

broom
devtools
rhub

geepack
modelroptions(repos = "https://cloud.r-project.org;)

get_build_list <- function(pkgs, cran=available.packages()) {
  base <- rownames(installed.packages(priority="high"))
  pkgs <- lapply(tools::package_dependencies(pkgs, db=cran), setdiff, base)
  pkgs <- lapply(Filter(Negate(is.null), pkgs), inte

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

[Iñaki Ucar]

On Tue, 23 Jun 2020 at 17:01, José Abílio Matos  wrote:
>
> On Tuesday, 23 June 2020 14.01.39 WEST Tom Callaway wrote:
> > At this point, I simply don't have the time.
> >
> > Tom
>
> What needs to be done and how can the work be streamlined?
>
> I asked this since this procedure will happen for other updates (in one year I
> know but time flies).
>
> I am a provenpackager so that I can drive the process.

Great, thanks! :) Basically, we need (correct me if I'm wrong, Tom):

1) A new user side tag.
2) For R, merge master in F32 and send a build to that side tag.
3) For all packages, either merge master into F32 or just increase the
release version and send builds to that side tag *in order*.
4) When everything is built, create an update from that side tag.

I have tooling in my Copr repo to resolve CRAN dependencies and create
a list of lists of builds in order. I can give you that. But note that
Bioc packages (and others) are not included.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

Maybe Elliott?

On Tue, 23 Jun 2020 at 15:01, Tom Callaway  wrote:
>
> 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



-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

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

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

[Iñaki Ucar]

On Tue, 9 Jun 2020 at 04:42, 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.

Much appreciated.

> There are two new packages that I created that are needed for R-biomaRt to
> be updated:
>
> R-AnnotationDbi
> https://bugzilla.redhat.com/show_bug.cgi?id=1845360
>
> R-BiocFileCache
> https://bugzilla.redhat.com/show_bug.cgi?id=1845362
>
> They are relatively simple noarch packages and should be quick reviews.
> Help in getting these reviewed quickly would be appreciated.

I took them. In progress.

> 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.

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] Changing the BLAS from openblas on a F32 box

[Iñaki Ucar]

FYI, USE_LOCKING=1 has been toggled in Fedora, so the next openblas
release (0.3.9-3) will be thread-safe by default.

On Wed, 27 May 2020 at 23:46, Iñaki Ucar  wrote:
>
> On Wed, 27 May 2020 at 23:03, Gavin Simpson  wrote:
> >
> > Thanks (again) Iñaki.
> >
> > There was a typo in my reply above. I should have said: I *can't*
> > answer the question re USE_LOCKING=1.
>
> :)
>
> > Those other suggestions are really helpful too; I really didn't
> > understand what the difference was (I'm still not clear what the
> > differences are between say openblas-openmp and openblas-openmp64),
> > but I did get R to pass mgcv's thread safe test with both
> > openblas-openmp and blis-openmp, so I have aliased those options for
> > use too.
>
> Basically, openblas has a number of features that can be enabled or
> disabled: 64-bit integer support, threading and parallelization of
> certain parts using openmp (as, e.g., data.table does). With the
> combination of these features, we end up with many different flavors,
> and all these are compiled and sub-packaged separately.
>
> Usually, you want parallelization at the top level calling a serial
> version, as mgcv does. Otherwise, you may end up with an "explosion"
> of threads that is counterproductive.
>
> --
> 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

Re: [R-sig-Fedora] Changing the BLAS from openblas on a F32 box

[Iñaki Ucar]

On Wed, 27 May 2020 at 23:03, Gavin Simpson  wrote:
>
> Thanks (again) Iñaki.
>
> There was a typo in my reply above. I should have said: I *can't*
> answer the question re USE_LOCKING=1.

:)

> Those other suggestions are really helpful too; I really didn't
> understand what the difference was (I'm still not clear what the
> differences are between say openblas-openmp and openblas-openmp64),
> but I did get R to pass mgcv's thread safe test with both
> openblas-openmp and blis-openmp, so I have aliased those options for
> use too.

Basically, openblas has a number of features that can be enabled or
disabled: 64-bit integer support, threading and parallelization of
certain parts using openmp (as, e.g., data.table does). With the
combination of these features, we end up with many different flavors,
and all these are compiled and sub-packaged separately.

Usually, you want parallelization at the top level calling a serial
version, as mgcv does. Otherwise, you may end up with an "explosion"
of threads that is counterproductive.

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] Changing the BLAS from openblas on a F32 box

[Iñaki Ucar]

On Wed, 27 May 2020 at 21:40, Gavin Simpson  wrote:
>
> Thanks Iñaki, that is exactly what i was looking for, esp the last
> option which I have now configured as an alias for easy remembering.
>
> I can answer the question re USE_LOCKING=1. I think that using both
> those options is required to get thread-safety even if openblas was
> compiled for single thread use. I don't know to what extent Simon has
> engaged with upstream on this etc.

I've seen that there is a brief note about this in the project's wiki.
I agree that a sensible default in any distro would be to build
openblas-serial with USE_LOCKING=1. But I don't understand why there
is no recommendation upstream (or I didn't find it besides the note in
the wiki) and there's no idea about the performance penalty that we
incur doing so. I brought this topic to fedora-devel.

> All I know is that using the openblas shipped with Fedora for R is
> currently a recipe for disaster for the large GAMs we're trying to
> fit. But being able to switch to atlas temporarily is a good
> alternative.

Note that switching to openblas-openmp (libopenblaso.so) should be
thread-safe and will probably get you a better performance than Atlas.
Also, Fedora packages blis (which provides
/lib64/blisblas/libblas.so.3). It seems to be thread-safe should be
more performant than Atlas too.

-- 
Iñaki Úcar

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

Re: [R-sig-Fedora] Changing the BLAS from openblas on a F32 box

[Iñaki Ucar]

Hi Gavin,

On Wed, 27 May 2020 at 01:15, Gavin Simpson  wrote:
>
> Dear list,
>
> What is the recommended incantation on Fedora 32 to swap out the
> openblas BLAS that the packaged (rpm) version of R-core installs for
> ATLAS?

I'm afraid there is no official mechanism in place to do that yet.
There was a proposal [1], but it was never pushed forward due to some
issues and lack of time. There's a simple hack you can do though.

Since recently, R in Fedora no longer uses openblas-Rblas and links
against system openblas, as you can see here:

$ ldd /usr/lib64/R/bin/exec/R | grep blas
libopenblas.so.0 => /lib64/libopenblas.so.0 (0x7f8fff849000)

So one simple trick to override that is something along these lines:

$ mkdir ~/blas
$ ln -s /lib64/atlas/libsatlas.so.3 ~/blas/libopenblas.so.0
$ LD_LIBRARY_PATH=~/blas ldd /usr/lib64/R/bin/exec/R | grep blas
libopenblas.so.0 => /home//blas/libopenblas.so.0
(0x7f78b3ea2000)

As you can see, now R points to the link in my home, which in turn
points to system's atlas. Now you can define an alias in your .bashrc
to always prepend that override to R and Rscript. If you remove the
link in your home, it will default to system's openblas. If you point
it to another BLAS implementation, it will pick it up.

Hope it helps.

[1] https://fedoraproject.org/w/index.php?title=PackagingDrafts:BLAS_LAPACK

> If anyone is interested, the issue Simon Wood reports with openblas
> and *mgcv* is:
>
> Issues:
>
> ** openblas 0.3.x x<7 is not thread safe if itself compiled for single thread
>use and then called from multiple threads (unlike the reference BLAS, say).
>0.2.20 appears to be OK. For 0.3.x x>6 make USE_THREAD=0 USE_LOCKING=1
>to make openblas ensures thread safety (currently unclear if USE_LOCKING
>will be default from 0.3.7).

Does this mean that single-threaded openblas should be built with
USE_LOCKING=1 by default? Is there any upstream recommendation about
this?

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Sat, 16 May 2020 at 10:26, José Abílio Matos  wrote:
>
> On Saturday, 16 May 2020 00.38.34 WEST Iñaki Ucar wrote:
> > Sorry, but I'm not sure I'm following you. How does having
> > /usr/lib64/R/library as system library prevent you from testing
> > r-devel?
>
> First the context, we are speaking of srpms.
>
> Use case: you want to test a pre-version of R before it is released and you
> want to do it using dnf while not having to de-install the current version,
> with all its libraries.
>
> Since the purpose is both to install and test both r-devel and the rpm
> packages the goal should be that the spec file should be as close as possible
> to the final spec file.
>
> What I am saying is that by experience it is easier to test and adapt a spec
> file if only a small number of conditionals are needed to use the current spec
> file.
> As far as I remember, from Miro's messages in fedora-devel, that is what is
> being done in the python packages.
> That is also what I have done for other packages, although not a language,
> like lyx.
>
> I hope that now it makes sense,

Makes sense. Then I think it's worthwhile paying attention at what
Dirk does for Debian. Debian's system path for R libraries is not
versioned, and neither it is the path for the r-devel package they
provide. Instead, r-devel stuff goes to /usr/local, and the binaries
are renamed as RD, RDscript. Finally, the R_LIBS_SITE variable in the
Renviron file takes the library under /usr/local first, then the
official system path /usr/lib/R/library.

Why is that? First, if you want to test r-devel, but you don't have
any packages, it makes little sense. But 90% of the time, the packages
compiled for the current version of R just work for r-devel, and
that's why /usr/lib/R/library is in their Renviron for r-devel. At
some point, a breaking change happens and some packages require
rebuilding. Then you can rebuild those few packages and place them
either under /usr/local or in your user dir, because both of them take
precedence, while continuing to reuse system libraries that still work
for r-devel.

So, wrapping up, there are 3 things that you need to do in the spec to
build r-devel as an RPM and test it: 1) redefine %{_libdir} and
%{_datadir} to include /local/; 2) modify the line that echoes
R_LIBS_SITE to the Renviron at your convenience (including or not the
official system path); 3) rename the executables to something like RD
and RDscript. And I think we could simply set up a Copr repo for this.
Maybe I'll do that.

That said, without any Copr repo, there are easier and faster ways to
test r-devel:

$ podman run --rm -it rocker/r-devel RD

and you're ready to go in a minute. :)

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Sat, 16 May 2020 at 00:49, José Abílio Matos  wrote:
>
> If we take the example from python where I have installed versions from python
> 3.4 to 3.9 (that is yet in alpha stage).
>
> # rpm -qf /usr/bin/python3.?
> python34-3.4.10-10.fc32.x86_64
> python35-3.5.9-1.fc32.x86_64
> python36-3.6.10-2.fc32.x86_64
> python37-3.7.7-1.fc32.x86_64
> python3-3.8.2-2.fc32.x86_64
> python39-3.9.0~a6-1.fc32.x86_64
>
> The only version where I have python packages installed is for 3.8 (since I am
> using Fedora 32 - as it can be seen above).
>
> That allows me to test the base version for python without having to compile
> every time and every where I want to use it.
>
> And although it was not my initial motivation but you probably saw the
> discussion today on R-devel (Rd) about people not testing the versions alpha,
> beta and rc from r-devel.
> A versioned system path would allow to test this more easily.

Sorry, but I'm not sure I'm following you. How does having
/usr/lib64/R/library as system library prevent you from testing
r-devel?

But anyway, I'm only saying that, independently of the path, we can
benefit from the R(ABI) virtual provide, as Python does.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Fri, 15 May 2020 at 11:58, José Abílio Matos  wrote:
>
> On Thursday, 14 May 2020 23.58.02 WEST Iñaki Ucar wrote:
> > But we still have to rebuild the packages anyway, and this setup
> > doesn't force us to actually rebuild them, nor the user to update
> > them. So a user could end up with R major.minor and a bunch of
> > packages installed in some major.minor-1 path that are just junk. Or
> > the other way around: a bunch of packages updated under major.minor+1
> > with a previous version of R.
>
> Honestly my point here was for consistency with the user settings.
> If you have per version directories for users why not to do the same for the
> system?

The rationale behind the user settings is that the user dir is not
controlled by the system, so versioning it is the only way to avoid
breakage. For the system library, there are better tools to prevent
that.

> > I mean, +1 to less boilerplate for packages, but changing the release
> > + the ABI specification is not a big deal and solves those issues. For
> > me, having a path with full version specification only makes sense if
> > there is more than one version installed at the same time, like
> > Python.
>
> That would also be a nice side effect. :-)

Are you suggesting that we should maintain several versions of R at
the same time? I don't think we want or should go down that path... :D

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Fri, 15 May 2020 at 00:23, José Abílio Matos  wrote:
>
> On Thursday, 14 May 2020 21.30.13 WEST Iñaki Ucar wrote:
> > Mmmh... but then you have to change that in the packages' SPEC and
> > rebuild them anyway when you update R. So... what's the advantage of
> > this?
>
> We already have other examples of how to do this with less steps. :-)
>
> Create macros like
>
> %{r_sitearch}
> %{r_sitelib}
>
> that expand with the R version being used and place them in R-rpm-macros and
> change all the R srpms to use them. We can also contribute changes to srpm
> generators like https://pagure.io/r2spec.
>
> This is a one-time change.
>
> Then when a new R version shows up it is enough to bump the release and
> rebuild the package. With the added advantage that all the cobwebs and dust
> are cleaned. :-)
>
> Another advantage is that the boilerplate code required to create a srpm
> package decreases. :-)

But we still have to rebuild the packages anyway, and this setup
doesn't force us to actually rebuild them, nor the user to update
them. So a user could end up with R major.minor and a bunch of
packages installed in some major.minor-1 path that are just junk. Or
the other way around: a bunch of packages updated under major.minor+1
with a previous version of R.

I mean, +1 to less boilerplate for packages, but changing the release
+ the ABI specification is not a big deal and solves those issues. For
me, having a path with full version specification only makes sense if
there is more than one version installed at the same time, like
Python.

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Thu, 14 May 2020 at 21:41, José Abílio Matos  wrote:
>
> On Monday, 11 May 2020 16.47.55 WEST Iñaki Ucar wrote:
> > 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.
>
> Something that I have been wondering for some time, previous to this thread,
> is why is not this the default also for system installation and not just for
> users installs.
>
> With this I mean to have the system directories to be respectively:
>
> %{__libdir}|%{__datadir}/R.
>
> Is this due to inertia or are there other reasons. That would naturally solve
> the need to rebuild for each minor release. The major point here is that would
> apply not only to our packages but also for others installed using R itself.

Mmmh... but then you have to change that in the packages' SPEC and
rebuild them anyway when you update R. So... what's the advantage of
this?

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

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

___
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

[Iñaki Ucar]

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

Re: [R-sig-Fedora] R 4.0.0

[Iñaki Ucar]

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

___
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

[Iñaki Ucar]

On Mon, 4 May 2020 at 18:34, José Abílio Matos  wrote:
>
> Hi Iñaki,
>   just tangentially related to this subject, what is the status of the copr 
> that you have
> related with automatic build of R packages?

Hi, José, the Copr repo is working great! I wrote a brief note about
it [1], and the README contains further details [2]. I use it in all
my machines and the servers I maintain, and I'm very happy with it.
Every day, a GitHub action checks which packages where
updated/added/archived on CRAN and triggers the corresponding builds.

[1] 
https://www.enchufa2.es/archives/cran2copr-rpm-repos-with-15k-binary-r-packages.html
[2] https://copr.fedorainfracloud.org/coprs/iucar/cran/

-- 
Iñaki Úcar

___
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

[Iñaki Ucar]

On Mon, 4 May 2020 at 16:27, 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.

I imagined he was very busy, but didn't know he was moving. Thanks!

> 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

I obviously meant **rather outdated**.

> 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

-- 
Iñaki Úcar

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

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

[Iñaki Ucar]

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

Re: [R-sig-Fedora] library ( vctrs ) + library ( ggplot2 )

[Iñaki Ucar]

On Wed, 26 Feb 2020 at 09:11, Orlando Ramirez  wrote:
>
> Hi i need use these 2 librarys  ( vctrs ) and ( ggplot2 ) , and the 2 
> librarys are installed in my Rstudio
>
> RStudio
> Version 1.2.5033
> © 2009-2019 RStudio, Inc.
> "Orange Blossom" (330255dd, 2019-12-04)
> but i got all times thesse messagesplease help-me...thanks lot of
> > library ( vctrs ) Error: package or namespace load failed for ‘vctrs’ in 
> > loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]):
>  namespace ‘rlang’ 0.4.0 is being loaded, but >= 0.4.2 is required

The message is pretty clear: you need to update rlang.

> > library ( ggplot2 )
> Error: package or namespace load failed for ‘ggplot2’:
>  .onLoad failed in loadNamespace() for 'pillar', details:
>   call: utils::packageVersion("vctrs")
>   error: there is no package called ‘vctrs’
> >
>
>
>
>   orlandomontr...@yahoo.com
> [[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

[R-sig-Fedora] CRAN RPM repositories available

[Iñaki Ucar]

Hi all,

I apologize if you are receiving multiple copies of this email, but
I'm cross-posting because I believe this may be of interest to a wider
audience than just R-SIG-Fedora.

This is to announce that I'm maintaining a Copr project [1] that
provides RPM repos for Fedora 30, 31 and rawhide for most of CRAN
(currently, almost 15k packages), and they are automatically
synchronized with CRAN (removing archived packages and building new
updates) on a daily basis.

Please, feel free to use them. For further details, see the overview
page [1]. Bug reports and feedback are more than welcome [2].

[1] https://copr.fedorainfracloud.org/coprs/iucar/cran
[2] https://github.com/Enchufa2/cran2copr/issues

Regards,
-- 
Iñaki Úcar

___
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 (language) + install.packages("DMwR") :

[Iñaki Ucar]

On Fri, 7 Feb 2020 at 00:30, Orlando Ramirez  wrote:
>
> Hi:please i am working on fedora 31, then i installed R (language), and i 
> want to install a R package ("DMwR"), but i get these warning messages ...:
>
> The downloaded source packages are in
> ‘/tmp/RtmpCBUyte/downloaded_packages’
> Updating HTML index of packages in '.Library'
> Making 'packages.html' ... done
> Warning messages:
> 1: In install.packages("DMwR") :
>   installation of package ‘curl’ had non-zero exit status
> 2: In install.packages("DMwR") :
>   installation of package ‘TTR’ had non-zero exit status
> 3: In install.packages("DMwR") :
>   installation of package ‘quantmod’ had non-zero exit status
> 4: In install.packages("DMwR") :
>   installation of package ‘DMwR’ had non-zero exit status
>
> i tried to install the packages  ‘curl’ ,  ‘TTR’,  and ‘quantmod’ but i got 
> error all time...could you help me...thanks

Did you take a look at the error message when you try to install curl?
This is because all these packages depend on curl, which in turn
requires curl-devel. You may install curl-devel in your system and
then try again.

Yet another posibility now for you is:

sudo dnf copr enable iucar/cran
sudo dnf install R-CRAN-DMwR

That's a Fedora repo I maintain with nearly 15k CRAN packages. Not the
entire CRAN, but close enough.

Iñaki

___
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 from EPEL 8 missing dependency on glibc-langpack

[Iñaki Ucar]

Reported here: https://github.com/CentOS/sig-cloud-instance-images/issues/154

Iñaki

On Mon, 7 Oct 2019 at 14:52, Iñaki Ucar  wrote:
>
> On Mon, 7 Oct 2019 at 11:13, Jeroen Ooms  wrote:
> >
> > I think R from EPEL 8 is missing a dependency on glibc-langpack-en or
> > similar. Testing with the new CentOS 8 docker image:
>
> This never was a dependency. There is no reason to depend particularly
> on an English locale.
>
> >docker run -it centos:8 bash
> >
> > And then in docker:
> >
> >yum install epel-release
> >yum config-manager --set-enabled PowerTools
> >yum install R-devel
> >
> > Installation succeeds but when I start R:
> >
> > During startup - Warning messages:
> > 1: Setting LC_CTYPE failed, using "C"
> > 2: Setting LC_COLLATE failed, using "C"
> > 3: Setting LC_TIME failed, using "C"
> > 4: Setting LC_MESSAGES failed, using "C"
> > 5: Setting LC_MONETARY failed, using "C"
> > 6: Setting LC_PAPER failed, using "C"
> > 7: Setting LC_MEASUREMENT failed, using "C"
> >
> > Installing glibc-langpack-en fixes the problem. Took me a while to
> > figure this out; I am guessing a lot of users will run into this.
>
> This has nothing to do with R. This is the issue:
>
> $ locale
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
>
> If you try Centos 7:
>
> $ locale
> LANG=
> LC_CTYPE="POSIX"
> LC_NUMERIC="POSIX"
> LC_TIME="POSIX"
> LC_COLLATE="POSIX"
> LC_MONETARY="POSIX"
> LC_MESSAGES="POSIX"
> LC_PAPER="POSIX"
> LC_NAME="POSIX"
> LC_ADDRESS="POSIX"
> LC_TELEPHONE="POSIX"
> LC_MEASUREMENT="POSIX"
> LC_IDENTIFICATION="POSIX"
> LC_ALL=
>
> And if you try Fedora rawhide:
>
> $ locale
> LANG=C.UTF-8
> LC_CTYPE="C.UTF-8"
> LC_NUMERIC="C.UTF-8"
> LC_TIME="C.UTF-8"
> LC_COLLATE="C.UTF-8"
> LC_MONETARY="C.UTF-8"
> LC_MESSAGES="C.UTF-8"
> LC_PAPER="C.UTF-8"
> LC_NAME="C.UTF-8"
> LC_ADDRESS="C.UTF-8"
> LC_TELEPHONE="C.UTF-8"
> LC_MEASUREMENT="C.UTF-8"
> LC_IDENTIFICATION="C.UTF-8"
> LC_ALL=
>
> I'm not sure why en_US.UTF-8 ended up in the Centos 8 image, but it
> should be C.UTF-8 instead.
>
> Iñaki



-- 
Iñaki Úcar

___
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 from EPEL 8 missing dependency on glibc-langpack

[Iñaki Ucar]

On Mon, 7 Oct 2019 at 11:13, Jeroen Ooms  wrote:
>
> I think R from EPEL 8 is missing a dependency on glibc-langpack-en or
> similar. Testing with the new CentOS 8 docker image:

This never was a dependency. There is no reason to depend particularly
on an English locale.

>docker run -it centos:8 bash
>
> And then in docker:
>
>yum install epel-release
>yum config-manager --set-enabled PowerTools
>yum install R-devel
>
> Installation succeeds but when I start R:
>
> During startup - Warning messages:
> 1: Setting LC_CTYPE failed, using "C"
> 2: Setting LC_COLLATE failed, using "C"
> 3: Setting LC_TIME failed, using "C"
> 4: Setting LC_MESSAGES failed, using "C"
> 5: Setting LC_MONETARY failed, using "C"
> 6: Setting LC_PAPER failed, using "C"
> 7: Setting LC_MEASUREMENT failed, using "C"
>
> Installing glibc-langpack-en fixes the problem. Took me a while to
> figure this out; I am guessing a lot of users will run into this.

This has nothing to do with R. This is the issue:

$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

If you try Centos 7:

$ locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

And if you try Fedora rawhide:

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

I'm not sure why en_US.UTF-8 ended up in the Centos 8 image, but it
should be C.UTF-8 instead.

Iñaki

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

Re: [R-sig-Fedora] Fedora 29 upgrade: texlive-scheme-medium may depend on R (texlive-includernw)

[Iñaki Ucar]

On Sat, 10 Nov 2018 at 19:12, Roger Bivand  wrote:
>
> My point exactly. It should only run R RHOME to check for the existence of
> R (if this is what it does) at run time, not at install time. If it then,
> at run time, does not find R, or having found R does not find knitr
> (though Sweave is part of utils, so knitr is only needed by those using
> knitr to weave Rnw documents, or to convert from Rmd), it should issue
> helpful error messages to tell the user to install R, or to install knitr
> within R. By requiring to see R when being run by root/admin at install
> time, it is making invasive assumptions about the user environment.
>
> It could be that the texlive-includernw package itself does not require
> install time dependency fulfillment, and that this is something only the
> Fedora texlive packager has mis-understood.

Texlive packages don't require anything at build time, so Andreas has
nothing to do with this issue. The description of his package claims
that R and knitr are required at run time, so the Fedora packager (Tom
'spot' Callaway, in CC now) had to take a decision: either to avoid
non-texlive dependencies, which results in a broken installation
(texlive-includernw won't work without R), or to be more user-friendly
and install all the required run time dependencies.

Tom took the second path, as he did too with texlive-graphicxpsd, for
instance, which requires ImageMagick. Of course, this doesn't work for
you, but admittedly, having an R installation under your home
directory is not a typical case. I don't know whether there's any
official packaging guideline about this (i.e., non-texlive
dependencies vs. installing non-working texlive packages). If not, you
could ask Tom to reconsider his decision.

Iñaki

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

Re: [R-sig-Fedora] Fedora 29 upgrade: texlive-scheme-medium may depend on R

[Iñaki Ucar]

On Sat, 10 Nov 2018 at 15:17, Roger Bivand  wrote:
>
> On upgrading my F28 to F29, I've found that R-core and a number of R
> packages:
>
> R-evaluate R-glue R-highr R-knitr R-magrittr R-markdown R-mime R-stringi
> R-stringr R-yaml
>
> are installed, although I only ever install R from source and always keep
> my Rs locally. So I don't use Fedora R rpms, but these were installed
> without my command.
>
> Something in texlive is doing this. A remedy is to yse rpm -r --nodeps <>
> to get rid of them, because dnf remove R-core takes out texlive too. I do
> use the RStudio rpm, but by command-line install, so it isn't the culprit.
> However, the choice of packages points to an injudicious editing of an rpm
> dependency list in some texlive package related to rmarkdown or similar.

$ dnf repoquery --tree --whatrequires R-knitr

texlive-scheme-medium installs texlive-collection-mathscience, which
installs texlive-includernw, which necessarily depends on R-knitr.

The solution is not to depend on texlive collections. Install
texlive-scheme-basic instead, plus additional packages as you need
them.

Iñaki

> I'm reporting this here in case other Fedora users are puzzled to see
> another R (or an rpm R) appearing on their systems if they also use
> texlive.
>
> If anyone has any ideas about resolving this properly, I'd be grateful (it
> isn't the best way to spread the use of R among Fedora texlive users IMO).
> Unfortunately, DNF/RPM and likely other packaging systems have issues
> detecting user-installed programs like R, so trying "R RHOME" isn't going
> to work when say ~/bin is where R lives. Almost certainly, the texlive
> component should not be included in any scheme groups.
>
> I would CC RStudio, but support does not expose an email, so I'm CC-ing
> the rmarkown maintainer.
>
> Roger
>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
> http://orcid.org/-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0J=en
>
> ___
> 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