Hi Dirk,
On Sun, Jul 06, 2014 at 10:27:53AM -0500, Dirk Eddelbuettel wrote:
> Yes, thanks -- it looks better now. I kept three tabs open on my desktop as
> reminder to come back to this 'at some point' (and I may still write a script
> to compare the CRAN status and what the Debian DB has -- mainly to finally
> learn about the Debian DB back end).
This might be helpful.
> Right now, I see these packages as out-of-date (and I wasn't thorough,
> scanning mostly for r-* only)
>
> - debian-med:
> catools
Need to check this.
> r-bioc-affy
This was a quite recent release.
> r-bioc-biovizbase
> r-bioc-bsgenome
> r-bioc-cummerbund
> r-bioc-edger
> r-bioc-genomicfeatures
> r-bioc-gviz
> r-bioc-iranges
> r-bioc-limma
> r-bioc-rsamtools
> r-bioc-rtracklayer
> r-bioc-shortread
All depend from r-bioc-biocparallel which is in new since several days. :-(
> r-cran-bbmisc
I'm discussing with upstream about the test suite which showed some issues.
> r-cran-g.data
> r-cran-genabel
Also problems with the test suite.
> - debian-science
> r-cran-colorspace
>
> - debichem
> r-cran-base64enc
Need to check these.
> (and a bunch of packages with wrong "policy" as we aim for
> r-other-$AUTHOR-$PACKAGE but then I never really finished the Policy so
> shame on me)
We could not only use a policy but also a mailing list for discussing this
kind of issues rather than a "random" bug report.
> | I keep on thinking that there is a difference between testing a source
> | package on a Debian machine and testing a binary in the chroot it was
> | built in. You did not answer how the test is done if not even all the
> | preconditions needed for a test are packaged.
>
> Several years ago, R changed how it tests its packages. It used to work from
> either the source dir, or the a tarball. These days, it stronly prefers a
> tarball.
I repeat: I was running the test suite manually and some packages had
missing requirements and some had failed tests. It seems these will not
show up in the test method you are mentioning. I feel it of topic to
discuss the single pieces here in the bug report.
> But post-build is simply not supported by R itself,
Well, I do not want to discuss whether it is suported by R itself. I
just think that we should add this value to the Debian packages if
possible and there are about 50% of packages I touched recently where
it is possible.
> even though has a _very
> robust_ and _widely used_ test system. If we go for automated testing (and
> we should, of course, though I'd prefer to see it being optional) then we are
> simply better off using 'R CMD check someTarFile_1.2-3.tar.gz'.
>
> Several packages try the test post-build, but __it is not standardized or
> even documented__ within the R ecosystem whereas the approach of using
But it is perfectly possible in the Debian ecosystem and this is what
I'm talking about.
> R CMD check someTarFile_1.2-3.tar.gz
>
> is at the same time understood, documented and even mandated.
Fine. So we can be save that this is just done and we can stop
discussing this here. Please, pretty please, stick to what I'm
discussing and what we also can approach. I just added autopkgtests
to those packages which are featuring tests. We now need to do
something to test at build time and as I suggested initially dh
has hooks like override_dh_autotest which could be used for non
standard tests.
> | I know that there are different testing frameworks - I just packaged one
> | of it (r-cran-testthat) to be able to do the testing. This is exactly
> | the point I want to make: We need to do the testing on a closed system
> | with Debian packaged code to be able to guarantee that the user gets a
> | package which was tested with the code we are delivering.
>
> See previous paragraphs. You think as a DD (which is normal) so you want to
> test post-build / post-install. That is __not generally supported by R__ so
> you are in for some work.
Exactly. As usual a bug report is triggering some work and I
wanted to trigger this work and I'm willing to test.
> | I would be really happy if you would stop trying to make this personal.
>
> I am not.
>
> But as you are the self-appointed emperor of these teams,
I'd be really happy if you would try to avoid terms like this. We have
no emperors in Debian teams and there is no such thing as
self-appointment. Thanks.
> Please keep packaged software current.
I try hard - but I also have other packages than R which are out of your
focus, sorry.
> And please believe me that I have nothing against "Andreas-the-person". I am
> in awe of all you have done for Debian; I am mostly sad about what I see as
> counterproductive outcomes (though I acknowledge happily that things are
> better now than a few months ago -- keep it up).
I will try, but I can not promise. What you call self-appointed emperor
is that I try to clean up behind others of the team and I show up in
more and more changelogs - way more than I want to. As long as nobody
else is grabbing packages up I'm struggling hard to keep packages up to
date and as you know not always successful. So I need to weight my time
and it can not always be put on the R-side of our packages. As I said
I'm fine with any team upload (which can be done by any DD) or I always
try to respond to "burning issues".
> And I am also very grateful for the earlier patches against r-cran.mk. They
> helped quite a bit.
:-)
> Now: as for the "dh" transition of r-cran.mk (or another replacement
> dh_r-build or whatever). That would be nice. And we can then see how to
> opt-in for tests. I will let this rest and see over the next few weeks /
> months if Don and I can get this going. We have debian-r.debian.net as a
> test bed to try things on, as I remain relunctant to change / break the
> current system "just because".
Sounds good.
> Ditto for a possible r-base-api-N package for R transition. I think Don
> convinced me of a way to do this, and as long as I don't forget all the
> details I will try to take a shot at implementing this.
Sounds good as well. If you ask me the best way to approach this would be
to register an alioth project for R and use a version control system which
would enable other to look at the code and provide patches.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
