Hi Graham,
On 19 November 2023 at 13:49, Graham Inggs wrote:
| On Tue, 14 Nov 2023 at 12:42, Dirk Eddelbuettel <e...@debian.org> wrote:
| > Doesn't 'normal' do that?
|
| No, only serious and above are considered RC [1] and also for migration.
|
| This week, Paul Gevers and I spent some time discussing ways to move
| this transition forward.
|
| Referring back to some of your previous emails below.
|
| On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel <e...@debian.org> wrote:
| > We need to address the packages needing a rebuild. Mine (r-cran-lme4,
| > r-cran-rcppeigen). have been taken care of.
|
| We see the upload of lme4 1.1-35.1-2 on 2023-11-14 [2], and the
| changelog mentions a rebuild, but the upload of r-cran-rcppeigen
| 0.3.3.9.4-1 on 2023-11-03 [3] happened before the upload of matrix
| 1.6-2-1. Does r-cran-rcppeigen still require a rebuild?
I am upstream for RcppEigen.
And the upstream NEWS has
\item The interface to package \pkg{Matrix} has been updated and
simplified thanks to an excllent patch by Mikael Jagan.
\item The new upload is coordinated with packages \pkg{lme4} and
\pkg{OpenMx}.
So it contains a patch by Mikael which had been applied _permitting Matrix
1.6-2_ to get to CRAN. So for this particular pair it was the other way around.
And I acted accordingly as Debian maintainer for a package for which I am
upstream.
| On Mon, 13 Nov 2023 at 12:23, Dirk Eddelbuettel <e...@debian.org> wrote:
| > I would appreciate it if someone could tickle rebuilds. To me a quick
| > informal touch of debian/changelog would do; if someone thinks this needs a
| > formal transition go for it.
|
| We don't believe only touching debian/changelog, or a binNMU, is
| sufficient. We were surprised that your r-cran-lme4 upload did not at
| least include:
| Depends: r-cran-matrix (>= 1.6-2-1)
| Without that relationship, r-cran-lme4 could migrate to testing and be
| installed on users' systems without the corresponding version of
| r-cran-matrix. It is no surprise that the excuses page for lme4 [4]
| is all red, because that is exactly what is being tested. More on
| this to come in my next email.
I can add that, and probably should have. And I agree with the sentiment in
your other mail that a transition is overkill here.
Matrix has 1304 reverse dependencies at CRAN [1], Mikael (in the two emails
he wrote at my urging) identified 14 packages that needed a rebuild because
they use Matrix header files (R packages can build against headers in another
package, this is more specialised use), and another 3 that had cached S4 (the
more complicated OO model in R) function signature.
So 17 out of 1304 is not exactly a general breakage. I think I found 6 out of
the 17 as being in Debian. I had dealt with three myself and then sent email to
initiate
simple rebuilds. But that went nowhere.
So I leave this in your hands. If you think that after all this needs a
transtion, I may shrug but will of course help.
And please dDon't get wrong: I am considering this to be an open problem
upstream. The R Core team, the CRAN team, and others are discussing, but the
CRAN system does not quite have our mechanisms even to push binary
rebuilds. So this is an ongoing and open issue.
Dirk
[1] See the R snippet:
> db <- tools::CRAN_package_db()
> length(tools::package_dependencies("Matrix", reverse=TRUE, db=db)$Matrix)
[1] 1304
>
so 1304 are found right now at CRAN, and 17/1304 is about 1.3%. We seem
to have 6 identified out of about 138 (per apt-cache rdepends ...)
which is a little higher at 4.3% which is normal as 'heavier' packages
are more likely to be packaged. But net-net it is still only one out
over twenty packages around Matrix.
|
| Regards
| Graham
|
|
| [1] https://www.debian.org/Bugs/Developer#severities
| [2]
https://tracker.debian.org/news/1478501/accepted-lme4-11-351-2-source-into-unstable/
| [3]
https://tracker.debian.org/news/1475888/accepted-r-cran-rcppeigen-03394-1-source-into-unstable/
| [4] https://qa.debian.org/excuses.php?package=lme4
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
