I've been using pkgdown::deploy_to_branch() for awhile now to publish my docs on the gh-pages branch of my repo, but as of this week it stopped working and has started giving me the following error:
Error: callr subprocess failed: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Type .Last.error.trace to see where the error occurred
7.
stop(cond) at errors.R#275
6.
throw(newerr, parent = remerr[[2]]) at result.R#70
5.
get_result(output = out, options) at eval.R#176
4.
callr::r(function(..., crayon_enabled, crayon_colors, pkgdown_internet) {
options(crayon.enabled = crayon_enabled, crayon.colors = crayon_colors,
pkgdown.internet = pkgdown_internet)
pkgdown::build_site(...) ... at build.r#432
3.
build_site_external(pkg = pkg, examples = examples, run_dont_run = run_dont_run,
seed = seed, lazy = lazy, override = override, preview = preview,
devel = devel) at build.r#385
2.
build_site(pkg, devel = FALSE, preview = FALSE, install = FALSE,
...) at deploy-site.R#172
1.
pkgdown::deploy_to_branch()
When I tried to debug and got deeper into the function, this is the error I got trying to call build_site() directly:
Admittedly, authentication of all sorts is consistently baffling to me, but what has me really baffled is that my auth with github seems to be working in all other ways. I have it cloned with SSH. I can push and pull to my heart's content when I do it manually or through the RStudio GUI. Also, I can't figure out anything that has changed since the time when this was working.
Anyway, any help is much appreciated. I've also looked at a few other issues that came up when I googled the error (this one, for example) but none of them seem to be relevant to my situation where git is working fine except in this call.
Some details:
I'm on Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1054-aws x86_64)
R 4.0.3
pkgdown 1.6.1
I tried this with two different repos (1 and 2, both of which were previously working with this same command and the same OS/versions/etc ^
Let me know if there are any more details that would help. Thanks!
Well, it turns out this had nothing to do with pkgdown. Sorry for blaming you pkgdown!
The issue had something to do with this which I was lucky enough to stumble onto the exact day that it happened. A coworker told me to run the following snippet and it fixed everything.
sudo apt-get update ; sudo apt-get install -y ca-certificates
Related
I'm hitting an SSL error in a ubuntu session of GitHub actions that I'm not sure I understand. these are the three lines of R code in the GitHub action that works on windows and macOS but fail on Ubuntu:
tf <- tempfile()
this_url <- "https://webfs.oecd.org/piaac/puf-data/SAS/SAS7BDAT/prgusap1_2012.sas7bdat"
download.file( this_url , tf , mode = 'wb' )
You can see the windows/macOS successes and ubuntu failures at: https://github.com/asdfree/piaac/actions/runs/4130891484
From what I've found elsewhere, it looks like I need to use OpenSSL on the Linux runner of the GitHub Actions.
I found some examples of how to use OpenSSL within an r.yml file here: https://github.com/jeroen/testbug/blob/929151a0f19ed029d0ae34a7b3661d453974de53/.github/workflows/test.yaml
But my attempt to modify the r.yml file didn't seem to solve the issue: https://github.com/asdfree/piaac/commit/9eb93f8ac8c2eae61300364337b6a357ba56d9e7
i've also attempted three alternatives to download.file() -- ubuntu still fails where windows and macOS succeeds. the error here shows up as unsafe legacy renegotiation disabled even when i use ssl.verifypeer=FALSE
https://github.com/asdfree/piaac/commit/07cb4808a4d027f28d6e8cefdf5af09493dcb309
https://github.com/asdfree/piaac/actions/runs/4131647361
https://github.com/asdfree/piaac/commit/468588f6813cfe734d7b11b875070b331189cbc0
https://github.com/asdfree/piaac/actions/runs/4131695976
https://github.com/asdfree/piaac/commit/77e228ef72fc3a781dba51c23ceb9f54f0fac286
https://github.com/asdfree/piaac/actions/runs/4131784227
Any advice about how to work around this issue would be appreciated. Thanks!
I successfully use mypyc in my project and it has performed well until just a couple days ago. I now get the following error:
File "mypyc/__main__.py", line 18, in <module>
KeyError: '__file__'
Line 18 above, i.e., the line that is failing, is just
base_path = os.path.join(os.path.dirname(__file__), '..')
which I wouldn't expect to fail. I am in my venv virtualenv when I execute mypyc using the same command as has always worked before.
I thought perhaps a regression was introduced in mypyc so I used git to go back in time to see if that line had changed in any recent version of mypy, but it hadn't.
I also tried downgrading mypy to an older version that worked before but that version also failed with the same error. To be sure it wasn't being experienced by others I also checked the issues at the mypy repo on github and did a search for __file__ to see if that part of the error message showed up and it didn't. Perhaps it is some weird issue with my environment?
I experience the issue with venv virtualenvs created with Python 3.10, 3.10.1 but also 3.9.9 too. It worked fine on Python 3.10 before. Any ideas on what to investigate next?
I am struggling with installing a package from a GitLab repository on a Windows computer.
I found different hints but still have problems to install my package from GitLab. First of all, I generated a public and private key with puttygen.exe. The files need to be changed afterwards, I had to remove comments and stuff so they look like my the file on my Unix system. So now, both public and private key files have just a single line.
I tried to install my package via devtools::install_git which takes very long and I get the error message
Error: Failed to install 'unknown package' from Git:
Error in 'git2r_remote_ls': Failed to authenticate SSH session: Unable to send userauth-publickey request
And with devtools::install_gitlab I get a different error message and I somehow have the feeling, the link which gets generated doesn't fit to my GitLab server.
Error: Failed to install 'unknown package' from GitLab:
cannot open URL 'https://gitlab.rlp.net/api/v4/projects/madejung%2FMQqueue.git/repository/files/DESCRIPTION/raw?ref=master'
My complete code to test at the moment is
creds <- git2r::cred_ssh_key(publickey="~/.ssh/id_rsa_gitlab.pub",
privatekey="~/.ssh/id_rsa_gitlab")
devtools::install_git(
url='git#gitlab.rlp.net:madejung/MQqueue.git',
quiet=FALSE,
credentials=creds)
devtools::install_gitlab(
repo='madejung/MQqueue.git',
host='gitlab.rlp.net',
quiet=FALSE,
credentials=creds
)
My id_rsa_gitlab.pub file looks like this and is just a single line:
ssh-rsa AAAA....fiwbw== rsa-key-20200121
The id_rsa_gitlab file has just the code:
AAABA.....3WNSIAGE=
Update
On my Mac system it works as expected after installing the libssh2 library via homebrew and and recompiling git2r with install.packages("git2r", type = "source").
So the working code on my machine is:
creds <- git2r::cred_ssh_key(publickey="~/.ssh/id_rsa_gitlab.rlp.net.pub",
privatekey="~/.ssh/id_rsa_gitlab.rlp.net")
devtools::install_git(
url='git#gitlab.rlp.net:madejung/MQqueue.git',
quiet=FALSE,
credentials=creds
)
For some strange reason, the devtools::install_git call needs about a minute to fail in the end. I have no idea where the problem here is.
After struggling for almost a day, I found a solution I can live with...
I first created a PAT (Personal Access Token) in my gitlab account and granted full API access. For some reason the read_only access didn't worked and I am now tired to figure out what the problem is.
After this I had still problems to install my package and for some reason, the wininet setting for downloading doesn't work.
I used the command capabilities("libcurl") to check if libcurl is available on my windows, which was and tried to overwrite wininet to libcurl by using method='libcurl' in the install function. Somehow, this was not enough so I overwrote the options variable download.file.method directly.
options("download.file.method"='libcurl')
devtools::install_gitlab(
repo='madejung/MQqueue',
auth_token='Ho...SOMETHING...xugzb',
host='gitlab.rlp.net',
quiet=FALSE, force=TRUE
)
PHP v7.2.3
PHP Unit 8.2.3
Codeception 3.0.2
When I try to run tests I get the following error:
Declaration of
Codeception\Test\Test::run(?PHPUnit\Framework\TestResult $result =
NULL) must be compatible with
PHPUnit\Framework\Test::run(?PHPUnit\Framework\TestResult $result =
NULL): PHPUnit\Framework\TestResult in
/var/com/vendor/codeception/codeception/src/Codeception/Test/Test.php
on line 18
When I look at the definition of PHPUnit\Framework\Test::run I see it specifies a return type but Codeception\Test\Test::run does not and this would appear to be the problem.
I've checked back through the version history of both of these files in the respective git repos and it seem these files have been this way for many versions.
After much searching it doesn't seem anyone else has posted the issue which makes me think I'm missing some key insight.
Any light shed on this issue would be much appreciated, thanks!
In the end a fresh install of Symfony latest version and Codeception presented a working solution.
Since this was initially a port from another symfony 3 application (with an older version of codeception) it's likely that there was a misconfig or incompatible package.
The other possible cause which occurred to me later is that the cli for codeception in previous versions of symfony was run from a general bin directory 'bin/codecept' and now we run directly from 'vendor/bin/codecept' its possible that my CI script was referencing an outdated cli.
I must correct some errors in my package antaresProcessing.
I want to reproduce these errors before.
Here, you can see CRAN Checks
I don't have debian OS.
I tried rhub, you can see that the results are ok
I tried to execute these functions, all are fine.
rhub::check_for_cran(platform = 'debian-gcc-devel')
rhub::check_for_cran(platform = 'debian-gcc-patched')
rhub::check_for_cran(platform = 'debian-gcc-release')