Re: [R-pkg-devel] interpreting rhub platform failures

[Uwe Ligges]

The oputput is not helpful to identify the problem.

If it passes except for intel/rchk it could be some compiled code issue, 
but if you do not have such code, the issue is, if at all, in another 
package than yours.


noSuggest issues indicate you may be using a suggested package 
unconditionally?
If you are sure this is not the case in your code, go ahead and try 
CRAN. Although standard incoming checks won't check for the issues above.



Best,
Uwe Ligges





On 29.06.2025 22:14, smallepsilon wrote:

I am preparing my R package for resubmission, and am using the "rhub" package 
to check it on various platforms. It passes the checks on all but three platforms (intel, 
nosuggests, and rchk), and I am hoping for guidance on how to interpret the failures.

The package initially failed on the "ubuntu-clang" platform, but it passed when 
I reran it without any changes. I tried rerunning the checks on intel, nosuggests, and 
rchk, but it failed again on each one.

The failure details are given below. Should I worry about these errors when I 
resubmit to CRAN?

- intel fails because of a problem loading "minqa", which is imported by 
"lme4", which my package suggests. The message reads:

Error in dyn.load(file, DLLpath = DLLpath, ...) :
   unable to load shared object 
'/github/home/R/x86_64-pc-linux-gnu-library/4.6/minqa/libs/minqa.so':
   libquadmath.so.0: cannot open shared object file: No such file or directory

I searched online for related errors, and found nothing about the intel 
platform from rhub specifically, but 
https://stackoverflow.com/questions/21149090/error-installing-minqa-in-r-3-0-2 
leads me to think that it might be an issue beyond an rhub user's control.

- nosuggests fails because it cannot rebuild the vignettes. The error message is "there is no 
package called 'rmarkdown'", which is not surprising given that "rmarkdown" is 
suggested for building vignettes. I hope this is not a deal-breaker for CRAN

- rchk fails for reasons that I cannot interpret. What I think is the relevant 
text is given below. My understanding is that this platform is used to test 
C/Fortran code included in a package, which mine does not use.

Run r-hub/actions/run-check@v1
Run # If env var is not set, we run R CMD CHECK, otherwise the
Run rchk.sh
Installing package
* installing *source* package ‘distfreereg’ ...
** this is package ‘distfreereg’ version ‘1.1’
not using staged install with --libs-only
** using non-staged installation
* DONE (distfreereg)
Run # Fail for rchk errors.
Fail for rchk errors
Run # Save binary package
Save binary package
Could not find binary package.
Run actions/upload-artifact@v4
/usr/bin/docker exec  6bc8600b43794ccf106ebb57224b520f4df047df97d9876c1d815f10f15ffaf6 sh 
-c "cat /etc/*release | grep ^ID"
Warning: No files were found with the provided path: check. No artifacts will 
be uploaded.


Thanks for any help,

Jesse

__
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] Depending on R 4.5.0 because a related package depends on it?

[Duncan Murdoch]

On 2025-06-29 1:56 a.m., Shu Fai Cheung wrote:

Hi All,

I would like to ask a quick question.

I am the maintainer of Package A, which imports Package B, and Package
B imports Package C.

An R-CMD-check action on an old release of R, conducted by GitHub
action, failed, because Package C depends on R 4.5.0. However, I found
that several other packages that import Package C, including Package
B, do not require R 4.5.0. They also did not fail in all the CRAN
package checks, including those r-oldrel-* checks.

Does it mean that I can safely ignore that failure and submit a new
version of my package to CRAN? I can change Package A to depend on R
4.5.0 if necessary. I just wonder whether I have to do so.


There's no quick answer to this.  You should show us the error you 
received, and name the packages involved.


Duncan Murdoch

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

Re: [R-pkg-devel] Depending on R 4.5.0 because a related package depends on it?

[Ivan Krylov via R-package-devel]

В Sun, 29 Jun 2025 13:56:36 +0800
Shu Fai Cheung  пишет:

> An R-CMD-check action on an old release of R, conducted by GitHub
> action, failed, because Package C depends on R 4.5.0. However, I found
> that several other packages that import Package C, including Package
> B, do not require R 4.5.0. They also did not fail in all the CRAN
> package checks, including those r-oldrel-* checks.

Is it semptools -> semPlot -> OpenMx?

The situation is indeed suboptimal, because while it's easy to install
a binary build of the previous version of OpenMx for r-oldrel from
CRAN, installing a compatible version of OpenMx from source requires
visiting  and
resolving dependencies manually, one by one. (There's no dependency
index of archived packages.)

The latest version of semPlot does seem to work with the old version of
OpenMx, seeing as it passes the r-oldrel checks. I think that the
r-oldrel builders and checkers on CRAN won't notice any problem with
semptools either, because they still have the old version of OpenMx
installed.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Depending on R 4.5.0 because a related package depends on it?

[Shu Fai Cheung]

Thanks a lot! Yes, the specific package I encountered that problem is
semptools. I didn't specify that (I should have, sorry for that)
because I am also curious about what we should do in this kind of case
in general.

Even if the package could somehow pass the CRAN checks without
changing the version of R it depends on, is it recommended to change
the version that semptools depends on to R 4.5.0 because OpenMx has
this requirement? If yes, I would do
so to meet CRAN requirements.

Regards,
Shu Fai


On Sun, Jun 29, 2025 at 4:35 PM Ivan Krylov  wrote:
>
> В Sun, 29 Jun 2025 13:56:36 +0800
> Shu Fai Cheung  пишет:
>
> > An R-CMD-check action on an old release of R, conducted by GitHub
> > action, failed, because Package C depends on R 4.5.0. However, I found
> > that several other packages that import Package C, including Package
> > B, do not require R 4.5.0. They also did not fail in all the CRAN
> > package checks, including those r-oldrel-* checks.
>
> Is it semptools -> semPlot -> OpenMx?
>
> The situation is indeed suboptimal, because while it's easy to install
> a binary build of the previous version of OpenMx for r-oldrel from
> CRAN, installing a compatible version of OpenMx from source requires
> visiting  and
> resolving dependencies manually, one by one. (There's no dependency
> index of archived packages.)
>
> The latest version of semPlot does seem to work with the old version of
> OpenMx, seeing as it passes the r-oldrel checks. I think that the
> r-oldrel builders and checkers on CRAN won't notice any problem with
> semptools either, because they still have the old version of OpenMx
> installed.
>
> --
> Best regards,
> Ivan

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

Re: [R-pkg-devel] Depending on R 4.5.0 because a related package depends on it?

[Uwe Ligges]

Ivan explained this already, but as you asked again, I will repeat 
Ivan's message:
you do not need to specify version requirements if your package can live 
with older versions of the package you depend on. Then users on old 
versions of R can use your package with an older version of OpenMX.


And even if you depend on a newer version of OpenMx, then that is fine 
as install.packages() finds out on older versions of R that neither the 
required version OpenMx is not installable nor your package.


Best,
Uwe Ligges


On 29.06.2025 10:49, Shu Fai Cheung wrote:

Thanks a lot! Yes, the specific package I encountered that problem is
semptools. I didn't specify that (I should have, sorry for that)
because I am also curious about what we should do in this kind of case
in general.

Even if the package could somehow pass the CRAN checks without
changing the version of R it depends on, is it recommended to change
the version that semptools depends on to R 4.5.0 because OpenMx has
this requirement? If yes, I would do
so to meet CRAN requirements.

Regards,
Shu Fai


On Sun, Jun 29, 2025 at 4:35 PM Ivan Krylov  wrote:


В Sun, 29 Jun 2025 13:56:36 +0800
Shu Fai Cheung  пишет:


An R-CMD-check action on an old release of R, conducted by GitHub
action, failed, because Package C depends on R 4.5.0. However, I found
that several other packages that import Package C, including Package
B, do not require R 4.5.0. They also did not fail in all the CRAN
package checks, including those r-oldrel-* checks.


Is it semptools -> semPlot -> OpenMx?

The situation is indeed suboptimal, because while it's easy to install
a binary build of the previous version of OpenMx for r-oldrel from
CRAN, installing a compatible version of OpenMx from source requires
visiting  and
resolving dependencies manually, one by one. (There's no dependency
index of archived packages.)

The latest version of semPlot does seem to work with the old version of
OpenMx, seeing as it passes the r-oldrel checks. I think that the
r-oldrel builders and checkers on CRAN won't notice any problem with
semptools either, because they still have the old version of OpenMx
installed.

--
Best regards,
Ivan


__
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] Depending on R 4.5.0 because a related package depends on it?

[Shu Fai Cheung]

Sorry, I have misread Ivan's message. I understand more about this
particular case now. Thanks for your clarification.

Regards,
Shu Fai

On Sun, Jun 29, 2025 at 10:38 PM Uwe Ligges
 wrote:
>
> Ivan explained this already, but as you asked again, I will repeat
> Ivan's message:
> you do not need to specify version requirements if your package can live
> with older versions of the package you depend on. Then users on old
> versions of R can use your package with an older version of OpenMX.
>
> And even if you depend on a newer version of OpenMx, then that is fine
> as install.packages() finds out on older versions of R that neither the
> required version OpenMx is not installable nor your package.
>
> Best,
> Uwe Ligges
>
>
> On 29.06.2025 10:49, Shu Fai Cheung wrote:
> > Thanks a lot! Yes, the specific package I encountered that problem is
> > semptools. I didn't specify that (I should have, sorry for that)
> > because I am also curious about what we should do in this kind of case
> > in general.
> >
> > Even if the package could somehow pass the CRAN checks without
> > changing the version of R it depends on, is it recommended to change
> > the version that semptools depends on to R 4.5.0 because OpenMx has
> > this requirement? If yes, I would do
> > so to meet CRAN requirements.
> >
> > Regards,
> > Shu Fai
> >
> >
> > On Sun, Jun 29, 2025 at 4:35 PM Ivan Krylov  wrote:
> >>
> >> В Sun, 29 Jun 2025 13:56:36 +0800
> >> Shu Fai Cheung  пишет:
> >>
> >>> An R-CMD-check action on an old release of R, conducted by GitHub
> >>> action, failed, because Package C depends on R 4.5.0. However, I found
> >>> that several other packages that import Package C, including Package
> >>> B, do not require R 4.5.0. They also did not fail in all the CRAN
> >>> package checks, including those r-oldrel-* checks.
> >>
> >> Is it semptools -> semPlot -> OpenMx?
> >>
> >> The situation is indeed suboptimal, because while it's easy to install
> >> a binary build of the previous version of OpenMx for r-oldrel from
> >> CRAN, installing a compatible version of OpenMx from source requires
> >> visiting  and
> >> resolving dependencies manually, one by one. (There's no dependency
> >> index of archived packages.)
> >>
> >> The latest version of semPlot does seem to work with the old version of
> >> OpenMx, seeing as it passes the r-oldrel checks. I think that the
> >> r-oldrel builders and checkers on CRAN won't notice any problem with
> >> semptools either, because they still have the old version of OpenMx
> >> installed.
> >>
> >> --
> >> Best regards,
> >> Ivan
> >
> > __
> > 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

[R-pkg-devel] interpreting rhub platform failures

[smallepsilon]

I am preparing my R package for resubmission, and am using the "rhub" package 
to check it on various platforms. It passes the checks on all but three 
platforms (intel, nosuggests, and rchk), and I am hoping for guidance on how to 
interpret the failures.

The package initially failed on the "ubuntu-clang" platform, but it passed when 
I reran it without any changes. I tried rerunning the checks on intel, 
nosuggests, and rchk, but it failed again on each one.

The failure details are given below. Should I worry about these errors when I 
resubmit to CRAN? 

- intel fails because of a problem loading "minqa", which is imported by 
"lme4", which my package suggests. The message reads:

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object 
'/github/home/R/x86_64-pc-linux-gnu-library/4.6/minqa/libs/minqa.so':
  libquadmath.so.0: cannot open shared object file: No such file or directory

I searched online for related errors, and found nothing about the intel 
platform from rhub specifically, but 
https://stackoverflow.com/questions/21149090/error-installing-minqa-in-r-3-0-2 
leads me to think that it might be an issue beyond an rhub user's control.

- nosuggests fails because it cannot rebuild the vignettes. The error message 
is "there is no package called 'rmarkdown'", which is not surprising given that 
"rmarkdown" is suggested for building vignettes. I hope this is not a 
deal-breaker for CRAN

- rchk fails for reasons that I cannot interpret. What I think is the relevant 
text is given below. My understanding is that this platform is used to test 
C/Fortran code included in a package, which mine does not use.

Run r-hub/actions/run-check@v1
Run # If env var is not set, we run R CMD CHECK, otherwise the
Run rchk.sh
Installing package
* installing *source* package ‘distfreereg’ ...
** this is package ‘distfreereg’ version ‘1.1’
not using staged install with --libs-only
** using non-staged installation
* DONE (distfreereg)
Run # Fail for rchk errors.
Fail for rchk errors
Run # Save binary package
Save binary package
Could not find binary package. 
Run actions/upload-artifact@v4
/usr/bin/docker exec  
6bc8600b43794ccf106ebb57224b520f4df047df97d9876c1d815f10f15ffaf6 sh -c "cat 
/etc/*release | grep ^ID"
Warning: No files were found with the provided path: check. No artifacts will 
be uploaded.


Thanks for any help,

Jesse

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