Re: [R-sig-Debian] R

[Dirk Eddelbuettel]

Hi,

Can you please resend, but this time not in html format?  The mailing list
manager software swallows html; your email did not contain any plain text so
there is nothing for us to read and (hopefully) help you with.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] [R] Why Rprofile.site is not built with manual installation of R devel in linux?

[Martin Maechler]

> Jeff Newmiller via R-help 
> on Thu, 09 Nov 2023 12:08:07 -0800 writes:

> No clue. Tip: R-devel is the mailing list for anything
> related to development versions of R. Off-topic here.

Yes.  Alternatively, as he uses Debian, there's the
R-SIG-Debian  mailing list, too.

--> I'm CC'ing  both R-devel and R-SIG-Debian instead of R-help.

> On November 9, 2023 2:59:44 AM PST, "Iago Giné Vázquez" 
 wrote:
>> Hi all,
>> 
>> I downloaded R-devel as explicited in 
https://developer.r-project.org/SVNtips.html
>> Then, I tried to install it through instructions in 
https://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Installation
>> (taking into account also 
https://stat.ethz.ch/pipermail/r-devel/2016-May/072777.html)
>> So:
>> export REPOS=https://svn.r-project.org/R
>> export RTOP=~ #adjust as necessary
>> cd $RTOP
>> svn co $REPOS/trunk r-devel/R
>> cd r-devel/R
>> tools/rsync-recommended
>> mkdir ../build-R
>> cd ../build-R
>> ../R/configure --prefix=/where/you/want/R/to/go
>> make
>> make check

all fine till here.

I never do the following two (they are not necessary, if you
keep your  .../r-devel/build-R/  directory and  symlink the
.../r-devel/build-R/bin/R  to some  /R-devel
{which is what I do all the time; by that I can easily symlink
to more than one of different R-devel- versions etc}

Still I cannot believe that these are the problem.

>> make install
>> make install-tests

>> cd tests
>> ## followed by one of
>> ../bin/R CMD make check
>> ../bin/R CMD make check-devel

I've never used../bin/R CMD make check
instead of simply  make check
(which you already did earlier),
and ditto replacing 'check' with 'check-devel'.

But even if I do that now, I don't get your error,
*and*  I have not made use of an  Rprofile.site  for a very long time
(and do *not* have any inside (my variant of your) build-R/


>> And here I get the following error
>> checking package 'base'
>> Error in file(filename, "r", encoding = encoding) :
>> cannot open the connection
>> Calls: source -> file
>> In addition: Warning message:
>> In file(filename, "r", encoding = encoding) :
>> cannot open file '.../etc/Rprofile.site': No such file or directory
>> Execution halted

You must have forgotten to tell us a bit more about your setup.
I never get the above error,
and I do *not* have an  Rprofile.site  either in my  /etc/

Have you by chance set an R_LIBS_SITE or similar environment
variable ?
Does
env | grep '^R_'

give a hint?

>> where the dots ... specify the path to the build-R folder where R-devel 
was built. And I check the etc folder and indeed there is no the Rprofile.site
>> -rw-r--r-- 1 iago iago  209 Nov  9 08:27 javaconf
>> -rw-r--r-- 1 iago iago  770 Nov  9 08:35 ldpaths
>> -rw-r--r-- 1 iago iago 6672 Nov  9 08:35 Makeconf
>> -rw-r--r-- 1 iago iago 3336 Nov  9 08:27 Makefile
>> -rw-r--r-- 1 iago iago 1853 Nov  9 08:27 Renviron
>> -rw-r--r-- 1 iago iago 1173 Nov  9 08:32 repositories


>> I note that make install installed R in the path I specified in  
../R/configure --prefix=/where/you/want/R/to/go
>> however
>> 1. make install-tests installed the tests folder in build-R .

Are your sure?  I don't see how it would do this when I do

make -n install-tests

(the `-n` "simulates" the make and tells you what make *would* do if you left 
away the `-n`)
Rather it would (try to) install to the same place that

make -n install

would do , namely the  $PREFIX/tests/  directory.
Maybe you are just confused, because indeed, your
.../build-R/tests/  directory also contains many of the files
needed for the tests {but not e.g. the crucial *.R  ones !}.


>> 2.  In the installed R in /where/you/want/R/to/go, there is no even etc 
folder, there are only the folders bin, lib and share.

>> Am I  skipping some step? I am on Debain 12.
Deb*ia*n  {Debora(h) + Ian }

Could it be that the Debian/Ubuntu default (for *their* build of
/usr/bin/R ) where they indeed use an  Rprofile.site and hence
that Debian-specific setup is hurting you here  in some way?

I'm close to sure that Debian users may be able to help you one
step further.

Martin

>> Thank you!
>> Iago

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

Re: [R-sig-Debian] R version on upgrading Debian 10 / 11 -> Debian 12

[Ashim Kapoor]

Dear Johannes,

Many thanks for the prompt response.

Best Regards,
Ashim

On Thu, Sep 28, 2023 at 11:45 AM Johannes Ranke  wrote:
>
> Hi,
>
> the repo on CRAN where that page comes from actually has R 4.3.1 for Debian 12
> (bookworm). I just missed to update that bit of that page, sorry for the
> confusion caused. The updated text will be online in the course of the day.
>
> Cheers,
>
> Johannes
>
> Am Donnerstag, 28. September 2023, 08:06:11 CEST schrieb Ashim Kapoor:
> > Dear All,
> >
> > I have 2 computers.
> >
> > 1. Debian 10 with R 4.3.1
> > 2. Debian 11 with R 4.3.0
> >
> > I wish to upgrade both to Debian 12.
> > The latest R I understand is 4.3.1
> >
> > I am reading:
> > https://cran.r-project.org/bin/linux/debian/#debian-bookworm
> >
> > Looks like we only have R 4.3.0 in Debian 12 ( bookworm). When I
> > upgrade Debian 11-> 12 (on the 2nd computer) all should go well and I
> > think I will have R 4 .3.0
> >
> > What happens when I do Debian 10 -> 11 -> 12 (on the 1st computer).
> > Will I be having 4.3.0 in place of 4.3.1 ?
> >
> > Can someone please clarify.
> >
> > Many thanks,
> > Ashim
> >
> > ___
> > R-SIG-Debian mailing list
> > R-SIG-Debian@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>

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

Re: [R-sig-Debian] R version on upgrading Debian 10 / 11 -> Debian 12

[Johannes Ranke]

Hi,

the repo on CRAN where that page comes from actually has R 4.3.1 for Debian 12 
(bookworm). I just missed to update that bit of that page, sorry for the 
confusion caused. The updated text will be online in the course of the day.

Cheers,

Johannes

Am Donnerstag, 28. September 2023, 08:06:11 CEST schrieb Ashim Kapoor:
> Dear All,
> 
> I have 2 computers.
> 
> 1. Debian 10 with R 4.3.1
> 2. Debian 11 with R 4.3.0
> 
> I wish to upgrade both to Debian 12.
> The latest R I understand is 4.3.1
> 
> I am reading:
> https://cran.r-project.org/bin/linux/debian/#debian-bookworm
> 
> Looks like we only have R 4.3.0 in Debian 12 ( bookworm). When I
> upgrade Debian 11-> 12 (on the 2nd computer) all should go well and I
> think I will have R 4 .3.0
> 
> What happens when I do Debian 10 -> 11 -> 12 (on the 1st computer).
> Will I be having 4.3.0 in place of 4.3.1 ?
> 
> Can someone please clarify.
> 
> Many thanks,
> Ashim
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian

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

Re: [R-sig-Debian] R 4.3.1 on Debian bullseye-cran40 repository

[Iago Giné Vázquez]

Thank you both Johannes and Dirk.

Iago

De: R-SIG-Debian  de part de Johannes Ranke 

Enviat el: dijous, 22 de juny de 2023 7:00
Per a: r-sig-debian@r-project.org 
Tema: Re: [R-sig-Debian] R 4.3.1 on Debian bullseye-cran40 repository

Am Mittwoch, 21. Juni 2023, 15:04:07 CEST schrieb Johannes Ranke:
> Am Mittwoch, 21. Juni 2023, 09:48:17 CEST schrieb Iago Gin� V�zquez:
> > Hello,
> >
> > Although R 4.3.1 has been released some days ago, and in
> > http://cloud.r-project.org/bin/linux/debian/ it is claimed that
> >
> >
> > Debian bullseye has been released with R 4.0.4. If you want to upgrade to
> > R
> > 4.3.1 on bullseye, you can use the following repository.
> >
> > deb http://cloud.r-project.org/bin/linux/debian bullseye-cran40/
> >
> >
> > it seems that it is not working yet. Yesterday, after `apt update`, `apt
> > upgrade` only a couple of r core packages were upgraded (matrix and some
> > other), but R version was yet 4.3.0.
> >
> > Further, searching 4.3.1 in
> > http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/ it shows that
> > there is only an i386 build, while in
> > http://cloud.r-project.org/bin/linux/debian/bookworm-cran40/ there are
> > various amd64 builds.
> >
> > Is this expected?
>
> No, this is a mistake on my end. The amd64 binaries for bullseye are on
> their way to CRAN, if I am not mistaken they should be fetched by CRAN at
> 18:00 my time, i.e. in three hours.

Sorry, I was in a hurry yesterday and did not look properly. R 4.3.1 for
bullseye is now on its way to CRAN for i386 and amd64. Should be available
later today.

Kind regards,

Johannes

>
> Sorry for the inconvenience,
>
> Johannes
>
> > Thanks!
> >
> > Iago
> >
> >  [[alternative HTML version deleted]]
> >
> > ___
> > R-SIG-Debian mailing list
> > R-SIG-Debian@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


--
Johannes Ranke
Wissenschaftlicher Berater
07624 8099027
https://jrwb.de

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

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R 4.3.1 on Debian bullseye-cran40 repository

[Johannes Ranke]

Am Mittwoch, 21. Juni 2023, 15:04:07 CEST schrieb Johannes Ranke:
> Am Mittwoch, 21. Juni 2023, 09:48:17 CEST schrieb Iago Giné Vázquez:
> > Hello,
> > 
> > Although R 4.3.1 has been released some days ago, and in
> > http://cloud.r-project.org/bin/linux/debian/ it is claimed that
> > 
> > 
> > Debian bullseye has been released with R 4.0.4. If you want to upgrade to
> > R
> > 4.3.1 on bullseye, you can use the following repository.
> > 
> > deb http://cloud.r-project.org/bin/linux/debian bullseye-cran40/
> > 
> > 
> > it seems that it is not working yet. Yesterday, after `apt update`, `apt
> > upgrade` only a couple of r core packages were upgraded (matrix and some
> > other), but R version was yet 4.3.0.
> > 
> > Further, searching 4.3.1 in
> > http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/ it shows that
> > there is only an i386 build, while in
> > http://cloud.r-project.org/bin/linux/debian/bookworm-cran40/ there are
> > various amd64 builds.
> > 
> > Is this expected?
> 
> No, this is a mistake on my end. The amd64 binaries for bullseye are on
> their way to CRAN, if I am not mistaken they should be fetched by CRAN at
> 18:00 my time, i.e. in three hours.

Sorry, I was in a hurry yesterday and did not look properly. R 4.3.1 for 
bullseye is now on its way to CRAN for i386 and amd64. Should be available 
later today.

Kind regards,

Johannes

> 
> Sorry for the inconvenience,
> 
> Johannes
> 
> > Thanks!
> > 
> > Iago
> > 
> > [[alternative HTML version deleted]]
> > 
> > ___
> > R-SIG-Debian mailing list
> > R-SIG-Debian@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
Johannes Ranke
Wissenschaftlicher Berater
07624 8099027
https://jrwb.de

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

Re: [R-sig-Debian] R 4.3.1 on Debian bullseye-cran40 repository

[Johannes Ranke]

Am Mittwoch, 21. Juni 2023, 09:48:17 CEST schrieb Iago Giné Vázquez:
> Hello,
> 
> Although R 4.3.1 has been released some days ago, and in
> http://cloud.r-project.org/bin/linux/debian/ it is claimed that
> 
> 
> Debian bullseye has been released with R 4.0.4. If you want to upgrade to R
> 4.3.1 on bullseye, you can use the following repository.
> 
> deb http://cloud.r-project.org/bin/linux/debian bullseye-cran40/
> 
> 
> it seems that it is not working yet. Yesterday, after `apt update`, `apt
> upgrade` only a couple of r core packages were upgraded (matrix and some
> other), but R version was yet 4.3.0.
> 
> Further, searching 4.3.1 in
> http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/ it shows that
> there is only an i386 build, while in
> http://cloud.r-project.org/bin/linux/debian/bookworm-cran40/ there are
> various amd64 builds.
> 
> Is this expected?

No, this is a mistake on my end. The amd64 binaries for bullseye are on their 
way to CRAN, if I am not mistaken they should be fetched by CRAN at 18:00 my 
time, i.e. in three hours.

Sorry for the inconvenience,

Johannes

> 
> Thanks!
> 
> Iago
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian

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

Re: [R-sig-Debian] R 4.3.1 on Debian bullseye-cran40 repository

[Dirk Eddelbuettel]

On 21 June 2023 at 07:48, Iago Giné Vázquez wrote:
| Although R 4.3.1 has been released some days ago, and in 
http://cloud.r-project.org/bin/linux/debian/ it is claimed that
| 
| 
| Debian bullseye has been released with R 4.0.4. If you want to upgrade to R 
4.3.1 on bullseye, you can use the following repository.
| 
| deb http://cloud.r-project.org/bin/linux/debian bullseye-cran40/
| 
| 
| it seems that it is not working yet. Yesterday, after `apt update`, `apt 
upgrade` only a couple of r core packages were upgraded (matrix and some 
other), but R version was yet 4.3.0.
| 
| Further, searching 4.3.1 in 
http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/ it shows that 
there is only an i386 build, while in 
http://cloud.r-project.org/bin/linux/debian/bookworm-cran40/ there are various 
amd64 builds.
| 
| Is this expected?

Each of these 'binary ports' has a maintainer, for Debian it is Johannes who
is active on this list and whom you could have contacted directly too.  I am
sure he will take a closer look. Thanks for pointing it out.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.1.0 and Graphics Packages

[Johannes Ranke]

Just a quick reminder, see below ...
 
> We can rebuild all the affected packages.  An 'apt update; apt upgrade'
> would then pull them in.  That is generally my preferred approach.
> 
> Dirk

Johannes

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

Re: [R-sig-Debian] R 4.1.0 and Graphics Packages

[Dirk Eddelbuettel]

On 25 May 2021 at 08:47, Johannes Ranke wrote:
| A more systematic way would be to have R 4.1.0-2 provide r-graphics-api_14 
and 
| only upload packages providing graphics devices that have a respective 
| dependency from now on. But I don't know if it's worth the trouble.

If you wanted to you could do that locally for just the backport. 
 
| At this point I don't really see what we can do other than spreading the word 
| so the backports users can quickly address the problem by reinstalling the 
| affected packages.

We can rebuild all the affected packages.  An 'apt update; apt upgrade' would
then pull them in.  That is generally my preferred approach.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.1.0 and Graphics Packages

[Johannes Ranke]

Am Freitag, 21. Mai 2021, 19:03:59 CEST schrieb Dirk Eddelbuettel:
> On 21 May 2021 at 10:56, Johannes Ranke wrote:
> | Hi all,
> | 
> | The NEWS for R 4.1.0 contain the note:
> | 
> | - The graphics engine version, R_GE_version, has been bumped to 14 and so
> | packages that provide graphics devices should be reinstalled
> | 
> | And indeed, I just ran into this and got a
> | 
> |   Graphics API version mismatch
> | 
> | error when using the tikzDevice package with my fresh CRAN backport of R
> | 4.1.0 that Dirk uploaded to experimental. The error went away after
> | reinstalling tikzDevice.
> 
> Eeek. Didn't think of that.
> 
> | For CRAN backports users, I just added a note on the Debian page
> | 
> |   https://cran.r-project.org/bin/linux/debian/#debian-bullseye-testing
> | 
> | (it will take a while for the mirrors to sync).
> | 
> | Before the r-api system was introduced, I used to set up fresh
> | repositories
> | when R introduced breaking changes, in order to avoid that an apt-get
> | upgrade breaks installed R package functionality. This one slipped by my
> | attention.
> | 
> | For the Debian R packages, I think we should find out which of the R
> | packages in the Debian archive are affected by this (r-cran-rgl,
> | r-cran-svglite, r-cran- vdiffr which embeds svglite, ggplot2, ...) and
> | add versioned Breaks.
> | 
> | Or should the r-api Version be bumped from r-api-4.0 to r-api-4.1?
> 
> I would prefer not, and don't think it is called for. But then I often
> argued for a more 'laissez-faire' approach that others (on the other list,
> i.e. debian-r).
> 
> Once the release is made, I will put R 4.1.0-* into unstable and rebuild at
> least all the packages from experimental.  Me thinks we can handle this via
> the normal bug track mechanism.

A more systematic way would be to have R 4.1.0-2 provide r-graphics-api_14 and 
only upload packages providing graphics devices that have a respective 
dependency from now on. But I don't know if it's worth the trouble.

> But the backport may have extra issue. But
> maybe your list of 'has graphics' packages is good enough?

At this point I don't really see what we can do other than spreading the word 
so the backports users can quickly address the problem by reinstalling the 
affected packages.

Cheers,

Johannes
> 
> Dirk


-- 
Johannes Ranke
Wissenschaftlicher Berater
07624 8099027
https://jrwb.de

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

Re: [R-sig-Debian] R 4.1.0 and Graphics Packages

[Dirk Eddelbuettel]

On 21 May 2021 at 10:56, Johannes Ranke wrote:
| Hi all,
| 
| The NEWS for R 4.1.0 contain the note:
| 
| - The graphics engine version, R_GE_version, has been bumped to 14 and so 
| packages that provide graphics devices should be reinstalled
| 
| And indeed, I just ran into this and got a 
| 
|   Graphics API version mismatch
| 
| error when using the tikzDevice package with my fresh CRAN backport of R 
4.1.0 
| that Dirk uploaded to experimental. The error went away after reinstalling 
| tikzDevice.

Eeek. Didn't think of that.
 
| For CRAN backports users, I just added a note on the Debian page
| 
|   https://cran.r-project.org/bin/linux/debian/#debian-bullseye-testing 
| 
| (it will take a while for the mirrors to sync).
| 
| Before the r-api system was introduced, I used to set up fresh repositories 
| when R introduced breaking changes, in order to avoid that an apt-get upgrade 
| breaks installed R package functionality. This one slipped by my attention.
| 
| For the Debian R packages, I think we should find out which of the R packages 
| in the Debian archive are affected by this (r-cran-rgl, r-cran-svglite, 
r-cran-
| vdiffr which embeds svglite, ggplot2, ...) and add versioned Breaks.
| 
| Or should the r-api Version be bumped from r-api-4.0 to r-api-4.1?

I would prefer not, and don't think it is called for. But then I often argued
for a more 'laissez-faire' approach that others (on the other list, i.e. 
debian-r). 

Once the release is made, I will put R 4.1.0-* into unstable and rebuild at
least all the packages from experimental.  Me thinks we can handle this via
the normal bug track mechanism. But the backport may have extra issue. But
maybe your list of 'has graphics' packages is good enough?

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R > 4.0.0 on Debian 9 Stretch?

[Rainer M Krug]

> On 22 Sep 2020, at 15:31, Dirk Eddelbuettel  wrote:
> 
> 
> On 22 September 2020 at 15:19, Rainer M Krug wrote:
> | I think the easiest is for me just to install Debian 10 and to use that one.
> 
> Exactly.
> 
> On a personal note I like the six month (releases) or two-year (LTS) cadence
> of Ubuntu a lot and also use that. Plus, on Ubuntu you get 4600 Rutter
> binaries for CRAN packages.

I was thinking about Ubuntu, but I want to test things for running on a 
cluster, and the cluster very likely runs Ubuntu and not Debian - most things 
will be similar, but the closer the better.

Thanks a lot,

Rainer


> 
> Dirk
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982




[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R > 4.0.0 on Debian 9 Stretch?

[Dirk Eddelbuettel]

On 22 September 2020 at 15:19, Rainer M Krug wrote:
| I think the easiest is for me just to install Debian 10 and to use that one.

Exactly.

On a personal note I like the six month (releases) or two-year (LTS) cadence
of Ubuntu a lot and also use that. Plus, on Ubuntu you get 4600 Rutter
binaries for CRAN packages.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R > 4.0.0 on Debian 9 Stretch?

[Rainer M Krug]

Hi Dirk,

Thanks for the explamnayion - Debian is running in a VM (and nothing really 
installed on it) , and I think the easiest is for me just to install Debian 10 
and to use that one.

Thanks a lot,

Rainer



> On 22 Sep 2020, at 15:14, Dirk Eddelbuettel  wrote:
> 
> 
> On 22 September 2020 at 14:49, Rainer M Krug wrote:
> | I know this is likely documented somewhere, but I can’t find it. How can I 
> install R > 4.0.0 on Debian 9 Stretch?
> 
> That is 'oldstable'. You are making a heroic assumption that "some" volunteer
> prepared a binary for you.
> 
> Maybe ... that volunteer needs to be you ;-) !
> 
> On a more serious note, doing that is actually very straightforward because
> Debian packages are so well structured.  Download the source package from
> unstable, unpack it on a Debian 9 machine or container or pbuilder or ... and
> build it. Learn how to create a package repo and upload it somewhere. I have
> done so in very small scale with Debian packages I needed [1] and more
> generally "do it all the time" for the Ubuntu systems as Launchpad makes it
> so easy. [2]
> 
> We (in the "royal we" sense) could and should probably think about writing a
> short and simple paper walking through these steps. 
> 
> Dirk
> 
> [1] https://github.com/eddelbuettel/ppa
> [2] https://launchpad.net/~edd links to three repos of mine
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982




[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R > 4.0.0 on Debian 9 Stretch?

[Dirk Eddelbuettel]

On 22 September 2020 at 14:49, Rainer M Krug wrote:
| I know this is likely documented somewhere, but I can’t find it. How can I 
install R > 4.0.0 on Debian 9 Stretch?

That is 'oldstable'. You are making a heroic assumption that "some" volunteer
prepared a binary for you.

Maybe ... that volunteer needs to be you ;-) !

On a more serious note, doing that is actually very straightforward because
Debian packages are so well structured.  Download the source package from
unstable, unpack it on a Debian 9 machine or container or pbuilder or ... and
build it. Learn how to create a package repo and upload it somewhere. I have
done so in very small scale with Debian packages I needed [1] and more
generally "do it all the time" for the Ubuntu systems as Launchpad makes it
so easy. [2]

We (in the "royal we" sense) could and should probably think about writing a
short and simple paper walking through these steps. 

Dirk

[1] https://github.com/eddelbuettel/ppa
[2] https://launchpad.net/~edd links to three repos of mine

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Paul Teetor]

@Johannes - Thank you for your suggestion. I see the wisdom in it. I like 
having pre-built binaries because I'm lazy; but in this case, being lazy is 
causing too much work.

@Patrice - Thanks for sharing the story and those links. It seems the Odroid is 
like the RPi 3. The newer RPi 4 has (up to) 4 GB of memory, so I hope I won't 
need 12 boards! (PS - It's pretty cool that someone made a midi sequencer from 
their Odroid. I never thought of using my RPi that way.)

Paul Teetor, Elgin, IL USA
http://quantdevel.com/public


On Thursday, July 16, 2020, 02:06:11 AM CDT, Patrice Kiener 
 wrote: 


2 years ago at one Meetup in Paris, Marc Girondot, professor at 
University Paris-Saclay, presented his cluster built with 12 Odroid 
(equivalent to Rapsberry Pi). The stack was almost the same size than 
your picture as there was no fan and a narrower distance between each 
PCB card. There were many more cables. For a total cost of less than 
1000 € and an electrical consumption reduced by a factor of 7, he got 
the same calculation capabilities than the most expensive Intel i7 
processor. He used an Arch Linux distribution and Spark to distribute 
the load to every processor and then centralize the results to one 
processor equipped with a keyboard, a mouse, a screen and a hard disk.

https://www.meetup.com/fr-FR/rparis/events/252405360/
https://www.minimachines.net/actu/avec-lodroid-c2-hardkernel-tient-un-vrai-concurrent-a-la-rasperry-pi-3-38411
https://max2.ese.u-psud.fr/epc/conservation/index.html
https://www.ese.universite-paris-saclay.fr/en/team-members/marc-girondot/


Patrice


>> My RPi cluster sits on the file cabinet next to my desk, all four 
boards. Yes, you could argue that it's merely a toy but it's bigger 
and cheaper than the AWS box that currently hosts my web site, RStudio 
server, and Shiny server!

> Got it. Missed the cluster part earlier and then confused myself 
looking for
arm64 16core machines. There aren't any :)

>> For the truly curious, you can view my RPi cluster here: 
https://photos.app.goo.gl/kALwoYCVxJ32VgxEA

> Neat :)  Very geek chic!


Patrice



    [[alternative HTML version deleted]]

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

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Patrice Kiener]

2 years ago at one Meetup in Paris, Marc Girondot, professor at 
University Paris-Saclay, presented his cluster built with 12 Odroid 
(equivalent to Rapsberry Pi). The stack was almost the same size than 
your picture as there was no fan and a narrower distance between each 
PCB card. There were many more cables. For a total cost of less than 
1000 € and an electrical consumption reduced by a factor of 7, he got 
the same calculation capabilities than the most expensive Intel i7 
processor. He used an Arch Linux distribution and Spark to distribute 
the load to every processor and then centralize the results to one 
processor equipped with a keyboard, a mouse, a screen and a hard disk.

https://www.meetup.com/fr-FR/rparis/events/252405360/
https://www.minimachines.net/actu/avec-lodroid-c2-hardkernel-tient-un-vrai-concurrent-a-la-rasperry-pi-3-38411
https://max2.ese.u-psud.fr/epc/conservation/index.html
https://www.ese.universite-paris-saclay.fr/en/team-members/marc-girondot/


Patrice


 >> My RPi cluster sits on the file cabinet next to my desk, all four 
boards. Yes, you could argue that it's merely a toy but it's bigger 
and cheaper than the AWS box that currently hosts my web site, RStudio 
server, and Shiny server!

 > Got it. Missed the cluster part earlier and then confused myself 
looking for
arm64 16core machines. There aren't any :)

 >> For the truly curious, you can view my RPi cluster here: 
https://photos.app.goo.gl/kALwoYCVxJ32VgxEA

 > Neat :)  Very geek chic!


Patrice



[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Johannes Ranke]

Am Mittwoch, 15. Juli 2020, 22:12:08 CEST schrieb Dirk Eddelbuettel:
> On 15 July 2020 at 19:44, Paul Teetor wrote:
> | H. Perhaps I'm using the wrong terminology. My logic is: (1) I am
> | running Ubuntu focal on the cluster.
> I am with you so far.
> 
> | (2) Ubuntu focal is built on Debian bullseye but
> 
> Not really. Ubuntu does their own thing, and their own snapshots.
> 
> There is no relationship to Debian _stable_ releases.  They take sources
> from Debian unstable and then do their thing.  Which sometimes is minor
> variation, often no change, but sometimes a lot more (i.e. snaps, different
> boot stuff, different window manager, fonts, branding, software store,
> alliances with third parties, paid-for patent technology (they always
> included mp3 players).
> 
> In short, I think you started from the wrong gate here.

I think it would be preferable to add to your /etc/apt/sources.list

  deb-src https://cloud.r-project.org/bin/linux/ubuntu focal-cran40/

to get access to the source packages for R 4.0.2, and then do

  sudo apt update
  sudo apt build-dep r-base

and

  sudo apt source -b r-base

to build these on your arm cluster for your architecture. Of course you will 
need to rebuild after R releases to keep up to date. 

Johannes

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Paul Teetor]

H. Perhaps I'm using the wrong terminology. My logic is: (1) I am running 
Ubuntu focal on the cluster. (2) Ubuntu focal is built on Debian bullseye but 
(3) Debian bullseye is not yet the stable release; it is the 'testing' release; 
hence (4) I will pull the r-base-core package from the 'testing' version of 
Debian. And, in fact, I found r-base-core for 4.0.2 in the bullseye 
distribution. Does that all make sense?

My RPi cluster sits on the file cabinet next to my desk, all four boards. Yes, 
you could argue that it's merely a toy but it's bigger and cheaper than the 
AWS box that currently hosts my web site, RStudio server, and Shiny server!

For the truly curious, you can view my RPi cluster here: 
https://photos.app.goo.gl/kALwoYCVxJ32VgxEA

Thanks again, Dirk. Your contributions to Debian and Ubuntu are foundational 
for my computing platforms.

Paul Teetor, Elgin, IL USA
http://quantdevel.com/public






On Wednesday, July 15, 2020, 11:52:03 AM CDT, Dirk Eddelbuettel 
 wrote: 






On 15 July 2020 at 16:35, Paul Teetor wrote:
| Thank you very much, Dirk. That nudge solved the problem, of course. I am 
embarrassed. I was so fixated on Ubuntu repositories that I neglected to check 
the Debian 'testing' world!
| 
| Regarding the RPi: The RPi 4 uses the 'arm64' architecture, the full 64-bit 
one. I stopped using dedicated distros, such as Raspian, when Ubuntu went 
all-in on RPi support, which happened in their newest release focal (20). The 
dedicated distros often have an unhelpful attitude -- e.g., "you should use 
*this* package, not *that* package" -- that doesn't work for me.

I am confused by these two paragraphs. Are you planning to use Debian
'testing' on you Raspberry Pi, or Ubuntu 'focal' aka 20.04?

And out of curiousity, is that a hosted machine?  Typically these are
toy-sized and usually at home.


Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Paul Teetor]

Thank you very much, Dirk. That nudge solved the problem, of course. I am 
embarrassed. I was so fixated on Ubuntu repositories that I neglected to check 
the Debian 'testing' world!

Regarding the RPi: The RPi 4 uses the 'arm64' architecture, the full 64-bit 
one. I stopped using dedicated distros, such as Raspian, when Ubuntu went 
all-in on RPi support, which happened in their newest release focal (20). The 
dedicated distros often have an unhelpful attitude -- e.g., "you should use 
*this* package, not *that* package" -- that doesn't work for me.

Paul Teetor, Elgin, IL USA
http://quantdevel.com/public






On Wednesday, July 15, 2020, 09:26:27 AM CDT, Dirk Eddelbuettel 
 wrote: 






On 15 July 2020 at 14:03, Paul Teetor wrote:
| Dear R-SIG-Debian folks,
| 
| I seem to be chasing my tail, despite having a simple goal:
| 
| - Install R 4.0.2
| - On Ubuntu 20.04
| - For an ARM processor (not Intel/AMD).
| 
| Can someone please suggest a Debian/Ubuntu repository of the required 
packages (e.g., r-base-core) built for ARM? I can't seem to find one.
| 
| (I can find the r-base-core package for R 3.6.3, but not R 4.0.2, built for 
ARM.)
| 
| If there is no such Debian/Ubuntu repository, what would you recommend? Build 
R 4.0 for ARM from source? Use the cool 'rocker' images for R 4.0? Something 
else?
| 
| Thank you so much for your advice. I must be misunderstanding something. I 
figured this would be a slam-dunk because (1) R 4.0 is the latest release, and 
(2) Ubuntu 20.04 is an LTS release, and (3) ARM is a supported architecture, or 
so I thought.
| 
| Paul
| 
| PS - Yes, the ARM processors in question are a Raspberry Pi cluster. Don't 
snicker. Hey, it's got 16 cores, 16 GB RAM total, and a
| terabyte of space. And it's paid for, no monthly fee.


When I look at the build pages for my packages, eg this one for r-base

  https://buildd.debian.org/status/package.php?p=r-base

I see three (3) different arm labels: arm64, armel, armhf. I have no idea
what the Pi uses, and never looked closely, but I am at least vaguely aware
that there are apparently entire _dedicated_ distros and installers based on
the Debian builds.  Raspian is one name that comes to mind.  Did you try that?

Also, one second of Googling leads to: https://ubuntu.com/download/server/arm

Good luck, keep us posted -- other architectures/platforms can be fun.

Dirk
(who just installed 20.04 on his daughters "retired / thought dead under a
large cup of coffee spilled" macbook air)

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Dirk Eddelbuettel]

On 15 July 2020 at 19:44, Paul Teetor wrote:
| H. Perhaps I'm using the wrong terminology. My logic is: (1) I am running 
Ubuntu focal on the cluster.

I am with you so far.

| (2) Ubuntu focal is built on Debian bullseye but

Not really. Ubuntu does their own thing, and their own snapshots.

There is no relationship to Debian _stable_ releases.  They take sources from
Debian unstable and then do their thing.  Which sometimes is minor variation,
often no change, but sometimes a lot more (i.e. snaps, different boot stuff,
different window manager, fonts, branding, software store, alliances with
third parties, paid-for patent technology (they always included mp3 players).

In short, I think you started from the wrong gate here.

| (3) Debian bullseye is not yet the stable release; it is the 'testing' 
release; hence (4) I will pull the r-base-core package from the 'testing' 
version of Debian. And, in fact, I found r-base-core for 4.0.2 in the bullseye 
distribution. Does that all make sense?

Given (2) you more or less land in a bad spot with (3) and (4).
 
| My RPi cluster sits on the file cabinet next to my desk, all four boards. 
Yes, you could argue that it's merely a toy but it's bigger and cheaper 
than the AWS box that currently hosts my web site, RStudio server, and Shiny 
server!

Got it. Missed the cluster part earlier and then confused myself looking for
arm64 16core machines. There aren't any :)
 
| For the truly curious, you can view my RPi cluster here: 
https://photos.app.goo.gl/kALwoYCVxJ32VgxEA

Neat :)  Very geek chic! 
 
| Thanks again, Dirk. Your contributions to Debian and Ubuntu are foundational 
for my computing platforms.

You're too kind.

Cheers, Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Dirk Eddelbuettel]

On 15 July 2020 at 16:35, Paul Teetor wrote:
| Thank you very much, Dirk. That nudge solved the problem, of course. I am 
embarrassed. I was so fixated on Ubuntu repositories that I neglected to check 
the Debian 'testing' world!
| 
| Regarding the RPi: The RPi 4 uses the 'arm64' architecture, the full 64-bit 
one. I stopped using dedicated distros, such as Raspian, when Ubuntu went 
all-in on RPi support, which happened in their newest release focal (20). The 
dedicated distros often have an unhelpful attitude -- e.g., "you should use 
*this* package, not *that* package" -- that doesn't work for me.

I am confused by these two paragraphs. Are you planning to use Debian
'testing' on you Raspberry Pi, or Ubuntu 'focal' aka 20.04?

And out of curiousity, is that a hosted machine?  Typically these are
toy-sized and usually at home.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 4.0 for ARM processors

[Dirk Eddelbuettel]

On 15 July 2020 at 14:03, Paul Teetor wrote:
| Dear R-SIG-Debian folks,
| 
| I seem to be chasing my tail, despite having a simple goal:
| 
| - Install R 4.0.2
| - On Ubuntu 20.04
| - For an ARM processor (not Intel/AMD).
| 
| Can someone please suggest a Debian/Ubuntu repository of the required 
packages (e.g., r-base-core) built for ARM? I can't seem to find one.
| 
| (I can find the r-base-core package for R 3.6.3, but not R 4.0.2, built for 
ARM.)
| 
| If there is no such Debian/Ubuntu repository, what would you recommend? Build 
R 4.0 for ARM from source? Use the cool 'rocker' images for R 4.0? Something 
else?
| 
| Thank you so much for your advice. I must be misunderstanding something. I 
figured this would be a slam-dunk because (1) R 4.0 is the latest release, and 
(2) Ubuntu 20.04 is an LTS release, and (3) ARM is a supported architecture, or 
so I thought.
| 
| Paul
| 
| PS - Yes, the ARM processors in question are a Raspberry Pi cluster. Don't 
snicker. Hey, it's got 16 cores, 16 GB RAM total, and a
| terabyte of space. And it's paid for, no monthly fee.

When I look at the build pages for my packages, eg this one for r-base

   https://buildd.debian.org/status/package.php?p=r-base

I see three (3) different arm labels: arm64, armel, armhf. I have no idea
what the Pi uses, and never looked closely, but I am at least vaguely aware
that there are apparently entire _dedicated_ distros and installers based on
the Debian builds.  Raspian is one name that comes to mind.  Did you try that?

Also, one second of Googling leads to: https://ubuntu.com/download/server/arm

Good luck, keep us posted -- other architectures/platforms can be fun.

Dirk
(who just installed 20.04 on his daughters "retired / thought dead under a
large cup of coffee spilled" macbook air)

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R-4.0.0 and Texlive 2020 installed on EmmabuntusDE4 (Debian Bullseye)

[Johannes Ranke]

Hi Patrice,

Am Mittwoch, 29. April 2020, 11:03:56 CEST schrieb Patrice Kiener:
> Hi Johannes,
> 
> 
> Thank you for your comments. I run
>sudo apt install -t bullseye-cran40 r-base
> 
> and have now the current R-4.0.0 in /usr/lib/R with links in the menus
> and R-devel R-4.1.0 in ~/patrice/svn/R/r-devel/build. Perfect.

Great!
 
> I used sid just to get the full Texlive 2020. I will probably not update
> it for a while and have already removed (commented) the sid line in
> sources.list as I do not want to break my system with too much fresh
> libraries. Indeed, we want to be on the edge for a few software (R,
> Texlive) and are conservative for all other parts of the OS. Thanks for
> the tips on /etc/apt/preferences.

You're welcome!
 
> Regarding the key, you can probably move the section at the top of the
> documentation as it is a necessary step. The key currently mentionned in
> the instruction is:
>   sudo apt-key adv --keyserver keys.gnupg.net --recv-key
> 'E19F5F87128899B192B1A2C2AD5F960A256A04AF'
> 
> but the one that worked for me (found in one comment in
> https://stackoverflow.com/questions/10255082/installing-r-from-cran-ubuntu-r
> epository-no-public-key-error) is:
>   sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
>   FCAE2A0E115C3D8A
> 
> The length of digits is different. Maybe one is the shortest version of
> the other?

Using the full fingerprint prevents forging the repository by uploading a fake 
key to the keyservers with the same hash string. This is known to have 
happened to other people.

Cheers,

Johannes


> 
> Patrice
> 
> 
> 
> 
> Dear Patrice,
> 
> 
> thanks for sharing your experience with Debian based distributions. It
> is amazing how many distros you tested!
> 
> In your situation I would recommend apt pinning for installing texlive
> 2020 from Debian sid on Debian bullseye aka testing or related systems.
> Simply adding sid sources as you did will make your system upgrade to
> sid. It seems you partially upgraded some of your test systems to sid
> and were left with broken systems.
> 
> This will also apply to emmabuntü - if you just added the sid repository
> without editing /etc/apt/preferences, you will always pull packages from
> sid which may be ok for your use case, but you should be aware of it.
> 
> You would need to edit /etc/apt/preferences in order to tell apt to just
> use texlive from sid and the other packages from bullseye.
> 
> Regarding the command to add my key, this is actually there, but I
> believe it was too far down - I just moved the section on secure apt
> before the section on the different distributions. Thanks for the hint!
> 
> Regarding your attempt to use the backports for bullseye on CRAN for
> your Emmabuntüs system, chances are it would have worked if you would
> have used the command I am listing there (of course adding sudo):
> 
>sudo apt install -t bullseye-cran40 r-base
> 
> instead of simply
> 
>sudo apt install r-base
> 
> However, now you have the newest devel version compiled from sources for
> checking your packages on Linux which is nice as well!
> 
> 
> Kind regards,
> 
> 
> Johannes
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian

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

Re: [R-sig-Debian] R-4.0.0 and Texlive 2020 installed on EmmabuntusDE4 (Debian Bullseye)

[Patrice Kiener]

Hi Johannes,


Thank you for your comments. I run
  sudo apt install -t bullseye-cran40 r-base

and have now the current R-4.0.0 in /usr/lib/R with links in the menus 
and R-devel R-4.1.0 in ~/patrice/svn/R/r-devel/build. Perfect.


I used sid just to get the full Texlive 2020. I will probably not update 
it for a while and have already removed (commented) the sid line in 
sources.list as I do not want to break my system with too much fresh 
libraries. Indeed, we want to be on the edge for a few software (R, 
Texlive) and are conservative for all other parts of the OS. Thanks for 
the tips on /etc/apt/preferences.


Regarding the key, you can probably move the section at the top of the 
documentation as it is a necessary step. The key currently mentionned in 
the instruction is:
 sudo apt-key adv --keyserver keys.gnupg.net --recv-key 
'E19F5F87128899B192B1A2C2AD5F960A256A04AF'


but the one that worked for me (found in one comment in 
https://stackoverflow.com/questions/10255082/installing-r-from-cran-ubuntu-repository-no-public-key-error) 
is:

 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
 FCAE2A0E115C3D8A

The length of digits is different. Maybe one is the shortest version of 
the other?


Patrice




Dear Patrice,


thanks for sharing your experience with Debian based distributions. It 
is amazing how many distros you tested!


In your situation I would recommend apt pinning for installing texlive 
2020 from Debian sid on Debian bullseye aka testing or related systems. 
Simply adding sid sources as you did will make your system upgrade to 
sid. It seems you partially upgraded some of your test systems to sid 
and were left with broken systems.


This will also apply to emmabuntü - if you just added the sid repository 
without editing /etc/apt/preferences, you will always pull packages from 
sid which may be ok for your use case, but you should be aware of it.


You would need to edit /etc/apt/preferences in order to tell apt to just 
use texlive from sid and the other packages from bullseye.


Regarding the command to add my key, this is actually there, but I 
believe it was too far down - I just moved the section on secure apt 
before the section on the different distributions. Thanks for the hint!


Regarding your attempt to use the backports for bullseye on CRAN for 
your Emmabuntüs system, chances are it would have worked if you would 
have used the command I am listing there (of course adding sudo):


  sudo apt install -t bullseye-cran40 r-base

instead of simply

  sudo apt install r-base

However, now you have the newest devel version compiled from sources for 
checking your packages on Linux which is nice as well!



Kind regards,


Johannes

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

Re: [R-sig-Debian] R-4.0.0 and Texlive 2020 installed on EmmabuntusDE4 (Debian Bullseye)

[Johannes Ranke]

Dear Patrice,

thanks for sharing your experience with Debian based distributions. It is 
amazing how many distros you tested!

In your situation I would recommend apt pinning for installing texlive 2020 
from Debian sid on Debian bullseye aka testing or related systems. Simply 
adding sid sources as you did will make your system upgrade to sid. It seems 
you partially upgraded some of your test systems to sid and were left with 
broken systems.

This will also apply to emmabunt� - if you just added the sid repository 
without editing /etc/apt/preferences, you will always pull packages from sid 
which may be ok for your use case, but you should be aware of it.

You would need to edit /etc/apt/preferences in order to tell apt to just use 
texlive from sid and the other packages from bullseye.

Regarding the command to add my key, this is actually there, but I believe it 
was too far down - I just moved the section on secure apt before the section 
on the different distributions. Thanks for the hint!

Regarding your attempt to use the backports for bullseye on CRAN for your 
Emmabunt�s system, chances are it would have worked if you would have used the 
command I am listing there (of course adding sudo):

  sudo apt install -t bullseye-cran40 r-base

instead of simply 

  sudo apt install r-base

However, now you have the newest devel version compiled from sources for 
checking your packages on Linux which is nice as well!

Kind regards,

Johannes


Am Dienstag, 28. April 2020, 20:49:31 CEST schrieb Patrice Kiener:
> Dear all,
> 
> 
> I whish to relate my installation of R-4.0.0 on Debian.
> 
> I am mainly a Windows user and occasionnaly verify the CRAN checks of my
> packages on a second laptop equipped with Linux Mint Debian Edition 3
> (LMDE3) based on Debian Stretch. On Friday, April 24, it took me a few
> hours to have R-4.0.0 installed on Windows and the sources compiled,
> thanks to the instructions provided by Jeroen Ooms:
>  https://cloud.r-project.org/bin/windows/Rtools/ + links
> 
> I decided to repeat the exercise on Debian with a clean SSD disk, a
> recent Debian distribution, Texlive 2020 and R-4.0.0 to replace the
> obsolete LMDE3. The main difficulty was to find the appropriate
> distribution that accepts Texlive 2020. I downloaded and tested:
> 
> - Debian Buster 10.3 (the current stable version with a few desktops:
> Gnome, KDE-Plasma, XFCE, LXDE, LXQt, Mosaic),
> - Netrunner (Debian Buster 10.3 + KDE),
> - Linux Mint LMDE4 (Debian Buster 10.3 + Cinnamon),
> - Emmabunt�s DE3 (Debian Buster 10.3 + XFCE),
> - Xubuntu (Ubuntu + XFCE),
> - Debian Bullseye (the testing version + LXQt),
> - Emmabunt�s DE4 alpha (Debian Bullseye + XFCE + LXQt) published on
> April 27 (yesterday),
> - Debian sid (the unstable version).
> 
> - Once again in four years, I had many difficulties with the independant
> install-tl-unix.tar.gz (*.sh) program provided by Texlive and the final
> steps with the PATH update. The program was not found and tlmgr --gui
> did not reconnect to the CTAN repository. Once again, I gave up.
> - All distributions based on Buster 10.3 have Texlive 2018 in their
> repositories. In a few distributions, it is possible to write the sid
> (unstable) repository in the sources.list file:
>  deb http://deb.debian.org/debian/ sid main contrib
> 
> Then, a sudo apt-get update and apt search Texlive gives access to
> Texlive 2020. Unfortunately, installing Texlive 2020 this way will
> suppress Libre Office and numerous libraries, a few of them being used
> by the display manager. This is a sure way to break the distribution at
> the next startup.
> - Debian Bullseye offers Texlive 2019 in its repository. Writing the sid
>   line in sources.list is again easy. But accessing it is much more
> difficult as Debian considers it unsecure, throws a warning message and
> requests some parameter change in another file (which is not clearly
> designated) to accept this repository. I kept it as a potential solution.
> - The installation of Debian sid follows other paths. It is a
> distribution meant for testing and chasing bugs, not for a permanent
> use. I did not insist.
> 
> The great winner is Emmabunt�s DE4, which can be downloaded from here:
>  https://emmabuntus.org/emmabuntus-de4/
>  http://dl.emma-de4x64.emmabuntus.org/
> 
> https://emmabuntus.org/on-april-27-2020-emmade4-debian-11-bullseye-is-rollin
> g-out-early/
> 
> (Disclaimer: I do not have any ties with the development team. I
> discovered the distribution 10 days ago when searching for alternatives
> to Ubuntu and Mint. I tested first DE3 and discovered yesterday by
> surprise that DE4 was released.)
> 
> With its predecessor DE3, they are very surprising distributions with a
> completely different philosophy than the most well-known distributions,
> like Ubuntu and Mint, on the number of preinstalled packages. They are
> meant for people who have recent 64 bits or old computers, including 32
> bits, a poor internet 

Re: [R-sig-Debian] [R] Curl4, Quantmod, tseries and forecast

[Lorenzo Isella]

Thanks, that fixed the issue!

L.

On Tue, Jul 09, 2019 at 01:41:39PM +0200, Ralf Stubner wrote:

Hi Lorenzo

I reordered the quote slightly:

On Tue, Jul 9, 2019 at 1:30 PM Lorenzo Isella  wrote:

On Sun, Jul 07, 2019 at 03:16:20PM +0200, Ralf Stubner wrote:
>Did you reinstall the curl package? See also
>https://stackoverflow.com/a/50085192/8416610

I tried the following

> install.packages("RCurl")


which went OK, but then same story when I tried to install tseries.


Note that I suggested reinstalling the "curl" package, not the "RCurl"
package. After all, it's curl's library and not RCurl's library that
is producing the error message.

cheerio
ralf


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

Re: [R-sig-Debian] [R] Curl4, Quantmod, tseries and forecast

[Ralf Stubner]

Hi Lorenzo

I reordered the quote slightly:

On Tue, Jul 9, 2019 at 1:30 PM Lorenzo Isella  wrote:
> On Sun, Jul 07, 2019 at 03:16:20PM +0200, Ralf Stubner wrote:
> >Did you reinstall the curl package? See also
> >https://stackoverflow.com/a/50085192/8416610
>
> I tried the following
>
> > install.packages("RCurl")
>
>
> which went OK, but then same story when I tried to install tseries.

Note that I suggested reinstalling the "curl" package, not the "RCurl"
package. After all, it's curl's library and not RCurl's library that
is producing the error message.

cheerio
ralf

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

Re: [R-sig-Debian] [R] Curl4, Quantmod, tseries and forecast

[Lorenzo Isella]

Hi Ralf,
I tried the following


install.packages("RCurl")



which went OK, but then same story when I tried to install tseries.


sessionInfo()

R version 3.6.1 (2019-07-05)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 10 (buster)

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0

locale:
[1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C  
[3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
[5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8   
[7] LC_PAPER=en_GB.UTF-8   LC_NAME=C 
[9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C   


attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 


loaded via a namespace (and not attached):
[1] compiler_3.6.1 tools_3.6.1   


I run a standard debian stable 10 + the ranke debian backports  -- no
fancy stuff.
I do not believe I am the only one experiencing this.
Cheers

L.


On Sun, Jul 07, 2019 at 03:16:20PM +0200, Ralf Stubner wrote:

Hi Lorenzo

Joshua Ulrich  schrieb am So. 7. Juli 2019 um
14:16:


Hi Lorenzo,

On Sun, Jul 7, 2019 at 6:42 AM Lorenzo Isella 
wrote:
> ** byte-compile and prepare package for lazy loading
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>   unable to load shared object
'/usr/local/lib/R/site-library/curl/libs/curl.so':
>   /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not
found (required by /usr/local/lib/R/site-library/curl/libs/curl.so)



Did you reinstall the curl package? See also
https://stackoverflow.com/a/50085192/8416610

cheerio
ralf


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

Re: [R-sig-Debian] [R] Curl4, Quantmod, tseries and forecast

[Ralf Stubner]

Hi Lorenzo

Joshua Ulrich  schrieb am So. 7. Juli 2019 um
14:16:

> Hi Lorenzo,
>
> On Sun, Jul 7, 2019 at 6:42 AM Lorenzo Isella 
> wrote:
> > ** byte-compile and prepare package for lazy loading
> > Error in dyn.load(file, DLLpath = DLLpath, ...) :
> >   unable to load shared object
> '/usr/local/lib/R/site-library/curl/libs/curl.so':
> >   /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not
> found (required by /usr/local/lib/R/site-library/curl/libs/curl.so)


Did you reinstall the curl package? See also
https://stackoverflow.com/a/50085192/8416610

cheerio
ralf

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] [R] Curl4, Quantmod, tseries and forecast

[Joshua Ulrich]

Hi Lorenzo,

On Sun, Jul 7, 2019 at 6:42 AM Lorenzo Isella  wrote:
>
> Dear All,
> I have just upgraded to Debian stable 10 and rebuilt most of the R
> packages.
> I use the R backported packages from here
>
> https://cran.r-project.org/bin/linux/debian/#debian-buster-testing
>
> for the core system.
> I encounter some issues when updating quantmod, tseries and forecast.
> For instance, see the following
>
> > install.packages("tseries")
>
> which finally fails with the following message
>
> ** byte-compile and prepare package for lazy loading
> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>   unable to load shared object 
> '/usr/local/lib/R/site-library/curl/libs/curl.so':
>   /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found 
> (required by /usr/local/lib/R/site-library/curl/libs/curl.so)
> Calls:  ... asNamespace -> loadNamespace -> library.dynam -> 
> dyn.load
> Execution halted
> ERROR: lazy loading failed for package ‘tseries’
> * removing ‘/usr/local/lib/R/site-library/tseries’
> * restoring previous ‘/usr/local/lib/R/site-library/tseries’
>
> Now I have curl44 installed on my system because that is what Debian
> prrovides me with (and for the overwhelming majority of my packages it
> is not a problem).
> Please find below my sessionInfo().
> Any suggestion is appreciated.

The error is related to the installation/version of cURL on your
system, so I suggest sending this to R-SIG-Debian (cc'd).

Best,
Josh

> Cheers
>
> Lorenzo
>
>
> > sessionInfo()
> R version 3.6.0 (2019-04-26)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Debian GNU/Linux 10 (buster)
>
> Matrix products: default
> BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0
>
> locale:
>  [1] LC_CTYPE=en_GB.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_GB.UTF-8LC_COLLATE=en_GB.UTF-8
>  [5] LC_MONETARY=en_GB.UTF-8LC_MESSAGES=en_GB.UTF-8
>  [7] LC_PAPER=en_GB.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.6.0 tools_3.6.0
>
> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.



-- 
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Johannes Ranke]

> Anyway, it is great to have the extra flag. I just prepared r-base 3.6.0-2
> and it contains the new flag in /etc/R/Makeconf thanks to your changes to
> configure{,.ac} which I "backported" to 3.6.0-2.  It also includes the
> whitelist for the non-portable compiler flags noise.

Great! I just updated the CRAN R packages for Debian buster aka testing to 
3.6.0-2. It will hit the mirrors soon.

Johannes

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Dirk Eddelbuettel]

On 10 May 2019 at 18:31, Kurt Hornik wrote:
| Thanks.  Btw, Tomas just told R Core that
| 
| *
| I had a quick look at reference lapack builds in different 
| distributions: looking at the disassembly, and specifically for dposv 
| tail-calling into dpotrs. I checked the latest packages from Fedora 30, 
| Fedora Rawhide (the same?), Ubuntu 19.04, Debian Sid, OpenSuse Leap 
| 42.3. None of the builds had that problem (yet). I've been looking for 
| the packages via pkgs.org.
| *
| 
| so we should be safe re BLAS/LAPACK binary packages in testing for now.
| (But of course, this might change in case of rebuilds using current
| gfortran-8). 

Well as we said for some sane distributions (us ;-) gcc-9 is still of limits,
and the patch to gfortran-8 is AFAIK not that old.

Then again the analysis is also incomplete as some distributions (us ;-)
permit live switching of BLAS/LAPACK so we'd also have to look at disassembly
for OpenBLAS, Atlas, ... and whatever else is used.

Anyway, it is great to have the extra flag. I just prepared r-base 3.6.0-2
and it contains the new flag in /etc/R/Makeconf thanks to your changes to
configure{,.ac} which I "backported" to 3.6.0-2.  It also includes the
whitelist for the non-portable compiler flags noise.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> On 10 May 2019 at 13:46, Kurt Hornik wrote:
> | > Dirk Eddelbuettel writes:
> | 
> | > On 10 May 2019 at 10:52, Johannes Ranke wrote:
> | > | Thanks, that sounds good. But I need some help as I do not know much 
> about 
> | > | autoconf and Debian packaging: Is it enough to patch configure.ac 
> (r76467) or 
> | > | do we need to update configure as well (r76468)?
> | 
> | > Again, that would happen in the sources you pick up from me, and per
> | 
> | > part1 
> https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c
> | > part2 
> https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030
> | 
> | > it only affects gfortran >= 7, and my Debian stable fileserver shows gcc
> | > still the default so no rush.
> |  
> | > | > In principle I think all Fortran BLAS/LAPACK implementations (refblas
> | > | > and ATLAS) packaged for buster should be recompiled with
> | > | > -fno-optimize-sibling-calls (they may be fine in case they were 
> compiled
> | > | > with older version of gfortran-8, but then the next rebuild will cause
> | > | > trouble): Dirk, any chance you could get the package maintainers to 
> make
> | > | > these changes?
> | > | 
> | > | It seems to me this is of relevance for for Sébastien (Ccing), or more 
> | > | generally for debian-science.
> | 
> | > Not really. I do not think anybody concluded our LAPACK/BLAS needed to be
> | > recompiled.  The discussion about this has been going on for a few weeks 
> and
> | > is now also between gcc/gfortran upstream and the lapack folks. See 
> Tomas's
> | > posts on (IIRC) r-devel.
> | 
> | > So in short, things are moving, and in the right direction. Also worth
> | > recalling that the _initial findings_ were and still are about a gcc /
> | > gfortran version _not even in Debian unstable yet_ (but the folks in
> | > Fedora once again jumped the gun and they now have that problem with
> | > gfortran 9).
> | 
> | Afaics, the issue certainly affects current gfortran-8 in testing?

> Correct -- my bad. As Debian pulled that upstream patch in. In any
> event I was planning to push an updated r-base package carrying the
> patch to configure.

Thanks.  Btw, Tomas just told R Core that

*
I had a quick look at reference lapack builds in different 
distributions: looking at the disassembly, and specifically for dposv 
tail-calling into dpotrs. I checked the latest packages from Fedora 30,
Fedora Rawhide (the same?), Ubuntu 19.04, Debian Sid, OpenSuse Leap 
42.3. None of the builds had that problem (yet). I've been looking for 
the packages via pkgs.org.
*

so we should be safe re BLAS/LAPACK binary packages in testing for now.
(But of course, this might change in case of rebuilds using current
gfortran-8). 

Best
-k
> And the as-discussed issue with noisy "verboten compiler switches" warning we
> are being handed between Debian imposing switches and R not liking them.

> Dirk

> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Dirk Eddelbuettel]

On 10 May 2019 at 13:46, Kurt Hornik wrote:
| > Dirk Eddelbuettel writes:
| 
| > On 10 May 2019 at 10:52, Johannes Ranke wrote:
| > | Thanks, that sounds good. But I need some help as I do not know much 
about 
| > | autoconf and Debian packaging: Is it enough to patch configure.ac 
(r76467) or 
| > | do we need to update configure as well (r76468)?
| 
| > Again, that would happen in the sources you pick up from me, and per
| 
| > part1 
https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c
| > part2 
https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030
| 
| > it only affects gfortran >= 7, and my Debian stable fileserver shows gcc
| > still the default so no rush.
|  
| > | > In principle I think all Fortran BLAS/LAPACK implementations (refblas
| > | > and ATLAS) packaged for buster should be recompiled with
| > | > -fno-optimize-sibling-calls (they may be fine in case they were compiled
| > | > with older version of gfortran-8, but then the next rebuild will cause
| > | > trouble): Dirk, any chance you could get the package maintainers to make
| > | > these changes?
| > | 
| > | It seems to me this is of relevance for for Sébastien (Ccing), or more 
| > | generally for debian-science.
| 
| > Not really. I do not think anybody concluded our LAPACK/BLAS needed to be
| > recompiled.  The discussion about this has been going on for a few weeks and
| > is now also between gcc/gfortran upstream and the lapack folks. See Tomas's
| > posts on (IIRC) r-devel.
| 
| > So in short, things are moving, and in the right direction. Also worth
| > recalling that the _initial findings_ were and still are about a gcc /
| > gfortran version _not even in Debian unstable yet_ (but the folks in
| > Fedora once again jumped the gun and they now have that problem with
| > gfortran 9).
| 
| Afaics, the issue certainly affects current gfortran-8 in testing?

Correct -- my bad. As Debian pulled that upstream patch in. In any event I
was planning to push an updated r-base package carrying the patch to
configure.

And the as-discussed issue with noisy "verboten compiler switches" warning we
are being handed between Debian imposing switches and R not liking them.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> On 10 May 2019 at 10:52, Johannes Ranke wrote:
> | Thanks, that sounds good. But I need some help as I do not know much about 
> | autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) 
> or 
> | do we need to update configure as well (r76468)?

> Again, that would happen in the sources you pick up from me, and per

> part1 
> https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c
> part2 
> https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030

> it only affects gfortran >= 7, and my Debian stable fileserver shows gcc
> still the default so no rush.
 
> | > In principle I think all Fortran BLAS/LAPACK implementations (refblas
> | > and ATLAS) packaged for buster should be recompiled with
> | > -fno-optimize-sibling-calls (they may be fine in case they were compiled
> | > with older version of gfortran-8, but then the next rebuild will cause
> | > trouble): Dirk, any chance you could get the package maintainers to make
> | > these changes?
> | 
> | It seems to me this is of relevance for for Sébastien (Ccing), or more 
> | generally for debian-science.

> Not really. I do not think anybody concluded our LAPACK/BLAS needed to be
> recompiled.  The discussion about this has been going on for a few weeks and
> is now also between gcc/gfortran upstream and the lapack folks. See Tomas's
> posts on (IIRC) r-devel.

> So in short, things are moving, and in the right direction. Also worth
> recalling that the _initial findings_ were and still are about a gcc /
> gfortran version _not even in Debian unstable yet_ (but the folks in
> Fedora once again jumped the gun and they now have that problem with
> gfortran 9).

Afaics, the issue certainly affects current gfortran-8 in testing?

-k

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Dirk Eddelbuettel]

On 10 May 2019 at 10:52, Johannes Ranke wrote:
| Thanks, that sounds good. But I need some help as I do not know much about 
| autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) or 
| do we need to update configure as well (r76468)?

Again, that would happen in the sources you pick up from me, and per

part1 
https://github.com/wch/r-source/commit/d60792d3f404cc970ab33ebee1d4481a770ec15c
part2 
https://github.com/wch/r-source/commit/05046138c6fa9b40b9676f6b67498d74281d5030

it only affects gfortran >= 7, and my Debian stable fileserver shows gcc
still the default so no rush.
 
| > In principle I think all Fortran BLAS/LAPACK implementations (refblas
| > and ATLAS) packaged for buster should be recompiled with
| > -fno-optimize-sibling-calls (they may be fine in case they were compiled
| > with older version of gfortran-8, but then the next rebuild will cause
| > trouble): Dirk, any chance you could get the package maintainers to make
| > these changes?
| 
| It seems to me this is of relevance for for Sébastien (Ccing), or more 
| generally for debian-science.

Not really. I do not think anybody concluded our LAPACK/BLAS needed to be
recompiled.  The discussion about this has been going on for a few weeks and
is now also between gcc/gfortran upstream and the lapack folks. See Tomas's
posts on (IIRC) r-devel.

So in short, things are moving, and in the right direction. Also worth
recalling that the _initial findings_ were and still are about a gcc /
gfortran version _not even in Debian unstable yet_ (but the folks in Fedora
once again jumped the gun and they now have that problem with gfortran 9).

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Johannes Ranke]

Kurt,

Am Donnerstag, 9. Mai 2019, 16:35:24 CEST schrieb Kurt Hornik:
> > Johannes Ranke writes:
> Johannes,
> 
> It seems that one can avoid the gfortran problems with Fortran
> BLAS/LAPACK implementations by compiling with
> -fno-optimize-sibling-calls.

...

> Yesterday I changed R-devel and R-patched to use
> -fno-optimize-sibling-calls for gfortran >= 7: it would be great if you
> could pull this change into the R 3.6.0 backports for buster.

Thanks, that sounds good. But I need some help as I do not know much about 
autoconf and Debian packaging: Is it enough to patch configure.ac (r76467) or 
do we need to update configure as well (r76468)?

> In principle I think all Fortran BLAS/LAPACK implementations (refblas
> and ATLAS) packaged for buster should be recompiled with
> -fno-optimize-sibling-calls (they may be fine in case they were compiled
> with older version of gfortran-8, but then the next rebuild will cause
> trouble): Dirk, any chance you could get the package maintainers to make
> these changes?

It seems to me this is of relevance for for Sébastien (Ccing), or more 
generally for debian-science.

Kind regards,

Johannes

> 
> Best
> -k
> 
> > Am Montag, 29. April 2019, 15:03:54 CEST schrieb Kurt Hornik:
> >> > Johannes Ranke writes:
> >> > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
> >> >> > Johannes Ranke writes:
> >> >> Thanks.  You may have seen that with current gfortran in
> >> >> testing/unstable, there are problems with the R BLAS/LAPACK API
> >> >> entries
> >> >> using a Fortran interface (and hence in particular when using the BLAS
> >> >> and LAPACK sources that ship with R).
> >> > 
> >> > No, I wasn't aware of this. Is there a bug report where this is
> >> > discussed?
> >> 
> >> Not really, as the issue seems to complicated to condense into a bug
> >> report.  From discussions with Thomas Koenig from the GCC team, it seems
> >> that f2c, g77 and now gfortran have always added additional character
> >> length arguments for each character argument, where the R
> >> F77_NAME/F77_CALL mechanism has always called with the arguments of the
> >> Fortran subroutine but without the additional length arguments.  A
> >> change in gcc trunk also ported to gcc-8-branch apparently changed what
> >> happened in such case, to the effect that we're now seeing about 25
> >> CRAN packages fail their run time checks with segfaults or run time
> >> errors ...
> >> 
> >> But things are actually hard to pin down for us, and no obvious "fix"
> >> is in sight.  It would be great if at least for the gfortran-8 that
> >> Debian will release we would get the old behavior back ...
> > 
> > I think the likelihood of this would be greater if there was a bug against
> > the version of gfortran in unstable/testing... Can you give a small
> > reproducible example?
> > 
> > Johannes
> > 
> >> Best
> >> -k
> >> 
> >> > Johannes
> >> > 
> >> >> It seems I can avoid these using
> >> >> OpenBLAS (but then this really only works find for me provided I
> >> >> setenv
> >> >> OPENBLAS_NUM_THREADS=1).
> >> >> 
> >> >> -k
> >> >> 
> >> >> > Dear all,
> >> >> > Now that the upcoming Debian release "buster" is frozen, I have
> >> >> > started
> >> >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0
> >> >> > is
> >> >> > now
> >> >> > available for Debian buster on i386 and amd64 architectures. Please
> >> >> > refer
> >> >> > to>
> >> >> > 
> >> >> >   https://cran.r-project.org/bin/linux/debian/
> >> >> > 
> >> >> > for details. At the moment I am not providing binaries for the arm
> >> >> > architecture for buster, as the SD card in my raspberry 3 has died
> >> >> > and
> >> >> > I
> >> >> > do
> >> >> > not use these binaries any more anyways. Let me know if this is a
> >> >> > problem.
> >> >> > 
> >> >> > Kind regards,
> >> >> > 
> >> >> > Johannes
> >> >> > 
> >> >> > ___
> >> >> > R-SIG-Debian mailing list
> >> >> > R-SIG-Debian@r-project.org
> >> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
> >> 
> >> ___
> >> R-SIG-Debian mailing list
> >> R-SIG-Debian@r-project.org
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
PD Dr. Johannes Ranke
Grenzach-Wyhlen

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Dirk Eddelbuettel]

On 9 May 2019 at 10:07, Dirk Eddelbuettel wrote:
| Kurt, there is one thing that has been bugging me too and I was wondering if
| I could lean on you as I have not had time work it out. It seems that one
| "should" be to set an environment variable to suppress additional
| "non-portable compiler flags used" warnings.  We get those from Debian as
| distro-imposed flags I cannot ("should not") override; they are everywhere:
| Debian, backport, Ubuntu, Michael's PPA, hence Travis, ...  and users are
| confused (see e.g. r-package-devel).
| 
| Can you and I pretty-please work either a quick patch we fold in, or a set
| set via an environment variable in the Renviron.site we ship?  I couldn't
| make the latter approach work yet.
| 
| Example from most recent Travis build of mine:
|   * checking compilation flags used ... NOTE
|   Compilation used the following non-portable flag(s):
| ‘-Werror=format-security’ ‘-Wformat’
|   * checking compiled code ... OK
| 
| Source https://travis-ci.org/eddelbuettel/digest/builds/530216741
| 
| Happy to take off-list.

I would appear that I had forgotten that I had half-fixed that. My
~/.R/check.Renviron contains this at the end

[... stuff omitted ...]
#
# edd Apr 2019
_R_CHECK_COMPILATION_FLAGS_=TRUE
_R_CHECK_COMPILATION_FLAGS_KNOWN_="-Wno-class-memaccess -Wno-ignored-attributes 
-Wno-misleading-indentation -Wno-unused"

so presumably carrying that line over would help. Sebastian Meyer also kind
sent me pretty mich the same line off-list which he had added to his 
~/.Renviron.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Dirk Eddelbuettel]

On 9 May 2019 at 16:35, Kurt Hornik wrote:
| > Johannes Ranke writes:
| 
| Johannes, 
| 
| It seems that one can avoid the gfortran problems with Fortran
| BLAS/LAPACK implementations by compiling with
| -fno-optimize-sibling-calls.  
| 
| Tomas recently wrote to R Core that
| 
| *
| - gfortran is leaning to (but no official announcement decision has 
| already been reached) making -fno-optimize-sibling-calls the default as 
| not to break BLAS/LAPACK, at least temporarily to give BLAS/LAPACK 
| authors some time to fix
| 
| - gfortran developers started discussing the issue with reference lapack 
| maintainers on github, suggesting that the reference should use wrappers 
| using portable C bindings using BIND(C) (which I've been suggesting to 
| the gfortran developers as I saw it in "Numerical Computing with Modern 
| Fortran" but of course they would have known too)
| *
| 
| See 
| 
| https://github.com/Reference-LAPACK/lapack/issues/339
| https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
| 
| for more information.
| 
| Yesterday I changed R-devel and R-patched to use
| -fno-optimize-sibling-calls for gfortran >= 7: it would be great if you
| could pull this change into the R 3.6.0 backports for buster.
| 
| In principle I think all Fortran BLAS/LAPACK implementations (refblas
| and ATLAS) packaged for buster should be recompiled with
| -fno-optimize-sibling-calls (they may be fine in case they were compiled
| with older version of gfortran-8, but then the next rebuild will cause
| trouble): Dirk, any chance you could get the package maintainers to make
| these changes?

If I make them in Debian package it usually just flows to Johannes (for
Debian backports) and Michael (for Ubuntu) as those two gentlemen are very
reliable too.


Kurt, there is one thing that has been bugging me too and I was wondering if
I could lean on you as I have not had time work it out. It seems that one
"should" be to set an environment variable to suppress additional
"non-portable compiler flags used" warnings.  We get those from Debian as
distro-imposed flags I cannot ("should not") override; they are everywhere:
Debian, backport, Ubuntu, Michael's PPA, hence Travis, ...  and users are
confused (see e.g. r-package-devel).

Can you and I pretty-please work either a quick patch we fold in, or a set
set via an environment variable in the Renviron.site we ship?  I couldn't
make the latter approach work yet.

Example from most recent Travis build of mine:
  * checking compilation flags used ... NOTE
  Compilation used the following non-portable flag(s):
‘-Werror=format-security’ ‘-Wformat’
  * checking compiled code ... OK

Source https://travis-ci.org/eddelbuettel/digest/builds/530216741

Happy to take off-list.

Dirk

| Best
| -k 
| 
| 
| 
| 
| > Am Montag, 29. April 2019, 15:03:54 CEST schrieb Kurt Hornik:
| >> > Johannes Ranke writes:
| >> > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
| >> >> > Johannes Ranke writes:
| >> >> Thanks.  You may have seen that with current gfortran in
| >> >> testing/unstable, there are problems with the R BLAS/LAPACK API entries
| >> >> using a Fortran interface (and hence in particular when using the BLAS
| >> >> and LAPACK sources that ship with R).
| >> > 
| >> > No, I wasn't aware of this. Is there a bug report where this is
| >> > discussed?
| >> 
| >> Not really, as the issue seems to complicated to condense into a bug
| >> report.  From discussions with Thomas Koenig from the GCC team, it seems
| >> that f2c, g77 and now gfortran have always added additional character
| >> length arguments for each character argument, where the R
| >> F77_NAME/F77_CALL mechanism has always called with the arguments of the
| >> Fortran subroutine but without the additional length arguments.  A
| >> change in gcc trunk also ported to gcc-8-branch apparently changed what
| >> happened in such case, to the effect that we're now seeing about 25
| >> CRAN packages fail their run time checks with segfaults or run time
| >> errors ...
| >> 
| >> But things are actually hard to pin down for us, and no obvious "fix"
| >> is in sight.  It would be great if at least for the gfortran-8 that
| >> Debian will release we would get the old behavior back ...
| 
| > I think the likelihood of this would be greater if there was a bug against 
the 
| > version of gfortran in unstable/testing... Can you give a small 
reproducible 
| > example?
| 
| > Johannes
| 
| >> 
| >> Best
| >> -k
| >> 
| >> > Johannes
| >> > 
| >> >> It seems I can avoid these using
| >> >> OpenBLAS (but then this really only works find for me provided I setenv
| >> >> OPENBLAS_NUM_THREADS=1).
| >> >> 
| >> >> -k
| >> >> 
| >> >> > Dear all,
| >> >> > Now that the upcoming Debian release "buster" is frozen, I have 
started
| >> >> > supplying backports for it. Pending mirror 

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

> Johannes Ranke writes:

Johannes, 

It seems that one can avoid the gfortran problems with Fortran
BLAS/LAPACK implementations by compiling with
-fno-optimize-sibling-calls.  

Tomas recently wrote to R Core that

*
- gfortran is leaning to (but no official announcement decision has 
already been reached) making -fno-optimize-sibling-calls the default as 
not to break BLAS/LAPACK, at least temporarily to give BLAS/LAPACK 
authors some time to fix

- gfortran developers started discussing the issue with reference lapack 
maintainers on github, suggesting that the reference should use wrappers 
using portable C bindings using BIND(C) (which I've been suggesting to 
the gfortran developers as I saw it in "Numerical Computing with Modern 
Fortran" but of course they would have known too)
*

See 

https://github.com/Reference-LAPACK/lapack/issues/339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329

for more information.

Yesterday I changed R-devel and R-patched to use
-fno-optimize-sibling-calls for gfortran >= 7: it would be great if you
could pull this change into the R 3.6.0 backports for buster.

In principle I think all Fortran BLAS/LAPACK implementations (refblas
and ATLAS) packaged for buster should be recompiled with
-fno-optimize-sibling-calls (they may be fine in case they were compiled
with older version of gfortran-8, but then the next rebuild will cause
trouble): Dirk, any chance you could get the package maintainers to make
these changes?

Best
-k 




> Am Montag, 29. April 2019, 15:03:54 CEST schrieb Kurt Hornik:
>> > Johannes Ranke writes:
>> > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
>> >> > Johannes Ranke writes:
>> >> Thanks.  You may have seen that with current gfortran in
>> >> testing/unstable, there are problems with the R BLAS/LAPACK API entries
>> >> using a Fortran interface (and hence in particular when using the BLAS
>> >> and LAPACK sources that ship with R).
>> > 
>> > No, I wasn't aware of this. Is there a bug report where this is
>> > discussed?
>> 
>> Not really, as the issue seems to complicated to condense into a bug
>> report.  From discussions with Thomas Koenig from the GCC team, it seems
>> that f2c, g77 and now gfortran have always added additional character
>> length arguments for each character argument, where the R
>> F77_NAME/F77_CALL mechanism has always called with the arguments of the
>> Fortran subroutine but without the additional length arguments.  A
>> change in gcc trunk also ported to gcc-8-branch apparently changed what
>> happened in such case, to the effect that we're now seeing about 25
>> CRAN packages fail their run time checks with segfaults or run time
>> errors ...
>> 
>> But things are actually hard to pin down for us, and no obvious "fix"
>> is in sight.  It would be great if at least for the gfortran-8 that
>> Debian will release we would get the old behavior back ...

> I think the likelihood of this would be greater if there was a bug against 
> the 
> version of gfortran in unstable/testing... Can you give a small reproducible 
> example?

> Johannes

>> 
>> Best
>> -k
>> 
>> > Johannes
>> > 
>> >> It seems I can avoid these using
>> >> OpenBLAS (but then this really only works find for me provided I setenv
>> >> OPENBLAS_NUM_THREADS=1).
>> >> 
>> >> -k
>> >> 
>> >> > Dear all,
>> >> > Now that the upcoming Debian release "buster" is frozen, I have started
>> >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is
>> >> > now
>> >> > available for Debian buster on i386 and amd64 architectures. Please
>> >> > refer
>> >> > to>
>> >> > 
>> >> >   https://cran.r-project.org/bin/linux/debian/
>> >> > 
>> >> > for details. At the moment I am not providing binaries for the arm
>> >> > architecture for buster, as the SD card in my raspberry 3 has died and
>> >> > I
>> >> > do
>> >> > not use these binaries any more anyways. Let me know if this is a
>> >> > problem.
>> >> > 
>> >> > Kind regards,
>> >> > 
>> >> > Johannes
>> >> > 
>> >> > ___
>> >> > R-SIG-Debian mailing list
>> >> > R-SIG-Debian@r-project.org
>> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>> 
>> ___
>> R-SIG-Debian mailing list
>> R-SIG-Debian@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


> -- 
> PD Dr. Johannes Ranke
> Grenzach-Wyhlen

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

> Dirk Eddelbuettel writes:

> On 29 April 2019 at 15:03, Kurt Hornik wrote:
> | > Johannes Ranke writes:
> | 
> | > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
> | >> > Johannes Ranke writes:
> | >> Thanks.  You may have seen that with current gfortran in
> | >> testing/unstable, there are problems with the R BLAS/LAPACK API entries
> | >> using a Fortran interface (and hence in particular when using the BLAS
> | >> and LAPACK sources that ship with R).
> | 
> | > No, I wasn't aware of this. Is there a bug report where this is
> | > discussed?
> | 
> | Not really, as the issue seems to complicated to condense into a bug
> | report.  From discussions with Thomas Koenig from the GCC team, it seems
> | that f2c, g77 and now gfortran have always added additional character
> | length arguments for each character argument, where the R
> | F77_NAME/F77_CALL mechanism has always called with the arguments of the
> | Fortran subroutine but without the additional length arguments.  A
> | change in gcc trunk also ported to gcc-8-branch apparently changed what
> | happened in such case, to the effect that we're now seeing about 25
> | CRAN packages fail their run time checks with segfaults or run time
> | errors ...
> | 
> | But things are actually hard to pin down for us, and no obvious "fix"
> | is in sight.  It would be great if at least for the gfortran-8 that
> | Debian will release we would get the old behavior back ...

> From what I saw, the change is triggered by 'lto' -- link-time
> optimisation.  A genuinely desirable feature (which can lead to
> improved performance from 'whole program' view) which however appears
> to have a side effect with older Fortran code and its calling
> convention.

> Note, however, that Debian unstable still has the 8.3.* branch. As
> such I would find that it is a little early to ring alarm bells at
> full tilt. CCing Martyn who use the R Foundation twitter handle for
> one such alarm.  Without commensurate discussion on r-devel or
> r-package-devel this may not help much.

Dirk: Martyn has a first tweet coming up shortly.

The change is actually not triggered by lto, but illustrated.  From what
we learned, calling Fortran from C without the additional character
length arguments for character arguments (as done in the R API) now
works differently as before, breaking at least about 25 CRAN packages,
half of which with segfaults.  And that compiler change is in the trunk
since several months but was ported to gcc-8-branch about a month ago,
and more or less immediately picked up in the gfortran-8 package in
testing/unstable ...

-k

> Dirk

> | 
> | Best
> | -k
> | 
> | > Johannes
> | 
> | >> It seems I can avoid these using
> | >> OpenBLAS (but then this really only works find for me provided I setenv
> | >> OPENBLAS_NUM_THREADS=1).
> | >> 
> | >> -k
> | >> 
> | >> > Dear all,
> | >> > Now that the upcoming Debian release "buster" is frozen, I have started
> | >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is
> | >> > now
> | >> > available for Debian buster on i386 and amd64 architectures. Please 
> refer
> | >> > to> 
> | >> >   https://cran.r-project.org/bin/linux/debian/
> | >> > 
> | >> > for details. At the moment I am not providing binaries for the arm
> | >> > architecture for buster, as the SD card in my raspberry 3 has died and 
> I
> | >> > do
> | >> > not use these binaries any more anyways. Let me know if this is a 
> problem.
> | >> > 
> | >> > Kind regards,
> | >> > 
> | >> > Johannes
> | >> > 
> | >> > ___
> | >> > R-SIG-Debian mailing list
> | >> > R-SIG-Debian@r-project.org
> | >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
> | 
> | ___
> | R-SIG-Debian mailing list
> | R-SIG-Debian@r-project.org
> | https://stat.ethz.ch/mailman/listinfo/r-sig-debian

> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Dirk Eddelbuettel]

On 29 April 2019 at 15:03, Kurt Hornik wrote:
| > Johannes Ranke writes:
| 
| > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
| >> > Johannes Ranke writes:
| >> Thanks.  You may have seen that with current gfortran in
| >> testing/unstable, there are problems with the R BLAS/LAPACK API entries
| >> using a Fortran interface (and hence in particular when using the BLAS
| >> and LAPACK sources that ship with R).
| 
| > No, I wasn't aware of this. Is there a bug report where this is
| > discussed?
| 
| Not really, as the issue seems to complicated to condense into a bug
| report.  From discussions with Thomas Koenig from the GCC team, it seems
| that f2c, g77 and now gfortran have always added additional character
| length arguments for each character argument, where the R
| F77_NAME/F77_CALL mechanism has always called with the arguments of the
| Fortran subroutine but without the additional length arguments.  A
| change in gcc trunk also ported to gcc-8-branch apparently changed what
| happened in such case, to the effect that we're now seeing about 25
| CRAN packages fail their run time checks with segfaults or run time
| errors ...
| 
| But things are actually hard to pin down for us, and no obvious "fix"
| is in sight.  It would be great if at least for the gfortran-8 that
| Debian will release we would get the old behavior back ...

>From what I saw, the change is triggered by 'lto' -- link-time optimisation.
A genuinely desirable feature (which can lead to improved performance from
'whole program' view) which however appears to have a side effect with older
Fortran code and its calling convention.

Note, however, that Debian unstable still has the 8.3.* branch. As such I
would find that it is a little early to ring alarm bells at full tilt. CCing
Martyn who use the R Foundation twitter handle for one such alarm.  Without
commensurate discussion on r-devel or r-package-devel this may not help much.

Dirk

| 
| Best
| -k
| 
| > Johannes
| 
| >> It seems I can avoid these using
| >> OpenBLAS (but then this really only works find for me provided I setenv
| >> OPENBLAS_NUM_THREADS=1).
| >> 
| >> -k
| >> 
| >> > Dear all,
| >> > Now that the upcoming Debian release "buster" is frozen, I have started
| >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is
| >> > now
| >> > available for Debian buster on i386 and amd64 architectures. Please refer
| >> > to> 
| >> >   https://cran.r-project.org/bin/linux/debian/
| >> > 
| >> > for details. At the moment I am not providing binaries for the arm
| >> > architecture for buster, as the SD card in my raspberry 3 has died and I
| >> > do
| >> > not use these binaries any more anyways. Let me know if this is a 
problem.
| >> > 
| >> > Kind regards,
| >> > 
| >> > Johannes
| >> > 
| >> > ___
| >> > R-SIG-Debian mailing list
| >> > R-SIG-Debian@r-project.org
| >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
| 
| ___
| R-SIG-Debian mailing list
| R-SIG-Debian@r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Johannes Ranke]

Am Montag, 29. April 2019, 15:03:54 CEST schrieb Kurt Hornik:
> > Johannes Ranke writes:
> > Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
> >> > Johannes Ranke writes:
> >> Thanks.  You may have seen that with current gfortran in
> >> testing/unstable, there are problems with the R BLAS/LAPACK API entries
> >> using a Fortran interface (and hence in particular when using the BLAS
> >> and LAPACK sources that ship with R).
> > 
> > No, I wasn't aware of this. Is there a bug report where this is
> > discussed?
> 
> Not really, as the issue seems to complicated to condense into a bug
> report.  From discussions with Thomas Koenig from the GCC team, it seems
> that f2c, g77 and now gfortran have always added additional character
> length arguments for each character argument, where the R
> F77_NAME/F77_CALL mechanism has always called with the arguments of the
> Fortran subroutine but without the additional length arguments.  A
> change in gcc trunk also ported to gcc-8-branch apparently changed what
> happened in such case, to the effect that we're now seeing about 25
> CRAN packages fail their run time checks with segfaults or run time
> errors ...
> 
> But things are actually hard to pin down for us, and no obvious "fix"
> is in sight.  It would be great if at least for the gfortran-8 that
> Debian will release we would get the old behavior back ...

I think the likelihood of this would be greater if there was a bug against the 
version of gfortran in unstable/testing... Can you give a small reproducible 
example?

Johannes

> 
> Best
> -k
> 
> > Johannes
> > 
> >> It seems I can avoid these using
> >> OpenBLAS (but then this really only works find for me provided I setenv
> >> OPENBLAS_NUM_THREADS=1).
> >> 
> >> -k
> >> 
> >> > Dear all,
> >> > Now that the upcoming Debian release "buster" is frozen, I have started
> >> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is
> >> > now
> >> > available for Debian buster on i386 and amd64 architectures. Please
> >> > refer
> >> > to>
> >> > 
> >> >   https://cran.r-project.org/bin/linux/debian/
> >> > 
> >> > for details. At the moment I am not providing binaries for the arm
> >> > architecture for buster, as the SD card in my raspberry 3 has died and
> >> > I
> >> > do
> >> > not use these binaries any more anyways. Let me know if this is a
> >> > problem.
> >> > 
> >> > Kind regards,
> >> > 
> >> > Johannes
> >> > 
> >> > ___
> >> > R-SIG-Debian mailing list
> >> > R-SIG-Debian@r-project.org
> >> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
PD Dr. Johannes Ranke
Grenzach-Wyhlen

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

> Johannes Ranke writes:

> Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
>> > Johannes Ranke writes:
>> Thanks.  You may have seen that with current gfortran in
>> testing/unstable, there are problems with the R BLAS/LAPACK API entries
>> using a Fortran interface (and hence in particular when using the BLAS
>> and LAPACK sources that ship with R).

> No, I wasn't aware of this. Is there a bug report where this is
> discussed?

Not really, as the issue seems to complicated to condense into a bug
report.  From discussions with Thomas Koenig from the GCC team, it seems
that f2c, g77 and now gfortran have always added additional character
length arguments for each character argument, where the R
F77_NAME/F77_CALL mechanism has always called with the arguments of the
Fortran subroutine but without the additional length arguments.  A
change in gcc trunk also ported to gcc-8-branch apparently changed what
happened in such case, to the effect that we're now seeing about 25
CRAN packages fail their run time checks with segfaults or run time
errors ...

But things are actually hard to pin down for us, and no obvious "fix"
is in sight.  It would be great if at least for the gfortran-8 that
Debian will release we would get the old behavior back ...

Best
-k

> Johannes

>> It seems I can avoid these using
>> OpenBLAS (but then this really only works find for me provided I setenv
>> OPENBLAS_NUM_THREADS=1).
>> 
>> -k
>> 
>> > Dear all,
>> > Now that the upcoming Debian release "buster" is frozen, I have started
>> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is
>> > now
>> > available for Debian buster on i386 and amd64 architectures. Please refer
>> > to> 
>> >   https://cran.r-project.org/bin/linux/debian/
>> > 
>> > for details. At the moment I am not providing binaries for the arm
>> > architecture for buster, as the SD card in my raspberry 3 has died and I
>> > do
>> > not use these binaries any more anyways. Let me know if this is a problem.
>> > 
>> > Kind regards,
>> > 
>> > Johannes
>> > 
>> > ___
>> > R-SIG-Debian mailing list
>> > R-SIG-Debian@r-project.org
>> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Johannes Ranke]

Am Montag, 29. April 2019, 13:44:03 CEST schrieb Kurt Hornik:
> > Johannes Ranke writes:
> Thanks.  You may have seen that with current gfortran in
> testing/unstable, there are problems with the R BLAS/LAPACK API entries
> using a Fortran interface (and hence in particular when using the BLAS
> and LAPACK sources that ship with R).

No, I wasn't aware of this. Is there a bug report where this is discussed?

Johannes

> It seems I can avoid these using
> OpenBLAS (but then this really only works find for me provided I setenv
> OPENBLAS_NUM_THREADS=1).
>
> -k
> 
> > Dear all,
> > Now that the upcoming Debian release "buster" is frozen, I have started
> > supplying backports for it. Pending mirror synchronisations, R 3.6.0 is
> > now
> > available for Debian buster on i386 and amd64 architectures. Please refer
> > to> 
> >   https://cran.r-project.org/bin/linux/debian/
> > 
> > for details. At the moment I am not providing binaries for the arm
> > architecture for buster, as the SD card in my raspberry 3 has died and I
> > do
> > not use these binaries any more anyways. Let me know if this is a problem.
> > 
> > Kind regards,
> > 
> > Johannes
> > 
> > ___
> > R-SIG-Debian mailing list
> > R-SIG-Debian@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian

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

Re: [R-sig-Debian] R 3.6.0 for Debian buster

[Kurt Hornik]

> Johannes Ranke writes:

Thanks.  You may have seen that with current gfortran in
testing/unstable, there are problems with the R BLAS/LAPACK API entries
using a Fortran interface (and hence in particular when using the BLAS
and LAPACK sources that ship with R).  It seems I can avoid these using
OpenBLAS (but then this really only works find for me provided I setenv
OPENBLAS_NUM_THREADS=1).

-k

> Dear all,
> Now that the upcoming Debian release "buster" is frozen, I have started 
> supplying backports for it. Pending mirror synchronisations, R 3.6.0 is now 
> available for Debian buster on i386 and amd64 architectures. Please refer to 

>   https://cran.r-project.org/bin/linux/debian/

> for details. At the moment I am not providing binaries for the arm 
> architecture for buster, as the SD card in my raspberry 3 has died and I do 
> not use these binaries any more anyways. Let me know if this is a problem.

> Kind regards,

> Johannes

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

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

Re: [R-sig-Debian] r-api-3 with R 3.5.2. on Stretch: is there a workaround?

[Chris Evans]

Thanks for confirming Johannes.  I take it that the "new, richer ..." option 
would be a lot of work.  I'm happy to let this old laptop grind through.  
There's the silver lining for me that when I did this install.packages() for 
pretty much the same list of packages on the server it ran through it pretty 
fast so it's nice that the laptop is reminding me how fast the server is!

Very best to all,

Chris

- Original Message -
> From: "Johannes Ranke" 
> To: "r-sig-debian" , "Chris Evans" 
> 
> Sent: Monday, 21 January, 2019 14:12:07
> Subject: Re: [R-sig-Debian] r-api-3 with R 3.5.2. on Stretch: is there a 
> workaround?

> Chris,
> 
> yes, the workaround is to install from within R. The alternative would be to
> increase the coverage of this repo, as currently mainly the recommended
> packages are supported. Another alternative would be to create a new, richer
> repo...
> 
> Kind regards,
> 
> Johannes
> 
> Am Montag, 21. Januar 2019, 13:45:52 CET schrieb Chris Evans:
>> Now that I am at least mapping the right repository to my Debian version
>> (doh!) I have another question. In the installation page at
>> https://cran.r-project.org/bin/linux/debian/#debian-stretch-stable there is
>> the line:
>> 
>> "Please note that R packages from the Debian stretch distribution are not
>> compatible with R 3.5.x, as it provides r-api-3.5, while the stretch
>> packages depend on r-api-3."
>> 
>> Certainly a number of packages won't install with Synaptic giving the
>> complaint about depending on r-api-3 and not having it, exactly as that
>> line says.  It seems that one package that gives this error, car, builds
>> fine in R with the usual install.packages("car") (after dealing with the
>> curl library dependency).
>> 
>> Am I right that the workaround is to install all the affected packages
>> within R?  On the very slow old laptop I'm using for this work that is
>> taking ages and I'm guessing that had I been able to install the debs the
>> installation would have been much faster.
>> 
>> Is there a workaround or am I right that installing within R _is_ the
>> workaround?
>> 
>> TIA (again),
>> 
>> Chris
> 
> 
> --
> Johannes Ranke
> Wissenschaftlicher Berater
> https://jrwb.de/contact

-- 
Chris Evans  Skype: chris-psyctc
Visiting Professor, University of Sheffield 
I do some consultation work for the University of Roehampton 
 and other places but this  
remains my main Email address.
I have "semigrated" to France, see: 
https://www.psyctc.org/pelerinage2016/semigrating-to-france/ if you want to 
book to talk, I am trying to keep that to Thursdays and my diary is now 
available at: https://www.psyctc.org/pelerinage2016/ecwd_calendar/calendar/
Beware: French time, generally an hour ahead of UK.  That page will also take 
you to my blog which started with earlier joys in France and Spain!

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

Re: [R-sig-Debian] r-api-3 with R 3.5.2. on Stretch: is there a workaround?

[Johannes Ranke]

Chris,

yes, the workaround is to install from within R. The alternative would be to 
increase the coverage of this repo, as currently mainly the recommended 
packages are supported. Another alternative would be to create a new, richer 
repo...

Kind regards,

Johannes

Am Montag, 21. Januar 2019, 13:45:52 CET schrieb Chris Evans:
> Now that I am at least mapping the right repository to my Debian version
> (doh!) I have another question. In the installation page at
> https://cran.r-project.org/bin/linux/debian/#debian-stretch-stable there is
> the line:
> 
> "Please note that R packages from the Debian stretch distribution are not
> compatible with R 3.5.x, as it provides r-api-3.5, while the stretch
> packages depend on r-api-3."
> 
> Certainly a number of packages won't install with Synaptic giving the
> complaint about depending on r-api-3 and not having it, exactly as that
> line says.  It seems that one package that gives this error, car, builds
> fine in R with the usual install.packages("car") (after dealing with the
> curl library dependency).
> 
> Am I right that the workaround is to install all the affected packages
> within R?  On the very slow old laptop I'm using for this work that is
> taking ages and I'm guessing that had I been able to install the debs the
> installation would have been much faster.
> 
> Is there a workaround or am I right that installing within R _is_ the
> workaround?
> 
> TIA (again),
> 
> Chris


-- 
Johannes Ranke
Wissenschaftlicher Berater
https://jrwb.de/contact

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

Re: [R-sig-Debian] R Commander does not work on Ubuntu 18.04

[Erin Hodgess]

Hello Juliano:

Are your data sets actually data frames, please?

Thanks,
Erin

Erin Hodgess, PhD
mailto: erinm.hodg...@gmail.com


On Tue, Oct 30, 2018 at 1:00 PM Juliano Mota  wrote:

> Hello my friends! I'm encountering problems using the R Commander package.
> In the "statistics" menu the "average" commands, tests for the mean, are
> inactive all the time, even when I already have a dataset. I use Ubuntu
> 18.04, everything is up to date and my machine is an i7 with 8GB of RAM. I
> installed ALL R packages available on the servers.
>
> What am I doing wrong?
>
> --
> 
> Juliano Fabiano da Mota
> 
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 154, Issue 8

[Clive Nicholas]

On 23 July 2018 at 11:00,  wrote:

Message: 1
> Date: Mon, 23 Jul 2018 02:08:47 +
> From: Alison Smith 
> To: "r-sig-debian@r-project.org" 
> Subject: [R-sig-Debian] Ubuntu issue with 18.04 Bionic Beaver
> Message-ID: <1532311727386.27...@uow.edu.au>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Debian persons
>
> I would like enquire about whether the repository
>
> deb https://cloud.r-project.org/bin/linux/ubuntu bionic-cran35/
>
> I tried to follow the instructions and I cannot get R3.5.1 - I get
> R3.4.4???
>
>
> I have been able to install R3.5.1 on Ubuntu 16.02 using the
> xenial-cran35/ repository & so not sure if the bionic link is up to date?
>
>
> thanks in advance
>
>
>
> Regards
> Alison
>
>
>
> Alison Smith
> Principal Research Fellow
> National Institute for Applied Statistics Research Australia (NIASRA)
> School of Mathematics & Applied Statistics
> Faculty of Engineering & Information Sciences
> Building 39C Room 261
> University of Wollongong NSW 2522
> M: 0417 947 115
> E: alism...@uow.edu.au
> W: http://niasra.uow.edu.au/index.html
>

I've submitted a post to the list (subject to approval) which should answer
your question. If it doesn't go through, email me privately and I'll send
it to you.

-- 
Clive Nicholas

"My colleagues in the social sciences talk a great deal about methodology.
I prefer to call it style." -- Freeman J. Dyson

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] r-base-dev not installing in Ubuntu 16.04

[Michael Rutter]

On 06/13/2018 04:23 PM, Dirk Eddelbuettel wrote:


On 13 June 2018 at 20:54, Robin Lovelace wrote:
| I have recently re-installed R on my Ubuntu system to get R 3.5 and found
| this to have worked:
|
| # you may need to remove incumbent repos e.g. with:
| sudo apt-add-repository --remove ppa:marutter/rrutter
|
| # add new repos
| sudo apt-add-repository ppa:marutter/rrutter3.5 # for base R
| sudo apt-add-repository ppa:marutter/c2d4u4.5  # for pkgs - this saved me
| lots of time installing my set-up

*Very* good point.  Given that what Michael does is outside of the distro, we
  are lacking some bells and whistles -- and moreover some check and balances
  I get thrown at me from within the distro and its quality checks.

So one thing we had run into was inconsistent versioning  so the "old" PPAs
may have shadowed the new one with the dh-r version wanted -- but 'hidden'
behind a higher version number. (This can happens as the version strings get
expanded with Ubuntu distro strings added etc pp).

So an implicit "reset" by only looking at one pair is a very good ides,

|
| At the end of it these are the only R-related repos I have:
|
| apt policy | grep 3.5
|
| # 500 http://ppa.launchpad.net/marutter/rrutter3.5/ubuntu xenial/main i386
| Packages
| # release
| v=16.04,o=LP-PPA-marutter-rrutter3.5,a=xenial,n=xenial,l=RRutter
| v3.5,c=main,b=i386
| # 500 http://ppa.launchpad.net/marutter/rrutter3.5/ubuntu xenial/main amd64
| Packages
| # release
| v=16.04,o=LP-PPA-marutter-rrutter3.5,a=xenial,n=xenial,l=RRutter
| v3.5,c=main,b=amd64
| # 500 http://ppa.launchpad.net/marutter/c2d4u3.5/ubuntu xenial/main i386
| Packages
| # release
| 
v=16.04,o=LP-PPA-marutter-c2d4u3.5,a=xenial,n=xenial,l=cran2deb4ubuntu_3.5,c=main,b=i386
| # 500 http://ppa.launchpad.net/marutter/c2d4u3.5/ubuntu xenial/main amd64
| Packages
| # release
| 
v=16.04,o=LP-PPA-marutter-c2d4u3.5,a=xenial,n=xenial,l=cran2deb4ubuntu_3.5,c=main,b=amd64
|
| Hope this helps. Please add-to this advice anyone who's more experienced
| than me in this.

Now why does a serious man like you still run 16.04 though?  ;-)
  
| Thanks to all involved in getting this working and documented.


Our pleasure.

Dirk


Just to complete this thread:

- If you are using a CRAN mirror to install R 3.5, there was an error in 
the configuration file that has been fixed.  It should work after the 
next CRAN sync.  This should solve Syed's original problem.


- To confirm Robin's post, regardless of which repository you use to 
install R 3.5, RRutter PPA or CRAN, you need to remove/disable the 3.4 
repositories.  Having both enabled will cause issues.


Michael

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

Re: [R-sig-Debian] r-base-dev not installing in Ubuntu 16.04

[Dirk Eddelbuettel]

On 13 June 2018 at 20:54, Robin Lovelace wrote:
| I have recently re-installed R on my Ubuntu system to get R 3.5 and found
| this to have worked:
| 
| # you may need to remove incumbent repos e.g. with:
| sudo apt-add-repository --remove ppa:marutter/rrutter
| 
| # add new repos
| sudo apt-add-repository ppa:marutter/rrutter3.5 # for base R
| sudo apt-add-repository ppa:marutter/c2d4u4.5  # for pkgs - this saved me
| lots of time installing my set-up

*Very* good point.  Given that what Michael does is outside of the distro, we
 are lacking some bells and whistles -- and moreover some check and balances
 I get thrown at me from within the distro and its quality checks.

So one thing we had run into was inconsistent versioning  so the "old" PPAs
may have shadowed the new one with the dh-r version wanted -- but 'hidden'
behind a higher version number. (This can happens as the version strings get
expanded with Ubuntu distro strings added etc pp).

So an implicit "reset" by only looking at one pair is a very good ides,

| 
| At the end of it these are the only R-related repos I have:
| 
| apt policy | grep 3.5
| 
| # 500 http://ppa.launchpad.net/marutter/rrutter3.5/ubuntu xenial/main i386
| Packages
| # release
| v=16.04,o=LP-PPA-marutter-rrutter3.5,a=xenial,n=xenial,l=RRutter
| v3.5,c=main,b=i386
| # 500 http://ppa.launchpad.net/marutter/rrutter3.5/ubuntu xenial/main amd64
| Packages
| # release
| v=16.04,o=LP-PPA-marutter-rrutter3.5,a=xenial,n=xenial,l=RRutter
| v3.5,c=main,b=amd64
| # 500 http://ppa.launchpad.net/marutter/c2d4u3.5/ubuntu xenial/main i386
| Packages
| # release
| 
v=16.04,o=LP-PPA-marutter-c2d4u3.5,a=xenial,n=xenial,l=cran2deb4ubuntu_3.5,c=main,b=i386
| # 500 http://ppa.launchpad.net/marutter/c2d4u3.5/ubuntu xenial/main amd64
| Packages
| # release
| 
v=16.04,o=LP-PPA-marutter-c2d4u3.5,a=xenial,n=xenial,l=cran2deb4ubuntu_3.5,c=main,b=amd64
| 
| Hope this helps. Please add-to this advice anyone who's more experienced
| than me in this.

Now why does a serious man like you still run 16.04 though?  ;-)
 
| Thanks to all involved in getting this working and documented.

Our pleasure.

Dirk
 
| Robin
| 
| On Wed, Jun 13, 2018 at 10:22 AM, Syed Murtuza baker <
| syed.murtuzaba...@manchester.ac.uk> wrote:
| 
| > Hello All,
| > When I try to install r-base-dev on my Ubuntu 16.04 it gives me the
| > following error
| >
| > r-base-dev : Depends: dh-r but it is not installable
| > E: Unable to correct problems, you have held broken packages.
| >
| > I added the following two repos
| >
| > deb https://mirrors.ebi.ac.uk/CRAN/bin/linux/ubuntu xenial-cran35
| > deb http://uk-mirrors.evowise.com/ubuntu/ bionic-backports main
| > restricted universe
| >
| > but still giving error. Could you please suggest me how to fix it.
| >
| > Thank you.
| >
| > Best Regards,
| > Syed
| >
| >
| > 
| > Dr. Syed Murtuza Baker
| > Bioinformatics Core Facility
| > Faculty of Biology, Medicine & Health
| > The University of Manchester
| >
| >
| > [[alternative HTML version deleted]]
| >
| > ___
| > R-SIG-Debian mailing list
| > R-SIG-Debian@r-project.org
| > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
| >
| 
|   [[alternative HTML version deleted]]
| 
| ___
| R-SIG-Debian mailing list
| R-SIG-Debian@r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 152, Issue 4

[Johannes Ranke]

Am Sonntag, 13. Mai 2018, 21:02:42 CEST schrieb Bill Harris:

...

Do I understand correctly that I should be able to replace the last line of my 
sources.list (in my reply to Dirk) with 


deb http:///bin/linux/debian stretch-cran35/

If you do this, then update and upgrade, r-cran-* or r-cran-bioc* packages 
installed via the Debian package management system will be removed, with the 
exception of r-recommended and the few packages listed in the Debian CRAN 
page. If you cannot afford that, you should stay with R 3.4.

You can check what packages will be affected as pointed out on the CRAN Debian 
page, or using apt-get upgrade -s (for silent). If this removes R packages 
your locally installed packages depend on, you need to install them from CRAN 
using install.packages or Dirks install.r afterwards.

If you then use


update.packages(lib.loc="/usr/local/lib/R/site-library", ask=FALSE, 
checkBuilt=TRUE)

this will update packages installed from CRAN (provided you use the default 
local library path) to make sure they are compatible with R>=3.5.0. Things 
installed from github and the like will have to be taken care of separately.

...

Johannes

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 152, Issue 4

[Bill Harris]

On Sun, May 13, 2018 at 9:27 AM, Johannes Ranke 
wrote:

> Hi,
>
> I wonder if you have read the notes on R 3.5.0 on stretch on
>
> https://cran.r-project.org/bin/linux/debian/
>
> I think this should answer your questions. If not, please let us know.
>
>
Johannes,

I think I have--I think that's how I got the last line in my
sources.list--but I missed it this morning in my hurry.

Do I understand correctly that I should be able to replace the last line of
my sources.list (in my reply to Dirk) with

deb http:///bin/linux/debian stretch-cran35/


and then use

update.packages(lib.loc="/usr/local/lib/R/site-library", ask=FALSE,
checkBuilt=TRUE)


to update all my packages (all packages--or just those that use Rcpp?)?
That seems to suggest I /not/ let aptitude safe-upgrade touch anything in
R, right?  I'm guessing / hoping I can use that to update all my CRAN R
packages.  Do I need to do anything to keep any of the r-cran-... Debian
packages from updating?

Figuring out which packages used Rcpp and which didn't seems tedious; am I
right?

Thanks,

Bill

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 152, Issue 4

[Bill Harris]

On Sun, May 13, 2018 at 9:30 AM, Dirk Eddelbuettel  wrote:

>
> On 13 May 2018 at 09:03, Bill Harris wrote:
> |
> | safest way to go.  Does something like this make sense:
> |
> |
> |1. aptitude safe-upgrade should be safe: there won't be any 3.5.0
> Debian
> |packages coming through until the environment is ready for them to
> come
> |through (which most likely means that base R and other Stretch R
> packages
> |are upgraded to 3.5.0?)..
>
> Unsure.
>
> You did not specify if you look only at Debian distro repositories, or if
> you
> include the backports managed by Johannes (which should be safe he plays
> along with the r-api-3.5 tag).
>

Here is my complete sources.list:

#

# deb cdrom:[Official Debian GNU/Linux Live 9.1.0 gnome 2017-07-23T04:21]/
stretch main

#deb cdrom:[Official Debian GNU/Linux Live 9.1.0 gnome 2017-07-23T04:21]/
stretch main

deb http://ftp.us.debian.org/debian/ stretch main non-free contrib
deb-src http://ftp.us.debian.org/debian/ stretch main non-free contrib

deb http://security.debian.org/debian-security stretch/updates main contrib
non-free
deb-src http://security.debian.org/debian-security stretch/updates main
contrib non-free

# stretch-updates, previously known as 'volatile'
deb http://ftp.us.debian.org/debian/ stretch-updates main contrib non-free
deb-src http://ftp.us.debian.org/debian/ stretch-updates main contrib
non-free

## R https://cran.r-project.org/
## deb https://cran.cnr.berkeley.edu/bin/linux/debian stretch-cran34/
deb http://cran.wustl.edu/bin/linux/debian stretch-cran34/

I'll be glad to take advice.


>
> |2. update.packages() inside R is /not/ safe, because it could pick up
> |problematic packages from CRAN that aren't under your control.
>
> I actually take the opposite view.
>
> I am comfortable compiling from source, so this mode happens to be my
> default. I use the littler scripts install.r and update.r _all the time_ to
> install / update.
>
>
I think I reasoned through to that once, and then I forgot.  so
install.packages() and update.packages() is safe; aptitude  safe-upgrade
may or may not be safe, depending upon what you see in my sources-list.
Right?


> |3. install.packages() inside R is /not/ safe, for the same reason.
>
> That seems to be the same as 2. so ...
>
> |4. A prominent note will be posted here, when these two restrictions
> are
> |removed.
> |
> | Are those true statements?  Would steps 2 and 3 work if the packages
> don't
> | require compiled C++ code?  If so, is there a way to tell which packages
> | are at risk without memorizing what seems like a very long list?
> |
> | If we (think we) need a new package we don't currently have installed,
> are
> | we out of luck until 3.5.0 is officially released in Stretch?
>
> Again, "pure Debian" or "Debian plus CRAN repos" ?
>

In addition to what you see in my sources.list, I've also installed a few
packages from github or similat (hydromad comes to mind).  Perhaps the CRAN
package that might test all this the most is rstan.

I'm okay if a small number of github packages--or any packages, for that
matter--fail; I just would rather not do something that makes a /lot/ of
extra work if I could avoid it.

>
> | Is there a place where an official summary of the state of the R system
> on
> | Stretch is maintained?
> |
> | I've tried to scan this list, but I may well have missed the answers to
> my
> | questions about Stretch.
>
> We're volunteers so something may always fall short somewhere.
> Documentation
> is always a good candidate.  Contributions are always welcome.
>
> I'll keep that in mind.
>

Thanks,

Bill

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 152, Issue 4

[Dirk Eddelbuettel]

On 13 May 2018 at 09:03, Bill Harris wrote:
| In these interesting times, I think you're saying that things will resolve
| themselves at some point, but we're in a transition.  I see a number of
| postings on Ubuntu, but I'm on Debian Stretch, trying to figure out the
| safest way to go.  Does something like this make sense:
| 
| 
|1. aptitude safe-upgrade should be safe: there won't be any 3.5.0 Debian
|packages coming through until the environment is ready for them to come
|through (which most likely means that base R and other Stretch R packages
|are upgraded to 3.5.0?)..

Unsure.

You did not specify if you look only at Debian distro repositories, or if you
include the backports managed by Johannes (which should be safe he plays
along with the r-api-3.5 tag).

|2. update.packages() inside R is /not/ safe, because it could pick up
|problematic packages from CRAN that aren't under your control.

I actually take the opposite view.

I am comfortable compiling from source, so this mode happens to be my
default. I use the littler scripts install.r and update.r _all the time_ to
install / update.

|3. install.packages() inside R is /not/ safe, for the same reason.

That seems to be the same as 2. so ...

|4. A prominent note will be posted here, when these two restrictions are
|removed.
| 
| Are those true statements?  Would steps 2 and 3 work if the packages don't
| require compiled C++ code?  If so, is there a way to tell which packages
| are at risk without memorizing what seems like a very long list?
| 
| If we (think we) need a new package we don't currently have installed, are
| we out of luck until 3.5.0 is officially released in Stretch?

Again, "pure Debian" or "Debian plus CRAN repos" ?
 
| Is there a place where an official summary of the state of the R system on
| Stretch is maintained?
| 
| I've tried to scan this list, but I may well have missed the answers to my
| questions about Stretch.

We're volunteers so something may always fall short somewhere. Documentation
is always a good candidate.  Contributions are always welcome.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 152, Issue 4

[Johannes Ranke]

Hi,

I wonder if you have read the notes on R 3.5.0 on stretch on

https://cran.r-project.org/bin/linux/debian/

I think this should answer your questions. If not, please let us know.

Johannes

Am Sonntag, 13. Mai 2018, 09:03:13 CEST schrieb Bill Harris:
> > Date: Sat, 5 May 2018 18:02:12 -0500
> > From: Dirk Eddelbuettel 
> > To: Matthieu S 
> > Cc: r-sig-debian@r-project.org
> > Subject: Re: [R-sig-Debian] Ubuntu 18.04 bionic: availability of R
> > 
> > Ubuntu packages/ppa?
> > 
> > Message-ID: <23278.14324.913149.453...@rob.eddelbuettel.com>
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > Thanks, we try. Not too much infrastructure that we have built so these
> > transitions can be slow.  On my side, Debian has one schedules but not yet
> > started.
> 
> Dirk, all,
> 
> I can't say enough about my appreciation of the work you folks do in
> keeping R going so well on Debian.
> 
> In these interesting times, I think you're saying that things will resolve
> themselves at some point, but we're in a transition.  I see a number of
> postings on Ubuntu, but I'm on Debian Stretch, trying to figure out the
> safest way to go.  Does something like this make sense:
> 
> 
>1. aptitude safe-upgrade should be safe: there won't be any 3.5.0 Debian
>packages coming through until the environment is ready for them to come
>through (which most likely means that base R and other Stretch R packages
> are upgraded to 3.5.0?)..
>2. update.packages() inside R is /not/ safe, because it could pick up
>problematic packages from CRAN that aren't under your control.
>3. install.packages() inside R is /not/ safe, for the same reason.
>4. A prominent note will be posted here, when these two restrictions are
>removed.
> 
> Are those true statements?  Would steps 2 and 3 work if the packages don't
> require compiled C++ code?  If so, is there a way to tell which packages
> are at risk without memorizing what seems like a very long list?
> 
> If we (think we) need a new package we don't currently have installed, are
> we out of luck until 3.5.0 is officially released in Stretch?
> 
> Is there a place where an official summary of the state of the R system on
> Stretch is maintained?
> 
> I've tried to scan this list, but I may well have missed the answers to my
> questions about Stretch.
> 
> Thank you,
> 
> Bill
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
PD Dr. Johannes Ranke
Grenzach-Wyhlen

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

Re: [R-sig-Debian] R-SIG-Debian Digest, Vol 152, Issue 4

[Bill Harris]

>
> Date: Sat, 5 May 2018 18:02:12 -0500
> From: Dirk Eddelbuettel 
> To: Matthieu S 
> Cc: r-sig-debian@r-project.org
> Subject: Re: [R-sig-Debian] Ubuntu 18.04 bionic: availability of R
> Ubuntu packages/ppa?
> Message-ID: <23278.14324.913149.453...@rob.eddelbuettel.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Thanks, we try. Not too much infrastructure that we have built so these
> transitions can be slow.  On my side, Debian has one schedules but not yet
> started.


Dirk, all,

I can't say enough about my appreciation of the work you folks do in
keeping R going so well on Debian.

In these interesting times, I think you're saying that things will resolve
themselves at some point, but we're in a transition.  I see a number of
postings on Ubuntu, but I'm on Debian Stretch, trying to figure out the
safest way to go.  Does something like this make sense:


   1. aptitude safe-upgrade should be safe: there won't be any 3.5.0 Debian
   packages coming through until the environment is ready for them to come
   through (which most likely means that base R and other Stretch R packages
   are upgraded to 3.5.0?)..
   2. update.packages() inside R is /not/ safe, because it could pick up
   problematic packages from CRAN that aren't under your control.
   3. install.packages() inside R is /not/ safe, for the same reason.
   4. A prominent note will be posted here, when these two restrictions are
   removed.

Are those true statements?  Would steps 2 and 3 work if the packages don't
require compiled C++ code?  If so, is there a way to tell which packages
are at risk without memorizing what seems like a very long list?

If we (think we) need a new package we don't currently have installed, are
we out of luck until 3.5.0 is officially released in Stretch?

Is there a place where an official summary of the state of the R system on
Stretch is maintained?

I've tried to scan this list, but I may well have missed the answers to my
questions about Stretch.

Thank you,

Bill

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R on Ubuntu

[Dirk Eddelbuettel]

Dale,

Thanks for chiming in. Some very personal notes below:

On 6 May 2018 at 17:52, Dale Steele wrote:
| Hi Roman -
| 
| Based on advice form the list, here's what I did:
| 
| sudo apt purge r-cran-* r-base-*

I usually try my utmost not to.  Once packages are purge you cannot get them
back. I prefer to start an upgrade and back out if need be / if it would
remove package -- my go-to command is 'apt-get dist-upgrade' which allows that.
 
| sudo add-apt-repository ppa:marutter/rrutter3.5
| sudo apt-get update
| 
| sudo add-apt-repository ppa:marutter/c2d4u3.5
| sudo apt-get update

Yes though Michael has not yet announced these or declared them ready. 
 
| dpkg -l | grep r-cran-*
| 
| sudo apt-get install r-base r-base-dev
| 
| Added my account to the 'staff' group, so that I can install
| non-recommended packages in R without 'sudo R'
| http://www.maketecheasier.com/add-remove-user-to-groups-in-ubuntu/
| http://stackoverflow.com/questions/5560139/install-r-
| package-xml-in-debian-ubuntu
| 
| sudo usermod -a -G staff myusername
| logout and restart

Good point. And often forgotten.
| 
| Many packages are becoming available in the c2d4u3.5 repository. I've
| built/rebuild mostly from CRAN.
| However, to add pre-built binaries:
| 
| sudo apt-get install r-cran-packagename
| 
| Finally ... rebuild existing packages in '/usr/local/lib/R/site-library'
| > update.packages(checkBuilt= TRUE)

Yep.

| One issues, to update recommended packages in '/usr/lib/R/site-library,,
| must start R as sudoer, ie. 'sudo R'

Actually, no!  Those are the ones from r-cran-* packages, and I would leave
those alone.

More below ..

| Best.  --Dale
| 
| 
| On Sun, May 6, 2018 at 1:14 PM, Aguirre Perez, Roman 
| wrote:
| 
| > Hi everyone,
| >
| > first of all, my sincerest thanks for the maintainers of this massive
| > project. Such a compelling task!
| >
| > Briefly, I’m a PhD student working on Spatial Stats who loves R. Last week
| > I decided to install and use Ubuntu (again). Consequently, I install the
| > latest release (18.04) and tried to install R 3.5.0 as well but
| > (un)fortunately I couldn’t.
| >
| > I have used R within Ubuntu and I use to follow the installation procedure
| > suggested in the R-project website. However, this time was a bit different.
| > I realised I was missing a key fact. There’s plenty of work behind making
| > available R packages for Ubuntu! It briefly showed up in front of my eyes
| > the meaning of each installation step. That’s why I’m here. So I would
| > really appreciate you to enlighten me with your knowledge. I really want to
| > go in depth on the relationship R-Ubuntu. Btw, any resource for learning is
| > more than welcome.
| >
| > In this sense, which is the meaning of starting to install R by adding
| >
| > deb https://www.stats.bris.ac.uk/R/bin/linux/ubuntu bionic/<
| > https://www.stats.bris.ac.uk/R/bin/linux/ubuntu%20bionic/>
| >
| > in the source.list file?

That is a basic Ubuntu / Debian question. Try googling for some tutorials on
'how to I add repositories to Ubuntu' (or Debian).

| > I realised that I’m able to compile
| >
| > sudo apt-get install r-base
| >
| > without doing the first step. Which is the difference between each one?

That you get a pre-built binary (with more bells and whistles) and don't need
to compile.

That is called 'package managment' (at the Debian / Ubuntu level).  Again,
tty some tutorials there.  This is orthogonal to R use.

Dirk

| > Now that I’m more aware I know that it isn’t so straightforward to mirror
| > to CRAN and I have to hold my horses a bit more jeje. So should I install
| > previous of both R and Ubuntu? I mean, does it take a long time to have a
| > mirrored version?
| >
| >
| > Best,
| > Roman.
| >
| >
| > [[alternative HTML version deleted]]
| >
| > ___
| > R-SIG-Debian mailing list
| > R-SIG-Debian@r-project.org
| > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
| >
| 
|   [[alternative HTML version deleted]]
| 
| ___
| R-SIG-Debian mailing list
| R-SIG-Debian@r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R on Ubuntu

[Dale Steele]

Hi Roman -

Based on advice form the list, here's what I did:

sudo apt purge r-cran-* r-base-*

sudo add-apt-repository ppa:marutter/rrutter3.5
sudo apt-get update

sudo add-apt-repository ppa:marutter/c2d4u3.5
sudo apt-get update

dpkg -l | grep r-cran-*

sudo apt-get install r-base r-base-dev

Added my account to the 'staff' group, so that I can install
non-recommended packages in R without 'sudo R'
http://www.maketecheasier.com/add-remove-user-to-groups-in-ubuntu/
http://stackoverflow.com/questions/5560139/install-r-
package-xml-in-debian-ubuntu

sudo usermod -a -G staff myusername
logout and restart

Many packages are becoming available in the c2d4u3.5 repository. I've
built/rebuild mostly from CRAN.
However, to add pre-built binaries:

sudo apt-get install r-cran-packagename

Finally ... rebuild existing packages in '/usr/local/lib/R/site-library'
> update.packages(checkBuilt= TRUE)

One issues, to update recommended packages in '/usr/lib/R/site-library,,
must start R as sudoer, ie. 'sudo R'


Best.  --Dale


On Sun, May 6, 2018 at 1:14 PM, Aguirre Perez, Roman 
wrote:

> Hi everyone,
>
> first of all, my sincerest thanks for the maintainers of this massive
> project. Such a compelling task!
>
> Briefly, I’m a PhD student working on Spatial Stats who loves R. Last week
> I decided to install and use Ubuntu (again). Consequently, I install the
> latest release (18.04) and tried to install R 3.5.0 as well but
> (un)fortunately I couldn’t.
>
> I have used R within Ubuntu and I use to follow the installation procedure
> suggested in the R-project website. However, this time was a bit different.
> I realised I was missing a key fact. There’s plenty of work behind making
> available R packages for Ubuntu! It briefly showed up in front of my eyes
> the meaning of each installation step. That’s why I’m here. So I would
> really appreciate you to enlighten me with your knowledge. I really want to
> go in depth on the relationship R-Ubuntu. Btw, any resource for learning is
> more than welcome.
>
> In this sense, which is the meaning of starting to install R by adding
>
> deb https://www.stats.bris.ac.uk/R/bin/linux/ubuntu bionic/<
> https://www.stats.bris.ac.uk/R/bin/linux/ubuntu%20bionic/>
>
> in the source.list file?
>
> I realised that I’m able to compile
>
> sudo apt-get install r-base
>
> without doing the first step. Which is the difference between each one?
>
> Now that I’m more aware I know that it isn’t so straightforward to mirror
> to CRAN and I have to hold my horses a bit more jeje. So should I install
> previous of both R and Ubuntu? I mean, does it take a long time to have a
> mirrored version?
>
>
> Best,
> Roman.
>
>
> [[alternative HTML version deleted]]
>
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R 3.5.0 binaries for Debian and Ubuntu

[Johannes Ranke]

Hi,

> - For Debian, I started a similar 'minimal' R 3.5.0 repo here
> https://github.com/eddelbuettel/drr35
>   which allowed me eg to update the 'base' Rocker image for R 3.5.0
> https://github.com/rocker-org/rocker/blob/master/r-base/Dockerfile
> https://hub.docker.com/r/rocker/r-base/
>   and I will send the usual PR to the offical library for the r-base image
>   mirroring this.

I would like to add that R 3.5.0 is available for Debian stable and oldstable 
in repositories stretch-cran35/ and jessie-cran35/ on CRAN:

https://cran.r-project.org/bin/linux/debian/

Johannes

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

Re: [R-sig-Debian] R 3.5.0 Binaries for Ubuntu now available

[Jeroen Ooms]

On Sun, Apr 29, 2018 at 3:49 PM, Dirk Eddelbuettel  wrote:
>
> On 29 April 2018 at 15:30, Jeroen Ooms wrote:
> | On Sat, Apr 28, 2018 at 10:00 PM, Michael Rutter  wrote:
> | > These have not been mirrored to CRAN as I want to have the other r-cran
> | > packages built against R 3.5 before adding to CRAN.  Worried about 
> breaking
> | > working systems currently on R 3.4.4.
> |
> | Thanks, Michael. I did some simple tests, upgrading existing r-base
> | installations to R 3.5. on Xenial and Bionic, and initially apt did
> | the correct thing of removing the incompatible r-cran-xyz packages.
> |
> | However then I tried installing the (knowingly incompatible)
> | r-cran-rcpp from c2d4u and apt didn't stop me. Do the r-cran-xyz
> | packages from c2d4u not have the same r-api-nn dependency
> | restrictions?
>
> Does it have a r-api-3.4 tag like the official packages?  Michael and I may
> at some have made an executive decision to _not_ impose those on c2d4u 
> packages.
> So blame us.

OK, understand this is a complex operation, but still unfortunate. The
mixing of c2d4u packages with r-base 3.5 will inevitably happen when
people upgrade their systems to R 3.5.

If there would be a way to start adding the appropriate r-api-nn tag
in c2d4u based on which version of R it was built with, that would
probably be an enormous improvement. Not sure if this is something
that can easily be automated.

Thanks for your efforts on this!

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

Re: [R-sig-Debian] R 3.5.0 Binaries for Ubuntu now available

[Michael Rutter]

On 04/29/2018 09:30 AM, Jeroen Ooms wrote:

On Sat, Apr 28, 2018 at 10:00 PM, Michael Rutter  wrote:

These have not been mirrored to CRAN as I want to have the other r-cran
packages built against R 3.5 before adding to CRAN.  Worried about breaking
working systems currently on R 3.4.4.


Thanks, Michael. I did some simple tests, upgrading existing r-base
installations to R 3.5. on Xenial and Bionic, and initially apt did
the correct thing of removing the incompatible r-cran-xyz packages.

However then I tried installing the (knowingly incompatible)
r-cran-rcpp from c2d4u and apt didn't stop me. Do the r-cran-xyz
packages from c2d4u not have the same r-api-nn dependency
restrictions?


Since c2d4u is (for the most part) automatic, it only grabs depends from 
the CRAN web page.  Therefore, there is no r-api-nn dependency for 
packages built from c2d4u source packages.  How that effects things is 
unclear.  As Dirk just posted, it was an executive decision that we made 
(or possibly ignored).


However, sometimes I need to borrow a package from Debian (when someone 
else has built it on Launchpad before I did), and those will have the 
r-api-nn dependency.  There are also the universe packages.


From my end, this is a mess.  Rebuilding the universe packages for 3.5 
is a slow process (crazy dependencies).  Plan is to build everything 
against 3.5, but it will take some time.


Michael

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

Re: [R-sig-Debian] R 3.5.0 Binaries for Ubuntu now available

[Dirk Eddelbuettel]

On 29 April 2018 at 15:30, Jeroen Ooms wrote:
| On Sat, Apr 28, 2018 at 10:00 PM, Michael Rutter  wrote:
| > These have not been mirrored to CRAN as I want to have the other r-cran
| > packages built against R 3.5 before adding to CRAN.  Worried about breaking
| > working systems currently on R 3.4.4.
| 
| Thanks, Michael. I did some simple tests, upgrading existing r-base
| installations to R 3.5. on Xenial and Bionic, and initially apt did
| the correct thing of removing the incompatible r-cran-xyz packages.
| 
| However then I tried installing the (knowingly incompatible)
| r-cran-rcpp from c2d4u and apt didn't stop me. Do the r-cran-xyz
| packages from c2d4u not have the same r-api-nn dependency
| restrictions?

Does it have a r-api-3.4 tag like the official packages?  Michael and I may
at some have made an executive decision to _not_ impose those on c2d4u packages.
So blame us.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.5.0 Binaries for Ubuntu now available

[Jeroen Ooms]

On Sat, Apr 28, 2018 at 10:00 PM, Michael Rutter  wrote:
> These have not been mirrored to CRAN as I want to have the other r-cran
> packages built against R 3.5 before adding to CRAN.  Worried about breaking
> working systems currently on R 3.4.4.

Thanks, Michael. I did some simple tests, upgrading existing r-base
installations to R 3.5. on Xenial and Bionic, and initially apt did
the correct thing of removing the incompatible r-cran-xyz packages.

However then I tried installing the (knowingly incompatible)
r-cran-rcpp from c2d4u and apt didn't stop me. Do the r-cran-xyz
packages from c2d4u not have the same r-api-nn dependency
restrictions?

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

Re: [R-sig-Debian] r-cran-rjava dependencies on debian jesse, library(rJava) fails when default-jre is missing

[Vaidotas Zemlys]

Hi,

> Le 17 mai 2017 à 13:54, Dirk Eddelbuettel  a écrit :
> 
> 
> On 17 May 2017 at 08:46, Vaidotas Zemlys wrote:
> | Hi,
> | 
> | > Le 17 mai 2017 à 00:42, Dirk Eddelbuettel  a écrit :
> | > 
> | > 
> | > On 8 May 2017 at 15:39, Vaidotas Zemlys wrote:
> | > | Hi,
> | > | 
> | > | Dirk Eddelbuettel advised me to write here. Here is my original letter 
> to him:
> | > | 
> | > | I would like to enquire about package r-cran-rjava on Debian jesse. It 
> seems that if default-jre package is not installed, but openjdk-7-jre is 
> installed, then library(rJava) in R fails. I’ve been bitten by this today and 
> I wonder whether this an issue of mine, or is this a possible bug. 
> | > | 
> | > | My server admin used apt-get update and apt-get upgrade today and R 
> started throwing an error that it cannot find libjvm.so, when trying to do 
> library(rJava). At first I thought that this is a problem of setting 
> JAVA_HOME, and setting it to JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 
> before starting R seemed to solve the problem. But this setting was ignored 
> by shiny-server, so I spent some time figuring out how to force shiny-server 
> to respect it. Only after repeated failure I’ve noticed that LD_LIBRARY_PATH 
> in Sys.getenv() points to /usr/lib/jvm/default-java/jre/lib/amd64/server and 
> there was no directory /usr/lib/jvm/default-java/ in the system. Then I found 
> out that this library is provided by default-jre and when it was installed 
> everything start to work. Then I investigated further and found that this 
> package is only optional for r-cran-rjava. Hence the question.
> | > | 
> | > | 
> | > | Here is my configuration:
> | > | 
> | > | > lsb_release -a
> | > | No LSB modules are available.
> | > | Distributor ID: Debian
> | > | Description:Debian GNU/Linux 8.8 (jessie)
> | > | Release:8.8
> | > | Codename:   jessie
> | > | 
> | > | 
> | > | dpkg -l with relevant packages:
> | > | 
> | > | Desired=Unknown/Install/Remove/Purge/Hold
> | > | | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> | > | |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> | > | ||/ Name  Version   
> Architecture  Description
> | > | 
> +++-=-=-=-
> | > | ii  r-cran-rjava  0.9-6-3   amd64   
>   GNU R low-level interface to Java
> | > | ii  r-base3.3.3-1~jessiecran.0  all 
>   GNU R statistical computation and graphics system
> | > | ii  openjdk-7-jre:amd647u121-2.6.8-2~deb8u1 
>   amd64OpenJDK Java runtime, using Hotspot JIT
> | > | ii  openjdk-7-jre-headless:amd64   7u121-2.6.8-2~deb8u1 
>   amd64OpenJDK Java runtime, using Hotspot JIT (headless)
> | > | 
> | > | Sorry for bothering if this is an issue from my side. 
> | > 
> | > You have the ‘jre', you need the 'jdk'.
> | > 
> | 
> | But the r-cran-rjava Depends: do not mention that. Of course having 
> packages openjdk-7-jre and openjdk-7-jdk is not at all confusing, but that is 
> Java.
> 
> I hear you but the 'jdk' is the build-depends, and needed when you want to
> build other packages. The 'jre' is the smaller minimal set needed to only run
> code. At least that was the idea, and at some point it worked.  Maybe I need
> to enlarge the Depends to use the jdk.
> 
 
I think there is some misunderstanding. I was not able to run any R package 
which depended on rJava, which in binary form was provided by r-cran-rjava. The 
issue was that after the update the already installed R packages which were 
depending on rJava were not able to load. So build-depend would not have helped 
me, because I was not building any packages. Everything started to work after 
install of default-jre. Since I did not try to reproduce the bug on a clean 
install, there is a chance that my problem was self-inflicted, i.e. my admin 
did something not entirely advisable. I think we can close this issue. I’ve 
reported the issue, solicited the reaction and reaffirmed “java is tricky” 
idiom, so everything is cool from my side.


Vaidotas Zemlys-Balevičius

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

Re: [R-sig-Debian] r-cran-rjava dependencies on debian jesse, library(rJava) fails when default-jre is missing

[Dirk Eddelbuettel]

On 17 May 2017 at 08:46, Vaidotas Zemlys wrote:
| Hi,
| 
| > Le 17 mai 2017 à 00:42, Dirk Eddelbuettel  a écrit :
| > 
| > 
| > On 8 May 2017 at 15:39, Vaidotas Zemlys wrote:
| > | Hi,
| > | 
| > | Dirk Eddelbuettel advised me to write here. Here is my original letter to 
him:
| > | 
| > | I would like to enquire about package r-cran-rjava on Debian jesse. It 
seems that if default-jre package is not installed, but openjdk-7-jre is 
installed, then library(rJava) in R fails. I’ve been bitten by this today and I 
wonder whether this an issue of mine, or is this a possible bug. 
| > | 
| > | My server admin used apt-get update and apt-get upgrade today and R 
started throwing an error that it cannot find libjvm.so, when trying to do 
library(rJava). At first I thought that this is a problem of setting JAVA_HOME, 
and setting it to JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 before starting R 
seemed to solve the problem. But this setting was ignored by shiny-server, so I 
spent some time figuring out how to force shiny-server to respect it. Only 
after repeated failure I’ve noticed that LD_LIBRARY_PATH in Sys.getenv() points 
to /usr/lib/jvm/default-java/jre/lib/amd64/server and there was no directory 
/usr/lib/jvm/default-java/ in the system. Then I found out that this library is 
provided by default-jre and when it was installed everything start to work. 
Then I investigated further and found that this package is only optional for 
r-cran-rjava. Hence the question.
| > | 
| > | 
| > | Here is my configuration:
| > | 
| > | > lsb_release -a
| > | No LSB modules are available.
| > | Distributor ID:   Debian
| > | Description:  Debian GNU/Linux 8.8 (jessie)
| > | Release:  8.8
| > | Codename: jessie
| > | 
| > | 
| > | dpkg -l with relevant packages:
| > | 
| > | Desired=Unknown/Install/Remove/Purge/Hold
| > | | 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
| > | |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
| > | ||/ Name  Version   Architecture  
Description
| > | 
+++-=-=-=-
| > | ii  r-cran-rjava  0.9-6-3   amd64 
GNU R low-level interface to Java
| > | ii  r-base3.3.3-1~jessiecran.0  all   
GNU R statistical computation and graphics system
| > | ii  openjdk-7-jre:amd647u121-2.6.8-2~deb8u1   
amd64OpenJDK Java runtime, using Hotspot JIT
| > | ii  openjdk-7-jre-headless:amd64   7u121-2.6.8-2~deb8u1   
amd64OpenJDK Java runtime, using Hotspot JIT (headless)
| > | 
| > | Sorry for bothering if this is an issue from my side. 
| > 
| > You have the ‘jre', you need the 'jdk'.
| > 
| 
| But the r-cran-rjava Depends: do not mention that. Of course having packages 
openjdk-7-jre and openjdk-7-jdk is not at all confusing, but that is Java.

I hear you but the 'jdk' is the build-depends, and needed when you want to
build other packages. The 'jre' is the smaller minimal set needed to only run
code. At least that was the idea, and at some point it worked.  Maybe I need
to enlarge the Depends to use the jdk.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] r-cran-rjava dependencies on debian jesse, library(rJava) fails when default-jre is missing

[Vaidotas Zemlys]

Hi,

> Le 17 mai 2017 à 00:42, Dirk Eddelbuettel  a écrit :
> 
> 
> On 8 May 2017 at 15:39, Vaidotas Zemlys wrote:
> | Hi,
> | 
> | Dirk Eddelbuettel advised me to write here. Here is my original letter to 
> him:
> | 
> | I would like to enquire about package r-cran-rjava on Debian jesse. It 
> seems that if default-jre package is not installed, but openjdk-7-jre is 
> installed, then library(rJava) in R fails. I’ve been bitten by this today and 
> I wonder whether this an issue of mine, or is this a possible bug. 
> | 
> | My server admin used apt-get update and apt-get upgrade today and R started 
> throwing an error that it cannot find libjvm.so, when trying to do 
> library(rJava). At first I thought that this is a problem of setting 
> JAVA_HOME, and setting it to JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 
> before starting R seemed to solve the problem. But this setting was ignored 
> by shiny-server, so I spent some time figuring out how to force shiny-server 
> to respect it. Only after repeated failure I’ve noticed that LD_LIBRARY_PATH 
> in Sys.getenv() points to /usr/lib/jvm/default-java/jre/lib/amd64/server and 
> there was no directory /usr/lib/jvm/default-java/ in the system. Then I found 
> out that this library is provided by default-jre and when it was installed 
> everything start to work. Then I investigated further and found that this 
> package is only optional for r-cran-rjava. Hence the question.
> | 
> | 
> | Here is my configuration:
> | 
> | > lsb_release -a
> | No LSB modules are available.
> | Distributor ID: Debian
> | Description:Debian GNU/Linux 8.8 (jessie)
> | Release:8.8
> | Codename:   jessie
> | 
> | 
> | dpkg -l with relevant packages:
> | 
> | Desired=Unknown/Install/Remove/Purge/Hold
> | | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> | |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> | ||/ Name  Version   Architecture
>   Description
> | 
> +++-=-=-=-
> | ii  r-cran-rjava  0.9-6-3   amd64   
>   GNU R low-level interface to Java
> | ii  r-base3.3.3-1~jessiecran.0  all 
>   GNU R statistical computation and graphics system
> | ii  openjdk-7-jre:amd647u121-2.6.8-2~deb8u1   
> amd64OpenJDK Java runtime, using Hotspot JIT
> | ii  openjdk-7-jre-headless:amd64   7u121-2.6.8-2~deb8u1   
> amd64OpenJDK Java runtime, using Hotspot JIT (headless)
> | 
> | Sorry for bothering if this is an issue from my side. 
> 
> You have the ‘jre', you need the 'jdk'.
> 

But the r-cran-rjava Depends: do not mention that. Of course having packages 
openjdk-7-jre and openjdk-7-jdk is not at all confusing, but that is Java.

Vaidotas Zemlys-Balevičius

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

Re: [R-sig-Debian] r-cran-rjava dependencies on debian jesse, library(rJava) fails when default-jre is missing

[Dirk Eddelbuettel]

On 8 May 2017 at 15:39, Vaidotas Zemlys wrote:
| Hi,
| 
| Dirk Eddelbuettel advised me to write here. Here is my original letter to him:
| 
| I would like to enquire about package r-cran-rjava on Debian jesse. It seems 
that if default-jre package is not installed, but openjdk-7-jre is installed, 
then library(rJava) in R fails. I’ve been bitten by this today and I wonder 
whether this an issue of mine, or is this a possible bug. 
| 
| My server admin used apt-get update and apt-get upgrade today and R started 
throwing an error that it cannot find libjvm.so, when trying to do 
library(rJava). At first I thought that this is a problem of setting JAVA_HOME, 
and setting it to JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 before starting R 
seemed to solve the problem. But this setting was ignored by shiny-server, so I 
spent some time figuring out how to force shiny-server to respect it. Only 
after repeated failure I’ve noticed that LD_LIBRARY_PATH in Sys.getenv() points 
to /usr/lib/jvm/default-java/jre/lib/amd64/server and there was no directory 
/usr/lib/jvm/default-java/ in the system. Then I found out that this library is 
provided by default-jre and when it was installed everything start to work. 
Then I investigated further and found that this package is only optional for 
r-cran-rjava. Hence the question.
| 
| 
| Here is my configuration:
| 
| > lsb_release -a
| No LSB modules are available.
| Distributor ID:   Debian
| Description:  Debian GNU/Linux 8.8 (jessie)
| Release:  8.8
| Codename: jessie
| 
| 
| dpkg -l with relevant packages:
| 
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
| |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
| ||/ Name  Version   Architecture  
Description
| 
+++-=-=-=-
| ii  r-cran-rjava  0.9-6-3   amd64 
GNU R low-level interface to Java
| ii  r-base3.3.3-1~jessiecran.0  all   
GNU R statistical computation and graphics system
| ii  openjdk-7-jre:amd647u121-2.6.8-2~deb8u1   
amd64OpenJDK Java runtime, using Hotspot JIT
| ii  openjdk-7-jre-headless:amd64   7u121-2.6.8-2~deb8u1   
amd64OpenJDK Java runtime, using Hotspot JIT (headless)
| 
| Sorry for bothering if this is an issue from my side. 

You have the 'jre', you need the 'jdk'.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] r-cran-rjava dependencies on debian jesse, library(rJava) fails when default-jre is missing

[Dirk Eddelbuettel]

On 8 May 2017 at 15:39, Vaidotas Zemlys wrote:
| Hi,
| 
| Dirk Eddelbuettel advised me to write here. Here is my original letter to him:
| 
| I would like to enquire about package r-cran-rjava on Debian jesse. It seems 
that if default-jre package is not installed, but openjdk-7-jre is installed, 
then library(rJava) in R fails. I’ve been bitten by this today and I wonder 
whether this an issue of mine, or is this a possible bug. 
| 
| My server admin used apt-get update and apt-get upgrade today and R started 
throwing an error that it cannot find libjvm.so, when trying to do 
library(rJava). At first I thought that this is a problem of setting JAVA_HOME, 
and setting it to JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64 before starting R 
seemed to solve the problem. But this setting was ignored by shiny-server, so I 
spent some time figuring out how to force shiny-server to respect it. Only 
after repeated failure I’ve noticed that LD_LIBRARY_PATH in Sys.getenv() points 
to /usr/lib/jvm/default-java/jre/lib/amd64/server and there was no directory 
/usr/lib/jvm/default-java/ in the system. Then I found out that this library is 
provided by default-jre and when it was installed everything start to work. 
Then I investigated further and found that this package is only optional for 
r-cran-rjava. Hence the question.
| 
| 
| Here is my configuration:
| 
| > lsb_release -a
| No LSB modules are available.
| Distributor ID:   Debian
| Description:  Debian GNU/Linux 8.8 (jessie)
| Release:  8.8
| Codename: jessie
| 
| 
| dpkg -l with relevant packages:
| 
| Desired=Unknown/Install/Remove/Purge/Hold
| | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
| |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
| ||/ Name  Version   Architecture  
Description
| 
+++-=-=-=-
| ii  r-cran-rjava  0.9-6-3   amd64 
GNU R low-level interface to Java
| ii  r-base3.3.3-1~jessiecran.0  all   
GNU R statistical computation and graphics system
| ii  openjdk-7-jre:amd647u121-2.6.8-2~deb8u1   
amd64OpenJDK Java runtime, using Hotspot JIT
| ii  openjdk-7-jre-headless:amd64   7u121-2.6.8-2~deb8u1   
amd64OpenJDK Java runtime, using Hotspot JIT (headless)
| 
| Sorry for bothering if this is an issue from my side. 

You have the 'jre', you may need the 'jdk' for the compiler.

I think the Depends: we have is good enough for running Java based R
packages. At least it used to be...

Dirk


| 
| Vaidotas Zemlys-Balevičius
| ___
| R-SIG-Debian mailing list
| R-SIG-Debian@r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian
-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R 3.4.0 for Ubuntu zesty?

[Michael Rutter]

On 05/03/2017 04:40 AM, Thierry Onkelinx wrote:

Dear all,

I only seems to get the yakkety version for R 3.4.0. Am I missing something?



Slight configuration error.  Thanks for pointing it out.  I have fixed 
the issue and it should be corrected the next time the CRAN mirrors are 
synced.  You can also get packages at my R PPA:


https://launchpad.net/~marutter/+archive/ubuntu/rrutter

Thanks,
Michael



Best regards,

ir. Thierry Onkelinx
Instituut voor natuur- en bosonderzoek / Research Institute for Nature and
Forest
team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance
Kliniekstraat 25
1070 Anderlecht
Belgium

To call in the statistician after the experiment is done may be no more
than asking him to perform a post-mortem examination: he may be able to say
what the experiment died of. ~ Sir Ronald Aylmer Fisher
The plural of anecdote is not data. ~ Roger Brinner
The combination of some data and an aching desire for an answer does not
ensure that a reasonable answer can be extracted from a given body of data.
~ John Tukey

[[alternative HTML version deleted]]

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



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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Dirk Eddelbuettel]

On 27 April 2017 at 13:16, Dirk Eddelbuettel wrote:
| On 27 April 2017 at 23:41, Charles Plessy wrote:
| | Within the Debian infrastructure, the architecture-dependant packages can be
| | easily rebuilt by binNMUs.  The architecture-independant packages are 
easier to

Actually one saving grace is that binary:all packages don't need the rebuild
as they (being R only) won't have .C() or .Fortran().

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R installation problems on Linux Mint 18.1 via jessie-cran3

[Clive Nicholas]

Thank you so much Johannes.

Problem now sorted:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E084DAB9
sudo add-apt-repository deb https://cran.ma.imperial.ac.uk/bin/linux/ubuntu
xenial/ # replaced the old repository link
sudo apt-get update
sudo apt-get install r-base r-base-core r-base-dev

With my .Renviron file already fixed from previously with the correct paths
inserted, my R 3.4.0 is now up and running with LaTeX run successfully.
I've also taken care to delete your Debian R key from my machine, retaining
the Ubuntu one.

I rather think it would be a good idea to publicise this solution for Linux
Mint 18.1 users *as widely as possible* so that they don't run into the
same unnecessary difficulties I just did: it would not be immediately
obvious to all such users (it wasn't to me) that they should instead be
downloading and installing from the Ubuntu and not the Debian repository.
(Indeed, I had used the Debian repository successfully on my previous
install of Linux Mint.) *It certainly shouldn't be buried in a thread on a
mailing list!*

May I also extend my grateful thanks to Professor J C Nash for his help.

Yours with thanks,
Clive Nicholas

On 27 April 2017 at 23:20, Johannes Ranke  wrote:

> Am Donnerstag, 27. April 2017, 15:05:32 schrieb J C Nash:
> > Is there a reason for jessie-cran3 rather than xenial? For Linux Mint 18
> > (admittedly not 18.1) I have
> >
> > deb https://cloud.r-project.org/bin/linux/ubuntu xenial/
> >
> > as one of the apt entries.
> >
> > JN
>
> Seconded. You should not expect that mixing apt entries for Ubuntu and
> Debian
> will work.
>
> > > It didn't work and I simply get the same SHA1 weak algorithm error when
> > > running -sudo apt-get update- or -sudo apt update-.
>
> jessie-cran3 is made for Debian jessie which uses a somewhat dated version
> of
> apt, which does not complain about weak SHA1 checksums.
>
> > > (Why is this issue not
> > > mentioned at all here  and why have users
> > > like
> > > me had to go ferreting for it, amongst other things?)
>
> Because Michael Rutter (for the Ubuntu backports) and myself (for the
> Debian
> backports) try our best to make things just work for the distributions for
> which these backports are advertised. The user should generally not have to
> worry about the checksum algorithms used by his distribution.
>
> Mint 18.1 is based on Ubuntu 16.04 AKA Xenial Xerus. So it seems to me you
> should use an apt entry (and only *one* for the CRAN R packages) for
> xenial as
> John recommended.
>
> Kind regards, I sort of feel with you, as I sometimes also get frustrated.
> But
> usually the satisfaction to work with free software prevails!
>
> Cheers,
>
> Johannes
>
> > >
> > > I've been a Linux user for six years and pride myself on researching as
> > > many possible forums when trying to fix stuff before asking for any
> help,
> > > have never had to confront this nonsense and I'm really fed up with
> this
> > > now; I very strongly object to what have been hitherto (reasonably)
> > > straightforward R download and installation procedures making a total
> > > idiot
> > > of me when I try my damnednest to follow all the steps to do it all
> > > correctly in much the same way as I have done before without too many
> > > issues.
> > >
> > > Please advise at your very earliest convenience and help me sort this
> out.
> > > Thank you.
> >
> > ___
> > R-SIG-Debian mailing list
> > R-SIG-Debian@r-project.org
> > https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>



-- 
Clive Nicholas

"My colleagues in the social sciences talk a great deal about methodology.
I prefer to call it style." -- Freeman J. Dyson

[[alternative HTML version deleted]]

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Charles Plessy]

Le Thu, Apr 27, 2017 at 01:16:11PM -0500, Dirk Eddelbuettel a écrit :
 
> Could you fill me in about what broke with BioC and what caused it?

As far as I understand, something changed with the c() generic, which broke
packages providing a S4 method for it.  The breakage and the solution were
reported on .

There was somewhere a better explanation on why it happens, but I could not
find it anymore.  In brief, it has to do with the fact that upon installation,
some S4 functions capture part of their environment, and the c() declarations
in R 3.3.2 are not compatible with the c() function (or method, etc., sorry for
the imprecise vocabulary) in R 3.3.3, and therefore packages need to be
reinstalled.  And since our Debian packages (and R Win/Mac pacakges) are
essentially a copy of installed packages, we need to rebuild the affected ones.

Thus, while BioC was more affected since it heavily uses S4, I would expect
that some CRAN packages were broken as well.  Continuous integration of Debian's
packages did not pinpoint problems in the r-cran-* namespace, but as exemplified
by r-bioc-xvector, some regression tests have only partial coverage.

> I am not sure I understand why people would want to do partial upgrades.
> Debian stable is support. Debian testing is supported.  Hybrid mixes of the
> two are risque.

I do agree and would not recommend mixes, especially since the CRAN and Debian
backports are available.  But Debian officially supports partial upgrades, in
the sense that if the dependency graph allows for it, then it should work.  In
that sense, preventing partial upgrades through the use of r-api-4 would be
an acceptable solution.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

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

Re: [R-sig-Debian] R installation problems on Linux Mint 18.1 via jessie-cran3

[Johannes Ranke]

Am Donnerstag, 27. April 2017, 15:05:32 schrieb J C Nash:
> Is there a reason for jessie-cran3 rather than xenial? For Linux Mint 18
> (admittedly not 18.1) I have
> 
> deb https://cloud.r-project.org/bin/linux/ubuntu xenial/
> 
> as one of the apt entries.
> 
> JN

Seconded. You should not expect that mixing apt entries for Ubuntu and Debian 
will work.

> > It didn't work and I simply get the same SHA1 weak algorithm error when
> > running -sudo apt-get update- or -sudo apt update-. 

jessie-cran3 is made for Debian jessie which uses a somewhat dated version of 
apt, which does not complain about weak SHA1 checksums.

> > (Why is this issue not
> > mentioned at all here  and why have users
> > like
> > me had to go ferreting for it, amongst other things?)

Because Michael Rutter (for the Ubuntu backports) and myself (for the Debian 
backports) try our best to make things just work for the distributions for 
which these backports are advertised. The user should generally not have to 
worry about the checksum algorithms used by his distribution.

Mint 18.1 is based on Ubuntu 16.04 AKA Xenial Xerus. So it seems to me you 
should use an apt entry (and only *one* for the CRAN R packages) for xenial as 
John recommended.

Kind regards, I sort of feel with you, as I sometimes also get frustrated. But 
usually the satisfaction to work with free software prevails!

Cheers,

Johannes

> > 
> > I've been a Linux user for six years and pride myself on researching as
> > many possible forums when trying to fix stuff before asking for any help,
> > have never had to confront this nonsense and I'm really fed up with this
> > now; I very strongly object to what have been hitherto (reasonably)
> > straightforward R download and installation procedures making a total
> > idiot
> > of me when I try my damnednest to follow all the steps to do it all
> > correctly in much the same way as I have done before without too many
> > issues.
> > 
> > Please advise at your very earliest convenience and help me sort this out.
> > Thank you.
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian

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

Re: [R-sig-Debian] R installation problems on Linux Mint 18.1 via jessie-cran3

[J C Nash]

Is there a reason for jessie-cran3 rather than xenial? For Linux Mint 18 
(admittedly
not 18.1) I have

deb https://cloud.r-project.org/bin/linux/ubuntu xenial/

as one of the apt entries.

JN

On 2017-04-27 02:57 PM, Clive Nicholas wrote:

Okay folks, I give up and - frankly - I'm fed up! I thought I'd sorted all
this last week, but clearly not. I've tried using mirrors from here in the
UK, Ireland, France and the USA and whichever mirror I use, all I get is
this:

clive@climate ~ $ sudo apt-get update
Hit:1 http://ubuntu.mirrors.uk2.net/ubuntu xenial InRelease
Ign:2 http://dl.google.com/linux/chrome/deb stable InRelease

Ign:3 http://www.mirrorservice.org/sites/packages.linuxmint.com/packages
serena InRelease
Ign:4 http://cran.ma.imperial.ac.uk/bin/linux/debian jessie-cran3/
InRelease
Hit:5 http://ubuntu.mirrors.uk2.net/ubuntu xenial-updates InRelease

Hit:6 http://archive.canonical.com/ubuntu xenial InRelease

Hit:7 http://dl.google.com/linux/chrome/deb stable Release

Hit:8 http://www.mirrorservice.org/sites/packages.linuxmint.com/packages
serena Release
Hit:9 http://ubuntu.mirrors.uk2.net/ubuntu xenial-backports InRelease

Hit:10 http://cran.ma.imperial.ac.uk/bin/linux/debian jessie-cran3/ Release

Get:11 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Hit:14 https://repo.skype.com/deb stable InRelease
Fetched 102 kB in 2s (37.7 kB/s)
Reading package lists... Done
W: http://cran.ma.imperial.ac.uk/bin/linux/debian/jessie-cran3/Release.gpg:
Signature by key 6212B7B7931C4BB16280BA1306F90DE5381BA480 uses weak digest
algorithm (SHA1)

To fix this SHA1 problem, I followed this page
 *to the letter* and
implemented this in a file on my Linux machine called ~/.gnupg/gpg.conf
(apologies for the length, but included for completeness; the key detail is
contained right at the bottom):

*# Options for GnuPG*
*# Copyright 1998, 1999, 2000, 2001, 2002, 2003,*
*#   2010 Free Software Foundation, Inc.*
*# *
*# This file is free software; as a special exception the author gives*
*# unlimited permission to copy and/or distribute it, with or without*
*# modifications, as long as this notice is preserved.*
*# *
*# This file is distributed in the hope that it will be useful, but*
*# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the*
*# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.*
*#*
*# Unless you specify which option file to use (with the command line*
*# option "--options filename"), GnuPG uses the file ~/.gnupg/gpg.conf*
*# by default.*
*#*
*# An options file can contain any long options which are available in*
*# GnuPG. If the first non white space character of a line is a '#',*
*# this line is ignored.  Empty lines are also ignored.*
*#*
*# See the man page for a list of options.*

*# Uncomment the following option to get rid of the copyright notice*

*#no-greeting*

*# If you have more than 1 secret key in your keyring, you may want to*
*# uncomment the following option and set your preferred keyid.*

*#default-key 621CC013*

*# If you do not pass a recipient to gpg, it will ask for one.  Using*
*# this option you can encrypt to a default key.  Key validation will*
*# not be done in this case.  The second form uses the default key as*
*# default recipient.*

*#default-recipient some-user-id*
*#default-recipient-self*

*# Use --encrypt-to to add the specified key as a recipient to all*
*# messages.  This is useful, for example, when sending mail through a*
*# mail client that does not automatically encrypt mail to your key.*
*# In the example, this option allows you to read your local copy of*
*# encrypted mail that you've sent to others.*

*#encrypt-to some-key-id*

*# By default GnuPG creates version 4 signatures for data files as*
*# specified by OpenPGP.  Some earlier (PGP 6, PGP 7) versions of PGP*
*# require the older version 3 signatures.  Setting this option forces*
*# GnuPG to create version 3 signatures.*

*#force-v3-sigs*

*# Because some mailers change lines starting with "From " to ">From "*
*# it is good to handle such lines in a special way when creating*
*# cleartext signatures; all other PGP versions do it this way too.*

*#no-escape-from-lines*

*# If you do not use the Latin-1 (ISO-8859-1) charset, you should tell*
*# GnuPG which is the native character set.  Please check the man page*
*# for supported character sets.  This character set is only used for*
*# metadata and not for the actual message which does not undergo any*
*# translation.  Note that future version of GnuPG will change to UTF-8*
*# as default character set.  In most cases this option is not required*
*# as GnuPG is able to figure out the correct charset at runtime.*

*#charset utf-8*

*# Group names may be defined like this:*
*#   group mynames = paige 0x12345678 joe patti*
*#*
*# Any time "mynames" is a recipient (-r or --recipient), it will be*
*# expanded to the names "paige", "joe", and "patti", and the 

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Dirk Eddelbuettel]

On 27 April 2017 at 23:41, Charles Plessy wrote:
| Le Thu, Apr 27, 2017 at 07:24:18AM -0500, Dirk Eddelbuettel a écrit :
| > 
| > On 27 April 2017 at 13:58, Johannes Ranke wrote:
| > | Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel:
| > | > On 27 April 2017 at 12:01, Johannes Ranke wrote:
| > | 
| > | > This may be a use case for r-api-4. Or not as it doesn't break _all_
| > | > packages so I am not sure we should force _all_ packages to be rebuilt.
| > | > 
| > | > Can we not find the ones that use .C and .Fortran ?
| > | 
| > | I do not understand how the use of r-api-x works, but my feeling is that 
it 
| > | will not allow to differentiate between packages using .C and .Fortan and 
the 
| > | rest.
| > 
| > Right. And therefore cast too wide a net. 
| > 
| > | I am surprised that I did not see a related bug report in the Debian BTS 
yet, 
| > | did I overlook something? I only looked for r-base.
| > 
| > They may not know yet. I should write to debian-devel.
| > 
| > Any debian-med or debian-science readers here?
| 
| Yes I am here :)

:)

| I spotted the breakage caused by R 3.4.0 when seeing regression tests
| failing on ci.debian.net.  But I did not report them yet as I am still
| busy with the breakage caused by R 3.3.3 (mostly on Bioconductor packages).
| In the case of R 3.3.3 it was a bit tedious to identify which packages were
| to rebuild because some test failures were only indirect consequences, and
| a pacakge responsible for the failures had its own tests passing because
| their coverage was shallow... Hence for 3.4.0 I would say that in doubt,
| let's rebuild everything.

Could you fill me in about what broke with BioC and what caused it?

I am not (yet?) on board with recommending a point-blank rebuild of all.
 
| If r-base starts to provide r-api-4 instead of r-api-3 then it will not be
| co-installable with the r-cran/bioc/other-* packages until they have been
| rebuilt.
| 
|  - The benefit is that it will prevent people doing partial upgrades
|from Stable, that would break their packages.

I am not sure I understand why people would want to do partial upgrades.
Debian stable is support. Debian testing is supported.  Hybrid mixes of the
two are risque.

|  - The drawback is the extra work of rebuilding the packages that do not
|use .C and .Fortran.
| 
| Within the Debian infrastructure, the architecture-dependant packages can be
| easily rebuilt by binNMUs.  The architecture-independant packages are easier 
to
| rebuild than before, because it is now possible to do source-only uploads.
| Also, it may be worth asking on debian-devel if binNMUs of arch-independant
| packages will become possible (since we now have autobuilders that can handle
| them).

It sure would help.

| For the Debian packages provided on CRAN, I am not familiar on build is
| trigger, so I can not comment on the ease of rebuilding.

I think that is a different topic for which we may want a different
discussion.

Dirk

| Have a nice day,
| 
| -- 
| Charles Plessy
| Debian Med packaging team,
| http://www.debian.org/devel/debian-med
| Tsurumi, Kanagawa, Japan

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Charles Plessy]

Le Thu, Apr 27, 2017 at 07:24:18AM -0500, Dirk Eddelbuettel a écrit :
> 
> On 27 April 2017 at 13:58, Johannes Ranke wrote:
> | Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel:
> | > On 27 April 2017 at 12:01, Johannes Ranke wrote:
> | 
> | > This may be a use case for r-api-4. Or not as it doesn't break _all_
> | > packages so I am not sure we should force _all_ packages to be rebuilt.
> | > 
> | > Can we not find the ones that use .C and .Fortran ?
> | 
> | I do not understand how the use of r-api-x works, but my feeling is that it 
> | will not allow to differentiate between packages using .C and .Fortan and 
> the 
> | rest.
> 
> Right. And therefore cast too wide a net. 
> 
> | I am surprised that I did not see a related bug report in the Debian BTS 
> yet, 
> | did I overlook something? I only looked for r-base.
> 
> They may not know yet. I should write to debian-devel.
> 
> Any debian-med or debian-science readers here?

Yes I am here :)

I spotted the breakage caused by R 3.4.0 when seeing regression tests
failing on ci.debian.net.  But I did not report them yet as I am still
busy with the breakage caused by R 3.3.3 (mostly on Bioconductor packages).
In the case of R 3.3.3 it was a bit tedious to identify which packages were
to rebuild because some test failures were only indirect consequences, and
a pacakge responsible for the failures had its own tests passing because
their coverage was shallow... Hence for 3.4.0 I would say that in doubt,
let's rebuild everything.

If r-base starts to provide r-api-4 instead of r-api-3 then it will not be
co-installable with the r-cran/bioc/other-* packages until they have been
rebuilt.

 - The benefit is that it will prevent people doing partial upgrades
   from Stable, that would break their packages.

 - The drawback is the extra work of rebuilding the packages that do not
   use .C and .Fortran.

Within the Debian infrastructure, the architecture-dependant packages can be
easily rebuilt by binNMUs.  The architecture-independant packages are easier to
rebuild than before, because it is now possible to do source-only uploads.
Also, it may be worth asking on debian-devel if binNMUs of arch-independant
packages will become possible (since we now have autobuilders that can handle
them).  For the Debian packages provided on CRAN, I am not familiar on build is
trigger, so I can not comment on the ease of rebuilding.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Johannes Ranke]

> | I am surprised that I did not see a related bug report in the Debian BTS
> | yet, did I overlook something? I only looked for r-base.
> 
> They may not know yet. I should write to debian-devel.

I have just submitted a bug report so the further discussion gets archived in 
the right place:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Johannes Ranke]

Am Donnerstag, 27. April 2017, 06:32:13 schrieb Dirk Eddelbuettel:
> On 27 April 2017 at 12:01, Johannes Ranke wrote:
> | > so it seems to me this must affect all packages in Debian sid that were
> | > built before the release of R 3.4.0!
> | 
> | or rather before 14 April 2017, which is when R from revision r72510 was
> | uploaded to sid as pre-release candidate.
> 
> Another example with KernSmooth:
>> library(KernSmooth)
> 
>KernSmooth 2.23 loaded
>Copyright M. P. Wand 1997-2009
> 
>> example(bkde)
> 
>bkde> data(geyser, package="MASS")
> 
>bkde> x <- geyser$duration
> 
>bkde> est <- bkde(x, bandwidth=0.25)
>Error in linbin(x, gpoints, truncate) : object 'F_linbin' not found
> 
> 
> Maybe this part of NEWS is what matters:
> 
> * Packages which register native routines for .C or .Fortran need
>   to be re-installed for this version (unless installed with
>   R-devel SVN revision r72375 or later).

Yes, that is what Martin Mächler referred to in the answer to Björan's call 
for help on r-help.

> KernSmooth surely has .Fortran. Your spatial example had VR_frset failing,
> and that too is called by the old .C.
> 
> A counter-example is eg my RcppEigen package -- I can load it and run
> example(fastLm) just fine as that uses .Call rather than .C or .Fortran.
> 
> I think you are
> 
>  -- correct in that we need rebuilds
>  -- but only for packages using .C and .Fortran calls to compiled

Yes.

> This may be a use case for r-api-4. Or not as it doesn't break _all_
> packages so I am not sure we should force _all_ packages to be rebuilt.
> 
> Can we not find the ones that use .C and .Fortran ?

I do not understand how the use of r-api-x works, but my feeling is that it 
will not allow to differentiate between packages using .C and .Fortan and the 
rest.

I am surprised that I did not see a related bug report in the Debian BTS yet, 
did I overlook something? I only looked for r-base.

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Dirk Eddelbuettel]

On 27 April 2017 at 12:01, Johannes Ranke wrote:
| 
| > so it seems to me this must affect all packages in Debian sid that were
| > built before the release of R 3.4.0!
| 
| or rather before 14 April 2017, which is when R from revision r72510 was 
| uploaded to sid as pre-release candidate.

Another example with KernSmooth:

   > library(KernSmooth)
   KernSmooth 2.23 loaded
   Copyright M. P. Wand 1997-2009
   >
   > example(bkde)
   
   bkde> data(geyser, package="MASS")
   
   bkde> x <- geyser$duration
   
   bkde> est <- bkde(x, bandwidth=0.25)
   Error in linbin(x, gpoints, truncate) : object 'F_linbin' not found
   > 

Maybe this part of NEWS is what matters:

* Packages which register native routines for .C or .Fortran need
  to be re-installed for this version (unless installed with
  R-devel SVN revision r72375 or later).

KernSmooth surely has .Fortran. Your spatial example had VR_frset failing,
and that too is called by the old .C.

A counter-example is eg my RcppEigen package -- I can load it and run
example(fastLm) just fine as that uses .Call rather than .C or .Fortran.

I think you are

 -- correct in that we need rebuilds
 -- but only for packages using .C and .Fortran calls to compiled

This may be a use case for r-api-4. Or not as it doesn't break _all_ packages
so I am not sure we should force _all_ packages to be rebuilt.

Can we not find the ones that use .C and .Fortran ?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Johannes Ranke]

> so it seems to me this must affect all packages in Debian sid that were
> built before the release of R 3.4.0!

or rather before 14 April 2017, which is when R from revision r72510 was 
uploaded to sid as pre-release candidate.

Johannes

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Johannes Ranke]

Am Dienstag, 25. April 2017, 11:21:31 schrieb Dirk Eddelbuettel:
> On 25 April 2017 at 16:11, Johannes Ranke wrote:
> | This looks similar to what I got this morning when I tested my
> | (unreleased)
> | backport of R 3.4.0 to Debian jessie. My test was
> | 
> | library(MASS)
> | example(rlm)
> | 
> | and there was an object that was not found. I am on a train on the way to
> | a
> | meeting right now, so I can not look into it at the moment. Maybe a side
> | effect of the new registration requirements for compiled objects?
> 
> I doubt that as it works for me under R 3.4.0 on a current-ish Ubuntu 16.10
> box.

This is because the version of MASS in sid (r-cran-mass) was released on 21 
April

https://packages.qa.debian.org/r/r-cran-mass.html

which is the same day when r-base was released for R 3.4.0, so MASS was 
obviously built against the current version.

I just tried r-cran-spatial on a **fresh Debian sid chroot**, and get

> library(spatial)
> example(surf.gls)

srf.gl> library(MASS)  # for eqscplot

srf.gl> data(topo, package="MASS")

srf.gl> topo.kr <- surf.gls(2, expcov, topo, d=0.7)
Error in surf.gls(2, expcov, topo, d = 0.7) : object 'VR_frset' not found

so it seems to me this must affect all packages in Debian sid that were built 
before the release of R 3.4.0!

And in fact, nlme, is affected as well:

> library(nlme)
> example(nlme)

nlme> fm1 <- nlme(height ~ SSasymp(age, Asym, R0, lrc),
nlme+ data = Loblolly,
nlme+ fixed = Asym + R0 + lrc ~ 1,
nlme+ random = Asym ~ 1,
nlme+ start = c(Asym = 103, R0 = -8.5, lrc = -3.3))
Error in pdFactor.pdLogChol(X[[i]], ...) : object 'logChol_pd' not found

So before I start spamming the Debian BTS, what would be the right way to deal 
with this? Do we need r-api-x here?

Cheers,

Johannes

P.S.: Sorry of the other post, I pressed send before typing and even before 
thinking ...

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Johannes Ranke]

> >> |  > library(survival, lib.loc = "/usr/lib/R/library")
> >> |  > fit <- coxph(Surv(exit, event) ~ x, data = mort)
> >> | 
> >> | I get
> >> | 
> >> | Error in fitter(X, Y, strats, offset, init, control, weights = weights,  
:
> >> |object 'Ccoxmart' not found
> > 
> > This looks similar to what I got this morning when I tested my
> > (unreleased)
> > backport of R 3.4.0 to Debian jessie. My test was
> > 
> > library(MASS)
> > example(rlm)
> > 
> > and there was an object that was not found. I am on a train on the way to
> > a
> > meeting right now, so I can not look into it at the moment. Maybe a side
> > effect of the new registration requirements for compiled objects?
> 
> Right, you need to run
> 
>  > update.packages(checkBuilt=TRUE)
> 
> to fix it.
> 
> Best, Göran
> 
> > Cheers,
> > 
> > Johannes

-- 
PD Dr. Johannes Ranke
Wissenschaftlicher Berater
Kronacher Str. 12
79639 Grenzach-Wyhlen
http://jrwb.de/contact

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Göran Broström]

On 2017-04-25 16:11, Johannes Ranke wrote:

Am Dienstag, 25. April 2017, 08:50:34 schrieb Dirk Eddelbuettel:

On 25 April 2017 at 14:58, Göran Broström wrote:
| hello,
|
| I just installed R-3.4.0 from scratch:
|
| $ sudo apt install r-base
|
| but when I try
|
|  > library(survival, lib.loc = "/usr/lib/R/library")
|  > fit <- coxph(Surv(exit, event) ~ x, data = mort)
|
| I get
|
| Error in fitter(X, Y, strats, offset, init, control, weights = weights,  :
|object 'Ccoxmart' not found


This looks similar to what I got this morning when I tested my (unreleased)
backport of R 3.4.0 to Debian jessie. My test was

library(MASS)
example(rlm)

and there was an object that was not found. I am on a train on the way to a
meeting right now, so I can not look into it at the moment. Maybe a side effect
of the new registration requirements for compiled objects?


Right, you need to run

> update.packages(checkBuilt=TRUE)

to fix it.

Best, Göran




Cheers,

Johannes



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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Johannes Ranke]

Am Dienstag, 25. April 2017, 08:50:34 schrieb Dirk Eddelbuettel:
> On 25 April 2017 at 14:58, Göran Broström wrote:
> | hello,
> | 
> | I just installed R-3.4.0 from scratch:
> | 
> | $ sudo apt install r-base
> | 
> | but when I try
> | 
> |  > library(survival, lib.loc = "/usr/lib/R/library")
> |  > fit <- coxph(Surv(exit, event) ~ x, data = mort)
> | 
> | I get
> | 
> | Error in fitter(X, Y, strats, offset, init, control, weights = weights,  :
> |object 'Ccoxmart' not found

This looks similar to what I got this morning when I tested my (unreleased) 
backport of R 3.4.0 to Debian jessie. My test was

library(MASS)
example(rlm)

and there was an object that was not found. I am on a train on the way to a 
meeting right now, so I can not look into it at the moment. Maybe a side effect 
of the new registration requirements for compiled objects?


Cheers,

Johannes

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Göran Broström]

On 2017-04-25 15:50, Dirk Eddelbuettel wrote:


On 25 April 2017 at 14:58, Göran Broström wrote:
| hello,
|
| I just installed R-3.4.0 from scratch:
|
| $ sudo apt install r-base
|
| but when I try
|
|  > library(survival, lib.loc = "/usr/lib/R/library")
|  > fit <- coxph(Surv(exit, event) ~ x, data = mort)
|
| I get
|
| Error in fitter(X, Y, strats, offset, init, control, weights = weights,  :
|object 'Ccoxmart' not found
|
| I was told on R-help that I need to
|
|  > update.packages(checkBuilt = TRUE)
|
| (and it works), but
|
| 1. I get two versions of recommended packages, one in
| /usr/lib/R/library, and one in

That is from apt / dpkg -- ie pre-packaged.

| ~/R/x86_64-pc-linux-gnu-library/3.4
| I could fix a write permission in /usr/lib/R or run R as root.

That is from you.

The two have ALWAYS been independent.


I understand that, but what is then the best practice to avoid having 
duplicates of the recommended packages? I tried running R as root and


> update.packages(checkBuilt=TRUE)
--- Please select a CRAN mirror for use in this session ---
Warning: package 'class' in library '/usr/lib/R/library' will not be updated
Warning: package 'cluster' in library '/usr/lib/R/library' will not be 
updated
Warning: package 'codetools' in library '/usr/lib/R/library' will not be 
updated
Warning: package 'foreign' in library '/usr/lib/R/library' will not be 
updated
Warning: package 'KernSmooth' in library '/usr/lib/R/library' will not 
be updated
Warning: package 'lattice' in library '/usr/lib/R/library' will not be 
updated
Warning: package 'Matrix' in library '/usr/lib/R/library' will not be 
updated

Warning: package 'nlme' in library '/usr/lib/R/library' will not be updated
Warning: package 'nnet' in library '/usr/lib/R/library' will not be updated
Warning: package 'spatial' in library '/usr/lib/R/library' will not be 
updated
Warning: package 'survival' in library '/usr/lib/R/library' will not be 
updated

>

Not possible?

I also tried

$ sudo apt install --reinstall r-cran-survival

to no avail.


| 2. Installing from scratch should have this fixed automatically, right?

False.


Thanks. Maybe better to install R from source then.

Göran

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

Re: [R-sig-Debian] R-3.4.0 and recommended packages

[Dirk Eddelbuettel]

On 25 April 2017 at 14:58, Göran Broström wrote:
| hello,
| 
| I just installed R-3.4.0 from scratch:
| 
| $ sudo apt install r-base
| 
| but when I try
| 
|  > library(survival, lib.loc = "/usr/lib/R/library")
|  > fit <- coxph(Surv(exit, event) ~ x, data = mort)
| 
| I get
| 
| Error in fitter(X, Y, strats, offset, init, control, weights = weights,  :
|object 'Ccoxmart' not found
| 
| I was told on R-help that I need to
| 
|  > update.packages(checkBuilt = TRUE)
| 
| (and it works), but
| 
| 1. I get two versions of recommended packages, one in
| /usr/lib/R/library, and one in

That is from apt / dpkg -- ie pre-packaged.

| ~/R/x86_64-pc-linux-gnu-library/3.4
| I could fix a write permission in /usr/lib/R or run R as root.

That is from you.

The two have ALWAYS been independent.
 
| 2. Installing from scratch should have this fixed automatically, right?

False.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R, OpenBLAS and OMP_NUM_THREADS

[Gordon Ball]

On 04/08/16 06:39, Ei-ji Nakama wrote:
> Hi,
> I was be half asleep in the heat ...
> 
> 2016-08-04 0:04 GMT+09:00 Dirk Eddelbuettel :
>>
>> On 3 August 2016 at 16:45, Gordon Ball wrote:
>> | On 02/08/16 03:10, Ei-ji Nakama wrote:
>> | > Hi,
>> | >
>> | > Create /etc/profile.d/openblas.sh.
>> | > Write the following during in this file.
>> | > OPENBLAS_NUM_THREADS = 1
>> | > export OPENBLAS_NUM_THREADS
>> | >
>> | > OPENBLAS_NUM_THREADS environment variable does not affect the 
>> OMP_NUM_THREADS.
>>
>> Thumbs up to using /etc/profile.d/ -- very nice hook.
>>
>> | Unfortunately neither this nor anything else I've tried today appears to
>> | set the variable for sessions started through RStudio server (which may
>> | or may not be an appropriate issue here).
>> |
>> | It appears that the rstudio server spawns sessions with a new minimal
>> | environment (rstudio::core::system::launchChildProcess) and no option to
>> | inject or inherit variables. (Various methods of controlling the session
>> | environment are documented in the pro/paid version manual [1], but are
>> | not implemented in the public codebase - enterprise features, presumably).
>> |
>> | Hence approaches like setting the environment in the
>> | rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
>> | service profile including pam_env.so (to load the setting from
>> | /etc/environment) don't work. It would probably be possible to work
>> | round this by creating a small binary wrapper for the rsession binary
>> | which sets the environment, but it would make a mess of the packaging.
>> |
>> | So I've gone with an `/etc/R/Rprofile.site` containing
>> |
>> | local({
>> | if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1)
>> | })
>> |
>> | which does mean people get this library loaded in all their sessions but
>> | that doesn't seem to cause any particular trouble (yet).
> 
> In this case, hook of the / etc / R / Rprofile.site would be best
> 
> local({
>   if(require("RhpcBLASctl", quietly=TRUE)){
>   if(Sys.getenv("OPENBLAS_NUM_THREADS")=="" &
>  Sys.getenv("OMP_NUM_THREADS")=="")
> blas_set_num_threads(1)
>   }
> })
> 
> $ OMP_NUM_THREADS=4 R -q -e 'library(RhpcBLASctl);blas_get_num_procs()'
>> library(RhpcBLASctl);blas_get_num_procs()
> [1] 4
> 
> maybe confusion would be minimal.

Yes, that looks a bit better, allowing it to be overridden by
environment variables.

The other thing that occurred to me was whether this setting would be
inherited by child R processes (otherwise you'd get a massive thread
explosion when running something intentionally parallel), but it looks
like at least the builtin `parallel` library does retain the BLAS
settings of the parent (presumably since it uses `fork()`).

It is maybe still worth setting `Sys.setenv(OPENBLAS_NUM_THREADS=1)`
along with the `blas_set_num_threads(1)` call in case there are any
multicore libraries for which this doesn't apply.


(Also, it hadn't occurred to me earlier but I realise you're the author
of RhpcBLASctl - appreciate it)


Gordon

> 
>> I was just working on something that needed environment variables (for
>> automating tests to a database backend) and populating
>>
>>/etc/R/Renviron.site
>>
>> worked for me. Otherwise explicit code in Rprofile.site is of course good, as
>> is conditioning.  I do that too for some use cases.
> 
> I often forget to have set it...orz
> 
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> 
>

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

Re: [R-sig-Debian] R, OpenBLAS and OMP_NUM_THREADS

[Ei-ji Nakama]

Hi,
I was be half asleep in the heat ...

2016-08-04 0:04 GMT+09:00 Dirk Eddelbuettel :
>
> On 3 August 2016 at 16:45, Gordon Ball wrote:
> | On 02/08/16 03:10, Ei-ji Nakama wrote:
> | > Hi,
> | >
> | > Create /etc/profile.d/openblas.sh.
> | > Write the following during in this file.
> | > OPENBLAS_NUM_THREADS = 1
> | > export OPENBLAS_NUM_THREADS
> | >
> | > OPENBLAS_NUM_THREADS environment variable does not affect the 
> OMP_NUM_THREADS.
>
> Thumbs up to using /etc/profile.d/ -- very nice hook.
>
> | Unfortunately neither this nor anything else I've tried today appears to
> | set the variable for sessions started through RStudio server (which may
> | or may not be an appropriate issue here).
> |
> | It appears that the rstudio server spawns sessions with a new minimal
> | environment (rstudio::core::system::launchChildProcess) and no option to
> | inject or inherit variables. (Various methods of controlling the session
> | environment are documented in the pro/paid version manual [1], but are
> | not implemented in the public codebase - enterprise features, presumably).
> |
> | Hence approaches like setting the environment in the
> | rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
> | service profile including pam_env.so (to load the setting from
> | /etc/environment) don't work. It would probably be possible to work
> | round this by creating a small binary wrapper for the rsession binary
> | which sets the environment, but it would make a mess of the packaging.
> |
> | So I've gone with an `/etc/R/Rprofile.site` containing
> |
> | local({
> | if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1)
> | })
> |
> | which does mean people get this library loaded in all their sessions but
> | that doesn't seem to cause any particular trouble (yet).

In this case, hook of the / etc / R / Rprofile.site would be best

local({
  if(require("RhpcBLASctl", quietly=TRUE)){
  if(Sys.getenv("OPENBLAS_NUM_THREADS")=="" &
 Sys.getenv("OMP_NUM_THREADS")=="")
blas_set_num_threads(1)
  }
})

$ OMP_NUM_THREADS=4 R -q -e 'library(RhpcBLASctl);blas_get_num_procs()'
> library(RhpcBLASctl);blas_get_num_procs()
[1] 4

maybe confusion would be minimal.

> I was just working on something that needed environment variables (for
> automating tests to a database backend) and populating
>
>/etc/R/Renviron.site
>
> worked for me. Otherwise explicit code in Rprofile.site is of course good, as
> is conditioning.  I do that too for some use cases.

I often forget to have set it...orz

> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



-- 
Best Regards,
--
Eiji NAKAMA 
"\u4e2d\u9593\u6804\u6cbb"  

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

Re: [R-sig-Debian] R, OpenBLAS and OMP_NUM_THREADS

[Dirk Eddelbuettel]

On 3 August 2016 at 16:45, Gordon Ball wrote:
| On 02/08/16 03:10, Ei-ji Nakama wrote:
| > Hi,
| > 
| > Create /etc/profile.d/openblas.sh.
| > Write the following during in this file.
| > OPENBLAS_NUM_THREADS = 1
| > export OPENBLAS_NUM_THREADS
| > 
| > OPENBLAS_NUM_THREADS environment variable does not affect the 
OMP_NUM_THREADS.

Thumbs up to using /etc/profile.d/ -- very nice hook.

| Unfortunately neither this nor anything else I've tried today appears to
| set the variable for sessions started through RStudio server (which may
| or may not be an appropriate issue here).
| 
| It appears that the rstudio server spawns sessions with a new minimal
| environment (rstudio::core::system::launchChildProcess) and no option to
| inject or inherit variables. (Various methods of controlling the session
| environment are documented in the pro/paid version manual [1], but are
| not implemented in the public codebase - enterprise features, presumably).
| 
| Hence approaches like setting the environment in the
| rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
| service profile including pam_env.so (to load the setting from
| /etc/environment) don't work. It would probably be possible to work
| round this by creating a small binary wrapper for the rsession binary
| which sets the environment, but it would make a mess of the packaging.
| 
| So I've gone with an `/etc/R/Rprofile.site` containing
| 
| local({
| if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1)
| })
| 
| which does mean people get this library loaded in all their sessions but
| that doesn't seem to cause any particular trouble (yet).

I was just working on something that needed environment variables (for
automating tests to a database backend) and populating

   /etc/R/Renviron.site

worked for me. Otherwise explicit code in Rprofile.site is of course good, as
is conditioning.  I do that too for some use cases.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] R, OpenBLAS and OMP_NUM_THREADS

[Gordon Ball]

On 02/08/16 03:10, Ei-ji Nakama wrote:
> Hi,
> 
> Create /etc/profile.d/openblas.sh.
> Write the following during in this file.
> OPENBLAS_NUM_THREADS = 1
> export OPENBLAS_NUM_THREADS
> 
> OPENBLAS_NUM_THREADS environment variable does not affect the OMP_NUM_THREADS.
> 

Thanks for the response.

This works fine for R run from the command line (as does setting the
same variable in `/etc/environment`), providing a fresh login is made.



Unfortunately neither this nor anything else I've tried today appears to
set the variable for sessions started through RStudio server (which may
or may not be an appropriate issue here).

It appears that the rstudio server spawns sessions with a new minimal
environment (rstudio::core::system::launchChildProcess) and no option to
inject or inherit variables. (Various methods of controlling the session
environment are documented in the pro/paid version manual [1], but are
not implemented in the public codebase - enterprise features, presumably).

Hence approaches like setting the environment in the
rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
service profile including pam_env.so (to load the setting from
/etc/environment) don't work. It would probably be possible to work
round this by creating a small binary wrapper for the rsession binary
which sets the environment, but it would make a mess of the packaging.



So I've gone with an `/etc/R/Rprofile.site` containing

local({
if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1)
})

which does mean people get this library loaded in all their sessions but
that doesn't seem to cause any particular trouble (yet).


Gordon


[1]: docs.rstudio.com/ide/server-pro/r-sessions.html

> 
> 2016-08-01 20:06 GMT+09:00 Gordon Ball :
>> What is the correct way to globally configure R to default to single (or
>> at least, << NUM_CPUS) threaded operation?
>>
>>
>> Using R 3.3.1 (both in debian unstable or using the CRAN repository for
>> xenial) with OpenBLAS (0.2.18) defaults to using one thread per
>> available CPU, which isn't ideal for machines more than a couple of CPUs.
>>
>> Setting the environment (OMP_NUM_THREADS or OPENBLAS_NUM_THREADS) in the
>> shell works:
>>
>> $ OMP_NUM_THREADS=1 R
>>> Sys.getenv("OMP_NUM_THREADS")
>> [1] "1"
>>> system.time({x <- replicate(5e3, rnorm(5e3)); tcrossprod(x) })
>> [runs in one thread]
>>
>> but adding it to /etc/R/Renviron.site doesn't:
>>
>> $ R
>>> Sys.getenv("OMP_NUM_THREADS")
>> [1] "1"
>>> system.time({x <- replicate(5e3, rnorm(5e3)); tcrossprod(x) })
>> [runs multi-threaded]
>>
>> (nor does setting the variable at runtime with `Sys.setenv`)
>>
>> Presumably Renviron is read after the library is already loaded and so
>> the environment variable is set too late to matter.
>>
>>
>>
>>
>> I can think of these solutions, but none of them are ideal:
>>
>>  * remove OpenBLAS (but even single threaded it performs quite a lot
>> better than the basic libblas)
>>
>>  * set OMP_NUM_THREADS globally in people's shells with the system
>> bashrc (but this doesn't work for non-shell, RStudio server sessions)
>>
>>  * use a library like RhpcBLASctl to set the number of threads in the
>> global Rprofile
>>
>>  * compile a custom openblas with threading disabled, or at least a
>> small default number of threads
>>
>>
>> Any better ideas?
>>
>>
>> Thanks
>>
>> Gordon
>>
>> ___
>> R-SIG-Debian mailing list
>> R-SIG-Debian@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-debian
> 
> 
>

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

Re: [R-sig-Debian] [R] Install R version 3.3 on Debian server

[Martin Maechler]

> Mbr Mbr 
> on Mon, 18 Jul 2016 11:45:00 +0200 writes:

> Hello,
> I'm currently in a internship and I'm working on a Debian server.
> However, I have some errors in my scripts and I think it's because of the
> version of R installed on the server (works well on my PC with the latest
> version of R on Windows aka 3.3.1).

> Here are the details from sessionInfo() of the server :

> - R version 2.15.1 (2012-06-22)
> - Platform : i486-pc-linux-gnu (32 bit)

Yes,  2.15.1  is considered antique,  and nobody should be using
it unless for "Rchaelogy" (the pre-history and history of R
implementations), and so I do occasionally start such a version.

> Since I'm totally a beginner about Linux server and my internship's tutor
> doesn't want to read the tutorial to install R for Debian (even if the
> server is his) or help for this tank for some unknown reason, I would like
> to know how to upgrade the current R version on the server (from 2.15.1 to
> 3.3).

Very good proposal.
Two things:

- We have a *dedicated* mailing list for Debian (and
  Debian-derived such as "ubuntu") Linux distributions:
  --> https://www.R-project.org/mail.html does list the "SIG"
  (Special Interest Groups), including R-SIG-Debian
  which points to http://stat.ethz.ch/mailman/listinfo/r-sig-debian

- CRAN itself has sections about this, notably
  https://cloud.r-project.org/bin/linux/debian/
  will tell you how to tell your debian system to get R from
  CRAN as opposed from the debian repositories.
  

> Thanks in advance

You are welcome,
Martin Maechler

> Sincelerly,
> Mbr

> [[alternative HTML version deleted]]

> __
> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide 
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.

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

Re: [R-sig-Debian] r-base installation fails on Ubuntu 14.04

[ProfJCNash]

Apologies for my bit of that. I thought I'd only got the top.
Fumble fingers!

JN

On 16-03-23 03:14 PM, Dirk Eddelbuettel wrote:
> 
> Folks,
> 
> Could we PLEASE stop replies on 100kb logs without cutting the quoted part?
> 
> I learned my lesson; I'll never post a log again. Whatever happened to list
> etiquette?
> 
> Dirk
>

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

Re: [R-sig-Debian] r-base installation fails on Ubuntu 14.04

[Dirk Eddelbuettel]

On 23 March 2016 at 12:35, Barnet Wagman wrote:
| One of the dependency problems I'm having is:
| 
| gfortran-4.8 : Depends: gcc-4.8-base (= 4.8.2-19ubuntu1) but 
| 4.8.4-2ubuntu1~14.04.1 is installed.
| 
| I'm not sure how to  interpret this.  Does this mean that the gfortran 
| installed is too recent?  If so, does R really require an older version 
| of gfortran, or is this related to the way the r-base-core package is 
| specified?

That is more promising and probably related to the liblapack/libblas issue!
With a bit of 'apt-cache policy' on these you may be able to find where they
are from; and you need the ones that R wants into order to use R.

Sometimes you get by specifying both as in

  $ sudo apt-get install gfortran-4.8 gcc-4.8-base

ie asking for both to be (re-)installed.  That may point to another package,
and you may have to recurse once or twice more.  As Alex correctly pointed
out, this is quite possibly due to the other backports.

I "own" Docker setup involving Ubuntu 12.04 and 14.04, but rarely add
anything besides CRAN in those (by design more minimal) setups.

Lastly, and please don't take this the wrong way: I think I am helping way
more people like you who for one reason or other insist on older / frozen
system like 14.04 but then desire newer software.  Simply running _current_
Ubuntu and upgrading every six months is IMHO much easier.  I've been doing
it for a decade on lots of machines across home and different workplaces.
YMMV, but it may be worth considering to just upgrade.  gcc and g++ 5.2 are
much nicer anyway :)

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] r-base installation fails on Ubuntu 14.04

[Barnet Wagman]

One of the dependency problems I'm having is:

gfortran-4.8 : Depends: gcc-4.8-base (= 4.8.2-19ubuntu1) but 
4.8.4-2ubuntu1~14.04.1 is installed.


I'm not sure how to  interpret this.  Does this mean that the gfortran 
installed is too recent?  If so, does R really require an older version 
of gfortran, or is this related to the way the r-base-core package is 
specified?


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

Re: [R-sig-Debian] r-base installation fails on Ubuntu 14.04

[Dirk Eddelbuettel]

On 23 March 2016 at 11:38, Barnet Wagman wrote:
| It's a Dell XPS 13.
| 
| Obviously I don't understand what's in libcmanager0.  I wonder if I can 
| safely replace it.  I'm a bit uneasy about replacing things Dell 
| installed.  I gather there are some specialized drivers for the monitor 
| on this system.

i)  Apply common sense

ii) If that fails do 'apt-cache show libcmanager0'.

It sounds like a system library so it is unlikely to interfere with your
lapack/blas issue which is almost surely only affecting R (and possibly
Octave, Scilab, some Python libs etc pp).

'apt-cache rdepends libcmanager0' will show you who depends on libcmanager0.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-sig-Debian] r-base installation fails on Ubuntu 14.04

[Dirk Eddelbuettel]

Folks,

Could we PLEASE stop replies on 100kb logs without cutting the quoted part?

I learned my lesson; I'll never post a log again. Whatever happened to list
etiquette?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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