Bug#1081122: sane-backends: FTBFS on hurd-i386 & hurd-amd64
Source: sane-backends Version: 1.3.0-1 Severity: important Tags: patch ftbfs User: debian-h...@lists.debian.org Usertags: hurd Hi, currently sane-backends fails to build on hurd-i386 [1] and cannot be built on hurd-amd64. The problem on hurd-i386 really is a problem on any non-Linux architecture: the udev rules, generated only on Linux architectures, are unconditionally installed by libsane1.install. The problem on hurd-amd64 is that libieee1284 is not supported on Hurd, and the libieee1284-3-dev build dependency is currently excluded only on hurd-i386. The attached patch fixes both the issues: - exclude the libieee1284-3-dev build dependency on any Hurd architecture - ensure that the /usr/lib/udev/rules.d/ directory is created, so it can be unconditionally used in the dh_install phase in debian/rules - install the udev rules in a Linux-only block of debian/rules, rather than with libsane1.install [1] https://buildd.debian.org/status/fetch.php?pkg=sane-backends&arch=hurd-i386&ver=1.3.0-1&stamp=1715647157&raw=1 Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -14,7 +14,7 @@ Build-Depends: libcups2-dev, libcurl4-gnutls-dev, libgphoto2-dev, - libieee1284-3-dev [!hurd-i386], + libieee1284-3-dev [!hurd-any], libjpeg-dev, libltdl-dev, libpng-dev, --- a/debian/libsane1.dirs +++ b/debian/libsane1.dirs @@ -1 +1,2 @@ /usr/lib/udev/hwdb.d/ +/usr/lib/udev/rules.d/ --- a/debian/libsane1.install +++ b/debian/libsane1.install @@ -1,4 +1,2 @@ usr/lib/*/*.so.* usr/lib/*/sane/*.so.* -debian/60-libsane1.rules /usr/lib/udev/rules.d/ -debian/99-libsane1.rules /usr/lib/udev/rules.d/ --- a/debian/rules +++ b/debian/rules @@ -92,6 +92,8 @@ ifeq (linux,$(DEB_HOST_ARCH_OS)) $(SANE_DESC) -s $(CURDIR)/doc/descriptions -m hwdb > $(CURDIR)/debian/20-sane.hwdb cp $(CURDIR)/debian/20-sane.hwdb $(CURDIR)/debian/libsane1/usr/lib/udev/hwdb.d/ + cp $(CURDIR)/debian/60-libsane1.rules $(CURDIR)/debian/libsane1/usr/lib/udev/rules.d/ + cp $(CURDIR)/debian/99-libsane1.rules $(CURDIR)/debian/libsane1/usr/lib/udev/rules.d/ endif dh_install
Bug#1081026: gimplensfun: FTBFS with exiv2 0.28
Source: gimplensfun Version: 0.2.4-1.1 Severity: important Tags: patch upstream ftbfs Control: forwarded -1 https://github.com/seebk/GIMP-Lensfun/pull/30 Hi, gimplensfun fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; this version is now available in unstable. There is a proposed patch upstream to fix this [1], although it looks like it will wait a while as the upstream project does not look that active. I extracted the patch/commit from that upstream PR, and verified that it builds fine with Exiv2 0.28; you can find it attached to this bug. This bug should have been reported before Exiv2 0.28.x was uploaded to unstable: for some reason my testing did not uncover the compatibility issues in gimplensfun, sorry for this. Because of this, I'm going to NMU this soon. [1] https://github.com/seebk/GIMP-Lensfun/pull/30 Thanks, -- Pino Author: Pino Toscano Description: Support Exiv2 0.28+ Use the new types for the image pointer and exception class, as available in the new Exiv2 version, keeping the support for older versions. . Fixes #29 Last-Update: 2024-09-07 Forwarded: https://github.com/seebk/GIMP-Lensfun/pull/30 --- a/src/gimplensfun.cpp +++ b/src/gimplensfun.cpp @@ -34,6 +34,7 @@ #include #include #include +#include #define VERSIONSTR "0.2.4" @@ -1033,7 +1034,11 @@ static void process_image (GimpDrawable // static int read_opts_from_exif(const char *filename) { +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr Exiv2image; +#else Exiv2::Image::AutoPtr Exiv2image; +#endif Exiv2::ExifData exifData; const lfCamera **cameras= 0; @@ -1061,7 +1066,11 @@ static int read_opts_from_exif(const cha return -1; } } +#if EXIV2_TEST_VERSION(0,28,0) +catch (Exiv2::Error& e) { +#else catch (Exiv2::AnyError& e) { +#endif if (DEBUG) { g_print ("exception on reading data. \n"); }
Bug#1080439: transition: exiv2 0.28.x
Package: release.debian.org Severity: normal X-Debbugs-Cc: ex...@packages.debian.org Control: affects -1 + src:exiv2 User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition for the current stable version of the Exiv2 library, i.e. 0.28.x (currently 0.28.3). There were changes in "core" parts of the API, which required changes in a large number of the users. At this point, basically almost all the users have been fixed either upstream or downstream, so I think it is finally time to introduce the new version, more than one year after the release of 0.28.0. In addition to the SONAME bump, the update to 0.28.x also splits the translation files form the libexiv2-X package to a new libexiv2-data: this means that libexiv2-27 (0.27.x) and libexiv2-28 (0.28.x) are not coinstallable. There are almost 40 users of Exiv2 in unstable, and at the time of this writing almost all of them build fine with 0.28.x; the exceptions are: - hdrmerge -- FTBFS reported as #1071027 - lomiri-gallery-app -- FTBFS reported as #1076761 - nomacs -- request to upload a new version filed as #1076763 Regarding hdrmerge & lomiri-gallery-app: I created delayed NMUs for them that will hit in about 14 days. Regardless, they are leaf packages, so they should not block this transition. Regarding nomacs: it is not currently in unstable, so it will not block the migration to testing. Also worth noting gpscorrelate: it builds fine with 0.28.x, however it is out of testing because of autopkgtest failures (see #1076775); this means it can be still rebuilt with the new version. Hence, I believe this transition should be good to go now, and I do not see other open RC bugs for the affected packages that would block this. I tested the rebuilds only on amd64, so in case issues on other architectures show up, I will take a look during the transition. Ben file: https://release.debian.org/transitions/html/auto-exiv2.html title = "exiv2"; is_affected = .depends ~ "libexiv2\-27" | .depends ~ "libexiv2\-28|libexiv2\-data"; is_good = .depends ~ "libexiv2\-28|libexiv2\-data"; is_bad = .depends ~ "libexiv2\-27"; Thanks, -- Pino
Bug#1079571: RM: falkon [mips64el] -- RoQA; Qt6 WebEngine not available on mips64el
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: fal...@packages.debian.org, georg...@debian.org Control: affects -1 + src:falkon User: ftp.debian@packages.debian.org Usertags: remove Hi, please remove falkon from mips64el: the new version switched to Qt6, and Qt WebEngine in Qt6 does not support mips64el. Thanks, -- Pino
Bug#1076775: gpscorrelate: autopkgtest failures
Source: gpscorrelate Version: 2.1-2 Severity: serious Hi Shriram, the test upstream-suite autopkgtest still fails on practically all the architectures, even after disabling the valgrind support (#1071656): - https://ci.debian.net/packages/g/gpscorrelate/testing/amd64/48755050/ - https://ci.debian.net/packages/g/gpscorrelate/testing/arm64/48333233/ - https://ci.debian.net/packages/g/gpscorrelate/testing/armel/48332791/ - https://ci.debian.net/packages/g/gpscorrelate/testing/armhf/48332992/ - https://ci.debian.net/packages/g/gpscorrelate/testing/i386/48333027/ - https://ci.debian.net/packages/g/gpscorrelate/testing/ppc64el/48332848/ - https://ci.debian.net/packages/g/gpscorrelate/testing/s390x/48337785/ Unfortunately, the logs do not show the reasons of the failures, so you need to run them manually to actually find out why they fail. Would you please take a look at the issues? The autopkgtest failures prevent gpscorrelate from migrate to testing. Thanks, -- Pino
Bug#1071027: hdrmerge: FTBFS with exiv2 0.28
Source: hdrmerge Followup-For: Bug #1071027 X-Debbugs-Cc: t...@debian.org Hi Alex, I'll soon request a transition for Exiv2 0.28; it would be really helpful if you could take a look at this hdrmerge compatibility issue with the new version of Exiv2. Thanks! -- Pino
Bug#1071979: pinot: FTBFS with exiv2 0.28
Source: pinot Followup-For: Bug #1071979 Hi Olly, sorry for the late answer. I'm left now with only a handful of sources that still do not build with Exiv2 0.28+: 5 in total (pinot is one of them), or 4 excluding one that is not available in testing. I got tickets for all of them filed now, and I'll likely open a transition request with release-team later this week. Hence, if you would please fix pinot in the meanwhile, that will certainly help :) Thanks, -- Pino
Bug#1076771: py3exiv2: FTBFS with exiv2 0.28
Source: py3exiv2 Version: 0.7.2-1.1 Severity: important Tags: upstream ftbfs fixed-upstream X-Debbugs-Cc: tc...@debian.org, er...@debian.org, me...@debian.org Control: forwarded -1 https://bugs.launchpad.net/py3exiv2/+bug/2027823 Hi, py3exiv2 fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; that version is available in experimental as of this writing. The issue was reported upstream [1], and it was fixed in the upstream release 0.12.0; unfortunately it seems hard to find the actual changes in the bazaar repository. Considering I'm planning to update Exiv2 to 0.28: would you please update nomacs to the new upstream release? [1] https://bugs.launchpad.net/py3exiv2/+bug/2027823 Thanks, -- Pino
Bug#1076763: nomacs: please update to the new version 3.19.0
Source: nomacs Version: 3.17.2282+dfsg-2 Severity: important X-Debbugs-Cc: czc...@debian.org, ajq...@debian.org Hi, upstream tagged a new version 3.19.0 a couple of weeks ago; this new version includes, among the other things, important bits: - support for Exiv2 0.28+ [1] - uses the right Exiv2 API to get the user comment (fixes #974616) - fixes a crash (fixes #1051579) Considering I'm planning to update Exiv2 to 0.28: would you please update nomacs to the new upstream release? [1] https://github.com/nomacs/nomacs/pull/983 Thanks, -- Pino
Bug#1076761: lomiri-gallery-app: FTBFS with exiv2 0.28
Source: lomiri-gallery-app Version: 3.0.2-1 Severity: important Tags: upstream patch ftbfs X-Debbugs-Cc: sunwea...@debian.org Control: forwarded -1 https://gitlab.com/ubports/development/apps/lomiri-gallery-app/-/issues/123 Hi, lomiri-gallery-app fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; that version is available in experimental as of this writing. I reported this upstream a while ago [1], and provided also a MR fixing this [2], which was already merged. I extracted the patch/commit from it, and verified that it builds fine with both Exiv2 0.27 and Exiv2 0.28; you can find it attached to this bug. Would you review this patch, and upload it so that lomiri-gallery-app rebuilds cleanly once a newer Exiv2 is uploaded to unstable? An alternative may be a new upstream release, which would be even nicer :) [1] https://gitlab.com/ubports/development/apps/lomiri-gallery-app/-/issues/123 [2] https://gitlab.com/ubports/development/apps/lomiri-gallery-app/-/merge_requests/144 Thanks, -- Pino >From be63c6d3497ece568f1d8a3629e6e48006129e4f Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Thu, 14 Mar 2024 07:16:37 +0100 Subject: [PATCH] Support Exiv2 0.28+ Use the new types for the image pointer and exception class, and the different method for the EXIF_ORIENTATION_KEY exif metadata, as available in the new Exiv2 version, keeping the support for older versions. Fixes #123 --- src/photo/photo-metadata.cpp | 16 src/photo/photo-metadata.h | 4 2 files changed, 20 insertions(+) diff --git a/src/photo/photo-metadata.cpp b/src/photo/photo-metadata.cpp index ac4a0b05..dd6e1907 100644 --- a/src/photo/photo-metadata.cpp +++ b/src/photo/photo-metadata.cpp @@ -134,7 +134,11 @@ PhotoMetadata* PhotoMetadata::fromFile(const char* filepath) result->m_keysPresent.insert(QString(i->key().c_str())); return result; +#if EXIV2_TEST_VERSION(0,28,0) +} catch (Exiv2::Error& e) { +#else } catch (Exiv2::AnyError& e) { +#endif qDebug("Error loading image metadata: %s", e.what()); delete result; return NULL; @@ -165,7 +169,11 @@ Orientation PhotoMetadata::orientation() const if (m_keysPresent.find(EXIF_ORIENTATION_KEY) == m_keysPresent.end()) return DEFAULT_ORIENTATION; +#if EXIV2_TEST_VERSION(0,28,0) +uint32_t orientation_code = exif_data[EXIF_ORIENTATION_KEY].toUint32(); +#else long orientation_code = exif_data[EXIF_ORIENTATION_KEY].toLong(); +#endif if (orientation_code < MIN_ORIENTATION || orientation_code > MAX_ORIENTATION) return DEFAULT_ORIENTATION; @@ -244,7 +252,11 @@ void PhotoMetadata::setDateTimeDigitized(const QDateTime& digitized) if (!m_keysPresent.contains(EXIF_DATETIMEDIGITIZED_KEY)) m_keysPresent.insert(EXIF_DATETIMEDIGITIZED_KEY); +#if EXIV2_TEST_VERSION(0,28,0) +} catch (Exiv2::Error& e) { +#else } catch (Exiv2::AnyError& e) { +#endif qDebug("Do not set DateTimeDigitized, error reading image metadata; %s", e.what()); return; } @@ -259,7 +271,11 @@ bool PhotoMetadata::save() const try { m_image->writeMetadata(); return true; +#if EXIV2_TEST_VERSION(0,28,0) +} catch (Exiv2::Error& e) { +#else } catch (Exiv2::AnyError& e) { +#endif return false; } } diff --git a/src/photo/photo-metadata.h b/src/photo/photo-metadata.h index a2687b8d..daf2ee49 100644 --- a/src/photo/photo-metadata.h +++ b/src/photo/photo-metadata.h @@ -59,7 +59,11 @@ public: private: PhotoMetadata(const char* filepath); +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr m_image; +#else Exiv2::Image::AutoPtr m_image; +#endif QSet m_keysPresent; QFileInfo m_fileSourceInfo; }; -- 2.43.0
Bug#1073480: llvm-17-dev: shipped Findzstd.cmake conflicts with cmake module provided by libzstd-dev
Source: qt6-base Followup-For: Bug #1073480 X-Debbugs-Cc: pkg-llvm-t...@lists.alioth.debian.org Control: reassign -1 llvm-17-dev Control: severity -1 important Hi, after a big of debugging, I think I got to the actual reason for this failure. In particular, starting from LLVM 16, there is a shipped cmake find module to find libzstd: $ dpkg -L llvm-17-dev | grep -i zstd /usr/lib/llvm-17/lib/cmake/llvm/Findzstd.cmake The problem here is that it defines cmake targets with the same name as those defined by the libzstd own cmake config modules: $ dpkg -L libzstd-dev | grep -i cmake /usr/lib/x86_64-linux-gnu/cmake /usr/lib/x86_64-linux-gnu/cmake/zstd /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdConfig.cmake /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdConfigVersion.cmake /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets-none.cmake /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets.cmake This can be easily reproduced on a clean system with only LLVM and libzstd development files, and a very simple CMakeLists.txt file: $ podman run -ti --rm --pull=newer debian:unstable root@514df0e64d7b:/# apt-get update root@514df0e64d7b:/# apt-get -y dist-upgrade root@514df0e64d7b:/# apt-get --no-install-recommends install gcc g++ make cmake libzstd-dev llvm-17-dev root@514df0e64d7b:/# cd /tmp/ root@514df0e64d7b:/tmp# cat >CMakeLists.txt < cmake_minimum_required(VERSION 3.20) > project(test) > find_package(LLVM CONFIG) > find_package(zstd CONFIG) > EOF root@514df0e64d7b:/tmp# mkdir build root@514df0e64d7b:/tmp# cd build/ root@514df0e64d7b:/tmp/build# cmake .. -- The C compiler identification is GNU 13.3.0 -- The CXX compiler identification is GNU 13.3.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Performing Test HAVE_FFI_CALL -- Performing Test HAVE_FFI_CALL - Success -- Found FFI: /usr/lib/x86_64-linux-gnu/libffi.so -- Could NOT find LibEdit (missing: LibEdit_INCLUDE_DIRS LibEdit_LIBRARIES) -- Performing Test Terminfo_LINKABLE -- Performing Test Terminfo_LINKABLE - Success -- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so -- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.3.1") -- Found zstd: /usr/lib/x86_64-linux-gnu/libzstd.so -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.12.7") -- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR) -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success -- Found Threads: TRUE CMake Error at /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdTargets.cmake:42 (message): Some (but not all) targets in this export set were already defined. Targets Defined: zstd::libzstd_shared, zstd::libzstd_static Targets not yet defined: zstd::libzstd Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/zstd/zstdConfig.cmake:42 (include) CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! The order of the bits in the CMakeLists.txt is the key: - the cmake find module shipped by LLVM defines two targets, zstd::libzstd_shared and zstd::libzstd_static - the libzstd cmake config module defines three targets, i.e. zstd::libzstd_shared, zstd::libzstd_static, and zstd::libzstd - the libzstd cmake config module expects a "all or nothing situation", as it assumes that if one is defined, then all the others are too (AFAIK this is done so that multiple calls to find_package(zstd) will not redefine things) This is exactly the situation in qt6-tools: first Clang is searched (which in turns requires LLVM), and then zstd. Hence: - I'm reassigning this to llvm, as it is clearly a bug there; IMHO either the module needs to be taught about the zstd::libzstd target, or it needs to try to use the libzstd config module - I'm lowering the severity of this to important, since it is a not so common situation - I will add a workaround in qt6-tools -- Pino
Bug#1074670: amarok: FTBFS: unsatisfiable build-dependency: libmariadb-dev (= 1:10.11.8-1) but 1:11.4.2-1 is to be installed
Source: amarok Followup-For: Bug #1074670 X-Debbugs-Cc: pkg-mysql-ma...@lists.alioth.debian.org Control: reassign -1 src:mariadb mariadb/1:11.4.2-1 Control: retitle -1 please build again the embedded server, needed by amarok Control: affects -1 + src:amarok Hi, this dependency issue happens because the upload of mariadb 1:11.4.2-1 drops the embedded server [1] with not exactly clear reasons: | * Stop building the embedded server to save disk space The embedded server is needed by Amarok, newly reintroduced into the Debian archive. Strictly speaking, Amarok can be built without the embedded server, however it will require a real MySQL/MariaDB server available and usable, which is not exactly the best experience for "desktop users". Hence: dear MariaDB packagers, please reintroduce the embedded server in Debian, thanks. [1] https://tracker.debian.org/news/1540944/accepted-mariadb-11142-1-source-amd64-all-into-unstable/ Thanks, -- Pino
Bug#1074124: source:pulseaudio-qt: Misalignment between Qt5/Qt6 package names, package description and dependencies
Source: pulseaudio-qt Followup-For: Bug #1074124 X-Debbugs-Cc: marco.matti...@hotmail.it Control: retitle -1 libkf6pulseaudioqt-dev: wrong dependency on qtbase5-dev rather than qt6-base-dev Hi, regarding the package names, looking at pulseaudio-qt 1.5.0: - there are two libraries, libKF5PulseAudioQt and libKF6PulseAudioQt; - both the libraries have "6" as part of their SONAME (in particular, it's the SOVERSION) Because of the above, the names of the binary packages contaning them, according to the Debian Policy [1], are libkf5pulseaudioqt5 and libkf6pulseaudioqt5. In pulseaudio-qt 1.4.0, the libraries had "4" as SOVERSION, and thus they were named libkf5pulseaudioqt4 and libkf6pulseaudioqt4 accordingly. If the ABI of the libraries will be changed in an incompatible way in a new version pulseaudio-qt, the SOVERSION will be bumped to "5", and we will have libkf5pulseaudioqt6 and libkf6pulseaudioqt6. Hence, there is no mistake regarding the package names and their descriptions. The potentially confusing bit is that some other libraries use suffixes such as "qtN"/"-qtN" to distriguish which Qt version they are built for. This is not done in case of pulseaudio-qt, as there is already the Framework version in the name ("KF5"/"KF6"). The other issue reported is about libkf6pulseaudioqt-dev that depends on qtbase5-dev: this is indeed a bug, and I just pushed a fix for that in the packaging repository, thanks. I will upload it once pulseaudio-qt 1.5.0 migrates to testing (so at least tomorrow). Also, not sure how the wrong dependency "messes things up": both qtbase5-dev and qt6-base-dev are perfectly coinstallable -- this very source pulls them both to build both the Qt5 and Qt6 libraries at the same time. [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#run-time-shared-libraries Thanks, -- Pino
Bug#1071027: hdrmerge: FTBFS with exiv2 0.28
Source: hdrmerge Followup-For: Bug #1071027 X-Debbugs-Cc: t...@debian.org Alex, would you please take a look at this? hdrmerge is one of the very few sources that still does not support Exiv2 0.28+, and I'm preparing the transition for it soon. Thanks in advance! -- Pino
Bug#1073982: transition: pulseaudio-qt
Package: release.debian.org Severity: normal X-Debbugs-Cc: pulseaudio...@packages.debian.org Control: affects -1 + src:pulseaudio-qt User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for the update of pulseaudio-qt to 1.5.0. The only user of pulseaudio-qt currently is kdeconnect, and I verified it builds fine with the new version of pulseaudio-qt. Ben file: title = "pulseaudio-qt"; is_affected = .depends ~ "libkf5pulseaudioqt4" | .depends ~ "libkf6pulseaudioqt4" | .depends ~ "libkf5pulseaudioqt5" | .depends ~ "libkf6pulseaudioqt5"; is_good = .depends ~ "libkf5pulseaudioqt5" | .depends ~ "libkf6pulseaudioqt5"; is_bad = .depends ~ "libkf5pulseaudioqt4" | .depends ~ "libkf6pulseaudioqt4"; Thanks, -- Pino
Bug#1071028: viewnior: FTBFS with exiv2 0.28
Followup-For: Bug #1071028 Hi Dominik, thanks for the upload of 1.8-4, which carries the changes I proposed. Would you please upload that to unstable, so it can fix the problem altogether? The version required (exiv2 0.27) is present already in the current Debian stable. Thanks, -- Pino
Bug#1071979: pinot: FTBFS with exiv2 0.28
Source: pinot Version: 1.21-1 Severity: important Tags: patch ftbfs Control: forwarded -1 https://github.com/FabriceColin/pinot/pull/11 Hi, pinot fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; that version is available in experimental as of this writing. Upstream recently merged a PR to fix this [1]. I extracted the patch/commit from that upstream PR, and verified that it builds fine with both Exiv2 0.27 and Exiv2 0.28; you can find it attached to this bug. Would you review this patch, and upload it so that pinot rebuilds cleanly once a newer Exiv2 is uploaded to unstable? [1] https://github.com/FabriceColin/pinot/pull/11 Thanks, -- Pino >From b52b8184a260e77bc72fea3e8e5bd163cf36b79d Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Sun, 25 Feb 2024 19:40:01 +0100 Subject: [PATCH] Support Exiv2 0.28+ Use the new types for the image pointer and exception class as available in the new Exiv2 version, keeping the support for older versions. --- Tokenize/filters/Exiv2ImageFilter.cc | 9 + 1 file changed, 9 insertions(+) diff --git a/Tokenize/filters/Exiv2ImageFilter.cc b/Tokenize/filters/Exiv2ImageFilter.cc index ceac398..6b685b3 100644 --- a/Tokenize/filters/Exiv2ImageFilter.cc +++ b/Tokenize/filters/Exiv2ImageFilter.cc @@ -26,6 +26,7 @@ #include #include #include +#include #ifdef HAVE_EXIV2_XMP_EXIV2_HPP #include #include @@ -236,7 +237,11 @@ bool Exiv2ImageFilter::next_document(void) try { +#if EXIV2_TEST_VERSION(0,28,0) + Exiv2::Image::UniquePtr image = Exiv2::ImageFactory::open(m_filePath); +#else Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(m_filePath); +#endif if (image.get() == NULL) { clog << m_filePath.c_str() << " is not an image" << endl; @@ -388,7 +393,11 @@ bool Exiv2ImageFilter::next_document(void) } } } +#if EXIV2_TEST_VERSION(0,28,0) + catch (Exiv2::Error &e) +#else catch (Exiv2::AnyError &e) +#endif { clog << "Caught exiv2 exception: " << e << endl; foundData = false; -- 2.43.0
Bug#1071028: viewnior: FTBFS with exiv2 0.28
Source: viewnior Version: 1.8-3 Severity: important Tags: patch ftbfs Control: forwarded -1 https://github.com/hellosiyan/Viewnior/pull/134 Hi, viewnior fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; that version is available in experimental as of this writing. There are two upstream PRs to address this problem, i.e. PR 130 [1] and PR 134, and sadly they have been sitting there for some months now (viewnior does not seem an actively developed project). I chose PR 134, as I find it as cleaner approach, I extracted the patch/commit from it, and verified that it builds fine with both Exiv2 0.27 and Exiv2 0.28; you can find it attached to this bug. Would you review this patch, and upload it so that viewnior rebuilds cleanly once a newer Exiv2 is uploaded to unstable? In addition to the actual fix, I attached an update of the libexiv2-dev build dependency, which is the result of the backported patch. [1] https://github.com/hellosiyan/Viewnior/pull/130 [2] https://github.com/hellosiyan/Viewnior/pull/134 Thanks, -- Pino Author: Robert-André Mauchin Description: Fix build with >=exiv2-0.28.0, raise minimum to 0.27.0 - enables use of EXIV2_TEST_VERSION macro - add compatibility for exiv2-0.28.0 Forwarded: https://github.com/hellosiyan/Viewnior/pull/134 Last-Update: 2023-11-11 diff --git a/meson.build b/meson.build index 8f91fb5..9ef9f09 100644 --- a/meson.build +++ b/meson.build @@ -28,7 +28,7 @@ viewnior_deps = [ dependency('gio-2.0', version: glib_ver), dependency('shared-mime-info', version: '>= 0.20'), dependency('gdk-pixbuf-2.0', version: '>= 0.21'), - dependency('exiv2', version: '>= 0.21'), + dependency('exiv2', version: '>= 0.27'), ] # diff --git a/src/uni-exiv2.cpp b/src/uni-exiv2.cpp index 0d14b9f..d03edd7 100644 --- a/src/uni-exiv2.cpp +++ b/src/uni-exiv2.cpp @@ -22,12 +22,21 @@ #include #include +#include #include "uni-exiv2.hpp" +#if EXIV2_TEST_VERSION(0,28,0) +typedef Exiv2::Error Exiv2Error; +typedef Exiv2::Image::UniquePtr ImagePtr; +#else +typedef Exiv2::AnyError Exiv2Error; +typedef Exiv2::Image::AutoPtr ImagePtr; +#endif + #define ARRAY_SIZE(array) (sizeof array/sizeof(array[0])) -static Exiv2::Image::AutoPtr cached_image; +static ImagePtr cached_image; extern "C" void @@ -35,7 +44,7 @@ uni_read_exiv2_map(const char *uri, void (*callback)(const char*, const char*, v { Exiv2::LogMsg::setLevel(Exiv2::LogMsg::mute); try { -Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(uri); +ImagePtr image = Exiv2::ImageFactory::open(uri); if ( image.get() == 0 ) { return; } @@ -80,7 +89,7 @@ uni_read_exiv2_map(const char *uri, void (*callback)(const char*, const char*, v } } } -} catch (Exiv2::AnyError& e) { +} catch (Exiv2Error& e) { std::cerr << "Exiv2: '" << e << "'\n"; } } @@ -103,7 +112,7 @@ uni_read_exiv2_to_cache(const char *uri) } cached_image->readMetadata(); -} catch (Exiv2::AnyError& e) { +} catch (Exiv2Error& e) { std::cerr << "Exiv2: '" << e << "'\n"; } @@ -121,7 +130,7 @@ uni_write_exiv2_from_cache(const char *uri) } try { -Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(uri); +ImagePtr image = Exiv2::ImageFactory::open(uri); if ( image.get() == 0 ) { return 2; } @@ -133,7 +142,7 @@ uni_write_exiv2_from_cache(const char *uri) cached_image.reset(NULL); return 0; -} catch (Exiv2::AnyError& e) { +} catch (Exiv2Error& e) { std::cerr << "Exiv2: '" << e << "'\n"; } -- 2.43.0 --- a/debian/control +++ b/debian/control @@ -6,7 +6,7 @@ Build-Depends: debhelper-compat (= 13), meson, intltool (>= 0.35.0), - libexiv2-dev, + libexiv2-dev (>= 0.27.0), libgtk-3-dev Standards-Version: 4.6.2 Homepage: https://siyanpanayotov.com/project/viewnior/
Bug#1071027: hdrmerge: FTBFS with exiv2 0.28
Source: hdrmerge Version: 0.5+git20200117-3.1 Severity: important Tags: patch ftbfs X-Debbugs-Cc: gur...@phys.ethz.ch Control: forwarded -1 https://github.com/jcelaya/hdrmerge/pull/222 Hi, hdrmerge fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; that version is available in experimental as of this writing. There is a proposed patch upstream to fix this [1], and sadly it has been sitting there for some months now (hdrmerge does not seem an actively developed project). I extracted the patch/commit from that upstream PR, and verified that it builds fine with both Exiv2 0.27 and Exiv2 0.28; you can find it attached to this bug. Would you review this patch, and upload it so that hdrmerge rebuilds cleanly once a newer Exiv2 is uploaded to unstable? [1] https://github.com/jcelaya/hdrmerge/pull/222 Thanks, -- Pino Author: Lukáš Jirkovský Description: Adapt to Exiv2 0.28.0 API change. Last-Update: 2023-08-03 Forwarded: https://github.com/jcelaya/hdrmerge/pull/222 diff --git a/src/ExifTransfer.cpp b/src/ExifTransfer.cpp index bc8f4f9..0598172 100644 --- a/src/ExifTransfer.cpp +++ b/src/ExifTransfer.cpp @@ -41,7 +41,11 @@ private: QString srcFile, dstFile; const uint8_t * data; size_t dataSize; +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr src, dst; +#else Exiv2::Image::AutoPtr src, dst; +#endif void copyXMP(); void copyIPTC(); @@ -58,7 +62,11 @@ void hdrmerge::Exif::transfer(const QString & srcFile, const QString & dstFile, void ExifTransfer::copyMetadata() { try { +#if EXIV2_TEST_VERSION(0,28,0) +dst = Exiv2::ImageFactory::open(BasicIo::UniquePtr(new MemIo(data, dataSize))); +#else dst = Exiv2::ImageFactory::open(BasicIo::AutoPtr(new MemIo(data, dataSize))); +#endif dst->readMetadata(); } catch (Exiv2::Error & e) { std::cerr << "Exiv2 error: " << e.what() << std::endl; diff --git a/src/RawParameters.cpp b/src/RawParameters.cpp index 40b77de..e6a38eb 100644 --- a/src/RawParameters.cpp +++ b/src/RawParameters.cpp @@ -49,7 +49,11 @@ void RawParameters::loadCamXyzFromDng() { cc[j][i] = i == j ? 1.0 : 0.0; } } +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr src = Exiv2::ImageFactory::open(fileName.toLocal8Bit().constData()); +#else Exiv2::Image::AutoPtr src = Exiv2::ImageFactory::open(fileName.toLocal8Bit().constData()); +#endif src->readMetadata(); const Exiv2::ExifData & srcExif = src->exifData(); -- 2.43.0
Bug#1064639: phototonic: FTBFS with exiv2 0.28
Source: phototonic Followup-For: Bug #1064639 Hi Laszlo, now that the time_t transition is over, would you please take a look at this patch for phototonic? I'm starting to prepare an Exiv2 0.28+ transition, and fixing this will drop one roadblock. Thanks in advance! -- Pino
Bug#1070806: RM: kseexpr/experimental -- ROM; 64bit time_t transition not needed
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ksee...@packages.debian.org Control: affects -1 + src:kseexpr User: ftp.debian@packages.debian.org Usertags: remove Hi, please remove kseexpr from experimental: the 64bit time_t transition for it is not needed, as the only time_t reference is an unused typedef in a public header. Thanks, -- Pino
Bug#1070703: transition: libunibreak
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. Ben file: title = "libunibreak"; is_affected = .depends ~ "libunibreak5" | .depends ~ "libunibreak6"; is_good = .depends ~ "libunibreak6"; is_bad = .depends ~ "libunibreak5"; Thanks, -- Pino
Bug#1064639: phototonic: FTBFS with exiv2 0.28
Source: phototonic Version: 2.1-3 Severity: important Tags: upstream patch ftbfs fixed-upstream Hi, phototonic fails to build with the new stable series of the Exiv2 library, i.e. 0.28.x; that version is available in experimental as of this writing. The compatibility was fixed upstream with the following two commits: - https://github.com/oferkv/phototonic/commit/7de1014fd5e28cd1578847aa4847e463696938d9 - https://github.com/oferkv/phototonic/commit/2d1ab87c5f8a840a3db5c9f478a7d20dfca1ec1f They do not apply cleanly, as there were lots of changes upstream since the last release; hence, I applied the changes manually into a single patch, which is attached, and which maintains the compatibility with Exiv2 0.27.x. Would you please review this patch, and upload it so that phototonic rebuilds cleanly once a newer Exiv2 is uploaded to unstable? Side note: the upstream project was switched to read-only few months ago, with a note in its README: "This project is unmaintained. See Geeqie for an alternative." Thanks, -- Pino Author: Andreas Sturmlechner Author: Pino Toscano Description: Fix build with exiv2-0.28 Modelled after the upstream commits: - https://github.com/oferkv/phototonic/commit/7de1014fd5e28cd1578847aa4847e463696938d9 - https://github.com/oferkv/phototonic/commit/2d1ab87c5f8a840a3db5c9f478a7d20dfca1ec1f Origin: backport, https://github.com/oferkv/phototonic/commit/7de1014fd5e28cd1578847aa4847e463696938d9, https://github.com/oferkv/phototonic/commit/2d1ab87c5f8a840a3db5c9f478a7d20dfca1ec1f Last-Update: 2024-02-25 --- a/ImageViewer.cpp +++ b/ImageViewer.cpp @@ -945,7 +945,11 @@ void ImageViewer::keyMoveEvent(int direc } void ImageViewer::saveImage() { +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr image; +#else Exiv2::Image::AutoPtr image; +#endif bool exifError = false; if (newImage) { @@ -985,8 +989,13 @@ void ImageViewer::saveImage() { } void ImageViewer::saveImageAs() { +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr exifImage; +Exiv2::Image::UniquePtr newExifImage; +#else Exiv2::Image::AutoPtr exifImage; Exiv2::Image::AutoPtr newExifImage; +#endif bool exifError = false; setCursorHiding(false); --- a/MetadataCache.cpp +++ b/MetadataCache.cpp @@ -64,7 +64,11 @@ void MetadataCache::clear() { } bool MetadataCache::loadImageMetadata(const QString &imageFullPath) { +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr exifImage; +#else Exiv2::Image::AutoPtr exifImage; +#endif QSet tags; long orientation = 0; @@ -78,7 +82,11 @@ bool MetadataCache::loadImageMetadata(co try { Exiv2::ExifData &exifData = exifImage->exifData(); if (!exifData.empty()) { +#if EXIV2_TEST_VERSION(0,28,0) +orientation = exifData["Exif.Image.Orientation"].value().toUint32(); +#else orientation = exifData["Exif.Image.Orientation"].value().toLong(); +#endif } } catch (Exiv2::Error &error) { qWarning() << "Failed to read Exif metadata"; --- a/Phototonic.cpp +++ b/Phototonic.cpp @@ -3151,7 +3151,11 @@ void Phototonic::removeMetadata() { if (ret == MessageBox::Yes) { for (int file = 0; file < fileList.size(); ++file) { +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr image; +#else Exiv2::Image::AutoPtr image; +#endif try { image = Exiv2::ImageFactory::open(fileList[file].toStdString()); image->clearMetadata(); --- a/Tags.cpp +++ b/Tags.cpp @@ -136,7 +136,11 @@ void ImageTags::addTag(QString tagName, bool ImageTags::writeTagsToImage(QString &imageFileName, QSet &newTags) { QSet imageTags; +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr exifImage; +#else Exiv2::Image::AutoPtr exifImage; +#endif try { exifImage = Exiv2::ImageFactory::open(imageFileName.toStdString()); @@ -160,7 +164,11 @@ bool ImageTags::writeTagsToImage(QString QSetIterator newTagsIt(newTags); while (newTagsIt.hasNext()) { QString tag = newTagsIt.next(); +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Value::UniquePtr value = Exiv2::Value::create(Exiv2::string); +#else Exiv2::Value::AutoPtr value = Exiv2::Value::create(Exiv2::string); +#endif value->read(tag.toStdString()); Exiv2::IptcKey key("Iptc.Application2.Keywords"); newIptcData.add(key, value.get()); --- a/ThumbsViewer.cpp +++ b/ThumbsViewer.cpp @@ -210,7 +210,11 @@ void ThumbsViewer::updateImageInfoViewer infoView->addEntry(key, val); } +#if EXIV2_TEST_VERSION(0,28,0) +Exiv2::Image::UniquePtr exifImage; +#else Exiv2::Image::AutoPtr exifImage; +#endif try { exifImage = Exiv2::ImageFactory::open(imageFullPath.toStdString()); exifImage->readMetadata();
Bug#1052253: transition: libunibreak
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak Hi, I'd like to request a transition slot for the much needed update of the libunibreak library (from 1.1 to 5.1). The only dependency in Debian is fbreader, which I verified that builds fine using the new version of libunibreak. Ben file: title = "libunibreak"; is_affected = .depends ~ "libunibreak1" | .depends ~ "libunibreak5"; is_good = .depends ~ "libunibreak5"; is_bad = .depends ~ "libunibreak1"; Thanks, -- Pino
Bug#1052252: transition: grantlee5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: grantl...@packages.debian.org, pkg-kde-t...@alioth-lists.debian.net Control: affects -1 + src:grantlee5 Hi, grantlee (packaged in Debian in src:grantlee5) is a library (two libraries, in practice) that has a stable API/ABI. The new release 5.3.x, currently in experimental, is generally usable by users built with the old version. The only gotcha is that plugins for it are installed and loaded from paths with the major and minor version in it, i.e. ../plugins/grantlee/./ This means that, after the upgrade to a new minor series, the plugins installed after building with the old version are not used anymore; usually software using grantlee and shipping plugins for it follows the grantlee version, so a simple rebuild is enough to fix the issue. Since I wanted to avoid uploading the new version and have to manually track external plugins and breaking users that rely on those plugins, I created a new simple dh_grantlee helper to track the dependency on the version the plugins were built for, adding the provide for it in one of the two grantlee libraries as "grantlee5-templates-MAJOR-MINOR". This is already in place in unstable starting from grantlee5 5.2.0-5, and the 4 sources that install plugins for it were already changed to use dh_grantlee, and thus now properly track their plugin dependency. Hence, I'd like to request a transition slot for uploading grantlee5 5.3.x to unstable, rebuilding the few dependencies needed: - kcalutils - kdevelop - libkf5grantleetheme - skrooge They all build fine with the new grantlee; I have the new version of kdevelop ready in experimental, and I can upload that rather than rebuilding the current version in unstable. Ben file: title = "grantlee5"; is_affected = .depends ~ "grantlee5-templates-5-2" | .depends ~ "grantlee5-templates-5-3"; is_good = .depends ~ "grantlee5-templates-5-3"; is_bad = .depends ~ "grantlee5-templates-5-2"; Thanks, -- Pino
Bug#1042366: RM: kchmviewer [armel ppc64el s390x] -- ROM; requires QtWebEngine
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kchmvie...@packages.debian.org Control: affects -1 + src:kchmviewer Hi, the new version of src:kchmviewer requires QtWebEngine for the main interface: as result, it is built only on few architectures. Hence, please remove kchmviewer on the following architectures: armel ppc64el s390x Thanks, -- Pino
Bug#1042069: RM: libvirt-daemon-driver-storage-gluster [armel armhf i386 mipsel] -- RoQA; glusterfs soon to be 64bit-only
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libv...@packages.debian.org Control: affects -1 + src:libvirt Hi, please remove the libvirt-daemon-driver-storage-gluster binary package on 32bit architectures: the libvirt 9.5.0-2 upload drops support for glusterfs on those architectures, as glusterfs itself is going to be 64bit-only soon (see [1], and #1039604). [1] https://tracker.debian.org/news/168/accepted-glusterfs-110-1-source-into-experimental/ Thanks, -- Pino
Bug#1041516: RM: kalgebra kalgebra-common [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kalge...@packages.debian.org Control: affects -1 + src:kalgebra Control: block 1041268 by -1 Hi, please remove the kalgebra & kalgebra-common binary packages on mipsel: they used to be built because qtwebengine-opensource-src is available on mipsel. Since qtwebengine-opensource-src FTBFSes on mipsel, and it is scheduled for removal on architecture, please remove the cruft binaries. Please note that src:kalgebra still builds a kalgebramobile binary package on mipsel (like in all the architectures without QtWebEngine). Thanks, -- Pino
Bug#1041515: RM: kalendar [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kalen...@packages.debian.org Control: affects -1 + src:kalendar Control: block 1041268 by -1 Hi, please remove kalendar from mipsel: it uses qtwebengine-opensource-src, which currently FTBFS on mipsel, and thus kalendar was excluded from building on mipsel. Thanks, -- Pino
Bug#1040957: xine-lib-1.2: FTBFS on hurd-i386
Source: xine-lib-1.2 Version: 1.2.13+hg20230710-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: found -1 1.2.12-1 Hi, xine-lib-1.2 currently FTBFSes on hurd-i386 [1]. The problem is that the VAAPI support is not available on hurd-i386, and libxine2-x unconditionally installs files that are built for that. The attached patch fixes the issue, by limiting the VAAPI plugins that were not already limited on some architectures (e.g. the wayland one) as !hurd-any, like the libva-dev build dependency. As I was tweaking/fixing the packaging for hurd-i386, I included also few more Hurd-related changes: - enable the smb plugin also on the Hurd, as samba is now built there - change the exclusion architecture pattern for the vcdo plugin to !hurd-any, as it applies to any Hurd architecture and not only to hurd-i386 [1] https://buildd.debian.org/status/fetch.php?pkg=xine-lib-1.2&arch=hurd-i386&ver=1.2.13%2Bhg20230710-1&stamp=1689013434&raw=0 Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -30,7 +30,7 @@ Build-Depends: debhelper-compat (= 13), libpulse-dev, librsvg2-bin, libsdl1.2-compat-dev, - libsmbclient-dev [!hurd-i386], + libsmbclient-dev, libspeex-dev, libtheora-dev, libv4l-dev [linux-any], --- a/debian/libxine2-misc-plugins.install +++ b/debian/libxine2-misc-plugins.install @@ -9,11 +9,11 @@ debian/tmp/usr/lib/*/xine/plugins/*/xine debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_network.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_pvr.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_rtp.so -[!hurd-i386] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_smb.so +debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_smb.so #[linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_v4l.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_v4l2.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_vcd.so -[!hurd-i386] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_vcdo.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_vcdo.so # audio output plugins [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_ao_out_alsa.so --- a/debian/libxine2-x.install +++ b/debian/libxine2-x.install @@ -5,7 +5,7 @@ debian/tmp/usr/lib/*/xine/plugins/*/xine debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_opengl.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_opengl2.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_sdl.so -[linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_vaapi.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_vaapi.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_xcbshm.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_xcbxv.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_xdirectfb.so @@ -17,7 +17,7 @@ debian/tmp/usr/lib/*/xine/plugins/*/xine debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_gl_egl_x11.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_gl_glx.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_hw_frame_vaapi.so -debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_drm.so -debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_glx.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_drm.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_glx.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_wl.so -debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_x11.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_x11.so
Bug#1040582: stress-ng: improve the build dependencies (more availability, linux-any markers)
Source: stress-ng Version: 0.16.00-1 Severity: minor Tags: patch Hi, some of the build dependencies can be improved: - what is specific for Linux ought to be better marked as "linux-any", rather than excluding non-Linux architectures - some of the them are actually available on non-Linux too Attached there is a patch to improve them, with some extra details in the changelog. Thanks, -- Pino diff -Nru stress-ng-0.16.00/debian/changelog stress-ng-0.16.00/debian/changelog --- stress-ng-0.16.00/debian/changelog +++ stress-ng-0.16.00/debian/changelog @@ -1,3 +1,17 @@ +stress-ng (0.16.00-2) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Update/improve the build dependencies: +- enable libkeyutils-dev also on ia64, as it is available there as well +- enable libjudy-dev, libxxhash-dev, and libglvnd-dev on all the + architectures, as they are not specific to a certain OS +- switch the build dependencies that exist only on Linux from + "!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64" to "linux-any": + libkeyutils-dev, libapparmor-dev, apparmor, libaio-dev, libcap-dev, + libsctp-dev, libatomic1, libkmod-dev, libgbm-dev + + -- Colin Ian King Fri, 07 Jul 2023 19:47:54 +0200 + stress-ng (0.16.00-1) unstable; urgency=medium * Makefile: bump version to 0.16.00 diff -Nru stress-ng-0.16.00/debian/control stress-ng-0.16.00/debian/control --- stress-ng-0.16.00/debian/control +++ stress-ng-0.16.00/debian/control @@ -12,19 +12,19 @@ libgcrypt20-dev, libjpeg-dev, libmpfr-dev, - libkeyutils-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64 !linux-ia64], - libapparmor-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - apparmor [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libaio-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libcap-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libsctp-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], + libkeyutils-dev [linux-any], + libapparmor-dev [linux-any], + apparmor [linux-any], + libaio-dev [linux-any], + libcap-dev [linux-any], + libsctp-dev [linux-any], libipsec-mb-dev [amd64], - libjudy-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libatomic1 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libkmod-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libxxhash-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libglvnd-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libgbm-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] + libjudy-dev, + libatomic1 [linux-any], + libkmod-dev [linux-any], + libxxhash-dev, + libglvnd-dev, + libgbm-dev [linux-any] Homepage: https://github.com/ColinIanKing/stress-ng Package: stress-ng
Bug#1040418: nmu: libheif_1.16.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libh...@packages.debian.org, ba...@struktur.de, sramac...@debian.org Control: affects -1 + src:libheif nmu libheif_1.16.2-1 . ANY . unstable . -m "rebuild on buildd" Please rebuild libheif (on all architectures, as it has M-A:same binaries), so it can migrate to testing; kimageformat will need it soon. Thanks, -- Pino
Bug#907152: vulkan: Porting to non-linux systems
Source: vulkan-loader Followup-For: Bug #907152 X-Debbugs-Cc: tjaal...@debian.org Control: tag -1 = upstream fixed-upstream Hi! The vulkan source changed a while since this bug was originally reported: it was split into components, with this bug reassigned to to the loader, and in it was ported to more architectures. I recently ported this to Hurd again, with good results: the upstream tests pass, and it was reviewed and merged upstream: https://github.com/KhronosGroup/Vulkan-Loader/pull/1244 Because of this, I submitted the enablement of src:vulkan-loader to non-Linux architectures, as the actual Hurd porting will come in soon in new upstream releases (I guess in versions greater than 1.3.250): https://salsa.debian.org/xorg-team/vulkan/vulkan-loader/-/merge_requests/14 I'm *not* submitting the upstream Hurd patch to downstream backport: the code upstream was refactored, so a good part of it would need to be rewritten, which is not that worth of effort for something that has never been available yet. -- Pino
Bug#1040123: sane-backends: FTBFS on hurd-386: unsupported parallel port IO
Source: sane-backends Version: 1.1.1-6 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: found -1 1.2.1-3 Hi, starting from sane-backends 1.1.1-6, there are in effect changes to the Debian packaging that cause --enable-parport-directio to be enabled only on hurd-386 [1][2][3]. In reality parallel port is not supported on the Hurd, and thus sane-backends FTBFS on hurd-i386 since 1.1.1-6 [4][5]. The fix here is to not use --enable-parport-directio, as it used to be in versions before 1.1.1-6; since the INS_CONF variable in d/rules is used only for this, then it can be dropped altogether. Easy patch attached. [1] https://git.jff.email/cgit/sane-backends.git/commit/debian/rules?id=a7fdf31671fc8393d8c50ad2e14668ce5d78282a [2] https://git.jff.email/cgit/sane-backends.git/commit/debian/rules?id=8a20544b5a6784e2c5ecbafc4ba2fa91c26c16aa [3] https://git.jff.email/cgit/sane-backends.git/commit/debian/rules?id=1e25318379249c8c4c2c55c741b409a858b1f52e [4] https://buildd.debian.org/status/fetch.php?pkg=sane-backends&arch=hurd-i386&ver=1.1.1-6&stamp=1664715955&raw=0 [5] https://buildd.debian.org/status/fetch.php?pkg=sane-backends&arch=hurd-i386&ver=1.2.1-3&stamp=1688016732&raw=0 Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -14,13 +14,6 @@ ifeq (,$(findstring nostrip,$(DEB_BUILD_ STRIP = "" endif -ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH))) - INS_CONF = "" -else - INS_CONF = --enable-parport-directio -endif - - %: dh $@ @@ -56,8 +49,7 @@ endif --enable-pnm-backend \ --with-usb \ --without-v4l \ - --disable-locking \ - $(INS_CONF) + --disable-locking override_dh_autoreconf: dh_autoreconf -Xlibtool.m4
Bug#1039055: qxmpp: please package qxmpp 1.5+
Source: qxmpp Severity: wishlist X-Debbugs-Cc: tehn...@debian.org Control: block 1036558 by -1 Hi, please package a upstream version of qxmpp, at least >= 1.5, currently 1.5.5; this is needed to update kaidan to 0.9.0+). Thanks! -- Pino
Bug#1021857: llvm-14-dev: ClangConfig.cmake is still broken
Package: llvm-14-dev Followup-For: Bug #1021857 Hi, (sending properly again) 1:14.0.6-6 does some changes, however it does not fix all of it; this is while trying to build qtcreator: CMake Error at /usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake:756 (message): The imported target "diagtool" references the file "/usr/lib/llvm-14/bin/diagtool" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/cmake/clang-14/ClangConfig.cmake:19 (include) cmake/FindClang.cmake:1 (find_package) CMakeLists.txt:100 (find_package) In practice, ClangTargets.cmake is still broken, as it tries to look for tools. I think that the "cmake-test" is incomplete, as it only tests the "LLVM" cmake module and not the "Clang" one; adding a new check for find_package(Clang) should help to make sure all the cmake bits are working as expected. Thanks, -- Pino
Bug#1021857: reopening 1021857
reopen 1021857 thanks 1:14.0.6-6 does some changes, however it does not fix all of it; this is while trying to build qtcreator: CMake Error at /usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake:756 (message): The imported target "diagtool" references the file "/usr/lib/llvm-14/bin/diagtool" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/cmake/clang-14/ClangConfig.cmake:19 (include) cmake/FindClang.cmake:1 (find_package) CMakeLists.txt:100 (find_package) Thanks, -- Pino
Bug#1019300: mp3guessenc: autopkgtests failure with grep 3.8: fgrep is deprecated
Source: mp3guessenc Version: 0.27.5+dfsg.1-1 Severity: serious Tags: patch Justification: breaks autopkgtests Hi, GNU grep 3.8 officially deprecates egrep and fgrep, and those two commands now issue a deprecation message on stderr [1]. The autopkgtests of mp3guessenc use fgrep, and while they still work fine, the extra messages on stderr are considered by default a failure, and thus the tests are marked as such. While autopkgtest has a "allow-stderr" restriction to not consider stderr output as failure in case it is expected, I think the better solution here is simply to switch away from fgrep to grep -F. This works fine with grep 3.8 and any older version. Patch attached for this. [1] https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html Thanks, -- Pino diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/changelog mp3guessenc-0.27.5+dfsg.1/debian/changelog --- mp3guessenc-0.27.5+dfsg.1/debian/changelog 2020-09-20 21:50:00.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/changelog 2022-09-07 08:12:34.0 +0200 @@ -1,3 +1,12 @@ +mp3guessenc (0.27.5+dfsg.1-2) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Switch from "fgrep" to "grep -F" in autopkgtests, as the former is +officially deprecated since grep 3.8, writing a deprecation message on +stderr that is considered as autopkgtest failure. + + -- Peter Blackman Wed, 07 Sep 2022 08:12:34 +0200 + mp3guessenc (0.27.5+dfsg.1-1) unstable; urgency=medium * New upstream version diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/a mp3guessenc-0.27.5+dfsg.1/debian/tests/a --- mp3guessenc-0.27.5+dfsg.1/debian/tests/a2020-07-16 10:49:55.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/a2022-09-07 08:12:13.0 +0200 @@ -6,7 +6,7 @@ mp3guessenc -a debian/flush.mp3 > a.tmp set -e # -fgrep 291 a.tmp +grep -F 291 a.tmp # rm a.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/f mp3guessenc-0.27.5+dfsg.1/debian/tests/f --- mp3guessenc-0.27.5+dfsg.1/debian/tests/f2020-07-16 10:43:15.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/f2022-09-07 08:12:13.0 +0200 @@ -6,8 +6,8 @@ mp3guessenc -f debian/flush.mp3 > f.tmp set -e # -fgrep "48 kbps" f.tmp -fgrep 550 f.tmp +grep -F "48 kbps" f.tmp +grep -F 550 f.tmp # rm f.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/i mp3guessenc-0.27.5+dfsg.1/debian/tests/i --- mp3guessenc-0.27.5+dfsg.1/debian/tests/i2020-07-16 10:48:58.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/i2022-09-07 08:12:13.0 +0200 @@ -6,8 +6,8 @@ mp3guessenc -i debian/flush.mp3 > i.tmp set -e # -fgrep 2020 i.tmp -fgrep Ambient i.tmp +grep -F 2020 i.tmp +grep -F Ambient i.tmp # rm i.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/m mp3guessenc-0.27.5+dfsg.1/debian/tests/m --- mp3guessenc-0.27.5+dfsg.1/debian/tests/m2020-07-16 10:44:39.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/m2022-09-07 08:12:13.0 +0200 @@ -6,8 +6,8 @@ mp3guessenc -f debian/flush.mp3 > f.tmp set -e # -fgrep "48 kbps" f.tmp -fgrep 550 f.tmp +grep -F "48 kbps" f.tmp +grep -F 550 f.tmp # rm f.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/n mp3guessenc-0.27.5+dfsg.1/debian/tests/n --- mp3guessenc-0.27.5+dfsg.1/debian/tests/n2020-07-16 11:08:27.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/n2022-09-07 08:12:13.0 +0200 @@ -11,7 +11,7 @@ fi set -e # -fgrep FhG n.tmp +grep -F FhG n.tmp # rm n.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/s mp3guessenc-0.27.5+dfsg.1/debian/tests/s --- mp3guessenc-0.27.5+dfsg.1/debian/tests/s2020-07-16 10:51:16.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/s2022-09-07 08:12:13.0 +0200 @@ -6,7 +6,7 @@ mp3guessenc -s debian/flush.mp3 > s.tmp set -e # -fgrep FhG s.tmp +grep -F FhG s.tmp # rm s.tmp
Bug#1017044: graphviz: please remove the Debian menu file
Package: graphviz Version: 2.42.2-7 Severity: minor Tags: patch Hi, graphviz currently provides a Debian menu file with two entries, for the dotty and lefty applications; however: - the Debian menu is deprecated for some years already [1] - none of the items in the menu file have icons - the applications are very niche - there are no desktop counterparts, nor requests for them either in Debian nor upstream Hence, rather than converting them to desktop files, I think it is a better idea to simply drop the old Debian menu file for now. In case there is a demand for those two applications, I think it would be better to ask upstream to provide proper desktop files for them. Attached there is a patch to simply drop the Debian menu file. [1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html Thanks, -- Pino diff -Nru graphviz-2.42.2/debian/changelog graphviz-2.42.2/debian/changelog --- graphviz-2.42.2/debian/changelog2022-06-15 19:55:30.0 +0200 +++ graphviz-2.42.2/debian/changelog2022-08-12 11:28:29.0 +0200 @@ -1,3 +1,15 @@ +graphviz (2.42.2-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop the Debian menu file: +- the Debian menu is deprecated for some years already +- none of the items in the menu file have icons +- the applications are very niche +- there are no desktop counterparts, nor requests for them either in Debian + nor upstream + + -- Pino Toscano Fri, 12 Aug 2022 11:28:29 +0200 + graphviz (2.42.2-7) unstable; urgency=medium * Recommend fonts-liberation2 (closes: #1003006). diff -Nru graphviz-2.42.2/debian/graphviz.menu graphviz-2.42.2/debian/graphviz.menu --- graphviz-2.42.2/debian/graphviz.menu2014-12-10 16:25:41.0 +0100 +++ graphviz-2.42.2/debian/graphviz.menu1970-01-01 01:00:00.0 +0100 @@ -1,4 +0,0 @@ -?package(graphviz):needs="X11" section="Applications/Graphics" \ - title="dotty" command="/usr/bin/dotty" -?package(graphviz):needs="X11" section="Applications/Graphics" \ - title="lefty" command="/usr/bin/lefty"
Bug#1016148: RM: kwayland-server -- ROM; dropped source from upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net Hi, please remove the kwayland-server source: its functionalities were moved to other KDE Plasma sources, and thus upstream dropped this. Thanks, -- Pino
Bug#1014672: gnunet-gtk: drop the not needed /usr/share/icons/gnunet-fs-gtk.png symlink
Package: gnunet-gtk Version: 0.16.0-2 Severity: minor Tags: patch Hi, gnunet-gtk ships a /usr/share/icons/gnunet-fs-gtk.png symlink to the application icon shipped in the XDG hicolor icon theme. This symlink is redundant, since the proper icons in various sizes are already available in the XDG hicolor icon theme. Hence, the symlink can be dropped. Easy patch attached for this. Thanks, -- Pino --- a/debian/gnunet-gtk.links +++ b/debian/gnunet-gtk.links @@ -1,2 +1 @@ -/usr/share/icons/hicolor/32x32/apps/gnunet-fs-gtk.png /usr/share/icons/gnunet-fs-gtk.png /usr/share/man/man1/gnunet-setup.1 /usr/share/man/man1/gnunet-setup-pkexec.1
Bug#1014632: RM: sapphire -- RoQA; FTBFS; dead upstream; unmaintained; very low popcon
Package: ftp.debian.org Severity: normal Hi, sapphire has not seen a new upstream release since 2002 (!), and upstream seems to have stopped working on it long long time ago. Furthermore: - the upstream website is a SourceForce page that only hosts very old releases, and has no source repositories - I cannot find anywhere a potential repository that continues the development - the last maintainer upload was in 2009, and since then it got only one NMU in 2017 - currently FTBFSes due to the very old packaging - it has a very low popcon count (19 at the time I'm writing this) - plenty of alternatives ("minimalist/lightweights" WMs) exist Hence, it looks to me it would be a better idea to simply remove sapphire from Debian. Thanks, -- Pino
Bug#1014502: nmu: labplot_2.9.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, I just started a very small transition affecting cantor & labplot; I checked in advance that it should not affect existing transitions, nor it is affected by any currently ongoing. The new cantor was already uploaded and installed on all the architectures (which are few, as it requires Qt WebEngine). labplot builds fine with the new cantor (I checked this too). Hence, please: nmu labplot_2.9.0-1 . amd64 arm64 armhf i386 mips64el mipsel . unstable . -m "rebuild with cantor 22.04" Thanks, -- Pino
Bug#1013679: nmu: xq_0.0.7-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please rebuild xq on amd64 after it was accepted from NEW; it is a simple tool, so rebuilding it only on amd64 is enough. nmu xq_0.0.7-1 . amd64 . unstable . -m "rebuild on buildd" Thanks, -- Pino
Bug#1012436: synaptic: please remove the unused 'menu' suggest
Package: synaptic Version: 0.90.2 Severity: minor Tags: patch Hi, synaptic currently suggests the 'menu' package. Looking back in the history, it looks like this was due to the usage of su-to-root, used to gain root permissions when launching synaptic from the Debian or XDG/desktop menu. synaptic 0.75.12 switches to policykit for this, dropping the usage of su-to-root. Hence, I believe it is possible to safely drop the 'menu' suggest; patch attached for this. I also dropped the conflict with an extremely old version of 'menu', even older than what's in Debian Jessie. Thanks, -- Pino diff -Nru synaptic-0.90.2/debian/changelog synaptic-0.90.2+nmu1/debian/changelog --- synaptic-0.90.2/debian/changelog2020-11-16 09:56:34.0 +0100 +++ synaptic-0.90.2+nmu1/debian/changelog 2022-06-07 08:10:57.0 +0200 @@ -1,3 +1,11 @@ +synaptic (0.90.2+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Stop suggesting 'menu', as it is not needed/used anymore since 0.75.12. + * Drop conflict with a very old version (at least pre-Jessie) of 'menu'. + + -- Pino Toscano Tue, 07 Jun 2022 08:10:57 +0200 + synaptic (0.90.2) unstable; urgency=medium [ Heimen Stoffels ] diff -Nru synaptic-0.90.2/debian/control synaptic-0.90.2+nmu1/debian/control --- synaptic-0.90.2/debian/control 2020-11-16 09:56:34.0 +0100 +++ synaptic-0.90.2+nmu1/debian/control 2022-06-07 08:10:57.0 +0200 @@ -13,9 +13,8 @@ Package: synaptic Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, policykit-1 -Conflicts: menu (<< 2.1.11) Recommends: libgtk3-perl, xdg-utils -Suggests: dwww, menu, deborphan, apt-xapian-index, tasksel, software-properties-gtk +Suggests: dwww, deborphan, apt-xapian-index, tasksel, software-properties-gtk Description: Graphical package manager Synaptic is a graphical package management tool based on GTK+ and APT. Synaptic enables you to install, upgrade and remove software packages in
Bug#1012435: RM: oroborus -- RoQA; Upstream Dead; Orphaned; FTBFS; Unmaintained
Package: ftp.debian.org Severity: normal Control: block -1 by 1012421 1012433 1012434 Hi, the oroborus source: - had no maintainer upload in the past 11+ years, with a single NMU to fix the build with GCC 10 - it was recently orphaned due to the maintainer retirement - its upstream was the Debian source itself - a very low popcon value (19 at the time of this writing) - plenty of alternatives ("minimalist/lightweights" WMs) exist Hence, it looks to me it would be a better idea to simply remove oroborus from Debian. Thanks, -- Pino
Bug#1012434: RM: keylaunch -- RoQA; Upstream Dead; Orphaned; FTBFS; Unmaintained
Package: ftp.debian.org Severity: normal Hi, the keylaunch source: - had no upload in the past 11+ years - it was recently orphaned due to the maintainer retirement - its upstream was the Debian source itself (part of the oroborus project) - a very low popcon value (21 at the time of this writing) Hence, it looks to me it would be a better idea to simply remove desklaunch from Debian. Thanks, -- Pino
Bug#1012433: RM: desklaunch -- RoQA; Upstream Dead; Orphaned; FTBFS; Unmaintained
Package: ftp.debian.org Severity: normal Hi, the desklaunch source: - had no upload in the past 11+ years - it was recently orphaned due to the maintainer retirement - its upstream was the Debian source itself (part of the oroborus project) - a very low popcon value (26 at the time of this writing) Hence, it looks to me it would be a better idea to simply remove desklaunch from Debian. Thanks, -- Pino
Bug#1010716: llvm-toolchain-14: autopkgtest failure on arm64/armhf
Source: llvm-toolchain-14 Version: 1:14.0.3-1 Severity: important Tags: patch X-Debbugs-Cc: sylves...@debian.org Hi, the qualify-clang.sh script, invoked as one of the autopkgtests, fails to complete successfully on arm64 & armhf for llvm-toolchain-14. The reason for this is because the output of the preprocessing of the "#include " source shrank a lot; when looking at arm64, the difference between the output with llvm-13 and llvm-14 are solely the empty lines: - llvm-13: 165 lines, 71 non-empty lines - llvm-14: 74 lines, 71 non-empty lines - there is no difference in the non-empty lines Compared to e.g. amd64, there are less lines due to the different fenv.h provided by glibc: - FE_TONEAREST, FE_DOWNWARD, FE_UPWARD, and FE_TOWARDZERO are implemented as macros on arm64 (while as single enum on amd64), thus disappearing after the preprocessing - the fenv_t struct has much less fields: 14 on amd64 vs 2 on arm64 - femode_t is a simple typedef on arm64, rather than a struct Similar comparisons can be done on armhf. Hence,I believe a possible way forward is the following: - remove the empty lines when counting the lines in the output of the "#include " preprocessing - reduce the number of required lines from 100 to 60; I don't know why 100 was chosen, as the commit that adds that [1] does not explain it; since the current value of non-empty lines on arm64 is 71, I chose 60 rather than 70 mostly to keep room for a minimal removal [1] https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/4f47c2ac959dd05399da8fd2c40084ee86c25267#b53c2fe1e367d55eb53a487fda5ca85af65594aa_0_32 Attached there is a patch that implements both the changes described above; with that, qualify-clang.sh fully completes successfully on arm64. Thanks, -- Pino --- a/debian/qualify-clang.sh +++ b/debian/qualify-clang.sh @@ -350,9 +350,9 @@ void increment(atomic_size_t *arg) { clang-$VERSION -v -c foo.c &> /dev/null echo "#include " > foo.cc -NBLINES=$(clang++-$VERSION -P -E foo.cc|wc -l) -if test $NBLINES -lt 100; then -echo "Error: more than 100 lines should be returned" +NBLINES=$(clang++-$VERSION -P -E foo.cc|grep .|wc -l) +if test $NBLINES -lt 60; then +echo "Error: more than 60 non-empty lines should be returned" echo "output:" clang++-$VERSION -P -E foo.cc exit 42
Bug#1010419: texstudio: Stop shipping no more needed texstudio.xpm
Package: texstudio Version: 4.2.3+ds-1 Severity: minor Tags: patch Hi, the texstudio packaging manually installs the upstream texstudio.xpm file to /usr/share/pixmaps; considering that - the application icon is already installed in various sizes in the global XDG hicolor icon theme - /usr/share/pixmaps is considered a legacy locations (unthemed, unsized, etc) then it would make sense to not ship /usr/share/pixmaps/texstudio.xpm anymore. Patch attached for this. Thanks, -- Pino --- a/debian/texstudio.install +++ b/debian/texstudio.install @@ -6,6 +6,3 @@ usr/share/icons usr/share/texstudio/CREDITS/usr/share/doc/texstudio usr/share/texstudio/*.badWords usr/share/texstudio/*.stopWords* - -# installing from upstream -utilities/texstudio.xpm/usr/share/pixmaps
Bug#996614: RM: kf5-kdepim-apps-libs -- ROM; dropped source from upstream
Package: ftp.debian.org Severity: normal Hi, please remove the kf5-kdepim-apps-libs source: its functionalities were moved to other KDE PIM sources, and thus upstream dropped this. Thanks, -- Pino
Bug#996610: RM: cantor/experimental -- ROM; NVIU
Package: ftp.debian.org Severity: normal Hi, please remove cantor from experimental: it is a version older than what is available in unstable now, and it was not automatically removed (dunno why). Thanks, -- Pino
Bug#995970: lshw: misses changes from 02.18.85-0.6 & 02.18.85-0.7
Source: lshw Version: 02.19.git.2021.06.19.996aaad9c7-1 Severity: serious Justification: reverts past changes X-Debbugs-Cc: z...@debian.org Hi, the upload of lshw 02.19.git.2021.06.19.996aaad9c7-1 was done starting from 02.18.85-0.5, meaning that neither 02.18.85-0.6 nor 02.18.85-0.7 are acknowledged: - 02.18.85-0.6 contains Debian-only changes that indeed need to be applied - 02.18.85-0.7 contains the backport of a 2 years old upstream commit, which might be already contained in the packaged Git snapshot Please include them both, acknowledging them in changelog. Thanks, -- Pino
Bug#995967: mate-panel: drop the menu-xdg dependency
Package: mate-panel Version: 1.24.1-1 Severity: minor Tags: patch Hi, The Debian menu system was officially deprecated more than 6 years ago; since then, Debian menu entries are being removed, making less and less useful to show the old Debian menu converted to XDG entries. Hence, no more require the old Debian menu system for MATE users: in case any old Debian menu entry is wanted, it can be easily provided as desktop file by the package that contains it. [1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html Thanks, -- Pino >From bf9ea5ff88f3f4db6f670468c5b5a33872a61710 Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Sat, 9 Oct 2021 10:05:18 +0200 Subject: [PATCH] Drop menu-xdg dependency from mate-panel The Debian menu system was officially deprecated more than 6 years ago; since then, Debian menu entries are being removed, making less and less useful to show the old Debian menu converted to XDG entries. Hence, no more require the old Debian menu system for MATE users: in case any old Debian menu entry is wanted, it can be easily provided as desktop file by the package that contains it. [1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html Gbp-Dch: Short --- debian/control | 1 - 1 file changed, 1 deletion(-) diff --git a/debian/control b/debian/control index 593bbe2..d403af7 100644 --- a/debian/control +++ b/debian/control @@ -50,7 +50,6 @@ Depends: libmate-panel-applet-4-1 (= ${binary:Version}), mate-menus, mate-panel-common (= ${source:Version}), mate-polkit, - menu-xdg, ${misc:Depends}, ${shlibs:Depends}, Breaks: mate-panel-common (<< 1.1.1-4), -- 2.33.0
Bug#995887: RM: subtitlecomposer [armel armhf] -- ROM; requires Desktop OpenGL
Package: ftp.debian.org Severity: normal Hi, please remove subtitlecomposer on armel & armhf. The new upstream version, 0.7.1, seems to require Desktop OpenGL, which is problematic to use together with the implicit EGL that Qt on those architectures defaults to. Thanks, -- Pino
Bug#995615: astyle: FTBFS on hurd-i386: unconditional PATH_MAX usage
Source: astyle Version: 3.1-2 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: forwarded -1 https://sourceforge.net/p/astyle/bugs/549/ Control: block -1 by 995612 Hi, currently astyle cannot be built on hurd-i386. The first issue is the unconditional requirement of Java, which is not available/ported on Hurd; this was reported as #995612, as it does not affect only Hurd. The second issue, specific to Hurd, is the unconditional usage of PATH_MAX; I reported the issue upstream with a patch [1]; however, given that the project is basically no more developed further [2], then I'm attaching it here as well, since apparently it will be needed as Debian patch... [1] https://sourceforge.net/p/astyle/bugs/549/ [2] https://sourceforge.net/p/astyle/bugs/548/ Thanks, -- Pino Author: Pino Toscano Description: Use modern realpath() to avoid PATH_MAX Last-Update: 2021-10-03 Forwarded: https://sourceforge.net/p/astyle/bugs/549/ --- a/src/astyle_main.cpp +++ b/src/astyle_main.cpp @@ -1379,13 +1379,12 @@ // Return the full path name or an empty string if failed. string ASConsole::getFullPathName(const string& relativePath) const { - // ignore realPath attribute warning -#pragma GCC diagnostic push -#pragma GCC diagnostic ignored "-Wunused-result" - char fullPath[PATH_MAX]; - realpath(relativePath.c_str(), fullPath); - return fullPath; -#pragma GCC diagnostic pop + char *fullPath = realpath(relativePath.c_str(), nullptr); + if (fullPath == nullptr) + return string(); + const string p(fullPath); + free(fullPath); + return p; } /**
Bug#995612: astyle: do not build the Java bindings on architectures without Java
Source: astyle Version: 3.1-2 Severity: important Tags: patch Hi, astyle currently cannot be built on architectures that do not have Java (so default-jdk is not installable); since the Java bindings are optional, it is possible to build astyle without them on those architectures. Attached there is a patch to do this. Sadly there is no "negative architectures" in the list of architectures of a package, so the drawbacks are: - the hardcoded list of architectures without Java, for the default-jdk build dependency - the hardcoded list of architectures with Java, for the libastylej-jni package Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -1,7 +1,7 @@ Source: astyle Section: devel Priority: optional -Build-Depends: debhelper (>= 11), default-jdk, dh-exec (>= 0.3), cmake +Build-Depends: debhelper (>= 11), default-jdk [!hppa !hurd-i386 !kfreebsd-any], dh-exec (>= 0.3), cmake Maintainer: Matteo Cypriani Uploaders: Margarita Manterola Standards-Version: 4.1.5 @@ -45,7 +45,7 @@ Package: libastylej-jni Section: java -Architecture: any +Architecture: alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32 Multi-Arch: same Depends: ${shlibs:Depends}, ${misc:Depends} Description: Java JNI library for Artistic Style --- a/debian/rules +++ b/debian/rules @@ -7,12 +7,19 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk +include /usr/share/dpkg/architecture.mk # Avoid unneeded library dependencies LDFLAGS += -Wl,--as-needed +ifneq (,$(filter libastylej-jni,$(shell dh_listpackages))) + EXTRA_CONFIGURE_ARGS += -DBUILD_JAVA_LIBS=on +else + EXTRA_CONFIGURE_ARGS += -DBUILD_JAVA_LIBS=off +endif + %: dh $@ override_dh_auto_configure: - dh_auto_configure -- -DBUILD_JAVA_LIBS=on -DBUILD_SHARED_LIBS=on + dh_auto_configure -- -DBUILD_SHARED_LIBS=on $(EXTRA_CONFIGURE_ARGS)
Bug#995575: colmap: FTBFS on hurd-i386: wrong reference to the build directory
Source: colmap Version: 3.6+really3.6-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: found -1 colmap/3.6+really3.6+git20210519-1 Hi, currently colmap fails to build on hurd-i386 [1]. The problem is that, in the colmap.install, the "obj-*-*-*" glob pattern is used to refer to the build directory. The default build directory for cmake is "obj-$DEB_HOST_GNU_TYPE", and considering that DEB_HOST_GNU_TYPE for hurd-i386 is "i686-gnu", then the pattern does not match the build directory. The fix is simple: simply use "obj-*" to refer to the build directory. Patch attached for this. [1] https://buildd.debian.org/status/fetch.php?pkg=colmap&arch=hurd-i386&ver=3.6%2Breally3.6-1&stamp=1632952345&raw=0 Thanks, -- Pino --- a/debian/colmap.install +++ b/debian/colmap.install @@ -1,2 +1,2 @@ -obj-*-*-*/src/exe/colmap usr/bin +obj-*/src/exe/colmap usr/bin doc/COLMAP.desktop usr/share/applications
Bug#995574: googletest: please support GNU/Hurd
Source: googletest Version: 1.11.0-2 Severity: important Tags: upstream patch fixed-upstream User: debian-h...@lists.debian.org Usertags: hurd Control: forwarded -1 https://github.com/google/googletest/pull/3200 Hi, a couple of months ago, thanks to the effort of Mattias Ellert, GoogleTest got support for GNU/Hurd [1], merged as commit 05e9fa23f7 [2]. Can you please backport it to the Debian package? This way, all the sources that use GoogleTest from the system will benefit from it. Attached there is a git format-patch version of the commit, which applies almost cleanly (only with offsets in one file). [1] https://github.com/google/googletest/pull/3200 [2] https://github.com/google/googletest/commit/05e9fa23f74a4766294f858c16e87a1560261340 Thanks, -- Pino >From 05e9fa23f74a4766294f858c16e87a1560261340 Mon Sep 17 00:00:00 2001 From: Mattias Ellert Date: Wed, 30 Dec 2020 13:50:04 +0100 Subject: [PATCH] Port to GNU/Hurd --- googletest/include/gtest/internal/gtest-port-arch.h | 2 ++ googletest/include/gtest/internal/gtest-port.h | 9 ++--- googletest/src/gtest-port.cc| 2 +- googletest/test/googletest-port-test.cc | 2 +- googletest/test/gtest_help_test.py | 3 ++- 5 files changed, 12 insertions(+), 6 deletions(-) diff --git a/googletest/include/gtest/internal/gtest-port-arch.h b/googletest/include/gtest/internal/gtest-port-arch.h index 813bf2c6..a75cd5bb 100644 --- a/googletest/include/gtest/internal/gtest-port-arch.h +++ b/googletest/include/gtest/internal/gtest-port-arch.h @@ -78,6 +78,8 @@ # define GTEST_OS_FREEBSD 1 #elif defined __Fuchsia__ # define GTEST_OS_FUCHSIA 1 +#elif defined(__GNU__) +# define GTEST_OS_GNU_HURD 1 #elif defined(__GLIBC__) && defined(__FreeBSD_kernel__) # define GTEST_OS_GNU_KFREEBSD 1 #elif defined __linux__ diff --git a/googletest/include/gtest/internal/gtest-port.h b/googletest/include/gtest/internal/gtest-port.h index 6b66362f..f62f5876 100644 --- a/googletest/include/gtest/internal/gtest-port.h +++ b/googletest/include/gtest/internal/gtest-port.h @@ -116,6 +116,7 @@ // GTEST_OS_DRAGONFLY - DragonFlyBSD // GTEST_OS_FREEBSD - FreeBSD // GTEST_OS_FUCHSIA - Fuchsia +// GTEST_OS_GNU_HURD - GNU/Hurd // GTEST_OS_GNU_KFREEBSD - GNU/kFreeBSD // GTEST_OS_HAIKU- Haiku // GTEST_OS_HPUX - HP-UX @@ -543,7 +544,7 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION; (GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_HPUX || GTEST_OS_QNX || \ GTEST_OS_FREEBSD || GTEST_OS_NACL || GTEST_OS_NETBSD || GTEST_OS_FUCHSIA || \ GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_OPENBSD || \ - GTEST_OS_HAIKU) + GTEST_OS_HAIKU || GTEST_OS_GNU_HURD) #endif // GTEST_HAS_PTHREAD #if GTEST_HAS_PTHREAD @@ -603,7 +604,8 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION; (GTEST_OS_WINDOWS_DESKTOP && _MSC_VER) || GTEST_OS_WINDOWS_MINGW || \ GTEST_OS_AIX || GTEST_OS_HPUX || GTEST_OS_OPENBSD || GTEST_OS_QNX || \ GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_FUCHSIA || \ - GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_HAIKU) + GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_HAIKU || \ + GTEST_OS_GNU_HURD) # define GTEST_HAS_DEATH_TEST 1 #endif @@ -623,7 +625,8 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION; // Determines whether test results can be streamed to a socket. #if GTEST_OS_LINUX || GTEST_OS_GNU_KFREEBSD || GTEST_OS_DRAGONFLY || \ -GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_OPENBSD +GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_OPENBSD || \ +GTEST_OS_GNU_HURD # define GTEST_CAN_STREAM_RESULTS_ 1 #endif diff --git a/googletest/src/gtest-port.cc b/googletest/src/gtest-port.cc index 3f39f71c..989c59ae 100644 --- a/googletest/src/gtest-port.cc +++ b/googletest/src/gtest-port.cc @@ -98,7 +98,7 @@ const int kStdOutFileno = STDOUT_FILENO; const int kStdErrFileno = STDERR_FILENO; #endif // _MSC_VER -#if GTEST_OS_LINUX +#if GTEST_OS_LINUX || GTEST_OS_GNU_HURD namespace { template diff --git a/googletest/test/googletest-port-test.cc b/googletest/test/googletest-port-test.cc index 4a87df0b..e3ad4dde 100644 --- a/googletest/test/googletest-port-test.cc +++ b/googletest/test/googletest-port-test.cc @@ -280,7 +280,7 @@ TEST(FormatCompilerIndependentFileLocationTest, FormatsUknownFileAndLine) { #if GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_QNX || GTEST_OS_FUCHSIA || \ GTEST_OS_DRAGONFLY || GTEST_OS_FREEBSD || GTEST_OS_GNU_KFREEBSD || \ -GTEST_OS_NETBSD || GTEST_OS_OPENBSD +GTEST_OS_NETBSD || GTEST_OS_OPENBSD || GTEST_OS_GNU_HURD void* ThreadFunc(void* data) { internal::Mutex* mutex = static_cast(data); mutex->Lock(); diff --git a/googletest/test/gtest_help_test.py b/googletest/test/gtest_help_test.py index 8d953bbd..54d45047 100755 --- a/googletest/test/gtest_help_test.py +++ b/googletest/test/gte
Bug#992759: nmu: tagua_1.0~alpha2-16-g618c6a0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild tagua in unstable against the libkdegames recently uploaded. tagua builds fine with the newer libkdegames. nmu tagua_1.0~alpha2-16-g618c6a0-3 . ANY . unstable . -m "rebuild for libkdegames 21.08.0 (libkf5kdegamesprivate7)" Thanks, -- Pino
Bug#992758: nmu: calamares_3.2.36-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild calamares in unstable against the newer kpmcore recently uploaded. calamares builds fine with the newer kpmcore. nmu calamares_3.2.36-1 . ANY . unstable . -m "rebuild against kpmcore 21.08.0 (libkpmcore11)" Thanks, -- Pino
Bug#992757: nmu: qtwebview-opensource-src_5.15.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild qtwebview-opensource-src in unstable for the new qtwebengine 5.15.5 recently uploaded, so it depends on the new internal ABI dependency. qtwebview builds fine with the newer qtwebengine. nmu qtwebview-opensource-src_5.15.2-2 . ANY . unstable . -m "rebuild with qtwebengine-opensource-src 5.15.5 (qtwebengine-abi-5-15-5)" Thanks, -- Pino
Bug#992697: RM: cantor [armel ppc64el s390x] -- ROM; requires QtWebEngine
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, the new version of src:cantor requires QtWebEngine for the main interface: as result, it is built only on few architectures. Hence, please remove cantor on the following architectures: armel ppc64el s390x Thanks, -- Pino
Bug#981515: kcoreaddons: please replace fam with gamin
block 981515 by 510368 thanks Hi, In data venerdì 20 agosto 2021 13:32:08 CEST, Chris Hofstaedtler ha scritto: > given we are now in the bookworm cycle - do you think kcoreaddons > could remove fam (or replace it with gamin if really needed)? As I wrote a couple of times in this bug already: #510368 must be fixed first. It seems like I forgot to set this dependency, so I'm adding it now. Also, considering that there is a huge queue of RM bugs on the FTP-masters side that have been attended so far a couple of times in this year (sigh), rushing this won't make any change, since the RM will be ignored for some time anyway. Also #2: considering that we are not even a week since the lift of the freeze and everybody and their dogs have already uploaded things of every sort of unstable, please give (me) some time for what is really not a priority. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#989007: usermode: please drop the custom XPM pixmaps
Package: usermode Version: 1.114-1 Severity: wishlist Tags: patch Hi, the Debian packaging converts 3 PNG icons to XPM pixmaps; they were used in the past by the Debian menu files, which were removed with version 1.109-1. Hence, there is no more need to convert them, dropping also the netpbm build dependency. Attached patch for this. Thanks, -- Pino >From 269b6b62379239e816e8a1fc2f0cc7e0f796f6d1 Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Sun, 23 May 2021 10:56:45 +0200 Subject: [PATCH] stop generating custom XPM pixmaps, as were only used with old Debian menu files (dropped in 1.109-1); drop netpbm B-D, no more needed --- debian/clean| 3 --- debian/control | 1 - debian/rules| 7 +-- debian/usermode.install | 1 - 4 files changed, 1 insertion(+), 11 deletions(-) delete mode 100644 debian/clean delete mode 100644 debian/usermode.install diff --git a/debian/clean b/debian/clean deleted file mode 100644 index 25ccdef..000 --- a/debian/clean +++ /dev/null @@ -1,3 +0,0 @@ -debian/disks.xpm -debian/password.xpm -debian/user_icon.xpm diff --git a/debian/control b/debian/control index ed9e78e..c9ecc0f 100644 --- a/debian/control +++ b/debian/control @@ -14,7 +14,6 @@ Build-Depends: libsm-dev, libuser1-dev, libxml-parser-perl, - netpbm, Rules-Requires-Root: no Standards-Version: 4.4.1 Homepage: https://pagure.io/usermode/ diff --git a/debian/rules b/debian/rules index d25cdb0..f8591a9 100755 --- a/debian/rules +++ b/debian/rules @@ -25,7 +25,7 @@ override_dh_auto_configure: MKFS=/sbin/mkfs \ FDFORMAT=/usr/bin/fdformat -override_dh_install: user_icon.xpm password.xpm disks.xpm +override_dh_install: dh_install # this functionality doesn't appear to be supported in Debian rm $(DEBDIR)/usr/bin/pam-panel-icon $(DEBDIR)/usr/share/pixmaps/badge-small.png @@ -40,10 +40,5 @@ override_dh_fixperms: dh_fixperms chmod 04755 $(DEBDIR)/usr/sbin/userhelper -%.xpm : %.png - pngtopnm -alpha $< | pnmscale -xysize 32 32 > debian/alpha.pnm - pngtopnm $< | pnmscale -xysize 32 32 | ppmtoxpm -alphamask=debian/alpha.pnm > debian/$@ - rm debian/alpha.pnm - override_dh_missing: dh_missing --fail-missing diff --git a/debian/usermode.install b/debian/usermode.install deleted file mode 100644 index e95a7b7..000 --- a/debian/usermode.install +++ /dev/null @@ -1 +0,0 @@ -debian/user_icon.xpm debian/password.xpm debian/disks.xpm usr/share/pixmaps -- 2.30.2
Bug#989005: RM: aewm -- RoQA; dead upstream; unmaintained; very low popcon
Package: ftp.debian.org Severity: normal Hi, aewm has not seen a new upstream release since 2007, and upstream seems to have stopped working on it long long time ago. Furthermore: - the upstream website is not available anymore - I cannot find anywhere a potential repository that continues the development - it has been "maintained" in Debian with NMUs/QA uploads since 2011 - uses old tech/libs (GTK+ 2) - it has a very low popcon count (38 at the time I'm writing this) - plenty of alternatives ("minimalist/lightweights" WMs) exist Hence, it looks to me it would be a better idea to simply remove aewm from Debian. Thanks, -- Pino
Bug#988544: RM: bbmail -- RoQA; dead upstream; unmaintained; very low popcon
Package: ftp.debian.org Severity: normal Hi, bbmail has not seen a new upstream release since 2007, and upstream seems to have stopped working on bbtools long long time ago. Furthermore, bbmail was orphaned 5 years ago (see #832561), and at the time of this writing has a popcon count of 14. Hence, it looks to me it would be a better idea to simply remove bbmail from Debian, as I'm sure alternatives to this exist and are more maintained. Please also close #832561 when RM'ing bbmail. Thanks, -- Pino
Bug#988541: RM: keytouch-editor -- RoQA; dead upstream; useful only for dead software
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: lcy...@gmail.com Hi, keytouch-editor is an editor for creating files for keytouch [1]. keytouch was removed from Debian 10 years ago (!) (see #632110 [2]) because it was broken, and not receiving any maintainer attention anymore. keytouch-editor thus is somehow of not much of use in Debian; furthermore, it has not been developed upstream for a decade as well, and it has not been maintained in Debian either. Hence, I think it is a better idea to remove also keytouch-editor from Debian. [1] https://tracker.debian.org/pkg/keytouch [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632110 Thanks, -- Pino
Bug#988272: xsane: improve the installation of files in binary packages
Source: xsane Version: 0.999-11 Severity: minor Tags: patch Hi, currently, the Debian build scripts (rules & debhelper files) ship only some of the files installed by upstream, and copy manually a couple more; this results in lack of files producing issues like #963185. To improve the situation, IMHO the best approach is to ship everything that upstream installs, and at most do few tweaks like the location of the documentation, or avoid a full GPL copy. The attached patch does this job; copying from the changelog: * Improve the general installation, also to properly install all the files provided by upstream and avoid issues like #963185: - ship the complete /usr/share/sane/xsane directory in xsane-common, rather than copying one specific file in xsane: this way nothing is missed - replace the xsane-gpl.txt file with a symlink to the GPL 2 file in /usr/share/common-licenses; xsane shows it in an about dialog - add a lintian override for /usr/share/sane/xsane/xsane-eula.txt, as xsane shows it in the about eula dialog - keep relocating the documentation from /usr/share/sane/xsane/doc to /usr/share/doc/xsane-common/html with symlinks for xsane - move/install the application icons, and the custom OCR scripts from xsane to xsane-common, as they are shared data - stop manually installing xsane.xpm, and xsane.png, as the XPM icon is already installed by upstream - add proper breaks/replaces in xsane-common because of the files moved from xsane - drop debian/not-installed, as everything from upstream is installed now - drop debian/xsane-common.docs, as there are no separate documentation files to copy manually - drop debian/xsane.dirs, as dh_install creates all the missing directories As result of shipping exactly what upstream installs, there is also a reduction in the installed sizes of the xsane, and xsane-common binaries: - xsane (on amd64): before is 2346 kb, after is 1630 kb - xsane-common: before is 5522 kb, after is 4498 kb Thanks, -- Pino diff -Nru xsane-0.999/debian/changelog xsane-0.999/debian/changelog --- xsane-0.999/debian/changelog2021-05-04 14:31:47.0 +0200 +++ xsane-0.999/debian/changelog2021-05-09 08:16:22.0 +0200 @@ -1,3 +1,29 @@ +xsane (0.999-12) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Improve the general installation, also to properly install all the files +provided by upstream and avoid issues like #963185: +- ship the complete /usr/share/sane/xsane directory in xsane-common, rather + than copying one specific file in xsane: this way nothing is missed +- replace the xsane-gpl.txt file with a symlink to the GPL 2 file in + /usr/share/common-licenses; xsane shows it in an about dialog +- add a lintian override for /usr/share/sane/xsane/xsane-eula.txt, as xsane + shows it in the about eula dialog +- keep relocating the documentation from /usr/share/sane/xsane/doc to + /usr/share/doc/xsane-common/html with symlinks for xsane +- move/install the application icons, and the custom OCR scripts from xsane + to xsane-common, as they are shared data +- stop manually installing xsane.xpm, and xsane.png, as the XPM icon is + already installed by upstream +- add proper breaks/replaces in xsane-common because of the files moved + from xsane +- drop debian/not-installed, as everything from upstream is installed now +- drop debian/xsane-common.docs, as there are no separate documentation + files to copy manually +- drop debian/xsane.dirs, as dh_install creates all the missing directories + + -- Jörg Frings-Fürst Sun, 09 May 2021 08:16:22 +0200 + xsane (0.999-11) experimental; urgency=medium * Fix FTBFS on hppa (Closes: #987841). diff -Nru xsane-0.999/debian/control xsane-0.999/debian/control --- xsane-0.999/debian/control 2021-05-02 19:13:09.0 +0200 +++ xsane-0.999/debian/control 2021-05-09 08:16:22.0 +0200 @@ -59,6 +59,10 @@ Multi-Arch: foreign Depends: ${misc:Depends} Recommends: xsane +Breaks: + xsane (<< 0.999-11~), +Replaces: + xsane (<< 0.999-11~), Description: xsane architecture independent files xsane can be run as a stand-alone program or through the GIMP image manipulation program. In stand-alone mode, xsane can save an image diff -Nru xsane-0.999/debian/not-installed xsane-0.999/debian/not-installed --- xsane-0.999/debian/not-installed2020-08-24 21:25:26.0 +0200 +++ xsane-0.999/debian/not-installed1970-01-01 01:00:00.0 +0100 @@ -1,155 +0,0 @@ -usr/share/pixmaps/xsane.xpm -usr/share/applications/xsane.desktop -usr/share/sane/xsane/xsane-logo.xpm -usr/share/sane/xsane/sane-xsane-logo.xpm -usr/share/sane/xsane/sane-umax-logo.xpm -usr/share/sane/xsane/sane-hp-logo.xpm -usr/share/sane/xsane/sane-epson-logo.xpm -usr/share/sane/xsane/UMAX-logo.xpm -usr/share/sane/xsane/Plustek-logo.xpm -usr/share/s
Bug#987873: RM: gadmintools-meta -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Control: block -1 by 987867 987868 987869 987870 987871 987872 Hi, please remove gadmintools-meta from Debian. It provides a metapackage to install the GAdmintools, which are requested to be removed from Debian as long dead upstream and unmaintained (and broken); see the following bugs: #987867, #987868, #987869, #987870, #987871, #987872 Thanks, -- Pino
Bug#987872: RM: gadmin-samba -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-samba from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987871: RM: gadmin-rsync -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-rsync from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987870: RM: gadmin-proftpd -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-proftpd from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. In addition, it appears to have been unusable in Debian for some years already, see #612037. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987869: RM: gadmin-openvpn-server -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-openvpn-server from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. In addition, it appears to have been unusable in Debian for some years already, see #768663 and #602870. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987868: RM: gadmin-openvpn-client -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-openvpn-client from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987867: RM: gadmin-bind -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-bind from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987864: RM: trovacap -- RoQA; long dead upstream; partially obsolete data
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: da...@debian.org Hi, trovacap is an application that ships an offline list of all the Italian CAPs (that is, the Italian ZIP codes). The first problem is that upstream is long gone: the last release was done more than 10 years ago, and since then even the upstream web site vanished (apparently with no public code hosting nowhere else like github/gitlab/etc). The second, IMHO bigger issue, is that the list of known CAPs is shipped statically in the sources, and it was not kept up-to-date. Yes, there were changes in the CAPs in Italy in the last decade, at least 300 from from a quick search; while they don't seem too many compared to the list of municipalities, IMHO providing a wrong data to the user (especially for something important like sending mail) is not a good idea. Hence, I rather prefer to remove trovacap altogether than shipping an unmaintained and partially outdated application. CCing the maintainer for his opinion. Thanks, -- Pino
Bug#987078: usbview: Remove duplicated files from upstream, and files no more needed
Source: usbview Version: 2.0-21-g6fe2f4f-2 Severity: wishlist Tags: patch Hi, the current debian directory ships some file that shadows files provided by upstream (e.g. the desktop file and the icons), and ships some files that are not needed. Hence, the provided patch simplify things a bit: - drop our own icons, as upstream now installs all the XDG icon themes icons properly (PNG and SVG) - drop the old Debian menu file, as a desktop file is provided, so by Policy the menu file ought to not be shipped; furthermore, the old menu system has been deprecated for 6 years - use su-to-root in the desktop file as a patch rather than using a copy of it: this reduces the maintenance cost, and it clearly separates the changes applied to it - use a debian/upstream/metadata file to reference the upstream Git repository, according to DEP 12 (replacing the X- field) The debdiff between a rebuild of 2.0-21-g6fe2f4f-2 and the provided 2.0-21-g6fe2f4f-3 is the following: Files in first .deb but not in second - -rw-r--r-- root/root /usr/share/icons/hicolor/32x32/apps/usbview.xpm -rw-r--r-- root/root /usr/share/menu/usbview -rwxr-xr-x root/root DEBIAN/postinst -rwxr-xr-x root/root DEBIAN/postrm Control files: lines which differ (wdiff format) Installed-Size: [-1201-] {+1191+} Version: [-2.0-21-g6fe2f4f-2-] {+2.0-21-g6fe2f4f-3+} Which is expected, as the XPM icon and the old Debian menu are to not be shipped anymore. Of course, I'm available to edit any part of it -- I personally see these changes as improvement and cleanups. Thanks, -- Pino diff -Nru usbview-2.0-21-g6fe2f4f/debian/changelog usbview-2.0-21-g6fe2f4f/debian/changelog --- usbview-2.0-21-g6fe2f4f/debian/changelog2018-06-04 11:52:41.0 +0200 +++ usbview-2.0-21-g6fe2f4f/debian/changelog2021-04-17 10:41:34.0 +0200 @@ -1,3 +1,19 @@ +usbview (2.0-21-g6fe2f4f-3) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Drop debian/usbview.manpages, as upstream already installs the man page. + * Drop menu file, as usbview already provides a .desktop file. + * Drop our own copy of usbview.svg, as it is provided by upstream already. + * Stop manually convering icons, as upstream already installs all the needed +hicolor icons. + * Make the usage of su-to-root for the desktop file as patch to the desktop +file provided by upstream, rather than as fork of that file; this way, +there is no need to maintain it. + * Create a debian/upstream/metadata with references to the upstream Git +repository, removing the X-Vcs-Upstream-Git field from debian/control. + + -- Mark Brown Sat, 17 Apr 2021 10:41:34 +0200 + usbview (2.0-21-g6fe2f4f-2) unstable; urgency=low * Add build dependency on librsvg2-bin since the imagemagick diff -Nru usbview-2.0-21-g6fe2f4f/debian/clean usbview-2.0-21-g6fe2f4f/debian/clean --- usbview-2.0-21-g6fe2f4f/debian/clean2017-02-04 12:24:38.0 +0100 +++ usbview-2.0-21-g6fe2f4f/debian/clean1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -debian/icons/*/* diff -Nru usbview-2.0-21-g6fe2f4f/debian/control usbview-2.0-21-g6fe2f4f/debian/control --- usbview-2.0-21-g6fe2f4f/debian/control 2018-06-04 11:52:41.0 +0200 +++ usbview-2.0-21-g6fe2f4f/debian/control 2021-04-17 10:41:34.0 +0200 @@ -6,7 +6,6 @@ Homepage: http://www.kroah.com/linux-usb/ Build-Depends: debhelper (>= 9), dh-autoreconf, autoconf-archive, imagemagick, libmagickcore-6.q16-2-extra, libgtk-3-dev, librsvg2-bin -X-Vcs-Upstream-Git: git://github.com/gregkh/usbview.git Package: usbview Architecture: any diff -Nru usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff --- usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff 1970-01-01 01:00:00.0 +0100 +++ usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff 2021-04-17 10:41:34.0 +0200 @@ -0,0 +1,15 @@ +Author: Mark Brown +Description: Make desktop entry use su-wrapper. +Last-Update: 2015-04-25 + +--- a/usbview.desktop b/usbview.desktop +@@ -2,7 +2,7 @@ + Name=USBView + GenericName=USB Device Viewer + Comment=View USB devices attached to system +-Exec=pkexec /usr/bin/usbview ++Exec=su-to-root -X -c /usr/bin/usbview + Icon=usbview + Terminal=false + Type=Application diff -Nru usbview-2.0-21-g6fe2f4f/debian/patches/series usbview-2.0-21-g6fe2f4f/debian/patches/series --- usbview-2.0-21-g6fe2f4f/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ usbview-2.0-21-g6fe2f4f/debian/patches/series 2021-04-17 10:41:34.0 +0200 @@ -0,0 +1 @@ +desktop-use-su-to-exec.diff diff -Nru usbview-2.0-21-g6fe2f4f/debian/rules usbview-2.0-21-g6fe2f4f/debian/rules --- usbview-2.0-21-g6fe2f4f/debian/rules2017-02-04 12:24:38.0 +0100 +++ usbview-2.0-21-g6fe2f4
Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Hi Dennis, In data venerdì 26 febbraio 2021 22:48:43 CET, Dennis Filder ha scritto: > If you decide to use the attached patch, please put the bugnumber in > the Bug-Debian: field for me. The patch you provided is the following: --- qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp 2021-02-26 18:48:50.407487828 +0100 +++ qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp 2021-02-26 18:48:52.711491373 +0100 @@ -8335,8 +8335,8 @@ QQuickItemLayer::~QQuickItemLayer() { -delete m_effectSource; -delete m_effect; +if (m_effectSource) delete m_effectSource; // FIXME: consider Q_ASSERT() here instead +if (m_effect) delete m_effect; // FIXME: consider Q_ASSERT() here instead } /*! Did you actually check that it fixes the problem for you? The thing is, in C++ (at least since C++98) the delete operator is defined to be a no-op for a null pointer, much like free() in C. Hence, constructs like "if (foo) delete foo;" are essentially doing null pointer checks twice, and with the same no-op result. A possible cause of the crash could be that the item being deleted was already deleted, and thus there was a stale pointer somewhere. That is my own speculation though. Because of this, I'm inclined to remove the "patch" tag from this bug; I'd like to hear from Dmitry what he thinks about it (since he already handled this bug). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
In data venerdì 5 marzo 2021 18:16:18 CET, Glenn Strauss ha scritto: > On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote: > > > Personally, I'd argue that switching the FAM implementation across the > > distribution _is_ a "transition", and as such it ought to have been > > requested (if not even started) two months ago. > > In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor > > I posted in October 2020 on that bug where FAM was abandoned. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 > Debian developers did not suggest "next steps" for over 3 months, > until the freeze occurred. > > The bug was not touched by a Debian Developer until 31 Jan 2021. This message was addressed only to bugs, one of them was assigned to "wnpp" and the other to libgamon0: this means that only the gamin maintainer (1 specific person, as there is no group maintenance) and who watches the bugs of wnpp and src:gamin actually read it. Becuase of this, its audience was limited, and neither the general list for Debian development (debian-devel) nor the release team (release-team) were notified/aware of it by default. I can understand your frustation, but that is not a reason to rush things just because of this. All the deadline for Debian releases have been more or less streamlined/standardized for at least the past 2 stable releases already, so every step is well known in advance. Because of this, for example, we were not able to provide Plasma 5.12 in Bullseye. > The solution is to remove FAM. And nobody, really, *nobody* ever said the opposite, so please stop repeating that it is not wanted. > Back on topic: > > If you take a moment to look in the kcoreaddons code, you can see that > kcoreaddons has multiple mechanisms for filesystem notification. > If FAM interfaces fail for any reason, kcoreaddons switches to an > alternative mechanism. > > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611 > > Therefore, your FUD is unsubstantiated. Changing kcoreaddons to use > gamin, or to not use FAM or gamin, are both reasonable options. > As I posted in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49 > gamin can be configured to poll NFS locations and so is a reasonable > substitution for FAM, not limited to inotify() as Sune suggested in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39 Sure, I well know that KDirWatch in kcoreaddons builds fine with either libfam or gamin as "FAM", I remember people doing this many years ago in other distributions. However, what I said is something completely different, let me summarize it in short points for easier understanding: - I am fine switching from libfam to gamin in the future - I am fine dropping libfam from Debian in the future - I want first libgamin to stop providing libfam - switching from libfam from gamin *is* switching FAM implementation, and thus which code is used for "FAM", and possibily different bugs; hence, this is *too late* to properly test is in Bullseye There is no FUD in what I said. > It is true that this relatively safe change is being requested during > the soft freeze and so should be scrutinized. However, that does not > make the requested change any more or less dangerous. It does mean > less time to test by people who, in your own words, might not be using > this feature: > > and these FAM/gamin bits do not get much of use these days So if, "less time to test by people who [...] might not be using this feature", this switch is even more dangerous. Thanks from proving my point. > I posit that the code in upstream kcoreaddons is already better tested > than would be Debian "testing" (existence in tree?) of an additional > month or two or three of the Debian kcoreaddons package configured to > use gamin (or to use neither FAM nor gamin). This "additional month or two or three" we are talking about is called "Debian freeze". Dependency changes like this are very much *not* the kind of changes we want to introduce during a freeze. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
Dear Glenn, In data venerdì 5 marzo 2021 16:41:40 CET, Glenn Strauss ha scritto: > In #981513, courier changed to use libgamin-dev, so > kcoreaddons is now the *only* remaining package using FAM. > > As such, there is considerably more risk to doing nothing > than there is to migrating to gamin. No, there is more risk in switching to a different library at this phase of the Debian freeze. > ==> Please change kcoreaddons to use libgamin-dev for Bullseye. > https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 While I understand your motivation behind this change, I'll repeat once again what I said previously in this bug: this is *not* going to happen for Bullseye, full stop. The reason is that we are talking about switching to a different library for a functionality that is rarely used these days (but potentially can be), hence a switch at this phase is very risky, and gives basically no time to test or even get feedback about it. The freeze for transitions started almost two months ago, on January 13th: https://lists.debian.org/debian-devel-announce/2021/01/msg2.html Personally, I'd argue that switching the FAM implementation across the distribution _is_ a "transition", and as such it ought to have been requested (if not even started) two months ago. On February 13th, a "mild freeze" started: https://lists.debian.org/debian-devel-announce/2021/02/msg2.html while changes at the beginning of it still migrated to testing, IMHO the switch of a dependency raises the bar of the risk; while I can check it for things I upload and work for, this feature represents something corner-case, which I don't have neither the setup nor the time to properly test. This request was opened at the end of January (so in transition freeze already, and IMHO enough to make it out of scope for Bullseye), and my question about the timing for this got "not for Bullseye" as answer. All the more traffic for you, Glenn, started two days ago, already in a time frame where uploads to unstable will not migrate to testing anymore [1], and thus it will need exception from release-team, meaning it has to be something importat/serious enough (and this is not, as the status of it would be the same as in previous Debian releases). [1] automatic migration ends on March 13th, and the default migration time is 10 days, which means the last day for such uploads was March 2nd Moreover, I already stated that I really want #510368 fixed _before_ switching the dependency, and that bug has not been fixed yet (and unlikely to be for Bullseye). So, thanks again for the time and interest in this, but this will be handled only after both a) Bullseye is released b) #510368 is fixed. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983680: RM: kcm-ufw/experimental -- RoQA; dead upstream; depends on removed KDE 4 libraries
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: sh...@sorbom.com Hi, please remove kcm-ufw from Debian (currently only in experimental). The last release upstream was more than 7 years ago, and it has seen basically no development since then. Furthermore, it was based on the KDE libraries 4.x, which were removed from Debian, so this source cannot be build anymore. Thanks, -- Pino
Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon
In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto: > I had checked the upstream repository before reporting this issue > (that's where I got the filename), it still contains this version of the > icon. Reporting here, because I couldn't find an issue tracker on KDE > GitLab. https://bugs.kde.org is the KDE upstream bug tracking system. Please report it there, rather than on a downstream bug tracking system. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon
Hi Bohdan, In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto: > Package: kdeconnect > Version: 20.04.3-1 > Severity: wishlist > > Dear Maintainer, > > the current icon looks very similar to a broken image icon. I thought it > was broken for several months, until I squinted and found out that × is > actually K. Though when I glance over it, I still subconciously percieve > it as a broken image icon. Please redesign it to something more contrast > and distinct; the light version of the icon does not have this issue. Please note that we do not do upstream development, and this kind of change (i.e. artwork) ought to be done by upstream, either in kdeconnect itself or in the breeze icon theme. Please note also: > Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, > TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), > LANGUAGE=ru_UA:ru > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages kdeconnect depends on: > ii kde-cli-tools 4:5.17.5-2 > ii kio 5.70.1-1 > ii libc6 2.31-3 > ii libfakekey0 0.3+git20170516-2 > ii libkf5configcore5 5.70.0-1 kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04: your system is ~6 month behind of the current Debian testing. Please fully dist-update your system when reporting bugs for unstable or testing, as otherwise there is the risk of reporting stale issues. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Hi Simon, In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto: > Control: retitle 969907 epdfinfo crashing with mismatched libpoppler102 and > libpoppler-glib8 > Control: tags 969907 + patch > > Sorry, this reply should have gone to the clone in libpoppler-glib8, > not to the archived original bug in epdfinfo (which I don't think was > ever really an epdfinfo bug). > > On Mon, 15 Feb 2021 at 12:03:35 +, Simon McVittie wrote: > > I don't think this is actually about whether libpoppler-glib added new ABI > > without bumping the shlibs version - it has a .symbols file that tracks > > the version in which each public symbol was added. > > > > Instead, I think this is about private symbols and partial > > upgrades. libpoppler102 and libpoppler-glib8 come from the same > > source package, so libpoppler-glib8 is very likely to make assumptions > > about private implementation details of the corresponding version of > > libpoppler102; many of the source files glib/*.cc that get compiled into > > libpoppler-glib8 have #include "poppler-private.h". This is fine if > > everyone does an `apt upgrade` with no pinning, but breaks down if people > > do arbitrary partial upgrades with pinning or interactively (leading to a > > "Frankendebian" system). > > > > If the upstream developers of poppler are asked to support a system where > > libpoppler102 and libpoppler-glib8 are at different versions, I'm pretty > > sure the first thing they will say is "don't". I think the same is > > appropriate for downstreams. Yes, this is correct. > > In Cairo and Pango (which have a similar structure with multiple binary > > packages making use of each other's implementation details), I added a > > debian/shlibs.local to make sure the binary packages all get lockstep > > dependencies. I think the same technique would be appropriate here. See > > attached. I honestly do not understand how this is even a problem, considering I fixed this more than 5 years ago: https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110 and indeed: $ apt-cache show libpoppler-glib8 Package: libpoppler-glib8 Source: poppler Version: 20.09.0-3.1 [...] Depends: libpoppler102 (= 20.09.0-3.1), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2) [...] So the strict dependency is already in place. If I check the version that was reported in the bug report, I see: $ debsnap -d . libpoppler-glib8 -a amd64 0.85.0-2 $ dpkg -I libpoppler-glib8_0.85.0-2_amd64.deb Package: libpoppler-glib8 Source: poppler Version: 0.85.0-2 Depends: libpoppler95 (= 0.85.0-2), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2) I'd rather think that the situation happened because elpa-pdf-tools-server links both to libpoppler and libpoppler-glib: the rebuild against poppler 20.09.0 (i.e. libpoppler102) make elpa-pdf-tools-server link to libpoppler102 (forcing the newer dependency to it), and setting an old dependency for libpoppler-glib because there is no need for a newer version. This was also a problem in case there was an incomplete dist-upgrade to the newer poppler, so the newer libpoppler was pulled in but the newer libpoppler-glib not. I remember having seen this in the past (when I used to maintain poppler), but it happened once and indeed it was due to an incomplete dist-upgrade. IMHO this will not happen in oldstable->stable dist-upgrades, as everything will be build with the newer libraries, and hopefully the dist-upgrade will be done fully. Another contributing factor is that emacs-pdf-tools "abuses" the libpoppler-glib internals, see server/poppler-hack.cc. I don't know why it does that, and I'd rather see the actual issues fixed in libpoppler-glib. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981679: Closing as per reporter request
reopen 981679 thanks Hi, In data giovedì 11 febbraio 2021 10:18:14 CET, Aurélien COUDERC ha scritto: > control: fixed -1 4:5.6.2-4 > > Thanks for the follow up. > Closing as per your request. > > What I read from upstream git log is that the commit you mention is on master > and the fix was actually backported to the 5.6 branch as > 4688d626c145711e35f3676dbd4c827b3b2ea7f6. The upload of kdevelop 4:5.6.2-4 fixes what Justin reported, i.e. that the clang plugin cannot parse the clang version string in more recent Debian clang versions. The original problem, though, is totally different: the clang plugin hardcodes the clang include directory and the clang version and, while it appears to have some logic to handle runtime version bumps, it seems it cannot fully cope with this situation. It looks like there is no more issue simply because the upload of kdevelop 5.6.2 (starting with 4:5.6.2-1) rebuilds with the latest clang, so it makes the problem "go away" until the next time the default clang version (currently 11) is updated in Debian. Because of this, the actual problem reported in this bug report *is* still valid, and I hope upstream can do something about it so we (in Debian) don't get breakages on clang version bumps. Luckly, I did changes in the packaging so it is possible to binNMU (i.e. a plain no-changes rebuild) kdevelop in such situations, and the rebuilt kdevelop will not migrate to testing until the newer clang version migrated too; it is mostly a workaround though. Julien: while I thank you for spotting the issue with the parsing of clang version string, I strongly recommend you to report *new* bugs for problems different that what reported. It is always easier to merge bugs in case they are actually the same issue, while adding different and unrelated issues to a bug makes it really hard to properly track what is fixed and what is not. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
In data lunedì 1 febbraio 2021 00:00:47 CET, Chris Hofstaedtler ha scritto: > Source: kcoreaddons > Version: 5.54.0-1 > > Dear Maintainer, > > your package currently Depends on libfam0 (fam), which has > been requested to be removed in #966273. Please switch to gamin > instead. You can find more info, and an analysis of what probably > needs to be done for your package in this message from Glenn Strauss: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 I wouldn't say that gamin is more maintained than FAM: - on the upstream side (gnome.org), it was moved the "Archive" section of the gnome gitlab - during the migration to gitlab, all the bugzilla tickets were closed instead of migrated too, because the project is archived - on the Debian side, gamin saw 4 uploads (one of them is an NMU) in the last 10 years - #510368 prevents to switch from FAM to gamin, as it will build against libgamin but still pulling libfam (or keep an old libfam as valid package satisfying the dependency) > Severity of this bug will probably raise over time. What is "over time" implying, please? I really hope this is not for bullseye: we are so close to its freeze, and these FAM/gamin bits do not get much of use these days, so the risk of release regressions seems medium/high to me. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#980879: RM: libqinfinity/experimental -- ROM; dead upstream, unused
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-kde-ext...@lists.alioth.debian.org Hi, please remove libqinfinity from experimental (the only suite where it is now). The last release upstream was 0.5.2, released more than 7 years ago, and the project is archived upstream (on kde.org). There were and still are no users of it. Thanks, -- Pino
Bug#966036: kajongg: Uses old name of sip module
Hi Dmitry, apparently I missed this sip-related bug. In data mercoledì 22 luglio 2020 13:31:19 CET, Dmitry Shachnev ha scritto: > Source: kajongg > Version: 4:19.12.3-1 > Usertags: sip5 > > Dear Maintainer, > > You are receiving this bug because your package seems to be using PyQt5 > and has Python files with "import sip" lines. > > With the latest version of PyQt5 in experimental, the private sip module > used by PyQt5 is called "PyQt5.sip", not just "sip". I am going to upload > this version to unstable around end of August. > > You may need to update your imports to do something like this: > > try: > from PyQt5 import sip > except ModuleNotFoundError: > import sip > > Alternatively, you may import sip after importing PyQt5. So the following > will work too: > > from PyQt5 import QtCore > import sip > > Please see the following link for details: > > https://www.riverbankcomputing.com/static/Docs/PyQt5/incompatibilities.html#importing-the-sip-module > > If you use sip for reasons unrelated to PyQt5, you may leave the old import > as is, but please bear in mind that sip4 is deprecated. > > Also, calls like "sip.setapi('QDate', 2)" are not needed at all with PyQt5. > They were needed only with PyQt4 and Python 2. It is safe to delete them. > > For the actual documentation of sip module, see the following link: > > https://www.riverbankcomputing.com/static/Docs/PyQt5/api/sip/sip-module.html It seems the sip-related bits are still the same. It looks to me that sip is used for the following this: 1) sip.unwrapinstance() 2) sip.SIP_VERSION_STR (printed in the about dialog) 3) sip.cast() I do not know whether it is possible to "do stuff" without using them; would it be possible for you (not a priority though) to send patches upstream in case? https://invent.kde.org/games/kajongg It definitely should be easier than with krita... ;-) Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977814: fixed in llvm-toolchain-11 1:11.0.1-1
In data venerdì 8 gennaio 2021 12:38:20 CET, Gianfranco Costamagna ha scritto: > llvm-toolchain-11 is now fixed, and clazy should be fixed too. No, llvm-toolchain-11 is not fixed yet. > Unfortunately clazy seems to be missing a "break" relationship against old > llvm, and britney uses > the broken testing version to test it. It makes no sense for clazy to break and old llvm, it should be rather the other way round... but it shouldn't be needed. Also, the version in testing is *not* broken. clazy in testing is perfectly working, and it was the llvm-toolchain-11 upload that broke it. > I don't know if we can hint to let it migrate anyway, Considering nothing was actually done to fix the problems I reported earlier in this bug, I don't think that letting the newer llvm-toolchain-11 migrate and break also testing is an acceptable way forward. Even more so when there was *no* attempt by the Debian LLVM Maintainers (of which you are part) to debug what was the issue. All this "fix" did was to apply the diff I mentioned, which was to fix only a small part of the problems I reported. Also, reading it further, even the shlibs of all the other libraries need to be fixed: they all specify old versions (like 9~something) that are satisfied by any llvm-toolchain-11 version available, including prereleases. > Let me know if you have a solution for this issue, The Debian LLVM Maintainers ought to help debug why updating a new version suddently breaks software built against old versions of it. Sorry if I seem harsh: LLVM is a key component in a modern Debian system, so uploading new versions and providing almost no help on problems does not seem like a good idea for the distribution. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#979577: qtcreator: Clang Code Model no longer finds 'stddef.h' since version 4.14.0-2
In data venerdì 8 gennaio 2021 16:52:02 CET, Michael Weghorn ha scritto: > Package: qtcreator > Version: 4.14.0-2 > Severity: normal > X-Debbugs-Cc: m.wegh...@posteo.de > > Dear Maintainer, > > since version 4.14.0-2, Qt Creator's Clang Code Model is unable to find the > 'stddef.h' header. It still works OK with version 4.14.0-1. qtcreator 4.14.0-2 has been available in unstable (which you use) for more than two weeks, so reading this problem now seems slightly awkward. Have you used qtcreator 4.14.0-2 (and it code model) successfully so far in the past two weeks? My suspect is the upload of llvm-toolchain-11 done yesterday, and your package list: > ii libclang1-11 1:11.0.1-2 show you updated to it. Can you please try to backport your LLVM/Clang 11 packages to the same version used to build qtcreator? You can get the list of installed packages using: $ dpkg -l '*llvm*11*' | grep ^ii $ dpkg -l '*clang*11*' | grep ^ii and then use the `debsnap` tool, part of the devscripts package, to download them, e.g.: $ debsnap -d . -a amd64 libclang-11 1:11.0.1~+rc2-1 (you will need to repeat that for all the packages you have installed, removing the :amd64 suffix in the packages that have multi-arch annotations). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever
In data domenica 27 dicembre 2020 03:53:01 CET, Jonas Smedegaard ha scritto: > Version: 9.53.3~dfsg-6 > > Quoting Pino Toscano (2020-12-22 10:08:12) > > In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto: > > > > On my side, rebuilding libspectre1 solved this on my system. > > > > > > If a simple rebuild with no source changes fixes the symptoms of a > > > bug, that might indicate an unintended ABI break in libgs9, or > > > perhaps a bug in the old libgs9 headers (but fixed in the new > > > headers) in code that gets inlined into libspectre at compile time. > > > > Both of them are issues in ghostscript anyway. > > This was fixed in Ghostscript since release 9.53.3~dfsg-6 - I just > forgot to mention it in changelog (that will be corrected in next > release). Oh nice, I did not notice it. I can confirm that using - libgs9 9.53.3~dfsg-6 - libspectre1 0.2.9-1 - evince 3.38.0-3 there are no problems opening PS files in evince. Thanks! -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#966405: libopenbabel-dev: CMake files do not reflect installation paths
Hi Andrius, In data martedì 28 luglio 2020 07:33:15 CET, mer...@debian.org ha scritto: > Package: libopenbabel-dev > Control: forwarded -1 https://github.com/openbabel/openbabel/issues/2264 > Control: block 951674 by -1 > > Paths in OpenBabel3Config.cmake do not reflect real installation paths > in Debian systems, at least OpenBabel3_EXPORTS_FILE, which is set to > > ${OpenBabel3_INSTALL_PREFIX}/lib/cmake/openbabel3/OpenBabel3_EXPORTS.cmake > > while it should be > > /usr/lib//cmake/openbabel3/OpenBabel3_EXPORTS.cmake I took a bit of time to investigate and hopefully fix this issue. The results are: - https://github.com/openbabel/openbabel/pull/2315 for fixing the CMake configuration files upstream (they needed a bit of massaging) - https://salsa.debian.org/debichem-team/openbabel/-/merge_requests/5 to fix the library directory in Debian builds -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#881761: signon-plugin-oauth2 FTCBFS: does not pass cross tools to qmake and other issues
Hi Helmut, In data martedì 14 novembre 2017 22:32:01 CET, Helmut Grohne ha scritto: > Source: signon-plugin-oauth2 > Version: 0.22-1 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > signon-plugin-oauth2 fails to cross build from source for multiple > reasons: > * It does not pass cross tools to qmake. This task can be easily >deferred to dh_auto_configure these days, but it doesn't fully work, >so in the best case dh_auto_build will fail until debhelper is fixed. This was a bug, even more problematic than just for cross-building. I included this part in my recent signon-plugin-oauth2 0.25-1 upload. > * It uses uname -m to discover the host cpu, but that returns the build >cpu of course. > * It uses plain pkg-config, which is the build architecture pkg-config >while the host architecture one was expected. These two look like genuine bugs as well. Can you please send them as merge requests to the upstream repository? https://gitlab.com/accounts-sso/signon-plugin-oauth2 Upstream accepts MRs, so it should be easy to send them patches. I'd rather not include patches downstream that are kept there forever, adding more work to the already small enough attention that this package (and other Accounts SSO packages) already gets... Thanks in advance, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#978199: [Pkg-kde-extras] Bug#978199: libqapt: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory
^ > > /<>/src/debfile.cpp:378:23: warning: ‘void > > QProcess::start(const QString&, QIODevice::OpenMode)’ is deprecated: Use > > QProcess::start(const QString &program, const QStringList > > &arguments,OpenMode mode = ReadWrite) instead [-Wdeprecated-declarations] > > 378 | tar.start(program2); > > | ^ > > In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/QProcess:1, > > from /<>/src/debfile.cpp:24: > > /usr/include/x86_64-linux-gnu/qt5/QtCore/qprocess.h:168:10: note: declared > > here > > 168 | void start(const QString &command, OpenMode mode = ReadWrite); > > | ^ > > In file included from /usr/include/apt-pkg/deblistparser.h:15, > > from /<>/src/dependencyinfo.cpp:24: > > /usr/include/apt-pkg/pkgcachegen.h:32:10: fatal error: xxhash.h: No such > > file or directory > >32 | #include > > | ^~ It looks like a bug in one of the public headers of libapt-pkg, and already fixed upstream: https://salsa.debian.org/apt-team/apt/-/commit/ece7f5bb0afee0994a4fb4380e756ce725fe67a9 APT developers: please mark this bug as fixed in changelog. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#978164: kguiaddons: FTBFS on non-linux
tag 978164 + pending thanks In data sabato 26 dicembre 2020 21:54:19 CET, Samuel Thibault ha scritto: > Source: kguiaddons > Version: 5.77.0-3 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > > Hello, > > kguiaddons currently doesn't build on non-Linux, where Wayland is not > available. The attached patch fixes this. Yes, I know. I already fixed it few days ago: https://salsa.debian.org/qt-kde-team/kde/kguiaddons/-/commit/1130cd0d8f0c95c9536a74034826fbb0ed5f0d8c -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#941721: kde-standard: Cannot open the desktop settings dialog
reassign 941721 dde-qt5integration retitle 941721 crash in libdstyleplugin.so severity 941721 important thanks Hi, sorry for the late answer. In data venerdì 4 ottobre 2019 11:28:48 CET, Mebus ha scritto: > Package: kde-standard > Version: 5:102 > Severity: normal > > Hallo, > > when I open the desktop settings dialog the whole desktop seems to crash and > restart. It happens right after I right click on the desktop. I am expecting > the destkop settings dialog to appear. Let's see the crash report: [KCrash Handler] #6 0x7fbcc97dbdd0 in QWidget::style() const () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #7 0x7fbcc1c28efb in dstyle::Style::drawComboBoxLabelControl(QStyleOption const*, QPainter*, QWidget const*) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/libdstyleplugin.so #8 0x7fbcc1c17636 in dstyle::Style::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/libdstyleplugin.so #9 0x7fbcb83f4d84 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/libqtquickcontrolsplugin.so #10 0x7fbcb83f57ec in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/libqtquickcontrolsplugin.so #11 0x7fbcca798573 in QQuickWindowPrivate::polishItems() () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #12 0x7fbcca7275b5 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #13 0x7fbcca728615 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #14 0x7fbcc90771d5 in QWindow::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #15 0x7fbcca7a22db in QQuickWindow::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #16 0x7fbcc97b64b1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x7fbcc97bd950 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x7fbcc8cbd5a9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x7fbcc906c203 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #20 0x7fbcc906cead in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #21 0x7fbcc904706b in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #22 0x7fbcc34473eb in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #23 0x7fbcc8cbc27b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x7fbcc8cc4262 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #25 0x55990a38d1ab in ?? () #26 0x7fbcc873209b in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #27 0x55990a38d62a in _start () [Inferior 1 (process 1318) detached] It seems like it crashed in libdstyleplugin.so, which is a Deepin DE style plugin. Hence, I'm reassigning this bug to dde-qt5integration; Thank you for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#974566: [Pkg-kde-extras] Bug#974566: Bug#974566: labplot: Labplot fails to perform curve fitting with custom functions
In data venerdì 25 dicembre 2020 18:20:54 CET, Volkov YO via pkg-kde-extras ha scritto: > According to upstream tracker, the bug is fixed in labplot-2.8.2 onwards. Yes, I know that. OTOH, labplot 2.8.2 has not been released yet. > Please bump the package when possible. "bump the package" does not make much sense, FYI. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1
reassign 977329 lxqt-qtplugin retitle 977329 lxqt-plugin: platform theme needs fixes for Qt 5.15 tag 977329 = fixed-upstream severity 977329 serious thanks Hi, In data giovedì 24 dicembre 2020 20:48:32 CET, proctor ha scritto: > hi! thanks very much for your help. > > the krita segfault still happens with all latest updates, including the > most recent kernel 5.9.0-5-amd64 > > krita crashes at open. when i select the krita program from the menu > nothing happens at all. > when i run like this: > $ krita > Segmentation fault > > that's what happens > > i'm using lxqt Thanks for the detail about this, and most probably you have lxqt-qtplugin installed, right? I see that the there were various fixes upstream related to the compatibility with Qt 5.15 and color palettes, and I would not be surprised that any of these issues would cause a crash: https://github.com/lxqt/lxqt-qtplugin/issues/54 https://github.com/lxqt/lxqt-qtplugin/pull/55 https://github.com/lxqt/lxqt-qtplugin/commit/8cc32d94b4c9de74b5bcf27fae2d10e6b2b11caf It looks like everything is included in the new upstream release 0.16.0, which then needs to be packaged in Debian. Another check you can do is try to run krita in a different desktop environment / window manager than LxQt. Hence, I'm reassigning this to lxqt-qtplugin with proper metadata. Thanks for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#978028: opencv: FTBFS on architectures without java
Source: opencv Version: 4.5.1+dfsg-1 Severity: important Tags: patch Hi, opencv 4.5.1+dfsg-1 fails to build on architectures without Java support, like hurd-i386 [1]. This is because the libopencv4.5-java binary was changed from arch:all to arch:any in version 4.5.1+dfsg-1, so on architectures without Java the files to install in libopencv4.5-java are not found. The solution is to restrict the architecture of the libopencv4.5-java binary to the same list of architectures of the other Java-related binary, i.e. libopencv4.5-jni. Patch attached for this. [1] https://buildd.debian.org/status/fetch.php?pkg=opencv&arch=hurd-i386&ver=4.5.1%2Bdfsg-1&stamp=1608798863&raw=0 Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -1106,7 +1106,7 @@ Description: computer vision contrlib li recognition, camera calibration and 3D reconstruction. Package: libopencv4.5-java -Architecture: any +Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32 Multi-Arch: no Section: java Depends: libopencv4.5-jni (>= ${binary:Version}),