Package fCalendar_260.72.tar.gz did not pass R CMD check

[Martin Maechler]

>>>>> "YC" == Yohan Chalabi <chalabi at phys.ethz.ch>
>>>>>     on Tue, 5 Feb 2008 18:08:44 +0100 writes:

    >>>>> "ULPO" == Uwe.Ligges at r-project.org
    >>>>> on Tue, 05 Feb 2008 17:10:21 +0100

    ULPO> Dear package maintainer,
    ULPO> 
    ULPO> this notification has been generated automatically.
    ULPO> Your package fCalendar_260.72.tar.gz did not pass 'R CMD
    ULPO> check' on
    ULPO> Windows and will be omitted from the corresponding CRAN
    YC> directory ULPO> (CRAN/bin/windows/contrib/2.6/).
    ULPO> Please check the attached log-file and consider to resubmit
    ULPO> a version
    ULPO> with increased version number that passes R CMD check on
    YC> Windows. ULPO> R version 2.6.2 RC (2008-02-04 r44320)
    ULPO> 
    ULPO> All the best,
    ULPO> Uwe Ligges
    ULPO> (Maintainer of binary packages for Windows)

    YC> The problem is coming from the example in TimeDateSubsets.Rd . This
    YC> year Easter is at the end of March and in the example one tries to find
    YC> the window time period of Easter in April. to solve it, one can
    YC> increase the array of dates:

[............]

[............]

    YC> All these errors have been fixed in
    YC> https://svn.r-project.org/Rmetrics/trunk/fCalendar

    YC> Question : Should we submit the new version of fCalendar or fix the
    YC> error in fCalendar 260.72 and submit it as 260.73? 

    YC> I would vote for the new version of fCalendar because we also fixed
    YC> problems in DST tables and in holidays functions.

I'd also vote for releasing the new version.

And -- BTW  I really think we should slowly discontinue the idea
that Rmetrics is released half-yearly together with new versions of R.
Rmetrics packages should be dealt with as other R packages are.

Martin