Bug#1073289: Bug#1073983: transition: ocaml
On 16/07/2024 13:16, Adrian Bunk wrote:
On Tue, Jul 16, 2024 at 10:25:43AM +0200, Stéphane Glondu wrote:
Hi,
Hi Stéphane,
Le 27/06/2024 à 11:38, Stéphane Glondu a écrit :
The remaining unknowns are llvm-toolchain-{14,15,16,17,18}... [...]
I've done a rebuild of the OCaml universe with yesterday's unstable
(mostly). The "missing" packages are the same, but the llvm-toolchain-16
build got far enough to FTBFS because of OCaml 5.2.0. This is likely to
affect llvm-toolchain-{14,15} as well, but might be fixed in newer versions.
I've reported bugs accordingly.
[...] Worst case scenario: the OCaml bindings can be disabled (they
don't have reverse dependencies in Debian).
I still think this is the best course of action.
looking at [1] this might be the only reasonable course of action for LLVM < 17.
Disabling them sounds fine (specially for 14 which is no longer in testing and
15 which we're trying to get rid of), but ideally it can be done ahead of the
start in order to prevent delays with the transition.
Other than that, I'm happy with the current state and we could go ahead. So if
you can get those bindings disabled, then I think we can go ahead.
Cheers,
Emilio
Bug#1076095: transition: libpqxx
Control: tags -1 confirmed On 10/07/2024 18:49, Teus Benschop wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libp...@packages.debian.org, teusbensc...@debian.org Control: affects -1 + src:libpqxx User: release.debian@packages.debian.org Usertags: transition The libpqxx upstream is now at version 7.9. Hence the need to have this in Debian too. A package already is in the experimental distro. (please explain about the transition: impacted packages, reason, ... for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) Ben file: https://release.debian.org/transitions/html/auto-libpqxx.html Reverse deps: osm2pgrouting - should build without error with the new lib. sqlsmith - should build without error with the new lib. For both packages a binNMU will be sufficient due to the clean library ABI bump. title = "libpqxx"; is_affected = .depends ~ "libpqxx-7.8t64" | .depends ~ "libpqxx-7.9"; is_good = .depends ~ "libpqxx-7.9"; is_bad = .depends ~ "libpqxx-7.8t64"; This is a request for a transition slot for this update. Go ahead. Emilio
Bug#1076000: transition: steptalk
Control: tags -1 confirmed On 09/07/2024 10:00, Yavor Doganov wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: stept...@packages.debian.org Control: affects -1 + src:steptalk Control: block -1 with 1075999 User: release.debian@packages.debian.org Usertags: transition This package has been neglected by our team (ltnu reports last upload was 10 years ago) and it has some subtle bugs which could be fixed only by moving to an upstream snapshot. We had to bump the SONAME (from libsteptalk0 to Debian-specific libsteptalk0d) because examining the diff has shown there is an ABI break. The only rdep adun.app builds fine against the new version; the ben tracker is also correct. Go ahead. Emilio
Bug#1075999: transition: gnustep-dl2
Control: tags -1 confirmed On 09/07/2024 09:50, Yavor Doganov wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: gnustep-...@packages.debian.org Control: affects -1 + src:gnustep-dl2 Control: block -1 with 1075998 User: release.debian@packages.debian.org Usertags: transition To fix some long-standing bugs in this package we decided to move to a git snapshot which introduces an ABI break, so we had to bump the Debian-specific SONAME once again, from libgnustep-dl2-0d to libgnustep-dl2-0deb (cherry-picking these fixes would have been possible but they would break the ABI nevertheless). As gnustep-dl2 requires a sourceful upload for the gorm.app transition, we suggest to carry out this transition at the same time. The sole rdep steptalk builds successfully but as there is a pending steptalk transition as well, we may combine them if you decide so. The ben tracker at release.d.o looks good. Go ahead. Emilio
Bug#1075998: transition: gorm.app
On 09/07/2024 19:40, Yavor Doganov wrote: Emilio Pozuelo Monfort wrote: On 09/07/2024 09:40, Yavor Doganov wrote: The only reverse dependency gnustep-dl2 will require a sourceful upload. Go ahead. Thanks, uploaded. May I assume that we also have your permission to upload gnustep-dl2 and steptalk from experimental (both have proper Build-Depends set to ensure they get built against the new versions)? I have looked at their respective transition bugs and both look ok. So yes, you can upload those and do the three transitions at once. Cheers, Emilio
Bug#1074248: transition: mbedtls
On 02/07/2024 18:43, Andrea Pappacoda wrote: Hi Emilio! Il 2 luglio 2024 13:13:43 CEST, Emilio Pozuelo Monfort ha scritto: Cool. btw I checked those packages and only these 3 are key packages: bctoolbox libgit2 rustc It'd be nice to know if rustc will build if it wasn't for the disk space. Also it'd be good to have the other two packages sorted (e.g. with a patch prepared or identified) before starting this transition. bctoolbox switched to using mbedtls 3.x since version 5.3.0, so the package maintainers would only need to upgrade the package. libgit2 too switched to the latest mbedtls in version 1.8.0, which is already in experimental. As for rustc, yeah, I'd need to build on a system with more disk space. I'm nonetheless at least looking at all the failures and filing bug reports when necessary. Once I've checked all the packages and the key packages you've mentioned are ready, I'll go ahead with the transition. Please mail us before proceeding, so that we can check that things are looking good and that there are no conflicting transitions, and we'll give you the go-ahead. Cheers, Emilio
Bug#1072673: qttools-opensource-src: uses LLVM 15 which is being removed
On 06/06/2024 18:17, Dmitry Shachnev wrote: Hi Emilio! On Thu, Jun 06, 2024 at 09:58:19AM +0200, Emilio Pozuelo Monfort wrote: Source: qttools-opensource-src Version: 5.15.8-2 Severity: important Hi, qttools-opensource-src is building with LLVM 15, which is going to be removed soon. Please switch to a newer version (such as 17), or ideally use the default version, which may be more suitable/stable these days. Unfortunately, qttools fails to build with newer LLVM, some qdoc-related tests fail [1]. In particular, it misinterprets typedefs as structs, as can be seen in the build log [2]. Upstream Qt 6 had a series of patches to fix build with LLVM 16/17, see the linked Gerrit Reviews in this bug [3]. However, most of these patches fail to apply cleanly to 5.15 branch, and based on patch descriptions I could not identify the patch which would fix these particular test failures. So I either need a help from LLVM expert who would explain this test failure, or we can ignore these tests, or we can drop qdoc in 5.15. The last option would mean dropping documentation for all of Qt 5, and also fixing at least kuserfeedback and quickflux. It is hard to identify the complete set of affected packages, because some packages can depend on qdoc-qt5 indirectly via qttools5-dev-tools. Maybe the set of affected packages will become smaller once Qt6-based KDE stack lands in unstable. I'm not sure what's the best way forward. If it's only the tests that break, or if the doc output is only affected in a minor way, obviously disabling those tests is a reasonable option. Might be better than removing qdoc-qt5 entirely. Cheers, Emilio
Bug#1075998: transition: gorm.app
Control: tags -1 confirmed On 09/07/2024 09:40, Yavor Doganov wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: gorm@packages.debian.org Control: affects -1 + src:gorm.app User: release.debian@packages.debian.org Usertags: transition Upstream has renamed the public Gorm library from libGorm to libInterfaceBuilder so on behalf of the GNUstep team I'd like to ask for a transition slot. The only reverse dependency gnustep-dl2 will require a sourceful upload. Go ahead. Emilio
Bug#1075964: transition: qtwebengine-abi-5-15-17
Control: tags -1 confirmed On 08/07/2024 14:58, Dmitry Shachnev wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release team, I would like to move Qt WebEngine 5.15.17 from experimental to unstable. It is a patch release in 5.15 LTS branch that backports multiple CVE fixes from upstream Chromium, adds native Python 3 support (so we can drop our large patch), and additionally it includes a fix for building with libxml2 2.12 (so it fixes #1074671). Only two reverse dependencies will need to be binNMUed: angelfish and qtwebview-opensource-src. I suppose those two build fine against the new version. If so, please go ahead. Cheers, Emilio
Bug#1074248: transition: mbedtls
Hi Andrea, On 25/06/2024 09:21, Andrea Pappacoda wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: mbed...@packages.debian.org Control: affects -1 + src:mbedtls User: release.debian@packages.debian.org Usertags: transition Hi :) I'm working on transitioning mbedtls from version 2.28 LTS to 3.6 LTS. There are a few packages currently failing to build with this new API (and ABI) breaking release, so this might take a while. This is my first "big" transition, so be sure to provide even the most stupid suggestion! I've used the ratt package to rebuild all the reverse dependencies, and here are the results: $ grep ^Status: * | grep -v success bctoolbox_5.2.0-2.1:Status: attempted bibledit_5.1.013-1:Status: attempted bibledit-cloud_5.1.013-1:Status: attempted dislocker_0.7.3-3.1:Status: attempted dolphin-emu_5.0-19870+dfsg-1:Status: attempted gauche_0.9.14-5:Status: attempted gauche-c-wrapper_0.6.1-12:Status: attempted geany-plugins_2.0-4:Status: given-back haxe_1:4.3.4-1:Status: attempted kicad_8.0.3+dfsg-1:Status: attempted lib60870_2.3.2-1:Status: attempted libgit2_1.7.2+ds-1:Status: attempted lief_0.9.0-1:Status: attempted micropython_1.22.1+ds-1:Status: attempted mongrel2_1.12.2-3:Status: attempted ncbi-blast+_2.12.0+ds-4:Status: attempted ncbi-vdb_3.0.2+dfsg-2:Status: attempted neko_2.3.0-2:Status: attempted privoxy_3.0.34-5:Status: attempted python-mbedtls_2.10.1-1:Status: attempted rustc_1.78.0+dfsg1-2:Status: attempted rust-parsec-service_1.3.0-5:Status: attempted rust-psa-crypto_0.9.2-3:Status: attempted rust-psa-crypto-sys_0.9.3-2:Status: attempted rust-ripasso_0.6.5-2:Status: given-back rust-ripasso-cursive_0.6.5-3:Status: given-back rust-sequoia-octopus-librnp_1.8.1-4:Status: given-back shadowsocks-libev_3.3.5+ds-10:Status: attempted yuzu_0-1335+ds-1.4:Status: attempted Some of these failures are not relevant. shadowsocks-libev, for example, isn't in testing and is scheduled for removal (see bug #1072934). rustc, instead, failed because I had no space left on my device. Most packages, though, are genuinely failing with MbedTLS 3.x. I'll start filing bugs against the affected packages soon-ish. Cool. btw I checked those packages and only these 3 are key packages: bctoolbox libgit2 rustc It'd be nice to know if rustc will build if it wasn't for the disk space. Also it'd be good to have the other two packages sorted (e.g. with a patch prepared or identified) before starting this transition. Cheers, Emilio
Bug#1060704: transition: dcmtk
Control: tags -1 confirmed Hi, On 28/06/2024 17:36, Étienne Mollier wrote: Hi Gents, Emilio Pozuelo Monfort, on 2024-06-27: On 27/06/2024 08:13, Mathieu Malaterre wrote: The debian-med team was kind enough to build the reverse dependencies dependencies: * https://lists.debian.org/debian-med/2024/06/msg3.html They only rebuilt one of them (insighttoolkit5) afaics? The rest should be few and lightweight, so maybe you can rebuild them yourself? All you need is to configure your build tool to include the new dcmtk. Maybe bin:ratt helps you do that. Looks like there's been a misunderstanding, so I thrown a batch of rebuilds today and here are the results. The following items are regressions introduced by dcmtk in experimental, while build goes through using dcmtk from sid: * orthanc fails to configure its build; * orthanc-wsi fails to build due to failure to include openssl/hmac.h; * plastimatch fails to build from source due to missing symbol DCM_ROIObservationLabel; * sight fails to build from source due to missing symbol UID_RFC2557MIMEEncapsulationTransferSyntax. I uploaded my corresponding build logs on people[1] if you would like to further examinate the failures right away. [1]: https://people.debian.org/~emollier/transitions/dcmtk/ Otherwise: * ants still build depends on itk4 and thus the build fails to start at all, so this is not a regression; * all the other reverse dependencies were unaffected in their construction by dcmtk version bump. Please file bugs for those issues. Once that is done, you can go ahead with the transition. Cheers, Emilio
Bug#1060704: transition: dcmtk
On 27/06/2024 08:13, Mathieu Malaterre wrote: On Sun, Jan 21, 2024 at 4:55 PM Sebastian Ramacher wrote: 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? I've integrated all changes from unstable back into the experimental package. The debian-med team was kind enough to build the reverse dependencies dependencies: * https://lists.debian.org/debian-med/2024/06/msg3.html They only rebuilt one of them (insighttoolkit5) afaics? The rest should be few and lightweight, so maybe you can rebuild them yourself? All you need is to configure your build tool to include the new dcmtk. Maybe bin:ratt helps you do that. Cheers, Emilio
Bug#1073537: transition: jpeg-xl
On 26/06/2024 14:40, Jeremy Bícha wrote: krita has been fixed by updating to a new version. I believe there are no remaining blockers here. Thanks. You can go ahead then. Cheers, Emilio
Bug#1073983: transition: ocaml
On 21/06/2024 07:25, Stéphane Glondu wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: oc...@packages.debian.org Control: affects -1 + src:ocaml User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I uploaded ocaml 5.2.0 to experimental, and it builds successfully on all release architectures: https://buildd.debian.org/status/package.php?p=ocaml=experimental I recompiled the OCaml world with it: http://ocaml.debian.net/transitions/ocaml-5.2.0/ At most 389 source packages are involved. A binNMU will suffice for most of them. I've posted a summary there: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073289#50 I think all problematic packages can be removed from testing. Bugs have been filed: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-5.2.0-transition;users=debian-ocaml-ma...@lists.debian.org I hereby request a transition slot. Assuming xen gets fixed, I checked if the rest could be removed: $ dak rm -Rn -s testing approx cairo-ocaml camlimages camltemplate coinst cothreads cryptgps facile frama-c gd4o hlins hol-light lablgl ledit mcl14 misery mlpcap nproc ocamlagrep ocamlcreal ocaml-cry ocamldap ocamldsort ocaml-expect ocaml-gnuplot ocaml-inifiles ocaml-magic ocaml-merlin ocaml-obuild ocaml-reins ocaml-rope ocamlrss ocaml-stdcompat ocaml-tools pagodacf orpie pa-ounit planets pxp polygen sks wyrd xstr [...] Checking reverse dependencies... # Broken Depends: cappuccino: cappuccino ikiwiki-hosting: ikiwiki-hosting-web [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] meta-ocaml: ocaml-libs # Broken Build-Depends: advi: libcamlimages-ocaml-dev (1:5.0.3 >=) cappuccino: polygen coccinelle: libstdcompat-ocaml-dev kalzium: libfacile-ocaml-dev pyml: libstdcompat-ocaml-dev (13 >=) Not sure if all of those can also be removed (along with their reverse-deps, if any). At least kalzium is a key package, so it'd be good to get its (build-)deps fixed. Cheers, Emilio
Bug#1074259: transition: alglib
Control: tags -1 confirmed On 25/06/2024 15:14, Anton Gladky wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: alg...@packages.debian.org Control: affects -1 + src:alglib User: release.debian@packages.debian.org Usertags: transition Dear release team, plase schedule a tiny transition of the new version of alglib library. There are only 3 dependencies and they are all building fine against new alglib. Go ahead. Cheers, Emilio
Bug#1072853: transition: gnustep-base, gnustep-gui
Control: tags -1 confirmed On 09/06/2024 05:45, Yavor Doganov wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org User: release.debian@packages.debian.org Usertags: transition Hi release managers, On behalf of the GNUstep team I'd like to request a transition slot for a combined gnustep-base/gnustep-gui transition (one-round binNMUs): libgnustep-base1.29 -> 1.30 libgnustep-gui0.30 -> 0.31 The new libraries are available in experimental, built on all release architectures. Build-testing the rdeps revealed only one issue (lynkeos.app, #1072736) which has been fixed in unstable so no sourceful uploads (except gnustep-back) will be required. FYI, the new gnustep-gui version adds support for ImageMagick 7 (release.d.o #1060103). The automatically generated trackers look fine. Go ahead. Emilio
Bug#1073537: transition: jpeg-xl
Control: tags -1 confirmed On 20/06/2024 10:00, Mathieu Malaterre wrote: On Thu, Jun 20, 2024 at 9:40 AM Emilio Pozuelo Monfort wrote: Hi, On 17/06/2024 08:13, Mathieu Malaterre wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpeg...@packages.debian.org Control: affects -1 + src:jpeg-xl As discussed previously I am filling a bug report for jpeg-xl 0.9 transition Did you rebuild the rdeps against the new version? I personally did not, but through private communication @jbicha did so. And the results were successful? Would help if that information is posted on the initial email. Assuming the test rebuilds went well, then you can go ahead. Cheers, Emilio
Bug#1073537: transition: jpeg-xl
Hi, On 17/06/2024 08:13, Mathieu Malaterre wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: jpeg...@packages.debian.org Control: affects -1 + src:jpeg-xl As discussed previously I am filling a bug report for jpeg-xl 0.9 transition Did you rebuild the rdeps against the new version? Cheers, Emilio
Bug#1072925: transition: nghttp3
Control: tags -1 confirmed On 10/06/2024 15:01, Sakirnth Nagarasa wrote: Package: release.debian.org Severity: normal Control: affects -1 + src:nghttp3 User: release.debian@packages.debian.org Usertags: transition Hi dear release team, the upgrade from nghttp3 version 0.8.0 to 1.3.0 requires a change in the SONAME and hence a transition. The new version is already in experimental. The following source packages need to be rebuilt: wireshark Please schedule binNMUs for the above mentioned packages on all architectures. First you need to upload nghttp3 to unstable. Go ahead with that. Cheers, Emilio
Bug#1072755: transition: rtmidi
Control: tags -1 confirmed On 07/06/2024 16:40, IOhannes m zmoelnig wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: rtm...@packages.debian.org Control: affects -1 + src:rtmidi User: release.debian@packages.debian.org Usertags: transition The latest upstream of RtMidi includes a soname bump of libRtMidi. The Debian packages have updated their names accordingly. The new RtMidi has been uploaded to experimental a while ago (last year). I've checked reverse dependencies with 'ratt', and so far only found problems in the following packages: - polyphone - octave-audio - ft2-clone all three fail during the dependency resolution, so we do not know whether RtMidi causes any problems. however, checking the RtMidi API does not show any backwards-incompatible changes, so I do not expect any problems. (the soname bump was obviously triggered by a class-method becoming virtual, so the ABI changed, but not the API) thanks in advance for a transition slot. Go ahead. Emilio
Bug#1072740: transition: rtaudio
Control: tags -1 confirmed On 07/06/2024 12:53, IOhannes m zmoelnig wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: rtau...@packages.debian.org Control: affects -1 + src:rtaudio User: release.debian@packages.debian.org Usertags: transition The latest upstream of RtAudio includes a soname bump of libRtAudio. The Debian packages have updated their names accordingly. The new RtAudio has been uploaded to experimental a while ago (last year). A couple of reverse dependencies FTBFS because of some API changes. Bugs have been filed for these packages, along with patches. Some maintainers have already applied these patches, but some are still missing: - #1051567 cubicsdr - #1051556 soapyaudio - #1051564 stk thanks in advance for a transition slot. Go ahead. Emilio
Bug#1072971: kuserfeedback: FTBFS on s390x: OpenGLInfoSourceTest::testOpenGLInfoSource() '!m.value(QLatin1String("vendor")).toString().isEmpty()' returned FALSE
Control: reassign -1 mesa 24.1.1-2
Control: affects -1 kuserfeedback
Control: retitle -1 mesa: fails to initialize OpenGL on s390x: Unexpected
format PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
On 11/06/2024 09:06, Emilio Pozuelo Monfort wrote:
Source: kuserfeedback
Version: 1.3.0-3
Severity: serious
Hi,
During a rebuild for the Qt6 transition, your package failed to build on s390x:
* Start testing of OpenGLInfoSourceTest *
Config: Using QtTest library 5.15.13, Qt 5.15.13 (s390x-big_endian-lp64
shared (dynamic) release build; by GCC 13.2.0), debian unknown
PASS : OpenGLInfoSourceTest::initTestCase()
Mesa 24.1.1-2 implementation error: Unexpected format
PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Please report at https://gitlab.freedesktop.org/mesa/mesa/-/issues
QWARN : OpenGLInfoSourceTest::testOpenGLInfoSource() Unrecognized OpenGL
version
QWARN : OpenGLInfoSourceTest::testOpenGLInfoSource() Unrecognized OpenGL
version
Mesa 24.1.1-2 implementation error: Unexpected format
PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Please report at https://gitlab.freedesktop.org/mesa/mesa/-/issues
FAIL! : OpenGLInfoSourceTest::testOpenGLInfoSource()
'!m.value(QLatin1String("vendor")).toString().isEmpty()' returned FALSE. ()
Loc: [./autotests/openglinfosourcetest.cpp(36)]
Full build log at
https://buildd.debian.org/status/fetch.php?pkg=kuserfeedback=s390x=1.3.0-3%2Bb3=1718075730=0
Actually this looks like a regression in mesa in 24.1. A few rdeps are failing
their autopkgtests with the same PIPE_FORMAT_X8B8G8R8_SRGB error, e.g.:
https://ci.debian.net/packages/k/kodi/testing/s390x/47675600/
https://ci.debian.net/packages/o/openscad/testing/s390x/47689316/
Cheers,
Emilio
Bug#1071235: transition: qt6-base 6.6.2
On 06/06/2024 21:40, Patrick Franz wrote: Hej, Am Donnerstag, 6. Juni 2024, 09:49:59 CEST schrieb Emilio Pozuelo Monfort: [...] Sounds like we're in good shape. You can go ahead. All Qt packages have been uploaded, so you can start with the binNUMs soon. The kuserfeedback s390x build issue is blocking this. Can you take a look at it? From a quick look it looks like the renderer vendor is empty, which could be a regression in mesa. Cheers, Emilio
Bug#1052660: gst-plugins-bad1.0: Fails to build: netsim build test failing
Control: severity -1 important On Mon, 25 Sep 2023 15:52:57 -0400 Jeremy Bicha wrote: Source: gst-plugins-bad1.0 Version: 1.22.4-1 Severity: serious Tags: ftbfs trixie sid Forwarded: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/3000 gst-plugins-bad1.0's elements_netsim build test began failing sometime after July 6 but before August 15 because of a change in its build depends. Also reported as https://launchpad.net/bugs/2037323 I don't see this happening on the Debian buildds from looking at a few old logs. Not sure if it's fixed or if it was specific to some buildd configuration, but for now let's downgrade the bug. Cheers, Emilio
Bug#1072971: kuserfeedback: FTBFS on s390x: OpenGLInfoSourceTest::testOpenGLInfoSource() '!m.value(QLatin1String("vendor")).toString().isEmpty()' returned FALSE
Source: kuserfeedback
Version: 1.3.0-3
Severity: serious
Hi,
During a rebuild for the Qt6 transition, your package failed to build on s390x:
* Start testing of OpenGLInfoSourceTest *
Config: Using QtTest library 5.15.13, Qt 5.15.13 (s390x-big_endian-lp64
shared (dynamic) release build; by GCC 13.2.0), debian unknown
PASS : OpenGLInfoSourceTest::initTestCase()
Mesa 24.1.1-2 implementation error: Unexpected format
PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Please report at https://gitlab.freedesktop.org/mesa/mesa/-/issues
QWARN : OpenGLInfoSourceTest::testOpenGLInfoSource() Unrecognized OpenGL
version
QWARN : OpenGLInfoSourceTest::testOpenGLInfoSource() Unrecognized OpenGL
version
Mesa 24.1.1-2 implementation error: Unexpected format
PIPE_FORMAT_X8B8G8R8_SRGB in st_new_renderbuffer_fb
Please report at https://gitlab.freedesktop.org/mesa/mesa/-/issues
FAIL! : OpenGLInfoSourceTest::testOpenGLInfoSource()
'!m.value(QLatin1String("vendor")).toString().isEmpty()' returned FALSE. ()
Loc: [./autotests/openglinfosourcetest.cpp(36)]
Full build log at
https://buildd.debian.org/status/fetch.php?pkg=kuserfeedback=s390x=1.3.0-3%2Bb3=1718075730=0
Cheers,
Emilio
Bug#1059249: fixed in qt6-base 6.6.2+dfsg-4
Control: reassign -1 qt6-base Control: fixed -1 6.6.2+dfsg-4 Control: affects -1 designer-qt6 On Tue, 27 Feb 2024 18:52:12 + Debian FTP Masters wrote: Source: qt6-base Source-Version: 6.6.2+dfsg-4 Done: Patrick Franz qt6-base (6.6.2+dfsg-4) experimental; urgency=medium . [ Patrick Franz ] * Add B-Ds for XCB. * Do not reduce the amount of relocations (Closes: #1059249). * Clean up cmake-arguments. If this was a bug in qt6-base, then let's reassign it, so that the BTS doesn't keep it open for qt6-tools.
Bug#1072680: bullseye-pu: package rust-cbindgen-web/0.26.0-3~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, This is rust-cbindgen-web for bullseye, following the bookworm update. In bullseye I think we could update src:rust-cbindgen, but that would cause version skew, so let's introduce a separate src building only bin:cbindgen-web. The name follows that of rustc-web, although maybe something like -snapshot or -latest would make more sense, but that's bikeshed territory which I don't want to enter. I'm attaching a debdiff from the bookworm backport. Cheers, Emilio diff -Nru rust-cbindgen-web-0.26.0/debian/changelog rust-cbindgen-web-0.26.0/debian/changelog --- rust-cbindgen-web-0.26.0/debian/changelog 2024-06-05 11:35:17.0 +0200 +++ rust-cbindgen-web-0.26.0/debian/changelog 2024-06-06 12:40:30.0 +0200 @@ -1,3 +1,11 @@ +rust-cbindgen-web (0.26.0-3~deb11u1) bullseye; urgency=medium + + * Backport to bullseye. + * Lower dh-cargo requirement to 24. + * Build with cargo-mozilla. + + -- Emilio Pozuelo Monfort Thu, 06 Jun 2024 12:40:30 +0200 + rust-cbindgen-web (0.26.0-3~deb12u1) bookworm; urgency=medium * Non-maintainer upload. diff -Nru rust-cbindgen-web-0.26.0/debian/control rust-cbindgen-web-0.26.0/debian/control --- rust-cbindgen-web-0.26.0/debian/control 2024-06-05 11:35:17.0 +0200 +++ rust-cbindgen-web-0.26.0/debian/control 2024-06-05 13:07:56.0 +0200 @@ -2,8 +2,8 @@ Section: utils Priority: optional Build-Depends: debhelper (>= 12), - dh-cargo (>= 25), - cargo:native, + dh-cargo (>= 24), + cargo-mozilla:native, rustc-web:native (>= 1.64), libstd-rust-web-dev, help2man,
Bug#1072673: qttools-opensource-src: uses LLVM 15 which is being removed
Source: qttools-opensource-src Version: 5.15.8-2 Severity: important Hi, qttools-opensource-src is building with LLVM 15, which is going to be removed soon. Please switch to a newer version (such as 17), or ideally use the default version, which may be more suitable/stable these days. Cheers, Emilio
Bug#1071235: transition: qt6-base 6.6.2
Control: tags -1 confirmed On 01/06/2024 01:37, Patrick Franz wrote: Hej, Am Freitag, 31. Mai 2024, 09:41:11 CEST schrieb Emilio Pozuelo Monfort: On 16/05/2024 23:34, Patrick Franz wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: delta...@debian.org User: release.debian@packages.debian.org Usertags: transition Hi Release Team, we would like to request a transition for Qt 6 from 6.4.2 to 6.6.2. To prepare for this transition, we tried to build as many reverse dependencies as possible. We encountered some FTBFS, but those failures have either been fixed since or patches are available to make the packages build with Qt 6.6. How many failures are we talking about? Can you make those bugs block this one? Since this transition needs to go into testing in lockstep, we can't start the transition until this is in a good shape. There are 5 failures left in Debian to take care of from what I know: * qtcreator: We split a package into 2 and qtcreator needs to build- depend on both. This cannot be fixed until Qt 6.6 is in unstable. Since the package is maintained in our team, I can fix it myself. * qcoro: Build results in symbol errors and can only be fixed once it is built against 6.6. The package is maintained in our team, so we'll take care of that. * pyotherside: FTBFS against Qt >= 6.5, but a patch is available. I filed a bug against the package and set it as blocking this transition. * dolphin-emu: FTBFS indepedently of the Qt version, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064753. The package has already been removed from testing, so that should not be a problem. * gpsbabel: We encountered test failures when we did the test build. It is likely that this was due to build environment as I could not find any problems at all for this package when building against Qt 6.6. Sounds like we're in good shape. You can go ahead. Cheers, Emilio
Bug#1072626: bookworm-pu: package rust-cbindgen-web/0.26.0-3~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net,
team+pkg-mozi...@tracker.debian.org
Hi,
As usual, we need a newer cbindgen for the upcoming Firefox ESR / Thunderbird
releases. For bookworm though, we can't just upgrade cbindgen, because by
bundling its dependencies, we can't (easily) ship the librust-cbindgen-dev
packages, and that's gained a build-rdep in bookworm.
Thus, I've gone the new source route, building only bin:cbindgen-web, which
conflicts with cbindgen.
I've used this to rebuild firefox-esr_115.11.0esr-1~deb12u1 with success and
the resulting package worked fine on some testing. Thus I'm happy to ship
this now in the upcoming point release, even if the next ESR won't be pushed
to bookworm for a few months.
I'm attaching a debdiff from sid's rust-cbindgen applying this command:
$ debdiff rust-cbindgen_0.26.0-3.dsc rust-cbindgen-web_0.26.0-3~deb12u1.dsc |
filterdiff -x '*/debian/vendor/*'
Cheers,
Emilio
diff -Nru rust-cbindgen-0.26.0/debian/cbindgen.manpages
rust-cbindgen-web-0.26.0/debian/cbindgen.manpages
--- rust-cbindgen-0.26.0/debian/cbindgen.manpages 2024-02-11
03:08:44.0 +0100
+++ rust-cbindgen-web-0.26.0/debian/cbindgen.manpages 1970-01-01
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-debian/cbindgen.1
-
diff -Nru rust-cbindgen-0.26.0/debian/cbindgen-web.manpages
rust-cbindgen-web-0.26.0/debian/cbindgen-web.manpages
--- rust-cbindgen-0.26.0/debian/cbindgen-web.manpages 1970-01-01
01:00:00.0 +0100
+++ rust-cbindgen-web-0.26.0/debian/cbindgen-web.manpages 2024-02-11
03:08:44.0 +0100
@@ -0,0 +1,2 @@
+debian/cbindgen.1
+
diff -Nru rust-cbindgen-0.26.0/debian/changelog
rust-cbindgen-web-0.26.0/debian/changelog
--- rust-cbindgen-0.26.0/debian/changelog 2024-02-11 03:08:44.0
+0100
+++ rust-cbindgen-web-0.26.0/debian/changelog 2024-06-05 11:35:17.0
+0200
@@ -1,3 +1,16 @@
+rust-cbindgen-web (0.26.0-3~deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport to bookworm as rust-cbindgen-web. Since we're vendoring
+the dependencies, we can't easily ship a librust-cbindgen-dev package
+as it's dependencies won't be available, and there are build-rdeps
+for that binary now so we can't just disable it.
+ * Vendor dependencies, they are not available in bookworm.
+ * Only build the cbindgen binary.
+ * Build with rustc-web.
+
+ -- Emilio Pozuelo Monfort Wed, 05 Jun 2024 11:35:17 +0200
+
rust-cbindgen (0.26.0-3) unstable; urgency=medium
* Team upload.
diff -Nru rust-cbindgen-0.26.0/debian/control
rust-cbindgen-web-0.26.0/debian/control
--- rust-cbindgen-0.26.0/debian/control 2024-02-11 03:08:44.0 +0100
+++ rust-cbindgen-web-0.26.0/debian/control 2024-06-05 11:35:17.0
+0200
@@ -1,29 +1,12 @@
-Source: rust-cbindgen
+Source: rust-cbindgen-web
Section: utils
Priority: optional
Build-Depends: debhelper (>= 12),
dh-cargo (>= 25),
cargo:native,
- rustc:native (>= 1.64),
- libstd-rust-dev,
- librust-clap-3+default-dev (>= 3.1-~~),
- librust-heck-0.4+default-dev,
- librust-indexmap+default-dev (>= 1-~~),
- librust-log-0.4+default-dev,
- librust-proc-macro2-1+default-dev (>= 1.0.60-~~),
- librust-quote-1+default-dev,
- librust-serde-1+derive-dev (>= 1.0.103-~~),
- librust-serde-json-1+default-dev,
- librust-syn-1+clone-impls-dev (>= 1.0.88-~~),
- librust-syn-1+extra-traits-dev (>= 1.0.88-~~),
- librust-syn-1+fold-dev (>= 1.0.88-~~),
- librust-syn-1+full-dev (>= 1.0.88-~~),
- librust-syn-1+parsing-dev (>= 1.0.88-~~),
- librust-syn-1+printing-dev (>= 1.0.88-~~),
- librust-tempfile-3+default-dev,
- librust-toml-0.5+default-dev,
+ rustc-web:native (>= 1.64),
+ libstd-rust-web-dev,
help2man,
- librust-serial-test-dev,
cython3
Maintainer: Debian Rust Maintainers
Uploaders:
@@ -34,57 +17,7 @@
X-Cargo-Crate: cbindgen
Rules-Requires-Root: no
-Package: librust-cbindgen-dev
-Architecture: any
-Multi-Arch: same
-Depends:
- ${misc:Depends},
- librust-heck-0.4+default-dev,
- librust-indexmap+default-dev (>= 1-~~),
- librust-log-0.4+default-dev,
- librust-proc-macro2-1+default-dev (>= 1.0.60-~~),
- librust-quote-1+default-dev,
- librust-serde-1+derive-dev (>= 1.0.103-~~),
- librust-serde-json-1+default-dev,
- librust-syn-1+clone-impls-dev (>= 1.0.88-~~),
- librust-syn-1+extra-traits-dev (>= 1.0.88-~~),
- librust-syn-1+fold-dev (>= 1.0.88-~~),
- librust-syn-1+full-dev (>= 1.0.88-~~),
- librust-syn-1+parsing-dev (>= 1.0.88-~~),
- librust-syn-1+printing-dev (>= 1.0.88-~~),
- librust-tempfile-3+default-dev,
- librust-toml-0.5+default-dev
-Recommends:
- librust-cbindgen+clap-dev (= ${binary:Version})
-Provides:
- librust-cbindgen-0-dev (= ${binary:Version}),
- librust-cbindgen-0.26-dev (= ${binary:Version}),
- librust-cbindgen-0.26.0-dev (= ${binary:Version})
-Description
Bug#1072625: nvidia-cuda-toolkit: switch to llvm 17
Source: nvidia-cuda-toolkit Version: 11.8.0-5~deb12u1 Severity: normal Hi, nvidia-cuda-toolkit currently uses llvm 15, but that version is going to be removed as we also have 16, 17 and 18 in sid. Please switch to a newer version. Cheers, Emilio
Bug#1070689: transition: msgpack-c
On 03/06/2024 03:25, James McCoy wrote: On Sun, Jun 02, 2024 at 07:23:39PM -0400, James McCoy wrote: I know libdata-messagepack-stream-perl and tmate already have fixes sitting in the Vcs. The other two are straight forward fixes that I should be able to NMU in the next couple days. Also, binNMUs should use "--add-depends 'libmsgpack-c-dev (>= 6)'" to ensure they rebuild with the new package. Can you instead provide a transitional package? That will help with the rdeps and especially with the reverse build-depends. Effectively once libmsgpack-dev is decrufted, those rdeps will be RC-buggy as they build-depend on a virtual package. The other alternative is to file bugs already for those packages asking to build-dep on libmsgpack-c-dev, in which case we don't need to add the extra-depends. My concern is that any future upload or binNMU for an unrelated reason will pick up libmsgpack-dev. Cheers, Emilio
Bug#1060103: transition: imagemagick7
Hi Bastien, On 02/06/2024 14:38, Bastien Roucariès wrote: Le dimanche 2 juin 2024, 11:17:33 UTC Sebastian Ramacher a écrit : On 2024-02-02 17:21:43 +, Bastien Roucariès wrote: Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit : 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? The problem is not the library but the command line interface that may need change. Librarry will break (I think here about php module that will need a update), but it is treatable. convert6 is not fully compatible with convert7 convert6 will be co installable with convert7 in order to test, and convert will be provided by alternative system. If they are not fully compatible, then alternatives are not an option. They are 95% compatible How many packages are we talking about? Have bugs been filed for packages thar are not compatible with convert7? The problem is chicken and eggs problem. If you could not test then you could not report bug. A least both should be in experimental for running a full archive rebuild Not really. I also don't think the 3-step migration plan in experimental you're proposing makes much sense. What we need here is to know how many packages fail to build against imagemagick 7. And for that, the package doesn't even need to be in experimental. Also, you don't need to perform a full archive rebuild, just rebuilding those packages that build-depend on imagemagick would be enough. Once that is done and we're ready to go, after going through experimental as src:imagemagick (no renamed package), then we would start the transition and scheduled the necessary binNMUs, and raise any bugs to serious. That'd be the ideal scenario. But we don't know how feasible that is until we know how many packages will need source changes, and for that we need the results of the test rebuilds. Cheers, Emilio
Bug#1071614: transition: libmatio13
On 31/05/2024 12:19, Sébastien Villemot wrote: Le vendredi 31 mai 2024 à 09:31 +0200, Emilio Pozuelo Monfort a écrit : On 24/05/2024 19:34, Emilio Pozuelo Monfort wrote: On 22/05/2024 14:49, Sébastien Villemot wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libma...@packages.debian.org Control: affects -1 + src:libmatio User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libmatio.html Dear Release Team, Please schedule a transition for libmatio. I’ve successfully rebuilt all reverse dependencies against the new version (currently in experimental), except gnss-sdr and labplot which are currently unbuildable due to the qt5 transition. Let's wait for the Qt 5 transition then. The Qt 5 transition is over now, so assuming those two packages build against libmatio13, then go ahead with this. It turns out that labplot FTBFS against the new libmatio. I opened a bug and submitted a patch that fixes the issue. Should I upload libmatio to unstable now and then NMU labplot, or should I give some time to the labplot maintainer to react? Either way is fine. You can start the transition now as I believe libmatio can be smooth-updated, so we don't really have to block on labplot. Of course fixing it later if the maintainer doesn't would be good in order to complete the transition. Cheers, Emilio
Bug#1053866: marked as done (transition: jpeg-xl)
Control: reopen -1 On 31/05/2024 12:36, Debian Bug Tracking System wrote: jpeg-xl (0.8.2-4) unstable; urgency=medium . * Upload 0.8.2-4 to unstable. Closes: #1053866 Uploading to unstable doesn't close the transition bug. There are still things to do here, such as binNMUs, and ensuring things migrate to testing. Cheers, Emilio
Bug#1071614: transition: libmatio13
Control: tags -1 confirmed On 24/05/2024 19:34, Emilio Pozuelo Monfort wrote: On 22/05/2024 14:49, Sébastien Villemot wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libma...@packages.debian.org Control: affects -1 + src:libmatio User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libmatio.html Dear Release Team, Please schedule a transition for libmatio. I’ve successfully rebuilt all reverse dependencies against the new version (currently in experimental), except gnss-sdr and labplot which are currently unbuildable due to the qt5 transition. Let's wait for the Qt 5 transition then. The Qt 5 transition is over now, so assuming those two packages build against libmatio13, then go ahead with this. Cheers, Emilio
Bug#1053866: transition: jpeg-xl
Control: tags -1 confirmed On 24/05/2024 19:33, Emilio Pozuelo Monfort wrote: On 23/05/2024 08:15, Mathieu Malaterre wrote: On Sun, May 5, 2024 at 11:43 PM Jeremy Bícha wrote: Control: block -1 by 1061627 I was able to build all the reverse dependencies in Ubuntu 24.04 LTS against jpeg-xl from experimental. But jpeg-xl won't be able to migrate to Testing until its autopkgtests are fixed. https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl Finally fixed today. Sorry for the delay. Let's wait for the ongoing Qt 5 transition. Go ahead. Cheers, Emilio
Bug#1071235: transition: qt6-base 6.6.2
On 16/05/2024 23:34, Patrick Franz wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: delta...@debian.org User: release.debian@packages.debian.org Usertags: transition Hi Release Team, we would like to request a transition for Qt 6 from 6.4.2 to 6.6.2. To prepare for this transition, we tried to build as many reverse dependencies as possible. We encountered some FTBFS, but those failures have either been fixed since or patches are available to make the packages build with Qt 6.6. How many failures are we talking about? Can you make those bugs block this one? Since this transition needs to go into testing in lockstep, we can't start the transition until this is in a good shape. As part of this transition, we also reverted the name changes from the time_t transition for all libraries in qt6-base except the core library which will keep the t64-suffix (libqt6core6t64). We think this is ok since every Qt library depends on libqt6core6t64 and hence depending on libqt6core6t64 signals t64-compatibility. Sounds fair to me. The Ben file for the transition is attached. Added to the tracker, should appear shortly in [1]. Cheers, Emilio [1] https://release.debian.org/transitions/html/qt6-base.html
Bug#1072035: bookworm-pu: package dns-root-data/2024041801
On 30/05/2024 14:14, Marco d'Itri wrote: On May 27, Jonas Meier wrote: [ ] attach debdiff against the package in (old)stable This looks reasonable to me. Should a similar update be proposed for bullseye? Cheers, Emilio
Bug#1063770: transition: mupdf
Control: tags -1 confirmed On 25/05/2024 16:52, Bastian Germann wrote: On Sun, 5 May 2024 18:29:52 +0200 Sebastian Ramacher wrote: > 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? The packages are prepared in experimental. I'm not sure there's anything for us to do here, as this is not really a library transition as you say. But in any case, go ahead and let us know if there's anything for us to do. Cheers, Emilio
Bug#1053866: transition: jpeg-xl
On 23/05/2024 08:15, Mathieu Malaterre wrote: On Sun, May 5, 2024 at 11:43 PM Jeremy Bícha wrote: Control: block -1 by 1061627 I was able to build all the reverse dependencies in Ubuntu 24.04 LTS against jpeg-xl from experimental. But jpeg-xl won't be able to migrate to Testing until its autopkgtests are fixed. https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl Finally fixed today. Sorry for the delay. Let's wait for the ongoing Qt 5 transition. Cheers, Emilio
Bug#1071614: transition: libmatio13
On 22/05/2024 14:49, Sébastien Villemot wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libma...@packages.debian.org Control: affects -1 + src:libmatio User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libmatio.html Dear Release Team, Please schedule a transition for libmatio. I’ve successfully rebuilt all reverse dependencies against the new version (currently in experimental), except gnss-sdr and labplot which are currently unbuildable due to the qt5 transition. Let's wait for the Qt 5 transition then. Cheers, Emilio
Bug#1061179: transition: qtbase-abi-5-15-13
On 24/05/2024 18:16, Dmitry Shachnev wrote: Hi Sebastian! On Mon, May 20, 2024 at 08:04:02PM +0200, Sebastian Ramacher wrote: Control: tags -1 confirmed Please go ahead I see that now all packages except gammaray built successfully. I think you can rebuild gammaray too. Its FTBFS bug is only about a flaky test, it should still build fine, maybe after retries on some architectures. I have some work in progress to update gammaray to the new upstream version, but that needs to wait for Qt 6.6 and KDE Frameworks 6 in unstable first. Scheduled. P.S. Also, upstream published Qt 5.15.14 and Qt WebEngine 5.15.17 this week. I will probably skip this Qt release, but maybe I will ask you for a Qt WebEngine mini-transition which will need rebuilds of two packages. Sure. btw not sure what to do about qtbase-opensource-src's reverse autopkgtests[1]. Looks like they are having some trouble installing the right dependencies from unstable. Perhaps they hadn't been rebuilt yet when the tests were scheduled. Paul, do you have any ideas? Cheers, Emilio [1] https://tracker.debian.org/pkg/qtbase-opensource-src
Bug#1070852: transition: gdal
On 24/05/2024 11:02, Sebastiaan Couwenberg wrote: On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote: If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. gdal, grass, and libgdal-grass just need to be tested together. I'd rather drop the autopkgtest test than having to maintain the Breaks in gdal. *shrug*. If that's a runtime check, then there's an issue with the dependencies/breaks, as one could have old libgdal-grass with newer gdal (as is happening in the autopkgtest) and then libgdal-grass is broken. If it's a check that's being done in libgdal-grass, then maybe that check can be dropped? With the information that autopkgtest has, the current situation is broken and testing migration will be (rightly) blocked. Cheers, Emilio
Bug#1069679: Debian Bugs information: logs for Bug#1069679
Hi Mike, On 24/05/2024 09:39, Hector Oron wrote: Hello Mike, On Fri, 24 May 2024 at 08:57, Mike Gabriel wrote: If noone plans to fix Ofono in Debian within the next 1-2 weeks, I'd like to do a team upload. In that case, could any of you give me access to https://salsa.debian.org/telepathy-team (or just the ofono repo in there). I tried but I do not have enough permissions to add you. You'll need Emilio or Laurent for that. I'm not really active on the telepathy stack anymore. I have granted you access to the team, feel free to take a look at ofono and any other stuff that needs some love. Cheers, Emilio
Bug#1070852: transition: gdal
On 22/05/2024 21:25, Sebastiaan Couwenberg wrote: On 5/22/24 8:40 AM, Emilio Pozuelo Monfort wrote: Go ahead. Thanks. gdal (3.9.0+dfsg-1) has been uploaded to unstable and is now built & installed on all release architectures. binNMUs scheduled. libdal-grass autopkgtests are failing for the version in testing with gdal from sid, apparently there's some runtime detection preventing that combination[1]: 32s autopkgtest [16:10:14]: test gdalinfo-ogrinfo: [--- 35s ERROR 1: OGR/GRASS driver was compiled against GDAL 3.8, but the current library version is 3.9 35s ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.8, but the current library version is 3.9 35s ERROR 4: `./spearfish60_grass7/PERMANENT/cellhd/geology' not recognized as being in a supported file format. [1] https://ci.debian.net/packages/libg/libgdal-grass/testing/amd64/46934033/ If that's the case, gdal should probably break older versions of libgdal-grass so that that combination is not possible. That will also make britney happy, otherwise it will block gdal due to the test regression. Cheers, Emilio
Bug#1071620: libchicken-dev: depends on obsolete libpcre3-dev package
Package: libchicken-dev Version: 5.3.0-1.1 Severity: serious Hi, pcre3 is being removed. libchicken-dev depends on libpcre3-dev, however it looks like that dependency is unused. The headers don't mention it and pcre3 support was removed in version 4.8.0.5-1 (bug #729144). Looks like libpcre3-dev was only removed from build-depends but not from libchicken-dev's depends. Cheers, Emilio
Bug#1071618: kannel-dev: depends on obsolete libpcre3-dev
Package: kannel-dev Version: 1.4.5-16 Severity: serious Hi, kannel-dev depends on libpcre3-dev, which is going to be removed. Given pcre3 support was removed in 1.4.5-13, that dependency can probably just go away. Cheers, Emilio
Bug#1071476: neochat: Neochat will not start, due to old kirigami-addons
On Mon, 20 May 2024 01:04:01 +0200 "Salvo \"LtWorf\" Tomaselli" wrote: Package: neochat Version: 23.08.5-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: ltw...@debian.org Dear Maintainer, neochat won't start. I have uploaded kirigami-addons, and made a new upload of neochat. This bug is so that it will not migrate. Should this be marked as fixed in 23.08.5-2 ? Cheers, Emilio
Bug#1070977: transition: snappy
On 13/05/2024 17:42, László Böszörményi (GCS) wrote: On Mon, May 13, 2024 at 2:04 PM Emilio Pozuelo Monfort wrote: Why is there a libsnappy1v5 transitional package? Serves several purposes. As noted, upstream soname is _not_ changed, so I can't let the old library package be present as it would contain the same named library file conflicting with the one in the new, normally named library package name. In short, I must do a file move between packages. Then the old libsnappy1v5 package has a conflict with the then old libsnappy1 package name. Thus this conflict needs to be removed. Also has upstream been contacted in order to do a proper SONAME bump? Otherwise libsnappy1 will have to conflict with libsnappy1v5, and that will make both the transition and upgrades harder, as they have to be done in lockstep. If they broke the ABI, then a SONAME bump is in order, and that will make it easier for us too. Yup, in such cases a soname bump is needed. Then upstream is Google and as I remember years back I had a somewhat similar problem with one of their library package. If I'm correct, I got a similar answer that in such cases they just recompile the dependent sources and don't change the soname. Then the public source tree is hosted on GitHub [1] without the issues (report) area enabled. The AUTHORS file contains a general email address (opensou...@google.com) [2] meaning I'm not sure if I get any answer or I will get one soon. But I can try it if you insist. Looks like this got reported upstream and the symbols got re-added: https://github.com/google/snappy/issues/183 https://github.com/google/snappy/commit/465b5b60ca410436fa663700c4656ea8f7bf2a95 If that's enough, I assume the package renaming in experimental can be reverted and we just update to snappy 1.2.1, keeping the old library package name. Cheers, Emilio
Bug#1070659: transition: re2
Control: tags -1 confirmed On 06/05/2024 19:09, Stefano Rivera wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: r...@packages.debian.org Control: affects -1 + src:re2 User: release.debian@packages.debian.org Usertags: transition Control: block -1 with 1070649 1053409 It has taken a while to prepare the next re2 transition, because it included a new dependency on abseil. This broke most of the reverse-dependencies. It also means that transitions will get more frequent, as every abseil transition will change re2's ABI. I think the state of the reverse-dependencies is reasonable, now. I just did a rebuild of them all, and got these failures: Go ahead. Cheers, Emilio
Bug#1071473: transition: opencascade
Control: tags -1 confirmed On 19/05/2024 23:08, Tobias Frost wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: opencasc...@packages.debian.org Control: affects -1 + src:opencascade User: release.debian@packages.debian.org Usertags: transition Control: block 1071284 by -1 Control: block 1071223 by -1 Control: block 1071470 by -1 Control: block 1071451 by -1 Control: block 1071471 by -1 Hi Release team, opencascade has a new release with breaking ABI, upstream versionied them as 7.8. The transition tracker [1] correctly picked it up already after the upload to experimental. [1] https://release.debian.org/transitions/html/auto-opencascade.html building the reverse depenencies most FTBFS due to library naming changes, but I was able to come up with patches for most, but they will require sourceful uploads. Freecad will require either backporting the upstream fixes or package a new upstream snapshot. This is the result of the compilation tests: Dependency level 2: f3d ✔ freecad (sid only) FTBFS, fixed in upstream git. horizon-eda patch available, #1071284 kicad ✔ netgen patch available, #1071223 slic3r-prusa (sid only) patch available, #1071470 Dependency level 3: gmshpatch available, #1071451 Dependency level 4: deal.ii patch available, #1071471 Will you help upload those fixes? Perhaps through delayed NMUs or team uploads? If so, go ahead. Cheers, Emilio
Bug#1071577: transition: libcamera 0.3.0
Control: tags -1 confirmed On 21/05/2024 15:25, 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.3.0. The auto-generated ben tracker looks good: https://release.debian.org/transitions/html/auto-libcamera.html The unique reverse dep (pipewire 1.0.6-1) builds fine with libcamera 0.3.0 in experimental. Go ahead. Cheers, Emilio
Bug#1070852: transition: gdal
Control: tags -1 confirmed On 10/05/2024 16:09, Bas Couwenberg wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html For the Debian GIS team I'd like to transition to GDAL 3.8.0. All reverse dependencies except python-django and facet-analyser rebuilt successfully with GDAL 3.9.0 from experimental as summarized below. python-django (3:4.2.11-1) FTBFS due to unrelated test failures. (#1042637) facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS due to uninstallable build dependencies. (#1040334) Bugreports can be found using the gdal-3.9 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=gdal-3.9 Transition: gdal libgdal34t64 (3.8.5+dfsg-1) -> libgdal35 (3.9.0~beta1+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.6-1) OK gmt (6.5.0+dfsg-3)OK grass (8.3.2-1) OK libcitygml (2.5.2-1) OK libgeo-gdal-ffi-perl(0.11-2) OK libosmium (2.20.0-1)OK mapcache(1.14.0-4)OK mapnik (3.1.0+ds-7) OK mapproxy(2.0.2+dfsg-1)OK mapserver (8.0.1-4) OK merkaartor (0.19.0+ds-5) OK mysql-workbench (8.0.32+dfsg-2) OK ncl (6.6.2.dfsg.1-7) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.2+dfsg-6) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-6)OK postgis (3.4.2+dfsg-1)OK python-django (3:4.2.11-1) FTBFS (#1042637) qmapshack (1.17.1-1)OK r-cran-sf (1.0-15+dfsg-1) OK r-cran-terra(1.7-65-1)OK rasterio(1.3.10-2)OK saga(9.4.0+dfsg-1)OK vtk9(9.1.0+really9.1.0+dfsg2-7.1) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS (#1040334) libgdal-grass (1:1.0.2-7) OK opencv (4.6.0+dfsg-13.1) OK osmcoastline(2.4.0-2) OK qgis(3.34.6+dfsg-1) OK sumo(1.18.0+dfsg-3) OK Go ahead. Emilio
Bug#1071558: gst-plugins-bad1.0-contrib: rebuild against t64 libraries
Source: gst-plugins-bad1.0-contrib Version: 1.20.0-1 Severity: normal Hi, While this package only builds on i386 and amd64, where t64 libs also provide the old names, it'd still be nice to have this package rebuilt to ease the transitions, as it shows on the cruft reports when trying to remove e.g. libglib2.0-0 which is no longer built. Thanks, Emilio
Bug#1071557: RM: maptool [armel armhf i386] -- RoQA; not built on 32-bit arches
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: na...@packages.debian.org Control: affects -1 + src:navit Hi, maptool isn't built on 32-bit arches, but it hasn't been detected by the cruft report, perhaps because it still has 'Architecture: any' and relies on a dh option in d/rules to skip that binary. Please remove the package from those architectures. Cheers, Emilio
Bug#1071502: RM: gssdp-tools [i386] -- ROM; no longer built on i386
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gs...@packages.debian.org Control: affects -1 + src:gssdp Hi, gssdp-tools hasn't been built on i386 for a while. Please drop the binary which has no rdeps afaict. Thanks, Emilio
Bug#1068915: RM: libgrss - dead upstream, depends on obsolete libsoup2.4, not needed
reassign 1068915 ftp.debian.org user ftp.debian@packages.debian.org usertags 1068915 remove thanks Hi Alexandre, On Sat, 13 Apr 2024 12:21:43 +0200 Alexandre Detiste wrote: Source: libgrss Version: 0.7.0-2.1 Severity: normal X-Debbugs-Cc: debian...@lists.debian.org, Graham Inggs Hi, Everything is in the title :-) Here are more pointers: https://release.debian.org/transitions/html/libsoup3.html https://qa.debian.org/popcon.php?package=libgrss https://gitlab.gnome.org/GNOME/libgrss/-/commits/master This looks like a RM bug. Thus it should be assigned to the ftp.debian.org pseudo-package. Cheers, Emilio
Bug#1071121: transition: clamav
Control: tags -1 moreinfo On 14/05/2024 19:49, Sebastian Andrzej Siewior wrote: Package: release.debian.org Control: affects -1 + src:clamav X-Debbugs-Cc: cla...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition Severity: normal ClamAV 1.3.x has a new soname. I have the in package in experimental with libclamav12t64. I would like to go back to libclamav12 (there is already libclamav11t64 so I don't think there is a need to keep the t64 suffix any longer). The impact is small, three packages in main which I test-built and libclamunrar in non-free which I need to upload manually. I can pre-upload the libclamav12 to experimental to avoid the new queue if this is preferred. Yes, go through experimental if you want to rename it. You'll have to add proper conflicts/etc. Let us know once the package is accepted in experimental. Cheers, Emilio
Bug#1061188: transition: python3-defaults (making python3.12 the default python3 version)
Hi Matthias, On 20/01/2024 15:41, Matthias Klose wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Please setup a tracker for the python3-defaults transition, making 3.12 the default Python version. What's the current status? Has a mass-build been done with python3-defaults from experimental? Cheers, Emilio
Bug#1071148: python3-rpm: only builds for the default python version
Package: python3-rpm Version: 4.19.1.1+dfsg-1 Severity: normal Hi, Looking at the python 3.12 transition tracker, I noticed that python3-rpm was listed as being incomplete. Upon inspection of the build log, I saw that while rpm build-depends on python3-all-dev (which is normally done in order to build for all supported python3 versions) rpm only builds for the default one. It'd help to build for all supported versions, but if that's not realistic, then the package should just build-dep on python3-dev. Cheers, Emilio
Bug#1071147: bluez: autopkgtests fail due to lack of devices
Package: bluez Version: 5.73-1 Severity: serious Hi, The new autopkgtests added in 5.73-1 are failing on ci.debian.net: autopkgtest [03:11:41]: test bluez-response: [--- testAdapter (__main__.TestBluezResponse.testAdapter) ... Can't open HCI socket.: Address family not supported by protocol skipped 'No bluetooth devices available for testing' testDevice (__main__.TestBluezResponse.testDevice) ... Can't open HCI socket.: Address family not supported by protocol skipped 'No bluetooth devices available for testing' This is blocking testing migration. If this can't be fixed in the short term by adding some type of restriction to the autopkgtest or by mocking the devices, then the tests should be removed until they can be made to work on our infrastructure. Cheers, Emilio
Bug#1071145: lxqt-menu-data: breaks lxqt-panel
Package: lxqt-menu-data Version: 1.4.1-2 Severity: serious Hi, Your package breaks/replaces lxqt-panel (<< 1.4), however the latest lxqt-panel in sid is 1.3.0-1. This means that those packages cannot be co-installed atm, which is making lxqt-core uninstallable now. If the reason for this breaks/replaces was to take over some files from lxqt-panel, then a new version of lxqt-panel should be uploaded with a high enough version and without those files. In a fresh sid chroot: root@andromeda:/# apt install lxqt-core Unsatisfied dependencies: lxqt-menu-data : Breaks: lxqt-panel (< 1.4) but 1.3.0-1+b1 is to be installed Cheers, Emilio
Bug#1069536: glib-d: FTBFS on armel: unsatisfiable build-dependencies: dh-dlang (>= 0.6.2), gir-to-d (>= 0.23.2)
Control: found -1 2.4.3-1 Hi, On Sat, 20 Apr 2024 15:22:43 +0200 Lucas Nussbaum wrote: Source: glib-d Version: 2.4.3-2 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel Hi, During a rebuild of all packages in sid, your package failed to build on armel. Relevant part (hopefully): > sbuild-build-depends-main-dummy : Depends: dh-dlang (>= 0.6.2) but it is not going to be installed >Depends: gir-to-d (>= 0.23.2) but it is not installable > E: Unable to correct problems, you have held broken packages. > apt-get failed. This is because dh-dlang / gir-to-d no longer support armel and have been removed, see #1068983. I guess glib-d should be removed from armel as well. Cheers, Emilio
Bug#1071110: libjson-glib-dev: ships installed tests, causing b-d cycles
Package: libjson-glib-dev
Version: 1.8.0-2
Severity: serious
Hi,
libjson-glib-dev ships tests in /usr/lib/x86_64-linux-gnu/installed-tests/,
which makes the package get a dependency on libglib2.0-0t64 through
shlibs:Depends. That in turn causes b-d cycles, e.g. for fcitx-kkc on
arm{el,hf}:
fcitx-kkc build-depends on:
- libjson-glib-dev:armel
libjson-glib-dev depends on:
- libglib2.0-0t64:armel (>= 2.77.0)
fcitx-kkc build-depends on:
- libkkc-dev:armel
libkkc-dev depends on:
- libkkc2:armel (= 0.3.5-8)
libkkc2 depends on:
- libglib2.0-0:armel (>= 2.38.0)
libglib2.0-0t64 conflicts with:
- libglib2.0-0:armel (< 2.80.0-7~)
Splitting the tests into a json-glib-tests package would help break this
cycle.
Cheers,
Emilio
Bug#1070447: sdpa: dependency generation does not account for t64 changes
On Sun, 5 May 2024 15:35:40 +0200 Sebastian Ramacher
wrote:
Source: sdpa
Version: 7.3.16+dfsg-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Dependencies on libmumps-seq are produced using ${mumps-seq:Version}
which does not include the changes from the t64 transition. Please adopt
the dependency generation accordingly.
From what I can see, libmumps-seq is statically linked into the sdpa binary.
Why is it not dynamically linked, like everything else? If it needs to be
statically linked, why do we need a dependency on the shared library package?
Instead of that, we should probably add a built-using field to the binary
package, so that rebuilds can be scheduled when libmumps-seq changes, so that
the statically-linked library gets updated.
Cheers,
Emilio
Bug#1070977: transition: snappy
On 12/05/2024 11:36, László Böszörményi (GCS) wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:snappy Hi RMs, Upstream of snappy changed function signatures [1] breaking other applications with the 1.2.0 release. I've added back the original function signatures calling the new ones to restore the immediate problem, to restore the ABI. But then this creates ambiguity in the Compress method signatures [2] making (only) ceph FTBFS. While it can be patched to avoid it, a proper transition should be done. I've renamed back the library name which was done due to the C++11 ABI change with g++ 5.0 back in 2015. Why is there a libsnappy1v5 transitional package? Also has upstream been contacted in order to do a proper SONAME bump? Otherwise libsnappy1 will have to conflict with libsnappy1v5, and that will make both the transition and upgrades harder, as they have to be done in lockstep. If they broke the ABI, then a SONAME bump is in order, and that will make it easier for us too. Cheers, Emilio
Bug#1065281: evolution-data-server: missing dpkg-dev (>= 1.22.5) build dependnecy for time_t transition
Control: notfound -1 3.51.2-1 Control: found -1 3.50.3-2 Control: fixed -1 3.50.3-2.1 On Sat, 2 Mar 2024 11:53:00 +0100 Sebastian Ramacher wrote: Source: evolution-data-server Version: 3.51.2-1 Severity: serious X-Debbugs-Cc: sramac...@debian.org, vor...@debian.org Thank you for uploading the changes required for the time_t transition. Unfortunately, the upload was missing dpkg-dev (>= 1.22.5) in Build-Depends. This leads to two potential issues: * The package is built with the wrong ABI. * The package migrates to testing before the change is enabled in testing and builds there would be produced against the wrong ABI. Please add dpkg-dev (>= 1.22.5) to Build-Depends and upload the new version ASAP. I believe the found version here was wrong. It should have been against the uploaded version to unstable at the time, which was subsequently fixed in 3.50.3-2.1. Updating this to un-confuse the BTS and britney. Cheers, Emilio
Bug#1070799: bullseye-pu: package rustc-web/1.70.0+dfsg1-7~deb11u1
On 12/05/2024 13:09, Jonathan Wiltshire wrote: Control: tag -1 confimed moreinfo Hi, On Thu, May 09, 2024 at 12:36:16PM +0200, Emilio Pozuelo Monfort wrote: rustc-web is needed to keep supporting firefox-esr/thunderbird on bullseye, for the upcoming ESR 128 releases. Instead of updating rustc-mozilla, I decided to backport the newer rustc-web (adopting that name) from bookworm. The backport is clean, just a changelog bump. I'm attaching the debdiff from the bookworm update to this one. Should rustc-mozilla be removed from oldstable as well as rustc-web introduced? Only if we can switch current versions of firefox-esr/thunderbird to use it. Alternatively I could rename this back to rustc-mozilla if that's preferred (again assuming current versions are happy with it, as the new versions won't be uploaded until around September). Cheers, Emilio
Bug#1060019: transition: poppler 24.02
Control: tags -1 confirmed On 05/05/2024 23:33, Jeremy Bícha wrote: Control: retitle -1 transition: poppler 24.02 Control: affects -1 src:poppler Since originally requesting this transition, I have updated the version to 24.02. I believe all reverse dependencies can be binNMU'd for this. Go ahead. Emilio
Bug#1069254: nwipe: FTBFS: configure: error: libconfig library not found
On Mon, 29 Apr 2024 16:56:55 +0200 "M. van Brummelen" wrote: Hi, On 2024-04-29 10:28, Bo YU wrote: > Tags: patch > > hi, > On Thu, Apr 18, 2024 at 10:00:30PM +0200, Sebastian Ramacher wrote: >> >> checking for libconfig... no >> checking for main in -llibconfig... no >> configure: error: libconfig library not found > > It seems it shuold use libconfig-dev. Thanks didn't have the time to test/verify this yet. Will test/fix and upload in a few days. You should also look at doing source-only uploads. The current package, even if it had built fine, wouldn't have migrated to testing due to the source+amd64 upload: $ grep-excuses nwipe [...] Issues preventing migration: ∙ ∙ Updating nwipe would introduce bugs in testing: #1069254 ∙ ∙ Not built on buildd: arch amd64 binaries uploaded by mart...@brumit.nl Cheers, Emilio
Bug#1066831: tagging 1066831
Hi Wouter, On Wed, 03 Apr 2024 14:17:38 +0200 Wouter Verhelst wrote: tags 1066831 + upstream fixed-upstream pending thanks Can we have a fix for this in sid? That would help with some ongoing transitions, and probably with some installability issues on arm* on testing. Thanks, Emilio
Bug#1070799: bullseye-pu: package rustc-web/1.70.0+dfsg1-7~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, rustc-web is needed to keep supporting firefox-esr/thunderbird on bullseye, for the upcoming ESR 128 releases. Instead of updating rustc-mozilla, I decided to backport the newer rustc-web (adopting that name) from bookworm. The backport is clean, just a changelog bump. I'm attaching the debdiff from the bookworm update to this one. Package is already uploaded, but if you find any issues feel free to reject it. Hopefully this can make it into the final bullseye point release. I've successfully used this to build a backport of cbindgen and then firefox 125, which works well. A cbindgen pu for both bookworm and bullseye will be proposed later once I verify that it doesn't cause any issues to current ESR 115. Thanks, Emilio diff -Nru rustc-web-1.70.0+dfsg1/debian/changelog rustc-web-1.70.0+dfsg1/debian/changelog --- rustc-web-1.70.0+dfsg1/debian/changelog 2024-03-02 08:23:15.0 +0100 +++ rustc-web-1.70.0+dfsg1/debian/changelog 2024-04-29 11:08:43.0 +0200 @@ -1,3 +1,10 @@ +rustc-web (1.70.0+dfsg1-7~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye. + + -- Emilio Pozuelo Monfort Mon, 29 Apr 2024 11:08:43 +0200 + rustc-web (1.70.0+dfsg1-7~deb12u2) bookworm; urgency=medium * Non-maintainer upload.
Bug#1070751: transition: libxlsxwriter
Control: tags -1 confirmed On 08/05/2024 15:40, Boyuan Yang wrote: Package: release.debian.org Control: affects -1 + src:libxlsxwriter X-Debbugs-Cc: libxlsxwri...@packages.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: by...@debian.org Severity: normal I would like to launch the transition as listed below: * https://release.debian.org/transitions/html/auto-libxlsxwriter.html The transition is triggered by the SONAME bump. List of all affected packages: * src:deepin-log-viewer (OK) * src:readstat (OK) All reverse build-dependencies can be successfully rebuilt with the new libxlsxwriter. Go ahead. Emilio
Bug#1070703: transition: libunibreak
Control: tags -1 confirmed On 07/05/2024 15:52, Pino Toscano wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for the update of the libunibreak library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in this case there are only few new symbols. There are few users of libunibreak in Debian: - fbreader - krita - libass I verified that all of them build fine using the new version of libunibreak. Go ahead. Emilio
Bug#1070698: transition: ticcutils
Control: tags -1 confirmed On 07/05/2024 14:21, Bastian Germann wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: ticcut...@packages.debian.org Control: affects -1 + src:ticcutils Control: forwarded -1 https://release.debian.org/transitions/html/auto-ticcutils.html User: release.debian@packages.debian.org Usertags: transition I am requesting a transition slot for ticcutils. The experimental version builds libticcutils9 while the unstable version has libticcutils8t64. The referenced tracker is okay. All reverse dependencies build with the experimental version (where an experimental version exists, it is the one that builds with libticcutils9). Go ahead. Emilio
Bug#1069285: trixie-pu: package flatpak/1.14.6-1~deb13u1
Control: tags -1 confirmed On 19/04/2024 12:49, Simon McVittie wrote: Package: release.debian.org Severity: normal Tags: trixie User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: flat...@packages.debian.org Control: affects -1 + src:flatpak [ Reason ] Fix CVE-2024-32462, a sandbox escape vulnerability, without having to wait for the whole 64-bit time_t transition. [ Impact ] If not fixed, malicious or compromised Flatpak apps can execute arbitrary code on the host system. (Severity: grave) The new upstream release also fixes one high-visibility non-security bug: after some infrastructure changes on Flathub, the flatpak(1) CLI currently mis-displays apps' developer names as though they were the name of the app, for example showing org.chromium.Chromium as "The Chromium Authors" instead of the correct "Chromium Web Browser". The proposed version corrects this. (Severity: important) [ Tests ] Flatpak has a rather large test suite, which still passes. Unfortunately, most tests have to be skipped when running under schroot or lxc because those frameworks don't allow creating a nested user namespace, but I do run the autopkgtest suite under autopkgtest-virt-qemu before uploading. There is new automated test coverage for CVE-2024-32462 and for the mis-display of app names. I'll do a smoke-test on a trixie GNOME VM (install an app, run an app, and verify that CVE-2024-32462 is fixed) before uploading. Please go ahead once you're ready, and let us know so that we can hint it into testing. Cheers, Emilio
Bug#1060407: gtkwave update for {bookworm,bullseye,buster}-security
On 29/03/2024 00:06, Adrian Bunk wrote:
Hi,
attached are proposed debdiffs for updating gtkwave to 3.3.118 in
{bookworm,bullseye,buster}-security for review for a DSA
(and as preview for buster).
General notes:
As suggested by the security team in #1060407, this is a backport of a
new upstream version to fix the 82 CVEs.
I checked a handful CVEs, and they were also present in buster.
If anyone insists that I check for every single CVE whether it is also
in buster I can do that, but that would be a lot of work.
As already mentioned in #1060407, the ghwdump tool (and manpage) was
dropped in 3.3.110 from the upstream sources, and is now in ghdl-tools.
For bullseye and buster it is therefore readded.
As mentioned in #1060407 there are different tarballs for GTK 2 and GTK 3.
Looking closer I realized that this is actually one tarball that
supports GTK 1+2, and one tarball that supports GTK 2+3.
I did stay at the GTK 1+2 tarball that was already used before
for bullseye and buster since there was anyway a different upstream
tarball required for the +really version that is required to avoid
creating file conflicts with ghwdump when upgrading to bookworm.
What does the security team consider the best versioning for bullseye?
In #1060407 I suggested 3.3.104+really3.3.118-0.1, but now I ended up
preferring 3.3.104+really3.3.118-0+deb11u1
I saw this earlier but I couldn't think of a better versioning scheme, though
this looked awkward. Now I have thought of a (possibly) better one, so I'm
stating it here in case we find ourselves in a similar situation in the future
and someone remembers this thread.
I would have gone with
3.3.118-0.1~deb12u1
3.3.118+gtk2-0+deb11u1
3.3.118+gtk2-0+deb10u1
Similar to how we do +dfsg or +repack. The +really is usually used for going
back without adding an epoch, but here we're going forward, so perhaps such a
naming would have made more sense. It also makes it clearer why there's a
different tarball.
Cheers,
Emilio
Bug#1065540: libxdmcp6: Please rebuild to avoid overly huge ELF segment alignment
Hi Mathias, On 06/03/2024 13:06, Mathias Krause wrote: Package: libxdmcp6 Version: 1:1.1.2-3 Severity: normal X-Debbugs-Cc: mini...@grsecurity.net Dear Maintainer, After investigating ELF binaries and libraries on Debian systems, I noticed that libxdmcp6 uses an overly huge alignemnt for its segments. This will lead to an unnecessary ASLR degradation for (transitive) users of this library like xserver-xorg-core, lightdm, cinnamon-session, cinnamon-settings-daemon, pipewire-bin and many others. Below is the relevant output: minipli@bell:~/src/paxtest (master)$ ./contrib/check_align.sh /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 (max align=0x20) minipli@bell:~/src/paxtest (master)$ readelf -Wl /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 | grep -B2 LOAD Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x 0x 0x0046c4 0x0046c4 R E 0x20 LOAD 0x004de0 0x00204de0 0x00204de0 0x000308 0x000310 RW 0x20 The cause for the excessive segment alignment of 2MB instead of the usual 4kB is binutils' ld which did, from versions v2.11 up to v2.30 (in Debian, at least), use a huge default, even if no segment required such a huge alignment. That was fixed in Debian with the release of buster, which makes use of binutils v2.31+. The full technical background behind overly huge alignment was reported here: https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr Rebuilding the package will implicitly make use of a recent version of ld and thereby fix the issue which is what I'm herby requesting. I don't know if there are many more bugs like this (I only noticed three), if there are, this should have been discussed in debian-devel@, see [1]. The solution to this is to request rebuilds to the Release team. Could you email debian-release@ with a summary of the problem and a list of packages (and possibly architectures) that need to be rebuilt? Cheers, Emilio [1] https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.en.html#reporting-lots-of-bugs-at-once-mass-bug-filing
Bug#1063446: libmozjs-115-dev: cannot call JS::CanonicalizeNaN(double) on mips64el
Hi Simon, On 08/02/2024 21:59, Simon McVittie wrote: On Thu, 08 Feb 2024 at 10:37:33 +, Simon McVittie wrote: Package: libmozjs-115-dev Justification: makes gjs FTBFS (#1063433) I believe mozjs115_115.7.0-3 should fix this. wb-team: Please could someone with wanna-build access schedule gjs on mips64el to be built after the fixed version of mozjs115 becomes available? I believe the correct spelling is: dw gjs_1.78.3-1 . unstable . mips64el . -m 'libmozjs-115-dev (>= 115.7.0-3)' mozjs115 is already built, so I just gave gjs back. Cheers, Emilio
Bug#1053702: NIST data feed to be retired in December 2023
Control: forwarded -1 https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/155 On 02/11/2023 07:01, Salvatore Bonaccorso wrote: Control: tags -1 + confirmed Hi, On Mon, Oct 09, 2023 at 11:48:59AM +0200, Bastian Blank wrote: Package: security-tracker Severity: important The security tracker currently uses the JSON feeds as linked from https://nvd.nist.gov/vuln/data-feeds. Those data feeds will be retired on December, 15th 2023, so in a bit more then two months. After that the information will be only available via the API. See also the announcement: https://nvd.nist.gov/General/News/change-timeline Thanks. TTBOMK, but will have to check, we only nowdays use the NVD feed for the descriptions. If that's the case we will switch to the MITRE provided feeds as we use for the rest already. Done in the above MR. Cheers, Emilio
Bug#1057540: transition: ace
Control: tags -1 confirmed On 05/12/2023 22:45, 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.2+dfsg-1 in experimental. The autogenerated ben tracker looks good. Please consider 'ace' for transition. Thanks in advance. Go ahead. Cheers, Emilio
Bug#1057376: symbols marked as hidden causes FTBFS in pixmap
Control: forwarded -1 https://gitlab.freedesktop.org/xorg/lib/libxpm/-/issues/5 On 04/12/2023 09:05, Paul Slootman wrote: Source: libxpm Version: 1:3.5.17-1 Severity: important Tags: patch commit 7f60f3428aa21d5d643eb75bfd9417cfabf48970 on libxpm hides a number of symbols. However a couple of these symbols are used in pixmap, causing a FTBFS on pixmap. These symbols are xpmReadRgbNames and xpmGetRgbName, xpmFreeRgbNames is related. I have confirmed that applying this patch lets pixmap compile successfully. Those symbols were not exposed in any header, so pixmap using those was rather hackish. See the upstream ticket. Cheers, Emilio
Bug#1056574: transition: ppp
On 23/11/2023 11:54, Chris Boot 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:ppp Hello Release Team friends, I uploaded ppp-2.5.0-1+1 to experimental back in September, and I think it's time to unleash it on unstable, ideally in the next few days. This is an ABI break both due to the new upstream version but there are also significant changes in this release that may break dependent packages. Any way to reduce possible breakage, or to detect and fix it before the transition starts? Like rebuilding rdeps, or checking rdep autopkgtests? The upload I'm planning, 2.5.0-1+2, only has a minor fix for loong64 and a changelog fix. As usual this isn't a traditional library package upload so the Ben file looks a bit foreign. See #890204 for a previous time we did this. I have added a tracker, should appear in an hour or two. Cheers, Emilio
Bug#972761: Please disable telemetry data submission by default
Hi Michael, Boud, On Fri, 23 Oct 2020 11:02:35 +0200 Michael Biebl wrote: Package: thunderbird Version: 1:78.4.0-1 Severity: important Hi, with TB 78, the default configuration of Thunderbird enables telemetry data submission and one has to explicitly opt out of that. See attached screenshot. Please change the default to off and let users opt in instead. I just checked this and tested it on TB 115 and it is completely disabled, without a way to enable it (which I don't see as a problem). It's config key toolkit.temetry.enabled in the config editor. Can you see if that's also the case for you? I think upstream will only enable it for nightlies and maybe alpha/beta releases now, which I think is acceptable for us. Cheers, Emilio
Bug#1055955: transition: perl 5.38
On 14/11/2023 19:28, Niko Tyni wrote: Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Hi release team, 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. We should aim to release trixie with 5.40 (which will be released in May 2024 or so), but it's still better to do these transitions one at a time. Indeed. And sounds good about releasing with 5.40. TL;DR: - can we raise the remaining bugs to severity:serious? Go ahead. - I'll request a transition slot once the easy ones are fixed Cool. - should we worry about time64? Let's not block (or even entangle) on that. Cheers, Emilio
Bug#1053657: dhcpcd-base has ineffective Replaces due to /usr-merge and looses files in upgrade
On 08/10/2023 08:15, Helmut Grohne wrote: I'm sorry for not having spotted this before the point release and will now monitor stable p-u suites for similar problems to raise this earlier. Great, thanks. Can I assume that a package sits in p-u for at least three days before migrating to a stable release? Yes, p-u is frozen about 5 or 6 days before the release. Exceptions can happen, but excluding those you can assume that. Cheers, Emilio
Bug#1022759: lintian: don't emit source-nmu-has-incorrect-version-number for stable updates
Control: tags -1 patch On Tue, 25 Oct 2022 11:56:33 +0200 Emilio Pozuelo Monfort wrote: Package: lintian Version: 2.104.0 Severity: normal X-Debbugs-Cc: debian-rele...@lists.debian.org Hi, When preparing stable or security updates, the convention is to use debXuY whether it is a NMU or not, without making it e.g. deb11u1.1. Thus please stop emitting this tag when a stable update is detected. no-nmu-in-changelog should keep being emitted. See https://salsa.debian.org/lintian/lintian/-/merge_requests/481 Emilio
Bug#1052082: bullseye-pu: package rust-cbindgen/0.24.3-2~deb11u1
On 17/09/2023 17:12, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sun, 2023-09-17 at 11:36 +0200, Emilio Pozuelo Monfort wrote: This updates rust-cbindgen to 0.24, as required by Firefox ESR 115. The risk is low as the only (build)rdep of cbindgen are firefox-esr and thunderbird. Attached is a debian/ diff of the update. - * Only build the cbindgen binary. afaict that's still true, so maybe the changelog entry should still be present? Ack. I removed it because the packages are already gone in the current version in bullseye, so there's no change to the status quo. However I see how we're documenting the changes wrt the previous version in d/changelog, so that entry is still relevant. Added back. In any case, please go ahead. Uploaded. Cheers, Emilio
Bug#1019570: librust-cbindgen-dev has been removed from Bullseye
Hi Nick, On 12/09/2022 11:21, Nick Brown wrote: Package: rust-cbindgen Version: 0.23.0-1~deb11u1 Severity: important The NMU of 0.23.0-1~deb11u1 replaced 0.20.0-1~deb11u1 in Debian Bullseye and in doing so removed librust-cbindgen-dev and librust-cbindgen+clap-dev https://tracker.debian.org/news/1345484/accepted-rust-cbindgen-0230-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/ https://sources.debian.org/src/rust-cbindgen/0.23.0-1~deb11u1/debian/control/#L35 This means that any debian packages (or 3rd party debian packaged) that were built using librust-cbindgen-dev will no longer do so. I had 3rd party debian packages that were being built against ibrust-cbindgen-dev that no longer builds, and only work around is now vendor ibrust-cbindgen-dev. Why was ibrust-cbindgen-dev removed? Can it be restored? Sorry for the delay in answering this. I'm in the process of updating cbindgen again, and remembered that you asked about this. The reason I disabled it is that cbindgen is now embedding all the build-dependencies, since newer versions and new dependencies are added that are not found in bullseye. That means that librust-cbindgen-dev can't depend on those packages, and I'm not sure if we could ship those extra sources in that package and how that would interact with other packages in the ecosystem. If you know of a package that is doing the same thing and still providing a -dev package, I can take a look. Cheers, Emilio
Bug#1052082: bullseye-pu: package rust-cbindgen/0.24.3-2~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net
Hi,
This updates rust-cbindgen to 0.24, as required by Firefox ESR 115.
The risk is low as the only (build)rdep of cbindgen are firefox-esr
and thunderbird.
Attached is a debian/ diff of the update.
Cheers,
Emilio
diff -ruNp rust-cbindgen-0.23.0/debian/changelog
rust-cbindgen-0.24.3/debian/changelog
--- rust-cbindgen-0.23.0/debian/changelog 2022-07-04 10:53:21.0
+0200
+++ rust-cbindgen-0.24.3/debian/changelog 2023-07-28 14:16:44.0
+0200
@@ -1,32 +1,32 @@
-rust-cbindgen (0.23.0-1~deb11u1) bullseye; urgency=medium
+rust-cbindgen (0.24.3-2~deb11u1) bullseye; urgency=medium
* Non-maintainer upload.
* Backport to bullseye.
* Vendor dependencies, they are not available in bullseye.
- * Only build the cbindgen binary.
* Lower dh-cargo build-dep.
* Build with rust-mozilla.
- -- Emilio Pozuelo Monfort Mon, 04 Jul 2022 10:53:21 +0200
+ -- Emilio Pozuelo Monfort Fri, 28 Jul 2023 14:16:44 +0200
-rust-cbindgen (0.23.0-1) unstable; urgency=medium
+rust-cbindgen (0.24.3-2) unstable; urgency=medium
- * Package cbindgen 0.23.0 from crates.io using debcargo 2.5.0
+ * Team upload.
+ * Package cbindgen 0.24.3 from crates.io using debcargo 2.6.0
+ * Relax dev-dependency on serial-test.
- -- Sylvestre Ledru Fri, 03 Jun 2022 11:20:37 +0200
+ -- Peter Michael Green Thu, 17 Nov 2022 20:11:36 +
-rust-cbindgen (0.20.0-1~deb11u1) bullseye; urgency=medium
+rust-cbindgen (0.24.3-1) unstable; urgency=medium
- * Non-maintainer upload.
- * Backport to bullseye.
+ * Package cbindgen 0.24.3 from crates.io using debcargo 2.5.0
- -- Emilio Pozuelo Monfort Thu, 02 Dec 2021 12:49:31 +0100
+ -- Sylvestre Ledru Sat, 25 Jun 2022 15:27:28 +0200
-rust-cbindgen (0.20.0-1) unstable; urgency=medium
+rust-cbindgen (0.23.0-1) unstable; urgency=medium
- * Package cbindgen 0.20.0 from crates.io using debcargo 2.4.4-alpha.0
+ * Package cbindgen 0.23.0 from crates.io using debcargo 2.5.0
- -- Sylvestre Ledru Sun, 22 Aug 2021 14:26:42 +0200
+ -- Sylvestre Ledru Fri, 03 Jun 2022 11:20:37 +0200
rust-cbindgen (0.19.0-1) experimental; urgency=medium
diff -ruNp rust-cbindgen-0.23.0/debian/control
rust-cbindgen-0.24.3/debian/control
--- rust-cbindgen-0.23.0/debian/control 2022-06-17 13:33:38.0 +0200
+++ rust-cbindgen-0.24.3/debian/control 2023-07-28 14:16:44.0 +0200
@@ -27,9 +27,10 @@ Build-Depends: debhelper (>= 12),
Maintainer: Debian Rust Maintainers
Uploaders:
Sylvestre Ledru
-Standards-Version: 4.5.1
+Standards-Version: 4.6.1
Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git [src/cbindgen]
Vcs-Browser:
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/cbindgen
+X-Cargo-Crate: cbindgen
Rules-Requires-Root: no
#Package: librust-cbindgen-dev
@@ -55,8 +56,8 @@ Rules-Requires-Root: no
# librust-cbindgen+clap-dev (= ${binary:Version})
#Provides:
# librust-cbindgen-0-dev (= ${binary:Version}),
-# librust-cbindgen-0.23-dev (= ${binary:Version}),
-# librust-cbindgen-0.23.0-dev (= ${binary:Version})
+# librust-cbindgen-0.24-dev (= ${binary:Version}),
+# librust-cbindgen-0.24.3-dev (= ${binary:Version})
#Description: Generating C bindings to Rust code - Rust source code
# This package contains the source for the Rust cbindgen crate, packaged by
# debcargo for use with cargo and dh-cargo.
@@ -72,10 +73,10 @@ Rules-Requires-Root: no
# librust-cbindgen+default-dev (= ${binary:Version}),
# librust-cbindgen-0+clap-dev (= ${binary:Version}),
# librust-cbindgen-0+default-dev (= ${binary:Version}),
-# librust-cbindgen-0.23+clap-dev (= ${binary:Version}),
-# librust-cbindgen-0.23+default-dev (= ${binary:Version}),
-# librust-cbindgen-0.23.0+clap-dev (= ${binary:Version}),
-# librust-cbindgen-0.23.0+default-dev (= ${binary:Version})
+# librust-cbindgen-0.24+clap-dev (= ${binary:Version}),
+# librust-cbindgen-0.24+default-dev (= ${binary:Version}),
+# librust-cbindgen-0.24.3+clap-dev (= ${binary:Version}),
+# librust-cbindgen-0.24.3+default-dev (= ${binary:Version})
#Description: Generating C bindings to Rust code - feature "clap" and 1 more
# This metapackage enables feature "clap" for the Rust cbindgen crate, by
pulling
# in any additional dependencies needed by that feature.
diff -ruNp rust-cbindgen-0.23.0/debian/patches/relax-dep.diff
rust-cbindgen-0.24.3/debian/patches/relax-dep.diff
--- rust-cbindgen-0.23.0/debian/patches/relax-dep.diff 1970-01-01
01:00:00.0 +0100
+++ rust-cbindgen-0.24.3/debian/patches/relax-dep.diff 2022-11-17
21:11:36.0 +0100
@@ -0,0 +1,13 @@
+Index: cbindgen/Cargo.toml
+===
+--- cbindgen.orig/Cargo.toml
cbindgen/Cargo.toml
+@@ -89,7 +89,7 @@ version = "3.0"
+ version = "0
Bug#1052027: bullseye-pu: package cargo-mozilla/0.66.0+ds1-1~deb11u1
On 16/09/2023 18:01, Adam D. Barratt wrote: Control: tags -1 + confirmed On Sat, 2023-09-16 at 11:15 +0200, Emilio Pozuelo Monfort wrote: Following up on #1051051, this updates cargo-mozilla for the upcoming Firefox ESR 115. Just like for rustc-mozilla, the risk here is small as this package is only used to build firefox-esr and thunderbird. I have used the resulting package to successfully build and test firefox-esr 115.0.2 on bullseye. Please go ahead. Uploaded. Cheers, Emilio
Bug#1052027: bullseye-pu: package cargo-mozilla/0.66.0+ds1-1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net Hi, Following up on #1051051, this updates cargo-mozilla for the upcoming Firefox ESR 115. Just like for rustc-mozilla, the risk here is small as this package is only used to build firefox-esr and thunderbird. I have used the resulting package to successfully build and test firefox-esr 115.0.2 on bullseye. Attached is the diff from 0.66 itself so that the changes in the backport are easier to review. A diff from 0.47 is not attached. Cheers, Emilio diff -ruNp cargo-0.66.0+ds1/debian/cargo.bash-completion cargo-mozilla-0.66.0+ds1/debian/cargo.bash-completion --- cargo-0.66.0+ds1/debian/cargo.bash-completion 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo.bash-completion 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -src/etc/cargo.bashcomp.sh cargo diff -ruNp cargo-0.66.0+ds1/debian/cargo.dirs cargo-mozilla-0.66.0+ds1/debian/cargo.dirs --- cargo-0.66.0+ds1/debian/cargo.dirs 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo.dirs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/bin diff -ruNp cargo-0.66.0+ds1/debian/cargo-doc.docs cargo-mozilla-0.66.0+ds1/debian/cargo-doc.docs --- cargo-0.66.0+ds1/debian/cargo-doc.docs 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-doc.docs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -target/doc diff -ruNp cargo-0.66.0+ds1/debian/cargo.manpages cargo-mozilla-0.66.0+ds1/debian/cargo.manpages --- cargo-0.66.0+ds1/debian/cargo.manpages 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo.manpages 1970-01-01 01:00:00.0 +0100 @@ -1,2 +0,0 @@ -src/etc/man/cargo-*.1 -src/etc/man/cargo.1 diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla.bash-completion cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.bash-completion --- cargo-0.66.0+ds1/debian/cargo-mozilla.bash-completion 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.bash-completion 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1 @@ +src/etc/cargo.bashcomp.sh cargo diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla.dirs cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.dirs --- cargo-0.66.0+ds1/debian/cargo-mozilla.dirs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.dirs 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1 @@ +usr/bin diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla-doc.docs cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla-doc.docs --- cargo-0.66.0+ds1/debian/cargo-mozilla-doc.docs 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla-doc.docs 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1 @@ +target/doc diff -ruNp cargo-0.66.0+ds1/debian/cargo-mozilla.manpages cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.manpages --- cargo-0.66.0+ds1/debian/cargo-mozilla.manpages 1970-01-01 01:00:00.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/cargo-mozilla.manpages 2023-01-11 18:55:09.0 +0100 @@ -0,0 +1,2 @@ +src/etc/man/cargo-*.1 +src/etc/man/cargo.1 diff -ruNp cargo-0.66.0+ds1/debian/changelog cargo-mozilla-0.66.0+ds1/debian/changelog --- cargo-0.66.0+ds1/debian/changelog 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/changelog 2023-07-30 10:37:52.0 +0200 @@ -1,3 +1,15 @@ +cargo-mozilla (0.66.0+ds1-1~deb11u1) bullseye; urgency=medium + + * Non-maintainer upload. + * Backport to bullseye as cargo-mozilla. + * Build-dep on rustc-mozilla. + * Don't build the doc package. + * Vendor libgit2 1.5.1, the system one is too old. + * Build-dep on libpcre3-dev, for libgit2. + * Don't use namespaced features. + + -- Emilio Pozuelo Monfort Sun, 30 Jul 2023 10:37:52 +0200 + cargo (0.66.0+ds1-1) unstable; urgency=medium [ Fabian Grünbichler ] diff -ruNp cargo-0.66.0+ds1/debian/control cargo-mozilla-0.66.0+ds1/debian/control --- cargo-0.66.0+ds1/debian/control 2023-01-11 18:55:09.0 +0100 +++ cargo-mozilla-0.66.0+ds1/debian/control 2023-07-30 10:37:52.0 +0200 @@ -1,4 +1,4 @@ -Source: cargo +Source: cargo-mozilla Section: devel Maintainer: Rust Maintainers Uploaders: Luca Bruno , @@ -10,17 +10,18 @@ Priority: optional Build-Depends: debhelper (>= 12~), dpkg-dev (>= 1.17.14), - cargo:native(>= 0.56.0), - rustc:native(>= 1.63), - libstd-rust-dev (>= 1.63), + cargo-mozilla:native(>= 0.56.0), + rustc-mozilla:native(>= 1.63), + libstd-rust-mozilla-dev (>= 1.63), pkg-config, bash-completion, python3:native, libcurl4-gnutls-dev | libcurl4-openssl-dev, libssh2-1-dev, - libgit2-dev (>= 1.5.0), - libgit2-dev (<< 1.6~~), +# libgit2-dev (>= 1.5.0), +# libgit2-dev (<< 1.6~~), libhttp-parser-d
Bug#1051051: bullseye-pu: package rustc-mozilla/1.63.0+dfsg1-2~deb11u1
Hi, On Fri, 01 Sep 2023 18:50:53 +0200 Emilio Pozuelo Monfort wrote: Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org Hi, The time has come for a new Firefox / Thunderbird ESR release in *stable. This will require rustc/cargo/cbindgen backports as usual. For bookworm we're in a good shape for this update, but for bullseye and buster we'll need all three updates. For rustc-mozilla, I've used the version from bookworm. Hopefully I got all the stage0 binaries this time. Risk is low as this package is only used to build FF/TB. I have successfully built the whole chain up to FF 115 ESR on amd64. I'm attaching a diff from rustc_1.63/bookworm to the proposed update. I don't think there's much value in a 1.59->1.63 diff, but if you want it say so and I'll prepare one. I have just uploaded this to pu-new. I'd be great to get it accepted so that it can be built and I can propose/upload cargo-mozilla and cbindgen, all before Sep 26 when the next round of updates will go out, requiring the newer toolchain packages. Thanks, Emilio
Bug#1051051: bullseye-pu: package rustc-mozilla/1.63.0+dfsg1-2~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: team+pkg-mozi...@tracker.debian.org
Hi,
The time has come for a new Firefox / Thunderbird ESR release in *stable.
This will require rustc/cargo/cbindgen backports as usual. For bookworm
we're in a good shape for this update, but for bullseye and buster we'll
need all three updates.
For rustc-mozilla, I've used the version from bookworm. Hopefully I got
all the stage0 binaries this time.
Risk is low as this package is only used to build FF/TB. I have
successfully built the whole chain up to FF 115 ESR on amd64.
I'm attaching a diff from rustc_1.63/bookworm to the proposed update. I don't
think there's much value in a 1.59->1.63 diff, but if you want it say so and
I'll prepare one.
Thanks,
Emilio
diff -ruNp debian.rustc/changelog debian/changelog
--- debian.rustc/changelog 2023-01-14 09:38:46.0 +0100
+++ debian/changelog2023-07-28 13:44:06.0 +0200
@@ -1,3 +1,13 @@
+rustc-mozilla (1.63.0+dfsg1-2~deb11u1) bullseye; urgency=medium
+
+ * Non-maintainer upload.
+ * Backport to bullseye as rustc-mozilla.
+ * Do a bootstrap build.
+ * Disable wasm.
+ * Disable new binary packages rustfmt, -clippy, -all.
+
+ -- Emilio Pozuelo Monfort Fri, 28 Jul 2023 13:44:06 +0200
+
rustc (1.63.0+dfsg1-2) unstable; urgency=medium
[ Fabian Grünbichler ]
diff -ruNp debian.rustc/control debian/control
--- debian.rustc/control2023-01-14 09:38:46.0 +0100
+++ debian/control 2023-07-28 13:44:06.0 +0200
@@ -1,4 +1,4 @@
-Source: rustc
+Source: rustc-mozilla
Section: devel
Priority: optional
Maintainer: Debian Rust Maintainers
@@ -12,14 +12,14 @@ Build-Depends:
debhelper-compat (= 13),
dpkg-dev (>= 1.17.14),
python3:native,
- cargo:native (>= 0.60.0) ,
- rustc:native (>= 1.62.0+dfsg) ,
- rustc:native (<= 1.63.0++),
- llvm-14-dev:native,
- llvm-14-tools:native,
+# cargo:native (>= 0.60.0) ,
+# rustc:native (>= 1.62.0+dfsg) ,
+# rustc:native (<= 1.63.0++),
+ llvm-13-dev:native,
+ llvm-13-tools:native,
gcc-mingw-w64-x86-64-posix:native [amd64] ,
gcc-mingw-w64-i686-posix:native [i386] ,
- libllvm14 (>= 1:14.0.0),
+ libllvm13 (>= 1:13.0.0),
cmake (>= 3.0) | cmake3,
# needed by some vendor crates
pkg-config,
@@ -38,30 +38,32 @@ Build-Depends:
curl ,
ca-certificates ,
Build-Depends-Indep:
- wasi-libc (>= 0.0~git20220510.9886d3d~~) ,
- wasi-libc (<= 0.0~git20220510.9886d3d++) ,
- clang-14:native,
+# wasi-libc (>= 0.0~git20220510.9886d3d~~) ,
+# wasi-libc (<= 0.0~git20220510.9886d3d++) ,
+ clang-13:native,
Build-Conflicts: gdb-minimal
Standards-Version: 4.2.1
Homepage: http://www.rust-lang.org/
Vcs-Git: https://salsa.debian.org/rust-team/rust.git
Vcs-Browser: https://salsa.debian.org/rust-team/rust
-Package: rustc
+Package: rustc-mozilla
Architecture: any
Multi-Arch: allowed
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends},
- libstd-rust-dev (= ${binary:Version}),
+ libstd-rust-mozilla-dev (= ${binary:Version}),
gcc, libc-dev, binutils (>= 2.26)
Recommends:
cargo (>= 0.64.0~~), cargo (<< 0.65.0~~),
# llvm is needed for llvm-dwp for -C split-debuginfo=packed
- llvm-14,
+ llvm-13,
Suggests:
# lld and clang are needed for wasm compilation
- lld-14, clang-14,
-Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~)
+ lld-13, clang-13,
+Conflicts: rustc
+Provides: rustc (= ${binary:Version})
+Replaces: libstd-rust-dev (<< 1.25.0+dfsg1-2~~), rustc
Breaks: libstd-rust-dev (<< 1.25.0+dfsg1-2~~)
Description: Rust systems programming language
Rust is a curly-brace, block-structured expression language. It
@@ -76,7 +78,7 @@ Description: Rust systems programming la
generic programming and meta-programming, in both static and dynamic
styles.
-Package: libstd-rust-1.63
+Package: libstd-rust-mozilla-1.63
Section: libs
Architecture: any
Multi-Arch: same
@@ -98,12 +100,12 @@ Description: Rust standard libraries
This package contains the standard Rust libraries, built as dylibs,
needed to run dynamically-linked Rust programs (-C prefer-dynamic).
-Package: libstd-rust-dev
+Package: libstd-rust-mozilla-dev
Section: libdevel
Architecture: any
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends},
- libstd-rust-1.63 (= ${binary:Version}),
+ libstd-rust-mozilla-1.63 (= ${binary:Version}),
Description: Rust standard libraries - development files
Rust is a curly-brace, block-structured expression language. It
visually resembles the C language family, but differs significantly
@@ -121,7 +123,7 @@ Description: Rust standard libraries - d
needed to compile Rust programs. It may also be installed on a system
of another host architecture, for cross-compiling to this architecture.
-Package: libstd-rust-dev-windows
+Package: libstd-rust-mozilla-dev-windows
Section: libde
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi Sean, On 11/05/2023 03:59, Sean Whitton wrote: Hello, On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote: Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive are copied unmodified into derivatives. The heart of the issue is how dpkg is a native package. What we're talking about is not the Debian system, but the Debian archive as it exists independently of the Debian system. dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly being used to distribute upstream dpkg. This is not in itself a problem -- we distribute a lot of stuff in source packages that does not form part of the Debian system. But in this case, this distribution that's occurring might conflict with how Debian is seeking to provide a product not just to end users, but also to those building derivatives. One simple solution is for dpkg to become a non-native package, carrying Debian-specific patches to do things like remove the warning code. I think you're conflating two independent things. If you override the dpkg maintainer to remove that warning that occurs on derivatives, then anyone could NMU dpkg and the maintainer wouldn't introduce it back, effectively removing the warning from "dpkg upstream". OTOH if the dpkg maintainer switches to non-native packages, anyone could NMU it adding the change as a patch, however the maintainer will just NACK the NMU before or after it happens. So I don't see a problem with dpkg being native, just like e.g. apt is, and that won't magically solve the issue at hand. Cheers, Emilio
Bug#817285: Allow releasing security updates via PGP-signed control messages
Control: forwarded -1 https://salsa.debian.org/ftp-team/dak/-/merge_requests/270 Hi, On Wed, 09 Mar 2016 19:36:02 +0100 Moritz Muehlenhoff wrote: Package: ftp.debian.org Severity: wishlist This was discussed at one of the past security team meetings, but there was never a bug for that: (This is a first high level view, the exact requirements can be hashed out later.) Right now to release a security update one needs shell access on security-master. It would be great to allow the release of a security update via a PGP-signed control message (similar to how changes files need to be signed to allow uploads). The next step would then be an ACL mechanism where trusted DDs can be granted the possibility to release DSAs on their own (after the security team having acked the debdiff). (This also needs some tweaks for the debian-security-announce moderation script, but that's unrelated to this task. There's now a MR at [1] that should address the ACL for dak. Feel free to comment if you have any feedback. Cheers, Emilio [1] https://salsa.debian.org/ftp-team/dak/-/merge_requests/270
Bug#1033704: unblock: ikiwiki-hosting/0.20220716-2
Hi Simon, On 30/03/2023 19:15, Simon McVittie wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ikiwiki-host...@packages.debian.org Control: affects -1 + src:ikiwiki-hosting Please unblock package ikiwiki-hosting The package is not blocked at this stage in the freeze as it's not a key package and has autopkgtests. However I have added an unblock hint anyway and aged it a bit. Cheers, Emilio
Bug#1013872: salt: CVE-2022-22967
On Thu, 1 Sep 2022 08:13:07 +0200 Paul Gevers wrote: Hi, On Sun, 26 Jun 2022 13:55:24 +0200 Salvatore Bonaccorso wrote: > Source: salt > The following vulnerability was published for salt. > > CVE-2022-22967[0]: > | An issue was discovered in SaltStack Salt in versions before 3002.9, > | 3003.5, 3004.2. PAM auth fails to reject locked accounts, which allows > | a previously authorized user whose account is locked still run Salt > | commands when their account is locked. This affects both local shell > | accounts with an active session and salt-api users that authenticate > | via PAM eauth. As much as I'd like to stay away from fixing packages, do you need help with this one? It causing RC issues in testing even though it's removed. https://qa.debian.org/dose/debcheck/src_testing_main/1661922002/packages/pytest-testinfra.html#076c12ad0c0676e354433b4fd854e3d5 There's a new upstream release and I pulled it locally, but there are a lot of changes. So without experience with the package, it's a bit much to go over. The fix for this is very simple. We are ignoring pam_acct_mgmt()'s return value. The upstream fix (with tests) is at: https://github.com/saltstack/salt/commit/e068a34ccb2e17ae7224f8016a24b727f726d4c8 Cheers, Emilio
Bug#1031589: Handling of RC bugs in firefox-esr
On 24/02/2023 09:48, Adrian Bunk wrote: On Fri, Feb 24, 2023 at 09:19:40AM +0100, Emilio Pozuelo Monfort wrote: ... Also note that one of the concerns was for armhf, which is now being built from arm64 buildds. ... On armhf there is a 4 GB FTBFS for the future (like on i386), and a 3 GB FTBFS today that still seems to be present on some buildds. While some armhf buildds have a 4 GB userspace address space that is sufficient at least today, several buildds still run into the debian/rules test for 64bit: https://buildd.debian.org/status/logs.php?pkg=firefox=armhf https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf arm-ubc-0* had out of memory before the debian/rules test for 64bit, so there might be a genuine issue that firefox-esr cannot be built on these buildds and still might have to be blacklisted: https://buildd.debian.org/status/logs.php?pkg=firefox-esr=armhf=91.11.0esr-1 My understanding was that those buildds were going to be decommissioned. But if that's not going to happen in the short term, a blacklist for firefox-esr and thunderbird would be in order. Cheers, Emilio
