Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham On 30 November 2023 at 07:54, Graham Inggs wrote: | Hi Dirk | | On Thu, 30 Nov 2023 at 00:51, Dirk Eddelbuettel wrote: | > Ping squared. | > | > If I don't hear from you I may just close this. I believe this (non-, to me) | > issue has been taken care of. If you think I am wrong please let me know. | | I closed it on 2023-11-24 [1]. Where do you see it still open? My bad: I don't. I just didn't see an explicit ack. (General bts acks are filtered away by procmail to a different folder). So my bad and sorry for wasting your time. I see you track it at Ubuntu too so all good. r2u, which dominates of course all r-(cran,bioc)-* packages for use on jammy had it long covered. Cheers, Dirk | | [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055922#118 -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Dirk On Thu, 30 Nov 2023 at 00:51, Dirk Eddelbuettel wrote: > Ping squared. > > If I don't hear from you I may just close this. I believe this (non-, to me) > issue has been taken care of. If you think I am wrong please let me know. I closed it on 2023-11-24 [1]. Where do you see it still open? Regards Graham [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055922#118
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 27 November 2023 at 08:27, Dirk Eddelbuettel wrote: | | Graham, | | Quick ping to ask where we are we on this? Matrix is in testing so can this | be closed? Ping squared. If I don't hear from you I may just close this. I believe this (non-, to me) issue has been taken care of. If you think I am wrong please let me know. Dirk | Cheers, Dirk | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Graham, Quick ping to ask where we are we on this? Matrix is in testing so can this be closed? Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham, Am Tue, Nov 21, 2023 at 06:20:01PM -0100 schrieb Graham Inggs: > I think this means at least r-cran-seuratobject (not r-cran-seurat > itself) is also in need of your fix [1], if only to silence that > warning. Would you please take care of that? Done. Thanks for checking Andreas. -- http://fam-tille.de
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Andreas On Mon, 20 Nov 2023 at 13:07, Andreas Tille wrote: > Since I have no idea what the failures in r-cran-seurat test > log[6] mean I would prefer to wait until we can upload the latest > version. > > > [6] https://ci.debian.net/packages/r/r-cran-seurat/unstable/amd64/40043272/ I had a look at that log and I saw the following: Attaching SeuratObject ‘SeuratObject’ was built with package ‘Matrix’ 1.6.1.1 but the current version is 1.6.3; it is recomended that you reinstall ‘SeuratObject’ as the ABI for ‘Matrix’ may have changed I think this means at least r-cran-seuratobject (not r-cran-seurat itself) is also in need of your fix [1], if only to silence that warning. Would you please take care of that? Regards Graham [1] https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/92579f72c2db4d51a45cf317f580d790da158f4f
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham, Am Mon, Nov 20, 2023 at 12:21:39PM -0100 schrieb Graham Inggs: > For the r-cran-tmb upload, I now see only autopkgtest regressions [1] for: > r-cran-insight/0.19.6+dfsg-1 > r-cran-parameters/0.21.2-1 > I have not investigated, but these seem to be passing in unstable, so > can be hinted if needed. OK, let me know if I should do something. > For the r-cran-irlba upload, there's only one autopkgtest regression [2] for: > r-cran-seurat/4.4.0-1 > This autopkgtest currently fails in unstable as well, would you please > investigate? By chance I tried to upgrade r-cran-seurat a couple of hours ago since there is a new upstream version (which follows r-cran-seuratobject version bump). Unfortunately it needs a new dependency which I pushed to new[5]. Since I have no idea what the failures in r-cran-seurat test log[6] mean I would prefer to wait until we can upload the latest version. > It seems your r-cran-seuratobject 5.0.0-1 upload is blocked by this > same regression for 19 days [3] and r-cran-seurat has not yet been > updated to the new upstream version 5.0.1. Does something prevent you > from updating? See above. > For the r-cran-openmx upload, there are no autopkgtest regressions [4] > \o/ Nice. > > I've reverted this but in previous discussion[4] with Paul we agreed > > upon the strict version dependency. I think this is only necessary for > > r-cran-tmb (where upstream is enforcing this with a test I'm hesitating > > to patch out). But maybe upstream can work with the freshly implemented > > R_MATRIX_ABI_VERSION and thus we can come back to upstream if the > > autopkgtest will fire next time (which will happen now after the next > > r-cran-matrix update). > > Thanks again. Yes, let's wait to see how TMB upstream deals with this. Kind regards and thank you for your work in release team Andreas. > [1] https://qa.debian.org/excuses.php?package=r-cran-tmb > [2] https://qa.debian.org/excuses.php?package=r-cran-irlba > [3] https://qa.debian.org/excuses.php?package=r-cran-seuratobject > [4] https://qa.debian.org/excuses.php?package=r-cran-openmx [5] https://ftp-master.debian.org/new/r-cran-fastdummies_1.7.3-1.html [6] https://ci.debian.net/packages/r/r-cran-seurat/unstable/amd64/40043272/ -- http://fam-tille.de
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham, On 20 November 2023 at 12:13, Graham Inggs wrote: | On Sun, 19 Nov 2023 at 14:59, Dirk Eddelbuettel wrote: | > 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. | | Great, thanks for clearing that up. | | > 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. | | Well, we are doing a transition (for some value of), just not a | "rebuild everything" transition like we must do for C libraries, but a | "rebuild only affected things" like we do for Python and other | interpreted languages. | | On Sun, 19 Nov 2023 at 17:28, Dirk Eddelbuettel wrote: | > Done in lme4 1.1-35.1-3. | | Thanks. I see now r-cran-lme4 now has a: | Depends: r-cran-matrix (>= 1.6-2) | ...however this is not correct, because dpkg considers r-cran-matrix | 1.6-1.1-1 in testing to meet that requirement, and the tests still | fail with that version. | | $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2 && echo True | True | | Please change that to: | Depends: r-cran-matrix (>= 1.6-2-1) | ... and re-upload, because dpkg considers 1.6-2 to be upstream version | 1.6 and Debian revision 2, whereas we need upstream version 1.6-2 and | Debian revision 1. | | $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2-1 && echo True | Dang. Fell into a well-known hole there. Will fix ASAP. Had in the back of my mind some notion of 'cannot express Debian build number' but that is clearly wrong. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Andreas On Mon, 20 Nov 2023 at 06:59, Andreas Tille wrote: > > We liked the change you made to r-cran-tmb [2], as this allows the > > affected packages to be binNMU'd and gain a versioned dependency on > > r-cran-matrix. Would you please apply this to the other affected > > packages (only r-cran-irlba and r-cran-openmx, if I understand > > correctly)? > > Done. Thanks! For the r-cran-tmb upload, I now see only autopkgtest regressions [1] for: r-cran-insight/0.19.6+dfsg-1 r-cran-parameters/0.21.2-1 I have not investigated, but these seem to be passing in unstable, so can be hinted if needed. For the r-cran-irlba upload, there's only one autopkgtest regression [2] for: r-cran-seurat/4.4.0-1 This autopkgtest currently fails in unstable as well, would you please investigate? It seems your r-cran-seuratobject 5.0.0-1 upload is blocked by this same regression for 19 days [3] and r-cran-seurat has not yet been updated to the new upstream version 5.0.1. Does something prevent you from updating? For the r-cran-openmx upload, there are no autopkgtest regressions [4] \o/ > I've reverted this but in previous discussion[4] with Paul we agreed > upon the strict version dependency. I think this is only necessary for > r-cran-tmb (where upstream is enforcing this with a test I'm hesitating > to patch out). But maybe upstream can work with the freshly implemented > R_MATRIX_ABI_VERSION and thus we can come back to upstream if the > autopkgtest will fire next time (which will happen now after the next > r-cran-matrix update). Thanks again. Yes, let's wait to see how TMB upstream deals with this. Regards Graham [1] https://qa.debian.org/excuses.php?package=r-cran-tmb [2] https://qa.debian.org/excuses.php?package=r-cran-irlba [3] https://qa.debian.org/excuses.php?package=r-cran-seuratobject [4] https://qa.debian.org/excuses.php?package=r-cran-openmx
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Dirk On Sun, 19 Nov 2023 at 14:59, Dirk Eddelbuettel wrote: > 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. Great, thanks for clearing that up. > 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. Well, we are doing a transition (for some value of), just not a "rebuild everything" transition like we must do for C libraries, but a "rebuild only affected things" like we do for Python and other interpreted languages. On Sun, 19 Nov 2023 at 17:28, Dirk Eddelbuettel wrote: > Done in lme4 1.1-35.1-3. Thanks. I see now r-cran-lme4 now has a: Depends: r-cran-matrix (>= 1.6-2) ...however this is not correct, because dpkg considers r-cran-matrix 1.6-1.1-1 in testing to meet that requirement, and the tests still fail with that version. $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2 && echo True True Please change that to: Depends: r-cran-matrix (>= 1.6-2-1) ... and re-upload, because dpkg considers 1.6-2 to be upstream version 1.6 and Debian revision 2, whereas we need upstream version 1.6-2 and Debian revision 1. $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2-1 && echo True Regards Graham
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham,
Am Sun, Nov 19, 2023 at 01:55:04PM -0100 schrieb Graham Inggs:
> On Sat, 18 Nov 2023 at 19:18, Andreas Tille wrote:
> > We need some means to follow ABI changes. In Debian we could use
> > something like r-matrix-abi-VERSION.
>
> Indeed, this is one solution. As you saw in [1], upstream now provide
> an ABI version and a way to extract it:
> > Matrix will commence ABI versioning in 1.6-2. The ABI version will be
> > available
> > in R as Matrix.Version()[["abi"]] and in C as R_MATRIX_ABI_VERSION (from
> > header
> > Matrix/Matrix.h). It is numeric_version("1") in Matrix 1.6-2 and
> > _implicitly_
> > numeric_version("0") in Matrix < 1.6-2.
I'd personally would prefer, if we would implement this ABI versioning
in our packaging in the long term.
> However, since rmatrix has over 100 reverse-dependencies, and only a
> very small number of these are broken by the ABI change, we feel this
> may be overkill, but wouldn't dissuade anyone from proposing patches
> to implement this.
This somehow reminds me to bug #1040038 where r-graphics-engine was
implemented in r-base. I'm willing to help with the implementation of
R_MATRIX_ABI_VERSION but my motivation would be increased if the
authorship of the patches would be mentioned at least in d/changelog
(which was not the case for r-graphics-engine).
> Another option is simply to add a versioned dependency on
> r-cran-matrix to the affected packages, e.g.:
> Depends: r-cran-matrix (>= 1.6-2-1)
> ...but this requires a source change and an upload, is error-prone,
> and a binNMU would not be sufficient.
>
> We liked the change you made to r-cran-tmb [2], as this allows the
> affected packages to be binNMU'd and gain a versioned dependency on
> r-cran-matrix. Would you please apply this to the other affected
> packages (only r-cran-irlba and r-cran-openmx, if I understand
> correctly)?
Done.
> Unfortunately, it seems the two-sided dependency introduced
> subsequently [3], which produces:
> r-cran-matrix (>= 1.6-2-1), r-cran-matrix (<= 1.6-2-199)
> ...is too strict, and r-cran-tmb already needs another rebuild due to
> the upload of rmatrix 1.6-3-1. Would you please revert that change
> and upload?
I've reverted this but in previous discussion[4] with Paul we agreed
upon the strict version dependency. I think this is only necessary for
r-cran-tmb (where upstream is enforcing this with a test I'm hesitating
to patch out). But maybe upstream can work with the freshly implemented
R_MATRIX_ABI_VERSION and thus we can come back to upstream if the
autopkgtest will fire next time (which will happen now after the next
r-cran-matrix update).
Kind regards
Andreas.
> [1] https://stat.ethz.ch/pipermail/r-sig-mac/2023-October/014890.html
> [2]
> https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/92579f72c2db4d51a45cf317f580d790da158f4f
> [3]
> https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/0a4d35d10f9c875863fa0238287cee8ab25aecdd
[4] https://lists.debian.org/debian-r/2023/11/msg7.html
--
http://fam-tille.de
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 19 November 2023 at 09:59, Dirk Eddelbuettel wrote: | On 19 November 2023 at 13:49, Graham Inggs wrote: | | 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. Done in lme4 1.1-35.1-3. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Graham,
On 19 November 2023 at 13:49, Graham Inggs wrote:
| On Tue, 14 Nov 2023 at 12:42, Dirk Eddelbuettel 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 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 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
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Andreas
On Sat, 18 Nov 2023 at 19:18, Andreas Tille wrote:
> We need some means to follow ABI changes. In Debian we could use
> something like r-matrix-abi-VERSION.
Indeed, this is one solution. As you saw in [1], upstream now provide
an ABI version and a way to extract it:
> Matrix will commence ABI versioning in 1.6-2. The ABI version will be
> available
> in R as Matrix.Version()[["abi"]] and in C as R_MATRIX_ABI_VERSION (from
> header
> Matrix/Matrix.h). It is numeric_version("1") in Matrix 1.6-2 and _implicitly_
> numeric_version("0") in Matrix < 1.6-2.
However, since rmatrix has over 100 reverse-dependencies, and only a
very small number of these are broken by the ABI change, we feel this
may be overkill, but wouldn't dissuade anyone from proposing patches
to implement this.
Another option is simply to add a versioned dependency on
r-cran-matrix to the affected packages, e.g.:
Depends: r-cran-matrix (>= 1.6-2-1)
...but this requires a source change and an upload, is error-prone,
and a binNMU would not be sufficient.
We liked the change you made to r-cran-tmb [2], as this allows the
affected packages to be binNMU'd and gain a versioned dependency on
r-cran-matrix. Would you please apply this to the other affected
packages (only r-cran-irlba and r-cran-openmx, if I understand
correctly)?
Unfortunately, it seems the two-sided dependency introduced
subsequently [3], which produces:
r-cran-matrix (>= 1.6-2-1), r-cran-matrix (<= 1.6-2-199)
...is too strict, and r-cran-tmb already needs another rebuild due to
the upload of rmatrix 1.6-3-1. Would you please revert that change
and upload?
Regards
Graham
[1] https://stat.ethz.ch/pipermail/r-sig-mac/2023-October/014890.html
[2]
https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/92579f72c2db4d51a45cf317f580d790da158f4f
[3]
https://salsa.debian.org/r-pkg-team/r-cran-tmb/-/commit/0a4d35d10f9c875863fa0238287cee8ab25aecdd
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Dirk On Tue, 14 Nov 2023 at 12:42, Dirk Eddelbuettel 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 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? On Mon, 13 Nov 2023 at 12:23, Dirk Eddelbuettel 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. 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
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
I will not engage any more with debian-r. But this is now at the BTS so a clarification may be in order. This started as I had sent an email as a heads-up to fellow maintainers (via that mostly pointless list) informing them that their packages would exhibit a bug following a bug in package Matrix. Now, net-net all I got out of this is a 'severity: serious' bug against my own package, and a beyond-stupid situation (sadly also not a first time) where the affected maintainer now acts like a three-year and refuses to update his known-broken packages. And I repeact that it was upstream (for Matrix) who asked (publically, on a R list) for a rebuild. Going forward, I will simply not send such courtesy emails. Life is too short. I will let just those follow maintainers continue to waste the time of the release managers by trying random combination of packages and then acting surprised that breakage happens. CRAN is well known to work exceedingly well at '@HEAD' (occasional bugs among what are now over 20k packages notwithstanding). But some people refuse to understand or acknowledge that and enjoy fighting fight pointless fights. We can all choose our own adventure, but that particular one is of no interest to me. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Am Fri, Nov 17, 2023 at 12:52:29PM -0600 schrieb Dirk Eddelbuettel: > | Anyway. Now that you made it a bug I let you drive this. Upstream just made > | an unrelated bugfix Matrix 1.6-3 which I just sent to unstable. > > There are two known failures left which the maintainer(s) do not want to fix. Again: Please stop blaming other maintainers for not doing what you want. We need some means to follow ABI changes. In Debian we could use something like r-matrix-abi-VERSION. As long as you not discussing this in a qualified wording I will not upload any package that is affected since I see my time wasted to discuss this in the next ABI change again and again. You were teached by Nilesh[1] about the right way to go (BTW, thanks for scaring away Nilesh[2].) > As I have fixed my dependents of package Matrix, I continue to find it unfair > that I am being to an open bug requiring fixes via builds in other packages > that are not mine. So I guess this bug will stay open 'forever' or > until those packages get normal routine updates. You were also told that even this statement is wrong.[3] Finger pointing to others and claiming you can't do anything is what I call unfair. Kind regards Andreas. [1] https://lists.debian.org/debian-r/2023/11/msg00049.html [2] https://lists.debian.org/debian-r/2023/11/msg00054.html [3] https://lists.debian.org/debian-r/2023/11/msg00044.html -- http://fam-tille.de
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 14 November 2023 at 07:42, Dirk Eddelbuettel wrote: | | On 14 November 2023 at 12:26, Graham Inggs wrote: | | Hi Dirk | | | | On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote: | | > Well that seems to be a) the wrong severity and b) the wrong package. | | | | Both are correct. We do not want rmatrix to migrate and break | | packages in testing. | | Doesn't 'normal' do that? I always get the shivers when I see 'serious' as I | fear that my package is at the risk of removal (which we of course Matrix | can't be 'really' given its systemic status from its "recommended" status | within R and very widespread use). | | | However, in this case, I only set the severity to match reality; | | rmatrix is already blocked from migrating due to the autopkgtest | | regressions. | | | | > We need to address the packages needing a rebuild. Mine (r-cran-lme4, | | > r-cran-rcppeigen). have been taken care of. | | | | Agreed, and rmatrix may need some new Breaks to allow the affected | | packages to migrate together. | | The issue is actually hugely problematic for CRAN and R Core, and there are | some discussions but no solutions. They do not have (formal) notions like | binary rebuild for parts where they distribute binaries, and no means of | reaching binary redistributors such as us. Oh well. At least it doesn't | happen often. | | Anyway. Now that you made it a bug I let you drive this. Upstream just made | an unrelated bugfix Matrix 1.6-3 which I just sent to unstable. There are two known failures left which the maintainer(s) do not want to fix. As I have fixed my dependents of package Matrix, I continue to find it unfair that I am being to an open bug requiring fixes via builds in other packages that are not mine. So I guess this bug will stay open 'forever' or until those packages get normal routine updates. Dirk | | Dirk | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 14 November 2023 at 12:26, Graham Inggs wrote: | Hi Dirk | | On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote: | > Well that seems to be a) the wrong severity and b) the wrong package. | | Both are correct. We do not want rmatrix to migrate and break | packages in testing. Doesn't 'normal' do that? I always get the shivers when I see 'serious' as I fear that my package is at the risk of removal (which we of course Matrix can't be 'really' given its systemic status from its "recommended" status within R and very widespread use). | However, in this case, I only set the severity to match reality; | rmatrix is already blocked from migrating due to the autopkgtest | regressions. | | > We need to address the packages needing a rebuild. Mine (r-cran-lme4, | > r-cran-rcppeigen). have been taken care of. | | Agreed, and rmatrix may need some new Breaks to allow the affected | packages to migrate together. The issue is actually hugely problematic for CRAN and R Core, and there are some discussions but no solutions. They do not have (formal) notions like binary rebuild for parts where they distribute binaries, and no means of reaching binary redistributors such as us. Oh well. At least it doesn't happen often. Anyway. Now that you made it a bug I let you drive this. Upstream just made an unrelated bugfix Matrix 1.6-3 which I just sent to unstable. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Hi Dirk On Tue, 14 Nov 2023 at 12:01, Dirk Eddelbuettel wrote: > Well that seems to be a) the wrong severity and b) the wrong package. Both are correct. We do not want rmatrix to migrate and break packages in testing. However, in this case, I only set the severity to match reality; rmatrix is already blocked from migrating due to the autopkgtest regressions. > We need to address the packages needing a rebuild. Mine (r-cran-lme4, > r-cran-rcppeigen). have been taken care of. Agreed, and rmatrix may need some new Breaks to allow the affected packages to migrate together. Regards Graham
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
On 14 November 2023 at 09:15, Graham Inggs wrote: | Source: rmatrix | Version: 1.6-2-1 | Severity: serious | X-Debbugs-Cc: debia...@lists.debian.org | | Hi Dirk | | I'm opening this bug as a place for discussion and to track the | affected packages. It can be closed once rmatrix and its | reverse-dependencies are ready to migrate. Well that seems to be a) the wrong severity and b) the wrong package. We need to address the packages needing a rebuild. Mine (r-cran-lme4, r-cran-rcppeigen). have been taken care of. Dirk | I've copied your email to the debian-r mailing list [1] below. | | Regards | Graham | | | [1] https://lists.debian.org/debian-r/2023/11/msg00033.html | | | Package Matrix is having a new and energetic maintainer/contributor in Mikael | Jagan who is tidying up a few loose corners (and inter alia sent me a patch | to RcppEigen that resulted in a coordinated CRAN update of RcppEigen, lme4, | and OpenMx). | | Mikael also identified two sets of packages needed a rebuild in messages to | the r-package-devel list (the more-or-less official place in the R Project to | ask / discuss package changes, it is a decent to be on) following private | mails between him and me. See | | https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010051.html | https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010054.html | | The first concerns packages using a LinkingTo: Matrix and building against | Matrix _headers_. The second concerns caching of S4 signatures (which bit us | at work because of SeuratObject [not in Debian] and how I got onto this). | | Most of these are not in Debian but I think we need binary rebuilds of | |irlbabecause of headers |OpenMx because of headers, a new upstream 2.21.10 is out too |TMB because of headers |MatrixModels because of S4 caching | | 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. | | The R Core team and the CRAN maintainers are aware of the implicit problem | with signalling the need for binary rebuilds. They are discussing this, but | do not have an answer. Historically, CRAN has informally rebuilt its binaries | for windows and macOS, but that of course does not help binary distributors | such as us, other Linux distros, Conda, r2u, ... at all. -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1055922: rmatrix: ABI change in Matrix 1.6-2
Source: rmatrix Version: 1.6-2-1 Severity: serious X-Debbugs-Cc: debia...@lists.debian.org Hi Dirk I'm opening this bug as a place for discussion and to track the affected packages. It can be closed once rmatrix and its reverse-dependencies are ready to migrate. I've copied your email to the debian-r mailing list [1] below. Regards Graham [1] https://lists.debian.org/debian-r/2023/11/msg00033.html Package Matrix is having a new and energetic maintainer/contributor in Mikael Jagan who is tidying up a few loose corners (and inter alia sent me a patch to RcppEigen that resulted in a coordinated CRAN update of RcppEigen, lme4, and OpenMx). Mikael also identified two sets of packages needed a rebuild in messages to the r-package-devel list (the more-or-less official place in the R Project to ask / discuss package changes, it is a decent to be on) following private mails between him and me. See https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010051.html https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010054.html The first concerns packages using a LinkingTo: Matrix and building against Matrix _headers_. The second concerns caching of S4 signatures (which bit us at work because of SeuratObject [not in Debian] and how I got onto this). Most of these are not in Debian but I think we need binary rebuilds of irlbabecause of headers OpenMx because of headers, a new upstream 2.21.10 is out too TMB because of headers MatrixModels because of S4 caching 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. The R Core team and the CRAN maintainers are aware of the implicit problem with signalling the need for binary rebuilds. They are discussing this, but do not have an answer. Historically, CRAN has informally rebuilt its binaries for windows and macOS, but that of course does not help binary distributors such as us, other Linux distros, Conda, r2u, ... at all.
