It seems to have gotten worse at the moment (package checking on my
local machine hangs at this step). Sorry if this is cross-threading.
On 3/19/19 7:11 AM, Rainer M Krug wrote:
Can anyone confirm if this has been fixed? I would like to remove the
_R_CHECK_SYSTEM_CLOCK_=0 but would like to
Thanks - will do so.
Rainer
> On 19 Mar 2019, at 12:14, Gábor Csárdi wrote:
>
> AFAICT you can still get a NOTE about it, so I would just leave the
> workaround in place:
> https://github.com/wch/r-source/blob/87110b6b9e20c324c44766cc8f5816580f681a2a/src/library/tools/R/check.R#L457
>
> G.
>
AFAICT you can still get a NOTE about it, so I would just leave the
workaround in place:
https://github.com/wch/r-source/blob/87110b6b9e20c324c44766cc8f5816580f681a2a/src/library/tools/R/check.R#L457
G.
On Tue, Mar 19, 2019 at 11:11 AM Rainer M Krug wrote:
>
> Can anyone confirm if this has
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 wrote:
>
> I think you can put this in appveyor.yml:
>
> environment:
> _R_CHECK_SYSTEM_CLOCK_: 0
>
>
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ś wrote:
>
> I have faced the same problem with using http://worldclockapi.com/. I dealt
> with Travis fail (because warnings
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
As of ~7 hours ago, the warning is suppressed:
https://github.com/wch/r-source/commit/31ee14c620eb1b939acd322f3b5617f998aab8e8
(But the service still doesn't work)
Hadley
On Thu, Mar 7, 2019 at 11:03 AM Hadley Wickham wrote:
>
> It appears that the code was added by BDR on 2 Sep 2018:
>
It appears that the code was added by BDR on 2 Sep 2018:
https://github.com/wch/r-source/commit/d839b1e04e173f90b51ad809ef0bdb18095abe6f
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
(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 under
consideration?
> On Mar 7, 2019, at 09:32, peter dalgaard wrote:
>
> It's not "stealth fixed"! It was never there... (on the release branch)
>
> The
It's not "stealth fixed"! It was never there... (on the release branch)
The timestamp checking code is still present in R-devel. I presume something
needs to be done about the breakage.
- pd
> On 7 Mar 2019, at 14:38 , Bob Rudis wrote:
>
> It's fixed in the RC that's GA on the 11th.
>
> I
Many thanks for clear words, boB! This closes the issue for me.
(I hope CRAN submissions are not impacted by the issue.)
Will remove the environment variable once the new version is available.
Best,
Ralf
> Am 07.03.2019 um 14:38 schrieb Bob Rudis :
>
> It's fixed in the RC that's GA on the
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
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 wrote:
>
> Dear All,
>
> Checking a new package under development produces a
13 matches
Mail list logo
