Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Source: mvtnorm, r-cran-pammtools
Control: found -1 mvtnorm/1.2-2-1
Control: found -1 r-cran-pammtools/0.5.8-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of mvtnorm the autopkgtest of r-cran-pammtools
fails in testing when that autopkgtest is run with the binary packages
of mvtnorm from unstable. It passes when run with only packages from
testing. In tabular form:
passfail
mvtnormfrom testing1.2-2-1
r-cran-pammtools from testing0.5.8-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing
I note that with both versions from unstable the test also passes, which
hints at either a missing *versioned* test dependency in
r-cran-pammtools (if it *only* breaks the test), or missing versioned
Breaks in mvtnorm *and* a missing versioned Depends in r-cran-pammtools
if r-cran-pammtools is really broken with the wrong version of mvtnorm.
I copied some of the output at the bottom of this report.
Currently this regression is blocking both the migration of mvtnorm to
testing [1] and the migration of r-cran-pammtools to testing [2]. Due to
the nature of this issue, I filed this bug report against both packages.
Can you please investigate the situation and reassign the bug to the
right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
mvtnorm/1.2-2-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=mvtnorm
[2] https://qa.debian.org/excuses.php?package=r-cran-pammtools
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-pammtools/34886689/log.gz
46s BEGIN TEST testthat.R
46s 46s R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
46s Copyright (C) 2023 The R Foundation for Statistical Computing
46s Platform: x86_64-pc-linux-gnu (64-bit)
46s 46s R is free software and comes with ABSOLUTELY NO WARRANTY.
46s You are welcome to redistribute it under certain conditions.
46s Type 'license()' or 'licence()' for distribution details.
46s 46s R is a collaborative project with many contributors.
46s Type 'contributors()' for more information and
46s 'citation()' on how to cite R or R packages in publications.
46s 46s Type 'demo()' for some demos, 'help()' for on-line help, or
46s 'help.start()' for an HTML browser interface to help.
46s Type 'q()' to quit R.
46s 46s > Sys.setenv("R_TESTS" = "") # see
https://github.com/hadley/testthat/issues/86
46s > library(testthat)
46s > library(checkmate)
46s > library(dplyr)
47s 47s Attaching package: ‘dplyr’
47s 47s The following object is masked from ‘package:testthat’:
47s 47s matches
47s 47s The following objects are masked from ‘package:stats’:
47s 47s filter, lag
47s 47s The following objects are masked from ‘package:base’:
47s 47s intersect, setdiff, setequal, union
47s 47s > library(purrr)
47s 47s Attaching package: ‘purrr’
47s 47s The following object is masked from ‘package:testthat’:
47s 47s is_null
47s 47s > library(tidyr)
47s 47s Attaching package: ‘tidyr’
47s 47s The following object is masked from ‘package:testthat’:
47s 47s matches
47s 47s > # library(pammtools)
47s > 47s > test_check("pammtools")
47s Loading required package: pammtools
48s 48s Attaching package: ‘pammtools’
48s 48s The following object is masked from ‘package:stats’:
48s 48s filter
48s 59s [ FAIL 2 | WARN 8 | SKIP 0 | PASS 341 ]
59s 59s ══ Failed tests
59s ── Error ('test-cumulative-effect.R:29'): LL helpers and as_ped
produce equivalent LL windows ──
59s Error in `vectbl_assign(x[[j]], i, recycled_value[[j]])`: DLL
requires the use of native symbols
59s Backtrace:
59s ▆
59s 1. ├─pammtools::sim_pexp(...) at test-cumulative-effect.R:29:2
59s 2. │ ├─base::suppressMessages(ped <- ped %>%
left_join(reduce(df2, full_join)))
59s 3. │ │ └─base::withCallingHandlers(...)
59s 4. │ └─ped %>% left_join(reduce(df2, full_join))
59s 5. ├─dplyr::left_join(., reduce(df2, full_join))
59s 6. ├─pammtools:::left_join.ped(., reduce(df2, full_join))
59s 7. │ └─pammtools:::ped_classes(y)
59s 8. │ └─class(ped) %in% ...
59s 9. └─purrr::reduce(df2, full_join)
59s 10. └─purrr:::reduce_impl(.x, .f, ..., .init = .init, .dir = .dir)
59s 11. ├─dplyr (local) fn(out, elt, ...)
59s 12. └─dplyr:::full_join.data.frame(out, elt, ...)
59s 13. └─dplyr:::join_mutate(...)
59s 14. ├─base::`[<-`(`*tmp*`, new_rows
Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Hi Paul, I really appreciate the diligence and detail you put into this. But I would like to offer a simple shortcut. I am also CCing debian-r again as this has come up time and time again, is guaranteed to come up again for as long as combine autopkgtests with letting packages go stake. Point 0: Trust CRAN. CRAN *never* lets a package onto their repo in their (complete) reverse depends checks reveal anything. Ever. (Unless a coordinated update is made.) E.g. I just sent a patch to uwot (aka r-cran-uwot) because my RcppAnnoy package (aka r-cran-rcppannoy) updated upstream annoy, introduces a C++ namespace in the header and breaks downstream compilation. So I altered uwot accordingly (last week), waited a few days for the maintainer to update it (big-ish package, he had other pending changes), it got onto CRAN today so I likely send RcppAnnoy tomorrow. CRAN very strongly believes in 'everything works at @HEAD' so if everything is current, everything is generally installable at all times. This is unparalleled in open source. No other repo gives such guarantees. I have worked with them as both package maintainer (for Debian) and upstream for twenty years. The trust is earned. Point 1: So check CRAN for the newly updated package See https://cloud.r-project.org/web/packages/mvtnorm/index.html and esp the results aggregation https://cloud.r-project.org/web/checks/check_results_mvtnorm.html which is *pristine*. So the smoke starts to come from our corners. Point 2: So check CRAN for borked package See https://cloud.r-project.org/web/packages/pammtools/index.html and note how it was update in March and is at 0.5.91 Whereas we are at 0.5.8. So I think that is not a bug in mvtnorm aka r-cran-mvtnorm. You could of course ask me to add versioning info to r-cran-mvtnorm but as I strongly suspect that the issue goes away once pammtools aka r-cran-pammtools updates, I think that that would be the wrong way to go. Sorry for the long email but there **value** in CRAN. We would be foolish to ignore it. Cheers, Dirk On 26 June 2023 at 21:53, Paul Gevers wrote: | Source: mvtnorm, r-cran-pammtools | Control: found -1 mvtnorm/1.2-2-1 | Control: found -1 r-cran-pammtools/0.5.8-1 | Severity: serious | Tags: sid bookworm | User: debian...@lists.debian.org | Usertags: breaks needs-update | | Dear maintainer(s), | | With a recent upload of mvtnorm the autopkgtest of r-cran-pammtools | fails in testing when that autopkgtest is run with the binary packages | of mvtnorm from unstable. It passes when run with only packages from | testing. In tabular form: | | passfail | mvtnormfrom testing1.2-2-1 | r-cran-pammtools from testing0.5.8-1 | versioned deps [0] from testingfrom unstable | all others from testingfrom testing | | I note that with both versions from unstable the test also passes, which | hints at either a missing *versioned* test dependency in | r-cran-pammtools (if it *only* breaks the test), or missing versioned | Breaks in mvtnorm *and* a missing versioned Depends in r-cran-pammtools | if r-cran-pammtools is really broken with the wrong version of mvtnorm. | | I copied some of the output at the bottom of this report. | | Currently this regression is blocking both the migration of mvtnorm to | testing [1] and the migration of r-cran-pammtools to testing [2]. Due to | the nature of this issue, I filed this bug report against both packages. | Can you please investigate the situation and reassign the bug to the | right package? | | More information about this bug and the reason for filing it can be found on | https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation | | Paul | | [0] You can see what packages were added from the second line of the log | file quoted below. The migration software adds source package from | unstable to the list if they are needed to install packages from | mvtnorm/1.2-2-1. I.e. due to versioned dependencies or breaks/conflicts. | [1] https://qa.debian.org/excuses.php?package=mvtnorm | [2] https://qa.debian.org/excuses.php?package=r-cran-pammtools | | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-pammtools/34886689/log.gz | | 46s BEGIN TEST testthat.R | 46s 46s R version 4.3.1 (2023-06-16) -- "Beagle Scouts" | 46s Copyright (C) 2023 The R Foundation for Statistical Computing | 46s Platform: x86_64-pc-linux-gnu (64-bit) | 46s 46s R is free software and comes with ABSOLUTELY NO WARRANTY. | 46s You are welcome to redistribute it under certain conditions. | 46s Type 'license()' or 'licence()' for distribution details. | 46s 46s R is a collaborative project with many contributors. | 46s Type 'contributors()' for more information and | 46s 'citation()' on how to cite R or R packages in publications. | 46s 46s Type 'demo()' for some demos, 'help()' for
Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Hi Dirk, On 26-06-2023 22:21, Dirk Eddelbuettel wrote: I really appreciate the diligence and detail you put into this. But I would like to offer a simple shortcut. I am also CCing debian-r again as this has come up time and time again, is guaranteed to come up again for as long as combine autopkgtests with letting packages go stake. Somehow I feel you missed my point. In Debian we also care about preventing partial upgrades doing the wrong thing. I explicitly noted that in unstable everything is fine, so I think I acknowledge what you said. However, for the migration to automatically happen and to (possibly, I leave that for you (packages maintainers) to judge) prevent issues with partial upgrades there needs to be some *versioned* package relation somewhere. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Hi Paul, On 27 June 2023 at 20:08, Paul Gevers wrote: | Hi Dirk, | | On 26-06-2023 22:21, Dirk Eddelbuettel wrote: | > I really appreciate the diligence and detail you put into this. | > | > But I would like to offer a simple shortcut. I am also CCing debian-r again | > as this has come up time and time again, is guaranteed to come up again for | > as long as combine autopkgtests with letting packages go stake. | | Somehow I feel you missed my point. In Debian we also care about | preventing partial upgrades doing the wrong thing. I explicitly noted | that in unstable everything is fine, so I think I acknowledge what you | said. However, for the migration to automatically happen and to | (possibly, I leave that for you (packages maintainers) to judge) prevent | issues with partial upgrades there needs to be some *versioned* package | relation somewhere. I am not a fan of accomodating outdated packages in Debian by means of imposed constraints _which then differ from perfectly viable and sane upstream uses_ and am not here for it. Life is too short: just under 20k CRAN packages, (last I checked) just over 1k in Debian -- and once you allow for "random" package combination (which, I repeat, are untested upstream in these combinations) you essentially get yourself an infinity of possible combinations. There lies madness. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Hi Paul, just as a hint for you who might have missed periodic blaming of Dirk about outdated R packages. Am Tue, Jun 27, 2023 at 02:02:43PM -0500 schrieb Dirk Eddelbuettel: > Life is too short: Yes, so I keep on updating r-cran- packages after freeze and save my time to repeat myself. Kind regards Andreas. -- http://fam-tille.de
Bug#1039510: mvtnorm breaks r-cran-pammtools autopkgtest: missing Breaks and/or versioned (test) Depends?
Dirk, Andreas, On Wed, Jun 28, 2023 at 10:49:24AM +0200, Andreas Tille wrote: > Yes, so I keep on updating r-cran- packages after freeze and save my > time to repeat myself. I probably should not be the one to add fuel to the fire, but allow me to present some statistics. The debian R team team currently has 1151 packages, and at the time of writing this mail, there are only 2-3 volunteers who do the job of maintaining this chunk of work, which means each volunteer is maintaining at least ~384 packages just in the R team (and I'm speaking this in the context of team uploads, and not according to the name mentioned in uploaders field). Here's upload stats[2]. In addition to that, the said volunteers are also maintaining packages in other debian teams. For instance, my packages span across ~10-12 different teams, and same goes for Andreas. On top of that, there's also RFP requests from people and we have to constantly work on packaging new and relevant software for debian. @Dirk, you, on the other hand have most of the packages you maintain out of maintainer teams, and as far as I can see, you currently have 179 packages[3], and you mostly upload only those packages, so it is likely easier to bring them to cran latest at most times. I'm not trying to draw any comparison, but only stating facts. As you may see, the load that's on each volunteer is quite a lot, and it gets humanely impossible to keep all those number of packages into an updated state. We'd love to be at versions that CRAN (or bioconductor) is at currently, but there simply aren't enough cycles most of the times. I'd also like to point out that despite the constraints, during the past year, the number of stale packages were consistently less than '30' which is ~CRAN latest. Now is an anomally because freeze just ended, and there's a huge delta. [1]: https://qa.debian.org/developer.php?email=r-pkg-team%40alioth-lists.debian.net [2]: http://blends.debian.net/liststats/uploaders_r-pkg.png [3]: https://qa.debian.org/developer.php?login=edd&comaint=yes Best, Nilesh signature.asc Description: PGP signature
