Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
Just to follow-up here: As upstream for Rcpp, I just ran another reverse dependency check againt 1700+ packages on a machine I get to use for that, and had S4Vectors and IRanges issues pop up for three packages. It looks like an issue with S4Vectors. But still: Three. Out of 1700+. Holding the Rcpp upgrade hostage to this is sub-optimal, to put it mildly. It is a simple bug in another, orthogonal package. There happens to be a package using both. Yet Rcpp gets shot by shrapnel. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
On 24 December 2019 at 09:34, Graham Inggs wrote: | Control: severity -1 serious | | On Mon, 23 Dec 2019 at 22:30, Dirk Eddelbuettel wrote: | > I would be very surprised if these were not self-inflicted by us. I know CRAN | > (much) better than BioC, but both of them are doing extensive self-tests (and | > generally without any arbitrary restrictions, say about timing and versions) | > we may impose. | | This situation reminds me of #877288, where I believe Debian's | autopkgtests detected the problem before upstream. Maybe, maybe not. Here is the BioC build report for iranges and s4vectors: http://bioconductor.org/checkResults/3.10/bioc-LATEST/IRanges/ http://bioconductor.org/checkResults/3.10/bioc-LATEST/S4Vectors/ "All green". To me th likeliest cause is one of synchronization: BioC generally "steps" in full releases dependenting on R releases, that does not map to our rolling scheme. That is, to me, what happened in #877288 too -- R releases and BioC releases out of step. (And I still don't know what the best move would be as thinks could break with either BioC release or devel...) | > I tried a quick test on a Debian testing machine I use for (extensive) | > reverse dependency checks (at the upstream level) but it was incloncusive. | | Hopefully we get an answer from upstream BioConductor soon. Well as shown above there is not bug they see. | > Still a pity that r-base is held back by this. | | This is better than allowing a package that breaks others to migrate | into testing. What if the breakage is in fact self-inflicted? | If there is no progress for some time, Release Team may remove | r-bioc-iranges and r-bioc-s4vectors from testing to allow r-base to | migrate, as in any other transition. I guess we have to wait. I run R via the CRAN-ports-for-Ubuntu or via unstable-on-testing so I have R 3.6.2 on both but it is not fair to our users to withhold it. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
Control: severity -1 serious On Mon, 23 Dec 2019 at 22:30, Dirk Eddelbuettel wrote: > I would be very surprised if these were not self-inflicted by us. I know CRAN > (much) better than BioC, but both of them are doing extensive self-tests (and > generally without any arbitrary restrictions, say about timing and versions) > we may impose. This situation reminds me of #877288, where I believe Debian's autopkgtests detected the problem before upstream. > I tried a quick test on a Debian testing machine I use for (extensive) > reverse dependency checks (at the upstream level) but it was incloncusive. Hopefully we get an answer from upstream BioConductor soon. > Still a pity that r-base is held back by this. This is better than allowing a package that breaks others to migrate into testing. If there is no progress for some time, Release Team may remove r-bioc-iranges and r-bioc-s4vectors from testing to allow r-base to migrate, as in any other transition.
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
On 23 December 2019 at 12:43, Graham Inggs wrote: | On Sun, 22 Dec 2019 at 17:04, Graham Inggs wrote: | > On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel wrote: | > > On the other hand the ppc64 is one of 'blocking compilation' so it can't | > > really segfaults at tests. | > | > I don't know what that means, but both the r-bioc-iranges and | > r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed: | > | > An irrecoverable exception occurred. R is aborting now ... | > Segmentation fault (core dumped) | | Looking closer, the failing tests above were with | r-base/3.6.2-1build1, which was uploaded by an Ubuntu developer and | included the PPC fix. | | No autopkgtests were run with r-base/3.6.2-1 in Ubuntu because it | didn't build on all architectures. | | Autopkgtests continue to pass with r-base/3.6.2-2 on ppc64el, and the | only diff between it and 3.6.2-1build1 is in the changelog [1]. | Autopkgtests continue to fail with r-base/3.6.2-2 on amd64, arm64, | armhf and s390x. I would be very surprised if these were not self-inflicted by us. I know CRAN (much) better than BioC, but both of them are doing extensive self-tests (and generally without any arbitrary restrictions, say about timing and versions) we may impose. I tried a quick test on a Debian testing machine I use for (extensive) reverse dependency checks (at the upstream level) but it was incloncusive. Still a pity that r-base is held back by this. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}
On Sun, 22 Dec 2019 at 17:04, Graham Inggs wrote: > On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel wrote: > > On the other hand the ppc64 is one of 'blocking compilation' so it can't > > really segfaults at tests. > > I don't know what that means, but both the r-bioc-iranges and > r-bioc-s4vectors autopkgtests with r-base/3.6.2-1 on ppc64el showed: > > An irrecoverable exception occurred. R is aborting now ... > Segmentation fault (core dumped) Looking closer, the failing tests above were with r-base/3.6.2-1build1, which was uploaded by an Ubuntu developer and included the PPC fix. No autopkgtests were run with r-base/3.6.2-1 in Ubuntu because it didn't build on all architectures. Autopkgtests continue to pass with r-base/3.6.2-2 on ppc64el, and the only diff between it and 3.6.2-1build1 is in the changelog [1]. Autopkgtests continue to fail with r-base/3.6.2-2 on amd64, arm64, armhf and s390x. [1] http://launchpadlibrarian.net/456137318/r-base_3.6.2-1build1_3.6.2-2.diff.gz
