R SIG Debian - Apr 2017 - R installation problems on Linux Mint 18.1 via jessie-cran3

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 at 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
<https://keyring.debian.org/creating-key.html> *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 cases it is better to use the key ID.*

*#group mynames = paige 0x12345678 joe patti*

*# Lock the file only once for the lifetime of a process.  If you do*
*# not define this, the lock will be obtained and released every time*
*# it is needed, which is usually preferable.*

*#lock-once*

*# GnuPG can send and receive keys to and from a keyserver.  These*
*# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP*
*# support).*
*#*
*# Example HKP keyserver:*
*#      hkp://keys.gnupg.net <http://keys.gnupg.net>*
*#      hkp://subkeys.pgp.net <http://subkeys.pgp.net>*
*#*
*# Example email keyserver:*
*#      mailto:pgp-public-keys at keys.pgp.net <pgp-public-keys at
keys.pgp.net>*
*#*
*# Example LDAP keyservers:*
*#      ldap://keyserver.pgp.com <http://keyserver.pgp.com>*
*#*
*# Regular URL syntax applies, and you can set an alternate port*
*# through the usual method:*
*#      hkp://keyserver.example.net:22742
<http://keyserver.example.net:22742>*
*#*
*# Most users just set the name and type of their preferred keyserver.*
*# Note that most servers (with the notable exception of*
*# ldap://keyserver.pgp.com <http://keyserver.pgp.com>) synchronize
changes
with each other.  Note*
*# also that a single server name may actually point to multiple*
*# servers via DNS round-robin.  hkp://keys.gnupg.net
<http://keys.gnupg.net> is an example of*
*# such a "server", which spreads the load over a number of physical*
*# servers.  To see the IP address of the server actually used, you may use*
*# the "--keyserver-options debug".*

*keyserver hkp://keys.gnupg.net <http://keys.gnupg.net>*
*#keyserver mailto:pgp-public-keys at keys.nl.pgp.net
<pgp-public-keys at keys.nl.pgp.net>*
*#keyserver ldap://keyserver.pgp.com <http://keyserver.pgp.com>*

*# Common options for keyserver functions:*
*#*
*# include-disabled : when searching, include keys marked as
"disabled"*
*#                    on the keyserver (not all keyservers support this).*
*#*
*# no-include-revoked : when searching, do not include keys marked as*
*#                      "revoked" on the keyserver.*
*#*
*# verbose : show more information as the keys are fetched.*
*#           Can be used more than once to increase the amount*
*#           of information shown.*
*#*
*# use-temp-files : use temporary files instead of a pipe to talk to the*
*#                  keyserver.  Some platforms (Win32 for one) always*
*#                  have this on.*
*#*
*# keep-temp-files : do not delete temporary files after using them*
*#                   (really only useful for debugging)*
*#*
*# http-proxy="proxy" : set the proxy to use for HTTP and HKP
keyservers.*
*#                      This overrides the "http_proxy" environment
variable,*
*#                      if any.*
*#*
*# auto-key-retrieve : automatically fetch keys as needed from the
keyserver*
*#                     when verifying signatures or when importing keys
that*
*#                     have been revoked by a revocation key that is not*
*#                     present on the keyring.*
*#*
*# no-include-attributes : do not include attribute IDs (aka "photo
IDs")*
*#                         when sending keys to the keyserver.*

*#keyserver-options auto-key-retrieve*

*# Display photo user IDs in key listings*

*# list-options show-photos*

*# Display photo user IDs when a signature from a key with a photo is*
*# verified*

*# verify-options show-photos*

*# Use this program to display photo user IDs*
*#*
*# %i is expanded to a temporary file that contains the photo.*
*# %I is the same as %i, but the file isn't deleted afterwards by GnuPG.*
*# %k is expanded to the key ID of the key.*
*# %K is expanded to the long OpenPGP key ID of the key.*
*# %t is expanded to the extension of the image (e.g. "jpg").*
*# %T is expanded to the MIME type of the image (e.g. "image/jpeg").*
*# %f is expanded to the fingerprint of the key.*
*# %% is %, of course.*
*#*
*# If %i or %I are not present, then the photo is supplied to the*
*# viewer on standard input.  If your platform supports it, standard*
*# input is the best way to do this as it avoids the time and effort in*
*# generating and then cleaning up a secure temp file.*
*#*
*# If no photo-viewer is provided, GnuPG will look for xloadimage, eog,*
*# or display (ImageMagick).  On Mac OS X and Windows, the default is*
*# to use your regular JPEG image viewer.*
*#*
*# Some other viewers:*
*# photo-viewer "qiv %i"*
*# photo-viewer "ee %i"*
*#*
*# This one saves a copy of the photo ID in your home directory:*
*# photo-viewer "cat > ~/photoid-for-key-%k.%t"*
*#*
*# Use your MIME handler to view photos:*
*# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f
GnuPG"*

*# Passphrase agent*
*#*
*# We support the old experimental passphrase agent protocol as well as*
*# the new Assuan based one (currently available in the "newpg"
package*
*# at ftp.gnupg.org/gcrypt/alpha/aegypten/
<http://ftp.gnupg.org/gcrypt/alpha/aegypten/>).  To make use of the
agent,*
*# you have to run an agent as daemon and use the option*
*#*
*# For Ubuntu we now use-agent by default to support more automatic*
*# use of GPG and S/MIME encryption by GUI programs.  Depending on the*
*# program, users may still have to manually decide to install gnupg-agent.*

*use-agent*

*# which tries to use the agent but will fallback to the regular mode*
*# if there is a problem connecting to the agent.  The normal way to*
*# locate the agent is by looking at the environment variable*
*# GPG_AGENT_INFO which should have been set during gpg-agent startup.*
*# In certain situations the use of this variable is not possible, thus*
*# the option*
*# *
*# --gpg-agent-info=<path>:<pid>:1*
*#*
*# may be used to override it.*

*# Automatic key location*
*#*
*# GnuPG can automatically locate and retrieve keys as needed using the*
*# auto-key-locate option.  This happens when encrypting to an email*
*# address (in the "user at example.com <user at example.com>"
form), and there
are no*
*# user at example.com <user at example.com> keys on the local keyring. 
This
option takes the*
*# following arguments, in the order they are to be tried:*
*# *
*# cert = locate a key using DNS CERT, as specified in RFC-4398.*
*#        GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)*
*#        CERT methods.*
*#*
*# pka = locate a key using DNS PKA.*
*#*
*# ldap = locate a key using the PGP Universal method of checking*
*#        "ldap://keys.(thedomain)".  For example, encrypting to*
*#        user at example.com <user at example.com> will check
ldap://keys.example.com <http://keys.example.com>.*
*#*
*# keyserver = locate a key using whatever keyserver is defined using*
*#             the keyserver option.*
*#*
*# You may also list arbitrary keyservers here by URL.*
*#*
*# Try CERT, then PKA, then LDAP, then hkp://subkeys.net
<http://subkeys.net>:*
*#auto-key-locate cert pka ldap hkp://subkeys.pgp.net
<http://subkeys.pgp.net>*
*personal-digest-preferences SHA256*
*cert-digest-algo SHA256*
*default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
CAST5 ZLIB BZIP2 ZIP Uncompressed*

It didn't work and I simply get the same SHA1 weak algorithm error when
running -sudo apt-get update- or -sudo apt update-. (Why is this issue not
mentioned at all here <https://cran.r-project.org/> and why have users
like
me had to go ferreting for it, amongst other things?)

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.

-- 
Yours with thanks,
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]]

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 at 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
> <https://keyring.debian.org/creating-key.html> *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 cases it is better to use the key ID.*
>
> *#group mynames = paige 0x12345678 joe patti*
>
> *# Lock the file only once for the lifetime of a process.  If you do*
> *# not define this, the lock will be obtained and released every time*
> *# it is needed, which is usually preferable.*
>
> *#lock-once*
>
> *# GnuPG can send and receive keys to and from a keyserver.  These*
> *# servers can be HKP, email, or LDAP (if GnuPG is built with LDAP*
> *# support).*
> *#*
> *# Example HKP keyserver:*
> *#      hkp://keys.gnupg.net <http://keys.gnupg.net>*
> *#      hkp://subkeys.pgp.net <http://subkeys.pgp.net>*
> *#*
> *# Example email keyserver:*
> *#      mailto:pgp-public-keys at keys.pgp.net <pgp-public-keys at
keys.pgp.net>*
> *#*
> *# Example LDAP keyservers:*
> *#      ldap://keyserver.pgp.com <http://keyserver.pgp.com>*
> *#*
> *# Regular URL syntax applies, and you can set an alternate port*
> *# through the usual method:*
> *#      hkp://keyserver.example.net:22742
> <http://keyserver.example.net:22742>*
> *#*
> *# Most users just set the name and type of their preferred keyserver.*
> *# Note that most servers (with the notable exception of*
> *# ldap://keyserver.pgp.com <http://keyserver.pgp.com>) synchronize
changes
> with each other.  Note*
> *# also that a single server name may actually point to multiple*
> *# servers via DNS round-robin.  hkp://keys.gnupg.net
> <http://keys.gnupg.net> is an example of*
> *# such a "server", which spreads the load over a number of
physical*
> *# servers.  To see the IP address of the server actually used, you may
use*
> *# the "--keyserver-options debug".*
>
> *keyserver hkp://keys.gnupg.net <http://keys.gnupg.net>*
> *#keyserver mailto:pgp-public-keys at keys.nl.pgp.net
> <pgp-public-keys at keys.nl.pgp.net>*
> *#keyserver ldap://keyserver.pgp.com <http://keyserver.pgp.com>*
>
> *# Common options for keyserver functions:*
> *#*
> *# include-disabled : when searching, include keys marked as
"disabled"*
> *#                    on the keyserver (not all keyservers support this).*
> *#*
> *# no-include-revoked : when searching, do not include keys marked as*
> *#                      "revoked" on the keyserver.*
> *#*
> *# verbose : show more information as the keys are fetched.*
> *#           Can be used more than once to increase the amount*
> *#           of information shown.*
> *#*
> *# use-temp-files : use temporary files instead of a pipe to talk to the*
> *#                  keyserver.  Some platforms (Win32 for one) always*
> *#                  have this on.*
> *#*
> *# keep-temp-files : do not delete temporary files after using them*
> *#                   (really only useful for debugging)*
> *#*
> *# http-proxy="proxy" : set the proxy to use for HTTP and HKP
keyservers.*
> *#                      This overrides the "http_proxy"
environment
> variable,*
> *#                      if any.*
> *#*
> *# auto-key-retrieve : automatically fetch keys as needed from the
> keyserver*
> *#                     when verifying signatures or when importing keys
> that*
> *#                     have been revoked by a revocation key that is not*
> *#                     present on the keyring.*
> *#*
> *# no-include-attributes : do not include attribute IDs (aka "photo
IDs")*
> *#                         when sending keys to the keyserver.*
>
> *#keyserver-options auto-key-retrieve*
>
> *# Display photo user IDs in key listings*
>
> *# list-options show-photos*
>
> *# Display photo user IDs when a signature from a key with a photo is*
> *# verified*
>
> *# verify-options show-photos*
>
> *# Use this program to display photo user IDs*
> *#*
> *# %i is expanded to a temporary file that contains the photo.*
> *# %I is the same as %i, but the file isn't deleted afterwards by
GnuPG.*
> *# %k is expanded to the key ID of the key.*
> *# %K is expanded to the long OpenPGP key ID of the key.*
> *# %t is expanded to the extension of the image (e.g. "jpg").*
> *# %T is expanded to the MIME type of the image (e.g.
"image/jpeg").*
> *# %f is expanded to the fingerprint of the key.*
> *# %% is %, of course.*
> *#*
> *# If %i or %I are not present, then the photo is supplied to the*
> *# viewer on standard input.  If your platform supports it, standard*
> *# input is the best way to do this as it avoids the time and effort in*
> *# generating and then cleaning up a secure temp file.*
> *#*
> *# If no photo-viewer is provided, GnuPG will look for xloadimage, eog,*
> *# or display (ImageMagick).  On Mac OS X and Windows, the default is*
> *# to use your regular JPEG image viewer.*
> *#*
> *# Some other viewers:*
> *# photo-viewer "qiv %i"*
> *# photo-viewer "ee %i"*
> *#*
> *# This one saves a copy of the photo ID in your home directory:*
> *# photo-viewer "cat > ~/photoid-for-key-%k.%t"*
> *#*
> *# Use your MIME handler to view photos:*
> *# photo-viewer "metamail -q -d -b -c %T -s 'KeyID 0x%k' -f
GnuPG"*
>
> *# Passphrase agent*
> *#*
> *# We support the old experimental passphrase agent protocol as well as*
> *# the new Assuan based one (currently available in the "newpg"
package*
> *# at ftp.gnupg.org/gcrypt/alpha/aegypten/
> <http://ftp.gnupg.org/gcrypt/alpha/aegypten/>).  To make use of the
agent,*
> *# you have to run an agent as daemon and use the option*
> *#*
> *# For Ubuntu we now use-agent by default to support more automatic*
> *# use of GPG and S/MIME encryption by GUI programs.  Depending on the*
> *# program, users may still have to manually decide to install
gnupg-agent.*
>
> *use-agent*
>
> *# which tries to use the agent but will fallback to the regular mode*
> *# if there is a problem connecting to the agent.  The normal way to*
> *# locate the agent is by looking at the environment variable*
> *# GPG_AGENT_INFO which should have been set during gpg-agent startup.*
> *# In certain situations the use of this variable is not possible, thus*
> *# the option*
> *# *
> *# --gpg-agent-info=<path>:<pid>:1*
> *#*
> *# may be used to override it.*
>
> *# Automatic key location*
> *#*
> *# GnuPG can automatically locate and retrieve keys as needed using the*
> *# auto-key-locate option.  This happens when encrypting to an email*
> *# address (in the "user at example.com <user at
example.com>" form), and there
> are no*
> *# user at example.com <user at example.com> keys on the local
keyring.  This
> option takes the*
> *# following arguments, in the order they are to be tried:*
> *# *
> *# cert = locate a key using DNS CERT, as specified in RFC-4398.*
> *#        GnuPG can handle both the PGP (key) and IPGP (URL + fingerprint)*
> *#        CERT methods.*
> *#*
> *# pka = locate a key using DNS PKA.*
> *#*
> *# ldap = locate a key using the PGP Universal method of checking*
> *#        "ldap://keys.(thedomain)".  For example, encrypting to*
> *#        user at example.com <user at example.com> will check
> ldap://keys.example.com <http://keys.example.com>.*
> *#*
> *# keyserver = locate a key using whatever keyserver is defined using*
> *#             the keyserver option.*
> *#*
> *# You may also list arbitrary keyservers here by URL.*
> *#*
> *# Try CERT, then PKA, then LDAP, then hkp://subkeys.net
> <http://subkeys.net>:*
> *#auto-key-locate cert pka ldap hkp://subkeys.pgp.net
> <http://subkeys.pgp.net>*
> *personal-digest-preferences SHA256*
> *cert-digest-algo SHA256*
> *default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
> CAST5 ZLIB BZIP2 ZIP Uncompressed*
>
> It didn't work and I simply get the same SHA1 weak algorithm error when
> running -sudo apt-get update- or -sudo apt update-. (Why is this issue not
> mentioned at all here <https://cran.r-project.org/> and why have
users like
> me had to go ferreting for it, amongst other things?)
>
> 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.
>

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 <https://cran.r-project.org/> 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 at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-debian