Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On 2023-12-11 16:57:34 +0100, Andreas Tille wrote: > Am Mon, Dec 11, 2023 at 01:36:38PM +0100 schrieb Sebastian Ramacher: > > > OK, but what is your suggestion? Reverting and have broken tests due to > > > the pandoc issue? > > > > pandoc is fixed in unstable. > > Really? Salsa CI[1] says: > >pandoc : Depends: pandoc-data (>= 3.0.1+ds) but 3.0.1-3 is to be installed > > I uploaded anyway and hope this will be cured somehow. This issue was fixed in 3.0.1+ds-3 which was uploaded today. Cheers -- Sebastian Ramacher
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Am Mon, Dec 11, 2023 at 01:36:38PM +0100 schrieb Sebastian Ramacher: > > OK, but what is your suggestion? Reverting and have broken tests due to > > the pandoc issue? > > pandoc is fixed in unstable. Really? Salsa CI[1] says: pandoc : Depends: pandoc-data (>= 3.0.1+ds) but 3.0.1-3 is to be installed I uploaded anyway and hope this will be cured somehow. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-cran-rmarkdown/-/jobs/5026534 -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On 2023-12-11 13:28:59 +0100, Andreas Tille wrote: > Hi Sebastian, > > Am Mon, Dec 11, 2023 at 11:29:24AM +0100 schrieb Sebastian Ramacher: > > > > I found a workaround; demote pandoc from a Depends to a Recommends in > > > > the r-cran-rmarkdown package. It seems that pandoc is not used for > > > > building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq > > > > and -tximeta, which I tried. > > > > > > Thanks for the patch - applied and uploaded. > > > > This change broke autopkgtests of reverse dependencies. > > OK, but what is your suggestion? Reverting and have broken tests due to > the pandoc issue? pandoc is fixed in unstable. Cheers -- Sebastian Ramacher
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Sebastian, Am Mon, Dec 11, 2023 at 11:29:24AM +0100 schrieb Sebastian Ramacher: > > > I found a workaround; demote pandoc from a Depends to a Recommends in > > > the r-cran-rmarkdown package. It seems that pandoc is not used for > > > building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq > > > and -tximeta, which I tried. > > > > Thanks for the patch - applied and uploaded. > > This change broke autopkgtests of reverse dependencies. OK, but what is your suggestion? Reverting and have broken tests due to the pandoc issue? Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Andreas On 2023-12-07 16:09:28 +0100, Andreas Tille wrote: > Hi Graham, > > Am Thu, Dec 07, 2023 at 01:37:02PM -0100 schrieb Graham Inggs: > > On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote: > > > I have no idea how to work around this. > > > > I found a workaround; demote pandoc from a Depends to a Recommends in > > the r-cran-rmarkdown package. It seems that pandoc is not used for > > building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq > > and -tximeta, which I tried. > > Thanks for the patch - applied and uploaded. This change broke autopkgtests of reverse dependencies. Cheers -- Sebastian Ramacher
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On 9 December 2023 at 01:06, Charles Plessy wrote:
| I do not know for r-bioc-netsam, but for r-bioc-org.hs.eg.db and similar
| packages, it is because it is an "annotation package" made of data and
| therefore not managed the same way as the other Bioconductor packages.
|
| This is why it DESCRIPTION file does not mention its Bioconductor Git
| branch. This is also why its version number matches the Bioconductor
| release number. Also, its homepage resolves to
|
https://bioconductor.org/packages/release/data/annotation/html/org.Hs.eg.db.html
| while for regular packages there is no data/annotation/html in the URL.
|
| I think that it does not have to depend on the bioc api pseudo-package.
When r2u builds all of CRAN plus the ~ 200 BioC that are implied plus ~ 200
more that either in Debian or high on BioC's own 'karma' list, I query all
four repositories as one must. That is basically what the BioC installer
helpers always did for twenty-some years. My code (quicker for me to find)
is
## cf contrib.url(BiocManager::repositories())
## [1] "https://bioconductor.org/packages/3.14/bioc/src/contrib;
## [2]
"https://bioconductor.org/packages/3.14/data/annotation/src/contrib;
## [3]
"https://bioconductor.org/packages/3.14/data/experiment/src/contrib;
biocrepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/bioc")
apBIOC <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocrepo)))
biocdataannrepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/data/annotation")
apBIOCdataann <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocdataannrepo)))
apBIOC <- merge(apBIOC, apBIOCdataann, all=TRUE)
biocdataexprepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/data/experiment")
apBIOCdataexp <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocdataexprepo)))
apBIOC <- merge(apBIOC, apBIOCdataexp, all=TRUE)
Ah, and younger Dirk left a message for current Dirk that this does indeed
show it too:
> contrib.url(BiocManager::repositories())
'getOption("repos")' replaces Bioconductor standard repositories, see
'help("repositories", package = "BiocManager")' for details.
Replacement repositories:
CRAN: https://cloud.r-project.org
[1] "https://bioconductor.org/packages/3.18/bioc/src/contrib;
[2] "https://bioconductor.org/packages/3.18/data/annotation/src/contrib;
[3] "https://bioconductor.org/packages/3.18/data/experiment/src/contrib;
[4] "https://bioconductor.org/packages/3.18/workflows/src/contrib;
[5] "https://bioconductor.org/packages/3.18/books/src/contrib;
[6] "https://cloud.r-project.org/src/contrib;
>
And when I bulk-updated the BioC packages for my 20.04 and 22.04 build in
r2u, I did notice that some of the 'non-R-package packages' in annotations
and experiment did not update. One could always ask BioC which of these are
/ are not considered release dependent. Their slack is open and pretty
friendly, I hang there too.
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Graham and Andreas, Le Thu, Dec 07, 2023 at 01:37:02PM -0100, Graham Inggs a écrit : > > Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on > the tracker? I do not know for r-bioc-netsam, but for r-bioc-org.hs.eg.db and similar packages, it is because it is an "annotation package" made of data and therefore not managed the same way as the other Bioconductor packages. This is why it DESCRIPTION file does not mention its Bioconductor Git branch. This is also why its version number matches the Bioconductor release number. Also, its homepage resolves to https://bioconductor.org/packages/release/data/annotation/html/org.Hs.eg.db.html while for regular packages there is no data/annotation/html in the URL. I think that it does not have to depend on the bioc api pseudo-package. I hope it helps, Charles
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On Thu, Dec 07, 2023 at 04:09:28PM +0100, Andreas Tille wrote: >... > Am Thu, Dec 07, 2023 at 01:37:02PM -0100 schrieb Graham Inggs: >... > > Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on > > the tracker? > > I was always wondering about this but I have no clue. r-bioc-go.db is > the third example in this row. I was updating these in past transitions > manually which is IMHO no big harm - but I simply don't understand. Finding the root cause would be investigating the question why no dependency on r-api-bioc-* is generated for them. Either that's not required and the packages are technically not part of the transition, or there is an (RC) bug that should be fixed. > Kind regards > Andreas. >... cu Adrian
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Am Thu, Dec 07, 2023 at 04:09:28PM +0100 schrieb Andreas Tille: > I'll take this > occurence as a reason to fail with an error in dh-r to avoid such cases > in future. Done in https://salsa.debian.org/r-pkg-team/dh-r/-/commit/e4c348832b3d99ba7bc8f7670085b9b21323f7b6 The check could be even more strict but should be sufficient for those practical cases that occured in the past. Thanks for Graham for spotting the issue Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Graham, Am Thu, Dec 07, 2023 at 01:37:02PM -0100 schrieb Graham Inggs: > On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote: > > I have no idea how to work around this. > > I found a workaround; demote pandoc from a Depends to a Recommends in > the r-cran-rmarkdown package. It seems that pandoc is not used for > building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq > and -tximeta, which I tried. Thanks for the patch - applied and uploaded. > Do you know why r-bioc-metagenomeseq is considered neither good nor > bad in the tracker? Argh, upstream has messed up DESCRIPTION/git_branch which we trust to detect r-bioc-api. This is fixed[1] and uploaded. I'll take this occurence as a reason to fail with an error in dh-r to avoid such cases in future. > Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on > the tracker? I was always wondering about this but I have no clue. r-bioc-go.db is the third example in this row. I was updating these in past transitions manually which is IMHO no big harm - but I simply don't understand. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/r-bioc-metagenomeseq/-/blob/master/debian/patches/fix_git_branch.patch -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Andreas
On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote:
> I have no idea how to work around this.
I found a workaround; demote pandoc from a Depends to a Recommends in
the r-cran-rmarkdown package. It seems that pandoc is not used for
building, at least for r-bioc-biovizbase, -degnorm, -ioniser, scrnaseq
and -tximeta, which I tried.
Do you know why r-bioc-metagenomeseq is considered neither good nor
bad in the tracker?
Also, why do r-bioc-netsam and r-bioc-org.hs.eg.db not even appear on
the tracker?
Regards
Graham
--- r-cran-rmarkdown-2.25+dfsg/debian/control
+++ r-cran-rmarkdown-2.25+dfsg/debian/control
@@ -37,10 +37,9 @@
libjs-prettify,
r-cran-jquerylib,
fonts-font-awesome,
- pandoc,
r-cran-shiny,
node-html5shiv
-Recommends: ${R:Recommends}
+Recommends: ${R:Recommends}, pandoc
Suggests: ${R:Suggests}
Description: convert R markdown documents into a variety of formats
R Markdown is a framework for creating documents that mix R code with
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On 2023-12-03 23:14:03 +0200, Adrian Bunk wrote: > On Sun, Dec 03, 2023 at 09:46:31AM -0100, Graham Inggs wrote: > >... > > This is probably a good example for why new packages should be > > uploaded to experimental first, instead of directly to unstable. > >... > > Not really. > > It is rare that a new source package takes over a binary package from > another binary package, and in this case the same might have happened > during an upgrade of the pandoc packages not involving NEW at all. It really is the best example why you perform such reorganizations in experimental first and then upload in one go to unstable. pandoc is now impacting at least two transitions. Cheers -- Sebastian Ramacher
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Adrian, Am Sun, Dec 03, 2023 at 11:15:49PM +0200 schrieb Adrian Bunk: > > And it also means that r-bioc-biocgenerics is now blocked on the haskell > > transition. Lovely. Good thing that pandoc is supposed to be the last piece > > in that several months long transition. > > It's only blocked by the pandoc part of the Haskell transition, > it shouldn't be blocked by the other remaining parts of the > transition or by getting the transition into testing. Is there any chance to upload a working pandoc to unstable? Nearly all r-* package tests I tried in upgrades are broken and I'd like to know when it makes sense again to touch those packages. Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi, Am Sun, Dec 03, 2023 at 09:51:38PM +0100 schrieb Paul Gevers: > > And it also means that r-bioc-biocgenerics is now blocked on the haskell > transition. Lovely. Good thing that pandoc is supposed to be the last piece > in that several months long transition. ... which on the other hand shows, that new packages have never been the main blocker in r-bioc-* transitions (even if I confirm I'm happy that you convinced us to get rid of this reason). Kind regards Andreas. -- http://fam-tille.de
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On Sun, Dec 03, 2023 at 09:51:38PM +0100, Paul Gevers wrote: >... > And it also means that r-bioc-biocgenerics is now blocked on the haskell > transition. Lovely. Good thing that pandoc is supposed to be the last piece > in that several months long transition. It's only blocked by the pandoc part of the Haskell transition, it shouldn't be blocked by the other remaining parts of the transition or by getting the transition into testing. > Paul cu Adrian
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On Sun, Dec 03, 2023 at 09:46:31AM -0100, Graham Inggs wrote: >... > This is probably a good example for why new packages should be > uploaded to experimental first, instead of directly to unstable. >... Not really. It is rare that a new source package takes over a binary package from another binary package, and in this case the same might have happened during an upgrade of the pandoc packages not involving NEW at all. > Regards > Graham >... cu Adrian
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi, On 03-12-2023 11:46, Graham Inggs wrote: This seems to be due to the restructuring of src:pandoc [1]. src:haskell-pandoc [2] recently cleared NEW into unstable, and the updated src:pandoc has not been uploaded yet. This is probably a good example for why new packages should be uploaded to experimental first, instead of directly to unstable. And it also means that r-bioc-biocgenerics is now blocked on the haskell transition. Lovely. Good thing that pandoc is supposed to be the last piece in that several months long transition. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi Andreas On Sun, 3 Dec 2023 at 07:21, Andreas Tille wrote: > Charles Plessy and I uploaded r-bioc-* packages until level 11. > Unfortunately building of some packages seems to be blocked for > > A: some pandoc dependency reason > pandoc depends on missing: > - pandoc-data:amd64 (< 2.17.1.1-3.~) This seems to be due to the restructuring of src:pandoc [1]. src:haskell-pandoc [2] recently cleared NEW into unstable, and the updated src:pandoc has not been uploaded yet. This is probably a good example for why new packages should be uploaded to experimental first, instead of directly to unstable. > https://buildd.debian.org/status/package.php?p=r-bioc-biovizbase > > B: for non-obvious reasons These seem to be the same as A above. Regards Graham [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053686 [2] https://tracker.debian.org/pkg/haskell-pandoc
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
Hi, Charles Plessy and I uploaded r-bioc-* packages until level 11. Unfortunately building of some packages seems to be blocked for A: some pandoc dependency reason pandoc depends on missing: - pandoc-data:amd64 (< 2.17.1.1-3.~) https://buildd.debian.org/status/package.php?p=r-bioc-biovizbase B: for non-obvious reasons https://buildd.debian.org/status/package.php?p=r-bioc-ioniser https://buildd.debian.org/status/package.php?p=r-bioc-scrnaseq https://buildd.debian.org/status/package.php?p=r-bioc-tximeta I have no idea how to work around this. Kind regards Andreas. -- http://fam-tille.de
