Re: R package CI test failures
>> However, since the working dir for the test is the root of the
extracted
>> source package, we should be able to extract the R and debian package
>> names directly rather than hardcoding or deriving them:
>>
>> rpkg=$(grep-dctrl -s Package -n '' DESCRIPTION)
>> dpkg=$(grep-dctrl -s Package -n '' debian/control)
>>
>> and in fact, skip finding tests and vignettes in the installed
>> filesystem and just find them in the source package: tests/*.R ;
>> vignettes/*.Rnw - in which case we don't need to know the package R or
>> debian names.
>
> I confirm that if you use the script for CI *only* this would work
> nicely. However, I consider it a good idea to provide the user with
> some test case / example use and thus I always put the script into
> /usr/share/doc/<pkgname> where grep-dctrl does not work. On the other
> hand I could check the directory name if all other means to calculate
> the package name might fail.
I hadn't considered other uses. However, there is maybe the possibility
of instead including a generic template and inserting the correct values
(determined as above) at build time?
However, since this would require modifying all the d/rules files, it is
maybe too much engineering to squash a few copy-paste bugs which are
mostly now fixed - to be added to the wishlist for debhelper-R?
> [...many packages fixed...]
>
>> - hopefully it'll look
>> in much better shape in a few days and we can see if CI is actually
>> doing its job and identifying some real errors.
>
> Yes.
Of the original list, I cound 24 (8 bioconductor and 16 cran) packages
now passing (on amd64 - most are still marked failed on arm64 but I
think that is just that the tests haven't re-run yet). Thanks to those
that committed fixes and uploaded.
>
>> I'll have a better look at the "?" ones.
>
Etiquette question - for packages in debian-science git requiring
trivial changes (eg, a missing package in debian/tests/control), is the
preferred course to just go ahead and commit the fix?
Reply to: