Re: CRAN package slider
>>>>> Davis Vaughan writes:
Many thanks for your detective work.
Turns out that this is actually already fixed in R-patched.
Martin: can you perhaps quickly identify the patch which fixes this?
Dirk: could you perhaps consider to apply that patch and redo the Debian
4.2.2 packages?
Best
-k
> One last thing. I have confirmed that this was a bug that was introduced in
> R 4.2.2, but has since been patched in R-devel.
> Is that something that can be fixed in R 4.2.2 Patched (I'm not sure how
> that works)?
> ```
> x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
> x
> #> [1] "2019-01-30 UTC" "2019-01-31 UTC"
> # Make the 2nd element NA by setting one of the fields to NA
> x$mon <- c(0L, NA)
> x
> #> [1] "2019-01-30 UTC" NA
> # R 4.2.1
> as.Date(x)
> #> [1] "2019-01-30" NA
> # R 4.2.2
> as.Date(x)
> #> [1] "2019-01-30" "1970-01-01"
> # R-devel, 2022-11-07 r83308
> as.Date(x)
> #> [1] "2019-01-30" NA
> ```
> This has practical implications for lubridate users that update to R 4.2.2
> but stay on lubridate 1.8.0, as this code no longer works. Luckily we can
> tell users to just update to lubridate 1.9.0 if they have issues, which
> works on all the R versions in question:
> ```
> library(lubridate)
> i <- as.Date("2019-01-30")
> i
> #> [1] "2019-01-30"
> # R 4.2.2, lubridate 1.8.0
> i + months(1)
> #> [1] "1970-01-30"
> # R 4.2.2, lubridate 1.9.0 (the NA is correct behavior)
> i + months(1)
> #> [1] NA
> ```
> Thanks all,
> Davis
> On Tue, Nov 8, 2022 at 6:04 PM Davis Vaughan <davis@posit.co> wrote:
>> Oh, and just as I send this I think I have figured it out!
>>
>> I'm seeing this on the debian log:
>>
>> ```
>> Setting up r-cran-lubridate (1.8.0+dfsg-1+b1) ..
>> ```
>>
>> Meaning that Debian is installing a version of lubridate that is
>> technically out of date now, as lubridate 1.9.0 landed on CRAN 2 days ago
>> (I assume CRAN is also installing an outdated version).
>>
>> If you run my lubridate reprex from above with:
>> - rocker/r-base image with released R 4.2.2 (2022-10-31)
>> - lubridate 1.8.0
>>
>> then you get:
>>
>> ```
>> library(lubridate)
>> i <- as.Date("2019-01-30") + months(-3:0)
>> i + months(1)
>> #> [1] "2018-11-30" "2018-12-30" "2019-01-30" "1970-01-30"
>> ```
>>
>> which clearly isn't right in that 4th slot, it should be `NA`.
>>
>> This has to do with this R-devel bug which I thought was fixed before
>> 4.2.2 went out? But it seems like I can reproduce this in R 4.2.2 which
>> makes me think somehow it slipped through:
>>
>> ```
>> x <- as.POSIXlt(c("2019-01-30", "2019-01-31"), tz = "UTC")
>> x
>> #> [1] "2019-01-30 UTC" "2019-01-31 UTC"
>>
>> # Looks like NA in the 2nd slot
>> x$mon <- c(0L, NA)
>> x
>> #> [1] "2019-01-30 UTC" NA
>>
>> # But this borks it completely!
>> as.Date(x)
>> #> [1] "2019-01-30" "1970-01-01"
>> ```
>>
>> I can't reproduce this in R-devel 2022-11-07 r83308, the `as.Date()` call
>> there correctly gives me `NA` in the 2nd slot.
>>
>> lubridate happened to switch to using timechange as a backend in the last
>> release, and it probably changes the internal code in such a way that it
>> now happens to avoid this bug, which is why we don't see it on R 4.2.2 with
>> lubridate 1.9.0.
>>
>> So I think CRAN and Debian just need to rerun these checks with lubridate
>> 1.9.0, and in the meantime I will go ahead and send in a patch release of
>> slider to fix the strict-prototype warnings.
>>
>> -Davis
>>
>> On Tue, Nov 8, 2022 at 5:30 PM Davis Vaughan <davis@posit.co> wrote:
>>
>>> Hi all,
>>>
>>> I fixed the strict-prototypes warnings here
>>> https://github.com/DavisVaughan/slider/pull/175
>>> (BTW, did you see Lionel's message about this on r-package-devel?
>>> https://stat.ethz.ch/pipermail/r-package-devel/2022q4/008589.html)
>>>
>>> I have slider ready to go, but can't reproduce the issues seen on the
>>> CRAN machines and on the Debian autopkgtest. I've tried a number of things,
>>> including:
>>>
>>> - Using the rocker/r-base image with released R 4.2.2 (2022-10-31), where
>>> I tried to run tests on the slider_0.2.2.tar.gz downloaded from CRAN with R
>>> CMD check and on the actual source code of slider pulled from GitHub with
>>> devtools::check()
>>> - Submitting slider to win-devel, where it comes back clean
>>> - Checking it locally on my own Mac, of course, with various versions of
>>> R including the exact r83217 revision it seems to be failing with on CRAN
>>>
>>> Those tests should have errored earlier in
>>> `check_endpoints_cannot_be_na()` where a missing value check is run, but
>>> somehow it is bypassed and is then erroring on the next check, which checks
>>> that all values are in ascending order. So my guess is that it has
>>> something to do with lubridate and this month addition, which should always
>>> result in a missing value in the 4th element, but that must not be the case
>>> somehow (here are the expected results):
>>>
>>> ```
>>> library(lubridate)
>>> i <- as.Date("2019-01-30") + months(-3:0)
>>> i + months(1)
>>> #> [1] "2018-11-30" "2018-12-30" "2019-01-30" NA
>>> ```
>>>
>>> If anyone can reproduce the test failures themselves, I'd be grateful if
>>> you could help me figure out what I might be missing here. I'm very
>>> motivated to try and get this fixed for CRAN.
>>>
>>> -Davis
>>>
>>> On Tue, Nov 8, 2022 at 6:30 AM Kurt Hornik <Kurt.Hornik@wu.ac.at> wrote:
>>>
>>>> Davis,
>>>>
>>>> Please see
>>>>
>>>> <https://cran.r-project.org/web/checks/check_results_slider.html>
>>>>
>>>> Unfortunately, in addition to the new strict-prototypes compilation
>>>> warnings in r-devel we also have test ERRORs for the Debian r-patched
>>>> and r-release checks, which also materialize in the autopkgtest checks
>>>> for the r-cran-slider package and thus currently prevent the migration
>>>> of the new R 4.2.2 Debian packages from unstable to testing, see
>>>>
>>>> <https://tracker.debian.org/pkg/r-base>
>>>>
>>>> My hope is that this can be overridden quickly to get the Debian
>>>> packages migrated to testing, but in any case, can you please fix the
>>>> ERRORs (and ideally also the compilation warnings) as quickly as
>>>> possible?
>>>>
>>>> Best
>>>> -k
>>>>
>>>
> [[alternative HTML version deleted]]
Reply to: