Hi Dirk, all,
On Fri, 9 Apr 2021 15:20:37 -0500 Dirk Eddelbuettel wrote:
> On 9 April 2021 at 10:43, Graham Inggs wrote:
> | Control: tags -1 + fixed-upstream
> |
> | Fixed in Matrix upstream svn rev 3376 [1].
> |
> |
> | [1]
>
On 8 April 2021 at 11:29, Graham Inggs wrote:
| Control: forwarded -1 https://deb.li/6f4z
|
| TMB upstream have submitted a bug report [1] to R-forge.
|
| > Headers need update corresponding to new SuiteSparse version 5.7.1
| >
| > SuiteSparse was recently updated from version 4.2.1 to 5.7.1,
Control: tags -1 + fixed-upstream
Fixed in Matrix upstream svn rev 3376 [1].
[1]
https://r-forge.r-project.org/scm/viewvc.php?view=rev=matrix=3376
Control: forwarded -1 https://deb.li/6f4z
TMB upstream have submitted a bug report [1] to R-forge.
> Headers need update corresponding to new SuiteSparse version 5.7.1
>
> SuiteSparse was recently updated from version 4.2.1 to 5.7.1, however without
> updating the header `inst/cholmod.h`
On Tue, Mar 9, 2021 at 2:23 PM Dirk Eddelbuettel wrote:
>
>
> On 9 March 2021 at 14:26, Graham Inggs wrote:
> | Control: tags -1 - fixed-upstream + upstream
> | Control: notforwarded -1
> |
> |
> | >From TMB upstream [1]:
> |
> | > Digging a bit deeper I found that after calling
> | >
> | >
On 9 March 2021 at 14:26, Graham Inggs wrote:
| Control: tags -1 - fixed-upstream + upstream
| Control: notforwarded -1
|
|
| >From TMB upstream [1]:
|
| > Digging a bit deeper I found that after calling
| >
| > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, )
| >
| > the
Control: tags -1 - fixed-upstream + upstream
Control: notforwarded -1
>From TMB upstream [1]:
> Digging a bit deeper I found that after calling
>
> M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, )
>
> the cholmod_common struct contains bogus, e.g. c.status=14903956 and
>
Hi Graham and Martin,
Thanks for coming back to this, I had also meant to write to Martin this
weekend.
On 6 March 2021 at 19:16, Graham Inggs wrote:
| Is there a bug opened for this issue with Matrix upstream?
Per field Bug-Reports in DESCRIPTION, the repo (and bug tracker) are (still)
at
Hi Dirk
Is there a bug opened for this issue with Matrix upstream?
I may have some useful feedback from TMB upstream to add.
Regards
Graham
Graham, Martin,
So I logged back onto the s390x box we can access. Matrix 1.13-2 does fail
the factorization test when doing
_R_CHECK_FORCE_SUGGESTS_=false R CMD check --no-manual \
--no-vignettes Matrix_1.3-2.tar.gz
and Matrix 1.2-18 passes it. So Graham was right all-along
On Tue, Feb 23, 2021 at 3:17 PM Graham Inggs wrote:
>
> Hi Dirk
>
> On Tue, 23 Feb 2021 at 15:34, Dirk Eddelbuettel wrote:
> > If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just
> > on s390x) and move on.
>
> That would just be hiding the problem.
>
> If it is the kind
Hi Dirk
On Tue, 23 Feb 2021 at 15:34, Dirk Eddelbuettel wrote:
> If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just
> on s390x) and move on.
That would just be hiding the problem.
If it is the kind of bug I described previously, it shows up more
often on big-endian
Control: affects -1 src:r-cran-glmmtmb
Control: affects -1 src:r-cran-tmb
Hi Andreas
On Tue, 23 Feb 2021 at 10:30, Andreas Tille wrote:
> If we do not find a timely solution what do you think about excluding
> s390x temporarily from the list of architectures of this package and set
> this bug
If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just
on s390x) and move on. I still have not been convinced by anyone that it is
an issue in package Matrix causing this.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Control: reassign -1 src:rmatrix 1.3-0-1
Control: tags -1 - fixed-upstream
Control: forwarded -1 https://github.com/kaskr/adcomp/issues/340
Hi Dirk
On Thu, 18 Feb 2021 at 19:58, Dirk Eddelbuettel wrote:
> Thanks for the bug tracker follow-up which made me aware of the ongoing
> discussion in
Hi,
any update to this bug?
If we do not find a timely solution what do you think about excluding
s390x temporarily from the list of architectures of this package and set
this bug to "important"?
I would not be happy about this but the issue creates some autoremoval
warnings on other packages
Graham,
Thanks for the bug tracker follow-up which made me aware of the ongoing
discussion in #665 at glmmTMB. It's frustrating to have the run around but it
really looks like as I argued all along: not an issue in Matrix. Now, TMB is
of course a complex package too.. Appreciate you chasing
On 17 February 2021 at 16:58, Graham Inggs wrote:
| Hi Dirk
|
| On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel wrote:
| > Graham: What does that bigendian box say for Sys.info()[["machine"]] ?
|
| The other big-endian box I tested was perotto.debian.net [*], it says:
|
| >
Hi Dirk
On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel wrote:
> Graham: What does that bigendian box say for Sys.info()[["machine"]] ?
The other big-endian box I tested was perotto.debian.net [*], it says:
> Sys.info()[["machine"]]
[1] "ppc64"
> Should we test for endianness instead?
Hi Martin,
On 17 February 2021 at 10:43, Martin Maechler wrote:
| Dear Dirk,
| I'm in vacations right now ...
Ah, nice.
| 1) I think I might simply disable the check *on* that platform .. or
| platforms with similar characteristics.
Sounds good to me.
| Can you send me the outputs of so
Hi Martin
On Wed, 17 Feb 2021 at 11:45, Martin Maechler wrote:
> 1) I think I might simply disable the check *on* that platform .. or
> platforms with similar characteristics.
I was able to reproduce the issue on our big-endian PowerPC
architecture as well, so maybe you can use the following
Dear Dirk,
I'm in vacations right now ...
1) I think I might simply disable the check *on* that platform .. or
platforms with similar characteristics.
Can you send me the outputs of so I can take some of the entries to
determine I'm on the platform?
sessionInfo()
str(.Machine, digits=10)
Martin,
I have this long-running bug report against Matrix, triggered by glmmTMB on
s390x. Graham has been chasing this patiently and we are now at the level of
checking on a shell account on the appropriate hardware.
We validated that everything does in fact "still break" with CRAN-current
Hi Dirk
On Sun, 14 Feb 2021 at 15:57, Dirk Eddelbuettel wrote:
> Sure. Just fire up R on the box, don't install anything beyond r-base-core
> (and maybe r-recommended accounting for a few of the ones above) and then say
Perfect, thank you!
I installed only r-base-core and r-base-dev (gfortran,
On 14 February 2021 at 12:00, Graham Inggs wrote:
| glmmTMB upstream came up with a minimal reproducer (see forwarded bug):
|
| stopifnot(require("testthat"),
| require("glmmTMB"),
| require("lme4"))
| data("Orthodont", package="nlme")
| fm1 <- glmmTMB(distance ~ age +
glmmTMB upstream came up with a minimal reproducer (see forwarded bug):
stopifnot(require("testthat"),
require("glmmTMB"),
require("lme4"))
data("Orthodont", package="nlme")
fm1 <- glmmTMB(distance ~ age + (age|Subject), data = Orthodont)
I can confirm this fails on the s390x
Hi Graham,
On 2 February 2021 at 11:32, Graham Inggs wrote:
| Control: forwarded -1 https://github.com/glmmTMB/glmmTMB/issues/665
|
| After another detour via #981623, r-cran-glmmtmb is now also rebuilt.
| Even with the rebuilt r-cran-glmmtmb, I still see the "gradient
| function must return a
Control: forwarded -1 https://github.com/glmmTMB/glmmTMB/issues/665
After another detour via #981623, r-cran-glmmtmb is now also rebuilt.
Even with the rebuilt r-cran-glmmtmb, I still see the "gradient
function must return a numeric vector of length" errors on s390x and
ppc64, which are both
On 31 January 2021 at 20:09, Graham Inggs wrote:
| Hi Dirk
|
| On Sun, 31 Jan 2021 at 16:13, Dirk Eddelbuettel wrote:
| > This is a bug in glmmTMB.
|
| I don't see how you can be so sure.
Experience around R. glmmTMB is a huge package with many dependencies, there
will be a stale one in the
Hi Dirk
On Sun, 31 Jan 2021 at 16:13, Dirk Eddelbuettel wrote:
> This is a bug in glmmTMB.
I don't see how you can be so sure.
> All the 'gradient function must ...' errors are from its tests and
> points to me to a recent change in R (where boolean comparisons can now check
> if the compared
On 31 January 2021 at 09:20, Graham Inggs wrote:
| Control: reopen -1
|
| Hi Dirk
|
| Paul's test results showed that the run-unit-test autopkgtest still
| fails with the same errors (
| Error: gradient function must return a numeric vector of length...) as
| in my original report.
|
|
| The
Control: reopen -1
Hi Dirk
Paul's test results showed that the run-unit-test autopkgtest still
fails with the same errors (
Error: gradient function must return a numeric vector of length...) as
in my original report.
The "Package version inconsistency detected" warning is now gone (due
to
Hi Graham,
On 28 January 2021 at 08:19, Graham Inggs wrote:
| On Thu, 28 Jan 2021 at 01:12, Dirk Eddelbuettel wrote:
| > Any update here? It still points at Matrix aka rmatrix aka r-cran-matrix,
| > and I still think wrongly.
|
| I'm still waiting for the results of the autopkgtest against
Hi Dirk
On Thu, 28 Jan 2021 at 01:12, Dirk Eddelbuettel wrote:
> Any update here? It still points at Matrix aka rmatrix aka r-cran-matrix,
> and I still think wrongly.
I'm still waiting for the results of the autopkgtest against the
rebuilt r-cran-tmb on s390x.
Unfortunately, it went into the
Graham,
Any update here? It still points at Matrix aka rmatrix aka r-cran-matrix,
and I still think wrongly.
Best, Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Hi Graham,
On 23 January 2021 at 00:21, Graham Inggs wrote:
| On Fri, 22 Jan 2021 at 23:38, Dirk Eddelbuettel wrote:
| > Can you still please talk to the corresponding Debian maintainer for glmmTMB
| > so that he/she can walk it upstream?
|
| I have assigned this bug to both packages, until
Hi Dirk
On Fri, 22 Jan 2021 at 23:38, Dirk Eddelbuettel wrote:
> Can you still please talk to the corresponding Debian maintainer for glmmTMB
> so that he/she can walk it upstream?
I have assigned this bug to both packages, until we can figure out
where the fix needs to happen.
> The package
Hi Graham,
On 22 January 2021 at 23:13, Graham Inggs wrote:
| Hi Dirk
|
| On Fri, 22 Jan 2021 at 22:39, Dirk Eddelbuettel wrote:
| > Matrix 1.3.0 from December has long been known to fail. Please use release
1.3.2.
|
| The test at [2], run at 2021-01-22 17:34:51 UTC was against
|
Hi Dirk
On Fri, 22 Jan 2021 at 22:39, Dirk Eddelbuettel wrote:
> Matrix 1.3.0 from December has long been known to fail. Please use release
> 1.3.2.
The test at [2], run at 2021-01-22 17:34:51 UTC was against
r-cran-matrix/1.3-2-1, see below:
Get:61 http://deb.debian.org/debian testing/main
On 22 January 2021 at 22:03, Graham Inggs wrote:
| While investigating this failure, I noticed the following output in
| the test log:
|
|
| > library('glmmTMB')
| Warning message:
| In checkMatrixPackageVersion() : Package version inconsistency detected.
| TMB was built with Matrix version
On 22 January 2021 at 21:45, Graham Inggs wrote:
| Source: rmatrix, r-cran-glmmtmb
| Control: found -1 rmatrix/1.3-0-1
| Control: found -1 r-cran-glmmtmb/1.0.2.1-1
| Severity: serious
| Tags: sid bullseye
| X-Debbugs-CC: debian...@lists.debian.org
| User: debian...@lists.debian.org
| Usertags:
While investigating this failure, I noticed the following output in
the test log:
> library('glmmTMB')
Warning message:
In checkMatrixPackageVersion() : Package version inconsistency detected.
TMB was built with Matrix version 1.2.18
Current Matrix version is 1.3.2
Please re-install 'TMB' from
Source: rmatrix, r-cran-glmmtmb
Control: found -1 rmatrix/1.3-0-1
Control: found -1 r-cran-glmmtmb/1.0.2.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Hi Maintainers
The upload of rmatrix/1.3-0-1
43 matches
Mail list logo
