Re: [R-sig-Debian] Solution to apt-key depreciation
For the debian usecase at least, it might be worth looking at extrepo [1][2]. It maintains a list of known external apt repositories, along with the correct config and keys, which can then be enabled with a single command. I don't know how well it works downstream with Ubuntu, but for debian at least, getting a definition for CRAN added would let people who want to enable it do so. Gordon [1]: https://grep.be/blog/en/computer/debian/Announcing_extrepo/ [2]: https://salsa.debian.org/extrepo-team/extrepo-data On Thu, Mar 18, 2021 at 09:03:12AM +0100, Johannes Ranke wrote: > 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 mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R, OpenBLAS and OMP_NUM_THREADS
On 04/08/16 06:39, Ei-ji Nakama wrote:
> Hi,
> I was be half asleep in the heat ...
>
> 2016-08-04 0:04 GMT+09:00 Dirk Eddelbuettel <e...@debian.org>:
>>
>> On 3 August 2016 at 16:45, Gordon Ball wrote:
>> | On 02/08/16 03:10, Ei-ji Nakama wrote:
>> | > Hi,
>> | >
>> | > Create /etc/profile.d/openblas.sh.
>> | > Write the following during in this file.
>> | > OPENBLAS_NUM_THREADS = 1
>> | > export OPENBLAS_NUM_THREADS
>> | >
>> | > OPENBLAS_NUM_THREADS environment variable does not affect the
>> OMP_NUM_THREADS.
>>
>> Thumbs up to using /etc/profile.d/ -- very nice hook.
>>
>> | Unfortunately neither this nor anything else I've tried today appears to
>> | set the variable for sessions started through RStudio server (which may
>> | or may not be an appropriate issue here).
>> |
>> | It appears that the rstudio server spawns sessions with a new minimal
>> | environment (rstudio::core::system::launchChildProcess) and no option to
>> | inject or inherit variables. (Various methods of controlling the session
>> | environment are documented in the pro/paid version manual [1], but are
>> | not implemented in the public codebase - enterprise features, presumably).
>> |
>> | Hence approaches like setting the environment in the
>> | rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
>> | service profile including pam_env.so (to load the setting from
>> | /etc/environment) don't work. It would probably be possible to work
>> | round this by creating a small binary wrapper for the rsession binary
>> | which sets the environment, but it would make a mess of the packaging.
>> |
>> | So I've gone with an `/etc/R/Rprofile.site` containing
>> |
>> | local({
>> | if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1)
>> | })
>> |
>> | which does mean people get this library loaded in all their sessions but
>> | that doesn't seem to cause any particular trouble (yet).
>
> In this case, hook of the / etc / R / Rprofile.site would be best
>
> local({
> if(require("RhpcBLASctl", quietly=TRUE)){
> if(Sys.getenv("OPENBLAS_NUM_THREADS")=="" &
> Sys.getenv("OMP_NUM_THREADS")=="")
> blas_set_num_threads(1)
> }
> })
>
> $ OMP_NUM_THREADS=4 R -q -e 'library(RhpcBLASctl);blas_get_num_procs()'
>> library(RhpcBLASctl);blas_get_num_procs()
> [1] 4
>
> maybe confusion would be minimal.
Yes, that looks a bit better, allowing it to be overridden by
environment variables.
The other thing that occurred to me was whether this setting would be
inherited by child R processes (otherwise you'd get a massive thread
explosion when running something intentionally parallel), but it looks
like at least the builtin `parallel` library does retain the BLAS
settings of the parent (presumably since it uses `fork()`).
It is maybe still worth setting `Sys.setenv(OPENBLAS_NUM_THREADS=1)`
along with the `blas_set_num_threads(1)` call in case there are any
multicore libraries for which this doesn't apply.
(Also, it hadn't occurred to me earlier but I realise you're the author
of RhpcBLASctl - appreciate it)
Gordon
>
>> I was just working on something that needed environment variables (for
>> automating tests to a database backend) and populating
>>
>>/etc/R/Renviron.site
>>
>> worked for me. Otherwise explicit code in Rprofile.site is of course good, as
>> is conditioning. I do that too for some use cases.
>
> I often forget to have set it...orz
>
>> Dirk
>>
>> --
>> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
>
>
___
R-SIG-Debian mailing list
R-SIG-Debian@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-debian
Re: [R-sig-Debian] R, OpenBLAS and OMP_NUM_THREADS
On 02/08/16 03:10, Ei-ji Nakama wrote:
> Hi,
>
> Create /etc/profile.d/openblas.sh.
> Write the following during in this file.
> OPENBLAS_NUM_THREADS = 1
> export OPENBLAS_NUM_THREADS
>
> OPENBLAS_NUM_THREADS environment variable does not affect the OMP_NUM_THREADS.
>
Thanks for the response.
This works fine for R run from the command line (as does setting the
same variable in `/etc/environment`), providing a fresh login is made.
Unfortunately neither this nor anything else I've tried today appears to
set the variable for sessions started through RStudio server (which may
or may not be an appropriate issue here).
It appears that the rstudio server spawns sessions with a new minimal
environment (rstudio::core::system::launchChildProcess) and no option to
inject or inherit variables. (Various methods of controlling the session
environment are documented in the pro/paid version manual [1], but are
not implemented in the public codebase - enterprise features, presumably).
Hence approaches like setting the environment in the
rstudio-server.service systemd unit, or creating a /etc/pam.d/rstudio
service profile including pam_env.so (to load the setting from
/etc/environment) don't work. It would probably be possible to work
round this by creating a small binary wrapper for the rsession binary
which sets the environment, but it would make a mess of the packaging.
So I've gone with an `/etc/R/Rprofile.site` containing
local({
if (require("RhpcBLASctl", quietly=TRUE)) blas_set_num_threads(1)
})
which does mean people get this library loaded in all their sessions but
that doesn't seem to cause any particular trouble (yet).
Gordon
[1]: docs.rstudio.com/ide/server-pro/r-sessions.html
>
> 2016-08-01 20:06 GMT+09:00 Gordon Ball <gor...@chronitis.net>:
>> What is the correct way to globally configure R to default to single (or
>> at least, << NUM_CPUS) threaded operation?
>>
>>
>> Using R 3.3.1 (both in debian unstable or using the CRAN repository for
>> xenial) with OpenBLAS (0.2.18) defaults to using one thread per
>> available CPU, which isn't ideal for machines more than a couple of CPUs.
>>
>> Setting the environment (OMP_NUM_THREADS or OPENBLAS_NUM_THREADS) in the
>> shell works:
>>
>> $ OMP_NUM_THREADS=1 R
>>> Sys.getenv("OMP_NUM_THREADS")
>> [1] "1"
>>> system.time({x <- replicate(5e3, rnorm(5e3)); tcrossprod(x) })
>> [runs in one thread]
>>
>> but adding it to /etc/R/Renviron.site doesn't:
>>
>> $ R
>>> Sys.getenv("OMP_NUM_THREADS")
>> [1] "1"
>>> system.time({x <- replicate(5e3, rnorm(5e3)); tcrossprod(x) })
>> [runs multi-threaded]
>>
>> (nor does setting the variable at runtime with `Sys.setenv`)
>>
>> Presumably Renviron is read after the library is already loaded and so
>> the environment variable is set too late to matter.
>>
>>
>>
>>
>> I can think of these solutions, but none of them are ideal:
>>
>> * remove OpenBLAS (but even single threaded it performs quite a lot
>> better than the basic libblas)
>>
>> * set OMP_NUM_THREADS globally in people's shells with the system
>> bashrc (but this doesn't work for non-shell, RStudio server sessions)
>>
>> * use a library like RhpcBLASctl to set the number of threads in the
>> global Rprofile
>>
>> * compile a custom openblas with threading disabled, or at least a
>> small default number of threads
>>
>>
>> Any better ideas?
>>
>>
>> Thanks
>>
>> Gordon
>>
>> ___
>> R-SIG-Debian mailing list
>> R-SIG-Debian@r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-debian
>
>
>
___
R-SIG-Debian mailing list
R-SIG-Debian@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-debian
