[R-pkg-devel] Package failing reverse dependency checks

2024-02-08 Thread David Hugh-Jones
Hi all,

I'm trying to upload a new version of my "huxtable" package. It is
currently failing reverse dependency checks for two packages (homnormal and
RSStest). The relevant failures are below.

I got this failure one time, and fixed the problem, which relates to
mistakenly relying on the Suggested: knitr package (see here for the
commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
commit, reverse dependency checks for homnormal and RSStest pass on my
machine, when testing either with revdepcheck::revdep_check or
tools::check_packages_in_dir, and even when knitr is not installed. But,
after I uploaded the new package to CRAN, the same failure recurred.

My new release candidate had the same version number as the previous one
(which had failed the revdep check, and therefore not been published on
CRAN). Is it possible that CRAN just tested the old version again?

If not, then can anyone suggest the best way to debug a revdep check on as
close a setup to the CRAN machines as possible?

Cheers,
David

Git tag for the last CRAN submission:
https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3

Info from the CRAN email:
--
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
>
RSStest, homnormal

Log dir: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
>
The files will be removed after roughly 7 days.

Pretests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
>
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
>
--
Changes to worse in reverse depends:

Package: homnormal
Check: examples
New result: ERROR
  Running examples in ‘homnormal-Ex.R’ failed
  The error most likely occurred in:

  > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
  > ### Name: Brown_Forsythe
  > ### Title: Brown-Forsythe Test for Homogeniety
  > ### Aliases: Brown_Forsythe
  >
  > ### ** Examples
  >
  > data(FH_data)
  >x1=FH_data$SurvivalTime
  >x2=FH_data$HospitalNo
  >Brown_Forsythe(x1,x2)
  Error in loadNamespace(x) : there is no package called ‘knitr’
  Calls: Brown_Forsythe ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
  Execution halted

Package: RSStest
Check: examples
New result: ERROR
  Running examples in ‘RSStest-Ex.R’ failed
  The error most likely occurred in:

  > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
  > ### Name: teststat_MRSS
  > ### Title: Median Ranked Set Sampling Test
  > ### Aliases: teststat_MRSS
  >
  > ### ** Examples
  >
  > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
  > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
  > teststat_MRSS(x1,x2,tn=1000)
  Error in loadNamespace(x) : there is no package called ‘knitr’
  Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
  Execution halted

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Package failing reverse dependency checks

2024-02-08 Thread Duncan Murdoch

On 08/02/2024 4:24 a.m., David Hugh-Jones wrote:

Hi all,

I'm trying to upload a new version of my "huxtable" package. It is
currently failing reverse dependency checks for two packages (homnormal and
RSStest). The relevant failures are below.

I got this failure one time, and fixed the problem, which relates to
mistakenly relying on the Suggested: knitr package (see here for the
commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
commit, reverse dependency checks for homnormal and RSStest pass on my
machine, when testing either with revdepcheck::revdep_check or
tools::check_packages_in_dir, and even when knitr is not installed. But,
after I uploaded the new package to CRAN, the same failure recurred.

My new release candidate had the same version number as the previous one
(which had failed the revdep check, and therefore not been published on
CRAN). Is it possible that CRAN just tested the old version again?


The CRAN policy on re-submission says "Increasing the version number at 
each submission reduces confusion so is preferred even when a previous 
submission was not accepted."


So yes, I think confusion with the previous submission could have happened.

Duncan Murdoch



If not, then can anyone suggest the best way to debug a revdep check on as
close a setup to the CRAN machines as possible?

Cheers,
David

Git tag for the last CRAN submission:
https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3

Info from the CRAN email:
--
Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt



RSStest, homnormal

Log dir: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/



The files will be removed after roughly 7 days.

Pretests:
Windows: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log



Debian: <
https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log



--
Changes to worse in reverse depends:

Package: homnormal
Check: examples
New result: ERROR
   Running examples in ‘homnormal-Ex.R’ failed
   The error most likely occurred in:

   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
   > ### Name: Brown_Forsythe
   > ### Title: Brown-Forsythe Test for Homogeniety
   > ### Aliases: Brown_Forsythe
   >
   > ### ** Examples
   >
   > data(FH_data)
   >x1=FH_data$SurvivalTime
   >x2=FH_data$HospitalNo
   >Brown_Forsythe(x1,x2)
   Error in loadNamespace(x) : there is no package called ‘knitr’
   Calls: Brown_Forsythe ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
   Execution halted

Package: RSStest
Check: examples
New result: ERROR
   Running examples in ‘RSStest-Ex.R’ failed
   The error most likely occurred in:

   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
   > ### Name: teststat_MRSS
   > ### Title: Median Ranked Set Sampling Test
   > ### Aliases: teststat_MRSS
   >
   > ### ** Examples
   >
   > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
   > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
   > teststat_MRSS(x1,x2,tn=1000)
   Error in loadNamespace(x) : there is no package called ‘knitr’
   Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
-> doWithOneRestart
   Execution halted

[[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] Package failing reverse dependency checks

2024-02-08 Thread Lluís Revilla
Hi David,

If you didn't increase the version number it could happen that the old
version of the package was used (as CRAN might not be aware that there is a
new version).
The CRAN repository policy says: "Increasing the version number at each
submission reduces confusion so is preferred even when a previous
submission was not accepted".
In addition, it is easier to track how smooth the submission process is for
maintainers/developers.

I would recommend submitting again, changing the version number of the
package.
Checking on  win builders and macos builders CRAN provides is the closest
one, other approaches include rhub2.

Best,

Lluís



On Thu, 8 Feb 2024 at 10:24, David Hugh-Jones 
wrote:

> Hi all,
>
> I'm trying to upload a new version of my "huxtable" package. It is
> currently failing reverse dependency checks for two packages (homnormal and
> RSStest). The relevant failures are below.
>
> I got this failure one time, and fixed the problem, which relates to
> mistakenly relying on the Suggested: knitr package (see here for the
> commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
> commit, reverse dependency checks for homnormal and RSStest pass on my
> machine, when testing either with revdepcheck::revdep_check or
> tools::check_packages_in_dir, and even when knitr is not installed. But,
> after I uploaded the new package to CRAN, the same failure recurred.
>
> My new release candidate had the same version number as the previous one
> (which had failed the revdep check, and therefore not been published on
> CRAN). Is it possible that CRAN just tested the old version again?
>
> If not, then can anyone suggest the best way to debug a revdep check on as
> close a setup to the CRAN machines as possible?
>
> Cheers,
> David
>
> Git tag for the last CRAN submission:
> https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
>
> Info from the CRAN email:
> --
> Debian: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
> >
> RSStest, homnormal
>
> Log dir: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
> >
> The files will be removed after roughly 7 days.
>
> Pretests:
> Windows: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
> >
> Debian: <
>
> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
> >
> --
> Changes to worse in reverse depends:
>
> Package: homnormal
> Check: examples
> New result: ERROR
>   Running examples in ‘homnormal-Ex.R’ failed
>   The error most likely occurred in:
>
>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>   > ### Name: Brown_Forsythe
>   > ### Title: Brown-Forsythe Test for Homogeniety
>   > ### Aliases: Brown_Forsythe
>   >
>   > ### ** Examples
>   >
>   > data(FH_data)
>   >x1=FH_data$SurvivalTime
>   >x2=FH_data$HospitalNo
>   >Brown_Forsythe(x1,x2)
>   Error in loadNamespace(x) : there is no package called ‘knitr’
>   Calls: Brown_Forsythe ... loadNamespace -> withRestarts -> withOneRestart
> -> doWithOneRestart
>   Execution halted
>
> Package: RSStest
> Check: examples
> New result: ERROR
>   Running examples in ‘RSStest-Ex.R’ failed
>   The error most likely occurred in:
>
>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>   > ### Name: teststat_MRSS
>   > ### Title: Median Ranked Set Sampling Test
>   > ### Aliases: teststat_MRSS
>   >
>   > ### ** Examples
>   >
>   > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
>   > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
>   > teststat_MRSS(x1,x2,tn=1000)
>   Error in loadNamespace(x) : there is no package called ‘knitr’
>   Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
> -> doWithOneRestart
>   Execution halted
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Package failing reverse dependency checks

2024-02-08 Thread David Hugh-Jones
Thanks for this tip. Out of interest, is there a way to make win/Mac
builder run revdep checks?

Writing: wyclif.substack.com
Book: www.wyclifsdust.com


On Thu, 8 Feb 2024 at 10:26, Lluís Revilla  wrote:

> Hi David,
>
> If you didn't increase the version number it could happen that the old
> version of the package was used (as CRAN might not be aware that there is a
> new version).
> The CRAN repository policy says: "Increasing the version number at each
> submission reduces confusion so is preferred even when a previous
> submission was not accepted".
> In addition, it is easier to track how smooth the submission process is
> for maintainers/developers.
>
> I would recommend submitting again, changing the version number of the
> package.
> Checking on  win builders and macos builders CRAN provides is the closest
> one, other approaches include rhub2.
>
> Best,
>
> Lluís
>
>
>
> On Thu, 8 Feb 2024 at 10:24, David Hugh-Jones 
> wrote:
>
>> Hi all,
>>
>> I'm trying to upload a new version of my "huxtable" package. It is
>> currently failing reverse dependency checks for two packages (homnormal
>> and
>> RSStest). The relevant failures are below.
>>
>> I got this failure one time, and fixed the problem, which relates to
>> mistakenly relying on the Suggested: knitr package (see here for the
>> commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
>> commit, reverse dependency checks for homnormal and RSStest pass on my
>> machine, when testing either with revdepcheck::revdep_check or
>> tools::check_packages_in_dir, and even when knitr is not installed. But,
>> after I uploaded the new package to CRAN, the same failure recurred.
>>
>> My new release candidate had the same version number as the previous one
>> (which had failed the revdep check, and therefore not been published on
>> CRAN). Is it possible that CRAN just tested the old version again?
>>
>> If not, then can anyone suggest the best way to debug a revdep check on as
>> close a setup to the CRAN machines as possible?
>>
>> Cheers,
>> David
>>
>> Git tag for the last CRAN submission:
>> https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
>>
>> Info from the CRAN email:
>> --
>> Debian: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
>> >
>> RSStest, homnormal
>>
>> Log dir: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
>> >
>> The files will be removed after roughly 7 days.
>>
>> Pretests:
>> Windows: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
>> >
>> Debian: <
>>
>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
>> >
>> --
>> Changes to worse in reverse depends:
>>
>> Package: homnormal
>> Check: examples
>> New result: ERROR
>>   Running examples in ‘homnormal-Ex.R’ failed
>>   The error most likely occurred in:
>>
>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>   > ### Name: Brown_Forsythe
>>   > ### Title: Brown-Forsythe Test for Homogeniety
>>   > ### Aliases: Brown_Forsythe
>>   >
>>   > ### ** Examples
>>   >
>>   > data(FH_data)
>>   >x1=FH_data$SurvivalTime
>>   >x2=FH_data$HospitalNo
>>   >Brown_Forsythe(x1,x2)
>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>   Calls: Brown_Forsythe ... loadNamespace -> withRestarts ->
>> withOneRestart
>> -> doWithOneRestart
>>   Execution halted
>>
>> Package: RSStest
>> Check: examples
>> New result: ERROR
>>   Running examples in ‘RSStest-Ex.R’ failed
>>   The error most likely occurred in:
>>
>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>   > ### Name: teststat_MRSS
>>   > ### Title: Median Ranked Set Sampling Test
>>   > ### Aliases: teststat_MRSS
>>   >
>>   > ### ** Examples
>>   >
>>   > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
>>   > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
>>   > teststat_MRSS(x1,x2,tn=1000)
>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>   Calls: teststat_MRSS ... loadNamespace -> withRestarts -> withOneRestart
>> -> doWithOneRestart
>>   Execution halted
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

[[alternative HTML version deleted]]

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


[R-pkg-devel] Changing package maintainers

2024-02-08 Thread Josiah Parry
I intend to change the maintainer of my package {sfdep}
https://cran.r-project.org/package=sfdep.
Is the process as simple as submitting a new release where the DESCRIPTION
file changes who has the role of `aut`?

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Changing package maintainers

2024-02-08 Thread Jeff Newmiller via R-package-devel
Are you aware of this [1]? J. Random Lurker may not be a reliable source, and 
actual CRAN repo maintainers are probably a bit busy...

[1] https://cran.r-project.org/web/packages/policies.html#Submission

On February 8, 2024 8:37:50 AM PST, Josiah Parry  wrote:
>I intend to change the maintainer of my package {sfdep}
>https://cran.r-project.org/package=sfdep.
>Is the process as simple as submitting a new release where the DESCRIPTION
>file changes who has the role of `aut`?
>
>   [[alternative HTML version deleted]]
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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


Re: [R-pkg-devel] Changing package maintainers

2024-02-08 Thread Josiah Parry
I’m sorry? I do not follow.

On Thu, Feb 8, 2024 at 12:01 Jeff Newmiller via R-package-devel <
r-package-devel@r-project.org> wrote:

> Are you aware of this [1]? J. Random Lurker may not be a reliable source,
> and actual CRAN repo maintainers are probably a bit busy...
>
> [1] https://cran.r-project.org/web/packages/policies.html#Submission
>
> On February 8, 2024 8:37:50 AM PST, Josiah Parry 
> wrote:
> >I intend to change the maintainer of my package {sfdep}
> >https://cran.r-project.org/package=sfdep.
> >Is the process as simple as submitting a new release where the DESCRIPTION
> >file changes who has the role of `aut`?
> >
> >   [[alternative HTML version deleted]]
> >
> >__
> >R-package-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Sent from my phone. Please excuse my brevity.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Changing package maintainers

2024-02-08 Thread Joshua Ulrich
The process is described in the 6th bullet of the "Source Packages"
section of the CRAN Policies:
https://cran.r-project.org/web/packages/policies.html

"When a new maintainer wishes to take over a package, this should be
accompanied by the written agreement of the previous maintainer
(unless the package has been formally orphaned)."

So the current maintainer needs to send CRAN an email with the name
and email address of the new maintainer.

Best,
Josh


On Thu, Feb 8, 2024 at 10:38 AM Josiah Parry  wrote:
>
> I intend to change the maintainer of my package {sfdep}
> https://cran.r-project.org/package=sfdep.
> Is the process as simple as submitting a new release where the DESCRIPTION
> file changes who has the role of `aut`?
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



--
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

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


Re: [R-pkg-devel] Changing package maintainers

2024-02-08 Thread Josiah Parry
Much appreciated, Josh! One day I’ll internalize everything in the
policies.

On Thu, Feb 8, 2024 at 12:32 Joshua Ulrich  wrote:

> The process is described in the 6th bullet of the "Source Packages"
> section of the CRAN Policies:
> https://cran.r-project.org/web/packages/policies.html
>
> "When a new maintainer wishes to take over a package, this should be
> accompanied by the written agreement of the previous maintainer
> (unless the package has been formally orphaned)."
>
> So the current maintainer needs to send CRAN an email with the name
> and email address of the new maintainer.
>
> Best,
> Josh
>
>
> On Thu, Feb 8, 2024 at 10:38 AM Josiah Parry 
> wrote:
> >
> > I intend to change the maintainer of my package {sfdep}
> > https://cran.r-project.org/package=sfdep.
> > Is the process as simple as submitting a new release where the
> DESCRIPTION
> > file changes who has the role of `aut`?
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>
>
> --
> Joshua Ulrich  |  about.me/joshuaulrich
> FOSS Trading  |  www.fosstrading.com
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] failing CRAN checks due to problems with dependencies

2024-02-08 Thread Ivan Krylov via R-package-devel
В Wed, 7 Feb 2024 08:40:44 -0600
Marcin Jurek  пишет:

> Packages required but not available: 'Rcpp', 'FNN',
> 'RcppArmadillo' Packages suggested but not available for checking:
> 'fields', 'rmarkdown', 'testthat', 'maptools'

One of the machines running the incoming checks was having problems. If
you followed the failing dependency chain by looking at the CRAN check
results of the packages described as "not available", you could
eventually find a package needing compilation (Rcpp or stringi or
something else), look at the installation log and see Make trying to
run commands that are completely wrong.

It looked like the path to the compiler was empty:
https://web.archive.org/web/20240208191430/https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/Rcpp-00install.html

I think that the problems are solved now, so it should be safe to
increment the version and submit it again.

-- 
Best regards,
Ivan

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


Re: [R-pkg-devel] failing CRAN checks due to problems with dependencies

2024-02-08 Thread Marcin Jurek
Ok, this makes sense! I saw that Rcpp was failing the checks too but I
wasn't sure if I should resubmit or wait. Thanks!

On Thu, Feb 8, 2024 at 1:17 PM Ivan Krylov  wrote:

> В Wed, 7 Feb 2024 08:40:44 -0600
> Marcin Jurek  пишет:
>
> > Packages required but not available: 'Rcpp', 'FNN',
> > 'RcppArmadillo' Packages suggested but not available for checking:
> > 'fields', 'rmarkdown', 'testthat', 'maptools'
>
> One of the machines running the incoming checks was having problems. If
> you followed the failing dependency chain by looking at the CRAN check
> results of the packages described as "not available", you could
> eventually find a package needing compilation (Rcpp or stringi or
> something else), look at the installation log and see Make trying to
> run commands that are completely wrong.
>
> It looked like the path to the compiler was empty:
>
> https://web.archive.org/web/20240208191430/https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/Rcpp-00install.html
>
> I think that the problems are solved now, so it should be safe to
> increment the version and submit it again.
>
> --
> Best regards,
> Ivan
>

[[alternative HTML version deleted]]

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


Re: [R-pkg-devel] Package failing reverse dependency checks

2024-02-08 Thread Lluís Revilla
Hi David,

Dependency checks cannot be run on win /Mac builders as far as I know.
Some packages have more than 2000 packages depending on them.
It would be too much for the heavily used CRAN's machines.

Best,

Lluís

On Thu, 8 Feb 2024 at 13:52, David Hugh-Jones 
wrote:

> Thanks for this tip. Out of interest, is there a way to make win/Mac
> builder run revdep checks?
>
> Writing: wyclif.substack.com
> Book: www.wyclifsdust.com
>
>
> On Thu, 8 Feb 2024 at 10:26, Lluís Revilla 
> wrote:
>
>> Hi David,
>>
>> If you didn't increase the version number it could happen that the old
>> version of the package was used (as CRAN might not be aware that there is a
>> new version).
>> The CRAN repository policy says: "Increasing the version number at each
>> submission reduces confusion so is preferred even when a previous
>> submission was not accepted".
>> In addition, it is easier to track how smooth the submission process is
>> for maintainers/developers.
>>
>> I would recommend submitting again, changing the version number of the
>> package.
>> Checking on  win builders and macos builders CRAN provides is the closest
>> one, other approaches include rhub2.
>>
>> Best,
>>
>> Lluís
>>
>>
>>
>> On Thu, 8 Feb 2024 at 10:24, David Hugh-Jones 
>> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to upload a new version of my "huxtable" package. It is
>>> currently failing reverse dependency checks for two packages (homnormal
>>> and
>>> RSStest). The relevant failures are below.
>>>
>>> I got this failure one time, and fixed the problem, which relates to
>>> mistakenly relying on the Suggested: knitr package (see here for the
>>> commit: https://github.com/hughjonesd/huxtable/commit/5a3edc). After the
>>> commit, reverse dependency checks for homnormal and RSStest pass on my
>>> machine, when testing either with revdepcheck::revdep_check or
>>> tools::check_packages_in_dir, and even when knitr is not installed. But,
>>> after I uploaded the new package to CRAN, the same failure recurred.
>>>
>>> My new release candidate had the same version number as the previous one
>>> (which had failed the revdep check, and therefore not been published on
>>> CRAN). Is it possible that CRAN just tested the old version again?
>>>
>>> If not, then can anyone suggest the best way to debug a revdep check on
>>> as
>>> close a setup to the CRAN machines as possible?
>>>
>>> Cheers,
>>> David
>>>
>>> Git tag for the last CRAN submission:
>>> https://github.com/hughjonesd/huxtable/releases/tag/v5.5.4-rc3
>>>
>>> Info from the CRAN email:
>>> --
>>> Debian: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/reverseDependencies/summary.txt
>>> >
>>> RSStest, homnormal
>>>
>>> Log dir: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/
>>> >
>>> The files will be removed after roughly 7 days.
>>>
>>> Pretests:
>>> Windows: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Windows/00check.log
>>> >
>>> Debian: <
>>>
>>> https://win-builder.r-project.org/incoming_pretest/huxtable_5.5.4_20240205_164815/Debian/00check.log
>>> >
>>> --
>>> Changes to worse in reverse depends:
>>>
>>> Package: homnormal
>>> Check: examples
>>> New result: ERROR
>>>   Running examples in ‘homnormal-Ex.R’ failed
>>>   The error most likely occurred in:
>>>
>>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>>   > ### Name: Brown_Forsythe
>>>   > ### Title: Brown-Forsythe Test for Homogeniety
>>>   > ### Aliases: Brown_Forsythe
>>>   >
>>>   > ### ** Examples
>>>   >
>>>   > data(FH_data)
>>>   >x1=FH_data$SurvivalTime
>>>   >x2=FH_data$HospitalNo
>>>   >Brown_Forsythe(x1,x2)
>>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>>   Calls: Brown_Forsythe ... loadNamespace -> withRestarts ->
>>> withOneRestart
>>> -> doWithOneRestart
>>>   Execution halted
>>>
>>> Package: RSStest
>>> Check: examples
>>> New result: ERROR
>>>   Running examples in ‘RSStest-Ex.R’ failed
>>>   The error most likely occurred in:
>>>
>>>   > base::assign(".ptime", proc.time(), pos = "CheckExEnv")
>>>   > ### Name: teststat_MRSS
>>>   > ### Title: Median Ranked Set Sampling Test
>>>   > ### Aliases: teststat_MRSS
>>>   >
>>>   > ### ** Examples
>>>   >
>>>   > x1=matrix(c(1,2.3, 3.4,4.5,5.6,4 ),nrow=3)
>>>   > x2=matrix(c(2,3.2, 4.2,6.5,4.6,6 ),nrow=3)
>>>   > teststat_MRSS(x1,x2,tn=1000)
>>>   Error in loadNamespace(x) : there is no package called ‘knitr’
>>>   Calls: teststat_MRSS ... loadNamespace -> withRestarts ->
>>> withOneRestart
>>> -> doWithOneRestart
>>>   Execution halted
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing

Re: [R-pkg-devel] failing CRAN checks due to problems with dependencies

2024-02-08 Thread Dirk Eddelbuettel


On 8 February 2024 at 13:28, Marcin Jurek wrote:
| Ok, this makes sense! I saw that Rcpp was failing the checks too but I
| wasn't sure if I should resubmit or wait. Thanks!

For completeness, it was not caused by Rcpp but rather by a mix on new clang
and gcc versions which somehow got into each other's way on that machine; and
this has by now been fixed.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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