Bug#1067842: transition: octave-9
Hi Sébastien octave-fits FTBFS on all architectures (#1070956), and octave-stk FTBFS on 32-bit architectures (#1069477), would you please take a look? Regards Graham
Bug#1067842: transition: octave-9
Hi Sébastien On Sat, 11 May 2024 at 08:48, Sébastien Villemot wrote: > Thanks. Uploaded and built on all release architectures. binNMUs underway! Regards Graham
Re: Please add a testing suite for riscv64 architecture
Hi Ansgar On Fri, 10 May 2024 at 15:23, Ansgar wrote: > I'm happy to do that, but someone from the release team should ack the > request. testing and related suites are their playground after all :-) Please go ahead! Regards Graham
Bug#1067842: transition: octave-9
Control: tags -1 + confirmed Hi Sébastien On Thu, 9 May 2024 at 08:09, Sebastian Ramacher wrote: > plplot is involved in the gnat and octave transitions. So let's do this > one after gnat is done. gnat 13 has migrated, please go ahead. Regards Graham
Bug#1065309: transition: gnat (12 -> 13 + time_t64)
Hi Nicolas and Rafael It looks like the last blocker for this transition is plplot 5.15.0+dfsg2-10 failing its own autopkgtests [1]. Regards Graham [1] https://ci.debian.net/packages/p/plplot/
Bug#1065309: transition: gnat (12 -> 13 + time_t64)
Hi Nicholas On Sat, 4 May 2024 at 12:21, Nicolas Boulenguez wrote: > For some reason, some rebuilds succeeded without a +b1 version. I think if the original uploads FTBFS then they would not have gained a +b1 version. > Their reverse dependencies is dep-waiting on the +b1 version. > Please cancel three dep-wait restrictions. > > gb libgnatcoll-db_23.0.0-6 . armel powerpc . -o > gb libgnatcoll-bindings_24.0.0-2 . armhf . -o I binNMU'd libgnatcoll again on armhf, and libgnatcoll-bindings again on armel, armhf, hppa and powerpc, this should get the +b1 versions aligned and get libgnatcoll-db built. Regards Graham
Re: please clear extra-depends for armnn
On Sat, 4 May 2024 at 14:41, Andreas Beckmann wrote: > src:armnn is stuck on i386,mips64el,ppc64el: > https://buildd.debian.org/status/package.php?p=armnn > > There is an unsatisfiable >Extra-Depends: libarm-compute-dev (>= 23.08+dfsg-3.1) > while the package has restricted that B-D to the three architectures > where the package exists: amd64, armhf, arm64 > Please clear the wrong Extra-Depends. armnn given back without the Extra-Depends on libarm-compute-dev, thanks.
Bug#1065309: transition: gnat (12 -> 13 + time_t64)
Hi Nicholas I think the builds are on track, except for: libtemplates-parser FTBFS on arch:all [1] gprbuild FTBFS on arch:any [2] libgnatcoll, libgnatcoll-bindings and libgnatcoll-db are blocked by the builds of gprbuild Regards Graham [1] https://buildd.debian.org/status/package.php?p=libtemplates-parser=sid [2] https://buildd.debian.org/status/package.php?p=gprbuild=sid
Bug#1065309: transition: gnat (12 -> 13 + time_t64)
Hi Nicholas On Tue, 30 Apr 2024 at 12:33, Nicolas Boulenguez wrote: > The time_t64 transition has triggered #1067453 in the Ada compiler, > which is now fixed by gcc-13/13.2.0-24. > > The patch modifies the sources of the Ada standard library, so most > Ada packages need a rebuild in order to update their dependencies > (gnat-13 Provides: gnat-13-HASH > each Ada library Provides: libFOO-dev-HASH > and each consumer Depends: gnat-13-HASH, libFOO-HASH). > > Please schedule the following rebuilds. > > nmu adacgi_1.6-34 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067070.' > dw adacgi_1.6-34 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu adasockets_1.14-1 . ANY . -m 'Rebuild with #1067453 fixed in > gnat.' > dw adasockets_1.14-1 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu ahven_2.8.9 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067224, #1069469.' > dw ahven_2.8.9 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu libaunit_24.0.0-2 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067071.' > dw libaunit_24.0.0-2 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu libgmpada_1.6-2 . ANY . -m 'Rebuild with #1067453 fixed in > gnat.' > dw libgmpada_1.6-2 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu libncursesada_6.3.20211021-11 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067073.' > dw libncursesada_6.3.20211021-11 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu libtexttools_2.1.0-28 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1069476.' > dw libtexttools_2.1.0-28 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu libxmlada_24.0.0-2. ANY . -m 'Rebuild with #1067453 fixed in > gnat' > dw libxmlada_24.0.0-2. ANY . -m 'gnat-13 (>= 13.2.0-24)' > nmu libxmlezout_1.06.2-14 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067220.' > dw libxmlezout_1.06.2-14 . ANY . -m 'gnat-13 (>= 13.2.0-24)' > > nmu liblog4ada_1.3.1.b6dafb49-13 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067074.' > dw liblog4ada_1.3.1.b6dafb49-13 . ANY . -m 'libxmezout-dev (>= > 1.06.2-14+b1)' > > nmu anet_0.5.0-3 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1067353.' > dw anet_0.5.0-3 . ANY . -m 'libahven-dev (>= 2.8.9+b1)' > nmu dbusada_0.6.2-6 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1069421.' > dw dbusada_0.6-2-6 . ANY . -m 'libahven-dev (>= 2.8.9+b1)' > nmu libalog_0.6.2-5 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1069454.' > dw libalog_0.6.2-5 . ANY . -m 'libahven-dev (>= 2.8.9+b1)' > nmu pcscada_0.7.7-6 . ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1069468.' > dw pcscada_0.7.7-6 . ANY . -m 'libahven-dev (>= 2.8.9+b1)' > > nmu libtemplates-parser_24.0.0-2 . ANY . -m 'Rebuild with #1067453 fixed in > gnat.' > dw libtemplates-parser_24.0.0-2 . ANY . -m 'libxmlada-unicode-dev (>= > 24.0.0-2+b1)' > nmu gprbuild_2024.1.20231009-4. ANY . -m 'Rebuild with #1067453 fixed in > gnat. Closes: #1069467.' > dw gprbuild_2024.1.20231009-4. ANY . -m 'libxmlada-unicode-dev (>= > 24.0.0-2+b1)' > > nmu libgnatcoll_24.1.20230921-4 . ANY . -m 'Rebuild with #1067453 fixed in > gnat.' > dw libgnatcoll_24.1.20230921-4 . ANY . -m 'libgnatprj-dev (>= > 2024.1.20231009-4+b1)' > > nmu libgnatcoll-bindings_24.0.0-2 . ANY . -m 'Rebuild with #1067453 fixed in > gnat.' > dw libgnatcoll-bindings_24.0.0-2 . ANY . -m 'libgnatcoll-dev (>= > 24.1.20230921-4+b1)' > > nmu libgnatcoll-db_23.0.0-6 . ANY . -m 'Rebuild with #1067453 fixed in > gnat.' > dw libgnatcoll-db_23.0.0-6 . ANY . -m 'libgnatcoll-iconv-dev (>= > 24.0.0-2+b1)' Scheduled, thanks, with a couple of fixed typos in versions; ahven_2.8.9 -> 2.8-9 and dbusada_0.6-2-6 -< 0.6.2-6. I'll check on the buildst later to see if any additional binNMUs are required to get the +b versions aligned. Regards Graham
Re: R 4.4.0 coming April 24
Hi Dirk On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote: > Right now it now only shows 'all reports (re-)running'. That was because of the new upload, but I see the results there now. The packages with failing autopkgtests are: r-bioc-iranges/2.36.0-1 r-bioc-mutationalpatterns/3.12.0+dfsg-1 r-bioc-s4vectors/0.40.2+dfsg-1 r-cran-data.table/1.14.10+dfsg-1 r-cran-ff/4.0.12+ds-1 > But package r-base > has had the usual issues in unstable for a few weeks now because 'some > people' insist on adding autopkg tests including for architectures / build > sizes no longer supported upstream -- R stopped 32 bit support over a year > and release ago For the pseudo-excuses in experimental only amd64 and arm64 are tested, no 32-bit architectures. > -- as well continually letting dependencies slip so that the > autopkg tests involve old and outdated package releases combined with the > fact that BioConductor has _very_ specific release cycles yet they throw > r-bioc-* package in too) so there is little I can do on the end of package > r-base. Briefly, I am being put into a bad corner by other maintainers here, > and I no longer have the energy to discuss that with them. We have been at > this for years. I think "discuss" was probably not the best word for Paul to suggest here. You only need to inform the maintainers of the affected packages, and that can be done by filing RC bugs against the affected versions. If the packages don't get updated, auto-removal will take care of them. The sooner this is done, the better. Regards Graham
Bug#1065309: transition: gnat (12 -> 13 + time_t64)
Control: tags -1 confirmed Hi Matthias, Nicolas On Sat, 2 Mar 2024 at 12:39, Matthias Klose wrote: > when preparing GCC packages for time_t64, I noticed that we'll have an > ABI change for libgnat as well. Instead of doing a gnat 12 -> 12+t64 > transition, let's do a gnat 12 -> 13+t64 transition instead. According > to Nicolas, packages are already prepared in experimental. On Wed, 13 Mar 2024 at 19:51, wrote: > I agree with Matthias that we should instead start the gcc-13 transition > in unstable. All packages are ready in experimental, with all library > packages already renamed through NEW. But unfortunately also with > intrusive unrelated changes, for example new upstream versions and a new > Ada workflow removing the version from -dev package names. It makes sense to do it in one go, please go ahead. Regards Graham
Bug#1065309: transition: gnat 12 -> 13 + time_t64
Hi Nicolas, Matthias On Sun, 3 Mar 2024 at 16:18, Nicolas Boulenguez wrote: > Ben file: > > title = "gnat-13"; > is_affected = .depends ~ > "libgnat-8/libgnat-9/libgnat-10/libgnat-11/libgnat-12" | .depends ~ > "libgnat-13"; > is_good = .depends ~ "libgnat-13"; > is_bad = .depends ~ "libgnat-8/libgnat-9/libgnat-10/libgnat-11/libgnat-12"; ben did not like the syntax, but I think I understood your intention and set up a tracker [1]. After seeing the output, I tried to simplify it, and assumed that gcc need not be included. I set up a second version of the tracker [2]. Please let me know if these need further refinement. If not, let me know which tracker you prefer to keep. Regards Graham [1] https://release.debian.org/transitions/html/gnat-13.html [2] https://release.debian.org/transitions/html/gnat-13-v2.html
Bug#1061188: transition: python3-defaults (making python3.12 the default python3 version)
Hi Matthias On Sat, 20 Jan 2024 at 16:45, Matthias Klose wrote: > Please setup a tracker for the python3-defaults transition, making 3.12 > the default Python version. I've set up a tracker [1]. It is based on the tracker used for python3.11 with the exclusion of source packages python3-defaults (which confused ben in dependency levels 1 and 2) and python3.11. Regards Graham [1] https://release.debian.org/transitions/html/python3.12-default.html
Re: [Pkg-pascal-devel] Issue with fpc_3.2.2+dfsg-24 in Sid.
Hi Abou On Sat, 30 Dec 2023 at 10:17, Abou Al Montacir wrote: > I've uploaded a broken version fpc_3.2.2+dfsg-24 unfortunately. > This prevents building arch independent packages due to a silly mistake. > This issue does not appear when you build both binaries and arch independent > packages thus I did not see it before upload. > > Now, the issue is fixed in fpc_3.2.2+dfsg-25, which managed to build on slow > building architectures, but all major architectures are now broken. > > I see only two possibilities, either upload manually fpc_3.2.2+dfsg-25 for > each missing architecture, or get fpc_3.2.2+dfsg-24 removed from archive and > replaced by fpc_3.2.2+dfsg-23 so that fpc_3.2.2+dfsg-25 can be built. > > Can anyone advise on how to proceed? The last time something similar happened, it was possible to upload and build fpc in testing [1]. I suggest to upload fpc_3.2.2+dfsg-26 targeting trixie. It will require some manual intervention by someone in the release team to copy and build the packages, but I think it will end up being quicker than re-bootstrapping fpc on all architectures. Regards Graham [1] https://tracker.debian.org/news/1218430/accepted-fpc-320dfsg-11-source-into-testing-proposed-updates/
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Andreas There are some packages that have still not migrated since the previous r-api-bioc-3.17 transition in July 2023. Links to their tracker pages, which should tell you what is needed, follow: https://tracker.debian.org/pkg/r-bioc-cner https://tracker.debian.org/pkg/r-bioc-dada2 https://tracker.debian.org/pkg/r-bioc-edaseq https://tracker.debian.org/pkg/r-bioc-ioniser https://tracker.debian.org/pkg/r-bioc-megadepth https://tracker.debian.org/pkg/r-bioc-scater https://tracker.debian.org/pkg/r-bioc-shortread https://tracker.debian.org/pkg/r-bioc-tcgabiolinks https://tracker.debian.org/pkg/r-bioc-tfbstools As a bonus, here's another, not related to the transition, but from a similar time: https://tracker.debian.org/pkg/r-cran-dials Regards Graham
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Andreas On Wed, 13 Dec 2023 at 09:45, Andreas Tille wrote: > as you might have noticed the upstream source for r-bioc-dss and > r-bioc-demixt are missing and upstream did not answered two mails about > this. Since the transition looks clean for me so far[1] after I fixed > two autopkgtest issues yesterday I (naively) think we could remove > r-bioc-dss and r-bioc-demixt from testing and all other packages can > migrate to finish the transition from r-bioc perspective. I've added removal hints for r-bioc-dss and r-bioc-demixt. Please file an RC bug for r-bioc-dss to prevent it from migrating straight back (r-bioc-demixt already has #1058278). One problem I see at [1]: Not built on buildd: arch all binaries uploaded by tille, a new source-only upload is needed to allow migration Remember, all r-bioc-* packages need to migrate together, so all of your uploads need to be ready before r-bioc-biocgenerics can migrate. I checked only the first few "Migrates after" links from [1], and found at least these packages still show autopkgtest regressions [2][3][4][5][6]. Regards Graham > [1] https://tracker.debian.org/pkg/r-bioc-biocgenerics [2] https://tracker.debian.org/pkg/r-bioc-beachmat [3] https://tracker.debian.org/pkg/r-bioc-biobase [4] https://tracker.debian.org/pkg/r-bioc-biocbaseutils [5] https://tracker.debian.org/pkg/r-bioc-biocio [6] https://tracker.debian.org/pkg/r-bioc-biostrings
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#1055085: waiting for 3.12.1
Control: tags -1 + confirmed On Thu, 30 Nov 2023 at 10:03, Matthias Klose wrote: > > wait until 3.12.1 is in the archive. 3.12.0+ isn't well handled as a > version by some third party libraries. binNMUs are now in progress with python3.12 3.12.0-7 in unstable. python3.12 (3.12.0-7) unstable; urgency=medium * Update to the 3.12 branch 2023-12-02. * Identify as version "3.12.0" instead of "3.12.0+", confusing some third party packages. * Remove references to the avr architecture. Closes: #1056761. * Fix more shebangs. Closes: #1057192. -- Matthias Klose Sat, 02 Dec 2023 13:35:02 +0100
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 issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2)
Control: tags -1 + confirmed Hi Andreas On Tue, 28 Nov 2023 at 13:50, Andreas Tille wrote: > Looks good. So if I understood correctly we are now rather waiting for > some infrastructure issues to start the transition and we should simply > sit-n-wait for the green light, right? Please go ahead. Thank you for your patience. Regards Graham
Bug#1054657: Transition issue for r-cran-rstanarm (Was: Bug#1055922: rmatrix: ABI change in Matrix 1.6-2)
Hi All I'm catching up after some AFK time, so I will just fill in some details where I can. On Tue, 28 Nov 2023 at 08:31, Paul Gevers wrote: > > I have no idea why r-cran-seurat is not profiting from reduced waiting > > time for the transition. > > Because its tests fail on armel. The reduction of waiting time is only > for tests that run successfully on all architectures where they are > triggered (as in, where at least some of the binaries build by the > source are installable). As the failure isn't a regression, the > migration isn't blocked, though. I noticed this today, and added an age hint for r-cran-seurat so it should migrate soon. On Mon, 27 Nov 2023 at 23:22, Charles Plessy wrote: > would it be possible to have an estimation about when we can expect to > start the Bioconductor transition ? We recently announced that britney now considers mips64el to be an out-of-sync architecture [1]. We are finding other systems; e.g. UDD and BTS, also need changes to accommodate this. We hope to have this resolved and for you to be able to start your transition within the next few days. We don't want to start a big transition and have it blocked on missing builds or installability issues on mips64el. On Sun, 26 Nov 2023 at 15:20, Andreas Tille wrote: > > > r-cran-rstan/r-cran-rstanarm on 2023-10-27 which have not yet > > > migrated. > > I've asked ftpmaster for removal (see bug #1056913) of some architecture > builds for r-cran-rstan which is preventing the migration of this > package. It seems the armel build was retried by someone and it succeeded [2]. Fixing the riscv64 build (where it built previously) would be nice, as riscv64 is aiming to be a release architecture for trixie, but I do not see that being a blocker for this transition. > There is another issue for r-cran-rstan which affects a regression > for r-cran-projpred for ppc64el architecture[1] which boils down to: > ... > It seems something on this architecture is broken I can't do anything > about. Could you provide help here? It looks like this was also retried and succeeded [3]. Regards Graham [1] https://lists.debian.org/debian-devel-announce/2023/11/msg5.html [2] https://buildd.debian.org/status/package.php?p=r-cran-rstanarm [3] https://ci.debian.net/packages/r/r-cran-projpred/testing/ppc64el/
Bug#1054657: transition: r-bioc-biocgenerics
Control: tags -1 + moreinfo Hi Andreas On Mon, 13 Nov 2023 at 09:10, Andreas Tille wrote: > Thanks to the hint from Charles I found that SparseArray is not new in > Bioconductor and we can build the previous version with the current > packages in unstable which I did and uploaded to new. Thanks. Since I count about 30 r-bioc-* packages with direct dependencies on r-cran-matrix, we'd rather not entangle the r-bioc* transition with rmatrix (#1055922), so please remove the 'moreinfo' tag once SparseArray has cleared NEW, and rmatrix has migrated. Regards Graham
Bug#1054657: transition: r-bioc-biocgenerics
HI Andreas On Sun, 29 Oct 2023 at 16:06, Andreas Tille wrote: > Sorry, my question was probably confusing. I was not talking about the > new packages. I was talking about the 170 r-bioc-* packages. If I > upload these to experimental, will it be necessary to upload these to > unstable again or can these be moved to unstable in one rush. Also > interesting in this connection: Will the tracker display the levels > of packages uploaded to experimental? I still don't think this has ever been possible. > I'm comfortable with doing source-only uploads of packages that have > passed NEW. I'm not comfortable with uploading 170 packages twice - > once to experimmental and once again to unstable. Given that all > this work has mainly ended up on my shoulders I would prefer to > upload directly to unstable and simply bear with the waiting time > in NEW. Why do you want to upload 170 packages to experimental? We are only asking that the NEW packages involved be uploaded to experimental and clear NEW review before we start the transition. > But you just mentioned the tracker in your previous mail[1]. The tracker is visible [0], but is still in the 'Some planned transitions' section along with many others. > I admit I personally see the bigger drawback on spending my time twice > on 170 packages than waiting for new packages. Please explain (again) > the real drawback of a transition that was delayed due to waiting for > new packages in total by estimated (not verified) by about two weeks. >From what I saw in the last transition, r-bioc-biocgenerics was uploaded on 2023-07-17, and the last package (I think) to clear NEW was r-bioc-pfamanalyzer, which was accepted on 2023-08-15, almost one month after the transition started. Again, we are not asking for the entire transition to happen in experimental. We are only asking for the NEW packages, so that NEW processing happens before the transition, and not during. Regards Graham [0] https://release.debian.org/transitions/
Bug#1055085: (some kind of) transition: add python3.12 as a supported python3 version
Hi Matthias On Tue, 31 Oct 2023 at 07:15, Matthias Klose wrote: > Please setup a tracker to add python3.12 as a supported python3 version. This > is > non-blocking, as packages can migrate on their own once built. I'm not yet > starting this, just want to have an overview of affected packages. > > Please re-use the final version of the python3.11 tracker. > https://release.debian.org/transitions/html/python3.11-add.html I've set up a tracker [1]. It is based on the tracker used for python3.11 with the inclusion of boost-defaults (which is otherwise not pulled in) and the exclusion of dh-python (which confused ben in dependency levels 1 and 2). Excluding the 'unknown' packages on the tracker (which should not need rebuilding), it lists the same packages as the old one. Regards Graham [1] https://release.debian.org/transitions/html/python3.12-add.html
Bug#1054657: transition: r-bioc-biocgenerics
Hi Andreas On Sun, 29 Oct 2023 at 04:33, Andreas Tille wrote: > Can you confirm that packages uploaded to experimental can be moved in > one rush from experimental to unstable without extra uploads? I don't think this has ever been possible. The packages would need to be uploaded again to unstable, presumably at the appropriate dependency level in the transition. Seeing these packages would be NEW, even if they were initially uploaded directly to unstable, they would likely still require source-only uploads for migration anyway. > Do you > have this process in mind after the moreinfo tag is removed? No, after the NEW packages have cleared NEW and the moreinfo tag is removed, we'll consider a slot for the transition. We would like to avoid stalling the transition with multiple packages going through NEW, and putting pressure on FTP Masters by telling them a package is needed for a transition is not nice either. Regards Graham
Bug#1054657: transition: r-bioc-biocgenerics
Control: tags -1 + moreinfo Hi Andreas On Fri, 27 Oct 2023 at 14:03, Andreas Tille wrote: > The BioConductor transition will bump the virtual package > r-api-bioc-3.17 to r-api-bioc-3.18. > > BTW, I'm aware that a couple of r-bioc-* packages did not yet migrated > to testing due to some autopkgtest issues on some architectures. We > decided that it makes sense to do the transition first and approach > upstream about their latest release in case those issues might remain. Please remove the 'moreinfo' tag once all NEW packages needed for this transition have been uploaded to experimental and have passed through NEW review. > Ben file: > > title = "r-bioc-biocgenerics"; > is_affected = .depends ~ "r-api-bioc-3.17" | .depends ~ "r-api-bioc-3.18"; > is_good = .depends ~ "r-api-bioc-3.18"; > is_bad = .depends ~ "r-api-bioc-3.17"; I modified the tracker used for the previous transition and the output can be viewed here: https://release.debian.org/transitions/html/r-api-bioc-3.18.html Please let me know if that doesn't look correct. Regards Graham
Bug#1054659: transition: utf8proc
Control: tags -1 confirmed Hi Mo On Fri, 27 Oct 2023 at 15:36, M. Zhou wrote: > We can start the transition for utf8proc, which recently got an > SOVERSION bump from 2 to 3. I tested the reverse dependencies > on ppc64el and all of them are fine. The results for amd64 should > be the same. Please go ahead. Regards Graham
Bug#1050223: RM: r-cran-rgdal/1.6-7+dfsg-1
Control: reopen -1 Something went wrong and r-cran-rgdal/1.6-7+dfsg-1 migrated back into testing on 2023-09-14.
Bug#1042005: Info received (Bug#1042005: transition: mumps hypre2.28.0 superlu combblas)
Hi On Thu, 31 Aug 2023 at 12:03, Sebastian Ramacher wrote: > Unfortunately trilinos is a key package and so cannot be removed without > much effort from testing to complete the transition. Can you please take > a look at fixing the current issues with trilinos? As can be seen on salsa [1], packaging of trilinos 14.4.0-1 is underway, although it is taking a bit longer than expected. In the meantime, I've uploaded trilinos 13.2.0-5 to unstable, which should fix the build with GCC-13. Regards Graham [1] https://salsa.debian.org/science-team/trilinos
Bug#1042896: transition: armadillo
Control: tags -1 confirmed Hi Kumar On Wed, 30 Aug 2023 at 07:22, Kumar Appaiah wrote: > Thanks for the response. I have build the following packages > successfully using the new Armadillo: > > gdal > gnss-sdr > phyx > seer > tvc Great! > I could not build mlpack since the build failed, but I am sure it's > not due to pip. Here is the extract from the failed build log: That's fine, mlpack has not been in testing for some time already. Please go ahead. Regards Graham
Bug#1043144: transition: mutter/gnome-shell 44
On Sun, 27 Aug 2023 at 18:21, Jeremy Bícha wrote: > This transition is done, but I think gnome-shell-extension-dashtodock > is popular enough that it's helpful to hint 87+really84-1 in sooner. I marked gnome-shell-extension-dashtodock urgent and it has migrated, thanks.
Bug#1041982: transition: symfony 6
Hi David On Tue, 25 Jul 2023 at 11:57, David Prévot wrote: > Do you have a way to spot packages in Sid currently depending on > symfony (<< 6~) in order to file bugs and eventually provide patches? You could use a ben tracker for this. I've set up something basic [1]. Feel free to submit MRs in Salsa [2] with improvements. Regards Graham [1] https://release.debian.org/transitions/html/symfony6.html [2] https://salsa.debian.org/release-team/transition-data
Bug#1042896: transition: armadillo
Hi Kumar On Wed, 2 Aug 2023 at 13:48, Kumar Appaiah wrote: > I have uploaded the new Armadillo to experimental. I would like your > permission to upload it to unstable. binNMUs should be sufficient for > the reverse dependencies. Have you checked that all the reverse-build-dependencies build with the new version of armadillo? Regards Graham
Bug#1043144: transition: mutter/gnome-shell 44
Hi libmutter-11-0 is gone from testing and gnome-shell has migrated. Is anything outstanding, or can we consider this transition done? Regards Graham
Bug#1049364: transition: gnome-panel
Control: tags -1 confirmed Hi Dmitry On Mon, 14 Aug 2023 at 18:27, Dmitry Shachnev wrote: > gnome-panel has a new release, which bumped SONAME of the shared library. > I packaged it in experimental and verified that all reverse build-dependencies > (gnome-applets, gnome-flashback, sensors-applet, workrave) build fine with it. Please go ahead. Regards Graham
Bug#1043144: transition: mutter/gnome-shell 44
Hi Jeremy On Thu, 24 Aug 2023 at 12:30, wrote: > age-days 2 budgie-desktop/10.8-2 > age-days 2 gnome-remote-desktop/44.2-6 I added these earlier, along with a removal hint for: gnome-shell-extension-impatience/0.4.8-2 > age-days 2 gnome-shell-extension-dashtodock/87-1 This was just uploaded, and the previous version is already removed from testing, but I'll keep an eye on it. > remove gnome-shell-extension-no-annoyance/0+20220925-c6804a4-3 > remove bfh-metapackages/20211009-20 I've added these, thanks. Regards Graham
Bug#1050365: transition: yaml-cpp
Control: tags -1 confirmed Hi Gianfranco On Wed, 23 Aug 2023 at 17:09, Gianfranco Costamagna wrote: > Only openimageio and qtcreator have issues finding the new libyaml-cpp > release, and this can be easily solved > by dropping the Findyaml-cpp.cmake > > excluding unrelated failures and packages out of testing, it's a 18 packages > transition. Please go ahead. Regards Graham
Bug#1043591: transition: libnfs
Control: tags -1 confirmed Hi Balint On Sun, 13 Aug 2023 at 11:33, Bálint Réczey wrote: > I would like to update libnfs in unstable to the 5.0.2 version. > > It is built for all release architectures in experimental. > The transition would involve libnfs and its reverse > dependencies: > far2l gvfs mpd kodi mpd qemu vlc > > All of them build with the new libnfs version: > https://people.debian.org/~rbalint/transitions/libnfs-5/ Please go ahead. Regards Graham
Bug#1043144: transition: mutter/gnome-shell 44
On Wed, 23 Aug 2023 at 12:04, Simon McVittie wrote: > Please consider adding hints as follows: > > remove gnome-shell-extension-arc-menu/49+forkv29-3 > remove gnome-shell-extension-dashtodock/75-1 > remove gnome-shell-extension-easyscreencast/1.7.0-2 > remove gnome-shell-extension-flypie/21-1 > remove gnome-shell-extension-freon/52+dfsg-1 > remove gnome-shell-extension-gamemode/8-2 > remove gnome-shell-extension-hamster/0.10.0+git20210628-4 > remove gnome-shell-extension-impatience/0.4.8-2 > remove gnome-shell-extension-panel-osd/1.0.50.gc032923-3 > remove gnome-shell-extension-system-monitor/40-5 > remove gnome-shell-extension-vertical-overview/10-1 > remove gnome-shell-extension-weather/119-1 Hints added, thanks. > If I understand britney syntax correctly, if extension maintainers do > a new sourceful upload fixing the "needs update for GNOME Shell 44" RC > bugs, those removal hints would not match the updated package because > its version would be higher, so the newer version would still be allowed > to migrate and stay in testing. Yes, the removal hints only apply to the specified version.
Bug#1050166: RM: printrun/2.0.1-1
Control: tags -1 + moreinfo Hi Rock Storm On Mon, 21 Aug 2023 at 09:03, Rock Storm wrote: > Dear release team, I would like to request the removal of the printrun > package (which I maintain) from *testing* due to bug #1050157 [1]. The severity of #1050157 is 'important', so it will just migrate back into testing after removal. Please raise the severity of that bug to RC (i.e. serious or above), then remove the 'moreinfo' tag from this bug. > IMHO, such a poor user experience > makes the package not suitable for migrating to Ubuntu and other > derivatives that rely on Debian testing Ubuntu imports from Debian unstable, so they already have the new version of printrun. Please consider filing a removal bug there too. Regards Graham
Bug#1043144: transition: mutter/gnome-shell 44
Control: tags -1 confirmed Hi Simon I added your combined ben file to the tracker with some minor changes: https://release.debian.org/transitions/html/gnome-shell-44.html On Tue, 15 Aug 2023 at 17:18, Simon McVittie wrote: > I think this is ready to go. Repeating the list of packages needing > sourceful uploads from experimental into unstable in approximately this > order, for the release team's convenience: > > * mutter > * gnome-shell > * gnome-shell-extensions > * gnome-remote-desktop > * budgie-desktop > * gnome-shell-extension-bluetooth-quick-connect > * gnome-shell-extension-gsconnect > * gnome-shell-extension-tiling-assistant > > And then any remaining extensions in > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-44 > will need temporarily removing from testing to let the transition through. > > The release team has traditionally been relatively trigger-happy about > removing broken Shell extensions, since they are clearly less important > than GNOME itself. When the transition is otherwise ready to migrate, > I'll provide a full list of packages needing removal. Please go ahead. Regards Graham
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas On Wed, 16 Aug 2023 at 11:24, Andreas Tille wrote: > Am Tue, Aug 01, 2023 at 01:06:41PM + schrieb Graham Inggs: > > At least the following packages are failing their own autopkgtests in > > unstable (list not complete): > > r-bioc-cummerbund > > r-bioc-decoupler > > r-bioc-monocle > > r-bioc-scran > > r-bioc-singler > > Most of those packages have autopkgtests marked as >Failed (not a regression) > Am I correct that we do not need to take any action regarding the > transition? Well, it means those autopkgtests already regressed in testing, but they do not block migration. Now that r-bioc-biocgenerics has migrated, you can see that at least r-bioc-cummerbund, r-bioc-scran and r-bioc-singler are still blocked by other packages which need attention. > > r-bioc-dupradar has regressed from passing to neutral, apparently due > > to the use of 'skip-not-installable'. Please don't use this > > restriction on all the autopkgtests in a package, otherwise there are > > no tests which are not superficial, and regressions can migrate to > > testing. > > Could you please be more verbose about this hint (may be suggesting a > patch that implements your suggestion since I'm afraid I do not > understand this correctly) --- a/debian/tests/autopkgtest-pkg-r.conf +++ b/debian/tests/autopkgtest-pkg-r.conf @@ -2,4 +2,3 @@ r-cran-knitr, \ r-cran-rmarkdown, \ r-bioc-annotationhub -extra_restrictions=skip-not-installable In general, skip-not-installable is no good as it does not catch when packages are non-installable, and during that time, it can hide other regressions and allow them to migrate. It may have some special use cases; e.g. a test depending on a package that is only available in unstable (virtualbox or openjdk-8), but skip-not-installable should not be applied to a package's only autopkgtest, or all of them, only the one that actually requires it. On Fri, 18 Aug 2023 at 10:40, Andreas Tille wrote: > I've fixed r-bioc-decoupler manually to remove this blocker quickly > (instead of working around invalid version specifications by detecting > these in dh-r) Thanks! elbrus marked r-bioc-decoupler urgent, and rather than being blocked by the autopkgtest regression of r-bioc-metagenomeseq, I removed 1.40.0-1 from testing (previously removed on 2023-07-16, but somehow migrated again) to allow r-bioc-biocgenerics to migrate. > Do you see any other blocker? Besides those packages mentioned above, there are others still needing attention. These can be seen on the team's DDPO page [1], just search for 'Excuse' there. Regards Graham [1] https://qa.debian.org/developer.php?email=r-pkg-team%40alioth-lists.debian.net
Bug#1050113: unblock: rust-rustls-webpki/0.101.3-1.1
Hi On Sat, 19 Aug 2023 at 23:57, plugwash wrote: > The package is blocked by autopkgtest failures on ppc64el and s390x. The > reason > for these failures is that the package (which is arch all) is not installable > on these architectures because it depends on the ring crate which is not > currently portable. Please can you override these failures and allow the > package to migrate to testing. I added a hint, but rust-rustls-webpki/0.101.3-1.1 was superseded by 0.101.3-2. I'll look again later. Regards Graham
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas Sorry for the incomplete reply. I'll respond to the other points when I have more time. On Wed, 16 Aug 2023 at 11:24, Andreas Tille wrote: > Do you see any further blockers? tracker.d.o. is having some issues (see #1043546), but you can still access up-to-date excuses here: https://qa.debian.org/excuses.php?package=r-bioc-biocgenerics The current blocker I see is: Implicit dependency: r-bioc-biocgenerics r-bioc-decoupler (not considered) Regards Graham
Bug#1040498: Should we consider the transition ready (Was: Bug#1040498: transition: r-bioc-biocgenerics)
Hi Andreas You should check on the package tracker pages for all the r-bioc-* uploads and make sure they are ready to migrate along with r-bioc-biocgenerics, e.g. r-bioc-cummerbund [1]. r-bioc-biocversion appears to break the autopkgtest of r-cran-biocmanager/1.30.21.1+dfsg-1 in testing. At least the following packages are failing their own autopkgtests in unstable (list not complete): r-bioc-cummerbund r-bioc-decoupler r-bioc-monocle r-bioc-scran r-bioc-singler r-bioc-dupradar has regressed from passing to neutral, apparently due to the use of 'skip-not-installable'. Please don't use this restriction on all the autopkgtests in a package, otherwise there are no tests which are not superficial, and regressions can migrate to testing. Regards Graham [1] https://tracker.debian.org/pkg/r-bioc-cummerbund
Re: FUSE 3 transition
Hi László On Sat, 30 Jul 2022 at 14:28, László Böszörményi (GCS) wrote: > Please note I do not maintain the reverse dependent fuse2 packages. > But I will ping those maintainers as I don't want to ship Bookworm > with fuse2. Its development stopped two years ago and fuse3 is here > for six years. I think it was enough time to adapt to it. Do you have plans to push this forward for trixie? Regards Graham
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Dirk
On Thu, 13 Jul 2023 at 16:25, Dirk Eddelbuettel wrote:
> Sounds good, and thanks for the assist! I should be able to provide a pretty
> quick turn-around.
I believe the attached patch should do the trick. It's basically
Paul's list from message #210, plus r-cran-interval and
r-cran-maldiquant. I've also used a << relationship against the
versions in unstable, and appended a tilde at the end. I believe this
will work better for derivatives and make backports easier.
Regards
Graham
--- a/debian/control
+++ b/debian/control
@@ -52,31 +52,17 @@
Provides: r-api-4.0, r-graphics-engine-${graphicsengine:Version}
Recommends: r-recommended, r-base-dev, r-doc-html
Suggests: elpa-ess, r-doc-info | r-doc-pdf, r-mathlib, r-base-html
-Breaks: r-bioc-graph (<< 1.62.0-1~),
-r-cran-bbmle (<< 1.0.20-5~),
-r-cran-biocmanager (<< 1.30.4+dfsg-2~),
-r-cran-caret (<< 6.0-84-2~),
-r-cran-cmprsk (<< 2.2-8-1~),
-r-cran-coin (<< 1.3-0-1~),
-r-cran-dendextend (<< 1.12.0+dfsg-1~),
-r-cran-fields (<< 9.8-3-1~),
-r-cran-filehash (<< 2.4-2-2~),
-r-cran-future (<< 1.14.0+dfsg-1~),
-r-cran-genetics (<< 1.3.8.1.2-1~),
-r-cran-haplo.stats (<< 1.7.9-4~),
-r-cran-igraph (<< 1.2.4.1-1~),
-r-cran-lava (<< 1.6.5-1~),
-r-cran-libcoin (<< 1.0-4-1~),
-r-cran-msm (<< 1.6.7-1~),
-r-cran-permute (<< 0.9-5-1~),
-r-cran-phangorn (<< 2.5.5-1~),
-r-cran-popepi (<< 0.4.7-1~),
-r-cran-recipes (<< 0.1.6-1~),
-r-cran-sp (<< 1:1.3-1-2~),
-r-cran-spam (<< 2.2-2-1~),
-r-cran-units (<< 0.6-3-1~),
-r-cran-vegan (<< 2.5-5+dfsg-1~),
-r-cran-zelig (<< 5.1.6.1-1~)
+Breaks: r-cran-cairo (<< 1.6-0-4~),
+r-cran-intervals (<< 0.15.3-1~),
+r-cran-fnn (<< 1.1.3.2-1~),
+r-cran-magick (<< 2.7.4+dfsg-2~),
+r-cran-maldiquant (<< 1.22.1-1~),
+r-cran-ps (<< 1.7.5-1~),
+r-cran-ragg (<< 1.2.5-3~),
+r-cran-svglite (<< 2.1.1-3~),
+r-cran-tibble (<< 3.2.1+dfsg-2~),
+r-cran-tikzdevice (<< 0.12.4-3~),
+r-cran-vdiffr (<< 1.0.5-3~)
Description: GNU R core of statistical computation and graphics system
R is a system for statistical computation and graphics. It consists
of a language plus a run-time environment with graphics, a debugger,
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Hi Dirk On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel wrote: > On 12 July 2023 at 19:47, Paul Gevers wrote: > | On 12-07-2023 16:02, Dirk Eddelbuettel wrote: > | > I can add the Breaks as a 'best of the worse alternative'. And, I > presume, I > | > can remove the existing four-year breaks? [1] > | > | Yes, you only need to carry the Breaks until in the next release. So > | every Breaks that's present in the r-base package in bookworm can be > | removed from the r-base package in unstable. > > Good point and much less ugly then :) I'll prepare a patch dropping the old and adding the new Breaks. Regards Graham
Bug#1040001: transition: r-base
Hi Andreas On Wed, 5 Jul 2023 at 15:51, Andreas Tille wrote: > the just uploaded r-base 4.3.1-2 implements r-graphics-engine-* which is > respected by dh-r 20230705 (also just uploaded). It would be great if > you could setup transition tracker. I don't think it's possible to set up a tracker for this first "transition", as no packages currently depend on r-graphics-engine-*. > Am I understanding things correctly that I can now start uploading those > r-cran-* packages featuring bugs >autopkgtest failure with r-base (4.3.1-1) > even if the tracker is not yet setup? Please wait until r-base and dh-r are built and in the installed state on all architectures. Regards Graham
Bug#1040001: transition: r-base
Hi Andreas On Sun, 2 Jul 2023 at 19:57, Andreas Tille wrote: > 45 > > serious bugs that are all caused by the non-transition while we should > have done one. That's pretty annoying for the people who need to do the > work (in this case basically me). IMHO, those autopkgtests regression bugs are useful. At least #1039651 (in r-cran-gnm) and #1039653 (in r-cran-irkernel) appear unrelated to the R_GE_version issue. In addition, r-cran-bookdown [1] appears to break r-cran-flextable's autopkgtests and r-cran-checkmate [2] fails its own autopkgtests on armel, armhf and i386. These do not have bugs filed yet. Regards Graham [1] https://tracker.debian.org/pkg/r-cran-bookdown [2] https://tracker.debian.org/pkg/r-cran-checkmate
Bug#1036885: unblock: hipsparse/5.3.3+dfsg-2
Hi Christian On Sun, 28 May 2023 at 18:48, Christian Kastner wrote: > unblock hipsparse/5.3.3+dfsg-2 The debdiff looks good to me, however the migration of hipsparse/5.3.3+dfsg-2 appears to be blocked by rocsparse/5.3.0+dfsg-3 [1]. Migrates after: rocsparse Migration status for hipsparse (5.3.3+dfsg-1 to 5.3.3+dfsg-2): BLOCKED: Needs an approval (either due to a freeze, the source suite or a manual hint) Issues preventing migration: ∙ ∙ Not touching package due to block request by freeze (Follow the freeze policy when applying for an unblock) ∙ ∙ Too young, only 2 of 5 days old ∙ ∙ Build-Depends(-Arch): hipsparse rocsparse ∙ ∙ Depends: hipsparse rocsparse I don't see an unblock request for rocsparse/5.3.0+dfsg-3, would you file one please? Regards Graham [1] https://tracker.debian.org/pkg/hipsparse
Bug#1036759: unblock: heat-cfntools/1.4.2-3
Control: tags -1 + moreinfo Hi Thomas On Thu, 25 May 2023 at 16:12, Thomas Goirand wrote: > unblock heat-cfntools/1.4.2-3 Debdiff looks good to me, but did you forget to upload? Regards Graham
Bug#1036535: unblock: altos/1.9.16-2
Control: tags -1 + moreinfo Hi Bdale On Mon, 22 May 2023 at 07:48, Bdale Garbee wrote: > [ Risks ] > The > change for the -2 upload was a one-line change of the delivery path for a > rarely-used systemd unit file in the packaging scripts (that is not enabled > by default). If this was an upload of 1.9.15-2 with only that change, altos would already have been unblocked. > [ Checklist ] > [ ] attach debdiff against the package in testing You didn't attach a debdiff, but I generated one in order to review the changes between 1.9.15-1 in testing and 1.9.16-2 in unstable. As far as I could see, the only change according to the upstream release notes was: * Add TeleGPS v3.0 support However, the debdiff showed a lot more, including the addition of several fonts. Diffstat showed: 159 files changed, 824544 insertions(+), 3993 deletions(-) > [ Other info ] > I am both an upstream and Debian package maintainer of altos. As upstream, please comment on risks of the other changes between 1.9.15 and 1.9.16. If you think it will help, please attach a filtered debdiff, e.g. excluding the font additions. Regards Graham
Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1
tags -1 + moreinfo Hi Yadd On Wed, 3 May 2023 at 04:51, Yadd wrote: > here is the current debdiff (without the big removal of useless > discoveryjs-json-ext/benchmarks) I removed the moreinfo tag before realizing this is exactly the same as the first debdiff. You seem to have missed this comment: On Wed, 15 Mar 2023 at 22:15, Paul Gevers wrote: > This doesn't look like a targeted fix, but rather seems to include much > more. > > How about reverting and providing a fix only for that CVE please? Regards Graham
Bug#1036831: unblock: mobile-broadband-provider-info/20230416-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: mobile-broadband-provider-i...@packages.debian.org Control: affects -1 + src:mobile-broadband-provider-info Please unblock package mobile-broadband-provider-info [ Reason ] This is an update of a data-only package containing settings for mobile broadband providers. [ Impact ] Users will miss out on up-to-date settings. [ Tests ] mobile-broadband-provider-info has no autopkgtests, but data files are validated during the build. [ Risks ] It is possible that some new settings are incorrect, but only users of those particular providers would be affected. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] None unblock mobile-broadband-provider-info/20230416-1 m-bb-p-i.debdiff Description: Binary data
Bug#1035298: pre-approval: unblock: Lazarus/2.2.6+dfsg1-2
Control: tags -1 + confirmed moreinfo Hi Abou Please go ahead and upload to unstable, and remove the moreinfo tag once the package is built. Regards Graham
Bug#1035088: unblock: gelemental/2.0.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: gelemen...@packages.debian.org Control: affects -1 + src:gelemental Please unblock package gelemental [ Reason ] This is a maintenance release from upstream with only the following changes: * an updated Russian translation * fix button colours with new Yaru themes (src:yaru-theme in Debian) * avoid FTBFS with Pango 1.50 (merged patch from Debian) [ Impact ] * Users will not benefit from the updated Russian translation. * Buttons will not appear in different colours for users of new Yaru themes. [ Tests ] gElemental has no autopkgtests. I have tested the gElemental UI with every Yaru theme. [ Risks ] The Russian translation could introduce new mistranslations. The changes for the new Yaru themes are specifically targeted at the new theme names, so should not be able to affect users of other themes. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] Upstream regenerated configuration files (autoreconf -fi) which introduced a lot of noise in the debdiff. I provide two filtered debdiffs, one with only Debian packaging changes: filterdiff -i '*/debian/*' and the other with only upstream changes (excluding regenerated configuration files and the Russian translation): filterdiff -x '*/debian/*' -x '*/aclocal.m4' -x '*/configure' -x '*/config.*' -x '*/ltmain.sh' -x '*/Makefile.in*' -x '*/intltool-*.in' -x '*/po/ru.po' unblock gelemental/2.0.2-1 debian-only.debdiff Description: Binary data upstream-only.debdiff Description: Binary data
Bug#1033811: closed by Graham Inggs (Re: Bug#1033811: unblock: mariadb/1:10.11.2-2)
Hi Otto On Thu, 20 Apr 2023 at 16:44, Otto Kekäläinen wrote: > Can you please list the commits you do not accept so I can revert them and > upload a 10.11.2-3 which you are then willing to approve? I've had a look at some of the bugs closed in the changelog of 10.11.2-2; #866751, #1029165, #1032047, #1032861 and #1032860, and none of these seem to be of severity: important or release critical. I suggest reverting to 10.11.2-1 and then only cherry-picking the fixes from 10.11.2-2 that are appropriate for the current freeze stage, i.e. release critical bugs, severity: important bugs, and translation updates and documentation fixes, etc. Be sure to make it clear in your unblock request why the changes are important, e.g. Reason, Impact, Tests, Risks, as per the template generated by reportbug. Regards Graham
Bug#1034518: unblock: openstack-pkg-tools/123
Hi Thomas I believe only the packages without autopkgtests; viz. cinder, gnocchi, magnum, neutron and watcher needed unblocking, and I have done those. I have aged all of them though. Regards Graham
Bug#1033219: unblock: ghostscript/10.0.0~dfsg-10
Control: tags -1 + confirmed Hi Håvard On Sun, 26 Mar 2023 at 22:18, Håvard F. Aasen wrote: > The fix is for making the package cross-buildable, not sure what more > to tell you. I was hoping for some motivation as to why we needed this fix now during the freeze, but not to worry, Helmut has already convinced me. I have confirmed that building ghostscript with and without your patch produces identical binary packages. Regards Graham
Bug#1033219: unblock: ghostscript/10.0.0~dfsg-10
Control: tags -1 + moreinfo Hi Håvard I don't see ghostscript/10.0.0~dfsg-10 in unstable, so I assume this is a pre-approval request. Please explain why we need this fix in bookworm, and why it can't wait for trixie. Regards Graham
Bug#1032073: unblock: scipy/1.10.1-1
Control: tags -1 + confirmed Hi Drew On Mon, 27 Feb 2023 at 14:12, Drew Parsons wrote: > I recommend we allow scipy 1.10.1 into bookworm (assuming it passes 10 > day freeze testing as normal). I'm filing this bug to check if you > agree that's a good idea before building and uploading to unstable. With 1.10.0-12 now in testing, please go ahead. Regards Graham
Re: sagemath in bookworm?
Hi Tobias On Wed, 8 Feb 2023 at 12:09, Tobias Hansen wrote: > sagemath is on track to re-enter testing on February 12 - if that's not too > late for the soft freeze. > > If it's too late, could you help along to make it re-enter sooner? For a start, I'll let giac migrate early. Regards Graham
Re: Bug#1022571: transition: pandas 1.3 -> 1.5
Hi Rebecca, Andreas On Wed, 25 Jan 2023 at 11:43, Andreas Tille wrote: > I was motivated for this patch by Diane's statement on the Debian Med > matrix channel that dask and dask.distributed are interconnected. If > the autopkgtest on Salsa CI[4] would have passed I would have uploaded. We will temporarily remove dask.distributed from testing, which should unblock dask and pandas. No uploads please, until dask and pandas have migrated. Regards Graham
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Sat, 21 Jan 2023 at 19:59, Graham Inggs wrote: > I noticed there was an upload of opm-common 2022.10+ds-3, but it also > FTBFS on armhf. I trust this is on your radar. It turns opm-common was blocked by python3-defaults and python3-defaults was blocked by opm-common's FTBFS on armhf. To break out of the Catch-22, I temporarily removed opm-* from testing and dune-* migrated together. opm-* will be able to migrate once the armhf build is fixed, or opm-common stops building for that architecture. Regards Graham
Re: Bug#1022571: transition: pandas 1.3 -> 1.5
Hi Rebecca On Tue, 24 Jan 2023 at 00:16, Rebecca N. Palmer wrote: > The remaining autopkgtest failures blocking pandas are: > - dipy/amd64 and snakemake/i386 look like random flakiness: please retry > them. (I think DMs can't use the self-service interface.) Or for dipy, > see #1029533 for a possible fix. These have cleared up. > - python-xarray/i386 looks like xarray not pandas: see #1004869. Sometimes britney is too greedy and pins too many packages from unstable. I managed to find the right combination [1] and got the test to pass without python-xarray. > - dask and dask.distributed have to go together, with or before pandas. There's nothing in the currently uploaded packages that specifies this, although I do see a commit on salsa [2]. I tried running dask.distributed's autopkgtest with dask and itself from unstable [3], but no luck. Regards Graham [1] https://ci.debian.net/packages/p/python-xarray/testing/i386/ [2] https://salsa.debian.org/python-team/packages/dask.distributed/-/commit/9df3fe1a0ea7538f742ebb162379e3cd50b388e6 [3] https://ci.debian.net/packages/d/dask.distributed/testing/amd64/
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Wed, 18 Jan 2023 at 20:48, Graham Inggs wrote: > Almost there, the excuses [1] for dune-common shows: > > Migration status: Blocked. Can't migrate due to a non-migratable > dependency. Check status below. > Blocked by: opm-simulators/ppc64el > >I don't think any action is required, just some waiting. My apologies, I knew the ppc64el buildd infrastructure was a bit behind, so didn't look at this closely. Upon further investigation, I found that the dune-common transition is entangled with the Python 3.11 transition through opm-simulators. We will either wait for Python 3.11, or find a way to disentangle them. > By the way, excuses [2] for opm-common shows: > > Issues preventing migration: > missing build on armhf I noticed there was an upload of opm-common 2022.10+ds-3, but it also FTBFS on armhf. I trust this is on your radar. Regards Graham
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Wed, 18 Jan 2023 at 09:59, Markus Blatt wrote: > Thanks a lot Graham. That really worked like a charm and seem to finished. > Cool.These processes > and the tools in Debian are really great. Almost there, the excuses [1] for dune-common shows: Migration status: Blocked. Can't migrate due to a non-migratable dependency. Check status below. Blocked by: opm-simulators/ppc64el I don't think any action is required, just some waiting. > Next time I will try to do that myself to avoid confusion. > Is the upload to NEW for dune-common optional as the package name stays the > same? That's correct. By the way, excuses [2] for opm-common shows: Issues preventing migration: missing build on armhf Regards Graham [1] https://tracker.debian.org/pkg/dune-common [2] https://tracker.debian.org/pkg/opm-common
Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)
Hi Markus On Tue, 3 Jan 2023 at 02:46, Markus Blatt wrote: > Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and > opm-upscaling will > need to be rebuild for the mini-transition. Otherwise they won't work > correctly > > If it is possible to give me upload rights for the DUNE packages, then I > could do the > upload/transition work myself, too. But I would still require some guidance > (next steps, etc.) > and don't want to step on other people's toes. I found out about this transition after an Ubuntu developer asked me to schedule binNMUs for some opm-* packages. In future, you can follow steps described [1] and file a transition bug against release.debian.org. For now, I have scheduled binNMUs for opm-grid, opm-material, opm-models, opm-simulators, and opm-upscaling. I've also set up a transition tracker [2], with the following ben file: title = "dune-common-2.9.0"; is_affected = .depends ~ /libdune-common-2/; is_good = .depends ~ /libdune-common-2\.9/; is_bad = .depends ~ /libdune-common-2\.8/; notes = "https://lists.debian.org/debian-science/2023/01/msg1.html;; export = false; Please let us know if anything else is needed. Regards Graham [1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions [2] https://release.debian.org/transitions/html/dune-common-2.9.0.html
Re: transition: pandas 1.3 -> 1.5
Hi Rebecca On Fri, 6 Jan 2023 at 10:30, Rebecca N. Palmer wrote: > Should this go ahead before the freeze? I think yes if the new dask > works, but am open to disagreement. Please go ahead. With numpy 1:1.24.1-2 built on all release architectures, now is a good time. Regards Graham
Re: SONAME bumps (transitions) always via experimental
Hi All On Fri, 6 Jan 2023 at 00:33, Bastian Blank wrote: > However, please describe an actionable plan. What do you want to be > rejected, in a codified form. > > It would be nice if you could provide a patch for process-new that > displays this information. Would it be a bad thing to require all uploads that need to go through NEW (source and binary) to target experimental? I have been doing this for my own, and sponsored, uploads for some years already. There's usually some reason for another upload after acceptance anyway; e.g. source upload for arch:all, breaking changes in toolchain or other dependencies, symbols file needs tweaking, autopkgtest needs tweaking, bump Standards-Version, update debian/copyright years, etc. Regards Graham
Bug#1027044: transition: numpy 1.24.x
Control: tags -1 + confirmed Hi Sandro On Sat, 7 Jan 2023 at 20:15, Sandro Tosi wrote: > the pending bugs number is dropping rapidly, so i'd like to ask for > this transition consideration. having numpy 1.24 in unstable, and > raising severity to RC, will likely speed up bugs fixing too. The last packages involved in the Python 3.11 rebuilds build-depending on numpy have now built on all architectures. Please go ahead. Regards Graham
Bug#1014460: transition: php8.2
On Fri, 6 Jan 2023 at 12:00, Sebastiaan Couwenberg wrote: > is_good doesn't match what's currently used for builds with php8.2: > > phpapi-20220829 This has just been merged, thanks Adrian! [1] https://salsa.debian.org/release-team/transition-data/-/merge_requests/36
Bug#1025056: transition: numerical library transition: hypre / petsc / slepc / sundials
Hi Drew On Mon, 2 Jan 2023 at 12:12, Drew Parsons wrote: > Looks like deal.ii needs another binNMU against sundials 6.4.1+dfsg1-3 > to catch the new libsundials-nvecparallel-mpi6 A binNMU was scheduled for 6.4.1+dfsg1-2 [1]. -3 shouldn't be relevant for building, however we hit a 'illegal instruction' on the arm64 buildds. Regards Graham [1] https://buildd.debian.org/status/package.php?p=deal.ii
Bug#1026825: python3.11 as default
Control: tags -1 + confirmed Hi Matthias Happy new year! On Sun, 25 Dec 2022 at 12:17, Graham Inggs wrote: > Python3-defaults with Python 3.11 as a supported version has now > migrated to testing. Let's go ahead with this once PHP 8.2 (#1014460) > and qtbase-opensource-src (#1025863) are done. qtbase-opensource-src is done, there's been no progress with PHP 8.2, but we can deal with mapserver and zeroc-ice if they become entangled. Please go ahead. Regards Graham PS: tracker is at: https://release.debian.org/transitions/html/python3.11-default.html
Re: Python 3.11 for bookworm?
Hi Matthias On Wed, 21 Dec 2022 at 18:24, Matthias Klose wrote: > while we have not an 100% agreement to go ahead, I think we should aim for > 3.11. Action speaks louder than words, and there's been a whole lot of work done to push this forward. > The following steps would be: > > - accept the current python3-defaults into > testing (adding 3.11 as supported) This has been done. > - ask for a transition slot to upload (see #1026825) > python3-defaults with 3.11 as the default We're currently waiting on the PHP 8.2 (#1014460) and qtbase-opensource-src (#1025863) transitions. Although, there's been no progress on PHP 8.2, so this may be reconsidered. qtbase-opensource-src is currently blocked on a pyqt5 FTBFS on mipsel (#1026980), but there is a possible workaround. We hope to be able to start with the remaining steps soon. > - start the no-change NMUs > - file bug reports. > - fix issues > - let 3.11 as default migrate to testing. > If things don't go as planned, we could default back to 3.10. Mostly that > would > be no-change uploads, however in the case of a 3.11 specific fix that doesn't > work for 3.10, these fixes would need reverting. I have no idea who many of > these we will introduce with this transition. OK, good to know we can still back out if we have to. > Also we might want to ask for some freeze exceptions for third party > libraries, > that we can't fix before the feature freeze, unfortunately at this point we > cannot say which and how many packages would be affected. The release team is prepared to consider these on a case-by-case basis. Regards Graham
Re: Python 3.11 for bookworm?
Hi Timo, Stefano On Thu, 22 Dec 2022 at 18:46, Stefano Rivera wrote: > > Hi Timo (2022.12.22_12:56:20_+) > > > There have been rebuilds in Ubuntu that give us some idea of how much > > > work remains. I think it's tractable, but also will have some package > > > casualties. > > I have some spare time right now, and I am happy to help > > work on problematic cases, so hopefully nobody will feel left out in > > the cold with their favorite packages. > > Offhand, the one I most expect trouble with is numba. We were reliant on > upstream for the 3.10 transition, and probably will be for 3.11. > > Thanks for your help with pony ORM, Timo. I didn't think we'd be able to > port that without upstream, but it did end up being tractable. > > I'm expecting to have more time in the upcoming weeks, too. > > So, release team, I still think we should go ahead! Thanks for committing your time to this, and for the fixes you've already uploaded (and to everyone else who has helped). Please let the release team know if you need things unstuck. Regards Graham
Bug#1026825: python3.11 as default
Hi Matthias On Wed, 21 Dec 2022 at 17:48, Matthias Klose wrote: > Please setup a transition window for python 3.11 as the default python3 > version. Python3-defaults with Python 3.11 as a supported version has now migrated to testing. Let's go ahead with this once PHP 8.2 (#1014460) and qtbase-opensource-src (#1025863) are done. Regards Graham
Bug#1026119: transition: matplotlib
Control: tags -1 + confirmed Hi Sandro On Sat, 24 Dec 2022 at 19:03, Sandro Tosi wrote: > All in all, i think this transition is rather manageable and i'd like > to upload to unstable, if you're ok with it. Please go ahead. Regards Graham
Bug#1025788: transition: numpy
Hi Sandro On Mon, 12 Dec 2022 at 23:27, Sandro Tosi wrote: > thanks, numpy/1.23.5-2 has just been uploaded to unstable. \o/ > thanks! on the same line, i'm planning on upgrading matplotlib > (another foundation package) from 3.5.x in unstable to 3.6.x (latest > upstream release). Do you want me to submit a transition bug report > when ready? Yes please. Filing it now would be even better, then additional information e.g. ETA, links to autopkgtest results, etc. can be added as it becomes available. Regards Graham
Bug#1025788: transition: numpy
Control: tags -1 + confirmed - moreinfo Hi Sandro On Sun, 11 Dec 2022 at 19:39, Sandro Tosi wrote: > numpy provides 2 virtual packages, to track the ABI/API version as > advertised by the upstream project. Between unstable and experimental, > we did not bump the ABI package (which stays at `python3-numpy-abi9`) > while we bumped the API package (from `python3-numpy-api14` to > `python3-numpy-api16`). > > In the past times we asked for a transition (f.e. #658289 or #616364), > we referred to the -abiXX package, but in this case we cannot rely on > it since it was not bumped. Since the ABI package python3-numpy-abi9 was not bumped, I don't believe any rebuilds are needed. Please go ahead and upload to unstable. > Was i just too conservative in asking for a transition slow while i > should have uploaded to unstable (as done several other times) and > handle the autopkgtests one by one? Although this is not a transition in the way a C library transition requires rebuilding all reverse-dependencies, a transition to a new Python module often requires updating reverse-dependencies, of which numpy has many, so it's good to bring these to the attention of the release team. Thanks for the headsup! Regards Graham
Re: Help with resolving an issue with wxwidgets3.2
Hi Scott On Wed, 16 Nov 2022 at 04:03, Scott Talbert wrote: > 2) Rebuild wxWidgets with soname bump and then rebuild all packages that > use wx (about 67 packages). > > What do you think is the best way to proceed? Option 2 seems the safest. Please upload to experimental and request another transition slot. Regards Graham
Bug#1021984: (some kind of) transition: add python3.11 as a supported python3 version
Hi Bas On Tue, 15 Nov 2022 at 09:15, Sebastiaan Couwenberg wrote: > Please also binNMU gdal & python-shapely in experimental: > > nmu gdal_3.6.0+dfsg-1~exp1 . ANY . experimental . -m "Rebuild with > Python 3.11 as supported" > nmu python-shapely_2.0~b2-1~exp1 . ANY . experimental . -m "Rebuild > with Python 3.11 as supported" Scheduled, thanks. Regards Graham
Bug#1021984: (some kind of) transition: add python3.11 as a supported python3 version
Control: tags -1 + confirmed Hi Matthias ICU has migrated. Please go ahead. Regards Graham
Re: Looking for help on transition workflow with package libevent
Hi Sebastian On Mon, 7 Nov 2022 at 08:58, Sebastian Ramacher wrote: > Is that really worth the effort for this one missing symbol? I'd just > make sure that is stays around regardless of glibc version. There was a patch proposed in the corresponding Ubuntu bug [1], re-introducing the symbol, however there was a concern from schopin (see comment #4): > This patch wouldn't work as intended, as we'd mix arc4random functions > from the vendored sources and from glibc, > each set having their own internal static data. A test rebuild of reverse-dependencies was done in Ubuntu, and the transition went ahead. Regards Graham [1] https://bugs.launchpad.net/debian/+source/libevent/+bug/1990941
Re: Looking for help on transition workflow with package libevent
Hi Nicholas On Sun, 6 Nov 2022 at 23:51, Nicolas Mora wrote: > I have a bug tagged serious in the package libevent I maintain [1], I've > been told the solution is to start a transition workflow. > > As mentioned in the transition doc [2], I uploaded the fixed package in > experimental, but I'm wondering what does "Check the auto-generated > "auto-"" mean. > Will my package appear on this list automatically or after I request a > transition slot from the release team? It should appear on the list automatically, but it won't because the libevent-2.1-7 package name did not change. I suggest that you follow what Ubuntu did [3] and bump the SONAME and package name for this transition. > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023284 > [2] https://wiki.debian.org/Teams/ReleaseTeam/Transitions Regards Graham [3] https://launchpad.net/ubuntu/+source/libevent/2.1.12-stable-5ubuntu1
Bug#1021984: (some kind of) transition: add python3.11 as a supported python3 version
Control: forwarded -1 https://deb.li/3Kf4j Hi Matthias On Tue, 18 Oct 2022 at 12:18, Matthias Klose wrote: > Please setup a tracker to add python3.11 as a supported python3 version. This > is > non-blocking, as packages can migrate on their own once built. I'm not yet > starting this, just want to have an overview of affected packages. > > Please re-use the final version of the python3.9 tracker (#996584). The tracker is up: https://release.debian.org/transitions/html/python3.11-add.html > The upstream release in on time again, so we should be prepared to start this > addition after the upstream release end of October. \o/ Regards Graham
Re: libpmix2: symbol lookup error: /usr/lib/x86_64-linux-gnu/openmpi/lib/openmpi3/mca_pmix_ext3x.so: undefined symbol: pmix_value_load
Hi Tobi On Wed, 24 Aug 2022 at 11:42, Tobias Frost wrote: > Maybe it would be a good idea to revert pmix to 4.1.2 ? (e.g > pmix-4.2.0+really-4.1.2-1) be uploaded and then > do a proper transistion? That would be appreciated by the release team. Regards Graham
Bug#1015254: transition: opencascade
Hi Tobi On Sat, 6 Aug 2022 at 18:51, Tobias Frost wrote: > I'd suggest to start binNMU freecad freecad is not in testing, and requires a source-only upload because of the arch:all binaries uploaded by the last uploader. Also, #1007013 and #1014875 need fixing. > and maybe then proceed to remove netgen together with gmsh and deal.ii > temporarily from testing. > (the later two need an updated netgen…) deal.ii was removed from testing due to a collision with glibc 2.34. There are some reverse dependencies of netgen and gmsh, so I'd prefer to wait for auto-removal, and hopefully one of those maintainers steps up with a fix for netgen in the meantime. Regards Graham
Bug#1015254: transition: opencascade
Control: tags -1 confirmed Hi Tobi On Sun, 31 Jul 2022 at 16:51, Tobias Frost wrote: > I've uploading 7.6.3 right now to experimental; as I removed the confirmed > tag, please reACK > the "go ahead" -- I've tested that all r-depends that worked before are still > compiling reACK Regards Graham
Bug#1015270: transition: nodejs
Control: tags -1 confirmed Hi Jérémy On Mon, 18 Jul 2022 at 19:09, Jérémy Lal wrote: > nodejs 18.6.0 will soon be the active version of nodejs: > https://nodejs.org/en/about/releases/ > > I rebuilt and checked all reverse-build-deps of libnode-dev/nodejs, > and dealt with most of the regressions, or opened bugs proposing a solution. Please go ahead with the upload to unstable. Regards Graham
Bug#1015254: transition: opencascade
Control: tags -1 confirmed Hi Tobi On Mon, 18 Jul 2022 at 14:30, Tobias Frost wrote: > opencascade has a new release with bumps so name to 7.6 The transition > tracker [1] > correctly picked it up already after the upload to experimental. Please go ahead with the upload to unstable. Regards Graham
Arch qualification for bookworm: call for DSA, Security, toolchain concerns
Hi, As part of the interim architecture qualification for bookworm, we request that DSA, the security team, Wanna build, and the toolchain maintainers review and update their list of known concerns for bookworm release architectures. If the issues and concerns from you or your team are not up to date, then please follow up to this email (keeping debian-release@l.d.o in CC to ensure we are notified). In particular, we would like to hear any new concerns for riscv64 (see below). Whilst porters remain ultimately responsible for ensuring the architectures are ready for release, we do expect that you / your team are willing to assist with clarifications of the concerns and to apply patches/changes in a timely manner to resolve the concerns. List of concerns for architectures == The following is a summary from the current architecture qualification table [1]. * Concern for ppc64el and s390x: we are dependent on sponsors for hardware. (Raised by DSA; carried over since stretch) * Concern for armel and armhf: glibc upstream has trouble finding qualified persons to implement security fixes for the 32-bit Arm architectures. (Raised by glibc upstream; carried over from bullseye) * Concern for armel: might be special because the use of the libatomics library is mandatory. (Raised by the GCC maintainer; carried over from bullseye) * Concern for mips64el and mipsel: no upstream support in GCC; Debian carries patches in binutils and GCC that haven't been integrated upstream even after a long time. Unaddressed test failures in binutils. (Raised by the GCC maintainer; carried over from bullseye) * Concern for mips64el and mipsel: builders are extremely slow. (Raised by kernel team; carried over from bullseye) * Concern for arm*, i386, mips* and ppc64el: only one porter has volunteered for each of these architectures. (Raised by release team) * Concerns for mips64el and mipsel: builders are slow and hold up transitions, lack of autopkgtest infrastructure, future availability of hardware due to MIPS (the company) pivoting to RISC-V [2]. (Raised by release team) * Concern for 32-bit architectures (armel, armhf, i386 and mipsel): some builds are hitting the address space limit on these architectures. (Raised by release team) Architecture status === These are the architectures currently being built for bookworm: * Intel/AMD-based: amd64, i386 * ARM-based: arm64, armel, armhf * MIPS-based: mipsel, mips64el * Other: ppc64el, s390x If the blocking issues cannot be resolved, affected architectures are at risk of removal from testing before bookworm is frozen. We are aware of efforts to have riscv64 ready in time for inclusion in bookworm. On behalf of the release team, Graham Inggs [1] https://release.debian.org/bookworm/arch_qualify.html [2] https://riscv.org/blog/2022/05/mips-pivots-to-risc-v-with-best-in-class-performance-and-scalability-mips/
Bug#1007222: transition: onetbb
Hi I've noticed some binNMUs failed on armel; mathicgb [1] (subsequently fixed by maintainer upload) and r-cran-rcppparallel [2]. Both seem to fail in a similar way: /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so: undefined reference to `__atomic_fetch_sub_8' /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so: undefined reference to `__atomic_load_8' call: dyn.load(path, local = FALSE, now = TRUE) error: unable to load shared object '/usr/lib/arm-linux-gnueabi/libtbb.so': /usr/lib/arm-linux-gnueabi/libtbb.so: undefined symbol: __atomic_fetch_sub_8 I also noticed the following in the armel build of onetbb [3]: dpkg-shlibdeps: warning: symbol __atomic_fetch_sub_8 used by debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none of the libraries dpkg-shlibdeps: warning: symbol __atomic_load_8 used by debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none of the libraries dpkg-shlibdeps: warning: symbol __atomic_fetch_add_8 used by debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none of the libraries Is this something that can/should be fixed in onetbb, or should this be fixed in the reverse-dependencies? Additionally, r-cran-rcppparallel failed on mipsel [4] and mips64el [5] with the following: /usr/bin/ld: cannot find -ltbbmalloc: No such file or directory collect2: error: ld returned 1 exit status This seems related to #102 [6]. What needs to happen here? Regards Graham [1] https://buildd.debian.org/status/logs.php?pkg=mathicgb=armel [2] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel=armel [3] https://buildd.debian.org/status/fetch.php?pkg=onetbb=armel=2021.5.0-10=1655112619=0 [4] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel=mipsel [5] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel=mips64el [6] https://bugs.debian.org/102
Bug#1007222: transition: onetbb
Control: tags -1 + confirmed - moreinfo Hi On Tue, 7 Jun 2022 at 18:39, Andrius Merkys wrote: > In the meantime I am test-rebuilding plastimatch, now unblocked by > #1005485. There you will hit #1012439, but plastimatch is now no longer in testing. Please go ahead with the upload of onetbb to unstable. Regards Graham
Bug#1007222: transition: onetbb
Hi Andrius Thanks for your work on this. My comments below are inlined. On Fri, 3 Jun 2022 at 09:06, Andrius Merkys wrote: > Unrelated FTBFS > === > > freeture - not in testing > gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html > kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html > limereg - not in testing > madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html > mldemos - not in testing > mpqc3 - not in testing > numba - not in testing > olive-editor - not in testing > opencolorio - not in testing > php-facedetect - not in testing > pigx-rnaseq - not in testing > pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html > plastimatch - #1005485 > pytorch-audio - not in testing > pytorch-text - not in testing > pytorch-vision - not in testing > trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html > > Unsatisfiable dependencies > == > > hyperspy - not in testing > poliastro - not in testing > pynpoint - not in testing > python-cogent - not in testing > python-epimodels - not in testing > python-fluids - not in testing > python-loompy - not in testing > python-numpy-groupies - not in testing > python-pynndescent - not in testing > python-sparse - not in testing > sfepy - not in testing > tiledarray - not in testing > umap-learn - not in testing > > Is this enough to remove 'moreinfo'? We can ignore everything that's not in testing, but please do look again at those marked 'Unrelated FTBFS' where I have placed a link to reproducible builds where they do not FTBFS. Regards Graham
Bug#1007222: transition: onetbb
Hi On Thu, 2 Jun 2022 at 03:11, M. Zhou wrote: > I personally dislike making the old package libtbb2-dev. > How about we make the old src:tbb package go through NEW again > with the following renames: > > libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev > because it explains itself to be a to-be-deprecated version. I personally don't like tbb-legacy-dev. It's not common in the archive for a -dev package. Most are unversioned, otherwise they match the library package, so libtbb2-dev for libtbb2. See e.g. lmsensors-dev, lmsensors4-dev, libpcre2-dev, libpcre3-dev, libvtk7-dev and libvtk9-dev, etc. Explanations can go in the package description, e.g. from libpcre3-dev "New packages should use the newer pcre2 packages, and existing packages should migrate to pcre2". > In this way we can finish the transition very quickly and leave > longer time for broken packages to migrate to onetbb. > > For me, submitting patches is as well much easier as I only have to > change libtbb-dev -> libtbb-legacy-dev for broken packages. Changing libtbb-dev -> libtbb2-dev should be even easier :). However, we don't **have** to reintroduce the old tbb package, and **you** don't have to be the one maintaining it. If all the packages that FTBFS with the new tbb can be removed from testing, the old tbb can be reintroduced after the transition, by some maintainers who wish to care for it. Regards Graham
Bug#1012299: RM: src:ruby-uglifier/2.7.2+dfsg-2
Control: tags -1 + moreinfo Hi Pirate On Fri, 3 Jun 2022 at 10:06, Pirate Praveen wrote: > Please remove ruby-uglifier from testing to allow migration of > node-source-map to testing. This regression was introduced by webpack 5 in > testing. > > rails no longer build depend on ruby-uglifier. > > ruby-uglifier should be removed from archive eventually. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981224 > > https://lists.debian.org/debian-ruby/2022/06/msg0.html This should wait until the following build-dependencies in testing have been resolved: $ reverse-depends -b -r testing src:ruby-uglifier Reverse-Build-Depends * nanoc (for ruby-uglifier) * rails (for ruby-uglifier) * ruby-sprockets(for ruby-uglifier) * ruby-sprockets-rails (for ruby-uglifier) Regards Graham
Bug#1007222: transition: onetbb
Control: tags -1 + moreinfo Hi I noticed some packages in the tracker not appearing in your list; e.g. openimageio, pcl and yade. These packages have transitive build-dependencies on libtbb-dev through e.g. libopenvdb-dev or libvtk9-dev, and should be investigated as well. Note that we will require fixes, or at least patches, for "key packages" [1] before starting with this transition, and at least trilinos is currently on that list. It may be worth considering again Matthias' suggestion in #1006920 to keep the old tbb package around as libtbb2-dev and libtbb2-doc in order to allow packages like numba to get the new tbb soon, and other packages stuck with the old tbb more time to get fixed. Regards Graham [1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
Bug#1012208: unblock: python-pytest-asyncio/0.18.2-1
Hi Julian On Wed, 1 Jun 2022 at 12:03, Julian Gilbey wrote: > [ Reason ] > python-pytest-asyncio and pytest-mock need to be upgraded together; > pytest-mock 3.7.0-2 build-depends on the newer version of > python-pytest-asyncio (0.18.2-1), while the older version of > pytest-mock (3.6.1-1) breaks with it. It seems to me that python3-pytest-asyncio misses an appropriate Breaks on python3-pytest-mock then. Regards Graham
