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

[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

[R-sig-Debian] R Graphics engine again - Was: Accepted r-base 4.1.3.20220324-1 (source) into unstable

[Johannes Ranke]

Dear all,

For the upcoming R 4.2.0, there is a NEWS entry:

- The graphics engine version, R_GE_version, has been bumped to 15 and so 
packages that provide graphics devices should be reinstalled

"Should" in this context really means "must be reinstalled if you want to be 
able to use the devices provided by these packages". I just tested my local 
backport of Dirks recent upload to unstable, and confirm that such devices only 
work after reinstalling the package that provides them. So I believe at least 
the following packages should be rebuilt in unstable:

r-cran-rgl, r-cran-svglite, r-cran-vdiffr which embeds svglite, ggplot2

This list is just what I came up with in May last year when R_GE_version was 
bumped to 14, I assume that the list is longer than that.

Another option (also discussed last year) would be to introduce something like 
Provides: r-gev-15 to the next prerelease upload of r-base, and add versioned 
depends to the affected R graphics packages.

As I do not provide backports of Graphics packages, I do not have a strong 
opinion on this. For Michael and the users of his nice PPAs of R packages for 
Ubuntu, the second option may have the potential to avoid some headaches.

Cheers,

Johannes


--  Weitergeleitete Nachricht  --

Betreff: Accepted r-base 4.1.3.20220324-1 (source) into unstable
Datum: Freitag, 25. M�rz 2022, 02:20:11 CEST
Von: Debian FTP Masters 
An: debian-devel-chan...@lists.debian.org

Format: 1.8
Date: Thu, 24 Mar 2022 19:25:31 -0500
Source: r-base
Architecture: source
Version: 4.1.3.20220324-1
Distribution: unstable
Urgency: medium
Maintainer: Dirk Eddelbuettel 
Changed-By: Dirk Eddelbuettel 
Changes:
 r-base (4.1.3.20220324-1) unstable; urgency=medium
 .
   * Initial alpha release (svn r81978) of R 4.2.0 to be released April 22
 .
   * debian/source.lintian-overrides: Override for katex.js sources which are
 at https://github.com/KaTeX/KaTeX
 .
   * debian/patches/series: No longer need 'use-fPIC-on-alpha'
Checksums-Sha1:
 e8a92c85322eafe16bd80afe1f0d3db314478c28 3077 r-base_4.1.3.20220324-1.dsc
 0968db74d3f83837648f4cbe1fa243b4d940079c 37564066 r-
base_4.1.3.20220324.orig.tar.gz
 baf9b2481af999e551ca0a3a3c3afb9c22534b94 97896 r-
base_4.1.3.20220324-1.debian.tar.xz
 6371ab923ea4f0416cd79c74450a3b1553b5875e 16715 r-
base_4.1.3.20220324-1_amd64.buildinfo
Checksums-Sha256:
 9bcd2fe7f655a3005edf4b28233fef285c5a6aef94c361fffe486413a5856a71 3077 r-
base_4.1.3.20220324-1.dsc
 a33a7b4031b8c92eb2eb28a514a5bad5c71620e8ff61421314e9f74a6698c6f0 37564066 r-
base_4.1.3.20220324.orig.tar.gz
 9e7ef4a09ef807d7ba314855a49ad437baecd6a59f510e8b553e3562e9f7d08b 97896 r-
base_4.1.3.20220324-1.debian.tar.xz
 22b8af5fc8a699ed955a37ea6dbc4a0447da5a774573e49fd9dca13c2c47ad1b 16715 r-
base_4.1.3.20220324-1_amd64.buildinfo
Files:
 d6c94ea0237307a87ba17369ff3a6c6e 3077 gnu-r optional r-
base_4.1.3.20220324-1.dsc
 c4d8c3a9832f7c8b6d9a352f9acf10b6 37564066 gnu-r optional r-
base_4.1.3.20220324.orig.tar.gz
 3eaa8ff662c0311280a086146a9d4593 97896 gnu-r optional r-
base_4.1.3.20220324-1.debian.tar.xz
 47a90075880240ea3deb707da2e9cb40 16715 gnu-r optional r-
base_4.1.3.20220324-1_amd64.buildinfo


-----
-- 
Johannes Ranke
Wissenschaftlicher Berater
07624 8099027
https://jrwb.de
[[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] signing key of repo expired -- tangential question

[Johannes Ranke]

While waiting for the mirrors to sync, you might want to have a look at my 
(poor man's) key transition statement located here

  https://jrwb.de/docs/key_transition_2021-11-16.asc

By the way, volunteers for improving the maintenance of the Debian section on 
CRAN are certainly welcome. It would be nice to have a team instead of a one 
man show! The scripts currently used can be studied here:

  https://cgit.jrwb.de/r-backports/
  
or cloned from this very URL.

Kind regards,

Johannes

Am Dienstag, 16. November 2021, 15:29:34 CET schrieb J C Nash:
> I've seen several issues like this with "private" repositories or
> sections thereof. Is there a reasonable way to set things up so keys
> or access is shared across several people or held in an organizational
> escrow? I think there is general good will on the part of most people
> contributing, but things happen in life, and the collective can be
> inconvenienced.
> 
> Best,
> 
> JN
> 
> On 2021-11-16 8:28 a.m., Johannes Ranke wrote:
> > Hi all,
> > 
> > sorry to all users of the CRAN Debian backports for the inconvenience
> > caused by the expiration of my signing key.
> > 
> > I have created a new key and uploaded it to keyserver.ubuntu.com, and
> > signed the buster40 and bullseye40 repositories with it. The repos signed
> > with the new key will be available to all users of the CRAN Debian
> > archive as soon as the synchronisation has taken place.
> > 
> > Kind regards,
> > 
> > Johannes
> > 
> > P.S.: Unfortunately I could not change the key expiration of the old key,
> > as I have lost the passphrase of the corresponding master key. For the
> > same reason, the new key is not signed with the old one.
> > 
> > Am Dienstag, 16. November 2021, 14:18:06 CET schrieb Dirk Eddelbuettel:
> >> On 16 November 2021 at 12:08, bodo riediger-klaus wrote:
> >> | Hello,
> >> | 
> >> | i get a key-expired message when i try to update my repository
> >> | 
> >> | root@merlot:/etc/apt/sources.list.d# cat rbase-stable.list
> >> | deb http://ftp.gwdg.de/pub/misc/cran/bin/linux/debian buster-cran40/
> >> | 
> >> | 
> >> | W: GPG-Fehler: http://ftp.gwdg.de/pub/misc/cran/bin/linux/debian
> >> | buster-cran40/ InRelease: Die folgenden Signaturen waren ungültig:
> >> | EXPKEYSIG FCAE2A0E115C3D8A Johannes Ranke (Wissenschaftlicher Berater)
> >> | 
> >> 
> >> As it is the personal key of Johannes, only Johannes (CC'ed) can fix it.
> >> It is my understanding that he has been contacted, but as we had not said
> >> so on the list it is good to have it here too.
> >> 
> >> Dirk
> >> 
> >> | As you can see on
> >> | 
> >> | https://keyserver.ubuntu.com/pks/lookup?search=0xE19F5F87128899B192B1A2
> >> | C2A
> >> | D5F960A256A04AF=on=index
> >> | 
> >> | there are two Expired Sub-Keys:
> >> | 
> >> | sub rsa3072/5bc121cfdc61bdae03062260af83ce117fbb4c22
> >> | 2016-11-15T20:12:04Z
> >> | sig sbind ad5f960a256a04af 2016-11-15T20:12:04Z 
> >> | 2021-11-14T18:17:46Z []
> >> | 
> >> | sub rsa3072/ad7b5162ba456be3526f8d92fcae2a0e115c3d8a
> >> | 2016-11-15T19:58:24Z
> >> | sig sbind ad5f960a256a04af 2016-11-15T19:58:24Z 
> >> | 2021-11-14T18:17:46Z []
> >> | 
> >> | 
> >> | greetings, bodo
> >> | 
> >> | --
> >> | R.-Bodo Riediger-Klaus IT-Dienst FB MI Freie Universität Berlin
> >> | bodo.riediger-kl...@fu-berlin.de Takustr.9 R.038 Fon: 030 838 75175
> >> | 
> >> | ___
> >> | 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

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

Re: [R-sig-Debian] signing key of repo expired

[Johannes Ranke]

Hi all,

sorry to all users of the CRAN Debian backports for the inconvenience caused 
by the expiration of my signing key.

I have created a new key and uploaded it to keyserver.ubuntu.com, and signed 
the buster40 and bullseye40 repositories with it. The repos signed with the 
new key will be available to all users of the CRAN Debian archive as soon as 
the synchronisation has taken place.

Kind regards,

Johannes

P.S.: Unfortunately I could not change the key expiration of the old key, as I 
have lost the passphrase of the corresponding master key. For the same reason, 
the new key is not signed with the old one.

Am Dienstag, 16. November 2021, 14:18:06 CET schrieb Dirk Eddelbuettel:
> On 16 November 2021 at 12:08, bodo riediger-klaus wrote:
> | Hello,
> | 
> | i get a key-expired message when i try to update my repository
> | 
> | root@merlot:/etc/apt/sources.list.d# cat rbase-stable.list
> | deb http://ftp.gwdg.de/pub/misc/cran/bin/linux/debian buster-cran40/
> | 
> | 
> | W: GPG-Fehler: http://ftp.gwdg.de/pub/misc/cran/bin/linux/debian
> | buster-cran40/ InRelease: Die folgenden Signaturen waren ungültig:
> | EXPKEYSIG FCAE2A0E115C3D8A Johannes Ranke (Wissenschaftlicher Berater)
> | 
> 
> As it is the personal key of Johannes, only Johannes (CC'ed) can fix it.
> It is my understanding that he has been contacted, but as we had not said so
> on the list it is good to have it here too.
> 
> Dirk
> 
> | As you can see on
> | 
> | https://keyserver.ubuntu.com/pks/lookup?search=0xE19F5F87128899B192B1A2C2A
> | D5F960A256A04AF=on=index
> | 
> | there are two Expired Sub-Keys:
> | 
> | sub rsa3072/5bc121cfdc61bdae03062260af83ce117fbb4c22
> | 2016-11-15T20:12:04Z
> | sig sbind ad5f960a256a04af 2016-11-15T20:12:04Z 
> | 2021-11-14T18:17:46Z []
> | 
> | sub rsa3072/ad7b5162ba456be3526f8d92fcae2a0e115c3d8a
> | 2016-11-15T19:58:24Z
> | sig sbind ad5f960a256a04af 2016-11-15T19:58:24Z 
> | 2021-11-14T18:17:46Z []
> | 
> | 
> | greetings, bodo
> | 
> | --
> | R.-Bodo Riediger-Klaus IT-Dienst FB MI Freie Universität Berlin
> | bodo.riediger-kl...@fu-berlin.de Takustr.9 R.038 Fon: 030 838 75175
> | 
> | ___
> | 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] Configure error: checking if libcurl supports https... no --- slight update.

[Johannes Ranke]

> > I don't think so.  I did "sudo find /usr -name "*curl*" -print".  The
> > results are attached in the file "curlSearch.txt".
> 
> Good thought as far as I can tell. Unfortunately the attachment didn't get
> through.

Oh, I just overlooked the attachement, it did get through. The listing clearly 
shows that you have a curl version in /usr/local/ that I would recommend to 
uninstall (preferably using make uninstall in the source directory) as 
suggested in my previous emails, as it is the likely cause of the configure 
error you came to report.

The Ubuntu curl/libcurl etc packages (that you should keep) provide the 
headers in /usr/include.

Johannes

> 
> > I am too ignorant
> > to discern what might be problematic, but nothing obvious leaps out at
> > me.  Could the stuff in /usr/local/include/curl be a source of
> > difficulty?
> 
> Others on this list are far more qualified to answer this, but from my
> limited knowledge in this area I would say yes, it could.
> 
> 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] Configure error: checking if libcurl supports https... no --- slight update.

[Johannes Ranke]

Am Dienstag, 31. August 2021, 01:47:14 CEST schrieb Rolf Turner:
> On Mon, 30 Aug 2021 08:00:34 +0200
 
 ...

> > But it seems you still have a curl/libcurl version in /usr/local that
> > you should get rid of, as it gets in the way of configuring R.
> 
> I don't think so.  I did "sudo find /usr -name "*curl*" -print".  The
> results are attached in the file "curlSearch.txt".  

Good thought as far as I can tell. Unfortunately the attachment didn't get 
through.

> I am too ignorant
> to discern what might be problematic, but nothing obvious leaps out at
> me.  Could the stuff in /usr/local/include/curl be a source of
> difficulty?

Others on this list are far more qualified to answer this, but from my limited 
knowledge in this area I would say yes, it could.

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] Configure error: checking if libcurl supports https... no --- slight update.

[Johannes Ranke]

Hi Rolf,

Am Montag, 30. August 2021, 07:42:56 CEST schrieb Rolf Turner:
> Hi All,
> 
> I just thought I'd let you know that I've tried a couple of other
> things.  No real progress, but.
> 
> (1) In respect of just-plain-curl: to make the issue clearer, I tried
> 
> curl --version
> 
> and got:
> > > curl: /usr/local/lib/libcurl.so.4: no version information available
> > > (required by curl)
> > 
> > curl: symbol lookup error: curl: undefined symbol: curl_mime_free,
> > version CURL_OPENSSL_4
> 
> I found that there was another, apparently newer, version of
> libcurl.so.4 in /usr/lib/x86_64-linux-gnu.  I realised that I did
> not have /usr/lib/x86_64-linux-gnu in my LD_LIBRARY_PATH.  So I put it
> into that path (*before* /usr/local/lib) and "curl --version" now
> 
> seems to be OK and gives:
> > curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f
> > zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0
> > (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0
> > librtmp/2.3 Release-Date: 2020-01-08 Protocols: dict file ftp ftps
> > gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp
> > sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS brotli
> > GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM
> > NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
> 
> which verbose, but I guess that's alright.

That may be OK for your the curl binary you are using (likely /usr/local/bin/
curl, you still owe use the output of 'which curl'.

But it seems you still have a curl/libcurl version in /usr/local that you 
should get rid of, as it gets in the way of configuring R.

Johannes

> 
> (2) In respect of libcurl and https:
> 
> I did a web search on "libcurl >= 7.28.0 library and headers are
> required" and after much thrashing around found what looked like a
> useful hit at https://www.xspdf.com/help/51318770.html .
> 
> The problem(s) described are exactly the same as mine.  Different
> correspondents report different results; one person said that
> installing libcurl4-openssl-dev solved the problem, another said that
> it didn't but that libcurl4-gnutls-dev did work.
> 
> It was nice to know that I am not alone, but neither of the foregoing
> solutions worked for me.  Then another correspondent suggested that the
> problem might be with the gcc variant.  I thought that this was
> promising.
> 
> I found that my gcc version was 9.3.0.  I found that the latest version
> seemed to be 11.2, so I tried to upgrade.  The process seemed to be
> endlessly complicated but I eventually got a new version such that
> 
>gcc --version
> 
> gives "(Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0".  (11.1 not 11.2 ??? Oh,
> well.)
> 
> But then I tried the configure step again, with the new gcc in place,
> and got the same old error.  Story of my life.
> 
> I'm going mad, *mad* I tell you!!! :-)
> 
> cheers,
> 
> Rolf


-- 
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] Configure error: checking if libcurl supports https... no

[Johannes Ranke]

...

> > curl: /usr/local/lib/libcurl.so.4: no version information available

so here we have evidence that indeed you have a locally compiled curl version 
on your system in addition to the Ubuntu one (which would not put anything 
into /usr/local/lib).

So it seems that at some point you have downloaded curl sources and installed 
them into your system, and that this version (as it has no https support) got 
in the way configuring R 4.1.0.

If you still have the sources lying around, there is an uninstall target in 
the Makefile, so you should go to the source directory and do a

sudo make uninstall

to get rid of your local curl version in /usr/local/.

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] Configure error: checking if libcurl supports https... no

[Johannes Ranke]

Am Sonntag, 29. August 2021, 11:01:43 CEST schrieb Rolf Turner:
> On Sun, 29 Aug 2021 10:16:16 +0200
> 
> Johannes Ranke  wrote:

...

> > You can try
> > 
> > $ sudo apt build-dep r-base
> > 
> > to pull in all build dependencies specified by Dirks R debs, and try
> > again.
> 
> Thanks for the suggestion.  I did
> 
>sudo apt build-dep r-base
> 
> as instructed.

I assume this pulled in some unrelated packages. As you do not mention any 
output, I assume there was no error.

> I then noticed that I could not run R --- got a "permission denied"
> error.  So I next did:

...

> P.S. Clearly there must be something broken in my system, but how on
> earth do I track down what's wrong?

One reason for what you see could be that you have previously compiled and 
installed curl from source (which will also build and install libcurl), and 
this local installation does not have ssl support.

One check that I can think of is to run

$ which curl

which returns

/usr/bin/curl

if you only have the Ubuntu package installed.

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] Configure error: checking if libcurl supports https... no

[Johannes Ranke]

Hi,

for what it's worth, on a Debian bullseye system, configuring the R 4.1.0 
tarball works fine:

$ wget https://cran.r-project.org/src/base/R-4/R-4.1.0.tar.gz
$ tar xf R-4.1.0.tar.gz
$ cd R-4.1.0/
$ ./configure

...
checking if libcurl supports https... yes
...

with libcurl4 and libcurl4-gnutls-dev installed. I believe this should also 
work on Ubuntu.

You can try

$ sudo apt build-dep r-base

to pull in all build dependencies specified by Dirks R debs, and try again.

Johannes






Am Sonntag, 29. August 2021, 08:49:19 CEST schrieb Rolf Turner:
> On Sat, 28 Aug 2021 22:33:08 -0500
> 
> Dirk Eddelbuettel  wrote:
> > Rolf,
> > 
> > I am truly sorry but I am getting lost in your original message.
> > Could you follow-up and describe (concisely, if possible) what your
> > question is?  Is it
> > 
> >  - installing 4.1.1 or 4.1.0
> >  - developing a package of yours
> >  - installing a package ?
> 
> Sorry if I over-egged my explanation.
> 
> * I am trying to install R 4.1.0 (the previous version of R).
>   I have the current version, R 4.1.1 (readily available as a Linux
>   binary) up and going; no problema.
> 
> * My desire to install 4.1.0 was *motivated* by a strange
>   conundrum with respect to a package that I am developing.
>   But that's *not* actually relevant at the moment.
> 
> * I successfully downloaded the source for R 4.1.0 and started
>   the configure -> make sequence.  But things came to a halt with the
>   configure error shown in the subject line.
> 
> * I then fooled around with installing/uninstalling various flavours
>   of libcurl.dev to see if I could get rid of the configure error.
>   Nothing worked.
> 
> I hope that my problem is clear now.
> 
> cheers,
> 
> Rolf

___
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

[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

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

[Johannes Ranke]

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.

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?

Cheers,

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] Failing to install R 4.0.? on Raspian

[Johannes Ranke]

Am Donnerstag, 25. März 2021, 08:11:43 CET schrieb Chris Evans:
> My reply to Dirk crossed with your incoming message Johannes. Thanks both.

You're welcome!

> More inline below.
> 
...

> > 
> > Yes, at one point I did compile armhf arm64 packages for the CRAN repo on
> > a
> > raspberry that I still own, but the SD card broke and I do not have use
> > case anyways, so I stopped that (this is documented on the CRAN repo).
> 
> Ah, I missed that.  Can you say where?

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

Hope you succeed anyways!

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] Failing to install R 4.0.? on Raspian

[Johannes Ranke]

{a}
> |   libxcb-present0{a} libxcb-shape0{a} libxcb-sync1{a}
> |   libxml-parser-perl{a} libxml-twig-perl{a} libxml-xpathengine-perl{a}
> |   libxmu6{a} libxshmfence1{a} libxss1{a} libxv1{a} libxxf86dga1{a}
> |   libxxf86vm1{a} pkg-config{a} r-base{b} r-base-core{a} r-base-dev{ab}
> |   r-base-html{a} r-cran-boot{ab} r-cran-class{a} r-cran-cluster{a}
> |   r-cran-codetools{ab} r-cran-foreign{a} r-cran-kernsmooth{a}
> |   r-cran-lattice{a} r-cran-mass{a} r-cran-matrix{a} r-cran-mgcv{a}
> |   r-cran-nlme{a} r-cran-nnet{a} r-cran-rpart{a} r-cran-spatial{a}
> |   r-cran-survival{a} r-doc-html{a} r-recommended{ab} unzip{a}
> |   x11-utils{a} x11-xserver-utils{a} xdg-utils{a} zip{a} zlib1g-dev{a}
> | 
> | 0 packages upgraded, 97 newly installed, 0 to remove and 0 not upgraded.
> | Need to get 1,812 kB/89.4 MB of archives. After unpacking 716 MB will be
> | used.| 
> | The following packages have unmet dependencies:
> |  r-cran-boot : Depends: r-base-core (>= 4.0.4-1~bustercran.0) but 3.5.2-1
> |  is to be installed|  
> |Depends: r-api-4.0 which is a virtual package and is not
> |provided by any available package|  
> |  r-cran-codetools : Depends: r-base-core (>= 4.0.4-1~bustercran.0) but
> |  3.5.2-1 is to be installed|  
> | Depends: r-api-4.0 which is a virtual package and is
> | not provided by any available package|  
> |  r-base : Depends: r-base-core (>= 4.0.4-1~bustercran.0) but 3.5.2-1 is to
> |  be installed r-recommended : Depends: r-base-core (>=
> |  4.0.4-1~bustercran.0) but 3.5.2-1 is to be installed r-base-dev :
> |  Depends: r-base-core (>= 4.0.4-1~bustercran.0) but 3.5.2-1 is to be
> |  installed| 
> | The following actions will resolve these dependencies:
> |  Keep the following packages at their current version:
> | 1) r-base [Not Installed]
> | 2) r-base-dev [Not Installed]
> | 3) r-cran-boot [Not Installed]
> | 4) r-cran-codetools [Not Installed]
> | 5) r-recommended [Not Installed]
> | 
> |  Leave the following dependencies unresolved:
> | 6) r-base-core recommends r-recommended
> | 7) r-base-core recommends r-base-dev
> | 
> | I assume that I have some part of R 3.5.? stuck in the apt system from
> | previously installing R from the default raspian repositories (stupid of
> | me).  There is nothing in /usr/lib/R (no directory) nor does /usr/bin/R
> | exist and I have (in desperation: not something I remember doing often
> | with Debian machines) even rebooted the machine but no change.
> | 
> | I could wipe the machine and start over and not install R until after
> | adding the buster line deb http://cloud.r-project.org/bin/linux/debian
> | buster-cran40/
> | to /etc/apt/sources.list and doing apt-get update
> | 
> | However, I thought I'd check things out here first. Thanks in advance for
> | any suggestions.
> | 
> | Chris
> | 
> | --
> | Small contribution in our coronavirus rigours:
> | https://www.coresystemtrust.org.uk/home/free-options-to-replace-paper-core
> | -forms-during-the-coronavirus-pandemic/
> | 
> | Chris Evans  Visiting Professor, University of Sheffield
> |  I do some consultation work for the
> | University of Roehampton  and other places| 
> | but  remains my main Email address.  I have a work web 
site at:
> |https://www.psyctc.org/psyctc/
> | 
> | and a site I manage for CORE and CORE system trust at:
> |http://www.coresystemtrust.org.uk/
> | 
> | I have "semigrated" to France, see:
> |https://www.psyctc.org/pelerinage2016/semigrating-to-france/
> |https://www.psyctc.org/pelerinage2016/register-to-get-updates-from-pele
> |rinage2016/| 
> | If you want an Emeeting, I am trying to keep them to Thursdays and my 
diary is at:
> |https://www.psyctc.org/pelerinage2016/ceworkdiary/
> | 
> | Beware: French time, generally an hour ahead of UK.
> | 
> | ___
> | 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] Solution to apt-key depreciation

[Johannes Ranke]

Hi all,

thanks for thoughts and valuable information on this issue. I think it will 
not make the CRAN repositories any safer to use. But I believe it will 
increase security of Debian/Ubuntu repositories in general.

As bullseye will still contain apt-key and Debians release cycle is a bit more 
relaxed, I can still afford to sit back for a while and watch...

Greetings,

Johannes

Am Mittwoch, 17. März 2021, 16:52:17 CET schrieb Carl Delfin:
> Michael,
> 
> Sounds great!
> 
> If it's any help, I put my solution in a bash script:
> 
> #!/bin/bash
> KEY=/usr/local/share/keyrings/marutter.key
> 
> if [ -f "$KEY" ]; then
>   echo "$KEY already exists"
>   sudo apt install -y r-base
> else
>   wget -q -O marutter.key
> "https://keyserver.ubuntu.com/pks/lookup?op=get=0xe298a3a825c0d65dfd
> 57cbb651716619e084dab9" if ! file marutter.key | grep -q "PGP public key";
> then
> echo "marutter.key does not appear to be a valid PGP key - aborting!"
> exit 1
>   else
> sudo mkdir -p /usr/local/share/keyrings/
> sudo mv marutter.key /usr/local/share/keyrings/
> echo "deb [signed-by=/usr/local/share/keyrings/marutter.key]
> https://cloud.r-project.org/bin/linux/ubuntu groovy-cran40/" | sudo tee -a
> /etc/apt/sources.list fi
>  sudo apt install -y r-base
> fi
> 
> Nothing fancy by any means, but it works and could perhaps be useful.
> 
> Cheers,
> Carl
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Wednesday, March 17th, 2021 at 16:04, Michael Rutter  
wrote:
> > On 3/17/21 7:27 AM, Carl Delfin wrote:
> > > Hi everyone,
> > > 
> > > Since apt-key will be deprecated in future releases of Debian
> > > (https://manpages.debian.org/testing/apt/apt-key.8.en.html), I recently
> > > got around to figuring out how to properly import Michael Rutter's key,
> > > based on this answer over at askubuntu:
> > > https://askubuntu.com/a/1307181.
> > > 
> > > Perhaps something along those lines should be added to the README at
> > > https://cran.r-project.org/bin/linux/ubuntu/fullREADME.html?
> > > 
> > > Cheers,
> > > 
> > > Carl
> > 
> > Carl,
> > 
> > Thank you. I need to read these posts over to see if the instructions
> > 
> > can be condensed, but this is very helpful.
> > 
> > Michael
> > 
> > > Sent with ProtonMail Secure Email.
> > > 
> > > [[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
> 
> ___
> 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

[R-sig-Debian] Fwd: Accepted mgcv 1.8-32-1 (source) into unstable

[Johannes Ranke]

Hi Dirk, hi all,

--  Weitergeleitete Nachricht  --

Betreff: Accepted mgcv 1.8-32-1 (source) into unstable
Datum: Donnerstag, 20. August 2020, 18:06:49 CEST
Von: Debian FTP Masters 
An: debian-devel-chan...@lists.debian.org

Format: 1.8
Date: Thu, 20 Aug 2020 10:41:33 -0500
Source: mgcv
Architecture: source
Version: 1.8-32-1
Distribution: unstable
Urgency: medium
Maintainer: Dirk Eddelbuettel 
Changed-By: Dirk Eddelbuettel 
Changes:
 mgcv (1.8-32-1) unstable; urgency=medium
 .
   * New upstream release
 .
   * debian/control: Set Build-Depends: to current R version

---snip---

This message reminded me that I never got the point of why the adaptation of 
the build dependency is necessary or beneficial for these uploads of CRAN 
packages to unstable. Shouldn't they build on older R versions as well, as 
demonstrated by the CRAN checks?

Johannes

---snip---


   * debian/compat: Set to 10
Checksums-Sha1:
 619c126c771e3c1337decea91f037d404a3a8e5c 1827 mgcv_1.8-32-1.dsc
 4f87f2900c1092b0a2eda5a37737fd19047f72e9 1004383 mgcv_1.8-32.orig.tar.gz
 59f093b52f8e7a1d1a36d919d3bdb6e2ad3b0846 5288 mgcv_1.8-32-1.debian.tar.xz
 8e09118b723d73c0abe987f6c7d2e83fac0f55c2 8551 mgcv_1.8-32-1_amd64.buildinfo
Checksums-Sha256:
 ddc3ee3d75f875baf42f6ab54bbda228be3bdf419af283779f282f658cb5c93b 1827 
mgcv_1.8-32-1.dsc
 6ff5d1d43a3ecbb1b772b57c06dc9b386c9cd698d032138c19f3bd3ab9a5a9a0 1004383 
mgcv_1.8-32.orig.tar.gz
 d6d0c8de54826abda31b1916539d52f60360a459b3c43ef092e86594813576d0 5288 
mgcv_1.8-32-1.debian.tar.xz
 a3c6e2462aecf4c12235469329757d7bc065ca0ee2111324d457eecf132f762e 8551 
mgcv_1.8-32-1_amd64.buildinfo
Files:
 c46d192efeb568757be0ef7d2b669799 1827 gnu-r optional mgcv_1.8-32-1.dsc
 4cdeac6b8161cf7f6cd885f8ea2a0672 1004383 gnu-r optional 
mgcv_1.8-32.orig.tar.gz
 46283d86194e7e4c609442747470278d 5288 gnu-r optional 
mgcv_1.8-32-1.debian.tar.xz
 af2b412d8c0b8c38d36b59d47fccb436 8551 gnu-r optional 
mgcv_1.8-32-1_amd64.buildinfo

___
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] How to install libisl.so.19 on chromebook?

[Johannes Ranke]

Am Dienstag, 14. Juli 2020, 13:57:01 CEST schrieb Luigi Marongiu:
> I don't know about the configuration. I installed R using the standard
> protocol for Chromebook
> http://blog.sellorm.com/2018/12/20/installing-r-and-rstudio-on-a-chromebook/

Hi Luigi,

I would not call this a standard protocol. I would say, it is a 1.5 year old 
blog telling you how to use a beta feature (at the time of writing) of 
ChromeOS to install R and RStudio on ChromeOS.

This would have been interesting to know the last time you had a question for 
this mailing list. On 27 May you mentioned that you are using this line

  deb http://cloud.r-project.org/bin/linux/debian buster-cran40/

In the blog, it is suggested that the Linux distribution that the Chromebook 
runs is Debian stretch. If your Chrombook runs Debian stretch, you need to use 
a backport for stretch, not for buster. However, I am currently not providing 
R 4 packages for stretch, as I do not run stretch systems any more.

What is the output of lsb_release -a on your system?

Johannes


> the rest, it was done by the system itself...
> 
> On Tue, Jul 14, 2020 at 1:30 PM Dirk Eddelbuettel  wrote:
> > There is something wrong with your system / setup I did not notice first:
> > 
> > On 14 July 2020 at 13:08, Luigi Marongiu wrote:
> > | Thank you, it looks like I have already libisl:
> > | ```
> > | apt search libisl
> > | Sorting... Done
> > | Full Text Search... Done
> > | libisl-dbg/oldstable 0.18-1 amd64
> > | 
> > |   manipulating sets and relations of integer points bounded by linear
> > | 
> > | constraints
> > | 
> > | libisl-dev/oldstable 0.18-1 amd64
> > | 
> > |   manipulating sets and relations of integer points bounded by linear
> > | 
> > | constraints
> > | 
> > | libisl15/oldstable,now 0.18-1 amd64 [installed,automatic]
> > | 
> > |   manipulating sets and relations of integer points bounded by linear
> > | 
> > | constraints
> > | 
> > | libisl19/now 0.19-1 amd64 [installed,local]
> > | 
> > |   manipulating sets and relations of integer points bounded by linear
> > | 
> > | constraints
> > | ```
> > | thus the problem must be with the installation step: I should tell the
> > | compiler to look for libisl19 instead of  libisl.so.19...
> > | 
> > | On Tue, Jul 14, 2020 at 12:54 PM Dirk Eddelbuettel  
wrote:
> > | > On 14 July 2020 at 12:26, Luigi Marongiu wrote:
> > | > | I am trying to install minpack.lm on R 3.3.3 (Debian version) on a
> > | > | Chromebook. But I get this error:
> > | > | ```
> > | > | 
> > | > | > install.packages("minpack.lm")
> > | > | 
> > | > | Installing package into
> > | > | ‘/home/marongiuluigi/R/x86_64-pc-linux-gnu-library/3.3’ (as ‘lib’
> > | > | is unspecified)
> > | > | trying URL
> > | > | 'https://cran.rstudio.com/src/contrib/minpack.lm_1.2-1.tar.gz'
> > | > | Content type 'application/x-gzip' length 43029 bytes (42 KB)
> > | > | ==
> > | > | downloaded 42 KB
> > | > | 
> > | > | * installing *source* package ‘minpack.lm’ ...
> > | > | ** package ‘minpack.lm’ successfully unpacked and MD5 sums checked
> > | > | ** libs
> > | > | gfortran   -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-3.3.3=.
> > | > | -fstack-protector-strong  -c chkder.f -o chkder.o
> > | > | /usr/local/libexec/gcc/x86_64-cros-linux-gnu/8.3.0/f951: error while
> > 
> > Why is gfortran calling into /usr/local?
> > 
> > You are outside of the package management system here.  Can you not use
> > the
> > package gfortran (and gcc, g++, ...) because ...
> > 
> > | > | loading shared libraries: libisl.so.19: cannot open shared object
> > | > | file: No such file or directory
> > | > | /usr/lib/R/etc/Makeconf:155: recipe for target 'chkder.o' failed
> > 
> > ... you are trying the packaged R.
> > 
> > Dirk
> > 
> > | > | make: *** [chkder.o] Error 1
> > | > | ERROR: compilation failed for package ‘minpack.lm’
> > | > | * removing
> > | > | ‘/home/marongiuluigi/R/x86_64-pc-linux-gnu-library/3.3/minpack.lm’> 
| > | 
> > | > | Warning in install.packages :
> > | > |   installation of package ‘minpack.lm’ had non-zero exit status
> > | > | 
> > | > | ```
> > | > | I tried to install  libisl.so.19 but:
> > | > | ```
> > | > | $ sudo apt-get install libisl.so.19
> > | > | Reading package lists... Done
> > | > | Building dependency tree
> > | > | Reading state information... Done
> > | > | E: Unable to locate package libisl.so.19
> > | > | E: Couldn't find any package by glob 'libisl.so.19'
> > | > | E: Couldn't find any package by regex 'libisl.so.19'
> > | > | ```
> > | > | I downloaded libisl.so.19 for debian, but where shall I place it?
> > | > | Is there an easier way to install this library?
> > | > | Thank you
> > | > 
> > | > That is not the correct package name as it is a _file name_.
> > | > 
> > | > Use eg
> > | > 
> > | >  https://packages.debian.org/
> > | > 
> > | > to search (go to Search the contents of packages) or search directly
> > | > via
> > | > 
> > | >  apt search libisl
> > | > 
> > | > 

Re: [R-sig-Debian] Update on docker Python:3 and adding R:4.x

[Johannes Ranke]

Am Donnerstag, 25. Juni 2020, 05:54:03 CEST schrieb Dirk Eddelbuettel:
> 
>RUN apt update && apt install -y r-base
> 
> instead.  (I also removed the -t buster-cran40 as the 'highest version
> should win'. That may or may not work. Adjust as needed.)

Removing -t buster-cran40 only installs R 4.0.x if there are no packages left 
on the system that depend on the lower r-api-35. Therefore this should be OK 
for a docker image which does not come with R.

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] Update on docker Python:3 and adding R:4.x

[Johannes Ranke]

Am Donnerstag, 25. Juni 2020, 04:52:37 CEST schrieb Dave Lange:
> My dockerfile:
> 
...

> RUN apt update \
> && apt-get install -y --no-install-recommends \
> ca-certificates \
> wget \
> && rm -rf /var/lib/apt/lists/*

Any reason why you remove the contents of /var/lib/apt/lists? On my system, 
this directory holds PGP signed information about each repository, so this may 
well be the reason why later buster-cran40 is said not to be available in the 
sources.

Johannes

> 
> ## Now install R
> ## RUN apt install -t buster-cran40 r-base
> 
> ## CMD ["R"]
> CMD python
> 
> On Wed, Jun 24, 2020 at 4:38 PM Dirk Eddelbuettel  wrote:
> > On 24 June 2020 at 15:15, Dave Lange wrote:
> > |  I continue to receive an error installing R via dockerfile on a buster
> > | 
> > | image python:3.
> > | E: The value 'buster-cran40' is invalid for APT::Default-Release as such
> > 
> > a
> > 
> > | release is not available in the sources
> > 
> > Do you have the Dockerfile in public repo we can look at?
> > 
> > | My starting point is the debian buster based Python:3 image adding a
> > 
> > couple
> > 
> > This is an R list so please tell us more about Python:3. What it is based
> > on?
> > 
> > Hypothetically, could you just start from debian:buster, add python3 and
> > then
> > add the buster-cran40 repo by Johannes?
> > 
> > | of python specific configurations and then using the commands in the R
> > | project documentation for installing R on Buster. I got slightly
> > 
> > different
> > 
> > | answers when I used apt versus apt-get. There were warnings about
> > | unverified sources solved by a reference to the certificate key.
> > 
> > You generally must install a key to validate a repository. This could even
> > be
> > your error.
> > 
> > In any event, this is all "academic". Maybe bring us the famous "MCVE": a
> > minimally complete verifiable example. Otherwise we have simply no idea
> > what
> > you may be doing.
> > 
> > | It turns out building the python container and commenting the R commands
> > | out allowed me to manually step through my dockerfile lines. Its
> > 
> > repeatable
> > 
> > | that the R install fails with the error above when in the dockerfile.
> > | Running the commands manually allows the installation to finish
> > | successfully.  I sense that docker is multithreaded and hits the "use
> > | buster-cran40" before it defines buster-cran40. Manually stepping
> > | through
> > 
> > I doubt that. Docker is very carefully "layered". Each RUN command results
> > in
> > one layer on filesystem. You can build them one by one. There is no
> > concurrency as each subsequent RUN needs / depends upon previous ones.
> > 
> > | the commands keeps the preferred order. At this point I'm happy with a
> > | repeatable process.
> > | 
> > | It sounds like I have been re-inventing the wheel, which has been
> > | educational for me. If someone wants to change my starting point to
> > | something that already has stable/latest production for debian, Python3
> > 
> > and
> > 
> > | R4 and will be updated for the future I would appreciate the head start.
> > 
> > Should be easy. Look at the variety of Dockerfiles is maintain inside the
> > Rocker Project -- while most are based on Debian's testing release you can
> > still look at them (though note that some are also Ubuntu based)
> > 
> > You could start at  https://github.com/rocker-org/rocker  but also look at
> > other repositories in the same org at GH.
> > 
> > Dirk
> > 
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
>   [[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] Docker build issue

[Johannes Ranke]

Am Montag, 22. Juni 2020, 20:06:18 CEST schrieb Dirk Eddelbuettel:
> On 22 June 2020 at 19:37, Johannes Ranke wrote:
> | sorry, I do not understand half of this, as I do not use docker myself.
...
> 
> This is getting off topic here. In essence Dave just needs a patient Docker
> tutor.  

or maybe using conventional installations may be less complex, ironically...

Johannes

> Sadly I don't have time for that right now -- sorry!


> 
> 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] Docker build issue

[Johannes Ranke]

Hi Dave and Dirk,

sorry, I do not understand half of this, as I do not use docker myself. Buf if 
Dirk does not use Debian buster as the basis for his Rocker container, then 
you should probably not try to install the backport to buster. Shouldn't these 
docker containers be there to avoid the need to install R?

Johannes

Am Montag, 22. Juni 2020, 19:15:56 CEST schrieb Dirk Eddelbuettel:
> Dave,
> 
> That's partial information for so hard to work with. One nice aspects about
> Docker is that if something complex fails, you can try something simpler.
> You appear to have made some assumptions here as to whether you could pile
> our instructions top on an existing python3 container---and "that depends".
> Your error messages indicate 'buster' as a release, which is not what I use
> in for the Rocker r-base container.  So you can't just copy and paste. You
> could however look at Johannes backport to buster, add its repo into to
> your Docker setup and build that.  And you can test that step by step. 
> Good luck!
> 
> Cheers, 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] installation problem for R 4.0 on Debian buster

[Johannes Ranke]

Am Freitag, 5. Juni 2020, 20:04:48 CEST schrieb Dirk Eddelbuettel:
> On 5 June 2020 at 08:52, Johannes Ranke wrote:
> | Hi Mark,
> | 
> | Am Freitag, 5. Juni 2020, 00:31:34 CEST schrieb Mark van der Loo:
> | > Hi all,
> | > 
> | > I just spun up a fresh Debian Buster instance, then I added:
> | > 
> | > deb http://cloud.r-project.org/bin/linux/debian buster-cran40/
> | > 
> | > to /etc/apt/sources.list. I also ran the apt-key command as described
> | > here:
> | > https://cran.r-project.org/bin/linux/debian/#secure-apt
> | > 
> | > So far so good,
> | 
> | OK, then you need to keep reading. Instead of simply installing R 4.0.0
> | you
> | need to remove the packages depending on r-api-35 as detailed in

Sorry Mark, it was me who did not read as much as I should - you are on a 
fresh buster system, so no need to remove r-api-35 packages...

Also, I think I have run into the same problem (r-recommended uninstallable) 
when checking the situation on buster in a chroot.

> | https://cran.r-project.org/bin/linux/debian/#debian-bullseye-testing
> | 
> | The reason is that the backported r-cran-* packages have a lower version
> | number than the r-cran-* packages in the Debian archive, but the packages
> | in the Debian archive depend on r-api-35 while the new backport provides
> | r- api-40.
> 
> That sounds ... suboptimal. And I am not sure I understand why that would
> be. Can you explain?  Are they behind a version?  If so, why?

OK, for buster I updated the backports of the recommended packages. I think 
things are fine now (pending CRAN syncs), i.e. the backport to buster including 
the recommended packages should be installable using

apt install -t buster-cran40 r-base

If you have buster packages depending on r-api-35 installed, these will be 
removed by the above command (just tested in my buster chroot).

Cheers,

Johannes

> Also, apt-pinning can help here.  You can give a repo a higher-than-default
> priority. Maybe that would be applicable here?
> 
> Dirk
> 
> | Also, you will need to rebuild all locally installed packages as detailed
> | on the CRAN Debian page.
> | 
> | Greetings,
> | 
> | Johannes
> | 
> | > now when I do the following, I get no joy:
> | > 
> | > $ sudo apt-get install r-base
> | > 
> | > Reading package lists... Done
> | > Building dependency tree
> | > Reading state information... Done
> | > Some packages could not be installed. This may mean that you have
> | > requested an impossible situation or if you are using the unstable
> | > distribution that some required packages have not yet been created
> | > or been moved out of Incoming.
> | > The following information may help to resolve the situation:
> | > 
> | > The following packages have unmet dependencies:
> | >  r-base : Depends: r-recommended (= 4.0.0-1~bustercran.0) but it is not
> | > 
> | > going to be installed
> | > E: Unable to correct problems, you have held broken packages.
> | > 
> | > 
> | > However, when I use the buster-cran-35 deb line, all works fine. So
> | > there
> | > seems to be something going on with buster-cran-40. Is this correct, or
> | > am
> | > I missing something?
> | > 
> | > Thanks,
> | > Mark
> | > 
> | >   [[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

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

Re: [R-sig-Debian] installation problem for R 4.0 on Debian buster

[Johannes Ranke]

Hey Dirk,

Am Freitag, 5. Juni 2020, 20:07:22 CEST schrieb Dirk Eddelbuettel:
> Johannes,
> 
> Also, the page is an edit behind. The Debian transition for R 4.0.0 ended;
> and the R package 4.0.0-3 is in testing as are all packages using r-api-4.0.

yes, absolutely, thanks for the hint! The backport of R 4.0.0 for bullseye is 
not needed any more. I just updated the page, so it will by synced to CRAN 
soon.

Cheers,

Johannes

> 
> 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] installation problem for R 4.0 on Debian buster

[Johannes Ranke]

Hi Mark,

Am Freitag, 5. Juni 2020, 00:31:34 CEST schrieb Mark van der Loo:
> Hi all,
> 
> I just spun up a fresh Debian Buster instance, then I added:
> 
> deb http://cloud.r-project.org/bin/linux/debian buster-cran40/
> 
> to /etc/apt/sources.list. I also ran the apt-key command as described here:
> https://cran.r-project.org/bin/linux/debian/#secure-apt
> 
> So far so good, 

OK, then you need to keep reading. Instead of simply installing R 4.0.0 you 
need to remove the packages depending on r-api-35 as detailed in

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

The reason is that the backported r-cran-* packages have a lower version 
number than the r-cran-* packages in the Debian archive, but the packages in 
the Debian archive depend on r-api-35 while the new backport provides r-
api-40.

Also, you will need to rebuild all locally installed packages as detailed on 
the CRAN Debian page.

Greetings,

Johannes 

> now when I do the following, I get no joy:
> 
> $ sudo apt-get install r-base
> 
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  r-base : Depends: r-recommended (= 4.0.0-1~bustercran.0) but it is not
> going to be installed
> E: Unable to correct problems, you have held broken packages.
> 
> 
> However, when I use the buster-cran-35 deb line, all works fine. So there
> seems to be something going on with buster-cran-40. Is this correct, or am
> I missing something?
> 
> Thanks,
> Mark
> 
>   [[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] HTML help files missing for some packages

[Johannes Ranke]

Hi Paul

$ sudo apt-file search /usr/lib/R/library/base/html/00Index.html

tells me that this file is in r-base-html.

do you have that package installed? r-base recommends r-base-html, but it does 
not depend on it.

Installing recommended packages is the default on Debian systems, in contrast 
to suggested packages. You can check what you have using

$ apt-config dump | grep Recommends
APT::Install-Recommends "1";

Kind regards,

Johannes


Am Freitag, 29. Mai 2020, 05:51:06 CEST schrieb Paul Dunmore:
> After a clean install of R 4.0.0 (R-base only) on Mint 19.3, the
> directory /usr/lib/R/library/base/html is empty. However, the directory
> /usr/lib/R/library/boot/html contains files 00Index.html and R.css.
> 
> Correspondingly, the command help(package="base", help_type="html")
> produces the text "No package index found for package base". The same
> occurs when clicking on the "Index" link at the bottom of help pages for
> functions in this package. The command help(package="boot",
> help_type="html") displays the documentation index for the boot package,
> as expected.
> 
> The 00Index.html and R.css files are missing also for the compiler,
> datasets, graphics, grDevices, grid, methods, parallel, splines, stats,
> stats4, tcltk, tools, utils packages, but are present for all other
> packages in the base distribution.
> 
> Can anyone else reproduce this, or is it some peculiarity of my setup or
> of Linux Mint?
> 
> Cheers, Paul
> 
> ___
> 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] Install R 4 on Chromebook (unmet dependencies)

[Johannes Ranke]

Hi,

I assume you are running Debian stable on this chromebook (True?). What's the 
architecture you are using (like amd64 or arm64, you can see it in the output 
of uname -a). I have stopped providing binaries for arm architectures, as I am 
not using them. You could build R 4.0.0 packages from source, though...

If you were on a supported architecture, you would need to use -t buster-
cran40 for apt install, as mentioned in the Debian page on CRAN.

Kind regards,

Johannes

Am Mittwoch, 27. Mai 2020, 08:05:23 CEST schrieb Luigi Marongiu:
> Hello,
> I have tried to upgrade R to 4.0. I have added `deb
> http://cloud.r-project.org/bin/linux/debian buster-cran40/` to
> `/etc/apt/sources.list` (but I removed cran35). Btu when I run
> `apt-get update; apt-get install r-base r-base-dev` I get an error. I
> think it depends on r-base-core, since it depends on these obsolete
> libraries:
> ```
> $ sudo apt-get install r-base-core
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  r-base-core : Depends: libc6 (>= 2.27) but 2.24-11+deb9u4 is to be
> installed Depends: libcurl4 (>= 7.28.0) but it is not installable Depends:
> libgfortran5 (>= 8) but it is not installable Depends: libicu63 (>=
> 63.1-1~) but it is not installable Depends: libpcre2-8-0 (>= 10.32) but it
> is not going to be installed
>Recommends: r-recommended but it is not going to be installed
> Recommends: r-base-dev but it is not going to be installed Recommends:
> r-doc-html but it is not going to be installed E: Unable to correct
> problems, you have held broken packages.
> ```
> How can I upgrade these libraries on Chromebook?
> 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

[R-sig-Debian] Fwd: RKWard and R 4.0.0 - Important bug and workaround

[Johannes Ranke]

Dear all,

as I am providing rkward backports for Debian testing and stable on CRAN, I am 
forwarding this notice by the main developer.

Meanwhile, it has been communicated that R 4.0.1 will be released on June 6.

Cheers,

Johannes


--  Weitergeleitete Nachricht  --

Betreff: RKWard and R 4.0.0 - Important bug and workaround
Datum: Sonntag, 24. Mai 2020, 10:14:17 CEST
Von: Thomas Friedrichsmeier 
An: rkward-de...@kde.org , rkward-us...@kde.org

Hi!

This is a note of caution about using RKWard with R 4.0.0:

-- Problem --

There is a bug in R 4.0.0 with respect to active bindings, which RKWard
is relatively likely to trigger. Running the following code *twice*
will render your RKWard session unusable, and **could result in
loss of data**:

  for (i in 1:2) { print (i) }

Note that this affects top-level statements, only, i.e. in general code
that you enter in the console of run from a script, directly. Not code
in packages or RKWard plugins.

-- Workaround --

If you have the choice, please delay upgrading R until R 4.0.1 is
released.

If you have already installed R 4.0.0, you should set the option

  compiler::enableJIT(2)  # or a lower value

in each session. This can also be made permanent by copying it into
the field "Futher option commands to run in each session" in
Settings->Configure RKWard->R-Backend.

-- Outlook --

The bug has been fixed in R devel, but no release date has been set to
R 4.0.1, yet. I will probably create a "bugfix"-release that enables
the above workaround by default in the coming day. Meanwhile I have
started working on a new approach to object modification detection that
does not rely on active bindings.

Regards
Thomas

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

Re: [R-sig-Debian] Sometimes commands do not terminate after upgrading to R 4.0 and Ubuntu 20.04

[Johannes Ranke]

Am Mittwoch, 13. Mai 2020, 14:19:07 CEST schrieb Adrien FABRE:
> I have upgraded R (from 3.6 to 4.0) and RStudio (from 1.1 to 1.2.5) a few
> days ago, and Ubuntu from 18.04 to 20.04 yesterday.
> 
> Since then, R sometimes never terminates when executing certain commands:

...

> install the packages in a personal library: none works. So I think the
> problem comes from Ubuntu 20.04, and is related to this post:
> https://stat.ethz.ch/pipermail/r-sig-debian/2020-April/003166.html.

...

Did you try 

sudo update-alternatives --config libblas.so.3-x86_64-linux-gnu

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

[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] Timezone conversion on Ubuntu 20.04

[Johannes Ranke]

Am Samstag, 25. April 2020, 01:02:38 CEST schrieb Jeroen Ooms:
> Hi all,
> 
> I am testing R 4.0 and ran into an issue with timezones on Ubuntu
> Focal: converting a timestamp to another timezone results in NA:
> 
>   as.POSIXct(as.POSIXlt(Sys.time(), tz = "CET"), tz = "EST")
> 
> This only happens on Ubuntu Focal, it seems to work fine on Ubuntu
> Bionic. I am the standard ubuntu docker image icw/ r-base from Dirk's
> ppa:edd/r-4.0 on both systems.

works fine using the backported R 4.0.0 on Debian buster:

R> as.POSIXct(as.POSIXlt(Sys.time(), tz = "CET"), tz = "EST")
[1] "2020-04-25 10:05:29 EST"

Johannes

> 
> Am I missing a system dependency for tzone data?
> 
> Jeroen
> 
> ___
> 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

[R-sig-Debian] R 4.0.0 for bullseye and buster

[Johannes Ranke]

Dear all,

I set up new repositories on CRAN for R 4.0.0 and the recommended packages. As 
the transition will probably still take a while, I also created a repo for 
bullseye. If you would like to use R 4.0.0 from these repos, you first need to 
remove r-base-core which will remove all the Debian packaged extensions, then 
install r-base and update your locally installed packages as described here

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

I am not currently supporting R 4.0.0 on stretch, as I am not using it. Let me 
know if you need it.

Kind regards,

Johannes

P.S.: I forgot to update the repo line for buster at first, the fix is on its 
way. It has to be buster-cran40 of course.

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

Re: [R-sig-Debian] 3.6 on debian stretch

[Johannes Ranke]

Dear Larry,

yes, because of various factors the r-cran-* packages from the stable and 
especially the oldstable distribution are often not compatible with the 
backported r-base packages provided on CRAN. At current, buster is not 
affected, but your case shows that using stretch gives this problem.

In principle it would be nice to have a repo containing all the r-cran-* and 
r-bioc-* packages recompiled for these backports. Such a repository does exist 
for Ubuntu as far as I know (I don't use it). For Debian, such a repository 
currently does not exist.

In your situation, I think the easiest solution is to simply install caret and 
ggplot2 from within R.

Personally, I like the install.r and update.r scripts available from Dirks 
littler package. They make it possible to conveniently install and update R 
packages from source using the command line, if you have the scripts in your 
PATH.

Kind regards,

Johannes

Am Mittwoch, 31. Juli 2019, 21:41:14 CEST schrieb Larry Martell:
> I need to run 3.6 on debian stretch - I followed the instructions here:
> 
> https://cran.r-project.org/bin/linux/debian/
> 
> and I was able to install it. But 2 packages I need,  r-cran-caret and
> r-cran-ggplot2 will not install:
> 
> # apt-get install r-cran-ggplot2
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  r-cran-ggplot2 : Depends: r-api-3
>   Depends: r-cran-digest but it is not going to be installed
> Depends: r-cran-gtable (>= 0.1.1) but it is not
> going to be installed
>   Depends: r-cran-plyr (>= 1.7.1) but it is not going
> to be installed
>   Depends: r-cran-reshape2 but it is not going to be
> installed Depends: r-cran-scales (>= 0.4.1) but it is not
> going to be installed
>   Depends: r-cran-tibble but it is not going to be installed
> Depends: r-cran-lazyeval but it is not going to be installed E: Unable to
> correct problems, you have held broken packages.
> 
> Is there a way to get these 2 packages for my environment?
> 
> Thanks!
> 
> ___
> 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]

> 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

[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

[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

[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

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

[Johannes Ranke]

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

Re: [R-sig-Debian] Most recent version R for IBM Power8 Ubuntu environment

[Johannes Ranke]

Hi all,

Am Dienstag, 26. Februar 2019, 09:06:49 CET schrieb Dirk Eddelbuettel:
> Bill,
> 
> On 21 February 2019 at 15:14, Bill Glessner wrote:
> | What is he most recent version of R known to run reliably in an
> | environment of IBM HPC cluster Power8 systems, Ubuntu 16.04.1 operating
> | environment with gpfs as the cluster file-system? It would seem from
> | 'apt' checking to be R-3.2.3; however, that one is rather old and does
> | not support a sufficient number of R packages that are needed for current
> | university research projects. R-3.5.1 has been built from source on the
> | IBM HPC cluster and passed its 'make check' without incident; but, when
> | actual project work began, it did not complete and issued console
> | messages indicating R task timeouts.
> Ubuntu proper may support Power8. That would provide whatever version of R
> was current when the particular Ubuntu release was made.  Ubuntu 16.04 is
> outdated, with Ubuntu 18.04 you would (IIRC) get R 3.4.4.
> 
> What is at CRAN as backports is provided by volunteers on shoestring
> budgets. Hence almost everything you see there is for x86_64. (Johannes
> backports Debian builds to arm as well as he has need for it).
> 
> So for Power8 help ... we can help with tips but I fear you may have to
> spearhead.  The good news is that it should not be hard.

I'd like to add that you should rebuild your R packages after upgrading from R 
3.2.3 to R 3.5.1 because of changes in base R.

Kind regards,

Johannes

> 
> Hth, Dirk

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] Cross compile R for ARM target

[Johannes Ranke]

Hi,

you can find the packages here

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

Kind regards,

Johannes

Am Sonntag, 17. Februar 2019, 13:28:20 CET schrieb Samir Mouhoune:
> Hi Johannes,
> 
> Thank you  for your quick feddback.
> 
> As I am using linux os build with buildroot on my raspberry pi I can't use
> package manager such as apt-get  to install R.
> 
> What I need to do is to get the precompiled R for arm arch and then when I
> build my linux  image using buildroot I include  the R precompiled package
> to my rootfs.
> 
> Could you please send me a link where I can download directly the
> precompiled R for arm without using apt-get install?
> 
> 
> Thanks again for your support
> 
> Best Regards,
> 
> 
> Samir MOUHOUNE
> Senior Principal Embedded Linux Engineer
> Technical R product manager
> 
> 
> OSMOS Group
> 37, rue la perouse
> 75116 PARIS
> 
> Tél: +331 70 23 97 45 - Fax: +331 71 39 85 14
> www.osmos-group.com
> ____
> De : R-SIG-Debian [r-sig-debian-boun...@r-project.org] de la part de
> Johannes Ranke [jra...@uni-bremen.de] Envoyé : dimanche 17 février 2019
> 12:01
> À : r-sig-debian@r-project.org
> Objet : Re: [R-sig-Debian] Cross compile R for ARM target
> 
> Hi Sami
> I do publish ports of the latest R releases for arm64 on CRAN. Not sure what
> you mean by R dev, but if you are looking for R 3.5.2 on Debian, you can
> install that using the instructions on CRAN
> 
>   https://cran.r-project.org/bin/linux/debian/
> 
> Disclaimer: I have no experience with cross compilation, buildroot or Yocto.
> I just build R on the raspi 3 running Debian stable.
> 
> Kind regards,
> 
> Johannes
> 
> Am Sonntag, 17. Februar 2019, 10:40:26 CET schrieb Samir Mouhoune:
> > Dear all,
> > 
> > I am currently trying to cross compile R3.5.2  using X86 host  and  trying
> > to cross compile for ARM target (raspberry pi 3 running on  linux system
> > generated  by buildroot).
> > 
> > The problem I am encountering is that the compilation fails because  the
> > current R buildsystem  I trying to execute the R binary generated for Arm
> > arch on the  host X86  computer.
> > 
> > My question is:   Is there  an  R branch supporting cross compilation for
> > ARM target?
> > 
> > Otherwise,  is there pre compiled R dev that I can install on an ARM
> > architecture?
> > 
> > My last question,  can we build R using buildroot or Yocto?  If yes could
> > you send me a link to yocto or buildroot branch allowing to build R?
> > 
> > Thank's in advance for your support
> > 
> > Best Regards,
> > 
> > 
> > Samir MOUHOUNE
> > Senior Principal Embedded Linux Engineer
> > Technical R product manager
> > 
> > 
> > OSMOS Group
> > 37, rue la perouse
> > 75116 PARIS
> > 
> > Tél: +331 70 23 97 45 - Fax: +331 71 39 85 14
> > www.osmos-group.com
> > ___
> > 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
> 
> ___
> 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] Cross compile R for ARM target

[Johannes Ranke]

Hi Samir,

I do publish ports of the latest R releases for arm64 on CRAN. Not sure what 
you mean by R dev, but if you are looking for R 3.5.2 on Debian, you can 
install that using the instructions on CRAN

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

Disclaimer: I have no experience with cross compilation, buildroot or Yocto. I 
just build R on the raspi 3 running Debian stable.

Kind regards,

Johannes

Am Sonntag, 17. Februar 2019, 10:40:26 CET schrieb Samir Mouhoune:
> Dear all,
> 
> I am currently trying to cross compile R3.5.2  using X86 host  and  trying
> to cross compile for ARM target (raspberry pi 3 running on  linux system
> generated  by buildroot).
> 
> The problem I am encountering is that the compilation fails because  the
> current R buildsystem  I trying to execute the R binary generated for Arm
> arch on the  host X86  computer.
> 
> My question is:   Is there  an  R branch supporting cross compilation for
> ARM target?
> 
> Otherwise,  is there pre compiled R dev that I can install on an ARM
> architecture?
> 
> My last question,  can we build R using buildroot or Yocto?  If yes could
> you send me a link to yocto or buildroot branch allowing to build R?
> 
> Thank's in advance for your support
> 
> Best Regards,
> 
> 
> Samir MOUHOUNE
> Senior Principal Embedded Linux Engineer
> Technical R product manager
> 
> 
> OSMOS Group
> 37, rue la perouse
> 75116 PARIS
> 
> Tél: +331 70 23 97 45 - Fax: +331 71 39 85 14
> www.osmos-group.com
> ___
> 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] Update RKWard to> = 0.7.0

[Johannes Ranke]

Hi Griera,

thanks for your report - I do not use rkward, so I did not notice that for 
some reason my backporting script failed to download the latest rkward 
version. I need to do apt-get source -t unstable instead of just apt-get 
source to get the current rkward source package from unstable.

rkward 0.7 packages for i386 and amd64 are uploaded and will be synchronized 
to CRAN within a day or so. I have quickly confirmed that they work with the R 
3.5.2 backports.

Cheers,

Johannes



Am Dienstag, 29. Januar 2019, 09:00:24 CET schrieb gri...@yandex.com:
> Hello:
> 
> I just upgraded my Debian Stretch to version 3.5 by following the
> instructions here:
> 
> https://cran.r-project.org/bin/linux/debian/stretch-cran34/
> 
> Then I have updated as root the R from inside with:
> update.packages(.libPaths()[1], ask = F, checkBuilt=TRUE, dependencies = F,
> repos = "http://mirror.ibcp.fr/pub/CRAN/;)
> 
> When finalizing the update of the R, I execute
> RKWard and I get the error: "unable to initialize the JIT"
> 
> The crash can be reproduced every time. The problem is that version R 3.5
> needs RKWard> = 0.7.0 according to:
> 
> https://bugs.kde.org/show_bug.cgi?id=403706
> 
> Is it possible to update the RKWard
> https://cran.r-project.org/bin/linux/debian/stretch-cran35/ to version
> 0.7.0?
> 
> My respect and gratitude for the R Debian repositories. Thank you. Griera
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
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] So nearly there, but can't install rJava

[Johannes Ranke]

Hi Chris,

> I think the problem may be options setting where R/rJava will look for Java 
so I tried:
> > options(java.home="/usr/lib/jvm/java-8-openjdk-amd64/")

This should not be necessary. I would recommend to start a fresh R session in 
order to unset this.

> As far as I can see Debian is happy with the setup of java and javac:
> 
...

> And I have the full jdk not just the headless version I can see the header
> files:
> 
...

> But I can't reconfigure R for Java:
> 
> root@DebianAdvent:/home/chris/Downloads/gmp-6.1.2# R CMD javareconf
> *** JAVA_HOME is not a valid path, ignoring

as above, I would not recommend setting JAVA_HOME manually.

> Java interpreter : /usr/lib/jvm/default-java/jre/bin/java
> /usr/lib/R/bin/javareconf: 1: /usr/lib/R/bin/javareconf:
> /usr/lib/jvm/default-java/jre/bin/java: not found

Obviously this file was not found. Again, apt-file can provide some help (but 
not when giving it the full path, because of the link maintained by update-
alternatives:

  apt-file search jre/bin/java

If you have openjdk-8-jre-headless installed, this file should be there on your 
system. Seems you don't have the jre installed?

...

> Tangential question: surely I'm not rare in running R 3.5.2 on Stretch am I?

I for sure am running it without issues on several computers. On my desktop, I 
am using openjdk-9 from stretch-backports, but on my laptop I just upgraded 
from R 3.4.x to R 3.5.2 using the stretch-cran35 packages on CRAN, and had no 
issues. I could install rJava from within R, and after that R CMD javareconf 
gives me:

Java interpreter : /usr/lib/jvm/default-java/jre/bin/java
Java version : 1.8.0_181
Java home path   : /usr/lib/jvm/default-java
Java compiler: /usr/lib/jvm/default-java/bin/javac
Java headers gen.: /usr/lib/jvm/default-java/bin/javah
Java archive tool: /usr/lib/jvm/default-java/bin/jar

trying to compile and link a JNI program 
detected JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
detected JNI linker flags : -L$(JAVA_HOME)/jre/lib/amd64/server -ljvm
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I/usr/lib/jvm/default-java/
include -I/usr/lib/jvm/default-java/include/linux -fpic  -g -O2 -fdebug-
prefix-map=/home/jranke/git/r-backports/stretch/r-base-3.4.3=. -fstack-
protector-strong -Wformat -Werror=format-security -Wdate-time -
D_FORTIFY_SOURCE=2 -g  -c conftest.c -o conftest.o
gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so conftest.o 
-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm -L/usr/lib/R/lib -lR


JAVA_HOME: /usr/lib/jvm/default-java
Java library path: $(JAVA_HOME)/jre/lib/amd64/server
JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
JNI linker flags : -L$(JAVA_HOME)/jre/lib/amd64/server -ljvm
Updating Java configuration in /usr/lib/R
Done.

> Other tangential question: is there anything that can be done to fix the
> r-api-3/r-api-3.5 issue.  You can see I'm no programmer or sysadmin but if
> there is anything I can do to help ...?

Thanks for the offer. Personally, I am always glad to get some feedback from 
people using the Debian backports on CRAN, so thanks for that. On the other 
hand, I do not think that there is an error to be fixed. Of course it would be 
nice if we could provide more precompiled debs for these backports in order to 
avoid having to install them from sources. For me personally, this is not a 
priority, I am happy if I manage to get the base and recommended packages out 
on new releases.

Johannes

> 
> TIA all,
> 
> Chris
> 
> 
> 
> - Original Message -
> 
> > From: "Dirk Eddelbuettel" 
> > To: "Chris Evans" 
> > Cc: "r-sig-debian" 
> > Sent: Tuesday, 22 January, 2019 12:21:39
> > Subject: Re: [R-sig-Debian] So nearly there, but can't install rJava
> > 
> > On 22 January 2019 at 10:14, Chris Evans wrote:
> >| root@DebianAdvent:/home/chris/Downloads/gmp-6.1.2# apt-get install
> >| openjdk-8-jdk-headless
> >| Reading package lists... Done
> >| Building dependency tree
> >| Reading state information... Done
> >| openjdk-8-jdk-headless is already the newest version
> >| (8u181-b13-2~deb9u1).
> >| openjdk-8-jdk-headless set to manually installed.
> >| 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> >| 
> >| Anyone else got any ideas?
> > 
> > Install the full-blown jdk no just headless.
> > 
> > In the sources for rJava I have as a build-depends
> > 
> >   openjdk-10-jdk
> > 
> > which may of course be a virtual. At some point we had more than JDK
> > implementation.  See what you can find there.
> > 
> > Dirk
> > 
> > --
> > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


-- 
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] So nearly there, but can't install rJava

[Johannes Ranke]

Am Dienstag, 22. Januar 2019, 08:27:14 CET schrieb Chris Evans:
...

> error: jni.h: No such file or directory
> #include 
> ^
> compilation terminated.

You get a complaint that jni.h is missing. So one strategy would be to look 
for this file in the available packages:

  sudo apt-file search jni.h

One of the packages returned is openjdk-8-jdk-headless (which I happen to have 
installed). I think (others will know for certain) that you need a Java 
Development Kit (jdk) not just a runtime environment (jre).

Cheers,

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-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] Still hitting odd problems trying to install R 3.5.2 on Debian amd64 machine

[Johannes Ranke]

Hi Chris,

Am Sonntag, 20. Januar 2019, 19:30:16 CET schrieb Chris Evans:
...

> root@DebianAdvent:/etc/apt# apt-get install drmngr
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package drmngr

That was just a typo.
 
...

> deb http://mirror.mythic-beasts.com/debian/ stretch main contrib non-free
> deb-src http://mirror.mythic-beasts.com/debian/ stretch contrib main
> non-free

Obviously you are running Debian stretch.

...

> deb http://cran.ma.imperial.ac.uk/bin/linux/debian jessie-cran35/
> deb-src http://cran.ma.imperial.ac.uk/bin/linux/debian jessie-cran35/

jessie-cran35 is for Debian jessie, please use stretch-cran35 for stretch.

Good luck!

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] This list elicits spam

[Johannes Ranke]

Hi,

I get the same annoyance, of course with varying text when I post to this 
list. Copying in r-sig-debian-ow...@r-project.org for information.

Johannes

Am Sonntag, 20. Mai 2018, 10:07:17 CEST schrieb Robin Lovelace:
> Unrelated to previous email: every time I send an email to this list I get
> a response such as:
> 
> Hey  Robin Lovelace
> 
> > Thanks for your response. Can I have a pic or two to start talking? Please
> > respond with pics/infos, Hope to hear back from you asap.
> 
> I wonder if others have received such emails and, if so, any suggestions
> how to tackle the spam?
> 
> Robin
> 
>   [[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-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

[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 <e...@debian.org>
> > To: Matthieu S <matthieu.stig...@gmail.com>
> > 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 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] Hash Sum mismatch @ uni-muenster mirror

[Johannes Ranke]

Hi,

I just installed these packages from the Uni Münster mirror 
https://cran.uni-muenster.de/ without errors. Maybe there was an incomplete 
sync yesterday on 
their server?

Johannes

Am Samstag, 17. März 2018, 18:33:17 CET schrieb Benjamin Redling:
> Hello everybody,
> 
> for serveral hours we had "Had Sum mismatch" errors for the following
> packages from the mirror of U of Münster -- r-project works fine as a
> temp. fallback:
> r-cran-cluster 2.0.6-2~stretchcran.0
> r-cran-foreign 0.8.69-1~stretchcran.0
> r-cran-kernsmooth 2.23-15-3~stretchcran.0
> r-cran-class 7.3-14-2~stretchcran.0
> r-cran-nnet 7.3-12-2~stretchcran.0
> r-cran-spatial 7.3-11-2~stretchcran.0
> 
> Regards,
> Benjamin


-- 
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] Debian r-base package

[Johannes Ranke]

Sorry, I was dreaming

> repositories (like jessie-backports) should go to the debian-science list.

to the debian-backports list.

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] Debian r-base package

[Johannes Ranke]

Hi,

requests regarding the backports in the official Debian backport repositories 
(like jessie-backports) should go to the debian-science list.

For stretch, I uploaded a backport of R 3.4.3 including the armhf architecture 
to CRAN

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

but I don't know if you are looking for arm64?

Kind regards,

Johannes



Am Donnerstag, 4. Januar 2018, 08:12:07 CET schrieb Dirk Eddelbuettel:
> Morgan,
> 
> On 4 January 2018 at 15:05, Morgan Morgan wrote:
> | Hi Dirk,
> | 
> | On the website:
> | https://packages.debian.org/jessie-backports/r-base
> 
>   
> 
> | I see that you are the maintainer.
> 
> ... of r-base in Debian, ie unstable / testing / stable. I have nothing to
> do with the backport.  Talk to its maintainer.
> 
> | I was wondering if you know when the version 3.4.3 of R will be available?
> 
> Just like every other release of the last ~ 18 years, I made it available
> ASAP and that is usually within hours.
> 
> | It is currently at version 3.3.3.
> | 
> | I am currently running R 3.3.3 on an android device.
> 
> Those are backport problems.
> 
> My android got stuck updating from jessie to stretch so that I could use
> testing and not have that problem.
> 
> Also note that there is a mailing list r-sig-debian for exactly this type of
> question.  I am CC my reply there, please keep follow-up on the list rather
> than my inbox.
> 
> Best, Dirk
> 
> | Thank you very much
> | Best regards
> | Morgan


-- 
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] Debian backport on Stretch?

[Johannes Ranke]

Am Sonntag, 19. November 2017, 09:06:04 CET schrieb Dirk Eddelbuettel:
> On 19 November 2017 at 19:02, Charles Plessy wrote:
> | Le Sat, Nov 18, 2017 at 03:26:53PM -0800, Bill Harris a écrit :
> | > Incidentally, you can see a bit more complete description at
> | > https://unix.stackexchange.com/questions/402560/how-do-i-install-r-on-de
> | > bian-stretch-given-the-r-api-3-issue .
> | 
> | Hi Bill and everybody,
> | 
> | if one installs R >= 3.4.2 from any source, then some Debian packages
> | will be broken.  The change of r-api virtual dependency prevents this to
> | happen.
> 
> Note that this was a transition forced upon the maintainer (ie me) by a
> group consensus and override. I argued against it as the underlying issue
> was rather minute [1] yet the imposition of the r-api change imposes this
> "omg everything is borked" side effect I consider overkill.
> 
> | Since you install R from CRAN's Debian packages, can't you also upgrade
> | the r-cran-* packages using `apt-get install -t stretch-cran34` as
> | suggested in
> |  ?
> 
> In short, you need matching toolchains. For a given r-base-core package, you
> need the corresponding r-cran-*
> 
> Personally, I don't use these backports. My 'development' work happens where
> Debian is fresh and new ("unstable", and "testing"); my deployments at work
> and elsewhere happens to be on Ubuntu (different story).
> 
> So I cannot speak to the state of these backports as that is a project by
> Johannes outside of the official Debian scope.  He may chime in.

Here I am:

packages fixed in unstable by rebuilding against current R do not propagate to 
stretch and jessie or older Ubuntu distributions.

Therefore, as the backport of R 3.4.2 to Ubuntu still provides r-api-3, I was 
under the impression that the 46 packages that you are listing in the current 
version of your document [1] must be broken in some way when using the current 
R backports on CRAN for Ubuntu. And I thought it is a good thing that they are 
not installable on Debian stretch/jessie when using the CRAN backport 
providing r-api-3.4.

In order to check the relevance of this once again, I selected r-cran-
data.table from your list. However, ironically, this package only uses .C() in 
a comment... So not really affected...

My next try was MCMCpack. Grepping the sources I found lots of calls to .C(), 
e.g. in the function MCMChlogit().

me@box:~/tmp/r-cran-mcmcpack-1.4-0/R$ grep "\.C(" *
...
MCMChlogit.R:  Sample <- .C("cMCMChlogit",
...

However, on Ubuntu Xenial using the backport of R 3.4.2 that still provides r-
api-3, this function works beautifully (against my expectation).

Finally, I tried deSolve as packaged in r-cran-desolve. It uses .C in all many  
of its major functions:

me@box:~/tmp/r-cran-desolve-1.20/R$ grep "\.C(" * 
daspk.R:  on.exit(.C("unlock_solver")) 
euler.R:on.exit(.C("unlock_solver")) 
iteration.R:on.exit(.C("unlock_solver")) 
lsoda.R:  on.exit(.C("unlock_solver")) 
lsodar.R:  on.exit(.C("unlock_solver")) 
lsode.R:  on.exit(.C("unlock_solver")) 
...

But e.g. the function lsode() from the old r-cran-lsode package from Xenial 
(uploaded long before R 3.4.x) works nicely together with the R 3.4.2 
backport. 

This leads me suspect that only calls to .C() (I didn't look at Fortran()) are 
affected that have the names of R objects as first argument, and not quoted 
strings like "unlock_solver". What got the whole issue rolling were the 
function coxph() in package survival [2] that uses internally a call

  coxres <- .C(Ccoxmart, as.integer(n),

and the case that I found myself [3] involving the call 

   z <-  .C(lqs_fitlots,

in package MASS. 

Therefore, in the light of the above, the list of Breaks: that I have pledged 
for [4] could have been even shorter than we thought.

In fact, I am thinking about trying to produce such a shortened list for the 
backport of R 3.4.3 that is scheduled to be released end of this month, to be 
able to switch back to r-api-3 for the CRAN backports to stretch and jessie. 
Thoughts and/or helpful hands appreciated.

I believe the best thing about all this is that we will all be prepared for 
the upcoming change of r-api-* next year.

Cheers,

Johannes

> Dirk
> 
> [1] http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html
[2] https://stat.ethz.ch/pipermail/r-sig-debian/2017-April/002680.html
[3] https://stat.ethz.ch/pipermail/r-sig-debian/2017-April/002683.html
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333#95

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

Re: [R-sig-Debian] Problem when installing lme4 under Debian stretch

[Johannes Ranke]

> the error message you posted). Surely more than five minutes ago my raspi
> started to compile the file fastLm.cpp ...
> 
> I will let you know if I succeed.

It only worked after activating swap.

However, this is not recommended  when using an SD card as file system...

So maybe it would be better to stick to the stretch packages.

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] Problem when installing lme4 under Debian stretch

[Johannes Ranke]

Hi,

apparently you are using the backport of R 3.4.2, which provides r-api-3.4.
With this backport installed, you cannot use the binary packages from the 
stretch archive.

> | The following packages have unmet dependencies:
> |  r-cran-car : Depends: r-api-3
> |  
> |   Depends: r-cran-pbkrtest but it is not going to be installed
> |   Depends: r-cran-quantreg but it is not going to be installed
> | 
> | E: Unable to correct problems, you have held broken packages.
> | 
> | 
> | Given the message, should I assume that lme4 (and car) cannot be installed
> | on my setup?  Many thanks in advance!

You should still be able to install car from within R, which you tried. On my 
raspi system using the unofficial Debian stretch image from 

  https://wiki.debian.org/RaspberryPi3

I had to install ed (apt install ed) in order to get the dependency nloptr to 
compile. Now the compilation of the dependency RcppEigen is running (which 
seems to have failed or was interrupted on your system, judging by the error 
message you posted). Surely more than five minutes ago my raspi started to 
compile the file fastLm.cpp ...

I will let you know if I succeed. But Dirk is right when he points out that 
the efficiency of using such a system to compile lots of source packages is 
questionable. Maybe it would be a solution to deinstall the backport, remove 
the stretch-cran34 line from your sources.list and install everything from the 
stretch archive. R version 3.3.3 from stretch is still sort of recent...

Johannes

> 
> It looks like you may have repos mixed, or they are out of sync.
> 
> The r-base-core you use should provide r-api-3.  Maybe it is newer and it
> offers r-api-3.4 -- which the r-cran-car you try to install does not yet
> depend on.  So the repo may be out of sync.
> 
> If that is the case -- well I was forced to add r-api-3.4 which creates this
> bug "because it would make things better".  I disagreed but was overruled.
> It all depends.
> 
> For what it is worth, on my Ubuntu box on which I type this, both 'apt-cache
> show r-base-core' and 'apt-cache show r-cran-cran' want r-api-3.
> 
> On Debian testing is should match too.  Maybe the Raspian repo you have
> needs to catch up.
> 
> Dirk
> 
> | On Sat, Oct 21, 2017 at 2:22 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
> | > I would start with the _binary_ package you can install via
> | > 
> | >sudo apt-get install r-cran-car
> | > 
> | > which will take care of all dependecies.
> | > 
> | > Building some of these package on small hardware can be challenging
> | > simply
> | > due to lack of RAM --- and ditto for minimal cloud instances with small
> | > RAM
> | > footprint.  Use binaries where you can if you hardware cannot cope.
> | > 
> | > Dirk
> | > 
> | > --
> | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | 
> | [[alternative HTML version deleted]]
> | 
> | ___
> | R-SIG-Debian mailing list
> | R-SIG-Debian@r-project.org
> | https://stat.ethz.ch/mailman/listinfo/r-sig-debian


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

[R-sig-Debian] Binary packages or R 3.4.2 for armhf and arm64 (Debian stretch)

[Johannes Ranke]

Hi,

I would like to announce the immediate avaiability of armhf and arm64 binaries 
of R 3.4.2 for Debian stretch on CRAN. I plan to skip the armel binaries in 
the future, so in case you should use this architecture and rely on the CRAN 
Debian backports, please let me know.

Cheers,

Johannes

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

[R-sig-Debian] R 3.4.2 for Debian on CRAN

[Johannes Ranke]

Dear all,

The backports of R 3.4.2 (providing r-api-3.4) to Debian stretch and Debian 
jessie have just hit CRAN. Should you still have R packages (e.g. r-cran-*) 
from regular Debian jessie/stretch on your system they would be removed if you 
install such a backport.

For some more information, see

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

as usual. Please let me know in case the backport does not work as it should.

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] Please be careful with R 3.4.2 upgrades via CRAN, launchpad, ...

[Johannes Ranke]

Small correction to my previous post:

> As of now (this was obviously going on today), all
> reverse dependencies at level 1 (including the recommended packages) of
> r-api-* have been adapted to depend on r-api-3.4 in unstable.

rpart is not through yet, so r-recommended is AFAICS still not installable in 
unstable.

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] Please be careful with R 3.4.2 upgrades via CRAN, launchpad, ...

[Johannes Ranke]

Am Freitag, 29. September 2017, 22:30:08 CEST schrieb Dirk Eddelbuettel:
> On 30 September 2017 at 04:21, Johannes Ranke wrote:
> | I noticed that rkward, littler, rpy and rpy2 do not depend on r-api-* at
> | all, so they do not get picked up by the transition.
> 
> Why should they?
> 
> There are not R extension packages, ie things one loads via library(...)
> from R.

rkward internally uses at least one R extension package

  https://cgit.kde.org/rkward.git/tree/rkward/rbackend/rpackages/rkward

The other ones you surely know better than me, so I believe there is no action 
needed there.

> 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] Please be careful with R 3.4.2 upgrades via CRAN, launchpad, ...

[Johannes Ranke]

Am Freitag, 29. September 2017, 16:20:37 CEST schrieb Dirk Eddelbuettel:
> On 29 September 2017 at 14:50, Michael Rutter wrote:
> | Corrected packages are now on the RRutter PPA (
> | https://launchpad.net/~marutter/+archive/ubuntu/rrutter) and soon on CRAN
> | mirrors.
> | 
> | If you have any issues or questions, please let me know.
> 
> Nice work--thanks so much for the prompt attention. We should be back in
> business, having overriden the tag to r-api-3. We'll deal with the tag
> transition when we have to for R 3.5.0 and its changes.

Wow, both of you were fast again. Nice indeed.

For the backports of R 3.4.2 to Debian, I am going for the r-api-3.4 tag from 
Debian unstable. As of now (this was obviously going on today), all reverse 
dependencies at level 1 (including the recommended packages) of r-api-* have 
been adapted to depend on r-api-3.4 in unstable. In addition, all recommended 
packages (even if at higher dependency levels) have been adapted as well.

  https://release.debian.org/transitions/html/r-base-3.4.html

I noticed that rkward, littler, rpy and rpy2 do not depend on r-api-* at all, 
so they do not get picked up by the transition.

Johannes

> 
> Dirk
> 
> | Michael
> | 
> | On Fri, Sep 29, 2017 at 8:50 AM, Dirk Eddelbuettel <e...@debian.org> wrote:
> | > So I now have this on my laptop
> | > 
> | >edd@brad:~$ apt-cache policy r-base-core
> | >
> | >r-base-core:
> | >  Installed: 3.4.2-1zesty0.1
> | >  Candidate: 3.4.2-1zesty0.1
> | > 
> | >  Version table:
> | > *** 3.4.2-1zesty0.1 500
> | > 
> | >500 http://ppa.launchpad.net/edd/misc/ubuntu zesty/main amd64
> | > 
> | > Packages
> | > 
> | >100 /var/lib/dpkg/status
> | > 
> | > 3.4.1-2zesty0 500
> | > 
> | >500 http://cloud.r-project.org/bin/linux/ubuntu zesty/
> | >Packages
> | > 
> | > 3.4.1-1zesty0 500
> | > 
> | >500 http://cloud.r-project.org/bin/linux/ubuntu zesty/
> | >Packages
> | > 
> | > 3.4.0-1zesty 500
> | > 
> | >500 http://cloud.r-project.org/bin/linux/ubuntu zesty/
> | >Packages
> | > 
> | > 3.3.2-1 500
> | > 
> | >500 http://us.archive.ubuntu.com/ubuntu zesty/universe amd64
> | > 
> | > Packages
> | > 
> | >edd@brad:~$
> | > 
> | > and I have launched rebuilds for xenial (16.04) and trusty (14.04) which
> | > should complete, possibly after another level of adjustments.
> | > 
> | > These use r-api-3 and work for the "here and now". Use
> | > 
> | > sudo add-apt-repository -y ppa:edd/misc
> | > 
> | > We may propagate these for to the usual 'rrutter' and then CRAN repos
> | > too,
> | > and will take it from there to figure out how to get r-api-3.4.
> | > 
> | > I'm sorry for the disruption. My hand was a little forced but I should
> | > have
> | > considered these consequences too.
> | > 
> | > 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


-- 
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] rkward_0.6.5-1~stretchcran.0_amd64.deb missing

[Johannes Ranke]

Hi Griera,

The version number of the backport is considered lower than the version number 
in the official repository. You could use

  apt-get install -t stretch-cran34 rkward

to get it anyways in this case. The version in the official Debian stretch 
repository has not been rebuilt using R 3.4.0, which is likely the reason if 
it did not work at your end.

Upcoming R 3.4.2 in Debian will, so it seems, not be co-installable with 
packages that it breaks any more[1]. Then, using -t should not be needed any 
more in such a case, as far as I understand (not very far).

Cheers,

Johannes

[1] https://tracker.debian.org/news/874312


Am Dienstag, 26. September 2017, 17:45:13 CEST schrieb Griera:
> Hi Johannes:
> 
> Thank you very much. Rkward now works. The only drawback is that I had to
> install it "by hand":
> 
> sudo dpkg -i rkward_0.6.5-1~stretchcran.0_amd64.deb
> rkward-data_0.6.5-1~stretchcran.0_all.deb
> 
> By default, apt-get installed the Debian repository version (rkward
> 0.6.5-1+b1 0.6.5-1+b1).
> 
> Thanks for your contributions to the R-Debian project!
> 
> Regards. Griera.
> 
> On Mon, 25 Sep 2017 11:41:54 +0200
> 
> Johannes Ranke <johannes.ra...@jrwb.de> wrote:
> > Hello Griera,
> > 
> > sorry, I forgot an "svn add", so the package got lost on the way.
> > 
> > It is on chem now, and will migrate to CRAN shortly.
> > 
> > Johannes
> > 
> > Am Montag, 25. September 2017, 10:57:37 CEST schrieb Griera:
> > > Hello Johannes:
> > > 
> > > I'm sorry, but I still have the same problem with Rkward.
> > > 
> > > After running apt-get update, I still can not find the amd64 version of
> > > the
> > > 
> > > Rkward package. I have tried it with the following sources:
> > > deb http://cran.r-project.org/bin/linux/debian stretch-cran34/
> > > deb http://chem.uft.uni-bremen.de/ranke/r-cran stretch-cran34/
> > > deb http://chem.uft.uni-bremen.de/ranke/r-cran jessie-cran34/  (the
> > > source you tell me in the answer)
> > > 
> > > On the other hand, the package does not seem to be in
> > > https://cran.r-project.org/bin/linux/debian/stretch-cran34/. I can see a
> > > new Rkward package for the i386 architecture dated September 20, but I
> > > do
> > > not see the version for the amd64 architecture.
> > > 
> > > Thank you very much for your help.
> > > 
> > > Best regards. Griera.
> > > 
> > > 
> > > On Wed, 20 Sep 2017 17:16:35 +0200
> > > 
> > > Johannes Ranke <johannes.ra...@jrwb.de> wrote:
> > > > Hello,
> > > > 
> > > > Am Mittwoch, 20. September 2017, 15:43:32 CEST schrieb Griera:
> > > > > Hi:
> > > > > 
> > > > > I have tried to upgrade from version 3.4.0 to 3.4.1 in a Debian
> > > > > Stretch
> > > > > 
> > > > > following the instructions of the web page:
> > > > >   https://cran.r-project.org/bin/linux/debian/
> > > > > 
> > > > > but after updating, Rkward does not work (Error in RK: Graphics API
> > > > > version
> > > > > mismatch). Analyzing the problem, I notice that the Rkward package
> > > > > is
> > > > > not
> > > > > 
> > > > > available in the amd64 version (yes in the i386 version), for
> > > > > example
> > 
> > here:
> > > > >   https://cran.r-project.org/bin/linux/debian/stretch-cran34/
> > > > 
> > > > Thanks for reporting. The build for amd64 failed, because somehow
> > > > apt-get
> > > > source does not see the source package of rkward in the repository any
> > > > more.
> > > > 
> > > > I had to adapt my build script
> > > > 
> > > >   https://cgit.jrwb.de/r-backports/commit/?id=56157ad9495765d9
> > > > 
> > > > The amd64 deb is on its way to CRAN, I think it should be there within
> > > > a
> > > > day or so. If impatient, use
> > > > 
> > > >   deb http://chem.uft.uni-bremen.de/ranke/r-cran jessie-cran34/
> > > > 
> > > > for the moment.
> > > > 
> > > > Cheers,
> > > > 
> > > > Johannes
> > > > 
> > > > > It is not necessary? Can anyone help me on how can I solve the
> > > > > problem that Rkward does not work?
> > > > > 
> > > > > Thanks a lot. Griera
> > > > > 
> > > > > ___
> > > > > R-SIG-Debian mailing list
> > > > > R-SIG-Debian@r-project.org
> > > > > https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
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] rkward_0.6.5-1~stretchcran.0_amd64.deb missing

[Johannes Ranke]

Hello Griera,

sorry, I forgot an "svn add", so the package got lost on the way.

It is on chem now, and will migrate to CRAN shortly.

Johannes

Am Montag, 25. September 2017, 10:57:37 CEST schrieb Griera:
> Hello Johannes:
> 
> I'm sorry, but I still have the same problem with Rkward.
> 
> After running apt-get update, I still can not find the amd64 version of the
> Rkward package. I have tried it with the following sources:
> 
> deb http://cran.r-project.org/bin/linux/debian stretch-cran34/
> deb http://chem.uft.uni-bremen.de/ranke/r-cran stretch-cran34/
> deb http://chem.uft.uni-bremen.de/ranke/r-cran jessie-cran34/  (the
> source you tell me in the answer)
> 
> On the other hand, the package does not seem to be in
> https://cran.r-project.org/bin/linux/debian/stretch-cran34/. I can see a
> new Rkward package for the i386 architecture dated September 20, but I do
> not see the version for the amd64 architecture.
> 
> Thank you very much for your help.
> 
> Best regards. Griera.
> 
> 
> On Wed, 20 Sep 2017 17:16:35 +0200
> 
> Johannes Ranke <johannes.ra...@jrwb.de> wrote:
> > Hello,
> > 
> > Am Mittwoch, 20. September 2017, 15:43:32 CEST schrieb Griera:
> > > Hi:
> > > 
> > > I have tried to upgrade from version 3.4.0 to 3.4.1 in a Debian Stretch
> > > 
> > > following the instructions of the web page:
> > >   https://cran.r-project.org/bin/linux/debian/
> > > 
> > > but after updating, Rkward does not work (Error in RK: Graphics API
> > > version
> > > mismatch). Analyzing the problem, I notice that the Rkward package is
> > > not
> > > 
> > > available in the amd64 version (yes in the i386 version), for example 
here:
> > >   https://cran.r-project.org/bin/linux/debian/stretch-cran34/
> > 
> > Thanks for reporting. The build for amd64 failed, because somehow apt-get
> > source does not see the source package of rkward in the repository any
> > more.
> > 
> > I had to adapt my build script
> > 
> >   https://cgit.jrwb.de/r-backports/commit/?id=56157ad9495765d9
> > 
> > The amd64 deb is on its way to CRAN, I think it should be there within a
> > day or so. If impatient, use
> > 
> >   deb http://chem.uft.uni-bremen.de/ranke/r-cran jessie-cran34/
> > 
> > for the moment.
> > 
> > Cheers,
> > 
> > Johannes
> > 
> > > It is not necessary? Can anyone help me on how can I solve the
> > > problem that Rkward does not work?
> > > 
> > > Thanks a lot. Griera
> > > 
> > > ___
> > > R-SIG-Debian mailing list
> > > R-SIG-Debian@r-project.org
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-debian


-- 
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] rkward_0.6.5-1~stretchcran.0_amd64.deb missing

[Johannes Ranke]

Hello,

Am Mittwoch, 20. September 2017, 15:43:32 CEST schrieb Griera:
> Hi:
> 
> I have tried to upgrade from version 3.4.0 to 3.4.1 in a Debian Stretch
> following the instructions of the web page:
> 
>   https://cran.r-project.org/bin/linux/debian/
> 
> but after updating, Rkward does not work (Error in RK: Graphics API version
> mismatch). Analyzing the problem, I notice that the Rkward package is not
> available in the amd64 version (yes in the i386 version), for example here:
> 
>   https://cran.r-project.org/bin/linux/debian/stretch-cran34/

Thanks for reporting. The build for amd64 failed, because somehow apt-get 
source does not see the source package of rkward in the repository any more.

I had to adapt my build script

  https://cgit.jrwb.de/r-backports/commit/?id=56157ad9495765d9

The amd64 deb is on its way to CRAN, I think it should be there within a day 
or so. If impatient, use

  deb http://chem.uft.uni-bremen.de/ranke/r-cran jessie-cran34/
  
for the moment.

Cheers,

Johannes
> 
> It is not necessary? Can anyone help me on how can I solve the
> problem that Rkward does not work?
> 
> Thanks a lot. Griera
> 
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian


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

[R-sig-Debian] R 3.4.0 for Debian stable and testing

[Johannes Ranke]

Dear all,

With this email I would like to announce the availability of R 3.4.0 for 
jessie and stretch on CRAN. Please excuse the delay, caused by some 
uncertainty about how to deal properly with the incompatibility of R 3.4.0 
with packages compiled with earlier versions that use calls to .C and 
.Fortran in their code as described in

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

where there is also a summary (but no list at the moment) of affected 
packages, provided by Dirk.

In order to avoid breaking packages without the user being prepared for it, 
I have created a new repository for R 3.4.0, so you need to replace
jessie-cran3 with jessie-cran34 if you are using the CRAN backports on jessie. 
Before the upgrade, you should deinstall r-cran-* or r-bioc-* packages from 
the jessie or stretch archives that use .C or .Fortran as they will not work 
with R 3.4.0. You can replace them by locally compiled versions installed 
from within R using install.packages() or the like.

Packages that have been installed locally (not from .deb packages) should 
be updated using

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

I would also like to announce that from R 3.4.0 on, I am signing the Debian 
repositories on CRAN with my new key.

You can import it using

  apt-key adv --keyserver keys.gnupg.net --recv-key 
'E19F5F87128899B192B1A2C2AD5F960A256A04AF'

Please see the README on CRAN for details:

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

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

[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

[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] proplems installing R 2.5 on Ubuntu 14.04

[Johannes Ranke]

Am Dienstag, 8. November 2016, 08:28:35 schrieb Dirk Eddelbuettel:
> On 8 November 2016 at 14:39, Lentes, Bernd wrote:
> | i'd like to install R 2.5 on an Ubuntu 14.04.
> | I have a special software requiring this old version.
> | 
> | While ./configure, i get the following error:
> | 
> | checking for mbstate_t... yes
> | checking for X... no
> | configure: error: --with-x=yes (default) and X11 headers/libs are not
> | available
> | 
> | The problem is that i don't know which headers or libraries are missing,
> | and when i search with aptitude in the Ubuntu repositories i find a ton
> | of them and don't know which one to install.
> | 
> | Can anyone help me ?
> 
> Builds are fully automated; the file debian/control lists in Build-Depends:
> exactly which packages are needed.  Now, we are usually concerned with
> getting _current_ versions right.  For R 3.3.2 we currently have
> 
> Build-Depends: gcc (>= 4:4.1.0), g++ (>= 4:4.1.0), gfortran (>=
> 4:4.1.0), libblas-dev, liblapack-dev (>= 3.1.1), tcl8.6-dev, tk8.6-dev,
> bison, groff-base, libncurses5-dev, libreadline-dev, debhelper (>= 7.2.3),
> texinfo (>= 4.1-2), libbz2-dev, liblzma-dev, libpcre3-dev,
> libcurl4-openssl-dev | libcurl4-dev, xdg-utils, zlib1g-dev, libpng-dev,
> libjpeg-dev, libx11-dev, libxt-dev, x11proto-core-dev, libpango1.0-dev,
> libcairo2-dev, libtiff5-dev, xvfb, xauth, xfonts-base, texlive-base,
> texlive-latex-base, texlive-generic-recommended,
> texlive-fonts-recommended, texlive-fonts-extra, texlive-extra-utils,
> texlive-latex-recommended, texlive-latex-extra, default-jdk [!arm !hppa
> !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], mpack, bash-completion
> 
> but some of these things are moving targets as packages are renamed or
> reorganised.  Start from there.

you can get the build dependencies of current R easily with

apt-get build-dep r-base

Good luck,

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] [FORGED] Re: Problem installing rgdal on a laptop running Ubuntu 16.04.1

[Johannes Ranke]

> > | Thanks. OK, I have now done
> > | 
> > |  sudo apt-get install r-cran-rgdal
> > | 
> > | successfully.
> > 
> > Very good.
> > 
> > Now do
> > 
> >IP <- installed.packages()
> > 
> > and convince yourself that you have rgdal. You could even do
> > 
> >library(rgdal)
> > | 
> > | But sad to say, it didn't help a bit.  When I try
> > | 
> > |  install.packages("rgdal",lib="/home/rolf/Rlib")

Why did you want to install the package again? The command

  sudo apt-get install r-cran-rgdal

should already have brought you the package. That's why Dirk suggested to 
check if it is installed and loadable.

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] Please update GPG signature to long format.

[Johannes Ranke]

Hello Charles,

thanks for the hint - I changed the instructions for the Debian section to use 
the key fingerprint. The change should propagate to CRAN 

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

and its mirrors soon.

Best regards,

Johannes
Am Sonntag, 4. September 2016, 10:03:16 schrieb Charles Plessy:
> Hi Michael and Dirk,
> 
> there are raising concerns that, as of today's computing power, an attacker
> can generate a GPG key that has the same short ID as a target key.  In this
> situation, it may be possible that a user downloads and trusts the
> attacker's GPG key, and as a consequence installs malware.
> 
> For that reason (better explained in http://lwn.net/Articles/697417/), it is
> recommended to use long IDs or even full fingerprints.  I am therefore
> suggesting to update the instructions at
> .
> 
> s/E084DAB9/E298A3A825C0D65DFD57CBB651716619E084DAB9/
> 
> (Note that I tested only in Debian Stable, which is one year older as
> Trusty, so it might be good to doublecheck on a Trusty system that it works
> as expected.)
> 
> Have a nice day,
> 
> Charles

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

Re: [R-sig-Debian] Outdated r-base-core when installing on Ubuntu 14.04

[Johannes Ranke]

Regarding Debian jessie - it turned out that Matt uses the armhf 
architecture, while the arm binaries provided on CRAN are for armel.

Johannes


Ok, first I poked around the ubuntu tablet and related PPAs to see if I 
could find one with an ARM port of R, but no luck. Next I tried a debian 
install - jessie is supported on Crouton and it installs and runs basically 
without a hitch. But I run into the same problem installing R - using only a 
cran debian source and none of Rutter's PPAs. Now r-base-core is only 
available up to 3.1.1-1. Attempting sudo apt-get install r-base=3.1.1-1 
yields a complaint from apt that r-recommended 3.1.1-1 is needed but 
won't be installed, though sudo apt-cache showpdg r-recommended shows 
3.1.1-1 as available.


This left me basically where I was with ubuntu, but I tried something here 
that I didn't try there - I manually tried to install r-recommended 3.1.1-1. It 
complained about a dependency, so I manually tried installing the right 
version of the dependency, which complained about a dependency, etc, 
until I got something to install. Through this process here are the things I 
installed, I believe in this order:


sudo apt-get install r-base-core=3.1.1-1
sudo apt-get install r-cran-boot=1.3-13-1


sudo apt-get install r-cran-codetools=0.2-9-1


sudo apt-get install r-recommended=3.1.1-1


sudo apt-get install r-base=3.1.1-1


This got R installed correctly. While it's still not the most updated version, 
it's a version I can probably live with considering this isn't my main 
machine.


I'm going to try the same thing on the ubuntu install to see if I can get R 
3.0.2 installed there - r-recommended 3.0.2 was available, so perhaps 
manually installing the correct dependencies in order will get the job done. 
I'll report back to say whether this worked either way.


Thanks for the help,
Matt


On Mon, Mar 21, 2016 at 1:48 PM, Johannes Ranke <jranke@uni-
bremen.de[1]> wrote:










-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 Grenzach-Wyhlen


[1] mailto:jra...@uni-bremen.de

[[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] Outdated r-base-core when installing on Ubuntu 14.04

[Johannes Ranke]

Am Montag, 21. März 2016, 13:31:44 schrieb Dirk Eddelbuettel:
> On 21 March 2016 at 13:18, Matthew Simpson wrote:
> | It may be significant that my chromebook has an ARM processor. I don't
> | know
> | about the details of how this works, but perhaps some pieces of the R
> | install haven't been ported to the appropriate architecture?
> 
> Bahh. I am clearly not awake.  Should have realized that.

Neither was I.

> 
> That is why you had r-doc-html, r-recommended, ... etc which are binary=all.
> On CRAN you will /only/ find i386 and amd64.  On the Ubuntu PPAs you /may/
> find arm builds as Ubuntu supports them for their tablet plans etc pp.

I am providing arm binaries for Debian wheezy and Debian jessie on CRAN, maybe 
this would be an option?

Cheers, Johannes

> 
> As such, the Dockerfile I sent you is more relevant than the CRAN README.
> 
> Good luck, 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] Default R Font Changed After Upgrade to Debian 8

[Johannes Ranke]

ry for X and cairo (development files)
> ii  python-cairo1.8.8-1+b2 
> amd64Python bindings for the Cairo
> vector graphics library ii  python-gi-cairo
> 3.14.0-1amd64Python
> Cairo bindings for the GObject library ii  python3-cairo   
>1.10.0+dfsg-4+b1amd64   
> Python 3 bindings for the Cairo vector graphics library ii 
> python3-gi-cairo3.14.0-1   
> amd64Python 3 Cairo bindings for the
> GObject library
> 
> I recently noticed it also affects other software, like Firefox internet
> browser.
> 
> --
> Dario Strbenac
> PhD Student
> University of Sydney
> Camperdown NSW 2050
> Australia
> ___
> R-SIG-Debian mailing list
> R-SIG-Debian@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian
-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 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] Unable to install R 3.2 on debian jessie

[Johannes Ranke]

Hi,

Am Freitag, 18. September 2015, 15:25:10 schrieb George N. White III:
> On Fri, Sep 18, 2015 at 8:35 AM Francois-Xavier Jollois <
> 
> francois-xavier.joll...@parisdescartes.fr> wrote:
> > Hi everybody
> > 
> > I try to update R 3.1.1 to R 3.2.2 on a Debian Jessie (8.2) server. I
> > try to do the following steps :
> > 
> > - Adding "deb-src http://cran.irsn.fr/bin/linux/debian jessie-cran3/"
> > to /etc/apt/sources.list
> 
> The instructions (today) say to add:
> 
>  "deb http://cran.irsn.fr/bin/linux/debian jessie-cran3/"
> 
> Not "deb-src ..." --  Could have been a typo that was since corrected.

Not really a typo, just taken from another part of the instructions - you need 
this form of the source line in case you want to compile from the source 
packages corresponding to the backports, i.e. if you want to compile on an 
architecture other than i386, amd64 or armel.

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] Problem installing R on Debian 6

[Johannes Ranke]

Dear Hartyun Khachatryan,

thanks for your report. It seems not a lot of people are using the backport to 
squeeze, as I have forgot to update the package index after doing the backport 
for R 3.2.2 and nobody (including me) noticed...

The updated index is on its way to the CRAN mirrors, it will take some time to 
be synchronised, so please try again tomorrow.

Johannes

Am Mittwoch, 16. September 2015, 07:55:56 schrieb Harutyun Khachatryan:
> Dear all,
> 
> I having a trouble installing R on debian 6 squeeze. Apt can not find some
> packages on repository. It seems like that some packages missed. Can you
> please help me with this? Thank you in advance. Harutyun khachatryan.
> P.S. It writing something like this. It doesn't depends on CRAN mirror. I
> have tried a lot of different CRAN mirrors with the same result.
> 
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-cluster
> 2.0.1-1~squeezecran.3.2.1  
> 
>   404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-foreign
> 0.8.63-1~squeezecran.3.2.1 
> 
>   404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-mass
> 7.3-40-1~squeezecran.3.2.1 
> 
>  404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-kernsmooth
> 2.23-14-1~squeezecran.3.2.1
> 
>404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-lattice
> 0.20-31-1~squeezecran.3.2.1
> 
>   404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-nlme
> 3.1.120-1~squeezecran.3.2.1
> 
>  404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-matrix
> 1.2-0-1~squeezecran.3.2.1  
> 
>404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-mgcv
> 1.8-6-1~squeezecran.3.2.1  
> 
>  404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-survival
> 2.38-2-1~squeezecran.3.2.1 
> 
>  404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-rpart
> 4.1-9-1~squeezecran.3.2.1  
> 
> 404  Not Found
> Err http://cran.at.r-project.org/bin/linux/debian/ squeeze-cran3/
> r-cran-class 7.3-12-1~squeezecran.3.2.1   
> 
>   [[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
Kronacher Str. 8
79639 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] Server certificate verification failed

[Johannes Ranke]

Hi,

Am Dienstag, 18. August 2015, 10:54:55 schrieb Irucka Embry:
 Hi all, I have the following in my apt sources.list file: 
 deb https://...

is there any reason you want to use https rather than http? 

 server certificate verification failed. CAfile:
 /etc/ssl/certs/ca-certificates.crt CRLfile: none

this should go away if you use unencrypted http.

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] Problems installing packages with R 3.2.0 on Linux Mint 17.1

[Johannes Ranke]

Dear Stefan,

you are using Linux Mint 17.1, which is based on Ubuntu 14.04 (using gcc 
4.8.2). I have an Ubuntu 14.04 system with CRAN backports installed and 
install.packages(sem) works there as well.

Again, compiler setup should just work on these systems. Still no clue what 
went wrong at your end.

The packages necessary to build R packages from source are pulled by the 
dependencies of r-base-dev, including build-essential, gcc and g++.

g++ gives the error messages in your case.

Kind regards,

Johannes


Am Freitag, 8. Mai 2015, 08:33:22 schrieb Dr. Stefan Röttger:
 Dear Dirk, dear Johannes,
 
 thank you very much for your immediate responses.
 
 Could you give me some directions on how to make sure that I have a
 correct compiler setup? I.e., which software / compiler packages are
 assumed by R to be installed?
 
 Maybe I can solve the problem by making a fresh install of all required
 components and deinstalling components that may interfere.
 
 Best regards,
 Stefan
 
 Am 07.05.2015 um 13:32 schrieb Dirk Eddelbuettel:
  On 7 May 2015 at 13:17, Johannes Ranke wrote:
  | I have no idea where the problem is, but I feel this strong urge to
  | mention
  | that install.packages(sem) works fine on Debian squeeze (g++ 4.4.5),
  | wheezy (g++ 4.7.2) and jessie (g++ 4.9.2) using the R backport from
  | CRAN... 
  +1
  
  As the messages all come from compilation, methinks something is wrong
  with
  the compiler setup.  Maybe icc got added, maybe gcc got broken, maybe
  something else you did not tell us.
  
  But the default toolchains on the systems we stand behind all work.
  
  Dirk
 
 ___
 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] Problems installing packages with R 3.2.0 on Linux Mint 17.1

[Johannes Ranke]

/ctype_base.h:57:32: error:
 ‘_IScntrl’ was not declared in this scope
   static const mask cntrl  = _IScntrl;
  ^
 /usr/include/x86_64-linux-gnu/c++/4.8/bits/ctype_base.h:58:32: error:
 ‘_ISpunct’ was not declared in this scope
   static const mask punct  = _ISpunct;
  ^
 /usr/include/x86_64-linux-gnu/c++/4.8/bits/ctype_base.h:59:32: error:
 ‘_ISalpha’ was not declared in this scope
   static const mask alnum  = _ISalpha | _ISdigit;
  ^
 /usr/include/x86_64-linux-gnu/c++/4.8/bits/ctype_base.h:59:43: error:
 ‘_ISdigit’ was not declared in this scope
   static const mask alnum  = _ISalpha | _ISdigit;
 ^
 make: *** [csem.o] Fehler 1
 ERROR: compilation failed for package ‘sem’
 * removing ‘/home/stefan/R/x86_64-pc-linux-gnu-library/3.2/sem’
 Warning in install.packages :
installation of package ‘sem’ had non-zero exit status
 
 
 
   [[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
Kronacher Str. 8
79639 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] Dependency problem with python-rpy2 package

[Johannes Ranke]

 Without looking into it I believe the solution will be for me to
 prepare a backport of python-singledispatch. I can not do it right
 away, but hopefully later in the week ...

I had a go at it, but did not succeed to produce a working python-
singledispatch package. After installing python3-all and python3-setuptools 
outside the pbuilder chroot (!) I could build a .deb, but this mysteriously 
depends on a virtual package python-ordereddict which is not in Debian and I 
do not know what package should provide that. As I do not understand how these 
python dependencies work, I stopped there.

I did successfully install rpy2 in the presence of 3.2.0 from CRAN in a wheezy 
chroot, using pip install. You need to install the development files for R, 
python and readline as well, compare the rpy2 installation instructions.

If someone can give me a hand here, OK, otherwise I will have to remove 
python-rpy2 from the wheezy-cran3 and squeeze-cran3 repositories (there it 
does not work either I found). I did not notice as I do not currently use 
rpy2.

Kind regards,

Johannes

 
 Meanwhile you could try to install the python-singledispatch version
 from unstable via apt pinning.
 
 Johannes
 
 Zitat von Vincent Lemoine vlemo...@teclib.com:
  Hello,
  
  I have a problem with package python-rpy2 with Debian Wheezy repository.
  
  I use this repo :
  deb http://cran.r-project.org/bin/linux/debian wheezy-cran3/
  
  This package depends on python-singledispatch but it doesn't exist
  in official Debian repo...
  
  Could you help me to fix this issue ?
  
  Thanks a lot,
  
  ___
  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
Kronacher Str. 8
79639 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] running unit tests on the stringr package

[Johannes Ranke]

Dear Raju

I agree to Dirk that this is not really the best place for these matters, but 
as I got curious, I checked and found you should use test_package() and not 
test_dir(), as the latter does not load unexported functions of the package 
(such as check_string()) that may occur in the tests.

For packaging of r-cran-stringr, it is probably most efficient to file a bug 
report there because of the missing Suggests for r-cran-testthat.

Kind regards,

Johannes

Am Sonntag, 19. April 2015, 17:58:53 schrieb kamaraju kusumanchi:
 I am trying to learn how  to run the unit tests in the stringr package
 and have the following questions.
 
 1) The r-cran-stringr package does not suggest/depend on the
 r-cran-testthat package . Would it make sense to add such a thing
 since after all the tests in /usr/lib/R/site-library/stringr/tests
 rely on testthat package?
 
 2) I am getting the following error when trying to run the unit tests
 
 % R
 R version 3.1.1 (2014-07-10) -- Sock it to Me
 ...
 
  library('testthat')
  library('stringr')
  test_dir('/usr/lib/R/site-library/stringr/tests')
 
 String and pattern checks : 123
 Counting matches : 
 Detecting patterns : ..
 Duplicating strings : ..
 Extract patterns : ..
 Joining strings : ..
 String length : .
 Locations : 
 Matching groups : ..
 Test padding : 
 Splitting strings : .
 Extracting substrings : ...
 Trimming strings : 
 
 
 1. Failure(@test-check.r#4): string is atomic
 -- check_string(list()) does not match
 'must be an atomic'. Actual value: Error in force(expr) : could not find
 function check_string\n
 
 2. Failure(@test-check.r#9): pattern is a string
 --- check_pattern(1) does not match 'must be a
 character vector'. Actual value: Error in force(expr) : could not find
 function
 check_pattern\n
 
 3. Error: error when string and pattern lengths incompatible
 --- could not find function check_pattern
 1: withCallingHandlers(eval(code, new_test_environment), error =
 capture_calls) 2: eval(code, new_test_environment)
 3: eval(expr, envir, enclos)
 4: expect_that(check_pattern(letters, a), equals(letters)) at
 test-check.r:14 5: condition(object)
 6: compare(expected, actual, ...)
 7: compare.character(expected, actual, ...)
 8: identical(x, y)
 
 What am I doing wrong?
 
 I am using a Debian box with a combo of Wheezy + Jessie
 
 % dpkg -l r-cran-testthat r-cran-stringr r-base
 ii  r-base 3.1.1-1all
 GNU R statistical computation and graphics system
 ii  r-cran-stringr 0.6.2-2all
 Make it easier to work with strings
 ii  r-cran-testthat0.9.1-1amd64
 GNU R testsuite
 
 regards
 raju
-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 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] Debian Testing: ~/.Renviron seems to not being read (R_LIBS not set)

[Johannes Ranke]

 PM, Dirk Eddelbuettel e...@debian.org 
wrote:
   Marius,
   
   On 30 March 2015 at 12:30, Marius Hofert wrote:
   | Here is how I installed R. This is basically how Martin Maechler
   | showed me to install R under Ubuntu (in several versions so that they
   | are also recognized by ESS). My goal is to adjust this to make it
   | work
   
   | for Debian:
   That's your beef.  We support reasonably feature complete packages
   built
   in
   reasonably well-engineered and by now mostly debugged processes.
   
   You can of course build your own, but if you do and things break you
   get
   to
   keep those pieces.
   
   And how to build R(-devel) locally has been discussed in the past.
   
   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
  
  --
  PD Dr. Johannes Ranke
  Kronacher Str. 8
  79639 Grenzach-Wyhlen
-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 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] Debian Testing: ~/.Renviron seems to not being read (R_LIBS not set)

[Johannes Ranke]

Dear Marius,

thanks for sharing your thoughts on this. I am not very happy that you provide 
instructions to install R 3.1.3 from sources when binaries are already 
provided on CRAN. The installation instructions you share bring more work and 
a more non-standard setup, unless you want two different copies of R. But your 
instructions do not cover that case!

From my point of view it could be interesting if it were modified for keeping 
an up to date copy of R-devel in addition to the released version, but in the 
way you are giving it here I think it may lead people to be distracted from 
the easy and clean way to do it. I say clean, because when you use the .deb 
packages it is much easier to remove or revert what you have done.

So maybe you could modify your instructions to the case where someone wants to 
have R-devel in addition to the released R version, if that is what you are 
aiming at? I could then add it to the README for Debian on CRAN.

And then, regarding your comment on the keyserver listed in the README, what's 
wrong with keys.gnupg.net? I just tested it (again) and it worked fine.

Kind regards, 

Johannes

Am Montag, 30. März 2015, 20:42:47 schrieb Marius Hofert:
 Dear Dirk, Dear Johannes,
 
 Thanks for helping, I could solve the problem.
 
 By reading your posts, I got a bit of the impression that questions
 beyond the 'standard installation' process are not really welcome on
 R-SIG-Debian. If this is the case, I'm sorry for my post. I wasn't
 aware of this, but Dirk makes it clear why on
 https://stat.ethz.ch/pipermail/r-sig-debian/2013-March/002062.html.
 
 As Dirk also mentioned on
 http://stackoverflow.com/questions/8343686/how-to-install-2-different-r-vers
 ions-on-debian installing from source is the only practical way in case one
 needs several R versions. I now went back to Chapter 2 of
 http://cran.r-project.org/doc/manuals/r-release/R-admin.html to read
 more about it and to see whether I have done something substantially
 wrong. This seemed not to be the case.
 
 Next, Dirk's wonderful little example helped... I could check that
 .Renviron is indeed found. Then it was easy: my local
 version-independent library was not found simply because .libPaths()
 only contains those folders which physically exist (also mentioned on
 ?.libPaths). And indeed, I had not checked that.
 
 Here is thus the final solution that worked (in case useful for others
 or being improved upon [slightly expanded in comparison to the
 original one, e.g., also addressing how to obtain a key -- the server
 is different than keys.gnupg.net mentioned on CRAN.]):
 
 1) sudo emacs /etc/apt/sources.list # then add: deb
http://stat.ethz.ch/CRAN/bin/linux/debian jessie-cran3/ deb-src
http://stat.ethz.ch/CRAN/bin/linux/debian jessie-cran3/ # = then run
 sudo apt-get update. It fails due to a missing key = note the missing key
 number # and use sudo apt-key adv --keyserver keyserver.ubuntu.com
 --recv-key NUMBER where # NUMBER = number of the missing public key
 
 2) sudo apt-get build-dep r-base
 
 3) sudo mkdir /usr/local/R sudo chown mhofert:mhofert /usr/local/R
 
cd /usr/local/R # if old versions exist (./R-devel, ./R-devel-build,
./R-devel.tar.gz etc.), # delete them first, then do: wget
http://cran.r-project.org/src/base/R-3/R-3.1.3.tar.gz tar -xzf
 R-3.1.3.tar.gz mv R-3.1.3 R-3.1.3-source
 
mkdir R-3.1.3-build cd R-3.1.3-build ../R-3.1.3-source/configure # we do
./configure *outside* the source directory (= keep sources)
 
make make check make pdf make info
 
cd ..  ln -s /usr/local/R/R-3.1.3-build/bin/R /usr/local/R/R
 
mkdir /usr/local/R/library # create version-independent library
 
sudo emacs ~/etc/bash.bashrc # then add: PATH=/usr/local/R:$PATH
 
 4) ~/.Renviron should contain R_LIBS=/usr/local/R/library
 
 
 Thanks  cheers,
 Marius
 
 On Mon, Mar 30, 2015 at 1:09 PM, Dirk Eddelbuettel e...@debian.org wrote:
  Marius,
  
  On 30 March 2015 at 12:30, Marius Hofert wrote:
  | Here is how I installed R. This is basically how Martin Maechler
  | showed me to install R under Ubuntu (in several versions so that they
  | are also recognized by ESS). My goal is to adjust this to make it work
  
  | for Debian:
  That's your beef.  We support reasonably feature complete packages built
  in
  reasonably well-engineered and by now mostly debugged processes.
  
  You can of course build your own, but if you do and things break you get
  to
  keep those pieces.
  
  And how to build R(-devel) locally has been discussed in the past.
  
  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
-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 Grenzach-Wyhlen

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

Re: [R-sig-Debian] Debian Testing: ~/.Renviron seems to not being read (R_LIBS not set)

[Johannes Ranke]

Hi Marius,

Am Montag, 30. März 2015, 02:24:28 schrieb Marius Hofert:
 Hi,
 
 I have Debian Testing running on a Lenovo Thinkpad X1
 Carbon (2015, 3rd gen.). 

Please specify what version of R you are using and how you installed it.

 I would like to have a package library
 independent of the installed R version.

For this purpose, in the default setup on Debian we have 
/usr/local/lib/R/site-library. When using the R backport from CRAN on Debian 
testing this is what you should get:

  sessionInfo()
 R version 3.1.3 (2015-03-09)
 Platform: x86_64-pc-linux-gnu (64-bit)
 Running under: Debian GNU/Linux 8 (jessie)

 ...

  .libPaths()
 [1] /usr/local/lib/R/site-library /usr/lib/R/site-library   
/usr/lib/R/library 

 Under Ubuntu, I used to
 have the following line in ~/.Renviron:
 R_LIBS=/usr/local/R/library:/usr/lib/R/site-library This worked
 fine and /usr/local/R/library showed up in .libPaths().

This should usually not be necessary, as you can use the default location of
the local site library.

 However, under Debian (with the same ~/.Renviron), my .libPaths()
 just shows /usr/local/R/R-3.1.3-build/library

It looks like you have done something fairly non-standard to your system...

Cheers,

Johannes

 which is the
 version-dependent library (this used to come at 3rd position in
 .libPaths()). Does R on Debian not look for ~/.Renviron? I also
 tried R_LIBS_USER but no luck here either (although, as far as I
 understand Section 6.2 of R Installation and Administration,
 R_LIBS or R_LIBS_USER should work (?))
 
 Cheers, Marius
 
 PS: I found two sites which seem to be related, but it was still
 not quite clear to me how to approach the problem:
 https://stat.ethz.ch/pipermail/r-sig-debian/2005-December/50.html
 https://stat.ethz.ch/pipermail/r-sig-debian/2010-May/001146.html
 
 ___
 R-SIG-Debian mailing list
 R-SIG-Debian@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-debian
-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 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] Debian Testing: ~/.Renviron seems to not being read (R_LIBS not set)

[Johannes Ranke]

Am Montag, 30. März 2015, 12:30:37 schrieb Marius Hofert:
 Dear Johannes, Dear Dirk,
 
 Thanks a lot for helping. Here is the missing information.
 
 Here is how I installed R. This is basically how Martin Maechler
 showed me to install R under Ubuntu (in several versions so that they
 are also recognized by ESS). My goal is to adjust this to make it work
 for Debian:
 
 1) sudo emacs /etc/apt/sources.list # then add:
deb http://stat.ethz.ch/CRAN/bin/linux/debian jessie-cran3/
deb-src http://stat.ethz.ch/CRAN/bin/linux/debian jessie-cran3/
 
 2) sudo apt-get build-dep r-base

At this point you should simply do

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

as per the Debian README on CRAN.

http://cran.r-project.org/bin/linux/debian/README.html

Then you do not have to build from sources as you did below! This will also 
give you /etc/R/Renviron.

Kind regards,

Johannes

 
 3) sudo mkdir /usr/local/R
sudo chown mhofert:mhofert /usr/local/R
 
cd /usr/local/R
wget http://cran.r-project.org/src/base/R-3/R-3.1.3.tar.gz
tar -xzf R-3.1.3.tar.gz
mv R-3.1.3 R-3.1.3-source
 
mkdir R-3.1.3-build
cd R-3.1.3-build
../R-3.1.3-source/configure
 
make
make check
make pdf
make info
 
cd ..
ln -s /usr/local/R/R-3.1.3-build/bin/R /usr/local/R/R
 
sudo emacs ~/etc/bash.bashrc # then add:
PATH=/usr/local/R:$PATH
 
 .libPaths() shows:
  .libPaths()
 
 [1] /usr/local/R/R-3.1.3-build/library
 
 and sessionInfo() is:
  sessionInfo()
 
 R version 3.1.3 (2015-03-09)
 Platform: x86_64-unknown-linux-gnu (64-bit)
 Running under: Debian GNU/Linux 8 (jessie)
 
 locale:
  [1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
  [5] LC_MONETARY=en_CA.UTF-8LC_MESSAGES=en_CA.UTF-8
  [7] LC_PAPER=en_CA.UTF-8   LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
 [11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C
 
 attached base packages:
 [1] stats graphics  grDevices utils datasets  methods   base
 
 
 Interestingly, under Ubuntu, I find /etc/R/Renviron, under Debian, it
 does not exist... hmmm... what's flawed in the above installation
 process (?)
 
 Cheers,
 Marius
 
 On Mon, Mar 30, 2015 at 7:39 AM, Dirk Eddelbuettel e...@debian.org wrote:
  Hi Marius,
  
  On 30 March 2015 at 02:24, Marius Hofert wrote:
  | I have Debian Testing running on a Lenovo Thinkpad X1
  | Carbon (2015, 3rd gen.). I would like to have a package library
  | independent of the installed R version. Under Ubuntu, I used to
  | have the following line in ~/.Renviron:
  | R_LIBS=/usr/local/R/library:/usr/lib/R/site-library This worked
  | fine and /usr/local/R/library showed up in .libPaths().
  
  Please look at
  
 /etc/R/Renviron
 /usr/lib/R/etc/Renviron
  
  (which are the same file via softlinks) and how they set R_LIBS_SITE and
  have been 2003 (!!).
  
  | However, under Debian (with the same ~/.Renviron), my .libPaths()
  | just shows /usr/local/R/R-3.1.3-build/library which is the
  | version-dependent library (this used to come at 3rd position in
  | .libPaths()). Does R on Debian not look for ~/.Renviron? I also
  
  It should. See help(Startup).
  
  And does:
edd@max:~$ grep Hello .Renviron
MARIUS=Hello, world from .Renviron
edd@max:~$ R -q -e 'Sys.getenv(MARIUS)'
R Sys.getenv(MARIUS)
[1] Hello, world from .Renviron
R
R
edd@max:~$
  
  Small caveat: littler does not (yet). But you didn't say whether you used
  R
  or r.
  
  Dirk
  
  | tried R_LIBS_USER but no luck here either (although, as far as I
  | understand Section 6.2 of R Installation and Administration,
  | R_LIBS or R_LIBS_USER should work (?))
  | 
  | Cheers, Marius
  | 
  | PS: I found two sites which seem to be related, but it was still
  | not quite clear to me how to approach the problem:
  | https://stat.ethz.ch/pipermail/r-sig-debian/2005-December/50.html
  | https://stat.ethz.ch/pipermail/r-sig-debian/2010-May/001146.html
  | 
  | ___
  | 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
-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 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] Suggestions to improve the info page of /bin/linux/debian

[Johannes Ranke]

Hi Mathieu,

thanks a lot for your help with this! I just did some minor polishing, and the 
result is now on CRAN.

I tried to make the resulting page validate cleanly, but as the README.html is 
only included in the body of the index page, I do not think there is a way 
to include the stylesheet with valid html. The rest of the html validates 
without errors.

I am now using a separate README.css - improvements welcome!

Kind regards,

Johannes


Am Dienstag, 3. März 2015, 10:26:51 schrieb Mathieu Basille:
 Le 03/03/2015 10:02, Mathieu Basille a écrit :
  Hi Johannes,
  
  I didn't know what would be the best approach to modify the page—how it
  was
  generated, is there a central place, etc.—which is why I posted on
  r-sig-debian in the first place. Anyway, although I'm more or less
  familiar
  with markdown and pandoc, it was easier for me to edit directly
  README.html
  as it was on CRAN. Please find attached a revision with the modifications
  I
  suggested earlier. Again, I tried to be correct to the best of my
  knowledge, but I may not be entirely accurate.
  
  I simply edited (and formated the file) using Emacs, and manually added
  the
  TOC and other suggested modifications (notably reorganization). I think
  there is still room for improvement, but this should get things started. I
  cleaned the layout, but left most of the actual code and text unchanged.
  
  I think the whole page would also benefit from a CSS, e.g. for titles
  (instead of caps), but left it without it.
 
 Ah! I just noticed that there was actually one (I must be really tired)...
 so let me rephrase that last part: I think the CSS would also benefit from
 an update, e.g. for titles (coding caps in the CSS) and the TOC, but I left
 it unchanged!
 
 Mathieu.
 
  Best,
  Mathieu.
  
  Le 02/03/2015 04:09, Johannes Ranke a écrit :
  Hi Mathieu,
  
  thanks for your input. It reminds me how I got involved in the Debian
  backports, as I thought the Debian README on CRAN needed an update...
  
  At the moment I do not have the time to reorganize the README, so if you
  would
  like to go ahead and implement your changes into a README.html, I
  wouldn't
  mind. Otherwise I am willing to pick up your suggestions, but it will
  take me
  some time to get around to do it.
  
   From my work on R package vignettes I know that pandoc is able to
   generate
  
  single html documents with linked TOC from markdown, which is more
  flexible
  than the text2html stuff I am using at the moment (as well as Michael
  does). But maybe you or someone else on this list knows another
  convenient way? Or it
  could be written in HTML using div tags and a hand-crafted css...
  
  Kind regards,
  
  Johannes
  
  Am Donnerstag, 26. Februar 2015, 15:49:58 schrieb Mathieu Basille:
  After Johannes set up the CRAN repository for Jessie, I had quite some
  trouble figuring out what any user should do to have a running and
  up-to-date R in Debian (particularly Testing). Part of the problem is, I
  think, the overwhelming documentation on the page DEBIAN PACKAGES OF R
  SOFTWARE which is provided on CRAN at /bin/linux/debian. Some
  information
  is also lacking in places.
  
  So here are a few suggestions to try to arrange this page. The main one
  is
  actually a reorganization of the whole page, which should make it easier
  from a user perspective. Note that I think all information I added is
  correct, but it might not be entirely accurate.
  
  I think the page in itself would benefit largely from the inclusion of a
  table of contents (with links to sections). With the page reorganized,
  that
  would follow this:
  
  INSTALLATION
  
   ADMINISTRATION AND MAINTENANCE
   PATHWAYS TO R PACKAGES
  
  BACKPORTS ON CRAN
  
   SUPPORTED PACKAGES
   DEBIAN WHEEZY (STABLE)
   DEBIAN JESSIE (TESTING)
   DEBIAN SQUEEZE (OLD STABLE)
   DEBIAN SID (UNSTABLE)
   SECURE APT
   SUPPORTED PLATFORMS
  
  REPORTING PROBLEMS
  BACKPORTING FOR DEBIAN
  ACKNOWLEDGEMENT
  
  I added at the bottom of this message a few modifications of some of
  these
  (sub-)sections. The vast majority of the information is already there,
  so
  these are really minor changes, except for the Jessie sub-section.
  
  Hope this helps,
  Mathieu.
  
  
  
  ==
  
  INSTALLATION
  
  With an appropriate entry in /etc/apt/sources.list *(see below according
  to
  the branch of Debian used)*, the newest R release *including recommended
  packages* can be installed using a command sequence like
  
  
  SUPPORTED PACKAGES
  
  [Remove:]   r-cran-rmatrix
  
  
  DEBIAN JESSIE (TESTING)
  
  As of end of January 2015, there is a new repository containing binaries
  for Jessie (current testing). This repository hosts all supported
  packages
  presented above, and is updated upon new R releases.
  
  To use R supported packages on Debian Jessie, simply add something like

Re: [R-sig-Debian] Unable to install R 3.1.2 on Debian:Testing

[Johannes Ranke]

 otherwise I will only have time in the weekend to do something (amend the
 README or set up a new repo for jessie) on the weekend.

The repository for jessie is in the works - but don't expect it to be up 
before next weekend.

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] Unable to install R 3.1.2 on Debian:Testing

[Johannes Ranke]

Dear Carl,

the CRAN repository does not support Debian testing. I did think of adding 
support for jessie, 
as it is frozen now, but did not get around to do it yet.

I believe you would have no problem when using Debian stable.

Am Freitag, 16. Januar 2015, 21:44:25 schrieb Carl Boettiger:
 Dear Johannes, R-sig-debian list,
 
 Along with Dirk Eddelbuettel I've been maintaining Debian-based Docker
 containers for R. Recently our container installing r-base has started to
 fail. This seems to be due to a problem with the libjpeg dependencies. The
 example I show below was working with debian:jessie on Jan 5th, but has
 been failing since then.  (https://registry.hub.docker.com/u/rocker/r-base/
 )
 
 From a vanilla install of debian:testing (or jessie or squeeze) I add the

Well, testing and jessie are the same. For squeeze you would have to add 
squeezecran 
sources.

 CRAN repository for the latest R version for debian, and then I then try to
 install `r-base-core` 3.1.2:
 
...
...

 Note that `apt-cache show r-base-core` shows three versions are available:

I should clean this up - generally I only have the latest released version in 
the repository.

 3.1.2~wheezycran3.0, 3.1.1+b2, and 3.1.0~wheezycran3.0, and that the
 `wheezycran3.0` versions (e.g. R 3.1.2 and 3.1.0) cannot be installed
 because they depend on libjpeg8, which is not available, while 3.1.1
 depends on libjpeg62-turbo-dev.
 
 I'm not sure why the libjpeg dependency has changed or how to address this
 so that I can install r-base=3.1.2 on Debian.

At the moment you are on your own with R 3.1.2 on jessie. The easiest safe bet 
in my opinion 
would be to install from the Debian sources in unstable, i.e. add a deb-src 
entry for unstable 
to your sources.list, do an apt-get build-dep r-base and then apt-get source 
--build r-base 
and install the packages with dpkg.

 Thanks for your help,
 
 Carl

Hope it helps.

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] BLAS/LAPACK routine 'DLASCL' gave error code -4 in liblapack3 Version 3.5.0

[Johannes Ranke]

Am Dienstag, 16. Dezember 2014, 08:39:34 schrieb Dirk Eddelbuettel:
 On 16 December 2014 at 14:45, Johannes Ranke wrote:
 | this list serves as a forum for discussions about R backports present on
 | CRAN,
 The mandate, as I recall, is a little broader: usage of R on Debian-based
 systems
 
 As such, I found the post perfectly adequate. We redirect from r-help and
 other lists to here because it is the one focus point for all things related
 to Debian / Ubuntu / ... and R.

you are right, Dirk  - it is not only about the backports of course. Also, I 
did not want to say the post was inadequate ... Just wanted to mention how 
useful a bug tracking system is for such things. And we do not have one for 
the backports on CRAN. Which reminds me that it would be good thing to have R 
3.1.2 in jessie-backports now that it is frozen at R 3.1.1. And if nobody with 
the necessary Debian uploading rights will step up to do so, I should start 
preparing R backports for jessie for the CRAN repository in the not so distant 
future.

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] Update R on a new Linux Mint Maya 13 + rJava and XLConnect

[Johannes Ranke]

Keith,

As Linux Mint Maya 13 appears to be based on Ubuntu Precise, you may be 
tempted to follow the corresponding Ubuntu README on CRAN. However, CRAN 
maintainers do not officially support Mint, so I do not recommend this approach 
as I have no idea in what ways Linux Mint deviates from Ubuntu Precise.

To be on the safe side, you could compile binaries for your platform from  
suitable source packages in Debian format. There are some hints in the Debian 
README on CRAN on how to do this.

This takes a bit of effort, which is why we provide binaries for Debian stable 
and the most important Ubuntu releases on CRAN.

Maybe somebody else knows more about Mint 13 and its compatibility with Ubuntu 
Precise?

Kind regards,

Johannes



Am Donnerstag, 31. Juli 2014, 22:28:04 schrieb Keith S Weintraub:
 Folks,
 I was able to get R installed using:
apt-get install r-base-core
 
 
 R version 2.14.1 (2011-12-22)
 Copyright (C) 2011 The R Foundation for Statistical Computing
 ISBN 3-900051-07-0
 Platform: i686-pc-linux-gnu (32-bit)
 
 
 * What is the best way to upgrade to the latest version of R.
 * What is the best way to install rJava and XLConnect.
 
 Thanks for your time,
 Best,
 KW
 
 PS. I know some of you may have seen these questions before from me on
 r-help. I was told this forum might be a better place to peddle my
 problems.
 
 --
 
 ___
 R-SIG-Debian mailing list
 R-SIG-Debian@r-project.org
 https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
PD Dr. Johannes Ranke
Kronacher Str. 8
79639 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] requet

[Johannes Ranke]

Dear Kabirou Toikourou

Please have a look at

https://stat.ethz.ch/mailman/listinfo/r-sig-debian

Kind regards,

Johannes Ranke

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

Re: [R-sig-Debian] debian testing CRAN repositories

[Johannes Ranke]

Hi Luca,

jessie is not supported by option 3). I plan to do so starting from the first 
official R release after jessie is frozen (scheduled for November 2014). Also, 
option 3) only contains the recommended packages plus a very few additional 
ones (see the README).

Kind regards,

Johannes

Am Donnerstag, 24. April 2014, 01:37:00 schrieb Luca Braglia:
 Dear all,
 
 i've a Debian jessie on my home pcs.
 
 For the repositories of CRAN packages, to the best of my knowledge, there
 are
 
 1) http://debian-r.debian.net/
 
 2) http://debian.cran.r-project.org/
 
 3) http://cran.r-project.org/bin/linux/debian/
 
 I'm a bit confused and need a little advice: which better (if one is so)
 for my setting? In order to make packages dependencies happy and
 integration with the standard debian system smooth, I have to use the
 first, right?
 
 Many thanks
   Luca
 
   [[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
Kronacher Str. 8
79639 Grenzach-Wyhlen

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