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

[Clive Nicholas]

Thank you so much Johannes.

Problem now sorted:

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

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

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

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

Yours with thanks,
Clive Nicholas

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

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



-- 
Clive Nicholas

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

[[alternative HTML version deleted]]

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

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

[Charles Plessy]

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

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

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

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

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

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

Have a nice day,

Charles

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

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

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

[Johannes Ranke]

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

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

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

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

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

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

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

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

Cheers,

Johannes

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

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

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

[J C Nash]

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

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

as one of the apt entries.

JN

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

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

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

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

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

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

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

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

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

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

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

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

*#no-greeting*

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

*#default-key 621CC013*

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

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

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

*#encrypt-to some-key-id*

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

*#force-v3-sigs*

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

*#no-escape-from-lines*

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

*#charset utf-8*

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

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

[Clive Nicholas]

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

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

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

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

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

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

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

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

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

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

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

*#no-greeting*

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

*#default-key 621CC013*

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

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

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

*#encrypt-to some-key-id*

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

*#force-v3-sigs*

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

*#no-escape-from-lines*

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

*#charset utf-8*

*# Group names may be defined like this:*
*#   group mynames = paige 0x12345678 joe patti*
*#*
*# Any time "mynames" is a recipient (-r or --recipient), it will be*
*# expanded to the names "paige", "joe", and "patti", and the key ID*
*# "0x12345678".  Note there is only one level of expansion - you*
*# cannot make an group that points to another group.  Note also that*
*# if there are spaces in the recipient name, this will appear as two*
*# recipients.  In these 

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

[Dirk Eddelbuettel]

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

:)

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

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

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

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

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

It sure would help.

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

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

Dirk

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

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

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

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

[Charles Plessy]

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

Yes I am here :)

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

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

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

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

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

Have a nice day,

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

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

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

[Johannes Ranke]

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

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

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

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

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

[Johannes Ranke]

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

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

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

Yes.

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

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

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

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

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

[Dirk Eddelbuettel]

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

Another example with KernSmooth:

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

Maybe this part of NEWS is what matters:

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

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

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

I think you are

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

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

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

Dirk

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

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

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

[Johannes Ranke]

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

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

Johannes

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

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

[Johannes Ranke]

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

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

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

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

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

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

srf.gl> library(MASS)  # for eqscplot

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

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

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

And in fact, nlme, is affected as well:

> library(nlme)
> example(nlme)

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

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

Cheers,

Johannes

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

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

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

[Johannes Ranke]

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

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

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