Bug#1061179: Bug#1060019: transition: poppler 24.02
Control: tags -1 confirmed On 2024-05-20 18:23:10 +0300, Dmitry Shachnev wrote: > Hi, > > On Thu, May 16, 2024 at 01:25:56PM +0200, Jeremy Bícha wrote: > > libpoppler134 has migrated to Testing and I don't see libpoppler126 > > there any more so I'm closing the poppler transition bug. > > FWIW, I am waiting for a formal "tags -1 confirmed" from Sebastian. Please go ahead Cheers -- Sebastian Ramacher
Bug#1067064: transition: petsc hypre
Control: tags -1 confirmed Hi On 2024-03-17 22:52:51 +0100, Drew Parsons wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: pe...@packages.debian.org, francesco.balla...@unicatt.it > Control: affects -1 + src:petsc > User: release.debian@packages.debian.org > Usertags: transition > > The petsc patch for the 64-bit time_t transition was deeply invasive. > It makes petsc (and slepc) essentially unmaintainable. > > I think the best way to deal with it is to pretend it never happened > and move on with petsc 3.20, upgrading from petsc 3.19. We'd want to > doing this upgrade anyway. Please go ahead. While looking at the tracker, I noticed that petsc is still building manual -dbg packages. IS there a reason that those have not been converted to automatic -dbgsym packages? Cheers -- Sebastian Ramacher
Bug#1061179: transition: qtbase-abi-5-15-12
Control: block -1 by 1060019 On 2024-01-20 13:47:18 +0300, Dmitry Shachnev wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: block -1 by 1060761 1060802 > > Dear Release team, > > I have skipped Qt 5.15.11 release and would like to upgrade to 5.15.12 > which was published in December. Qt WebEngine will be upgraded from 5.15.15 > to 5.15.16. The transition is prepared in experimental. Let's do this one after poppler migrated. Cheers -- Sebastian Ramacher
Bug#1071065: transition: libsecp256k1
Control: tags -1 confirmed On 2024-05-13 19:59:30 +0200, Bastian Germann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: affects -1 + src:libsecp256k1 > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-libsecp256k1.html > > Hi, > > I request a transition slot from libsecp256k1-1 to libsecp256k1-2. > The auto-generated tracker is okay. All reverse dependencies in sid build > with the experimental libsecp256k1. Please go ahead Cheers -- Sebastian Ramacher
Bug#1067842: transition: octave-9
Control: forwarded -1 https://release.debian.org/transitions/html/octave-59.html Control: block -1 by 1065309 On 2024-03-27 14:26:42 +0100, Sébastien Villemot wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: debian-oct...@lists.debian.org > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > Please schedule a transition for the latest major upstream version of Octave, > version 9. All the arch:any Octave addons need to be rebuild. > > Octave 9 has already been uploaded to experimental. > > A rebuild of all the packages affected by the transition has been performed. > Several problems were fixed, and to the best of our knowledge, all packages > are > ready. We stand ready to upload and NMU as needed if other issues arise. plplot is involved in the gnat and octave transitions. So let's do this one after gnat is done. Cheers -- Sebastian Ramacher
Bug#1063516: transition: pcl
Control: tags -1 confirmed On 2024-02-09 11:40:46 +0100, Jochen Sprickerhof wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: p...@packages.debian.org > Control: affects -1 + src:pcl > > Hi release team, > > I would like to transition to the new pcl version. The auto generated > ben file looks fine and the reverse build dependency builds fine. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1062761: transition: libfm-qt
Control: tags -1 confirmed On 2024-02-03 09:57:00 +0800, ChangZhuo Chen wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: libfm...@packages.debian.org > Control: affects -1 + src:libfm-qt > > libfm-qt has bumped its soversion from 13 to 14, so we need a > transition. > > All affected packages listed in > https://release.debian.org/transitions/html/auto-libfm-qt.html > are good in experimental. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1062666: transition: openmm
Control: tags -1 confirmed On 2024-02-02 16:57:16 +0200, Andrius Merkys wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hello, > > I would like to request a transition slot for openmm > (experimental -> unstable) due to soname bump. Current ben tracker [1] > is OK. > > All reverse dependencies rebuild fine, except for cpptraj which is not in > testing. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1070462: transition: evolution-data-server 3.52
Control: tags -1 confirmed On 2024-05-05 13:00:06 -0400, Jeremy Bícha wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: evolution-data-ser...@packages.debain.org > > One of the evolution-data-server libraries had a soname bump. I > believe everything should be binNMUable without issue. Please go ahead Cheers -- Sebastian Ramacher
Bug#1070043: transition: wireplumber 0.5
Control: tags -1 confirmed On 2024-04-29 11:16:46 +0200, Dylan Aïssi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: affects -1 + src:wireplumber > > Dear Release Team, > > Please schedule a transition slot for wireplumber 0.5. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1070321: transition: nginx ABI change: nginx-abi-1.24.0-1 -> nginx-abi-1.26.0-1
Control: tags -1 confirmed On 2024-05-03 19:08:58 +0200, Jan Mojzis wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: ng...@packages.debian.org > Control: affects -1 + src:nginx > > Hi, > > a new version 1.26.0 of nginx has been released. > > I have uploaded version 1.26.0-1~exp1 to the experimental and > would like to upload the new nginx 1.26.0-1 version to the unstable. > > And with the upload of 1.26.0-1 nginx to unstable, > the nginx ABI version changes at the same time. Previous ABI > nginx-abi-1.24.0-1, new ABI nginx-abi-1.26.0-1. > > Therefore, we would also need to rebuild all 3rd party nginx modules > (libnginx-mod-* packages) > which depends on nginx. Hence the transition request. > > Furthermore, this upload/rebuild solves the problem that arises at time_t 64 > transition: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069997 Please go ahead. Cheers -- Sebastian Ramacher
Bug#1069919: transition: kimageannotator
Control: tags -1 confirmed On 2024-04-26 23:51:19 -0400, Boyuan Yang wrote: > Package: release.debian.org > Control: affects -1 + src:kimageannotator > X-Debbugs-Cc: kimageannota...@packages.debian.org couc...@debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: by...@debian.org > Severity: normal > > I would like to initiate the following listed transitions together > since they are tightly bundled together: > > * https://release.debian.org/transitions/html/auto-kimageannotator.html > * https://release.debian.org/transitions/html/auto-kcolorpicker.html Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055755: transition: libre/rem/baresip
Control: tags -1 confirmed On 2024-04-12 21:29:09 +0200, Bastian Germann wrote: > Control: tags -1 - moreinfo > > On Fri, 10 Nov 2023 22:34:49 +0100 Sebastian Ramacher > wrote: > > Did you coordinate this plan with the maintainer of libre? > > I am now part of the maintaining team and confirm my request. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1069700: transition: rpm
Control: tags -1 confirmed On 2024-04-23 01:59:12 +0100, Luca Boccassi wrote: > Package: release.debian.org > Control: affects -1 + src:rpm > X-Debbugs-Cc: team+pkg-...@tracker.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Dear Release Team, > > A new RPM version is available and has been uploaded and accepted in > experimental as version 4.19.1.1+dfsg-1~exp, and it introduces an ABI > bump from soname version 9 to 10 for the library packages shipped from > src:rpm. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1063770: transition: mupdf
control: tags -1 moreinfo On 2024-02-12 23:30:58 +0900, Kan-Ru Chen wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: mu...@packages.debian.org, pymu...@packages.debian.org, > sio...@packages.debian.org, ippsam...@packages.debian.org > Control: affects -1 + src:mupdf > User: release.debian@packages.debian.org > Usertags: transition > > Hi Release Team, > > This is a somewhat unusual transition request. The libmupdf-dev package > used to only ship static library archives due to upstream preference. > Recently upstream started to provide makefiles for building shared library > so I think it's time to ship shared library in Debian. > > I've uploaded the new version to experimental (binary package libmupdf23.10) > and tried to build the affected reverse build-deps (Cc'ed). > > ippsample - doesn't seem to use mupdf at all > pymupdf - requires some changes. Likely also needs to update to new upstream > version. > sioyek - requires some changes to drop extra linker flags. Have bugs been filed for these issues? Cheers -- Sebastian Ramacher
Bug#1061267: transition: unixcw
control: tags -1 confirmed On 2024-01-21 11:21:03 -0800, tony mancill wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: uni...@packages.debian.org > Control: affects -1 + src:unixcw > > Dear Release Team, > > I am requesting a transition for unixcw [1]. The one reverse > dependency, cwdaemon, builds correctly against the package in > experimental. The auto-transition page is [2]. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1064810: transition: mpi-defaults
On 2024-05-05 17:59:40 +0200, Sebastiaan Couwenberg wrote: > On 2/26/24 7:40 AM, Alastair McKinstry wrote: > > OpenMPI 5.0 drops 32-bit support, so we need to move those archs to MPICH. > > This transition is blocking many of the remaining packages rebuilt for > 64-bit time_t. > > The autopkgtest for slurm-wlm on i386 is blocking testing migration of > mpich: > > https://qa.debian.org/excuses.php?package=mpich > > Testing migration of openmpi is likewise blocked by autopkgtest failures on > i386 of several rdeps: > > https://qa.debian.org/excuses.php?package=openmpi > > I'm starting to think that it'd be better to drop support for 32bit > architectures from all these rdeps so they can just use openmpi everywhere > and not have i386 autopkgtest failures able to block testing migration. openmpi should migrate with the next britney run. After that we can look into starting the transition to change mpi-defaults on 32 bit architctures. That is currently https://release.debian.org/transitions/html/mpi-defaults.html This will also require changes to hdf5. Have they been prepared somewhere? Cheers -- Sebastian Ramacher
Bug#1061515: transition: ace
Control: tags -1 confirmed On 2024-01-25 19:47:27 +, Sudip Mukherjee wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: sudipm.mukher...@gmail.com > Control: affects -1 + src:ace > > > Hi, > > Small transition with only two affected packages: diagnostics, ivtools, > Both of them builds fine with ace 7.1.3+dfsg-1 in experimental. > > The autogenerated ben tracker looks good. Please consider 'ace' for > transition. > Thanks in advance. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)
On 2024-04-30 15:44:51 +0100, Simon McVittie wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: coreut...@packages.debian.org, p...@packages.debian.org, > debian-b...@lists.debian.org > Control: affects -1 + src:coreutils src:pam > > coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie > for whatever reason. Because debootstrap doesn't currently know about > versioned Provides, I think it would be useful to get versions of these > packages in trixie that have been rebuilt against the 64-bit time_t ABIs > and package names. > > If the versions in trixie don't migrate imminently, please consider: > > nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64" > nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64" > > In a trixie derivative (a non-public future branch of the Steam Runtime) > I found that local rebuilds of those two source packages were enough to > bring a minbase debootstrap back from repeatably failing to reasonably > reliable. I hope they would have a similar effect in real trixie. > > Based on kibi's thread "Making trixie debootstrap-able again?" on -release > and -boot, binNMUing util-linux and iproute2 might also help for d-i's > use-case, which is larger than minbase and wants fdisk and iproute2: > > nmu util-linux_2.39.3-6 . ANY . trixie . -m "rebuild against libreadline8t64" > nmu iproute2_6.7.0-2 . ANY . trixie . -m "rebuild against libtirpc3t64" > > but I have not independently verified that those two are necessary > or sufficient. The packages would be ready to migrate to trixie, but migrating them makes britney crash. I don't expect that to change when we rebuild the packages in trixie. Cheers -- Sebastian Ramacher
Re: Making trixie debootstrap-able again?
Hi we've been made aware on #d-release that my hints broke debootstrap. I am working through the remaining packages that are relevant for debootstrap, but it takes some time. On 2024-04-26 18:35:59 +0200, Cyril Brulebois wrote: > I'm not sure how we reached this situation but there are a bunch of > packages in trixie that are not in a suitable state. To reproduce, a > simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient. > > Note: I've limited my exploration to amd64, which kept me busy already… > > An obvious first problem is coreutils, which picked a Pre-Depends on > libssl3 (not the t64 one), which… disappeared from testing between the > 2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at > Packages.gz for amd64 via snapshot.debian.org). The core problem is that deboostrap fails to understand versioned Provides. libssl3t64 on amd64: Package: libssl3t64 Source: openssl Version: 3.2.1-3 Installed-Size: 7302 Maintainer: Debian OpenSSL Team Architecture: amd64 Replaces: libssl3 Provides: libssl3 (= 3.2.1-3) Depends: libc6 (>= 2.34), libzstd1 (>= 1.5.5), zlib1g (>= 1:1.1.4) Breaks: libssl3 (<< 3.2.1-3), openssh-client (<< 1:9.4p1), openssh-server (<< 1:9.4p1), python3-m2crypto (<< 0.38.0-4) Description-en: Secure Sockets Layer toolkit - shared libraries This package is part of the OpenSSL project's implementation of the SSL and TLS cryptographic protocols for secure communication over the Internet. . It provides the libssl and libcrypto shared libraries. Description-md5: 88547c6206c7fbc4fcc7d09ce100d210 Multi-Arch: same Homepage: https://www.openssl.org/ Section: libs Priority: optional Filename: pool/main/o/openssl/libssl3t64_3.2.1-3_amd64.deb Size: 2243528 MD5sum: 8919d70ec8be690308f3970878113b1a SHA256: 84bf4abab84da9c8a2bdd2b161ae02d4de78657fe77483bf7656d8a368344add So that britney dropped libssl3 from testing on !armel !armhf is fine in genaral, but britney does not account for deboostrap not supporting versioned Provides. That's the same for all the other packages involved in bootstraping. > Again, I have absolutely no clue regarding the best course of action at > this point. I can't even perform clean builds to check what a binNMU in > testing would look like, as I can't debootstrap a clean environment (and > therefore only tested rebuilds in an existing, devel-oriented, unclean > trixie chroot). I am currently looking into making coreutils and systemd (which needs glib2.0) migrate. I hope to have it back in a debootstrapable-step after the weekend. If you are aware of more apckages that need help, please let us know. Cheers -- Sebastian Ramacher
Re: Status of the t64 transition
Hi, dpkg and gcc with t64 enabled migrated to trixie last night. The other packages will slowly migrate as we fix the remaining blockers (autopkgtest regressions, FTBFS bugs, etc). Be aware that temporary removals from trixie may occur to get packages (especially key packages) unstuck as we work through all the packages hat need to migrate. Since the time_t bugs are now also RC in trixie, I will reraise the severity of all time_t bugs to serious in 1 week. If you wonder how you are able to help with the migration, here are some things to do: * Fix FTBFS bugs * Check the status of autopkgtests [1] and report or fix any issues related to failing tests. * Check if source-only uploads for Arch: all packages are missing. Cheers [1] Note that wecurrently ignore autopkgtest results on armel and armhf. -- Sebastian Ramacher
Re: Status of the t64 transition
Hi Andreas, please stop reopening the time_t bugs where transitions are staged in experimental. When we eventually start those transitions, they do not need to change the package name again as they will enter unstable with a new SONAME and built with the 64 bit time_t ABI. Cheers -- Sebastian Ramacher
Bug#1056574: transition: ppp
Control: tags -1 confirmed On 2024-04-19 17:11:44 +0100, Chris Boot wrote: > On 26/11/2023 11:36, Chris Boot wrote: > > On 26/11/2023 10:56, Chris Boot wrote: > > > > Any way to reduce possible breakage, or to detect and fix it > > > > before the transition starts? Like rebuilding rdeps, or checking > > > > rdep autopkgtests? > > > > > > I'll go an do some rebuilds now and see how they go. If any breakage > > > occurs it will be obvious at build time. > > > > The status of the rdeps (list taken from the tracker): > > > > connman: OK > > network-manager: OK > > pptpd: https://bugs.debian.org/1056898 > > sstp-client: https://bugs.debian.org/1056900 > > > > network-manager-fortisslvpn: https://bugs.debian.org/1056901 > > network-manager-l2tp: OK > > network-manager-pptp: OK > > network-manager-sstp: https://bugs.debian.org/1056903 > > All that's left now is pptpd (with an offer from Christoph to upload when > ready) and network-manager-fortisslvpn (with commits fixing the issues > upstream, but no upstream release). > > In the mean time, #1065940 has become a blocker for the time_t transition. I > think I'd rather upload 2.5.0 and break network-manager-fortisslvpn than > just the patch to fix the breakage. > > Would the release team be happy to continue with this transition? Please go ahead with the upload to unsable. Cheers -- Sebastian Ramacher
Re: Status of the t64 transition
Hi Andreas On 2024-04-19 10:49:15 +0200, Andreas Tille wrote: > I've spotted these Debian Med packages. > > > gentle gentle required a rebuild for wxwidgets3.2 on mips64el. Done > > jellyfish The t64 changes were reverted. crac needs to rebuilt for this change so that libjellyfish-2.0-2t64 can be decrufted. I've scheduled binNMUs and excluded from further checks. > > quorum With jellyfish reverted, this one is fine. > > sbmltoolbox Builds an arch: all package with a dependency on a pre-t64 library. This will need an upload fixing this issue. > > vg > > This package is in a bad state in any case and we are aware of this. > However, could you explain in how far is this affecting t64 transition > since 32bit architectures are excluded? As said in my initial mail, I didn't exclude packages that are not part of testing. Patches welcome. Cheers -- Sebastian Ramacher
Re: Status of the t64 transition
On 2024-04-19 06:02:03 +0200, Andreas Metzler wrote: > On 2024-04-18 Sebastian Ramacher wrote: > [...] > > Let's start with the first category. Those are packages that could be > > binNMUed, but there are issues that make those rebuilds not have the > > desired effect. This list include packages that > > * are BD-Uninstallabe, > > * FTBFS but with out ftbfs-tagged RC bug, > > * have hard-coded dependencies on pre-t64 libraries, > > * have $oldlib | $newlib dependencies (those are at least wrong on > >armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are > >decrufted), > > * have been rebuilt before all dependencies were built, > > * have broken symbols/shlibs files producing incorrect dependencies, > > * or might just be missing the binNMU (but those should be few). > > > hugin > [...] > > Good morning, > > thanks for the update. > > Looking at hugin, I think it is fine on all release-architectures, none > of the problems noted above apply here. Am I missing something? It required rebuilds for wxwidgets3.2 on mips64el: INFO Rebuilding src:hugin/2023.0.0+dfsg-1 (hugin) for libwxbase3.2-1 on mips64el INFO Rebuilding src:hugin/2023.0.0+dfsg-1 (hugin-tools) for libwxbase3.2-1 on mips64el They were scheduled last night and now hugin is fine. Thanks for double checking. > PS: fakeroot seems to be an important blocker not in the list. The lists in my mail only contain those packages that require changes to their dependencies due to the library package renames. So everything on these lists depends on foo, but should depend on foot64 [1]. fakeroot only depends on packages that are not involved in the t64 transition. Cheers [1] And some other variations including previous ABI transitions such as v5, etc: https://github.com/sebastinas/drt-tools/blob/main/src/nmu_t64.rs#L75 -- Sebastian Ramacher
Status of the t64 transition
Hi, as the progress on the t64 transition is slowing down, I want to give an overview of some of the remaining blockers that we need to tackle to get it unstuck. I tried to identify some clusters of issues, but there might be other classes of issues. Let's start with the first category. Those are packages that could be binNMUed, but there are issues that make those rebuilds not have the desired effect. This list include packages that * are BD-Uninstallabe, * FTBFS but with out ftbfs-tagged RC bug, * have hard-coded dependencies on pre-t64 libraries, * have $oldlib | $newlib dependencies (those are at least wrong on armel/armhf and violate policy 2.2.1 once the pre-t64 libraries are decrufted), * have been rebuilt before all dependencies were built, * have broken symbols/shlibs files producing incorrect dependencies, * or might just be missing the binNMU (but those should be few). 3depict arctica-greeter cegui-mk2 condor courier deepin-movie-reborn fastnetmon fcitx-kkc gentle gnome-subtitles gocryptfs gozer gtk-chtheme gvmd gxneur haskell-gi-dbusmenugtk3 haskell-gi-gtk haskell-gi-gtk-hs haskell-gi-vte haskell-gtk-strut hkl hugin hxtools ibus-kkc ippsample jellyfish jskeus lcmaps-plugins-basic lcmaps-plugins-jobrep lcmaps-plugins-verify-proxy lcmaps-plugins-voms libcanberra libosmo-netif lightdm lightdm-gtk-greeter light-locker limesuite llvm-toolchain-17 lmms lyskom-server massxpert2 nautilus-wipe ncl nfs-ganesha obs-advanced-scene-switcher openjdk-20 perdition ppp prads prelude-lml prelude-manager purple-xmpp-carbons purple-xmpp-http-upload python-escript qt5-ukui-platformtheme quorum renpy roger-router rtags sdpa seafile-client slick-greeter sonic-visualiser spectrwm spice-gtk swtpm tfortune thunderbird trantor ui-gxmlcpp ukui-greeter urfkill vdeplug-pcap vdeplug-slirp wine-development worker xbase64 xca Next, packages that need an upload since they build Architecture: all binaries depending on pre-t64 libraries: alsa-ucm-conf anki clearlooks-phenix-theme gtk-sharp3 jruby mandos python-pylibdmtx pyzbar rapid-photo-downloader ruby-ethon ruby-ffi-libarchive sbmltoolbox syncevolution Finally, packages that need rebuilds but currently have open FTBFS (RC + ftbfs tag) bugs: 3dchess ace-of-penguins acm adns adonthell alsa-oss amberol anfo arrayfire audtty barrier blasr boinc-app-eah-brp broker caml-crush cctools clanlib clazy clickhouse code-saturne coz-profiler cp2k cpdb-backend-cups cpm criu curlftpfs dapl darcs das-watchdog deepin-log-viewer dnstop dolphin-emu dradio dub dune-pdelab dvbstreamer dx ecere-sdk elektra epic4 epic5 eterm filament freebayes freebsd-buildutils gabedit gamazons ganeti gdis ggcov ghdl ghemical giblib gigedit glirc gnat-gps gnome-breakout gnome-photos gnunet-gtk google-compute-engine-oslogin grok gsocket gtk-sharp3 gtkterm gwc gyoto hardinfo hping3 hplip httest i2masschroq ibus-anthy info-beamer intel-hdcp irssi-plugin-robustirc isoquery kamailio kbtin kcov kdrill kexec-tools keynav klatexformula kluppe kpatch kraptor kwin-effect-xrdesktop ldapvi lftp libaws libengine-gost-openssl libgovirt libkkc libnginx-mod-http-modsecurity liboqs librm libvma libzorpll lief linssid lintian-brush linuxtv-dvb-apps literki lives llvm-toolchain-16 lmemory lnav loqui lsh-utils mahimahi maildrop matchbox-keyboard matchbox-panel mate-equake-applet mathgl mdbtools mdk4 mit-scheme mldemos mlpcap mod-gnutls moonshot-ui mozillavpn mpqc3 ncrack netdiag newsboat nitrokey-app nng ntopng obs-ashmanix-countdown obs-downstream-keyer obs-ptz obs-scene-notes-dock obs-websocket octave-mpi openems openexr-viewers openjdk-19 openmx opensta openturns openvas-scanner ortools performous-composer pesign pidgin-sipe pixmap pngphoon porg projecteur purify purple-lurch pxe-kexec pyferret pygame-sdl2 pytorch-vision qstopmotion raku-readline ramond rdup recutils regina-normal resvg rmlint ruby3.2 ruby-fcgi ruby-ruby-magic-static ruby-sigar s390-tools sagemath samhain scm scrollz sdaps searchmonkey siconos siridb-server sitecopy slapi-nis slrn sniffit snort spek spotlighter squeak-plugins-scratch stimfit subvertpy supertuxkart swift-im syrthes tcptrack telegram-purple termrec thin-provisioning-tools threadscope tightvnc tlog uhub urweb vart vecgeom veusz vg virtualjaguar whitedune wmweather+ xbill xcolmix xir xneur xpat2 xpra xqilla xrt xshogi xtide yap yrmcds zabbix zeek Note that not all of the packages listed above have bugs filed. Also, the list is produced based on the state in unstable. Packages that were already removed from testing are also on these lists. If you maintain any of the packages above, please check their status and help get them fixed. Any help in filing bugs, fixing packages, requesting removals, etc. is appreciated so that we can look into unblocking the whole stack and migrate it to testing. The dd-list of the packages above is attached. Cheers -- Sebastian Ramacher A Mennucc1 dvbstreamer Adam Borowski kbtin termrec Adrian Knoth qstopmotion (U) Agathe Porte
Bug#1068961: llvm-toolchain-18: block migration to testing: to many llvm-toolchain versions in testing
Source: llvm-toolchain-18
Version: 1:18.1.3-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org, debian-release@lists.debian.org
Currently we we have llvm-toolchain-{14,15,16,17} in testing whereas RC
bugs in the verious versions of llvm-toolchain do not get addressed:
#1067005 in llvm-toolchain-18
#1068185 and #1057586 in llvm-toolchain-16
#1036596 and #1068840 in llvm-toolchain-14
Seeing that some of the bugs are unaddressed for a long time, that many
versions of llvm-toolchain in the archive seem to be to much to handle
for the maintainers. As there is also no progress in removing old
versions from the archive, I propose to not let any new versions of
llvm-toolchain-X migrate to trixie until the number of versions is
reduced to a maintainable number.
Please do not downgrade or close this bug report before contacting the
release team.
Cheers
--
Sebastian Ramacher
Bug#1068366: nmu: gyoto_2.0.2-1.1
Control: tags -1 moreinfo On 2024-04-04 09:27:06 +0100, plugwash wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > It seems that the new version of gyoto was built a bit too early and, on most > architectures, picked up a dependency on libcfitsio10 rather than > libcfitsio10t64. > > nmu gyoto_2.0.2-1.1 . ANY . unstable . -m "Rebuild against libcfitsio10t64 > for time64 transition." gyoto currently FTBFS, see #1067562. If this bug was fixed, please fix its metadata. Otherwise it will need an upload anyway. Cheers -- Sebastian Ramacher
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 2024-04-02 07:13:38 +0100, Alastair McKinstry wrote: > > On 01/04/2024 23:25, Sebastian Ramacher wrote: > > > There is a transition to openmpi-5 / mpi-defaults which is stalled by the > > > t64 transition. > > > > > > It drops 32-bit support from OpenMPI. > > > > > > Because of this, I don't think the solution is to port 32-bit atomics for > > > armel/armhf, as it will be removed in a few weeks/months. > > > > > > While we didn't want the transitions to be done simultaneously, it might > > > be > > > the best answer. > > > > > > > > > What does the release team think? > > Adding another transition on top will just delay the time_t transition > > even more. So if we can avoid that, I'd prefer to not do this transition > > now. Unfortunately, uploads such as the one of pmix that no dropped > > support for 32 bit architectures (#1068211) are not really helpful. > > > > Also, #1064810 has no information on test builds with the new > > mpi-defaults on a 32 bit architecture. So has this transition been > > tested? > > > > Cheers > > OpenMPI 5 drops 32-bit support, but otherwise does not change the API/ABI. > So it is technically not a transition, but breaks 32-bit builds. Doesn't make it better. This is not the time to do that without tests builds and bugs filed. > The solution is changing mpi-defaults to MPICH for 32-bit archs. MPICH > builds on all archs, but testing all dependencies of the change has not been > tested, and I don't know how you would do that - setting up eg ratt to > rebuild all on 32-bit archs (as everything on 64-bit will not have changed.) Beside the easy part of chaning mpi-defaults, I count 30 something packages that have explicit build dependencies on libopenmpi-dev. None of those packages has bugs filed to change to mpich on 32 bit architectures. To be honest, I don't see these two changes (changing mpi-defaults to mpich on 32 bit; breaking 32 bit build of openmpi) to be ready. It'd be preferable to reinstate a 32-bit compatible pmix and fix openmpi on 32 bit until the time_t transition is done. Cheers -- Sebastian Ramacher
Bug#1067953: transition: flint
Control: tags -1 confirmed On 2024-03-29 12:46:50 +, Torrance, Douglas wrote: > Package: release.debian.org > Control: affects -1 + src:flint > X-Debbugs-Cc: fl...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: dtorra...@piedmont.edu > Severity: normal > > Dear Release Team, > > I would like to request a transition slot for flint. The recent upstream > release 3.1.0 introduced the new soversion flint 19. A new binary package, > libflint19, was introduced in the source package flint 3.1.2-1~exp1, which > cleared the NEW queue on March 28 and is now in experimental. > > flint 3.1.1-1 already exists in unstable, which ships libflint.so.19 in > the libflint18t64 binary package. However, flint 3.0.1-3.1 had been > previously uploaded for the t64 transition, shipping libflint.so.18 in > the same binary package. This is RC bug #1067226 and has resulted in > several other RC bugs in reverse dependencies. Please go ahead so that reverse dpeendencies can actually build again. > An auto-flint tracker already exists for the t64 transition, but it doesn't > take the new libflint19 package into account. (Although perhaps this will > update automatically at some point?) > > binNMU's should be sufficient for each of flint's reverse dependencies: > > * e-antic > * gyoto > * macaulay2 > * msolve > * normaliz > * polymake > * singular Please perform test builds or track the rebuilds for build failures. Cheers > > Ben file: > > title = "flint"; > is_affected = (.build-depends ~ /\blibflint-dev\b/) | (.depends ~ > /\blibflint(?:18|18t64|19)\b/); > is_good = .depends ~ /\blibflint19\b/; > is_bad = .depends ~ /\blibflint18(?:t64)?\b/; > > Thank you! -- Sebastian Ramacher
Bug#1064810: Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
On 2024-04-01 12:05:30 +0100, Alastair McKinstry wrote: > > On 23/03/2024 01:58, Thorsten Glaser wrote: > > Andrey Rakhmatullin dixit: > > > > > OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64 > > > And I assume this arch doesn't have 64-bit atomics. > > No native ones, yes. > > > > I *think* either libatomic or libatomic_ops(?) make them > > available, but very slowly, using a syscall to guarantee > > atomicity (those systems are normally uniprocessor) on > > m68k. > > > > If possible, avoiding them would be preferrable. (For > > example, in some cases, like reading a 64-bit timestamp, > > if the writing direction is known and stable, reading > > twice then comparing is a possible alternative at least > > for some architectures (e.g. I know BSD code for sparc > > does it that way). > > > > I guess you’ll have to ask the porters of 32-bit arches > > with no native 64-bit atomics for details. > > > > Though I had thought GCC’s builtin atomics use the > > aforementioned kernel-based workaround from that library > > these days? > > There is a transition to openmpi-5 / mpi-defaults which is stalled by the > t64 transition. > > It drops 32-bit support from OpenMPI. > > Because of this, I don't think the solution is to port 32-bit atomics for > armel/armhf, as it will be removed in a few weeks/months. > > While we didn't want the transitions to be done simultaneously, it might be > the best answer. > > > What does the release team think? Adding another transition on top will just delay the time_t transition even more. So if we can avoid that, I'd prefer to not do this transition now. Unfortunately, uploads such as the one of pmix that no dropped support for 32 bit architectures (#1068211) are not really helpful. Also, #1064810 has no information on test builds with the new mpi-defaults on a 32 bit architecture. So has this transition been tested? Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
On 2024-04-01 10:39:08 -0400, Benjamin Barenblat wrote: > On Monday, April 1, 2024, at 2:57 PM +0200, Sebastian Ramacher wrote: > > Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to > > ensure that the build with the new armel/armhf ABI only migrates when > > the time_t transition is ready to advance? > > Yes! I am going to wait for the current upload (20230802.1-3) to finish > building on RISC-V, just to make sure the FTBFS is fixed. (It’s already > 11 hours in; it can’t take too much longer.) Once that’s done, I’ll > upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5). > (If you’d prefer that I preempt the current build and upload > 20230802.1-4 right now, just let me know.) Sounds good. Let's wait for -3 to finish building on riscv64. Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
On 2024-03-29 17:27:58 -0400, Benjamin Barenblat wrote: > On Friday, March 29, 2024, at 1:02 PM +0100, Sebastian Ramacher wrote: > > Since the version in unstable fails to build on armel and armhf and > > blocks the time_t transition, but the version in experimental builds > > fine, let's do this transition now. > > > > With the upload to unstable, please check the FTBFS issue on risc64, > > though. > > Sounds good. I never did get around to uploading 20240116 to > experimental. I’ll upload 20230802 to unstable this weekend, and I’ll > come back for 20240116 later. Thanks! Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to ensure that the build with the new armel/armhf ABI only migrates when the time_t transition is ready to advance? Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
Control: tags -1 confirmed Hi Benjamin On 2024-02-14 21:01:40 +0100, Sebastian Ramacher wrote: > On 2024-02-14 14:48:49 -0500, Benjamin Barenblat wrote: > > I’d like to alter this transition request. Instead of transitioning to > > version 20230802, I’d like to transition to version 20240116, which > > upstream recently released. > > > > Is that okay? If so, I’ll upload 20240116 to experimental and reexamine > > reverse dependencies. If not, please let me know how to proceed; a > > 20230802 -> 20240116 upgrade would require a second transition, and I > > don’t want to create extra work. > > That's okay. There is enough time to prepare a tranistion to 20240116 > until we have finished the time_t transition. Since the version in unstable fails to build on armel and armhf and blocks the time_t transition, but the version in experimental builds fine, let's do this transition now. With the upload to unstable, please check the FTBFS issue on risc64, though. See https://buildd.debian.org/status/fetch.php?pkg=abseil=riscv64=20230802.1-2=1703403912=0 Cheers -- Sebastian Ramacher
Bug#1067943: nmu: qtbase-opensource-src_5.15.10+dfsg-7
Control: reopen -1 On 2024-03-29 12:15:11 +0100, Sebastian Ramacher wrote: > On 2024-03-29 11:17:25 +0100, Bas Couwenberg wrote: > > Package: release.debian.org > > Severity: normal > > X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org > > Control: affects -1 + src:qtbase-opensource-src > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > nmu qtbase-opensource-src_5.15.10+dfsg-7 . armel armhf . unstable . -m > > "Rebuild for time_t" > > Scheduled Ah, no, it was not on my list for the last mass-binNMU. Cheers -- Sebastian Ramacher
Bug#1036884: more trackers
On 2024-03-29 00:39:02 +0500, Andrey Rakhmatullin wrote: > Some additional smaller trackers that apparently didn't have binNMUs: > https://release.debian.org/transitions/html/auto-ogre-1.12.html > https://release.debian.org/transitions/html/auto-ros-ros-comm.html > https://release.debian.org/transitions/html/auto-octomap.html > https://release.debian.org/transitions/html/auto-poppler.html > https://release.debian.org/transitions/html/auto-freerdp2.html Scheduled > Not sure if it's possible to find more of those without checking all > auto-* trackers. I wrote a script to schedule all remaining binNMUs. We then hopefully only have to sort out the remaining FTBFS issues, hardcoded dependencies and Architecture: all binaries. Cheers -- Sebastian Ramacher
Re: Should I upload 0ad involved in wxwidgets3.2 migration?
On 2024-03-27 15:51:22 +0100, Ludovic Rousseau wrote: > Hello Debian Release team, > > 0ad has a FTBFS bug #1064726. > I have a new version with the fix ready for upload. > > But when trying to upload I get: > - > $ dupload --to debian-ssh *_source.changes --no > dupload note: no announcement will be sent. > Checking OpenPGP signatures before upload..signatures are ok > Checking Debian transitions... > > Warning: Source package 0ad is part of ongoing transitions: > > <https://release.debian.org/transitions/html/auto-curl> > <https://release.debian.org/transitions/html/auto-libpng1.6> > <https://release.debian.org/transitions/html/auto-wxwidgets3.2> > > If the upload does not solve issues caused by these transitions, then it > might disrupt them by adding delays or entangling them. For more information, > please read: > > <https://wiki.debian.org/Teams/ReleaseTeam/TransitionUploadHook> > > Note: If you are aware of this and do not want to be warned, you can disable > this hook from the configuration file, skip it with --skip-hooks or set the > one-off environment variable DUPLOAD_SKIP_HOOKS, or alternatively you can > reply to the following prompt. > > Continue anyway? (yes/NO) > - > > I see 0ad listed in > https://release.debian.org/transitions/html/auto-wxwidgets3.2.html > Of course the rebuild failed because the FTBFS fix is not yet in unstable. > > Should I upload a new version of 0ad to help the wxwidgets3.2 migration? Yes, please. The upload is necessary to rebuild 0ad for these transitions. Cheers > Should I wait for 0ad to be removed from testing (planned in 5 days)? > > Please Cc: me on reply. > > Thanks > > -- > Dr. Ludovic Rousseau > -- Sebastian Ramacher
Bug#1036884: libgpgme11t64 binNMUs
On 2024-03-26 20:30:12 +0500, Andrey Rakhmatullin wrote: > The next good target for binNMUs that wasn't done yet (AFAICS) is > https://release.debian.org/transitions/html/auto-gpgme1.0.html Scheduled Cheers -- Sebastian Ramacher
Bug#1036884: transition: time64_t -> sphinxbase
On 2024-03-26 13:56:26 +, Simon McVittie wrote: > I think binNMUs for packages involved in > https://release.debian.org/transitions/html/auto-sphinxbase.html > would be useful. If I'm reading correctly, that would unblock ffmpeg > on armel/armhf (or at least get some way towards it), and ffmpeg is > involved in a bunch of other sub-transitions. Scheduled, thanks. > (I hope this is an OK format to make suggestions in?) Yes, it is. Cheers -- Sebastian Ramacher
Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi On 2024-03-09 21:39:50 +0100, Helmut Grohne wrote: > Hi release team and essential maintainers, > > On Mon, Sep 04, 2023 at 10:33:54PM +0200, Helmut Grohne wrote: > > Once these issues have been resolved, we can move most files except for > > a small set of essential packages. For those, a coordinated upload > > moving their files will be needed as will be an upload of base-files > > adding the aliasing symlinks there. > > We're well into this now. Most of the essential set is moved and I've > most of the remaining pieces. I hope that within one week, we're left > with only: > - base-files > - bash > - dash > - glibc > - util-linux > > Patches for these have been prepared. The current patches are available > from https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo. These > changes have been uploaded to Ubuntu noble already and feedback has been > incorporated. In particular, base-files will now divert to dot files to > avoid cluttering the / view during the transition and base-files will > remove unnecessary diversions (those where it ships symlinks). > > I'd now like to coordinate a time of upload. Given that chroots are > rebuilt in Wednesday and Sunday, I suggest we pick a Thursday morning > for the actual upload. If I unexpectedly break stuff, I still have a few > days to fix. How about March 21st? If and only if time64_t is done by then. Adding more changes where transition has to be coordinated to the ongoing mega transition does not help. Cheers -- Sebastian Ramacher
Bug#1036884: 64-bit time_t: libuuid1t64 -> libuuid1
On 2024-03-04 23:16:02 +0100, Chris Hofstaedtler wrote: > Hi, > > please schedule binNMUs for these source packages to transition back > from libuuid1t64 to libuuid1. Note that I've built this list based > on the amd64 Packages file. I'm not sure if skipping armel, armhf > would be helpful or not at this time. > > The notable thing is e2fsprogs on archs where the ABI didn't change, > to possibly help debootstrap find the correct package set. > > e2fsprogs > gsequencer > hwinfo > lib3mf > netplan.io > obs-studio > ola > optee-client > pacemaker > parted > rasqal > reiserfsprogs > scitokens-cpp > seafile > tpm2-tss > xen > xplc > xrootd Scheduled Cheers -- Sebastian Ramacher
Bug#1036884: 64-bit time_t: libpam0g -> libpam0t64 -> libpam0g
On 2024-03-02 13:51:13 +0100, Aurelien Jarno wrote: > Hi, > > As part of the time_t transition, the libpam0t64 library change got > reverted, and we ended-up with a few packages not installable even on > non arm* because they depends on libpam0t64 which is now gone. Well > technically it is still there as cruft, but it conflicts with libpam0g > which is used by essential packages. > > Would it be possible to fix that for our non arm* users? I have attached > the wb commands below, but you might want to do some of them on all > architectures for multiarch sync. Scheduled. We'll need to do some MA: same version skew clean up after the transition is done, though. Cheers -- Sebastian Ramacher
Bug#1036884: transition: time64_t
On 2024-03-02 15:06:15 +0200, Adrian Bunk wrote: > On Fri, Mar 01, 2024 at 11:10:22PM -0800, Steve Langasek wrote: > >... > > This needs to be built with dpkg-dev (>= 1.5.22), ... > >... > > The correct version is 1.22.5 (and >= 1.5.22 therefore a nop). There was already an upload by the maintainer correcting the issue. Cheers -- Sebastian Ramacher
Bug#1036884: transition: time64_t
On 2024-03-01 23:10:22 -0800, Steve Langasek wrote: > Please binNMU fyba on armhf and armel. The maintainer uploaded it without > versioned build-deps so it is renamed but has wrong ABI. > > This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1). Scheduled everywhere since it builds MA: same binaries. Cheers -- Sebastian Ramacher
Bug#1036884: transition: time64_t
On 2024-02-29 23:08:45 -0800, Steve Langasek wrote: > We are going to need a lot of binNMUs for the time_t transition of course, > but we're not quite ready to do the mass binNMUs. > > In the short term, can you please binNMU apt for libgnutls30t64? > > This needs to be built with dpkg-dev (>= 1.5.22), gcc-13 (>= 13.2.0-16.1), > and libgnutls28-dev (>= 3.8.3-1.1). Scheduled. Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
On 2024-02-14 14:48:49 -0500, Benjamin Barenblat wrote: > I’d like to alter this transition request. Instead of transitioning to > version 20230802, I’d like to transition to version 20240116, which > upstream recently released. > > Is that okay? If so, I’ll upload 20240116 to experimental and reexamine > reverse dependencies. If not, please let me know how to proceed; a > 20230802 -> 20240116 upgrade would require a second transition, and I > don’t want to create extra work. That's okay. There is enough time to prepare a tranistion to 20240116 until we have finished the time_t transition. Cheers -- Sebastian Ramacher
Bug#1061476: Transition slot for elpi
Hi Julien On 2024-02-09 10:06:28 +0100, julien.pu...@gmail.com wrote: > Hi, > > is there a particular problem with what I'm proposing? I checked and > didn't see any collision with an ocaml transition or some such. Until the time_t transition is done, we won't process other transition. Normal operation will continue after the time_t transition. Cheers -- Sebastian Ramacher
Bug#1061645: poco: NMU diff for 64-bit time_t transition
Hi Bastian On 2024-02-06 12:34:32 +0100, Bastian Germann wrote: > Hi Lucas, > > Please use the latest experimental QA upload for the 64-bit time_t transition > instead of uploading your NMU. > The other planned transition is documented in #1061645. > All library package names are SO-bumped, which should be enough to fulfill > your intended change. > This is a cross-posting to ensure the release team is aware of that. Please beaware that we are doing time_t first and pause all other transitions until that is complete. We will process the poco transition independently after time_t is done. Please do not entangle them. Cheers -- Sebastian Ramacher
Bug#1060103: transition: imagemagick7
Control: tags -1 moreinfo Hi Bastien On 2024-01-05 22:35:44 +, Bastien Roucariès wrote: > Package: release.debian.org > Severity: important > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-CC: ftpmas...@debian.org > > Imagemagick will need a new major bump > > I achieved to get imagemagick 7 build for experimental (it is only on salsa > not > uploaded yet). > > Every package include a version in the package name (except legacy package > name > and perl*) so I plan to do some step by step migration, because it is mainly > coinstallable with imagemagick 6. Why does this migration require co-instabillity with the old version? This makes the transition overly complicated. Do you expect major changes required in reverse dependencies of imagemagick's shared library? PS: Before the time_t transition is done, we will not process other transitions. Cheers -- Sebastian Ramacher
Bug#1061774: nmu: pngcheck_3.0.3-1
Control: reassign -1 fitspng 2.0-1 Control: retitle -1 fitspng: prints warnings on zlib updates On 2024-01-29 13:56:14 -0300, David da Silva Polverari wrote: > On Mon, Jan 29, 2024 at 04:45:59PM +0100, Filip Hroch wrote: > > Dear Release Team, > > > > may I ask you to rebuild pngcheck package against to > > the current version of zlib? > > > > I'm maintainer of fitspng package having bug #1059970, > > and I found that the bug is not related on fitspng itself. > > Actually, it is caused by pngcheck during CI tests > > verification. The current binary of pngcheck is compiled > > against an old zlib yet, and needs a recompilation. > > > In my opinion, there is no need for a rebuild. This is just a warning > that upstream deemed useful to include on the program. If tests are > failing because of that, I believe that fitspng tests are the ones that > should be updated to take that behaviour into account (using > allow-stderr and grepping for the 'OK', for example). If zlib's SONAME > hasn't changed, there's not need to link against a newer version. The warning is mostly pointless for Debian. Minimum requirements are expressed via dependencies and if zlib's ABI breaks it has to change its SONAME. Reassinging to fitspng. Cheers -- Sebastian Ramacher
Bug#1061071: transition: libcamera 0.2.0
Control: tags -1 confirmed Hi Dylan On 2024-01-17 12:33:56 +0100, Dylan Aïssi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: affects -1 + src:libcamera > > Dear Release Team, > > Please schedule a transition slot for libcamera 0.2.0. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1061061: transition: astc-encoder
Control: tags -1 confirmed Hi Timo On 2024-01-17 09:16:19 +0100, Timo Röhling wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: astc-enco...@packages.debian.org > Control: affects -1 + src:astc-encoder > > > Dear release team, > > I'd like to transition astc-encoder after a SONAME bump. There is only > one reverse dependency (filament), which builds fine against the new > version. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1060704: transition: dcmtk
Control: tags -1 moreinfo Hi Mathieu On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition. Are the reverse dependencies known to build with the new dcmtk version? Cheers -- Sebastian Ramacher
Bug#1060188: transition: flatbuffers
Control: tags -1 confirmed Hi On 2024-01-07 01:11:24 -0500, M. Zhou wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: flatbuff...@packages.debian.org > Control: affects -1 + src:flatbuffers > > The flatbuffers version in unstable is rather old. I'd like to start > the transition. All reverse dependencies can be built on amd64. > > Note, the package list in transition tracker is not complete. > I get the list by > >for each binary package from src:flatbuffers: > build-rdeps package Should those that are not part of the transition tracker use the shared library or not? Cheers -- Sebastian Ramacher
Bug#1060182: transition: simdjson
Control: tags -1 confirmed On 2024-01-06 18:22:36 -0500, M. Zhou wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: simdj...@packages.debian.org > Control: affects -1 + src:simdjson > > Hi, > > simdjson upstream bumped SOVERSION from 16 to 19 in the latest release. > All reverse dependencies can be rebuilt against 19 on amd64. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1060058: transition: tpm2-tss
Control: tags -1 confirmed Hi Ying-Chun On 2024-01-05 20:14:15 +0800, Ying-Chun Liu (PaulLiu) wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: tpm2-...@packages.debian.org, paul...@debian.org > Control: affects -1 + src:tpm2-tss > > The upstream changes the API/ABI. So we need a transition. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1059066: transition: nauty
On 2024-01-16 11:16:17 +, Torrance, Douglas wrote: > On Mon 15 Jan 2024 10:20:44 PM +01, Sebastian Ramacher > wrote: > > Control: tags -1 confirmed > > > > On 2023-12-19 23:02:13 +, Torrance, Douglas wrote: > > > Package: release.debian.org > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: dtorra...@piedmont.edu > > > Severity: normal > > > > > > Hello! > > > > > > I am requesting a transition slot for nauty. > > > > Please go ahead. > > Thank you! > > New versions of nauty, normaliz, and libgraph-nauty-perl have now been > uploaded > to unstable. > > In my original bug report, I mistakenly said that pynauty would need a new > source upload, but it already listed libnauty-dev instead of libnauty2-dev > in its Build-Depends, so a binNMU will be sufficient for it. Scheduled a rebuild of pynauty Cheers -- Sebastian Ramacher
Bug#1059272: transition: tango
Hi Santiago On 2023-12-27 21:16:02 +0100, Sebastian Ramacher wrote: > On 2023-12-22 08:36:17 -0300, Santiago Ruano Rincón wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: ta...@packages.debian.org, thomas.br...@byte-physics.de > > Control: affects -1 + src:tango > > > > Dear Release Team, > > > > I would like to upload tango 9.5.0 to unstable. There has been a SONAME > > bump from 9.4.2. Its reverse dependency pytango 9.5.0 builds and works > > well. Both are available in experimental. > > > > This set of uploads are needed to fix the pytango FTBFS bugs in unstable > > related to python3.12: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055733 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049843 > > > > Even if there is only one reverse dependency, I prefer to ask: May I go > > ahead? > > Please go ahead. The autopkgtests of pytango fail on s390x: https://ci.debian.net/packages/p/pytango/testing/s390x/ Could you please take a lookg? Cheers -- Sebastian Ramacher
Bug#1060077: transition: g2clib
Control: tags -1 ocnfirmed On 2024-01-05 17:11:23 +, Alastair McKinstry wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: g2c...@packages.debian.org, sramac...@debian.org > Control: affects -1 + src:g2clib > > > There is a minor transition I wish to proceed. g2clib upstream have added an > SOVERSION of .0 Please go ahead. Cheers -- Sebastian Ramacher
Bug#1059066: transition: nauty
Control: tags -1 confirmed On 2023-12-19 23:02:13 +, Torrance, Douglas wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: dtorra...@piedmont.edu > Severity: normal > > Hello! > > I am requesting a transition slot for nauty. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1028489: boost1.83 as default
Hi Anton On 2023-12-18 07:20:28 +0100, Anton Gladky wrote: > Hi Sebastian, > > uploded. boost-defaults migrated to testing. The remaining issues are: ceph: #1056793, #1056085, #1058543 graph-tool: #1060786 i2pd: #1060787 pycuda: #1060788 Cheers -- Sebastian Ramacher
Bug#1055955: transition: perl 5.38
Control: tags -1 confirmed On 2024-01-09 00:08:09 +0200, Niko Tyni wrote: > On Sat, Dec 09, 2023 at 01:15:26PM +0200, Niko Tyni wrote: > > On Tue, Nov 14, 2023 at 08:28:01PM +0200, Niko Tyni wrote: > > > > > this has taken me much longer than necessary for various reasons, but I > > > think we're almost ready to push Perl 5.38 to sid now. > > > > > > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.38-transition;users=debian-p...@lists.debian.org > > > I think we're as ready as can reasonably be, assuming you're OK with the > > above testing removals. Please let me know when a suitable transition > > slot becomes available. > > Hi, gentle ping on this? Please go ahead. Cheers -- Sebastian Ramacher
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve > - perl will also get a sourceful upload, to manually handle 'perlapi' > Provides. Can we combine this one with the upcoming perl transition? See #1055955. Here are some more comments on individual packages. > 22 libobs-dev That's a change to the plugin ABI only. > 14 gnuradio gnuradio bump its SONAME every other month. > 9 libopenmpt-dev Seems to be a false positive. > 9 libogre-1.9-dev > 9 libgirara-dev Why is this one on the list? > 5 gcc-10-plugin-dev Can be skipped, not part of testing. Should be RMed from the archive instead. > 4 llvm-15-dev llvm-toolchain-15 is scheduled for removal. Reverse dependencies should get an RC bug instead. > 4 libspatialaudio-dev Why is this package on the list? > 3 libdvbpsi-dev Seems to be a false positive > libavutil58 av_timegm is not used by any package in the archive. I'd skip ffmpeg and it's libraries. > libpoppler-cpp0v5 > libpoppler-glib8 > libpoppler-qt5-1 > libpoppler-qt6-3 > libpoppler126 Can be combined with the upcoming poppler transiton (see #1060019) > libvlc5 > libvlccore9 Change to vlc plugin ABI. This does not require a change of the binary package name. > g2clib Can be combined with the upcoming transition (see #1060077). Cheers -- Sebastian Ramacher
Bug#1059597: transition: papi
Control: tags -1 confirmed Hi Andreas On 2023-12-29 01:51:37 +0100, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > I'd like to update papi from libpapi7.0 to libpapi7.1. > Only starpu needs a binNMU (builds fine locally). > I'll upload a binNMU of starpu-contrib myself since it cannot be > autobuilt due to the non-free nvidia-cuda-tookit build-dependency. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1059272: transition: tango
Control: tags -1 confirmed Hi Santiago On 2023-12-22 08:36:17 -0300, Santiago Ruano Rincón wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: ta...@packages.debian.org, thomas.br...@byte-physics.de > Control: affects -1 + src:tango > > Dear Release Team, > > I would like to upload tango 9.5.0 to unstable. There has been a SONAME > bump from 9.4.2. Its reverse dependency pytango 9.5.0 builds and works > well. Both are available in experimental. > > This set of uploads are needed to fix the pytango FTBFS bugs in unstable > related to python3.12: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055733 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049843 > > Even if there is only one reverse dependency, I prefer to ask: May I go > ahead? Please go ahead. Cheers -- Sebastian Ramacher
Bug#1059330: transition: shapelib
Control: tags -1 confirmed Hi Bas On 2023-12-22 16:39:57 +0100, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: shape...@packages.debian.org > Control: affects -1 + src:shapelib > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-shapelib.html > > Shapelib 1.6.0 bumps the SONAME requiring a transition. > > All rdeps built successfully with the new version as summarized below. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1059358: transition: wolfssl
Control: tags -1 confirmed Hi Bastian On 2023-12-23 14:30:39 +0100, Bastian Germann wrote: > Package: release.debian.org > Control: affects -1 wolfssl > X-Debbugs-Cc: wolf...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-wolfssl.html > > wolfssl is available in experimental with libwolfssl42. > This transition is from libwolfssl41. > The auto-generated Ben file is okay and all reverse dependencies build fine. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1059026: transition: rocksdb
Control: tags -1 confirmed Hi On 2023-12-19 14:31:20 +0100, László Böszörményi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: affects -1 + src:rocksdb > > Hi RMs, > > Small transition of RocksDB to the 8.9.1 release, available from > experimental. Affected packages are balboa, oxigraph and sortmerna. > While oxigraph is Sid only currently, all three build fine with this > version of RocksDB as well. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1058944: transition: petsc
Control: tags -1 confirmed Hi Drew On 2023-12-18 19:02:51 +0100, Drew Parsons wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pe...@packages.debian.org > Control: affects -1 + src:petsc > > I'd like to upgrade PETSc (and SLEPc, and their python packages) > from 3.18 to 3.19. This is expected to fix the python 3.12 build > error in slepc4py, Bug#1057863. dolfin has now been patched to work > with petsc 3.19. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1057706: transition: dpdk
Hi Luca On 2023-12-19 09:12:12 +0100, Luca Boccassi wrote: > Please binnmu src:collectd as well, when you have a moment - there's a > runtime recommends instead of a depends, so it won't appear on the > automated tracker. Thanks! Scheduled Cheers -- Sebastian Ramacher
Bug#1028489: boost1.83 as default
Control: tags -1 = confirmed Hi Anton On 2023-11-16 23:08:10 +0100, Anton Gladky wrote: > Hi Sebastian, > > bugs are filed: > > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-boost183-transition=gl...@debian.org=1=1=1=1#results Please go ahead. Cheers -- Sebastian Ramacher
Bug#1057706: transition: dpdk
Control: tags -1 confirmed Hi Luca On 2023-12-07 11:41:04 +, Luca Boccassi wrote: > We have prepared the src:dpdk 23.11 ABI transition. Please go ahead Cheers -- Sebastian Ramacher
Bug#1058781: transition: zxing-cpp
Control: tags -1 confirmed On 2023-12-15 23:00:43 -0500, Boyuan Yang wrote: > I am looking to upload zxing-cpp 2.x (currently 2.2.1-1~exp1) to Debian Sid. A > library SONAME bump is needed in this transition (libzxing2 -> libzxing3). Please go ahead. Cheers -- Sebastian Ramacher
Bug#1058742: transition: libcotp
Control: tags -1 confirmed Hi On 2023-12-15 11:41:09 +, Francisco Vilmar Cardoso Ruviaro wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I would like to update libcotp in unstable to the 3.0.0-1. Please go ahead. Cheers -- Sebastian Ramacher
Re: g2clib transition
Hi Alastair On 2023-12-16 11:14:28 +, Alastair McKinstry wrote: > Hi, > > There is a minor transition I wish to proceed. g2clib upstream have added an > SOVERSION of .0 > > so the package name has changed libg2c0d -> libg2c0 > > Three dependencies will need rebuilding: pygrib, ncl and grads. > > I also maintain these 3 packages and they trivially rebuild. So this can be > done in a day, without impacting other transitions. > > May I proceed? Please turn this into a transition bug. Cheers -- Sebastian Ramacher
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)
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 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 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#1057304: nmu: ros2-performance-test-fixture_0.2.0-1
Control: tags -1 moreinfo On 2023-12-03 00:10:52 +0100, Timo Röhling wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: ros2-performance-test-fixt...@packages.debian.org, > team+robot...@tracker.debian.org > Control: affects -1 + src:ros2-performance-test-fixture > > nmu ros2-performance-test-fixture_0.2.0-1 . ANY . unstable . -m "Rebuild > against benchmark (Closes: #1054676)" > > benchmark 1.8.3 apparently dropped an exported symbol, which causes an > undefined reference to `benchmark::internal::Benchmark::Benchmark(char > const*)' when linking against ros2-performance-test-fixture. If benchmark drops a symbol from its shared library without a SONAME bump, that's a serious bug in benchmark. Please clarify the situation with the benchmark maintainers. > A binNMU seems to be the simplest fix for that. That would just hide a serious bug in benchmark. Cheers -- Sebastian Ramacher
Bug#1053800: transition: libgit2
Control: tags -1 confirmed On 2023-12-02 14:28:42 +0100, Timo Röhling wrote: > Hi Sebastian, > > * Sebastian Ramacher [2023-12-01 22:17]: > > Hoping that there are some good news regarding the bindings. What's the > > current status? > > 50% progress :) Then let's go ahead. > The Rust Team did not react. Too bad. Please raise the bug to RC. Cheers -- Sebastian Ramacher
Bug#1053800: transition: libgit2
Hi Timo On 2023-11-04 21:34:29 +0100, Timo Röhling wrote: > * Sebastian Ramacher [2023-11-01 12:14]: > > There are no replies on the bug report. Are there any news regarding the > > rust bindings? > No, nothing yet. All uploads in the past two years came from Peter Michael > Green, so I am going to ping him directly. > > > > golang-github-libgit2-git2go upstream has fallen behind and > > Same as above. Are there any news here? > No. I was prepared to ignore the Go bindings completely after they got > removed from trixie, but Mohammed Bilal did an upload to fix the RC bug, > presumably because they are a build dependency of gitlab. > I'll ping him, too. Hoping that there are some good news regarding the bindings. What's the current status? Cheers -- Sebastian Ramacher
Bug#1057175: transition: libsfml
Control: tags -1 confirmed On 2023-12-01 01:34:53 +, James Cowgill wrote: > Package: release.debian.org > Control: affects -1 + src:libsfml > X-Debbugs-Cc: libs...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > > Hi, > > libsfml needs a transition due to an ABI bump from 2.5 to 2.6. It's > currently in experimental and built everywhere except mips64el where > it's waiting to be built. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055857: transition: opm-common
Control: tags -1 moreinfo On 2023-11-12 21:42:20 +0100, Markus Blatt wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-scie...@lists.debian.org > > Dear Debian release team, > > A new upstream release of OPM is available. To ease migration to testing I am > requesting a mini-transition. Uploading to unstable would probably work even > without a transition, but I would like to play it safe. > > This should only affect the OPM source packages opm-common, opm-grid, opm- > models, opm-simulators and opm-upscaling. > > I have already uploaded new versions to experimental that seemed to have built > without any issues, see [1]. > (please explain about the transition: impacted packages, reason, ... > for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > Ben file: > > title = "libopm-common-2023"; > is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- > common-2023.10"; > is_good = .depends ~ "libopm-common-2023.10"; > is_bad = .depends ~ "libopm-common-2023.04"; libopm-common has a Provides: libopm-common-X, but the shared library included in libopm-common also has a SONAME of libopm-common.X. Why is the packaging not following the common practice of matching the package name with the SONAME? Cheers -- Sebastian Ramacher
Bug#1056308: transition: wireshark
Control: tags -1 confirmed On 2023-11-20 11:37:49 +0100, Bálint Réczey wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I'd like to update wireshark in unstable. The only reverse dependency to be > rebuilt is libvirt [1]. Please go ahead. Cheers > > Libvirt fails to rebuild for me locally on an Ubuntu system in an unstable > schroot environment with and without wireshark with the same test error: > > ... > --- stderr > --- > TEST: virnetsockettest > Cannot identify IPv4/6 availability > ... > Summary of Failures: > > 124/173 libvirt:bin / virnetsockettestFAIL > 0.05s exit status 1 > > Ok: 171 > Expected Fail: 0 > Fail: 1 > Unexpected Pass:0 > Skipped:1 > Timeout:0 > ... > > I believe libvirt will build fine with the updated wireshark package on the > buildds. > > Thank you, > Balint > > [1] https://release.debian.org/transitions/html/auto-wireshark.html -- Sebastian Ramacher
Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
On 2023-11-19 13:54:02 +0100, Hilmar Preuße wrote: > On 11/19/23 00:40, Adrian Bunk wrote: > > On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote: > > > On 11/18/23 20:18, Samuel Thibault wrote: > > Hi all, > > > > > nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild > > > > against new zlib" > > > > > > > Thanks for filing the NMU bug. > > > > > > > So a binnmu of the texlive-bin source package seems needed on all archs > > > > to fix installing texlive-binaries. > > > > > > > > > > I tested if recompiling solves the issue and it does. Hence I bump > > > severity > > > of the NMU bug the get a solution ASAP. > > > > I don't see how a binNMU would solve the problem. > > > > A proper fix would be either to: > > 1. patch the version check out of texlive-bin (preferred), or > > > I can patch out that version check as found by Samuel, but I don't see how > that would solve the core dump or the SIGABRT, which was reported. I hope > lua_error(L) is not the equivalent of "exit with SIGABRT". ;-) > > I still suspect that something broke in the API of zlib, the zlib people are > not aware of. That crash is the fault of lua_error(L). Removing the version check including the call to lua_error is the proper fix for this. If any of the binaries of texlive-bin require a minimum version of the zlib, this needs to be reflected in Depends and not with a deliberate crash. > > 2. ensure texlive-bin has package dependencies that match this runtime > > check > > The zlib people, did not change the API version or created a version > statement in the depends line like "Depends: ... zlib1g (>= 1:1.3)", hence > I'd add an artificial "Breaks: ... zlib1g (<= 1:1.2.3)" to my > texlive-binaries package to make sure 1.3 is in place, when the new > texlive-binaries comes in. Correct? No, that's certainly the incorrect fix. Especially if that is hard-coded. Cheers -- Sebastian Ramacher
Bug#1056065: transition: spdlog
Hi Andrius binNMUs for the reverse dependencies have been scheduled. spdlog's autopkgtest fail, though: https://ci.debian.net/data/autopkgtest/testing/amd64/s/spdlog/39983394/log.gz Could you please take a look? Cheers -- Sebastian Ramacher
Bug#1055891: transition: gdal
Control: tags -1 confirmed On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: g...@packages.debian.org > Control: affects -1 + src:gdal > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-gdal.html > Control: block -1 by 1051433 > > For the Debian GIS team I'd like to transition to GDAL 3.8.0. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055600: transition: suitesparse-7.3
Control: tags -1 confirmed On 2023-11-08 18:00:20 +0100, Sébastien Villemot wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-suitesparse.html > > Dear Release Team, > > Please schedule a transition for suitesparse 7.3, which currently sits in > experimental. > > One the shared libraries got a SOVERSION bump (libcholmod4 → libcholmod5). The > ABI change is minor and I’m therefore fairly confident that there won’t be any > issue. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1056065: transition: spdlog
Control: tags -1 confirmed On 2023-11-16 18:01:01 +0200, Andrius Merkys wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: cru...@debian.org > > Hello, > > I would like to request a transition slot for spdlog (experimental -> > unstable) due to soname bump. Please go ahead. > Ben tracker was not set up automatically, thus > its file should look like this: > > is_affected = .depends ~ > /\b(libspdlog\-dev|libspdlog1\.10|libspdlog1\.12)\b/; > is_good = .depends ~ /\b(libspdlog\-dev|libspdlog1\.12)\b/; > is_bad = .depends ~ /\b(libspdlog1\.10)\b/; I suspect that's due to the use of libspdlogX-fmtY. I've added a manual tracker and added the fmt postfix. Cheers -- Sebastian Ramacher
Bug#1055812: nmu: sqlcipher_4.5.5-3
user release.debian@packages.debian.org usertags 1055812 = transition retitle 1055812 transition: sqlcipher forwarded 1055812 https://release.debian.org/transitions/html/auto-sqlcipher.html tags 1055812 confirmed thanks On 2023-11-11 23:19:03 +0100, Petter Reinholdtsen wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: sqlcip...@packages.debian.org > Control: affects -1 + src:sqlcipher > > nmu sqlcipher_4.5.5-3 . ANY . unstable . -m "Rebuild with newer sqlcipher." > > The SONAME of the shared library changed from libsqlcipher0 to libsqlcipher1. > This is related to > https://release.debian.org/transitions/html/auto-sqlcipher.html >. In this case, please select transition in reportbug to get the correct meta data. Fixing. Cheers -- Sebastian Ramacher
Bug#1054657: transition: r-bioc-biocgenerics
On 2023-11-10 17:43:43 +0900, Charles Plessy wrote: > Hi Paul and everybody, > > we are finding a way to compare the R dependencies of the Bioconductor > packages in Debian and in Bioc 3.18. It uncovers some core packages > introduced in Bioc 3.17, but which only start to have > reverse-dependencies in 3.18, meaning that they are not in Debian yet > since we did not have a reason to package them at that time. > > It seems that I was too confident that no new core dependencies would be > introduced, and I feel guilty for that. Still I need to add that > despite the stress on both sides, I really would like no not be told "We > do not care about [the information you sent]" again, while "I am sorry > but I do not see the relevance" or "I am sorry but this is not enough" > is so much more informative and less conflictual. I did appreciate a lot > the care you took in expressing your criticisms in your email yesterday. I am sorry that my terse mail crossed you the wrong way. I am afraid that your first paragraph keeps me confused and I wonder if we are talking past each other. For this transition we are interested in packages that have to go through NEW since they are new (Build-)Depends of packages involved in the r-bioc-transition. New reverse dependencies, i.e., NEW packages that depend on packages that are part of the transition, but are not (Build-)Depends of the current set of packages in the archive, do not affect this transition. Can you please clarify whether you are talking about new dependencies or reverse dependencies above? Thanks. Cheers -- Sebastian Ramacher
Bug#1055755: transition: libre/rem/baresip
Control: tags -1 moreinfo On 2023-11-10 17:56:31 +0100, Bastian Germann wrote: > Package: release.debian.org > Control: affects -1 libre > X-Debbugs-Cc: li...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-libre.html > > libre, rem, and baresip are available in experimental, details on the update > at #967266. > I suggest to upload libre, then rem, then baresip to unstable. > The auto-generated Ben files of auto-libre and auto-rem are okay and > the packages build fine but are relying on being updated together (the > experimental baresip does not build with unstable libre/rem, while > experimental libre/rem break baresip). Did you coordinate this plan with the maintainer of libre? Cheers -- Sebastian Ramacher
Bug#1055699: transition: spglib
Control: tags -1 confimred On 2023-11-10 10:42:38 +0200, Andrius Merkys wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hello, > > I would like to request a transition slot for spglib > (experimental -> unstable) due to soname bump. Current ben tracker [1] > is OK. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055751: transition: wolfssl
Control: tags -1 = confirmed On 2023-11-10 19:13:22 +0100, Bastian Germann wrote: > Am 10.11.23 um 18:03 schrieb Sebastian Ramacher: > > Control: tags -1 moreinfo > > > > On 2023-11-10 15:57:27 +0100, Bastian Germann wrote: > > > The auto-generated Ben file is okay and all reverse dependencies build > > > fine. > > > > What's the status of the reverse dependencies? Do they build > > successfully with the new version of wolfssl? > > Yes, as I have written. I should have finished with reading that sentence. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055751: transition: wolfssl
Control: tags -1 moreinfo On 2023-11-10 15:57:27 +0100, Bastian Germann wrote: > Package: release.debian.org > Control: affects -1 wolfssl > X-Debbugs-Cc: wolf...@packages.debian.org > User: release.debian@packages.debian.org > Usertags: transition > Severity: normal > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-wolfssl.html > > wolfssl is available in experimental with libwolfssl41. > This transition is from libwolfssl35. > The auto-generated Ben file is okay and all reverse dependencies build fine. What's the status of the reverse dependencies? Do they build successfully with the new version of wolfssl? Cheers -- Sebastian Ramacher
Bug#1055194: transition: openturns
Control: tags -1 confirmed On 2023-11-01 22:49:33 +0100, Pierre Gruet wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: opentu...@packages.debian.org > Control: affects -1 + src:openturns > > Dear Release Team, > > I would like to request a transition slot for openturns. It has been accepted > to experimental after a SONAME bump as some symbols changed in a not > backward-compatible way. It builds correctly. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055487: nmu: openstructure_2.6.0~rc-1~exp spglib_2.1.0-1~exp
Control: tags -1 moreinfo Hi Andrius On 2023-11-07 11:15:44 +0200, Andrius Merkys wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hello, > > I want to request binNMU on amd64 for packages recently accepted to > experimental. > > nmu openstructure_2.6.0~rc-1~exp . amd64 . experimental . -m "Rebuild on > buildd" > nmu spglib_2.1.0-1~exp . amd64 . experimental . -m "Rebuild on buildd" We can of course schedule the binNMUs, but I am wondering why are those required? Cheers -- Sebastian Ramacher
Bug#1054657: transition: r-bioc-biocgenerics
On 2023-11-07 14:38:13 +0100, Andreas Tille wrote: > Hi Sebastian, > > Am Tue, Nov 07, 2023 at 10:53:00AM +0100 schrieb Sebastian Ramacher: > > Control: tags -1 moreinfo > > I admit I'm not really happy about the bug ping-pong. > > > > I just finished inspecting by eye the homepage of each of the 69 new > > > Bioconductor packages. None of them declare a reverse-dependency to > > > an existing Bioc package that we ship in Debian. > > > > We do not care about new reverse dependencies. > > Seems there is some misunderstanding. Charles has inspected pacckages > *outside* Debian whether they might be pulled by new versions of > packages *inside* Debian. These would be candidates for new packages. > > > We care about new > > dependencies of packages currently in the archive. So what's the status > > of new the dependencies? > > Charles and I tried to explain in different ways: We do not have simple > means to answer this question. Picking a random r-bioc-* package: https://salsa.debian.org/r-pkg-team/r-bioc-aroma.light/-/blob/master/DESCRIPTION has an "Imports" field. Those are mapped to dependencies in the package. So I presume that when importing those packages into the packaging repository, changes to this field can be identified and checked. I would excpect this information to be enough to identify any currently missing packages. > But I had a different question; What > exactly is the problem of a transition taking about 1 month due to some > delay by waiting for packages in new? > > I somehow have the feeling that this transition is currently delayed by > some bug-mail / tagging ping-pong which is demotivating for both sides. > You make a request to some volunteers to do some extra work that was not > requested before and we volunteers explained that it is really hard > work. I think it is fair to ask for the reasons you want us to do some > work which is definitely hard to do and for us painful and unproductive. We should have requested this information for all transitions in the past. We did not and thus had the same problems for the last couple of transitions including missing packages and a significant number of autopkgtest regressions. The r-bioc-* transition is special in the sense that it requires all involved packages to be ready to migrate at the same time. This is where delays become an issue. It essentially blocks all other transitions that could potentially overlap (e.g., auto-hdf5) from being started or progressing. All of that binds resources on our side to track down the remaining bits and pieces to make everything migrate at the same time. This is usually not an issue with a typical shared library transition. Hence we are asking you to identify possible NEW packages that will be required to complete the transition. Cheers -- Sebastian Ramacher
Bug#1054657: transition: r-bioc-biocgenerics
Control: tags -1 moreinfo Hi Charles On 2023-11-03 09:56:13 +0900, Charles Plessy wrote: > > Am Wed, Nov 01, 2023 at 09:02:10AM -0100 schrieb Graham Inggs: > > > 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. > > Le Wed, Nov 01, 2023 at 11:28:38AM +0100, Andreas Tille a écrit : > > Understood this item now - but I'm lacking any clue how to find out > > what new packages are needed. > > Hi Graham and Andreas, > > I just finished inspecting by eye the homepage of each of the 69 new > Bioconductor packages. None of them declare a reverse-dependency to > an existing Bioc package that we ship in Debian. We do not care about new reverse dependencies. We care about new dependencies of packages currently in the archive. So what's the status of new the dependencies? Cheers -- Sebastian Ramacher
