Dear Dustin,
On 2020-08-27 8:26 p.m., Tracy, Josef wrote:
Hi John,
Duncan explained the cause of the problem, but i'm afraid I didn't
follow how one solves it. Did you manage to get a check without that note?
I didn't -- I just disregarded the note assuming that it would go away
when the t
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 k
Dear Duncan,
Thank you and the others who responded to my message.
John
On 2020-08-27 2:17 p.m., Duncan Murdoch wrote:
R tries to get the time from
http://worldtimeapi.org/api/timezone/UTC or
http://worldclockapi.com/api/json/utc/now
The first one doesn't accept UTC as a timezone; it appears
R tries to get the time from
http://worldtimeapi.org/api/timezone/UTC or
http://worldclockapi.com/api/json/utc/now
The first one doesn't accept UTC as a timezone; it appears to want
etc/UTC instead. The second one is offline.
Duncan Murdoch
If both of those fail, you'll get the message you
Dear Josef
From the policy
Explain any change in the maintainer’s email address and if possible
send confirmation from the previous address (by a separate email to
cran-submissi...@r-project.org) or explain why it is not possible.
Burned into my cortex since I did it incorrectly a few years
Dear r-package-devel list members,
I got the following note when checking two different packages today
--as-cran, both under R 4.0.2 and under R-devel, on my Windows 10 and
macOS Catalina systems, and on several platforms on rhub:
* checking for future file timestamps ... NOTE
unable
Hi,
I submitted a package, "PhysActBedRest" to the CRAN a couple of years ago and
am trying to update it. In writing the update, I realized I forgot to update
my email address when I changed institutions. As a consequence, when I run CMD
check on the updated package there is a NOTE that the m
Hi Uwe,
Thanks for the response and for mentioning the 'tools::' functions. Those
functions were super helpful in identifying a hyphen that I missed in a
supporting file that roxygen used to build the manual.
My package builds without warnings and errors now on a few systems, so I
think I am good
Hyphens that, e.g., get auto generated in MS Word are non ASCII. You
have to declare an appropriate encoding, or even better, replace by
regular hypehsn.
See functions
tools:::showNonASCII tools:::showNonASCIIfile
that may help to see where these are...
Best,
Uwe Ligges
On 25.08.2020 20
