Bug#981744: plasma-discover: Plasma-Discover immediately crashes
Hi, The latest round of updates (appstream specifically I think) appears to have resolved this issue. Cheers, Gerald
upcoming transition for webp package
Dear Debian colleagues, I'm writing because you maintain a package with a direct dependency in libwebp6. I'm planning to transition it to libweb8. Although I am not expecting any compatibility trouble, previous transitions have not always gone smoothly. So I'm sending this email as a heads up, and I've also just uploaded libweb8 to experimental. Thank you very much. Jeff Reverse Depends: darktable (>= 3.4.0-2) Reverse Depends: geeqie (>= 1:1.6-6) Reverse Depends: gimp (>= 2.10.22-2) Reverse Depends: godot3 (>= 3.2-stable-2) Reverse Depends: godot3-runner (>= 3.2-stable-2) Reverse Depends: godot3-server (>= 3.2-stable-2) Reverse Depends: gstreamer1.0-plugins-bad (>= 1.18.2-1~deb11u1+build1) Reverse Depends: gthumb (>= 3:3.11.2-0.1) Reverse Depends: liballegro-image5.2 (>= 2:5.2.6.0-3) Reverse Depends: libavcodec-extra58 (>= 7:4.3.1-6) Reverse Depends: libavcodec58 (>= 7:4.3.1-6) Reverse Depends: libevas1 (>= 1.25.1-1) Reverse Depends: libfreeimage3 (>= 3.18.0+ds2-6+build1) Reverse Depends: libgd3 (>= 2.3.0-2) Reverse Depends: libgdal20 (>= 2.4.3+dfsg-1) Reverse Depends: libgdal28 (>= 3.2.1+dfsg-1) Reverse Depends: libgegl-0.4-0 (>= 1:0.4.26-2) Reverse Depends: libgraphicsmagick-q16-3 (>= 1.4+really1.3.36+hg16442-1) Reverse Depends: libgvc6 (>= 2.42.2-4+gl2) Reverse Depends: libimlib2 (>= 1.7.1-1) Reverse Depends: liblept5 (>= 1.79.0-1) Reverse Depends: libmagickcore-6.q16-6 (>= 8:6.9.11.24+dfsg-1+gl0) Reverse Depends: libmagickcore-6.q16hdri-6 (>= 8:6.9.11.24+dfsg-1+gl0) Reverse Depends: libmapnik3.1 (>= 3.1.0+ds-1) Reverse Depends: libopencv-imgcodecs4.2 (>= 4.2.0+dfsg-6+build8) Reverse Depends: libopencv-imgcodecs4.5 (>= 4.5.1+dfsg-4) Reverse Depends: libopenimageio2.2 (>= 2.2.9.0+dfsg-1+build2) Reverse Depends: libqt5webenginecore5 (>= 5.15.2+dfsg-3) Reverse Depends: libqt5webkit5 (>= 5.212.0~alpha4-11+gl0) Reverse Depends: librasterlite2-1 (>= 1.1.0~beta1-2) Reverse Depends: libsdl-image1.2 (>= 1.2.12-12+build1) Reverse Depends: libsdl2-image-2.0-0 (>= 2.0.5+dfsg1-2) Reverse Depends: libsqlite3-mod-rasterlite2 (>= 1.1.0~beta1-2) Reverse Depends: libtiff5 (>= 4.2.0-1) Reverse Depends: libvips42 (>= 8.10.5-1) Reverse Depends: libwebkit2gtk-4.0-37 (>= 2.30.4-1) Reverse Depends: libwebp-dev (= 0.6.1-2+build1) Reverse Depends: libwebp6-dbgsym (= 0.6.1-2+build1) Reverse Depends: libwebpdemux2 (>= 0.6.1-2+build1) Reverse Depends: libwebpmux3 (>= 0.6.1-2+build1) Reverse Depends: libweston-9-0 (>= 9.0.0-2) Reverse Depends: libwpewebkit-1.0-3 (>= 2.30.4-1) Reverse Depends: pike8.0-image (>= 8.0.702-1.1) Reverse Depends: python3-pil (>= 8.1.0-1) Reverse Depends: python3-pil-dbg (>= 8.1.0-1) Reverse Depends: qt5-image-formats-plugins (>= 5.15.2-2) Reverse Depends: simple-scan (>= 3.38.1-1) Reverse Depends: telegram-purple (>= 1.4.3-3) Reverse Depends: webp (>= 0.6.1-2+build1) Reverse Depends: weston (>= 9.0.0-2) Reverse Depends: xpra (>= 3.0.7+dfsg1-1+build2)
stellarsolver_1.5-1_amd64.changes is NEW
binary:libstellarsolver-dev is NEW. binary:libstellarsolver1 is NEW. binary:libstellarsolver-dev is NEW. binary:libstellarsolver1 is NEW. source:stellarsolver is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Processing of stellarsolver_1.5-1_amd64.changes
stellarsolver_1.5-1_amd64.changes uploaded successfully to localhost along with the files: stellarsolver_1.5-1.dsc stellarsolver_1.5.orig.tar.gz stellarsolver_1.5-1.debian.tar.xz libstellarsolver-dev_1.5-1_amd64.deb libstellarsolver1-dbgsym_1.5-1_amd64.deb libstellarsolver1_1.5-1_amd64.deb stellarsolver_1.5-1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#973659: qtdeclarative5-dev-tools: qmlcachegen segfaults on hppa
On Thu, Feb 04, 2021 at 01:39:04PM -0500, John David Anglin wrote: > That's the dichotomy. I know hppa but not Qt. It painful to find the > parts of Qt that depend on endianness, stack layout, and possibly the NaN > representation. I also don’t know the QML / V4 engine code well. But the qv4staticvalue_p.h file you mentioned has an excellent comment which describes how it treats different double values: https://sources.debian.org/src/qtdeclarative-opensource-src/5.15.2+dfsg-4/src/qml/common/qv4staticvalue_p.h/#L140 For NaN, you probably need to check if these masks are correct: https://sources.debian.org/src/qtdeclarative-opensource-src/5.15.2+dfsg-4/src/qml/common/qv4staticvalue_p.h/#L285 https://sources.debian.org/src/qtdeclarative-opensource-src/5.15.2+dfsg-4/src/qml/common/qv4staticvalue_p.h/#L305 and this method: https://sources.debian.org/src/qtdeclarative-opensource-src/5.15.2+dfsg-4/src/qml/common/qv4staticvalue_p.h/#L354 From endianness point of view, Qt Declarative should be mostly fine. I looked at s390x test logs and only few tests are failing: - qmltestrunner::item-grabber::test_endresult* — for this I filed https://bugreports.qt.io/browse/QTBUG-56806 - tst_qmldiskcache::regenerateAfterChange() — this one I didn’t notice before, and I will investigate it. It regressed somewhere between 5.11.3 and 5.12.2. -- Dmitry Shachnev signature.asc Description: PGP signature
