Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Ben Bolker]

 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 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

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 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)
.
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  wrote:


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:


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 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  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

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 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 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).


-boB


On Mar 7, 2019, at 07:54, Rainer M Krug  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 

wrote:


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.


The warning concerns using http://worldclockapi.com/, which

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,

"r") :

cannot open URL 'http://worldclockapi.com/api/json/utc/now':

HTTP status was '403 Site Disabled'

WARNING
unable to verify current time
* checking 

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Rainer M Krug]

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.
> 
> On Tue, Mar 19, 2019 at 11: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 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
>>> 
>>> 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 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)
 .
 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  wrote:
 
> 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:
>> 
> 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 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  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
> 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 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 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).
> 
> -boB
> 
>> On Mar 7, 2019, at 07:54, Rainer M Krug  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 
> wrote:
>>> 
>>> 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.

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Gábor Csárdi]

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 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
> >
> > 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 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)
> >> .
> >> 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  wrote:
> >>
> >>> 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:
> 
> >>> 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 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  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
> >>> 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 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 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).
> >>>
> >>> -boB
> >>>
>  On Mar 7, 2019, at 07:54, Rainer M Krug  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 
> >>> wrote:
> >
> > 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.
> >
> > The warning concerns using http://worldclockapi.com/, which
> >>> however seems out of service ("The web app you have attempted to 

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Rainer M Krug]

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
> 
> 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 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)
>> .
>> 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  wrote:
>> 
>>> 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:
 
>>> 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 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  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
>>> 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 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 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).
>>> 
>>> -boB
>>> 
 On Mar 7, 2019, at 07:54, Rainer M Krug  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 
>>> wrote:
> 
> 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.
> 
> The warning concerns using http://worldclockapi.com/, which
>>> 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 

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Gábor Csárdi]

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 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)
> .
> 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  wrote:
>
> > 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:
> > >
> > 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 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  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
> > 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 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 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).
> > > > >>
> > > > >> -boB
> > > > >>
> > > > >>> On Mar 7, 2019, at 07:54, Rainer M Krug  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 
> > wrote:
> > > > 
> > > >  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.
> > > > 
> > > >  The warning concerns using http://worldclockapi.com/, which
> > 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

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Marta Karaś]

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)
.
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  wrote:

> 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:
> >
> 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 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  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
> 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 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 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).
> > > >>
> > > >> -boB
> > > >>
> > > >>> On Mar 7, 2019, at 07:54, Rainer M Krug  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 
> wrote:
> > > 
> > >  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.
> > > 
> > >  The warning concerns using http://worldclockapi.com/, which
> 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,
> "r") :
> > > 

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Hadley Wickham]

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:
> 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 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  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 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 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 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).
> > >>
> > >> -boB
> > >>
> > >>> On Mar 7, 2019, at 07:54, Rainer M Krug  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  wrote:
> > 
> >  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.
> > 
> >  The warning concerns using http://worldclockapi.com/, which 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, "r") :
> >  cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP 
> >  status was '403 Site Disabled'
> >  WARNING
> >  unable to verify current time
> >  * checking 'build' directory … OK
> >  [...]
> > 
> > 
> > 
> >  ## Ralf Herold
> >  ## mailto: ralf.her...@mailbox.org [S/MIME]
> >  ## https://paediatricdata.eu/
> > 
> >  __
> >  R-package-devel@r-project.org mailing list
> >  https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Rainer M. Krug
> > >>> email: 

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Hadley Wickham]

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 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  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 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 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 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).
> >>
> >> -boB
> >>
> >>> On Mar 7, 2019, at 07:54, Rainer M Krug  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  wrote:
> 
>  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.
> 
>  The warning concerns using http://worldclockapi.com/, which 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, "r") :
>  cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
>  was '403 Site Disabled'
>  WARNING
>  unable to verify current time
>  * checking 'build' directory … OK
>  [...]
> 
> 
> 
>  ## Ralf Herold
>  ## mailto: ralf.her...@mailbox.org [S/MIME]
>  ## https://paediatricdata.eu/
> 
>  __
>  R-package-devel@r-project.org mailing list
>  https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Rainer M. Krug
> >>> email: Rainerkrugsde
> >>> PGP: 0x0F52F982
> >>>
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > --
> > Peter Dalgaard, Professor,
> > Center for 

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Bob Rudis]

(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 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 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).
>> 
>> -boB
>> 
>>> On Mar 7, 2019, at 07:54, Rainer M Krug  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  wrote:
 
 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.
 
 The warning concerns using http://worldclockapi.com/, which 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, "r") :
 cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
 was '403 Site Disabled'
 WARNING
 unable to verify current time
 * checking 'build' directory … OK
 [...]
 
 
 
 ## Ralf Herold
 ## mailto: ralf.her...@mailbox.org [S/MIME]
 ## https://paediatricdata.eu/
 
 __
 R-package-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Rainer M. Krug
>>> email: Rainerkrugsde
>>> PGP: 0x0F52F982
>>> 
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Office: A 4.23
> Email: pd@cbs.dk  Priv: pda...@gmail.com
> 
> 
> 
> 
> 
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[peter dalgaard]

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 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).
> 
> -boB
> 
>> On Mar 7, 2019, at 07:54, Rainer M Krug  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  wrote:
>>> 
>>> 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.
>>> 
>>> The warning concerns using http://worldclockapi.com/, which 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, "r") :
>>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
>>> was '403 Site Disabled'
>>> WARNING
>>> unable to verify current time
>>> * checking 'build' directory … OK
>>> [...]
>>> 
>>> 
>>> 
>>> ## Ralf Herold
>>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>>> ## https://paediatricdata.eu/
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> 
>> 
>> 
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982
>> 
>> 
>>  [[alternative HTML version deleted]]
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Ralf Herold]

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 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).
> 
> -boB
> 
>> On Mar 7, 2019, at 07:54, Rainer M Krug  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  wrote:
>>> 
>>> 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.
>>> 
>>> The warning concerns using http://worldclockapi.com/, which 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, "r") :
>>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status 
>>> was '403 Site Disabled'
>>> WARNING
>>> unable to verify current time
>>> * checking 'build' directory … OK
>>> [...]
>>> 
>>> 
>>> 
>>> ## Ralf Herold
>>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>>> ## https://paediatricdata.eu/
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> 
>> 
>> 
>> --
>> Rainer M. Krug
>> email: Rainerkrugsde
>> PGP: 0x0F52F982
>> 
>> 
>>  [[alternative HTML version deleted]]
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Bob Rudis]

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).

-boB

> On Mar 7, 2019, at 07:54, Rainer M Krug  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  wrote:
>> 
>> 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.
>> 
>> The warning concerns using http://worldclockapi.com/, which 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, "r") :
>> cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status was 
>> '403 Site Disabled'
>> WARNING
>> unable to verify current time
>> * checking 'build' directory … OK
>> [...]
>> 
>> 
>> 
>> ## Ralf Herold
>> ## mailto: ralf.her...@mailbox.org [S/MIME]
>> ## https://paediatricdata.eu/
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> 
> 
> 
> --
> Rainer M. Krug
> email: Rainerkrugsde
> PGP: 0x0F52F982
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Checking for future file timestamps - warning with worldclockapi HTTP status 403 Site Disabled

[Rainer M Krug]

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 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. 
> 
> The warning concerns using http://worldclockapi.com/, which 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, "r") :
>  cannot open URL 'http://worldclockapi.com/api/json/utc/now': HTTP status was 
> '403 Site Disabled'
> WARNING
> unable to verify current time
> * checking 'build' directory … OK
> [...]
> 
> 
> 
> ## Ralf Herold 
> ## mailto: ralf.her...@mailbox.org [S/MIME]
> ## https://paediatricdata.eu/
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel




--
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel