Can anyone confirm if this has been fixed? I would like to remove the _R_CHECK_SYSTEM_CLOCK_=0 but would like to know in advance.
Thanks
Rainer
On 8 Mar 2019, at 10:03, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote:
I think you can put this in appveyor.yml:
environment:
_R_CHECK_SYSTEM_CLOCK_: 0
before the "build_script" section.
Gabor
On Fri, Mar 8, 2019 at 5:15 AM Marta Kara? <marta.karass at gmail.com> wrote:
I have faced the same problem with using http://worldclockapi.com/. I dealt
with Travis fail (because warnings are changed to errors) after setting
environment variable _R_CHECK_SYSTEM_CLOCK_ to zero, as adviced above.
How I deal with appveyor fail for the same reason? It may be seen in my
built output here (link)
<https://ci.appveyor.com/project/martakarass/adept/build/job/vq4ncvg6qbh526u4>.
I googled but was unable to find the equivalent of
env:
- _R_CHECK_SYSTEM_CLOCK_=0
for appveyor. Would appreciate any hint a lot - thank you!
Marta
On Thu, Mar 7, 2019 at 2:53 PM Hadley Wickham <h.wickham at gmail.com> wrote:
It appears that the code was added by BDR on 2 Sep 2018:
I assume we are seeing failing R CMD check results because
http://worldclockapi.com/api/json/utc/now has recently died.
It would be appreciated if someone from R-core could look into this as
it's currently causing all R-devel builds on travis to fail.
Hadley
On Thu, Mar 7, 2019 at 9:32 AM Bob Rudis <bob at rud.is> wrote:
(a) that's gd news (#ty)
(b) genuine apologies for my confusion
(c) why was the introduction of reliance on a third-party site even
On Mar 7, 2019, at 09:32, peter dalgaard <pdalgd at gmail.com> wrote:
It's not "stealth fixed"! It was never there... (on the release
The timestamp checking code is still present in R-devel. I presume
something needs to be done about the breakage.
On 7 Mar 2019, at 14:38 , Bob Rudis <bob at rud.is> wrote:
It's fixed in the RC that's GA on the 11th.
I think perhaps "stealth fixed" may be more appropro since it's not
in SVN logs, Bugzilla nor noted prominently in any of the various NEWS*
files.
Then there's the "why was the core R installation using a third
party, non-HTTPS site for this to begin with".
And, in other news, there are tests in the R source that rely on a
check of `foo.bar` for connectivity. `.bar` is a valid domain and `foo.bar`
is registered. Thankfully there's no current IP address associated with it.
Anything under `*.invalid` (https://en.wikipedia.org/wiki/.invalid) might
be a better choice as well since that won't break the reason for the
connectivity checks and won't arbitrarily send telemetry pings to third
parties in the even anyone outside of R Core decides to run the tests (say,
when patching something in R).
On Mar 7, 2019, at 07:54, Rainer M Krug <Rainer at krugs.de> wrote:
I can confirm the same when checking on travis with r-devel.
And thanks for the tip with
env:
- _R_CHECK_SYSTEM_CLOCK_=0
In .travis.yml
Seems to be working now
Rainer
On 7 Mar 2019, at 12:48, Ralf Herold <ralf.herold at mailbox.org>
Dear All,
Checking a new package under development produces a warning in a
local R-devel MS Windows environment (output below).
Building it with R-devel on Travis fails (because warnings are
changed to errors), but is successful when setting environment variable
_R_CHECK_SYSTEM_CLOCK_ to zero.
No issue occurs when checking and building with R-stable and
R-oldrel on Travis, or with any R version on win-builder.r-project.org.
however seems out of service ("The web app you have attempted to reach is
currently stopped and does not accept any requests."). This is referenced
in the main function for R CMD check (
https://svn.r-project.org/R/trunk/src/library/tools/R/check.R) and may
concern more R-devel than R-package-devel. I am posting here to check if
the issue was noticed by other package developers and to check the impact.
Thanks for any suggestions.
Best regards,
Ralf
PS C:\Users\username> & 'C:\Program Files\R\R-devel\bin\R.exe'
CMD check E:\mypackage_0.1.2.3.tar.gz --as-cran
* using log directory 'C:/Users/username/ctrdata.Rcheck'
* using R Under development (unstable) (2019-03-05 r76200)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* using option '--as-cran'
[...]
* checking package directory ... OK
* checking for future file timestamps ...Warning in file(con,
HTTP status was '403 Site Disabled'
WARNING
unable to verify current time
* checking 'build' directory ? OK
[...]
## Ralf Herold
## mailto: ralf.herold at mailbox.org [S/MIME]
## https://paediatricdata.eu/