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#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#1064672: marked as pending in virt-manager
Control: tag -1 pending Hello, Bug #1064672 in virt-manager reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/virt-manager/-/commit/a8db17eb476ceab2fe5a0782227539cddd77d070 d/patches: add fix from upstream for FTBFS with libvirt 10.0 - tests: cli: Adjust hotplug test for latest libvirt Closes: #1064672 (this message was generated automatically) -- Greetings https://bugs.debian.org/1064672
Bug#1042147: marked as pending in virt-manager
Control: tag -1 pending Hello, Bug #1042147 in virt-manager reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/virt-manager/-/commit/35d6d1eeea61ea361289eb940ada658ecd74a017 d/patches: fix tests with newer osinfo-db Closes: #1042147 (this message was generated automatically) -- Greetings https://bugs.debian.org/1042147
Bug#1022339: marked as pending in virt-manager
Control: tag -1 pending Hello, Bug #1022339 in virt-manager reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/virt-manager/-/commit/592f0810d6b06c3ce358cc617a6bb8ab70db6bd4 Explicitly specify --install-layout=deb in the Python module installation; fixes compatibility with Python 3.10 in Debian. Closes: #1022339 Gbp-Dch: Full (this message was generated automatically) -- Greetings https://bugs.debian.org/1022339
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#1008358: marked as pending in virt-manager
Control: tag -1 pending Hello, Bug #1008358 in virt-manager reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/libvirt-team/virt-manager/-/commit/b8db30e00024b5a009be5a25fef7e0458f39dcd7 d/patches: add fixes from upstream for FTBFS with libvirt 8.1 - tests: Drop usage of sgio=unfiltered - tests: Fix another sgio=filtered case Closes: #1008358 (this message was generated automatically) -- Greetings https://bugs.debian.org/1008358
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#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#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#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#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#977988: /usr/bin/spectacle: does not start (libkImageAnnotator.so.0.3.2 not found)
reassign 977988 src:kimageannotator forcemerge 977649 977988 thanks In data mercoledì 23 dicembre 2020 22:26:13 CET, Dominik George ha scritto: > Package: kde-spectacle > Version: 20.12.0-1 > Severity: grave > File: /usr/bin/spectacle > Justification: renders package unusable > > After a recent update, spectacle stoppede working, and errors out on start > with: > > spectacle: error while loading shared libraries: > libkImageAnnotator.so.0.3.2: cannot open shared object file: No such file or > directory > > Maybe it needs a binNMU? No, it needs a fixed SONAME and a fixed Debian package name matching it. See also #977649 (which this bug will be merged to). In the meanwhile, I will disable the kimageannotator-related features, as at least there will be a functional Spectacle. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977814: clazy's autopkg tests fail with llvm 11.0.1 rc2
retitle llvm-toolchain-11/1:11.0.1~+rc1-1 breaks behaviour with 1:11.0.0-5 reassign 977814 src:llvm-toolchain-11 llvm-toolchain-11/1:11.0.1~+rc1-1 affects 977814 src:clazy thanks Hi, I did a change in clazy today, landed as 1.8-2, but we still have failures, so I did some more research. We currently have these versions of llvm-toolchain-11 and clazy: - llvm-toolchain-11/testing: 1:11.0.0-5 - llvm-toolchain-11/unstable: 1:11.0.1~+rc2-1 (the same can be said for 1:11.0.1~+rc1-1 too) - clazy/testing: 1.8-1+b1 - clazy/unstable: 1.8-2 clazy executes its own test suite both at build time (with the just built binaries/plugin), and as autopkgtest (with what is installed by the 'clazy' package). We have the following situation: a) clazy/testing a.1) PASS: build against llvm-toolchain-11/testing a.2) PASS: autopkgtest against llvm-toolchain-11/testing a.3) FAIL: autopkgtest against llvm-toolchain-11/unstable b) clazy/unstable b.1) PASS: build against llvm-toolchain-11/unstable b.2) FAIL: autopkgtest against llvm-toolchain-11/testing b.3) PASS: autopkgtest against llvm-toolchain-11/unstable So, to me it looks like we have two problems in llvm-toolchain-11: 1) something in llvm-toolchain-11/unstable breaks compatibility with clazy/testing, and thus it breaks the CI testing for testing migration of llvm-toolchain-11/unstable, case (a.3); in addition, clazy/unstable is now blocked for a similar situation, i.e. case (b.2) 2) in the dependencies of clazy I see: Depends: libc6 (>= 2.14), libclang-cpp11, libllvm11 (>= 1:9~svn298832-1~), libstdc++6 (>= 9), clang-11 that is, libllvm11 has a version as specified by shlibs, while libclang-cpp11 not; this sort of causes the case (b.2), as it allows that combination (as llvm-toolchain-11/testing is enough to satisfy the dependencies of clazy/unstable); a possible workaround is to make sure that all the libraries in llvm-toolchain-11 without symbols cause strict dependencies, as done by the following patch: --- a/debian/rules +++ b/debian/rules @@ -724,7 +724,7 @@ override_dh_makeshlibs: dh_makeshlibs -pliblldb-$(LLVM_VERSION) -V"liblldb-$(LLVM_VERSION) (>= 1:9~svn298832-1~)" dh_makeshlibs -plibllvm$(LLVM_VERSION) -V"libllvm$(LLVM_VERSION) (>= 1:9~svn298832-1~)" dh_makeshlibs -plibomp$(SONAME_OPENMP)-$(LLVM_VERSION) -V"libomp$(SONAME_OPENMP)-$(LLVM_VERSION) (>= 1:9~svn298832-1~)" - dh_makeshlibs --remaining-packages + dh_makeshlibs --remaining-packages -V override_dh_shlibdeps: # Ignore asan libraries. They would trigger dependencies to multiarch libraries In short: I'm reassigning this to llvm-toolchain-11, because there is a behaviour change in the new version, and because its libraries cause too loose dependencies. In the end, the clazy autopkgtest works properly, and it looks like it caught actual issues in llvm-toolchain-11. LLVM maintainers: please investigate and fix, thanks. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977814: closing 977814
close 977814 clazy/1.8-2 thanks -- Hopefully fixed with clazy 1.8-2: clazy (1.8-2) unstable; urgency=medium . * Add the libclang-cpp-dev build dependency to link against the shared libclang-cpp; hopefully this avoids problems when the LLVM version changes (due to the static linking). https://tracker.debian.org/news/1203963/accepted-clazy-18-2-source-into-unstable/ -- Pino Toscano
Bug#977649: kde-spectacle: Spectacle no longer starts after an update to libkimageannotator0
reassign 977649 src:kimageannotator retitle 977649 bumped SONAME without name change affects 977649 kde-spectacle thanks In data venerdì 18 dicembre 2020 06:40:15 CET, Christopher Cormier ha scritto: > Package: kde-spectacle > Version: 20.12.0-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: christophercorm...@protonmail.com > > Dear Maintainer, > > Spectacle is unable to start after the libkimageannotator0 package updated to > 0.4.0-1 > > When attempting to start it, it crashes with "error while loading shared > libraries: libkImageAnnotator.so.0.3.2: cannot open shared object file: No > such file or directory" > > Presumably, it needs to be rebuilt against the newer version of > KImageAnnotator, and the package's dependency on it should be locked to the > specific version it's built with. No, the problem is rather that the new version of kimageannotator bumps the SONAME of the shared library from libkImageAnnotator.so.0.3.2 to libkImageAnnotator.so.0.4.0, which is a big no-no. This also means that kimageannotator sets the SONAME of its shared library to the full version number, basically breaking compatibility even in patch releases; this is _bad_... Also, the Debian packaging of it does not help detecting this kind of situations, as names the library package as if the SONAME was only "0": $ lintian -I -E --pedantic --no-tag-display-limit libkimageannotator0_0.3.2-2_amd64.deb W: libkimageannotator0: package-name-doesnt-match-sonames libkImageAnnotator0.3.2 I: libkimageannotator0: no-symbols-control-file usr/lib/x86_64-linux-gnu/libkImageAnnotator.so.0.3.2 -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#975745: kexi: FTBFS: KReportGroupTracker.h:15: undefined reference to `vtable for KReportGroupTracker'
reassign 975745 libkreport3-4 kreport/3.2.0-2 tag 975745 = bullseye sid pending affects 975745 src:kexi thanks In data mercoledì 25 novembre 2020 20:58:28 CET, Lucas Nussbaum ha scritto: > Source: kexi > Version: 1:3.2.0-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201125 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > /usr/bin/ld: CMakeFiles/kexi_reportplugin.dir/krscriptfunctions.cpp.o: in > > function `KReportGroupTracker::~KReportGroupTracker()': > > /usr/include/KReport3/KReportGroupTracker.h:15: undefined reference to > > `vtable for KReportGroupTracker' > > collect2: error: ld returned 1 exit status Ops, I underestimated the symbols loss in kreport 3.2.0-2; fixing it soon, luckly already fixed upstream. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#971879: [Pkg-kde-extras] Bug#971879: Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image
retitle 971879 "charset=Ascii" appears before the comment of the image severity 971879 normal thanks In data giovedì 12 novembre 2020 23:33:17 CET, Vincent Lefevre ha scritto: > On 2020-11-12 22:48:32 +0100, Pino Toscano wrote: > > This is not how SONAME works, especially in a binary distro like Debian. > > Even assuming an SONAME bump is due (which IMHO is not), the consequence > > will be: > > 1) the SONAME of the library is bumped, either by upstream or in Debian > > 2) the Debian package is renamed > > 3) exiv2 will go through NEW > > 4) there will be a new exiv2 transition, and all the packages using the > >exiv2 library will be rebuilt anyway (including gthumb) > > 5) we are back to the same situation > > Not really. The applications should notice the change of the API via > their testsuites (if the build does not fail in the first place), > because they do not get the expected result. [...] > Now, it appears that in the particular > case of gthumb, its testsuite does not detect the issue. :( I don't > know about the other applications, though. That is not that much different than any other API or behaviour change. > So, what happens in > practice is that both versions of the library are coinstallable, and > applications that do not support the new API yet can still use the old > library until support is added. That only works for your local system, not for the Debian archive. If gthumb will not build during a library transition (for whichever reason, API change or test suite failure), then either it is fixed to build, or it will be removed from testing until it is fixed. The exiv2 source is one, and it provides only a library package. > > This is a behaviour change of the API, and IMHO there are two only > > options: > > a) restore the old behaviour, optionally adding a new API if needed > > b) adapt the applications to the new behaviour of the API > > > > Considering that it seems a wanted change by upstream, then I don't > > see (a) happening, so (b) seems to me the only alternative. Sure, > > it is not nice, but meh, not something else to do. > > > > Because of the above, Vincent, what about closing this bug, since there > > is nothing actionable in exiv2? > > I think that the best workaround is to temporarily restore the old > behavior until the applications support both the old one and the > new one. That would mean changing the behaviour for all _the_ exiv2 users, including the ones that adapted to the new behaviour. Also, this is definitely not a kind of change that I will apply locally in Debian, since it will make exiv2 behave differently than how upstream does, and how applications expect. Sorry, but unless upstream changes the behaviour, then the only viable solution is adapting the applications. Definitely this is *not* an rc-bug, though, especially with a misleading reason. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#971879: [Pkg-kde-extras] Bug#971879: gthumb: "charset=Ascii" appears before the comment of the image
In data giovedì 12 novembre 2020 22:25:31 CET, Vincent Lefevre ha scritto: > Control: retitle -1 libexiv2-27: change in both the API and the ABI > Control: severity -1 serious > > On 2020-10-09 03:11:19 +0200, Vincent Lefevre wrote: > > I think that this is > > > > https://github.com/Exiv2/exiv2/issues/1258 > > > > but this bug has been closed. So I don't know the current status. > > According to upstream, this is a change in the behavior on purpose, > which affects the ABI as one can see (and probably the API too). It > is not normal that one can upgrade libexiv2-27 only, affecting other > applications like gthumb as a consequence. > > The soname should have been changed. This is not how SONAME works, especially in a binary distro like Debian. Even assuming an SONAME bump is due (which IMHO is not), the consequence will be: 1) the SONAME of the library is bumped, either by upstream or in Debian 2) the Debian package is renamed 3) exiv2 will go through NEW 4) there will be a new exiv2 transition, and all the packages using the exiv2 library will be rebuilt anyway (including gthumb) 5) we are back to the same situation This is a behaviour change of the API, and IMHO there are two only options: a) restore the old behaviour, optionally adding a new API if needed b) adapt the applications to the new behaviour of the API Considering that it seems a wanted change by upstream, then I don't see (a) happening, so (b) seems to me the only alternative. Sure, it is not nice, but meh, not something else to do. Because of the above, Vincent, what about closing this bug, since there is nothing actionable in exiv2? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#936809: Processed: severity of 936809 is serious
severity 936809 important thanks Hi Moritz, In data domenica 25 ottobre 2020 10:45:05 CET, Debian Bug Tracking System ha scritto: > Processing commands for cont...@bugs.debian.org: > > > severity 936809 serious > Bug #936809 [src:kross-interpreters] kross-interpreters: Python2 removal in > sid/bullseye > Severity set to 'serious' from 'normal' This bug was already marked py2keep, as it depends only on src:python2.7, and we want to ship it in the next stable for now (it is not even fixed upstream). Hence, lowering its severity to important. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#971589: clazy's test suite uses the default clang, while the package uses the versioned one
severity 971589 important tag 971589 + needinfo thanks Hi, In data venerdì 2 ottobre 2020 13:12:19 CET, Matthias Klose ha scritto: > Package: src:clazy > Version: 1.7-3 > Severity: serious > Tags: sid bullseye > > This is seen when updating llvm-defaults to point to 11, and then running the > autopkg test. The test tries to run with the updated default clang (11), but > the package is still built using the previous 10 version. The package itself > uses a versioned clang for building, and also gets this dependency encoded in > the package. The plugins are not compatible across versions, so the test > should > always use the version that the package was built for. clazy will run against the clang version it was built with. The two unversioned invocations of clang are done only for diagnostic (one by the run-tests autopkgtest, and one by the upstream script used for testing). Considering the situation described is already what happens, I'm lowering the severity, and requesting for more information. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#972606: plasma-workspace FTFBS: cmake error / some missing dependency
reassign 972606 libkf5kdelibs4support-dev kdelibs4support/5.74.0-1 tag 972606 + pending thanks In data mercoledì 21 ottobre 2020 06:39:03 CEST, Norbert Preining ha scritto: > Hi > > On Wed, 21 Oct 2020, Helmut Grohne wrote: > > | -- Could NOT find KF5KDELibs4Support (found version "5.74.0"), checked > > the following files: > > | > > /usr/lib/x86_64-linux-gnu/cmake/KF5KDELibs4Support/KF5KDELibs4SupportConfig.cmake > > (version 5.74.0) > > | Reason given by package: KF5KDELibs4Support could not be found > > because dependency KF5ItemModels could not be found. > > Ahh, that is the same error I reported recently on IRC, it seems that > the kdelibs4support -dev package needs more Depends. Sandro removed it (again) in 5.74.0-1 :-/ I'll fix it soon. Sandro: when planning to remove dependencies from a -dev file, please rebuild the reverse dependencies to check everything still works (currently kdelibs4support has only 12 users in unstable). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#968438: Should this really be RC?
In data mercoledì 19 agosto 2020 17:54:47 CEST, Drew Parsons ha scritto: > On 2020-08-19 23:42, Lisandro Damián Nicanor Pérez Meyer wrote: > > I have updated okular and, while the bug is important I fail to see it > > as an RC bug. Most of okular's functionality is still there and > > working perfectly. > > > > I am not downgrading the bug severity because Pino did a first review > > and I might be missing something else. > > > Since it was a new release just uploaded to unstable, I marked it RC to > halt it from migrating to testing, at least until you had a chance to > review the problem. It's only the one piece of functionality that's > broken, but it's broken bad. (And for me, it's the functionality that I > like to use okular for). > > I'm happy for Pino to make the judgement to downgrade severity if you > and he thinks the new version is fit to go into testing. I understand the concern related to the bug introduced by the new version. I found an upstream bug that seems the same issue: https://bugs.kde.org/show_bug.cgi?id=425354 feel free to join it, and provide your feedback. Also, note that your point #1 is sort of invalid, as the design of the annotation toolbar was changed upstream. OTOH, all the other functionalities such as - opening and displaying any kind of document - dealing with attachments - dealing with forms - printing - all the various options/settings - showing the existing annotations - even modifying the properties of existing annotations - removing existing annotations work fine, TTBOMK. So yes, we have a bug that prevents creating new annotations, however it is just one of the possible functionalities. Because of this... > I think, and for that reason I've > marked this bug as Severity grave, "makes the package in question > mostly unusable" ... I disagree with this statement: the package in question is _not_ mostly unusable. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#964137: clazy: autopkgtests failure on 32bit
severity 964137 important tag 964137 - patch thanks In data giovedì 2 luglio 2020 13:12:54 CEST, Gianfranco Costamagna ha scritto: > Source: clazy > Version: 1.7-2 > severity: serious There are no 32bit architectures for autopkgtest in Debian, so this is definitely *not* a RC bug. > Hello, the following patch should be sufficient to make it work also in > autopkgtests. The patch is basically applying the workaround used in debian/rules also for autopkgtest; weird, flex, but I'd rather use the upstream patch that does the same. I will backport it after the current clazy 1.7 migrates to testing, since there is no reason it should be prevented to migrate. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#963837: soqt: Autopkgtests fail because of stderr (wrong permissions on $XDG_RUNTIME_DIR, 7755 instead of 7700)
In data domenica 28 giugno 2020 10:30:45 CEST, Dmitry Shachnev ha scritto: > Source: soqt > Version: 1.6.0+ds1-1 > Severity: serious > Justification: https://release.debian.org/bullseye/rc_policy.txt 6a > User: debian-qt-...@lists.debian.org > Usertags: qt5.14 > > Dear Maintainers, > > soqt autopkgtests fail with Qt 5.14: > > autopkgtest [23:09:17]: summary > test01 FAIL stderr: QStandardPaths: wrong permissions on > runtime directory /tmp/autopkgtest-lxc.da6wz6on/downtmp/autopkgtest_tmp, 7755 > instead of 7700 > test02 FAIL stderr: QStandardPaths: wrong permissions on > runtime directory /tmp/autopkgtest-lxc.da6wz6on/downtmp/autopkgtest_tmp, 7755 > instead of 7700 > test04 FAIL stderr: QStandardPaths: wrong permissions on > runtime directory /tmp/autopkgtest-lxc.da6wz6on/downtmp/autopkgtest_tmp, 7755 > instead of 7700 > test05 FAIL stderr: QStandardPaths: wrong permissions on > runtime directory /tmp/autopkgtest-lxc.da6wz6on/downtmp/autopkgtest_tmp, 7755 > instead of 7700 > > You can easily hide this warning by exporting > QT_LOGGING_RULES="default.warning=false" environment variable. > > Or add "Restrictions: allow-stderr" to debian/tests/control. Actually both of them are workarounds; the proper fix is to create the $XDG_RUNTIME_DIR directory with the proper permissions, as described by the XDG basedir spec: https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html $XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700. So the following change, that applies to all the debian/tests/test* tests, should do it: @@ -6,7 +6,8 @@ set -e export OMPI_MCA_orte_rsh_agent=/bin/false export DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH) -export XDG_RUNTIME_DIR="$AUTOPKGTEST_TMP" +export XDG_RUNTIME_DIR="$AUTOPKGTEST_TMP/run" +mkdir -m 700 "$XDG_RUNTIME_DIR" WORKDIR=$(mktemp -d) trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM (PS: you don't need to create WORKDIR either, simply use $AUTOPKGTEST_TMP directly.) -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#963704: libmount-dev: missing libcryptsetup-dev dependency breaks mount.pc
Package: libmount-dev
Version: 2.35.2-5
Severity: serious
Tags: patch
Justification: Policy 7.2
Hi,
util-linux 2.35.2-5 added support for dm-verify (#951048); apparently
this results in libmount requiring it as private dependency:
$ pkg-config --libs mount
-lmount
$ pkg-config --cflags mount
Package libcryptsetup was not found in the pkg-config search path.
Perhaps you should add the directory containing `libcryptsetup.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libcryptsetup', required by 'mount', not found
Easily fixed by adding libcryptsetup-dev dependency to libmount-dev;
patch attached for this.
Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -280,6 +280,7 @@ Section: libdevel
Priority: optional
Depends: libblkid-dev,
libc6-dev | libc-dev,
+ libcryptsetup-dev,
libmount1 (= ${binary:Version}),
libselinux1-dev,
${misc:Depends}
Bug#962348: kig: boost1.67 is being removed from testing
severity 962348 important thanks In data sabato 6 giugno 2020 16:26:34 CEST, Dimitri John Ledkov ha scritto: > Package: kig > Version: 4:20.04.1-1 > Severity: serious > > Hi, > > boost1.67 is being removed from testing and is transitioning to boost1.71. Yes, I know about the boost transition to 1.71.0, that the new boost does not provide Python 2 support, and that it is expected to not ship boost 1.67.0 in bullseye. > kig has just now switched from boost1.71 to boost1.67. Quoting what I wrote in the changelog entry of 4:20.04.1-1: * Temporarily switch from libboost-python-dev to libboost-python1.67-dev, as boost 1.67 is the latest version of boost in Debian that supports Python 2: kig < 20.08 is not ready for Python 3, so stil with Python 2 for now. As the version number hints, the new stable version will be released in (late) August; the development version already switched to Python 3 only, and it contains few Python 3 fixes. The current version does *not* work properly with Python 3, that is why I had to rollback to boost 1.67.0 (since boost 1.71.0 has no Python 2 bindings, sigh). > Thus I am opening this bug report to prevent kig from migrating. First of all, please do not abuse severities for things that are not critical yet. There is a catch here: the version in testing is the binNMU for the boost 1.71.0 rebuild, and apparently (to my surprise) it was detected and switched to Python 3. This is buggy though, so not letting this version migrate means having a buggy version in testing. > boost1.71 does not offer python2 bindings, as python2 is being removed to. Sure, I know this too. > I understand that kig is using boost-python2. Either please disable > python bindings usage at build time, or try to port to boost-python3? As I said, in ~3 months there will be a new upstream release fully supporting Python 3, and I will switch it when it is released. In the meanwhile, please: a) open a RM bug for boost 1.67.0, so it is clear that it will be removed b) make this bug block the RM bug I'm pretty sure boost 1.67.0 can stay 3 months more around, especially since I see it is still not the only package using the old boost. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#962172: closing 962172
close 962172 5.70.0-2 thanks -- Fixed in 5.70.0-2. -- Pino Toscano
Bug#955687: [Pkg-kde-extras] Bug#955687: wacomtablet: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/
reassign 955687 libwacom-dev libwacom/1.3-1 retitle 955687 missing libgudev-1.0-dev dependency severity 955687 serious bts affects 955687 src:wacomtablet thanks In data venerdì 3 aprile 2020 21:56:25 CEST, Lucas Nussbaum ha scritto: > Source: wacomtablet > Version: 3.2.0-3 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200402 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > make[2]: Entering directory > > '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' > > Building C object CMakeFiles/cmTC_56fac.dir/CheckFunctionExists.c.o > > /usr/bin/cc -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -g -O2 > > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=iso9899:1990 > > -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security > > -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute > > -Wwrite-strings -Werror=implicit-function-declaration > > -DCHECK_FUNCTION_EXISTS=shmat -o > > CMakeFiles/cmTC_56fac.dir/CheckFunctionExists.c.o -c > > /usr/share/cmake-3.16/Modules/CheckFunctionExists.c > > Linking C executable cmTC_56fac > > /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_56fac.dir/link.txt > > --verbose=1 > > /usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > > -D_FORTIFY_SOURCE=2 -std=iso9899:1990 -fno-common -Wall -Wextra > > -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long > > -Wpointer-arith -Wundef -Wmissing-format-attribute -Wwrite-strings > > -Werror=implicit-function-declaration -DCHECK_FUNCTION_EXISTS=shmat > > -Wl,-z,relro -Wl,-z,now -rdynamic > > CMakeFiles/cmTC_56fac.dir/CheckFunctionExists.c.o -o cmTC_56fac > > make[2]: Leaving directory > > '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' > > make[1]: Leaving directory > > '/<>/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp' > > > > > > > > dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake > > -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None > > -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var > > -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON > > -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON > > -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" > > -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_AUTOGEN_VERBOSE=ON > > -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu .. returned exit code 1 > > make: *** [debian/rules:8: build] Error 2 > > The full build log is available from: >http://qa-logs.debian.net/2020/04/02/wacomtablet_3.2.0-3_unstable.log This build was attempted with libwacom 1.3-1, whose libwacom-dev lacked a dependency and thus the libwacom detection (via pkg-config) in wacomtablet failed. This was already fixed in src:libwacom, so I'm reassigning this there, and closing it after that. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault
lts switch, this is slightly less problematic. In the meanwhile: because of what I said above, I'm demoting the severity of this bug to important. Also, Paul, please re-enable the autopkgtest of clazy on ci.debian.net, as they will pass now. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#784479: [kde4libs] Qt4's WebKit removal
In data lunedì 14 gennaio 2019 22:28:46 CET, Adrian Bunk ha scritto: > What is actually the overall plan for KDE4 in buster now? kdelibs 4.x will stay in buster. Period. Dropping stuff just for the sake of removal is a no-go, especially when done from people who have NO IDEA about Qt/KDE libraries/applications. As I already asked you: Adrian Bunk, please stay away from Qt/KDE stuff. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#784479: [kde4libs] Qt4's WebKit removal
In data lunedì 14 gennaio 2019 12:22:52 CET, Scott Kitterman ha scritto: > On Thu, 01 Nov 2018 14:04:12 -0300 Lisandro > =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer wrote: > > On Wed, 17 Oct 2018 15:57:25 +0200 Ivo De Decker wrote: > > > Hi, > > > > > > On Fri, Nov 24, 2017 at 04:59:58PM -0300, Lisandro Damián Nicanor Pérez > > Meyer wrote: > > > > Control: tag -1 patch > > > > > > > > There is patch available for this at > <https://git.archlinux.org/svntogit/ > > > > packages.git/tree/trunk/kdelibs-no-kdewebkit.patch?h=packages/kdelibs> > > > > > > > > We might want to wait for the last tandem of KF5 apps though. > > > > > > Is there anything still blocking this? > > > > Yes, at least one co maintainer believes the kde-runtime patch is not > > appropriate. > > That patch no longer seems to be available, so I made my own. Patches for > kde4libs and kde-runtime attached. I looked at the KDE4 packages still in > Buster and I don't believe this interferes with anything. This also fixes > the > FTBFS with Samba 4.9 by dropping the KDE4 kio_smb. The samba compatibility issue is a different story, and it can be fixed by just disabling kio_smb (in case it requires non-trivial work to make it work again). > I think we should move forward on these (or some improved version if someone > has suggestions). > > Even though there are separate bugs for kde-runtime, since the patch for it > was already discussed in this bug, I thought we might as well keep them > together. Did you check that all the packages using kde4libs still build fine? The removal of kio_thumbnail from kde-runtime is definitely not appropriate, since it will break the thunbnail support for any kdelibs 4.x application. Again: something worth to mention, since apparently it is not clear: removing bits from either kde4libs or kde-runtime has consequences, either build time or runtime ones. Randomly chopping pieces without checking what changes, and potentially what breaks, is generally a big no-no from me. I do not see how "remove qtwebkit" is an excuse to start messing up with packages, just for the sake of package removal. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#913474: [Pkg-kde-extras] Bug#913474: kile: Kile fails to start due to missing libnepomukutils (and other nepomuk related libs)
tag 913474 + moreinfo thanks In data domenica 11 novembre 2018 14:32:27 CET, Nicola Chiapolini ha scritto: > Package: kile > Version: 4:2.9.92-1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > >* What led up to the situation? > The system upgrade (testing) from 2018-10-15 removed the nepomuk related > libraries, probably since then kile does not start any more. (I do not > use kile daily anymore.) This is unrelated: the removed nepomuk libraries were Qt4/kdelibs 4.x, while kile since the 2.9.x versions switched to Qt5/KF5. Are you really sure that the version of the installed kile on your machine is 4:2.9.92-1? Please provide: $ dpkg -l kile $ dpkg -L kile $ ldd /usr/bin/kile $ ldd /usr/lib/*/libkdeinit5_kile.so Also, what is your exact Debian version? Please provide the rest of the reportbug template: $ reportbug --template kile >* What was the outcome of this action? > "kile: error while loading shared libraries: libnepomukutils.so.4: > cannot open shared object file: No such file or directory" It sounds like you still have kile 2.1.x installed. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#858938: fixed in kopete 4:18.04.1-1
In data sabato 10 novembre 2018 13:30:19 CET, Kurt Roeckx ha scritto: > On Sun, Oct 28, 2018 at 11:29:43PM +0100, Sebastian Andrzej Siewior wrote: > > On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote: > > > On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote: > > > > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote: > > > > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote: > > > > > > Source: kopete > > > > > > Source-Version: 4:18.04.1-1 > > > > > > > > > > > > We believe that the bug you reported is fixed in the latest version > > > > > > of > > > > > > kopete, which is due to be installed in the Debian FTP archive. > > > > > > > > > > Any plans to upload this to unstable? > > > > > > > > There are just two packages left in testing which use openssl1.0. The > > > > last kopete upload was in mid June. Is there anything blocking an upload > > > > to unstable? > > > > > > The other one just got fixed in unstable, so this will soon be the > > > only package in testing still depending on libssl1.0.2. > > > > kopete is the only package in testing still using libssl1.0.2. Could > > someone please comment on this? > > This is in experimental for more than 5 months now. > > If nobody replies to this, I will upload an NMU to unstable. NMU *what*? Because if you upload the version in experimental to unstable, then you are effectively taking its maintainership. The version in experimental is *NOT* ready for unstable/testing, otherwise I would have uploaded it long ago. I cannot work on it today, maybe tomorrow. OTOH, this kind of non-helping attitude for you openssl guys (for example not helping fixing these porting bugs, constant useless poking, breakage of openssl 1.1 in unstable) certainly does not help. If you want cooperation, then be ccoperative yourself, instead of just expecting others to follow whatever you do. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#904855: octave ftbfs in unstable
retitle 904855 FTBFS with Qt 5.11 forwarded 904855 https://savannah.gnu.org/bugs/?53978 tag 904855 + upstream fixed-upstream thanks In data domenica 29 luglio 2018 01:53:16 CEST, Matthias Klose ha scritto: > Package: src:octave > Version: 4.4.0-3 > Severity: serious > Tags: sid buster > > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/usr/include/freetype2 > -I/usr/include/libpng16 -I/usr/include/uuid -I/usr/include/freetype2 > -I/usr/include/libpng16 -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork > -I/usr/include/x86_64-linux-gnu/qt5 > -I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL > -I/usr/include/x86_64-linux-gnu/qt5 > -I/usr/include/x86_64-linux-gnu/qt5/QtPrintSupport > -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtHelp > -I/usr/include/x86_64-linux-gnu/qt5 > -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets > -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtGui > -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtSql > -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtCore > -I/usr/include/x86_64-linux-gnu/qt5 -I./libgui/qterminal/libqterminal > -Ilibgui/src -I./libgui/src -I./libgui/src/m-editor -I./libgui/src/qtinfo > -I./libgui/graphics -I./liboctave/array -Iliboctave/numeric > -I./liboctave/numeric -Iliboctave/operators -I./liboctave/operators > -I./liboctave/system -I./liboctave/util -Ilibinterp -I./libinterp > -Ilibinterp/parse-tree -I./libinterp/parse-tree -Ilibinterp/corefcn > -I./libinterp/corefcn -I./libinterp/octave-value -I./liboctave/wrappers > -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -fopenmp -Wall -W -Wshadow > -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align > -Wcast-qual -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -c > libgui/src/settings-dialog.cc -fPIC -DPIC -o > libgui/src/.libs/libgui_src_libgui_src_la-settings-dialog.o > libgui/src/settings-dialog.cc: In constructor > 'settings_dialog::settings_dialog(QWidget*, const QString&)': > libgui/src/settings-dialog.cc:302:57: error: invalid use of incomplete type > 'class QButtonGroup' >QButtonGroup *icon_size_group = new QButtonGroup (this); > ^ This happens because in Qt 5.11 some unneeded #include's were removed from public headers, breaking users that relied on them without including everything they needed. This was already reported [1], and fixed upstream [2]. Backporting that commit should be enough to fix the build failure with Qt 5.11. [1] https://savannah.gnu.org/bugs/?53978 [2] https://hg.savannah.gnu.org/hgweb/octave/rev/cdaa884568b1 -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#897792: [Pkg-kde-extras] Bug#897792: Bug#897792: libqaccessibilityclient: ftbfs with GCC-8
In data lunedì 23 luglio 2018 15:38:47 CEST, Maximiliano Curia ha scritto: > ¡Hola! > > El 2018-05-04 a las 12:22 +, Matthias Klose escribió: > > Package: src:libqaccessibilityclient > > Version: 0.1.1-5 > > Severity: normal > > Tags: sid buster > > User: debian-...@lists.debian.org > > Usertags: ftbfs-gcc-8 > > > Please keep this issue open in the bug tracker for the package it > > was filed for. If a fix in another package is required, please > > file a bug for the other package (or clone), and add a block in this > > package. Please keep the issue open until the package can be built in > > a follow-up test rebuild. > > > The package fails to build in a test rebuild on at least amd64 with > > gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The > > severity of this report will be raised before the buster release. > > > The full build log can be found at: > > http://aws-logs.debian.net/2018/05/01/gcc8/libqaccessibilityclient_0.1.1-5_unstable_gcc8.log.gz > > The last lines of the build log are at the end of this report. > > > To build with GCC 8, either set CC=gcc-8 CXX=g++-8 explicitly, > > or install the gcc, g++, gfortran, ... packages from experimental. > > > apt-get -t=experimental install g++ > > > Common build failures are new warnings resulting in build failures with > > -Werror turned on, or new/dropped symbols in Debian symbols files. > > For other C/C++ related build failures see the porting guide at > > http://gcc.gnu.org/gcc-8/porting_to.html > > It seems to me that src:libqaccessibilityclient currently has not reverse > dependencies, and since it's still qt4 based, we might want to get rid of it. We actually do want to use it. > Although, there is an "unstable" qt5 release > (https://download.kde.org/unstable/libqaccessibilityclient/), and recent > versions of kmag seem to be trying to use that. It seems misnamed, and actually the latest release in a while. > Sandro, if you plan to upload libqaccessibilityclient 0.2 please close this > issue with it. You could have checked this bug, see that I marked it as "pending", and possibly imagined the issue was taken care already. You could have checked its VCS: https://salsa.debian.org/qt-kde-team/extras/libqaccessibilityclient and noticing work on it, including this bug, and the Qt4 bug mentioned above. You could have also checked the kde-extras ML for possible uploads: https://alioth-lists.debian.net/pipermail/pkg-kde-extras/2018-July/029275.html ... and its NEW entry: https://ftp-master.debian.org/new/libqaccessibilityclient_0.2.0-1.html But you did not, as usual, check for things. Sad. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#902227: Krita lead developer has requested Debian cease distributing his software.
tag 902227 + moreinfo thanks Hi anonymous user, In data sabato 23 giugno 2018 17:13:11 CEST, anondeb...@1337.no ha scritto: > As per the reddit thread > https://www.reddit.com/r/linux/comments/8t2zgc/maintainers_matter_the_case_against_upstream/ > > (https://www.reddit.com/r/linux/comments/8t2zgc/maintainers_matter_the_case_against_upstream/), > the lead developer of Krita has made it very clear that they want Debian and > other distributions to cease packaging Krita unless they can always package > the latest version. As this is the wish of upstream, I feel that Debian > should immediately honor their wishes and stop packaging Krita, so we can get > the vastly superior version that is packaged in their appimage/flatpak, what > have you. I do not see any explicit request in that forum thread. Boudewijn Rempt knowns already who does most of the packaging work for Debian (which is me), and how to contact me. Hence, if he thinks there are issues with the way Krita is packaged and shipped in Debian, he is very well welcome to contact the Qt/KDE packaging team and/or me directly. I will not do changed based on random interpretations of comments in some random forum on the Internet made by some random/anonymous nick. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#862883: Port from libnm-glib/libnm-util to libnm
In data mercoledì 18 aprile 2018 19:35:01 CEST, Michael Biebl ha scritto: > Control: tags -1 + patch > > I made some more minor tweaks to v2: > > - Update debian/changelog > - Drop debian/patches/add_glib_for_nm, no longer necessary > > v3 of the debdiff is attached. I was told that it's probably not worth > forwarding this upstream, as KDE4 development is pretty much dormant. While the KDE 4 development is basically stopped, the code here was basically copied into the compatibility framework kdelibs4support; hence I'd prefer to see the resolution of #862877 (or at least upstream feedback on the patch for it), so the same fix can be backported here too. > I plan to NMU kde-runtime in a week or so and upload to DELAYED/10 > unless I hear back from you. Please holler, if you have any objections. See above. Also, there are local changes in the packaging git, and possibly I should land one/two more (although I have not worked on them yet). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#862877: Port from libnm-glib/libnm-util to libnm
In data mercoledì 18 aprile 2018 19:01:53 CEST, Michael Biebl ha scritto: > Control: tags -1 + patch > > Attached is a debdiff which is based on lubo's patch. > > Changes to the initial patch > - Use Q_SLOTS instead of slots, instead of simply commenting it out > - Use nm-dbus-interface.h include instead of NetworkManager.h, so we > don't pull in any glib/gio related headers > - Drop NM_CHECK_VERSION define, no longer needed. > > I've submitted the same patch upstream. Do you have the link to the upstream submission? Note that these days upstream uses phabricator [1] for patch reviews. [1] https://phabricator.kde.org/ > I plan to NMU in a week or so and upload to DELAYED/10 unless I hear > back from you. I'd rather prefer to get first the feedback from upstream, so we can possibly even just backport the upstream commit. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#858938: kopete: Please migrate to openssl1.1 in buster
In data martedì 17 aprile 2018 20:46:24 CEST, Emilio Pozuelo Monfort ha scritto: > ¡Hola Lisandro! > > On 25/02/18 17:40, Lisandro Damián Nicanor Pérez Meyer wrote: > > Hi Emilio! > > > > El 25 feb. 2018 7:00 a.m., "Emilio Pozuelo Monfort" > > escribió: > > > > Hi, > > > > On Thu, 12 Oct 2017 23:44:27 +0200 Sebastian Andrzej Siewior > > wrote: > >> this is a remainder about the openssl transition [0]. We really want to > >> remove libssl1.0-dev from unstable for Buster. I will raise the severity > >> of this bug to serious in a month. Please react before that happens. > > It looks like kopete only wants openssl for jingle support in XMPP. Can you > > temporarily disable that, and forward this bug upstream so they add support > > for > > openssl 1.1? > > > > > > I haven't checked, but maybe it depends on qt itself. If that's the case > > then waiting upon qt 5.10 might be the best thing here. We are not that far > > from asking a transition for it. > > > > Of course If that's not the case then it's a possibility. > > Now that we have Qt 5.10 in sid, can you check if kopete can be built with > OpenSSL 1.1? Otherwise, disabling jingle could solve this for the time being. The version of openssl used to build Qt is irrelevant for the jingle code that uses openssl directly; nobody did anything about that, so the status is the same as before. If the openssl maintainers want to get rid of openssl 1.0, why don't they *cooperate* with *upstream* communities on the migration to the newer version of openssl? That would certainly help, and surely way more than useless "please migrate, ktnxbye" nagging. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#784524: [Pkg-kde-extras] Bug#784524: [robojournal] Qt4's WebKit removal
Hi, In data sabato 10 marzo 2018 10:21:16 CET, Boyuan Yang ha scritto: > We really want to remove Qt4 Webkit from the archive in Debian Buster. "we" who? I don't see you as part of the Qt/KDE team, nor I don't see any email from you about this on the team mailing list. > [1] As a result, I'm wondering if we could remove package robojournal > from Debian Archive soon. Because of this bug, robojournal is already out of testing, so a QtWebKit removal is not blocked by this bug. > Please feel free to tell me about your idea torwards this package. Unless Ritesh says otherwise, leave this package as it is. Also, for what it matters, please leave also QtWebKit as it is, since it is under the Qt/KDE team wing, and removing it requires more work than occasional people (like this email) think about. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#886943: [Pkg-kde-extras] Bug#886943: libtelepathy-qt5-0: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE
Hi Andreas,
In data giovedì 11 gennaio 2018 16:51:26 CET, Andreas Beckmann ha scritto:
> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.
> [...]
> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.
> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.
> See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.
Could you help with a patch for this, or mention some other source that
needed to do the same changes?
Thanks,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#874980: Bug#874826: libkdewebkit5/libplasma3 removal from buster
severity 874980 wishlist tags 874980 = thanks On domenica 3 dicembre 2017 14:01:33 CET Adrian Bunk wrote: > As part of the removal of Qt4's WebKit it is planned to remove > libkdewebkit5 and libplasma3 from buster soon, even earlier > than the rest of the Qt4 removal. The upload of kremotecontrol 4:17.08.3-1 drop the Plasma parts, so this bug is back to "just" Qt4 porting concern. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883100: ksudoku FTBFS on armel/armhf: error: conflicting declaration 'typedef ptrdiff_t GLsizeiptr'
severity 883100 important tag 883100 - patch thanks Since ksudoku was removed from unstable (and soon testing), this is no more a blocking issue. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883626: kubrick FTBFS on armel/armhf: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'
severity 883626 important tag 883626 - patch thanks Since kubrick was removed from unstable (and soon testing), this is no more a blocking issue. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#886322: libkf5kdelibs4support-dev: Should libkf5kdelibs4support-dev still depend on libssl1.0-dev
On giovedì 4 gennaio 2018 15:03:38 CET Eric Valette wrote: > On 01/04/2018 02:25 PM, Pino Toscano wrote: > > On giovedì 4 gennaio 2018 14:17:59 CET Eric Valette wrote: > >>> this is a duplicate of bug #850888, since the dependency in the -dev > >>> package depends on which libssl was used for the build. When > >>> kdelibs4support is ported to libssl1.1, then the dependency in the -dev > >>> package will be updated. > >> But if the kdelibs4supportpackage was build using libsll1.0-dev, then > >> some kdelibs4support generated packages should depend on libsll1.0.0 > >> which is not the case. > > > > kdelibs4support is built against libssl1.0. There are few publich > > headers of it that include libssl headers, so that warrants the > > dependency in the -dev package -- but they are not used a lot, so it > > will not cause a dependency on that on the majority (if not all) of > > packages that build using kdelibs4support (also almost all the > > kde-related packages are built using --as-needed). > > > > So, what you said is not true, and partially does not make any sense. > > Sorry to be stupid but: > > If I understand, the include exported libkf5kdelibs4support-dev by > require the sll headers because some of them are included but are not > used by the packages itself. Right? No, there are parts of kdelibs4support that use OpenSSL, but because of its obnoxious license then it is not common for code using OpenSSL to link directly to it. > But then other packages build using kdelibs4supportpackage-dev should > then depend on libsll1.0.0 if they really use the headers requiring ssl > includes and sll API and not only macros As I wrote above, the usage of the SSL-using parts in kdelibs4support is not common; indeed, if anything links to kdelibs4support and uses those parts, then it must use libssl1.0-dev (same as kdelibs4support to avoid API mismatches), which is a dependency in our -dev. > which is not the case as shown via apt-rdepends in original report. There is no such "libssl1.0.0" in Debian, so you indeed get almost no packages depending on it. The library for libssl1.0-dev is libssl1.0.2, and you can verify there are still many packages depending on it. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#886322: libkf5kdelibs4support-dev: Should libkf5kdelibs4support-dev still depend on libssl1.0-dev
On giovedì 4 gennaio 2018 14:17:59 CET Eric Valette wrote: > > this is a duplicate of bug #850888, since the dependency in the -dev > > package depends on which libssl was used for the build. When > > kdelibs4support is ported to libssl1.1, then the dependency in the -dev > > package will be updated. > But if the kdelibs4supportpackage was build using libsll1.0-dev, then > some kdelibs4support generated packages should depend on libsll1.0.0 > which is not the case. kdelibs4support is built against libssl1.0. There are few publich headers of it that include libssl headers, so that warrants the dependency in the -dev package -- but they are not used a lot, so it will not cause a dependency on that on the majority (if not all) of packages that build using kdelibs4support (also almost all the kde-related packages are built using --as-needed). So, what you said is not true, and partially does not make any sense. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883100: Bug#886245: RM: ksudoku [armel armhf] -- ROM; does not support Desktop OpenGL
On mercoledì 3 gennaio 2018 20:48:25 CET Adrian Bunk wrote: > On Wed, Jan 03, 2018 at 07:32:46PM +0100, Pino Toscano wrote: > > On mercoledì 3 gennaio 2018 20:26:53 CET Adrian Bunk wrote: > > > On Wed, Jan 03, 2018 at 07:14:58PM +0100, Pino Toscano wrote: > > > > On mercoledì 3 gennaio 2018 20:12:05 CET Adrian Bunk wrote: > > > >... > > > > > Regarding ksudoku, is there any reason why you didn't apply > > > > > either my patch from #883100 or the similar change from Ubuntu? > > > > > Either one would fix the build on armel and armhf. > > > > > > > > It is a bad hack, and I do not want to carry and support it. > > > > > > Ubuntu backported the upstream fix. > > > > Ah I see, a different hack than yours [1], > >... > > [1] that btw will not work, since even if you skip the > > find_package(OpenGL) call, then set_package_properties(OpenGL ...) sets > > TYPE REQUIRED, and thus make cmake error out (see feature_summary) > > because a required dependency was not found > > Why are you implying that I did not test that my patch fixed the FTBFS > before submitting it? > > When you are claiming that it "will not work", all I can say is > that it did work for me in an armel build on November 29th 2017. I stand corrected: your patch "builds" (although IMHO it should not). Still, both yours and "upstream" patches are hacks, and no, I am *not* going to support them. If you could stop pushing for them, it would be less time I am wasting on this. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#885111: Note that this bug prevents to install libssl-dev and force libssl1.0-dev => severity should be raised
Dear user, On mercoledì 3 gennaio 2018 14:54:08 CET Eric Valette wrote: > severity 885111 serious Please do not bump the severity of bugs with random criterias. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#867561: gksu, kdesu, etc dependencies not really needed
tag 867561 + patch
thanks
Hi,
according to:
- base/password.py, __get_password_utils_ui
- installer/core_install.py, check_passwd_util
all the bits that use kdesu, kdesudo, gnomesu, and gksu are commented,
so the dependencies can be removed altogether. Even because, looking
at them we have:
- gksu: deprecated, broken, #867236
- kdebase-bin & kdebase-runtime: transitional since Wheezy
(oldoldstable)
- kde-runtime: it does not contain the "kdesu" binary in $PATH anymore
- kdesudo: deprecated, dropped, #875107
- ktsuss: dropped more than 6 years ago, #622270
Patch attached for this.
Thanks.
--
Pino Toscano--- a/debian/control
+++ b/debian/control
@@ -122,7 +122,6 @@ Description: HP Printers PostScript Desc
Package: hplip-gui
Architecture: all
Depends: default-dbus-session-bus | dbus-session-bus,
- gksu | kdebase-bin (<< 4:4.4.0-1) | kde-runtime | kdebase-runtime | kdesudo | ktsuss,
hplip (>= ${source:Version}),
python3-dbus.mainloop.pyqt5,
python3-pyqt5,
signature.asc
Description: This is a digitally signed message part.
Bug#884874: phonon-backend-vlc: Application using phonon are crashing with vlc 3.0.0~rc2
In data martedì 26 dicembre 2017 13:00:02 CET, Vincas Dargis ha scritto: > VLC 3.0.0 entered Testing, and Dragon and Amarok started to crash. > > Could it have been possible to kinda stop VLC upload because some > depended packages breaks? That would be nice in this case. The fixed phonon-vlc will migrate to testing tomorrow. You can pull it from unstable, or just temporarily switch to phonon-gstreamer for today. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#884874: phonon-backend-vlc: Application using phonon are crashing with vlc 3.0.0~rc2
Hi Sandro, In data mercoledì 20 dicembre 2017 21:06:38 CET, Sandro Knauß ha scritto: > Source: phonon-backend-vlc > Version: 0.9.0-2 > Severity: serious > > with the upload of vlc 3.0.0~rc2-1 at unstable phonon applications like > amarok and kcmshell4 kcm_phonon are constanly crashing. For the moment I > switched to gstreamer backend. Do you still have crashes with phonon-backend-vlc 0.9.1-2? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#884048: gnome-shell: /usr/lib/gnome-shell/gnome-shell-calendar-server continually crashes with segfault
Control: severity -1 important In data sabato 16 dicembre 2017 23:25:16 CET, Adrian Bunk ha scritto: > Control: severity -1 serious > > On Sat, Dec 16, 2017 at 09:19:18PM +0100, Michael Biebl wrote: > > Control: severity -1 important > > > > > Dec 10 13:17:40 lavaine kernel: [ 3324.799650] gnome-shell-cal[2352]: > > > segfault at 10812 ip 7f2eeafd0324 sp 7ffd0bc3d6d0 error 4 in > > > libical.so.2.0.0[7f2eeaf8d000+5e000] > > To explain what's happening here: > > gnome-shell links directly against libical (here against v2) and also > > against libecal (from evolution-data-server). > > evolution-data-server was updated to link against libical v3. The result > > is, that gnome-shell was now loading libical2 (directly) and libical3 > > (indirectly via libecal) into its address space. This is not supported > > and leads to the crash. > > > > I decided to add a Conflicts: libical2 to libecal (see #884012) to avoid > > this situation. > > > > So from my POV, this bug can be closed. Other DDs mentioned on > > #debian-devel though, that this conflicts should be added directly to > > libical3. I'm thus leaving this bug report open for further discussion > > but downgrade the severity, as the immediate issue (the segfault in > > gnome-shell) is addressed by #884012. > > KDE has/had similar problems, setting back to RC to prevent testing > migration until this is sorted out. What are the "similar problems" of "KDE"? Neither the kdelibs 4.x nor the KF5 stacks support libical3, so everything uses libical2 for now. The only exception is digikam, for which I just requested a rebuild (since kcalcore was fixed to properly use libical2, see #883921). Since I don't see any other message in this bug regarding problems, nor I see any bug filed in any part of the KDE stack, then I'm lowering the severity of this bug, so this rushed doko-transition can be finally unblocked (unblocking the marble+libkipi transition too). -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#884679: nomacs: linked with incompatible quazip library
Source: nomacs Version: 3.8.0+dfsg-1 Severity: grave Justification: renders package unusable Control: block 875026 by -1 Hi, it seems like nomacs is built against the Qt4 version of the quazip library (libquazip-dev as build dependency, and links to libquazip1). Considering nomacs uses Qt5, this combination will not ever work (hence the 'grave' severity). Please fix it so it uses the Qt5 version of quazip. Thanks, -- Pino
Bug#884488: [Pkg-kde-extras] Bug#884488: [ktorrent] Freezes at start
In data venerdì 15 dicembre 2017 19:56:38 CET, Antonio Marcos López Alonso ha
scritto:
> Package: ktorrent
> Version: 5.1.0-2
> Severity: grave
>
> --- Please enter the report below this line. ---
>
> Since last update KTorrent freezes at start. The windows turns unusable. The
> only maybe
> related piece of info in terminal output might be:
>
> Qt Warning: "0 instead of 3 arguments to message {...}
> supplied before
> conversion."
The last update of what? ktorrent, Debian unstable, etc? When was the
last successful run of ktorrent?
> --- System information. ---
Unfortunately, this system information is not useful; please attach
inline the output of `reportbug --template ktorrent`.
Thanks,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#884409: kio-audiocd failing with "Unknown protocol 'audiocd'".
severity 884409 important block 884409 by 874820 thanks Hi, In data giovedì 14 dicembre 2017 23:08:30 CET, Hakan Bayindir ha scritto: > Accessing audio CDs with kio-audiocd package is currently not possible. > kio-audiocd slave doesn't run, and the CD cannot be read or ripped via > dolphin. > > [...] > > kf5.kio.core: couldn't create slave: "klauncher said: Unknown protocol > 'audiocd'.\n" This is because kio-audiocd is still a KIO-Slave for kdelibs 4.x (with Qt 4), while dolphin is an application based on Frameworks 5.x (with Qt 5). Obviously, you cannot use Qt4 plugins in Qt5 applications, and vice versa. This will be fixed once kio-audiocd is updated to version >= 17.08; see also bug #874820. (BTW: we still ship a dolphin4 package, which is the latest version of dolphin for kdelibs 4.x; this version is able to use the current version of kio-audiocd.) -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#883706: dolphin4 is still linked with libplasma3
Control: severity -1 important Control: tag -1 - patch In data mercoledì 6 dicembre 2017 19:33:10 CET, Adrian Bunk ha scritto: > Package: dolphin4 > Version: 4:16.08.3-1 > Severity: serious > Tags: patch buster sid > > dolphin4 is still linked with libplasma3, > which has to be removed for the qtwebkit removal. NACK. dolphin4 (which uses kdelibs4) is shipped only to provide file browsing capabilities to konqueror (which uses kdelibs4). In recent versions of KDE Applications kde-baseapps does not exist anymore, replaced by split tarballs (konqueror, kfind, keditbookmarks, kdialog). Only konqueror is available in experimental, the others are waiting in NEW. Once all are available, they will replace kde-baseapps in unstable (in a coordinated upload with kde-l10n, since they ship translations), and thus dolphin4 will be removed. To be honest, it would be much easier if you could *wait* for the completion of Applications 17.08 in unstable/testing, so there will be few more kdelibs4-using sources either dropped (like dolphin4) or ported to Frameworks. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#873411: kdevelop: Please update to llvm-toolchain 4.0 or, better, 5.0
Control: severity -1 important (see below why...) In data lunedì 20 novembre 2017 20:05:20 CET, Emilio Pozuelo Monfort ha scritto: > Control: severity -1 serious > > On Wed, 06 Sep 2017 21:34:47 +0200 Pino Toscano wrote: > > Hi, > > > > In data domenica 27 agosto 2017 16:01:25 CEST, Sylvestre Ledru ha scritto: > > > Source: kdevelop > > > Severity: normal > > > > > > Hello, > > > > > > Currently, we have 6 versions of the llvm toolchain in the archive. > > > I would like to move to 3 versions (4.0, 5.0 and snapshot, aka 6.0) > > > > > > Could you please update your package to use 4.0 (or, better, 5.0 which > > > will be released very > > > soon)? > > > > Sure, but only after the versions available build and work at least on > > all the release architectures. So far, llvm 3.9 is still affected by > > #866354, since it did not build fine again since then -- this is > > holding kdevelop in unstable for more than 2 months, and I really would > > like to get it into testing. > > > > I see that each of the llvm sources has various bugs, FTBFSes, cmake > > issues, and so forth... as a suggestion from a bystander, what about > > focusing on at most 3 versions of llvm in the archive, instead of > > upload every version available (and then have to cleanup llvm users > > periodically, like with bugs like this)? > > > > > I will update the severity of this bug at the end of September > > > > Doing that with the current state of llvm versions would be a bad idea. > > It should be fine now with 4.0. Would be good if this could move to either > unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. > Bumping > to serious as we want to remove 3.8 soon to reduce the high number of llvm > versions that we currently ship. IMHO, if the goal would really be getting rid of old llvm versions in the archive, then (as I wrote above) the llvm maintainers ought to a) fix the latest stable (= 5.0) b) switch llvm-defaults to the above llvm got versioned symbols, so loading two llvm versions in the same process (hello, mesa), although it is ugly. This should allow kdevelop to switch back to llvm-defaults, even if llvm maintainers should care a bit more about it, instead of almost letting it rot... Anyway, I just lowered the severity of this bug to important, so kdevelop 5.2 can migrate to testing. Yes, it is an important update (merged kdevplatform, so the separate source can be dropped), so I really it to reach testing. Because of another issue in the past, related to llvm (#866354), kdevelop 5.1.x was stuck in unstable for basically 2 months. I don't want llvm to get in the way of kdevelop, once again. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#882191: ktuberling: file conflict with kde-l10n-ptbr: /usr/share/doc/HTML/pt_BR/ktuberling/index.cache.bz2
reassign 882191 src:kde-l10n kde-l10n/4:16.04.3-3 thanks In data lunedì 20 novembre 2017 03:53:49 CET, Andreas Beckmann ha scritto: > I'm filing only this one bug (because ktuberling is the only > package with a -2 revision and a changelog entry pointing > into the Breaks+Replaces direction), > but the problem affects many packages uploaded yesterday: > > ark=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > blinken=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > bomber=4:17.08.3-1kde-l10n-ptbr=4:16.04.3-3 > bovo=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > filelight=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > granatier=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > kapman=4:17.08.3-1kde-l10n-ptbr=4:16.04.3-3 > katomic=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > kblackbox=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > kblocks=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > kbounce=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > kbreakout=4:17.08.3-1 kde-l10n-ptbr=4:16.04.3-3 > > kde-l10n-ptbr=4:16.04.3-3 kdiamond=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kfourinline=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 khangman=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 killbots=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kiriki=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kjumpingcube=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 klettres-data=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 klickety=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 klines=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kmahjongg=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kmines=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 knavalbattle=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 knetwalk=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kollision=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kpat=4:17.08.3-2 > kde-l10n-ptbr=4:16.04.3-3 kshisen=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 ksquares=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 ksystemlog=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 kteatime=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 ktuberling=4:17.08.3-2 > kde-l10n-ptbr=4:16.04.3-3 lokalize=4:17.08.3-1 > kde-l10n-ptbr=4:16.04.3-3 picmi=4:17.08.3-1 > > kde-l10n-sr=4:16.04.3-3 lokalize=4:17.08.3-1 Sigh... OK, let's move this bug to kde-l10n, no point it staying as a ktuberling bug. I'll fix kde-l10n and the other affected packages tonight. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#882100: kgoldrunner: File conflict with kde-l10n-de
reassign 882100 src:kde-l10n kde-l10n/4:17.08.3-1 thanks Hi, In data domenica 19 novembre 2017 00:23:12 CET, Sandro Knauß ha scritto: > Package: kgoldrunner > Version: 4:17.08.3-1 > Severity: grave > Justification: renders package unusable > > Hey, > > there is a file conflict with kde-l10n-de 4:17.04.3-1, so it needs to Breaks > with that: > > dpkg: error processing archive > /tmp/apt-dpkg-install-AL96il/23-kgoldrunner_4%3a17.08.3-1_amd64.deb > (--unpack): > trying to overwrite '/usr/share/locale/de/LC_MESSAGES/kgoldrunner.mo', > which is also in package kde-l10n-de 4:17.04.3-1 > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) This cannot be fixed properly in kgoldrunner (and in the other applications I uploaded yesterday), otherwise it will make kde-l10n uninstallable in general. Let's fix this in kde-l10n instead. This affects only people using kde-l10n from experimental, and it will not be a problem in the long term. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#880884: marked as done (qtav: Adapt to libva 2)
In data lunedì 13 novembre 2017 12:06:01 CET, Steve Robbins ha scritto: > On Sunday, November 12, 2017 7:21:30 PM CST Sebastian Ramacher wrote: > > > > [ Pino Toscano ] > > >* Remove manual library and va-driver dependencies. (Closes: #880884) > > > > I am afraid that this change is not enough. qtav still needs to be ported to > > the new libva. Currently it links libva2, > > Concretely, what needs to be "ported"? The sources build against libva2 as > you say. Aside from dlopen issues, below, what needs to change? > > > but dlopens libva.so.1, > > libva-x11.so.1, and maybe others. Sebastian: this would have been nice to know when the bug was filed (or as additional comments), instead of only when reopening it later on... > How did you determine this? I looked for dlopen in the code and found > nothing. Grepping for "libva" came up only with this code setting a > "detail_display" property. It is a bit more complex than that: see in src/vaapi/vaapi_helper.h/cpp a) the dll_helper class, its constructor in particular b) all the various dll_helper subclasses, and how they pass "1" as version for the library to load The even more funny part is that libQtAV.so actually links to libva (and thus it gets the proper shlibs dependency), although it will try to dlopen it later on! This is funky (to say it mildly), and QtAV ought to better link to libva* if found during build. A simple solution could be to adapt to "2" all the libva versions there, but also checking that all the symbols dynamically loaded actually are what libQtAV expects (parameters, semantics, etc). A more complex solution is, of course, to properly link to the used libraries... Both of them need some feedback from upstream. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#877295: [Pkg-kde-extras] Bug#877295: amarok build-depends on removed package libgpod-nogtk-dev
In data sabato 30 settembre 2017 16:12:19 CEST, Adrian Bunk ha scritto: > On Sat, Sep 30, 2017 at 02:04:58PM +0200, Pino Toscano wrote: > > In data sabato 30 settembre 2017 14:55:34 CEST, Adrian Bunk ha scritto: > >... > > > Current status quo in Debian is that it is completely normal that > > > a new upload of some package is followed by me filing 10-50 RC bugs > > > against packages that FTBFS due to that change. > > > > No, it is not. You are mixing two things in the same pot: > > a) breakages due to side-effect (possibly not known in advance) of new > >versions of packages > > b) well-known breakages that some change is going to cause > >... > > In the vast majority of the RC bugs I report, the sole difference > between a) and b) is whether the uploader bothered to check whether > the new package might break rdeps. Which you knew, yet ignored. > gtk-doc-tools 1.26 or Qt 5.9 likely breaking some rdeps is something > that is known in advance. Usually the breakages due to a new version of Qt tend to be very low. > > My note was a general remark that for things in the (b) category above > > a pre-emptive email/bug/etc to the interested rdeps *is* the optimal > > way to interface with other people. I do not care if other people just > > dump stuff in unstable and expect other to clean up after the mess they > > created -- it is simply *not* correct, not even fair. > > #872796 #873023 #873444 #872742 #873020 #874187 > > Do you consider it fair that I had to submit bugs to help clean up the > mess created by the Qt maintainers dumping 5.9 into unstable without > first checking that all their rdeps still build? a) #872742 was detected during the transition, and was correctly fixed as part of it (thanks for reporting it) b) #874187 has nothing to do with Qt, but with the switch to GCC 7 c) Qt 5.9 was not "dumped" into unstable: it was tested with a large DE (Plasma), and a number of other packages; sure, there were 5 FTBFSes, and this is what I said earlier with "possibly not known in advance [side effects]" d) I don't see anybody forcing you to file bugs to "clean up a mess" (that did not actually exist); if you didn't have the time/will/etc, you could have *contacted* the team (see what I already said about cooperation); using these bugs as excuse like "I break things, since you broke them" is not exactly a constructive modus operandi, and just lead to a downhill path in lack of cooperation e) even said all the above: I don't see how this is relevant to the note I sent to you over what I saw regarding your libgpod upload; please do not change the topic like "... so what about the others?" > > > So when the only rdep is one package that is not in testing and anyways > > > requires a (non-trivial) sourceful upload for re-entering testing, > > > I fail to see any reasonable justification for me to spend additional > > > time on going through any process longer than just filing an RC bug. > > > > And this is again this very specific case. > > I did this change as part of a QA upload also fixing one of these > FTBFS I reported but didn't cause (#876583). Sure, and I don't see how fixing that bug required dropping used (even if only in unstable) packages. Again, my note was only regarding the way a breakage was introduced in Debian, not on the upload as a whole. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#877295: [Pkg-kde-extras] Bug#877295: amarok build-depends on removed package libgpod-nogtk-dev
In data sabato 30 settembre 2017 14:55:34 CEST, Adrian Bunk ha scritto: > On Sat, Sep 30, 2017 at 01:28:54PM +0200, Pino Toscano wrote: > > In data sabato 30 settembre 2017 13:17:43 CEST, Adrian Bunk ha scritto: > > > libgpod-nogtk-dev was a transitional package removed in libgpod 0.8.3-9. > > > > > > amarok is the only package build-depending on libgpod-nogtk-dev. > > > > Even if amarok is the only rdep, the "first I break, then I file > > serious bugs on rdeps" modus operandi is *not* a good way of > > cooperating with other packagers in Debian. > > Filing a bug some time before, or even writing an email, would have > > been a much nicer, and cooperative, way. > > amarok is not in testing and anyways needs a source upload for #784448. This is because of the amarok status, although my note was for the general way to work in Debian. > It is also worth looking at the around 300 (sic) currently open RC bugs > I have reported for FTBFS that were *not* caused by me [1]: Sure, and that is completely not relevant with what I said, nor it can even be used as "excuse" to "dump and file". > Current status quo in Debian is that it is completely normal that > a new upload of some package is followed by me filing 10-50 RC bugs > against packages that FTBFS due to that change. No, it is not. You are mixing two things in the same pot: a) breakages due to side-effect (possibly not known in advance) of new versions of packages b) well-known breakages that some change is going to cause My note was a general remark that for things in the (b) category above a pre-emptive email/bug/etc to the interested rdeps *is* the optimal way to interface with other people. I do not care if other people just dump stuff in unstable and expect other to clean up after the mess they created -- it is simply *not* correct, not even fair. > So when the only rdep is one package that is not in testing and anyways > requires a (non-trivial) sourceful upload for re-entering testing, > I fail to see any reasonable justification for me to spend additional > time on going through any process longer than just filing an RC bug. And this is again this very specific case. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#877295: [Pkg-kde-extras] Bug#877295: amarok build-depends on removed package libgpod-nogtk-dev
In data sabato 30 settembre 2017 13:17:43 CEST, Adrian Bunk ha scritto: > libgpod-nogtk-dev was a transitional package removed in libgpod 0.8.3-9. > > amarok is the only package build-depending on libgpod-nogtk-dev. Even if amarok is the only rdep, the "first I break, then I file serious bugs on rdeps" modus operandi is *not* a good way of cooperating with other packagers in Debian. Filing a bug some time before, or even writing an email, would have been a much nicer, and cooperative, way. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#874170: libappstreamqt-dev: AppStreamQtConfig.cmake hardcodes a 64bit behaviour
Package: libappstreamqt-dev Version: 0.11.4-1 Severity: grave Justification: renders package unusable Control: affects -1 src:frameworkintegration Control: affects -1 src:plasma-discover Hi, in the new version 0.11.4, I guess because of the switch from cmake to meson, the source got a template for the AppStreamQtConfig.cmake file. This template was created from an existing file on a 64bit system, so the final AppStreamQtConfig.cmake file is rejected by cmake when found by packages via cmake on 32bit architectures. Two examples are frameworkintergration, and plasma-discover: https://buildd.debian.org/status/logs.php?pkg=frameworkintegration&ver=5.37.0-2 https://buildd.debian.org/status/logs.php?pkg=plasma-discover&ver=5.10.5-1 In particular: < CMake Warning at CMakeLists.txt:44 (find_package): Could not find a configuration file for package "AppStreamQt" that is compatible with requested version "0.10.4". The following configuration files were considered but not accepted: /usr/lib/i386-linux-gnu/cmake/AppStreamQt/AppStreamQtConfig.cmake, version: 0.11.4 (64bit) < The severity is grave because this is an issue in the upstream sources, and because it's a regression compared to the previous version (and thus ought to not migrate to testing). -- Pino
Bug#854884: #854884: baloo: is this obsoleted by src:baloo-kf5?
In data giovedì 1 giugno 2017 14:28:58 CEST, Boyuan Yang ha scritto: > In my understanding, perhaps baloo4 is completely useless in Debian Stretch > with Plasma 5. Why don't we remove it from unstable/testing *now*? src:kdepim4, which provides ktimetracker and knode, requires the old baloo libraries. Patching that source honestly requires more work than what is worth spending. > Should anyone file a RM request for src:baloo immediately? No. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch
In data domenica 26 febbraio 2017 20:15:25 CET, John Paul Adrian Glaubitz ha scritto: > On 02/26/2017 07:48 PM, Sebastian Andrzej Siewior wrote: > > I don't insist on anything. I noticed that this package does not depend on > > libssl after building and that is why I took a look. That is because it dlopen's libssl at runtime. > Interesting. So, I guess the best option would actually to drop the B-D on > libssl-dev completely. I have checked it myself and indeed libkf5khtml5 does > not depend on libssl at all. Plus, the package also builds fine with the > build dependency on libssl-dev completely removed. That is because it is an optional dependency. > Lisandro, maybe just dropping the build dependency on libssl-dev would be > the best option if it's actually not used at all? NACK. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#850900: [Pkg-kde-extras] Bug#850900: amarok: 6GREPME MySQLe query failed! (2000)
forcemerge 849326 850900 thanks, Hi, In data martedì 10 gennaio 2017 22:20:19 CET, Alex Henry ha scritto: > Hello, I've written in some detail about the bug here: > > https://bugs.kde.org/show_bug.cgi?id=374891 > > I have marked this as grave because it generates data loss > (the collection metadata, which is an integral part of Amarok > and most users wouldn't enjoy losing their statistic, favorites, > etc, built over years since this is a major part of Amarok). It also > renders the packages unusable. It should be marked as grave so as > to prevent the package from going to stable in its current state. > > My issue is similar to #849326 - the major difference being that > Amarok also crashes when trying to play any file. This issue is a duplicate of #849326 (and thus I'm merging with it, so please followup there only). This is also a downstream-only issue, due to the mixup of MariaDB versions currently in testing/unstable, and I see the KDE bug was rightfully closed as DOWNSTREAM. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#849598: [Pkg-kde-extras] Bug#849598: amarok: FTBFS (cannot find -lmysqlclient)
severity 849598 important thanks Temporarly downgrading to important as a) I want amarok in testing, and not having it here by tomorrow means it won't be in stretch b) it looks like something due to MySQL/MariaDB, and possibly it will be sorted once the MariaDB version mess is over -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#849245: krita: segfault on startup
tag 849245 + moreinfo severity 849245 important thanks In data sabato 24 dicembre 2016 12:23:22 CET, Boyuan Yang ha scritto: > Package: krita > Version: 1:3.1.1+dfsg-1 > Severity: grave > Justification: renders package unuseable > > Hi, > > The new krita just won't start. > > Stderr output: > > [...] > Thread 1 (Thread 0x7efe1b6fd8c0 (LWP 18387)): > [KCrash Handler] > #6 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove- > vec-unaligned-erms.S:284 > #7 0x7efe29fe9a22 in memcpy (__len=18, __src=, > __dest=0x5626110d4b68) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 > #8 QResourceFileEngine::read (this=0x562610e477d0, data=0x5626110d4b68 "@K\r > \021&V", len=18) at io/qresource.cpp:1287 > #9 0x7efe29fbb83f in QFileDevice::readData > (this=this@entry=0x5626110737f0, data=0x5626110d4b68 "@K\r\021&V", > len=len@entry=16384) at io/qfiledevice.cpp:460 > #10 0x7efe29fc452e in QIODevice::read (this=0x5626110737f0, > data=0x7ffc43fc8f70 "", maxSize=18) at io/qiodevice.cpp:1076 > #11 0x7efe066030d4 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/ > imageformats/libxfreeimage.so > #12 0x7efe063a3805 in isTARGA20 (io=io@entry=0x7efe06807020, > handle=handle@entry=0x5626110737f0) at Source/FreeImage/PluginTARGA.cpp:371 > #13 0x7efe063a39aa in Validate (io=0x7efe06807020, handle=0x5626110737f0) > at Source/FreeImage/PluginTARGA.cpp:380 > #14 0x7efe06383940 in FreeImage_Validate (fif=fif@entry=FIF_TARGA, > io=io@entry=0x7efe06807020, handle=handle@entry=0x5626110737f0) at Source/ > FreeImage/Plugin.cpp:831 > #15 0x7efe06377ded in FreeImage_GetFileTypeFromHandle (io=0x7efe06807020, > handle=0x5626110737f0, size=) at Source/FreeImage/GetType.cpp: > 41 > #16 0x7efe0660313c in FreeImageHandler::GetFIF(QIODevice*, QByteArray > const&) () from /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/ > libxfreeimage.so > #17 0x7efe0660496c in FreeimageQt5Plugin::capabilities(QIODevice*, > QByteArray const&) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/ > imageformats/libxfreeimage.so Everything seems to happen in this libxfreeimage.so image plugin of qt5; I don't see it provided by any package in the Debian archive, so please paste the output of: $ dpkg -S /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libxfreeimage.so Is it https://github.com/linuxdeepin/deepin-image-viewer by chance? Another option is that the issue is in libfreeimage (src:freeimage), which does not seem to do proper error checking in its usage of I/O handlers... Anyway: does krita start fine if you remove the package installing that file, or simpy manually move that plugin away? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#844762: [Pkg-kde-extras] Bug#844762: amarok crashes on startup with "Message recipient disconnected from message bus without replying"
tag 844762 + moreinfo severity 844762 important thanks Hi, In data venerdì 18 novembre 2016 11:19:21 CET, Phil Dibowitz ha scritto: > Package: amarok > Version: 2.8.0-5 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Amarok crashes like this every time I start it: > > > $ amarok > QDBusConnection: session D-Bus connection created before QCoreApplication. > Application may misbehave. > QDBusConnection: session D-Bus connection created before QCoreApplication. > Application may misbehave. > Connecting to deprecated signal > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) > QDBusConnection: session D-Bus connection created before QCoreApplication. > Application may misbehave. > QDBusConnection: session D-Bus connection created before QCoreApplication. > Application may misbehave. > kbuildsycoca4 running... > KCrash: Application 'amarok' crashing... > KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit > KCrash: Connect sock_file=/home/phil/.kde/socket-rider/kdeinit4__0 > unnamed app(12406): Communication problem with "amarok" , it probably > crashed. > Error message was: "org.freedesktop.DBus.Error.NoReply" : " "Message > recipient disconnected from message bus without replying" " > > > I have tried removing my ~/.kde/apps/amarok but it doesn't help. The above just says amarok crashes, but nothing more. Let's try to get more information: a) install gdb b) run `gdb --args amarok --nofork` c) in the (gdb) prompt, execute `run` d) when the crash happens and the (gdb) prompt appears again, execute `thread apply all bt` e) execute `quit` to exit gdb, confirming with yes when asked whether kill the running application Please attach/write the full backtrace, with all the threads included. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#824959: [PATCH] kadu-mime-tex: remove extra build dependencies
tag 784473 + patch tag 824959 + patch thanks Hi Patryk, attached there is a patch to remove a number of build dependencies which are not used at all by kadu-mime-tex, including libqtwebkit-dev (#784473) and qtquick1-5-dev (#824959). qtdeclarative5-dev is explicitly added now, as it is needed to build and most probably it was implicitly pulled by one of the removed packages. I'll most probably NMU/5 in a week, unless it is fixed before, or there are objections/issues in NMUing. Thanks, -- Pino Toscano--- a/debian/control +++ b/debian/control @@ -4,41 +4,19 @@ Maintainer: Patryk Cisek = 9), chrpath, cmake, - enchant, kadu, kadu-dev (>= 1.2-2), - libarchive-dev, - libasound2-dev, - libaudio-dev, - libdbus-1-dev, - libenchant-dev, - libgadu-dev, - libidn11-dev, libinjeqt-dev, libkadu, - libmpdclient-dev, - libotr5-dev, - libphonon-dev, - libqca2-dev, - libqt4-dev, libqt5webkit5-dev, libqt5x11extras5-dev, - libqtwebkit-dev, - libsndfile1-dev (>= 1.0), - libsqlite3-dev, libxfixes-dev, - libxss-dev, - libxtst-dev, patchutils (>= 0.2.25), pkgconf, qtbase5-dev, - qtquick1-5-dev, - qtscript5-dev, + qtdeclarative5-dev, qttools5-dev, qttools5-dev-tools, - sharutils, - x11proto-scrnsaver-dev, - zlib1g-dev Standards-Version: 3.9.6 Section: libs Homepage: http://www.kadu.im/~patryk/plugins/mime_tex/ signature.asc Description: This is a digitally signed message part.
Bug#811846: #811846: status?
In data lunedì 19 settembre 2016 11:32:18 CEST, John Paul Adrian Glaubitz ha scritto: > On 09/19/2016 09:08 AM, Pino Toscano wrote: > > Looking further at this very issue (#811846), I don't think the > > solution implemented is actually the correct one: > > > > https://anonscm.debian.org/cgit/collab-maint/xbase64.git/commit/?id=39d6239543df5dff1707e14e129574ac393325af > > > > This just forces the C++ dialect to C++98, but that's only a workaround; > > looking at the build log in this bug (which can be produced also by > > rebuilding xbase64 in an up-to-date unstable/testing environment), > > there is a real bug in xbase64/xblock.cpp: > > > > std::cout << "xbLock constructor" << std::cout; > > > > std::cout is clearly wrong at the end, where std::endl is most probably > > what should be used; there are 5 occurrences of this in xbase64, all of > > them in xblock.cpp. > > Ugh, you're right. I somehow missed the debian/rules file completely, I > automatically interpreted the first changelog entry as "New upstream > release" and assumed those were upstream changes. > > Your fix is the correct one, of course. Interesting that the compiler > let's this slip with a warning instead of bailing out completely when > specifying -std=c++98. > > Anyway, I'll help Joerg incorporate the changes and the updated package > uploaded. Friendly ping. Note that, if nothing happens within few days (say, friday 30th), then I'll NMU/2 the patch I sent earlier; it has been already 3 months since the switch to GCC 6, and this bug was reported months earlier. xbase64 is not a leaf package, so leaving it unfixed means blocking other packages (calligra, at least in my case). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#811846: #811846: status?
tag 811846 + patch
thanks
In data domenica 18 settembre 2016 19:15:50 CEST, John Paul Adrian Glaubitz ha
scritto:
> On 09/18/2016 01:07 PM, John Paul Adrian Glaubitz wrote:
> > Sorry guys, was busy this weekend. Will look at it in a few hours :).
>
> There are two issues with the package on mentors that I see:
Looking further at this very issue (#811846), I don't think the
solution implemented is actually the correct one:
https://anonscm.debian.org/cgit/collab-maint/xbase64.git/commit/?id=39d6239543df5dff1707e14e129574ac393325af
This just forces the C++ dialect to C++98, but that's only a workaround;
looking at the build log in this bug (which can be produced also by
rebuilding xbase64 in an up-to-date unstable/testing environment),
there is a real bug in xbase64/xblock.cpp:
std::cout << "xbLock constructor" << std::cout;
std::cout is clearly wrong at the end, where std::endl is most probably
what should be used; there are 5 occurrences of this in xbase64, all of
them in xblock.cpp.
Attached there is an actual patch fixing the issue: please integrate it,
and remove the -std=c++98 workaround.
Thanks,
--
Pino Toscano--- a/xbase64/xblock.cpp
+++ b/xbase64/xblock.cpp
@@ -84,7 +84,7 @@ xbLock::xbLock(xbDbf * pdbf)
TableLockCnt = 0;
MemoLockCnt = 0;
IndexLockCnt = 0;
- std::cout << "xbLock constructor" << std::cout;
+ std::cout << "xbLock constructor" << std::endl;
}
/*/
xbLock::~xbLock()
@@ -169,7 +169,7 @@ else if( LockType == XB_LOCK || LockType
/*/
xbaseLock::xbaseLock( xbDbf * pdbf ) : xbLock( pdbf )
{
- std::cout << "xbaseLock constructor" << std::cout;
+ std::cout << "xbaseLock constructor" << std::endl;
}
/*/
xbShort xbaseLock::LockTableHeader( xbShort LockType )
@@ -336,7 +336,7 @@ xbShort xbaseLock::LockInit()
/*/
dbaseLock::dbaseLock( xbDbf * pdbf ) : xbLock( pdbf )
{
- std::cout << "dbaseLock constructor" << std::cout;
+ std::cout << "dbaseLock constructor" << std::endl;
}
/*/
xbShort dbaseLock::LockTableHeader( xbShort LockType )
@@ -460,7 +460,7 @@ xbShort dbaseLock::UnlockAll()
/*/
clipperLock::clipperLock( xbDbf * pdbf ) : xbLock( pdbf )
{
- std::cout << "clipperLock constructor" << std::cout;
+ std::cout << "clipperLock constructor" << std::endl;
}
/*/
xbShort clipperLock::LockTableHeader( xbShort LockType )
@@ -523,7 +523,7 @@ xbShort clipperLock::UnlockAll()
/*/
foxproLock::foxproLock( xbDbf * pdbf ) : xbLock( pdbf )
{
- std::cout << "foxproLock constructor" << std::cout;
+ std::cout << "foxproLock constructor" << std::endl;
}
/*/
xbShort foxproLock::LockTableHeader( xbShort LockType )
signature.asc
Description: This is a digitally signed message part.
Bug#811846: #811846: status?
Hi, what's the status of this bug (xbase64 that FTBFS with GCC 6)? Because of it, xbase64 was removed from testing a couple of months ago, and now it will prevent calligra (which ships a sybase access driver for kexi) to migrate to testing. Any way I can help with this? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#811432: Krita no longer part of Calligra
Hi,
In data lunedì 12 settembre 2016 14:56:12 CEST, juichenieder-deb...@yahoo.co.uk
ha scritto:
> root/debian/changelog
> This contains only the line for this package, this seems a bit odd to ditch
> the
> changelog from before. While Krita technically goes in to debian as a new
> package,
> it just replaces the older krita package, and I do not presume that upstream
> have
> started from scratch with krita 3.x. Of course the old-package's changelogs
> allias
> the entire calligra source package, so a copy-paste not doable, but I would
> expect
> more than just "Initial Release" as this breaks the flow from the previous
> version.
> Just something to document that krita has now split from Calligra and thus
> has been
> repackaged from scratch, so people don't feel so surprised to see an empty
> changelog.
This is technically the packaging of a new source: in the end, what I
could borrow from the calligra packaging was just the descriptions of
the packages; everything else (rules, build deps, copyright, etc) was
done from scratch.
I could have mentioned "Initial release, split from calligra", but IMHO
was not really true, and anyway it's too late now (if the source is
rejected I can amend it).
> In NEW, I see that you haven't listed krita as closing this bug. Would that
> help
> speed up the NEW process as this represents only a package split, rather than
> an
> actually NEW package?
This has almost no change on the processing of the source from the NEW
queue -- what will slow it is the review of the licenses & copyrights
for the huge amount of files (more than 9000) in the source.
Note the upload is targeted to experimental for now -- its upload to
unstable will close the "it's uninstallable" bug for krita (#811432).
> Should the new calligra package reference krita as a suggested package? Or
> treat it as
> completely separate.
Since I uploaded also calligra (and it's waiting in NEW as well),
I had to comment out the krita dependency in the calligra metapackage
(otherwise if calligra is accepted before krita, that metapackage will
be uninstallable and prevent the migration to testing).
Once both sources are accepted in the archive and migrated to testing
(which means they build fine on all the release architectures, and
there are no critical/RC bugs), I will readd it as recommend or
suggest.
> I notice a lot of commented out lines, personally I hate them in VCS as they
> undermine the reason for using a VCS. If you want to go back and look at old
> lines,
> use git for that, not comments.
Which ones are you referring to in particular? Most of the occurrences
are proper comments, and the two places which aren't are there for
actual reasons (like point out why libopenexr-dev is not enabled).
> I still don't understand what has changed between this version and the
> previous to
> fix the depend requirements, I still see ${misc:Depends}
> and${shlibs:Depends}, so
> won't this hit the same problem as before, or do I miss something with the
> reason
> calligra got removed before... did the new package depends break BC with
> regards
> calligra or something like that?
${shlibs:Depends} is the actual sauce of the dependencies: it contains
the list of libraries dependencies of the binaries & libraries in each
binary package. See the man pages of dh_shlibdeps & dpkg-shlibdeps to
know how they are filled, and dh_gencontrol & dpkg-gencontrol to know
how they are used.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#811432: Krita no longer part of Calligra
Hi people,
TL;DR: there is currently krita 3.0.1 currently in NEW, and calligra
2.9.11 reaching NEW soon.
In data domenica 4 settembre 2016 13:02:30 CEST,
juichenieder-deb...@yahoo.co.uk ha scritto:
> > My guess is that most of these bugs will fix themselves once 2.9 is
> > packaged. I think there were some attempts to fix these before, but the
> > package was rejected by the ftpmasters on copyright grounds - so they'll
> > need to be some work to sort that out.
>
> Yes, pretty much my philosophy. Why put time and energy into fixing something
> that you plan to discard for a newer version shortly after you have fixed it.
> When for all one knows, the upgraded package might auto-fix the problems you
> were trying to fix.
>
> That said, the copyright grounds don't seem too severe... I guess the file
> that
> they object to appeared in the build before, as they do not upload a new
> version,
> thus it must also appear in Jessie and Sid ports, and only one file that could
> get downloaded seperately.
It seems the issues that caused the reject of the latest NMU for 2.8.x
are gone in newer calligra versions. Reviewing the licenses of all the
files in calligra, and writing a copyright file for them, has never
been an easy task (more than 22000 files!) -- different approaches to
do this basically caused the friction between a couple of contributors
last year, causing both of them to eventually more their efforts
elsewhere.
> How much of a task goes into packaging something like Calligra? I see that
> calligra-2.9.10 went into the debian VCS on 2015-12-31 (last entry). I have
> no experience in packaging, slowly as time goes on I learn more and more about
> this dark art, until I reach the point where I feel ready to take the plunge.
Excluding the copyright parts, IMHO the packaging parts are not too
difficult: it's mostly building, putting the files installed by upstream
in the right packages, checking that the package relationships
(depends/recommends/etc) are correct, and stuff like that (including
testing, of course).
A potentially problematic part is the size of calligra itself: lots of
sources and libraries/executables, which take at least even 2 hours on
not-super-fast machines: this means that if you want to test a new
split package, or move files from package to package, and so on, it's
a "issue build + take a pause" cycle much longer than a cup of
$beverage...
> > I was thinking about helping packaging Krita, but I haven't found the
> > time as of yet.
>
> I would consider packaging it myself, but as I say, I don't feel quite ready
> to take the plunge just yet, and the time commitment puts me of a bit. I have
> reached the stage where ${misc:Depends} and ${shlibs:Depends} now pique my
> curiosity as that seems part of the initial problem here in this bug. That
> debian autodetects the wrong library (to link against?). As far as I
> understand.
I've took the time yesterday to work on the new krita 3.x, based on
Qt5+Frameworks; you can find its packaging among the rest of the pkg-kde
repositories [1]. Packaging itself didn't take much, but as usual
copyright took quite a lot. Anyway, I deemed it acceptable for now, so
built and uploaded it to NEW. If you have any improvements for it,
please reach me directly so I can queue them until krita is in NEW.
Regarding calligra: first of all, I dropped entirely krita from there
(because of src:krita), then cleaned up the rest of the packaging work
done already. Right now it's building on my machine, and will be
uploaded to NEW afterwards. As above, please do reach me directly for
any change until it's accepted in unstable again.
[1] https://anonscm.debian.org/cgit/pkg-kde/kde-std/krita.git
Regards,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#835687: plasma-sdk: FTBFS: dh_install: missing files, aborting
Hi, In data domenica 28 agosto 2016 12:27:34 CEST, Lucas Nussbaum ha scritto: > Source: plasma-sdk > Version: 5.7.0-1 Two days ago there was the upload od version 5.7.4-1: can you please try that one? I guess it would be better to not send a FTBFS bug report if the attempted version becomes older than the current one in unstable... Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#828911: FTBFS on various architectures when generating the gtk-doc documentation
Hi, On 2016-06-28 23:17, Michael Biebl wrote: After applying the change as requested by Pino in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823268 the package FTBFS on various architectures: https://buildd.debian.org/status/package.php?p=tracker I suspect gtk-doc is not really safe regarding parallel builds. This should be investigated or https://anonscm.debian.org/cgit/collab-maint/tracker.git/commit/?id=5f82b567362c0449f85a8008ba7d1a31735fe93c reverted. Sorry for the issue, it was working fine for my in my tests (and it still does, as I cannot trigger the build failure). Before disabling the parallel build, what about trying to backport the upstream commit 8a5ba082959b8439993f4d731445db12a4c5e301 (in tracker)? It is also included in the new version 1.9.0, so upgrading to that will provide that commit too. -- Pino Toscano
Bug#822578: marked as pending
tag 822578 pending thanks Hello, Bug #822578 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-freedesktop/poppler.git;a=commitdiff;h=7b76a0c --- commit 7b76a0cf5b66508c6a89b199b024c5269a882451 Author: Pino Toscano Date: Mon Apr 25 16:37:13 2016 +0200 fix a crash on invalid files; CVE-2015-8868 (#822578) backport upstream commit b3425dd3261679958cd56c0f71995c15d2124433 diff --git a/debian/changelog b/debian/changelog index cc47829..d7f7942 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,8 @@ poppler (0.38.0-3) UNRELEASED; urgency=medium + * Backport upstream commit b3425dd3261679958cd56c0f71995c15d2124433 to fix +a crash on invalid files, reported also as CVE-2015-8868; patch +upstream_Do-not-crash-on-invalid-files.patch. (Closes: #822578) -- Pino Toscano Mon, 25 Apr 2016 16:29:19 +0200
Bug#810069: elektra: FTBFS During Rebuild For Python3.5 Transition
tag 810069 + moreinfo thanks In data mercoledì 6 gennaio 2016 03:46:12, Scott Kitterman ha scritto: > Source: elektra > Version: 0.8.14-5 > Severity: serious > Justification: fails to build from source (but built successfully in the past) > > While rebuilding elektra in a chroot modified so that python3.5 is the default > python3, the follosing test failure ocurred: > > 31/92 Test #31: testmod_python2 ..***Failed0.07 sec > PYTHON TESTS > == > > Testing simple variable passing... > There are 1 warnings > buffer is: warnings/#00 > number: 11 > description: open of plugin returned unsuccessfully (reason contains plugin, > see other warnings for details) > ingroup: kdb > module: > file: /home/test/elektra-0.8.14/src/libelektra/plugin.c > line: 296 > reason: python2 > reason: > reason: > /home/test/elektra-0.8.14/src/plugins/python2/../python/testmod_python.c:52: > error in test_variable_passing: warnings in kdbOpen for plugin python2 > number: 111 > description: : python error > ingroup: : plugin > module: : python > at: /home/test/elektra-0.8.14/src/plugins/python2/../python/python.cpp:255 > reason: : Unable to import kdb module > mountpoint: : > configfile: : > /home/test/elektra-0.8.14/src/plugins/python2/../python/testmod_python.c:52: > error in test_variable_passing: error in kdbOpen for plugin python2 > /home/test/elektra-0.8.14/src/plugins/python2/../python/testmod_python.c:52: > fatal in test_variable_passing: could not open python2 plugin > > Since this appears to be related to python2 and not python3 I don't think it > is due to the changed python3 version. Please provide a full log of the build, including all the installed packages and their versions. Just tried rebuilding elektra in a clean chroot (using builder), and it build fine. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#796919: marked as pending
tag 796919 pending thanks Hello, Bug #796919 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-freedesktop/poppler.git;a=commitdiff;h=ca9d4b2 --- commit ca9d4b24657f8c84e9803d684258474e6672eada Author: Pino Toscano Date: Sat Aug 29 10:51:03 2015 +0200 handle new libstc++ ABI of GCC 5 on libpoppler-cpp (#796919) - rename libpoppler-cpp0 to libpoppler-cpp0v5 - make libpoppler-cpp0v5 conflict/replace libpoppler-cpp0 diff --git a/debian/changelog b/debian/changelog index 57728d4..4566591 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,8 @@ poppler (0.26.5-4) UNRELEASED; urgency=medium + * Handle the new libstc++ ABI of GCC 5 on libpoppler-cpp: (Closes: #796919) +- rename libpoppler-cpp0 to libpoppler-cpp0v5 +- make libpoppler-cpp0v5 conflict/replace libpoppler-cpp0 -- Pino Toscano Sat, 29 Aug 2015 10:44:48 +0200
Bug#793093: PDF makes pdftoppm to hang
Hi, In data martedì 21 luglio 2015 12:45:30, hai scritto: > I have closed this report because I'm not sure that it is a bug in > pdftoppm. > > However, I've tried again this command: > > pdftoppm -r 300 the-above-document.pdf foo > > and I see that page 8 takes 37 minutes to be rendered on my machine? > > Is this really a faulty PDF file, or it is possible that pdftoppm > is faulty instead? This is either some corner-case in poppler, not handling the document well, or a very convoluted document. We should check this bug's document again with more recent versions of poppler (0.26.x is not that new anymore...). Most probably not something fixable in stable. Thanks for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#767659: marked as pending
tag 767659 pending thanks Hello, Bug #767659 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: http://git.debian.org/?p=pkg-freedesktop/poppler.git;a=commitdiff;h=7929aa2 --- commit 7929aa2d5ec9464fea755f622319d224787c4110 Author: Pino Toscano Date: Sat Jul 25 19:34:57 2015 +0200 tighten libpopplerN dependencies (#767659) diff --git a/debian/changelog b/debian/changelog index f03b4e9..50bae0a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -5,6 +5,8 @@ poppler (0.26.5-3) UNRELEASED; urgency=medium (Closes: #774949) * Disable pie for now, as there seems to be an incompatibility between Qt5 and GCC >= 5. (Closes: #792592) + * Tighten dependencies on the libpopplerN package to the exact binary +version in other library packages and poppler-utils. (Closes: #767659) -- Pino Toscano Sat, 25 Jul 2015 19:21:17 +0200 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#789471: cg3: FTBFS on buildds
Source: cg3 Version: 0.9.9~r10439-1 Severity: serious Tags: patch Justification: fails to build from source Hi, cg3 does not build on Debian buildds. This is because among the build dependencies there is: libboost1.48-dev | libboost-dev (>= 1.49.0) given that on buildds only the first element of an OR is used (to make sure the build does not change depending on temporary issues of the alternatives), and that libboost1.48-dev does not exist. The solution is to use libboost-dev only, with the minimum version "lowered" to 1.48 (to include the former alternative option). Patch attached for it. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -6,7 +6,7 @@ Uploaders: Tino Didriksen Build-Depends: cmake (>= 2.8.9), debhelper (>= 9.0), - libboost1.48-dev | libboost-dev (>= 1.49.0), + libboost-dev (>= 1.48), libicu-dev (>= 4.8) Standards-Version: 3.9.6 Homepage: http://visl.sdu.dk/cg3.html
Bug#775034: apport: FTBFS on arch-only builds
Source: apport Version: 2.15.1-1 Severity: serious Tags: patch Justification: fails to build from source Control: found -1 apport/2.14.2-2 Hi, apport fails to build in arch-only builds (debian/rules build-arch), as done e.g. on buildds [1]. This happens because python(3)-distutils and python(3)-apt seem to be mandatory when building, and they are pulled as Build-Depends-Indep, so not when doing arch-only builds. Furthermore, the dh_install override edits files of arch:all binaries, which are not available in arch-only builds. The attached patch fixes these issues: - python-distutils-extra, python-apt, python3-distutils-extra, and python3-apt are now Build-Depends - apport-retrace and apport-kde are edited only when building their binaries [1] https://buildd.debian.org/status/logs.php?pkg=apport&ver=2.15.1-1 Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -9,11 +9,12 @@ Build-Depends: debhelper (>= 7.0.50~), net-tools, xauth, python-all, - python3-all -Build-Depends-Indep: python-distutils-extra (>= 2.24~), - python3-distutils-extra (>= 2.24~), + python3-all, + python-distutils-extra (>= 2.24~), python-apt (>= 0.7.9), + python3-distutils-extra (>= 2.24~), python3-apt (>= 0.7.9), +Build-Depends-Indep: intltool, xvfb, python-mock, --- a/debian/rules +++ b/debian/rules @@ -34,12 +34,16 @@ override_dh_install: dh_install -X.pyc -X.egg-info --list-missing pod2man -c Debhelper -r "$(DEB_VERSION)" debian/debhelper/dh_apport debian/debhelper/dh_apport.1 +ifneq (, $(filter apport-retrace, $(shell dh_listpackages))) # apport-retrace needs python-launchpadlib, which is not yet available # # for Python 3; so switch back to Python 2 sed -i '1 s/python3.*$$/python/' debian/apport-retrace/usr/bin/apport-retrace +endif +ifneq (, $(filter apport-kde, $(shell dh_listpackages))) # Same applies for KDE4... sed -i '1 s/python3.*$$/python/' debian/apport-kde/usr/share/apport/apport-kde +endif override_dh_python3: dh_python3 --skip-private
Bug#774699: kdevelop regularly crashes on diverse actions
tag 774699 + moreinfo thanks On 2015-01-06 13:40, Mike Gabriel wrote: Package: kdevelop Version: 4:4.3.1-3+b1 This is in wheezy ... -- System Information: Debian Release: 8.0 APT prefers stable APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 ... but wheezy is debian 7.x, not 8.x (which is jessie) ... Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) ... this is from jessie too ... Versions of packages kdevelop depends on: ii kde-runtime4:4.14.2-2 ii kdevelop-data 4:4.7.0-1 ii libc6 2.19-13 ii libgcc11:4.9.1-19 ii libkcmutils4 4:4.14.2-4 ii libkdecore54:4.14.2-4 ii libkdeui5 4:4.14.2-4 ii libkio54:4.14.2-4 ii libkparts4 4:4.14.2-4 ii libktexteditor44:4.14.2-4 ii libplasma3 4:4.14.2-4 ii libqt4-dbus4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqt4-help4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqt4-script 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2+b1 ii libqtwebkit4 2.3.4.dfsg-3 ii libstdc++6 4.9.1-19 ii libthreadweaver4 4:4.14.2-4 ... these are in jessie too ... ii kdevplatform5-libs 1.3.1-2 ii libkasten1controllers1 4:4.8.4+dfsg-1 ii libkasten1core14:4.8.4+dfsg-1 ii libkasten1okteta1controllers1 4:4.8.4+dfsg-1 ii libkasten1okteta1core1 4:4.8.4+dfsg-1 ii libkasten1okteta1gui1 4:4.8.4+dfsg-1 ii libprocessui4a 4:4.8.4-6 ii libsublime51.3.1-2 ... but these are in wheezy, and most probably are there because of the old kdevelop version. Your system is a weird mixup of wheezy and jessie, with a not totally clear situation (at least from the information provided here) of what is being installed. Please fix it first, either by having it fully on wheezy or on jessie, otherwise it is hard to debug such weird setup. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774287: kgpg don't start with dbus error
severity 774287 important
tag 774287 + moreinfo
thanks
On 2014-12-31 12:48, Jörg Frings-Fürst wrote:
Package: kgpg
Version: 4:4.14.2-1
Severity: grave
Please, please, please: do not open "grave" bugs when there is
basically
no information at all except "doesn't work".
Btw, kgpg starts and works fine here.
if I start kgpg I always get:
QDBusConnection: session D-Bus connection created before
QCoreApplication.
Application may misbehave.
QDBusConnection: session D-Bus connection created before
QCoreApplication.
Application may misbehave.
These messages are not actual errors, and are unrelated to what could
be
the problem you are reporting.
* have you checked whether there is kgpg process running?
* have you checked whether there is kgpg in the "hidden icons" section
of the kde's tray applet? (click on the small triangle-like icon on
its right)
* after running `kgpg`, does the execution gets back to the terminal,
or it stays there?
* run `kdebugdialog`, enable the two areas for kgpg ("2100 kgpg" and
"kgpg") and close it, and try running `kgpg` again; paste the
*full* output here
Thanks,
--
Pino Toscano
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767659: poppler: diff for NMU version 0.26.5-2.1
On 2014-11-15 22:57, Simon McVittie wrote: Control: tags 767659 + patch On Tue, 11 Nov 2014 at 10:33:42 +, Simon McVittie wrote: If the new symbol is public API that (in principle) other packages could use, which AFAICS it is, then I think the only solution that doesn't involve bumping shlibs for everyone is a symbols file. The attached seems to work as desired: libpoppler-glib8 ends up with a dependency on libpoppler46 (>= 0.26.5-2~), but libpoppler-qt4-4 (which presumably doesn't use GfxFont::getAlternateName) still depends on libpoppler46 (>= 0.26.5). Again, this is not the right approach. This bug *only* affects people which have upgraded just parts of jessie/testing in the last two weeks, without all of it. As I asked previously: please LET ME FIX IT. I *know* how to fix it, just had no proper time to do this. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767659: poppler: diff for NMU version 0.26.5-2.1
On 2014-11-10 21:36, Simon McVittie wrote: Control: tags 767659 + patch Control: tags 767659 + pending Dear maintainer, I've prepared an NMU for poppler (versioned as 0.26.5-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Please drop this NMU, since the approach chosen (bumping shlibs for everybody) is not correct. And please leave me the _time_ to fix it... not even asking what is the right approach, and just firing an NMU not even after one day I received this bug, does not seem that polite to me. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#768475: evince: segfault on trying to open a pdf
On 2014-11-09 23:04, Emilio Pozuelo Monfort wrote: On 09/11/14 00:51, Lennert Van Alboom wrote: I think you just hit bull's eye there. This was what I tested with: [alver@Crusoe ~]$ dpkg -l *poppler* | grep ^ii ii libpoppler-glib8:amd64 0.26.5-2 amd64PDF rendering library (GLib-based shared library) ii libpoppler46:amd64 0.26.5-1 amd64PDF rendering library ii poppler-data 0.4.7-1 all encoding data for the poppler PDF rendering library ii poppler-utils 0.26.5-2 amd64PDF utilities (based on Poppler) Do note the slight version difference between libpoppler46:amd64 and libpoppler-glib8:amd64. When installing libpoppler-dev as you requested, it pulled in libpoppler46:amd64 0.26.5-2, and lo and behold, evince opens PDFs again. So something in the tiny versions caused it, and somehow the version didn't get up to my workstation until just now. Reassigning to libpoppler. It sounds like libpoppler ought to have tighter dependencies if version mismatches cause segfaults. The current dependencies are enough to cover the majority of the cases; in this case, only the update from poppler 0.26.5-1 to 0.26.5-2 is affected, due to the addition of the patch upstream_Map-Standard-Expert-encoding-ligatures-to-AGLFN-name.patch (and -2 is in testing already). Thus, I'm not that sure this is much of an issue. Ah, looking at the original bug report: -- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) jessie has 3.16-3-amd64 Versions of packages evince depends on: ii libgdk-pixbuf2.0-0 2.30.8-1+b1 jessie has 2.31.1-2+b1 ii libnautilus-extension1a3.12.2-1 jessie has 3.14.0-1 ii gvfs 1.20.3-1 jessie has 1.22.1-1 I don't know how you update your system; regardless whether the dependencies are satisfied properly, I don't recommend to mixup/hold old versions of packages, since such combinations are much less tested, and possibly prone to silent breakages. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763924: onak: unbuildable on !linux archs
Source: onak Version: 0.4.5-1 Severity: serious Tags: patch Justification: fails to build from source (but built successfully in the past) Hi, currently onak cannot be built on non-Linux architectures, because of the systemd (Linux-specific) build dependencies. Since the features they enable are optional, those build dependencies can be safely restricted as linux-only. Patch attached for it. Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: net Priority: optional Maintainer: Jonathan McDowell Uploaders: Ross Burton -Build-Depends: debhelper (>= 9), dh-autoreconf, dh-systemd, libdb-dev, nettle-dev, libcurl4-gnutls-dev | libcurl-dev, libsystemd-dev (>= 214) | libsystemd-daemon-dev +Build-Depends: debhelper (>= 9), dh-autoreconf, dh-systemd, libdb-dev, nettle-dev, libcurl4-gnutls-dev | libcurl-dev, libsystemd-dev (>= 214) [linux-any] | libsystemd-daemon-dev [linux-any] Standards-Version: 3.9.6.0 Homepage: http://www.earth.li/projectpurple/progs/onak.html Vcs-Browser: http://the.earth.li/gitweb/?p=onak.git;a=summary
Bug#763840: iagno: file conflict with gnome-accessibility-themes < 3.14
Package: iagno
Version: 1:3.14.0-1
Severity: serious
Tags: patch
Justification: Policy 7.6.1, Policy 10.1
Hi,
when upgrading iagno to 1:3.14.0-1 (i.e. today's upgrade in
testing) while gnome-accessibility-themes is still at 3.12.0-1, a file
conflict is reported:
Preparing to unpack .../iagno_1%3a3.14.0-1_amd64.deb ...
Unpacking iagno (1:3.14.0-1) over (1:3.12.2-1) ...
dpkg: error processing archive
/var/cache/apt/archives/iagno_1%3a3.14.0-1_amd64.deb (--unpack):
trying to overwrite '/usr/share/icons/HighContrast/48x48/apps/iagno.png',
which is also in package gnome-accessibility-themes 3.12.0-1
It seems like the HighContrast icons of iagno moved in 3.14 from
gnome-accessibility-themes to iagno itself, so Breaks+Replaces is
missing here. Patch attached for it.
Thanks,
--
Pino
--- a/debian/control.in
+++ b/debian/control.in
@@ -25,6 +25,8 @@ Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends}
Recommends: yelp
+Breaks: gnome-accessibility-themes (<< 3.14.0)
+Replaces: gnome-accessibility-themes (<< 3.14.0)
Description: popular Othello game for GNOME
Iagno is a computer version of the game Reversi, more popularly called
Othello. Iagno is a two player strategy game similar to Go. The board
Bug#763587: five-or-more: file conflict with gnome-accessibility-themes < 3.14
Package: five-or-more
Version: 1:3.14.0-1
Severity: serious
Tags: patch
Justification: Policy 7.6.1, Policy 10.1
Hi,
when upgrading five-or-more to 1:3.14.0-1 (i.e. today's upgrade in
testing) while gnome-accessibility-themes is still at 3.12.0-1, a file
conflict is reported:
Unpacking five-or-more (1:3.14.0-1) over (1:3.12.2-1) ...
dpkg: error processing archive
/var/cache/apt/archives/five-or-more_1%3a3.14.0-1_amd64.deb (--unpack):
trying to overwrite
'/usr/share/icons/HighContrast/48x48/apps/five-or-more.png', which is also in
package gnome-accessibility-themes 3.12.0-1
It seems like the HighContrast icons of five-or-more moved in 3.14 from
gnome-accessibility-themes to five-or-more itself, so Breaks+Replaces
is missing here. Patch attached for it.
Thanks,
--
Pino
--- a/debian/control.in
+++ b/debian/control.in
@@ -23,8 +23,8 @@ Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends}
Recommends: yelp
-Breaks: glines (<< 1:3.7.2)
-Replaces: glines (<< 1:3.7.2)
+Breaks: glines (<< 1:3.7.2), gnome-accessibility-themes (<< 3.14.0)
+Replaces: glines (<< 1:3.7.2), gnome-accessibility-themes (<< 3.14.0)
Description: make color lines of five or more length
This is a GNOME port of the once popular “Color Lines” game.
.
Bug#763307: gnome-mines: file conflict with gnome-accessibility-themes < 3.14
Package: gnome-mines
Version: 1:3.14.0-1
Severity: serious
Tags: patch
Justification: Policy 7.6.1, Policy 10.1
Hi,
when upgrading gnome-mines to 1:3.14.0-1 (i.e. today's upgrade in
testing) while gnome-accessibility-themes is still at 3.12.0-1, a file
conflict is reported:
Preparing to unpack .../gnome-mines_1%3a3.14.0-1_amd64.deb ...
Unpacking gnome-mines (1:3.14.0-1) over (1:3.12.2-2) ...
dpkg: error processing archive
/var/cache/apt/archives/gnome-mines_1%3a3.14.0-1_amd64.deb (--unpack):
trying to overwrite
'/usr/share/icons/HighContrast/24x24/apps/gnome-mines.png', which is also in
package gnome-accessibility-themes 3.12.0-1
It seems like the HighContrast icons of gnome-mines moved in 3.14 from
gnome-accessibility-themes to gnome-mines itself, so Breaks+Replaces is
missing here. Patch attached for it.
Thanks,
--
Pino
--- a/debian/control.in
+++ b/debian/control.in
@@ -23,8 +23,8 @@ Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends}
Recommends: yelp
-Breaks: gnomine (<< 1:3.7.2)
-Replaces: gnomine (<< 1:3.7.2)
+Breaks: gnomine (<< 1:3.7.2), gnome-accessibility-themes (<< 3.14.0)
+Replaces: gnomine (<< 1:3.7.2), gnome-accessibility-themes (<< 3.14.0)
Description: popular minesweeper puzzle game for GNOME
Mines is a puzzle game where you locate mines floating in an ocean
using only your brain and a little bit of luck.
Bug#743596: #743596: fix for gimp with lcms2
Hi, I'm not sure there's much I can do at this point beyond patching upstream. Fixing debian/rules, for example: | DEB_CONFIGURE_EXTRA_FLAGS := --disable-static \ | --enable-python \ | PYTHON=/usr/bin/`pyversions -d` \ | --enable-default-binary \ | --enable-gtk-doc | --with-lcms=lcms2 \ | --without-webkit The \ is missing at the end of the --enable-gtk-doc line, so the other arguments, --with-lcms=lcms2 --without-webkit, are not part of DEB_CONFIGURE_EXTRA_FLAGS and thus not passed to configure. Thanks, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726799: #726799: not a shared-mime-info bug726...@bugs.debian.org
On 2014-09-14 13:28, Yann Dirson wrote: On Sun, Sep 14, 2014 at 10:12:41AM +0200, Pino Toscano wrote: Hi, first of all, the behaviour of update-mime-database is correct: it deletes files in *generated* directories. Yes, the various application, audio, text, subdirectories under /usr/share/mime are business of update-mime-database, where it places the XML mimetypes generated from the XML definitions in /usr/share/mime/packages. It is exactly in this directory where applications should install XML definitions of mime types to have them registered in the XDG mime type system. Installing stuff directly to e.g. /usr/share/mime/text is like installing to, say, /var/cache (i.e., you shouldn't). Furthermore, qgo is installing wrong things, and I will send the proper explanation and fix to #749582. This is not a bug in shared-mime-info, hence closing. Ah, that's interesting. But then: * why are those directories in /usr/ and not in /var/ in the first place ? Isn't this part of the shared-mime-info spec against the spirit of the FHS ? Possibly, although changing at this point is not exactly an easy task. * if it is deemed the right place for generated files, then we surely want a lintian check to spot the problem early Feel free to file a wishlist bug for lintian. * the update-mime-database manpage is quite terse, and does not explain that different parts of MIME-DIR have different roles. It is awkward to have to read the spec to get such important information I guess you are referring to the update-mime-database man page, right? This seems just specific to the tool itself, so IMHO what it lacks is pointers to the specifications. Another option would be having the specifications themselves as man page. -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
