Dear Release Team,

Shortly after the release of R 4.6, planned for next week, Bioconductor
will publish new upstream versions for all of its packages. This
collective release will form Bioconductor 3.23.

There is tight coupling between R and Bioconductor packages, and as you
can see from the RC bugs opened yesterday by Santiago, a number of them
will need to be rebuilt. This will be addressed by the update to the new
upstream versions, since each upstream package is receiving an update,
even if only to its changelog.

As with the previous transition, the dependency graph will likely grow
with new packages. The NEW queue is almost empty at the moment, so
processing should be fast.

I am writing now to ask you to set up a transition tracker. All uploads
will be targeted to Experimental, and we will contact you again when
mass uploads to Unstable are ready, so we can proceed once you confirm
that the transition may begin.

On the technical side: r-bioc-generics provides the r-api-bioc-3.??
virtual package, and the tools used to build the other r-bioc-* packages
pick up that virtual package at build time. There are currently no
packages depending on r-api-bioc-3.21, and only one package depending on
r-api-bioc-3.22, since we skipped the corresponding Bioconductor
releases due to lack of manpower.

Have a nice weekend,

Charles

Ben file:

title = "r-api-bioc-3.23";
is_affected = .depends ~ /r-api-bioc/ | .source ~ /r-bioc-/;
is_good = .depends ~ "r-api-bioc-3.23";
is_bad = .depends ~ "r-api-bioc-3.20 | r-api-bioc-3.22";

Hi Charles

I don't think it is necessary to stage the entire transition in
Experimental, only the NEW source packages, but perhaps I
misunderstand.

I have set up a transition tracker [1], which should mark 3.20, 3.21
and 3.22 as bad, and 3.23 as good.  Please let me know if it is not as
expected.

Please remove the 'moreinfo' tag from this bug when you are ready.

Regards
Graham


[1] https://release.debian.org/transitions/html/r-api-bioc-3.23.html

Hi Graham,

I think that on the R packages maintainers team side, we are ready for the
Bioconductor transition.  Can we go ahead?

Have a nice day,

Charles

Hi Charles

Please do!

Regards
Graham

Hi Charles

I noticed that the autopkgtests of r-bioc-biocgenerics [1] are still
using the deprecated [2] 'skip-not-installable'
restriction.

Would you please drop that as part of your mass uploads?

Regards
Graham


[1] https://ci.debian.net/packages/r/r-bioc-biocgenerics/testing/amd64/
[2] https://udd.debian.org/lintian-tag/testsuite-restrictions-has-deprecated-skip-not-installable

Le Sat, Jul 11, 2026 at 11:33:56AM +0000, Graham Inggs a écrit :

Hi Graham,

thanks for the notice,

I am now dropping it in all Bioconductor packages through routine-update.

https://salsa.debian.org/debian/routine-update/-/commit/1e5e7dd601dd78c61609e7a6f8c6546e00528a68

Have a nice day,

Hi Graham,

most of the Bioconductor transition went smoothly, but unfortunately it clashed
with the HDF5 transition.

When Bioconductor was released, it contained core packages shipping a vendored
version 1.14 of HDF5, which was very close to the one in Testing.  Unvendoring
was very easy.  After the Bioconductor transition started, the HDF5 transition
took place and now we have version 2.1 in testing, and I simply do not have the
skill to unvendor HDF5 in Bioconductor and do the major upgrade instead of
upstream themselves.  I am CCing debian-r@ and debian-med@lists.debian.org to
see if somebody else wants to pick the ball, but I am pessimistic about this.

The next Bioconductor release might solve the problem, or might not.  The
next-next release will be in April.

I think that our possibilities are:

 0 Someone unvendors HDF5 in Bioconductor and ports the dependencies to be
   compatible with the major upgrade to1 version 2.1.  I tried with Claude 4.8 in
   OpenCode and failed after spending 20$ of OpenRouter tokens, but my AI skills
   are still beginner level…

 1 Ship the r-bioc-* packages with their vendored HDF5 library and trust that
   they will handle major security issues well.  The Bioconductor project has good
   programmers, more than a decade of acheivements, and a full commitment to
   security.  Also, they might migrate before the Freeze.

 2 Leave the r-bioc-* packages depending on r-bioc-rhdf5lib in Sid, migrate the
   rest and call the transition done.  The next one is next month.  Revisit the
   issue before the Freeze.

 3 Remove r-bioc-rhdf5lib and its dependencies from Debian until we can
   unvendor HDF5.  The NEW queue is very efficient those days.

 4 Give up and remove all r-bioc-* packages from Debian.  There are excellent
   third-party repositories shipping them.  In that case we may need to move some
   non-R dependencies to contrib, or remove them too.

My favorite is option 1.

What shall we do?

Hi,

Am Thu, Sep 03, 2026 at 09:11:17AM +0900 schrieb Charles Plessy:

:-(

Really in April?  In item 2 you write "next month" and as far as I understood
there are two releases per year.

This sounds complex and trusting AI only seems to be a bad idea.

I like this pragmatic approach.  I'd prefer to talk to Bioconductor
developers what they might think and what schedule they intend to
follow.

Might be an option I would rank below the former option.  It has the
problem that we might loose time before the Freeze which we could use
now (by talking to Bioconductor developers).

$ apt rdepends r-bioc-rhdf5lib
r-bioc-rhdf5lib
Reverse Depends:
  Depends: r-bioc-rhdf5 (>= 1.33.3)
  Depends: r-bioc-alabaster.base
  Depends: r-bioc-rhdf5filters
  Depends: r-bioc-alabaster.base
  Depends: r-bioc-hdf5array
  Depends: r-bioc-dropletutils

I do not see a big problem in not shipping these for some time.  On the
other hand since some time r-bioc-rhdf5lib has a popcon > 200 which is
above a lot of other Debian Med packages.

I'm not convinced that this is in the interest of our users.

Same here.

Kind regards
    Andreas.

Hi Charles

...

The release team is fine with option 1.  Please see the packaging
notes about embedded code copies [1], and please register the affected
packages with the security team.  Previously, you could add them
yourself in the wiki, but now you can do it in salsa [2].

Regards
Graham


[1] https://wiki.debian.org/Packaging/EmbeddedCopies
[2] https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies

Hi Graham,

Le Thu, Sep 03, 2026 at 02:56:24PM +0000, Graham Inggs a écrit :

Many thanks to you and the release team for letting us doing this!

I will work on it next week.

Charles

Le Fri, Sep 04, 2026 at 08:45:12AM +0900, Charles Plessy a écrit :

Hi Graham,

thanks again for the guidance and the green light.

I have uploaded the packages and declared it:

https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/d74ae7f4d648f5ce6fac323e3c60d735b0093962

Have a nice day,

Charles